Requesting current NOTIFICATION event status


#1

I’d like to understand how to request the current status of a notification event. The spec states that “The Notification Get Command is used to request the status of a specific Notification Type” and “A device implementing push mode MUST respond to the Notification Get by returning a Notification Report command advertising the current status for unsolicited messaging.”

As an example, if I send a request of the battery notification “Replace battery soon” - v1 alarm= 0, notification 8, event 10, I get a response providing a notification status of FF (meaning Unsolicited messages are enabled for the specified Notification Type) and otherwise returns the notification type and event.

How do I interpret this? Given it’s responded with the notification event, do I assume that this means the event is triggered (and in this case it shouldn’t be as the battery state is reporting as 100%). I would have thought that if the event was not triggered, it would return with event 0 to indicate event is inactive.

Can someone clarify how this should be handled?

Thanks
Chris


#2

FF means that the unsolicited messaging is enabled as stated.

This means that the node will send you notification whenever it is designed to do so. You cannot know what triggers an notification, however it may be specified in the device documentation.

The status cannot relay the exact battery value, but certain events:

If you need readings of the battery level, refer to the battery command class.

Best regards,
Crilles


#3

If I understand correctly, the FF means that events are enabled (as I wrote in my first message, this is stated in the spec and I interpret this to mean the device will send events when they change) not that the event is active (ie that the event is triggered). I understand that the battery command class is used to read the battery state - as I said, this reads as 100% in this case, so I would not expect this event to be triggered.

Maybe using the battery low event was a bad example - let’s use a different one. For a door sensor, the device will send a specific event when the door is opened, and then another when the door closes. If the door is left open, how can I find out that the door is open - ie I want to read the state of the event.

As I wrote above, the spec states “A device implementing push mode MUST respond to the Notification Get by returning a Notification Report command advertising the current status for unsolicited messaging”. I interpret this to mean that I can use the GET command to read the state. In my battery example, I therefore think I should be able to read the state of this event to know if the “replace battery soon” event is currently triggered.

I hope that is clearer?


#4

Hi,
I was wondering if you had any more thoughts on how to get the current notification status (as above)? Is this possible at all even or can we only get the state of the reports (ie unsolicited reports are on or off) and not the state of the event (ie triggered or not triggered)?

Thanks
Chris


#5

The notification (previously name Alarm) command class is event driven, meaning that whenever something happens the sensor will either queue the event if operating in ”pull” mode, or sent it immediately if operating in ”push” mode.

• In pull mode sending a get to the device will make the device sent you reports until the queue is empty.
• In push mode sending a get to the device will make the device report the status for unsolicited messaging.

Most of the events you are referring to are implemented on push nodes, as the event has no value later, as an example a smoke alarm in pull mode makes no sense. And here you have the issue you are referring to.

The case is further complicated by the fact that many of these nodes are sleeping battery powered nodes, that may not be reachable as they may have very long wake up intervals.

This unfortunately means that there is little you can do from your side, as changing this requires a revised command class, and that the sensor manufacturers implement the revised command class. For this reason Z-ware implements a caching mechanism of these events, allowing to retrieve them later.

Best regards,
Crilles


#6

Thanks for the response. I’m not sure that I agree that the notifications have no meaning if polled - a door open event gets sent when the door is open, but without the ability to poll its status we don’t know if it remains open.

Of course openhab also caches the status, but when the system starts we refresh the status and this is where the issue lies.

Anyway, I don’t ask to change the command class (even if I think it would be a good idea :wink: ) just to understand how it is intended to work at the moment, so the answer is fine - thanks.

Cheers
Chris


#7

“…Most of the events you are referring to are implemented on push nodes, as the event has no value later, as an example a smoke alarm in pull mode makes no sense…”

Is it possible to expand on this as I do not understand it. My experience of edge triggered events in real-time systems is that you always need to interrogate the relevant state machine (ie the sensor in this case) as events do get missed.

My interpretation of the quote above is that if a smoke alarm goes into a ‘smoke detected’ state and sends the corresponding event, it’s not possible to ask the smoke alarm if it is in the ‘smoke detected’ state. Thus if the first event gets lost, it’s not possible to tell that the smoke alarm has spotted smoke.

What have I got wrong?

regards

Tim


#8

Bump.

This issue is turning into a significant issue for me. Is there any command class that can be used to get a device to tell me what its current state is? Does notification Pull mode work for this, or can I get confirmation if I get in fast enough when a device is awake?

I don’t care so much if it is asleep when the request is sent. What I’m seeing at the moment is door sensors that are sending streams of apparently inconsistent event transitions (eg a series of ‘open’ events over a period of days, with no corresponding ‘closes’), and I’d like some application level mechanism to confirm the current state.

I don’t know whether it’s been fixed in the Lock specification, but it used to be the case that the lock wasn’t aware of the state of the door, so extra devices were required to distinguish between the back door being locked open vs locked shut :slight_smile:

tc