3 ms·

Speaking only as a Home Assistant novice, not as someone who read the mqtt spec cover-to-cover... I assume the reason was to keep topics to a single responsibi

Speaking only as a Home Assistant novice, not as someone who read the mqtt spec cover-to-cover... I assume the reason was to keep topics to a single responsibility; if a trigger wants to subscribe to light.state= [on,off] notifications, it only wakes up if that single topic gets notified. It would not have to process light.color notifications or light.brightness notifications. Sending the smallest payload to the "correct" topic was probably the goal, especially meaning that battery-operated devices only had to monitor the one topic. (Sending gets more complicated, but maybe it balances out in terms of reducing un-needed wakes due to events you do not care about.) But I agree, that means you lose atomic state change events, unless you also had a topic that had the entire state.

mindslight 3y ago
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.

mindslight 3y ago

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.