Buderus KM200 Kommunikationsmodul

[Jorge3711]

Zu kurze Afragezyklen können dazu führen, dass sich das KM200 aufhängt, und dann kommt es grnsu zu solchen Fehlermeldungen.

Dann stellt sich mir die Frage, weshalb diese dann so vom Modul vorgegeben sind.

Aber ich habe noch etwas getestet:

Ich habe noch einen RasPi B+ mit meiner alten FHEM Installation, welchen ich zum testen benutze. Dort habe ich das DBLog aktiviert und anschließend mein KM200 eingebunden. Abgesehen davon, dass das Modul zu Beginn im Status Sounding hängen blieb, läuft das ganze jetzt seit über einer Stunde ohne Fehlermeldungen.
Damit sich die beiden FHEM Installationen beim Polling möglichst nicht in die Quere kommen habe ich auf meinem produktiven RasPi das Polling auf 10 Minuten gestellt. Beim Test RasPi mit DBLog habe ich IntervalDynVal auf 90 Sekunden und PollingTimeout auf 20 Sekunden gesetzt.

Auf meinem produktiven RasPi kam es im gleichen Zeitraum immer wieder mal zu den genannten Fehlermeldungen.

Auch interessant:
Der RasPi B+ braucht teilweise bis zu 1,5 Minuten (!) für ein komplettes Polling. Der RasPi 2 ist i.d.R. nach 20 - 30 Sekunden mit dem Polling fertig.

Es scheint also einen Unterschied zu machen, ob man FileLog oder DBLog nutzt.

Viele Grüße
Carsten

[DLindner]

2015.05.24 18:58:13 1: Accept failed (WEB: Too many open files)
2015.05.24 18:58:13 1: Accept failed (WEB: Too many open files)
2015.05.24 18:58:13 1: Accept failed (WEB: Too many open files)
2015.05.24 18:58:13 1: Accept failed (WEB: Too many open files)

Und vor allen Dingen:

Can't connect(2) to http://172.28.135.35:80: IO::Socket::INET: Too many open files

Jede offene TCP-Verbindung stellt einen offenen file handle dar.

Solltest mal die limits hochsetzen. Mit ulimit -a bekommst du in etwa folgende Ausgabe:

root@raspberrypi:~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 7731
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 7731
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Mit ulimit -n 4096 kannst Du den Wert der open files zum Testen auf das 4-fache hochsetzen. Mit "root - nofile 16384" am der der Datei /etc/security/limits.conf gibst du dem System das limit dauerhaft vor. Ich weiß allerdings auch nicht warum der Dir diese Fehlermeldungen rausschmeißt. Läuft auf Raspi noch was anderes?
Folgende shell-Befehle geben die Anzahl der file handle wieder:

root@raspberrypi:~# lsof -u fhem | wc -l      # offene Dateien vom user fhem
63
root@raspberrypi:~# lsof -u root | wc -l     # offene Dateien user root
635
root@raspberrypi:~# lsof | wc -l                 # alle offenen Dateien
846

lsof ohne Parameter listet alle file handles.

Falls lsof nicht vorhanden : apt-get install lsof

Meine FHEM Installation läuft auf einem RasPi B2 der direkt auf den gleichen Netzwerkswitch (GBit) eingesteckt ist wie das KM200

64 bytes from 172.28.135.35: icmp_req=1 ttl=64 time=7.68 ms
64 bytes from 172.28.135.35: icmp_req=2 ttl=64 time=5.68 ms
64 bytes from 172.28.135.35: icmp_req=3 ttl=64 time=3.71 ms
64 bytes from 172.28.135.35: icmp_req=4 ttl=64 time=1.72 ms

Für eine GBit Anbindung saumäßig. Sollte eigentlich im Bereich 0.3 ms laufen. Das ereiche ich mit einer schnöden Powerline-Verbindung und habe nur ganz, ganz selten Verbindungsabbrüche.

Der RasPi B+ braucht teilweise bis zu 1,5 Minuten (!) für ein komplettes Polling. Der RasPi 2 ist i.d.R. nach 20 - 30 Sekunden mit dem Polling fertig.
Es scheint also einen Unterschied zu machen, ob man FileLog oder DBLog nutzt.

