Sorry about this problem. This came about from a Global Variable with a space in the name. The bug has been fixed for the next release. In the meantime, please see the PM I am sending you about it.
Hi! I would like to propose an additional feature: option to reference to the triggering device in conditions within the triggered rule, sort of like how actions around private booleans can reference the rule itself.
Here is one use case: I have a rule that I would like to run whenever any of a few contact sensor changes; if a sensor becomes open, one action should be taken, while if a sensor becomes closed, a different action should be taken. The limitation right now, so far as I understand RM 4.0, is that when a "contact sensor changed" event occurs, I have no way of determining whether the change itself was an opening or a closingāI can check only the current state of each of the sensors, but that says nothing about what the actual change was.
Or if this feature is already available and I just haven't found it, I'd love to hear that!
(To be clear: I know I can use any number of workarounds for the above purpose. I'm not trying to say that the behavior is impossible to implement right now, only that the feature would add utility and make rules more flexible and enable more-compact sets of rules.)
This can be done a couple of ways. One is that the last event is available as a string %value%. This could be placed in a variable and tested against.
Another way is the condition called Last Event Device. You can test any of the triggering device's attributes.
the trigger can be anything OR changed. so on a contact you can select opened or closed in the drop down.
I just converted a BC app instance to RM 4. This button device is a Lutron RadioRA 2 keypad. That new RM 4 rule is throwing an error that does not seem to cause problems:
I have a different RM (2.5) rule that "presses" a Lutron keypad (the one in the new RM4 rule) button at 7 am. The new RM 4 button controller rule is thus triggered.
As I said, there seem to be no performance issues, so I'm not asking for any help, it's more for your QA process.
Same error
This error is somewhat of a mystery at the moment. Could you show the rule that is throwing it.
Here it is. I would guess it's due to 2 rules running at the same time as this button controller rule doesn't cause an error when called by pushing a physical button. Button 1 was the button that was pushed via the other RM 2.5 rule.
It has something to do with per mode actions. But we have not been able to reproduce the failure yet. I'm making a 'superstitious' code change in the next release that may correct it.
1 Like
Hi!
If the PM above were to be a workaround, could you let me in on it?
I created some new rules, (love the latest enhancements), lots of GV's with spaces.
I have paused the rule that stops the hub. Same rough time (~0210) 3 nights in a row. Once at an odd time of 0900 (today, had just powered down and back up the hub at about 0500) I will trade off the fun data collection and display, gladly for a hot cup of coffee when I roll out of bed. If the next release is eminent, don't bother. Do what you do! I am thrilled with the platform, and all of the built in aspects that are available.
Thanks,
Frank.
Maybe I am just missing the obvious, but is there any way to specify a temperature range in RM? I am trying to control a ceiling fan based on temperature and want to set up different speeds depending on room temperature and also make sure the fan does not come on below a certain temperature.
This rule works fine for me.
Also note: that for the motion inactive/active I'm using an ecobee remote sensor which doesn't poll a change but every 5 minutes. So using a normal motion sensor you would need to set up some sort of second rule to not update a "normal" motion sensor for a longer period than most or else you will have your fan shutting off every time you don't move much in the room.
That looks like it should work, I was just thinking that having multiple else-if statements using <(temperature) would cause an issue.
This shouldn't be an issue, this is for a bedroom so the fan would only be triggered between certain times.
I must admit it would be nice to have a 'Between' option.
As it stands we have to do what is in the post above. i.e. specify an
IF > than AND IF < than.
Would be nice to have
IF
.> than x
AND
< y.
@bravenel any thoughts on this?
Not a big issue but would just make things easier/more obvious.
That would work also, I don't seem to have any issue with the rule itself running.
Occasionally I don't think ecobee polls (because of their crappy servers) reliably therefore doesn't change speeds/update room temperature readings as much I think it should but I'm eliminating the ecobee very soon and changing to a different sensor.
I have had nothing but issues with HE and Ecobee integration, I was originally using the built in app but it slowed the hub down too much. Recently i switched to the Ecobee Suite Manager, but again I had a massive slowdown on the hub. I suspect it has to do with Ecobee's servers and when they are having issues it slows down the hub. So for now I just disabled the app until I do more testing.
I haven't noticed any slowdowns using the built in integration, but I also have all my wifi devices/integrations segregated onto their own hub, and my zwave/zigbee devices are on their own.
Which the wifi hub does (according to my router traffic info) have over 10x the amount of traffic the device hub has.
Yeah that is probably why you aren't experiencing any issues with the separate hubs. I have everything on one hub. But I also have eliminated most all third party apps/drivers. Everything else runs great though, just Ecobee is problematic. I know their cloud service has a poor track record for up time, seems like multiple times a week sometimes its down.
Does anyone know what "system" variables are available for us to use.
I've had a rummage round the forum but cannot find anything that gives the info I'm after.
I've also had a play and with what I'm trying I'm getting a few "nulls".
I know there is
%now%
%device%
%value%
%time%
%date%.
What I would like to do is in a push notification have something like this.
Fred arrived at 18:00 on 21/10.
In "other" rule engines you can specify these types of variables like this.
Bert arrived at {$time24} on {$date}/{$month}.
This gives Bert arrived at 18:00 on 21/10 for example.
Any ideas/thoughts?
Thanks.
With respect to my prior post, Last Event Device was the missing pieceāthank you for pointing that out, as I had overlooked it before.
I have a different feature request to propose: Could the set of actions triggered by a given rule be atomic, preventing races between multiple instances of a single rule?
Use case for me is that I have some contact sensors (Ecolink Garage Sensor and Ecolink Contact Sensors) that are logging multiple open/close events. Flaw in the devices, I suppose, but they're also listed as officially supported devices, so I think they should be supported with their flaws. To that end, I have selected āsuppress duplicate contact eventsā for each device in my HE, but the duplicate contact events are still being reported. So I have rules that are supposed to trigger things when the contacts "change" to open, but the actions are being triggered two or three times every time the contact sensors open, regardless of whether the event is actually a change from the device's prior state (I wouldn't expect two "open" events in a row would both trigger a "changed" event, but that seems to be the behavior). I have tried using both private booleans and local variables (in different implementations of my rules) to prevent actions from being triggered multiple times, but I think multiple instances of the rule are racing because even private booleans / local variables as backstops to "suppress duplicate contact events" isn't suppressing the duplicate rule actions. I can't imagine a situation where non-atomic sets of rule actions are helpfulāI would think that, for a given rule, it would always be more logical to run through all actions once before letting the rule actions fire again.
Please let me know if some other approach to solving this problem exists that I haven't discovered. Thanks!
Current rule implementation that is causing these issues is below:
1 Like
