BOB Firmware um Lora erweitern

Hi,

Ich denke es ist recht einfach möglich die BOB FiPy oder LoPy Firmware um eine Lora Funktionalität zu erweitern.
Ping @Andr3as

Die Idee:
Die Sensorbeuten senden anstelle zu Bee-Observer ihre Messdaten über Lora raus.
Die Daten wären:

  • sensor_key
  • Messdaten (Alle als 2 Byte Float)
    – Gewicht
    – Luftfeuchte
    – Temp BME
    – Temp 1
    – Temp 2
    – Temp 3
    – Temp 4
    – Temp 5
    – Temp Out

Das wäre zusammen gerade mal 32 Byte.
Das kann Lora im schlimmsten Fall innerhalb einer Sekunde verschicken.
(250 Bps)

Ein Aufbau könnte so aussehen, dass man mehrere Sensorbeuten haben könnte und sich nur entsprechend Lora Antennen kaufen und einen Zentralen LoPy mit Antenne als Zentrale anschaffen müsste.

Wenn eine Kollision auftreten würde und kein. ACK von der Zentrale kommt, könnte die Sensorbeite eine zufällige Zeit warten und erneut senden.
Collision Detection
In dem Scenario wäre die Zentrale recht Dumm und hätte quasi nur das WLAN und die URL von Bee-Observer als Config.

Alternative: “Collision Avoidance
Die Zentrale fragt von den Sensorbeuten die Daten ab und iteriert über die konfigurierten Beuten.
Die Beuten Antworten, wenn Ihre ID im Request, der von der Zentrale kommt, steht.

Meinungen, oder Einwände?
Damit könnten die Nutzerihre Beuten weiter weg vom Haus. für ca. 60€

Ich würde gar kein “normales” LoRa dazwischen verwenden, sondern gleich die Daten per TTN schicken. Wenn ein Community-Gateway in der Nähe ist – das ist in Berlin sicher so, sollte in anderen großen Städten aber ebenfalls vorkommen – kann dieses Gateway gleich die Daten empfangen und weiterleiten, der oder die Imker:in bräuchte sich nix kaufen und um nichts kümmern. Wenn keine public Gateway in der Nähe ist, bekommt man “richtige” TTN-Gateways auch schon für um die 100 EUR.

LoRa hat generell den Nachteil, dass wir halt nicht so viel Daten über Funk schicken dürfen wie es per WLAN möglich wäre, aber alle 5 Minuten würde funktionieren, siehe Wie viel darf ich per LoRaWAN, wie viel per TTN schicken.

Micro-Python-Code für LoRa / TTN gibt es in der Terkin-Firmware, ggf. kann man sich da einiges abschauen. Siehe auch

Generell würde ich auf Collision Detection verzichten. das macht es komplex und wenn mal ein Datensatz nicht ankommt, würde der nächste ja 5 oder 10 oder 30 oder 60 Minuten (je nach Sendeintervall) später hoffentlich auch kommen. Ein verlorener Datensatz wäre in unserem Szenario denke ich nicht tragisch.

Die Variante “die Zentrale fragt von den Sensorbeuten die Daten ab” wäre ok, wenn der node immer aktiv ist. Falls wir allerdings an batterie- oder solarbetriebene Szenarien denken, dann würde der node zwischen den Messungen im deep sleep schlafen und nur minimal Energie brauchen. Das würde aber zwingend bedeuten, dass der node den Takt vorgibt und nicht auf Anforderung Daten schickt. Klar könnte man das auch timen im Sinn von “alle hören oder senden nur Minute 0-2 nach der vollen Stunde” … Da das gateway aber meist eh in Strom- und WLAN-Nähe sitzt wäre die andere Variante (Gateway empfängt und node sendet wann er will) deutlich einfacher realisierbar wenn wir an low power denken.

Etwas OT, weil es hier aber passt. Die Hiveeyes Terkin-Software ist um einiges mächtiger, stabiler und vom featureset umfrangreicher als die “klassische” BOB-Software. Wir sind damals leider nicht mehr dazu gekommen die Konfiguration der Terkin-Firmware über ein captive portal zu realisieren (FiPy agiert im Konfig-Modus als AP / Webserver und man kann über eine HTML-Seite das Ding konfigurieren), was sehr schade ist. Generell wäre es somit überlegenswert eher bei Terkin das captive portal “nachzurüsten” als die fehlenden features in die “klassische” Bob-Software einzubauen.

@clemens wäre ggf. ne option.

