Home / Raspberry Pi / MobileAlerts Daten lokal auslesen und lokal nutzen

MobileAlerts Daten lokal auslesen und lokal nutzen


Auch wenn die Sensoren von MobileAlerts nicht die günstigsten sind, so überzeugen sie durch Vielfalt, Qualität, sehr hohe Reichweiten und grandios lange Batterielaufzeiten. Eigentlich die perfekte Wahl, wenn man für eine gute Gesamtleistung bereit ist, den extra Euro zu bezahlen... wäre da nicht der alles verderbende Cloud-Zwang :-/ Zwar bietet MobileAlerts offiziell das REST-Api an, um Daten lokal verwenden zu können, aber die Cloud bleibt mit all ihren Licht- und Schattenseiten. Mir missfällt einfach der Gedanke, meine lokal erhobenen Daten raus in den Ether zu blasen, sie dann wieder aus dem Netz zu angeln, um sie am Ende wieder lokal nutzen zu können. Zudem kommt es leider öfters zu Serverproblemen, was einer Nutzung für kritische Überwachungen sehr entgegensteht.

Als ich vor einiger Zeit über diesen Blog gestolpert bin, fingen meine Augen an zu leuchten. Dort wird beschrieben, wie man mittels Proxyserver seine Daten lokal vom Gateway (MA10000) abgreifen und an einen MQTT-Broker publishen kann. Der Server wird dabei auf einem Raspberry Pi eingerichtet, den wahrscheinlich viele ohnehin am Laufen haben, wenn sie ihre 4 Wände etwas smarter machen wollen. Da der Server ressourcentechnisch sehr genügsam ist, reicht ein Raspberry Pi Zero 2 W vollkommen aus, auch wenn dieser bereits mit anderen Dingen beschäftigt sein sollte. Da mir die Installation und Einrichtung nicht ganz leicht von der Hand ging, werde ich meine Erkenntnisse hier mal in diese Seite gießen.


Installation und Einrichten

Voraussetzung für die Installation des Proxyservers (MAServer) ist ein vorkonfigurierter Raspberry Pi. Wer dies noch erledigen muss und nicht so recht weiß wie, kann hier mal vorbeischauen. Falls noch nicht am Laufen sollte man auch gleich den MQTT-Broker Mosquitto installieren.

Wie vor jeder Installation empfiehlt es sich ein Systemupdate zu fahren, man muss es aber nicht zwingend tun.

Für den Betrieb wird Node.js und für die Installation der Packagemanager npm benötigt. Durch die Eingabe von "node -v" bzw. "npm -v" kann man die aktuell installierte Version auslesen. Erscheint hier keine Versionsnummer und stattdessen so etwas wie "command not found" dann muss es zuerst installiert werden. Ich habe bei mir node v22.15 am laufen, es wird aber auch mit v18.x und v20.x laufen.

Im Anschluss wird das Paket  MMMMobileAlerts von GitHub heruntergeladen, dazu sollte man im Homeverzeichnis stehen, was man nach dem Anmelden ja auch tut. Dann wird die Beispiel-Config kopiert und in Texteditor Nano geöffnet und angepasst.

Die config.json sollte wie folgt angepasst werden:

{
"localIPv4Address": "DeineRasberryPi-IP",
"mqtt": "mqtt://DeineRasberryPi-IP:1883",
"mqtt_home": "MobileAlerts/",
"mqtt_username": "",
"mqtt_password": "",
"publish_type": "default",
"sonoffPublish_prefix": null,
"logfile": "./MobileAlerts.log",
"logGatewayInfo": true,
"proxyServerPort": 8095,
"mobileAlertsCloudForward": true,
"serverPost": null,
"serverPostUser": null,
"serverPostPassword": null,
"locale": "de-DE"
}

Anstelle von DeinRaspberryPi-IP muss die IP-Adresse des Pi eingetragen werden, auf dem der Proxy-Server gerade installiert wird. In meinem Fall war das die 192.168.178.139, diese wird bei dir aber aller Wahrscheinlichkeit nach anders lauten. Ich gehe davon aus, dass der MQTT-Broker ebenfalls auf dem Pi läuft und den Standardport 1883 nutzt. Bei "mobileAlertsCloudForward" sollte true eingetragen werden, wenn die Daten auch weiterhin noch in die Mobile-Alerts-Cloud gesendet werden sollen. Tut man das nicht, so kann man die dazugehörige Handy-App nicht mehr nutzen, ist aber komplett cloudfrei. Genau an dieser Stelle kam es bei mir zu einem Fehler, weshalb wir gleich noch das Originalskript leicht anpassen werden. Erst mal muss aber die config.json gespeichert werden. Dazu [Strg] + [o] drücken und anschließend [Strg] + [x] um Nano zu verlassen.

Wie erwähnt wird jetzt noch schnell der Code vom Proxy-Server angepasst. Bei mir kam es trotz installiertem "request-micro" zu einem Problem bei der Weitergabe der Daten zum MobileAlerts-Server (Cloud). Aus diesem Grund bin ich auf "request" ausgewichen, was einwandfrei funktioniert. Dazu wird die gatewayProxyServer.js im Nano geöffnet - wir stehen noch in "~/MMMMobileAlerts/maserver".

Die Zeile 14 "const request = require('request-micro');" wird durch "const request = require('request');" ersetzt und anschließend mit [Strg] + [o] und [Strg] + [x] speichern und schließen.
Zu guter Letzt muss noch das "request" Package installiert werden.

Jetzt kann das Build vom Servergefahren werden - wir stehen noch in "~/MMMMobileAlerts/maserver".

