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
- Unlocking LoRaWAN / TTN on the LoPy4 within Terkin
- Datenweiterleitung via TTN / LoRa zu Hiveeyes, BOB und BEEP einrichten
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.