Hallo,
Auf http://www.mikrocontroller.net/topic/317004 sind zwei Schaltungen beschrieben, um die Daten einer Junkers-Heizung über einen Adapter vom HT-Bus auszulesen. Der Entwickler hat
dazu eine Standalone-Software unter Python geschrieben, um diese Daten zu loggen und anzuzeigen. Ich habe nun ein Modul geschrieben, um die Daten in FHEM auswerten
zu können.
Files: 89_HEATRONIC.pm
Fortschritt:
- Die grundlegenden Telegramme der Heizung für einen Heizkreis werden ausgewertet, die Auswertungen für Daten mehrerer Heizkreise müssen noch implementiert werden. Auch sind noch nicht alle Werte der Telegramme bekannt, da die Protokolle nicht offengelegt sind.
- Das Modul ist bereits im Einsatz (vgl. http://forum.fhem.de/index.php/topic,19445.msg175595.html#msg175595), die anfänglichen Fehler sind behoben.
- Der Lesepuffer soll in der nächsten Version in $hash->{buffer} gelegt werden.
- Da manche Temperaturwerte sehr häufig aktualisiert werden, soll ein Intervall (in Sekunden) eingebaut werden, in der Daten nicht übernommen werden.
- Da es noch viele Telegramme ungeklärte Werte haben, soll ein partielles Logging einzelner Telegrammtypen implementiert werden.
Offene Fragen:
- lassen sich die Readings auch bei der Definition festlegen? (Manche Werte kommen nur selten; bis die Liste mit Readings aufgebaut ist, dauert es entsprechend lange)
- Mit den regular Expressions stehe ich noch auf Kriegsfuß. Lässt sich irgendwas der Art '=~ "88003400(17 Bytes)00"' implementieren? Habe ich dadurch einen Geschwindigkeitsvorteil oder wird es dadurch eher unübersichtlich? Oder wäre evtl. ein Arrayzugriff schneller?
Über Verbesserungsvorschläge und Anregungen würde ich mich freuen. Ich würde mich auch freuen, wenn das Modul in das FHEM Repos übernommen werden könnte (Test mit /contrib/commandref_join.pl wurde durchgeführt). Ein SVN-Schreibzugriff wäre dann auch super.
Gruß,
Heiko
Zitatlassen sich die Readings auch bei der Definition festlegen?
Ja (siehe readings*Update), aber man muss das explizit programmieren. Ich verstehe aber den Grund noch nicht: man wartet beim ersten mal halt laenger, danach sind die Readings gespeichert, und nach dem Start "sofort" verfuegbar.
ZitatMit den regular Expressions stehe ich noch auf Kriegsfuß.
Meiner Ansicht nach ist die in das Verstehen von Regexps gesteckte Zeit gut investiert.
ZitatLässt sich irgendwas der Art '=~ "88003400(17 Bytes)00"' implementieren?
Sicher: $a =~ m/^88003400(.{17})00$/, das Ergebnis findet man in $1.
Ich habe zwar keine Geschwindigkeitsvergleiche gemacht, ich vermute aber, dass diese Zeiten, wenn man mit dem Aufruf nicht uebertreibt, irrelevant sind. Und 17 ist komisch.
ZitatEin SVN-Schreibzugriff wäre dann auch super.
Bitte email mit dem sourceforge-login (kein OpenId) an mich.
Hallo Rudolf,
vielen Dank für die schnelle Antwort.
1. Readings: Das habe ich mir fast schon so gedacht. Grund war, das manche Werte nur zweimal am Tag kommen, aber das betrifft ja nur das erste mal. Und wer kein Solarpanel hat, braucht die Daten dafür auch nicht.
2. Regexps: Ja, das ist aber schon etwas härterer Tobak, da brauche ich mal eine ruhige Minute für ;) Aber wer die verstanden hat, ist klar im Vorteil.
3. $a =~ m/^88003400(.{17})00$/: Da habe ich mich wohl missverständlich ausgedrückt. Ich habe mit unpack gearbeitet, d.h. jedes Byte sind 2 Zeichen (0x88 -> "88"). Ich wollte etwas wie (.{34}) verhindern, damit ich nicht mit der Länge durcheinander komme. (.{17*2}) ist nach erster Durchsicht nicht möglich. Intuitiv würde ich sagen (..{17}), aber ich bin mir nicht sicher, ob das korrekt ist. Ich will damit einfach nur die Länge sicherstellen: 4 Telegammbytes + 17 Wertebytes (incl. CRC) + 1 Breakbyte. Dann könnte ich mir die ganzen Längenabfragen sparen.
4. Mail: ist raus
Gruß,
Heiko
% perl -e '$a="1234567"; $a=~m/^((..){2})/; print $1,"\n"; print $2,"\n"'
1234
34
%
Ich fange an, zu verstehen. Ich glaube, die RegExps und ich können noch gute Freunde werden. Vielen Dank.