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.
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.
@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.
Ich habe bisher nur mitgelesen (bzw kurz mit snooz in einer VK über das Thema gesprochen.). Ich habe bei meiner Box, welche am Projekt teilnimmt die Terkin Software drauf. (Damit kann ich BOB füttern und eine eigene Datenbank gleichzeitig über mqtt befüllen.)
Diese Beute steht neben dem Wohnhaus mit kompletter Infrastruktur (WLAN, Strom).
Ich würde gerne bei LoRa einsteigen, bin aber da noch am “Lernen”. Habe aber noch eine Waage und diverse Microcontroller und bin da offen auch zu experimentieren. Code schreiben kann ich.
Wenn ihr Ideen habt für einen Musteraufbau (benötige zusätzliche Hardware), bin ich dabei mit einzusteigen. (Im Moment kenne ich den SourceCode von Terkin allerdings besser als Bob, aber das sollte kein Problem sein.)
Wie gesagt, die Terkin -Firmware kann schon Lora. Wenn du schon die Terkin Firmware drauf bekommen hast, Ist die Hürde zu Lora auch nicht mehr wirklich hoch.
Der Bob-Firmware Lora beizubringen ist da schon eine ganz andere Hausnummer.
Hardwaretechnisch kann der FiPy LoRa / TTN, du brauchst aber zwingend eine externe Antenne dazu! Wenns etwas günstiger sein darf, nimm statt dem FiPy den LoPy von PyCom.
Wenn ich das richtig verstanden habe, braucht man für Terkin einen Gateway, der die Lora Daten in das “echte” Internet an BOB schickt.
Dafür könnte man einfach LoRaWAN nehmen, was aber quatsch ist, weil man da dann den ganzen IP und TCP undund und quatsch drüber schickt.
Also nimmt man TTN. TTN ist ein datenorientiertes Protokoll, welches auf Sparsamkeit ausgelegt ist. Extra für so sensoren kram.
Jedes Device hat einen eindeutigen Identifier.
Der TTN Gateway nimmt die Daten über LoRA entgegen und sendet sie zu dem TTN Server.
Auf dem TTN Server erstellt man einen Account und hinterlegt ein Skript welches definiert, wie die TTN Daten eines speziellen Gerätes, identifiziert über dessen ID, weiterverarbeitet werden.
Also in unserem Fall einen HTTP Post an BOB.
In manchen Großstädten gibt es bereits TTN Gateways, die man einfach nutzen kann.
Für die PyCom Boards gibt es glaube ich auch TTN-Gateway Software.
TTN braucht normalerweise ein “richtiges” 8-Kanal-Gateway, da gibt es auch eines von PyCom, das pyGate, hab ich auf der Werkbank liegen, @wtf hat es auch,war ändert mit der Stabilität nicht so zufrieden, ich hatte es nur gelegentlich im Einsatz und kann zur Reliabilität zu wenig sagen.
Man könnte auch jedem node, der auch WiFi kann (LoPy, FiPy) als single channel gateway verwenden muss (!) dann aber auch den node anpassen, damit dieser genau auf diesem einen channel auf dem das gateway lauscht auch sendet. Die normale TTN-Implementierung sendet ja random auf allen Kanälen. Meine Empfehlung wäre ein richtiges LoRa-Gateway, damit kann man auch anderen in der TTN community einen Zugang bereitstehen und ist mit weiteren Geräten flexibel.
Hattest Du mir nicht erzählt, daß Du Dich wunderst, was das mit dieser Zunahme der airtime nach dem booten auf sich hat, welche auch nicht mehr unter die etwa 2 Sekunden von allein fällt … und daß dies ein Problem des gateways wäre?
Nope, das ist known-issue von dem HelTec-Steinchen/LoRa-Node. Mit dem PyCom PyGate waren am Anfang auch irgendwelche Sorgen, aber die hab ich denn später eher vor-der-Tastatur-sitzend verbucht.
