[HMCCU] Feature Request

Begonnen von PatrickR, 18 November 2019, 18:31:14

Vorheriges Thema - Nächstes Thema

PatrickR

Guten Abend zusammen!

In der Vergangenheit hatte ich mehrfach das Problem eines hohen Duty Cycle der CCU. Den Antworten in Foren und Gruppen nach ist der Standard-Ansatz bei diesem Problem das Raten ("Bei mir waren das Problem die HmIP-PSMs").

Ich habe meine Probleme in den Griff bekommen, indem ich den RPC-Devices das ccuflag logEvents hinzugefügt und die Logfiles mit einem Skript ausgewertet habe. Das führt leider zu großen Logdateien, da jedes Paket geloggt wird.

Besteht die Möglichkeit, jedem Gerät zwei Readings mit einem Counter der gesendeten und empfangenen Pakete hinzuzufügen oder (gerne deaktivierbare) Events, mit denen ich innerhalb von FHEM eine solche Statistik führen kann?

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

BadenPower

Arbeitest Du mit Windows?

Wenn ja, dann mußt Du nicht länger raten oder ewig große Log-Dateien auswerten.

Der HM-Analyser der HM-Internals kann die ausgehenden SysLog- und RPC-Daten live und gefiltert darstellen und speichern.
Damit findet man einen DutyCycle-Hochtreiber im Handumdrehen.

.
Zitat eines Users per PN:
Die Dummheit eines Forums, vor allem deren Nutzer, läßt sich daran ablesen, wie oft Personen als Troll bezeichnet werden, wenn sie offenkundige Fehlverhalten von anderen Benutzern öffentlich machen.

PatrickR

Zitat von: BadenPower am 18 November 2019, 21:38:09
Arbeitest Du mit Windows?
Eigentlich nicht. Nur, wenn ich dafür bezahlt werde, d. h. auf der Arbeit ;)

Zitat von: BadenPower am 18 November 2019, 21:38:09
Der HM-Analyser der HM-Internals kann die ausgehenden SysLog- und RPC-Daten live und gefiltert darstellen und speichern.
Damit findet man einen DutyCycle-Hochtreiber im Handumdrehen.
Offen gestanden werde ich (neben der Windowsproblematik) mit dem Lizenzmodell nicht warm.

Werde bei Gelegenheit mal einen Client/Server für die RPC-Schnittstelle schreiben. Nach einem ersten Blick auf die API sollte das für meinen spezifischen Anwendungszweck kein Problem darstellen. Eleganter wäre es natürlich als Feature "für Alle" im hmccu-Modul.

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

zap

Ich hab´s auf die Liste gesetzt
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

PatrickR

lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook