Neues Buderus KM Modul mit neuen Features 79_BDKM.pm

RoRo · 07 November 2016, 11:30:09

Zitat von: meier81 am 03 November 2016, 21:04:03
Code Auswählen Erweitern
reload: Error:Modul 99_Utils deactivated: Unrecognized character \xC2; marked by <-- HERE after <-- HERE near column 1 at ./FHEM/99_Utils.pm line 249, <$fh> line 4.

Klingt ein wenig, als hätte sich da ein Windows-Sonderzeichen eingeschlichen oder so...
Ich habe meine FHEM/99_myUtils.pm jetzt mal unter http://www.spinnaker.de/tmp/99_myUtils.pm abgelegt, das sollest Du einfach runterladen und an der entsprechenden Stelle ablegen können und damit sollte es dann funktionieren...

Gruß
Roland

obb20a · 08 Dezember 2016, 22:14:31

Hallo,

erst mal vielen Dank für das Modul. Ich habe bisher das KM200 laufen und wollte heute BDKM ausprobieren. Schnell ein define gemacht und schon läuft die Sache.

ALLERDINGS: Irgendwie stimmt da was nicht - ich bekomme nur die obersten Hierarchien, keine weiteren Werte. Wenn ich z.B. RC300 verwende oder meine bekannten Attribute direkt bei PollID's einfüge, bleiben die immer leer.

Neustart änder da auch nix dran ... ?

Die INFO sieht dann so aus: (wie gesagt, KM200 liefert mit hier eine Riesenliste ...)

Gateway ID FHEM Reading (Alias) Last Value Read TW Valid Values Poll Rd.Update
-------------------------------------------------------------------------------------------------------------------------------------------------------------
/dhwCircuits - on change
/gateway - on change
/heatSources - on change
/heatingCircuits - on change
/notifications - on change
/recordings - on change
/solarCircuits - on change
/system - on change
-------------------------------------------------------------------------------------------------------------------------------------------------------------

arnoaugustin · 09 Dezember 2016, 10:00:42

Gibt's da noch mehr Infos außer: "Irgendwie stimmt da was nicht"?
Loglevel mal hoch gedreht? Was steht im Logfile? Config-File mal posten usw.?
Da steht mit Sicherheit was drin.
Könnt mir gut vorstellen, dass der Key nicht stimmt. Dann einfach mal den Thread hier komplett lesen.
Bitte Ergebnisse auch hier Posten, damit andere nicht über ähnliche Probleme stolpern.
VG
Arno

binifada · 12 Dezember 2016, 10:14:08

@Arno

Hi, ich habe auch von KM200 auf BDKM umgestellt. Läuft immer wenige Tage
dann kommt:

"Buderus communication ERROR in state reading ids ERROR - retrying every 60s: connect to http://192.168.178.102:80 timed out"

Erst nach einem Neustart der Heizung läuft's dann wieder für ein paar Tage?!

Im Log taucht ebenfalls auf:

