Be careful with putting these outside the rule. That means they only get set up and populated when the script is loaded. That was definitely a problem in Rules DSL and I would expect it might be a problem here too. If for some reason that Item Object goes stale (e.g. you’ve reloaded the .items file and the Items in that file were all deleted and recreated as a result) blinds and porchLight will no longer be connected to an active Item and no longer reflect the current state of the Items.
Better to get the Item and it’s state inside the rule so you know you always have the most recent and active Items and states.
It’s somewhat cleaner and avoids a problem with how commands are processed to use logic.itemCommand (for command triggered rules) and logic.itemState for update and change triggered rules. (NOTE: in execute: logic => {, logic is the name of the argument passed to your execute function. In files based rules you can name it what you want (in this case you’ve named it “logic”. In UI rules and in most of the examples you will see this is named event since it represents the event that triggered the rule.
Given that’s what this does, “logic” is kind of an odd name really and I’d recommend changing it.
So, if you keep the command trigger:
if(logic.itemCommand.toString() == 'SUNRISE')
or if you change to changed trigger:
if(logic.itemState.toString() == 'SUNRISE')
I’m not 100% certain the toString is required here and include it just in case.
One important distinction (and not one I necessarily agree with but it is what it is) is items.getItem('MyItem').state always returns the string representation of the Item’s state. However, that event Object that gets passed to the rule will have the “raw” Item State Objects, the same as if you called `items.getItem(‘MyItem’).rawState;
Note, there won’t be an itemState or itemCommand when you run the rule manually. There was no such Item event that occurred. That’s why the toString failed. You tried to call toString on something that doesn’t exist.
If you want also be able to run this rule using triggers that are not Item events, you cannot rely on event.
I don’t know. was the Item TimeOfDay commanded? How do you know the rule didn’t run and instead it just failed? Add logging. I’d guess the removal of the toString() calls is why the rule didn’t do anything.
Unless there is an error your rule will never output anything to openhab.log unless one of your if/else if statements evaluate to true.
It is highly likely that event.itemCommand == 'SUNRISE' will never be true because evetn.itemCommand is, in this case a StringType, not a string (that’s why we need the toString().
Therefore, none of your if/else if statements evaluate to true (2.) so there will be no evidence in your logs that the rule ran (1.). There is no evidence what-so-ever to tell you whether the rule ran or not. You just can’t assume it didn’t run, it might have run and exited without doing anything.
You need to add a log statement to the rule to show that it ran (or modify the events logger so show rule events in events.log). Maybe add an else that logs an error when none of your if statements match. Maybe just a log statement at the top of the rule to show it was triggered.
Never make assumptions. If your assumptions were correct, the rule would work. You have to prove to yourself with evidence what is going on in the rule. If your assumption was that the rule didn’t run, add some logging to prove it didn’t run.
All your points are completely valid @rlkoshak, can’t argue at all
I’ve gone ahead and added some additional logs; 1 at the start/end of the rule and also ‘else’, if none of the criteria is met.
I have found some error, after forcing the ‘TimeOfDay’ item to change shown below:
2022-01-12 18:20:58.542 [INFO ] [b.automation.script.daily.automation] - Daily Automation Script - Start
2022-01-12 18:20:58.753 [ERROR] [org.openhab.automation.script.rules ] - Failed to execute rule DailyHomeAutomation: TypeError: undefined has no such function "toString": TypeError: undefined has no such function "toString"
at execute (home.js:18)
at doExecute (webpack://openhab/./node_modules/openhab/rules/rules.js?:110)
2022-01-12 18:20:58.827 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule 'DailyHomeAutomation': Fail to execute action: 1
2022-01-12 19:54:30.974 [INFO ] [del.script.Rules.rules_toold.Time_SM] - Today is a default day.
2022-01-12 19:55:30.994 [INFO ] [del.script.Rules.rules_toold.Time_SM] - The current time of day is SUNSET
2022-01-12 19:55:31.006 [INFO ] [b.automation.script.daily.automation] - Daily Automation Script - Start
2022-01-12 19:55:31.014 [INFO ] [org.openhab.automation.script ] - {
"eventType": "command",
"triggerType": "ItemCommandTrigger",
"receivedCommand": {},
"oldState": "null",
"newState": "null",
"itemName": "TimeOfDay"
} undefined
2022-01-12 19:55:31.021 [ERROR] [org.openhab.automation.script.rules ] - Failed to execute rule DailyHomeAutomation: TypeError: undefined has no such function "toString": TypeError: undefined has no such function "toString"
at execute (home.js:19)
at doExecute (webpack://openhab/./node_modules/openhab/rules/rules.js?:110)
2022-01-12 19:55:31.027 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule 'DailyHomeAutomation': Fail to execute action: 1
I’ve not seen that before. I wonder what is going on here. receivedCommand is an empty dict, not the expected StringType.
I don’t use file based rules but can’t imagine this is done differently in files compared to UI rules.
What happens when you adjust the trigger to a Change and change the comparisons to check event.newState? Leave the console.log statement in place and post those logs as well.
Try it out and see what happens. What is weird is this doesn’t look like the event Object I’m used to. I think the openhab-js library is monkeying around with the Java Object before sending it on. I’m not sure I like this difference between UI rules and text based rules if that is the case.
Hi I see Jeevs was able to work around the issue by changing the rule to react to a state change of an Item. However, I need a rule that reacts to the command an item receives and that command may be the same, so reacting to a state change doesn’t work. To simplify things I trimmed down my rule to logging only, to see what is happening. BTW I am also using file based rules.
So what I am noticing is that the event.itemCommand is undefined. That looks like it is not possible to pick up the command itself. That is a basis fuction of openhab, so I must be missing something, but I cannot figue out what.
I run into similar issue, not sure what I’m doing wrong - everything worked in OH3.
In OH4 I updated the scripts to use a different “sendCommand” syntax as below:
2023-09-11 17:36:22.373 [DEBUG] [cript.Rules.Hauswasserwerk_PowerCtrl] - >>>>> itemNameitem_HM_Sw4_Bewaesserung_1_STATE - itemCommand: undefined - event: Item 'item_HM_Sw4_Bewaesserung_1_STATE' changed from OFF to ON - itemState: ON
I tried to convert the itemCommand.toString() but this is not valid for undefined of course.
