LevelJet serielle Schnittstelle in openhab auslesen

[FossiBaer]

Hallo liebe Aktiven.

Auf der Suche nach einem Füllstandsanzeiger für unseren Öltank bin ich auf die Leveljets von ProJet gestoßen. Die Geräte sehen ja ganz ordentlich aus und sind Öltank-geeignet.

Ich möchte in der Heizperiode etwas genauer in die Heizung sehen, also evt. den tägl. bzw. wöchentlichen Verbrauch analysieren könne, z.B. in Verbindung mit der Aussentemperatur.

Meine Frage ist, ob jemand einen solchen schon mal in Openhab integriert hat und wie das zu machen ist. Die Wege vom Raspi zum Öllager sind nicht allzu weit, Denkbar wäre somit eine direkte Anbindung an den Raspi, über USB to Serial oder sogar über lan to serial. Die letzte Variante ist nur leider auch in bisschen kostenintensiv, lantronix xport liegt so um die 70 EUR.

Ich bin mir nicht sicher, wie ich über serial die Daten abfangen kann und wie ich das in der config hinterlegen muss. kann ich mit json oder http auf den lantronix schießen oder muss ich über socat auf den lantronix verbinden? Geht das dann ggf. auch über usb to serial? wie bekomme ich die Daten in Openhab ausgelesen? über regex?

Vielleicht hat ja jemand das schonmal realisiert und kann mir auf den richtigen weg helfen.

VG Fossi

[misa]

Hallo Fossi, ich habe so etwas auch noch nicht gemacht, steht aber bei mir an für meine Lüftersteuerung.

In OH2 gibt es die Möglichkeit für ein serielles Binding: http://docs.openhab.org/addons/bindi...l1/readme.html

Ggf. hilft Dir das.

[udo1toni]

Nur um auch ein bisschen Senf dazu zu geben...

Je nach genauer Leitungslänge wäre vermutlich eine reine serielle Verbindung das Beste, USB ist eigentlich nur bis 3m/5m spezifiziert, es gibt zwar aktive Verlängerungen, aber die kosten ja auch Geld, außerdem geht so etwas auch mal kaputt (bei mir am Schreibtisch...). Normale serielle Verbindungen sind zwar bei konventionellen Kabeln auch nur bis 15m "erlaubt", aber erstens kann man bessere Kabel verwenden und kommt dann sogar offiziell bis 45m, und zweitens ist die serielle Verbindung wegen der geringeren Datenrate recht unempfindlich, wenn man nicht gerade Störstrahler neben der Leitung aufbaut.

Der Raspberry hat eine Onboard Serielle Schnittstelle mit TTL-Pegeln, das passt hervorragend zu der Schnittstelle am ProJet.
Falls wider Erwarten keine gute Verbindung zustande kommt, muss dann halt doch ein teurer Schnittstellenwandler her, aber im ersten Versuch würde ich es so probieren.

Übrigens kann ein direkt vor Ort verbauter Raspberry auch hervorragend die Daten der seriellen Schnittstelle aufbereiten und per LAN weiter schicken - der Raspberry kostet dann mit Netzteil und Gehäuse um die 60EUR, aber vielleicht fliegt auch noch was in der Grabbelkiste rum, dann wird's billiger (dafür halt mit mehr Zeitaufwand).
Die Anbindung an openHAB kann man vorzugsweise über Mosquitto und das mqtt Binding erledigen, da gibt es hier schon einige Threads.

Am Rande noch ein Warnung: Der ProJet stellt zwar an der seriellen Schnittstelle 5 Volt zur Verfügung, aber nur maximal 250mA, das reicht, wenn ich mich recht erinnere nicht mal für den XPort, der außerdem 3,3V benötigt - an einem zusätzlichen Netzteil wird also kein Weg vorbei führen.

[FossiBaer]

Leveljet habe ich heute bestellt. Raspi 1 liegt hier noch rum, der eigentliche ist aber auch nur 5 Meter weiter. Da kann ich eigentlich ein Catkabel ziehen, liegt noch rum.

Kann mir jemand mit der Belegung helfen? Was muss ich wie verbinden? Tx + Masse + Rx + Masse direkt? Passen die Spannungen? USB tu serial brauch ich dann ja nicht. Welche Pins am Raspi sind richtig? Hatte bislang nur fertige Module.

VG&Danke Fossi

[udo1toni]

