Not getting temperature from ZMNHAD / ZMNHEA1 (qubino)

Sorry - I missed this. I’ve been very busy over the past few weeks certifying a ZigBee system…

First point is the association seems to be set correctly -:

This is using the MC Association command, and it’s reading it back and it confirms it is set.

As you point out, there are temperature readings in the file -:

This one is on endpoint 0 (the root endpoint) and there is no channel associated with this. This is polled - probably during initialisation, and the device should not report this channel since it should only report on MC (so not endpoint 0).

This is on endpoint 2 - again, there is no database channel configured for this. The channel has been configured on endpoint 3.

I don’t know if this device changes its endpoint number, or if the database is just wrong, or if you have a different version from what is in the database, but that is why it’s not working and I guess we need to understand which one of these points is the reason why the database doesn’t tie up with your device.

Thanks for your comment.
As a understood the temperature sensor is bind to endpoint 2, but the configuration says it’s bind to endpoint 3.
What makes me wonder is, that there are already two channels for the temperature (endpoint 3 and endpoint 4). Why is that and what can I do to change to endpoint 2?

I’m afraid I have no idea - I’m not familiar with the device. We need to know if this is just your device that’s different to others, or if the device dynamically changes the endpoint depending on some configuration during the inclusion (since it can’t change after inclusion). Either way, the device is sending endpoint 2 for the temperature sensor on your device - that’s clear.

Ok. I’ll contact qubino to get more information.
Two questions:

  1. Why is there is temperature endpoint 4, if it should be always endpoint 3?
  2. Can I manually change the configuration locally on my side to change it to endpoint 2?
    Thank you.

I don’t know. As I said it could be that different devices have shown up with different configurations as the device changes its configuration, or it could be that someone has entered incorrect data into the database. I can’t really answer this - sorry.

No - not easily at least. This comes from the database.

Okay, no problem.
BTW: In this thread - also qubino (Getting temperature reading from ZMNHDD Flush Dimmer Plus from Qubino) it looks like the temperature is also at endpoint 2. Maybe qubino changed it or the database is not up to date anymore.
As soon as I got more information from qubino I’ll share what the told me.

Maybe, but this is what we need to work out. If it’s wrong, then we change it. If it’s changed for different versions, then we need to act differently otherwise we fix it for you, and break it for others, and that’s also not good.

I’m having similar issues with two Qubino flush devices (I have already posted in the thread mentioned by Timo above).
A Flush dimmer ZMNHDD, and a Flush relay ZMNHND.
I’ve done some more experiments with both of these since posting in the other thread.
If I configure them to be polled (i.e. no unsolicited reports), they both work fine - the temperature sensor_temperature channel/item are updated correctly.
If I configure them to send unsolicited updates based on temperature change, then it does not work.

The difference for both devices is the endpoint that is sent in the message:

  1. For the polled response the endpoint is ‘0’ and there is a following ‘Updating channel…’ message in the log and the sensor_temperature channel/item gets updated.
2020-01-13 18:38:22.447 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 29: Received COMMAND_CLASS_SENSOR_MULTILEVEL V7 SENSOR_MULTILEVEL_REPORT
2020-01-13 18:38:22.448 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 29: Sensor Type = Temperature(1), Scale = 0
2020-01-13 18:38:22.449 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 29: Sensor Value = 22.4
2020-01-13 18:38:22.450 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2020-01-13 18:38:22.451 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=22.4
2020-01-13 18:38:22.453 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Updating channel state zwave:device:1139f694:node29:sensor_temperature to 22.4 °C [QuantityType]
  1. For the unsolicited message the endpoint is ‘2’ and there is no subsequent ‘Updating channel…’ entry in the log and the sensor_temperature channel/item does NOT get updated.
2020-01-13 21:55:40.007 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Incoming command class COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 2
2020-01-13 21:55:40.008 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: SECURITY not supported
2020-01-13 21:55:40.009 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 29: Received COMMAND_CLASS_SENSOR_MULTILEVEL V7 SENSOR_MULTILEVEL_REPORT
2020-01-13 21:55:40.010 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 29: Sensor Type = Temperature(1), Scale = 0
2020-01-13 21:55:40.011 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 29: Sensor Value = 23.7
2020-01-13 21:55:40.012 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2020-01-13 21:55:40.013 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got a value event from Z-Wave network, endpoint=2, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=23.7
2020-01-13 21:55:40.014 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 29: Commands processed 1.
2020-01-13 21:55:40.015 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 29: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@100b667.

So, the crux of the problem does appear to involve the endpoint. There are no Associations set on either device.

Hi again,

