Yep, you’re right. The PR looks the same (or at least very similar) to what’s in master.
In any event, for what’s in master or the PR against dev, should it really be logging the REPORT at INFO level?
I’m using LC-13 Living Connect Z Thermostats.
I find the following Properties (in German) in the Habmin UI:
Does this help?
It looks like there’s no way to configure/disable that. You may need to live with all that noise in you openhab.log.
I suspect, however, that it’s unrelated to why you see odd behavior of the setpoint. I know there are others on the forum with that device, so maybe you should post another topic with a title that’s more reflective of the issue you’re seeing.
Thank you! 
@chris Hi Chris, I still observe this spontaneous switching back of the new thermostat’s setpoint value to the previous value. Do you have any idea? Is this a problem with the wake up interval of the thermostats, which is set to 300 seconds? As @psixilambda mentioned in the other thread (LC-13 Living Connect Z Thermostats) the new setpoint occurs at the thermostat’s display immediately after waking it up manually. So, my idea is that the new setpoint value might not be preserved by the bus long enough until the thermostat wakes up automatically after 300 seconds.
Regards, Christoph
The binding will queue the request until the device wakes up - no matter how long this takes. Most battery devices in ZWave wake up after 1 hour, or 1 day, so 5 minutes isn’t an issue. In any case, there is simply no time relationship in the queue - it is queued until it is sent.
It shouldn’t be an issue - this is how these devices are intended to operate.
Without seeing a debug log it’s just speculation as to what the possible issue is. I’d recommend putting the binding into debug mode, getting the log, then viewing it with the online viewer to see what is happening.
How can I do this? Is there a tutorial for this?
You can use the log:set debug org.openhab.binding.zwave command…
Hi
I have a rally simple rule. I want my fan to run at 90% for some time when the bath light received command on (or changed to).
But somehow I mangaged, that this doesn´t work. The fan pulls up to 90% but it doesn´t come back to the 25%.
Whad did I wrong?
var Timer timer = null
rule "WC Luefter"
when
Item Licht_Buero received command ON
then
sendCommand(Luefterstufe_SOLL, 90)
timer = createTimer(now.plusSeconds(3) [
sendCommand(Luefterstufe_SOLL, 25)
timer = null // reset the timer
])
end
Later I want the fan to run at 90% (or max. controlled by an other item) via athroom light on, or toilet withdifferent timing. In the bathroom only if the light is on longor for xx minutes.
But in the first step, I would be really happy if this works.
(Item Lich_buero ist just for testing)
THX
A couple suggestions.
- use item method instead of action to send command
- syntax errors on createTimer call
- check for timer equal to null before creating timer
You might want to consider installing vscode with the openHAB extension. It will help identify syntax errors.
var Timer timer = null
rule "WC Luefter"
when
Item Licht_Buero received command ON
then
Luefterstufe_SOLL.sendCommand(90)
if (timer === null) {
timer = createTimer(now.plusSeconds(3)) [ |
Luefterstufe_SOLL.sendCommand(25)
timer = null // reset the timer
]
}
end
Hello Mark
thank you for your reply.
I already use VS code 
What is the item instead of action method.
I see the little differences, and now it works fine.
Thank you very much.
Best
Thank you.
One more question:
If i want that the fan only rises to 90% only when the light is on longer than 10 Minutes, how would this look like?
Is this a separate timer rule for the bath light?
THX
Daniel
var Timer myTimer = null
rule "WC Luefter"
when
Item Licht_Buero received command
then
if (receivedCommand == ON) {
if (myTimer === null) {
myTimer = createTimer(now.plusMinutes(10)) [ |
Luefterstufe_SOLL.sendCommand(90)
myTimer = null // reset the timer
]
}
}
else {
myTimer.cancel
}
end
But this would only set the fan to 90%, so, you would need another timer to reset the fan to 25%. I guess some time after the light turned off, so you would create this timer in the else part of the rule.
Thank you Udo
As you mentioned, it would be important that the fan sets back to xx% after some time.
Have to look that up, maybe I find something in other rule examples.
THX
Daniel
Simply use a second timer, according the first timer, and take it into the else part of the rule.
Hi @chris,
thanks for your support so far. Unfortunately I had no time to care for further logging and debugging issues.
Now, I think I just made it to figure out how to use the Karaf console, and set the binding into debug mode with the command you mentioned. What do you think, how long should I wait until I can put the log file into your viewer? And which log file are you interested in: events.log or openhab.log?
So long!
Christoph
Hi @chris,
this is a screenshot from your viewer filtered for one thermostat (node 21):
The previous setpoint was 26 °C. The new setpoint shall be 22 °C (19:20:21 and 19:20:22 respectively).
At 19:20:58 and 19:20:59 respectively from “somewhere” the previous setpoint (26 °C) is reactivated.
Then I changed temperature via my sitemap again to 22 °C; in the next screenshot you’ll find the log entries some minutes later with a successful change of the setpoint:
I’d really appreciate if you could check this for me and if you’d have a solution.
Thanks a lot in advance
Christoph
Please can you provide the log and I’ll take a look.
Thanks.