PERL WARNING: Use of uninitialized value $hth in substitution (s///) at ./FHEM/79_BDKM.pm line 450.
PERL WARNING: Use of uninitialized value $hth in concatenation (.) or string at ./FHEM/79_BDKM.pm line 451.

Ne Idee was da los sein könnte?

LG Bini

Hugo Becker · 12 Dezember 2016, 12:40:12

Hallo,

@Arno
genau dieselben Meldungen erhalte ich täglich in Massen, quasi bei jedem Abfrageintervall (180 sek.). Habe versucht mit Verbose auf das Device die Meldungen zu unterdrücken, aber Verose greift nicht.

Code Auswählen


[Mon Dec 12 12:03:37 2016] fhem.pl: Use of uninitialized value $hth in substitution (s///) at ./FHEM/79_BDKM.pm line 450.
[Mon Dec 12 12:03:37 2016] fhem.pl: Use of uninitialized value $hth in concatenation (.) or string at ./FHEM/79_BDKM.pm line 451.
[Mon Dec 12 12:06:37 2016] fhem.pl: Use of uninitialized value $hth in substitution (s///) at ./FHEM/79_BDKM.pm line 450.
[Mon Dec 12 12:06:37 2016] fhem.pl: Use of uninitialized value $hth in concatenation (.) or string at ./FHEM/79_BDKM.pm line 451.

Ich habe keine Ahnung was ich noch probieren könnte. Vielleicht hast Du noch einen Tip für mich. Wäre prima...

Gruß
Hugo

arnoaugustin · 12 Dezember 2016, 15:47:03

Zitat von: binifada am 12 Dezember 2016, 10:14:08
...habe auch von KM200 auf BDKM umgestellt. Läuft immer wenige Tage
dann kommt:
"Buderus communication ERROR in state reading ids ERROR - retrying every 60s: connect to http://192.168.178.102:80 timed out"
Erst nach einem Neustart der Heizung läuft's dann wieder für ein paar Tage?!
Im Log taucht ebenfalls auf:
PERL WARNING: Use of uninitialized value $hth in substitution (s///) at ./FHEM/79_BDKM.pm line 450.
PERL WARNING: Use of uninitialized value $hth in concatenation (.) or string at ./FHEM/79_BDKM.pm line 451.
....

Hallo Bini, hallo Hugo,

wenn der loglevel auf größer gleich 2 steht werden die Kommunikationsfehler geloggt. Zusätzlich kann man auch auf das Event reagieren, da hier der "state" der Modulinstanz gesetzt wird. Den ERROR-Log kann man mit verbose auf 1 abschalten.
Das Zeile 450 und 451 im Falle einer fehlerhaften Kommunikation mit Gateway "PERL WARNING: Use of uninitialized value $hth usw." ausspucken liegt daran, dass dann in "$param->{httpheader}" undef zu stehen scheint.
Ich hab die Zeilen 449-451 hinter die if-Abfrage gestellt. Habs eingecheckt - sollte morgen mit update aus FHEM verfürbar sein
Die Perl-Warning sollte dann zwar weg sein, aber es hilft nichts dagegen, dass Ihr Probleme mit der Kommunikation mit Eurem Gateway habt.
Bei mir kommt ein Kommunikationsfehler nur, wenn die Netzverbindung getrennt ist.
Das BDKM-Modul hat ein Attribut "HttpTimeout" das default auf 10 steht. Kann man mal hoch drehen, wird aber nichts bringen.
Wenn die Kommunikationsprobleme erst nach Tagen auftreten und wenn das Ein- und Ausschalten des Gateways/Heizung das Problem löst, dann ist es eindeutig ein Gateway/Heizungs-Problem. Da kann ich dann leider nichts machen. Von solchen Problemen wurde glaube ich auch schon beim KM200 berichtet.
Ich hoffe hier hat niemand beide Module gleichzeitig laufen. Denn das führt irgend wann in jedem Fall zu einem Problem. Beide Module lesen dann permanent gleichzeitig vom Gateway und das scheint das Gateway nicht zu mögen.
Zu viele Anfragen verkraftet das Gateway scheinbar nicht. Evtl. läuft in dem Ding dann irgendwo mal ein Puffer über. Was weiß ich....
Am besten fährt man, wenn man nur die IDs vom Gateway holt, die man auch wirklich braucht. Evtl. mag die Heizung selber auch die vielen Anfragen vom Gateway nicht und wenn von der Heizung nichts mehr kommt, dann kommt vom Gateway evtl. nichts mehr. Man könnte bei Buderus nachfragen.....

Ich habe so konfiguriert:

Code Auswählen


attr   Buderus BaseInterval 180
attr   Buderus HttpTimeout 10
attr   Buderus PollIds \
   RC300DEFAULTS \
   /heatingCircuits/hc1/actualSupplyTemperature::: \
   /system/info:::SystemInfo \
   /heatingCircuits/hc1/operationMode:10::HeatMode \
   /system/sensors/temperatures/outdoor_t1:1:1:OutdoorTemp \
   /heatSources/systemPressure:240:0:SystemPressure

Zusätzlich habe ich auch die Kommunikation zum Internet unterbunden.

Wenn ihr Euer Netz überprüft habt, die PollIds eingeschränkt habt, keine Anfragen von Verschiedenen aufs Gateway stattfinden, Ihr ein evtl. nebenbei laufendes KM200 abgeschaltet habt, und dann immer noch die Kommunikationsfehler auftreten, dann weiß ich auch kaum noch Abhilfe.
Man könnte dann zwischen den Requests noch Pausen einbauen, aber dazu müsste ich den Code umstricken, weil ich nicht einfach blockierend im Code warten kann.
Gebt mal bitte Bescheid ob ihr bei Berücksichtigung der Tips anderes Verhalten habt.
Wenn das Modul den Kommuikationsfehler meldet, dann ist dieser auch wirklich vorhanden!

VG,
Arno

binifada · 13 Dezember 2016, 08:44:15

Hallo Arno,

erst mal vielen Dank das Du hier dein Feedback gibst. Bei mir läuft nur BDKM

. Meine Definition sieht folgendermaßen aus:

define Buderus BDKM xxx.xxx.xx yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
attr Buderus PollIds RC300DEFAULTS\
/system/sensors/temperatures/outdoor_t1:1:0:Temperatur_aussen\
/dhwCircuits/dhw1/actualTemp:1:0:Temperatur_Wasser\
/gateway/DateTime:1:0:DatumZeit\
/system/appliance/actualPower:1:0:Leistung_aktuell\
/heatSources/flameStatus:1:0:Status_Flamme\
/heatSources/returnTemperature:1:0:Temperatur_Ruecklauf\
/heatingCircuits/hc1/pumpModulation:1:0:Modulation_Pumpe\
/heatingCircuits/hc1/temperatureLevels/comfort2:1:0:Temperatur_Tag\
/heatingCircuits/hc1/temperatureLevels/eco:1:0:Temperatur_Nacht\
/system/appliance/systemPressure:1:0:Druck_Leitung\
/system/sensors/temperatures/supply_t1:1:0:Temperatur_Vorlauf\
/heatSources/actualCHPower:1:0:Leistung_aktuell_kW
attr Buderus room Heizung
attr Buderus userReadings ZZLeistungGB212_kW:DatumZeit.* {ReadingsNum("Buderus","Leistung_aktuell","1")*22/100},\
ZZArbeitGB212_kWh:DatumZeit.* integral {ReadingsNum("Buderus","ZZLeistungGB212_kW","1")/3600}

Gestern abend habe ich die Heizung neu gestartet und alles läuft wieder "schick", mal sehen wie lange.

Im Log stand nach Neustart der Heizung und von FHEM:

Buderus: unknown type eMonitoringList for /heatSources/accumulatedEMonitoring

Pollintervall habe ich hochgesetzt auf 180, Http-Timeout war auf 10. Gateway und Internetzugang der IP prüfe ich heute abend.

obb20a · 13 Dezember 2016, 08:48:14

Zitat von: arnoaugustin am 12 Dezember 2016, 15:47:03
Ich hoffe hier hat niemand beide Module gleichzeitig laufen. Denn das führt irgend wann in jedem Fall zu einem Problem. Beide Module lesen dann permanent gleichzeitig vom Gateway und das scheint das Gateway nicht zu mögen.

Es gibt in diesem Thread ja doch einige, die von beiden Modulen im Einsatz schruben - daher hab' ich BDKM natürlich hinzudefiniert - werde das im nächsten Anlauf mal prüfen, nachdem ich KM200 deaktiviert habe.

Zum Glück läuft bei mir FHEM auf einer ESXI, da kann ich einen Snapshot machen und zur Not wieder einen Rollback, wenn's wirklich komisch wird.

Gruss Stefan

arnoaugustin · 13 Dezember 2016, 10:40:41

Zitat von: binifada am 13 Dezember 2016, 08:44:15
...Definition sieht folgendermaßen aus:

define Buderus BDKM xxx.xxx.xx yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
attr Buderus PollIds RC300DEFAULTS\
/system/sensors/temperatures/outdoor_t1:1:0:Temperatur_aussen\
/dhwCircuits/dhw1/actualTemp:1:0:Temperatur_Wasser\
/gateway/DateTime:1:0:DatumZeit\
/system/appliance/actualPower:1:0:Leistung_aktuell\
/heatSources/flameStatus:1:0:Status_Flamme\
/heatSources/returnTemperature:1:0:Temperatur_Ruecklauf\
/heatingCircuits/hc1/pumpModulation:1:0:Modulation_Pumpe\
/heatingCircuits/hc1/temperatureLevels/comfort2:1:0:Temperatur_Tag\
/heatingCircuits/hc1/temperatureLevels/eco:1:0:Temperatur_Nacht\
/system/appliance/systemPressure:1:0:Druck_Leitung\
/system/sensors/temperatures/supply_t1:1:0:Temperatur_Vorlauf\
/heatSources/actualCHPower:1:0:Leistung_aktuell_kW
attr Buderus room Heizung
attr Buderus userReadings ZZLeistungGB212_kW:DatumZeit.* {ReadingsNum("Buderus","Leistung_aktuell","1")*22/100},\
ZZArbeitGB212_kWh:DatumZeit.* integral {ReadingsNum("Buderus","ZZLeistungGB212_kW","1")/3600}

...

Buderus: unknown type eMonitoringList for /heatSources/accumulatedEMonitoring
...

Hallo Bini,

"unknown type eMonitoringList" kommt, weil ich den Typ nicht kenne. Hat mein Gateway nicht. Wenn man das Feature unterstützen möchte braucht es Infos wozu das Ding da ist. Ich könnt den Typ zumindest im Code mal ignorieren (nachdem ich jetzt weiß, dass es sowas auch zu geben scheint). Bau ich evtl. ein.
Meldung kannst aber vermeiden idem du den IDs

Code Auswählen

/heatSources/accumulatedEMonitoring::: \

hinzufügst.
Du könntest die IDs noch etwas reduzieren, falls das Gateway/Heizung Probleme mit den vielen Anfragen hat.
Manche Einträge tauchen im Gateway auch an verschiedenen IDs auf. Kann man also raus werfen. SystemInfo brauchts sicher nicht gepollt. Kann man bei Interesse mit einem "get" lesen. Da steht glaube ich auch mehr drin, übertragt also viele Daten von der Heizung. DateTime würde ich auch nicht jedes mal lesen, bzw. einfach gar nicht lesen. Druck reicht alle paar Stunden. comfort und eco Temperatur reicht im Hochlauf (Ändert man ja normal nicht). Wenn man die nicht gepollten Werte über FHEM ändert, dann werden sie ja in die Readings eingetragen. Pollen muss man die deshalb nicht laufend. Außentemperatur ändert sich auch nicht so schnell, kann man z.B. nur jedes 3. mal lesen. Die Logfiles werden +übrigens kleiner, wenn man nur Änderungen "*:*:1:*" melden lässt.

Code Auswählen


   /heatSources/accumulatedEMonitoring::: \
   /heatingCircuits/hc1/actualSupplyTemperature::: \
   /system/info:::SystemInfo \
   /gateway/DateTime:::DatumZeit \
   /system/appliance/systemPressure:240:0:Druck_Leitung \
   /heatingCircuits/hc1/temperatureLevels/comfort2:0::Temperatur_Tag \
   /heatingCircuits/hc1/temperatureLevels/eco:0::Temperatur_Nacht \
   /system/sensors/temperatures/outdoor_t1:3:1:Temperatur_aussen \

mit "get Buderus INFO"
einfach mal gucken, was so alles doppelt vor kommt und die dann gar nicht mehr abholen. Also "ID:::" setzen.
Wenn Du den loglevel testweise auf 5 setzt kannst Du im fhem.log mal nachgucken was das Modul dann alles wirklich aus dem Gateway abholt.
Ich hab da im Schnitt nur 13 Werte oder so. Damit läuft das bei mir Monate stabil.

Vom Aufbau her scheint es ja so zu sein:
Heizngsreglung/Sterung (RC300) => Interner Bus => Gateway => LAN => FHEM
Ich kanns nicht wirklich wissen, aber die Stabilität scheint mit der Menge der Anfragen zu fallen.
Evtl. gibts da irgendwo Überläufe/Verklemmer. Das kann Zwischen Steuerung und Gateway sein oder im Gateway selbst oder in der Heizung. LAN und FHEM verdauen die paar Daten jedenfalls ganz locker.

VG
Arno

arnoaugustin · 13 Dezember 2016, 10:45:39

Zitat von: obb20a am 13 Dezember 2016, 08:48:14
Es gibt in diesem Thread ja doch einige, die von beiden Modulen im Einsatz schruben - daher hab' ich BDKM natürlich hinzudefiniert - werde das im nächsten Anlauf mal prüfen, nachdem ich KM200 deaktiviert habe.

Zum Glück läuft bei mir FHEM auf einer ESXI, da kann ich einen Snapshot machen und zur Not wieder einen Rollback, wenn's wirklich komisch wird.

Gruss Stefan

Hallo Stefan,

ich geb Dir nattürlich recht. Das Gateway sollte das eigentlich verkraften können, kanns aber auf Grund der vielen Anfragen wohl nicht. Wenn die auch noch durcheinander kommen, also bevor eine Anfrage fertig bearbeitet worden ist, könnte es zusätzlich Probleme geben.
Ich würd das tunlichst lassen. Und darüber hinaus die Anfrage so weit wie möglich reduzieren. Außer du versuchts das Gateway auf Robustheit zu testen

VG

Arno

Hugo Becker · 13 Dezember 2016, 15:56:24

Hallo Arno,

vielen Dank für die Änderungen im Modul. Die nervigen (Massen-) Meldungen...

Zitat[Mon Dec 12 12:06:37 2016] fhem.pl: Use of uninitialized value $hth in substitution (s///) at ./FHEM/79_BDKM.pm line 450.
[Mon Dec 12 12:06:37 2016] fhem.pl: Use of uninitialized value $hth in concatenation (.) or string at ./FHEM/79_BDKM.pm line 451.

...sind bei mir seit dem Update verschwunden !!!

Ich hatte / habe zwar keine (sehr wenige) "Communication Errors" wie Bini, kann aber bestätigen, dass sie nur Auftreten wenn zuviele Werte auf einmal gepollt werden.
Hierr heisst es, ein gesundes Mittelmass zu finden, wie Du schon oben erläutert hast.
Das KM200-Modul läuft bei mir übrigens nicht parallel, nur BDKM.

Danke für Deine Antworten. Ich dachte schon Du hast die aus dem Projekt verabschiedet.
Vorallem: vielen, vielen Dank auch für das klasse Modul !!!

Gruß
Hugo

arnoaugustin · 13 Dezember 2016, 20:37:06

Zitat von: Hugo Becker am 13 Dezember 2016, 15:56:24
...
Danke für Deine Antworten. Ich dachte schon Du hast die aus dem Projekt verabschiedet.
Vorallem: vielen, vielen Dank auch für das klasse Modul !!!

Gruß
Hugo

Nee, aber in der MAINTAINER.txt steht ja auch, dass ich ne PM will wenn was is

Ich les natürlich nicht immer im Forum.
VG

arnoaugustin · 13 Dezember 2016, 21:14:00

Hi zusammen,

ich hab mir meinen Code nochmal angeguckt wegen dem Delay zwischen zwei Anfragen ans Gateway. Da musste ich doch nicht viel machen, da ich das praktisch schon drin hatte, falls das Gateway nicht kommuniziert.
Ich hab mal ne neue Version eingecheckt.
Änderungen:

eMonitoringList wird ignoriert.
neues Attribut "InterPollDelay".

Binis Heizung hatte ja diesen "eMonitoringList" Typ geliefert. Bis mir irgendwer was liefert oder wenigstens verbose 6 Logs schickt kann ich da erst mal nix machen außer das im Code zu ignorieren. Meine Heizung hat sowas nicht - also kann ich auch nichts ausprobieren.
Mit InterPollDelay kann man einen Delay-Wert definieren der fest legt, wie lange in Millisekunden zwischen dem Lesen von IDs verzögert wird. Der Wert steht default auf 0.
Mit der Verzögerung kann man das Gateway entstressen

Und drauf achten, dass ein Pollzyklus auch innerhalb von "BaseIntervall" fertig werden kann. Wenn nach dem Start 150 IDs gelesen werden und das InterPollDelay z.B. auf 500 (=0.5 Sekunden) steht, dann kann der Pollzyklus nicht unter 75 Sekunden dauern! Wenns zu lange dauert, dann fehlt auch nix, aber es wird ne Logmeldung aus gegeben!
Wenn man InterPollDelay auf 500 setzt und den verbose Level vom Modul auf 4, dann kann man z.B. mit "tail -F log/fhem.log" schön sehen, dass die Daten langsam abgeholt werden.

Und bitte gebt mal Rückmeldung ob die Heizungen damit besser klar kommen oder falls es Probleme gibt. So was hilft auch anderen weiter!
Und keine zwei Gateway-Module (KM200/BDKM) gleichzeitig laufen lassen!

Ich möcht hier auch noch mal auf folgenden Text aus dem KM200 FHEM Wiki hinweisen - Zitat:

"....Ohne, dass der Umstand in den Unterlagen der KMxxx Geräte aus datenschutzrechtlicher Sicht auch nur erwähnt ist, baut das KMxxx-Gerät nach jedem Polling seitens des fhem-Moduls von sich aus eine Verbindung zum Server von Buderus bzw. BOSH Thermotechnik auf. Über den Inhalt der Datenübertragung kann nur spekuliert werden. Um diese Datenübertragung zu unterbinden, muss man in dem jeweiligen Internet-Router das KMxxx Gerät bzw. dessen entsprechende IP-Adresse für den Internetzugang gesperrt werden. In der Fritz!Box bzw. unter Fritz!OS funktioniert dies am Besten mit der Kindersicherung Bei anderen Routern muss die entsprechende Bedienungsanleitung konsultiert werden. Eine erfolgreiche Sperrung des Internet-Zugangs quittiert das KMxxx Gerät mit dem Wechsel der Betriebs-LED auf die orange Farbe...."

Schönen Abend noch....
VG
Arno

Michael · 17 Dezember 2016, 17:35:52

Moin arnoaugustin

Schönes Modul, läut prima.
Habe z. Zt. zwar noch keine Anwendung, aber die werde ich bestimmt noch finden.

1.) Ich habe in den Reading's ReturnTemp und Temperatur_Ruecklauf Minuswerte
ist das ein Bug? sh. Anhang
2.) Gibt es irgend wo eine Beschreibung der Reading's bzw was für Einheiten stehen da hinter?

arnoaugustin · 18 Dezember 2016, 13:59:16

Zitat von: Michael am 17 Dezember 2016, 17:35:52
Moin arnoaugustin

Schönes Modul, läut prima.
Habe z. Zt. zwar noch keine Anwendung, aber die werde ich bestimmt noch finden.

1.) Ich habe in den Reading's ReturnTemp und Temperatur_Ruecklauf Minuswerte
ist das ein Bug? sh. Anhang
2.) Gibt es irgend wo eine Beschreibung der Reading's bzw was für Einheiten stehen da hinter?

Moin,

1) ist kein Bug. Die Heizung liefert einfach den Wert an den dem Alias von ReturnTemp unterliegenden Wert.
Wenn ein Rücklauftemperaturgeber vorhanden ist und der an der Heizung nachgesehen werden kann, dann wird er auch sicher irgendwo abgelegt werden. Musst die Aliase dann halt anders vergeben.
2) Mal im Thread lesen und in comandref wegen get INFO usw.

VG

VG