Softwaregebastel: Pseudo-MQTT auf den kleinen 841ern

Technik
1

Ich pack das hier nochmal rein, bin bei Freifunk Rhein-Neckar.

Problem 1: Ich wuerde immer mal wieder ganz gerne wissen, wieviele Clients auf meinem AP sind, da hier gelegentlich das Wifi wegschmiert und sich nicht mehr alleine faengt (Gluon 1.1.0, haben ja einige hier das Problem).

Problem 2: Der Freifunkrouter haengt hier in einer DMZ zwischen zweimal NAT, kann also direkt ins LAN keine MQTT-Topics publishen, nach draussen geht.

Da ich im Moment so ziemlich alles was irgendwie (sinnvoll) machbar ist auf MQTT umstelle, fehlt mir ein MQTT-Client/Publisher auf dem Freifunkrouter. Die kleinen 841er haben ja mittlerweile kein opkg mehr drauf, da sowieso kein Platz mehr ist, wie krieg ich da also Mosquitto zum laufen? Und wenn, wie krieg ich die Daten ins LAN?

Mosquitto als Broker laeuft auf einem Raspberry Pi hier im Haus, habe auch noch einen eigenen Broker draussen, Problem Speicherknappheit auf dem 841er bleibt.

Loesung: ich hole mir die Infos per ssh und „publishe“ mit mosquitto_pub vom Broker auf sich selbst. Diesen kann ich dann direkt per MQTT abfragen (prima APP fuer Android MQTT Dash) und wenn noetig kann ich auch noch per Node-Red den ganzen Scheiss in eine Datenbank schreiben (InfluxDB ist mein Freund), Grafana koennte das auswerten, mit Node-Red kann man ja noch jede Menge andere Sachen mit den Daten anstellen.
Hahaha…genau das macht ja Freifunk schon mit Grafana, direkter Zugriff per MQTT tut da aber nicht.

  1. Zertifikatsbasierte Authentifizierung auf dem 841er einrichten.
  2. clients.sh im Ordner /etc/config/ anlegen, zeigt die verbundenen Clients an

batctl tl | grep -cE "\[....W.\]+"

  1. diese mit chmod +x clients.sh ausfuehrbar machen

  2. auf dem Raspberry Pi ein ssh-Skript clientmqtt.sh ablegen, welches sich mit dem FF-Router 192.168.0.15 verbindet, das obige clients.sh ausfuehrt und den Wert, der zum Pi zurueckgegeben wird selbst per mosquitto_pub auf den Broker 10.0.0.252 schickt.

    #!/bin/bash
    anzahl=$(ssh root@192.168.0.15 -t /etc/config/clients.sh)
    #echo $anzahl
    /usr/bin/mosquitto_pub -h 10.0.0.252 -t anzahl -m $anzahl

  3. Dieses Skript per cronjob alle 10 Minuten (oder nach belieben) auf dem Pi starten.
    crontab -e
    */10 * * * * /root/skripte/clientmqtt.sh

Sind die Daten auf dem Broker, kann man mit diesen machen, was man will. Ich moechte auf MQTT nicht mehr verzichten, ein grossartiges Protokoll, Node-Red dazu und alles ist machbar ohne grosses Geschiss.

Anmerkdungen sind willkommen, hat jemand Mosquitto auf seinem Router laufen?
Ich hatte noch mit bish-bosh GitHub - raphaelcohn/bish-bosh: MQTT shell script client, for bash, dash, BusyBox ash and others. Gives you MQTT on anything Unix like, from embedded routers to AIX servers with almost no dependenices. herumprobiert, lief aber mit Busybox nicht richtig, hat das jemand gerissen bekommen?

1 „Gefällt mir“
2

Moin.

Vielleicht was MCU-Mäßiges (Arduino, ESP8266 oder ESP32) an den 841 dranhängen? JTAG, oder seriell?

Iwo hatte ich mal etwas gelesen, das eine Gemeinschft sowas vorhatte.

Gruß

1 „Gefällt mir“
3

