Der RFM zu LoRa gateway war nur in einer Übergangszeit interessant als @einsiedlerkrebs noch RFM nodes hatte und diese weiterverwenden wollte. Heute gibt es keinen wirklichen Grund zuerst mit “Garagenfunk” zu schicken, ausser man hat viele Daten und kommt an die Grenzen der oben beschriebenene faire use policy. Und man hat mit den “direkten” TTN nodes eben auch die Möglichkeit diese ohne eigenes gateway zu betreiben, wenn jemand anderes eines betreibt.
Ja, das ist alter Stand und wir kommen mit der Pflege da nicht hinterher, aktuelles findet man hier im Forum.
;-) Bei mir funkt so was unterm Dach The Things Indoor Gateway | The Things Network das ist mit unter 100 EUR ein relativ günstiges 8-Kanal gateway, das TTN voll unterstützt. Eines von PyCom ist nun auch lieferbar Pycom Pygate 8-channel LoRaWAN gateway das liegte ebenfalls hier auf dem Schreibtisch, habs aber noch nicht ausführlich getestet.
Ja, auf jeden Fall, der Uno ist halt gar nicht auf Stromsparen oder low power getrimmt, es ist ein schönes Bastel-Microcontroller-Board wenn man Strom in der Nähe hat für Batterie ober Solar (mit mehr als ein paar Stunden) aber ungeeignet!
Wenn du Strom bei deinen Bienen hast und auch mit 5 oder 12 V an die Beuten kommst ist es was anderes, bei geplantem Solarbetrieb würde ich mir aber ein board aussuchen, das im deep sleep wenig Strom verbraucht.
Hast du schon Solarzellen bei den Bienen oder sollen die mit ans Gehäuse der Elektronik bzw. auf den Beutendeckel?
Derzeit habe ich noch gar nichts am Bienenstand installiert, doch der Wille es zu machen ist vorhanden :). Es ist prinzipiell möglich, an diesem Stand Strom zur Verfügung zu stellen, doch wäre mir eine unabhängigere Lösung lieber, da ich in Zukunft meine Bienen auch mal wo anders hinstellen möchte, wo definitiv kein Strom vorhanden ist.
Ich vermute, dass es noch keine Lösung für alle Fälle gibt (würde die Wartung vereinfachen). Technisch kommt der FiPy wirklich sehr nahe, doch laut Stromversorgung der BOB-Platine läuft der Solarbetrieb noch nicht so rund oder gibt es hier schon einen funktionierenden Ansatz? Pro Beute wäre das natürlich nicht so kosteneffizient, doch mit HX711 Junction Board für 4 Wägezellen - #15 by weef sieht das schon wieder anders aus.
Was mir auch noch nicht ganz klar ist: Die Bob Plattform mit LoPy scheint die neuere Variante zu sein. Sind die älteren Varianten, welche in der hiveeyes.org-Doku beschrieben sind, noch komplett kompatibel? (Backend etc.)
Ihr stellt ja auch Daten der Forschung zur Verfügung (BeeObserver). Dieses Projekt hat es in der Zeit der älteren Variante noch nicht gegeben.
Die Probleme mit der Solar-/Batterie-Stromversorgung betreffen vor allem die BOB-Software in Kombination mit der hohen Messfequenz von ein paar Sekunden(!) ! Mit der hiveeyes Terkin-Software läuft der deep sleep recht gut, gerade mit dem LoPy. Die verschiedenen BOB-Platinen können mit allen PyCom-Geräten verwendet werden, jedenfalls hatte ich schon den WiPy, den LoPy und den FiPy drauf. Wenn du nur LoRa verwenden willst könntest du den günstigeren LoPy verwenden, wenn nur LTE den GPy, wenn noch nicht klar ist, ob LoRa oder LTE, wäre der FiPy etwas, der ist aber teuer und braucht mehr Energie im deep sleep mode.
Das HX711 Junction Board für 4 Wägezellen erlaubt es nicht 4 Waagen an einen Microcontroller anzuschließen, die 4 Völker wiegen, sondern schließt nur 4 oder 2 (kleinere) Wägezellen parallel, die ein Bienenvolk wiegen!
Nochmals vielen Dank für die wirklich große Hilfe und dem netten Entgegenkommen. Schön langsam bekomme ich einen besseren Überblick bzgl. Möglichkeiten.
Ich werde mit einem LoPy + Terkin beginnen, da es alles abdeckt was ich brauche, wirklich super. Dann werde ich mit der Beschaffung der richtigen Hardware starten. Falls das Angebot mit der BOB-Platine noch steht, würde ich es dankend annehmen.
Das hängt vor allem davon ab wie häufig du Daten senden möchtests, 1x pro Tag, jede Stunde, mehrmals pro Stunde? Ohne es getestet zu haben sollte das 1 W-Panel mit LoRa für ein Sendeintervall von 20 bis 30 Minuten reichen, @Thias hat da längere Erfahrungen.
Bei mir ging sogar ein (stromhungriger) WLAN-Betrieb mit 5 Minuten update und 0,5 W Solarzelle im Frühjahr, siehe Open Hive WiFi Solar / Adafruit HUZZAH das dort verwendete System verbrauchte 90 uA im deep sleep, ich habe gerade Zahlen für den LoPy gesucht und nicht gefunden, wir hatten das afaik aber mal gemessen und sind glaube ich auf 20 uA im deep sleep gekommen.
Problematisch ist immer der Winter, da hier die Sonne schwächer ist. Da könnte man dann auch das Messintervall verändern was in der hiveeyes Terkin-Software aber noch nicht implementiert ist.
Remote per TTN downlink über die TTN-Console kann man schon das Messintervall ändern, hat @Thias netterweise eingebaut, was nicht geht ist eine automatisch Umstellung per Sommer-/Winterzeit oder von November bis Jänner oder wenn die Batterie “low” ist.
Leider nicht, da unser “Chefentwickler” @Andreas gerade anderweitig gut eingebunden ist passier momentan nicht allzuviel. Was mir gerade einfällt und über das wir an diversen Stellen schon gesprochen haben:
Konfiguration über ein captive portal per WLAN, geht bei Terkin momentan nur über eine Konfigurationsdatei
Zwischenspeicherung von Daten vor dem Versand, z.B. alle 10 Minuten messen, Daten aber nur alle 2 Stunden verschicken um Energie zu sparen
Verschiedene Messintervalle nach Jahreszeit / Batteriespannung
Ja, wäre schön, wenn wir das auch in den code mit Nutzung der internen RTC bekommen könnten, die externe DS3231 RTC war ja nur ein workaround für z.B. den T-Call, also board, die auch im deep sleep durch nicht ganz zu Ende gedachtes hardware-Design noch immer viel Strom im deep sleep verbraucht haben. Beim LoPy wäre das ja nicht nötig.
Das Problem ist halt, das ohne batteriegepufferte RTC die MCU Datum & Uhrzeit nicht kennt. Sobald man das weiß, ist eine variable sleep time trivial.
Man könnte die Uhrzeit natürlich auch per Funk bekommen. Da gibt es aber noch nix und das ist das eigentliche Problem.
Bei LoRa müsste ich noch recherchieren, zur Not mit einem downlink, der die Zeit enthält, könnte aber auch schon TTN-mäßig default bei einem downlink dabei sein, weiß ich aber nicht. Ich gehe jetzt erst mal davon aus, dass die RTC weitertickt im deep sleep …
Ja sie tickt weiter, ist aber recht ungenau. Soweit ich das noch weiß mehrere Sec bis min pro Tag. Und wenn der WDT, Coredump oder Hardreset zuschlägt ist die Zeit glaube ich weg.
Ungenauigkeit ist für unsere Anwendung und nötige Genauigkeitsklasse kein Problem, wir können alle 5 Tage die Zeit neu von einem Zeitserver abrufen, und auch wenn sie nicht gesetzt bzw. < 2020-01-01 ist.
auch von mir ein nachträgliches Herzliches Willkommen. @Thias betreibt seinen Meßknoten soweit ich weiß recht ordentlich mit der Terkin Firmware via LoRaWAN/TTN und @einsiedlerkrebs, der bisher noch mit RFM+LoRa funkte, schaut derzeit ebenfalls in diese Richtung.
Hach ja, da gibt es einiges – jedoch nicht in einer kohärenten Liste. Wir gehen meistens sehr stark impulsgetrieben vor, entlang der Anforderungen der Menschen, die hier so reinschneien. Grundsätzlich sind wir aber sehr zufrieden mit dem aktuellen Stand des Gesamtsystems und arbeiten abwechselnd an verschiedenen Ecken, sei es bei den Meßknoten oder am Backend. Infrastrukturwartung nimmt oft einen signifikanten Teil der Zeit in Anspruch, daher sind manche Features vielleicht noch nicht so ausgereift, wie man sie sich bei einem “all inclusive” System vorstellt. Allerdings gibt es hier dafür einige individuelle Schmankerl, die bei solcherlei Systemen oft noch in weiter Entfernung oder überhaupt nicht machbar sind.
Sag gern Bescheid, wenn Du an irgendwelchen Stellen nicht weiterkommst, Du zu spezifischen Dingen gerne weitere Informationen aus erster oder zweiter Hand wünschst, oder Du Dir das Thema Bienenstocküberwachung zur kommenden Saison neu vornehmen willst.