Zwave dimmer not respoding


I hope someone can help me with this.
I’m trying to setup OpenHab 2.2.0 with an Aeotec Z-stick Gen5 and a few Everspring AD142 dimmers. I’m not new to OH (been using 1.x for some time now), but Z-wave is new for me.
In short:

  • USB hardware seems to be working correctly
  • pairing works (nodes are shown in OH ui and logs)
  • controlling the items just won’t work, they won’t respond.

While troubleshooting this, I came across 2 different ways to configure the item. According to the OH2 docs, you should do something like:
Dimmer Light1 {zwave="3"}
But after reading other pages and forum posts, I came across:
Dimmer Light1 {channel="zwave:device:cef0f9ef:node3"}

When I use the latter, the log shows:
[.ItemChannelLinkAddedEvent] - Link 'Light1-zwave:device:cef0f9ef:node3' has been added.
Which sounds good I guess? But I sounds odd that the docs are wrong at this point.

Anyhow, I tried both types of configurations, no luck.

The dimmers I am using are branded “Eminent” but are detected as “Everspring” so they are probably rebranded by Eminent. Should be no issue offcourse.

The dimmer has also 1 button for manual switching the output. When I press that button, the following shows up in the debug log:

[WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 49 84 03 09 03 11 01 26 27 72 86 75 73 D7 
[ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
[wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0F 00 49 84 03 09 03 11 01 26 27 72 86 75 73 D7 
[ve.internal.protocol.ZWaveController] - Process Message = 01 0F 00 49 84 03 09 03 11 01 26 27 72 86 75 73 D7 
[ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 03 09 03 11 01 26 27 72 86 75 73 
[essage.ApplicationUpdateMessageClass] - NODE 3: Application update request. Node information received.
[alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
[ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@30f4d8b6 already registered
[essage.ApplicationUpdateMessageClass] - NODE 3: Application update request. Requesting node state. 
[ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveDelayedPollEvent
[ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveDelayedPollEvent
[ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling intialised at 1800 seconds - start in 75 milliseconds.
[.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Poll, dest=3, callback=13, payload=03 01 00 
[.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 03 09 03 11 01 26 27 72 86 75 73 
[.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=13, expected=SendData, cancelled=false      MISMATCH
[ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling...

So there is some kind of communication.

My items file looks like this:

Dimmer Light1 {channel="zwave:device:cef0f9ef:node3"}

Sitemap looks like this:

sitemap default label="Main Menu" {
        Frame label="Test" {
                Slider item=Light1

For testing I’m using the openhab 2.2.0 zip file downloaded from
I also tried setting commands in the items file like SWITCH_MULTILEVEL, but nothing makes the dimmers repond.

I’ve set the zwave binding to debug level. The log shows this when changing the dimmer level:

[ome.event.ItemCommandEvent] - Item ‘Light1’ received command 50
[vent.ItemStateChangedEvent] - Light1 changed from 0 to 50

I would expect that there should be also some zwave logging, right (particulalry in debug)?

Is there something wrong with the node configuration? I sometimes read that it helps to show the node xml file, so here it is:

  <lastSent>2018-01-13 16:01:00.933 UTC</lastSent>
  <lastReceived>2018-01-13 16:01:00.970 UTC</lastReceived>

Sorry for the wall of text, but I’m just not getting why this won’t work.
Am I missing something obvious? Hopefully someone can help me out.


That is the old way of the openhab1 zwave binding to define items.

That is almost correct, but your are missing the channel definition: switch_dimmer (or something similar)

Dimmer Light1 {channel=“zwave:device:cef0f9ef:node3:switch_dimmer”}

Unfortunately the database has an error, so that device likely won’t work at the moment:

You could open a support ticket on Chris website to solve the issue …

Where did you see this? It looks more like an OH1 configuration.

I’m not sure what this means - you should just need to set the dimmer level just like any other device - there’s no need to worry about command classes…

Thanks for your replies!
I probably messed up reading the docs and thought i had the right configuration for OH2, but apparently i didn’t and was reading the OH1 docs. Sometimes it’s not easy to distinguish one from another.
Thanks for clearing that up.

According to @sihui, the right item config should be:
Dimmer Light1 {channel="zwave:device:cef0f9ef:node3:switch_dimmer"}
So that’s in my config right now. But, he also mentions that the device probably not working correctly because of an error in de config(?) for this device.
It indeed is not working yet.

What can I do to get the config for this device right?

Look in your userdata/zwave folder and find the xml file for your device (if it was generated), then upload it to the database.

In this case uploading your xml may not work either because of the overlapping versions issue:

In the mean time I’ve concluded that the device configuration is the problem. It has no commands listed, so it will not respond to any command which is send to it.

Right, I see. When I search the database for “0003:0001”, multiple devices (10 in total) show up. So that’s probably not an unique combination. What “overlapping versions” means I don’t fully understand. That seems to be the culprit? I think the other device which is referenced to is:
AD130 That one has id 23 (in the url) and my AD143 has id 25.
However, I do not understand what needs to be changed (or is conflicting) in the device xml. Or is it that the combination of Manufacturer ID and Type:ID should be unique?

Yes, it was generated. I’ve pasted the node xml in my first post of this topic.
Should I apply for an account on and submit my generated node xml? But I think some manual labor is involved to fix this device? Are there any directions so I can try to get this right?

BTW: I’ve already tried to build the zwave binding using maven (from a git clone), and that is working for me. I thought this way I could test my modifications to the node xml file before submitting a new version.
Or is there a better way to do this?

Yes. But there can be different firmware versions …


I already did that but that does not help because as expected we still have the overlapping versions.

You cannot do it that way, the xml must come from the device. Manual editing does not help.

You still should:

Uploaded to the wrong device, now I have to open a support ticket … :sunglasses:

Thanks! I will do that right away.

Oh… :grimacing:

Maybe you did, or maybe you didn’t…

The database tries to be smart - most of the time it is :wink: . What normally happens when you upload an XML (among other things) is that the database searches to see if the device id/type is already in the database, and if it is, it uses that database entry. This is designed to prevent duplication…

Here we already have duplication - this probably came from the original OH1 database since both these entries are from the original import, so they would have bypassed these checks…

So, when you uploaded this entry, you might have uploaded it to the right database, but the database will do a search, and given there is id/type duplication, it’s undefined which one it will load to… So it might not have been an error on your part :slight_smile: .


We have a duplication problem - I’m currently inclined to do something to “remove” the AD132 from the database as I can’t confirm it’s identity. The ZWave Alliance site shows no type id for the AD130! It does show the id for the AD142 and it is consistent with the info from @hugor.

So, I will change the id of the AD132 to 0000:0000 to remove the conflict. If anyone has the AD132 then please let’s discuss further so we can try and resolve this - maybe the devices really have the same ids in which case we can only have a single entry (this should not be the case, but sometimes manufacturers do this!).

Thanks for the support @chris! (and @sihui offcourse) I’ve got a reply on my ticket from chris and the issue with the AD142 should be resolved (after it has been merged in a few days).
I will post an update wheter the device works.

I already thought about never touching the database again :rofl:

Noooooooo :wink: . Your help with the database is I’m sure greatly appreciated by many people - especially me :slight_smile: .

1 Like

I can confirm the device is working now.
Since I was curious, I’ve cloned the git repo, replaced the xml with the one from the database and built the addon (I had to skip tests because for some reason some of them failed). I’ve put the resulting jar in the “addons” directory. I had to remove the nodes in habmin en re-added them. At that point there was a channel available in the node config.

One thing I do not quite understand yet: In which binding version will the updated node config be available? Will this automatically become the newest stable 2.2.0? Or do I need to use some snapshot version?