Falls das ein Kommentar zu meinem Posting war, die 841er nochmal mit Controllerkram aufzublasen halte ich fuer wenig zielgerichtet, es ging mir eher auf quick&dirty-Pseudo-MQTT-Gebastel und die cleverste Loesung hierfuer.
MQTT-Broker auf ESP8266 geht wohl uebrigens.

4

Moin.

Warum nutzt du dann nicht gleich ein Gerät welches leitungsfähiger ist und wo man deine Vorgaben event. einbauen könnte?

Ansonsten halte ich Meinen da jetzt raus. War halt nur eine Überlegung von mir.

Gruß

5

Noenoe, bin ja froh ueber Deine Kommentare, aber ich verwende so lange wie sinnvoll moeglich, das Zeugs, das gerade da ist und das sind halt mal eine Handvoll 841er und da bin ich sicher nicht alleine hier.

Diese Loesung belastet ja den 841er lediglich immer nur kurz fuer den Aufbau der ssh-Sitzung und den batctl-Befehlt und wer einmal mit MQTT gearbeitet hat, faengt an anders zu Denken,
Ploetzlich geht sehr viel, was vorher nur durch aufwaendige „Systemintegration“ loesbar war und Node-Red als IoT-Klebstoff dazu bringt eine sehr steile Integrationskurve zustande.

6

Wenn der Preis des „kompletten WemosD1&Co“ von rund 7€ ein Problem sein sollte und man schon etwas Übung hat mit den Esp8266, dann kann man auch die „nackten“ nutzen für deutlich unter 2 USD. 3,3V gibt es im 841er mundgerecht und einen ES232-Usb wird sich zum einmaligen Programmieren auch noch in der Debrick-Kiste finden.

7

@adorfer: ich hab hier ueber 30 ESP8266 liegen, ich geb Schulungen damit, nur welches Problem soll ich denn hier damit loesen?

8

Dein Problem ist es vermutlich nicht, es war als Anmerkung für andere gemeint, die evtl. Bedenken haben einen ESP8266 in einen 841er einzubauen, um sich die Autoupdate-Fähigkeit des 841ers zu erhalten.

9

ESP8266 in einen 841er einzubauen, um sich die Autoupdate-Fähigkeit des 841ers zu erhalten.

Jetzt machst Du mich neugierig, ich such mal im Forum, was es damit auf sich hat.

10

Naja, wenn Du auf einem 841er viel mit Portforwarding baust, dann musst Du schauen, wie Du das z.B. über die /etc/rc.local einhängst (wenn es einfach ist) oder wenn Du komplexere Startscripte in /etc/init.d&Co braucht, dann über einen Check in der /etc/rc.local eine „Reinstallation“ der Startscripte triggerst.

Problem ist halt, dass Du auf den Autoupdater der FF-Community sinnvollerweise nicht verzichten solltest, da es durchaus Szenarien gibt, in denen binnen weniger Tage ein Autoupdate ausgerollt werden muss und alle, die es nicht „nehmen“, entweder offline sind oder -schlimmer- das Netz weiter belasten.

1 „Gefällt mir“
11

So, eben war ich mal wieder etwas langsam in der Denke, jetzt hab ich geschnallt, dass es um den Autoupdater geht.

Mir ist noch unklar, ob die /etc/-Ordner beim autoupdate ueberschrieben werden oder geloescht, werden sie denn geloescht? Ich hatte die Hoffnung, dass dort nur „ueberschrieben“ wird.
Ich habe nicht vor, den autoupdate zu deaktivieren.

12
1 „Gefällt mir“
13

Danke, dann leg ich das Skript einfach mal in /etc/config/
Oben geaendert.

1 „Gefällt mir“
14

Wenn man hier MQTT in die Suche eingibt, dann bekommt man nichtmal eine Handvoll Treffer.
Gibt es einen Grund, wieso dieses Protokoll so stiefmuetterlich behandelt wird? Wird der ganze Datenhaufen, den die FF-Wolke da jeden Tag produziert noch per http „zentralisiert“? Welche Protokolle kommen da fuer die Statistiken zum Einsatz und wieso nicht MQTT?

