Since the moment the binding was integrated into openHAB I never removed it.
Just upgraded it along openHAB.
Right now it seems that I’m using version:
openhab> bundle:list -l | grep -i zway
229 | Active | 80 | 2.2.0.201707190537 | ZWay Binding | mvn:org.openhab.binding/.../2.2.0-SNAPSHOT
Sorry for asking again. Where did you find the version org.openhab.binding.zway-2.2.0.jar?
Hello Mihai,
i dont know why but my Wall-C works. But i use a Scene ID like 10 for Button one normal click.
Group gFL_Wandschalter "Flur Wandschalter" <wallswitch> (gFlur)
Number FL_Wandschalter_Scene "Flur Wandschalter[%s]" <wallswitch> (gFL_Wandschalter) { channel="zway:zwayDevice:192_168_2_9:27:sensorDiscrete-ZWayVDev_zway_27-0-91-DS" }
Number FL_Wandschalter_Batterie "Flur Wandschalter Batterie [%s]" <battery> (gFL_Wandschalter, gBatterie) { channel="zway:zwayDevice:192_168_2_9:27:battery-ZWayVDev_zway_27-0-128" }
but i have the same Problem with a Danfoss Room Sensor. It has a Button and when i press it then …
10:18:55.643 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/FL_RaumSensor_Button/state' with an invalid status value 'on'.
and in the zway log on my WD i have this entry:
10:18 | Observer not notified - openHAB item: FL_RaumSensor_Button (HTTP Status: 400 - Bad Request - State could not be parsed: on). Failed request: http://192.168.2.2:8080/rest/items/FL_RaumSensor_Button/state with body: on
I thought its a problem with case sensitive ???
Joerg
I suspect also a case issue…
Regarding the WALLC-S, your item definition matches my gTestControl - same channel {channel="...sensorDiscrete-ZWayVDev_zway_37-0-91-DS"}
That works OK - it’s a Number
I’m having problem with another channel, which is mapped to a Switch: {channel="zway:zwayDevice:192_168_200_202:37:switchControl-ZWayVDev_zway_Remote_37-0-0-1-S"}
Will wait for @pathec to shed some light.
I created this item …
Switch FL_Wandschalter_Button1 "Flur Wandschalter Button 1" <wallswitch> (gFL_Wandschalter) { channel="zway:zwayDevice:192_168_2_9:27:switchControl-ZWayVDev_zway_Remote_27-0-0-1-S" }
and in the openHAB log is now the same … when i press the button
09:56:40.874 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/FL_Wandschalter_Button1/state' with an invalid status value 'on'.
I think its a case sensetive Problem ???
I tried it with the REST API
when i put “on” i have error 400.
when i put “ON” its ok with Status Code 202-Accepted
But i dont know how we can manage this?
Hi,
Sorry for the late reply. I have uploaded an update for the openHAB connector to the Z-Way AppStore. The new version 0.1.6 is visible through the access token sse_zwickau_beta. Then simply update the openHAB connector. That should solve the problem.
Hi Patrick!
I updated openHAB connector to 0.1.6, but I think something’a broken seriously…
Now, even states that were supposed to be sent as numbers - like battery levels or power consumption - are sent as ON/OFF:
2017-09-02 16:53:53.305 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/gTestControl/state' with an invalid status value 'OFF'.
2017-09-02 16:54:18.160 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/Front_Door_Contact_Battery/state' with an invalid status value 'OFF'.
2017-09-02 16:54:37.645 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/gTestControl/state' with an invalid status value 'OFF'.
2017-09-02 16:54:39.553 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/WashingMachine_W/state' with an invalid status value 'OFF'.
2017-09-02 16:54:43.467 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/gTestControl/state' with an invalid status value 'OFF'.
2017-09-02 16:54:48.077 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/gTestControl/state' with an invalid status value 'OFF'.
2017-09-02 16:55:17.867 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/HEM_Total/state' with an invalid status value 'OFF'.
2017-09-02 16:55:39.555 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/WashingMachine_W/state' with an invalid status value 'OFF'.
2017-09-02 16:56:39.534 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/WashingMachine_W/state' with an invalid status value 'OFF'.
2017-09-02 16:57:17.695 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/HEM_Total/state' with an invalid status value 'OFF'.
2017-09-02 16:57:39.540 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/WashingMachine_W/state' with an invalid status value 'OFF'.
2017-09-02 17:05:54.811 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/HEM_Voltage/state' with an invalid status value 'OFF'.
2017-09-02 17:05:56.071 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/HEM_Current/state' with an invalid status value 'OFF'.
2017-09-02 17:06:15.592 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/Balcony_Door_Contact_Battery/state' with an invalid status value 'OFF'.
I removed all the observers from the list, rebooted the whole system - just in case, but the problem remains.
In openHAB connector, the list of observers is full of Unkown for those number channels:
Please retry it with version 1.7. I’ve reverted the changes and add the device type toggle button to ON/OFF transformation.
Thanks, Patrick, it look OK now and no more Received HTTP PUT request errors.
Thanks you Patrick. The Failure is gone but i dont see the “on” command in openHAB. Only the SceneID.
My Items looks like this
Number FL_RaumSensor_Control "Flur Raumsensor Control [%s]" <temperature> (gFL_RaumSensor) { channel="zway:zwayDevice:192_168_2_9:33:sensorDiscrete-ZWayVDev_zway_33-0-91-DS" }
Switch FL_RaumSensor_Button "Flur Raumsensor Taster" <temperature> (gFL_RaumSensor) { channel="zway:zwayDevice:192_168_2_9:33:switchControl-ZWayVDev_zway_Remote_33-0-0-1-S" }
But in the Screenshoot you see the Z-Way History and openHAB log.
I hope it will help.
Hi Patrick,
i switched over from openHab ZWave binding to Z-Way (Razberry) and tried to integrate an Figaro RGBW Controller. Now i run into a problem.
If i use multiple sendCommands to control the Red/Green/Blue Dimmer Channels the color switches, but it takes very long between each change. I guess around 50s. With the openHab ZWave binding the same rule took only around 5s.
I tried to improve the rule using a sendCommand with HSBType, but i could not successfully run that rule. I don’t know exactly whats the problem with that.
Do you have any advise why the ZWay communication is processed that slow or an rule that works with the zway binding for an rgb (or better hsb) color control?
Thanks and greetings from saxony 
Danilo
Hi there,
I am also trying the binding and I am wondering if there is no field to enter the network key for the secure inclusion?
Matthias
Hi!
I’m having major problems installing the z-way binding using the paperui.
Openhab restarts and the binding is uninstalled. Other bindings intstall just fine.
MapDB also crashes during this process.
Anyone else having problem with this?
Trying to install it manually:
208 │ Active │ 80 │ 2.7.0 │ Gson
209 │ Installed │ 80 │ 2.0.0.201612071328 │ ZWay Binding
openhab> bundle:start 209
Error executing command: Error executing command on bundles:
Error starting bundle 209: Could not resolve module: org.openhab.binding.zway [209]
Unresolved requirement: Import-Package: com.google.gson.internal
Anyone else having problems installing zway under latest oh2 snapshot?
/S
no, but possibly you’re missing the serial binding => feature:install openhab-transport-serial
After upgrading from 2.1 STABLE to latest SNAPSHOT i have numerous warnings like:
11:18:05.538 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
I believe there is something linked to Z-Way binding.
I’m running latest openHAB 2.2 SNAPSHOT, Z-Way binding 2.2.0.201711121147 and openHAB Connector 0.1.7.
The DEBUG log:
11:20:49.272 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:20:49.594 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: sensorMeterW-ZWayVDev_zway_49-0-50-2 with new state: 3.52
11:20:49.634 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:20:53.977 [DEBUG] [.discovery.ZWayDeviceDiscoveryService] - Z-Way device found with 3 virtual devices - device types: switchBinary, sensorMultilevel, sensorMultilevel
11:20:54.596 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:20:57.238 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_40-0-37 with new state: OFF
11:20:57.304 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:00.489 [DEBUG] [.discovery.ZWayDeviceDiscoveryService] - Z-Way device found with 10 virtual devices - device types: switchControl, switchBinary, sensorMultilevel, sensorMultilevel, sensorMultilevel, sensorMultilevel, sensorMultilevel, sensorBinary, sensorBinary, sensorBinary
11:21:02.242 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:03.762 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Checking link state of channel: Window Sensor - Bedroom
11:21:03.784 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh items that linked with channel: Window Sensor - Bedroom
11:21:08.147 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_46-0-37 with new state: OFF
11:21:08.185 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:13.154 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:13.857 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Checking link state of channel: Current power (#42)
11:21:13.880 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh items that linked with channel: Current power (#42)
11:21:14.638 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: sensorMeterW-ZWayVDev_zway_74-1-50-2 with new state: 0
11:21:14.691 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:19.641 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:20.703 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_44-0-37 with new state: OFF
11:21:20.739 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:25.704 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:27.457 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_74-2-37 with new state: OFF
11:21:27.559 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:32.462 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:34.335 [DEBUG] [.discovery.ZWayDeviceDiscoveryService] - Z-Way device found with 3 virtual devices - device types: switchControl, switchBinary, switchBinary
11:21:37.468 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_74-1-37 with new state: OFF
11:21:37.517 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:40.718 [DEBUG] [.discovery.ZWayDeviceDiscoveryService] - Z-Way device found with 4 virtual devices - device types: switchControl, sensorMultilevel, thermostat, battery
11:21:42.473 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:43.928 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:48.149 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: battery-ZWayVDev_zway_51-0-128 with new state: 78
11:21:48.184 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:50.310 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Checking link state of channel: Aeotec Electric Meter (#42)
11:21:50.334 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Polling for device: Aeotec Home Energy Meter not possible (channel Aeotec Electric Meter (#42) not linked
11:21:50.361 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:53.155 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:53.466 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_40-0-37 with new state: OFF
11:21:53.506 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:21:56.610 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Checking link state of channel: Door Sensor - Front Door
11:21:56.631 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh items that linked with channel: Door Sensor - Front Door
11:21:58.471 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:21:59.803 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_46-0-37 with new state: OFF
11:21:59.849 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:22:04.806 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:22:07.483 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: switchPowerOutlet-ZWayVDev_zway_50-0-37 with new state: OFF
11:22:07.522 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:22:09.008 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Starting polling for device: Window Sensor - Balcony
11:22:09.036 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Checking link state of channel: Window Sensor - Balcony
11:22:09.078 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh items that linked with channel: Window Sensor - Balcony
11:22:12.485 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
11:22:12.986 [DEBUG] [.discovery.ZWayDeviceDiscoveryService] - Z-Way device found with 4 virtual devices - device types: sensorBinary, sensorBinary, sensorBinary, battery
11:22:14.855 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Starting polling for device: Window Sensor - Kitchen
11:22:14.877 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Checking link state of channel: Fibaro Battery (#61)
11:22:14.901 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh items that linked with channel: Fibaro Battery (#61)
11:22:16.217 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: sensorMultilevel-ZWayVDev_zway_74-1-50-0 with new state: 0.37
11:22:16.254 [DEBUG] [g.zway.handler.ZWayZWaveDeviceHandler] - Refresh last update for Z-Wave device
11:22:21.222 [WARN ] [core.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1c0a912' takes more than 5000ms.
On 2.1 STABLE I never noticed any warnings like that…
Does anybody have a clue?
@pathec Patrick, are you still maintining this binding?
Thanks
Hi @Mihai_Badea
I see similar Warnings in my upgraded Version (Build #1080). But I cannot see, whether it its related to the ZWay-Binding or another configuration.
I upgraded from #101x or something (I could have a look at it if needed).
I am running my openHAB2 on an Raspberry 3, but from time to time I have to restart the software to get it running again. It feels like with the new version the time for a restart of openHAB gets shorter and shorter. Even the Alexa service latency increases with the new version.
So like you I would like to know what causes this issue.
Where is your instance running on? I download and update every new snapshot-version via this script here (https://github.com/xsnrg/OpenHAB2-tools/blob/master/makeHAB). So it is a manual installation.
cheers