I’m trying to trigger a scene by using the I2 input on a Qubino ZMNHDD1.
The problem is that for this to work I need to keep the push button pressed for about 7 seconds for the associated item to be updated in Openhab.
I’m looking for either speeding up the item change in openhab, which I think originates at the speed the ZMNHDD1 passes the ‘keypress’ along, or configure the Qubino or OH in such a way that a I2 input flips the value of the associated item.
zwave binding 1.0.9.2, OH1.8.2
Any ideas on how to achieve this??
Thanks
The solution was to add the controller to the first 7 association groups. At least you get a timely update in OH, but the value is alway 0 and stays 0.
So you need to change the rule trigger to simply look for an update. And to my surprise is a value of 0 being updated to 0, visible to OH as an update and triggering the scene.
rule "kitchenOff"
when
Item door_sensor_0 received update
then
bla bla bla
end
Really - I would have thought that would be a bad thing to do… Normally, only a single group should be required - if you add it to all groups, you will very likely receive multiple notifications which might cause problems.
More likely, this issue could be associated with the new implementation of associations in ZWave Plus, but if you are still using OH1, there is no solution for this as it’s not implemented in OH1.
It’s not all groups, there 4 more…
I’ve started experimenting by adding one group at the time until I received a notification in OH.
I could probably remove some of them associated with I1 from the list.
ok, but 7 is a LOT of extra communication.
Normally there is a lifeline group that should cover most communication (group 1 normally), but the issue is likely to be a common problem with ZWave plus and the second button in that the spec now requires encapsulation that must be configured using the multi-endpoint-association class.
Maybe there’s a group that provides some sort of backward compatability.
Good luck…
Did you ever find a solution to this one? I think I’m facing the same issue in z-wave-binding-and-qubino-dimmer-with-two-switches-on-i1-and-i2. When I use “received update” it also gets hit when polling and no state changes as it’s configured as binary sensor when I2 is enabled, a bi-stable switch would work as then it would at least change state but I prefer not to change as it’s already installed in 7 places…
Hi Johan,
I’m basically still use it with most association groups enabled. Waiting for OH2 migration to review all functionality.
rgds, c
I think I found a solution. Basically I’m setting the state of the binary sensor back to ON once it’s changed to OFF. That way I always get the “changed to OFF” event triggered on click. You can either do it on update or change:
rule "Reset node36 binary sensor on update"
when
Item node36_sensor_binary received update
then
if (node36_sensor_binary.state != ON) {
logInfo("rules.main", "Setting node 36 sensor binary to ON");
sendCommand(node36_sensor_binary, ON);
}
end
rule "node36 click on I2"
when
Item node36_sensor_binary changed to OFF
then
logInfo("rules.main", "It works!");
// Toggle other lamps here (if lamp is ON turn it OFF, if lamp is OFF turn it ON)
sendCommand(node36_sensor_binary, ON);
end
I’m using the latest OH2 snapshot. No other association groups than 1 for the main controller.
Cheers,
Johan
Nice, I’ll give it a go
I have tried this also, and now the rules are fireing after pressing I2 and I3. But it takes about 3-5 seconds before it happens. Is there any way to speed this up?
I’m in the process of updating to OH2, and that seriously messed up the rules for this switch. The rules execute at random now, creating a very entertaining effect in the kitchen.
Most likely it has to do with have too much associations as Chris suggested earlier. It should all get sorted in the next couple of days and I will post my findings here.
The minimum association groups my implementation needs is two: 1 and 7. I can activate other association groups, but it does not change behavior: for a reaction to occur (item update) it needs a key press of 1.5 sec approx. Too long for normal use.
I’m checking events.log for the item update. Triggering a rule will slow down the process a bit more.
Conclusion: the less than ideal solution in OH1, activating 7 association groups, does not work in OH2. I do not know of a way to speed up the item update. Resetting the item value in a rule seems not to address the timing issue and seems to happen anyway: (two log log lines are the result of a button press and release)
2017-06-08 13:14:54.821 [ItemStateChangedEvent ] - etage0KeukenKoofSensor1 changed from 0 to 1
2017-06-08 13:14:57.826 [ItemStateChangedEvent ] - etage0KeukenKoofSensor1 changed from 1 to 0