Anbindung and ebusd mit modul 98_GAEBUS.pm

[Christian.]

Das ging schnell, herzlichen Dank!

Ich habe es auch schon erfolgreich testen können. get und set funktionieren ganz analog zu read. Prima!

Um die Werte von Status01 als einzelne Readings im GAEBUS-device auszulesen, müsste ich 6 Attribute anlegen, je eins passend zu einem der folgenden Read-Befehle:

Code Auswählen Erweitern


read -c heatgen Status01 temp1.0 # VL
read -c heatgen Status01 temp1.1 # RL
read -c heatgen Status01 temp2 # AussenTemp
read -c heatgen Status01 temp1.2 # VLWW
read -c heatgen Status01 temp1.3 # RLWW
read -c heatgen Status01 pumpstate # Status


Meines Wissens kann ich aber ein Attribut nicht mehrfach definieren. 
Hat jemand eine Idee?

[Christian.]

Ich habe schon was gefunden: das Attribut userReadings mit dem Wert

Code Auswählen Erweitern

Status-Vorlauf:Status              { my @values = split(/ /, ReadingsVal("ebus", "Status", 0)); $values[0] },
Status-Ruecklauf:Status            { my @values = split(/ /, ReadingsVal("ebus", "Status", 0)); $values[1] },
Status-Aussentemperatur:Status     { my @values = split(/ /, ReadingsVal("ebus", "Status", 0)); $values[2] },
Status-Warmwasser-Vorlauf:Status   { my @values = split(/ /, ReadingsVal("ebus", "Status", 0)); $values[3] },
Status-Warmwasser-Ruecklauf:Status { my @values = split(/ /, ReadingsVal("ebus", "Status", 0)); $values[4] },
Status-Pumpenstatus:Status         { my @values = split(/ /, ReadingsVal("ebus", "Status", 0)); $values[5] }


Damit, dass der Namen eines userReadings keine Umlaute enthalten darf, kann ich leben. Die Lösung ist also für mich in Ordnung. Ich schaue jetzt noch, ob man das auch effizienter formulieren kann.

[Christian.]

Ich habe eine Alternative gefunden, die etwas effizienter sein sollte.
Die userReadings habe ich gelöscht und stattdessen ein notify und eine Routine in 99_myUtils angelegt:

Code Auswählen Erweitern

define ebus_status_update notify ebus.Status:.* { create_ebus_status_readings("ebus") }
In 99_myUtils.pm:

Code Auswählen Erweitern

sub create_ebus_status_readings {
  my $devicename = shift;
  my $hash = $defs{$devicename};
  my $dotrigger = 1;
  my @values = split(/ /, ReadingsVal($devicename, "Status", 0));
  readingsBeginUpdate($hash);
  readingsBulkUpdate($hash, "Status-Vorlauf", $values[0]);
  readingsBulkUpdate($hash, "Status-Rücklauf", $values[1]);
  readingsBulkUpdate($hash, "Status-Außentemperatur", $values[2]);
  readingsBulkUpdate($hash, "Status-Warmwasser-Vorlauf", $values[3]);
  readingsBulkUpdate($hash, "Status-Warmwasser-Rücklauf", $values[4]);
  readingsBulkUpdate($hash, "Status-Pumpenstatus", $values[5]);
  readingsEndUpdate($hash, $dotrigger);
}


Ich bin damit zufrieden. Vielen Dank nochmal für die schnelle Implementierung des h-Kommandos!

[Christian.]

Ich möchte einen Vorschlag machen.

Idee
Erweiterung des Moduls GAEBUS um Unterstützung für ein Reading pro Feld bei Nachrichten mit mehr als 1 Feld.

Beispiel

CSV-Zeile: h,,Status01,VL/RL/AussenTemp/VLWW/SpeicherTemp/Status,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,

Wert der Antwortnachricht (Ergebnis des Aufrufs r -c heatgen Status01): 43.0;39.0;8.000;38.0;39.0;ok

Attributdefinition: attr ebus h~heatgen~Status01~VL/RL/AussenTemp/VLWW/RLWW/Status Beispielname:1:reading-per-field
Die bestehende Syntax wird hier um ein Schlüsselwort erweitert, z.B. 'reading-per-field'. Liegt das Schlüsselwort vor, soll ein Reading pro Feld erstellt werden.

Pseudo-Code

Code Auswählen Erweitern


my $readingBasename; # Basisname für alle Feld-Readings, im Beispiel: "Beispielname"
my $readingValue; # Wert der Antwortnachricht, im Beispiel: "43.0;39.0;8.000;38.0;39.0;ok"

my @row; # Zeile aus der CSV-Datei
my @fieldnames = split('/', $row[3]) ; # Spalte "comment"
my @values = split(';', $readingValue);

for (my $i=0; $i <= $fieldnames; $i++) {
  create userReading:
    my $readingName = createReadingName($readingBasename, $fieldnames[i]);
    $readingName = $values[$i];
    # im Beispiel:
    #   Beispielname-VL = 43.0
    #   Beispielname-RL = 39.0
    #   Beispielname-AussenTemp = 8.000
}

sub createReadingName { return join("-", @_); } # vom User durch ein Attribut überschreibbar


Was denkt ihr?

[jamesgo]

Hallo Christian,

du warst ja richtig aktiv und creativ

Ich finde auch, dass es eine einfache Lösung geben muss um mehrere Felder in Readings einzulesen.

Es gibt ja schon z.B "Status:5" was bedeutet "nur jedes 5-te mal abfragen"

