HABmin2, no zwave option and trouble connecting to the controller

No - it’s the controller. If you’re getting timeouts to the controller, then that’s quite strange and might indicate something fundamentally wrong somewhere.

That is weird, indeed. If it is helpful I can provide you the zwave log both from the old binding and new binding, where it works well in the first one, and not so well in the second one. I just need to figure out how to put the zwave log in a separate file in the latest snapshot version.

I’m happy to take a look, but I doubt I’ll see much as it’s not possible to know why the controller is not responding (by it’s nature, there’s no response here).

I switched my installation to a Windows computer, this got rid of the node 255 commutation errors. I can send you the logs of all three systems. Do you have a better way of sending them than embedding them in the forum?

And by the way,I see a few messages when discovering some of my dimmers with embedded temperature sensors that SWITCH_MULTILEVEL is not supported. How do I go about getting this supported? I have this working with the 1.8 zwave binding for the same devices using the following string: zwave=“36:1:command=switch_multilevel”

Yes - you can email them to me. If you can’t find my address, then PM me…

Well, I guess this is just another strange feature of your system since this is clearly supported. Maybe you should post the exact message?

I think I might have misunderstood the log message:

2016-04-10 14:43:18.495 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 37: CommandClass SENSOR_MULTILEVEL (0x31) not implemented by endpoint 3, fallback to main node.

Still, I find no such channel for the device for any of the endpoints.

Well, firstly you told me it was SWITCH_MULTILEVEL - it’s not, it’s SENSOR_MULTILEVEL, and secondly you didn’t provide an error message, which is why I asked for it :wink:.

The message doesn’t say that SENSOR_MULTILEVEL isn’t supported. This means that it’s not supported by the specific endpoint. Without full information though, it’s hard to say why this message is showing up! I need to see the message received from the device, and I also need to know what the device actually is - it’s hard to second guess - sorry.

I sent you an email at cd-jackson. I hope this reaches you.

Got it - thanks. Can you tell me what the device actually is (ie node 37)?

It seems to be recorded correctly as Z-Wave Node 37: ZMNHDD Flush Dimmer Plus from Qubino

I need DEBUG logs - sorry.

Email sent, not sure how to get more debug than this :slight_smile:

I suddenly found this in the log, but still no reference to the sensor_multilevel in the thing configuration.

16:52:03.995 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 25 06 31 05 01 22 01 02 C0
16:52:03.996 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
16:52:03.996 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 25 06 31 05 01 22 01 02 C0
16:52:03.996 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 25 06 31 05 01 22 01 02 C0
16:52:03.996 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, payload=00 25 06 31 05 01 22 01 02
16:52:03.996 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 37: Application Command Request (ALIVE:DONE)
16:52:03.996 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 37: Incoming command class SENSOR_MULTILEVEL
16:52:03.996 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 37: Received Sensor Multi Level Request
16:52:03.996 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 37: Sensor Multi Level REPORT received
16:52:03.996 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 37: Sensor Type = Temperature(1), Scale = 0
16:52:03.996 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 37: Sensor Value = 25.8
16:52:03.996 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMultiLevelSensorValueEvent
16:52:03.996 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
16:52:03.996 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_MULTILEVEL, value = 25.8
16:52:03.996 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Config updated

The issue isn’t to do with the configuration. It’s saying that it received a message for endpoint 3, but from the scan, endpoint 3 doesn’t exist. I need to look into this more, but not right now…

The timeouts to node 255, at least the ones I looked at, are actually being sent to another device so this is also not too strange (it may not be correct as the device should respond of course, but at least it’s within the bounds of the protocol).

Okay, thanks, so nothing actually seems to be wrong? It is weird, because I have never had a device 255 before.

I guess the other point to note is that these Qubino devices do have temperature sensors, so maybe that’s what this is? Anyway, it does look like that’s what the device is sending, so I think the binding is doing the correct thing with the data (from a quick look only so far).

I know there is a temperature sensor, I just can’t understand how to access it if the thing has no sensor_multilevel channel?

By the way, thanks for bearing with me, I know take some effort to keep track of all existing and imaginary issues :slight_smile:

Thanks :slight_smile:

For information, I have an online log viewer here that might help visualise what’s going on.

Is there a way I can delete imaginary nodes such as 255?