I’m running OH 3.0 via Docker on Raspbian, with a pending upgrade to 3.1
I’m adding tide tracking functionality to my OH, where I use an API to get times of upcoming tides (high/low) for the next day. I plan to create “next High” and “next Low” tide items, as well as current status (rising, falling) from this information.
I currently have a rule running a (JS) script at midnight to make the API call, parse the data, and do the calculations, but I’d like to fire it again at each high/low tide event to update the “next” and status items. I see a couple options, and appreciate input from the OH3 gurus on best approach:
- Run at midnight, get the day’s data via API, and schedule a timer for the next high/low event. Timer action updates whatever is needed, and schedules a new timer for the next event (if there are any remaining for the day). This would run 3 or 4 times in a day. Seems pretty efficient, but does have a timer hanging out there at all times.
- Roughly the same, except run every 15 minutes via cron to do the updates. Gets rid of the hanging timer, but now runs and does unnecessary work 92 out of 96 runs/day.
- Some way I haven’t yet discovered to set the “next run time” for a rule.
I’m hoping to make this fairly generic so I can share it when done.
I’d just do this to keep it simple. Yes, it runs a lot, but the overhead isn’t really an issue. Also, it will survive a restart.
The question I’d have is, do you need it to run every 15 minutes? I don’t know enough about tide tracking to identify the best intervals.
Tide cycles are a little over 12 hours. Today, high was at 13:10. I’d rather not look at, say, 13:45, and have it say “next high tide is at 13:10”, by then, I’d want it updated to “01:50” or whatever the correct time is. 15 minutes seemed like a small enough nterval that if you caught it just after the high/low tide, it would be close enough to be acceptable.
I could always code the midnight run to also happen on restart, there’d be no problem with it running at a different time.
If I had decent Java chops, I’d do this as a binding, but I’m making do with a JS emulation for now.
Good point. If so, then it’s just a question of how much effort you want to put into programming it. I totally get not wanting to have it run unnecessarily, but I’m also lazy.
What do you use the tide information for? I’m just curious as it sounds interesting.
With the cron, you could cut down on the number of times the API is called by using the timestamp-change profile. Create an item that timestamps when the tide information changes, then check the current time against the timestamp before calling the API. If it’s less than 11 hours, don’t call the API.
You’d still need/want a 15-minute cron, but most of the time it would fail the check and not run.
We live near a large marsh/estuary that’s tidal. Kayaking at low tide can be a drag, literally. Near high tide, currents can be interesting. It’s an interesting area, because the connection to the ocean is small relative to the area being drained/filled, and the tides vary by a few minutes even within the estuary.
Speaking strictly from a computer efficiency perspective a Timer is going to win over polling every time. All a Timer does when it’s “hanging out” is take up a few bytes of RAM. That’s far less RAM and far less CPU than a polling rule will use over the course of a day.
But computer efficiency rarely matters nearly as much as human efficiency. Follow Russ’s advice and implement what’s easiest for you to implement and understand.
I’ve a question though. If you are running it on every tide event anyway, why run it at midnight at all? Definitely run it on system started but I don’t see the point of running it at night, unless the API only returns the values for the current day or something like that.
My typical pattern is to try to build something simple, get consumed by minutiae that makes it complicated and finicky, and then revert back to what I was originally doing.
This happens a lot when I’m designing in 3D. I would be much more efficient with my laziness if I trusted my first instinct more often.
I feel like timers won’t be any more complicated in the long run, and this particular install is pretty lean anyway, so efficiency isn’t a major concern.
The midnight run may factor out once I get further; I started out thinking a run at midnight to set values for today’s tides would be the whole story, then I moved on to the status and “next” ideas. Thanks for helping me remember to take a step back and look at it again.
The API is flexible on the times, although “today” is simplest. I left out some detail in the original description, though … I need to look at more than today anyway. As I write this at 14:00, the next high tide is early tomorrow.
If you are comfortable writing rules in java this can be done using the jrule binding see example and info here: