I've recently been setting up some automations for my air conditioning system, and I noticed that my rule seemed to be triggering more than it should. I have it set to trigger when the temperature of a particular sensor is *changed*. I think it used to trigger properly, but then started triggering every time that sensor was updated, even if the temperature was the same as the last time. I decided to create a new, very simple RM app to see if it would trigger on every update, or only when the temperature was actually changed. Sure enough, the test rule only triggers when the value changes. Here are some screenshots of the two apps, and the logs created by both.
I tried rebooting my hub, in case that would fix things, but I'm getting the same results after rebooting.
I don't think it's a similar issue. In my case, the problem is not that the sensor is updating too frequently, I just set a 1 minute polling interval for the sake of testing.
The sensor in question is a Sensibo Sky A/C controller, using a community-created Hubitat integration.
Hmm .. that's very interesting. I should look at my fan rule. I have the fan trigger according to temperature using an aeotec multi 6. I wonder if it triggers like that. I'll watch it and see if it's happening to us too. Those Aeotecs are really chatty, so I turned off a lot of logging on them.
I am wondering if there is one decimal missing out?
If the views we see only has 0.1 digit, but the sensor and RM sees two decimals, that could explain it for you... That means that a change from 25.81, to 25,89, will still look like 25.8 in the logs, but a change to RM that might see two decimals. Could that be it? Strange if it is not, but do you see the two digit decimals on temp on the device page?
Dont you have a temperature IF statement to start and stop the actions too, by the way, not on every change?
Such as IF temp is higher that X, then turn on fan, Else off?
You get the logic.
I had thought about the precision of the values at one stage, but as far as I can tell, the temperature is only ever reported to one decimal place by the Sensibo. The temp on the device page is shown to only 1 decimal place, too. I do have at least one other sensor type that reports 2 decimal places, and both decimal places are shown in the logs and in RM when I'm creating rules. Also, even if the precision was the cause, it seems strange that one RM rule triggers differently from the other, given the exact same trigger condition.
You're right, I do have other conditions in the Actions part of the code. You got me thinking that maybe you were onto something, so I just tried modifying my Test app to include some conditions, too. But, as I would expect, the conditions in the Actions still don't cause the Test app to trigger if the temperature has not changed.
But in the lower log picture (Test), it still say it triggers when the temp has not changed (first trigger from top, temp is the same before and after. So it seems to me that the trigger goes off, but the actions do not? Or do I miss something? The thing is, the actions only appears IF the trigger is TRUE, not the other way around. If the actions do not work, then you have set conditions in the action to maybe kill itselves. Fast and easy to do, so did you try to turn on the debug log on the rule? Turn on to the left of Done button(slider) to get more info what the rule actually does.
The whole rule might be helpfull here...
RogerThat
Which timestamp are you referring to? When I look at my screenshot of the log for the Test app, the top 9 entries (from 01:42:37 to 01:50:38) all show the same temp, and no triggering of the rule.
Ah, a bit off in the previous post... But leaving it there anyway, whos perfect... hehe.
But, Is there a way to look in the device drivers code (dev) if the temperature is calculated somehow/reported with two decimals? A small decimal change, could be the reason, I still believe, even if the device page say it only reports one decimal. I have a 0,5 standard deviation in my heater oven/temp automation, and that seems to work just great. Turning power to stuff in a tighter temp window, could give you some of the erratic on off triggers I think you experience. But I see you point, very hard to understand why it triggers, even if you see no change in temp... Hmmm.
Is there a way to actually get more decimals on temp sensoring? Why not two decimals? 25.1, is the same as 21.10, so why not implement that? Could maybe give us an understanding why this behavour happens.
RogerThat
I'm pretty sure the Sensibo device/api itself only reports a single decimal. Even if I view the readings in the Sensibo app, all temps are with only 1 decimal place.
And, even if there were a hidden decimal coming into play, you would expect the 2 rules to react/trigger in the same way as each other, right? This is the part that makes me think something else is wrong.
What if you try to set the second IF to 26.1 and upwards with an increase of 26.11..26.12..26.13 and so on, and se where it changes, will that give the answer?
Just a thought to see where the hidden decimals is. Since trigger register a change, some value has changed, for sure. but the reading 26.1 might be more accurate with two decimals for the trigger event, than you see in the device page and rule values...
Hmm... Interesting case this, But as many sais, KISS...
But I think the strange case here is that the actions are not triggered, even when the trigger event logs that temp has changed, correct?
No, that's not really the problem that I'm seeing. The actions are properly running every time the rule is triggered, but the rule is being triggered more than it should.
In the Test app, the logs are showing every time my Sensibo integration polls for the temperature, which is set to 1 minute for this testing. But this is not necessarily triggering the rule, it's just being logged. Then, if the new temp is different, the Test app is triggering, which is each point where you see "Test Triggered" and "Change detected" in the logs, and then my simple conditional actions are also running ("Temp above 25"). So, the Test app is behaving exactly the way I would expect, and I'm sure this is the way triggers are intended to work.
But in my actual AC app, you can see that each time the temp is updated, the trigger is also firing, even though the temp is the same. The actions are then also run each time, but I didn't include the actions in the logging, because the logs would be too verbose.
Yeah, I did actually experience some error in my bedroom motion light automation just now as well.
The built in Mode manager is set to change to the morning mode(self created mode) at 07:00. But the previous time(was 05:00) still is remembered, even the rule shows 07:00.
Can it be so simple that there is a bad update to DB, so by deleting the whole rule, recreating it, might solve it and also what you see?
I will try this now to see if that is the case. I have tuned this rule quite a few times, so maybe a user input (back/Done) was not correct by me, and it’s somehow got out of sync with view/DB? I would think that the views would show DB values, but maybe not?
The logs clearly showed the built in app changing mode, even the time showed in the rule is set for 7... Hmmm... A bug here?
Looking at it now, I see that several of them miss the right times.
I need to test to delete this whole mode rule, and try over again.
But clearly, there is something strange going on here... Hmm....
Workaround: save the current value in a local variable at the end of the rule, and put an IF at the beginning of the rule that does an Exit Rule if the incoming value matches the saved value.
Yeah, I've put in similar workarounds so that at least my automations aren't going haywire anymore, but I feel like this is a bug worth investigating and fixing properly.
could it be in the driver
sendEvent(name:"nextHeatingSetpoint", value: degrees, unit: getTemperatureScale(), descriptionText: "Next heating setpoint is ${degrees}", displayed: true, isStateChange:true)
Hmmmm... I don't know the answer to that, but once again, the thing that throws me is the fact that 2 different apps with the exact same trigger condition respond differently to the exact same trigger event. Surely, we should expect the 2 apps to respond in the same way, regardless of what the driver is doing?
it they are user drivers you could have a look for isStateChange:true, just click in the code window, press ctrl F, type in isStateChange:true, press enter. any hits will show up.
not saying this is the problem, might help ruling things out
