It’s actually not broken for OH 2, which is why it remains. Had I removed it or updated it you wouldn’t have any option at all but to upgrade to OH 3 really.
However, which is easier for the average user?
copy and paste, try to understand the code and what it does and edit said code to customize it so it works how you need it to
see the rule in a list of rules, click on it and it installs
I’m going towards 2 but until 2 is as simple as installing an add-on, I’m not going to cut off everyone by removing postings and examples. And even when 2 is that simple, I’ll not remove stuff that works or makes for a good example.
There are plenty of users like you who can not or will not upgrade. Though the users here on the forum that are able to help with 2.x problems is dwindling and will eventually reach 0 (i.e. you’ll be on your own) and the longer you wait to upgrade the harder and more work the upgrade will become. Regardless, I’m not going to remove stuff that works in OH 2 just because it doesn’t work as written in OH 3.
Also, the whole point of the Design Pattern posts is not to post complete and fully realized rules that you can just take and use as is without modification. The code posted in a DP is an example, and often incomplete example at that. The illustrate the concept of the DP. They are not intended to be copy/paste and use. They all require understanding and customization.
Anyway, the tl;dr here is if you are running on OH 2.x, the Rules DSL version of the code in the original post works just fine as written. But no version of the rules will work if your DateTime Items are NULL. You have to initialize them with a valid state before the rule can run. That should happen for you already with the Astro linked Items, but in OH 2 sometimes the rules start to run before Astro updates the Items with values when OH starts up. There’s not much you can do about it (this is fixed in OH 3 BTW) except to watch the logs and run the rule manually again if it failed.
In OH 2 you have to use a Rule or the REST API. In OH 3 you have other options.
But as I said, it’s more likely that the Astro Binding is what failed to initialize your Items, not that you failed to initialize it. When OH starts up, sometimes the rules start running before everything else has initialized. So you probably just need to manually trigger the rule to run again, wait for a day, or it already might be working just fine.
The way that version of the rule works is:
At startup it attempts to figure what the current time of day is based on the values stored in the DateTime Items.
The rule triggers at times that correspond with the DateTime Items and figures out what the current time of day is based on the values stored in the DateTime Items.
So if the rule ran before Astro populated the DateTime Items you’ll get a NULL error. However, after that the Astro will have done it’s job and populated the Item so the next time the rule runs it will run OK.
One other possibility is that the you’ve not linked your Items to an Astro Thing that exists. Do you have an astro:sun:home Thing and an astro:sun:minus90 Thing?
It’s a different Astro Thing with some offsets applied so that the event occurs 90 minutes before the real event. In this case Afternoon occurs 90 minutes before sundown. There are all sorts of ways to handle that sort of thing but at the time I wrote this DP I used a separate Astro Thing (actually it was written before there were Astro Things but I updated it to OH 2 at some point).
Question … Rather than add another binding thing … could I just run a rule that subtracts 90m from the thing that’s made in the first when the astro binding is installed?
First make sure to use the right terminology or else things get confused. The “binding” is the software that interacts with the device or API. Astro is the binding here.
A “Thing” represents a single device. The “Channels” represent the sensors and actuators, one per.
So you are creating another Thing, not a binding.
Now to the question. Rules are triggered based on events. How would you trigger a rule to subtract 90 minutes based on the sundown event from Astro? You’d have to somehow trigger a rule to run 90 minutes before sundown to do the subtraction. But once you’ve done that you don’t need to even do the subtraction.
So how do you generate an event 90 minutes before sundown? You can apply an offset to one of the sundown event Channels in the Astro Thing. But what if you also want an event that occurs at sundown too? You can either be a little flexible and use an event that’s close (e.g. civic sundown) to apply the offset to, or you have to create another Astro Thing where you can apply the offset.
You should review/rereview the docs, in particular the Concepts section.
You only need to set the offset on one Channel no matter what. But once you’ve set the offset that’s when that event will occur. Once you set the offset for the sunset event to -90 minutes, that event will always occur 90 minutes before sunset and there will be no event actually at sunset.
If you want an event at exactly sunset and 90 minutes before sunset you have to have two Astro Things. And yes, you can manually create an Astro Thing.
The docs are unintelligible at times, I’m afraid … they’re really hard to understand … For example I have literally zero idea what presence is after reading them.
But thanks all the same!
It comes with some nice UIs, I intend to use them as much as possible.
OK, you lost me a bit again at the end there with the time travel, but I just made a new thing in the things folder, so hopefully after another reboot all will be well with the world.
Given that the docs don’t talk about “presence” I’m not surprised. Do you mean “persistence”, a feature of OH that will save Item states to a database for charting, analysis, and restoring the state of Items on OH reboot?
Wait … it didn’t keep information over reboots before I put some SQLite thing on the other day? No wonder this thing has only started automatically doing stuff over the past few days.
That may explain it.
The usually best way to persist everything for a restore-on-startup without generating a huge database is using the MapDB. It only persists the last value, which is enough for that purpose. Otherwise you’ll end up with a lot of items in an undefined state.
I am trying to add Hours to a certain time already set when the lights were turned on.
Once I turn on the light, it saves the time. Then according to selected time in sitemap it takes that and add (x) Hours to the total time. and then checkes every 15 minutes until the .isAfter time is active then shuts them off automatically. I am unsure how to compare the times.
rule "Grow Lights auto off"
when
Time cron "0 */15 * ? * *"
then
//Grab the selected hours from sitemap
var Integer GrowLightsTime=(GrowLights_Time.state)
// Epoch time to compare start time with hours selected by sitemap
val Long StartTime = (GrowLights_StartTime.state as DateTimeType).zonedDateTime.toInstant.toEpochMilli
//This is where i am unsure how to compare the start time to the end time to create a condition and always gives gets errors I know the line below does not work, just giving you an idea
// what i'm trying to acomplish
val Long end_time = (new DateTime((GrowLights_StartTime.state as DateTimeType).zonedDateTime.toInstant().toEpochMilli).plusHours(GrowLightsTime))
//This is also where i am also unsure how to compare to and would like to do it
if (now.isAfter(end_time)){
if (GrowLights_Power.state!=OFF){
GrowLights_Power.sendCommand(OFF)
}
}
end
Why so complicated?
Just start a timer when you switch on the light and use your “sitemap” item’s state as the duration.
When the timer has run out, switch off the lights. When you manually switch them off and on during that timeframe, cancel and re-start the timer.
var Timer t = null
rule "Lights"
when
Item light_item changed to ON
then
if (t !== null) t.cancel // cancel timer if started
t = createTimer(now.plusHours(duration_item.state), [ | // start timer
light_item.sendCommand(OFF) // when elapsed send OFF
t = null // reinitialize Timer
])
end
that is my current running situation. From sunrise start a timer and then shut off after the time. This is more if i change the hours while it is running it will then compare the times and turn on and off instead of add that extra hours on top of when it has been running… if that makes sense.
