Hallo, ich bin neu hier und habe nun ein paar Tage das Forum durchgestöbert. Wirklich super was ihr hier macht.
Ich habe mich derzeit für RFM entschieden, da mein primärer Bienenstand (derzeit 5 Bienenstöcke) zu weit vom nächsten Router steht, um WLAN vernünftig nutzen zu können. Mit einem RFM Gateway sollte das laut Doku gut funktionieren (ca. 120m Luftlinie) und würde so auch SIM-Kosten sparen bzw. kann am Gateway entscheiden, wie ich mit dem Internet verbunden bin. Zusätzlich könnte ich alle Queue-Nachrichten am Gateway lokal persistieren, falls es temporäre Verbindungsprobleme zum Backend gibt. Da am Stand kein Strom verfügbar ist, muss ich die Sensoren vorerst per Solarpanel betreiben.
Hallo Werner, erst mal herzlich willkommen bei hiveeyes!
Wir haben die RFM-Geschichte schon vor längerer Zeit betrieben. Ggf. könnte es für dich auch interessant sein gleich auf LoRa umzusteigen. Mit dem RFM-Modulen sollten 120 m zwar überbrückbar sein. Wenn das aber nicht line of sight ist und das Gateway dann doch hinter einer dickeren Wand oder nicht im Dachboden ist könnte es mit dem “normalen” Funk schwierig werden. Vielleicht hast du da aber mehr Erfahrung als ich und bist Funker und das ist alles kein Problem für dich … ;-)
Je nach Standort gibt es in deiner Nähe sogar ein TTN-Gateway und du könntest das nutzen, oder du bist der early adopter in deiner Region und betreibst ein TTN-Gateway. :-)
Das nur als kleine Idee von meiner Seite. TTN ist techisch etwas ausgefuchster als normaler Funk auf 868 MHz und mit dem community-Gedanken ähnlich wie Freifunk aufgestellt. Allerdings musst du schauen, ob dir die erlaubte Datenmenge (“faire use policy”) reicht, s. Wie viel darf ich per LoRa-WAN, wie viel per TTN schicken für normale Bienenvölker aber mehr als genug.
Das wäre natürlich sehr schön, nur leider komme ich aus der Softwareecke und fühle mich im Backend wohler
Gute Idee, ich habe in der Doku gelesen, dass schon mal ein RFM zu LoRa Gateway gemacht wurde. Gibt es dafür einen gewissen Grund? Sehe derzeit keinen Vorteil gegenüber der Verwendung von LoRa direkt von der Node aus (außer ggf. höherer Stromverbrauch).
Die neueren Beiträge über LoPy und ähnliches werden mir erst jetzt richtig bewusst, da ich zuvor die Doku auf hiveeyes.org als Referenz genommen habe.
Im 10km Umkreis meiner Region gibt es noch kein Gateway, also könnte ich wirklich ein early adopter sein.
Ich denke, das könnte auch eine Option für mich sein, da sie auch mit dem Arduino Uno kompatibel ist. Doch die 5V machen den Uno nicht wirklich attraktiv für einen Solarbetrieb, richtig?
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.
