Sticky Unreach information will not be reset under objects even if there is already reset in CCU

[smartboart]

Hello ,
The Sticky Unreach information will not be reset automatically under objects even if it is already reset in CCU. The state still stands on true.

[foxriver76]

Do you mean the state UNREACH or the state UNREACH_ALARM?

[foxriver76]

If you mean the alarm state, I can confirm this. It seems like the script to read alarms shows state 2 for solved alarms, like:

    "1321": {
        "Name": "AL-OEQ1197840%3A0.CONFIG_PENDING",
        "AlState": 2,
        "AlOccurrenceTime": "2019-01-24 15:02:20",
        "LastTriggerTime": "2019-01-24 15:05:27",
        "Operations": 5,
        "AlTriggerDP": 1320,
        "Parent": 1318
    }

and state 1 for an currently present alarm. But the code in rega seems like it has been implemented to interpret 0 as no alarm and everything else as an active alarm by using

            const state = {
                val: !!data[dp].AlState,
                ack: true,
                lc: new Date(data[dp].AlOccurrenceTime),
                ts: new Date(data[dp].LastTriggerTime)
            };

Unfortunately I am not able to find more information about AlState: 2 so I can only assume that it says: Once there was an alarm. So I would suggest to set the alarm indicator to false if its !== 1

@smartboart please anyway give me an answer to my question to be sure. ;-)

[Apollon77]

The idea of the (iobroker onw) ALARM states is to use them as "true" trigger option when it happends. They are not supporsed to be reset

[foxriver76]

Thanks for clarification, so if the alarm state was meant it works as designed. Maybe enhancing Readme would be a good option.

[smartboart]

OK, understand... I mean sticky unreach and sticky unreach alarm. But I am quit sure that all reacts the same. Just sticky happens quit often. That's maybe why it hurts me the most.. I trigger with this state a counting script to see which hardware seems to have some trouble... So I would be happy to have this information as a trigger in both directions... I mean I also want to know if the problem is acknowledged and not present anymore... For my opinion it makes sense to update this states also...

[foxriver76]

Yes, e. g. the UNREACH state should work like this (not the UNREACH_ALARM). Tested it with Config pending state today and it worked as expected.

[foxriver76]

@Apollon77 I still think there is something wrong with the implementation of alarms. Maybe the following example helps:

1. I took out the battery of one of my devices and changed config to create a config pending message
2. ioB polls alarms and recognizes alarm state (1) --> ioB changes related alarm to true
3. I set the realated alarm in ioB to false, this triggers the acknowledgeAlarm function --> service message is gone in CCU
4. Alarm script polls --> now the config pending alarm state is 2 by the rega script (which MAYBE means, the alarm has been acknowledged), due to the fact, that the adapter interprets a 2 as true, my alarm state is again set to true in ioB, but the service message is already gone
5. so I would still expect that a 2 not means alarm should be set to true

I know you are also not deep in this alarm meachanics, but as it is implemented at the moment, it makes no sense for me.

[foxriver76]

On the other hand due to the fact, that the alarm is set with its occurence time in last changed, users may use it as an indicator when the alarm has happened, but it's still weird, that you are not able to recognize if the alarm is present or already acknowledged by the user.

So my 3 possible approaches would be, but option 3 sounds most promising to me:

1. Add this behavior to documentation
2. Alarm states !== 1 should set the state to false
3. make alarm state a Key Value Pair like

states: {
    0: 'NO ALARM',
    1: 'ALARM',
    2: 'ALARM ACKNOWLEDGED' 
}

[foxriver76]

Added documentation + reworked the alarm states as described here https://github.com/ioBroker/ioBroker.hm-rega#what-are-the-alarm-states-created-in-the-devices-object in d6c775e

[Apollon77]

Cool I even did not knew that :-)