Anbindung and ebusd mit modul 98_GAEBUS.pm

[Reinhart]

@yellowpinki

amunra hat es dir ja schon beantwortet, ich habe das auch so mit ECMD realisiert, dass ich 2 Timer verwende. In den einem hole ich die Daten die ich öfters brauche (Vorlauf, Rücklauf, HKurve etc.) und in dem anderen nur alle 30 Minuten. Hier sind Druck, Fehlerzähler etc. Beim Druck "nieder" und dem Watchdog vom eBus bekomme ich sogar eine Mail.

GAEBUS ist leichter anzuwenden, dafür nicht ganz so flexibel. Als ich mit eBus Abfragen begonnen habe gab es den GAEBUS noch nicht, daher habe ich alles schon auf ECMD laufen. Aber aus technischer Neugierde, ist auch GAEBUS eingerichtet.

LG
Reinhart

[yellowpinky]

Danke für eure Antworten.
Die Geschichte mit dem Runden hab ich zur Zeit mit einem userReadings gelöst, aber ich glaube da kann man ja nur eines anlegen mit dem Inhalt von mehreren Variablen.
Mein Beispiel mit einer Variablen:

Code Auswählen Erweitern

Therme_RaumTempIst { sprintf("%.1f", ReadingsVal("ebus","ThermeRaw_RaumTemp",0)-1.81);; }
Geht das auch anders mit mehreren userReadings ?

Die Sache mit der Abfrage versehe ich aber in GAEBUS noch nicht ganz.
Mein Abfrage intervall ist 300 d.h. 5min
Wenn ich beim Reading :6 eintrage, sollte die nächste Abfage für dieses Reading doch erst wieder nach der 6 fachen Zeit also 30min erfolgen, es sind aber nur 15min. Also durch 2 dividiert. Das gilt auch z.B. für :12 -> 30min statt 60min...

Was mir auch aufgefalle ist, das bei mir meist das selbe Reading doppelt in meinem ebus.log steht ?

GAEBUS verwende ich weil es für mich einfacher zu bedienen ist als ECMD.... Was Perl betrifft bin ich auch Anfänger

LG
Daniel

[amunra]

Die Sache mit der Abfrage versehe ich aber in GAEBUS noch nicht ganz.
Mein Abfrage intervall ist 300 d.h. 5min
Wenn ich beim Reading :6 eintrage, sollte die nächste Abfage für dieses Reading doch erst wieder nach der 6 fachen Zeit also 30min erfolgen, es sind aber nur 15min. Also durch 2 dividiert. Das gilt auch z.B. für :12 -> 30min statt 60min...

Hallo Daniel,

ich habe mal in das Modul geschaut, der Interval funktoniert technisch wie folgt:

Für die Berechnung wird der InternalValue "UpdateCnt", zu sehen in der GUI unter "Internals", und der entsprechende "Zyklus" (Für das entsprechende Reading) herangezogen.
UpdateCnt wird bei "define" auf "0" gesetzt und bei jedem "polling ininterval" um 1 erhöht
Berechnung sieht wie folgt aus:

Code Auswählen Erweitern

"UpdateCnt"  Modulo "Zyklus" == 0   ----> dann wird ein read Befehl ausgeführt.
Heißt: Ist der "UpdateCnt" durch den Zyklus teilbar und das Ergbnis ist Null (also 0), dann wird ein Read ausgeführt.

Dadurch das GAEBUS zu dem Zeitpunkt schon läuft und mehrere Pollingintervalle hinter sich hat, kann es passieren, dass der erste Zyklus früher, also nicht regulär, ausgeführt wird, wei der UpdateCnt schon früher durch "Zyklus" teilbar ist. Der zweite Zyklus sollte passen - hast du den mal abgewartet? Das du genau die Mitte getroffen hast, war eher ein Zufall.

Viele Grüße
Arthur

[yellowpinky]

Hallo Arthur;

Code Auswählen Erweitern

Dadurch das GAEBUS zu dem Zeitpunkt schon läuft und mehrere Pollingintervalle hinter sich hat, kann es passieren, dass der erste Zyklus früher, also nicht regulär, ausgeführt wird, wei der UpdateCnt schon früher durch "Zyklus" teilbar ist. Der zweite Zyklus sollte passen - hast du den mal abgewartet? Das du genau die Mitte getroffen hast, war eher ein Zufall.

..ist immer so, wenn man es weiß ist es ja kein Problem. Vielleicht häng es aber damit zusammen, dass immer 2 Abfragen vom  selben Reading in meinem log stehen... warum auch immer !?

LG
Daniel

[amunra]

Hallo Daniel,
hmm, das ist etwas seltsam und auch nicht richtig - wenn Du magst, dann kannst du ja ein "list" von deinem GAEBUS Device hier posten, vielleicht gibt es dafür eine Erklärung.
Viele Grüße
Arthur
P.S. Interessant wäre auch von dem Zeitpunkt (etwas davor und danach) ein Fhem log mit Level 5.

[yellowpinky]

Hallo Arthur;

