Agreed, but many of us do have another point of reference to judge by.
I have multiple Wi-Fi networks as well as multiple cloud services that get used all the time. Streaming video, streaming music, Streaming games, anything Using voice processing including Siri and echo, IFTTT.
As well as all the services on the local Wi-Fi, including the Hue bridge, harmony, Kuna and some other stuff.
I’m not saying we never get Dropped packets or whatever, but only one system has a QOS low enough that we started taking things off of it. And it wasn’t Harmony or Echo.
It’s also not just the Internet connection - if the underlying Cloud system doesn’t have reliable apps/software running on it, the Cloud Platform itself could be the best in the world and you’d still be having these issues.
Again, I really want to like this platform. I was at Samsung when they acquired Smart Things, and had many discussions with the CTO and others (I’ve since left for another company). The vision is solid here for what they want to do. Unfortunately, I don’t think their execution has been up to snuff.
I can live with advanced features needing some additional debugging/work, but when core functionality like mode changes and cron jobs/events aren’t working reliably, there’s simply no excuse other than shoddy development/testing practices.
I hope Samsung/ST gets their act together and addresses these things, because I think they could lead in this market by a large margin and instead of negativity, would breed huge excitement about how this platform is stable and easy to use for both novices (through official Smart Apps) and also for advanced users like those of us here using Rule Machine.
Quite honestly, Rule Machine should be core functionality - Smart Apps could be built on top of this engine if they were architected correctly. Sorry, my $.02…
Credit to the platform itself for supporting Rule Machine and allowing us to implement it. Not all platforms allow this. We are all partners with ST in a way. Let’s keep building.
Removed “At Certain Time” condition due to unreliability (use Time of Day instead, with two different times)
Removed “Valve” condition, to avoid confusion for valves that report on/off
For rule input, “Choose AND, OR, Done” has been replaced with “AND or OR”; “More conditions” is gone, instead it offers another condition (which does not need to be entered). If a rule only has a single Condition, there can only be one rule, which is simply that Condition; now, the rule is filled in automatically for you in that case.
I concur… we can and should keep building. We should also feel like we can hold ST’s feet to the fire when very basic building block functionality is broken in a supposedly ‘mature’ product.
Changing color based on a mode or SHM change would be nice. I change the color of my lights based on whether the house is armed or not. The entry lights turn red at 10% when armed then go red 100% when an alarm is triggered.
Pending cancellation - post #238
"An action called “Turn off these switches after a delay, pending cancellation” has been added. The timer for this will be cancelled if the rule state reverses.
The way I use it is for some lights turned on and off by motion. The rule is based on motion-active for the relevant sensor. That’s the only condition, and that’s the rule too.
For true action, turn on the lights. For false action, turn off the lights with the cancellable delay of x minutes (easiest to test with 1 minute). What happens is this: motion is detected, the rule proves true, the lights turn on. Some time later, the motion stops, the rule proves false, and the turn-off with delay is started. If during the interim of that timer starting, and it finishing, motion becomes active again, the rule would prove true, and the timer would be cancelled. At that point we’d be back to where we were when the lights were first turned on. The lights would have stayed on as long as motion happens again before the timer runs out. The timer will be started over and over, but get interrupted by motion, and cancelled over and over. That’s how motion-controlled lighting works.
I should add, you can do this with Smart Lighting, and it would work pretty much the same way. SL did have a bug in this part, but I think that may have been fixed. Anything that just needs a simple trigger can be done in Smart Lighting, and there is no advantage to using Rule Machine for those uses, and in some cases it isn’t the right app at all.
There was a bug in yesterday’s release of 1.1.14 that caused Time of Day events not to be scheduled correctly, actually, at all. If you downloaded that release, you should get it again. 1.1.14a. Sorry for the inconvenience, another typo. My crack QA team missed it.
Removed “At Certain Time” condition due to unreliability (use Time of Day instead, with two different times) [/quote]
Although this change doesn’t impact me, it breaks backward compatibility. Since Rule Machine has a limit of one time/date condition, if someone previously had a rule with both, it will now be broken. For example, set for a Certain Time OR Time of day (completely different times)… that previous single rule will now have to be split into two rules, each using ‘Time of day.’ I think it might be better to retain Certain Time and just include a warning.
I’m thinking about including Certain Time in a different way, not as a Condition but as a Trigger. A Trigger would be certain events that don’t really fit as Conditions, but could be used to trigger a rule evaluation.
The list of possible triggers I came up with are these: at a certain time, when a Routine runs, when a momentary button is pushed, and when a button device button is pushed/held (Minimote). I’m wondering if this would solve anybody’s problems? It’s not clear to me that this would work for anybody the way I just stated it, because if a trigger causes rule evaluation, that implies for it to do anything, the rule would have to be true, in which case it should already have done its thing. So perhaps a trigger should just run the Actions?
I think a trigger that runs the rule without evaluating for truth first makes excellent sense and will be useful provided The ability to put conditions into the rule is removed if a trigger is used.
Well there are reasons to argue both ways, I have seen exactly this kind of set up trip up a lot of people and you end up having to do a lot of tech-support for something which is kind of operator error but in fact comes about because you asked a question that had no meaning in the context.
If you allow conditions to be included in the rule, people will have a rule “only turn on the overhead light between six and 11 at night” then they will assign that to minimote button, then they will want to know why if the minimote was pushed at four in the afternoon the light came on.
So I am all in favor of what we used to call “manual execution” rules that fire off of a trigger rather than an evaluated truth condition, I just like it to be really clear in the UI that it’s really going to fire as soon as you use that trigger.
You may well have been thinking of all of that already, I just have too many hours of calls trying to untangle confusion around that particular issue, so I just thought I’d mention it.
Uses
Triggers of this type are really useful for widgets, by the way.
That’s very insightful. The idea sort of bothers me because of this. It really is a different app, say “Trigger Machine”. That app would have some triggers (a much longer list than above), and a long list of actions that can be taken, and no logic at all. Smart Lighting sort of does this.
With a trigger machine app, there could still be standard restrictions: mode, time of day, days of week, so that the trigger would only cause action within the bounds of the restrictions.
That would be very cool, because then the same widget or the same minimote button could do different things at different times or under different modes.
By the way, I expect that people will want to use SHM arm state as a restriction. So if you press the button when you’re in armed stay mode it does something but only if you’re in that mode.
This becomes a really easy way to use one nightstand or keyfob button as a toggle between armed/disarmed state.
