Shellys bringen den Event monitor ins Rotieren

Begonnen von Gundermann, 28 Januar 2020, 18:56:03

Vorheriges Thema - Nächstes Thema

Gundermann

Hallo FHEM-Forum,

seit ich einige Shelly1 als MQTT2_DEVICE mit FHEM betreibe kommt mein Event monitor ganz schön ins Rotieren. Bisher ist es mir gelungen mit "event-min-interval", "event-on-change-reading" und "event-on-update-reading" den Event monitor einigermaßen ruhig zu halten, weil ich denke, dass dadurch eine geringere Systembelastung entsteht. Bei den Shellys funktioniert das ingenwie nicht. Die geben nun alle 30 Sekunden jeweils drei Meldungen von sich, die im Event monitor angezeigt werden (z.B. "relay0: off" und "off" und "input0: 1"). Kann man das irgendwie reduzieren ohne die Funktion zu beeinträchtigen?

Ja ich weiß. Dieses oder ein ähnliches Thema wurde schon irgendwann und irgendwo im Forum behandelt. Deshalb bitte ich schon jetzt um Vergebung für diese Frage.

Sorry und Grüße von Gundermann (noch immer Anfänger)
FHEM auf RPi 4B | CUL 868 MHz | SIGNALduino 433 MHz | FRITZ!Dect | FS20 | Homematic | Intertechno | Sonoff | Shelly | IP-Kameras | Wettersensoren | ZigBee | ...
FHEM ist nicht Plug & Play. Man muss bereit sein hinter die Kulissen zu schauen.

Otto123

Hallo,

event-on-change-reading .* ist das Mittel der Wahl die Events minimal zu halten.

Alle 30 sec 3 Meldungen sind jetzt nicht das große Ding. ;D

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Die tiefere Ursache dürfte auf dem shelly zu finden sein. Warum sendet der überhaupt wasbzw. so viel unnötige Informationen...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Otto123

hab ich was falsch gelesen? Alle 30 sec 3 Meldungen ist doch normal? :-[
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: Otto123 am 28 Januar 2020, 22:10:28
hab ich was falsch gelesen? Alle 30 sec 3 Meldungen ist doch normal? :-[
In meiner Gedankenwelt wären 30 Sek. z.B. für temp/hum-Werte noch "normal" (aber meist auch unnötig).

Was mich stört, ist dass das scheinbar auch on/off-Zustände und den "input"-Schalter betrifft:
Zitat von: Gundermann am 28 Januar 2020, 18:56:03
Die geben nun alle 30 Sekunden jeweils drei Meldungen von sich, die im Event monitor angezeigt werden (z.B. "relay0: off" und "off" und "input0: 1").
Da sehe ich das so:
Mich interessiert der Zustand, klar. Aber nur einmal, nämlich nach der Ausführung des Befehls bzw. beim Betätigen des (lokalen) Schalters, hilfsweise noch beim Reboot von dem Teil. Dann stimmen die Zeitstempel usw.. Da der TE sich wundert, gehe ich mal davon aus, dass nicht alle 30 Sek. geschaltet wird...

Bleibt eine Frage, die dann noch zu offen ist: Ist das Teil noch online? Die zu beantworten ist aber nicht Aufgabe von "relay0", sondern das sollte über den LWT-Mechanismus und ein anderes Reading geklärt werden ;) . Ergo bin ich 1:1 bei Gundermann: Das sollte anders sein!

PS:
Zitat von: Gundermann am 28 Januar 2020, 18:56:03
Ja ich weiß. Dieses oder ein ähnliches Thema wurde schon irgendwann und irgendwo im Forum behandelt. Deshalb bitte ich schon jetzt um Vergebung für diese Frage.
Jedenfalls mir war dieses Verhalten bisher nicht bekannt gewesen (ich habe aber keinen Shelly und wundere mich manchmal, worüber sich eine Vielzahl von Usern nicht zu wundern, wenn ich dann mal konkrete Hardware in die Hände bekomme). Trotzdem finde ich diese Art der "Vorabentschuldigung" suspekt und hätte vermutlich nie was geschrieben, wenn hier nicht (mMn.) ein Mißverständnis bei einem wichtigen Mitstreiter zu klären gewesen wäre...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gundermann

Hallo Otto123 und Beta-User,

danke für die Rückmeldungen.

Ich habe jetzt wie vorgeschlagen event-on-change-reading .* gesetzt, die besagten Meldungen sind weg und die Shellys funktionieren wie vorher. Wenn ich sie mit dem angeschlossenen Taster oder über FHEM schalte, werden diverse Einträge in den event Monitor geschrieben.

Also ist für mich alles wie ich es mir wünsche und gut. Leider fehlen mir für den tieferen Einblick in die Materie die Kenntnisse.

Die "Vorabentschuldigung" kam mir deshalb in den Sinn, weil manch einer in diesem Forum auf solche Wiederholungsfragen etwas empfindlich reagiert. Das lässt sich aber bei der Fülle der Informationen bei "Anfängern" nur schwer vermeiden.

Danke und freundliche Grüße von Gundermann

FHEM auf RPi 4B | CUL 868 MHz | SIGNALduino 433 MHz | FRITZ!Dect | FS20 | Homematic | Intertechno | Sonoff | Shelly | IP-Kameras | Wettersensoren | ZigBee | ...
FHEM ist nicht Plug & Play. Man muss bereit sein hinter die Kulissen zu schauen.

Otto123

#6
Moin Gundermann,

Du musst Dich nicht entschuldigen. :)
ZitatBisher ist es mir gelungen mit "event-min-interval", "event-on-change-reading" und "event-on-update-reading" den Event monitor einigermaßen ruhig zu halten
Meine erste Antwort  bezog sich vor allem auch auf diese Aussage.

