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.
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:
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.
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.
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 on().
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.
