Remember, that a rule only does something when rule-truth changes. So you probably have a rule that’s true, and is still true, so nothing happens.
Try making the test < 90, then take the dimmer to above 90 — that makes the rule false. Then take it back below 90, it’s true, and the other will follow.
Again a user error, thanks for the clarification.
Evidently the Android mobile app and Rule Machine don’t play nice together. The Android mobile app does not process a critical UI function correctly, called submitOnChange: true. This function is supposed to force a page refresh when you enter an input, but on Android often this fails to happen. In some places this means that the UI is not presented correctly with respect to your selections. Usually, when you hit Done on a selection page, and then go back into it again, the selection is properly displayed. So if you don’t see what you think you should see, try that.
I have submitted a ticket to support about this, it is a major UI fail in the Android mobile app, making dynamic pages malfunction for the user. It would help if those of you with Androids would also submit tickets to support.
Bruce, do you create backup rules to some of your critical ones just to make sure it executes? I have one rule that turns on/off a night mode virtual switch, the off part seems to always fail every 2 or 3 days.
Submitted a ticket. 20 Char
No, I don’t.
For me, trying to patch over STs shortcomings is a non-starter. I’d rather see the failure, and understand it, than patch over it. But that’s just me. My system has few failures. In the past I’ve discovered that some particular failure was a bug in my own code, not an ST problem. I have to be exposed to all of it to find those things.
You know I submitted the ticket when we first discovered this. Tim is investigating since Nov 11…how many Android updates have been released since then?
Pointless, IMO. It’s clearly a major bug, unaddressed. How long has it been like this?
Well forever and a day if you ask me, probably a couple of days in their time. For this day and age both time frames are a day too long!
Used rule machine to set dimmer switch to 30% on a contact sensor trigger. Fantastic work. Worked on first try. Got me around the known “turn on and set” bug in the stock ST lighting app. Your hard work is much appreciated.
It’s been broken this way since submitOnChange was published.
Are you saying they published a broken item? SMH
Is there any documentation anywhere that goes over all of the different parameters? I have multiple rules setup but I wanted to know what types of functionality is possible to think of new automations. Is for instance, this possible: When pressing and holding a button on a minimote, incrementally dim the lights on a dimmer? IE Wasn’t sure what track event dimmer is; or if adjust these dimmers by: (integer) would take care of this. Again, awesome App.
SHM being broken is a POV thing.
submitOnChange has only ever worked correctly on Android for enum and device selections, I didn’t even know it worked correctly on iOS, so I never said nuttin, cause I didn’t know any better…
I just entered a ticket for this as well, it’s actually holding up some development I’m doing.
No, this isn’t possible. A Minimote simply sends discrete button pushes, at most one every 3 seconds. It can be pushed, or held down for 2 seconds to get 2 different buttons out of one.
Tracking a dimmer is using the value of one dimmer to set another.
I’m not sure if this is a bug or by design so please let me know:
I wanted to a rule to be evaluated repeatedly over a set period of time at x min increments. So I set up the rule, and then went to make a trigger that would keep evaluating that rule. I had assumed that I could just start a new rule that consisted of multiple triggers that were for a “certain time” where each time was 4 min after the next for 40 min (so 10 certain time triggers). However, every time I created a new certain time trigger - the new time that I entered over-wrote the previous times in the previous triggers - so the trigger set up page just looked like a load of time triggers where each one was exactly the same! and editing one would affect all the others. So it was impossible to do in one rule.
Let me know if this is deliberate. I am aware that you cannot have more that 5 time triggers for scheduling ST issues - but I would have assumed that it would be possible to have up to 5 different time based triggers?
Just wanted to give thanks for a great application, seems to replace so many other less capable apps.
I have a question - is it possible to “pre-set” a dimmer? For example, I have a rule set up that turns all my Hue lamps red when Mode=Night. That way, when my motion sensors trigger if I walk through the house to the bathroom at night, I get red light so it doesn’t wake me up too much. If I walk through in the day, they are white as the same rule changed the daylight when Mode=Night evaluated to False.
However, if I use the “set level” to 30, it wants to turn the lights on when the mode changes to night, same when I change mode to Home and want a rule to set level to 85, it wants to turn them on.
What I’d like, and might be missing somewhere, is just to set the dimmer level without turning them on. So when my motion sensors trigger, it already knows what brightness to use and that rule doesn’t need to explicitly state the level.
From the documentation above:
Limitation: a rule may only have at most one each of Days of week, Mode, or Time of day as conditions. If you need logic for two different Time of day periods, that would have to be done in two separate rules. A trigger can have at most one each of Certain Time or Mode change as a trigger event. If you need more time events, that would have to be done in two separate triggers.
This may be upgraded in the future, but due to the scheduling API, there will always be a limit. For now, it’s one.
Unfortunately setting a dimmer level without turning it on is not possible. This is a hardware limitation. You have a few choices.
When a dimmer is turned off it retains the current dim level. This level is used when the dimmer Is turned on.
What i do is trigger on the dimmer on event, then issue a set level command to change the dimmer level based on criteria, mostly lux.
I’m not sure what your trying to do with the rolling timer and the dim level, is this like a slow dim thing?
If you’re looking to automatically manage your dimmer levels based on lux, then autoDimmer is for you. A nice feature about it is that the levels get set the same way if turned on manually or via another app.
This is actually quite tricky, and not actually fully possible due to the way dimmers work. A dimmer will always turn on to its previous level. You can set a new level, but doing so turns on the dimmer.
I struggled with this issue for the same reason you are. I found two solutions. The first, and best, is to use motion controlled lighting, with the dimmer level set appropriately for the mode or time of day. I use mode to do this, with Day, Evening and Night modes, each with their own dimmer levels pre-programed. @Mike_Maxwell has a way to do this with luminance.
The second method entails a custom dimmer device type that supports a special command, resetLevel. What that command does is set the level and immediately turn off the light. You will see the lights flash momentarily, unless they are fairly dim. I drive this pre-programming with modes also.
The first method led to my app called Motion Lighting. It allows you to pre-determine dimmer levels for each mode you want to use for this purpose, and it supports motion on/off and some other handy features. I have another app, not published, that does the second method. If you end up wanting to try that, send me a private message.