[SOLVED] Rule doesn't work

Hello Community,

I wrote a simple rule to change heating setpoint (here: “set setpoint to 28 °C at 5:30 am every week day!”) depending on a cron expression:

rule "Heizung Bad morgens"

when
     Time cron "0 30 5 ? * MON-FRI *"
then
     Temp_Bad_soll.sendCommand(28)
     Temp_Bad_soll.postUpdate(28)
end

But it doesn’t work. Any suggestions? Thanks in advance!
Regards
Christoph

The cron syntax looks right, so the rule should be executing. Just FYI, I find this tool handy for dealing with cron expressions.

It’s always a good idea to put log statements in the rule, so that you can verify in openhab.log it is executing. See here.

Can you post your item definition for Temp_Bad_soll? That might help shed some light on what’s happening.

Hi,

the item definition:

Number Temp_Bad_soll "Temperatur Bad [%.1f °C]" <temperature> (gHeizung) ["Heizungen"] {channel="zwave:device:78e36f13:node22:thermostat_setpoint_heating"}

I’m going to try that logging issue … :cold_sweat:

Ok, that item definition looks ok.

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.

I would suggest not to use the question mark in the cron expression

Time cron "0 30 5 * * MON-FRI" 

should work. (the year is optional)

Curious why you say that. I thought a question mark was valid. Admittedly, I’ve only ever used a question mark in the day-of-week position.

Rule is working fine now! :+1:

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.

Thanks to you both for your help!

Yes, the question mark is correct at the position, but sometimes openHAB does strange things…

Just another question:

This morning only the first temperature setpoint (Temp_Bad_soll) was changed. The other two still had the value from last night.

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)
	Temp_Bad_soll.postUpdate(28)
	Temp_EZ_soll.sendCommand(24)
	Temp_EZ_soll.postUpdate(24)
	Temp_WZ_soll.sendCommand(22)
	Temp_WZ_soll.postUpdate(22)
end

This time I have no variable declarations in the rules file. :relieved:

Any ideas about the reason?
Thanks!

Maybe the bus was busy :slight_smile:

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"}

OK, good idea I’m going to try Thread.sleep.

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’

What does this mean?

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 :slight_smile:

Just a short feedback:

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. :thinking:

Correction:
Still the same phenomenon: temperature setpoint values switch back sponaneously to previous values … :face_with_raised_eyebrow:

In the openhab.log file I found “millions” of these entries:

(Nodes 21 to 23 are the Z-Wave thermostats.)

What does this mean? Could this be the reason for the above mentioned temperatur setpoint problem?

@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.

No - I think there’s a PR for this, but I don’t really like the functionality being here as it mixes the different layers (application and transport).

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?

@mhilbush

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! :+1: