Number Temp_Bad_soll "Temperatur Bad [%.1f °C]" <temperature> (gHeizung) ["Heizungen"] {channel="zwave:device:78e36f13:node22:thermostat_setpoint_heating"}
While it’s not hurting anything, you don’t need the postUpdate in your rule. You can delete it.
I see it’s a zwave device. Once you verify the rule is executing, you can look in opebhab.log to see what the zwave binding is doing with the command. If you need more information about what zwave is doing, you can put the zwave binding into debug mode.
The problem was a variable declaration (for another rule) I put in between two rules sections instead of putting it at the very beginning of the rules file.
To send the commands more slowly, you can use Thread::sleep()
Do you really need to postUpdate the items? They should get the new value from the bus.
rule "Heizungen morgens an"
when
Time cron "0 30 5 ? * MON-FRI *" or
Time cron "0 0 8 ? * SUN,SAT *"
then
Temp_Bad_soll.sendCommand(28)
Thread.sleep(250)
Temp_EZ_soll.sendCommand(24)
Thread.sleep(250)
Temp_WZ_soll.sendCommand(22)
// Temp_Bad_soll.postUpdate(28)
// Temp_EZ_soll.postUpdate(24)
// Temp_WZ_soll.postUpdate(22)
end
If the items do not update properly (but the actuators do), you can simply add , autoupdate="true" to the binding definition of the item (right before the closing curly bracket) e.g.
Number Temp_Bad_soll "Temperatur Bad [%.1f °C]" <temperature> (gHeizung) ["Heizungen"] {channel="zwave:device:78e36f13:node22:thermostat_setpoint_heating", autoupdate="true"}
I’m not sure whether it began with the changes (Thread.sleep, deleted all postUpdates), but my Visual Studio Code Editor reported an error and in the log file now I find the following:
2018-01-22 20:14:50.131 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'auto_heizung.rules’
2018-01-22 20:14:50.157 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model ‘auto_heizung.rules’ is either empty or cannot be parsed correctly!
2018-01-22 20:14:50.387 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘auto_heizung.rules’
When editing the file through samba share, this is normal behavior (although confusing).
The file is not readable for a short moment or something like that (maybe locked from samba, I don’t know the exact reason) and therefor can’t be parsed… but after some fractions of a second, the file is loaded successfully
I took out all the .postUpdate() tasks and observed, that the temperature setpoints - after changing them by cronjob or manually - often jumped back to their previous values.
Now, after reinserting .postUpdate()s after .sendCommand()s it seems that temperature setpoint controlling runs more stable and reliable.
@c_nagel I’m not sure what it means, and why there would be some many log entries. What model of Z-Wave thermostats do you have? Maybe in the device config there’s a way to disable this report.
@chris This line is using INFO level to log the message. Is there a reason for not making it DEBUG. Looks like the functionality for this CC is not implemented in the dev version.
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.