I also found that one… is that ms ? 1500 = 1,5 s?
I changed it to 300 by coincidence … which would even be faster but that improved the situation a bit… odd
or the 1500 is only displayed but the real default which was set?
Yes - it is in milliseconds.
I don’t understand this point? 1500 is the default. Before this setting was added, the binding used to send the GET request immediately after the SET and this caused problems with some devices.
I can only describe it by my observation as I did not log it.
But I guess for a new device it shows 1500 in habmin but that value is not really set? My experience on default “felt” like it was performing a GET request or Poll instantly as this was exactly the behaviour on the UI.
.
Ok, without logs, I can’t really comment. It’s also possible that the times can be shorter as the timer is from the point the SET is queued, not when it is sent. AsI said though, in previous versions, this time was basically always 0 as the GET was queued at the same time as the SET.
ok these devices drive me crazy :D:D:D too good I have 16 of them
ALL have the same revision H1S2P2 ans the same device firmware etc in Habmin
MOST work: I dim from 0 - 100
The Watts slowly rise as messages are received from 0 to final watt usage
Dim Level stays at 100
SOME : I dim from 0- 100
dim level in real life goes to 100 however the device sends ONE message during dim up with the current level (e.g.) 56 and the current watt
the final DIM level 100 and final watt usage is not sent anymore
same device same everything
crazy
node 55 → fine
node 56 → cr*p
any idea @chris where I could look further?
@shorty707 do You expirience the same hng that is desribed here ? Qubino Dimmer Firmware 3.7 reporting wrong status
Hi, I’ve read almost the whole thread and thought, that the problem might be solved. But I have the problem that my qubino roller shutter is not reporting a status.
I’m using the latest official version of openhab (2.3 I think) no development.
I will attach the node9.xml and a log. After a few minutes with log-level trace i’ve reduced it to warn, but i think all relevant information should be in there.
By the way, it seems that the association group was not set automatically and setting it manually does not work, after reloading the page, group 1 is empty again . I think this might be an important information.
How can i upload the log file? file extension (zip) is not allowed
Please use the development version of the binding before looking further. Hopefully this will solve the issue, but if it doesn’t we need to start from there as it’s not possible to debug the very old binding.
When you change to the development binding, I’d recommend to reset these devices and re-include them.
Hi Chris,
thank you for the answer.
I’ve updated the binding to Version 2.4.0.201808230908 (the latest I found). I’ve excluded and re-included the device but I still have the same issue:
- seems that there is no status send
- association group 1 is not set and I cannot set it manually. After saving the setting and checking it, that one field is empty again.
Because I cannot upload a zip file I provide my latest log at this link: log file as zip
This log doesn’t look like it’s from the development version. You need to manually install the version from the top of this thread - please read the first half dozen or so messages about installing this…
I’m confused because i’ve installed that version: https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastStableBuild/org.openhab.binding%24org.openhab.binding.zwave/ and this is also with date 23.08.2018 and has the same filename as your link. Ive installed it by hand according ti this post:
How to upgrade Zwave-Binding to latest Snapshot?
The version number is also in thw log file in one of the first lines
That doesn’t make it the same. Every snapshot has the same filename - it’s potentially rebuilt every day, but it can be different.
You need to use the binding, and read the information on the post I referenced above.
ok, now I’ve updated to the binding you told me but this causes a lot of problems for some reason.
I deleted the things as mentioned in the post but after the update it took me about 2 hours to add at least two of them again and they do not work really good at the moment.
Also I still have the same problem with the roller shutter, I do not get any status and association group is not set and cannot set manually
https://files.fm/u/4avt6qjd
You also should follow this recommendation:
Make sure through Karaf that only ONE zwave binding is active.
I’ve excluded and reincluded the devices, but I’m not sure if it worked for the roller shutter because it is still node9, all other nodes got new numbers. Will try it again.
— edit —
ok, obviously the qubino has not been excluded. all other devices were not able to connect without exclude and re-include so I did not ask why the qubino kept its node number. Now it is definitly re-included and it seems that i get a power status.
Still it seems that the zwave network is less reliable than before.
Also I have a strange behavior now. If i send the up or down command via zwave, the shutter stops twice and goes on in less than 1 second on the way up and down. This does not happen when using the hardware-switch but this is probably nothing for this thread.
Thank you for your help
Anyone having those problems with stable zwave binding in OH 2.3.0 stable?
8-08-28 08:06:07.314 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 4: Already processed another send data request for this callback Id, ignoring.
2018-08-28 08:06:07.500 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 4: Already processed another send data request for this callback Id, ignoring.
2018-08-28 08:06:10.761 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 4: Already processed another send data request for this callback Id, ignoring.
==> /var/log/openhab2/events.log <==
2018-08-28 08:06:13.498 [hingStatusInfoChangedEvent] - 'zwave:device:81ab7676:node4' changed from ONLINE: Node initialising: STATIC_VALUES to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller
==> /var/log/openhab2/openhab.log <==
2018-08-28 08:06:13.635 [WARN ] [WaveAssociationGroupInfoCommandClass] - NODE 4: Unsupported Command 0 for command class ASSOCIATION_GROUP_INFO (89).
==> /var/log/openhab2/events.log <==
2018-08-28 08:06:13.636 [hingStatusInfoChangedEvent] - 'zwave:device:81ab7676:node4' changed from OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller to ONLINE
2018-08-28 08:06:28.023 [hingStatusInfoChangedEvent] - 'zwave:device:81ab7676:node4' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller
2018-08-28 08:06:28.157 [hingStatusInfoChangedEvent] - 'zwave:device:81ab7676:node4' changed from OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller to ONLINE
2018-08-28 08:07:12.094 [hingStatusInfoChangedEvent] - 'zwave:device:81ab7676:node4' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller
It’s also a Roller Shuter Qubino ZMHNCD1 but it does weird stuff. Especially this communication error, what’s causing it?
And also this other messages are strainge like:
2018-08-28 08:06:07.500 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 4: Already processed another send data request for this callback Id, ignoring.
or this:
2018-08-28 08:06:13.635 [WARN ] [WaveAssociationGroupInfoCommandClass] - NODE 4: Unsupported Command 0 for command class ASSOCIATION_GROUP_INFO (89).
Would you advise to switch to the dev version of the binding? Or is there anything I can do to make the stable work better. Especially the communication error is bad because somtimes device is OFFLINE and sometimes ONLINE. It’s quite random.
What I do see is that none of the association groups are set. Any help would be greatly appreciated.
sorry for jumping on this thread but i think my question fits best here…
i have 2 qubino flush 1 realys in my z-wave network that i installed behind sockets.
They have been discovered, included and everything is fine, but…
1 of those is in the socket my fridge is connected to and obviously i rarely switch it.
Can anyone confirm that those qubino only send updates on the “meter_kwh”-channel if the “switch-binary”- channel receives an update?
Regards,
Raven
I don’t have the device (a link to the device db would help), but you are likely seeing the meter_kwh channel updating due to a poll that is done after a command is sent to the device. Make sure the device configuration parameters and associations are set properly. I’ve also seen this after the Thing definition has been updated in the binding but the Thing has not been updated. If this is the case, deleting/rediscovering the Thing (this does not mean exclude/include) will pull in the new definition and set some of the associations for you.
The device is this one: Qubino/Goap ZMNHAD
I’m running 2.4.0 snapshot and haven’t updated the binding after i joined this Thing, so i assume the definitions are correct.
No, this is not the case. I don’t have this particular device, but I have a dimmer ZMNHDD and I think they are both very similar. There are 2 configuration parameters responsible for sending power reports:
- 40: Power reporting in watts on power change
- 42: Power reporting in Watts by time interval
Take a look at the configuration, 0 in each means no reports - maybe for some reason you have reports disabled.