Tx zu Rx gekreuzt, Masse verbunden. Laut Specs haben beide (Raspberry und ProJet) TTL Pegel an der seriellen Schnittstelle, das sollte also direkt funktionieren.

[FossiBaer]

Also einmal Masse und Rx und Tx, das sind die Pins 8 & 10, richtig? Damit aber keine Spannung. Ich werde es erstmal mit dem alten Raspi testen. Das ist noch ein
1 Rev B. Ich checke da vorher nochmal die Gpios. mit mqtt habe ich noch nichts am Start. Bislang schreibe ich alles in Mysql. Den Raspi würde ich frisch aufsetzen und dann mal rumprobieren. Damit versenke ich zumindest nichts in meiner Live-Installation. Eigentlich würde es mir reichen, wenn der Raspi 1-2 Mal pro Tag den Füllstand in die mysql schreibt. Von dort kann ichs dann in Openhab weiterverarbeiten. Verbrauch berechnen und Füllstand anzeigen. Im Moment schwebt mir eine Auswertung vor, die die wöchentliche Durchschnittstemperatur Außen und den wöchentlichen Verbrauch in einen Grafen schreibt. Ich denke, das sich daraus Zusammenhänge ablesen lassen. Da sich bei einer Füllhöhe von 140 cm und einem Volumen von 6000 Litern in Verbindung mit 1cm Messgenauigkeit ca. 40-50 Liter pro Messschritt ergeben, wird eine tägliche Auswertung zu ungenau sein. Die Sprünge sind zu hoch. Aber wöchentlich könnte klappen.

Den ProJET habe ich übrigens gestern installiert. Reduzierstück habe ich natürlich nicht mitbestellt. In der Gartenabteilung hab ich dann aber entsprechende Nippel gefunden. Der Sensorkopf hat ein 1" Gewinde, am Tank sitzt ein 1,5" Anschluss. Durch die Reduzierstücke gab es auch gleich den notwendigen Abstand, so dass der Messkopf jetzt 6 cm über dem Tankanschluß sitzt. Damit war die Installation in 15 Minuten gemacht. Loch im Tankraum war bereits vorhanden. Jetzt muss ich nur noch eine Steckdose installieren und die Anzeigeeinheit an die Wand schrauben. Die Einstellungen waren auch recht simpel zu machen. Leider kenne ich den richtigen Höchst- und Tiefststand des Tanks nicht. Gibt es dafür Erfahrungswerte (cm oder%)? Ich müsste die Heizung Mal bis zum "Exitus" laufen lassen und den Tank dann volltanken. Dann würde ich die Maximalstände kennen. :-)

[udo1toni]

Die Maße des Tanks solltest Du kennen, dann müssten die korrekten Werte für den Fühler auch auszurechnen sein.

Was die Spannung für die serielle Schnittstelle betrifft: Beide Geräte (Raspberry und ProJET) haben eine eigene Stromversorgung, es darf keinesfalls eine Versorgungsspannung von dem einen an das andere Gerät angeschlossen werden! Für die Kommunikation werden nur die Signalleitungen Rx und Tx verwendet.
Um einen gemeinsamen Bezugspegel zu haben, wird noch eine dritte Ader gebraucht, die mit GND verbunden ist. Alle Signalpegel beziehen sich immer auf GND (bzw. Masse).

• Pin 10 am Raspberry ist Rx (Receive oder zu deutsch empfangen)
• Pin 08 am Raspberry ist Tx (Transmit oder zu deutsch senden)
• Pin 09 am Raspberry ist GND (unter anderem Pin 09, aber der ist räumlich nahe)

Logischerweise muss das eine Gerät (Raspberry) die gesendeten Signale des anderen Geräts (ProJET) empfangen (und umgekehrt), also wird immer das Rx des einen Geräts mit dem Tx des anderen Geräts verbunden.

Wenn Du Deinen openHAB-Raspberry in Reichweite hast, reicht die einfache Strippe und das serial Binding - oder Du erledigst das Wrapping (die Umsetzung des ProJET-Protokolls auf das gewünschte Itemformat) mit einem Script und nutzt das Exec Binding.

