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.
