Qubino Flush Shutter (ZMNHCD) does no longer report Temperature Values

Setup, Configuration and Use Scripts & Rules
, , , ,
1

Dear Community,

Please see my setup at the end.

From the beginning of setting up a smart home, I face an issue with the Qubino Flush Shutter (ZMNHCD). I have 13 of them and they work well in regard to controlling the shutter position.
I have also attached a temperature sensor to all of them. It is not the original expensive one, but I have re-built it according to a friend’s advice.
So, I am able to see the temperature in the different rooms. But sometimes, a device just stops to send the temperature value. When I “Reinitialize the device” via the OH UI, it takes some time (probably until the diff threshold is reached) and the device sends the temperature values again.
Best way would be to solve the root cause. Do you have any idea what I have to check for the problem?

As a workaround, I implemented a functionality to see when a device stops to send the temperature value. In fact, it is just a timer which (re-)starts when a new temp value in the corresponding item was set. When the timer ends, it just sends an email, so that I know I have to do something.
Now, I wanted to add this “Reinitialize the device” UI functionality in the rule. But I didn’t find a way how to achieve this. Does anyone of you know how I can implement that UI functionality in a rule?
Just sending a “REFRESH” command does not work. I hoped that in this RefreshType there is also a value for this re-initialize, but according to what I found in the internet, there is only this one REFRESH value.

In the logfile, I saw that there is a configuration update action_reinit sent to the device. Can I send this in a rule as a workaround?

Unfortunately, I do not have the logfiles from when the device stopped sending the temp value as this was some weeks ago already. But as soon as the problem appears again, I can attach it here.

For the REFRESH command, I attached
openhab Node 6 REFRESH.log (25.5 KB)
starting at
2023-09-10 10:02:13.234 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Command received zwave:device:3fb0a8315c:node6:sensor_temperature → REFRESH [RefreshType]

For the “Reinitialize the device”, I attached (remove .txt extension and unzip it)
openhab re-initialize Node 5.zip.txt (211.6 KB)
starting at
2023-09-10 11:03:57.646 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Configuration update received

However, I am not sure if you can see anything in those logfiles.

Thank you for your support in advance!

Best regards,

Chris

Here is my configuration:

I use openHABian 3.4.1 on a Raspberry Pi 4

Qubino values:

zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_SWITCH_MULTILEVEL
zwave_neighbours 1,5,16,23,24
modelId ZMNHCD
zwave_plus_devicetype NODE_TYPE_ZWAVEPLUS_NODE
zwave_version 75.0
versionMin 4.1
defaultAssociations 1
vendor Goap
zwave_routing true
zwave_beaming true
zwave_secure false
zwave_class_specific SPECIFIC_TYPE_CLASS_C_MOTOR_CONTROL
zwave_devicetype 3
zwave_frequent false
zwave_listening true
manufacturerId 0159
manufacturerRef 0003:0052
dbReference 213
zwave_deviceid 82
zwave_nodeid 6
zwave_lastheal 2023-09-09T23:19:47Z
zwave_plus_roletype ROLE_TYPE_SLAVE_ALWAYS_ON
zwave_manufacturer 345

Qubino setting for parameter 120: Digital temperature sensor reporting 2 (changing to 1 after the issues occurred does not help)

2

I do not have the device, but with the threshold param 120 my guess is that if the temperature does not change there will not be a reading. Are you wanting a reading regardless if it has changed or not?

The refresh log shows the temperature “GET” is cancelled. Oddly the device seems to respond three times to the Switch “GET”, almost like it is not getting the acknowledgment that command is complete. That might be the cause of the cancellation (Still working on the last command). I’m not sure how to solve that. You can use the debug log viewer here Z-Wave Log Viewer (opensmarthouse.org) to see that.

From the longer re-int log, it does seem like the temperatures are reported pretty frequently. I’m a little concerned about the amount of traffic, but response times seem mostly okay. Nodes 5, 17 and 18 are a little slow.

Personally I don’t know how to reinitialize in a rule and I would be concerned about overwhelming the zwave network.

3

Thanks for the quick reply!

If there is no change, I do not need an update of the temperature. So regular reporting is not necessary.
But it is not because of the threshold. I have increased the temperature with a hair dryer, but the device still did not send.

I know the website and have used it. But how do I see that a command has been cancelled?

