Homematic IP - Hoher Duty Cycle

Begonnen von PatrickR, 04 August 2019, 19:30:10

Vorheriges Thema - Nächstes Thema

PatrickR

Hallo zusammen,

ich habe aktuell eine Raspberrymatic mit 2 Homematic- und 109 HmIP-Geräten. Der Duty Cycle fällt eigentlich nie unter 40%, so dass die Reserve für Firmware-Updates gering ist. Aktuell suche ich nach einer Möglichkeit, das Problem auf ein Gerät oder eine Gerätegruppe einzugrenzen. Das Logging auf der Raspberrymatic gibt für Homematic ganz brauchbare Log-Einträge aus, wenn Kommunikation stattfindet, für Homematic IP nicht.

Kennt jemand eine elegante Möglichkeit, an das Problem heranzugehen? Ich hatte noch ins Auge gefasst, eine zweite FHEM-Instanz aufzusetzen, auf event-on-change-reading zu verzichten und eine kleine Statistik darüber zu fahren, welches Gerät besonders oft sendet, bin aber offen für schönere Lösungen.

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

PatrickR

Guten Abend!

Update:
Ich habe mittlerweile eine einfachere Möglichkeit gefunden, das Thema anzugehen: Auf den RPC-Interfaces das flag logEvents setzen. Über eine Quick'n'Dirty zusammengebaute Pipe konnte ich damit eine TOP10-Liste der Geräte erstellen, die besonders viele Events schicken.

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

Auf vielen Geräten kann man die Frequenz einstellen, in der Statusmeldungen geschickt werden (zB Temperaturwerte bei einem Thermostaten, oder Helligkeitswerte bei einem Lichtsensor).
>100 Geräte sind eine Menge. allerdings habe ich auch schon fast 80 und keinerlei Probleme mit dem Duty Cycle.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

frank

ich tippe auf aktoren mit leistungsmessung.
bei den bidcos modellen kann man mit entsprechender konfiguration die gateways schnell in den overload bringen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

PatrickR

Hi!

Wie gesagt, mir ging es darum, das Problem strukturiert anzugehen. Mit der obigen Methode habe ich schon einmal die Wetterstation als Hauptübeltäter identifiziert. Danke übrigens für logEvents Zap. Das hat sehr geholfen.

Patrick


Von unterwegs gesendet.
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