Add Z-Wave device to database

Hi,

I have just joined the community and am quite new to z-wave and OpenHAB.
I am running OpenHabian on a rpi4, and have installed the Z-wave binding and successfully added several z-wave nodes. My system version is openHAB 2.5.0-1 (Release Build)

I now have a battery-powered Z-wave wall-switch that seems is not found in the z-wave database.
From PaperUI I see it added as
‘Z-Wave Node 016 (0330:0300:A310:1.28)’ with ‘Unknown device’ below.

I live in Norway and the purchased the device as ’ Namron Z-wave 2 channel Switch’ but as the Namron is a store-brand, I’ve learnt that this is in fact the same device as Sunricher SR-ZV9001K4-Dim device

https://www.sunricher.com/single-color-wall-mounted-push-button-z-wave-secondary-controller-dimmer-switch-sr-zv9001k4-dim.html

I have googled some, and came across the CD-Jackson Z-wave database. I see one item that looks similar:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1191
But reading the documentation and by the picture it doesn’t seem to be exactly the same.

I’ve also tried to read the guide, but as I am a beginner I don’t want to do anything wrong,so I thought I’d ask before I started to add devices to the database.

I have the xml file and product manual, but it seems as a new user I am not permitted to upload any files.

Rgds
Kristian

Welcome!

That is indeed the device. The database entry was last updated a month ago so it may not be in the 2.5.0 version of the binding. I recommend first updating to 2.5.4 which basically just has later binding versions. Then delete the Thing from openhab (do NOT exclude) and then rediscover and add to openhab. That will get the new binding settings for the device.

1 Like

Hi Bruce,
Thank you so much for your swift reply!

I did what you proposed, and yes - it was now identified as the Sunricher device!

But I fear it is not the exact same device. I might be completely mistaken, but from the z-wave device database, it seems the device is for both the product ID 0300:A306 and 0300:A310. However, I believe the attributes, parameters, groups etc added to the database is for the id 0300:A306. My particular product has the ID 0300:A310; and based on documentation it should for instance have only two groups. The one I currently have in my openHAB system and the one in the database definition has three groups.

I wouldn’t mind; but from the log I see that the buttons doesn’t have the expected action. Instead of being a swith (on/off) and a dimmer (0-100 percent) it is appearing with the _scene_number channel.

attached is the xml file i downloaded before updating to version 2.5.4. Is there someway this can be used to see if in fact there should be two entries in the database? One for the current 0300:A306 and one for 0300:A310 f(my device)?

Sunricher SR-ZV9001K4-DIM Manual.pdf (90.6 KB) Sunricher SR-ZV9001K4-DIM.XML (9.7 KB)

I have attached the xml-file, manual and pictures of the device I belive is 0300:A310.

And like I oopened with - I am completely new to openHAB and z-wave so apologies in advance if I have completely misunderstood! :slight_smile:

Many times the differences in device ids are due to radios for different Z-Wave regions.
You have not misunderstood. It may take more research or experimentation.

If I were you I would try our current entry first, unless out developer, @chris disagrees.

I was new to openHAB a year ago. I am now assisting our very dedicates Z-Wave & Zigbee developer.

Thanks again for the fast response @Bruce_Osborne :wink:

I have included/added the device to my system; and from the log I can see that the following actions fro the various buttons:

‘1’ (top left on the image) -> “zwave_device_c12e6389_node16_scene_number changed from 3.0 to 1.0”
‘0’ (top right) -> “zwave_device_c12e6389_node16_scene_number changed from 1.0 to 2.0”
big sun (bottom left) -> “zwave_device_c12e6389_node16_scene_number changed from 2.0 to 3.0”
small sun (bottom right) -> “zwave_device_c12e6389_node16_scene_number changed from 3.0 to 4.0”

I would expected the two buttons on top to trigger the switch_binary channel, and the two lower buttons to trigger the switch_dimmer channel.

Currently it seems all four buttons trigger the scene_number channel.

