ZWave: Temper alarm not supported for Aeotec Gen5 Door/Window Sensor (ZW120)?

skeil · January 4, 2020, 9:35am

Hi all,

I have a “ZWave Aeotec Gen5 Door/Window Sensor” which works ok [*] with openHAB 2.5.0.1, just the temper alarm (switch checking if device is (un)mounted) seems not to work.
I thought that would be the alarm_general channel, but in the UI a respective item

Switch HaustuerSensor_Alarm "HaustuerSensor_Alarm [%s]" <siren> { channel="zwave:device:af5df4d6:node5:alarm_general" }

is not updated.
Is alarm_general the right channel? Is it configured correctly? Any hints are welcome.

Here’s the log when pressing the switch (i.e. changing from “unmounted” to “mounted”):

2020-01-04 09:58:06.809 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 05 0A 71 05 00 00 00 FF 07 00 00 00 68 
2020-01-04 09:58:06.816 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=0, payload=00 05 0A 71 05 00 00 00 FF 07 00 00 00 
2020-01-04 09:58:06.820 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=0, payload=00 05 0A 71 05 00 00 00 FF 07 00 00 00 
2020-01-04 09:58:06.822 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2020-01-04 09:58:06.824 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Application Command Request (ALIVE:REQUEST_NIF)
2020-01-04 09:58:06.827 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2020-01-04 09:58:06.829 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: SECURITY not supported
2020-01-04 09:58:06.831 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 5: Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT
2020-01-04 09:58:06.833 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: NOTIFICATION report - 0 = 0, event=0, status=255, plen=0
2020-01-04 09:58:06.835 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: Alarm Type = BURGLAR (0)
2020-01-04 09:58:06.837 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2020-01-04 09:58:06.839 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2020-01-04 09:58:06.842 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 5: Alarm converter processing NOTIFICATION
2020-01-04 09:58:06.845 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 5: Alarm converter NOTIFICATION event is 0, type OnOffType
2020-01-04 09:58:06.847 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 5: Alarm converter NOTIFICATION event is 0, channel alarm_general is not implemented.
2020-01-04 09:58:06.850 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Commands processed 1.
2020-01-04 09:58:06.852 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@b4e21b.
2020-01-04 09:58:06.854 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2020-01-04 09:58:06.856 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2020-01-04 09:58:06.859 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2020-01-04 09:58:06.861 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

[*] I really had a hard time making it work - the binary channel simply stayed silent, battery always at NaN. Just all of a sudden it started working. Not sure what went wrong before, so I don’t have full trust yet…

vespaman · January 4, 2020, 9:54am

Hi, and welcome!

Your Z-stick is one of the most common one, and not part of the problem you are experiencing.
So in order for someone to be able to help out, we need to know what kind of device you have (the “HaustenSensor”), that is not sending the tamper alarm. Hopefully someone has exactly that device, and knows more about it.

Bruce_Osborne · January 4, 2020, 9:59am

And please use code fences for log postings! There is a tutorial thread on how to do that.

sihui · January 4, 2020, 10:19am

I guess you are talking about the Door/Window Sensor Gen5?

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/405

According to the manual I cannot find any information that a tamper alarm can be triggered:

skeil · January 4, 2020, 10:31am

Sorry, my bad, indeed I noted the controller and not the device: So it is a Aeotec Gen5 Door/Window (ZW120) sensor. I corrected that in the title and text.

Btw: re-searching I found that this problem was reported before but without a solution.

skeil · January 4, 2020, 10:34am

Ja, sorry, done - but not sure if done correctly (using 3 back-ticks) as it adds some “random” formatting (some words colored, bold texts).

Bruce_Osborne · January 4, 2020, 10:43am

Thank you. It makes things much more readable here.

Perhaps a feature was added with newer sensor firmware? Posting your xml file from the zwave folder in userdata may shed some light on the matter.

skeil · January 4, 2020, 10:50am

I found another manual: ES - DW Sensor Gen5 V1_05.pdf (190.0 KB)

See chapter 4.2 there:

At least my sensor does have that switch (maybe it is a newer version) and when pressing it also some stuff is received in OH - see excerpt from the log. “Just” I don’t get it displayed in the UI / item:
grafik

grafik

Bruce_Osborne · January 4, 2020, 10:55am

If that was an added feature you would not get it until we get your xml file from OH and update the database in the zwave binding. That is why I asked for the file.

skeil · January 4, 2020, 10:57am

Here’s the network_db48d3eb__node_5.xml (13.0 KB)

P.S.: I am really impressed by the responsiveness in this community - getting replies faster than I can provide more infos . Awesome!

sihui · January 4, 2020, 11:04am

From taking a deeper look we maybe could get this to work with an updated channel:

from

grafik

to

grafik

Stephan, once the changes got merged you need to update to a recent zwave snapshot binding.
Please report back if it works, otherwise we have to undo the changes.

Bruce_Osborne · January 4, 2020, 11:13am

Are you going to upload the newer manual too or is that not needed?

Bruce_Osborne · January 4, 2020, 11:14am

Thank you.
I do not know where you are located, but the developer of this binding is in the UK, I am in the US and sihui is in Germany. We try to work together globally.

skeil · January 4, 2020, 11:15am

Sure, I am happy to help.
Please provide/point me to instructions how to switch to (only) new zwave binding - and how to revert back [*]

[*] Background: I had some trouble with snapshots (frozen RasPi) so I prefer to stay as stable as possible. In this case maybe even live without temper alarm in favor of stability. But of course I will check whether the change works…

Bruce_Osborne · January 4, 2020, 11:21am

It is likely very simple. If we are lucky the changes will make it into the 2.5.1 stable being released this month.

skeil · January 4, 2020, 11:21am

…then you should be still sleeping - not ?

I am located in Germany (as well)

Bruce_Osborne · January 4, 2020, 11:24am

I just got up, but I should sleep in.
Actually, I am in eastern US and will go to the west coast in a little over a week for training. I really need to try and sleep later to better handle the 3 hour time zone change…

sihui · January 4, 2020, 1:04pm

Even while it has less pages, it is much more detailed for the zwave part, so yes, it’s uploaded. Thx.

sihui · January 4, 2020, 1:05pm

Older people like us don’t need as much sleep as usual anymore, right?

Bruce_Osborne · January 4, 2020, 1:35pm

Is that why we sometimes have memory loss issues?