Hello I currently develop a cusom node for mqtt communication according to the homie convention . Devices using this "protocol" propagate there capabilities by a bunch of retained messages (in my setup over 450). It is the nature of mqtt as far as I know that you can't determine the sequence when t…

When you publish you have to add a timestamp yourself I believe, mqtt does not have timestamps afaik Or use MQTT explorer , that one keeps track of timestamps

I timestamp can be a solution but the homie convention do not provide this. I read somewhere that after subscribing first ALL retained messages should be sent before a "live" message is published. Therefore perhaps I have to subscribe to the $sys topic. But I do not know which topic is best to chos…

[image] Christian-Me: When this is finished [image] Christian-Me: But how to determine and trigger "this is finshed" ? The short answer, you cannot unless you stop being compliant to the protocol. As was written last year explaining this issue well: [hardillb] MQ…

I had the same thoughts when I first stumbled across the "homie convetion" when openHAB 2.4 was released (and the MQTT binding using it as there future standard). But digging a little bit deeper I found it so compelling that I wrote a controller & receiver plugin for the ESPEasy firmware . This work…

Thank you for pointing me in this direction. I found this post before... Thought perhaps I can get a new idea or trick to solve this minor problem.

I had a similar problem when I started using retained messages in my broker. My automations run when somebody restarts, which isn't always ideal! I now check the .retained flag in NodeRed and ignore messages with that flag set. Now only unretained messages cause automations to run. if (msg.retai…

[image] TexasKevin: My automations run when somebody restarts, which isn't always ideal! If I interpret that correctly then it means that you have mqtt messages which cause actions and they have been defined as Retained. A better concept is to retain the state of the system rather than actio…

So there are multiple situations to account for... In one case an actual change has occurred (someone opened a door) for example. In another case, a system restarted and caused actions to be re-reported (ie. retained MQTT messages) for which other receivers of that information are unaware of the re…

I would have thought that the answer there is to have a notification when someone "when someone restarts". That way, you have a positive indication of state rather than trying to derive a negative indication which is very likely to fall foul of other edge-cases that you are not yet aware of. This …

MQTT determine when the last "retained" message arrived

Developing Nodes

Colin 15 September 2019 20:36 5

I am sure you have considered this possibility and rejected it, but rather than use many different topics for the data could you instead build a single JavaScript object containing all the data and publish that to a single topic?

Topic		Replies	Views
MQTT retain option General	22	4910	4 November 2019
MQTT nodes. Old messages. QOS. Retain General	16	2923	10 September 2019
Access to mqtt retained messages General	17	474	1 May 2023
Using MQTT retained messages to store state between reboots General	25	1842	26 July 2021
Understanding MQTT v5 retain options General mqtt	36	1137	10 June 2023

MQTT determine when the last "retained" message arrived

Related topics