OH2 Z-Wave refactoring and testing... and SECURITY

I’m running 2.3.0.201806041552 as well with 2 FGD-212’s and I haven’t had any problems. Just pushed one of my momentary switches to confirm…

FGD212

Thanks for this. I switched back to the 2.3.0.201806041552 binding again and its working now. Very strange because I restarted Openhab multiple times before deciding to revert the binding. Everything was working except Scene numbers (and yes, parameter had been set on the devices).

I’m guessing some sort of co-incidence, but for clarity it was a clean install + inclusions using 2.3.0.201806041552, so I guess it could be that going via the earlier binding it works? Was yours an upgrade to 2.3.0.201806041552 as well?

I’ve been flipping versions a lot lately trying to chase down an issue with Nodon Soft Remotes, but if I recall correctly, the first time I did it, it was a normal upgrade. I haven’t been touching anything related to those devices when crossing between Dev/Test bindings or different build dates and they’ve worked consistently. They’re actually some of the best performing devices I have.

I just had a look on GH and there have been no changes to the converters for scene classes for at least 3 months. There was a change to some polling activities but I don’t think that is linked to this as these should be sent directly by the device when you press the button.

Please provide a debug log so we can see what is happening.

Scene numbers still working fine on my system (but I am on the second edition of the test development zwave binding).

Still having issues with polling. Sometimes when I start the binding it will Poll my devices, but most of the time I just get a Polling… message and then nothing. : (

zwave.log:19-Jun-2018 15:14:00.154 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Got an event from Z-Wave network: ZWaveInitializationStateEvent
zwave.log:19-Jun-2018 15:14:00.162 [DEBUG] [ternal.protocol.initialization.ZWaveNodeSerializer] - NODE 105: Serializing to file /var/lib/openhab2/zwave/network_de57ebfe__node_105.xml
zwave.log:19-Jun-2018 15:14:00.166 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 105: Node advancer - advancing to DONE
zwave.log:19-Jun-2018 15:14:00.166 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Got an event from Z-Wave network: ZWaveInitializationStateEvent
zwave.log:19-Jun-2018 15:14:00.166 [DEBUG] [ternal.protocol.initialization.ZWaveNodeSerializer] - NODE 105: Serializing to file /var/lib/openhab2/zwave/network_de57ebfe__node_105.xml
zwave.log:19-Jun-2018 15:18:12.716 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Polling...
zwave.log:19-Jun-2018 15:28:12.716 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Polling...
zwave.log:19-Jun-2018 15:38:12.716 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Polling...
zwave.log:19-Jun-2018 15:48:12.716 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Polling...
zwave.log:19-Jun-2018 15:58:12.716 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Polling...
zwave.log:19-Jun-2018 16:08:12.716 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Polling...

This looks ok and means that there are no channels linked at this time. There’s no exception or any problem I can see. The binding only polls channels that have been linked to reduce traffic.

Odd, HABmin shows channels linked. And I get a reading from it when the binding starts up:

zwave.log:19-Jun-2018 15:14:04.224 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 109: Initialising cmd channel zwave:rtc_ct100plus_00_000:controller:node109:sensor_temperature2 for DecimalType
zwave.log:19-Jun-2018 15:14:04.224 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 109: Initialising state channel zwave:rtc_ct100plus_00_000:controller:node109:sensor_temperature2 for DecimalType
zwave.log:19-Jun-2018 15:14:04.224 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 109: Initialising state channel zwave:rtc_ct100plus_00_000:controller:node109:sensor_temperature2 for DecimalType
zwave.log:19-Jun-2018 15:14:42.670 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 109: Updating channel state zwave:rtc_ct100plus_00_000:controller:node109:sensor_temperature2 to 67.5 �F [QuantityType]

I just never see any Polling updates. Right now the only way to make my HVAC system work is to restart openHAB every 15 min. Since openHAB pulls the temp when it first configures the device, but then never again.

Do you see a log entry Channel XX linked - polling started? This is logged when the binding is alerted that the channel is linked.

No unfortunately I don’t. However other then polling, everything works.

Have you tested deleting the Thing?

The polling is the only thing that relies on the linked calls. I’m not sure why they would be called - I would guess that it’s a framework issue, but I guess only for your system (strangely!) since I think polling is generally working for others.

They are manually defined.

Thing zwave:rtc_ct100plus_00_000:controller:node102 "Node 102: CT100 - Joshua's Bedroom" (zwave:serial_zstick:controller) [ node_id=102, binding_pollperiod=600 ] {
  Channels:
    Type sensor_temperature : sensor_temperature [ config_scale=1 ]
    Type thermostat_setpoint : thermostat_setpoint_cooling [ config_scale=1 ]
    Type thermostat_setpoint : thermostat_setpoint_heating [ config_scale=1 ]
}

Open to ideas on how I can dig deeper.

Sorry - I don’t really have any idea. The framework is meant to call the binding when the channel is linked to an item - it seems that’s not happening, but I don’t know why that would be.

OK, this sounds familiar… I think we’ve been here before. :smile:

What if you move the file and then put it back? I would think that would delete the Thing and then add it again.

I also just noticed your using config_scale, but this should not be needed after the UoM additions. But you may need to reconfigure your items.

1 Like

You rock my world!!! I have tried this a few times and it works! To fix polling I just move my zwave.things fine and then put it back.

19-Jun-2018 17:53:27.455 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:sensor_temperature linked - polling started.
19-Jun-2018 17:53:27.455 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:thermostat_mode linked - polling started.
19-Jun-2018 17:53:27.455 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:thermostat_state linked - polling started.
19-Jun-2018 17:53:27.455 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:thermostat_setpoint_heating linked - polling started.
19-Jun-2018 17:53:27.456 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:thermostat_setpoint_cooling linked - polling started.
19-Jun-2018 17:53:27.456 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:battery-level linked - polling started.
19-Jun-2018 17:53:27.456 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:time_offset linked - polling started.
19-Jun-2018 17:53:27.457 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 105: Channel zwave:rtc_ct100plus_00_000:controller:node105:sensor_relhumidity2 linked - polling started.
1 Like

I’ve had a suspicion that something was going on in ESH that made devices behave oddly after a binding update. Maybe more often than that. Deleting my Things would fix it. For me, it was related to scene_number. Resolving @sipvoip’s issue reinforces this for me a bit, but I really don’t have anything solid to open a bug with. Looking forward to when the Thing definitions refresh themselves!

I’ve actually had the same exact symptoms as @sipvoip regarding polling. I would have posted something earlier, but I just haven’t had the time to debug so I just reverted to a previous snapshot of my system. I now have 2.3.0.201804022210 of the binding installed. When I tried the updated binding, I did see the polling started log entry. The one difference from Nathan on my system is that my things are not manually defined.

Just one more thing to add…I also recently tried updating to the latest daily build of openhab while keeping the same old 2.3.0.201804022210 version of the z-wave binding. I had polling issues with this setup as well, but I did even less investigating this time and did not look at the log at all. Sorry for the lack of information, but this at least further points to a framework issue instead of binding issue. My wife has gotten accustomed to using Openhab (especially with google home support) so I can’t leave my setup broken for too long.