Hi,
I have a Wave network with the Aeotec Wave Gen5 Z-Wage stick and 25 Fibaro 212 dimmers. I recently updated the Openhab to openhanded 2.2 and installed the zwave binding 2.2.0 and then all the lights stopped posting updates when I turned on the lights. It would eventually populate the state after about 20±10mins mins but as you would imagine this is not useful as I would want the state changes to be instantly reflected on the openhab interface. The current device polling period seems to be 30 mins on habmin.
Upon doing further investigation I thought it would be better to install the latest wave binding which is 2.3.0 so I uninstalled it and downloaded and installed the latest binding. This has not fixed the issue.
I also checked and confirmed that there are no association groups except the lifeline which is associated with the openhab controller for all nodes. I left if for a few days and that does not seem to have settled down. I tried using refresh interval and does not seem to help. Also wondering what the right syntax is for the refresh interval. I tried the 2 below
Switch MBed1 “MasterBed Reading” (FiF_MBed) { channel=“zwave:device:b07e5746:node27:switch_dimmer, refresh_interval=3” }
Dimmer MBed1_dim “MasterBed Reading [%d %%]” (FiF_MBed, fDimm) { channel=“zwave:device:b07e5746:node27:switch_dimmer, refresh_interval=3” }
Switch MBed1 “MasterBed Reading” (FiF_MBed) { channel=“zwave:device:b07e5746:node27:switch_dimmer, refreshInterval=3” }
Dimmer MBed1_dim “MasterBed Reading [%d %%]” (FiF_MBed, fDimm) { channel=“zwave:device:b07e5746:node27:switch_dimmer, refreshInterval=3” }
No joy without the refresh interval removed either…
Another weird issue that I have seen for a while now is that when I restart openhanded the wave fails to initialise. The zwave stick shows as OFFLINE - COMMUNICATION_ERROR Serial Error: Port /dev/ttyACM0 does not exist
I then have to just change the location name to something else slightly different and then the controller comes online and all the nodes are discovered and initialised. This only happens on the Debian VM running openhab. My harmony, neohub, hue bindings all initialise fine. When I try this on my openhabian there are no such issues with the stick initialisation.
Any help would be greatly appreciated. Thanks again.
I have since tried to reduce the polling interval the device configuration to 3 although it seems to have reset back to 15 but has improved the response time to approx 15 secs. I know @chris would not like that and am hoping a better solution is reached with assistance. At least now I do not have to wait 30 mins for the device status to be updated on openhab. I’m hoping its something on the openhab zwave controller config that is the mistake. the only zwave devices I have are the fibre 212 dimmers and the aeotec gen5 stick. Hope you can help.
Have you tried deleting your Things and rediscovering? My Leviton dimmers would stop reporting after an update of the binding, and deleting the Thing (not excluding) fixes it.
I’m sure I did that to as the zwave/channel id would have changed. I delete all zwave items including the controller today. Sorry I had been on vacation. Will let you know if it works.
Hi Scott,
I tried that and it didn’t work. I did it 2 ways. Delete the zwave stick followed by the individual items. And rediscovered them all after adding the stick. And also deleting the individual items and the nthe zwave stick before re-discovering them all. Just some logs while doing some of the removes
2018-04-02 12:36:22.912 [hingStatusInfoChangedEvent] - ‘zwave:device:25b2bb4d:node33’ changed from ONLINE to REMOVING
2018-04-02 12:36:22.913 [hingStatusInfoChangedEvent] - ‘zwave:device:25b2bb4d:node33’ changed from REMOVING to REMOVED
2018-04-02 12:36:22.919 [hingStatusInfoChangedEvent] - ‘zwave:device:25b2bb4d:node33’ changed from REMOVED to UNINITIALIZED
2018-04-02 12:36:22.922 [hingStatusInfoChangedEvent] - ‘zwave:device:25b2bb4d:node33’ changed from REMOVED to UNINITIALIZED (HANDLER_MISSING_ERROR)
Removing z-wave stick
2018-04-02 12:57:58.861 [hingStatusInfoChangedEvent] - ‘zwave:serial_zstick:25b2bb4d’ changed from OFFLINE (COMMUNICATION_ERROR): Serial Error: Port /dev/ttyACM0 does not exist to REMOVING
2018-04-02 12:57:58.862 [hingStatusInfoChangedEvent] - ‘zwave:serial_zstick:25b2bb4d’ changed from REMOVING to REMOVED
2018-04-02 12:57:58.865 [hingStatusInfoChangedEvent] - ‘zwave:serial_zstick:25b2bb4d’ changed from REMOVED to UNINITIALIZED
==> /var/log/openhab2/events.log <==
2018-04-02 12:57:58.869 [hingStatusInfoChangedEvent] - ‘zwave:serial_zstick:25b2bb4d’ changed from REMOVED to UNINITIALIZED (HANDLER_MISSING_ERROR)
I am now doing a clean install and installing the latest snapshot org.openhab.binding.zwave-2.3.0-SNAPSHOT.jar as the first addon in a clean addon without any other bindings. Hopefully things will improve.
One other thing is that i started off at openhab1.6 when i did the items file. Is it worth redoing it if the syntax has changed/evolved?? Below is an extract of an item
Switch MBed1 “MasterBed Reading” (FiF_MBed) { channel=“zwave:device:c684afb6:node27:switch_dimmer” }
Dimmer MBed1_dim “MasterBed Reading [%d %%]” (FiF_MBed, fDimm) { channel=“zwave:device:c684afb6:node27:switch_dimmer” }
Dimmer MBed1_HB “MasterBed Reading” (Homebridge) [ “Lighting” ] { channel=“zwave:device:c684afb6:node27:switch_dimmer” }
Number MBed1_alarm “MasterBed Reading - Alarm” (fAlarm) { channel=“zwave:device:c684afb6:node27:notification_send1” }
Number MBed1_power “MasterBed Reading - current power consumption [%.2f W]” (gEnergy) { channel=“zwave:device:c684afb6:node27:meter_watts” }
Number MBed1_energy “MasterBed Reading - total energy use [%.2f KWh]” (gEnergyKWh) { channel=“zwave:device:c684afb6:node27:meter_kwh, refreshInterval=300” }
Any help is really appreciated. I really do not want to be changing the polling interval as @chris says it is not the right approach. BTW is it refresh_interval or refreshInterval for the zwave item.
refresh_interval does not exist in OH2. It has been replaced with the Polling Interval configured on the Thing. Rremove this from your Items. However, your items should be updating without the need to rely on the polling. I do not have this device, but it appears that your items do need some updating. Hopefully someone with this device will chime in. My understanding is that you would not use the channels in Endpoint 0. You could start here…
This is a bit of a guess, but I think your items should look something like this (note: I used code fences to improve the appearance). Why do you have separate items for Homebridge and the switch? I think you can combine these all into one item.
Switch MBed1 “MasterBed Reading” (FiF_MBed) { channel=“zwave:device:c684afb6:node27:switch_dimmer1” }
Dimmer MBed1_dim “MasterBed Reading [%d %%]” (FiF_MBed, fDimm) { channel=“zwave:device:c684afb6:node27:switch_dimmer1” }
Dimmer MBed1_HB “MasterBed Reading” (Homebridge) [ “Lighting” ] { channel=“zwave:device:c684afb6:node27:switch_dimmer1” }
Number MBed1_alarm “MasterBed Reading - Alarm” (fAlarm) { channel=“zwave:device:c684afb6:node27:notification_send1” }
Number MBed1_power “MasterBed Reading - current power consumption [%.2f W]” (gEnergy) { channel=“zwave:device:c684afb6:node27:meter_watts1” }
Number MBed1_energy “MasterBed Reading - total energy use [%.2f KWh]” (gEnergyKWh) { channel=“zwave:device:c684afb6:node27:meter_kwh1” }
There’s no need to delete the Thing for the controller, or to delete the Items. Just delete the Things and rediscover. This should only be needed after updating a binding where there are channel updates that have been made for devices that you already have a Thing for. After reading through the whole thread, I do not think this is your problem. Just be aware of it when you are updating bindings. There have also been some recent breaking changes in 2.3, which may make certain 2.3 bindings imcompatible with previous versions of OH2. If strange things happen (specifically during discovery), you may need to upgrade OH to 2.3 snapshot to use a 2.3 binding.
Another consideration is to use the development zwave binding. It should be the same as the 2.3 snapshot, as far as devices go, but has many features and fixes in it.
That was magic mate. Thanks. I did used have switch_dimmer1 a long time ago and for some reason changed to switch_dimmer. It worked like a charm. I have now run into other fibaro specific issues such as the light turning off immediately after being turned on. Possibly some overload protection. I thought i got rid of the ssues but seems to have resurfaced as the old config parameters seem to have dissappeared.
I thought i will take a leap with the dev zwave snapshot and installed it on a new openhab vm. It has just been done and the nodes are discovered.
Did you pull the controller out? If so, it may have come up on another port. Try rebooting. You could look into using udev rules so that the OH config stays consistent, no matter what port the USB stick comes up on.
Sorry was using /dev/ttyAMA0 instead of /dev/ttyACM0. Also i’m using the _HB item for homekit integration. i couldn’t use the _dim item for homekit because of the %d with the label which makes homekit think its a new item when dim level changes and i didnt want to complicate the homekit.cfg file with custom definitions as changes are harder to manage.
One very weird issue i’m having is that after i reboot the vm the zwave controller reports offline. if i edit the location to something else it comes back online. very weird but non critical as i dont reboot often
I recall someone else reporting that… maybe it was you. I’ve got no idea what could cause that… well… maybe the serial port is slow to come up? If your starting OH as a service, you could try delaying it’s startup.
How would i do the ddelay?? I’m happy to set the delay to 45 secs if that sorts the issue. This VM is dedicated to Openhab so no other services are running on it. It is a Debian 8 vm.
I don’t run OH2 as a service (yet). Easiest would probably be to add sleep 10 at the beginning of your start.sh to delay it’s running for 10s. But the best way would be to setup your unit configuration file to not start the service until your dongle was started.
