Been following the brewblox development from a distance for a few months. My current setup involves quite some temp sensors and a few relays that all work on a local MQTT based setup. The temp sensors publish their temperatures on a fixed interval to their own topic. All relays publish their current state on a different topic and can be controlled by getting remote MQTT command. I even made a PWM based topic, so the relays can be used as a slow PWM.
So my question… how hard is it to use the brewbox MQTT broker and get my devices into the brewblox interface?
Hope to get som insight, and maybe a little starting help on this
Getting data from sensors/relays to UI is simple: publish MQTT messages to the brewcast/history topic, and it will be automatically made available to be viewed in UI. You can find the spec at https://brewblox.netlify.app/dev/reference/history_events.html
A minimal example for publishing data can be found at https://brewblox.netlify.app/dev/tutorials/pubscript/
(Automatically) publishing events to control relays is possible using the automation service, but is still experimental.
We may also add a widget to the UI that lets users manually publish events.
Getting your sensors and relays to exchange information with a Spark controller would also be possible, but somewhat more complicated - depending on your use case.
Edit: fixed broken link
Hi Bob, am also trying to get subscribed to MQTT messages, using the standard mosquitto broker and mosquitto_sub and mosquitto_pub tools.
The link for the spec is broken above that’s “Four-Oh-Four”, how exactly can I visualize these messages in the UI?
We reorganized the docs, and that info can now be found at https://brewblox.netlify.app/dev/reference/history_events.html
If you want a GUI client for MQTT messages, you can try http://mqtt-explorer.com/
Thanks for that link - does help a bit.
Question: if the spark service is running in simulator/emulation mode, do messages still go out on the bus? Am having trouble subscribing to the tutorial script.py, or is the paho implementation of mqtt different to mine (mosquitto).
Yes. Simulation is done at firmware level. If a service is running a simulation, it starts the firmware simulator inside the container, and then treats it exactly like the real thing.
You mentioned “the standard mosquitto broker” earlier. Are you sending script.py messages to the Brewblox eventbus, or to your own broker?
Ok that helps clear up that possible problem.
I am using the script as copied verbatim, so i guess that means I am using the eventbus.
Also am running into a port conflict now, when starting up the containers. See below:
brewblox_ui_1 is up-to-date
Starting brewblox_eventbus_1 …
brewblox_influx_1 is up-to-date
brewblox_history_1 is up-to-date
brewblox_traefik_1 is up-to-date
brewblox_spark-one_1 is up-to-date
brewblox_redis_1 is up-to-date
Starting brewblox_eventbus_1 … error
ERROR: for brewblox_eventbus_1 Cannot start service eventbus: driver failed programming external connectivity on endpoint brewblox_eventbus_1 (16d0b89dcaa66595e0a8e02380132b442ebaf874d8e07e709a6b47d79e36f3ec): Error starting userland proxy: listen tcp4 0.0.0.0:1883: bind: address already in use
ERROR: for eventbus Cannot start service eventbus: driver failed programming external connectivity on endpoint brewblox_eventbus_1 (16d0b89dcaa66595e0a8e02380132b442ebaf874d8e07e709a6b47d79e36f3ec): Error starting userland proxy: listen tcp4 0.0.0.0:1883: bind: address already in use
ERROR: Encountered errors while bringing up the project.
Error logs at https://termbin.com/lydx
Any ideas appreciated.
Since the last patch, Brewblox by default exposes the 1883 MQTT port. If that’s already taken, it suggests you’re also running another mosquitto broker.
Stop that broker, restart brewblox, and you’ll start getting spark events when listening to MQTT on port 1883.
Great thanks - of course when I installed mosquitto it setup and ran a service on 1883.
All good now.