lelelic
commented
3 months ago 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..
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
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.ymlfile 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 thesecrets.ymlfile. 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.