I am working on with a HVAC app. Device has a lot of possible alarms, and I know I could use a custom boolean capability; but yet, I decided to try using proposed built-in alarm capabilities; on of them being alarm_fire, now; on the init, I decided to set all alarm states to false, when I noticed that I received alarm notification to my phone, that my device no longer detects fire. Well it never did as this was just caused because I set the initial value for alarm.
This made me think that if I setup flows that are activated when (any) alarm states change- they will fire. So, I removed initial setup of values, but that leaves the alarm sensor value to state “-” when it should say “No”.. To set initial values, I used setCapabilityValue(‘alarm_class.name’, false);
Is there another way to set initial value to false, which would not cause non-intentional notification or triggering? If not, what other proposals are recommended for this?
AFAIK, Homey remembers the last state of a capability and will only trigger such events if the value is set to a different state. So, you should only get one false alarm when the app is first installed, as the default value is undefined, and after that it should be OK.
I don’t think there is any other official way to set a capability value and I am not aware of any unofficial methods.
Best way in your case is to use a custom capability where you can define own text/icon.
This way, a generic Homey alarm is not triggeres - Homes raises alerts if fire/water alarms are triggered.
The initial “alarm off” trigger wil be raised if you define your flow triggers (custom triggers for your capability).
Instead of these flow triggers, you can also define a completely independent trigger. Jist don’t use capability name and default suffix. These triggers, you can execute in your app on conditions you want.
I took following approach, as a reminder, this is a HVAC/heat pump-
There’s 2 different alerts: filter alert and device alert - where device alerts.. Well are real immediate attention requiring alerts.
System stores up to 3 different alerts at same time. So- filter alarm is filtered from list of alerts, if active; and it fire’s filter alarm; if there was nothing to filter, or on the list, there are more alerts, it triggers device alarm. Also it adds capabilities (text/sensor) at maximum of 3 (let’s say alert1, alert2 and alert3 - can’t remember how I named them), where it displays alarm description in text (machine gives them out as codes from 0-58 and 70-70x and 90-92 ranges). It monitors on-going alarms and changes these error descriptions if they change, or if one of those alarms goes off, capability will be removed.
So now when device is added, with proper descriptions, list get’s “filter is OK” and “device is functioning properly” or something like that.
There’s one more thing that is strange- when I add my device, these 2 alarms, filter and device- are set to false (from null), but still, sensor’s tab/page shows “-” as their status. Now, if I stop execution of my app, device is still on Homey, but unavailable because software is missing- and then I restart my app again, so my device comes up because software is up again. From logs, I can see, that alarm states were not changed (because it happens only on add of device), but yet - on the sensors page, it now displays correctly “No” instead of “-”.
Is this a bug in my work, or bug in homey’s system? This is easy to replicate; happens every time.
Software is here with links to source at GitHub; though you would need a modbus tcp adapter and Nilan heat pump with cts602 board to actually test. Maybe it will happen on a simpler app as well if someone wants to check it out.
This is mostly harmful, whether it says “no” or “-”, it signs a negative status. It would be more problematic, if it would say “yes” when it definitely shouldn’t. So pretty much cosmetic- but if it’s in my work… I’d like to fix it.
