Mesh EMH support (deduplication of state&update topics)

[PetricaM]

Hi Chris,

As there are different issues with packets sent to the lights, I've found that using multiple gateways (2 or even 3 :) ) ensures almost 100% reliability in MQTT payloads reaching the lights. However, keeping state and update topics active for all gateways creates some loops (multiple gateways using the same command topic is fine but when using forwarding between update/state topics things get complicated) alongside with additional stress on the MQTT broker. A solution might be to keep state and/or update topics active for only one gateway; instead, if this gateway is knocked out of the wifi or there are problems with NRF boards, the two MQTT topics are not updated anymore.

Would it be possible for multiple gateways to still have enabled the state and update topics however to check if the same message has been previously posted (say in the last 1.5 - 2 seconds) and not post it again as this would be a duplicate of a payload posted by another gateway?

Thanks for the transition support. As far as I've seen, changing between different brightness levels works as expected (for the number of seconds included in the payload); however, turning on or off is done immediately. Is this the intended functionality or is it something I'm missing? I'm getting around this by sending brightness 1 to lights right before turning them off (so that transition from say 255 to off state can be smoother) and then (when turned on) the lights are, again at brightness 1 so transition to a higher brightness level can be done; however, it requires two separate calls to transition from and to desired state.

[sidoh]

Hi Petrica!

Sounds complicated to do correctly. What if hubs have different state? Is there a reason you can't disable updates/state updates on all but one hub?

re: transitions -- that's intentional in that I thought about it and didn't implement it, but not in the way that I don't think it makes sense. It does, it's just work. I'll try to add it before the 1.10 release :)

[PetricaM]

I'm already using multiple hubs, all subscribed to same command topic and only one of them has state&update topics active.

Although the commands reach the lights (even if one of the hubs is offline), reliability of the automations depending on the state/update topics (coming from the single hub) is affected. For different reasons (either Wifi or NRF24L01 issues) the hub with state/update topics enabled is not always online.

However, if all the hubs are subscribed to the same command topic, doesn't this basically mean that they all have the same state and the update/state topics (if subscribed to) will publish the same payloads (with a slight time delay due to network latency/NRF board performance/no. of repeat packets/other factors)?

Another idea :) to use multiple hubs and have them aware of the others so that only one of them publishes state and update (or something similar to):

• all hubs get connected to same command, update and state MQTT topics;
• there's another MQTT topic similar to LWT but commonly used by all hubs and each hub publishes its unique ID incremented based on time of day (or other factors);
• only lowest ID hub will publish state and update payloads to MQTT topics;
• at startup and/or different time intervals, each board checks if there are other boards with lower IDs that are active.

[sidoh]

That does sound neat, but to me it doesn't seem like it strikes the right balance of added complexity and utility.

I'm assuming that you have some control layer over espMH (e.g. HomeAssistant)?

I think the way I would solve this if I needed to mesh is to have all of the nodes emit to different state topics, and have some external service aggregate them. I think it'd be a pretty simple Node-RED flow.