Hier die Konfig vom ebus.. wenn es hier keine offensichtliche Lösung gibt ist das ja auch kein Beinbruch.
Eine Möglichkeit für das Runden wird es wohl auch mal geben, GAEBUS entwickelt sich ja auch weiter...

Code Auswählen Erweitern

Internals:
   DEF        10.0.0.13:8888 300
   DevType    EBUSD
   DeviceAddress 10.0.0.13:8888
   DeviceName ebus
   FD         14
   Interval   300
   NAME       ebus
   NR         42
   PARTIAL
   STATE      Connected
   TYPE       GAEBUS
   UpdateCnt  2344
   Readings:
     2016-01-23 23:57:39   ThermeRaw_RaumTemp 22.88
     2016-01-23 23:57:39   Therme_AussenTemp -9.25
     2016-01-23 23:57:39   Therme_Betriebsstunden_Hz 2671
     2016-01-23 23:57:39   Therme_Betriebsstunden_WW 482
     2016-01-23 23:57:39   Therme_Flammensignal 84.0
     2016-01-23 23:57:39   Therme_ModulationSoll 27.0
     2016-01-23 23:57:39   Therme_RaumTempIst 21.1
     2016-01-23 23:17:19   Therme_RuecklaufTemp 43.56
     2016-01-23 23:47:33   Therme_VorlaufTemp 39.19
     2016-01-23 23:57:39   Therme_Wasserdruck 1.638
   Helper:
Attributes:
   ebusWritesEnabled 0
   event-on-change-reading .*
   group      Therme
   room       .Keller
   r~470~OutsideTemp~Außentemp._Sensor Therme_AussenTemp
   r~470~RoomTemp~Raumisttemp. ThermeRaw_RaumTemp
   r~bai~FlowTemp~d.40_Vorlauftemperatur Therme_VorlaufTemp:12
   r~bai~HcHours~d.80_Hz._Betriebsstunden Therme_Betriebsstunden_Hz
   r~bai~HwcHours~d.81_Betriebsstunden_WW Therme_Betriebsstunden_WW
   r~bai~IonisationVoltageLevel~d.44_Spannungspegel_Ionisationssignal Therme_Flammensignal
   r~bai~ModulationTempDesired~Modulationssollwert Therme_ModulationSoll
   r~bai~SDTRT~d.41_Rücklauftemperatur Therme_RuecklaufTemp:24
   r~bai~WaterPressure~Wasserdruck Therme_Wasserdruck
   userReadings Therme_RaumTempIst { sprintf("%.1f", ReadingsVal("ebus","ThermeRaw_RaumTemp",0)-1.81);; }
   userattr   r~470~OutsideTemp~Außentemp._Sensor r~470~RoomTemp~Raumisttemp. r~bai~FlowTemp~d.40_Vorlauftemperatur r~bai~HcHours~d.80_Hz._Betriebsstunden r~bai~HwcHours~d.81_Betriebsstunden_WW r~bai~IonisationVoltageLevel~d.44_Spannungspegel_Ionisationssignal r~bai~ModulationTempDesired~Modulationssollwert r~bai~SDTRT~d.41_Rücklauftemperatur r~bai~WaterPressure~Wasserdruck
   verbose    0

Danke für deine Hilfe
Daniel

[amunra]

Hallo Daniel,

ich kann nichts ungewöhnliches feststellen. Mit deiner Konfig kann ich bei mir, dein beschriebenes Verhalten nicht reproduzieren.

..ist immer so, wenn man es weiß ist es ja kein Problem. Vielleicht hängt es aber damit zusammen, dass immer 2 Abfragen vom selben Reading in meinem log stehen... warum auch immer !?

Was genau möchtest Du loggen, wie sieht die Log Definition aus? Ich vermute, dass es etwas mit deiner Logdefinition in FHEM, und evtl. auch noch in Kombination mit Userreadings, zu tun hat.

Viele Grüße
Arthur

P.S: Das Thema mit der Formatierung der Werte muss Andy entscheiden, man könnte so etwas einbauen: "reading:zyklus:format".

[yellowpinky]

Hallo Arthur;

...ist eigentlich ein "Standard Log" (siehe Anhang) um die Plots zu erstellen
(Die Kombi mit den UserReadings muss ich noch testen).. fahre morgen 1 Woche auf Urlaub vielleicht schaffe ich es noch vorher 

Edit:
Hab die userReadings gelöscht, der Eintrag efolgt aber trotzdem doppelt. Da ist wohl noch igendwo ein Rest einer Konfig vorhanden sein dürfte....

