Multiple notifications on programmable bulbs

[dd-b]

First draft, but this largely works. Though I have questions, below.

The purpose is to provide priority notifications (fire, tornado warning, intruder, flood, that kind of top-priority things) in the environment. I'm using programmable bulbs in "nightlight" situations so they are present a number of places around the house. With multiple notifications I want to show that, not just the first one. By adding a second action statement in the inner if body I can also display this information on Inovelli switch LED strips at the same time. (Eventually, serious notifications probably should also go to various phones, and probably turn on all lights, but I'm still thinking through what's wanted.)

It's annoying to do in that it requires coding a section for each event type (as well as creating a virtual switch for it).

Current code is this:

One question I have is, if I were to change this to repeat say a million times (which really means until a human notices and resets the condition triggering it)...would that interfere with other rules in the hub? Just Rule Machine rules, or everything? Or would it all happen in parallel? (That first test for the conditions being reset, terminating the loop early, is there to help if I greatly increase the repeat count.)

I'm also not clear what would happen if, say, I triggered a fire alert, and while that was still displaying I triggered a tornado alert. Would I then have two copies of this rule running, maybe sending conflicting commands to the lights at random times? Or does RM limit it to one copy of the rule running? Or what?

And...why isn't any of this written down anywhere? Why do I have to learn everything by experiment?

[bertabcd1234]

You can get multiple instances of a rule "running" at the same time (the term "running" is a bit of a misnomer: a rule wakes up in response to a trigger, executes whatever actions, then goes back to sleep until something else wakes it up again, whether that's another trigger or a delay, wait, or timeout--all of which will also put it to sleep when reached--being met). However, there is only one state shared among all "instances" of a rule, so I'd avoid multiple potential executions whenever you can. One way to do this is to track this somehow, e.g, with Private Boolean or another variable of your choice. Overly simplified, this would look something like:

Actions:

IF (Private Boolean is False) Exit Rule
Set Private Boolean False
Do Things
Set Private Boolean True

Repeating a million times shouldn't be substantially different than repeating less, other than that in any case if you have a high-frequency repeat interval, it's more work on the hub and so risks competing with other things you might be trying to do at the same time. In most cases, this is probably little concern. There are no hard limits, but you'll have to see what works well in your particular environment (and generally less and slower would be better). You also don't need to specify a number of times to repeat if you want to repeat indefinitely; your IF (all off) Stop Repeating Actions will get you out of the repeat on its own when things change if that's all you want.

The only other concern I have: your repeat interval is 5 seconds, yet the actions inside could take over 6 seconds to run (if all the conditions are true and you wait two seconds three times, though I guess really only the first two--so four seconds--would matter and you'd just be cutting the last thing one second short). The repeat will start over with or without this wait having finished, though since there's nothing after the last one I suppose this won't really cause any other noticeable effects.

I can't speak to why some of this is or isn't documented; in general, staff recommend writing rules as simply as possible, using multiple rules if needed, or using built-in apps if they meet your needs (e..g, Hubitat Safety Monitor, though it can't do the color looping you're doing here). With simple rules, most of these questions don't really matter. In your case, I'd say they are good questions to think about, and heeding the advice to avoid overlapping execution of the same rule--whether by careful consideration of triggers, a way to "bail" early on in the actions, or some other means--is good. Good bits of information from staff can be found scattered in various forum posts...so probably not what you mean with "documentation," but at least not total silence on the matter.

[dd-b]

I thought about trying to do my own interlocking against multiple executions. That's something that turns out to be an actual difficult problem in computer science, though, requiring hardware-level support to actually get to work fully reliably. On the other hand, if the results of failure aren't disastrous or common, reducing the problem instances might make sense.

I'll tune the time interactions of the big loop and the sum of the little blocks in it better eventually, when it starts to settle down.

I'm also confused about what "delay" does; I can't figure it out in experiment (I thought putting a delay on setting new colors would let the old color last two seconds, so I could skip the explicit test and wait-for-elapsed time, but experimentally that didn't work).

[dd-b]

So can one view or set the private boolean for an app instance through the UI somewhere? Because it ran nicely once and then won't run again, and if I'm reading the commentary added in the displayed rule right (and the logs) it's because the private bool isn't getting cleaned up right. But I don't see how it can miss the code to do it.

[bertabcd1234]

@dd-b

I'm also confused about what "delay" does; I can't figure it out in experiment (I thought putting a delay on setting new colors would let the old color last two seconds, so I could skip the explicit test and wait-for-elapsed time, but experimentally that didn't work).

There are sort of two types of delays: the "delay" option you can use on an action and the standalone "Delay" action. The former will schedule the delayed action for the specified amount of time into the future, then continue onto the next action. A plain "Delay" action will stop execution at that point, schedule a wake-up for the specified amount of time into the future, then continue with the next action. In this respect, it's a bit like: "Wait for event: elapsed time," except "Waits" of any kind are implicitly cancelled when a rule re-triggers, where as delays must be cancelled if you want that behavior (e.g., by marking them as "cancelable" and using a "Cancel Delayed Actions").

@dd-b

So can one view or set the private boolean for an app instance through the UI somewhere?

You can only set it via rule actions. It begins as true by default, if that's helpful to know. There's no good way to see it in the UI, but you can look on the "App Status" page (gear icon) and look for "private" under "Application State" to see its current value--at least as long as they don't change how this works internally.

If you have an action that is setting PB back to true but aren't sure if/why it isn't running, turning on logging for, at least, "Actions" in the rule might help, if nothing else.

[dd-b]

Okay, so it is in fact stuck in false state, something screwed up in the logic, in a way that shouldn't be possible.

I can make another app to fix it I think, which would then let me play around enough to maybe find out how it happened and fix that.

[ETA: seems to have been a one-shot? At least, having forced the fix once, I haven't been able to re-create the problem. I think maybe for safety I'll add a rule that when all the notification virtual switches are off it forces a cleanup on the main rule.]

[dd-b]

So, I've got it setting the nightlight bulbs, and two Inovelli switch LEDs. Most of the time.

And, when the notifications go away, it turns the lights off but doesn't restore the nightlight functions. That I can just add code for.

But it seems to interact strange with motion lighting commands on the same lamps. Where can I learn about general rules or principles on how things interact?

[bertabcd1234]

I'm not sure exactly what you're looking for with "interaction," but in general, apps just send command to devices, usually either in response to a schedule or an event (usually device attribute) subscription. So if you're asking about something like two apps (including rules) scheduled to run at the exact same time or waking up (e.g., triggering in the case of rules) in response to the same device event, the behavior isn't really defined: all the subscribed apps will wake up more or less at the same time, just not in any guaranteed order.