Anbindung and ebusd mit modul 98_GAEBUS.pm

[zentis666]

Hab gerade mal versucht die Heizkurve zu definieren und dann zu setzen, geht auch nicht.
Wen ich den Befehl 3x absetze ändert sich  nichts.
Hier die Ausgabe von list ebus1

Code Auswählen Erweitern

Internals:
   DEF        192.168.178.59:8888 300
   DevType    EBUSD
   DeviceAddress 192.168.178.59:8888
   DeviceName ebus1
   FD         154
   Interval   300
   NAME       ebus1
   NR         594
   PARTIAL
   STATE      Connected
   TYPE       GAEBUS
   UpdateCnt  8
   Readings:
     2016-01-01 22:06:04   Aussentemperatur_Heizung 3.50 ok
     2016-01-01 22:01:01   Betriebsart_hk1 2
     2016-01-01 22:06:05   Betriebsart_ww  2
     2016-01-01 22:01:01   Flammensignal   off
     2016-01-01 22:01:04   Mode_Urlaub     0
     2016-01-01 22:01:01   Rücklauftemp   26.88 65105 ok
     2016-01-01 22:01:01   Speichertemp_WW 47.0
     2016-01-01 22:01:02   Vorlauftemp_Heizkreis_Ist 27.12 ok
     2016-01-01 22:01:02   Vorlauftemp_Heizkreis_Soll 49.5
     2016-01-01 22:01:04   Zirkulationspumpe_aktiv off
Attributes:
   ebusWritesEnabled 1
   room       Vaillant,heizkoerper
   r~470~BMUB51101StorageTemp~Speichertemperatur_Ist Speichertemp_WW
   r~470~CirPump~Zirkulationspumpe_aktiv Zirkulationspumpe_aktiv
   r~470~Hc1ActualFlowTempDesired~Aktuelle_Vorlauftemperatur_Soll_Heizkreis_1 Vorlauftemp_Heizkreis_Soll
   r~470~Hc1HeatCurve~Heizkurve_Heizkreis_1 Heizkurve
   r~470~Hc1OPMode~Betriebsart_Heizkreis_1 Betriebsart_hk1
   r~470~Hc1SFMode~HC1_SFMode Mode_Urlaub
   r~470~HwcOPMode~Betriebsart_Warmwasserkreis Betriebsart_ww
   r~470~OutsideTemp~Außentemp._Sensor Aussentemperatur_Heizung
   r~bai~FlowTemp~d.40_Vorlauftemperatur Vorlauftemp_Heizkreis_Ist
   r~bai~SDFlame~Flammensignal Flammensignal
   r~bai~SDTRT~d.41_Rücklauftemperatur Rücklauftemp
   r~cp~Mode~Betriebsart Betriebsart
   userattr   r~470~BMUB51101StorageTemp~Speichertemperatur_Ist r~470~CirPump~Zirkulationspumpe_aktiv r~470~Hc1ActualFlowTempDesired~Aktuelle_Vorlauftemperatur_Soll_Heizkreis_1 r~470~Hc1HeatCurve~Heizkurve_Heizkreis_1 r~470~Hc1OPMode~Betriebsart_Heizkreis_1 r~470~Hc1SFMode~HC1_SFMode r~470~HwcOPMode~Betriebsart_Warmwasserkreis r~470~OutsideTemp~Außentemp._Sensor r~bai~FlowTemp~d.40_Vorlauftemperatur r~bai~SDFlame~Flammensignal r~bai~SDTRT~d.41_Rücklauftemperatur r~cp~Mode~Betriebsart w~470install~Hc1HeatCurve~Heizkurve_Heizkreis_1 w~470install~Hc1SFMode~HC1_SFMode
   w~470install~Hc1HeatCurve~Heizkurve_Heizkreis_1 Heizkurve_Set
   w~470install~Hc1SFMode~HC1_SFMode Mode_Urlaub_Set

[Reinhart]

Sven poste uns bitte noch das Fhem Log, da sieht man dann genau wie der Befehl raus geht.

bei mir sieht das so aus, wenn ich das Wartungsdatum setze.

Code Auswählen Erweitern

2016.01.01 22:09:43 3: ebus1 execute r  -f -c 430 MaintenanceDate
2016.01.01 22:09:43 3: ebus1 answer r Wartung 01.03.2016
2016.01.01 22:09:43 3: ebus1 execute r  -f -c bai StatusTHER


LG

[zentis666]

Code Auswählen Erweitern

2016.01.01 22:20:37 3: ebus1 execute w -c 470install Hc1SFMode 0
2016.01.01 22:20:37 3: ebus1 answer w Mode_Urlaub_Set ERR: element not found
Eine Raute fehlt...

Die Reads gehen aber

Code Auswählen Erweitern