@chris: I got feedback from qubino which explains why there are currently two channels (endpoint 3 and endpoint 4) for the temperature and why I would need the temperature at endpoint 2 (I don’t use l2 and l3).

Hello Timo,

Our relay devices have multiple configurations. In their basic configurations, the majority of Qubino devices are single channel. If the user connects a temperature sensor or enables additional inputs (usually by writing a suitable value into parameters 100, 101, 102) and performs a reinclusion, the devices become multi channel (this can be recognized by the gateway, by checking for CC_MULTI_CHANNEL during inclusion).

​In the case of Flush 1 Relay we have the following configurations:

Default configuration (no temperature sensor, no additional inputs enabled)

Temperature sensor connected (device becomes multi channel, temperature reports are sent from endpoint2, if multi channel lifeline is enabled)

I2 enabled via parameter 100, temperature sensor connected and reinclusion is performed (device becomes multi channel, temperature is sent from endpoint3)

I2 and I3 enabled via parameters 100 and 101, temeprature sensor connected and reinclusion is performed (device becomes multi channel, temperature is sent from endpoint4)

As you can see, the source endpoint, from which the temperature is sent, depends on the number of additional inputs. We would be happy to explain all the integration issues to Chris, if he’ll contact us.

I hope I was able to help you, if you have any additional questions please don’t hesitate to ask.

Best regards,
Igor, Technical support
(Ticketnumber 4557)

IMHO a quick workaround would be to add endpoint 2 for the temperature sensor in the database and explain when which channel is supposed to work.
The “better” solution is propably to change the handling to check the multichannel inclusion and have just one channel which is internally routing to the right endpoint (I have no idea if thats a big issue or not).

What do you think?

Hi,
This is what I expected to be the case - the device has different configurations depending on how it’s included. Qubino seam to like to do this…

The only option at the moment is to add the extra channel to the database.

When OH2 was first released (well, first conceived) there was no way to have dynamic channels, so everything had to be managed through the XML. The database was used to do this - the binding writes the configuration, the database reads this and creates the definition for OH which is then read back into OH when the binding starts.

Since then, we have the ability to create channels dynamically - this is what I do in the ZigBee binding, but it requires a major rewrite of the binding. It’s on my todo list (has been there about 2 years!), but it will likely be later in the year before this is ready (a binding rewrite is what I’m working on now, but it really needs to start from scratch).

So, I think for now, if you can add the channel then please go ahead

Hi,
I hope I did everything right. Just added the channel to the database.
What do I have todo as soon as somebody accepts the change request? Just exclude and include the device or do I have to update some component of openHAB first (running openhab 2.5)?
Thank you.

Just delete the thing, press the discovery button and add the thing again. There’s no need to exclude the device. This allows the binding to pick up the latest thing configuration which OH otherwise doesn’t update as it’s stored in the JSON database.

@TimoT @chris
How easy would it be to add that same fix for the Qubino ZMNHDD and ZMNHND?

I’m happy to try myself if you can give me some pointers, or is there a guide/tutorial anywhere? How do I test my changes locally and then commit them to the main build?

From what I can see the channels are already available in the database.
You need to set the proper config parameter and after connecting the sensor exclude and re-include your devices.

@sihui Thanks for the information.

Is that a recent change? Could it have been updated some time after I had originally included the devices?

Rather than excluding and including the devices on the Z-Wave network, would deleting the relevant Things and re-discovering them be adequate?

UPDATE: I’ve just taken a look at the database entry for ZMNHDD on Chris’ site. As far as I can tell there is no SENSOR_MULTILEVEL capability for Endpoint 2 (only for Endpoint 0).

Acccording to the docs it should be endpoint 4:

End point 4:
Group 1: Lifeline group, 0 nodes allowed.
Group 2: multilevel sensor report (triggered at change of
temperature sensor) up to 16 nodes

As I don’t have this device and can’t test it I am not able to make the database changes, sorry.

The change was accepted (however, it is already declarded as deprecated which I don’t understand).
I just deleted the thing and added it again. However, there is still no change in the thing. It doesn’t seem to use the latest thing configuration from the database. Does somebody know what I missed?

Have a look here: https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide
You register for an account, make the change and request the approval. That’s pretty much it :slight_smile:

During your last database change you’ve added/edited the sensor_mulitlevel channel for endpoint 0.
Is that really what you want?

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/210

Not quite. It took me a little while to work out what’s up here. I think the sensor_temperature channel in endpoint 0 was always there.

No channels were added - but a new command class has been added to endpoint 1, and in the config for that command class the channel has been added (Which won’t do anything).

I’ll remove this as it’s presumably wrong?