The MQTT spec is actually quite straightforward and not at all tiring, so if you do end up having a reason to read it, don't hesitate to dig in! (I'm not saying

The MQTT spec is actually quite straightforward and not at all tiring, so if you do end up having a reason to read it, don't hesitate to dig in! (I'm not saying you need to though) I understand the rationale for multiple topics. I went down this road when I was trying to design the layout for my own MQTT-controlled device. I would have really liked taking advantage of topics as something closer to an in-system semantic model, rather than only using MQTT for a bare minimum stream and then stuffing more layers on top. FWIW It's not merely losing atomic state changes that's the problem, but rather that updates can end up out of order. For example sending the commands [/light/brightness = 30, /light/state = on] can end up turning the light on with the previous (perhaps full) brightness before dimming it. And mitigating this by creating an additional topic with the entire state undoes most of the advantages of splitting it out in the first place, leaving more complexity and resource usage for little gain.