Yes, does this affect all devices? Will Z-Way show more recent values for the devices?
Please perform the following command once: http://Z_WAY_IP:8083/ZAutomation/api/v1/devices/OpenHabConnector/command/refreshListener.
This should solve the problem one time. Normally this is also done with every change in openHAB. Can you check in the terminal if any errors have occurred for the affacted item or thing for example with: grep "ITEMNAME" /opt/openhab2/userdata/logs/openhab.log (change ITEMNAME to the value from the second column of openHAB connector list).
I have an additional question on one of the channels:
Thermostat operation (24.0)
zway:zwayDevice:11fb7777:24:thermostatMode-ZWayVDev_zway_24-0-64content_copy
The channel allows the control or display of a thermostat (mode). A thermostat can have up to three states (modes): off, heating and cooling. The state of heating and cooling is alternately set at the state on.
The only way here is to define the OpenHAB-item as a String and check the value of it?
Can you also please elaborate when the value will be “HEATING”, “COOLING” or “ON” ?
That’s a problem of Z-Way. Thermostat modes are mapped incorrectly to virtual devices, only as binary switches. An “on” command in Z-Way sets the mode alternately (1 - heating / 2 - cooling) and an “off” command sets the mode 0 (off). However, many Z-Wave thermostats have several modes. The problem is known and worked on the Z-Way developers.
As a workaround I’ve implemented the thermostat command class as channel (see immage). Here you can set the thermostat mode, e.g. for stella-z thermostats: 1 (frost protection), 0 (energy saving) or 11 (comfort). Note: if the value changes outside of openHAB, it is not updated directly in openHAB, only during a polling. Whether your HeatIt thermostats support the thermostat command class I can not recognize directly from the manual.
What does not work is the command class configuration. Do you change the configuration parameter 12 during the runtime or only once during configuration?
I do have an Aeonlab zstick gen5 as my zwaver controller and I’m stuck, for over 2 months, with initialisation of a motion sensor as discussed here.
Since the problem is within the database of supported zwave devices, which I don’t know how to resolve, I’m considering to use the zway binding instead of the zwave binding.
I have two questions:
Will the Z-Way software license key, work with the Aeonlab zstick gen5 zwave controller?
Does the Z-Way software operate based the zwave database or some other database? (would it support the HSM100 motion sensor?)
Is the binding in the final openhab 2.0 the latest or should I download another one? The roller shutters are all offline (Error occurred when performing polling.)
EDIT: Oh and I’m using 2.3.0-rc10 of z-way becaufe of problems with fibaro dimmer 2
Can you please describe the problem in more detail? The dimmer and binary switch function should work. What virtual devices does Z-Way generate for the Fibaro Dimmer 2? According to the manual, a dimmer, a binary switch and a display for power and energy consumption should be generated.
it was a test because dimmer 2 never completed interview. The rc10 did it.
Back to 2.2 I’ll test your new binding. Thank you and I will tell the result!
Well, I just installed, added new items and linked them to the new channels.
Everything works great so far! I’ll keep an eye on it and report back…
Many thanks Patrick!
I just noticed some messages in the logs… I didn’t see them before, but that doesn’t mean it’s because of the testing version. Maybe I was not paying attention…
13:30:24.573 [INFO ] [thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/Front_Door_Sensor_Battery/state' for the unknown item 'Front_Door_Sensor_Battery'.
13:30:24.582 [DEBUG] [.zway.handler.ZWayZWaveDeviceHandler] - Handle update for channel: battery-ZWayVDev_zway_7-0-128 with new state: 82
13:30:24.822 [INFO ] [marthome.event.ItemStateChangedEvent] - Front_Door_Contact_LastUpdate changed from 2017-02-07T13:25:03.000+0200 to 2017-02-07T13:30:24.000+0200
Item was renamed a while ago from Front_Door_Sensor_Battery to Front_Door_Contact_Battery and I added today the item Front_Door_Contact_Battery:
Number Front_Door "Front Door [MAP(fibaro_contact.map):%s]" <frontdoor1> (Contact_Items, Doors)
Switch Front_Door_Contact (Contacts, Doors) {channel="zway:zwayDevice:192_168_200_202:7:ContactBinary-ZWayVDev_zway_7-0-113-6-Door-A"}
Number Front_Door_Contact_Battery "Front Door Contact [%.1f %%]" <battery> (Doors, Contact_Battery) {channel="zway:zwayDevice:192_168_200_202:7:battery-ZWayVDev_zway_7-0-128"}
DateTime Front_Door_Contact_LastUpdate "Front Door [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" <calendar> (Doors, LastUpdate) {channel="zway:zwayDevice:192_168_200_202:7:lastUpdate"}
Who is trying (and why?) to PUT the new state to the old item?
This is because the observer (openHAB item) was not properly removed in the Z-Way module. Z-Way tries to notify the non-existent item. This is not problematic, but I should rework the Z-Way module.
Getting back to the “last seen” timestamp…
Where do you get this “last seen” info from? I’m interested in the “last seen” timestamp as the time when the device last communicated with the z-way controller.
It seems that that is not the case…
Here are 2 screenshots:
The second image comes from the Z-Way Expert-UI and you can see in clear the time when the device connected to the controller.
In the screenshot from my sitemap, there is another timestamp.
Maybe this is from the last time the binding scanned the z-way-server for devices?
However, the time of the last connection is only loaded if the value of the device changes. Therefore, the time could not always be quite up-to-date. Otherwise I would have to pull the time constantly.