@chris, is there anyway to compare the database entry for item# 1191 with the xml file I attached in the earlier post?

1 Like

Chris is in the UK and I am in the US. I am just starting work and he may still be at work.

Thank you for your patience.

No problem at all - I am already impressed by the response :wink:

1 Like

No - it’s not really possible to compare them. Do you think it’s different, or is there something you’re missing?

I have compared the manual attached to the database; this list that the device supports three association groups. The manual that came along with my device says it only support two association groups. Both the A306 and the A310 device seems to be communicating on the 868.42 Mhz frequenzy.

I’m not too concerned with the association groups (I am going to use it to control an IKEA Tradfri device, so it will have to handled by openHAB). But the issue is that I can’t figure out how to get the buttons to trigger what I believe are the correct channles (binary_switch and dimmer_switch). All four buttons are only triggering the scene_number channel.

I’ve not looked at the details of this device, but I assume it is a ZW+ device and therefore the binding should automatically set the lifeline no matter what the database says. I guess if this is triggering the scene channel, then the association is set, and it is likely a configuration issue with the device.

Yes, It should be a Z-wave Plus devices (stamped at the back of the physical product).
You are correct; the lifeline association, Group 1, was automatically set to ‘Controller’.

The other two association groups (Group 2 and 3) are not set (search showing in PaperUI asscoiation configuration).

I discovered that the local store actually sells the device with id a306. I have ordered this, and will add to my system, and test if behaviour is as expected, ie the buttons triggering the switch and dimmer channels.
I guess if that turs out true, it might be that the devices with id 0300:a306 and 0300:a310 are different devices, and a new entry to database should be made for the 0300:a310 device :thinking:

Thanks for all your advise and assistance so far, I really appreciate it :pray:

So, I got the other one; the one with id 0300:a306, and it is behaving the exact same way; none of the four buttons are triggering anything other than the scene channel.

This second device should actually be able to handle on/off switch and dimmer for two devices, so something is not working as intended here. In PaperUi/Habmin, there seems to be no configuration parameters, so I’m somewhat lost as to what should be the next step.

From the Z-wave database guide, I se there are section on updating endpoints. Any chance there might be something there that are not setup correctly?

From my quick read of the manual you need to use association group 2.

So I tried to set the association of group 2 to controller . That made some impact;the button for on/off are now triggering the binary_switch channel in addtion to the scene channel. However still nothing on the dimmer.

I went into the console and enable debug logging for zwave binding. Holding down the dimmer increase button; I see the following in the log:

2020-05-03 09:09:02.294 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)

2020-05-03 09:09:02.296 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false

2020-05-03 09:09:02.297 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0

2020-05-03 09:09:02.298 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported

2020-05-03 09:09:02.299 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_SWITCH_MULTILEVEL V0 SWITCH_MULTILEVEL_START_LEVEL_CHANGE

2020-05-03 09:09:02.300 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 18: Switch Multi Level start level change, direction = INCREASE

2020-05-03 09:09:02.301 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveStartStopEvent

2020-05-03 09:09:02.303 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_MULTILEVEL, value=INCREASE

2020-05-03 09:09:02.304 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 18: ZWaveMultiLevelSwitchConverter.handleEvent() <<switch_dimmer>>

2020-05-03 09:09:02.305 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.

2020-05-03 09:09:02.306 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@11b0b04.

2020-05-03 09:09:02.341 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)

2020-05-03 09:09:02.342 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false

2020-05-03 09:09:02.344 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_CENTRAL_SCENE, endpoint 0

2020-05-03 09:09:02.345 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported

2020-05-03 09:09:02.346 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_CENTRAL_SCENE V3 CENTRAL_SCENE_NOTIFICATION

2020-05-03 09:09:02.347 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 18: Received scene 3 at key 2 [Key Held Down]

2020-05-03 09:09:02.349 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveCommandClassValueEvent

2020-05-03 09:09:02.350 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CENTRAL_SCENE, value=3.2