2016.01.01 22:16:13 3: ebus1 execute r -f -c cp Mode
2016.01.01 22:16:14 3: ebus1 answer r Betriebsart ERR: read timeout
2016.01.01 22:16:14 3: ebus1 execute r -f -c 470 CirPump
2016.01.01 22:16:15 3: ebus1 answer r Zirkulationspumpe_aktiv off
2016.01.01 22:16:15 3: ebus1 execute r -f -c bai SDFlame
2016.01.01 22:16:15 3: ebus1 answer r Flammensignal off
2016.01.01 22:16:15 3: ebus1 execute r -f -c 470 Hc1OPMode
2016.01.01 22:16:15 3: ebus1 answer r Betriebsart_hk1 2
2016.01.01 22:16:15 3: ebus1 execute r -f -c 470 Hc1ActualFlowTempDesired
2016.01.01 22:16:15 3: ebus1 answer r Vorlauftemp_Heizkreis_Soll 41.5
2016.01.01 22:16:15 3: ebus1 execute r -f -c 470 Hc1SFMode
2016.01.01 22:16:16 3: ebus1 answer r Mode_Urlaub 2
2016.01.01 22:16:16 3: ebus1 execute r -f -c 470 OutsideTemp
2016.01.01 22:16:16 3: ebus1 answer r Aussentemperatur_Heizung 3.25 ok
2016.01.01 22:16:16 3: ebus1 execute r -f -c 470 HwcOPMode
2016.01.01 22:16:16 3: ebus1 answer r Betriebsart_ww 3
2016.01.01 22:16:16 3: ebus1 execute r -f -c 470 Hc1HeatCurve
2016.01.01 22:16:16 3: ebus1 answer r Heizkurve 1.20
2016.01.01 22:16:16 3: ebus1 execute r -f -c bai SDTRT
2016.01.01 22:16:16 3: ebus1 answer r Rücklauftemp 26.81 65106 ok
2016.01.01 22:16:16 3: ebus1 execute r -f -c 470 BMUB51101StorageTemp
2016.01.01 22:16:16 3: ebus1 answer r Speichertemp_WW 46.5
2016.01.01 22:16:16 3: ebus1 execute r -f -c bai FlowTemp
2016.01.01 22:16:16 3: ebus1 answer r Vorlauftemp_Heizkreis_Ist 27.00 ok

[Reinhart]

sorry, ich habe dir nur den read gepostet, w sieht dann so aus.

Code Auswählen Erweitern

2016.01.01 22:25:12 3: ebus1 execute w -c 430#install MaintenanceDate 01.04.2016
2016.01.01 22:25:12 3: ebus1 answer w nWartung done

bei dir sieht man das # nicht, bei mir schon.

LG

[amunra]

