da ich gerade am perf tunen bin, frage ich mich wie ich Events für ein reading abschalten kann das ich nicht brauche?
Bei readings die sich nicht ändern gehts es ja mit dem "attr name timestamp-on-change-reading .*"
Aber wie mache ich es bei readings die sich ändern?
Habe zwei Fälle.
1. das unifi device
5fb4f94b8f3c49010e0560f9_last_seen 2022-12-27 12:30:29 2022-12-27 12:30:38
5fb4f94b8f3c49010e0560f9_snr 40 2022-12-27 12:30:38
5fb4f94b8f3c49010e0560f9_uptime 633600 2022-12-27 12:30:38
Bis auf das snr ändern sich die daten natürlich für alle WLAN Geräte ständigst und ich bringe diese Events nicht weg die ich nicht brauche.
2. Für die WEtterstation habe ich einen SysLog Server Device das generiert mir jedesmal ein reading mit MSG_ESP-0948FC.localdomain mit den JSON Daten drinnen die dann entjsont werden die result werte kann ich dann wieder schön beschränken das ist kein problem mehr.
https://forum.fhem.de/index.php/topic,130912.15.html#msg1251523
hmmm so ganz check ich das noch nicht.
hätte nun probiert
attr SyslogServer event-on-change-reading (?!MSG_ESP-0948FC.localdomain).*
aber der Wert von dem MSG_ESP-0948FC.localdomain wird nun gar nicht mehr geändert - ich dachte es wird nur kein Event mehr ausgelöst dafür?
Meine auffassung war das das event-on-change-reading NUR dafür da ist ob ein Event ausgelöst wird (im EventMonitor sichtbar dann) und keinen Einfluss darauf hat dass das Reading den Wert hat oder nicht?
Woran machst du fest, dass der wert nicht mehr geändert wird? Die anzeige im Frontend basiert auf websockets und Events. Damit wird der neue wert erst sichtbar, wenn du Seite mit F5 reloadest, dann sollte der neue wert sichtbar sein.
Aber du schriebst, dass einzelne Teile aus dem json dann extrahiert werden. Wenn du das beispielsweise Event-basiert machst, dann klappt das nicht mehr.
Meine Antwort bezog sich übrigens nur auf deinen 1.punkt, genau beim unifi-controller hab ich das auch gebraucht.
Ja ich habe natürlich F5 gedrückt, und es kam dann keine neuen Werte mal rein.
Das extrahieren erfolgt hier per Userreadings
aussentemperatur { my $w=ReadingsVal($name,"MSG_ESP-0948FC.localdomain",0) ;; $w =~ s/.*"w_temperatur".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
gefuehlte_temperatur { my $w=ReadingsVal($name,"MSG_ESP-0948FC.localdomain",0) ;; $w =~ s/.*"w_windchill".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
taupunkt_temperatur { my $w=ReadingsVal($name,"MSG_ESP-0948FC.localdomain",0) ;; $w =~ s/.*"w_taupunkt".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
aber so weit war ich noch gar nicht, sonder das reading selbst wurde anscheinend nicht mehr aktualisiert.
Aber eventuell hat es da was mit dem Modul SysLog Server zu tun, den da funktioniert es anders - mit dem Attr makeEvent no, genau so wie ich es haben möchte - es war halt nur komisch
Du hattest ja Probleme mit der Performance, deine userreadings haben keine Trigger und werden damit bei jedem Event des devices ausgelöst, das ist wenig sinnvoll. Je nach Anzahl der Events/anderen readings kann das unnötig ausgeführt werden.
Zitat von: sn0000py am 27 Dezember 2022, 12:34:07
da ich gerade am perf tunen bin, frage ich mich wie ich Events für ein reading abschalten kann das ich nicht brauche?
[...]
Habe zwei Fälle.
1. das unifi device
Ich habe hier nach Hin- und Herprobieren mich für eine Positivliste entschieden:
attr <Unificontroller> event-on-change-reading [A-Za-z0-9-]+,-UC_.*-UC_.* ist zur Überwachung der Funktion an sich und
[A-Za-z0-9-]+ liefert Events für alle Readings ohne "_", d.h. <client>:(connected|disconnected)
Grüße
aber nur die Events bzw notify abschalten geht hier gar nicht?
Ich möchte das sich zumindest einige Readings aktualisieren, aber brauche bzw will keine Events
Zitat von: sn0000py am 29 Dezember 2022, 13:15:46
aber nur die Events bzw notify abschalten geht hier gar nicht?
Ich möchte das sich zumindest einige Readings aktualisieren, aber brauche bzw will keine Events
Anscheinend verstehe ich Dein Anliegen nicht. Wenn ich das lese, möchte ich antworten, dass die Readings beim Unifi-Controller doch alle immer wieder aktualisiert werden - bzw. soweit die Clients mit seinem Netzwerk verbunden sind -, aber dass die Events mit den genannten Möglichkeiten reduziert werden können. Oder wenn Du möchtest mit
attr <unifi-controller> event-on-change-reading ist_auskomplett deaktiviert werden.
Das scheint aber nicht Dein Problem zu sein. Was genau meinst Du mit "das sich zumindest einige Readings aktualisieren"?
Grüße
Zitat von: sn0000py am 29 Dezember 2022, 13:15:46
aber nur die Events bzw notify abschalten geht hier gar nicht?
Ich möchte das sich zumindest einige Readings aktualisieren, aber brauche bzw will keine Events
Na ja, mit (Info ohne code-Tags aus #1...!?!)
attr DEVICE timestamp-on-change-rading .*werden eben auch alle Zeitstempel nur dann aktualisiert, wenn sich das zugehörige Reading ändert. Wenn du das für einzelne Readings nicht so haben willst, wäre das wieder diese "alle nicht, bis auf ..."-Konstruktion, die hier schon gezeigt wurde ((?!bla).*).
Da es um MQTT geht: LWT-Event auf "offline" oä. funktioniert nicht zur Überwachung? (Darum ging es doch eigentlich, oder?)
Ok dann machen wir mal eines nach dem anderen.
Beim Unifi DEvice
define Unifi Unifi
attr Unifi event-on-change-reading -.*
attr Unifi room UnifiSwitch
attr Unifi timestamp-on-change-reading .*
# DEF 10.0.0.95 8443 crypt:5e50005c crypt:5d4d377a641c0211075d
# FUUID 5d43f628-f33f-1e88-b9ee-f7c4566f282dfbcb
# FVERSION 74_Unifi.pm:0.235000/2021-01-09
# LASTInputDev Unifi
# MSGCNT 2406158
# NAME Unifi
# NOTIFYDEV global
# NR 82
# NTFY_ORDER 50-Unifi
# STATE connected
# TYPE Unifi
# UC_VERSION 7.3.76
# Unifi_MSGCNT 2406158
# Unifi_TIME 2022-12-29 17:02:22
# VERSION 3.5.2
# eventCount 1671425
Bekomme ich nun für die -.* die notify und auch die readings werden geändert - so wie es sein sollte.
Aber zB.:
wz_tv-2529_last_seen 2022-12-29 17:00:04 2022-12-29 17:00:18
wz_tv-2529_snr 38 2022-12-29 16:57:10
wz_tv-2529_uptime 169107 2022-12-29 17:00:18
da ändert sich der uptime Wert nun nicht mehr und auch der timestamp nicht mehr
sobald ich den attr Unifi event-on-change-reading .* setze wird der wieder aktualisiert
wz_tv-2529_last_seen 2022-12-29 17:05:47 2022-12-29 17:06:26
wz_tv-2529_snr 37 2022-12-29 17:06:26
wz_tv-2529_uptime 169450 2022-12-29 17:06:26
Das sollte ja nicht das Verhalten sein oder?
Hast du denn Readings, die mit einem Bindestrich beginnen? Afaik werden die Regexe in diesen Attributen "Rudi-typisch" jeweils als "ganzer Ausdruck" ausgewertet (also mit ^ und $ ergänzt) ;) .
Ja genau das war der Test das die Readings die mit - beginnen
zb den hier, der wird dann auch geändert, und der timestamp aktualisiert und ich bekomme ein event
-AP_GARTEN_utilization 48,7 2022-12-29 17:24:11
aber eben der hier
wz_tv-2529_uptime 169107 2022-12-29 17:00:18
wird nicht mehr geändert (habe natürlich auch F5 gedrückt usw.)
Da würde ich eben gerne wollen, das der Wert natürlich sich ändert, auch der timestamp aber KEIN event/notify ausgelöst wird
...dann sollte wohl die regex in tocr passend gewählt werden... "Alles" passt m.E. nicht.
aber verstehe ich es falsch?
ich dachte der Wert selbst beim Reading sollte trotzdem aktualisiert werden (und dann mit einem druck auf F5 auch sichtbar werden?)
Zitat von: sn0000py am 29 Dezember 2022, 18:07:27
aber verstehe ich es falsch?
ich dachte der Wert selbst beim Reading sollte trotzdem aktualisiert werden (und dann mit einem druck auf F5 auch sichtbar werden?)
Da ist irgendetwas anderes schräg. Ich habe mal zwei Auszüge von meinem Unifi-Device gemacht:
define UNIFI_1 Unifi 192.168.1.79 8443 <creds> 15
attr UNIFI_1 alias Unifi-Controller
attr UNIFI_1 event-on-change-reading [A-Za-z0-9-]+,-AP-.*,-UC_.*
[...]
# READINGS:
# 2022-12-29 19:01:31 -AP-lastUpdate Thu Dec 29 18:01:31 2022
# 2022-12-29 19:01:31 Akon_uptime 4677772
define UNIFI_1 Unifi 192.168.1.79 8443 <creds> 15
attr UNIFI_1 alias Unifi-Controller
attr UNIFI_1 event-on-change-reading [A-Za-z0-9-]+,-AP-.*,-UC_.*
[...]
# READINGS:
# 2022-12-29 19:02:12 -AP-lastUpdate Thu Dec 29 18:02:13 2022
# 2022-12-29 19:02:12 Akon_uptime 4677828
Der zeitliche Abstand betrug ca. eine halbe Minute.
Das Reading "-AP-lastUpdate" ist in der eocr-Regex enthalten und feuert einen Event.
Das Reading "Akon_uptime" ist nicht in der eocr-Regex enthalten und feuert keinen Event, wird aber aktualisiert.
Grüße
hast du auch ein timestamp-on-change-reading in verwendung?
Zitat von: sn0000py am 29 Dezember 2022, 19:52:54
hast du auch ein timestamp-on-change-reading in verwendung?
Ich hatte bisher keinen Fall, bei dem timestamp-on-change-reading einen Nutzen gebracht hätte. Ist systemweit also nicht gesetzt.
Habe ich jetzt testweise beim Unifi-Controller identisch zum eocr gesetzt => keine Änderung im Verhalten bei diesen Readings.
Grüße
hmmm das ist komisch.
ich habe nun folgendes
[code]define Unifi Unifi 10.0.0.95 8443
attr Unifi event-on-change-reading [A-Za-z0-9-]+,-AP-.*,-UC_.*
attr Unifi room UnifiSwitch
attr Unifi timestamp-on-change-reading .*[/code]
damit werden die readings (.*_uptime und .*_last_seen) nicht mehr aktualisiert - und die werden ja alle 30 sekunden zumindest bei den sicher 50 aktiven devices aktualisiert.
Aber weder der timestamp noch der wert ändert sich. Das -AP-lastUpdate ändert sich aber brav
sobald ich das timestamp-on-change-reading .* wieder lösche, dann werden alle readings aktualisiert (Wert + timestamp)
Hallo sn0000py,
ich lese diesen Thread nun schon eine ganze Weile mit, aber irgendwie wird mir nicht klar, was das Problem ist.
Zitatda ich gerade am perf tunen bin, frage ich mich wie ich Events für ein reading abschalten kann das ich nicht brauche?
Bei readings die sich nicht ändern gehts es ja mit dem "attr name timestamp-on-change-reading .*"
Aber wie mache ich es bei readings die sich ändern?
Daraus lese ich, Du möchtest unnötige Events verhindern, richtig? Ich vermute die Verwirrung in diesem Statement:
ZitatBei readings die sich nicht ändern gehts es ja mit dem "attr name timestamp-on-change-reading .*"
wo ist das denn her? kenne ich so nicht.(*)
Ein Versuch der Erklärung:
ein Device, welches neu angelegt ist, hat diverse Readings, die z.B. von Sensoren oder aus dem Netz (Wetterdaten) kommen. Diese Readings erzeugen Events, jedesmal wenn sie neu geschrieben werden (unabhängig davon, ob sie nun gleich sind oder sich geändert haben).
Um diese "Flut" an events einzudämmen gibt es die Attribute event-on-change-reading, event-on-update-reading, event-min-interval, timestamp-on-change-reading.
Diese Attribute sind FILTER, d.h. sie können nur die events einschränken, erzeugen können sie keine! Sobald eines der event-on- Attribute gesetzt ist gibt es nur noch events von den dort eingetragenen Readings, die anderen sind "stumm" oder "abgeschaltet". Diese Readings erzeugen keine Events mehr, werden jedoch im Device selbst aktualisiert, und wenn Du die Browserseite aktualisierst siehst Du die neuen Werte und den dazugehörigen Timestamp (zu dem das Reading geschrieben wurde, egal ob geändert oder nicht).
(*) Das Attribut timestamp-on-change-reading sehe ich nur im Zusammenhang mit event-on-change-reading. Ich habe das bei genau 3 Devices gesetzt: ich rechne die Zeitspanne zwischen den Änderungen des Readings. Da auch unveränderte Zustände immer wieder neu geschrieben werden brauchts das timestamp-on-change-reading, da sonst die Zeit nicht korrekt berechnet werden kann.
Aus der Commandref timestamp-on-change-reading:
ZitatThe attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, the timestamps of the listed readings will not be changed if event-on-change-reading is also set and it would not create an event for this reading.
Dieses Attribut enthält eine durch Kommata getrennte Liste von Readings. Wenn gesetzt, werden die Zeitstempel der gelisteten Readings nicht aktualisiert wenn durch ein ebenfalls gesetztes event-on-change-reading für dieses Reading kein Ereignis erzeugen würde.
In der deutschen Version fehlt der Hinweis auf Regex, insgesamt bezieht sich das Attribut auf gesetzte event-on-change-reading Readings.
Ich will gar nicht darüber nachdenken, was ein .* als reading-Angabe am Ende bedeutet....
Versuch eines Vorschlags:
- schau Dir die Readings deinen Devices im Event-Monitor an, am besten ohne Einschränkungen.
- überleg, welche Readings sollen events auslösen, damit sie z.B. geloggt werden oder sich in der Browseroberfläche automatisch aktualisieren
- trage diese Readings in event-on-change-reading ein. Regex würde ich hier nur einfache verwenden, die direkt klar sind. Hängt vom persönlichen Regex-Kann-ich-level ab ;-)
- test: Eventmonitor beobachten, kommen die entsprechenden Events wie gewünscht? werden sie gelogged? werden sie aktualisiert angezeigt?
Finetuning:
- event-min-interval: kann nötig werden, wenn z.B. ein Sensor auch gleiche Daten liefert, diese aber doch in einem bestimmten Intervall gelogged werden sollen. Beispiel:Helligkeitssensor nachts. Da möchte man vielleicht jede Stunde ein Lebeszeichen, ausserdem sieht der Plot besser aus.
- event-on-update-reading: kann z.B. bei einem HUE-Taster nötig sein, der für jeden Tastendruck die gleiche Zahl schickt, um den Event auszuwerten.
- timestamp-on-change-reading: brauchts nicht, siehe oben.
bei allen nicht eingetragenen Readings bekommst Du nach einem Browserrefresh die aktuellen Werte und den letzten Timestamp, wann das reading geschrieben wurde. Das ist aber eigentlich nur informativ oder eben "völlich wurscht". Und falls es doch irgendwie wichtig wäre: dann soll es eben einen Event erzeugen und muss in event-on-.... eingetragen werden.
Der nächste Schritt sollte sein: alles, was auf Events reagiert (notify, at, userReadings,DOIF, FileLog, DBlog....) überprüfen, ob die triggernden "Filter" nicht zu unscharf sind. Das ist viel Arbeit, lohnt sich aber!
Das war jetzt viel allgemeines. Für genaueres zu Deinem Problem könntest Du ja mal anfangen vollständige lists vom Unify zu posten. Wenn Du die in Zitat-Tags packst sieht es zwar nicht so gut aus wie in Code-Tags, Du kannst aber betimmte Sachen farbig oder fett markieren, dann ist es übersichtlicher. Und bitte vollständig, da aus ein paar Zeilen nicht ersichtlich ist, welche Attribute wie gesetzt sind etc....
Viel Erfolg!
Sany
Ja danke, mein Hauptproblem war bzw ist der Bug mit event|timestamp-on-change-reading das die readings nicht mehr gesetzt werden.
zB.: Mein Beispiel war ein shelly per MQTT
die input readings sollte der Wert aktuell sein, und der Timestamp sollte auf den Wert stehen wann der input sich das letzte mal geändert hat, aber es sollte niemals ein event ausgelöst werden brauche ich nicht.
die relay_.* sollte auch der Timestamp nur dann gesetzt werden wenn sich der wert ändert, aber es sollte bei änderung ein event ausgelöst werden.
das funtkioniert leider nicht
Zitat von: sn0000py am 30 Dezember 2022, 11:48:14
das funtkioniert leider nicht
Zitat von: Beta-User am 29 Dezember 2022, 17:51:41
...dann sollte wohl die regex in tocr passend gewählt werden... "Alles" passt m.E. nicht.
Hast du das mal ausprobiert?
(Also auf denselben Wert setzen wir eocr).
Dann sollten alle nicht in eocr genannten Readings weiter aktualisiert werden, und der timestamp bei den von der regex erfassten dann nur bei Änderung.
Zitat von: Beta-User am 30 Dezember 2022, 11:53:18
Hast du das mal ausprobiert?
(Also auf denselben Wert setzen wir eocr).
Dann sollten alle nicht in eocr genannten Readings weiter aktualisiert werden, und der timestamp bei den von der regex erfassten dann nur bei Änderung.
Jop hab ich
zb diser shelly hier
define shelly.Kueche MQTT2_DEVICE
attr shelly.Kueche IODev mqttBroker
attr shelly.Kueche event-min-interval .*:3600
attr shelly.Kueche event-on-change-reading temperature:1,.*_power:1,relay_.
attr shelly.Kueche readingList shellies/shellyKueche/relay/0:.* relay_0\
shellies/shellyKueche/online:.* online\
shellies/shellyKueche/relay/0/power:.* relay_0_power\
shellies/shellyKueche/relay/0/energy:.* relay_0_energy\
shellies/shellyKueche/relay/1:.* relay_1\
shellies/shellyKueche/relay/1/power:.* relay_1_power\
shellies/shellyKueche/relay/1/energy:.* relay_1_energy\
shellies/shellyKueche/input/0:.* input_0\
shellies/shellyKueche/input/1:.* input_1\
shellies/shellyKueche/temperature:.* temperature\
shellies/shellyKueche/voltage:.* voltage\
shellies/shellyKueche/overtemperature:.* overtemperature\
shellies/shellyKueche/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr shelly.Kueche room Küche
attr shelly.Kueche setList relay_0 shellies/shellyKueche/relay/0/command $EVTPART1\
relay_1 shellies/shellyKueche/relay/1/command $EVTPART1\
x_update:noArg shellies/shellyKueche/command update_fw\
x_mqttcom shellies/shellyKueche/command $EVTPART1
attr shelly.Kueche stateFormat { ReadingsVal($name,"relay_0_power",0) . " W / " . ReadingsVal($name,"relay_0_energy",0) . "Wh - ".ReadingsVal($name,"relay_0", "off")." --- ".ReadingsVal($name,"relay_1_power",0) . " W / " . ReadingsVal($name,"relay_1_energy",0) . "Wh - ".ReadingsVal($name,"relay_1", "off") }
attr shelly.Kueche timestamp-on-change-reading temperature.*_power,relay_.,.*_energy
# FUUID 5dea1795-f33f-1e88-cccd-6ca92a79083a8457
# FVERSION 10_MQTT2_DEVICE.pm:0.268600/2022-12-16
# IODev mqttBroker
# LASTInputDev mqttBroker
# MSGCNT 3539
# NAME shelly.Kueche
# NR 142
# STATE 56.99 W / 670801Wh - on --- 19.70 W / 42322Wh - on
# TYPE MQTT2_DEVICE
# eventCount 43
# mqttBroker_MSGCNT 3539
# mqttBroker_TIME 2022-12-30 12:04:23
# READINGS:
# 2022-12-30 09:23:36 IODev mqttBroker
# 2022-12-26 13:37:04 fw_ver 20221027-092056/v1.12.1-ga9117d3
# 2022-12-26 13:37:04 id shellyKueche
# 2022-12-30 11:24:13 input_0 0
# 2022-12-30 11:24:13 input_1 0
# 2022-12-26 13:37:04 ip 10.0.0.181
# 2022-12-26 13:37:04 mac 98F4ABB8ADC9
# 2022-12-26 13:37:04 mode relay
# 2022-12-26 13:37:04 model SHSW-25
# 2022-12-26 13:37:04 new_fw false
# 2022-12-26 13:37:04 online true
# 2022-12-30 11:24:13 overtemperature 0
# 2022-12-30 12:04:03 relay_0 on
# 2022-12-30 11:24:13 relay_0_energy 670801
# 2022-12-30 12:04:06 relay_0_power 56.99
# 2022-12-30 12:03:42 relay_1 on
# 2022-12-30 11:24:13 relay_1_energy 42322
# 2022-12-30 12:04:06 relay_1_power 19.70
# 2022-12-29 20:20:53 state relay_1
# 2022-12-30 11:24:13 temperature 44.65
# 2022-12-30 12:03:14 voltage 241.58
# hmccu:
#
setstate shelly.Kueche 56.99 W / 670801Wh - on --- 19.70 W / 42322Wh - on
setstate shelly.Kueche 2022-12-30 09:23:36 IODev mqttBroker
setstate shelly.Kueche 2022-12-26 13:37:04 fw_ver 20221027-092056/v1.12.1-ga9117d3
setstate shelly.Kueche 2022-12-26 13:37:04 id shellyKueche
setstate shelly.Kueche 2022-12-30 11:24:13 input_0 0
setstate shelly.Kueche 2022-12-30 11:24:13 input_1 0
setstate shelly.Kueche 2022-12-26 13:37:04 ip 10.0.0.181
setstate shelly.Kueche 2022-12-26 13:37:04 mac 98F4ABB8ADC9
setstate shelly.Kueche 2022-12-26 13:37:04 mode relay
setstate shelly.Kueche 2022-12-26 13:37:04 model SHSW-25
setstate shelly.Kueche 2022-12-26 13:37:04 new_fw false
setstate shelly.Kueche 2022-12-26 13:37:04 online true
setstate shelly.Kueche 2022-12-30 11:24:13 overtemperature 0
setstate shelly.Kueche 2022-12-30 12:04:03 relay_0 on
setstate shelly.Kueche 2022-12-30 11:24:13 relay_0_energy 670801
setstate shelly.Kueche 2022-12-30 12:04:06 relay_0_power 56.99
setstate shelly.Kueche 2022-12-30 12:03:42 relay_1 on
setstate shelly.Kueche 2022-12-30 11:24:13 relay_1_energy 42322
setstate shelly.Kueche 2022-12-30 12:04:06 relay_1_power 19.70
setstate shelly.Kueche 2022-12-29 20:20:53 state relay_1
setstate shelly.Kueche 2022-12-30 11:24:13 temperature 44.65
setstate shelly.Kueche 2022-12-30 12:03:14 voltage 241.58
da sieht man schön, relay_1 ist on und aktuell, relay_1_power hat auch 19,7Watt aber relay_1_energy wird weder der Timestamp noch der Wert selber aktualisiert, der ist nach wie vor 42322, auch die input_0 und input_1 werden nicht mehr aktualisiert.
Hmm, vielleicht habe ich was an der Brille, aber soweit ich das erkennen kann, sind die beiden Attributinhalte eben NICHT wie vorgeschlagen identisch... bzw. tocr weniger im Vergleich zu eocr...
wenn ich die gleich mache (bis auf den Wert halt den den mag vermutlich der tocr nicht )
define shelly.Kueche MQTT2_DEVICE
attr shelly.Kueche IODev mqttBroker
attr shelly.Kueche event-min-interval .*:3600
attr shelly.Kueche event-on-change-reading temperature:1,.*_power:1,relay_.
attr shelly.Kueche readingList shellies/shellyKueche/relay/0:.* relay_0\
shellies/shellyKueche/online:.* online\
shellies/shellyKueche/relay/0/power:.* relay_0_power\
shellies/shellyKueche/relay/0/energy:.* relay_0_energy\
shellies/shellyKueche/relay/1:.* relay_1\
shellies/shellyKueche/relay/1/power:.* relay_1_power\
shellies/shellyKueche/relay/1/energy:.* relay_1_energy\
shellies/shellyKueche/input/0:.* input_0\
shellies/shellyKueche/input/1:.* input_1\
shellies/shellyKueche/temperature:.* temperature\
shellies/shellyKueche/voltage:.* voltage\
shellies/shellyKueche/overtemperature:.* overtemperature\
shellies/shellyKueche/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr shelly.Kueche room Küche
attr shelly.Kueche setList relay_0 shellies/shellyKueche/relay/0/command $EVTPART1\
relay_1 shellies/shellyKueche/relay/1/command $EVTPART1\
x_update:noArg shellies/shellyKueche/command update_fw\
x_mqttcom shellies/shellyKueche/command $EVTPART1
attr shelly.Kueche stateFormat { ReadingsVal($name,"relay_0_power",0) . " W / " . ReadingsVal($name,"relay_0_energy",0) . "Wh - ".ReadingsVal($name,"relay_0", "off")." --- ".ReadingsVal($name,"relay_1_power",0) . " W / " . ReadingsVal($name,"relay_1_energy",0) . "Wh - ".ReadingsVal($name,"relay_1", "off") }
attr shelly.Kueche timestamp-on-change-reading temperature,.*_power,relay_.
# FUUID 5dea1795-f33f-1e88-cccd-6ca92a79083a8457
# FVERSION 10_MQTT2_DEVICE.pm:0.268600/2022-12-16
# IODev mqttBroker
# LASTInputDev mqttBroker
# MSGCNT 3795
# NAME shelly.Kueche
# NR 142
# STATE 58.26 W / 671130Wh - on --- 0.00 W / 42412Wh - off
# TYPE MQTT2_DEVICE
# eventCount 62
# mqttBroker_MSGCNT 3795
# mqttBroker_TIME 2022-12-30 12:15:25
# READINGS:
# 2022-12-30 09:23:36 IODev mqttBroker
# 2022-12-26 13:37:04 fw_ver 20221027-092056/v1.12.1-ga9117d3
# 2022-12-26 13:37:04 id shellyKueche
# 2022-12-30 12:15:25 input_0 0
# 2022-12-30 12:15:25 input_1 0
# 2022-12-26 13:37:04 ip 10.0.0.181
# 2022-12-26 13:37:04 mac 98F4ABB8ADC9
# 2022-12-26 13:37:04 mode relay
# 2022-12-26 13:37:04 model SHSW-25
# 2022-12-26 13:37:04 new_fw false
# 2022-12-26 13:37:04 online true
# 2022-12-30 12:15:25 overtemperature 0
# 2022-12-30 12:12:47 relay_0 on
# 2022-12-30 12:15:25 relay_0_energy 671130
# 2022-12-30 12:13:19 relay_0_power 58.26
# 2022-12-30 12:13:25 relay_1 off
# 2022-12-30 12:15:25 relay_1_energy 42412
# 2022-12-30 12:13:25 relay_1_power 0.00
# 2022-12-29 20:20:53 state relay_1
# 2022-12-30 12:13:19 temperature 50.22
# 2022-12-30 12:15:25 voltage 244.04
# hmccu:
#
setstate shelly.Kueche 58.26 W / 671130Wh - on --- 0.00 W / 42412Wh - off
setstate shelly.Kueche 2022-12-30 09:23:36 IODev mqttBroker
setstate shelly.Kueche 2022-12-26 13:37:04 fw_ver 20221027-092056/v1.12.1-ga9117d3
setstate shelly.Kueche 2022-12-26 13:37:04 id shellyKueche
setstate shelly.Kueche 2022-12-30 12:15:25 input_0 0
setstate shelly.Kueche 2022-12-30 12:15:25 input_1 0
setstate shelly.Kueche 2022-12-26 13:37:04 ip 10.0.0.181
setstate shelly.Kueche 2022-12-26 13:37:04 mac 98F4ABB8ADC9
setstate shelly.Kueche 2022-12-26 13:37:04 mode relay
setstate shelly.Kueche 2022-12-26 13:37:04 model SHSW-25
setstate shelly.Kueche 2022-12-26 13:37:04 new_fw false
setstate shelly.Kueche 2022-12-26 13:37:04 online true
setstate shelly.Kueche 2022-12-30 12:15:25 overtemperature 0
setstate shelly.Kueche 2022-12-30 12:12:47 relay_0 on
setstate shelly.Kueche 2022-12-30 12:15:25 relay_0_energy 671130
setstate shelly.Kueche 2022-12-30 12:13:19 relay_0_power 58.26
setstate shelly.Kueche 2022-12-30 12:13:25 relay_1 off
setstate shelly.Kueche 2022-12-30 12:15:25 relay_1_energy 42412
setstate shelly.Kueche 2022-12-30 12:13:25 relay_1_power 0.00
setstate shelly.Kueche 2022-12-29 20:20:53 state relay_1
setstate shelly.Kueche 2022-12-30 12:13:19 temperature 50.22
setstate shelly.Kueche 2022-12-30 12:15:25 voltage 244.04
dann habe ich wieder das problem das der timestamp bei den readings gesetzt wird obwohl der wert sich nicht geändert hat, also beim input_0, input_1, online.
und nur für alle als info
es ist doch kein Bug sondern anscheinend ein Feature das die readings dann nicht mehr geschrieben werden wenn das timestamp-on-change-reading gesetzt wird.
dh für mich gibts dann auch keine Möglichkeit so ein shelly Device performance mässig gut und richtig abzubilden.
Irgend eine "Grot" muss man fressen, enteweder erzeugen die inputs dann Events die ich nicht brauche, oder ich kann nicht mehr nachvollziehen wann der letzte input gesetzt wurde.
Schade eigentlich aber naja
Hmm, mein Verständnis: Wenn du keine Events für bestimmte Readings haben willst, muss eocr passend gesetzt werden. Alle diese oder eben nur eine Teilmenge davon kann dann mit tocr "markiert" werden, dann wird _auch_ der Zeitstempel nicht aktualisiert.
Anders gesagt: tocr macht m.E. nur Sinn, wenn man es dazu nutzt, den Zeitstempel einzelner Readings "korrekt" zu halten. Oder man nutzt es dazu (ohne eocr überhaupt zu setzen), _nur noch die dort genannten Readings_ triggern zu lassen (dann aber ohne eocr immer, auch ohne Änderung!). Das ist aber ein "verstecktes feature"...
Zitatenteweder erzeugen die inputs dann Events die ich nicht brauche,
ein paar events mehr oder weniger schaden nicht, wenn alles, was auf events reagiert, ordentlich justiert ist, um nicht bei jedem Event im System erst mal "sich getriggert fühlt". s.o.
Zitatoder ich kann nicht mehr nachvollziehen wann der letzte input gesetzt wurde
wie machst Du das dann? def aufrufen und den Timestamp anschauen? was würde das bringen? zur Fehlersuche? Ansonsten: loggen lassen und im Log/DB nachsehen. Der Timestamp mag sich zwar ändern, wenn das Reading mehrfach mit dem gleichen Wert geschrieben wird, aber gelogged wird nur bei Änderung des Reading, dann mit diesem Zeitpunkt (Vorausgesetzt, event-on-change... ist gesetzt). Oder eben Timestamp-on-change- zusätzlich, dann kannst Du mit ReadingsAge auswerten.
Aber mal ne andere Frage: du bist ja dabei, die Performance zu erhöhen: hast Du mehrere (viele) shellys im Einsatz? per MQTT2 angebunden?
Gruß
Sany
ja wird schon stimmen, nur wenn ich nun schon vemrutlich jedes device anschauen und ändern muss, wollte ich es gleich mal richtig machen wie es für MICH logisch ist (und da brauche ich für input keine events aber eben timestamp wenn es perfekt sein sollte) - aber stimmt schon geht anders auch - man kann um dieses Feature herumarbeiten ;)
ja habe mehrere Shelly sicher um die 30 Stück sind per MQTT (ein externer mosquitto Server) angebunden
Zitatja habe mehrere Shelly sicher um die 30 Stück sind per MQTT (ein externer mosquitto Server) angebunden
Bei mir ist es etwa die gleiche Anzahl, allerdings per mqtt2server an fhem angebunden. Wenn ich Deine Konstellation richtig verstehe hast du Mosquitto extern als Broker und den nutzen Deine fhem-Devices als IO.
Was mir irgendwann mal aufgefallen ist:
die shellys machen alle 30sec ein "announce", also pusten ein umfangreiches JSON hinaus und der Broker muss ja irgendwas damit machen. Bei 30 Shellies sind das im Schnitt alle 2sec eine Menge Daten. Ich hatte bei mir das Problem, dass ich immer wieder, völlig losgelöst von Ereignissen und nicht regelmäßig, kleine "Hänger" im System hatte. Das konnt ich schön an meiner Digitaluhr (Device TYPE=Watches) sehen, die immer mal wieder ein wenig "gestolpert" ist, also die Sekunden nicht gleichmäßig gezeigt hat.
Dann kam der Versuch, im mqtt2Server alle möglichen Regexps zu ignorieren, hat aber nicht geholfen. Dann habe ich bei allen Shellies dieses announce abgestellt und seitdem sind diese Hänger nicht mehr und das System hat die meiste Zeit einstellige CPU-Last Werte (htop).
Das Setting läßt sich nur per http-Befehl ändern:
Zitathttp://<IP-vom-Shelly>/settings
ergibt in meinem Browser eine entschlüsselte JSON Ansicht, dort kannst Du grob im oberen Drittel unter mqtt den Wert update_period sehen. Sollte 30 stehen, also default.
Ändern geht über:
Zitathttp://<IP-vom-Shelly>/settings?mqtt_update_period=0
Die Seite wird dann gleich wieder angezeigt, mit dem geänderten Wert.
ABER: Das hat bei mir geholfen, evtl. hat das per Mosquitto keine Auswirkungen. Ausserdem solltest Du Dir sicher sein, diese announces in fhem nicht zu verwerten, sonst fehlen Dir Trigger. Aber vermutlich löst es Dein Problem z.B. beim Input, dass eben nur eine Änderung ins Reading geschrieben wird und nicht jedes Update per announce nur den Timestamp ändert.
Ich sags nochmal: probier das auf eigene Gefahr, man kann es aber auch jederzeit zurückdrehen, ist halt ne Fleißarbeit....
Viel Erfolg!
Sany
Ok danke das kannte ich noch gar nicht :D
Werd mir da dann ein patch script schreiben dafür.
Ausschalten geht glaub ich nicht, weil was ich im ersten Test gesehen habe, kommen dann gar keine zyklischen Messages mehr an.
Und die .*power und .*energy würde ich schon haben wollen zyklisch wenn das relay eingeschaltet ist (aber da reicht dann ein 5 sekunden intervall oder so)
ZitatUnd die .*power und .*energy würde ich schon haben wollen
die kommen ja, sobald sich was ändert. Im Prinzip ist das ja ein event-on-change-reading: shelly sendet nur bei geänderten Werten.
Zitat von: Sany am 30 Dezember 2022, 17:18:54
die kommen ja, sobald sich was ändert. Im Prinzip ist das ja ein event-on-change-reading: shelly sendet nur bei geänderten Werten.
Ja stimmt funkt so eigentlich ganz gut.
Man muss halt wenn man die settings ändert also den update_period auf 0 oder <> 0 immer einen reboot vom device machen, sonst tut das ding gar nichts mehr - hatte 15 minuten gewartet und es kam nix.
Nach dem Reboot läuft es jetzt perfekt!
Hmm eines passt mir dann doch nicht bei den shelly und update_period=0
wenn ich das relay einschalte, dann bekomme ich brav den relay status =1, die Power wird auf 227Watt gesetzt und Energy wird auch aktualisiert.
Aber wenn ich dann ausschalte, dann wird zwar der relay status auf 0 gestellt sofort, aber die Power bleibt auf 227 Watt stehen und wird auch zig minuten später nicht aktualisiert
theoretisch könnte man ein notify machen
define shellyPower0 notify shelly\..*:relay_0:off { fhem "setreading $NAME power_0 0";; }
damit würden bei all meinen shellys (fangen mit shelly. an) die power_0 auf 0 gesetzt wenn das relay ausgeschaltet wird.
ist zwar dann ein notify mehr das halt öfters aufgerufen wird, aber dafür müssten die shellys nicht mehr ständig schicken?
Frohes Neues!
ZitatAber wenn ich dann ausschalte, dann wird zwar der relay status auf 0 gestellt sofort, aber die Power bleibt auf 227 Watt stehen und wird auch zig minuten später nicht aktualisiert
Das machen meine Shellys auch, allerdings nutze ich das Reading nicht, somit ist es mir bisher nicht aufgefallen.
Unschön ist es, ich würde fast tippen, das ist ein Bug in der Shelly-Firmware. Habe das aber nicht weiter verfolgt, da ich es, wie gesagt, nicht nutze.
Generell schrieb ich ja, es kann sein, dass nach abschalten des Announce evtl. Trigger fehlen.
Hast Du denn eine geringere CPU-load feststellen können, solltest Du alle shellys umgestellt haben?
Gruß
Sany
Zitat von: Sany am 01 Januar 2023, 18:08:28
Frohes Neues!Das machen meine Shellys auch, allerdings nutze ich das Reading nicht, somit ist es mir bisher nicht aufgefallen.
Unschön ist es, ich würde fast tippen, das ist ein Bug in der Shelly-Firmware. Habe das aber nicht weiter verfolgt, da ich es, wie gesagt, nicht nutze.
Generell schrieb ich ja, es kann sein, dass nach abschalten des Announce evtl. Trigger fehlen.
Hast Du denn eine geringere CPU-load feststellen können, solltest Du alle shellys umgestellt haben?
Gruß
Sany
4
Ja habe schon eine geringere Last nun (habe es mit dem trigger nun gemacht die power auf 0 zu stellen wenn das relay ausgeht.
Ja ich vermute auch das es ein Bug in der shelly ist, aber wenn shelly eine ähnliche Bug Analyse haben wie die hier bei FHEM dann werden auch die den Bug als Feature verkaufen wie die hier bei FHEM ;) - sage ja immer der Verkauf ist wichtiger als die Technik ;D