event-on-change-reading wird bei bei Neuanlegen von Readings ignoriert

Begonnen von peterk_de, 26 August 2014, 16:46:39

Vorheriges Thema - Nächstes Thema

peterk_de

Hallo zusammen,

ich habe da ein Problem, von dem ich zunächst dachte, es beträfe nur einige bestimmte Module (wo ich es auch schon gelegentlich moniert habe), aber es scheint von genereller Natur zu sein:

Ich finde es sehr praktisch, über event-on-change-reading nur jene Events überhaupt erst entstehen zu lassen, die mich interessieren. Ich würde, wenn gesetzt, entsprechend erwarten, dass keine anderen Events auftreten - setze ich also


attr a event-on-change-reading r1


... dann sollt bei Änderungen an r2 kein Event entstehen, richtig? Und das tut es im Normalfall auch nicht. Aber - und jetzt kommt mein Problem - es gibt eine Ausnahme: Wenn durch ein Modul ein Reading neu "angelegt" wird, vorher also im Device noch nicht existiert, dann fliegt das Event r2 trotzdem. Nun meine Frage: Ist das so gewollt / günstig / anderen außer mir egal?

Mir ist es bislang z.B. bei Modulen auf die Füße gefallen, die Readings bei Updates zunächst wohl komplett löschen und dann neu anlegen (gibt es ein paar von, die ich daher nun nicht mehr verwende) oder - noch heimtückischer - bei solchen, wo Readings erst nach und nach angelegt werden, wenn ein Ereignis zum ersten mal Auftritt. Da führen dann solche neuen Readings, die ich zum Zeitpunkt des Erstellens möglicherweise gar nicht kannte und auch dachte, sie eh per event-on-change-reading ausgefiltert zu haben zu recht schwer zu debuggendem Verhalten von komplexeren Notifys.

Das Problem scheint da ReadingsSingleUpdate() bzw -begin/Endupdate zu sein. Leider reichen meine rudimentären Perl-Kenntnisse nicht wirklich, den entsprechenden Code zu debuggen um dieses meiner Ansicht nach inkonsistente Verhalten zu beheben. Daher einmal dieser Thread - vielleicht sagt aber auch jemand "muss so", dann würde ich mich damit wohl auch zufrieden geben müssen ;-)
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

justme1968

es wird dann kein event erzeugt wenn sich am reading nichts ändert.

der übergang von nicht vorhanden zu vorhanden ist aber sehr wohl eine änderung.

also ist es konsequent das auch bei gesetztem attribut ein event kommt.

ich denke eher deine notifys sind nicht genau genug auf genau die events spezifiziert die dich interessieren.

im übrigen würde das verhalten das du dir wünschst vermutlich noch sehr viel mehr probleme machen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

peterk_de

Ja, dass es ein Event für das Reading r1 in meinem Beispiel geben sollte, wenn es neu angelegt wird, sehe ich auch so - ist ja ne Änderung.

Aber muss es ein solches für r2 geben, wenn es neu angelegt wird - während ich  keins bekomme, wenn r2 zwar nicht neu angelegt wird, sich aber ändert? Woher soll ich als Dumm nutzer wissen, wann es in einem Modul mal neu kommt und wann es sich "bloß" ändert? Das is eher mein Problem ... gefühlt irgendwie inkonsistent... Aber scheint echt nur mir so zu gehen ;-)
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

frank

wenn du dein notify nur auf das reading r1 triggerst, sollten doch keine probleme auftauchen. oder habe ich etwas missverstanden?
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

peterk_de

Frank, das stimmt und mache ich auch so. Ich wollte nur auf diesen Umstand hinweisen. Wenn es nur mich stört kann ich mit Leben, aber dann ist es mal dokumentiert und erspart vielleicht dem ein oder anderem Probleme ;-)
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...