ok, reads gehen das ist schon mal was.
Das Problem liegt an der csv Definition (
Ich habe mal kurz reingeschaut:

Code Auswählen Erweitern

  if ($action eq "w") {

    $class =~ s/install/#install/;

    $cmd = "$io ";
    $cmd .= "-c $class $var ";
    $cmd .= "$writeValues";

  } else {

    $cmd = "$io ";
    $cmd .= " -f " if ($io ne "h");
    $cmd .= "-v " if ($action eq "v");
    $cmd .= "-c $class $var";
    $cmd .= " $cmdaddon" if ($action eq "r");

    $cmd =~ s/^h /r /;
  }

  Log3 ($name, 3, "$name execute $cmd");

Ein write muss als "w" Type deklariert sein, dann wird "install" durch "#install" ersetzt.
Heißt: Du brauchst eine "w" Type Definition.
Ich schaue mal ....

[zentis666]

Entwarnung... schreiben ging ja schonmal...
habe gerade die 98_GAEBUS.pm nochmal von http://sourceforge.net/
runtergeladen und meine überschrieben und nun gehts.

Sorry für die Verwirrung, hatte erst letztens aktualisiert aber es war wohl nicht die neuste installiert.
Grüsse
Sven

[Reinhart]

das wäre mein nächster Vorschlag gewesen unsere Versionen einmal zu vergleichen, denn wir haben ja jetzt schon ganz genau gewusst warum er nicht schreiben wollte und amunra hat schon die Sourcen zerlegt.

Gut wen was funktioniert, die Fehlrsuche ist oft spannender als ein Krimi.

LG

[zentis666]

@Reinhart: könntest Du bitte Deine TabletUI htmls zur Verfügung stellen, jetzt wo write geht wäre das mein nächstes Projekt ...

LG
Sven

[john30]

Hi Andy,

nochmal zum Thema CSV einlesen:

das muss ich mir anschauen.

Es geht um das "find -f":

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,...


Letzteres ist jetzt wieder rückwärtskompatibel, d.h. "find -f" liefert jetzt keine Bedingungen mehr vor dem Typ (r/w etc) aus, weil einen da ja die Bedingung nicht mehr interessiert. Statt dessen werden nur die Definitionen ausgegeben, deren Bedingung (sofern vorhanden) auch erfüllt ist.

Das sollte die Einbindung erleichtern

LG John

[amunra]

Hallo John,

ich habe mir mal die 2.0.0 angeschaut und habe zu "find -f" eine Frage.
Laut der Aussage:

Es geht um das "find -f":
Letzteres ist jetzt wieder rückwärtskompatibel, d.h. "find -f" liefert jetzt keine Bedingungen mehr vor dem Typ (r/w etc) aus, weil einen da ja die Bedingung nicht mehr interessiert. Statt dessen werden nur die Definitionen ausgegeben, deren Bedingung (sofern vorhanden) auch erfüllt ist.

werden im "find" Ergebnis keine Bedingungen mehr geliefert.
Ich habe die aktuelle Version mit den default csv's im Einsatz
(http://up.picr.de/24173303oc.jpg)
und erhalte im "find" result noch diverse Bedingungen angezeigt.
z.B.

Code Auswählen Erweitern

[SW>=126]r,430,AssertFileName,AssertFileName,,15,b509,0da000,,s,STR:10,,,"shows, if assert is enabled, the name of the module where the 'assert fail' occured"
[SW>=126]r,430,AssertLineNumber,AssertLineNumber,,15,b509,0da100,,s,UIN,,,assert fail occured in this line
[SW>=210]r,430,B51000M10HwcFlowSetMon,B51000M10DHWFlowSetMon,,15,b509,0d6600,,s,UCH,,,flow setpoint DHW sent via B5 10 00
[SW>=210]r,430,B51000M12DisableBitsMon,B51000M12DisableBitsMon,,15,b509,0d6700,,s,UCH,,,"bits 0-7: disable CH/disable DHW tapping/disable DHW tank loading/not used/clear burner blocking DHW/dis, disable bits sent via B5 10 00 (leftmost bit 0, rightmost bit 7)"
[SW>=210]r,430,B51000M14Monitor,B51000M14Monitor,,15,b509,0d6800,,s,UCH,,,"bits 0-7: remote control CH pump/release backup heater/release cooling/not used/left stop position DHW o, bits sent in M14 of B5 10 00 (leftmost bit 0, rightmost bit 7; relevant is bit 0: remote control of CH pump)"
[SW>=210]r,430,B51000M7OpModeMonitor,B51000M7OpModeMonitor,,15,b509,0d6500,,s,UCH,,,"operation mode sent via B5 10 00 (0 = auto, 1 = forced off, 2 = forced CH, 3 = forced DHW)"

Ist das so gewollt?
Oder habe ich etwas missverstanden?
Danke und Viele Grüße
Arthur

EDIT: nach dem 10 mal lesen habe ich es - glaube ich - verstanden ;o)

Statt dessen werden nur die Definitionen ausgegeben, deren Bedingung (sofern vorhanden) auch erfüllt ist.

Bedeutet, dass die "passenden" Messages ein "r/w" beinhalten - Datensätze mit Bedingung davor passen nicht zur der Therme und ich kann die ausblenden. Richtig? Falls ja, dann muss ich bei mir, bei Wechsel von 1.x auf 2.x, nichts ändern - zumindest nichts am Modul.
Danke.

[john30]

Hallo Arthur,

Ist das so gewollt?
Oder habe ich etwas missverstanden?

da bist Du genau einen commit zu früh dran. Das ist erst mit commit https://github.com/john30/ebusd/commit/af997ea9a275d746945f851b697ae78659e137b7 geändert.

EDIT: nach dem 10 mal lesen habe ich es - glaube ich - verstanden ;o) Bedeutet, dass die "passenden" Messages "r/w" beinhalten - Datensätze mit Bedingung davor passen nicht zur der Therme und ich kann die ausblenden. Richtig? Falls ja, dann muss ich bei mir, bei Wechsel von 1.x auf 2.x - zumindest nicht am Modul, nichts ändern.

Ein Beispiel:
Bei Deiner 430 ist z.B. "read -c 430 DisplayedHwcStorageTemp" möglich, weil die Bedingung dafür, dass die Software Version mindestens 0125 sein muss, erfüllt ist (bei Deiner 430 ist es ja 0215). Also wird bei Dir die Nachricht im "find -f -c 430" erscheinen. Bei jemandem mit einer älteren 430 (sprich Software Version vor 0125), ist die Message dann gar nicht erst verfügbar und das o.g. read Kommando liefert "element not found".

