I have a similar use case as this humidifier but for a diffuser. I don’t plan on using an environmental sensor input (e.g., humidity) to determine when to start/stop. I do have a tank empty sensor that allows me to turn off the unit in that case. I don’t have an accurate time to empty so I will rely only on the empty sensor. I probably will add a presence sensor eventually. I can handle the rules logic for these kinds of inputs.
I would like to randomize a duty cycle for the device. For example, every hour, I would like to run the device for a total of 15 minutes. I would like to spread those 15 minutes out over the course of the hour and make each “on” cycle be a variable range of seconds (say 30-120) and be random over the course of the hour. In other words, at the end of the hour the total “on” time will have been 15 minutes and it will have been spread out in random bursts randomly over the course of the hour.
Any help, insights, pointers, or outright coding examples are most welcome
I think I’d tackle it with a rule run hourly to set up a set of future cycles.
Have a piggybank set for total duration.
A problem is going to be generating random periods that do not overlap.
If you can tolerate psuedo-random start times it makes it easier, you might divide the hour into 2.5 minute portions you can select from.
Make a map of possible start times, limited in range from 0 to two minutes before the hour. (these can be just numbers that you add to “now”)
Generate a random selection, see if the map entry is available or else try again. mark it used in your map.
Now generate a random duration and subtract from piggybank.
Create a timer for target time, that turns ON and also creates a timer for OFF after duration.
if piggybank is non-zero, repeat until its exhausted.
I have to say, this sounds like an incredibly annoying feature, but I expect you have reasons
I was “told” that this thing needed to be “invisible” It’s very quiet so that’s not an issue. If it’s too strong a “pattern” then it becomes predictable and noticeable.
Thanks. I’ll mull this over… but yes, that’s a lot of moving parts. May be too much for me to bite off. I’ll have to find snippets to steal from
I’ll second rossko57’s approach. That’s how I’d do it. This is one of those problems that are way more complex than most people would think. But, this is also the sort of problem that people who love to code live to solve. Maybe someone will come along and give it a shot.
It’s very quiet so that’s not an issue. If it’s too strong a “pattern” then it becomes predictable and noticeable.