Broadcast: change in the convention the name "level" with channel and define some common home

[nicola-lunghi]

Implements the idea of having different channel of broadcast communication

instead of this

homie / $broadcast /level: level is an arbitrary broadcast identifier. It must adhere to the ID format.

having this

homie/$broadcast/channel channel is an arbitrary broadcast identifier. It must adhere to the ID format.

Some predefined channels are defined by the standard

homie/$broadcast/system for system wide messages
homie/$broadcast/events for events (like a door is open)
homie/$broadcast/new-devices for device auto discovery

[fermuch]

But what if you have 30+ devices, all listening to events?
The downside of using global namespaces for everything is exactly that: everyone needs to receive and parse the messages. If your device isn't that great at parsing messages (not enough capacity, maybe), it'll have a bad time once you have more devices.

I'd go for the dumber way: just listening for door-open and door-closed, or door w/payload open or closed, which the devices can subscribe only if they need to, and are ignored if no device needs that data.

[ingoogni]

Read level (level id) as a complete topic string, this way you can have coarse and very fine grained controll using just one topic string.
$broadcast/lights <- on switches all lights on
$broadcast/lights/purple/ceiling <- on switches all purple ceiling lights

[davidgraeff]

The entire broadcast thing is actually flawed in my opinion. A controller is usually a bigger machine, and is capable of publishing a value to a wildcard topic homie/+/light/set <- on. What use-case is broadcast for?

[davidgraeff]

Found a nice use-case in another issue: #81 (comment)

[timpur]

Remember homies origin is embedded systems, and we have to keep these low level systems in mind as does the mqtt protocol. The broadcast was designed for IOT devices to directly talk to each other or share data that one device might use later for calibrating sensors or something. It could do with some fix ups thought, and this ticket makes a valid example of that

[marvinroger]

Indeed, the point of the broadcast channel was to allow devices to react to very specific events that every device might subscribe to, typically, an intrusion. The @fermuch comment linked above represents a great example. It should be clarified in the convention, though.

[euphi]

I use it for two purposes:

• broadcasting the time (as string)
• broadcasting alerts (intruder, fire).

[nicola-lunghi]

other uses

• new device auto discovery
• system reset/reboot
• mqtt broker ip change
• firmware update?

[davidgraeff]

Mqtt topic wildcards can be used for all mentioned use cases. In my opinion broadcasts are still... Useless :D the one big reason is: they are untyped. On a controller stand point I would not know what do to with broadcasts. Should I display them to the user, like notifications? But then the source is missing. I really have no idea what to do with them.

[fermuch]

Mqtt topic wildcards can be used for all mentioned use cases.

Only if you already know in advance what you need to change. If you don't know, but need to send an alert system-wide, broadcasts are still useful.
My personal use-case for broadcasts, as I pointed before, is to let other systems subscribe to network-wide changes which might not be part of a node.

---

Let's build an ideal system with homie: home control with intruder and fire alerts.
Our system has (a) a smoke detector, (b) cameras/PIR (to detect intruders), (c) light switches, (d) sirens, (e) door lock system.

The structure is something like:

• The (a) smoke detector publishes a node with the property "smoke-detected", which is a boolean.
• The (b) cameras have a node with the property "person-in-view", which is also a boolean.
• The (c) light switches have a node for every light they control. These are settable.
• The (d) sirens also have settable nodes for each siren they control.
• The (e) door lock also is settable.

Now, let's imagine a common use case:

• Every member of your family has an app on their phone that sends a package to signal every sensor they should work on "normal" mode. As I would do it today, this app should send a broadcast message every X time signaling the devices they should continue to operate in normal mode.
• The light switches and sires SHOULD NOT run the alarm system if they are still in "normal" mode.
• The door lock SHOULD operate as a normal door lock.

But now, let's see how it should work when no one is @ home:

• No one is at home, so no phone is sending a broadcast. After a few minutes, the alarm system activates on each device (or maybe there's a controller that switches the whole network?)
• If someone is detected at home, the (b) camera sensors should send broadcasts warning there's someone around. This would also work if in some areas of your home you use PIR instead of cameras.
• When someone is detected, the lights turn on. This is a special logic for the lights, and the logic should be on the light nodes.
• After a while, the (b) sensors still detect someone around, so the alarm switches from alarm to critical. Now a broadcast is sent every minute to warn every node they should operate in critical mode.
• Sirens detect they are in critical mode. They don't need to know who set the critical mode, they just need to turn on the sirens. This logic belongs to the sirens, not to the camera sensor.
• The door now is in locked state and cannot be unlocked unless a special code is sent.

The smoke detector system is pretty similar. It detects a small amount of smoke (maybe a cigarrete?) and after a while of constant smoke, switches to "fire" mode. On this mode, the door unlocks, all lights are turned on, etcetera.

Without broadcasts, building such a system (at least for me!) would be very difficult. Each device in the network would need to keep a full image of what other devices are, what nodes they have, and the state of the properties of each node, so they can select when to switch modes. This, for an embedded system, is no easy task.

How I see you're thinking of it (I'm sure I'm wrong! Please correct me!):

• Each device that has an state should have a node (status?) with a property (current-level) that sets the level.
• The cameras, when they confirm there is an intruder, send an update to every status node, changing their status.

This is not ideal, since you need to keep track of the whole network in your camera/smoke sensor, which involves computing, storing the network in ram, and a lot of code to keep track of everything added / disconnected.

Even if you go the other way around, and the door subscribes to the cameras to switch mode if they detect an intruder, it is still not ideal. Why? Because now the door needs to build the whole network to filter for the appropiate nodes, and subscribe to each; also, now the door system needs to keep track of every device connection status (did the device set their status to lost? If that's the case, we need to ignore their data)

And what would happen if tomorrow you add a device that should still enable / disable the locking of the home security system?
Let's assume you add a PIR sensor, which works kinda like a camera (but provides different nodes and properties). Well, if you use the method of sensor -> lock you're forced to have a beefy board to keep track of the whole network. If you go lock -> sensor, you need to update the firmware of every other device to know there is a new kind of node.

I see broadcasts as the only effective way to alter the status of multiple unknown devices without the need to keep track of the whole network.

[timpur]

@davidgraeff
Just because you don't see a use for them for ESH doesn't mean there isnt. As pointed above people have many uses for them. There purposely left open to be used however and IOT system want to use them. Maybe they don't have a place in a Home automation system like ESH, but they do have a place in the IOT network.

I'd recommend you implement them as notification Chanel's like you said, but allow the user to configure which ones they want to show in ESH as alerts or something. Or just don't implement them.

If sender information is a concern then we could recommend a message structure that includes this but is not required.

Please keep in mind that were not modelling homie around ESH.

[euphi]

@timpur Of course there is a use for them in ESH, too.

However, broadcasts cannot be configured with auto-discovery. But thats exactly the reason why there a needed.

If you have two devices with an "alert" node (e.g. that flashes and turns on a buzzer) and they would announce them as "alert" system, the auto-discovery of the home-automation system still would not know that these two alerts are the same channel.

In the long term we could think about defining some standard information channels from the central controller to the devices, so devices can announce that they will subscribe to the related topic.
Than the topic may look like homie/$controller/alert/state with value "true".

However, to keep things simple, for now I don't see the need for such a feature to be on the roadmap .

[davidgraeff]

As long as MQTT does not support wildcard publish, broadcasts are probably necessary. I see the point.

[davidgraeff]

People have seem to agreed that broadcast levels are not a requirement for now. They should also be specified in a separate document. (Because removing/updating/renaming a broadcast level later on is a major version update, and we want as few as possible for this mqtt discovery convention).