Wenn openHAB physisch zu weit entfernt ist, bindest Du einen anderen Raspberry seriell an, der liest die Daten vom ProJET und schickt sie über Ethernet an openHAB. Dazu bietet sich mqtt an. Wenn Du gerne bastelst, kannst Du die Umsetzung seriell <-> (W)LAN auch mit einem Arduino oder so machen, dann musst Du halt alles zu Fuß erledigen, der Arduino wird dann auch per mqtt angebunden. MQTT brauchst Du also nur, wenn eine weitere Kommunikationsebene zwischen den Geräten gebraucht wird.

Die Messwerte solltest Du zumindest alle paar Minuten auslesen, auch wenn sie sich nicht ändern. Wenn Du das nur einmal pro Tag machst, ist das Risiko zu groß, dass openHAB gerade in dem Moment zufällig nicht läuft, dann fehlt Dir der Messwert. Außerdem frisst die Wertabfrage kein Brot. Abgesehen davon ist ja die Frage, was der Messfühler tatsächlich liefert. Eine Messgenauigkeit von 1cm bedeutet nicht, dass der Pegel um 1cm sinken muss, um eine Wertänderung herbeizuführen. Das kannst Du nur über Analyse der Daten herausfinden. Solange sich die Daten nicht ändern, werden von der Persistence auch keine Daten geschrieben (Voraussetzung ist natürlich, dass Du nur everyChange als Strategie angegeben hast). Falls Du rrd4j verwendest, hat die Häufigkeit der Messwerte gar keinen Einfluss auf die Datenbankgröße, da rrd4j RoundRobin verwendet, um immer die gleiche Größe beizubehalten.

Welche Zeiträume Du zum kumulieren verwendest, ist dann natürlich Geschmacksache bzw. abhängig von der Dynamik der Ausgangsdaten, aber das ist ja jederzeit änderbar, Du musst Dich also nicht festlegen.

[FossiBaer]

Ich mach mir grad nen Kopf, wie ich die Daten evt. etwas einfacher aufbereiten kann, ohne mqtt. Das ist sicherlich möglich, da ich aber noch gar nicht über mqtt angebunden habe, wäre mqtt ein bisschen overload.

Im Fhem-Forum habe ich eine config Zeile gefunden, die die Auslesung über regex macht. Damit habe ich auch schon irgendwas am Laufen, das muss ich nochmal nachschlagen.Aber wäre das nicht ggf. eine Möglichkeit, die Daten der seriellen Schnittstelle abzufangen und in ein Item zu Schreiben, das dann in mysql landet und weiter verarbeitet werden kann?

define ReadLevelJet at +*00:15:00 {my $leveljetreading = `socat - /dev/ttyUSB0,b19200,nonblock,raw,echo=0,readbytes=18 | egrep "[0-9]{2,4} , [0-9]{1,4} , [0-9]{1,4}"`;; fhem "set Oeltank $leveljetreading"}

Im Thread ist jedoch die Rede vom Funksystem und einer Einstellung zur seriellen Schnittstelle auf verbose umstellen. Da habe ich bei meinem Gerät noch nicht nachgesehen.

https://forum.fhem.de/index.php?topic=12534.0

[FossiBaer]

Danke für die ausführliche Anleitung. Das hilft OpenHAB und Leveljet liegen 5 Meter auseinander. Und der Mauerspecht war letztes Jahr schon da. Das wird kein Problem sein. Und rj12 habe ich mir gestern besorgt. Ich werd mal ne strippe ziehen und die gpio Leiste freilegen. Bin aber Erst in zwei Tagen wieder daheim.

[udo1toni]

Da hat sich Schreiben mit Schreiben überkreuzt.

Genau, mqtt brauchst Du nicht zwingend, genauso wenig, wie eine Funkverbindung.

