No way. That's not possibly a source of an issue with your hub.
lol - yeah ok, i understand your point.
by variable concatenation i mean to link a series of boolean variables together into a a new variable/vector so each bit position is linked to the individual boolean. Then they could be referenced as variable(bit.position). Then it's a single operation to test the vector = zero and a single loop can then test each bit position using a index variable.
The use case for this for example - i currently have five leak sensors, but i see this increasing over time. The rule will need to be modified (well the way i have written it anyway) to accommodate new sensors.
With concatenation, and if you also supported variable size detection (the bit depth of the variable) the rule would not need any modification as the number of sensors was increased or decreased.
Hey, just thinking out loud.
I think i have already covered this, but to elaborate further, bit'set & bit'clear operations on variables & just like having an interrupt register and a mask register, bitwise and'ing & or'ing variables would be a nice to have.
I think you are crossing over into the territory of writing your own app to do these things. Groovy is a great language, and you can certainly do these sorts of things. With variable connectors in RM, it's easy to link a custom app into RM.
1 Like
Thanks Bruce. Yes I am definitely going to get there at some point. I have no groovy experience yet but have taken a peak at some the many examples available. Need better time management - lol.
Thanks for your responses.
Steve
Probably the first, but in the first screenshot you need to add in
If (Temp of Bedroom is >27 AND < 28.5) THEN
1 Like
The first rule won't ever set the fan to high. A temperature > 28.5 would meet the condition of > 27 and set the fan to medium then end the IF statement. It'll never get to the ELSE-IF statement.
The second rule should be okay but a temperature > 28.5 would set the fan to medium then immediately set the fan to high. Don't know if that'll be an issue or not but I would check for > 28.5, > 27, <= 27 in that order
There are many ways to write the same rule. I like using simple condition when I can so I like the approach of the second rule.
1 Like
sorry @mike / @pseudonym - this takes me freaking forever and I never get it right lol.
Was this better ? I see now that it would set to medium and not go to high.
Yes, better, but you can still make it better. Change the <28.4 to <= 28.5 (less than or equal to).
For currently, there exists a scenario where it's 28.44 and it wont turn the fan on at all.
1 Like
Yes, better. Are you trying to put a little deadband between your conditions? If so, that's a good idea.
The ELSE statement doesn't really need a condition since you captured everything > 27. The only temperatures left are <= 27. If you want to leave the condition I would change the ELSE and IF to
ELSE-IF temperature < 26.5
1 Like
Thing is, he has a 0.5 dec celcius where the fan doesnt do anything. The fan will turn on at 27.0, but it wont turn off until it drops back to 26.5
I gather this is by design.
I do want there to be a .5 gap, yeah.
I dont want the fan to turn off at 26.9 then go back to 27 and turn back on again and bounce off that. I'd rather know the temp is going south and then turn off as the temp drops over night.
Looks good! Though not as bad as on-off, I did like your .1 C deadband in your previous version between medium and high.
1 Like
@mike / @pseudonym
Mrs has now decided she doesnt want the motors on the fans to burn out being on all day so i've added a virtual switch into the mix so they cant be on unless she has them on (she wont remember the command).. is this right ?
which then doesnt work cause if you turn it on with the physical switch it doesnt turn on the virtual, so i'll probably need another rule to turn the VS on if the physical switch it flipped. lol, bloody hell.
Will this work ?
Bloody hell, that was an endeavour,
so in the end I made a Group, added the VS and PS to it. But when I turn on the PS it didnt turn on the VS even though they are in the same group.
So ive got the Group as my echo skill, and a rule above (boys fan PS to Virtual Switch) that if the Physical switch is turned on the VS turns on too (tested, works).
Man, she should of just let me keep them full auto lol
1 Like
Sounds like you’ve got the best of both worlds. You’ve got manual control and have got it automated. 
Got this error from this rule, any thoughts on why @bravenel ?
*Anything you can help me with @bravenel ?
Hi people,
Is this a bug or with intention: I think there should be an option to choose a light for the stop color temperature change function... am I wrong?
FYI. I read your comment about state machines back when you made it, and it intrigued me. So for the last week, I've been working on an app for defining state machines in HE.
I'm a software engineer by trade, and I love state machines for certain applications. (Also the old saying about any class eventually becoming a state machine. The distinction is if you know that it's a state machine and plan it out, or you just allow states and transitions at random. The quote at the top of this article is excellent: How I Learned to Stop Worrying and ❤️ the State Machine)
So when I see people posting screenshots of their RM rules with multiple IF - ELSEIF - ELSE blocks with different conditions in each and they wonder why it doesn't catch an edge case, my engineer brain says "That's a place for a state machine!"
However, I'm torn over whether to release it or not. Even RM4 is edging into the point of being powerful enough for non-programmers to get themselves into a lot of trouble, as evidenced by those posts. It has the power to do recursive, iterative conditional logic. For users who aren't used to that kind of power, they don't realize the pitfalls. For professional engineers, we see certain patterns in code and think "code smell!" and then refactor and clean it up.
So for a professional, you see "smelly" code that can be simplified and more reliable by using a state machine. But the tradeoff is an additional level of abstraction. And for typical users, the abstraction of a well-defined state machine is not something they're used to seeing.
However, the most likely result is I release the app and no one uses it because it's too confusing. So I probably will release it when I feel it's ready.
One thing that would help me: what use cases would you want to use a state machine for? This is the first thing I've built for Hubitat that didn't come from one of my own needs. I've tried to keep my automations simple, and haven't needed a state machine yet. I'm just building it because it's cool.
To give an idea of the "spec" of my app:
- ability to define "states"
- a state is a child device that implements the "switch" capability, so you can use RM to perform actions either when you enter or leave a state.
- ability to define "events"
- an event is a child device that implements the "button" capability, so you can use any arbitrary RM rule or other app to trigger the event
- ability to define "transitions"
- a transition means that if you are in the "from" state, and the chosen event fires, the state machine should transition to the "to" state. (the from state turns off, and the to state turns on.)
- don't re-implement RM. Rely on RM to perform actions from the state transitions. Rely on RM to trigger the events. Just be the core of the state machine that manages the state and transitions.
1 Like
