I have 21 CT100 stats that are causing me problems because OpenHAB is not getting updated. I am manually configuring my stats with .things:
Thing zwave:rtc_ct100_00_000:controller:node2 "Node 2: CT100 - First Floor" (zwave:serial_zstick:controller) [ node_id=2, 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 ]
}
I think my issue is that this does not configure openhab controller as group 1 association. It does not take the setting in HABmin because I am using text .things, @chris is there any way around this?
I tried setting binding_poolperiod=600, and I do indeed see it being triggered every 600 sec, but nothing is updated. It just says Polling… no other DEBUG or TRACE.
The association group should be set automatically when the binding starts.
Polling on battery devices won’t do a lot unless the device wakeup period is also set to a similar value. Otherwise the request is just stored until the device wakes up at which time it should be sent.
Unfortunately that’s correct, and this is still a feature that is blocked in ESH - sorry .
So it’s listening, so any queued data should be sent immediately…
If there’s no other messages when polling, then it probably means it’s not actually generating any messages. The binding will only poll channels that are linked to an item, so maybe this isn’t working?
Yep - that’s the issue - if it was actually polling anything, then you would see another message showing the channel it’s polling.
Sorry to not give more detail. Yes, it looks to be just a display issue. If you watch the logs, the call goes through and a report comes back, if the device is mains powered. If battery powered, it should be queued.
So the problem is I am seeing huge gaps in time where I don’t get any feedback from my stats.
As you can see there were times last night when temp went up and down in steps. However, there are huge gaps like this morning where nothing changed and there was a huge jump from 44.5 to 48^.
The CT100 stat should report any temp change to openhab that is more then .5^F, yet openHAB is not getting the updates. Even more strange I am polling every 5 min so I should at least get the changs via the poll, but that does not happen.
My network looks like it has good mesh, I don’t understand why mains powered CT100s are not updating.
This is a huge problem for me because I have 21 zone HVAC system controlled by openHAB because of the lack of updates rooms are getting way to hot or way to cold.
Firstly, what do the debug logs show - are there updates coming in during this time - that would tell you if it’s a device issue or something else. By this I mean if the device is actually sending data, but the data isn’t updating, then you know it’s an issue with the device.
If the device is only sending updates periodically, then that’s an issue with the device, or the propagation between the device and the controller
If it’s time of day related, then it could be propagation or other interference type issues
If the polling isn’t working, then this could be down to the wakeup period set in the device - I would check this
When I look with your very cool log viewer tool I don’t see Polling. So if I look the last hour, I saw two channel updates for sensor_temperature, however my logs show 20 Polling requests.
They don’t show up in the log viewer, but if I look at the raw logs I see:
22-Mar-2018 12:06:51.559 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling...
22-Mar-2018 12:06:51.559 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling zwave:rtc_ct100_00_000:controller:node7:sensor_temperature
22-Mar-2018 12:06:51.559 [DEBUG] [.internal.converter.ZWaveMultiLevelSensorConverter] - NODE 7: Generating poll message for COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
22-Mar-2018 12:06:51.559 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 7: Creating new message for command SENSOR_MULTILEVEL_GET
22-Mar-2018 12:06:51.559 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Encapsulating message, endpoint 0
22-Mar-2018 12:06:51.559 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY not supported
22-Mar-2018 12:06:51.559 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Command Class COMMAND_CLASS_SENSOR_MULTILEVEL is NOT required to be secured
22-Mar-2018 12:06:51.560 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling zwave:rtc_ct100_00_000:controller:node7:battery-level
22-Mar-2018 12:06:51.560 [DEBUG] [ing.zwave.internal.converter.ZWaveBatteryConverter] - NODE 7: Generating poll message for COMMAND_CLASS_BATTERY endpoint 0
22-Mar-2018 12:06:51.560 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Encapsulating message, endpoint 0
22-Mar-2018 12:06:51.560 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY not supported
22-Mar-2018 12:06:51.560 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured
22-Mar-2018 12:06:51.560 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling zwave:rtc_ct100_00_000:controller:node7:time_offset
22-Mar-2018 12:06:51.560 [DEBUG] [nding.zwave.internal.converter.ZWaveClockConverter] - NODE 7: Generating poll message for COMMAND_CLASS_CLOCK endpoint 0
22-Mar-2018 12:06:51.560 [DEBUG] [ernal.protocol.commandclass.ZWaveClockCommandClass] - NODE 7: Creating new message for command CLOCK_GET
22-Mar-2018 12:06:51.560 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Encapsulating message, endpoint 0
22-Mar-2018 12:06:51.560 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY not supported
22-Mar-2018 12:06:51.560 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Command Class COMMAND_CLASS_CLOCK is NOT required to be secured
22-Mar-2018 12:06:51.560 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling zwave:rtc_ct100_00_000:controller:node7:sensor_relhumidity2
22-Mar-2018 12:06:51.560 [DEBUG] [.internal.converter.ZWaveMultiLevelSensorConverter] - NODE 7: Generating poll message for COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 2
22-Mar-2018 12:06:51.560 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 7: Creating new message for command SENSOR_MULTILEVEL_GET
22-Mar-2018 12:06:51.561 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Encapsulating message, endpoint 2
22-Mar-2018 12:06:51.561 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Encapsulating message, instance / endpoint 2
22-Mar-2018 12:06:51.561 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 7: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 2
22-Mar-2018 12:06:51.561 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY not supported
22-Mar-2018 12:06:51.561 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: Command Class COMMAND_CLASS_MULTI_CHANNEL is NOT required to be secured
So is the Polling request actually being sent? Also, if I look at the deltas between requests they look longer then the 200 seconds configured, I see one at 12:06:51 and then the next is 12:22:09 with another 3 in the same second.
I guess then that this must be an issue with the device. I’m not sure how it’s configured so can’t really comment on that.
Sorry - I assumed it was a battery device (most thermostats are and I didn’t check). You’re right - wakeup is only for battery devices).
How have you configured polling? You said it was set to 5 minutes?
I don’t know - I don’t really see why it wouldn’t be? You’ve presumably filters the log so it’s hard to confirm, but unless you’ve seen something I’ve missed I don’t see any errors here?
.
