HARVY2 - BATTERIEFREIER LORAWAN-STROMSENSOR

Moin,

setzt jemand schon den „Harvy2 drahtloser LoRaWAN-Stromsensor“ ein?

https://www.dezem.de/portfolio/datenerfassung/lorawan/harvy2-batteriefreier-stromsensor/

Wird von der Berliner Firma deZem GmbH hergestellt.

Hein09

Ich hab mir das Datenblatt angesehen.
Von auswertbaren Protokollen steht da nichts drauf.
Und durchschnittlich 1A pro Leiter würde bei 3 Phasen ca. 700W Dauerlast bedeuten.
Für einen Haushalt ziemlich viel.
Aber grundsätzlich eine gute Idee.
Und LoRaWAN ist ja nicht dafür gedacht permanent Daten zu übermitteln. Sondern eher kurze Datenpakete ein oder mehrmals täglich.

Hallo habre, der Harvy2 benötigt nur ca. 0,5mA an irgendEINEM seiner 4 Analogeingänge - alle anderen können dann auch überwacht werden, ohne dass darüber Energy Harvesting möglich sein muss.

Er ist eigentlich für all die Situationen gemacht, in denen über irgendeine der vermessenen Adern immer mindestens ca 200W fließen. Mit einem Stromwandler, der durch 2000 teilt, hat man dann das besagte Strömchen und der Sensor benötigt keine Batterie oder sonstige Speisung. Typischer Einsatz in größeren Gebäuden (technische Anlagen, Stockwerke usw.) sowie Industrie, Landwirtschaft, Rechenzentren usw.

Einzelpreis 163€ netto, also wahrscheinlich leider zu teuer für private Wohnung usw. Und ich will hier keinen Werbespot draus machen, aber wenn Interesse besteht, dann poste ich gerne mehr Info.

Grüße aus Berlin - Georg (von der Herstellerfirma deZem)

Das hatte ich übrigens nicht verstanden. Datenversand natürlich per LoRaWAN, Dekoder und Payloadbeschreibung verfügbar. Aber sämtliche Daten werden ansonsten auch sekündlich per USB C „gepusht“ - JSON, glaub ich. War das die Frage?

Danke.
„Uns“ hier interessieren ua. so Dinge wie MQTT oä.
Eine Anbindung per USB-C finde ich persönlich nicht so cool.
Betr. Protokolle etc. hatte ich auf der Homepage nichts gefunden, möglicherweise habe ich es auch überlesen.
Aber mal sehen was die Kollegen hier so sagen.
Das Produkt selbst finde ich innovativ und auch der Preis ist angemessen.

Danke gleichfalls, und klar - macht Sinn. Für unsere Kunden ist halt das LoRaWAN absolut perfekt für die Feldebene (Sensoren weit verteilt). Aber als Firma lieben und nutzen wir MQTT (auf Plattformebene). Ich frag die Entwicklergurus mal, wie aufwendig eine MQTT Variante wäre. - Dumme Frage: man bräuchte dann WLAN, also wesentlich mehr Saft und Energy Harvesting ginge nicht?

Ja das stimmt wohl - warten wir auf die Kollegen.

Das Gerät ist meiner Meinung nach vom Konzept genau so wie es ist gut. Fängt man da jetzt an wesentlich was zu ändern, hat man ein anderes Gerät, welches dann mit idr. deutlich günstigeren Geräten mithalten muss.

Ob man jetzt Kleinigkeiten wie weitere Werte, anderes Sendeintervall, Verschlüsselung, anpasst, ist nochmal was anderes.

Danke tobiasr - sehen wir im Prinzip genau so, und die Konfig ist bereits vielfältigst gestaltbar. Auch wenn hier nicht unsere typischen Kundengruppe unterwegs ist: wenn jemand mag können wir gern mal ein Webmeeting machen und ich zeig Interessierten die bunten Einsatzmöglichkeiten.

Hab mit unseren Gurus gesprochen, und ja: MQTT usw würden die radikale Energieeffizienz, die für optimales Harvesting nötig ist, kaputt machen. Aber eine Idee war: LoRa anstelle des LoRaWAN. Das gibt jede Menge Freiheit, um die Daten rein lokal (zB in den eigenen 4 Wänden) mit oder ohne Verschlüsselung, Meshing usw zu kommunizieren. Dann können diese Geräte auch untereinander reden und einer kann Empfänger für alle anderen sein. Keine Batterien, große Reichweiten usw. - Vielleicht ja ne Anregung. Das zentrale device könnte zB per USB an einen embedded controller angebunden sein, der dann auch Automatisierungen übernimmt etc.

Was braucht man denn für LoRa, gibt es dafür Beispiele?

Hein09

Sorry für die späte Antwort. Für das obige Szenario bräuchte man ein paar Harvy2. Einer davon hängt per USB am Edge Controller. Dort liegen die Messdaten dann zB per JSON an. Details würden wir spezifizieren. Ist so noch nicht implementiert, aber bereits in der Pipeline.