Anbindung and ebusd mit modul 98_GAEBUS.pm

[amunra]

Hi Daniel,
der BlockingCall hat ein Problem, nach 120 Sekunden (default Wert) bricht er ab bzw. läuft in ein timeout und bricht ab.

Code Auswählen Erweitern

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
Das ist nicht ok.
Dein Device heißt "ebus" - poste bitte hier den Result von:

Code Auswählen Erweitern

list ebus

Logging setzen:

Code Auswählen Erweitern

attr ebus verbose 5
ist spärlich, können es aber mal versuchen. Warten bis Abfrage läuft und Ergebnis hier posten.
Anschließend kannst du das Attribut

Code Auswählen Erweitern

verboseam Device wieder löschen.
EDIT: Davon würde ich dann doch jetzt Abstand nehmen - das ist vergebene Liebesmüh - mehr werde ich eh nicht sehen.

Gruß
Arthur

EDIT: Und bitte gleich auch noch die GAEBUS.pm (reicht auch wenn Du den Stand des Moduls hier postest - der letzte Stand ist von 04.12.2015) und die bai.csv hier anhängen. Ist FHEM aktuell? Welche ebusd Version nutzt du - schon die 2.x? Danke.

[yellowpinky]

@ Arthur

Danke für die Hilfe...

list ebus

Code Auswählen Erweitern

Internals:
   DEF        10.0.0.13:8888 300
   DevType    EBUSD
   DeviceAddress 10.0.0.13:8888
   DeviceName ebus
   FD         13
   Interval   300
   NAME       ebus
   NR         42
   PARTIAL
   STATE      Connected
   TYPE       GAEBUS
   UpdateCnt  470
   Readings:
     2016-01-02 00:29:32   Therme_Betriebsstunden_Hz 2348
     2016-01-02 00:29:38   Therme_Betriebsstunden_WW 454
     2016-01-02 00:29:55   Therme_RuecklaufTemp 28.06
     2016-01-02 00:29:59   Therme_VorlaufTemp 31.88
     2016-01-02 00:30:04   Therme_Wasserdruck 1.984
   Helper:
Attributes:
   ebusWritesEnabled 0
   group      Therme
   room       .Keller
   r~bai~FlowTemp~d.40_Vorlauftemperatur Therme_VorlaufTemp
   r~bai~HcHours~d.80_Hz._Betriebsstunden Therme_Betriebsstunden_Hz
   r~bai~HwcHours~d.81_Betriebsstunden_WW Therme_Betriebsstunden_WW
   r~bai~SDTRT~d.41_Rücklauftemperatur Therme_RuecklaufTemp
   r~bai~WaterPressure~Wasserdruck Therme_Wasserdruck
   userattr   r~bai~FlowTemp~d.40_Vorlauftemperatur r~bai~HcHours~d.80_Hz._Betriebsstunden r~bai~HwcHours~d.81_Betriebsstunden_WW r~bai~SDTRT~d.41_Rücklauftemperatur r~bai~WaterPressure~Wasserdruck

- fhem & Linux am Raspi sind aktuell
- GAEBUS Version ist vom 4.12.2015
- ebusd Version ist 1.3.0
- Raspi fhem = Raspberry 2 B
- Raspi ebus = Raspberry B

Danke
Daniel

[amunra]

Hallo John,
ich habe vorgestern in die 2.x reingeschnuppert, dabei habe ich ein paar Ablauf-/organisatorische- aber auch technische Fragen zum Thema ,,scan" und ,,Konfigurationsänderungen (reload)"  mitgenommen.
Du hast weiter oben schon etwas zum Thema ,,scan" und welche Zustände der annehmen kann beschrieben.
Ich habe ein paar weitere Fragen dazu - wann wird ein scan ausgeführt?
1) Bei jedem Start des Services
2) Beim Laden von Konfigurationsdateien ,,reload" – (hat bei mir etwas gedauert und sah aus als würde er ein scan ausführen bevor er die Daten einließt)
3) Nach Ausführen des Befehls ,,scan"
Der ebusd scheint sich die Informationen nicht zu merken, da sich die HW Konfiguration nur sehr selten ändert, wäre eine Art cache (der per Befehl ,,scan" erneuert wird) durchaus sinnvoll. Oder gibt es andere Beweggründe warum der Service die Informationen nicht vorhält? Gut man braucht irgendwo Schreibrechte ; o(
Für die Weiterverarbeitung wäre ein ,,scan" Gesamtstatus (1=läuft 2=fertig 3=horchen) – Stichwort: ,,i" - sehr hilfreich, denn dann könnte man sich die Daten holen ohne einen Abgleich (komplex und fehleranfällig) durchführen zu müssen. In dem Zusammenhang wäre ebenfalls ein ,,config-change"? (Konfigurationsdaten wurden neu geladen) Status (Timestamp?), der nach ein ,,scan/reload" gesetzt wird und per Befehl ,,i" abgefragt werden könnte, auch hilfreich.
Damit könnte man folgende Fälle abdecken:
1)   Daten erst holen wenn der ,,scan"gelaufen ist.
2)   Daten holen/aktualisieren wenn sich die Konfiguration geändert hat bzw. sich geändert haben könnte.
Danke und viele Grüße
Arthur

