Hello community :)
Today we have something that some people have been asking for: the connection to our own MQTT server for remote operation and monitoring.
A quick word about how our iOS/Android app works. The app automatically connects via the phone's internet connection to one of our servers, which runs an MQTT broker. For this you need a QR code, i.e. an ID. This ID represents the main topic of the user, the user only has access to this topic.
At the same time, the LTE bridge that we offer connects to the same server with exactly this topic. This means that we have an existing connection between the bridge and the app on the phone. The bridge ultimately sends HTTP requests to the system on the Raspberry Pi, which then issues a response, which is then sent by the bridge to the server and thus to the app. The bridge and the system on the Raspberry Pi must therefore be on the same network.
Now, of course, some people have thought, why buy an LTE bridge when I already have a router with a SIM card in my motorhome? Because the data has to be sent back and forth between the app and the motorhome somehow... so there has to be a server in between (unless you only work locally, but that would be pointless). From the router to the server is no problem, the server has a static IP that always stays the same. The other way around is more difficult.
In addition, you would have to give every user access to the server somehow, which would firstly be time-consuming and secondly not very smart.
I could now bombard you with a lot more technical blabla about why and how things work, but back to the topic:
This is what the flow looks like, a small but nice compilation of some nodes, paired with a dynamic MQTT subscription :)
Step by step:
The inject node "Connect" at the beginning is executed once when the system starts so that the connection to the server is established. It could also be executed at regular intervals, e.g. every few hours, in case the connection should break.
In the function node "set broker & pass" the domain of the broker (or the IP address of the server) is entered, as well as the port (8883 encrypted, 1883 unencrypted), as well as the user name and password for the broker. With "node.send(msg)" we send the first payload to our MQTT node to establish the connection, then we change the action, specify our topic and also send this information to the MQTT node so that we subscribe to our topic. The hash # is a wildcard, so everything that is sent under this topic can be received or sent to it. If you want to use our server, the topic is exactly like the user name, but more on that below. With "force": true we tell the broker that any existing connection should be disconnected and re-established.
As mentioned, the subsequent MQTT node is set up so that we can pass our data to it dynamically.
Once we are connected, the fun part comes: "get topics and respond". Here is an excerpt from the node:
We filter the messages sent by our app, set the appropriate URL to access the HTTP API and prepare the response topic (simply add "ans" after the request topic).
In the first three lines we split the main topic, which consists of the ID and the actual request, and filter out everything that is a response (i.e. contains "ans"). We obviously also get these "ans" messages, since we are subscribed. (I hope you can still follow my Denglisch :D)
Wherever msg.method is set to "PUT", something is switched, i.e. the relays, WiFi relays, dimmers and the heating. Everything with "GET" gives us information about the current states, we have battery, BMS, heating, temperatures, relays, WiFi relays, dimmers and water levels to choose from.
That's basically it, now the HTTP API is requested, the response is converted to JSON and sent back to the MQTT broker on the server with the previously set topic.
Smartphone APP
However, the current version of the app uses a different server. The app therefore needs an update so that you can set up your own MQTT brokers. And of course you need a server on which the whole thing runs.
As soon as the app has been updated, you will have the option of using your own server or continuing to use our servers for a fee. This saves you the need for a bridge if you already have internet access installed in your RV. Or you can use both to be on the safe side in case the bridge or router doesn't have reception for whatever reason.
Requests
The requests are always structured according to a very specific pattern, namely with a "get" string in raw format. In the MQTT Explorer it looks like this:
When we send this command, we receive our response under the topic "<ID>/levelans", with the water level values from the Raspberry Pi.
The whole thing works with the subtopics /batt, /bms, /conniot, /heat, /temp, /relay, /wrelay, /dimmer and /level. We use the /conniot topic for the connection test in the app, i.e. whether the app can establish a connection to the Raspberry.
In order to switch things, we need to adjust our string a little. Here is an example of a relay:
Note that we are still sending in raw format and not JSON. Also pay attention to the upper and lower case and the single quotes. It only works in this particular format unless you edit the corresponding function node, but that is the format that we also use for our app or on the bridge. So the example would turn relay 1 on, with "false" we can turn it off again.
We switch WiFi relays in exactly the same way, except that we use "wrelayId" in the raw string, for example {'wrelayId':'one','state':true}. Always remember to adjust the topic accordingly, in this case to "<ID>/wrelay"
The dimmers can be controlled in a similar way, here too we send "{'dimmerId':'four','state':55}" to the topic <ID>/dimmer and receive a response on <ID>/dimmerans.
Note that the values are like true/false Booleans, if we were to put them in quotation marks it would result in a string and that won't work. The same goes for the dimmers, the value to be set is of type integer, i.e. a simple number, also without quotation marks.
Finally, the heating, for this we simply send a true or false as payload:
Attached you will find the flow from the screenshot above. If you have any problems or questions, please let me know! Otherwise, have fun tinkering and trying things out! :)
Link to the flow:
