rule "Evening Lamp lighting Rules"
when
Item heating_timeofday changed to "LATEAFTERNOON" or
Item heating_timeofday changed to "EVENING" or
Item heating_timeofday changed to "LATEEVENING" or
Item lamp_light_check changed
then
var boolean lightState = true;
if (lamp_lighting_powermode.state == "Schedule" && (heating_timeofday.state == "LATEAFTERNOON" || heating_timeofday.state == "EVENING" || heating_timeofday.state == "LATEEVENING" ))
With 2.3 these worked fine, and I thought it was ok with 2.5.4 as well. But now I’m not so sure.
Some other threads I’ve seen that an item changed to “string” state is not working, or has never worked (which doesn’t make sense to me, since this rule, up until yesterday was.
I do have an if statement at the first line which does also check for those 3 string values, but that was just a bit of a safety net.
rule "ToD String"
when
Item heating_timeofday changed to "MORNING" or
Item heating_timeofday changed to "DAY" or
Item heating_timeofday changed to "LATEAFTERNOON" or
Item heating_timeofday changed to "EVENING" or
Item heating_timeofday changed to "LATEEVENING" or
Item heating_timeofday changed to "NIGHT" or
Item heating_timeofday changed to "BED"
then
logInfo("ToD Strings","Current ToD: " + heating_timeofday.state)
Notify_Info.postUpdate("ToD Strings: Current ToD: " + heating_timeofday.state)
end
rule "ToD No String"
when
Item heating_timeofday changed to MORNING or
Item heating_timeofday changed to DAY or
Item heating_timeofday changed to LATEAFTERNOON or
Item heating_timeofday changed to EVENING or
Item heating_timeofday changed to LATEEVENING or
Item heating_timeofday changed to NIGHT or
Item heating_timeofday changed to BED
then
logInfo("ToD No Strings","Current ToD: " + heating_timeofday.state)
Notify_Info.postUpdate("ToD No Strings: Current ToD: " + heating_timeofday.state)
end
good idea, so lets look forward waiting for results
not shure but i think you will have to write (at least i do it this way)
logInfo("ToD No Strings","Current ToD: " + heating_timeofday.state.toString)
Notify_Info.postUpdate("ToD No Strings: Current ToD: " + heating_timeofday.state.toString)
I would think there would be a risk here that the parser will go off and look for a system object or variable called DAY … and there might just be one, any kind of object.
So far as I know, the parser doesn’t actually “evaluate” these lines - you cannot do x+y or substitute a variable I’m sure. But clearly there are keywords like or and Item and spaces.
Item myString changed to one two
nope, has to be Item myString changed to "one two"
Item myString changed to from
nope, has to be Item myString changed to "from"
What I’m saying is that it is at least sometimes ambiguous without the quotes, and you should be using them. Behaviour may have changed, doesn’t mean it was correct before.
I did have a play with Item myString changed to ON
where we know ON is a predefined object of type OnOffType.
Sending “ON” to my Item does successfully trigger the rule. I don’t know if the parser just uses strings as found in the trigger line, or if it really looks up the ON object and gets its .toString method which happens to return “ON”, and so gives a match that way.
That could all go wrong if you have an object or variable e.g. DAY where the ..toString returns something else like “Tuesday”, I don’t know.
I can confirm that it is still working with Scripted Automation. I have at least one Rule that has that type of trigger:
@when("Item vTimeOfDay changed to 'BED'")
and it runs every bed time.
There is no need to wait. Open the Karaf console and smarthome:send heating_timeofday "DAY" to manually change the state of the heating_timeofday Item. Just remember to set it back to what it is supposed to be after you are done testing.
Unfortunately I can’t say if this is broken for Rules DSL.
2020-05-13 05:00:00.019 [INFO ] [e.smarthome.model.script.ToD Strings] - Current ToD: MORNING
2020-05-13 05:00:00.020 [INFO ] [marthome.model.script.ToD No Strings] - Current ToD: MORNING
So something else must have happened for the trigger to not take effect. But this is handy to know.
Maybe I’m making my rules files cover too much, there’s a risk with that, that any error, tends to take out the entire rule file. But means i can could technology together. ie everything that relates to my lamps is in a rule file LampLightingToD.rules
That should be apparent at load time though. If you watch openhab.log as you save the file you will see something along the lines of “loading model blah.rules”. If there is an error that takes out the whole file you will see that error right then. Once loaded, the Rules are independent so an error that occurs at runtime in one Rule won’t wipe out the others. (there are other things you can do to stop all your rules running though).
Yeah I wish where was some other place for seeing validation errors rather than relying on watching the logs…especially if doing a small tweak via ipad for example (rather thane opening two ssh sessions, one for editing, and one for tai).
When Rules are saved to the JSONDB using the NGRE they carry a status similar to the status you see with Things. But ultimately you will probably never get away from having to watch the logs as you are making changes.
Frontail is a tool that will let you tail the log in a browser tab. It comes with openHABian but is not difficult to install and configure on your own.
Yeah I have a seprerate docker container with openhab logs in tail. But I think I’d prefer something with some sort of filtering/notifications. That would be useful
When you use the Jython helper libraries, rules are wrapped with log_traceback, which sends a notification when there is an exception in a rule. I keep a few screen sessions on my server tailing logs all the time, but it is really nice to get notifications on my phone when something breaks unexpectedly.
