Ok, thanks. Just note that in the next update, it might change to use dimmer 1. If so, then I hope it should be consistent and reproducible and we then should remove Dimmer channel from the database.
Let’s see 
with the latest dev binding the Qubino flush 2 relay is reporting binary1 and 2 status back to OH2 for me,
however it takes at least 3 seconds to show up in habmin or any other UI.
is this “delay” to be expected or is it my setup?
I would suggest to take a look at the logs - check when the response is logged in the zwave binding. When I was testing here, the responses came in pretty quickly - if it’s the same for you, then the issue might just be the time it takes for the state change to propagate through the system and out to the UI.
3 seconds seems very long, but there are a lot of things that need to happen after the zwave binding updates the event bus to get stuff out onto the UI…
With Dimmer1 it is working the same.
Now I have couple of strange behaviours …
In my sitemap I have defined Switch and Setpoint for the dimmer like this:
Switch item=bedroom1_light_dimmer icon=“switch” label="Large Bedroom"
Setpoint item=bedroom1_light_dimmer minValue=0 maxValue=100 step=5
- when turning on/off the lights manually (from the light switch) i do get update of the Setpoint but do not get update of the Switch - but after reloading the page in Basic UI both Switch and Setpoint are showing correct values.
- Lights are set to 100%. When I turn light off manually and then turn on from the Basic UI the lights are set to 50% instead of last 100%. in the log I can see that the command to the switch is to set FF (if i decoded it correctly):
01 0A 00 13 1E 03 26 01 FF 25 CF C9
and then in response:
01 09 00 04 00 1E 03 26 03 32 F8
and i guess that the reported value is 32 -> 50% - You wrote that the switch channel will be removed, why ? I would like to use switch channel because the dimmer has two dimming time settings, one dimming time is for switching light manually and remotely with switch channel, and another dimming time is for setting the dimming value manually and remotely with dimmer channel. So if there will be no switch channel then turning on/off lights remotely with dimmer channel will use the second dimming time setting which normally is quite large (I have set it to 5 seconds).
My Qubino flush 2 relays are also very slow, the 3 seconds is exactly what I experienced. For this reason I changed to Fibaro FGS223 for “time critical” items which reports nearly immediately. So from my experience I would say that this a typical characteristic of the Qubino flush 2 relay (I have more than 10 of these, all with firmware 1.2).
@vossivossi how is you experience with the FGS223 ? i heard / read that a lot of people have problems with them, that the relays giving issues quite often. that’s why i was testing the qubino relay.
But you don’t get reports if you change the dimmer at the switch I assume? Only Dimmer updates through the associations right?
If you use FF then the device will return to the last value - this is configurable in the channel configuration.
Because it is not required - you can just use the dimmer channel. It should use exactly the same commands as the switch channel if you use a switch.
My experience with FGS223 is very good. I am running 12 of them and the response speed of status updates is nearly immediately (max. <= 1 sec.).
There were also problems with the endpoints about a year ago (you can find the discussion here in the forum) similar to the Qubino problems. The problems were then solved and when I included them via Habmin network wide inclusion everything worked fine (but this was months ago). There are however some reports here which indicate that at some stage the dev binding had a regression so I am not sure how they will work if you include them with the most recent dev version.
The strange thing with all these problems (Fibaro FGS223 und Qubino ZMNHBD) ist that they were all already solved in the first half of 2017 and from then on my devices all worked fine (reporting status changes on swtich1/2, power 1/2 etc.). But it seems that I was lucky to include them with a binding version at the time which made them work (although I do not understand why this makes a difference).
sorry, actually it is not working with Dimmer1. I changed from switch_dimmer to switch_dimmer1 in the items file, but actually it only added the link between item and switch_dimmer1 channel - the old link was not removed so there was two links. I had to comment out the item definition to remove all links and then add it again.
Yes, and I have set it to “restore last value” but the actual behaviour is different. Instead of setting the last value of 100% it sets the dimmer to 50%. And if the last dimmer value was at 50% then it sets the dimmer to 30%. It only works like that if i turn off manually and turn on remotely. I can send you the debug log.
Actually no. As I wrote, there are two dimming times, and one dimming time is used with switch channel and the other dimming time is used with dimmer channel.
Maybe this is a device setting? If the binding is sending FF, then I don’t think it can be a problem with the binding…
Yes, but this is not the point. The binding should send the same commands if you send a ONOFF type to the dimmer channel. It’s not currently configured this way, but that’s how it should be configured.
I’d like to try out the latest changes you’ve made, @chris. Just to be sure, is this were you put the latest development builds for the Qubino changes?
http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar
Yes, but please refer to the following thread as installing is not as simple as with the master binding -:
The top 6 or so messages are relevant for installing…
@vossivossi i just fully reset my zwave stick of my test environment and added the latest dev binding for ZWave.
re-included the fibaro 223 and my qubino flush 2 relay, which was reporting the status with the earlier binding.
fibaro working perfectly, but qubino is now not reporting any status.
Please provide a log and I will take a look.
@chris
Chris, I am sorry to report that using the Dec. 30th Build, my firmware 1.1 version dimmers no longer report state back to openhab.
I have tried all the “tricks” that worked when this was “fixed” some time ago…
Please provide a debug log and I’ll take a look, but also check (if you haven’t) that no channels are working… By this, I mean check that neither the dimmer, or dimmer 1 channels are working.
Hopefully tonight I’ll update the binding and I’ve updated the dimmer to remove some channels to avoid some confusion - let’s see if that helps or makes things worse .
I’m just going to do one last test and delete the xml:s and restart the binding, and also test to manually re-set the associations.
Chris,
I created a ticket and uploaded a log, ticket ID KBXfmTkhQ9P.
5 dimmers, two are reporting back. 3 does not.
Thanks - I’ll take a look.
@rozpruwacz the latest update now removes the switch - if you send an on/off command, then it should send exactly the same command, in exactly the same way as the switch channel (it goes through the same converter still). Please let me know if you have any issues - I only did a quick check to make sure that the binary_switch command was being sent, which it was…
Sorry Daniel, but the log doesn’t have the initialisation as the device was presumably already initialised and it just loaded the data from the XML
Maybe the thing to do is to use the latest binding that I just loaded an hour or so ago so we have a known starting point. The after initialisation has completed and everything is settled, use HABmin to reinitialise the device - this is in the menu in the top right corner once you select advanced mode.
Try this with one device that doesn’t work…
Also, I assume when you say that the device doesn’t report status that there is nothing in the logs?
Thanks.
Chris