Hat mit DbLog und File-Log nichts zu tun. Die Unterschiede von der Schreibgeschwindigkeit sollten eigentlich vernachlässigbar sein.

habe ich IntervalDynVal auf 90 Sekunden

Mit 90 Sekunden haust du dir dein filelog(Dblog) voll. 300 Sekunden ist ein akzeptabler Wert oder sollen statische Werte wie Temperaturvorgaben, Heizprogramm-Daten, etc. in Graphen dargestellt werden?

[furban]

Dann stellt sich mir die Frage, weshalb diese dann so vom Modul vorgegeben sind.

Aber ich habe noch etwas getestet:

Ich habe noch einen RasPi B+ mit meiner alten FHEM Installation, welchen ich zum testen benutze. Dort habe ich das DBLog aktiviert und anschließend mein KM200 eingebunden. Abgesehen davon, dass das Modul zu Beginn im Status Sounding hängen blieb, läuft das ganze jetzt seit über einer Stunde ohne Fehlermeldungen.
Damit sich die beiden FHEM Installationen beim Polling möglichst nicht in die Quere kommen habe ich auf meinem produktiven RasPi das Polling auf 10 Minuten gestellt. Beim Test RasPi mit DBLog habe ich IntervalDynVal auf 90 Sekunden und PollingTimeout auf 20 Sekunden gesetzt.

Auf meinem produktiven RasPi kam es im gleichen Zeitraum immer wieder mal zu den genannten Fehlermeldungen.

Auch interessant:
Der RasPi B+ braucht teilweise bis zu 1,5 Minuten (!) für ein komplettes Polling. Der RasPi 2 ist i.d.R. nach 20 - 30 Sekunden mit dem Polling fertig.

Es scheint also einen Unterschied zu machen, ob man FileLog oder DBLog nutzt.

Viele Grüße
Carsten

Nur auch noch mal ganz dumm angemerkt da man ja manchmal doch den Wlad vor lauter Bäumen nicht mehr sieht. Einfach den Raspi mal komplett neu gestartet hast du aber mal, oder?

[Jorge3711]

Und vor allen Dingen:Jede offene TCP-Verbindung stellt einen offenen file handle dar.

Solltest mal die limits hochsetzen. Mit ulimit -a bekommst du in etwa folgende Ausgabe:Mit ulimit -n 4096 kannst Du den Wert der open files zum Testen auf das 4-fache hochsetzen. Mit "root - nofile 16384" am der der Datei /etc/security/limits.conf gibst du dem System das limit dauerhaft vor. Ich weiß allerdings auch nicht warum der Dir diese Fehlermeldungen rausschmeißt. Läuft auf Raspi noch was anderes?

Auf diesem Raspi läuft nur FHEM. Habe jetzt meinen produktiven Raspi auch auf DBLog umgestellt. Wenn es nochmal solche Meldungen geben sollte, dann werde ich mir die Werte bzw. die Anpassung ansehen. Seit der Umstellung habe ich keine Fehler mehr im fhem.log bzgl. Verbindungsproblemen gesehen. Abwarten.

Für eine GBit Anbindung saumäßig. Sollte eigentlich im Bereich 0.3 ms laufen. Das ereiche ich mit einer schnöden Powerline-Verbindung und habe nur ganz, ganz selten Verbindungsabbrüche.

Stimmt, scheint dann aber am KM200 zu liegen, ein Ping vom Raspi auf den Router passiert in dem genannten Bereich von 0,x ms.

Mit 90 Sekunden haust du dir dein filelog(Dblog) voll. 300 Sekunden ist ein akzeptabler Wert oder sollen statische Werte wie Temperaturvorgaben, Heizprogramm-Daten, etc. in Graphen dargestellt werden?

Temperaturverläufe des Boilers usw. hätte ich gern irgendwann als Graphen. Muss ich noch überlegen was da sinnvolle Intervalle wären.

Grüße Carsten

[Sailor]

Hallo Carsten

Was bedeutet "Sounding..."?
Edit: Selbst nach einem Reboot des RasPi bleibt es bei "Sounding". Ich werde mal das Gerät stromlos machen (lassen)...

