Events abschalten für Device:reading

[alanblack]

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:

Code Auswählen Erweitern

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


Code Auswählen Erweitern

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

[sn0000py]

hast du auch ein timestamp-on-change-reading in verwendung?

[alanblack]

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

[sn0000py]

hmmm das ist komisch.
ich habe nun folgendes

Code Auswählen Erweitern

[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)

[Sany]

Hallo sn0000py,

ich lese diesen Thread nun schon eine ganze Weile mit, aber irgendwie wird mir nicht klar, was das Problem ist.

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?

Daraus lese ich, Du möchtest unnötige Events verhindern, richtig? Ich vermute die Verwirrung in diesem Statement:

Bei 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:

The 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

[sn0000py]

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

[Beta-User]

das funtkioniert leider nicht

...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.

[sn0000py]

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

Code Auswählen Erweitern

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.

[Beta-User]

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...

[sn0000py]

wenn ich die gleich mache (bis auf den Wert halt den den mag vermutlich der tocr nicht )

Code Auswählen Erweitern

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.

[sn0000py]

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.

[sn0000py]

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

[Beta-User]

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"...

[Sany]

enteweder 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.

oder 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

[sn0000py]

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