Unexpected alarm report (?) from Zwave device

tonus · May 13, 2021, 11:32am

OK, so I was brave and added the Zwave BeNext Panic button to the database. The help of Chris was excellent, and it all worked pretty soon. Basic functionality is OK, still some enhancements to be done by me at the manual.

I’m on 3.1.0-SNAPSHOT - Build #2350, Zwave bundle version 3.1.0.202104250336.

But than the alarm of that device happened during the middle of the night, totally unexpected. So I was puzzled, and looked at the Zwave log file:

At 05:31:51.426 the sensors wakes up. That seems fine.
The battery report at 05:31:51.916 seems to be expected too.
However, at 05:31:52.135 the ALARM_REPORT is strange.

What’s going on?
Would it be possible that the sensor send such an alarm by design ? Because the alarm value was still ON ?
Any idea’s?

Something different:
Any ideas about the repeated Neighbor Update Failed messages?

chris · May 13, 2021, 9:30pm

This looks to be part of the initialisation and the binding has polled the device, and the device looks like it has said the alarm is active. The binding always polls devices as part of the startup to find their state - if this is a device that only reports ON, then this is probably not worth doing, and given it causes problems, can be disabled.

In the database, for the ALARM command class, you can add the NOGET option. This should prevent the binding requesting the status, and will rely on the device sending updates by itself.

tonus · May 16, 2021, 7:28am

The binding always polls devices as part of the startup to find their state - if this is a device that only reports ON, then this is probably not worth doing, and given it causes problems, can be disabled.

That seems to be the case! Thanks for the clarification.

The device reports ON when the button is pressed, and stays on. When pressed again, it reports OFF. So when it is still ON, and the wake up will happen (may be in the middle of the night), you get a repeated alarm?

In the database, for the ALARM command class, you can add the NOGET option. This should prevent the binding requesting the status, and will rely on the device sending updates by itself.

Seems like a good solution. Should I put the NOGET option at all endpoints (switch_binary, sensor_binary, and alarm_general) ?

But what happens when the device is out of reach of the controller and the button is pressed? The new alarm state is kept, and later when at the wake up, supposing it is back in reach then, the (late) alarm will be transferred to the controller, but OH will ignore it?

chris · May 16, 2021, 8:33pm

I would expect that if it is out of range of the mesh, then the state will not get reported.

tonus · June 4, 2021, 10:34am

I would expect that if it is out of range of the mesh, then the state will not get reported.
the device is out of reach, and you push the button, the device tries to sent the message, cannot reach the Zwave network, and reports an error (LED blinks 3 x).
Once back in reach, it will not send the alarm message again. This make sense, as trying to send the message forever would drain the battery.

In the database, for the ALARM command class, you can add the NOGET option. This should prevent the binding requesting the status, and will rely on the device sending updates by itself.

Has this been fixed Chris? I added the NOGET option in OpenSmartHouse. According to the database, an update of the database has been made. However,
However, using the new Zwave binding jar file, the behaviour described above still occurs.

rossko57 · June 4, 2021, 11:27am

I’m not sure you’re going at this the right way. Who/what thinks ON represents an alarm condition? Should it be taking previous state into account - if the state wasn’t OFF before, then a report of ON now means little (it seems you should be expecting periodic ON reports).

I’m suspecting you might need to be looking at rules that act on OFF-to-ON transition and vice versa; and ignoring NULL-to-either.

chris · June 4, 2021, 8:22pm

If you made the updates, then it will have been updated in the binding by now. If you have updated the binding, you must also delete the thing and add it back so that OH updates the thing configuration. Otherwise nothing will change in your system.

tonus · March 4, 2022, 9:48am

I added the “noget” parameter to the endpoints, last year in May, on http://opensmarthouse.org. I assume this was not yet taken in the database/jar update, but recently in the new Zwave .jar file, Build #144 on 28 feb 2022, on Database update (#1744) · openhab/org.openhab.binding.zwave@b4a1999 · GitHub I saw some changes about this BeNext Panic Button.

I tried this in OH 3.3.0.M2, removed the default Zwave library, add the new .jar file in /usr/share/openhab/addons, restarted OH, excluded the old device, and included the device again.
This library was accepted:

openhab> bundle:list | grep -i Zwave
261 │ Active │  80 │ 3.3.0.202202280349    │ openHAB Add-ons :: Bundles :: ZWave Binding

However, trying to include the device, it is not recognized anymore! Here some relevant lines from the openhab.log:

