Add group topic to MQTT subscriptions

[smcgann99]

It's quite common with MQTT based devices to have a group topic in addition to the deviceId. This allows users to get around the limitation of MQTT to publish to a wildcard topic, and send messages to any number of devices with one command.

The way I would envision it could work is to add an additional field to the MQTT setup screen for a group topic. (or more for maximum flexibility as then you can have the same devices in multiple groups) There is already topic prefix and suffix so adding group will not be a breaking change, as devices will still be subscribed to the usual topics. Assuming the group topic is not blank, then the device would then subscribe to the normal topics as well as the group topic. The group topic basically replaces the deviceId allowing all devices in the group to receive the same messages. If the normal topic is oxrs/cmnd/oxrs1 then group topic might be oxrs/cmnd/groundfloor. You can create as many group topics as needed and apply to the relevant devices.

Possible use cases could be updating a clock, setting backlight at night, background colour as a visual indicator of a set alarm zone, displaying weather information, a global thermostat display, and whatever ingenuous uses people may devise.

I think this would add additional flexibility and reduce the amount of coding required on the server.

Thoughts ?

[moinmoin-sh]

I see the idea behind this request and there could be scenarios where it looks like making thing easier, but ...

• it adds another layer of configuration in the backend (NR) which needs to be maintained
• it only works for common (system) parameters like color, brightness, ... because all tile related parameters would require that all your grouped devices have the same scren/tile layout
• screens that are power cycled have to be updated with the group information whenthey come online again

I'm not sure if a group topic is a real win for the TouchPanel?

[sumnerboy12]

The more I think about this one, the more I think about how easily it is solved in NodeRED and whether we need to complicate the firmware.

Using NodeRED gives you a lot more flexibility and control IMO.

[plains203]

I feel this feature is not a great fit for these devices & the aim of the firmware.

[smcgann99]

Obviously these are just my thoughts, and I understand some reticence to change the way things are and worries about "mission creep", but I'm only trying highlight some things which I know the wider audience will ask about.

it adds another layer of configuration in the backend (NR) - Taking a clock as an example, I would have to write the code to update this now anyway, perhaps as a part of a routine that updates 1 device, or a routine that updates all the clocks and then sends to multiple devices. Group topic would allow the latter option to be much simpler, and easier to maintain. Indeed I could add as many new devices that required the clock element as I want, without ANY additional code, just by adding them to the "clock" topic. Extracting all the common elements to their own routine, would make the NR code easier to read and understand and is is more inline with the NR way of doing things.

because all tile related parameters would require that all your grouped devices have the same scren/tile layout - Well that's not strictly true, only the common elements would need to be the same, but its likely that if I wanted a common tile, it would fall into the same place on each device for constancy of the appearance. Other tiles can all be unique to the device.

screens that are power cycled have to be updated with the group information when they come online again - This is true with or without group topic, and is easily handled in the same way, indeed with the group topic the common elements could simply be set to retained on the broker. With a routine running to publish the latest values.

Using NodeRED gives you a lot more flexibility and control IMO I'm not sure what you are saying here , the group topic would add more flexibility, and at the end of the day nobody is forced to make use of it.

[plains203]

Some of the commonality could quite easily be handled by using variables in your node red flows and then would be able to easily use the same block of code for multiple screens in one flow.

[smcgann99]

I don't really understand the push back on this one, its a very ubiquitous feature on most MQTT based systems. eg https://www.openhasp.com/0.6.3/configuration/mqtt/

I totally appreciate you have all managed without it, but that doesn't mean that people wouldn't find it very useful. To implement only requires an additional subscription, the payloads can then just get passed to the existing code. Anyway I can't really add any more to this, so may have to accept defeat ;-)

[sumnerboy12]

Closing due to inactivity and a general consensus that this functionality could be handled by NodeRED.