[amunra]

Hallo Daniel,
danke.
Was mir gestern schon aufgefallen ist, deine executes beinhalten 2x Leerzeichen zwischen dem r und -f

Code Auswählen Erweitern

ebus execute r  -f -c bai FlowTemp
Ich kann aber im Moment nicht sagen, welche Auswirkung das hat - das muss ich mir mal anschauen (vielleicht komme ich heute Abend dazu?).
Gruß Arthur

[john30]

Hi Arthur,

wann wird ein scan ausgeführt?
1) Bei jedem Start des Services
2) Beim Laden von Konfigurationsdateien ,,reload" – (hat bei mir etwas gedauert und sah aus als würde er ein scan ausführen bevor er die Daten einließt)
3) Nach Ausführen des Befehls ,,scan"

fast ganz richtig
Also erstmal muss zwischen ebusd mit Parameter "--scanconfig" und ohne unterschieden werden. Ohne "--scanconfig" macht ebusd überhaupt keinen Scan von sich aus, sondern nur nach Absetzen des "scan" Kommandos.
ebusd lauscht in der aktuellen Version dauernd auf dem Bus und "notiert" sich für alle gültigen Nachrichten (sprich eBUS Protokoll eingehalten und valide CRCs) die beiden "Gesprächspartner" (also Quell- und Ziel-Adresse). Das sieht man z.B. an den Meldungen "[bus notice] new master 03, master count 2".
Es wird also im Hintergrund immer aufgezeichnet, welche Master und welche Slaves an validen Kommunikationen beteiligt waren. Das Ergebnis sieht man auch mit dem "info" Kommando, wenn dort bei einer Adresse "seen" steht.

Mit "--scanconfig" passiert dann zusätzlich folgendes: In regelmäßigen Abständen wird die Liste der auf dem Bus als gültig erkannten Adressen durchgegangen und für die neu dazu gekommenen dann ein scan gemacht, sprich die Message mit PBSB=0704 an die Slave Adresse gesendet. Wenn ein Gerät darauf antwortet (und nur dann), wird die dazu passende Konfigurationsdatei gesucht und geladen. Das ist dann wiederum in dem "info" Ergebnis ersichtlich.

Bei "reload" wird die gesamte Konfiguration wieder verworfen und auch der Ladezustand der CSVs, so dass das Spielchen von vorn beginnt.

Das "scan" Kommando ist davon relativ unabhängig und setzt für alle gesehenen Slaves (oder alle möglichen mit "scan full") einen scan ab, hat aber nichts mit den CSVs zu tun.

