It's from ST I created a party mode to make the lights change colour, my little girl loves it (and me ) and because I have a old house I found some options to make the lights flicker like candles that's not on HE at the moment because it uses a lot of power (need to plan that). But i also have fibaro dimmer 2's in the bedrooms and one switch controls the load and the other though the driver controls a zigbee lamp so because it's only one button I need the same press to decide if it should turn on or off hence this setup. It would look/ be easier in WC.
I think it's a good thing usually to take the long way... divide the problem into bite size chunks. Optimizing later as time and insight allow.
There is of course a TOO Long Way, and you want to avoid that. It's hard to tell the difference but it's fundamentally a problem with defining the goal in simple terms. I've seen a lot of Rules pasted in various threads where the state of the device is a Condition. But a good percentage of the time, it's not actually needed. If the device is On and you send an On, so what ? Does it hurt to have the condition? probably not, but it's implying the goal hasn't been simplified.
But in my case if its on I want to send a off, and if it's off I want a on
Bad choice of an example
I was tying to give an example of when unneeded conditions get tossed in... not a commentary on your specific set of Rules. All my commentary about your set of Rules is about the benefits of the long way.
could we expand on the restrictions option in RM? More like @Cobra apps, currently the restrictions are quite limiting.
Restrictions are supposed to be quite limiting. (snicker)
Care to elaborate?
walked into that one
these options are in all his apps, so you can use presence sensors (and them in each state) as restrictions as well as more than one switch but again they could be in different states. I.E one needs to be off one needs to be ON. currently you can only select one switch.