@jnschemm I agree with you. I haven’t explored the full capabilities of RM, though I agree it does most of what anyone could think of. There are a few things it cannot do (had to add code to it to make it do what I needed) but that’s perhaps 1% of use cases. I am sorry if I came across the wrong way, I do not in any way mean to undermine RM or its maker and/or supporters. The main reason I did not yet explore all the strengths of RM is because I am not the RTFM kind of guy. And getting in touch with RM, it kind of turned me down. I mentioned earlier, it is most likely due to backwards compatibility. I can tell by browsing through the code. And yes, having a base of ideas to start with makes it much easier. But that should not stop an attempt to make something, if not better, at least easier to use. I also said my target is not to better RM, my target is to make it more accessible. And to provide newcomers with ways to do things that are otherwise completely missing in ST. RM being removed is a big loss to the ST community in general. Big loss to Samsung/SmartThings in particular.
I will keep you guys posted as I make progress, but I’d like to see ideas that we can put in. I also would like to see use cases so that we can ensure they are in the code from get-go, rather than having to patch it later.
Regards,
Adrian
2 Likes
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
82
I finally mastered the hardware all in the blink of an eye. I even remember the moment.
It was the moment that I embraced the beauty and simplistic pure form of the flaws.
to be perfect, it must be imperfect.
There are two reasons I don’t code. I can, I just refuse to.
it’s boring.
there can be no flaws, therefore it’s boring.
You should see my carpentry skills. I build from scratch with no plans, no nothing. A pencil, a straight edge, and tools.
When I lay tile, my design is in the grout lines. The tile just colors in the lines.
3 Likes
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
83
I will pm you some scenarios I’ve used RM for.
I was thinking of dissecting the code to make specialized smaller apps. But I’m thinking I like your path. I prefer to keep it all together.
Assume you have two switches, A and B. You want something to happen if switch A is on and you turn switch B on. But if B is on when you turn A on, nothing should happen. I believe this is doable in RM with two rules and a private boolean?
I would allow the switch condition to have four values: “is on”, “is off”, “turns on”, and “turns off”. Condition would then be “switch A is on and switch B turns on”. This would only execute when the above situation happens. The momentary values “turns on” and “turns off” would be restricted to only one use within a whole rule. “When switch A turns on and switch B turns on” would never happen.
You do know this is a mesh network, right? You can’t guarantee forced sequencing because messages can bounce around the mesh for a while.
“Do while” conditions are fine, smartrules already uses them.
Just be aware that if switch A and switch B are both turned on in close proximity to each other, you won’t necessarily know which one physically happened first.
(Your example doesn’t need extra switch values, you just need a do while. You subscribe to the event of B turning on, not the state of B being on.
assume you have two switches, A and B. You want something to happen if switch A is on and you turn switch B on. But if B is on when you turn A on, nothing should happen. I believe this is doable in RM with two rules and a private boolean?
Do X when switch B is turned on while switch A is on.
The event subscribed to is switch B turning on. So if switch B is already on when switch A is turned on, nothing happens. You don’t need an extra switch state.)
I understand that, I don’t think anyone is using ST to watch fast triggering events. Let me add to it that there is a human pushing the switches and the two switches do not get pushed at the same time or within 5 secods. Going beyond the technicalities of how zwave relaying functions, would such a built-in capability be useful to anyone?
What do you mean by “do while”? A loop in groovy? SmartApp execution is limited in time (40s?) and this while do won’t cover large periods of time. My scenario assumes the two switches are handled at intervals of anything over minimum relay time (say, 5 seconds, YMMV). How do you handle this particular case in RM?
Ok, looking at SmartRules, I see what you mean. Same logic, different way of describing it. I am aiming at user friendliness. Which one do you think would be easier to the newcomer?
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
94
Ok, here is an example of hour I’ve handled this, if I’m reading it right… It has been a long day. 300 miles on the road and a day at six flags with two hours sleep… So I could be dreaming right now!
I consider home automaton to be a slightly advanced binary system. So, I look at the entire thing as an adder, our just a big if this then that machine.
Devices are either on, off, turning on, turning off. The last two are pretty much useless in a mesh system, except to have your speaker tell you that the garage door is closing.
Using five rules in RM (a combo of rules, triggers, and conditioconal triggers) along with private Boolean internal switching I’ve gotten the system to not act as simple an on/off system.
I got the door sensor to turn on and off the light with every other open or close. And the scenario is self healing for st glitches.
But, doing this I find it best to build in a wait time because of the cloud lag and time out.
So, if I could use one or two rules to be just as reliable, that would be awesome.
But I don’t think it’s going to create a more user friendly place for the common user. It’s going to create another in depth layer that only a few are going to grasp and understand.
I will take the challenge. Can you please describe the use case in more detail? Every other time you open the door the light turns on and when you close the door it turns off the light? This lnly happens every other opening of the door, right?
To do this in RM I would use a Conditional Trigger. I would not use a private boolean. In fact, I believe this is precisely why Conditional Triggers were implemented.
Trigger: Switch B On
Conditions: Switch A On
Rule: Switch A On
True: Do whatever…
False: N/A
At first glance I think “turns on” and “turns off” as concepts, especially if they’re limited to one use per rule, are a bit confusing.
The limit resides in the fact that you cannot expect two things to happen at the very same time. Not with AND between them. A logical OR would allow for multiple momentary conditions. But once you use AND between two such conditions, the rule would never be true. This can be done automatically in the UI so that once you a add a “turns on” or “opens” or “detected motion” etc. the same momentary states would only be presented if they would not cause such conflicts.
SmartRules uses the “while”. Conditional triggers are the RM equivalent then. The question is, which way is closer to how the human brain thinks? The average human brain… I mean.
I would have to write a lot of extra code to impose that limit. It would obly be there to assist the user, so that he cannot mistakenly setup something that will never trigger. And the app could have a lot of guidance at every step via paragraphs or even help hrefs.
For me, the difference between a “rule” and a “trigger” is easy to understand, and the “while” logic from SR is a bit harder to understand***. But I understand that your mind is different than my mind.
Which one of us is closer to average? We’ll likely never know!
I think you should develop what makes the most sense to you, since you’re the developer!
***Edit: Specifically, I find that “Everyone leaves” behavior is strange to implement with SR.
I believe it would help simplify things if we were a little more precise in the original example. You said:
Assume you have two switches, A and B. You want something to happen if switch A is on and you turn switch B on. But if B is {already} on when you turn A on, nothing should happen.
So far so good.
Our trigger will be the event when B changes from off to on. That’s what you will subscribe to.
Whether you are dealing with Java or Groovy, it’s important to distinguish the event (the moment the state changes) from the state itself (on or off).
You’re going to subscribe to the event so you will be notified when the state changes to on.
You don’t need your other two proposed states of “turning on” and “turning off” because you already have that information with the event subscription.
Once you get used to thinking of the events as separate from the states, everything will get much easier. You subscribe to the event which is a change in state. Additionally, you can just query for the current state.
So you get triggered by the event, which is the change in state for switch B, at which point you can query the state of switch A to see if it is on.
B being on (state) is not a trigger. B changing to the state of on (event) is the trigger.
Also, note that if you think about it in this way, you don’t have to subscribe to the events for A. The Event for A doesn’t trigger anything. When we get notification of the event for B, we query the state of A.
Did that help any?
(Of course it’s possible that you didn’t mean your original use case to be “while A is on” {a state} but rather “when A is turned on” {an event} in which case it would be good to clear that up. But the point is still that states and events are different. )
)