Anbindung and ebusd mit modul 98_GAEBUS.pm

[amunra]

Hallo Daniel, Hallo Andy,
leider kann man aus dem Log noch keine Ursache ableiten – was fehlt ist der call back telnet Aufruf. Ich bin mir sicher, dass das Problem nichts mit dem GAEBUS Modul zu tun hat.
Meiner Meinung nach wäre der nächste sinnvolle Schritt in das BlockingCall Modul zu schauen, vielleicht kann man mehr ableiten.
Das BlockingCall Modul hat leider auch sehr spärliche log Ausgaben, aus diesem Grund habe ich ein wenig mehr Logging eingebaut und das Modul angehängt.
Ablauf:
1)   Vorhandene Blocking.pm umbenennen und durch die im Anhang ersetzen.
2)   attr ebus1 verbose 5 setzen
3)   FHEM Restart und Logs hier posten
4)   Alles wieder rückgängig machen
Viele Grüße
Arthur

[yellowpinky]

Hallo Andy, Hallo Arthur;

Hier der log..

Code Auswählen Erweitern


2016.01.06 23:21:55 4: ebus1 start GetUpdates2
2016.01.06 23:21:55 2: BlockingCall start
2016.01.06 23:21:55 1: BlockingCall (GAEBUS_GetUpdatesDoit) created child (17096), uses telnetForBlockingFn to connect back
2016.01.06 23:21:55 1: BlockingCall (GAEBUS_GetUpdatesDoit) created child (17096) timeout
2016.01.06 23:21:55 1: BlockingCall (GAEBUS_GetUpdatesDoit) created child (17096) in time
2016.01.06 23:21:55 3: GAEBUS opening ebus1 device 10.0.0.13(8888)
2016.01.06 23:21:55 3: GAEBUS device opened (ebus1)
2016.01.06 23:21:55 5: ebus1 GetUpdates: Speichertemperatur:1
2016.01.06 23:21:55 3: ebus1 execute r  -f -c 470 BMUB51101StorageTemp
2016.01.06 23:21:57 3: ebus1 answer r Speichertemperatur 52.0
2016.01.06 23:21:57 4: ebus1: GetUpdatesDoit returnes ebus1|Speichertemperatur|52.0
2016.01.06 23:21:57 1: BlockingCall exit
2016.01.06 23:21:57 1: BlockingCall exit done
2016.01.06 23:21:57 1: BlockingCall end
2016.01.06 23:21:57 1: BlockingInformParent started
2016.01.06 23:23:55 1: BlockingKill started
2016.01.06 23:23:55 1: Timeout for GAEBUS_GetUpdatesDoit reached, terminated process 17096
2016.01.06 23:23:55 3: BlockingCall for ebus1 was aborted
2016.01.06 23:23:55 1: BlockingKill done


VIELEN DANK
Daniel

[rudolfkoenig]

Koenntest du bitte das Ganze nach einem update wieder probieren?
Es gab diverse Probleme mit BlockingCall nach der Umstellung auf die neuen Authentifizierungsmechanismen, die Probleme wurden aber mW inzwischen alle adressiert.
Falls es immer noch nicht klappt, dann bitte ein Log mit "attr global verbose 5" hier anhaengen.

[amunra]

Hallo Rudolf,
danke für den Hinweis.
@Daniel könntest du bitte ein Update durchführen und erneut probieren.

FYI: ich habe hier (Maintainer BlockingCall ->  Rudolf) um Unterstützung gebeten.
Viele Grüße
Arthur

[yellowpinky]

Hallo Rudolf, Arthur & Andy

Hab das Update durchgeführt - BlockingCall wurde erneuert.
Leider hat sich nichts geändert.
Anbei der Log... schicke euch gerne den gesamten log per PN/Mail falls notwendig

Vielen Danke
Daniel

[amunra]

@Daniel,
bitte hier schauen - Danke.
Gruß
Arthur

[amunra]

FYI: Das BlockingCall Problem wurde hier gelöst.

[jamesgo]

@Amura,

danke für die Unterstützung!! Das muss man erst mal finden.

Grüße
Andy

[amunra]

@John:
kann ich irgendwie den Pollinterval (also den globalen ebusd Zyklus siehe Parameter: --pollinterval=SEC) per cmd abfragen.
Falls nicht, könntest du das bei Gelegenheit einabuen? Mir würde es ausreichen es per cmd "i" abzufragen.
Hintergrund ist: Ich würde mich an den Pollingitevale und die Zyklen für die Abfrage der Daten/Infomrationen dranhängen - ich muss nur aufpassen, dass ich hinter ebusd herlaufe (leicht zeitversetzt), um auf den aktuellen Stand zu bleiben.
Vielen Dank und Grüße
Arthur

[john30]

Hintergrund ist: Ich würde mich an den Pollingitevale und die Zyklen für die Abfrage der Daten/Infomrationen dranhängen - ich muss nur aufpassen, dass ich hinter ebusd herlaufe (leicht zeitversetzt), um auf den aktuellen Stand zu bleiben.

So ist das glaube ich nicht die beste Lösung.
Hat Dein Modul permanent einen Socket an ebusd offen?
Falls ja, könnstes Du einfach das "listen" Kommando benutzen. Damit kommen dann automatisch alles aktualisierten Werte vorbei.

