Logfile groß, viele Einträge von CCU3-Devices

Dieter Rapp · 13 Oktober 2021, 00:33:33

Hallo,
ich habe eine Homematic CCU3 mit z.Zt. 5 Kanälen (HMCCUCHN) und 17 Thermostaten (HMCCUDEV) in FHEM eingebunden. Die Kanäle fangen alle mit "chn_" an, die Thermostate mit "dev_". Alle 10 Sekunden führe ich "get dev_.* update" und "get chn_.* update" aus, damit die Temperaturen immer aktuell angezeigt werden.
Dummerweise wird dabei für jeden Kanal und jedes Thermostat ein Eintrag ins Logfile geschrieben wird. Alle 22 Einträge sehen gleich aus:

2021.10.13 00:02:08 4: HMCCU: [CCU3 : 1207] Build URL = http://192.168.178.97:8181/tclrega.exe

Ich habe das globale Attribute verbose auf 0 gestellt. Damit sollte eigentlich gar nichts mehr ins Logfile eingetragen werden. Da die Einträge oben das Loglevel 4 haben, sollten sie nicht geschrieben werden. Das stimmt für alle Aufrufe von Log(), die ich benutze. Aber das Perl-Modul für die CCU3 scheint das nicht zu interessieren. Was kann ich da machen?

Beta-User · 13 Oktober 2021, 06:34:11

Vorab mal: Willkommen im Forum!

Wie steht denn verbose am HMCCU-Gerät? Vielleicht reicht es, wenn du an global und an diesem Gerät verbose einfach wieder löschst

.

Ansonsten wundert mich etwas, dass man bei HMCCU pollen muss, ich hätte vermutet, dass das pusht, kenne das aber nicht.

Wernieman · 13 Oktober 2021, 10:25:05

HMCCU bekommt die Info per "rpc-Server" .. also ja, gepushed.

Die Frage ist also eher: Warum muß hier gepollt werden? Könnten wir mehr Info übers System bekommen?
(Software, Hardware etc.)

Dieter Rapp · 15 Oktober 2021, 16:15:22

Gelöst!

Da kann ich mir gleich selbst antworten:
Nachdem ich das Perl-Modul 88_HMCCU.pm nach dem Ausgabetext "Build URL" durchsucht habe, habe ich herausgefunden, dass hier die Funktion Log3 verwendet wird. Die verwendet als erstes Argument den Namen des Devices, bei dem das Attribute 'verbose' überprüft wird. Das war bei mir "CCU3". Ja und da stand 'verbose' auf 5. Kein Wunder, dass die Änderung des globalen Attributes 'verbose' nicht geholfen hat...

Jetzt ist alles okay und das Log bleibt schön klein.

Dieter Rapp · 15 Oktober 2021, 16:30:32

Danke für die herzliche Begrüßung.

Bezüglich des Pollings, das mache ich, damit die Temperaturanzeigen zügig upgedatet werden. Kann sein, dass das auch automatisch passiert. Ich wollte halt nur nicht minutenlang warten.

Ich verstelle die Solltemperatur an einem Channel mit 'set chn_XX controldatapoint YY' und möchte sehen, dass alle zugehörigen Thermostate ihren Wert ebenfalls updaten. Wenn ich das unmittelbar nach dem Schreiben des neuen Wertes einen Update durchführe, dann sind die neuen Werte bei den Thermostaten noch nicht gesetzt. Also muss ich ein wenig warten. Ich habe das so gemacht, dass ich alle 10 Sekunden 'get dev_.* update' für die Thermostate und 'get chn_.* update' für alle Channel ausführe. Normalerweise sehe ich den neuen Wert spätestens 10 Sekunden, manchmal dauert es auch etwas länger.

Wie lange würde es dauern, bis ich ohne manuellen Update die neuen Werte sehe? Im Augenblick bin ich in der Testphase und will sofort sehen, wenn sich was ändert. Im Regelbetrieb kann das ruhig länger dauern, da schaut ja keiner zu und wartet.

Dieter Rapp · 15 Oktober 2021, 19:06:41

Zitat von: Wernieman am 13 Oktober 2021, 10:25:05
HMCCU bekommt die Info per "rpc-Server" .. also ja, gepushed.

Die Frage ist also eher: Warum muß hier gepollt werden? Könnten wir mehr Info übers System bekommen?
(Software, Hardware etc.)

Danke für den Tipp.

Ich benutze FHEM in der Revision 21051 auf Raspberry Pi in einer virtuellen Maschine (Oracle VM Virtual Box) unter Windows 10. Mein HMCCU-Device ist eine CCU3 mit 17 Funkthermostaten, die aktuell auf 8 Channels (Räume) verteilt sind.

Polling ist tatsächlich nicht nötig. Ich habe beim Einrichten der CCU3 etwas vergessen, nämlich das hier:

attr CCU3 ccuflags procrpc
attr CCU3 rpcserver on

Bei mir hatte das Attribut rpcstate immer den Wert Inactive, also ist der RPC-Server nicht gelaufen. Ich habe zwar versucht den RPC-Server zu starten, indem ich rpcserver auf on gesetzt habe. Aber das hat nicht funktioniert, wohl weil das Attribut ccuflags nicht definiert war.

