Inspired by this thread, this is a port of a driver used in Palette Scenes to a stand-alone app.
It's a very simple utility app -- select multiple switches, and only one of them can be on at once. If one turns on, the others get turned off. Of course, you can do this in Rule Machine, but only by taking a dependency on the names of the switches or having one rule per switch (each of which knows about all the other switches). That's fragile; I don't like doing that if I can avoid it.
And I can, so now you can too.
Additionally, based on @danabw's comment below, this has a second type of child app which creates a collection of virtual switches with similar behavior -- when one turns on, the others turn off. The parent device collecting all the switches will also indicate the current and previous state of the collection:
Available on HPM, or from GitHub.
This combined with virtual switches has some interesting possibilities that also bear investigating.
Thanks for your help with this. I installed this just now, when I click on Create New Single Active Group I get the following screen.
Just guessing, but it appears like you only installed the child app. Did you also install the parent app?
I just used HPM. Would this not install both components?
I removed the install from HPM and added the code from both Parent and Child code pages you shared into the Apps code page and then installed the App using the Add User App Button and I get the same message.
If you are responding to me, then I did not share anything. I was just trying to solve your problem. I haven't installed the app, so I was just guessing the most likely solution from the error you showed. HPM should install both. Did they? Look in the Developers Code / Apps Code to see both are installed.
Bah, one-line issue. You can run an HPM repair on it / reinstall it, and it should be linked up correctly now.
Verrrry interesting suggestion. Makes me think of the discussions about multiple parallel sets of Modes to capture different states of the house. I'd previously had the insight that those would be equivalent to an Enum type in global variables, but you're right: a collection of mutually exclusive virtual switches would let you create Mode-like tracks. (Though that might be better-served by the original design of this -- a parent device driver with a collection of child switches. Keep everything together.)
That was how I was thinking about it as well, though I have to admit I haven't taken much time to really consider the possibilities in detail, but the general potential popped into my head quickly.
Somewhat like the direction Simple State Machines is/was moving. (Virtual switches to represent the states, virtual buttons to represent transitions.) A variant of this app closer to the original driver might be worth creating.
What about something like this?
One quick question (likely my confusion) - should the mutex parent update w/status of the mutext children? In the pic below I have two of four children on.
It shouldn't be possible to have two children on, so that's a separate thing to look at. But no, there's not anything currently on the parent device that reflects which child is turned on. That would be a simple addition. Just child switches that send each other
off() commands as part of processing
OK, thanks...I think I was just doing too much at the same time (multiple projects today!)...
I had first installed just the Mutex parent and child, created a few generic component switches, and in that setup mulitple child switches on is allowed.
Then installed single switch parent and child apps and selected the Mutex switches and only allows one on.