Here’s my use case: I have a pool pump that OH turns on and then off again every day. But the timing of that depends on the temperature of the water (the hotter the pool, the longer the pump needs to run to prevent algae).
In OH2, I accomplish this through timers. I have a rule that runs every night at 12:01 am that calculates the start and stop times and then sets a timer for each. This works great in normal circumstances, but I need an additional trigger for when I update the rules file or OH restarts in the middle of the day. So, I also have a “system started” trigger for the rule.
This has worked great for years.
In OH3, though, I understand that the “system started” trigger is more limited to literally refer to when OH restarts. Thus, when I edit the rule file, the timers are (I think) destroyed, but (I’m pretty sure through testing) not recreated.
So, my questions are:
Is there a better way to do this? Specifically to have a rule that is triggered at a specific time, but where the time changes each day? I’ve looked into DateTime items, but there doesn’t seem to be a rule trigger for them. I use the astro binding for things that change daily based on daylight and sun position, but this has nothing to do with daylight and is very specific to my own personal pool.
Is there a workaround to the system started limitation in OH3?
Perhaps related to #2, but I’ve noticed that when I edit items and things files in OH3 (I haven’t played that much with OH3 yet, so I don’t know about other config files), the items and things do not update until I restart my OH (which is running inside a docker container, so it involves restarting the docker container). Is this just my system, or do I really need to completely restart OH every time I edit a config file? That seems like a lot of extra work when you’re making small debug tweaks to a config file.
Do you have a temperature sensor for the pool?
In OH3 you can use an expire timer and set the timer to a specific duration. If you have a sensor you can have a rule that says if temperature > whatever turn on pump and the switch item for the pump is the one that has the expire timer on it. The benefit of this is if the temperature hasn’t gone below the temperature you are checking and you send another ON command to the pump switch item the expire time is reset.
I am using OH3 and I just use the GUI and don’t edit files and it just works.
Not really, you have the right approach. Always more than one way to do things though.
How often are you editing this rule, exactly?
Presuming you’re editing other stuff really, can you extract it to a separate rule file that won’t get edited often? (You may need to take shared global variables into account here.)
What happens when you edit a Thing is pretty much dependent on the binding it belongs to. Some accept dynamic changes more gracefully than other. It is usually possible to restart only the affected binding, if needed.
That’s not exactly my setup. The pump needs to run every day, even if the temperature doesn’t get above any given number. It’s just the duration that changes.
I think this is the answer. I do have a separate rules file for all my pool rules, but I think separating those that have timers into their own rules files will mostly solve this because, as you suggest, I’m not editing THIS rule that often. I will have to consider global variables, but for the most part I store my globals as persistent items, so that shouldn’t be too hard.
I think this may have been an issue with trying to run an OH2 and OH3 container side-by-side. I just realized I couldn’t get to my OH3 karaf console to check logs (because both containers were listening on 8101). When I stop my OH2 container, the items and things files seem to reload as expected. Now on to figuring out how I can get my karaf consoles running side-by-side.
Edit: I answered my own question. I had found this post: OpenHAB3 Docker Test Instance on Synology , which explains how to change the karaf port. But when I did that it would not accept my karaf password. Somehow restarting everything fixed that, so it seems to be working for now.
My understanding is no, in .rules files System started works the same as it ever has. Can you describe more about what I’ve done to determine that it’s not working?
But in the UI Rules System started is not available and instead there is a start level trigger which only runs when openHAB itself reaches a start level and independent of when the rule itself is reloaded. But being in the UI, there is no reloading of a bunch of rules just because they happen to be in the same .rules file. Each rule is independent. You’ll know that your rule was reloaded because either all of openHAB restarted (in which case the start level trigger will run the rule) or you’ve been editing that specific rule in which case you can manually run it by clicking on the play button.
In Python and JavaScript (and I assume Groovy) a better solution to a System started rule is to use the scriptLoaded function which gets called when the file is loaded. There is also a scriptUnloaded function too, which is a great place to cancel any running Timers to avoid errors in the logs from orphaned Timers.
I think that pretty well covers all the startup options in OH 3 right now.
In any event, I have loginfo set up in my rule. It posts a log entry when restarted, but not when reloaded. I’m fairly confident that the behavior was to trigger the rule when the rules file was reloaded under OH2.5, but I don’t have 2.5 set up anymore, so I can’t go back and easily check.
The scriptLoaded and scriptUnloaded functions seem ideal. I quick google search didn’t turn up a lot of documentation, but I’ll try to figure that out at some point. I still use the old OH1/2 rules language, so I’m not sure where I would put Python or JS code to be accessible to the rule. But I’ll look into it when I have some time.
For now, the separate rules file for the timer rules seems to be working. They definitely trigger when the system is started and and the predefined cron times, and since I hardly ever edit those rules specifically, I don’t have to worry too much about them getting cancelled and not restarted when I edit other rules.
