Läuft: Heizung mit eBus-Schnittstelle

[Prof. Dr. Peter Henning]

Hm, ich habe gestern etwa eine Stunde gebraucht, um das herauszufinden:

Ich traue dem auch noch nicht ganz - weil es nämlich durchaus Sinn machen könnte, die unterschiedlichen Teilgeräte auf unterschiedliche CSV-Dateien aufzuteilen. Dann hängt die Reihenfolge vom Dateinamen ab.

@heikoh81: pin1-4 ist nicht mehr aktuell, die Typen wurden umgebaut. Muss durch "code" ersetzt werden.

LG

pah

P.S.: Ich habe heute keine weiteren Arbeiten am EBUS vorgenommen, sondern eine Lösung programmiertt, die aus 12 Abfragen (im Abstand von je 2 Sekunden, um den normalen EBUS-Verkehr nicht zu behindern) eine Jahreslogdatei für meinen solaren Ertrag zusammenbaut, die mit normalen FHEM-Mitteln visualisiert werden kann.

[john30]

Bei automatisierten Abfragen würde raten, immer die Klasse mit anzugeben. Für den manuellen Fall ist es ganz praktisch, weil es einfach schneller geht  Dafür haben wir jetzt aber auch die noch elegantere Lösung über das "find" Kommando (z.B. "find temp").

@pah: ebusd beherrscht jetzt die Arbitrierung laut ebus Spezifikation inkl. forciertem Warten auf N SYN Symbole nach Verlust der Arbitrierung (Parameter --numbermasters). Insofern gibt es m.E. keinen Grund mehr,  Wartezeit einzubauen.

[Prof. Dr. Peter Henning]

Aus Sicht von FHEM aber schon. 12 EBUS reads in einem einzigen ECMD-Aufruf sind schon etwas heftig.

LG

pah

[heikoh81]

nein, es muss Klasse+Name unique sein (wird bei Start bzw. configcheck dann auch angemeckert).
Lässt man bei der Abfrage die Klasse weg, wird die erste Nachricht mit dem angegebenen Namen verwendet.

Das dürfte auch die von mir hier gepostete Fehlermeldung beim Configcheck erklären?
Wenn man es weiß, kein Problem. Mich hat es - wie pah auch - mind. 1h gekostet.
Gibt es irgendwo einen Changelog? Der bei Github enthält nur ein paar Zeilen allg. Text, und aus den Protokollen werde ich nicht wirklich schlau.
Ich denke auf eine so wichtige Änderung sollte irgendwo aktiv hingewiesen werden.

Viele Grüße,
Heiko

[Prof. Dr. Peter Henning]

Guten Rutsch in die Runde.

LG

pah

[heikoh81]

Auch von mir einen Guten Rutsch an alle.
Auf ein Gutes Neues!

Viele Grüße,
Heiko

[heikoh81]

Mit dem neuen ebusd scheint es ein weiteres Problem zu geben, und zwar scheint die Telnet-Abfrage 2 Leerzeichen nach den Werten zurückzuliefern.
Dadurch funktioniert die Aufbereitung nicht mehr (aus dem FHEM-Wiki).
Also bei den alten Revs kam da keine Leerzeile. Ich glaube das müssen sich die ebusd-Programmierer mal anschauen, ob das Absicht oder ein Fehler ist.

Code Auswählen Erweitern


read -c BC OutsideTempBC
2.062

read OutsideTempBC
2.062

FHEM-Log:

Code Auswählen Erweitern


2014.12.31 18:20:46 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)
2014.12.31 18:21:33 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)
2014.12.31 18:22:34 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)
2014.12.31 18:22:35 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)


Meine Aufbereitungsdatei ebus_systemdruck.cfg:

Code Auswählen Erweitern


# VaillantSystemdruck
get VaillantSystemdruck cmd {"read -c THER Pressure\n\n"}
get VaillantSystemdruck expect ".*"
get VaillantSystemdruck postproc { my ($SYSTEMDRUCK,$STATUS,$zval);\
my $hash  = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
    $SYSTEMDRUCK = "Keine Werte vorhanden";\
    $STATUS = "Keine Werte vorhanden";\
}else{\
    my @values=split(';',$_);\
       $SYSTEMDRUCK = sprintf("%5.2f Bar",$values[0]);\
       $STATUS = $values[1];\
       $zval = sprintf("Systemdruck %5.2f Bar, Systemdruck Status %s", $values[0], $values[1]);\
}\
readingsSingleUpdate($hash, "Systemdruck", $SYSTEMDRUCK, 1);\
readingsSingleUpdate($hash, "Systemdruck Status", $STATUS, 1);\
$zval; }


Ich habe oben jetzt schon alle 3 Varianten probiert, leider kein Erfolg:
get VaillantSystemdruck cmd {"read -c THER Pressure\n\n"}
get VaillantSystemdruck cmd {"read -c THER Pressure\n"}
get VaillantSystemdruck cmd {"read -c THER Pressure"}

In Folge kommen in FHEM leider keine Werte mehr an.

Viele Grüße,
Heiko

[Dr. Boris Neubert]

Hallo,

habe dieses Topic geteilt und die ECMD-relevanten Teile in das zutreffende Forum verschoben.

Melde mich aus diesem Topic hier ab.

Grüße
Boris

[john30]

