Die meisten Projekte bestehen aus einer Waage, die dann manchmal mit “Connectivity” erweitert wird. Bei mir war das umgekehrt, ich entwickle schon länger Connectivity und habe in den letzten 1 1/2 Jahren eine Waage drum rum gebaut.
Die Waage ist weder die günstigste noch die präziseste, für die zwei Imker, die sie für mich testen, passt es aber trotzdem.
In Stichworten:
zwei elektronische Bausteine, die Waagenbox (ADC + Kalibrierspeicher) und die Sendebox (nRF9160 Modem LTE-M/NB-IoT, 3xAA Akkus (LSD, 2000mAh), Taster und RGB LED).
zwei Wagenmodelle, “Badezimmer” zum Starten, “Double” wenn man etwas nachhaltigeres möchte.
Das System ist für 2 Waagen pro Sendebox ausgelegt. Von den 3 AA Zellen sendet die Waage 1x pro Stunde über ein Jahr Daten (UDP basiert, CoAP/DTLS 1.2 CID). Eine Sendbox mit 2 Waagen lief das letzte Jahr durch, aktuell sind 3 Sendboxen und 5 Waagen im Einsatz.
Der Server besteht aktuell aus einem CoAP-S3-Proxy und einer JavaScript Webbrowser App.
Die Kosten für den Materialbedarf liegen bei ca. 200 Euro für die Sendbox und 100-150 Euro für die Waage (je nach Bauform). Und man muss sowohl löten als auch bohren können. Der Nachbau ist daher aktuell nicht für jeden einfach machbar. Die Betriebskosten sind dafür relativ gering; je nach SIM Karte fängt das mit 1 Euro pro Jahr an, wobei ab 4 Euro pro Jahr das Angebot größer wird. Viele Firmen verkaufen ihre SIM Karten leider nur an gewerbliche Kunden.
Falls jemand Lust hat, freue ich mich auf eure Meinung.
Bin persönlich auf der Suche nach einer dreidimensionalen Darstellung von Temperaturwerten
sowie unabhängig davon
einer dreidimensionalen Darstellung von CO2-Werten via Fernübertragung.
Leistet es Dein Aufbau viele erhobene Daten aus einem Bienenvolk von einem oder sogar mehreren Dutzend Sensoren ( Temperatur, CO2 in eine Datenbank oder evtl direkte grafische Auswertung zu übermitteln?
Wenn ja, dann lass uns gerne zu den Details telefonieren. Die Nummer teile ich per PM.
Es werden nur das Gewicht der bis zu 2 Waagen und die Umgebungstemperatur der Sendbox übermittelt.
Die JavaScript Browser App kann aktuell keine 3D Darstellungen (ich bin mir gar nicht sicher, was die 3. Dimension dabei ist), und es wird auch kein CO2 Sensor verwendet, daher keine CO2 Werte.
Das darunterliegende System mit der nRF9160 feather kann zwar erweitert werden, z.B. wenn man eine CO2 Sensor hat, der von Zephyr unterstützt wird oder zumindest über I2C angeschlossen wird. Aber das muss dann entwickelt werden. Ein 3D Anzeige in JavaScript ist natürlich auch denkbar, muss aber ebenfalls entwickelt werden.
Für mich selber, ich bin kein Imker, geht es letztlich nicht darum, hier eine umfangreiches System zu entwickeln, sondern darum, zu zeigen, dass man mit CoAP/DTLS 1.2 CID spürbar längere Laufzeiten von Batterie bekommt, auch wenn man nicht nur 1x am Tag sondern jeder Stunde Daten schickt.
Hallo Achim,
habe dein Projekt mit Interesse gelesen da ich mich auch mit diesem Thema befasse.
Besonders gefällt mit deine Waage mit den Aluwinkeln und 2 Waagezellen (Double).
Leider habe ich bisher nicht gesehen wie du die zwei Zellen an den NAU7802 angeschlossen hast. Vermutlich hast du nicht 2 NAU7802 ADC’s verwendet.
Viele Grüße
Bernd
Leider habe ich bisher nicht gesehen wie du die zwei Zellen an den NAU7802 angeschlossen hast.
Danke für den Hinweis, werde ich ergänzen.
Parallel an einen. Der Stromverbrauch der beiden Zellen liegt dann etwas oberhalb der Maximalwerte der Spec. des NAU7802.
Insgesamt ist meiner Erfahrung, dass ab 14 Bit es sehr schwer wird, besser zu werden. Ich hatte mich auch mit Sensor-Abgleich und rechnerischen Temperatur-Kompensation versucht. Mir erscheint das alles sehr aufwendig und am Ende ist das aktuelle Ergebnis “ohne alles” für die zwei Test-Imker passend.
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.
