@chris @Bruce_Osborne to try and do some more debugging I quick installed Zwave JS. Figured it would be a good way to confirm that the devices aren’t the issue. They work flawlessly there.
So I suppose that means either there’s an issue with the device in the db or in the binding itself. Not really sure where to go from here though.
ZWave JS is a much newer project. These devices have been used by many users without major issue over the 5+ years of this binding. The issue is likely something unique to your environment, either configuration or device related. ZWave JS also uses a completely different database, Ours is community maintained based on actual devices used in the binding,
Are you defining your Thing in a file or automatically? File-based Things are very error-prone and discouraged. The binding has changed over the years so a file-based Thing may not work with the same definition in newer bindings.
EDIT: I just looked and ZWave JS device database just has the configuration parameters, not the Endpoint(s) from the device firmware. Perhaps posting your device xml file from userdata/zwave could provide a clue.
It’s database, not file based config. Nothing particularly interesting about the thing or item setup. And as I noted, they receive the commands without issue.
Here’s the XML:
<node>
<homeId>0xf1b35fd1</homeId>
<nodeId>15</nodeId>
<version>4</version>
<manufacturer>0x63</manufacturer>
<deviceId>0x3031</deviceId>
<deviceType>0x4944</deviceType>
<listening>true</listening>
<frequentlyListening>false</frequentlyListening>
<routing>true</routing>
<security>false</security>
<beaming>true</beaming>
<maxBaudRate>40000</maxBaudRate>
<sleepDelay>1000</sleepDelay>
<nodeInformationFrame>
<commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
<commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
<commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
<commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
<commandClass>COMMAND_CLASS_VERSION</commandClass>
<commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
<commandClass>COMMAND_CLASS_NODE_NAMING</commandClass>
</nodeInformationFrame>
<associationGroups class="concurrent-hash-map"/>
<endpoints class="concurrent-hash-map">
<entry>
<int>0</int>
<endPoint>
<deviceClass>
<basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
<genericDeviceClass>GENERIC_TYPE_SWITCH_MULTILEVEL</genericDeviceClass>
<specificDeviceClass>SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL</specificDeviceClass>
</deviceClass>
<endpointId>0</endpointId>
<secureCommandClasses/>
<supportedCommandClasses class="concurrent-hash-map">
<entry>
<commandClass>COMMAND_CLASS_NODE_NAMING</commandClass>
<COMMAND__CLASS__NODE__NAMING>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<name></name>
<location></location>
</COMMAND__CLASS__NODE__NAMING>
</entry>
<entry>
<commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
<COMMAND__CLASS__POWERLEVEL>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<powerLevel>0</powerLevel>
<powerTimeout>0</powerTimeout>
</COMMAND__CLASS__POWERLEVEL>
</entry>
<entry>
<commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
<COMMAND__CLASS__CONFIGURATION>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<configParameters>
<entry>
<int>3</int>
<configurationParameter>
<index>3</index>
<size>1</size>
<value>0</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>4</int>
<configurationParameter>
<index>4</index>
<size>1</size>
<value>0</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>5</int>
<configurationParameter>
<index>5</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>7</int>
<configurationParameter>
<index>7</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>8</int>
<configurationParameter>
<index>8</index>
<size>1</size>
<value>3</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>9</int>
<configurationParameter>
<index>9</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>10</int>
<configurationParameter>
<index>10</index>
<size>1</size>
<value>3</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>11</int>
<configurationParameter>
<index>11</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>12</int>
<configurationParameter>
<index>12</index>
<size>1</size>
<value>3</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
</configParameters>
</COMMAND__CLASS__CONFIGURATION>
</entry>
<entry>
<commandClass>COMMAND_CLASS_BARRIER_OPERATOR</commandClass>
<COMMAND__CLASS__BARRIER__OPERATOR>
<version>0</version>
<instances>0</instances>
<control>false</control>
<versionSupported>0</versionSupported>
</COMMAND__CLASS__BARRIER__OPERATOR>
</entry>
<entry>
<commandClass>COMMAND_CLASS_BASIC</commandClass>
<COMMAND__CLASS__BASIC>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__BASIC>
</entry>
<entry>
<commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
<COMMAND__CLASS__MANUFACTURER__SPECIFIC>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<initSerialNumber>false</initSerialNumber>
<deviceManufacturer>99</deviceManufacturer>
<deviceType>18756</deviceType>
<deviceId>12337</deviceId>
</COMMAND__CLASS__MANUFACTURER__SPECIFIC>
</entry>
<entry>
<commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
<COMMAND__CLASS__NO__OPERATION>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
</COMMAND__CLASS__NO__OPERATION>
</entry>
<entry>
<commandClass>COMMAND_CLASS_VERSION</commandClass>
<COMMAND__CLASS__VERSION>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<libraryType>LIB_SLAVE_ROUTING</libraryType>
<protocolVersion>3.67</protocolVersion>
<applicationVersion>3.37</applicationVersion>
</COMMAND__CLASS__VERSION>
</entry>
<entry>
<commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
<COMMAND__CLASS__SWITCH__ALL>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
<mode>SWITCH_ALL_INCLUDE_ON_OFF</mode>
</COMMAND__CLASS__SWITCH__ALL>
</entry>
<entry>
<commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
<multiLevelSwitchCommandClass>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
</multiLevelSwitchCommandClass>
</entry>
</supportedCommandClasses>
</endPoint>
</entry>
</endpoints>
<nodeNeighbors>
<int>1</int>
<int>2</int>
<int>3</int>
<int>4</int>
<int>5</int>
<int>9</int>
<int>10</int>
<int>11</int>
<int>12</int>
<int>13</int>
<int>14</int>
<int>16</int>
<int>17</int>
<int>18</int>
<int>19</int>
<int>20</int>
<int>21</int>
<int>23</int>
<int>24</int>
<int>25</int>
<int>26</int>
<int>28</int>
<int>29</int>
<int>30</int>
<int>32</int>
<int>34</int>
<int>39</int>
<int>41</int>
<int>44</int>
<int>52</int>
</nodeNeighbors>
<lastReceived>2021-03-19 01:45:36.54 UTC</lastReceived>
</node>
There appear to be no supported association groups. That XML field is empty.
<associationGroups class="concurrent-hash-map"/>
Correct. @chris already pointed that out earlier: OH3 + GE 12794 Zwave Dimmer problems - #7 by chris
And again, I should note, these previously worked flawlessly. As Chris said, they send a command and then you poll them. But as of right now, even if I send a REFRESH command they aren’t updating.
Sorry - I’m not really sure. There’s very little here to understand what’s happening. The log doesn’t show any reports, so clearly if it’s not receiving anything, then the binding will not do anything.
@chris this is definitely the most frustrated I’ve been with OH in the many years I’ve used it. I setup an OH2 instance on the old Pi I used to run it on. Plugged in the USB stick, allowed all of noise on the Zwave network die down, added the thing/ & item for one of the GE dimmers, and it worked fine. Here’s the log:
2021-03-22 21:32:56.877 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update request. Node information received. Transaction null
2021-03-22 21:32:56.880 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: resetResendCount initComplete=true isDead=false
2021-03-22 21:32:56.882 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update request. Requesting node state.
2021-03-22 21:32:56.885 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveDelayedPollEvent
2021-03-22 21:32:56.888 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling initialised at 1800 seconds - start in 175 milliseconds.
2021-03-22 21:32:56.890 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update - no transaction.
2021-03-22 21:32:57.066 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling...
2021-03-22 21:32:57.070 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling zwave:device:168118d907c:node15:switch_dimmer
2021-03-22 21:32:57.074 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 15: Generating poll message for COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2021-03-22 21:32:57.077 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 15: Creating new message for command SWITCH_MULTILEVEL_GET
2021-03-22 21:32:57.079 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: SECURITY not supported
2021-03-22 21:32:57.082 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2021-03-22 21:32:57.085 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling skipped for zwave:device:168118d907c:node15:switch_dimmer on COMMAND_CLASS_BASIC
2021-03-22 21:32:57.088 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Adding to device queue
2021-03-22 21:32:57.091 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Added 897 to queue - size 4
2021-03-22 21:32:57.101 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 15: Sending REQUEST Message = 01 09 00 13 0F 02 26 02 25 36 DF
2021-03-22 21:32:57.152 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 15: sentData successfully placed on stack.
2021-03-22 21:32:57.158 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: TID 897: Transaction not completed
2021-03-22 21:32:57.186 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 15: SendData Request. CallBack ID = 54, Status = Transmission complete and ACK received(0)
2021-03-22 21:32:57.189 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: resetResendCount initComplete=true isDead=false
2021-03-22 21:32:57.194 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: TID 897: Transaction not completed
2021-03-22 21:32:57.202 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Application Command Request (ALIVE:DONE)
2021-03-22 21:32:57.204 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: resetResendCount initComplete=true isDead=false
2021-03-22 21:32:57.207 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2021-03-22 21:32:57.209 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: SECURITY not supported
2021-03-22 21:32:57.212 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Received COMMAND_CLASS_SWITCH_MULTILEVEL V1 SWITCH_MULTILEVEL_REPORT
2021-03-22 21:32:57.214 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 15: Switch Multi Level report, value = 68
2021-03-22 21:32:57.216 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2021-03-22 21:32:57.218 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_MULTILEVEL, value=68
2021-03-22 21:32:57.221 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:168118d907c:node15:switch_dimmer to 68 [PercentType]
2021-03-22 21:32:57.225 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Commands processed 1.
2021-03-22 21:32:57.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@4846e6.
2021-03-22 21:32:57.230 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@4846e6.
2021-03-22 21:32:57.233 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: notifyTransactionResponse TID:897 DONE
2021-03-22 21:32:57.236 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
So I plugged it back into my OH3 instance, and it doesn’t work. Same log as I sent before:
2021-03-22 21:39:39.608 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update request. Node information received. Transaction null
2021-03-22 21:39:39.608 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: resetResendCount initComplete=true isDead=false
2021-03-22 21:39:39.609 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update request. Requesting node state.
2021-03-22 21:39:39.610 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveDelayedPollEvent
2021-03-22 21:39:39.611 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling initialised at 1800 seconds - start in 175 milliseconds.
2021-03-22 21:39:39.611 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update - no transaction.
2021-03-22 21:39:39.786 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling...
So obviously something is different between OH2 and OH3. Considering I got it up and running on Zwave JS without any issues, I’m going to guess OH3 (as in the OH3 version of the binding) is the bad apple here. Unless the database is different between OH2 and OH3. But I’m assuming that’s not the case.
If there’s anything more I can do to debug I’m happy to do it…but I’m really hoping to avoid having to spin up a Java dev environment here and throw a bunch of debugging into the binding to get more info.
@chris I have good news!
I was looking through the binding code, specifically the polling code. I noticed in my two sets of logs that the difference was that in OH2, it polled for that channel…in OH3, it just started the “Polling…” process and then did nothing. In the code I noticed that polling had a heavy requirement on the channel linking. I was staring at my OH3 channel item, and the link was there, but I paid some more attention to the “Profile” section, which is new in OH3 and I’ve never used before. Saw this:
and thought: “what’s the difference between (No Profile) and Default?” So I switched it to Default, and voila!I’m guessing that’s because all of my links/items were created from a OH2 upgrade, and that doesn’t set it as Default. I imagine none of my Zwave items are polling properly because of this, but it’s only the GE ones that require polling to work.
@feens - Glad to see you managed to get this sorted! I wanted to chime in and say I have a bunch of (mix of ~30 different GE/Honeywell/Jasco models) in-wall Z-Wave devices and they all work perfectly fine using ‘No Profile’ on the latest stable OH 3.x branch. Their statuses when changed directly at the switch or otherwise via the App stay in sync as expected. This is on a clean install of OH3 - didn’t upgrade; rather just rebuilt from scratch.
I am still pecking away at this other issue below effecting only the Scene_Number channel for only one older device… And in my case switching the Profile didn’t help either - simply nothing gets captured or logged (in DEBUG mode) when attempting to change scenes. And this particular model does support Association Groups in case anyone here was wondering - this one is setup for the Associate Group #1 being the Controller:)
@d0t the newer GE devices don’t require polling, so if you have anything other than the really old ones, you wouldn’t need to worry. The ones I have are older than the scene support as well, so I can’t really comment there. I gave up on GE after these ones started failing badly (about 50% of them).
It’s also possible that changing the profile wasn’t the direct fix, but the side-effect of it causing an item to unlink and relink.
@feens - all point taken there - I’ve started to question if I made a bad decision with buying many of these devices on clearance earlier this year 
So far so good, but time will tell what the failure rate is.
Thanks; best of luck with the others!
@chris or @Bruce_Osborne i am curious, is the profile required to be set, or is it just that maybe the links on the items didn’t register? I feel like somewhere there’s definitely an underlying bug, maybe in the OH2 → OH3 migration script/flow
What version are you using? There was a change introduced in OH3 to not send the binding linking information during startup. This required a change to bindings - it was requested a couple of days before OH3 was released and was not done in a number of bindings (including the ZWave). If you are using OH3.0 release, then it will have this issue still.
I believe it was fixed before 3.0.1 so it should be fine.
I always leave the profile at its default setting. “If it ain’t broke, don’t fix it”. 
Default as in default or default as in “no profile” though.
I’m still curious if it was the profile that was the issue or an item linking issue.
I have not worked with OH3 in a while. I do not change whatever profile is automatically set by the system. That is the plain English definition of default.
Yes, but there is a choice for users in the menu offered - where none and default are two different things.
It might be interesting to compare the link JSONDB for each selection and see what’s what.