Das dürfte auch die von mir hier gepostete Fehlermeldung beim Configcheck erklären?
Wenn man es weiß, kein Problem. Mich hat es - wie pah auch - mind. 1h gekostet.
Gibt es irgendwo einen Changelog? Der bei Github enthält nur ein paar Zeilen allg. Text, und aus den Protokollen werde ich nicht wirklich schlau.
Ich denke auf eine so wichtige Änderung sollte irgendwo aktiv hingewiesen werden.

@heikoh81: wir sind mit ebusd immer noch im Beta Status, deshalb ist mit Änderungen, neuem Verhalten etc. nach wie vor zu rechnen. Sobald wir einen Release-Status erreicht haben, gibt es natürlich auch ein Changelog.

Mit der Option --configcheck sollte doch relativ klar sein, was falsch ist, oder nicht? Zumindest werden Duplikate mit entsprechender Meldung versehen und auch so gut wie möglich auf die fehlerhafte Position hingewiesen.

[john30]

Mit dem neuen ebusd scheint es ein weiteres Problem zu geben, und zwar scheint die Telnet-Abfrage 2 Leerzeichen nach den Werten zurückzuliefern.
Dadurch funktioniert die Aufbereitung nicht mehr (aus dem FHEM-Wiki).
Also bei den alten Revs kam da keine Leerzeile. Ich glaube das müssen sich die ebusd-Programmierer mal anschauen, ob das Absicht oder ein Fehler ist.

Code Auswählen Erweitern


read -c BC OutsideTempBC
2.062

read OutsideTempBC
2.062

Wir haben vor kurzem auf ein HTTP-ähnliches Protokoll geschwenkt, weil ebusd jetzt auch mehr als eine Ergebnis-Zeile liefern kann. Deshalb ist das Ender der ebusd-Mittelung nun mit einer Leerzeile nach allen Daten markiert.
Ich schätze, das müsste im "expect" angepasst werden, sofern das einen Zeilenumbruch im String verträgt.

Die Anfrage ist nach wie vor mit einem einfachen Zeilenumbruch zu stellen, hier gibt es derzeit noch keinen Anwendungsfall um mehr als eine Zeile übertragen zu müssen/wollen. Insofern könnte es so stimmen:

Code Auswählen Erweitern


# VaillantSystemdruck
get VaillantSystemdruck cmd {"read -c THER Pressure\n"}
get VaillantSystemdruck expect ".*\n"
...


[john30]

Hier mal ein Beispiel, das bei mir funktioniert:

Code Auswählen Erweitern


define ebusd ECMD telnet localhost:8888
set ebusd classdef ebusd ebusd.classdef
define ebus ECMDDevice
set ebus class ebusd
get ebus outsidetemp


Und die ebusd.classdef dazu:

Code Auswählen Erweitern


get outsidetemp cmd {"r outsidetemp\n"}
get outsidetemp expect "\d+\.\d+\n\n"
get outsidetemp postproc { s/^(\d+\.\d+)\n\n$/$1/;; $_ }


[Prof. Dr. Peter Henning]

Ich halte sehr viel mehr davon, solche Nachbearbeitung nicht in der ECMD-Klassendefinition unterzubringen, sondern mit einem ordentlichen Perl-Programm zu arbeiten.

LG

pah

[john30]

@pah: ganz meiner Meinung. Stünde ich nicht mit Perl so auf Kriegsfuß, wäre das schon längst in meinem FHEM im Produktivbetrieb 

[Prof. Dr. Peter Henning]

Mal etwas Anderes: Mein EBUS-System ist immer noch etwas wirr in Bezug auf Broadcasts und direkte Abfragen.

Ich hatte bisher separate Klassen für die internen Module der vrs620, Beispiel: Klasse HC steht für Adresse 26 = Heizkreis 1.

Sowie eine Klasse MS für Master-Slave-Befehle, die auf dem Bus herumlaufen. Ein checkconfig findet keine Fehler

Jetzt habe ich in der Konfig
*re,SOL,,,,EC,B504,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
re,,Status3,KollTemp/Status/Füllung/Power,,,,21,,,temp1;skip;status;percent1;percent1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
u,MS,StatusSOL3,KollTemp/Status/Füllung/Power,10,EC,B504,21,,,temp1;skip;status;percent1;percent1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Das Problem ist, dass mit Eurem neuen Parser der zyklisch gelesene MS-Befehl niemals erkannt wird, sondern eine MS-Message 10ECB5040121 (von 10->EC) bereits als "Status3" abgeheftet wird. Ein

ebusctl read MS StatusSOL3

liefert also immer "no data stored".
Allerdings greift ein

ebusctl read SOL Status3

nicht auf die empfangenen MS-Daten zurück, die ja schon im Puffer stehen sollten. Sondern setzt explizit ein FFECB5040121 (von FF->EC) auf den Bus ab. Das dauert natürlich viel länger, als das Lesen der schon empfangenen MS-Message.

Wie kann ich dem entgehen ?

LG

pah

[john30]

@pah:
Die Config definiert in der angegebenen Weise zwei Mal die gleiche Nachricht mit dem einzigen Unterschied, dass MS-StatusSOL3 von ebusd niemals aktiv abgefragt werden darf (wegen des "u"). Insofern ist das so sicher nicht gewünscht. Ich würde die zweite Definition ("u") einfach rauswerfen und alles ist gut, denn alle reads und writes werden seit kurzem auch automatisch von ebusd mitgelesen, falls ein anderer Teilnehmer die Nachrichten absetzt.