Having the arm/disarm conditions is so great for me. Previously, my automated window blinds always tripped the motion sensors and I got false negative intrusions. Now I can have my blinds open when SHM disarms but after a delay.
3 Likes
@bravenel - not sure if this is a bug too, but Iām seeing some strange behavior with one of my rules (which only has lux value <= 75 as the trigger). All of my other rules rely on both motion and lux, and when I change modes from Night to Home, they eventually fire (they are all limited to Home) with no issues.
However, this one rule that only relies on lux value wonāt fire, even if the lux reading is below 75 when the mode changes. Having looked through the code, and in talking to you, I realized that state wasnāt changing until the next lux reading came in from the Aeon Multisensor (which may be 10+ minutes later). So, I added (based on your previous suggestion) a condition (but not added to the rule itself) that mode == home.
I thought this would cause things to work correctly, as the mode change from Night to Home would cause a re-evaluation of the rule in this case, right? Or is my logic somehow hosed?
Thanks.
So I finally got the chance to play with this - and just wowā¦ @bravenel This is incredible work - Iām just amazed that at Hub 2.0 it had to be a community member who created this absolutely essential app. Samsung should pay you for your efforts.
I have some suggestions - apologies if these have been requested already (I couldnāt read all 700+ comments!):
- Accept Button presses as triggers/conditions
- Allow set delay time in seconds (I realise that in the Smartapps docs it says the minimum for runIn() should be 60 but it will accept 1 or above and to be honest, in most scenarios that Iāve had to use it you need to use a number of seconds)
- Allow different delay times for each of the actions. I realise that you could just make multiple rules but it would be very nice to have one rule per sequence. For example Iād use it to set up my home cinema, which involves many steps and requires that there is a delay between some of them whilst parts are waiting to boot up) - currently Iāve had to make my own app for this and hardcode the values - would be amazing if I could set it up and tweak it from here in just one rule.
- Assuming that you can do (3.) a further improvement would then be to add more than one of the same type of actions to the rule (for example if I set a light to switch on with a delay of x seconds, then I should have the option to switch another (or the same in fact) light on in another number of seconds - each time alight/switch/whatever is set up, the option to add another of the same type appears. Obviously this is only useful if you set a delay for that action so should only show if you did.
- Somehow (no idea how) allow actions that trigger virtual button presses for virtual devices that users have
Thank you again!
1 Like
Button presses have no state, so they canāt be a condition. To use as a trigger would imply that the rule is already true, and it did its thing when it became true. So now, a button press is simply telling it to do the same thing again, assuming the rule is still true. So this doesnāt fit at all.
ST doesnāt allow apps to do things with time less than 1 minute for perfectly valid reasons. This isnāt supported by ST, so I canāt support it either.
Are you kidding? Iām sorry, but the UI complexity of what youāre describing would sink the app. Make multiple rules.
3 Likes
Button presses have no state, so they canāt be a condition. To use as a trigger would imply that the rule is already true, and it did its thing when it became true. So now, a button press is simply telling it to do the same thing again, assuming the rule is still true. So this doesnāt fit at all.
I understand what you are saying here - so I think I need to change the request to: Actions can occur when either a set of conditions becomes true or false (as currently) and / or when a particular event occurs (like a button pressā¦ or anything else actually). It would undoubtedly be very useful.
ST doesnāt allow apps to do things with time less than 1 minute for perfectly valid reasons. This isnāt supported by ST, so I canāt support it either.
Fair enough - Iām hoping in the not to distant future they change this rule.
Are you kidding? Iām sorry, but the UI complexity of what youāre describing would sink the app. Make multiple rules.
Is it really that bad? you already have point 3. for switches so itās not so crazy to extend it for all actions. Point 4 I grant you is far more complex, but again very useful if you are building a long sequence.
Thanks again for your app - itās already proved itself very useful for me
1 Like
Thanks for taking care of this, its working perfect now. I think I may have found something else too. When choosing a dimmer as an action for either true or false when I click done and is goes back to the rule screen, the actions are blank. Going back into the actions again shows what I choose earlier, clicking done this second time will now show what I have chose on the rule screen. Im seeing this for Rule and Trigger. This has been happing for awhile too just forgot to mention. Im on a note 3 with android 5.0. Thanks
Sounds like it to me too. Thanks for reporting it. Iāll track it down and correct. The rule or trigger should work fine, thatās a UI bug.
1 Like
No, heās not kidding, and yes it really is that bad.
While all us devs are grateful to be able to create the stuff we can create here, coding against this interface implementation is not fun, simple, quick, well documented (though thatās way way better than it was a year ago), versatile or flexible.
It takes me 4 to 5 times longer to get a decent interface than to code the business logic in a typical smart app.
2 Likes
I can see the same thing on my Android tablet. I have no idea why that happens. There are a number of UI weirdnesses about ST on Android, and Iām just beginning to see them.
This has been a pretty consistent happening on Android, and given a slew of recent bugs in Android (including losing the ability to edit rooms to add/remove devices), Iām not surprised.
Based on my minimal review of the code, I canāt see anything obvious in Bruceās code that should be causing this. 
Itās a timing thing, sometimes it works, sometimes it doesnāt.
1 Like
FWIW, Iāve only experienced this when creating a new rule and hit the back button during initial configuration (either because I changed my mind, or made a mistake while defining Conditions). Iāve never had it happen if I go straight through to the end without hitting Back.
I think it must be something going on on the cloud side. I made 5 or more rule machine apps yesterday without issue. This morning, I created two more and had the same issue and can replicate it. On Android if that makes a difference.
Not sure what you are referring to, but there are definitely some cloud issues today. None of my apps that subscribe to mode changes got the mode change events. Big slow-downs in the cloud appear to be responsible.
Bruce, reboot your hub from IDE, that will take care (at least it took care of my similar issues)ā¦
This is what I was referring to. Sorry:
When choosing a dimmer as an action for either true or false when I click done and is goes back to the rule screen, the actions are blank. Going back into the actions again shows what I choose earlier, clicking done this second time will now show what I have chose on the rule screen
OK, thatās some Android mobile app glitch, beyond the reach of us mere mortal app developers.
1 Like
Interestingā¦ this would explain some things. I actually have one rule and one trigger that both rely solely on mode exclusions and lux values. The rule pretty consistently wonāt fire after mode change from Night to Home, but my trigger (for outside lights) fired this morning after mode change from Night to Home (it was still dark enough outside for the lux value to trigger outside lights to turn on).
Given that these are based off the same code base, this is puzzling, but seems likely to be an ST issue.
BTW @SBDOBRESCU, Iāve been regularly rebooting (like every other day) and this hasnāt helped so farā¦ sigh
I havenāt had any issues in about 10 days now, but last night my house was acting as if it was in the Night mode but the IDE and the Android app were showing that mode was Eveningā¦and this morning my house was acting as if it was in Night mode, but IDE and the app were showing the Morning mode. After rebooting everything came back to normal. Hope Iāll get another 10 days of peaceā¦
This is almost exactly what happened to me this morning! Iāve been seeing evidence of apps timing out due to very long delays in the cloud, and evidence these long delays happen in āstormsā. It appears that the node handling our hubs gets overloaded with events from time to time, and things get in a traffic jam. Evidently, sometimes a mode change happens, and some or all of the apps subscribed to mode changes donāt get the event.
1 Like