I like where this application is headed so far.
Yep, I see a lot of thought going in to it… And I’m liking the out side influence on the build… It’s a community idea!
Quick update: On to building the evaluation process
NOTE: read from bottom to top
The Living Room Ambient light is used as a condition in the IF block (primary block) and as a trigger in the BUT IF block (secondary block) of a latching SmartThinger.
What I already notice is how I sometimes get two events with the same device, attribute and value one after the other one, but different event IDs. So I’m getting some duplicate events with unique IDs from the OSRAM Lightify device - perhaps it sends the on event twice? ST should filter the second one? I’ll investigate
I believe there is a second platform limitation beyond that of clock time: any one smartapp is only allowed to create four future scheduled events.
@tgauchat or one of the other master coders can say more, but I do know that in the past people have broken up rules into multiple pieces to allow for this issue when a large number of devices were being controlled from the same trigger.
So that’s just one more factor to take into account. It doesn’t affect the number of devices being evaluated; just the number of future events being scheduled, typically when a delay is involved.
On this issue, I don’t know if this applies, but it might, so I’ll just mention it… Beginning in March, some polling events began reporting as a physical device change. (That is, the SmartThings platform was reporting the event, the device hadn’t changed what it was doing.) This caused a lot of problems with several smartapps because Subscriptions were being fired assuming that the light was coming on when in fact it was just being polled.
Again, I don’t know if that’s directly relevant, but I just wanted to mention it because it was the source of much of the duplicate event discussion in April.
This is exactly the reason I carry the volume of rules I have… Over 100 among my apps, 65 in RM, 20 in SL, and then some random others.
Too many problems with large complex rules… Been cake since I broke them up.
Correct. My plan is as follows:
Create a map element in which all “commands” are stored. There are two types of commands, one generated by triggers that need timing (attribute stays for so long, or time triggers - sunset, at this time, etc.) and the second one generated by actions. Each action may have one or more commands (i.e. turn on in so many seconds and turn off after so many more seconds, two commands). All these are stored in the map element and then sorted. After evaluation is complete and the map is populated, sort it and run through it:
- schedule a runIn some minutes for safety purposes - a way to recover in case we die trying to execute actions
- anything with a required time less than now execute and remove from the map
- anything left with a requested time higher than now, calculate the time interval until such request and perform a runIn at that time. When that executes, repeat this cycle
- if list is empty, cancel the safety schedule setup at step 1 and set one per day instead, only if sunset/sunrise are used - to update these times - there is a one that runs at some time in the morning
Optionally, when a schedule comes, if actions were requested at times that are far behind the current time, I may want to just drop them as they’re probably stale. Just a thought.
That’s pretty much the scheduler.
Yeah, what I did for this is caching the last event using the deviceId dash attribute as the key. This may touch up the 100k limit on the state though - we’ll see. I can purge the list so that I only keep events that happened in the last hour for example, this way I minimize the size of said cache.
So I save the event value and the time the event was generated. Then when a new event comes in, for the same device and attribute, if it has the same value, then I check the following:
a) were the two events generated within 1000ms of each other (they seem to be at very low intervals < 100ms) - I may change the 1000ms
b) is the value a string value?
If any of the two is true, then I completely ignore the event.
Just an fyi… I’m predicting a huge new experience fit us ST users in the very near future.
This new rule builder is shaping up to be incredibly powerful yet simplistic in use.
Couple this power with the upcoming ask Alexa app from @MichaelS …
Our HA is about to take on a whole new level…
I know for a fact that my system is already transforming into a true home automation system in which I will hardly ever touch the app… (yeah right… Me not tweaking… Lol)
I am not a fan of big rules either, they tend to get very hard to grasp when revisiting them. But I’m also not a big fan of having to build two rules just because one can’t do a simple task like, for example, tell me when the fridge door was left open for too long…
Get outta town…
In all honesty, I think rules should not be trigger/event-centric, but controlled-device-centric. That is, if you have ten lights in your home, you should have one rule for each light or group of lights having the same expected behavior, not one rule for each device that can trigger events, trying to control a multitude of devices. That’s what I’m aiming at.
UPDATE: It should be “DO THIS IF THAT” rather than “IF THIS DO THAT”. That may simplify the thinking patterns for some people but complicate it for others…
One more thing coming in the future which may or may not affect SmartThings, but I think will have an impact on UI design for home automation, so I just wanted to mention it…
We already have some community members who have added automatic window openers to their systems. These are becoming more popular, particularly for skylights and in hurricaneprone locations where they are often combined with automatic shutter systems.
There are also some homes which have automatic door openers. I have friends Who use wheelchairs that rely on these and the cost has come way down just in the last two years.
The newest version of HomeKit distinguishes between open/close sensors and motorized doors. The first group is called “door sensors” and the second group is called doors.
This is pretty new for home automation, where in the past the open/close sensors were usually given the name of “door” In most UIs. Not “door sensor.”
However, it seems possible that the distinction will be made in many future systems, if only because the motorized devices are becoming more common.
As I said, we do already have some SmartThings community members using motorized windows.
So just one more thing to think about:
Thank you for pointing that out. ST made sure to append the “Control” word at the end of them. And I passed that separately into the UI, though I removed the word Control. There is no capability that I know of that acts as a contact sensor but is called a Door or a Window. So we have to use Contact Sensor to know if a manual door is open or closed.
[ name: "doorControl", display: "Door", attribute: "door", commands: ["open", "close"], multiple: true, ], [ name: "garageDoorControl", display: "Garage Door", attribute: "door", commands: ["open", "close"], multiple: true, ],
Also, the attribute is called “door” instead of “contact” so there’s a pretty clear separation.
Should I rename the display value to Door Control? Or perhaps Automatic Door?
Most automatic entrances would be very easily integrated into an HA system, If anyone needs help particularly with Record, or Stanley brands pm me and I can probably point you to the correct contact terminal that you could hook a relay up to for simple open commands.
As @schapper05 mentions, I think most of these control devices are integrated with a relay. Some of them have remote controls that allow for integration through a bridge. I don’t think SmartThings defines them as a separate capability the way they do with garage doors. Maybe someday.
Personally, I like the term “automatic door” because that’s the ADA term, so it’s what you usually see in product descriptions and I think most people in the US are familiar with it. Same with “automatic skylight.” I don’t think you see “automatic window,” that often, it seems to be more “motorized window.” Probably just historical convention on all of those.
But I think all these terms are very understandable once someone asks the question so I think you can use whichever seems more sensible to you.
(Garage doors are a separate device class in SmartThings because they allowed for two physical devices: a tilt sensor and a switch.)
@JDRoberts maybe something changed, but the documentation shows Door Control as well as Garage Door Control
Both only have the “door” attribute (open, closed, opening, closing, unknown)
Both only have the open and close commands
They seem to be identical except for the name. Of course, programmers can add any amount of other capabilities, for example, in a garage door device handler: Garage Door Control, Contact Sensor and Three Axis.
I’ll call them Automatic, I like that as well.
On top of the list present in their documentation, I have also added the powerSource capability, as per Platform Update - Release Notes - 4/13/16
I’m blown away how developers here design these programs! Hats off to you guys. Your like mad scientists.
It’s fun to watch how things progress for sure!