Hi, I have been converting lots of devices at my home to allow bi-directional communication with MQTT, such as temperature sensors, energy meters, hue lights and of course my WLED devices. For this, I have a very standardized MQTT topic structure, such that it doesn't matter if the backend device communicates through the Hue API, a 433 MHz HackRF one or a direct connection to the embedded device. All topic can be assumed to be the same.
I have found that the current WLED topic structure doesn't work with this at all, and doesn't make much sense to me. That's why I'm suggesting an overhaul of the MQTT topic structure, which would of course have to be a opt-in toggle in the settings menu (or maybe even a build flag) to avoid breaking existing WLED devices communicating with the current topic structure.
For starters I'm confused why the topics don't allow for bi-directional communicating. Sending commands to the device is expected to be done at the mqttDeviceTopic "top-level" topic, but reading data from a WLED device is expected to be done at different (awkwardly short abbreviations) topics.
The current topic structure seems to be:
<mqttDeviceTopic> (WLED subscribes) send either on/off signal, brightness number or "t" to toggle
<mqttDeviceTopic>/col (WLED subscribes) send color data
<mqttDeviceTopic>/api (WLED subscribes) send API request
<mqttDeviceTopic>/g (WLED publishes) current brightness
<mqttDeviceTopic>/c (WLED publishes) current color
<mqttDeviceTopic>/status (WLED publishes) connected status
<mqttDeviceTopic>/v (WLED publishes) some XML data
This works of course, but is far from perfect when integrating WLED devices with other MQTT-capable devices into a similar topic structure.
I'm currently using a custom build that uses the following bi-directional topic structure (meaning WLED both listens and publishes to the same topics):
<mqttDeviceTopic>/status - 1 or 0, whether the light is on or off.
<mqttDeviceTopic>/brightness - 0 - 255, current brightness of the light.
<mqttDeviceTopic>/color - r,g,b[,w] all 0 - 255, current color (optionally including white) of the light.
I omitted the API calls because I do not use them. I also think that anyone wanting to communicate through the API would make a direct HTTP request instead of going through the trouble to connect through a MQTT broker (and if someone were to connect to the broker, they could just as easily use the topics), but I might be missing something.
What do y'all think of this idea to give the topic structure an overhaul? The topics I listed are just a suggestion of course, but I have found that this works well on my end. It allows for a sort of "abstraction" layer at the MQTT-level; I have some smart-plugs that only publish and listen to the /status topic, meaning that if it were connected to a light, controlling a smart-socket light can be done in the same way as controlling WLED devices and the like.
Hi, I have been converting lots of devices at my home to allow bi-directional communication with MQTT, such as temperature sensors, energy meters, hue lights and of course my WLED devices. For this, I have a very standardized MQTT topic structure, such that it doesn't matter if the backend device communicates through the Hue API, a 433 MHz HackRF one or a direct connection to the embedded device. All topic can be assumed to be the same.
I have found that the current WLED topic structure doesn't work with this at all, and doesn't make much sense to me. That's why I'm suggesting an overhaul of the MQTT topic structure, which would of course have to be a opt-in toggle in the settings menu (or maybe even a build flag) to avoid breaking existing WLED devices communicating with the current topic structure.
For starters I'm confused why the topics don't allow for bi-directional communicating. Sending commands to the device is expected to be done at the
mqttDeviceTopic"top-level" topic, but reading data from a WLED device is expected to be done at different (awkwardly short abbreviations) topics.The current topic structure seems to be:
<mqttDeviceTopic>(WLED subscribes) send either on/off signal, brightness number or "t" to toggle<mqttDeviceTopic>/col(WLED subscribes) send color data<mqttDeviceTopic>/api(WLED subscribes) send API request<mqttDeviceTopic>/g(WLED publishes) current brightness<mqttDeviceTopic>/c(WLED publishes) current color<mqttDeviceTopic>/status(WLED publishes) connected status<mqttDeviceTopic>/v(WLED publishes) some XML dataThis works of course, but is far from perfect when integrating WLED devices with other MQTT-capable devices into a similar topic structure.
I'm currently using a custom build that uses the following bi-directional topic structure (meaning WLED both listens and publishes to the same topics):
<mqttDeviceTopic>/status-1or0, whether the light is on or off.<mqttDeviceTopic>/brightness-0-255, current brightness of the light.<mqttDeviceTopic>/color-r,g,b[,w]all0-255, current color (optionally including white) of the light.I omitted the API calls because I do not use them. I also think that anyone wanting to communicate through the API would make a direct HTTP request instead of going through the trouble to connect through a MQTT broker (and if someone were to connect to the broker, they could just as easily use the topics), but I might be missing something.
What do y'all think of this idea to give the topic structure an overhaul? The topics I listed are just a suggestion of course, but I have found that this works well on my end. It allows for a sort of "abstraction" layer at the MQTT-level; I have some smart-plugs that only publish and listen to the
/statustopic, meaning that if it were connected to a light, controlling a smart-socket light can be done in the same way as controlling WLED devices and the like.