LC-13 Living Connect Z Thermostats

[c_nagel (Christoph Nagel)]

Hello Community,

I’m using a Raspberry Pi 3 B with OH2 and a ZME_UZB1 Stick.
The problem I want to report occurs with all of the 3 LC-13 Living Connect Z Thermostats.

When the temperature setpoint was changed (independetly from manual or rule based) quite often (not always) the new setpoint value switches back to its previous value after some minutes (the log file says something like “the setpoint changed from [new value] to [previous value]”). If this occurs I have to switch the setpoint manually to the “new” value and if I’m lucky the new value does not switch back again.

In HabminUI I find the following (in German) properties of the thermostats:

Hersteller 0002 Danfoss
Typ-Kennzeichen 0005:0004
Firmeware-Version 1.1
Basisklasse ROUTING_SLAVE
Generische Klasse THERMOSTAT
Spezifische Klasse SETPOINT_THERMOSTAT
Sicherheit verwenden ?
Routing (check mark)
Lauschen X
Häufiges lauschen X
Beaming (check mark)
Letzter Aufwachzeitpunkt Monday, January 29th 2018, 10:54:38 3 minutes ago
Nachbarn 2 nodes <=> 1, 9

Besides this I find “millions” of this kind of entries in the events.log file:

2018-01-25 06:36:36.168 [INFO ] [veClimateControlScheduleCommandClass] - NODE 22 reported: Override type: NO_OVERRIDE, ScheduleState: [UNUSED]
2018-01-25 06:37:19.074 [INFO ] [veClimateControlScheduleCommandClass] - NODE 21 reported: Override type: NO_OVERRIDE, ScheduleState: [UNUSED]
2018-01-25 06:40:41.165 [INFO ] [veClimateControlScheduleCommandClass] - NODE 23 reported: Override type: NO_OVERRIDE, ScheduleState: [UNUSED]

(Nodes 21 to 23 are the thermostats.)

Does anybody have the same experiences with this thermostat model … and has even a solution?
What should I to with these “overrides”?

See: [SOLVED] Rule doesn't work

Thanks!

[psixilambda (Alexander Elsing)]

I have the same Thermostats in use and below Rule to change Thermostat setpoints. So no *.update in the rule.

I remember some flipping of values at first but I attributet this to the wakeup interval of the thermostats. When I remember correctly the individual setpoint of the thermostat only shows the new value (sendCommand(X) ) after the thermostat passed its wakeup interval. I can not try this now but after the sendCommand I could wait for 10 min (or whatever your wakeup interval is) and then all setpoints are correct, not before.

When I manually wakeup the thermostat after the sendCommand execution by pressing the middle button I can watch the thermostat change to the new value immediatly and this is representet in the Openhab UI as well.

I will update this when I am able to check this tonight.

rule "Heizung Erdgeschoss"
when
    Item EG_Wohnbereich_Solltemperatur changed or
    Item EG_Wohnbereich_Absenktemperatur changed or
    Item EG_Wohnbereich_Heizungsmodus changed
then
    // Heizungsmodus EG Absenkung: 0="Off", 1="On", 2="Automatik"
    if (EG_Wohnbereich_Heizungsmodus.state == 0) {
        // alle Thermostate auf Solltemperatur
        Group_Wohnbereich_Setpoint.members.forEach[ i | i.sendCommand(EG_Wohnbereich_Solltemperatur.state as DecimalType)]
    } else if (EG_Wohnbereich_Heizungsmodus.state == 1) {
    // alle Thermostate auf Absenktemperatur
      Group_Wohnbereich_Setpoint.members.forEach[ i | i.sendCommand(EG_Wohnbereich_Absenktemperatur.state as DecimalType)]
    } else if (EG_Wohnbereich_Heizungsmodus.state == 2) {
    // TODO Automatik
    } else {
    // sollte nicht vorkommen
    }
end

[c_nagel (Christoph Nagel)]

Thanks for your reply.
Could you check your settings already?
Can you please check your openhab.log file if you also have all these override entries?

[psixilambda (Alexander Elsing)]

I just checked with this simple rule (the thermostat I tested on is node 22 as well :

rule "Testing"
when
   Item VT_Testing_Rules changed
then
    ThermostatDGRechts_SetpointHeating.sendCommand(28)
	logInfo("ThermostatTEST", "Changed DG to 28")
end

The setpoint value displayed in PaperUI immediatly changed to the desired 28. After the next wakeup interval passes (in my case 300s) I get the value on the thermostat.

2018-01-31 12:25:44.396 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent

I used the AEON Zwave Stick. Maybe there is something wrong with your zwave stick send queue? Sorry couldn’t help more.

regarding the Overrides Chris explained that it is just information in below thread:

Z-Wave: Override type: NO_OVERRIDE, ScheduleState: [UNUSED]

This is just information. Possibly it should be a debug message, but it must means that the device has sent this report - it’s not processed by the binding and is logged for information.

[Jonas88 (Jonas)]

how to get rid of that message?
i tried to:

log:set WARN veClimateControlScheduleCommandClass

in Karaf but it did not work

[chris (Chris Jackson)]

@Jonas88

log:set WARN veClimateControlScheduleCommandClass

The the full class name - org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveClimateControlScheduleCommandClass

[Jonas88 (Jonas)]

hi!

thank you!
How did you find that name?
(Maybe i need this again in the future)

[chris (Chris Jackson)]

@Jonas88

How did you find that name?

I had a look in the sourcecode. Normally, it would also be printed in the log, but as it’s quite long, and the logfile is configured to only log the last X characters, it got truncated.

Since I know the sourcecode, I know where to look, but unfortunately there’s no universal answer that I can give you for future - sorry.