Mqtt retain

[firefigther0575]

using it for a week now and it works great!!! stable! but having some issue with the retain properties of mqtt sometimes it doesnt update the sensor and it retains the previous message.

what are youre thoughts on that.

greets

[cyberjunky]

@firefigther0575 I'm not sure, do you have an example, logs to show what exactly is logged?

[bobskee]

Maybe it is not the same issue as @firefigther0575 is experiencing but I had something similar. When I create automations that trigger on 'state or attribute changes' of a p2000_rtlsdr MQTT entity, it first gets triggered because it publishes its 'attributes', followed by another trigger because it publishes the 'state' of the entity [source]. If you include actions or conditions that use the 'state' value it uses the old value of 'state' because that value is not updated yet, but the automation gets triggered earlier than intended because of 'attribute' changes.

[cyberjunky]

@bobskee how did you workaround this, did you manage to change your automation? If so can you give an example for the documentation?

If you haven't got it working, I'm not sure if changing the code can fix this, I can switch the order and first do state and then attribute update, but either one is lagging. Need to look on how other add-ons do this.

[bobskee]

I am not proud of my workaround but in my case it fits my needs. My automations now only trigger on changes of the 'tts' attribute. Everything else is ignored and unused. Then the 'tts' value is checked against a locally cached value (using a input_text helper in HA) to verify it truely changed since the last time the state was updated. If true then continue the automation.

I am very curious how other addons handle those MQTT updates. P2000_rtlsdr is the only project I use where this is an issue (still very grateful for your work!)

[LiquidBlackNL]

Hi all, I think I experience about the same thing. I tried making it visible via Node-Red. :)

Addon config example:

- id: 1001
  name: P2000 NR
  icon: mdi:message-bulleted
  capcode: "*001033216*,*001180000*"

This is a debug dump (from Node-Red) from the sensor. You can see the new_state is a new message from another capcode on the same sensor. You can see everything is updated expect the "state". The state remains the same as the previous message.

old_state:

new_state:

Hope it helps! I think I can work around this myself by using the mqtt topic as a source in Node-Red instead of the sensor by the way.