15
16

Ich erinnere mich dunkel an ein striktes Requirement, dass UDP eingesetzt werden musste. Frag mich aber nicht wieso, keine Ahnung.

Vielleicht einfach nur weil man mit Multicast spielen wollte…

17

Es ist die alte Diskussion, dass es prinzipiell n Datensammler im Netz geben können soll. Und das auch ohne „zentralistische Genehmigung“.
d.h. es scheitern alle Protokolle, bei denen sich Knoten bei nur einem/zwei Kollektoren subscriben können. (Oder wie immer auch das jetzt geregelt ist mit push oder pull)

In wie weit das sinnvoll ist oder nicht und ob es vielleicht auch andere Konzepte gibt, die die Anforderung(en) erfüllen können, das sollte man vielleicht in einem separaten Thread betrachten.

18

Auf der Suche nach Möglichkeiten, wie man gluon-basierte (Freifunk-)Router an die Heimautomatisierung anbinden kann, bin ich hier gelandet, und möchte diesen Thread nochmal anwärmen.
Meine ersten Basteleien bestanden auch darin, auf dem FF-Router mit „mosquitto_pub“ und einem Cronjob 5-minütig JSON-Infos an den MQTT-Broker im Heimnetz zu publizieren… Das hat einigermaßen funktioniert, aber offensichtliche Nachteile.
Jetzt ist mir noch was Anderes eingefallen - vielleicht gibt es Meinungen dazu:

  • Ziel ist ja, den Bedarf installierter SW auf dem FF-Knoten minimal zu halten.
  • Auf dem FF-Knoten ist ja respondd schon enthalten.
  • Gibt es eine Respond-Client Software, die auf dem Raspi laufen könnte, und deren Ausgabe man verskripten könnte, um sie an den MQTT-Broker zu „pumpen“?
  • Oder ist das eine Sackgasse/Irrweg?

Letztendlich wäre es aber schön, etwas Upgrade-festes zu haben, mit dem man auch aktiv am FF-Knoten etwas steuern kann, zB das private WLAN aus- und einzuschalten, oder abends das Freifunk-WLAN wegen der Kinder ausschalten kann, ohne eine Zeitschaltuhr verwenden zu müssen. (Ich weiss, cron-Jobs gäben auch eine, aber leider etwas starre Möglichkeit ab, letzteres Ziel zu erreichen).
Auch würde ich letztendlich auch gerne Presence-Detection für ausgewählte Smartphones im FF-Netz ermöglichen, um Lichter an- und auszumachen, wenn niemand daheim ist. (Kinder sind bei mir nur im Freifunk-Netz)

19

Einerseits haben wir dafür einen Patch (»Nachtruhe«, schaltet zwischen 22 und 6 Uhr die AP-SSID aus), andererseits halte ich schon den erzieherischen Ansatz dahinter für Bullenscheiße (wir haben das gebaut für z. B. Fußgängerzonen, wo sich in lauen Sommernächten Nutzer zu Telefonaten häuften). Meine Kinder haben, seit sie ein Smartphone haben, auch einen Datenvertrag; schalte ich also ihnen das WLAN ab, gingen ihre Endgeräte stumpf in die Mobilfunkkonnektivität, auf meine Kosten. Wir haben das bis zum Alter X so gelöst, daß die mobilen Geräte nachts im Wohnzimmer geladen wurden — also effektiv der Nutzung im Kinderzimmer entzogen. Aber eben auch nur nachts, sprich wenn die Kids schlafen sollen; zwischen Aufstehen und Schlafengehen gab und gibt es keine Restriktionen — und gefülhlt ›übermäßiger‹ Konsum dazwischen wird thematisiert und diskutiert.

Das ist definitiv nicht der Sinn eines Freifunk-Netzwerkes.

2 „Gefällt mir“
20

Hi Kai,

Das schreit nach Widerspruch bzw. nach der Frage nach dem Sinn von Freifunk-Netzwerken? Wollen wir nicht alle auch ein bisschen spielen?