Dieser Vorgang kann je nach Systemauslastung etwas länger dauern.
Danach kann der Proxi-Server zum ersten mal gestartet werden.

Beim allerersten Start bekam ich die Meldung "Error [ERR_SOCKET_DGRAM_NOT_CONNECTED]... bla bla bla". Beim Blick auf den Gateway-Status (IP-Adresse vom Gateway im Browser eingeben) sah ich aber, dass das Gateway bereits den Proxy-Server erkannt und sich damit verbunden hat. Ich habe dann den laufenden Prozess mit [Strg] + [c] abgebrochen und ihn mittels "node mobilealerts.js" neu gestartet, seitdem läuft er ohne zu murren. Der Server kann hier mittels [Strg] + [c] beendet werden.

Nach <= 7 Minuten sollten dann auch schon die ersten Werte an den MQTT-Broker gesendet werden. Dies kann man z. B. mit dem MQTT Explorer beobachten. Dazu gleich mehr.

Zunächst folgt noch der Feinschliff und zwar das Anlegen eines systemd-Service für einen automatischen Autostart des Servers nach dem Neustart.

Es öffnet sich Nano mit einer leeren Datei, dort wird folgendes eingefügt:

[Unit]
Description=Mobile Alerts MAServer
After=network-online.target
Wants=network-online.target
[Service]
WorkingDirectory=/home/DeinUserName/MMMMobileAlerts/maserver
ExecStart=/usr/bin/node /home/DeinUserName/MMMMobileAlerts/maserver/mobilealerts.js
Restart=always
User=DeinUserName
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target

Anstelle von DeinUserName muss dein Benutzername vom Raspberry angegeben werden. Danach mit [Strg] + [o] und [Strg] + [x] speichern und schließen.
Zum Abschluss folgt noch:

Um zu prüfen, ob der Server läuft, kann Folgendes eingegeben werden:

Beendet wird die Ansicht mit [Strg] + [q].


MQTT

Wie weiter oben erwähnt, lässt sich der MQTT-Broker mit dem MQTT Explorer von Thomas Nordquist ausspionieren, sprich, man kann mit ihm beobachten, welche Daten gerade über den Broker laufen. Nach dem Start klickt man auf + Connections (1) , vergibt einen sprechenden Namen (2), gibt die IP-Adresse vom Broker (4) ein und startet die Verbindung über den Connect-Button (4). Im Fall von Mosquitto und lokaler Standardinstallation wird weder ein Benutzername noch ein Passwort benötigt. 1883 ist der Standardport eines unverschlüsselten Brokers.

Nach spätestens 7 Minuten sollten die ersten Werte im JSON-Format in den Broker purzeln.

Der Topic, über den die Daten gepublished werden, setzt sich aus "MobileAlerts" (Wurzel-Topic (5)), "Sensor-ID" (1. Unter-Topic) und "json" (2. Unter-Topic) zusammen.
Selektiert man im linken Fenster ein JSON (6), so kann man dessen kompletten Topic-Pfad über den [Topic]-Button (7) in die Zwischenablage kopieren.
Das JSON enthält neben den eigentlichen Sensorwerten, z. B. Temperatur und Luftfeuchte, auch einen Zeitstempel und den Batteriestatus.

Mehr zum Thema MQTT gibt es hier und hier. Die Daten können nun mit Node-RED oder Home Assistant weiter verarbeitet werden. 


Retain Message

Je nachdem, wie man die Werte später weiterverarbeiten möchte, macht es durchaus Sinn, die Daten mit einem "retain"-Attribut zu senden. Dadurch werden die zuletzt empfangenen Werte vom Broker gemerkt und, sobald sich ein Client mit entsprechendem Topic anmeldet, werden diese direkt bereitgestellt. Ansonsten müsste der Client so lange warten, bis die nächste Aktualisierung läuft, was hier in diesem Fall bis zu ca. 7 Minuten dauern kann. Das Originalskript unterstützt diese Methode leider nicht, weshalb ich hier eine modifizierte Version von mobilealerts.js bereitstelle.

mobilealerts.js (4 KB)

Anstatt die Datei auf den Pi zu kopieren, kann man diese auch per Copy & Paste auf den Pi schieben. Dazu zuerst die originale mobilealerts.js umbenennen, dann mittels nano neu anlegen und speichern:

Jetzt die hier heruntergeladene mobilealerts.js öffnen, den kompletten Inhalt kopieren und per Rechtsklick in nano einfügen, dann [Strg] + [o] und [Strg] + [x] zum Speichern und Schließen.

Im nächsten Schritt muss die config.json angepasst werden. Bei publish_type "default" durch "retain" ersetzen. Dies kann ebenfalls im nano erledigt werden. Die config.json sieht dann wie folgt aus:

{
"localIPv4Address": "DeineRasberryPi-IP",
"mqtt": "mqtt://DeineRasberryPi-IP:1883",
"mqtt_home": "MobileAlerts/",
"mqtt_username": "",
"mqtt_password": "",
"publish_type": "retain",
"sonoffPublish_prefix": null,
"logfile": "./MobileAlerts.log",
"logGatewayInfo": true,
"proxyServerPort": 8095,
"mobileAlertsCloudForward": true,
"serverPost": null,
"serverPostUser": null,
"serverPostPassword": null,
"locale": "de-DE"
}

Zum Abschluss muss der Server neu gestartet werden. Wurde der Server per systemd-Service bereits gestartet, so kann er wie folgt neu gestartet werden:


Die Option Drucken funktioniert erst ab Netscape V4.0 bzw. I-Explorer 5.0 !
[erstellt 04.01.2026 - letzte Aktualisierung 19.01.2026]