[amunra]

Hallo John,

Hat Dein Modul permanent einen Socket an ebusd offen?

Ja ist aber nicht zwingend nötig. Es ist ein IO Device das ich idealerweise über BlockingCall ansprechen muss - ohne BlockingCall wird in der Zeit FHEM blockiert.
Das bedeutet, dass ich nicht permanet das IO Device abfragen kann.
Aus diesem Grund muss ich mir eine Messagequeue bauen, so mein Plan, die in regelmässigen Abständen getriggert wird (über ein InternalTimer).
Ich habe schon eine konkrete Vorstellung, ich dachte mir nur, dass es sinvoll wäre, falls in ebusd eh schon ein pollingintevall und die zyklen definiert sind, sich dadran zu hängen. Fallback (wenn kein in ebusd definiert) wäre dann ein eigenen Ploinginterval zu definieren.

[john30]

Ja ist aber nicht zwingend nötig. Es ist ein IO Device das ich idealerweise über BlockingCall ansprechen muss - ohne BlockingCall wird in der Zeit FHEM blockiert.
Das bedeutet, dass ich nicht permanet das IO Device abfragen kann.
Aus diesem Grund muss ich mir eine Messagequeue bauen, so mein Plan, die in regelmässigen Abständen getriggert wird (über ein InternalTimer).
Ich habe schon eine konkrete Vorstellung, ich dachte mir nur, dass es sinvoll wäre, falls in ebusd eh schon ein pollingintevall und die zyklen definiert sind, sich dadran zu hängen. Fallback (wenn kein in ebusd definiert) wäre dann ein eigenen Ploinginterval zu definieren.

Aus meiner Sicht ist das nicht der richtige Ansatz, denn das polling interval verrät ja nur, in welchem Abstand ebusd theoretisch den nächsten poll macht. Du müsstest dann ja auch noch von jeder Message die Poll Priority wissen, um rausfinden zu können, in welchem Abstand die jeweils aktualisiert wird.
Ich denke nach wie vor, dass ein Abfragen der aktualisierten Werte bzw. ein liefern lassen derselben deutlich besser wäre.
In den JSON Daten, die mit dem HTTP Port abrufbar sind, geht das auch über einen socket hinweg durch Anhängen des Parameters "?since=lastup", wobei lastup der zuletzt abgeholte Zeitstempel ist (aus global.lastup).

[amunra]

Aus meiner Sicht ist das nicht der richtige Ansatz, denn das polling interval verrät ja nur, in welchem Abstand ebusd theoretisch den nächsten poll macht.

Ja, du hast Recht ich müsste wissen wann der nächste Pollinginterval ist.

Du müsstest dann ja auch noch von jeder Message die Poll Priority wissen, um rausfinden zu können, in welchem Abstand die jeweils aktualisiert wird.

Die Poll Priority, und alles andere was ein "find ..." liefert, habe ich eh im hash - sollte also kein problem sein.

Ich denke nach wie vor, dass ein Abfragen der aktualisierten Werte bzw. ein liefern lassen derselben deutlich besser wäre.
In den JSON Daten, die mit dem HTTP Port abrufbar sind, geht das auch über einen socket hinweg durch Anhängen des Parameters "?since=lastup", wobei lastup der zuletzt abgeholte Zeitstempel ist (aus global.lastup).

Ich stehe vor der Herausforderung/Frage "in welchen Zeitabständen frage ich welche werte ab" (und das möglichst FHEM schonend) - ich kann Werte haben, die ich nur einmal am Tag, und welche die ich kürzeren Zeitabständen (min/stunden) abfragen möchte. Das ganze muss möglichst optimiert (aus Zeitlicher- und Ressourcensicht) ablaufen.
Die JSON Daten schaue ich mir mal an - ich denke aber, dass die mir in meiner Problemstellung nicht weiterhelfen werden.

Ok, ich sehe, dass ich dann doch noch die eine oder andere Minute darüber grübeln muss.
Ich danke Dir für die Infos
Viele Grüße
Arthur

[yellowpinky]

Hi;

Ist es eigentlich möglich die Readings gleich bei der Abfrage zu Runden, weil z.B. die Temperatur mit 2 Nachkommerstellen eigentlich nicht notwendig ist und ja nur Einträge im Logging verursacht werden ?
Wie groß darf der Faktor für das Abfrageintervall direkt beim Reading sein, da ich z.B. den Wasserdruck nicht so oft abfragen will ?

Danke
Daniel

[amunra]

Hallo Daniel,

möglich ist es technisch schon, in GAEBUS aber aktuell nicht implementiert. Das könnte mit ECMD funktionieren, da man dort den ausgegeben Wert formatieren kann (Stichwort: postproc) bevor der als Reading gespeichert wird.

Wie groß darf der Faktor für das Abfrageintervall direkt beim Reading sein, da ich z.B. den Wasserdruck oder die Betriebsstunden nicht so oft abfragen will ?

Es gibt keine Begrenzung (Der InternalTimer, den Du beim Define mitgibst, läuft in dem entsprechenden Interval und prüft den "Count/Faktor", falls vorhanden, ist der Count erreicht, dann wird das Reading gelesen.) - funktioniert etwas nicht?
Viele Grüße
Arthur