"Sounding" kommt aus dem englischen und bedeutet "Abklopfen" bzw. das "Gebälk abklopfen".
Soll heißen: Das Modul versucht herauszufinden welche Services die KM200-Kiste bereitstellt.
Solange du die bereits erwähnten Fehler im System hast, wird er diesen Vorgang nie beenden können und nicht auf "Standby" wechseln können.

Das selbst nach einem ReBoot das Teil immer noch auf "Sounding" steht, liegt an 2 Dingen:
a) fhem hat eine fhem.save - Datei, in denen für den Fall eines Neustarts der letzte Wert eines Readings gespeichert bzw. wieder aufgerufen wird.
b) Das Modul fängt natürlich sofort wieder an die KM200-Kiste abzuklopfen und geht auf "Sounding".

Gruß
   Sailor

[Sailor]

Moin zusammen

Für eine GBit Anbindung saumäßig. Sollte eigentlich im Bereich 0.3 ms laufen.

Full Ack

8ms brauche ich nicht mal für einen Ping an www.tagesschau.de . Und der liegt nicht gerade um die Ecke

Ich denke, hier liegt das Problem der Ausfälle tatsächlich an der Hardware-Anbindung.
Es kommt ja nicht einmal eine einzige brauchbare Antwort von der KM200-Kiste zurück.

Hast du auch ganz sicher die KISTE für >36h im Internet gehabt (Grüner LED-Kreis leuchtet)?

Gruss
    Sailor

Gruss
    Sailor

[Sailor]

Hallo Carsten

Dann stellt sich mir die Frage, weshalb diese dann so vom Modul vorgegeben sind.

Wenn die Anbindung vernünftig funktioniert, ist der komplette Abklopfvorgang in 50s und ein anschließendes normales dynamisches Polling in 20s erledigt.

Gruß
    Sailor

[Sailor]

Hallo DLindner

Und vor allen Dingen:Jede offene TCP-Verbindung stellt einen offenen file handle dar.
Solltest mal die limits hochsetzen. Mit ulimit -a bekommst du in etwa folgende Ausgabe:Mit ulimit -n 4096 kannst Du den Wert der open files zum Testen auf das 4-fache hochsetzen.

Ich bin mir nicht sicher, ob dies das Problem lösen wird.

Wir reden hier in diesem Fall über einen Stack von TCP-Verbindungen und somit - wie du schon richtig gesagt hast - um einen Aufbau von file-handler, der schneller aufgebaut als er durch gültige Antworten seitens der KM200-Kiste wieder abgebaut wird.

Schlimmstenfalls wird das Problem durch den größeren Puffer lediglich verzögert.
Das Problem ist die Verbindung zum KM200. Wird das Problem gelöst und die Antworten kommen richtig, dann sind auch die anderen Symptome verschwunden...

Mit 90 Sekunden haust du dir dein filelog(Dblog) voll. 300 Sekunden ist ein akzeptabler Wert oder sollen statische Werte wie Temperaturvorgaben, Heizprogramm-Daten, etc. in Graphen dargestellt werden?

Hier lautet die Devise: "So kurz wie nötig und so lang wie möglich". Man muss abwägen zwischen einem schlanken Log-File auf der einen Seite sowie smoothen Graphen und zeitnaher Wechsel der Anzeigen (e.g. "Flame ON", Fehlermeldungen) auf dem Web-Interface.

Auf alle Fälle sollte bis zum gefundenen Fehler der Wert mal auf 300s gesetzt werden, die km200-Konsolenausgabe per Attribut aktiviert werden, und dann poste du Carsten mal deine Ausgabe.

Achtung, nach Aktivierung des Attributs

Code Auswählen Erweitern

attr <devicename> ConsoleMessage  1


muss fhem im (PUTTY) Konsolenfenster mittels

Code Auswählen Erweitern


sudo service fhem stop
sudo service fhem start

neu gestartet werden, um die Ausgabe in diesem fenster zu ermöglichen.

Gruss
    Sailor

[Starkstrombastler]

Bezüglich der Kommunikationsprobleme schlage ich vor, ein ungeschirmtes Patchkabel (kein Metall an den Steckern) zu probieren. Das hat bei mir geholfen.

