Danfoss Devolo Room Sensor: COMMAND_CLASS_SCHEDULE V1 unknown command 5

Tags: #<Tag:0x00007f74575531d8>

I have a Danfoss Room Thermostat (or better: a Devolo MT-2649).
You can set the setpoint temperature with up and down keys. If you manage to press the “LED Button” you can set a “timed heating period” for 1h up to 24h what is really a cool feature… BUT i can’t get openhab or the zwave binding to get this value.
This device doesn’t just send the plain new setpoint value and x hours later the former value again - it uses the command class schedule for sending so there is no change for the temperature setpoint channels in openhab.

Any idea how to get these values / value changes or how to make the device send the changes via default setpoint value?

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

This is the output when “setting the setpoint temperature PLUS set 2 hours heating time”:

2019-09-09 16:51:26.140 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 59: Application Command Request (ALIVE:DONE)

2019-09-09 16:51:26.142 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 59: resetResendCount initComplete=true isDead=false

2019-09-09 16:51:26.144 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 59: Incoming command class COMMAND_CLASS_SCHEDULE, endpoint 0

2019-09-09 16:51:26.146 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 59: SECURITY not supported

2019-09-09 16:51:26.147 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 59: Received COMMAND_CLASS_SCHEDULE V1 unknown command 5

2019-09-09 16:51:26.149 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 59: Commands processed 1.

2019-09-09 16:51:26.151 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 59: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@10e2cc7.

OK, let’s start with the basics.
What version of OpenHAB & Z-Wave binding?
That item was last updated last month which means you likely need 2.5M3 version of the binding. 2.5M2 may be new enough. I am not sure.

Hey Bruce, thanks for your fast response!

I’m using OpenHAB 2.5M3 with 2.5M3 binding.

I have been trying to update the database. removing obvious errors.
Does your manual show some configuration parameters that we may have missed? Sometimes finding the necessary information can be quite a challenge, especially on older devices.

What do you mean by configuration parameters?!

I‘m not sure what to expect here because there’s no channel for this (only setpoint heating and setpoint cooling).

I think when setting „scheduled heating“ with the led button there is another kind of message.

See Page 10 - command class SCHEDULE / SCHEDULE REPORT

I will need to look further after I get home this evening unless one of the other people get to look first.

I just added configuration command class SCHEDULE
The change will need to be reviewed and then it will be in the next binding version published.by @chris

Wow. Thank you for your effort.

So what can I expect from this? AFAIK there’s a „relative difference to actual setpoint“ and a „time“ …
Is this one or two channels?

Thank you very much. That’s really awesome!

Sorry to disappoint you, but I think the binding does not support that command class:

Just to understand this:

The binding receives the command class SCHEDULE but doesn’t know what to do with it?
Any idea how to get these commands as raw values as a string or sth. similar?

BTW: where and how could I find (or handle) this payload?

2019-09-09 16:51:26.151 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 59: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@10e2cc7.

Got the payload …

Receive Message = 01 1B 00 04 00 3B 15 53 05 01 00 FF 30 00 00 3F 3F 00 07 00 01 06 43 01 01 22 01 18 2E 
2019-09-10 10:42:56.393 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=59, callback=0, payload=00 3B 15 53 05 01 00 FF 30 00 00 3F 3F 00 07 00 01 06 43 01 01 22 01 18 
2019-09-10 10:42:56.397 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=59, callback=0, payload=00 3B 15 53 05 01 00 FF 30 00 00 3F 3F 00 07 00 01 06 43 01 01 22 01 18 

Findings:

payload=00 3B 15 53 05 01 00 FF 30 00 00 3F 3F 00 07 00 01 06 43 01 01 22 01 18

only three bytes are changing for this “schedule”:

  • 06 = this is the hours for how long the overwritten schedule shall be used… 06 = 6 hours
  • 01 18 = this is the setpoint times 10
    01 18 = 280 -> 28 deg
    00 C8 = 200 -> 20deg
    00 FF= 255 -> 25.5 deg

so maybe there’s someone with an idea how to process these in openhab? or maybe @chris could give me a hint how to get this message for further processing?

If you really wish to pursue this I recommend filing an issue on GitHub with a link to this thread.
I think this should be a lower priority than some other pressing issues.
Chris needs to get his development environment working with the new system so he is able to make binding changes.
I know of one pending change where users cannot use their devices (Doorbells and Sirens) with OpenHAB until changes are made.
Thank you for your patience.

I can really only point back at the statement I’ve already made (that @Bruce_Osborne referenced a few posts back). It’s not super easy to see how this can be incorporated into OH as there is no item time linked to schedules, and it’s not something that is regularly requested.

You could try and hack something together, but to implement this properly is quite a lot of work given we’d need to also look at how to integrate it to the OH core system.

1 Like

thanks for your response, @chris
how would i get this raw payload as it is for further processing?

Probably compiling the binding yourself with debugging turned on :wink:
Good luck with that since @chris the expert is not successful with his dev environment yet.

There’s no real way to do this other than to modify the binding and code up some sort of custom support.

I wondered about the binding just pushing something to the logs.

I picked up one of these room sensors so following with interest.