Anbindung and ebusd mit modul 98_GAEBUS.pm

[jamesgo]

ok, die Fehlermeldung kann ich reproduzieren wenn ich das Attribut im drop-down auswähle. (ich klicke immer direkt auf das Attribut ... da kommt es nicht). Das kann es also nicht sein.

Im userattr steht nur u~bai~SetMode ... das ist richtig.

Wenn du "get Vaillant reading ...." (und den elends langen string auswählen) machst dann brauchst du nicht 30 Sekunden warten.

Setzte doch mal den loglevel für Vaillant auf 5 und führe dann obiges get aus.

[freetz]

Wie gesagt, das get liefert mir ja immer die richtigen Werte, die auch mit denen im ebusd.log übereinstimmen. Nur die Übernahme (bzw. das Anlegen) in die entsprechenden Readings findet nicht statt. Soll ich trotzdem dann das get noch mal mit erhöhtem LogLevel aufrufen, obwohl das für sich keine Probleme macht?

[jamesgo]

get reading

nicht

get u~bai~SetMode

[freetz]

Ah, ok, sorry...
Also mit loglevel 5 kommt

Code Auswählen Erweitern

2019.05.17 11:51:20 3: Vaillant execute r -c bai SetMode
2019.05.17 11:51:21 3: Vaillant answer r xbai-HcMode;xbai-FlowTempDesired2;xbai-HwcTempDesired;xbai-HwcFlowTempDesired;xbai-DisableHc;xbai-DisableHwcTapping;xbai-DisableHwcLoad;xbai-RemoteControlHcPump;xbai-ReleaseBackup;xbai-ReleaseCooling auto;0.0;-;-;1;0;1;0;0;0
...und jetzt sind auch die Readings angelegt, und zwar alle !
Heißt das, dass ich für SetMode den Readings-Befehl manuell absetzen muss und der nicht im Rahmen des angegebenen Zeitintervalls ausgeführt wird?

[jamesgo]

Cool, warte doch mal das interval ab und prüfe dann nochmal das log. Evt. hab ich da was übersehen

Gesendet von meinem BTV-DL09 mit Tapatalk

[freetz]

Ok, drei Intervalle abgewartet, die SetMode Readings aktualisieren sich nicht, erst dann, wenn ich get reading ... manuell aufrufe. Habe auch noch mal im Logfile nachgesehen: Dort taucht in den ganzen execute/answer Paaren der entsprechende Eintrag für SetMode nicht auf. Wenn ich ihn manuell über get reading aufrufe, kommt der beim Intervall-Abruf fehlende Eintrag:

Code Auswählen Erweitern

2019.05.17 12:00:06 3: Vaillant execute r -c bai SetMode
2019.05.17 12:00:06 3: Vaillant answer r xbai-HcMode;xbai-FlowTempDesired2;xbai-HwcTempDesired;xbai-HwcFlowTempDesired;xbai-DisableHc;xbai-DisableHwcTapping;xbai-DisableHwcLoad;xbai-RemoteControlHcPump;xbai-ReleaseBackup;xbai-ReleaseCooling auto;90.0;-;-;0;0;1;0;0;0

[jamesgo]

Ok, dann ist das ein bug ... schaue ich mir nacher an.

Gesendet von meinem BTV-DL09 mit Tapatalk

[freetz]

Super, danke!

[freetz]

Eine Sache ist mir noch aufgefallen: Wenn ich bei bai-Status01 die ersten beiden Werte ignorieren will, gebe ich dafür ja den Platzhalter "dummy" an. Mein attr r~bai~Status01 hat daher diesen Wert

Code Auswählen Erweitern

dummy;dummy;bai-temp2-3;bai-temp2-4;dummy;bai-pumpstate
Allerdings wird dabei trotzdem ein Reading namens "dummy" angelegt. Der Wert, der im Reading angezeigt wird, ist eine Temperatur, die dem ersten Wert entsprechen könnte, bin mir da aber nicht sicher. Darf "dummy" vielleicht nur innerhalb einer Reihe, aber nicht am Anfang stehen?

[freetz]

Nachtrag: Ich habe jetzt mit deletereading das "dummy" Reading entfernt und es wird dann bei Updates auch nicht mehr neu angelegt. Allerdings fällt mir jetzt auf, dass die Zuordnung der Werte  zu den verbleibenden Variablen nicht mehr stimmt. Wenn Status02 folgendes zurück liefert:

Code Auswählen Erweitern

bai Status01 temp1=17.0;temp1=17.0;temp2=-;temp1=-;temp1=17.0;pumpstate=off
würde ich bei der Reading-Zuordnung

Code Auswählen Erweitern

dummy;dummy;bai-temp2-3;bai-temp2-4;dummy;bai-pumpstate
erwarten, dass bai-temp2-3 und bai-temp2-4 jeweils den Wert "-" haben und bai-pumpstate den Wert "off".
Jetzt ist es aber so, dass bai-temp2-3 den Wert 17.0 hat und bai-temp2-3 ebenfalls, bai-pumpstate hat den Wert "-". Es scheint mir so, als würde die Wertezuordnung trotzdem von Anfang an passieren, also dass der erste verfügbare Rückgabewert dem ersten nicht-"dummy"-Reading zugewiesen wird und nicht übersprungen wird. Kann das sein?
Ohne die Dummy-Angaben war die Zuordnung korrekt.

[Hanjo]

Hi jamesgo,

mir ist aufgefallen, dass einige Standardattribute (wie z.B. timestamp-on-change-reading) in diesem Modul nicht konfigurierbar sind. Ich würde daher vorschlagen die $readingFnAttributes hinzuzufügen.

Anbei ein Patch dafür, vielleicht kannst du dir das ja mal anschauen 

Vielen Dank & viele Grüße
Hanjo

[jamesgo]

Hallo Hanjo,

habe die Änderung eingecheckt.

Grüße
Andy

[Hanjo]

Hi Andy,

cool, das war schnell  Vielen Dank!

Grüße
Hanjo

[Hanjo]

Hi Andy,

habe mein FHEM neu aufgesetzt und werde seitdem mit dieser Meldung bombardiert:

Code Auswählen Erweitern

PERL WARNING: Redundant argument in sprintf at ./FHEM/98_GAEBUS.pm line 1301

Offensichtlich liegt das an dem, was ich im Attribut "valueFormat" hinterlegt habe, es muss wohl irgendwo ein Platzhalter zu wenig sein, nur fällt es mir schwer die genaue Ursache zu identifizieren.

Hast du eine Idee, wie ich den Fehler eingrenzen kann? Alternativ: da alles so funktioniert, wie ich mir das denke, lässt sich die Fehlermeldung unterdrücken?

Danke & Gruß
Hanjo

[jamesgo]

Hallo Hanjo,
poste doch mal was hast du im valueFormat definiert hast.

Grüße
Andy