How to get ZWave Siren recognised by binding

Add-ons Bindings
1

I have recently acquired a ZWave “Siren Alarm” device which - by everything in the included manual, description, and image (apart from not having the “Zipato” brand printed on it) appears to be a Zapato AB02Z siren. I suspect that - buying in the Australian market - I’ve got a device which is fully compatible but doesn’t match what the OH ZWave binding recognises as being the AB02Z. Is there a way I can tell the binding to treat it as if that’s what it is, even though it doesn’t currently recognise it? Or would I need the binding developer to add some kind of mapping in the binding itself?

The Thing, when added using the ZWave Binding, shows as an “Unknown Device” under “Thing Type”. Specifically, in the description under “Unknown Device”, the wording indicates that the device is not in the database. It adds as “... (0258:0600:1028:2.20)”. According to the wording the binding shows, that means I need to “raise an issue to get this addressed”. So… can I raise an issue?

As I say, I’m pretty certain that what we have is an identical device sold in a different region without the same branding.

If it is of use, the thing properties are as follows:

zwave_manufacturer	600
zwave_devicetype	1536
zwave_deviceid	4136
zwave_routing	true
zwave_class_basic	BASIC_TYPE_ROUTING_SLAVE
zwave_frequent	true
zwave_listening	false
zwave_version	2.20
zwave_plus_roletype	ROLE_TYPE_SLAVE_SLEEPING_LISTENING
zwave_nodeid	8
zwave_plus_devicetype	NODE_TYPE_ZWAVEPLUS_NODE
zwave_beaming	true
zwave_class_specific	SPECIFIC_TYPE_SIREN
zwave_class_generic	GENERIC_TYPE_SWITCH_BINARY
zwave_secure	false
zwave_neighbours	1,2,3,4,5

Thanks!
Robin

2

It could also be the NAS-AB01Z - but they seem to take identical commands, etc, so presumably it doesn’t matter which device the binding learns to recognise it as.

3

Here is a little background on unknown devices. For testing I created an XML that needs to be added to your existing binding using this procedure. If you have a compressed file editor that can make changes to a jar you might just be able to add the type:ID 0600:1028 to the existing entry for the NAS-AB01Z
nasab01z_0_0.xml (8.2 KB)

4

Thank you! I’ve followed that procedure to try adding the XML to the jar and incorporating it into openhab, but I’m not sure if the procedure is working or not - it still seems to think the device is unknown. However, I’ve had success by creating a .things file as follows:

Bridge zwave:serial_zstick:422141d2 "Z-Wave Serial Controller"
{
	shenzhen_nasab01z_00_000 siren_tf "Things File Siren" [ node_id=8 ]
}

That seems to force openhab to “recognise” the device, and I’ve successfully been able to link items and remotely activate the siren, so I guess I have a solution for me at least!

I’m curious to try getting the modified JAR import working though - because I’d quite like to change some parameters that currently aren’t modifiable in the NAS-AB01Z support from openHAB. I think just tweaking the XML should make that possible, but until the modify-and-import process definitely works, it’s rather difficult to know.

5

I’m actually fairly sure that using bundle:update to bring the modified JAR into openHAB through those instructions is not working - also, am I right in thinking those instructions wouldn’t survive a restart of openhab? Either way, when looking at the details of the thing that I create using the .things file, I do not see the additional type:ID that you added in the list… so either the JAR modification isn’t working, or the bundle:update isn’t working, or the .things-created Thing is ignoring the updated bundle.

EDIT: I tried disabling the .things file and letting it auto-detect after doing the rest of the process… and the auto-detected thing still isn’t recognised. So either jar modification or bundle updating is not working.

NODE 8: Device discovery could not resolve to a thingType! 0258:0600:1028::2.20
6

Since the procedure has worked for others for almost two years, there must be something in your process. Can you check for file location in the modified jar using a zip like utility? Should be in the shenzhen folder since mfg is 0x0258. Also did you delete the thing and rescan after the jar update?

Yes the updated jar will be lost with an OH upgrade. On the plus side, I see that the ZWDB was updated yesterday so the changed file is available in a OH5 snapshot now. If you are on OH5, you can update the bundle from this location as an alternate.

Edit: There is also more detailed documentation on updating bundles here

7

Ahah! I knew there must have been something I had done wrong - because I wasn’t paying attention to the fact that the branches of the directory tree needed to match before running the jar update, I had put the XML file you sent me in a directory name that didn’t match. It was using the (unmodified) version in the shenzhen folder, not the modified one mis-filed in the zipato folder. Fixed that, and it works perfectly! Including both detecting the device, and enabling the other parameters I wanted to play with. Thanks so much for your help!