Listen to attribute state change seems to trigger too often

Hi,

I am using code to listen for an attribute change in one of my sensors, in this case its a solar powered temperaturenode. The attribute solar informs me the mV coming from the solarpanel powering a sensors battery. Every 2nd message coming from this sensor has this info from the solarpanel.

I am using appdaemon to translate the raw incoming MQTTdata into a “sensor.node_xx” with temperature and attributes (solar, rssi, battery, timestamp) in Home_assistant using self.set_state(…)

The code to listen is the same as in the API docs:

self.listen_state(self.change_light,"sensor.node_f0", attribute = "solar")

The routine self.change_light gets triggered with every change on any of the attributes or value in "sensor.node_f0" and not only when the solar attribute gets updated. I added a self.log statement to follow the triggers and the values for solar.

2017-09-02 10:48:01.805268 INFO Housemode: 2840.0 day
2017-09-02 10:49:57.561074 INFO Housemode: 2840.0 day

Its clear that the value of solar has not changed between messages, the 1st message actually updated the solar attribute but the 2nd did not update the solar attribute.

Any idea what can cause this ?

regards
Cor

i would check all attribute values from that sensor at the start of the callback, to see if something else has changed in the sensor making it trigger the callback.

you are right it should only trigger with solar change.

Hi Rene,

I know which attribute values have changed, I send a timestamp value that is the current “epoch” in seconds and that changes with every datapacket I send to HA.
I havent checked if the default “state” value (temperature for this sensor) also changed or not, maybe that triggers also. I will try and follow the sensor for 30 minutes and dump all attributes via self.log to inspect.

regards
Cor

Hi

This is part of the log, it shows after Housemode, the temperature, timestamp of the last datapacket, B:xxxx =battery in mV, S:xxxx is solar in mV, dB=RSSI

Messages arrive every 2 minutes (more or less) every 2nd message has a possible update for solar. Clearly several messages passed the trigger whilst the value for the solar-attribute is the same still (** xxxx **)

2017-09-03 13:21:07.619963 INFO Housemode: 25.43 2017-09-03 13:21:08 B:2614S:2945 dB:64
2017-09-03 13:25:01.327011 INFO Housemode: 25.5 2017-09-03 13:25:02 B:2614**S:2930** dB:64
2017-09-03 13:26:58.173181 INFO Housemode: 25.56 2017-09-03 13:26:59 B:2618**S:2930** dB:64
2017-09-03 13:28:55.799216 INFO Housemode: 25.62 2017-09-03 13:28:56 B:2618S:2935 dB:64
2017-09-03 13:32:49.037327 INFO Housemode: 25.68 2017-09-03 13:32:49 B:2618**S:2945** dB:64
2017-09-03 13:34:45.721549 INFO Housemode: 25.75 2017-09-03 13:34:46 B:2614**S:2945** dB:64
2017-09-03 13:36:42.609739 INFO Housemode: 25.81 2017-09-03 13:36:43 B:2614S:2930 dB:64

The workaround is easy since I can add an
If (new!=old):

at the start of the routine.

But I also have logged the value of old and new and they are often equal … so the trigger is really wrong.

i guess that @aimc should look at that.
I never used attributes as trigger, so i dont know if its a bug or not, but Andrew can help there.

I like the way things are arranged in Appdaemon, the flexibility is great. Not very used to Python yet but its not too complex.
I hope that Andrew can check this option. Like stated I have a workaround currently.

Bedankt voor het meedenken !

your welcome,
gern gemacht
graag gedaan :wink:

@RegiStax - could you open an issue to remind me to look at this please? I have been a little distracted this weekend.

Hi Andrew,

Ive posted the issue on Github, with a link to this forum included

regards
Cor

1 Like

Thanks, I’ll take a look.

Hi,

The issue was just removed from Github, Andrew has stated that it was working as planned. My advice to anybody having the same setup as me where you try to listen to a change of a sensor attribute is to simply add a if (new!=old) test in the function. That always works fine

regards
Cor

Hmm, looking at this again, it seems like a different issue to the one I was looking at when I closed this - I’ll re-open, and take another look.

If you need more info, I am willing to supply