Re: [mosquitto-dev] topic alias

[Kurt Van Dijck <dev.kurt@xxxxxxxxxxxxxxxxxxxxxx>]

>    Hello and happy new year to everybody. I am using mosquitto in a home
>    automation project, connecting multiple raspberry and controlling them
>    from a central one using node-red.

I have a home automation running on a heterogenous network of rpi1a,
beaglebone green, rpi0w (recently) and I have an orange pi in the queue.
They all run a similar buildroot configured rootfs.

>    Every raspberry produce or receive messages from/to his gpio ports with
>    this mqtt topics:
>    hostname/gpiox
>    with minor variations.

I'd like to refer to my post on a different mailing list here:
https://lists.suckless.org/dev/1710/32430.html

I explained in that thread how to avoid gpio numbers.

Next step is a package mqttautomation of mine
(https://github.com/kurt-vd/mqttautomation), more specifically
mqttled & mqttinputevent, that takes configuration from retained
messages, and allow interaction with inputs/outputs.

if you feed the distributed system then following retained topics:

	io/garagesensor/inputhw	'key:3 garage'

then the mqttinputevent program on the node with hostname 'garage'
will emit

	io/garagesensor '0|1'

upon reception of key with number '3' on its assigned input event
(/dev/input/eventX).

likewise, mqttled will find a retained

	io/garage/ledhw 'relay:p9.13 home'

and respond to
	io/garage/set '0|1'
by writing 0 or 255 to /sys/class/leds/relay:p9.13/brightness
and sending a retained
	io/garage '0|1'

There are 2 levels of indirection (or aliasing) here:

* the mapping between gpio's and leds and input event numbers
  is handled via the devicetree overlay that is loaded.
  btw, I load devicetree overlays now using the kernel mechanism.
  I dislike very customized devicetree overlay loading using the RPI
  bootloader, or even the beaglebone capemanager, it's all very
  non-portable.
* The mapping between led names/input events and mqtt topics
  is configured using retained messages.

This is my approach to a layered design.
This approach eliminates your need for for topic aliases.

>    When i receive the messages in the central
>    node-red i use them to automate various stuff. The problem is that my
>    automation logic become cluttered with this topics that indicate not
>    what is connected to it but which raspberry and gpio port.
>    One solution to this problem could be to rename all the topics in the
>    raspberrys to represent what is connected to it, but i don't really
>    like that because
>    a) i would lose the indication of where it is connected, which is
>    really useful in case of problems, and
>    b) that would mean continuously editing the many raspberry node-reds
>    when i connect something new or change a port or stuff like that.
>    A better solution would be to use topic forwarding, for example
>    subscribing to the topic raspberry-a/gpio12 and forwarding every
>    message to aquarium/moon-light. That would allow to have automation
>    logic independent from the locations of the devices, but also keep that
>    information for when it's needed.
>    My worry is: how big is the performance penalty of having all topics
>    subscribed and republished with different topics in mosquitto? keep in
>    mind that the raspberry pi it's not the fastest machine around...
>    Is there a better way to have this kind of topic aliasing?

If you care about execution speed, my super light C programs
perform better & boot faster than the average Node-Red thing I've seen.
I run linux+initramfs images of <16MB total.

If you want, I can add more detailed instructions. my mqtt tools
repository not yet very well documented.

I'm still developing some things around it.

Kurt