Mit dem o.g. commit brauchst Du eigentlich nichts anpassen, aber das Lesen der CSV Dateien würde ich eben nicht empfehlen, weil ja potentiell alle bekannten Geräte eines Herstellers in dem Verzeichnis rum liegen. Wenn Du statt dessen das "find -f" Ergebnis nutzt, bekommst Du bereits schön gefiltert, welche Geräte da sind und welche Nachrichten (zumindest theoretisch) funktionieren sollten.
Und wenn das z.B. 5 Minuten nach dem Verbindungsaufbau zu ebusd abrufst, sollte die Liste auch komplett sein.

[amunra]

Hallo John,

Mit dem o.g. commit brauchst Du eigentlich nichts anpassen, aber das Lesen der CSV Dateien würde ich eben nicht empfehlen, weil ja potentiell alle bekannten Geräte eines Herstellers in dem Verzeichnis rum liegen. Wenn Du statt dessen das "find -f" Ergebnis nutzt, bekommst Du bereits schön gefiltert, welche Geräte da sind und welche Nachrichten (zumindest theoretisch) funktionieren sollten.
Und wenn das z.B. 5 Minuten nach dem Verbindungsaufbau zu ebusd abrufst, sollte die Liste auch komplett sein.

Ich hole mir die Daten per "find" - unter anderem aus den, von dir, genannten Gründen.
Ich probiere es mal mit dem neuen commit und melden mich evtl. wieder ;o)
Danke und viele Grüße
Arthur

[amunra]

Hallo John,
kurze Rückmeldung - mit der aktuellen Version ist das Verhalten wie erwartet bzw. wie von dir beschrieben.
Danke und Gruß
Arthur

[john30]

kurze Rückmeldung - mit der aktuellen Version ist das Verhalten wie erwartet bzw. wie von dir beschrieben.

prima, issue closed

[yellowpinky]

Hi;

Ich möchte euch nochmals um Hilfe bei meinem alten Problem bitten..

Ich verwende ebusd und fhem auf unterschiedlichen Raspis.
Nach den automatischen Abfragen werden die jedoch Readings nicht aktualisiert.
Im log sehe ich aber, das meine Attribute in den definierten Abständen (5min) ausgelesen werden, jedoch kommt dann nach 2min eine Fehlermeldung
Die Readings werden nur aktualisiert wenn ich direkt in fhem über get abfage.
Mit ebusctl bekomme ich ebenfalls die richtigen Werte.

Hab ich vielleicht ein Timing oder Schreibrechte Problem ?

Code Auswählen Erweitern


2015.12.20 15:00:45 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.20 15:00:45 3: GAEBUS device opened (ebus)
2015.12.20 15:00:45 3: ebus execute r  -f -c bai HwcHours
2015.12.20 15:00:46 3: ebus answer r Therme_Betriebsstunden_WW 439
2015.12.20 15:00:46 3: ebus execute r  -f -c bai FlowTemp
2015.12.20 15:00:46 3: ebus answer r Therme_VorlaufTemp 40.31;ok
2015.12.20 15:00:46 3: ebus execute r  -f -c bai HcHours
2015.12.20 15:00:46 3: ebus answer r Therme_Betriebsstunden_Hz 2182
2015.12.20 15:00:46 3: ebus execute r  -f -c bai SDTRT
2015.12.20 15:00:47 3: ebus answer r Therme_RuecklaufTemp 36.06;64958;ok
2015.12.20 15:00:47 3: ebus execute r  -f -c bai WaterPressure
2015.12.20 15:00:47 3: ebus answer r Therme_Wasserdruck 2.055;ok
2015.12.20 15:02:45 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 5907
2015.12.20 15:02:45 3: BlockingCall for ebus was aborted
2015.12.20 15:07:45 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.20 15:07:45 3: GAEBUS device opened (ebus)
2015.12.20 15:07:45 3: ebus execute r  -f -c bai HwcHours
2015.12.20 15:07:46 3: ebus answer r Therme_Betriebsstunden_WW 439
2015.12.20 15:07:46 3: ebus execute r  -f -c bai FlowTemp
2015.12.20 15:07:46 3: ebus answer r Therme_VorlaufTemp 40.69;ok
2015.12.20 15:07:46 3: ebus execute r  -f -c bai HcHours
2015.12.20 15:07:46 3: ebus answer r Therme_Betriebsstunden_Hz 2182
2015.12.20 15:07:46 3: ebus execute r  -f -c bai SDTRT
2015.12.20 15:07:46 3: ebus answer r Therme_RuecklaufTemp 36.50;64951;ok
2015.12.20 15:07:46 3: ebus execute r  -f -c bai WaterPressure
2015.12.20 15:07:47 3: ebus answer r Therme_Wasserdruck 2.055;ok
2015.12.20 15:09:45 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 9642
2015.12.20 15:09:45 3: BlockingCall for ebus was aborted


LG
Daniel