OH3 + GE 12794 Zwave Dimmer problems

I noticed after updating to OpenHAB 3 that my older GE zwave dimmers weren’t working quite as I expected (they didn’t seem to be updating the status that I send to HomeKit). I had time to take a closer look, and as it turns out, it looks like they literally don’t work at all with OH3.

The behaviour: if I turn on/off a switch (dimmer), it doesn’t update in OH. If I send a refresh command to them via the console, they still don’t update. I can see in the logs that they receive a NIF command when they’re toggled at the device, and I can see that it says it’s polling them.

@chris I’m curious if there were any changes in the binding that would cause this behaviour. I’d suspect it was one of the devices because frankly they have kind of ended up sucking (and I’m slowly replacing them), but it seems unlikely that all of them would just cease to function.

They do receive commands without issue (i.e. I can control them over zwave)

Throwing my TRACE levels logs in here in case that helps.

2021-03-14 22:54:49.613 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2021-03-14 22:54:49.615 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 49 84 0F 0A 04 11 01 26 27 73 70 86 72 77 B2
2021-03-14 22:54:49.616 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 10 00 49 84 0F 0A 04 11 01 26 27 73 70 86 72 77 B2
2021-03-14 22:54:49.617 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = -78
2021-03-14 22:54:49.617 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2021-03-14 22:54:49.618 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 15: Message payload = 84 0F 0A 04 11 01 26 27 73 70 86 72 77
2021-03-14 22:54:49.619 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2021-03-14 22:54:49.621 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2021-03-14 22:54:49.621 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationUpdate[73], type=Request[0], dest=15, callback=132, payload=84 0F 0A 04 11 01 26 27 73 70 86 72 77
2021-03-14 22:54:49.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationUpdate[73], type=Request[0], dest=15, callback=132, payload=84 0F 0A 04 11 01 26 27 73 70 86 72 77
2021-03-14 22:54:49.623 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-03-14 22:54:49.624 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
2021-03-14 22:54:49.625 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: null
2021-03-14 22:54:49.626 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=15, callback=132, payload=84 0F 0A 04 11 01 26 27 73 70 86 72 77
2021-03-14 22:54:49.626 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
2021-03-14 22:54:49.627 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update request. Node information received. Transaction null
2021-03-14 22:54:49.628 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: resetResendCount initComplete=true isDead=false
2021-03-14 22:54:49.629 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update request. Requesting node state.
2021-03-14 22:54:49.630 [TRACE] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveDelayedPollEvent
2021-03-14 22:54:49.630 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveDelayedPollEvent
2021-03-14 22:54:49.632 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling initialised at 1800 seconds - start in 175 milliseconds.
2021-03-14 22:54:49.632 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update - no transaction.
2021-03-14 22:54:49.634 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-03-14 22:54:49.634 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2021-03-14 22:54:49.635 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 37: listening == false, frequentlyListening == false, awake == false
2021-03-14 22:54:49.636 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 37: Node not awake!
2021-03-14 22:54:49.637 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 32: listening == false, frequentlyListening == false, awake == false
2021-03-14 22:54:49.637 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 32: Node not awake!
2021-03-14 22:54:49.638 [TRACE] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2021-03-14 22:54:49.807 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Polling...
2021-03-14 22:54:49.884 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Node is listening - ignore wakeup

There were no changes in OH3 - or very few, but since I have no idea what you were using previously I can’t really say what changes there were between your version.

There may have been database changes for the devices 12794 does not show up in a database search.

Why include TRACE logs when the binding documentation explicitly says to use DEBUG?

The device database is now here.

Coming from OH 2.5 (whatever the last version was before OH 3 was released).

My bad. I don’t normally use TRACE but wasn’t seeing anything that popped out in DEBUG and thought maybe it’d show something else.

Looks like my title had a typo…it’s the 12724, db entry here: OpenSmartHouse Z-Wave Device Database

I may try and setup a 2.5 instance to do more testing, but it is really weird that they just stopped. IS there any way to get more info on what’s being sent to the controller?

That database entry has not been updated since OH 2.5.0. I notice no Association Groups in the database. That may not be unusual for some old Z-Wave devices. @chris would know better.

Perhaps the log viewer can help you interpret the DEBUG logs.

The device doesn’t seem to support associations. Many of these older devices didn’t support them so there was no direct reporting. The other way reporting was done was to use the HAIL class where a HAIL command gets sent to the binding, and then the binding has to poll - this got around patent issues at the time. It doesn’t see this device supports that though either - or it may be that the database is wrong - I don’t know.

2 Likes

Device 43 is definitely an old one.

Old indeed. When I got these OpenHAB was in beta for 2.0. They were well regarded at the time and actually worked really well, though durability has been a big issue.

Up until these issues, they’ve generally worked almost like they have instant status.

What really confounds me is why they don’t even update the status after sending the refresh command.

@Bruce_Osborne @chris I looked at the log viewer tonight, but it’s pretty sparse (including a screen shot). Is there any way to get deeper logging to figure out what may be going on with the binding? Unfortunately I don’t have a Zniffer or extra Zwave controller to create one so that’s not an option, and I’m purely running macOS so I can’t easy use the Silabs PC Controller software.

I tried with 5 different switches of that model and the behaviour/logs looks to be the same.

@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.

@Bruce_Osborne @chris any other guidance? I think I’ve provided all the info I can at this point.

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:)