Do users follow the convention of controlling outputs per app, rather than multiple apps addressing the same output? It can make fault finding and diagnosis easier in most cases.
Example case-
I have an indicator on an output-device that switches ON when a certain condition is present.
I now want to flash this same indicator if a different (more important) event/condition occurs.
I could have two apps each addressing the same output but the "always on" event would overrider the flashing state, so how would you do it?
Would you have one app that monitors the two conditions and sets the output accordingly?
BTW- how best can i make an ouput/indicator flash.
You'll probably get lots of opinions on this one! Not sure there is a right answer, more based on personal preference. I've found in general with HE there are usually a lot of ways to tackle the same problem, and none of them are wrong.
I don't as a general rule but in your use case that might work best. I have to remind myself from time to time that RM is not actually a programming language. Not that one should abandon programming techniques but I do tend to do things that with real programming would be considered sloppy.
True. But it also makes rules more complex, which can make them more difficult to debug.
I would have one app that had both conditions as a trigger. Then I would use a simple IF/THEN/ELSE statement to determine which of the two conditions occurred and adjust the output device accordingly. I'd also figure out what it would take to clear the condition and include those in the triggers and if/then statements as well. Or use a virtual switch to clear the condition, as I do when my litter box is full.
Depending on what the indicator is, some drivers actually have a "flash" command. That makes it pretty simple. For those that don't, you can turn them on, wait a second, turn them off, etc. Here's an example that uses a variable called "holiday flasher internal delay" to set the flash delay because I got tired of tweaking the rule all the time.
follow up-
so i have a RM app that sets my LED indicator (an output) to stay on with the input of switch A and another RM app that flashes the same LED/output if switch B is on.
How do i know which app takes priority and how can i control which has priority?
whilst we're on it, is there any control over the "flash" command, ie the frequency?
You could manage this with a Hub Variable used in effect to communicate state between the two rules. If both rules are triggered, one of those trigger events happened first. You'd have to decide which takes precedence, and act accordingly. Race conditions are possible if both events happen quickly. If that's a consideration things would get more complicated -- this depends on the real world relationship between these events timing-wise.
Assuming app B is the priority, app A could check to see if switch B was already on before changing the condition of the light to solid on. That way if switch B was still on it would take priority and the switch would keep flashing. If app B never checked and app A always checked, app B would become the priority. A call for a flashing light would always cause the light to flash but a call for a solid light would cause the light to go solid only if the higher priority condition had cleared. You might also be able to simplify the rule by using a required expression in app A that checks to make sure switch B is off. But I've only had a couple cups of coffee so my logic might need a little tweaking.
I'm pretty sure this is driver-specific. The Lutron switches, for instance, have a setting for it, but the Hue lights (at least using CoCoHue) do not. The Hue lights just flash at whatever rate they decide is right, and changing the transition time does not seem to affect how they flash.
Picking up on your example which takes me slightly OT. This is a subject worth understanding. I had a holiday light scenario where I was setting the FLASH mode for one set of lights for one part of the cycle of the total lighting plan. I had thought with the relay device I was commanding that "once told to flash" it would continue that way w/o any chatty conversation back to the hub for the duration.
I finally turned that flashing (with a 2 second interval set in the driver) off because I was seeing something either in the Zigbee traffic or the log that made me go "whowa, that's talking every time it's flashin?!". I might have been mis-reading or mis-understanding what I was seeing...but none-the-less I stopped the flashing of that string for the 15 minutes every 30 minutes in the loop.
And I appreciate the OP's original question as "control over various outside security lights" have grown beyond the original rule tied to the first sensor placed wayyy back.... and I've had a mind to go back and make an integrated rule just for the Exterior Security Lighting (vs Gate Motion, Yard Motion, and Driveway Activity)