Nur, dass ich eher ein wenig Energie aufwenden wollte für die “normalen” BOB nutzer*innen eine Lösung zu bieten, die quasi einfach Plug&Play ist.

Wie habt ihr das denn bei Terkin mit LoRa gelöst?
Als LoRaWAN Gateway?
Also die gesammte HTTP Kommunikation über LoRa geprügelt?

Es gibt ja bei TTN keine HTTP-Kommunikation auf der Funkstrecke. Der node sendet die Daten raus (normalerweise bei TTN auch ohne ACK), und diese landen dann über irgendein TTN-Gateway–WLAN/Ethernet/Mobilfunk bei TTN auf der “TTN-Konsole” (Server von TTN) von dort werden sie weitergeschickt, z.B. an den BOB-Server oder an den Hiveeyes-Server.

Nach dem Einsammeln der Daten von den Sensoren muss man bei fast allen “einfachen” Funk-Protokollen die Daten speziell encoden und verschicken. Bei TTN hat sich z.B. als Quasi-Standard fürs Encoden Cayenne LPP durchgesetzt. Auf der Gegenstelle dann alles rückwärts und die Verbindung zum Server. Das ist schon noch 'ne Menge Holz, was mit TTN und Terkin schon da wäre.

Autsch. Sorry. Hatte deine erste Nachricht mit dem TTN übersehen.

Da hast du schon n punkt.
Und das mit der 1% airtime ist natürlich auch so ne sache.

@clemens
Ich hab jetzt noch einmal drüber geschlafen.

Ich denke tatsächlich, das gerade auf Grund der duty cycles von 1% bei 868MHz und der sehr sehr starken Abhängigkeit von Datenmenge zu Airtime eine Nutzung von TTN hier einen unnötigen Overhead bedeuten würde.
Ich muss gestehen, dass ich mich mit TTN noch garnicht auseinandergesetzt hatte.
Aber von dem was ich gelesen habe, ist die TTN Implementierung von Terkin für Imker*innen nicht zu bewältigen. Für einen “Halb-Nerds” schon. Wenn man also beides ist, gut. Aber einen normalen Mensch überfordert man glaube ich mit dem Account erstellen, JavaScript einfügen etc. Da ist dann das Captive Portal auch keine wirkliche Lösung.

Es sollte also für die BOB Nutzer*innen ein wenig mehr wie “Plug&Play” sein.
Zumindest, wenn wir uns hier auf das Bee-Observer Projekt beschränken.

Annahme:
Bei den von mir vorgeschlagenen 34Byte würden wir bei SF8 (ca. 170ms AirTime) bsp. alle 20 Sekunden senden können ohne den DC zu überschreiten.

Wir könnten das Protokoll auch auf 21Byte (sogar mit CRC) weiter runterfahren, so dass sogar alle 15Sekunden (SF8) oder 10Sek (SF7) gesendet werden könnte. Dabei würden sich dann die Nodes über einen registration request mit ihrem BOB-Sensor-Key beim Gateway/Relay melden und der Gateway weist dem Node eine ID zu. da würde vermutlich sogar ein Nibble reichen
Abgesehen von der technischen Implementierung wären somit für Bee-Observer noch akzeptable Sendeintervalle von 10 oder 15 Sekunden problemlos möglich.
Ob bei falschem CRC die Daten nur verworfen, oder der Node zum erneuten Senden aufgefordert wird, wäre zu überlegen. Ich tendiere derzeit zum verwerfen.
Bei der “Registrierung” des Nodes an dem Gateway, könnte auch der Gateway das Sendeintervall kommunizieren.

|...1....|...2....|...3....|...4....|...5....|...6....|...7....|...8....|...9....|...10...|...11...|...12...|...13...|...14...|...15...|...16...|...17...|...18...|...19...|...20...|...21...|
| Sen. ID| Pkg Len| Gewicht HX711   | Luftfeuchte BME | Temperatur BME  | Temperatur 1    | Temperatur 2    | Temperatur 3    | Temperatur 4    | Temperatur 5    | Temperatur out  |  CRC8  |

Das wäre dann nur eine Option im Captive Portal mehr.
Da wäre dann ein Eintrag LoRA und die Nutzer könnten zwischen Beute und Zentrale wählen.
Und eben die Spreizung (SF7 - SF11) und das Intervall wählen.

Ja du hast Recht, dass man dann den Vorteil einer bestehenden TTN Infrastruktur nicht Nutzen kann. Aber das geht ja mit Terkin.