Are you aware of Presence Simulation [4.0.0.0;5.0.9.9]? Why write what you can just install and use?
Create an Item to represent vacation mode. When it’s on the above rule template will similate presence merely by playing back the states your system did seven days ago? It’s better than random because it’s your actual recorded activities.
Then you’d have a rule that triggers when vacation mode turns on that disables the other two rules and when it turns off it enables the other two rules.
State machines and all the rest is way over complicated for this.
I don’t understand why there are so many triggers. And you usually do not want to mix a periodic polling trigger with a bunch of Item updated triggers. Furthermore, you only need to do something if these Items change so they should be using the changed trigger.
This rule is probably almost constantly running.
If you want it to run every second, just use the cron trigger. If you want it to run when something changes, remove the cron trigger and make all the Item triggers run on changes, not just updates.
With so many triggers it’s no wonder there are interactions between rules.
Also, since this is fully automated, can’t you just let it run as is for vacation mode? The whole point of vacation mode is to make it look like the home is occupied. Changing the behavior of the home when you are away becomes a signal that you are away.
Why not using the built in time library?
var currentTime = time.toZDT();
var sunsetDate = time.toZDT(items.OneCallAPIweatherandforecast_Current_Sunset);
var sunriseDate = time.toZDT(items.OneCallAPIweatherandforecast_Current_Runrise);
var currentHours = currentTime.hour();
var sunriseAndDelay = sunriseDate.toLocalTime.plusMinutes(3);
var sunsetAndDelay = sunsetDate.toLocalTime.minusMinutes(3);
In fact the whole rule can be simplified to:
rules.JSRule({
id: "r_SteckdosenStehlampeWZ",
name: "SteckdosenStehlampeWZ",
description: "Diese Regel schaltet SteckdosenStehlampeWZ automatisch.",
triggers: [triggers.GenericCronTrigger("0 */10 * * * ? *")],
execute: (event) => {
console.name = 'org.openhab.rule.r_SteckdosenStehlampeWZ'; // use the console instead of a custom logger
// Assuming MainUI, you can create a widget with an action that enables or disables the rule
// directly instead of using a separate Item. You can also enable/disable rules from other rules.
// If for some reason you need to have these Items, put all this code into a library which can be
// reused across all your rules instead of adding duplicate code to each rule.
let now = time.toZDT();
let sunrisePlusDelay = time.toZDT(items.OneCallAPIweatherandforecast_Current_Sunrise).plusMinutes(3);
let sunsetPlusDelay = time.toZDT(items.OneCallAPIweatherandforecast_Current_Sunset).minusMinutes(3);
// put the rollarshutters into a Group with a MIN aggregation function, I've called it RollershuttersGroup here
let rollershuttersAreClosed = items.RollarshuttersGroup.numericState >= 70;
let command = "OFF";
console.warn("now: " + now.toLocalTime());
console.warn("sunrise: " + sunrisePlusDelay.toLocalTime());
console.warn("sunset: " + sunsetPlusDelay.toLocalTime());
console.warn("rollershuttersAreClosed: " + rollarShuttersAreClosed);
if(now.isBetween("06:00", sunrisePlusDelay)) command = "ON"
else if (rollershuttersAreClosed && now.isAfter(time.toZDT("08:00"))) command = "ON";
else if(now.idBefore(sunsetPlusDelay)) command = "ON";
else if (rollershuttersAreClosed && now.isBefore(time.toZDT("17:00"))) command = "ON":
items.SteckdoseAnAusWZSuedwest1Item.sendCommandIfDifferent(command);
}
});
There is no reason to trigger this rule based on this Item. I’m surprised this rule even loads and parses since this Item is created by this rule in the first place. It should throw errors when this Item doesn’t exist.
If that created Item triggers the first rule, you should remove it there too.
You never use this and you should not be importing it. For JS Scripting use the openhab-js interface instead of accessing the JSR223 API directly. Everything you need to do is available to you by default.
Is this some AI generated code? It has that overly complicated look to it that usually comes from trying to use a chatbot to generate code.
Though if this works maybe not as chatbots have a really hard time writing rules for OH.
If you use the built in time libraries this whole function gets replaced with time.toZDT()isBetween("07:30", "19:00");. Though why not just configure the cron trigger to only trigger the rule between 07:30 and 19:00 in the first place. Then you don’t need to check for this in the rule itself.
As far as I can tell this adds nothing but extra complexity to this rule.
Note that you do not need to define all the functions inline in the rule like this. These can be declared in the same file outside the rule.
Use items.OneCallAPIweatherandforecast_Current_Apparenttemperature.quantityState to work with units or items.OneCallAPIweatherandforecast_Current_Apparenttemperature.numericState to work with primitive numbers.
This should be a function you call with the Item name as an argument. Avoid repeated code. Using Groups, Item metadata perhaps or maps in the rule to map the rollershutters to the windows and the directions you could shrink this rule by more than half.
If you use the Astro binding, you can base this on the sun angle instead of the time of day. Then the rollershutters will adjust themselves as the sun changes position over the seasons.
Anyway, seeing the rules themselves my suggestions are:
- use either cron or Item state changes to trigger the rules
- these feel overly complicated for what they do
- these look like a strange combination of Nashorn JS and JS Scripting. Make sure to review the JS Scripting docs as you are missing out on a lot of stuff that’s already done for you to make your code simpler.
- I don’t see any reason either of these rules should behave differently to simulate presence. Just let them run when you are not there. That’s the great thing about automation, it works the same whether you are there or not.
- But if you do want to override the behaviors and simulate presence differently from how these would behave when you are actually there, disable these two rules and enable a presence simulation rule.