Was hältst du von:

Code Auswählen Erweitern

Wert1;Wert2;dummy;Wert3:5

Bedeutet:

• die ersten beiden Rückgabewerte in Wert1 und Wert2
• den dritten Rückgabewert ignorieren
• den vierten Rückgabewert in Wert3
• alle weiteren Rückgabewerte werden ignoriert
• gibt es keinen vierte Wert dann wird Wert3 auf leer gesetzt
• die ":5" bleibt optional und macht auch nur 1-mal für die komplette Abfrage Sinn

Grüße
Andy

[Christian.]

Dein Vorschlag ist einfacher als meine Variante, weil der CSV-Kommentar unberücksichtigt bleibt, gleichzeitig aber flexibler, weil man eigene Namen vergeben kann. Außerdem hat man kein Problem, wenn CSV-Kommentar nicht passt. Finde ich gut!

[jamesgo]

Hallo Christian,

habe gerade eine neue Version hochgeladen.

Jetzt kannst du dem Attribut den Wert: "VL;RL;dummy;VLWW;RLWW"
geben und damit vier readings aus einem ebusd Befehl generieren.

Grüße
Andy

[Reinhart]

Danke jamesgo, funktioniert perfekt.

Code Auswählen Erweitern


r~bai~StatusTHER~VL/RL/AussenT/VLWW/RLWW/Status     VL;RL;aTemp;VLWW;RLWW;Status
dieses Attribut ergibt dann die Ausgabe von 6 zusätzlichen Readings.

LG
Reinhart

[Christian.]

Bei mir funktioniert es auch - super, vielen Dank!

[gima84]

Hi, ich hätte noch einen Wunsch für das Modul:

event-min-intervall

Den Rest funktioniert einwandfrei. Danke für das Modul.

[jamesgo]

Hallo gima84,

ich habe event-on-intervall zur Liste der Attribute hinzugefügt und das Modul hochgeladen.

Schau doch mal ob das reicht.

Wäre schön wenn du hier berichten könntest wie du dieses Attribut verwendest.

Grüße
Andy

[gima84]

Hallo jamesgo,

ich komm sicherlich erst am WE dazu, das zu testen.

Ich habe event-on-change-reading.* gesetzt. Leider wird dann bei einem Reading der Wert zu wenig aktualisiert, so das es zum Plotabriss kommt. Daher erhoffe ich mir mit dem event-min-intervall Abhilfe (ohne auf logproxy umstellen zu müssen).

Gruß Martin

[yellowpinky]

Ich verwende ebusd und fhem auf unterschiedlichen Raspis..
Ich bekomme im log sehr viele Einträge vom gaebus. Weisen die auf Fehler hin?

Code Auswählen Erweitern

2015.12.12 12:11:30 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.12 12:11:30 3: GAEBUS device opened (ebus)
2015.12.12 12:11:31 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.12 12:11:31 3: GAEBUS device opened (ebus)
2015.12.12 12:13:30 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 22748
2015.12.12 12:13:30 3: BlockingCall for ebus was aborted
2015.12.12 12:13:31 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 22756
2015.12.12 12:13:31 3: BlockingCall for ebus was aborted
2015.12.12 12:16:00 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.12 12:16:00 3: GAEBUS device opened (ebus)
2015.12.12 12:16:01 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.12 12:16:01 3: GAEBUS device opened (ebus)

Im log sehe ich auch, das meine Attribute in den definierten Abständen ausgelesen werden, aber warum werden sie in den Readings des ebus-device nicht aktualisiert ?

Code Auswählen Erweitern

2015.12.13 20:33:52 3: ebus execute r  -f -c bai HwcHours
2015.12.13 20:33:52 3: ebus answer r Therme_Betriebsstunden_WW 432
2015.12.13 20:33:52 3: ebus execute r  -f -c bai FlowTemp
2015.12.13 20:33:52 3: ebus answer r Therme_VorlaufTemp 71.62;ok

(http://reading.jpg)

event-on-change-reading .* greift im Zusammenhang mit den Readings anscheinend auch nicht bei mir (z.B. bei den Betriebssstunden, die ja länger gleich bleiben) !?

Wäre auch cool wenn vielleicht jemand eine kleine Beispielkonfig Posten könnte 

Danke

[john30]

Hallo jamesgo,

wär es denkbar, statt die CSVs zu lesen das ebusd "find -f" Kommando zu nutzen?
Das liefert die aktuell definierten Nachrichten im CSV Format ab.

Hintergrund der Frage ist, dass mit Version 2.0 ebusd die CSVs dynamisch nach Scan einlesen kann und somit das komplette Verwursten des Config Verzeichnisses viel zu viele Nachrichten in Deinem Modul zur Folge hätte.

Und noch was:
Ebenfalls ab ebusd 2.0 werden Bedingungen unterstützt. Diese werden vor den read/write... Typ in eckigen Klammern platziert, z.B. so:

Code Auswählen Erweitern


[SW=202-349]r,uih,ThisYearsYieldEnergyMonth4,Ertrag April dieses Jahres,,15,...

Dein Modul müsste also beim Einlesen der CSV aus dem ersten Feld ("$io") alles bis zur letzten schließenden eckigen Klammer verwerfen.

Wär cool, wenn Du das einbauen könntest.

LG John

[jamesgo]

Hallo John,
das muss ich mir anschauen.

Wie lange würde es dauern bis "find -f" nach dem Start von ebusd einen vollständigen output liefert?
Muss bei jedem Start vorher ein scan laufen?

Grüße
Andy