Jetzt kann ich auf das manuelle Update alle 10 Sekunden verzichten, die Werte werden vom RPC-Server in einem ähnlichen Zeitrahmen aufgefrischt.

Wernieman · 15 Oktober 2021, 19:10:49

Wirklich unter Windows? Also RasPi mit VM und dort dann Windows ...... ??

Könnte sonst auch daran liegen ...

frank · 15 Oktober 2021, 19:15:49

ZitatRevision 21051

aktuell ist 25073

Beta-User · 15 Oktober 2021, 21:52:53

...und HMCCU 5.0 beta ist vermutlich auch "besser" als die letzte "offizielle"...
(frage mich, wann zap die eincheckt, das sollte eigentlich vor zwei Wochen erfolgen.)

Dieter Rapp · 15 Oktober 2021, 22:38:24

Zitat von: Wernieman am 15 Oktober 2021, 19:10:49
Wirklich unter Windows? Also RasPi mit VM und dort dann Windows ...... ??

Könnte sonst auch daran liegen ...

Nein, umgekehrt. Der Host läuft unter Windows. Das Gast-System ist ein RaspPi-Linux.

Dieter Rapp · 15 Oktober 2021, 22:40:28

Zitat von: frank am 15 Oktober 2021, 19:15:49
aktuell ist 25073

Ich habe FHEM schon vor längerer Zeit aufgesetzt und nie einen Update durchgeführt. Wird wohl mal Zeit...

Dieter Rapp · 15 Oktober 2021, 23:25:53

Zitat von: Dieter Rapp am 15 Oktober 2021, 19:06:41
Danke für den Tipp.

Ich benutze FHEM in der Revision 21051 auf Raspberry Pi in einer virtuellen Maschine (Oracle VM Virtual Box) unter Windows 10. Mein HMCCU-Device ist eine CCU3 mit 17 Funkthermostaten, die aktuell auf 8 Channels (Räume) verteilt sind.

Polling ist tatsächlich nicht nötig. Ich habe beim Einrichten der CCU3 etwas vergessen, nämlich das hier:

attr CCU3 ccuflags procrpc
attr CCU3 rpcserver on

Bei mir hatte das Attribut rpcstate immer den Wert Inactive, also ist der RPC-Server nicht gelaufen. Ich habe zwar versucht den RPC-Server zu starten, indem ich rpcserver auf on gesetzt habe. Aber das hat nicht funktioniert, wohl weil das Attribut ccuflags nicht definiert war.

Jetzt kann ich auf das manuelle Update alle 10 Sekunden verzichten, die Werte werden vom RPC-Server in einem ähnlichen Zeitrahmen aufgefrischt.

Zu früh gefreut...

Leider habe ich gerade festgestellt, dass nur die Channels (HMCCUCHN) upgedated werden, nicht aber die Daten der Thermostate (HMCCUDEV). Wenn ich bei den Thermostaten get dev_.* update ausführe, dann sehe ich die veränderten Werte, von alleine funktioniert der Update nur bei den Channels. Ist das normal so?

Ich habe ein HMCCU-Device (CCU3) und drei HMCCURPCPROC-Devices (CCU RPC BidCos-RF, CCU RPC HmIP-RF und CCU RPC VirtualDevices). Bei allen vier steht rpcstate auf running und state auf OK.

Ich kann natürlich wieder zurück zu meinem zyklischen Polling, zumindest für die Thermostate. Aber schöner wären automatische Updates von Seiten des RPC-Servers.

schwatter · 16 Oktober 2021, 08:35:03

Morgen,
ich habe nur eine Fussbodenheizung von HmIp und diese letzten Winter schnell eingerichtet über Debmatic. Sprich ich bin kein Maßstab für qualitative Antworten und beschäftige mich jetzt erst wieder damit.
Aber es müssen mein ich Filter gesetzt werden per ccudef-readingfilter. So sieht das bei mir aus. Das musst du auf dich anpassen. Dient der Lastreduzierung.

edit:
Und ich meine ohne den Filter wurden bei mir die Readings auch nicht aktualisiert.

Code Auswählen


^(LOW_?BAT|UNREACH|ACTUAL_TEMPERATURE|HUMIDITY)$

Wernieman · 16 Oktober 2021, 16:57:45

Bist Du Dir sicher, das die CCU bei der Channel Aktuallisierung überhaupt alle Devices Aktuallisiert?

Dieter Rapp · 16 Oktober 2021, 19:53:21

Zitat von: Wernieman am 16 Oktober 2021, 16:57:45
Bist Du Dir sicher, das die CCU bei der Channel Aktuallisierung überhaupt alle Devices Aktuallisiert?

Ich verstehe es nicht so richtig, aber jetzt funktioniert es.

Keine Ahnung, was ich geändert habe, dass es nun läuft. Die Attribute ccudef-readingfilter musste ich nicht definieren. So wie ich das verstanden habe, dienen sie eher dazu, die Menge der Readings für den Update einzuschränken.

Das zyklische Polling habe ich mittlerweile rausgeschmissen. Die Werte aller Thermostate werden trotzdem aktualisiert. Dauert manchmal eine Weile, bleibt aber unter 20 Sekunden. Damit kann ich leben.

Ich hoffe, die Sache ist damit erledigt. Vielen Dank nochmal für die Hilfe.