09:45:59.267 - NODE 19: Node advancer: DYNAMIC_VALUES - checking COMMAND_CLASS_MANUFACTURER_SPECIFIC
09:45:59.268 - NODE 19: Node advancer: DYNAMIC_VALUES - checking COMMAND_CLASS_BASIC
09:45:59.269 - NODE 19: Node advancer: DYNAMIC_VALUES - checking COMMAND_CLASS_NO_OPERATION
09:45:59.270 - NODE 19: Node advancer: DYNAMIC_VALUES - checking COMMAND_CLASS_BATTERY
09:45:59.271 - NODE 19: Found 1 instances of COMMAND_CLASS_BATTERY for endpoint 0
09:45:59.271 - NODE 19: SECURITY not supported
09:45:59.272 - NODE 19: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured
09:45:59.277 - NODE 19: ZWaveCommandClassTransactionPayload - send to node
09:45:59.278 - NODE 19: SECURITY not supported
09:45:59.278 - NODE 19: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured
09:45:59.279 - NODE 19: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@65407e
09:45:59.281 - NODE 19: Bump transaction 104 priority from Get to Immediate
09:45:59.285 - NODE 19: Adding to device queue
09:45:59.286 - NODE 19: Added 104 to queue - size 1
09:45:59.286 - NODE 19: SendData Request. CallBack ID = 161, Status = Transmission complete and ACK received(0)
09:45:59.288 - NODE 19: Response processed after 38ms
09:45:59.289 - NODE 19: TID 103: Transaction completed
09:45:59.290 - NODE 19: notifyTransactionResponse TID:103 DONE
09:45:59.293 - NODE 19: Went to sleep COMPLETE
09:46:53.442 - NODE 19: Unable to find thing type (008A:0014:0101:0.31)   <==============
09:46:53.442 - NODE 19: Controller status changed to ONLINE.
09:46:53.443 - NODE 19: Controller is ONLINE. Starting device initialisation.
09:46:53.447 - NODE 19: Updating node properties.
09:46:53.450 - NODE 19: Updating node properties. MAN=138
09:46:53.450 - NODE 19: Updating node properties. MAN=138. SET. Was 138
09:46:53.451 - NODE 19: Properties synchronised
09:46:53.453 - NODE 19: Configuration synchronised
09:46:53.459 - NODE 19: Initialising Thing Node...
09:46:53.460 - NODE 19: Polling initialised at 1800 seconds - start in 1666800 milliseconds.
09:46:53.461 - NODE 19: Device initialisation complete.

Anyone any idea’s?

chris · March 4, 2022, 6:46pm

If you made changes last May, and the changes were reviewed and approved, then they would definately have been in the binding last May. The only way this would not be the case is if the device was not requested for review and then not approved.

Someone has made changes to the database and not requested review. As above, this can result in the device being removed from the snapshot binding which changes are ongoing.

tonus · March 5, 2022, 10:02am

Then it might be simple! How to request for review? It that a button or a ticket? Sorry, but I have no idea…

anon71759204 · March 5, 2022, 11:47am

grafik

tonus · March 5, 2022, 1:00pm

Ooops … painfully simple…
Totally overlooked that. It is at the overview page.
And done immediately!
Thanks @anon71759204

tonus · March 9, 2022, 9:23pm

At now the device is back in the jar file ! (release 45) Thanks @chris )

However, the status of the alarm_general channel is still be requested after a wakeup, see below at 18:24:53.630:

Reading back the tip of Chris, looking back in the databases edit proposals I made, I came to the conclusion you can put a NOGET at 2 levels (!):

At the channel level (what I did, unfortanedly )
At the command class level (what Chris described)

Can someone confirm that it is now correct? (RED is old, green is new situation)

Can the NOGET at the channel level do any harm?

Thanks!

tonus · March 22, 2022, 9:07pm

This is fixed now!
My assumptions (NOGET must be at the command class level) appears to be correct. This was fixed by the last update of the Zwave jar file (Build 146), generated by @chris. Thanks a lot!!

Now this device is ready to be used!

Now how to “finalize” this device in the database ?
How to make sure this is OK and the definition is final ?

One minor point is left:
This device has an unusual reset procedure, by a config item that is both writable as set by the device:

When you write 255 (0xFF) to this parameter, all configurable values are set back to their defaults. After some time, at the next wake up, the device will “answer” that by making the value -86 again (input is 0 to 255, but output is -128 to +127, in 2’s complement notation)

I can see this line in my logfile, after changing the sensor:

21:50:24.456 NODE 28: Application Command Request (ALIVE:DONE)
21:50:24.457 NODE 28: resetResendCount initComplete=true isDead=false
21:50:24.458 NODE 28: Incoming command class COMMAND_CLASS_CONFIGURATION, endpoint 0
21:50:24.459 NODE 28: SECURITY not supported
21:50:24.460 NODE 28: Received COMMAND_CLASS_CONFIGURATION V1 CONFIGURATIONCMD_REPORT
21:50:24.460 NODE 28: Node configuration report, parameter = 1, value = -86, size = 1
21:50:24.461 NODE 28: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent
21:50:24.462 NODE 28: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CONFIGURATION, value=
21:50:24.463 NODE 28: Update CONFIGURATION 1/1 to -86
21:50:24.464 NODE 28: Configuration pending removed for config_1_1
21:50:24.464 NODE 28: Commands processed 1.
21:50:24.465 NODE 28: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@c8c39e.
21:50:24.466 NODE 28: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@c8c39e.
21:50:24.467 NODE 28: notifyTransactionResponse TID:861 DONE
21:50:24.468 NODE 28: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
21:50:24.469 Transaction completed - outstandingTransactions 1
21:50:24.470 Transaction completed - outstandingTransactions 0
21:50:24.471 ZWaveReceiveThread queue empty
21:50:24.472 Transaction SendNextMessage 0 out at start. Holdoff false.
21:50:24.835 NODE 28: WakeupTimerTask 0 Messages waiting, state DONE
21:50:25.335 NODE 28: WakeupTimerTask 0 Messages waiting, state DONE
21:50:25.336 NODE 28: No more messages, go back to sleep
21:50:25.337 NODE 28: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
21:50:25.338 NODE 28: SECURITY not supported
21:50:25.339 NODE 28: Command Class COMMAND_CLASS_WAKE_UP is NOT required to be secured
21:50:25.340 NODE 28: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactio
nPayload@9564f7

It seems like the sensor is anwering with ‘-86’, however, the OpenHab CLI (neither GUI) does not reflect this:

openhab> openhab:things show zwave:device:07a8817ea9:node28
...
        config_1_1 : 2
...

This is not a big deal, but it puzzles me…

What to do about that?
Perhaps ignore it?