Qubino ZMNHBD1

[jotakar]

The config XML file for Qubino ZMNHBD1 Flush 2 Relays contains the line

In Domoticz at least this line must be deleted, so the device will be properly detected (as 3 relays: one common and 2 individual)

Thanks

[Fishwaldo]

Please use the code tags - I can't see what line you refer to, but I"m guessing based on your email to the mailing list.
@nechry Does this seem ok to you?

[nechry]

I guest is the

<!-- Map endpoints to instances -->
<CommandClass id="96" mapping="endpoints" />

yes they will got 3 switches but they will be not happy with the behaviors.
they still mix endpoint instances as I remember.

the qubino issue is more deeper as I can understand.

[jotakar]

Thanks for your answer

Yes this is the line, the last line in the file.

I have the model ZMNHBD1 H1S3P1, that’s the software version S3. And with this modification of XML file it’s working fine under Domoticz. Every relay responds properly and it’s status is reported right. If I don’t delete it the two relays don’t works fine (Q1 report as Q1+Q2, although it commands just one relay).

I know previous version of software had problems.

Perhaps it would be a good idea to add a comment in the config file about this issue.

Thanks

Juan Carlos Gámez

De: Jean-François Auger [mailto:notifications@github.com]
Enviado el: martes, 19 de abril de 2016 15:40
Para: OpenZWave/open-zwave
CC: jotakar
Asunto: Re: [OpenZWave/open-zwave] Qubino ZMNHBD1 (#857)

I guest is the

yes they will got 3 switches but they will be not happy with the behaviors.
they still mix endpoint instances as I remember.

the qubino issue is more deeper as I can understand.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #857 (comment) Imagen quitada por el remitente.

[nechry]

@jotakar Ok I have one in my lab and is a version H1S2P1 so they (qubino) finally do a patch.
I will connect again and check without the mapping="endpoints" if the behaviour is acceptable, I don't want loose "compatibly" with old devices. a new version they allow multi config according to the device version, @Fishwaldo do you confirm?

[Fishwaldo]

I"ll let it to you to test @nechry as I don't have the device.

[kjamsek]

Hello,
about the line in question about mapping endpoints:
<!-- Map endpoints to instances --> <CommandClass id="96" mapping="endpoints" />
This was thought to be needed because the guide about OZW's static configuration files ( https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices ) makes no mention about defining endpoints whereas the other device files they inspected had these lines included.

According to my knowledge no static mapping of endpoints is even needed in Z-Wave since the module can report the number of supported endpoints (via the Multi Channel Command Class) when queried by the controller.

In order to dispell any confusion here is a short intro to how Qubino devices are represented when included into a controller that supports Multi Channel commands and associations and one that does not (this was implemented in such a way according to Sigma's requirements for maximum backwards comnpatibility since the module can't tell whether a controller supports the classes in question or not):

• Non Multi Channel context:
  The module is seen by the controller as a single Z-Wave device. This device reports Binary Switch Status, Meter Reports and etc.. as originating through the lifeline group (association group 1) no matter which actual input was activated. So whenever I1 or I2 on the module gets activated the module will report them being activated as originating from the root device.
• Multi Channel Association is fully supported on the controller and additional Multi Channel Group associations are set by the user:
  Let's say the user activates I1. This will make the module report activation on the root device's (technically endpoint/instance 0) lifeline group, but also multicchannel encapsulated reports with source endpoint 1 and destination endpoint 0, adressed to node 1 (the controller). In this way the root device will become active since it serves a common reporting purpose for both endpoints.
  Similarly when I2 would be activated the root device would send a Binary Switch Report to node 1 reporting that the devices activated an output, but would additionally send a multi channel encapsulated Binary Switch report from endpoint 2 to endpoint 0, adressed to node 1 (the controller).

In conclusion, can you please share how the endpoints of a device can correctly be defined in your static configuration files? The guide about adding devices seems to lack this section entirely.
Please keep in mind that this mapping needs to maintain potential dynamically changing endpoints also.

[Fishwaldo]

(this was implemented in such a way according to Sigma's requirements for maximum backwards comnpatibility since the module can't tell whether a controller supports the classes in question or not):

ehhh. If you have a controller/gateway that doesn't support MultiChannel CC, then your device is never going to work with that gateway correctly....... same even goes for other devices (like double gang switches etc). I wouldnt call that maximum backwards compatibility - I'd say they are then "incompatible" in the ZWave world....

But - in real life, show me a gateway/controller that doesn't support MultiChannel... and I'll tentatively accept the argument.

in OZW, when a device supports MultiChannelAssociation CC, we handle like this:

1. if they didn't specify a Instance, we send the NodeID in the first part of the MultiChannelAssociationCmd_Set message before the 0x00 Marker
2. if they did specify a instance, then we send the NodeID and Instance after the 0x00 marker.
   (see https://github.com/OpenZWave/open-zwave/blob/master/cpp/src/command_classes/MultiInstanceAssociation.cpp#L375)

So it appears that Qubino devices only respect option 2? (even though we set the Assoications using the new "MultiChannelAssoication" CC?)

In conclusion, can you please share how the endpoints of a device can correctly be defined in your static configuration files? The guide about adding devices seems to lack this section entirely.
Please keep in mind that this mapping needs to maintain potential dynamically changing endpoints also.

We do dynamic discovery of endpoints (dynamic, static, even handle different CC's on different endpoints) so as long as the MultiChannelCapabilityReport from the devices is correct, it will work.

The mappings option was added as some (older) devices had a off by 1 bug, and we generally don't document these types of "workarounds" as they are seldom needed with newer devices.

finally, if I come across as a bit harsh, its not my intent. I take the approach with OZW to hide all the "device quirks" behind a common interface, so applications don't need to know anything about the device itself other than these are the "value's" reported by the device. With Qubino taking a different approach to how the send the MultiChannel reports (or at least how to set it up) means I have to add "another" workaround in OZW to make these devices work the "same" as other devices from say Aeotec, Fibaro etc.

I've just added a new Configuration option - ForceInstances that will always ensure that a Instance is set on a the ControllerNode. Please add <CommandClass id="142" ForceInstances="true" /> to a config file affected by this and let me know how it goes.

[Fishwaldo]

Closing this also.