2nd endpoint not exposed in Zwave blinding for Qubino Flush Shutter, release 2.1

Hi @chris, if you search in the log for node 39 you see the warnings and what happens if I try to move the blinds. You see as well my rules trying to recover for blinds not moving (my qubinos have a firmware bug, so I need to program around this), but nothing works. Typically this error shows:

2017-06-30 23:38:37.062 [INFO ] [.eclipse.smarthome.model.script.FILE] - --> CLOSE slates for Blinds_FF_LivingRoom_Side1_Lam
2017-06-30 23:38:37.070 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 39: Command received zwave:device:b11c1630:node39:switch_binary2 --> OFF
2017-06-30 23:38:37.074 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 39: No command converter set for command zwave:device:b11c1630:node39:switch_binary2 type OnOffType
2017-06-30 23:38:37.804 [INFO ] [.eclipse.smarthome.model.script.FILE] - --> OPEN slates for Blinds_FF_LivingRoom_Side1_Lam
2017-06-30 23:38:37.810 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 39: Command received zwave:device:b11c1630:node39:switch_binary2 --> ON
2017-06-30 23:38:37.811 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 39: No command converter set for command zwave:device:b11c1630:node39:switch_binary2 type OnOffType

I can’t see any problem in the startup phase, it seems to setup the corresponding command classes. something broken in my installation ?

I don’t really see any problem. I suspect the most likely issue is that you’ve done something wrong with creating the binding that you’ve created, so I’ll update the binding properly tomorrow and you can try that.

I am as well seeing frequent fails of nodes no longer communicating, which I didn’t have before. I have different nodes getting marked as failed in the controller. The system with by modified 2.1.0-snapshot.jar seems to be very unstable.

Let me know when I can wget the new 2.1.0-snapshot.jar, or will I be able to pull it via the paper UI ?

I’ve just updated the binding so try again with that version.

Oh - and make sure to delete the thing again so that it picks up the new database definition…

messages crossing, I’ll try it now. I wget the latest snapshot now.

running now with:
194 | Active | 80 | 2.1.0.201706302351 | ZWave Binding

SUCCESS !!!

So what I did was not correct with the JAR, it seems. Thanks for the new version, this is very good.

I still have failed nodes, I leave it running for some time and see if I can recover them without a rest. Problem is that it is not the same nodes failing all the time, it is different ones… hmmm… could this connected to the security updates ?

Well it seems now we have problems with the ZMNHCD with version S5. There are no 1st and 2nd endpoints in the binding now, the version seems 4 in the XML. I do not use additional endpoints it is only rollersutter, not blinds. However i cannot get values from the optional temperature sensors now. Using Zwave binding:

225 | Active   |  80 | 2.2.0.201706290942     | ZWave Binding

And, habmin and paperui sees the module as version:

ZMNHCD version S1

This is the same point that we are talking about - you are still running a version that has not yet had the fix - I will probably do an update tonight.

This binding hasn’t been changed. The one I changed was the development version.

My bad… I switched to development version:

226 | Active   |  80 | 2.1.0.201706302351     | ZWave Binding

Endpoints are back.But now i have two problems:

  1. As i see the database has 2 versions for ZMNHCD. Version up to 4.0, and version higher than 4.0. Although my modules are of version S5, habmin still sees them as “Version S1 for for version up to 4.0”.
  2. Temperature sensor still not updating the value, they still insist on showing the same values as it was working some versions ago.

Above you said your devices were version 4…

… so that sounds correct.

Is the data being received from the device, but isn’t changing, or is not not being received and you just see a persisted value?

My devices are version S5, so i guess they should get the device database “All After 4.1”. In XML it says:

 <version>4</version>

So i am not sure if openhab-habmin picks the correct database item.

Looking at the logs the device never sends the temperature. The values are coming from persistence. When i check out from domoticz software, it gets the values as expected. So i guess there’s nothing wrong with the devices.

You’re looking at the wrong information. What does HABmin or PaperUI say the version is.

Then you need to solve this problem first. I would guess that there’s a configuration value to set when the device sends the data? If the device isn’t sending the temperature, then the binding won’t display it. Polling should return the data as well of course, but without some data to look at I can’t do anything to help.

Paper UI and Habmin says:

ZMNHCD version S1 for version up to 4.0 

Sorry - in the attributes section it will show a bunch of information about the device - what does it say the firmware version is?

My devices don’t have temperature sensors added, so I can’t help here.

So you have the < 4.0 version - version 1.1 firmware. The binding is detecting this correctly.

Hi, this is the same as mine, it says on habmin 1.1 but in the XML it is 4.0.

That seems a bit unlikely, and from the XML you posted earlier, I can see it says 1.1.

        <applicationVersion>1.1</applicationVersion>