Page 1 of 2
Qubino Flush Dim State issue
Posted: Friday 11 October 2019 21:58
by hestia
I've bought 2 new Qubino (Goap) ZMNHDD1 Flush Dimmer+
And have an new issue
When I switch on the light with the GUI, it lights on : ok (the GUI and the real light)
When I switch off the light with the GUI, it’s lights off (the GUI and the real light): ok and after the GUI goes back to on ☹
I need to switch the GUI if off again to be aligned with the real light
Version: 4.11361
Build Hash: 1872f7e5d
Compile Date: 2019-10-11 16:42:44
Idem with the previous beta
I've tried
to delete ozwcache to recreate it
delete all the devices and click Refresh Node Info to recreate the devices
I still have this issue
The same with the 2 new devices
I also have still no refresh of the GUI when I use the real switch
https://www.domoticz.com/forum/viewtopi ... 84#p224798
I've tried an older one that didn't have this issue even tough it is the same HW version (for what I could read on the device)
Something with the browser (tested with Win 10 + Chrome and Ipad + Firefox)? With recent inclusion?
Re: Qubino Flush Dim State issue (no refresh)
Posted: Friday 22 November 2019 13:17
by hestia
same with last version
Version: 4.11503
Build Hash: a18e48543
OpenZWave USB
Version: 1.6-943-gacce060e-dirty
Qubino support reply it is an issue with the integration in Domoticz
Re: Qubino Flush Dim State issue
Posted: Wednesday 04 December 2019 16:44
by Ron
Ik have quite a lot of these ZMNHDD1 devices and no problem with it.
(version V4.10717)
Maybe you should use a stable version of Domoticz instead.(?)
Re: Qubino Flush Dim State issue
Posted: Thursday 12 December 2019 17:13
by ronaldbro
I'm having a simular issue with a few qubino Flush Shutters (ZMNHCDx). In the device log I see that the qubino's always report the current state again and then the new state. But with 3 out of 6 flush shutters these two messages are in the wrong order which causes Domoticz to report the old state.
I didn't notice it before because my control script just resend the command and the state is corrected. But because of a change in the script for manual mode detection it became a problem.
Re: Qubino Flush Dim State issue
Posted: Thursday 12 December 2019 21:07
by hestia
I saw there was something in the last beta regarding Config/qubino/ZMNHDDx.xml and particularly ZMNHDDx and I downloaded it...
And I've just experienced the same issue (but I didn't Refreshed my nodes).
In my script I have several Qubino Flush Dimmers and Qubino DIN Dimmers, all switch on or off at the same time... (perhaps I going to put a delay between each switch on/off... afterSec(1)
@Ron: I had this issue before the last stable!
@ronaldbro: If I remember well I got this issue when I extended the nodes in my script
Re: Qubino Flush Dim State issue
Posted: Thursday 12 December 2019 21:57
by ronaldbro
Hi Hestia,
What did you mean with ‘extended the nodes in my script’? Do you mean adding and switching more devices at the same time?
Some times I close or open 6 shutters at the same time. Would it help by adding a few seconds delay between the shutters?
Re: Qubino Flush Dim State issue
Posted: Thursday 12 December 2019 22:08
by hestia
I have a script with a list of devices to switch or off in my garden and a list of PIR to detect people
I started with some lights and PIR and added more
So now when I enter my garden I could switch on 4 different lights with 2 flush dimmers, 2 din dimmers... and another RFXtrx433 at the same time
Re: Qubino Flush Dim State issue
Posted: Thursday 12 December 2019 22:53
by ronaldbro
Interresting... Just for a test I reduced the number of trigger devices in my script and added a 5 second delay between the shutter commands when multiple shutters should be controlled at the same time. That way Domoticz and OZW have some more time to process everything. I'm curious if that would make a difference.
The 'problem' devices are the last 3 which are controlled in the script so that would support the theory.
Re: Qubino Flush Dim State issue
Posted: Friday 13 December 2019 13:20
by ronaldbro
I checked this morning but the delay and reducing the number of triggerdevices in the script didn't make any difference.
Re: Qubino Flush Dim State issue
Posted: Saturday 21 December 2019 19:10
by ronaldbro
@hestia, I found my problem today. Since OZW 1.6 you can have a multichannel lifeline for Z-wave. In the z-wave hardware tab -> groups -> group 1.
The trouble devices, which I added last had '1.1' for group 1 and the old devices had '1' for group 1.
Searching this forum and google I found out that 1.1 is for multichannel and is net for OZW 1.6. And it seems that the qubino's don't handle multichannel very good. I changed the zwave config file to disable multichannel and with some hassle I managed to get the all to '1'. And the problem is solved
Re: Qubino Flush Dim State issue
Posted: Saturday 21 December 2019 22:42
by hestia
@ronaldbro
great news
"qubino's don't handle multichannel very good."
I had emails with Qubino support and they answer that Domoticz should have 1 and not 1.1
viewtopic.php?f=24&t=30519#p230949
I have the complete email if you want
"I changed the zwave config file to disable multichannel" Could you please explain how to do this?
Re: Qubino Flush Dim State issue
Posted: Sunday 22 December 2019 1:16
by ronaldbro
I found the answer in this post:
https://domoticz.com/forum/viewtopic.php?f=24&p=225153
Add the following to the CommandClass with the group specification in the deviceconfig in domoticz/Conf/<device id>.xml
Code: Select all
<Compatibility>
<ForceInstances>false</ForceInstances>
</Compatibility>
And then:
- delete ozwcache.... file in /domoticz/Conf
- restart domoticz and let it finish z-wave initialization (takes longer as usual)
- remove the '1.1' from group 1
- On the Node tab do a device refresh on the node
- add 1 to group 1
I did have about 5 crashed of domoticz doing this, but when it was finished all worked perfect. (And I needed to rebind my zwave PIRs, but maybe I wasn't patient enough)
Good luck
Re: Qubino Flush Dim State issue
Posted: Sunday 22 December 2019 1:25
by ronaldbro
Lol, I just noticed that the answer was actually in your post
Hope you'll get it fixed
Re: Qubino Flush Dim State issue
Posted: Sunday 22 December 2019 10:29
by hestia
Perhaps in my post but surely I didn't understand it well enough
A copy / paste ?
I've tried what you described.
I have got this at the end of ZMNHDDx.xml
Code: Select all
<CommandClass id="96">
<Compatibility>
<MapRootToEndpoint>true</MapRootToEndpoint>
<ForceInstances>false</ForceInstances>
</Compatibility>
</CommandClass>
</Product>
But even after removing 1.1 from Group 1, it is 1.1 that reappears
Re: Qubino Flush Dim State issue
Posted: Sunday 22 December 2019 11:05
by ronaldbro
No, there is a commandclass section which contains all groups, add the three lines directly below the <CommandClass id="???"> line
Re: Qubino Flush Dim State issue
Posted: Sunday 22 December 2019 22:33
by hestia
I did it... with no success
I still 1.1 in Group 1
Could you please tell me if my xml is OK
Code: Select all
<!-- Association Groups -->
<CommandClass id="133">
<Compatibility>
<ForceInstances>false</ForceInstances>
</Compatibility>
<Associations num_groups="11">
<Group index="1" label="Lifeline" max_associations="1"/>
<Group index="2" label="Basic on/off input I1" max_associations="16"/>
<Group index="3" label="Multilevel set Flush dimmer" max_associations="16"/>
<Group index="4" label="Start level change/stop level change input I1" max_associations="16"/>
<Group index="5" label="Basic on/off input I2" max_associations="16"/>
<Group index="6" label="Notification report input I2" max_associations="16"/>
<Group index="7" label="Binary sensor input I2" max_associations="16"/>
<Group index="8" label="Basic on/off input I3" max_associations="16"/>
<Group index="9" label="Notification report input I3" max_associations="16"/>
<Group index="10" label="Binary sensor input I3" max_associations="16"/>
<Group index="11" label="Multilevel sensor report temp sensor" max_associations="16"/>
</Associations>
</CommandClass>
<!-- Remove COMMAND_CLASS_BASIC -->
<CommandClass action="remove" id="32"/>
<!-- Map endpoints to instances -->
<CommandClass id="96">
<Compatibility>
<MapRootToEndpoint>true</MapRootToEndpoint>
</Compatibility>
</CommandClass>
</Product>
Re: Qubino Flush Dim State issue
Posted: Monday 23 December 2019 23:17
by ronaldbro
Yep, looks correct.
Did you also follow this:
And then:
- delete ozwcache.... file in /domoticz/Conf
- restart domoticz and let it finish z-wave initialization (takes longer as usual)
- remove the '1.1' from group 1
- On the Node tab do a device refresh on the node
- add 1 to group 1
Re: Qubino Flush Dim State issue
Posted: Saturday 28 December 2019 20:14
by hestia
Thanks
I didn't refresh the node before adding 1 in the group 1!
I did it for the flush dimmer ZMNHDDx and it seems ok.
I did it also for the ZMNHADx Flush 1 Relay and ZMNHBDx Flush 2 Relays+ and it is ok too. I need to do some more testing to be sure.
I also did it for the DIN Dimmer ZMNHSDx, but it is not good, and I have different behavior
With both I have 1 in group 1, but the state is not updated in Domoticz, with the other, I have 1.1 in group 1, and it didn't work neither (not the same HW version for all the devices!). Maybe, I'll have to reverse...
If it is the solution, who is responsible of those files? Why Domoticz is not delivered with those files...
Re: Qubino Flush Dim State issue
Posted: Sunday 29 December 2019 19:08
by hestia
Follow-up...
for the DIN Dimmer ZMNHSDx I put the original xml file and refreshed the nodes. It was ok for some nodes except one. I removed 1.1 and put 1 in Group 1 and finally it was ok (after some domoticz crashes and restarts).
So far, all my qubino switches are working fine, the same for the Fibaro ones
I still have some issues with NOTRIGGER that didn't work well
viewtopic.php?f=6&t=27607: XXX.silent no longer works with Z-Wave devices
Re: Qubino Flush Dim State issue
Posted: Thursday 02 January 2020 9:02
by ronaldbro
Good to read that the 1.1 problem is solved.
About the .silent(), yep it’s a pain it doesn’t work for qubino’s. It because you get multiple updates in stead of just one.