Der ebusd scheint sich die Informationen nicht zu merken, da sich die HW Konfiguration nur sehr selten ändert, wäre eine Art cache (der per Befehl ,,scan" erneuert wird) durchaus sinnvoll. Oder gibt es andere Beweggründe warum der Service die Informationen nicht vorhält? Gut man braucht irgendwo Schreibrechte ; o(

Richtig, es wird nicht gespeichert, da es mit dem Verfahren von oben m.E. keinen Grund für ein persistentes Speichern gibt.

Für die Weiterverarbeitung wäre ein ,,scan" Gesamtstatus (1=läuft 2=fertig 3=horchen) – Stichwort: ,,i" - sehr hilfreich, denn dann könnte man sich die Daten holen ohne einen Abgleich (komplex und fehleranfällig) durchführen zu müssen.

Verstehe. Problem ist nur: der Individual-Scan passiert ja erst, wenn ein neue valide Adresse entdeckt wurde. Insofern gibt es keinen Gesamtstatus...
Man könnte höchstens nach Start von ebusd einen scan auf alle Adressen forcieren und somit auch das Laden aller CSVs.

In dem Zusammenhang wäre ebenfalls ein ,,config-change"? (Konfigurationsdaten wurden neu geladen) Status (Timestamp?), der nach ein ,,scan/reload" gesetzt wird und per Befehl ,,i" abgefragt werden könnte, auch hilfreich.

Das ist easy: Mach einfach eine MD5 Summe über die Zeilen aus dem "info" Ergebnis, die mit "address" anfangen. Oder noch einfacher: nimm die Anzahl der Nachrichten aus dem Info Kommando, also z.B. "messages: 738". Wann immer sich das ändert, muss Dein Modul CSVs abholen.

Nachtrag: ich könnte natürlich auch noch einen Timestamp der letzten Config Änderung in das Info Kommando einbauen, also z.B. "configstamp: 1451977859".

VG John

[amunra]

Hallo John,
danke für die Infos.
Ich muss noch in mich gehen, aber ich denke, dass der Ansatz: regelmäßig (konfigurierbar: an/aus und Zeitintervalle) auf die ,,messages" zu schauen, und dann bei ungleichem ,,count" ,,alles" neun holen, ein guter Kompromiss (Effizienz, Performance etc.) sein wird. Wir reden hier ja auch von überschaubaren Datenmengen.
Man könnte es optimieren, indem man prüft wie lange der ebusd läuft => ist die ,,uptime < 5-7" min dann regelmäßiger prüfen, ansonsten kann man davon ausgehen, dass 99% der Daten schon da sind und seltener prüfen.  Hierfür wäre evtl. die ebusd uptime info, abfragbar per command, hilfreich. Alternativ könnte man sich die Info auch über die system commandos holen, hier aber wieder Plattform abhängig etc.
Eine manuell forcierte Abfrage bzw. ,,hole alle Daten neu" sollte neben ,,führe einen scan durch" sowieso möglich sein.
Viele Grüße

Arthur

[jamesgo]

Hallo Daniel,

ich versuche gerade die Ursache für dein Problem zu finden.

In deinem post (14.12) des Logfiles sieht es so aus als ob die Verbindung zum ebusd nicht sauber funktioniert bzw. der Status hierfür nicht richtig gesetzt wird.

D.h. folgender Code wird (im blocking call) aufgerufen:

Code Auswählen Erweitern


      # limit number of reopens if ebusd cannot be reached
      if (($hash->{STATE} ne "Connected") or (!$hash->{TCPDev}->connected()) )
      {
        if (--$tryOpenCnt <= 0)
        {
          Log3 ($name, 2, "$name: not connected, stop GetUpdates loop");
          last;
        }
      }


Bisher hatte ich ebusd Version 1.2.0 im Einsatz und jetzt 1.3.0 installiert (funktioniert aber weiterhin)
Merkwürdig ist, dass "get reading" funktioniert die Abfrage über "blocking call" aber nicht.

Wie sieht bei dir die Datei /etc/defaults/ebusd aus?

Wenn dort nichts aussergewöhnliches drinnen steht werde ich dir eine Version mit mehr Debug Ausgaben zur Verfügung stellen.

Grüße
Andy

Code Auswählen Erweitern


2015.12.14 21:45:57 3: ebus answer r Therme_Betriebsstunden_WW 432
2015.12.14 21:45:57 2: ebus device closed. Try to reopen
2015.12.14 21:45:57 1: GAEBUS ebus reappeared (ebus)
2015.12.14 21:45:57 3: ebus execute r  -f -c bai FlowTemp
2015.12.14 21:45:58 3: ebus answer r Therme_VorlaufTemp 31.75;ok
2015.12.14 21:45:58 2: ebus: not connected, stop GetUpdates loop
2015.12.14 21:47:57 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 9890
2015.12.14 21:47:57 3: BlockingCall for ebus was aborted
2015.12.14 21:52:57 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.14 21:52:57 3: GAEBUS device opened (ebus)
2015.12.14 21:52:57 3: ebus execute r  -f -c bai HwcHours
2015.12.14 21:52:57 3: ebus answer r Therme_Betriebsstunden_WW 432
2015.12.14 21:52:57 2: ebus device closed. Try to reopen
2015.12.14 21:52:57 1: GAEBUS ebus reappeared (ebus)
2015.12.14 21:52:57 3: ebus execute r  -f -c bai FlowTemp
2015.12.14 21:52:58 3: ebus answer r Therme_VorlaufTemp 31.44;ok
2015.12.14 21:52:58 2: ebus: not connected, stop GetUpdates loop
2015.12.14 21:54:57 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 13384
2015.12.14 21:54:57 3: BlockingCall for ebus was aborted
2015.12.14 21:59:57 3: GAEBUS opening ebus device 10.0.0.13(8888)
2015.12.14 21:59:57 3: GAEBUS device opened (ebus)
2015.12.14 21:59:57 3: ebus execute r  -f -c bai HwcHours
2015.12.14 21:59:57 3: ebus answer r Therme_Betriebsstunden_WW 432
2015.12.14 21:59:57 2: ebus device closed. Try to reopen
2015.12.14 21:59:57 1: GAEBUS ebus reappeared (ebus)
2015.12.14 21:59:57 3: ebus execute r  -f -c bai FlowTemp
2015.12.14 21:59:58 3: ebus answer r Therme_VorlaufTemp 31.12;ok
2015.12.14 21:59:58 2: ebus: not connected, stop GetUpdates loop
2015.12.14 22:00:00 3: CUL_HM set A_GaragentorZu on-for-timer 1
2015.12.14 22:01:57 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 16874
2015.12.14 22:01:57 3: BlockingCall for ebus was aborted


[yellowpinky]

Hi Andy;

meine ebusd.debian sieht wie folgt aus:

Code Auswählen Erweitern

EBUSD_OPTS="--acquiretime 9400 -l All -d /dev/ttyUSB0"


steht aber in:
/root/ebusd/contrib/etc/default

Danke

[amunra]

Ich hätte jetzt auch an der einen oder anderen Stelle mehr logging eingebaut, da Andy unterstütz und eine debug version bereitstellt, halte ich jetzt mal die Füße still.
Viel Erfolg noch.

[jamesgo]

Hallo Daniel,

versuch doch mal die angehängte Version.

Vorher noch

attr ebus1 verbose 5

und danach ein "save" und "shutdown restart".

Bitte das fhem logfile posten.

Danke
Andy

PS: jetzt mit Anhang

[yellowpinky]

Hallo Andy;

.... hier das Logging..

Code Auswählen Erweitern

2016.01.06 00:11:46 4: ebus start GetUpdates2
2016.01.06 00:11:46 3: GAEBUS opening ebus device 10.0.0.13(8888)
2016.01.06 00:11:46 3: GAEBUS device opened (ebus)
2016.01.06 00:11:46 5: ebus GetUpdates: Therme_Betriebsstunden_WW:1
2016.01.06 00:11:46 3: ebus execute r  -f -c bai HwcHours
2016.01.06 00:11:46 3: ebus answer r Therme_Betriebsstunden_WW 459
2016.01.06 00:11:46 5: ebus GetUpdates: Therme_VorlaufTemp:1
2016.01.06 00:11:46 3: ebus execute r  -f -c bai FlowTemp
2016.01.06 00:11:47 3: ebus answer r Therme_VorlaufTemp 30.56;ok
2016.01.06 00:11:47 5: ebus GetUpdates: Therme_Betriebsstunden_Hz:1
2016.01.06 00:11:47 3: ebus execute r  -f -c bai HcHours
2016.01.06 00:11:47 3: ebus answer r Therme_Betriebsstunden_Hz 2410
2016.01.06 00:11:47 5: ebus GetUpdates: Therme_RuecklaufTemp:1
2016.01.06 00:11:47 3: ebus execute r  -f -c bai SDTRT
2016.01.06 00:11:47 3: ebus answer r Therme_RuecklaufTemp 24.69;65140;ok
2016.01.06 00:11:47 5: ebus GetUpdates: Therme_Wasserdruck:1
2016.01.06 00:11:47 3: ebus execute r  -f -c bai WaterPressure
2016.01.06 00:11:47 3: ebus answer r Therme_Wasserdruck 1.984;ok
2016.01.06 00:11:47 4: ebus: GetUpdatesDoit returnes ebus|Therme_Betriebsstunden_WW|459|Therme_VorlaufTemp|30.56|Therme_Betriebsstunden_Hz|2410|Therme_RuecklaufTemp|24.69|Therme_Wasserdruck|1.984
2016.01.06 00:13:46 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 22803
2016.01.06 00:13:46 3: BlockingCall for ebus was aborted
2016.01.06 00:18:46 4: ebus start GetUpdates2
2016.01.06 00:18:46 3: GAEBUS opening ebus device 10.0.0.13(8888)
2016.01.06 00:18:46 3: GAEBUS device opened (ebus)
2016.01.06 00:18:46 5: ebus GetUpdates: Therme_Betriebsstunden_WW:1
2016.01.06 00:18:46 3: ebus execute r  -f -c bai HwcHours
2016.01.06 00:18:46 3: ebus answer r Therme_Betriebsstunden_WW 459
2016.01.06 00:18:46 5: ebus GetUpdates: Therme_VorlaufTemp:1
2016.01.06 00:18:46 3: ebus execute r  -f -c bai FlowTemp
2016.01.06 00:18:47 3: ebus answer r Therme_VorlaufTemp 31.19;ok
2016.01.06 00:18:47 5: ebus GetUpdates: Therme_Betriebsstunden_Hz:1
2016.01.06 00:18:47 3: ebus execute r  -f -c bai HcHours
2016.01.06 00:18:47 3: ebus answer r Therme_Betriebsstunden_Hz 2410
2016.01.06 00:18:47 5: ebus GetUpdates: Therme_RuecklaufTemp:1
2016.01.06 00:18:47 3: ebus execute r  -f -c bai SDTRT
2016.01.06 00:18:47 3: ebus answer r Therme_RuecklaufTemp 27.38;65097;ok
2016.01.06 00:18:47 5: ebus GetUpdates: Therme_Wasserdruck:1
2016.01.06 00:18:47 3: ebus execute r  -f -c bai WaterPressure
2016.01.06 00:18:47 3: ebus answer r Therme_Wasserdruck 1.984;ok
2016.01.06 00:18:47 4: ebus: GetUpdatesDoit returnes ebus|Therme_Betriebsstunden_WW|459|Therme_VorlaufTemp|31.19|Therme_Betriebsstunden_Hz|2410|Therme_RuecklaufTemp|27.38|Therme_Wasserdruck|1.984
2016.01.06 00:20:46 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 26383
2016.01.06 00:20:46 3: BlockingCall for ebus was aborted

Danke

[jamesgo]

Hmm,

Code Auswählen Erweitern

2016.01.06 00:11:47 4: ebus: GetUpdatesDoit returnes ebus|Therme_Betriebsstunden_WW|459|Therme_VorlaufTemp|30.56|Therme_Betriebsstunden_Hz|2410|Therme_RuecklaufTemp|24.69|Therme_Wasserdruck|1.984

Das ist genau vor dem Return aus dem blocking call heraus und das Ergebnis sieht richtig aus.
Als nächstes sollte vom blocking call die Routine "GAEBUS_GetUpdatesDone" aufgerufen werden.

Ich werde mal weiter forschen.

Grüße
Andy

[amunra]

Hallo Andy,

ein Hinweis - zwischendurch:
Der Rückgabewert wird über den Telnetprompt als Perl-Befehl zurückgegeben - an dem Punkt steht der BlockingCall - da liegt der Hase im Pfeffer.
Das sieht man wenn man

Code Auswählen Erweitern

attr global verbose 5
setzt.
Das würde auch erklären warum "get" commands funktionieren - "get" commandos werden ohne BlockingCall abgesetzt.
Vermutlich kann auf dem System keine Tellnet session aufgebaut werden?
Vielleicht hilft dir/euch der Hinweis?
Gruß
Arthur

[jamesgo]

Hallo Arthur,

danke für den Hinweis.

@Daniel: kannst du den globalen loglevel mal erhöhen, speichern und dann einen shutdown restart machen?

In der fhem.cfg sollte es auch sowas geben:

define telnetPort telnet 7072 global



Grüße
Andy

[yellowpinky]

Hallo Arthur,
Servus Andy;

Danke für die Unterstützung,

Habe mein device testweise auf ebus1 umbenannt und der Übersicht halber nur mehr ein Attribut abgefragt (Speichertemperatur).

Anbei der Ausschnitt meines Log-Files und der Konfig.

Danke
Daniel