2020-05-03 09:09:02.351 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Updating channel state zwave:device:c12e6389:node18:scene_number to 3.2 [DecimalType]

2020-05-03 09:09:02.354 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.

2020-05-03 09:09:02.355 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@152ac7e.

2020-05-03 09:09:03.431 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)

2020-05-03 09:09:03.432 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false

2020-05-03 09:09:03.434 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_CENTRAL_SCENE, endpoint 0

2020-05-03 09:09:03.435 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported

2020-05-03 09:09:03.436 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_CENTRAL_SCENE V3 CENTRAL_SCENE_NOTIFICATION

2020-05-03 09:09:03.438 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 18: Received scene 3 at key 1 [Key Released]

2020-05-03 09:09:03.439 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveCommandClassValueEvent

2020-05-03 09:09:03.440 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CENTRAL_SCENE, value=3.1

2020-05-03 09:09:03.442 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Updating channel state zwave:device:c12e6389:node18:scene_number to 3.1 [DecimalType]

2020-05-03 09:09:03.445 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.

2020-05-03 09:09:03.446 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1577fa.

2020-05-03 09:09:03.478 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)

2020-05-03 09:09:03.480 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false

2020-05-03 09:09:03.481 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0

2020-05-03 09:09:03.482 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported

2020-05-03 09:09:03.483 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_SWITCH_MULTILEVEL V0 SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE

2020-05-03 09:09:03.485 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 18: Switch Multi Level stop level change

2020-05-03 09:09:03.486 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveStartStopEvent

2020-05-03 09:09:03.487 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_MULTILEVEL, value=STOP

2020-05-03 09:09:03.489 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 18: ZWaveMultiLevelSwitchConverter.handleEvent() <<switch_dimmer>>

2020-05-03 09:09:03.490 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.

2020-05-03 09:09:03.491 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@14a35c4.

Again, I am total newbie to z-wave, but imho it looks like the device is sending events/commands on the command class COMMAND_CLASS_SWITCH_MULTILEVEL, but this is not mapped to the OH2 switch_dimmer channel?

The device is using the INCREASE / DECREASE commands rather than sending level commands and the binding is not supporting these.

1 Like

Ah, OK, thanks for clarifying this. Is there any may for me to make workaround for this - using a rule or something? Or is this device simply not compatible with OH, except being a basic on/off switch and a scene selector?

Just out of curiosity, is there anyway for me to check how a particular product is sending commands before purchasing?

It would require a binding update to add support for these commands. They are very seldom used so this hasn’t been required in the 1000+ devices so far.

I would simply suggest to use the scene commands.

Not really. This is one of the “problems” with ZWave - there are often many different ways to do the same thing. Normally you can find out what command classes are supported, but each command class will often have different command sets - which is what we see here. Sometimes a manufacturer will publish more detailed information.

Your best bet is to just use the SCENE commands, but I know you weren’t keen to do that. However, even if I added support for these commands, all you would get is an INCREASE or DECREASE command - you’d then need to use a rule to do something with this. So, does it matter if you have an INCREASE command, or a SCENE-X command? It is fundamentally the same - you are being alerted when the user presses the button and you need to do something with this information.

I see your point - I must admit that to begin with I did not have the DUBUG log enabled for z-wave binding. Hence I did only see the vent.ItemStateChangedEvent events in the log. Which of course only happened when a scene was changed. So I became fixated on the idea that the scene channel was not possible to use for dimming, as I only saw when it changed - ie I could only dim one step brighter and then one step dimmer again… :flushed:

But now I see that the scene command is triggered at every button push (even though it is not changed) - and I absolutely see that a rule should do what I am after. A good opportunity for me to create my first rule! :slightly_smiling_face:

I am sorry for wasting your time, thank you so much for your patience with me!

2 Likes

Let me add my thanks to @chris for his patience with all of us here.

In my opinion, he is one of our busiest, most valued developers.

4 Likes