2016-01-24_12:56:23 ebus Therme_Flammensignal: 17.2
2016-01-24_12:56:23 ebus Therme_Flammensignal: 17.2
2016-01-24_12:58:39 ebus ThermeRaw_RaumTemp: 23.12
2016-01-24_12:58:41 ebus Therme_Flammensignal: 16.4
2016-01-24_12:58:41 ebus ThermeRaw_RaumTemp: 23.12
2016-01-24_12:58:41 ebus Therme_Flammensignal: 16.4
2016-01-24_13:03:42 ebus Therme_Betriebsstunden_Hz: 2682
2016-01-24_13:03:42 ebus Therme_Flammensignal: 16.9
2016-01-24_13:03:42 ebus Therme_Betriebsstunden_Hz: 2682
2016-01-24_13:03:42 ebus Therme_Flammensignal: 16.9
2016-01-24_13:06:26 ebus Therme_Flammensignal: 16.6
2016-01-24_13:06:26 ebus Therme_Flammensignal: 16.6
2016-01-24_13:08:44 ebus Therme_Flammensignal: 16.7
2016-01-24_13:08:45 ebus Therme_Flammensignal: 16.7
2016-01-24_13:11:28 ebus Therme_AussenTemp: -3.12
2016-01-24_13:11:29 ebus Therme_Flammensignal: 17.2
2016-01-24_13:11:29 ebus Therme_AussenTemp: -3.12
2016-01-24_13:11:29 ebus Therme_Flammensignal: 17.2
2016-01-24_13:13:46 ebus Therme_Wasserdruck: 2.046
2016-01-24_13:13:47 ebus Therme_Flammensignal: 17.3
2016-01-24_13:13:47 ebus Therme_Wasserdruck: 2.046
2016-01-24_13:13:47 ebus Therme_Flammensignal: 17.3

Danke & LG
Daniel

[amunra]

Hallo Daniel,
ok, ich habs gefunden - doppelte Log Einträge kommen, weil das GAEBUS zwei mal hintereinander ein readingsUpdate macht - man kann dieses Verhalten, ohne das Modul zu verändern, leider nicht beeinflussen.    das muss sich Andy anschauen.

@Andy: Die Funktion GAEBUS_doEbusCmd und GAEBUS_GetUpdatesDone (wenn BlockingCall abgeschlossen wurde) führen ein readingsBulkUpdate durch. Ich denke, das ein

Code Auswählen Erweitern

if ($action eq "r" and !$inBlockingCall) in der Funktion GAEBUS_doEbusCmd" Zeile 944 ausreichen/helfen sollte.

Viele Grüße
Arthur

[yellowpinky]

Hi;

Hab das Runden zur Zeit mit einem userReadings so gelöst:

Code Auswählen Erweitern

Therme_Diverse { "TI: ".sprintf("%.1f", ReadingsVal("ebus","ThermeRaw_TempRaum",0)-1.81)." TA: ".sprintf("%.1f", ReadingsVal("ebus","Therme_TempAussen",""))." VL: ".sprintf("%.0f", ReadingsVal("ebus","Therme_TempVorlauf",""))." RL: ".sprintf("%.0f", ReadingsVal("ebus","Therme_TempRuecklauf",""))." P: ".sprintf("%.1f", ReadingsVal("ebus","Therme_WasserDruck",""));; }
geht sicher einfacher aber es funkt jetzt einmal..

Um die Log Einträge zu minimieren hab ich das so eingerichtet:

Code Auswählen Erweitern

./log/ebus-%Y.log ebus:(Therme_Diverse:.*|Therme_Brenner.*:.*|Therme_Betriebsstunden.*:.*)

LG
Daniel

[jamesgo]

Hallo Arthur,

sehe gerade, dass ich das Problem mit den doppelten Einträgen nachvollziehen kann.

Bisher bin ich davon ausgegangen, dass der blocking Call (dadurch dass er in einem separaten Prozess ausgeführt wird) nur seine eigenen Readings aktualisieren kann und der code deshalb richtig ist.

Aber es stimmt natürlich dass das logging der events in dem neuen ("geforkten") Prozess ebenfalls existiert und die Logfiles existieren halt nur einmal ... deshalb zwei Einträge.

Danke für den Hinweis, werde das noch einbauen.

Grüße
Andy

[jamesgo]

Hallo,

das Problem mit den doppelten log Einträgen für die Readings sollte nun gelöst sein.

Grüße
Andy

[amunra]

Hallo Andy,
aus der Funktion direkt rauszuspringen, wenn der Befehl in BlockingCall läuft, ist natürlich besser ;o)
Viele Grüße
Arthur

[yellowpinky]

Hallo Andy;

Habe die neue GAEBUS am laufen und ich habe anfänglich das Problem gehabt, dass anscheinend der Intervall Timer nicht gegriffen hat, weil dazwischen in unregelmässigfen Abständen (< der Intervallzeit) immer wieder Einträge im LOG waren.
Habe dann zum Test die alte Version wieder aktiviert und dann wiederum umgestellt auf die Neue Version und jetzt funktioniert es ... warum auch immer.
Auf jeden Fall DANKE für die Behebung der doppelten Log Einträge.
Vieleicht greifst du auch die Idee mit dem Runden nochmal auf, wäre wirklich hilfreich.

DANKE
Daniel

[jamesgo]

Hallo Daniel,

ich arbeite gerade an eine Implementierung analog zu "valueFormat" aus dem readingsGroup Modul. Dann kannst du die Werte auch formatieren bzw. runden.

Die Variante "reading:number:format" gefiel mir nicht, da dann ein ":" im Format in der Zukunft zu Problemen beim Aufteilen der Werte führen könnte.

Bitte ein bisschen Geduld.

Grüße
Andy