I’ve successfully included the relay, but don’t receive any information from the temperature sensor.
What I’ve done:
Before I included the relay, I’ve pluged the temperature sensor in the relay.
The inclusion worked fine with OpenHab 2.5 (final).
Within OpenHab I can see two channels for the temperature (sensor_temperature3 and sensor_temperature4), but both sensors don’t send any information.
Configration Parameters:
1: bi-stable switch type
2: NO (normaly open)
3: NO (normaly open)
10: ALL ON active, ALL OFF active
11: 0
12: 0
15: Seconds selected
30: Module saves its state before power failure
40: 10
42: 300
63: 0V
100: Endpoint, l2 disabled
101: Endpoint, l3 disabled
110: 32536
120: 5
Questions:
Why are there two channels for the temperature? Which is the “right” one?
What do I have to do, to get the temperature from the temperature sensor?
Note: I contacted already qubino and told them the story and this is the response from their side:
“Thank you very much for reaching out to us,
I check the tests done with our 1 Relay with the temperature probe installed with the openHAB 2.4 and see that it had a note for that.
Note: The gateway configures a MC lifeline, using MC_ASSOCIATION_SET(groupId=1, multichannelnodeid=1, endpointid=1). The temperature is sent MC encapsulated. The web GUI widget probably expects a non-MC encapsulated temperature sensor report .
Which means that our device works properly and the gateway set it properly too, but the widgets to report the received data are set wrong. We sent our findings to the gateway producers, but looks like they didn’t fix this yet.”
For me this sounds like their could be a bug in OpenHAB? Any chance I get the temperature sensor to work? Thank you and merry X-MAS.
Now while I doubt they’ve contacted openHAB, you can help finding out if they’re right and if so ensure this is properly fixed:
Please reproduce what Qubino did with your OH and device while taking zwave debug logs.
Then open either a Github issue to openhab-addons or directly get a login from @chris for his website and open a ticket there.
PS: I recall you need to ex- and re-include the device after adding the sensor. Have you also removed the zwave thing and .xml for this device before including again ?
The binding should use the MC_ASSOCIATION, so this should be correct. If you have a log of this configuration then I can take a look, but it needs the device to be reinitialised.
I did have some conversations with them a few months back, but nothing recent (I forget when this was now). Maybe I’ll check my spam filter - just in case.
Sorry for being late, but I couldn’t imagine that you are that fast in responding. Thank you.
I switched into the debug mode, excluded the qubino node (node9) and initalized the node after that (node10).
Here are the openhab logs. I hope this helps you. Thank in advance.
PS: Since I’m a new user, I’m not allowed to attach the file.
Just another note:
Looking at the logs, there seem data to be send. However, it’s not being displayed to the two temperature channels (why are there two anyways)?
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.
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:
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]
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.
@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).
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.
