Is anyone else using the Smart Lighting app and discovering what seems to me to be an obvious logic flaw in the way it works?
When motion is detected it sends an on signal to the bulbs regardless of their current state (one of the benefits of zigbee and z-wave things over something like lightwave RF is the ability to query the status of something). In my particular scenario I’m using Philips Hue bulbs and if I switch the physical light switch on (or off then on) they default to 100% brightness, as you’d expect, then within a minute the Smart Lighting app detects motion on the Motion Sensor and even though the bulb is already on it sends another signal to turn the light on to the last known brightness in SmartThings.
This logic also interrupts other apps, so for example as I have the Hue bulbs I’ve got an app running on my Mac Mini which matches the light to the average colour of the monitor, apart from if I move then the Smart Lighting app kicks in sets the colour and brightness to whatever was set in SmartThings and then the other app quickly takes control again (this usually results in random flashes of bright white when people move.
It seems to me that a simple solution would be IF motion detected AND bulb status NOT EQUAL to ON then set bulb status to ON.
Any one else noticed this behaviour, find it odd and or know how to report these issues to the app developer (Is this one built by Samsung?)
Side Note: Can apps lock devices, i.e. get exclusive rights to it so others cannot change the status? I see lots of scenarios where you would want to override default automation routines like when playing music, or relaxing whilst watching TV.
Thanks,
Matt
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
2
The official solution across the entire product is to use Modes. It’s a weak solution because there is only 1 global mode variable per Location, so you can’t be in both “Vacation Mode” and “Night Mode” for example. And there is no report that lists all of your SmartApps by Mode.
In your example, you would create a “Relax” Mode and have no lighting automations run in that Mode.
The other option is to manually create a set of Virtual Switches representing special scenarios, but not all SmartApps have logic to check a Switch State.
Yes, Have a hue bulb in the landing with a motion detector set up to provide light at night (10%), but if I turn the lamp on it is at 100% until I move, when it goes back to 10%. TBH it doesn’t bother me. I could set the motion not to come on until later in the evening.
I have a very similar motion set up in my landing @onlynik although i also have a motion sensor downstairs to factor in also…
I have so far ended up building 4 rules to achieve something quite simple to try and allow both motion sensors to play nicely with 2 sets of bulbs (one upstairs and one downstairs). This allows motion downstairs to trigger both sets of bulbs on @100% at the darkest times of day (likely use cases going up stairs, getting home etc). Another rule to only turn upstairs on at 100% based on motion during the first part of the day (seems a waste of energy to have downstairs come on if only upstairs & as i work from home am frequently just upstairs). Another for the evening (the hours before a nightlight scenario where you would still want 100% upstairs only)
Finally a night light rule @10% during night hours for the upstairs bulbs / motion sensor combo.
Seems a rather overly complex way to set up these kinds of routines. Only being able to select a single start / end time for each scenario and not actual hours of the day to apply a rule is short sighted. I am considering replacing my motion sensors for ones with lux meters built in to simplify slightly but i am waiting for OAuth issues & secondary user functionality before i invest any further (A Nest Protect with Lightlight may also just fix the nightlight issue LOL) To be able to multi select active times on a rule like the below (but for mobile) would seem far more flexible
Regarding your initial query @mohawk_matt - I completely agree - but perhaps motion sensors with inbuilt lux would also solve your issues as if the light was already on the lux level may already be bright enough to not trigger the rule (as this is a condition you can set)… It would require further investment on your part but suspect it will be the quicker way to resolve it given the lead times of OAuth & adding additional users.
You can technically do what you stated in post one with @obycodes SMARTRULES rule builder app
If motion is detected then turn on “lamp1” to ___ level // unless “lamp1” is already on — whilst in whatever mode or all modes or between certain times etc etc etc
Unfortunately i am an android only home… i found SMARTRULES the other day and was gutted to find its Ios only… a true rules engine via webUI would be gold - perhaps something configurable via Graph to allow quick pc based rule creation would make life so much easier
Thanks for this didn’t know this app existed, although installing it just now and signing in it appears to suffer the same problem as everything else in that my hub is missing due to this OAuth mess. Have you managed to use this app with your hub, I take it you are in the UK? If so how did you manage to persuade it to work?
Thanks,
Matt
Edit: Had a response back from the app developers:
Hi Matthew,
Yes, unfortunately SmartRules is affected by that OAuth bug as well. I can’t believe that it still has not been fixed! As soon as they resolve the issue, if there are any changes required on our end, we’ll definitely take care of them right away.
(A Nest Protect with Lightlight may also just fix the nightlight issue LOL) To be able to multi select active times on a rule like the below (but for mobile) would seem far more flexible
