Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable/Disable sensors through switches #80

Open
davidecavestro opened this issue Oct 14, 2023 · 1 comment
Open

Enable/Disable sensors through switches #80

davidecavestro opened this issue Oct 14, 2023 · 1 comment

Comments

@davidecavestro
Copy link

Is your feature request related to a problem? Please describe.
Sometimes I miss in HA a way to exclude/include a sensor, as can be done from econnect web UI

image

Describe the solution you'd like
I'd like to have an additional switch for every input sensor, that when toggled excludes/includes that sensor.
When a sensor is bypassed this way (excluded), arming any sector will ignore its status until it is included again.
The effect is persistent.
The API client already supports this action through the exclude/include methods.

Describe alternatives you've considered
There is no way to exclude a set of sensors in one shot - that is with a single call to the econnect api - as it just exposes primitives to toggle one single sensor at a time.
That said, it should be possible for the HA user to create groups of switches leveraging multiple calls under the hood.

Additional context
The action of excluding/including a sensor needs the same permissions as when arming a sector, so the client in turn has to acquire a lock and temporarily switch to write mode.
This means it has to provide the pin code.

Asking the pin code from UI is not feasible/desirable, so the code should be saved somewhere from the config flow.
OTOH the pin code must be handled carefully, as it is the key to arm/disarm the entire system and any leak would be harmful at least.

Getting the pin from the HA secrets would potentially disclose it to any other HA component/automation.
Furthermore HA support for secrets seems limited to reading contents from a secrets.yml file manually/externally edited by the user: this would be cumbersome for users lacking knowledge of yaml syntax.
So far I found no evidence of support or best practices for storing secrets other than through the secrets.yml file.
Also checking Alarmo project for a safe way to store and retrieve the pinCode, it seems that its use case is different, as it doesn't need to actually retrieve the original pin, but just its hash, so it uses bcrypt to validate it against the value submitted by the user.

A trivial way to encrypt/decrypt the pin for storage would be using a key obtained hashing some user info, such as the username and password, but clearly anyone having access to that info could do the same, so gaining access to the pin code.

@lelelic
Copy link

lelelic commented Mar 16, 2024

Would this allow an automation system to be able to disarm or alarm only one sensor?
I'm building an automation system that closes shutters at a specific time that can be alarmed. So I would have to disarm the shutter, close it and then re-alarm it. I can't disarm the whole alarm, otherwise if one shutter takes longer than another, it would re-alarm the alarm while the other is still moving..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants