Remote Konfiguration der Nodes (Firmware/Backend)

@clemens ist das mit der serverseitigen Steuerung des Meßintervalls über eine - bzgl. zukünftigen Vorhaben flexible - HTTP Response wichtig. Gekauft!

@Alex: Die Remote Konfiguration der Nodes wie unter Inbetriebnahme von node-wifi-mqtt-homie mit Hiveeyes Anbindung beschrieben ist schon eine coole Sache! Habe ich auch vor. Ich schrecke allerdings vor einem “großen Ding” wie Homie etwas zurück …

Hallo @clemens,

Homie ist eben kein “großes Ding”, sondern nimmt einem jede Menge Arbeit/Design auf cleverem Wege ab. Guck mal in meine Sketches: Halte ich für ziemlich schlank.

Ich möchte keine Sonderlösung für WLAN, sondern möglichst viel einheitlich managen, ob GSM, WLAN oder Funk. Weiter schläft der node ja auch die meiste Zeit, d.h. man kommt auch nicht drauf. Oder kannst du die neuen Konfigparameter irgendwo (mosquitto) zwischenspeichern?

Natürlich. Ist ja MQTT. Stichwort “retained”. Du gibst dem neue Parameter und eine Stunde später, wenn die Node aufwacht, holt sie sich die Werte/Firmware/Whatever ab. Wenn Du Deine anderen MQTT Nodes an der Homie Topic-Konvention (die ich für durchdacht halte) ausrichtest, hast Du ein fertiges Framework. OTA Updates via Sigfox/LoRa, etc. kriegst Du natürlich nicht hin, ist ja funktechnische Einbahnstraße. Konfig/FW Updates via GPRS/LTE sind machbar denke ich.

Die (optionale) Website, die JSON API, die Handy-GUI funktionieren natürlich nur, wenn die Node gerade nicht schläft. Die muss man aber nicht zwingend nutzen, machen aber bei der Ersteinrichtung der Parameter Sinn. Außerdem kannst Du per MQTT auch sagen: Hey, nicht mehr schlafen gehen oder resette deine Config…oder, oder, oder. Da bist Du völlig frei. (Was eben die Funktechnik hergibt).
Meine LoRa Node (im Bau, Reichweite: krass ~500m mit Metallhalle, Wald und 20 Häusern dazwischen - yay) basiert auch auf dem ESP. Im Normalbetrieb ist der WLAN Teil aus. Zum konfen kommen 2 Magnetschalter ran: Einer zum kontaktlosen ein/ausschalten, ein zweiter um den AP aufzumachen, so dass ich via Handy/Laptop updaten kann.

Daher hast du auch einen lokale mosquitto laufen, oder? Ja, schon cool, der dazupassende MQTT broker ist dazu aber notwendig. Mit einem CSV via HTTP-setting läuft das nicht. Http ist halt universeller, daher möchte ich das von vornherein nicht unbedingt ausschließen und nur komplett auf MQTT setzen. Die Idee die komplette remote config aber auch wieder über MQTT abzuwickeln hat aber natürlich was und alles wäre - ob tx oder rx, sprich Daten vom node zum gateway / Server oder Konfiguration vom Server / user zum node aus einem Guß.

@Andreas hast du als hiveeyes lead software architect ;-) hier schon ma Gedanken reingesteckt? Wie universell sollen wir den “Rückkanal” vom Server zum Gateway “denken”?

Wenn es größere Änderungen gibt, etwa der Tausch von Sensoren, wir man immer auch an die Elektronik ran müssen und könnte dabei gleich das notwendige update machen. Für mich wäre es daher ausreichend nur einige Konfig-Parameter remote ändern zu können.

Es hat aber auch - wie oben geschrieben - Charm die komplette erst-Konfiguration nur mit dem eigenen Handy machen zu können, dann spart man sich - oder zumindest dem Imker, dem man “mal schnell” die fertige Hardware in die hand drückt - vermutlich enorm viel Zeit. Nur Handy auspacken mit dem entsprechenden Wifi connecten, Konfig-Angaben browserbasiert über ein Formular machen, abschicken, fertig! Wäre schon cool!

Die Re-Konfiguration über einen Reedschalter zu triggern finde ich auch gut. Macht Beewatch ähnlich, ich weiß aber gerade nciht für was, glaube bei Inspektion die Waage temorär zu locken, damit keine “falschen” Daten ankommen. Man muss da so eine Art Morse-Code eingeben, wenn ich das auf der Messe richtig gesehen habe. Ist auf jeden Fall besser als RFID, weil es ja mechanisch auf “on” geschaltet wird und sonst keinen Strom beim “warten” oder im sleep mode des Arduinos verbraucht. Man kann den Schlater dann an einen IRQ-Pin hängen und wie einen Alarm behandeln, der den MC auch im sleep mode aufweckt.

Falls du “all in one” hardware, zumindest was MCU, WiFI und LoRa verwenden möchtest und nicht vor dem ESP32 zurückschreckst, dann schau’ dir mal den LoPy an https://www.pycom.io/product/lopy/ der braucht sicher noch ein paar Monate bis der sleep mode entsprechend umgesetzt ist und Pycom macht alles mit MicroPython, vielleicht ist der Arduino-Core für den ESP32 aber demnächst weiter und ggf. gibt es dann auch für den LoRa-Chip dort unterstützung. Bei der MicroPython-Implementierung feht auf technischer Seite momentan der LowPower-suport und die HX711- bzw. ADS-lib.

@clemens

Daher: klares nein. Sondern weil ich nicht auf Cloud-Dienste stehe. Sicherheit und so. Kannst Du aber alles via swarm.hiveeyes.org machen. Ist nix “dazu passendes”, ist Standard. Davon ab: Mosquitto auf z.b. Raspi aufsetzen: 5 Minuten. Es gibt übrigens schon einen für esp8266/esp32

Nö, hat aber ne JSON HTTP API, so funzt das Handy/Web Tool.

Ja und nein.

Eben.

Ja, und es zwingt Dich ja keiner OTA FW-Updates zu nutzen. Ist einfach da, wenn man es nicht braucht, gibt es sogar einen Haken zum disablen im Config Tool. Für mich als (Achtung: der folgende Begriff ist zu hochtrabend) Entwickler ist es aber höllen-praktisch.

Ja und lasse den Konjunktiv weg, es geht schon.

Full ack. Im aktuellen Setup nutze ich ihn zum harten ein-/ausschalten und stoppe damit die Messung beim arbeiten an den Bienen.

@clemens: Jetzt schmunzle ich gerade mal. Von meinem ESP32 LoPy hab ich dir vor 3-4 Monaten am Telefon erzählt :-)
Solange die Libs/SDK noch nicht so weit sind, mache ich erst mal noch nix damit.

Der reine mosquitto wird aber nicht reichen, klar kannst du ihn über Kommandozeile bedienen aber ein frontend wäre schon ganz nett bei dem man dann updateintervall, load cell parameter, usw. einstellen kann, das ist nicht mit dem Aufsetzen einer Datenbank erledigt.

… dazu müsste der aber immer an sein? Oder kann der sich die Dinge auch dann erst holen, wenn er wieder aus dem Schlaf aufwacht?

Jetzt wo du es sagst … ;-) Denke der ESP32-Core für die Arduino-IDE ist noch nicht so weit, habe mir das aber auch schon länger nicht mehr angeschaut. Was tatächlich funktioniert, ist, dass der LoPy über Micropython auf Daten zugreifen kann, die ein RFM95 mit der RadioHead-Lib verschickt.

Dazu müsstest du MQTT mit besagtem Retain benutzen

Du schriebst aber vorher: der dazupassende MQTT broker ist dazu aber notwendig. Darauf bezog sich meine Antwort.
Frontend ist jetzt was anderes. Wenn sich keiner hinsetzt und eine brauchbare MQTT Node schreibt, dann setzt sich auch keiner hin und macht ein Frontend.

Guten Tag,

passend zum Thema kam gerade folgendes rein:

marvinroger starred rttools/hodmin 2 days ago

Hodmin enables you to administrate your Homie-devices via command-line-interface (CLI). It consists of some scripts to wrap homie-administration in some handy commands. If needed, these commands can be used within your own scripts, so interaction with Homie-devices is very flexible. Hodmin does not communicate with a homie-device directly. It instead uses your MQTT-broker to pull / push informations from / to a device.

Egal ob für Homie konkret oder agnostisch dazu, kann man sich dabei vielleicht manches abschauen. Hier geht es beispielsweise um die Konfigurationsparameter eines Geräts:

Viele Grüße,
Andreas.

@Andreas; Hast Du das auf dem Schirm: GitHub - jpmens/homie-ota: OTA "server" in Python for Homie

Jawollja. Danke für die Nennung an dieser Stelle!

Genau sowas, wie rttools/hodmin mit pullCF/pushCF vormacht, sehe ich für eine bestimmte Klasse von Nodes (entspanntes Energie- und Funkbandbreiten-Budget mit Rückkanal): der node suscribed auf einem config channel als client oder broker, der das sicher™ hinbekommt.

In diesem Zusammenhang wollte ich Pulga als Idee für weitere Gedanken erwähnt haben, ein minimaler embedded controller -fähiger mqtt-broker, der zwar einige mqtt features unterdrückt,

[...] Currently Pulga does not consider hierarchical topics (subtopics), only basic topics)

dafür aber Extra-Funktionen bietet:

 * Send/receive files. Considering that the MQTT protocol sends binary messages... [...] 
 * Configuration of the EoT device. [...]
 * Configuration of access to a WiFi infrastructure.  [...] 

pdf 10-25-2017, 1-15-32 AM
(aus: http://eyesofthings.eu/wp-content/uploads/2015/08/SPC15.pdf)


"Software efficiency halves every 18 months, compensating for Moore’s Law.” - David May’s law

1 Like