Wie die Daten von A (ProJET) nach B (openHAB) kommen, ist die eine Sache - mindestens ist RS232 mit im Spiel, weil das der ProJET spricht. Ob noch weitere Komponenten vonnöten sind, hängt nur von den räumlichen Gegebenheiten ab.
Wie Du die Daten in Form bringst, ist die zweite Sache (entweder ein kleines Script, welches die Daten auf Befehl aus dem ProJET ausliest und aufbereitet an openHAB weitergibt oder ein entsprechend definiertes Item. Den Lesebefehl direkt über das Item abzusetzen bedeutet halt eine entsprechend komplexere Item-Konfigurationszeile.
Wie die Daten gespeichert werden, ob in (My)SQL, rrd4j, influxdb, ist die dritte Sache, das ist letztlich vor allem Geschamcksache, bzw. davon abhängig, was Du ohnehin schon am Laufen hast. Viele Programme verlangen explizit genau eine Form des datenbankbasierten Gedächtnisses, das ist ziemlich unpraktisch. Wer sowieso ein PostgreSQL am Laufen hat, will nicht extra MySQL aufsetzen. Deshalb bietet openHAB hier eine offene Schnittstelle, die viel unbestimmter ist. Wer nur einfach ein paar Graphen haben will, ohne sich um irgendwas zu kümmern, greift zu rrd4j und den eingebauten Funktionen, wer Wert auf Äußerlichkeiten legt und extreme Freiheiten in der Gestaltung haben will, nimmt influxdb mit Grafana. Grafana könnte auch eine SQLdb als Backend verwenden, darunter leidet aber die Performance, influxdb ist auf zeitbasierte Datenreihen spezialisiert und in diesem Bereich sehr performant.

[FossiBaer]

Läuft eben schon alles auf MySQL. Wetterdaten, Raumtemperaturen, Vor- Rücklauftemperaturen. Der Server liegt aber in einer eigenen Instanz auf einem Virtualisierungsserver. Da liegen auch die dB des Mailservers etc. Ich wollte halt von Anfang an die Schreiblast auf der SD des Raspis gering halten. Das funktioniert sehr gut und die Grafen bauen sich zügig auf, solange ich nicht auf die Wetterdaten des letzten Monats zugreife. Dann dauerts halt ein bisschen.

[FossiBaer]

Ist das geil. Verbindung hat auf Anhieb geklappt:

root@MAR-SMART_2:~#socat - /dev/ttyAMA0,b19200,readbytes=12
4970 , 350 ,

Jetzt muss es noch ins Item. Die Ausgabe kommt vom rpi mit OpenHAB.

Da muss ich jetzt mal testen und in mich gehen.

VG - Fossi

[FossiBaer]

Folgende Zeile habe ich in ein Script gepackt:

/usr/bin/socat - /dev/ttyAMA0,b19200,nonblock,raw,echo=0,readbytes=18

Und das spuckt folgende Zeile aus:

4970 , 350 , 1180

Jetzt suche ich nach einer Erklärung für REGEX: ich könnte natürlich die readbytes auf 4 setzen und hätte damit eine Zahl. Mich interessiert aber schon, wie ich jetzt alle drei Werte mittels script oder item auslesen könnte.

Wo kann man sich denn zum Thema Regex schlau lesen?

VG - Fossi

[lo4dro]

Du könntest das ganze auch damit Lösen, dass du dein Script einen Parameter mit gibst.
Dadurch musst du im Exec Binding das RegEX nichts anpassen.
Ich nutze das für die Abfrage von SolarView.

Das könnte dann so aussehen: (keine Garantie das das auf Anhieb funktioniert)
Das Script könnte auch die drei Werte verarbeiten und dann ausgeben.

#!/bin/sh
#Aufruf: leveljet.sh 1|2|3

PARAMETER=$1 #Die Variable PARAMETER bekommt den Wert 1 oder 2 oder 3

#Falls $PARAMETER leer wird die 1 benutzt:
if [ -z "$PARAMETER" ]
then
        PARAMETER=1
fi


case $PARAMETER in

1)
   /usr/bin/socat - /dev/ttyAMA0,b19200,nonblock,raw,echo=0,readbytes=18|cut -d ',' -f 1
   exit 0
  ;;

2)
   /usr/bin/socat - /dev/ttyAMA0,b19200,nonblock,raw,echo=0,readbytes=18|cut -d ',' -f 2
   exit 0
 ;;

3)
   /usr/bin/socat - /dev/ttyAMA0,b19200,nonblock,raw,echo=0,readbytes=18|cut -d ',' -f 3
   exit 0
 ;;

esac
exit 0 

Das sollte zur Ausgabe vom Wert 1 oder 2 oder 3 ohne Komma führen.

[udo1toni]

Alternativ kannst Du ein Item in openHAB erstellen, welches die drei Werte als String übernimmt. Anschließend parst dann eine Rule den String in drei Number Items. Die Rule wird dann bei Changed vom String Item ausgelöst.
Im Script (also auf Bash-Ebene) könntest Du vorher shcon mal die Leerzeichen entfernen, so dass nur die Drei Zahlen ohne Komma da stehen, dann ist das Aufteilen des Strings in der Rule mit einem simplen split(",") erledigt.