Alle event-.* Attribute zu setzen ist aus meiner Sicht selten wirklich sinnvoll. event-on-change-reading verringert fast in jedem Fall die Events...

Und ich finde alle 30 sec ein paar Events ist ein relativ "langweiliges Programm" - da würde ich nicht hinschauen. rotierend würde ich den Monitor nennen, wenn der Browser nicht nachkommt die Events anzuzeigen ;)

Ich meine das Teil liefert Messwerte, die will man doch aktuell haben!? Ja der Relais wäre nicht nötig den zyklisch zu senden, aber der kommt einfach mit? Und im off Zustand weiß man dadurch das Ding lebt. ;)
@Beta-User
Die senden doch eh einen json String, da ist der Zustand vom Relais einfach mit drin.
https://shelly-api-docs.shelly.cloud/#shelly-plug-plugs
Oder meinst  Du im ausgeschalteten Zustand sollte die Übermittlung eingestellt werden?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Thyraz

Ich finde auch ok, wenn die Readings aktualisiert werden sobald das Gerät das eben sendet.
Wenn das im JSON so derin steht sollte das so durchgereicht werden.

Wer nur bei Änderungen benachrichtigt werden will verwendet event-on-change-reading.
Dazu ist es ja da.
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Beta-User

Zitat von: Otto123 am 29 Januar 2020, 08:45:32
Ich meine das Teil liefert Messwerte, die will man doch aktuell haben!? Ja der Relais wäre nicht nötig den zyklisch zu senden, aber der kommt einfach mit? Und im off Zustand weiß man dadurch das Ding lebt. ;)
@Beta-User
Die senden doch eh einen json String, da ist der Zustand vom Relais einfach mit drin.
https://shelly-api-docs.shelly.cloud/#shelly-plug-plugs
Oder meinst  Du im ausgeschalteten Zustand sollte die Übermittlung eingestellt werden?
Nein, ich meine, es macht keinen Sinn, zyklisch alles zu senden, ob jetzt über den JSON-Blob oder "klassisch". Das ist m.E. ein Designfehler der firmware.
Vollständige Info macht nur beim reboot Sinn, danach will ich eigentlich nur Differenzmeldungen haben, ganz unabhängig vom an/aus-Zustand...
(Aber ich sehe grade, dass meine Tasmotas diesen Unsinn genauso betreiben...)

Ansonsten ist klar: Ausgewertet wird eben, was das Gerät sendet, und das ist an sich ok so (was die FHEM-Seite betrifft). Die Filterei auf FHEM-Seite ist schon dazu da, solche Unzulänglichkeiten der firmwares zu kompensieren, aber besser ist es eben, das gar nicht erst zu generieren...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gundermann

#9
Hallo noch einmal,

ZitatUnd ich finde alle 30 sec ein paar Events ist ein relativ "langweiliges Programm" - da würde ich nicht hinschauen. rotierend würde ich den Monitor nennen, wenn der Browser nicht nachkommt die Events anzuzeigen

Ich möchte mir nicht vorstellen wie der event Monitor rotiert, wenn jemand 20 oder gar 50 Shellys am laufen hat  (das soll es ja geben, bei mir sind es zur Zeit nur 3).

Meine Shellys brauchen auch wirklich nur etwas zu melden, wenn sie geschaltet werden. Mehr als schalten können sie auch nicht (Shelly1, keine Messwerte). Wenn es z.B. um die Abfrage von Leistungs- oder Temperaturdaten geht, sieht das schon anders aus.

Ich denke man sollte, wo auch immer möglich und sinnvoll, die Datenflut begrenzen. Vieleicht fällt ja den Shelly-Entwicklern dazu noch etwas ein.

Grüße von Gundermann (zufriedener Anfänger)

FHEM auf RPi 4B | CUL 868 MHz | SIGNALduino 433 MHz | FRITZ!Dect | FS20 | Homematic | Intertechno | Sonoff | Shelly | IP-Kameras | Wettersensoren | ZigBee | ...
FHEM ist nicht Plug & Play. Man muss bereit sein hinter die Kulissen zu schauen.