The devices are supposed to send a temperature update when the temperature has changed by 0.2°. I can also set the threshold a little higher, so that it is not sent so often. But this should not affect the actual problem, right?

The re-init should only be done when there are problems, so maybe once every few days. I don’t think this should have a big impact on the network either.

4

Two ways. 1) Using the viewer note the time of the TX (Get multisensor) and see if there is a state update of temp within 5 seconds (That is the timeout). 2) You can also look at the log in notepad (or text editor) and search for “Cancelled”.

One idea to get at the boundaries of the problem is to do the Refresh test on each of the 13 devices and see if they all have the problem or just one or two. However, have the debug run for at least 20+ seconds. The binding should try three times. I could not tell from the snippet above if a new TX was sent. “GET” is a low priority, so if the network is busy it will be delayed.

This could also be contributing?

Do you have a chart set up with the temperature reading(s)? Overtime (without the Refresh) it should show increments of 0.2. Again maybe just one or two device might be problematic or there might be some pattern.

5

Thank you for the explanation regarding the canceled transaction!

I have now tested the REFRESH on two devices that are currently working (see diagrams at the end of the post). Are these the diagrams you wanted to see?
Seems they generally don’t respond to the refresh command, as in my tests (two nodes, temp channel and blinds control channel used, passed as string and as value) the transaction was always cancelled.

Of course it could be due to the cheap china temperature sensors. That would mean I should order and install an original part, and then see if the problem occurs with that as well. Maybe I will do that when I order something for the smarthome again.

image
image1556×677 50.8 KB

image
image1576×674 48.7 KB

6

So probably the refresh is not going to work with your devices for some reason. However from the charts it seems the temperature is adjusted based on the threshold setting. Those charts should be able to catch when the updates stop and maybe provide a clue as to why.

7

If you want to just see a diagram when sending the temperature stops, here it is:

image
image1536×675 31.8 KB

This is before it stopped.
image
image1543×682 20.6 KB

At the left side, you see the last update, then it stayed the same for more than 14 hours. After the reinitialize of the device, it sends again the temp data.
The shutter functionality works fine all the time.

8

Unfortunately, as noted above, I do not know how to reinitialize a Thing in a rule. Maybe the master of all might know @rlkoshak ?

9

It depends on the rules language. At a high level you need to pull the ThingRegistry, get the Thing by it’s UID. Then you can setEnabled(false) followed by setEnabled(true) (probably with a delay inbetween.

I’m not sure if that’s what you mean by “reinitialize”. If not, you’ll have to delete the Thing and recreate it.

10

What I understand the OP is doing is using this “Reinitialize the Device” from the Zwave thing UI page to get the attached temp sensor to send values again. The item “Refresh” command doesn’t seem to work with the temperature sensors OP is using, but after “reinitialize” it works for a time.

Five Lines of configured node

OP will have to contribute preferred rules language.

1 Like
11

As far as I understand, that’s something specific to the Zwave binding and not generic. Therefore it’s not exposed through the generic openHAB APIs. You’d have to reverse engineer what HTTP calls are made when you click on that link and reproduce those in a rule using the sendHttpXRequest Actions or the HTTP binding.

2 Likes
12

@apella12 is right about how it works again.

@rlkoshak: Next time it occurs, I can also check if disabling and enabling the thing also works. Then I can use this approach.
The way via an HTTP request is also a good idea.

Thank you all for your feedback!

13

Unfortunately, disabling and enabling the thing also does not work.
Even powering the device off and on again does not work.

Now I have to find out how I can see which HTTP call is sent when I press the re-initialize button in the GUI.

14

Just to finalize how I implemented the “Re-Initialize a Thing” workaround:

  1. install the exec binding
  2. add a Thing for this binding
    1. add “curl %2$s” as Command / Befehl
    2. activate Autorun in the Thing
    3. add Item at least for input string
  3. whitelist curl
    1. sudo nano /etc/openhab/misc/exec.whitelist
    2. add “curl %2$s” in a separate row
  4. get a token from your OH account
  5. set input string:
    '-u <OH_Token>: -X PUT --header "Content-Type: application/json" --header "Accept: application/json" -d "{action_reinit:true,node_id:<NodeID>}" "http://<OH_IP>:8080/rest/things/zwave:device:<zwave_device_ID>:node<NodeID>/config"'
    which executes the REST call

Maybe I can spend some time to investigate the root cause in the winter season.