willkommen bei Hiveeyes, und vielen Dank für die Vorstellung Deines Projekts. Neben den Anleitungen für den Nachbau der Hardware bräuchte man vermutlich noch die Firmware des Geräts.
Ich finde, die Telemetrie über CoAP bietet eine interessante Alternative, die wir bis dato noch nicht für uns erschlossen haben. Es wäre stark, wenn wir durch Deine Firmware in den Genuß einer entsprechende Blaupause kommen würden.
ja, man braucht Firmware und auch den entsprechende Server-Software.
Die Quelltexte sind bereits veröffentlicht:
Server (EPL-2.0, Eclipse/Californium)
Aktuell habe ich den PR für Eclipse/Californium gestellt und werde denn dann Anfang Juni mergen und am 6. Juni ist die Release geplant.
Modem-Client (EPL-2.0)
Der Treiber für den NAU7802 ist da auch dabei, und viel mehr “spezielles” für die Bienenstockwaage gibt es nicht. Den Rest des Clients kann man auch für den Wein-Monitor genauso einsetzen.
Der Modem-Client ist nur ein “Top-Level-Projekt”, da brauch man dann noch
Nordic Connect SDK (Nordic-5-Clause)
und Zephyr (Apache 2.0)
Und die nRF9160 feather v5 ist unter CERN 2.0 (Hardware).
Das ist die Idee des Modem-Clients. Der Client macht aber außer CoAP/DTLS 1.2 CID auch noch jede Menge um das Modem herum, z.B. PSM (Power Saving Mode). Je nach dem, wo der Client laufen soll, müsste man ähnliches auch machen, um dann jeweils ein gutes Ergebnis zu bekommen.
Es ist aber leider nicht ganz so einfach, CoAP zu verwenden. Ich arbeite seit Ende 2014 an dem Thema und erst in den letzten 3 Jahren hat es angefangen, dass man wirklich zeigen kann, was da drin steckt. Aus meiner Erfahrung als langjähriger Eclipse/Californium (Java CoAP/DTLS 1.2 CID Implementierung) und Eclipse/tindtls (DTLS 1.2 CID Implementierung) Entwickler:
nur mit der DTLS 1.2 Connection ID Erweiterung macht DTLS für IoT Monitoring Spaß. Aktuell gibt es da mbedtls (C), pion/dtls (Go), und eben Californium (Java) und tinydtls (C).
für eine einfache Monitoring-Applikation passt ein simpler POST super, man braucht kein Observe/Notify oder ähnliches.
bei den Implementierungen gibt es durchaus Unterschiede, was die Stabilität und Funktion angeht. Es klingt natürlich nach “Eigenwerbung/Eigenlob”, aber Eclipse/Californium ist da doch weit vorne. Funktionen wie “DTLS graceful restart” mach schon ziemlich Spaß. Man kann den Server Updaten, ohne das die Geräte die Verschlüsselung neu aufbauen müssen. Wenn es kein sonstigen Probleme beim Updaten gibt, merken die Geräte meistens nichts davon.
Beim Gerät selber muss man dann leider hauptsächlich bei DTLS aufpassen. Das macht die eine oder andere Firma sehr gerne dicht an TLS. Und das ist nicht wirklich gut. So werden Sockets (und damit der Verschlüsselungskontext) geschlossen, wenn das Netzwerk nicht mehr gefunden wird. Das mag für TCP Sinn machen, für DTLS auch. Aber bei DTLS 1.2 CID ist es etwas “sinnfrei”. Im dümmsten Fall muss man dann bei schlechtem Netzwerk genauso wie bei TLS den Verschlüsslungskontext neu Aufbauen (Handshake), was aber je schlechter das Netz ist, um so weniger erfolgreich ist. Mit einer guten DTLS 1.2 CID Implementierung (wie die in meinem Demo) merkt man zwar das schlechte Netz auch, aber die Kommunikation funktioniert trotzdem besser, da man einfach weniger Nachrichten austauschen muss.
vielen Dank für die Verweise auf die Quellen für die Firmware und das Backend.
Das war auch mein Eindruck. Gut Ding will Weile haben, 10 Jahre nach der Erfindung wird es endlich gut? Tiptop auf jeden Fall, vielen lieben Dank für die zahlreichen Einblicke.
Das ist völlig in Ordnung. Dass Eclipse im MQTT Ökosystem mit Mosquitto and friends weit vorne ist, bzw. die einzige Organisation zu sein scheint, die MQTT++ innovativ weiterentwickelt [1], ist ja kein Geheimnis. Das darf gerne um entsprechende Informationen zu CoAP ergänzt werden.
Ahja, danke. Genau deswegen habe ich sie wohl übersehen, ja ;]. Vielleicht ist es gut, in der nächsten Iteration einen dedizierten Abschnitt “Firmware / Telemetry / Backend” einzuführen?
Summa summarum: Starke Arbeit, vielen Dank für die Entwicklung und Vorstellung.
Der Punkt ist hier das “public internet”. Zu Beginn war es eher in lokalen netzwerken (Lichtsteuerung) Zuhause. Dann gab es immer die “Hoffnung”, dass mit IPv6 die ip-Adressen “statisch” werden, und erst in den Jahren der Ernüchterung dann die Erkenntnis, dass man noch lange mit NATs in irgendeiner Art leben muss.
Für CoAP heißt so etwas ähnliches LwM2M. Zu Sparkplug habe ich keine Berührungspunkte. Aus meiner Sicht ist das Grundproblem von Sparkplug und LwM2M, dass man den Funktionsumfang mit entsprechenden Entwicklungsressourcen abdecken muss. Regelmäßig stecken die Firmen ihre Ressourcen aber lieber in die eigene Applikation und dann kommt irgendwann das bitter erwachen.
Das war 8850 mal mit einer Nachricht erfolgreich (0 Wiederholungen).
5 mal mit 1 Wiederholung, 3 mit 2 Wiederholung und 3 mal konnte die Nachricht nicht
erfolgreich gesendet werden.
Die Waage sendet all 30 Minuten (das habe ich im Laufe der 199 Tage geändert, daher kommen beim zurückrechnen dann nur 8850/48 => 184 Tage raus). Von den 3x 2000mAh NiMH Accus sind noch 23% Ladung übrig.
Zwei weitere Sendeboxen laufen auch stabil (1 bei mir im Garten, 1 bei dem Imker mit der Sendbox oben). 1 Sendebox bei einem anderen Imker hatte innerhalb 70 Tagen zwei Aussetzer, beim ersten Mal kam Wasser in die Sendbox. Das zweite Mal habe ich noch nicht analysieren können.
Auch das 2. mal kam Wasser in die Sendbox an diesem Standort.
Bei den anderen Testaufbauten steht die Sendbox geschützt unter dem Bienenstock,
bei dem mit Wasser im “freien”. Ich werde mal eine höherwertiges Gehäuse testen.
Hier noch die Sendestatistik der 2. Sendebox unter einem Bienenstock:
sieht so gut aus, wie die Statistik der anderem vom August. Muss halt aktuell unter den Bienenstock ;-).
(Ich habe gerade bemerkt, dass die Statistik von der 1 Sendbox im August formatiert wurde.
199-12:04:52 [d-hh:mm:ss], nRF9160 feather/scale v0.9.0+0, 0*8850, 1*5, 2*3, 3*0, failures 3
ist die richtige Anzeige, also 0 retransmission 8850 mal, 1 retransmission 5 mal usw.)
Die Blechschrauben 4,2x9,5mm sind für die 4x6mm Bohrungen und die 2mm Platine 1,5mm zu lang. Dadurch gibt es ein kleines Loch auf der Unterseite. Zumindest legt das die Vermutung nahe, dass das Wasser durch dieses unbeabsichtigte Loch kommt.
Inzwischen habe ich auch die anderen 4 Waagen + 2 Sendbox gewartet.
Beide Sendboxen haben mit den NiMH 2000 mAh Akkus rund 9 Monate im Feld mindestens jede Stunde (teilweise war ich auf 30 Minuten) Daten gesendet. Die Fehlerquote ist “vernachlässigbar”, bei beiden 3 von 9000.
Im Laufe der Zeit haben sich bei 2 Waagen größere Temperaturabhängigkeiten eingestellt. Beim Analysieren ist mir aufgefallen, dass die Waagen im inneren (an den Sensoren) verschmutzen. nach der Reinigung ist die Temperaturabhängigkeiten wieder OK. Kann natürlich auch andere Ursachen haben. Diese erste Waagen wurden auch mehrfach überarbeitet (z.B. Alu gekürzt), so dass da die Spalten größer sind. Ich versuche zum einen, die alten Waagen mal besser abzudichten und zum anderen, (endlich) die zwei neuen, für die das Material schon da ist, zu bauen (und da sehr auf das Spaltmaß zu achten).
Ich habe die Wochen auch meine ersten Erfahrungen mit Solarpanels gesammelt, siehe auch Solarchamp
Zusammenfassung: mit der Kombination aus den neuen Super-Caps (400F), Modem und CoAP/DTLS 1.2 CID läuft das sehr schön. Solarpanel kann man ein ganz kleines nehmen. Aktuelle erste Erfahrungen zeigen eine Laufzeit von 4 Wochen an und zum Laden braucht man dann 4h Sonne.
Vielleicht bekommen dann die neuen Waagen die erste Solar-Sendebox.
So einen ähnlichen Aufbau – Solarpanel in einer Box mit durchsichtigem Deckel – hatte ich auch mal hier: Open Hive Bee Monitoring System, Hardware Overview GSM node der Deckel wurde bei mir mit der Zeit zwar etwas blind, funktionierten bei mir aber dennoch recht gut. Es wird halt sehr heiß in der Box und mit der Dichtigkeit hatte ich irgendwann auch Probleme.
Schöne Box. Ich war bei dem Thema überrascht, wie zumindest die Hochrechnungen sehr positiv stimmen.
Ja, das wurde mir mit dem ersten Testlauf in Sonne auch klar. Inzwischen (seit gestern, Sonntag) gibt es ein Gerät mit einem abgesetzten Solarpanel . Das bereite ich gerade für den “Wintertest” in meinem Garten vor (abdichten). Die Box kommt dann unter den Bienenstock und das Solarpanel ober drauf. Ich denke, dass Solarpanel wird dann als erstes aufgeben. Da gibt es sicher auch “wertigere” Alternativen. Für mich ist aber in erster Linien entscheidend, wie gut das über den Winter mit mehr Dunkelheit läuft.
Die letzten Wochen, seit es im Garten steht, kann man sehen, dass es selbst bei normalen Lichtverhältnissen, teils bewölkt, teils sonnig, sehr gut aussieht. Wenn es im Frühjahr immer noch funktioniert, dann wird das wohl die Energieversorgung für die nächsten Sendeboxen und Waagen.
Das Gerät mit Solarbetrieb lief nun über Dezember/Januar im Garten. Da hat es jeden Tag genug Licht gehabt, um die 3,3mAh auszugleichen.
Ich werde meine Sendboxen entsprechend umbauen, der Adafruit 6091 / BQ25185 ist nun auch erhältlich. Mal sehen, wie das mit einer echten Funk-Bienenstock Waage funktioniert.
Es gibt seit letztem Winter ein neues “fertig” Gerät von Nordic. Damit kann man den Bau von Sendeboxen drastisch vereinfachen. Man “stöpselt” einen NAU 7802 einfach “out-of-the-box” an.
Allerdings kann man da dann nur 1 Waage pro Sendebox anschließen. Zwar könnte man das mit dem BLE chip auch erweitern, aber für’s Erste sollte das nun mal so reichen. Das neue Thingy:91X hat auch WiFi, aber aktuell unterstützt Nordic nicht, Mobilfunk und WLAN zusammen zu benutzen.
Die RGB Led und den Taster spare ich mir auch. Man braucht nun ein SmartPhone/Tablet und kann sich dann mit BLE auf die Sendebox verbinden. Noch ein paar Tage “Indoor” testen, dann raus in den Garten und hoffentlich dann im April unter die Bienenstöcke.
Wir haben sehr gute Erfahrung mit 1nce gemacht. 10 Jahre, einmalig 10 EUR für 500 MB! 1NCE Pricing . Wenn du dich als Imkerei (d.h. geschäftlich!) dort registrierst geht das auch!
Mit Gewerbe ist das erheblich einfacher. Die 1nce kenne ich natürlich auch. Besonders für D sind das gute Karten, zumindest wenn man nicht in eine “Funk-Problem Zone” ist. Die Konkurrenten Melita, Onomondo, Flo.Live und Wireless Logic sind für D auch gut.
In “Funk-Problem Zone” ist Melita mein Favorit, da kann man die meisten SIM Funktionen wie “bevorzugte Netze/gesperrte Netze” nutzen, um in solchen Standorten nicht die Batterie zu leeren. Die meisten anderen bieten nur “gesperrte Netz”.
Über Velocity IoT kann man Flo.Live bekommen, meiner Erfahrung nach auch als Privatperson. Kosten ab ca. 0,69 Euro im Monat.
Preislich gibt es auch Unterschiede, wobei wenn man die 264 Euro für die Waage nimmt, bin ich mir nicht sicher, ob die Preispanne bei den SIM da eine Rolle spielt.
Ich habe zwei Waagen montiert (ein mit 2x 100kg eine mit 2x 50kg, jeweils Vechta Single Point Wägezelle E120A). Ein paar Tage Testlauf im Innenraum, nun seit ein paar Tagen auf der Terrasse.
Die Temperatur am Haus hat leider nicht sehr stark geschwankt (3°) da sieht man keine Temperaturabhängigkeit.
Im Gegensatz zum Vorgänger Thingy:91 (leider ohne Qwiic) braucht das neue Thingy:91X nun mit aktivierten BLE leider 100µA anstatt 30µA. Bei 30 Minuten Sende-Intervall kommt man damit auf ca. 100 Tage von dem 1350 mAh LiPo. Ich habe nun auf 60 Minute gestellt. Mal sehen, was dann raus kommt.
Alte 2-Kanal Sendebox mit Adafruit 6091 Solar-Charger:
Die erste Sendebox (alte Version) habe ich erfolgreich auf Solar umgerüstet. Leider haben die neuen Adafruit 6091 Solar-Charger mit BQ25185 eine PWR LED, die im Gegensatz zum Vorgänger schon durch das anschließen des Akkus angeht. Konsequenz: 2.13mA Ruhestrom anstatt 2.5µA (wenn man die LED mit dem Lötkolben entfernt).
Dafür hat es selbst heute, bei schlechtem Wetter und mit noch halb eingeschneiten Solarpanel (6V 1.2W) bereits die Akkus ein bisschen geladen ;-) (3920mV auf 3990mV).