[Jorge3711]

8ms brauche ich nicht mal für einen Ping an www.tagesschau.de . Und der liegt nicht gerade um die Ecke

Dann hast Du aber eine recht ordentliche Anbindung mit sehr geringer Latenz. Ich bekomme auf meinem Router kaum Pingzeiten unter 10 ms ins Internet (bei einem Kabelanschluss mit 120 MBit/s). Aber mir sind die Latenzzeiten auch nicht so wichtig, da ich nicht zocke Vielleicht wird Sohnemann sich in ein paar Jahren hier eher beschweren

Ich denke, hier liegt das Problem der Ausfälle tatsächlich an der Hardware-Anbindung.
Es kommt ja nicht einmal eine einzige brauchbare Antwort von der KM200-Kiste zurück.

Hast du auch ganz sicher die KISTE für >36h im Internet gehabt (Grüner LED-Kreis leuchtet)?

Hardwareanbindung ist für mich noch kein wirkliches Argument. Alle Raspis, Router und KM200 hängen am gleichen Switch. Alles kann ich < 1ms pingen, nur das KM200 antwortet mit >= 5ms. Mit welchen Zeiten könnt Ihr Eure KM200 anpingen? Würde mich mal interessieren.

Bevor ich das KM200 in FHEM eingebunden habe, hing es für eine ganze Weile (ich meine > 24h) am Internet. Eine Änderung der FW gab es keine (03.01.00). Auf Deinen Hinweis habe ich heute Morgen das KM200 in FHEM komplett deaktiviert (es lief übrigens die ganze Nacht ohne Fehler in den Logs) und habe es wieder ins Internet gelassen. LED-Kreis ist grün und die App zeigt mir jetzt die FW 03.01.09. Hier hat sich also etwas getan, wobei ich jetzt nicht weiß, ob das heute passierte oder evtl. gestern (da hatte ich das KM200 auch mal kurzfristig ins Internet gelassen).

Ich werde das KM200 jetzt mal noch eine Weile im Internet lassen (zumindest heute - sind nachher zum grillen eingeladen), auch wenn ich jetzt wohl mit die aktuellste FW lt. Google Docs habe.

Grüße von der Terrasse
Carsten

[Stefan M.]

Hi zusammen
ich hab die Googletabelle um die Pingzeit erweitert.

LG
Stefan

[Jorge3711]

Hi zusammen
ich hab die Googletabelle um die Pingzeit erweitert.

Das war eine gute Idee, vielen Dank! Habe meine Pingzeiten eingetragen (ermittelt über 100 Pings).

Grüße Carsten

[AndiL]

Hallo Carsten,

ich betreibe neben dem KM200 auch noch eine HUE-Bridge von Phillips.
Diese ist netzwerkmäßig genauso am Switch angeschlossen. Sogar die Entfernung ist identisch da sie nebeneinander an der Wand montiert sind.

Es verhält sich bei mir ebenfalls so, daß die HUE-Bridge und alles alles andere unter 1ms anpingbar ist.
Nur beim KM200 schwanken die Werte von 1 bis 9ms.
Das heißt wohl, daß das KM200 nicht das schnellste ist und Werte im o.g. Rahmen "normal" sind.
Ich habe meine Werte auch in der Liste eingetragen und scheinbar bewegen sich diese alle im gleichen Bereich.
   
Gruß
Andi

Im angehängten Bild unter IP....101 das KM200 und mit IP.....102 die HUE-Bridge

[Jorge3711]

Andere Frage in die Runde: Gibt es eigentlich ein Reading für die Zirkulationspumpe? Ich konnte bisher noch kein Reading zuordnen...

[Sailor]

Hallo Carsten

Andere Frage in die Runde: Gibt es eigentlich ein Reading für die Zirkulationspumpe? Ich konnte bisher noch kein Reading zuordnen...

Das Reading "/heatingCircuits/hc1/pumpModulation" zeigt den Modulationsgrad der Pumpe von 0 bis 100% an.

Wieviel [l/min] das am Ende bedeutet, hängt von der Pumpe und der Ventilstellungen im Haus ab.

Gruss
    Matthias