Verständnisfrage zu event-on-change-reading

Begonnen von Thomas_SH, 04 August 2015, 16:21:24

Vorheriges Thema - Nächstes Thema

Thomas_SH

#15
Zitat von: justme1968 am 04 August 2015, 17:45:49
doch...

(1) für event-min-interval gibst du jeweils paare aus reading und zeit an die angeben wann dieses reading frühestens ein event erzeugen soll.

(2) für deinen fall brauchst du aber event-on-change-reading um anzugeben das das event nur erzeugt werden soll wenn der wert sich geändert hat bzw. wenn er sich um mindestens einen bestimmten betrag geändert hat.

(3) wenn du zusätzlich zu event-on-change-reading auch noch event-min-interval passend setzt wird nach dem angegebenen intervall auch dann genau ein mal ein event erzeugt wenn due schwelle nicht erreicht wurde.

(1) Endlich mal Fakten! Das das Paar aus 2 verschiedenen Sachen bestehen soll steht ja nirgends!!!

(2) Das habe ich ja schon gestern erkannt, aber nicht hinbekommen weil Infos fehlen.

(3) "Passend"... Warum sagt mir denn hier niemand, WAS GENAU ich WO eintragen muß? Warum wird hier immer nur um den Brei herumgeredet?  Oder nur Teilinformationen gegeben?

Vermutung: event-min-interval   temperature:300 Liest den Sensor nach 300 Sekunden aus, wenn nicht vorher eine andere Bedingung für ein auslesen gesorgt hat.

event-on-change-reading 2 Änderung wird geschrieben wenn sich der Wert um 2 (oder mehr) ändert.

Ist das denn jetzt so richtig?

Thomas

P.S.: Bei einigen Texten zu diesem Thema steht noch

event-on-update-reading .*

als Angabe. Brauche ich das / wozu ist das notwendig?

Thomas_SH

Zitat von: JoWiemann am 04 August 2015, 18:00:53
event-min-interval gibt die Zeit an, die zu vergehen hat, bis ein neues event akzeptiert wird.

event-min-interval   temperature:300 bedeutet: Bei Änderungen des readings wird erst ein event erzeugt, wenn 300 Sekunden vergangen sind und nicht wenn 300 sich die Temperatur um 300 Grad genändert hat.

Grüße Jörg

Okay, das ist einigermassen verständlich. Warum kann das nicht so in der Commanref stehen?

Thomas

JoWiemann

Steht doch da:

event-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens min Interval Sekunden vergangen sind.

Dein Modul hat über das attr pollingInterval einen Abfragerythmus von 15 Sekunden. Damit werden die Werte alle 15 Sekunden aufgefrischt. event-min-interval sorgt nun dafür, dass die Werte für das reading temperature nur alle 300 Sekunden aufgefrischt und damit ins Log geschrieben werden. Das sollte so dann auch im Log sichtbar sein.

Das event-on-change-reading sollte nun als weitere Bedingung haben, dass nur dann ein event erzeugt wird, wenn das angegebene reading, also temperature um mindestens den Wert 2 abweicht.

attr <device> event-min-interval temperature:300
attr <device> event-on-change-reading temperature:2

Was die command.ref nicht beantwortet ist die Frage: Wer sticht wen, wird also immer das 300 Sekunden Intervall berücksichtig, oder nur die Wertedifferenz oder irgendwie beide.

Ich würde erst einmal beide Attribute alleine ausprobieren und die Ergebnisse im Log beobachten.

Grüße Jörg

Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

justme1968

beide sind oder verknüpft.

das event wird erzeugt wenn mindestens 300 sekunden seit dem letzen event vergangen sind oder sich der wert seit dem letzen event mindestens um den betrag von 2 verändert hat.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

frank

ZitatVermutung: event-min-interval   temperature:300 Liest den Sensor nach 300 Sekunden aus, wenn nicht vorher eine andere Bedingung für ein auslesen gesorgt hat.
ausserdem haben die attribute nichts mit auslesen/empfangen zu tun. hier geht es nur darum, ob zu den sowieso schon ausgelesenen/empfangenen daten zusätzlich noch events generiert werden sollen oder eben auch nicht. wie die namen der attribute (event-...) schon sagen. ohne die attribute erzeugt jedes auslesen/empfangen neuer daten events.
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

Thomas_SH

Zitat von: frank am 04 August 2015, 19:53:10
ausserdem haben die attribute nichts mit auslesen/empfangen zu tun. hier geht es nur darum, ob zu den sowieso schon ausgelesenen/empfangenen daten zusätzlich noch events generiert werden sollen oder eben auch nicht. wie die namen der attribute (event-...) schon sagen. ohne die attribute erzeugt jedes auslesen/empfangen neuer daten events.

Also, da es keine _vernünftige_ Anleitung gibt, die strukturiert aufgebaut ist, mit nachvollziehbaren Beispielen (und nicht ein 1/4 Beispiel Sensor x und 1/2 Beispiel mit Aktor y und  1/4 fehlendes Infos) war mir einiges nicht klar. Dieses E-Buch für Anfänger ist eben KEINE Anleitung, sondern nur ein Buch mit nicht zusammenpassenden Beispielen zur Anwendung.

Auch die Commandref ist leider vom gleichem Schlage: Mitten im Text auf einmal etliche Abschnitte in englisch, Beispiele die nicht nachvollziehbar sind, Kommandosequenzen die nicht erklärt werden sondern einfach in den Raum geworfen werden und zu viele englische Begriffe im Text.

Schaut euch mal das hier an: http://www.erfa.ethz.ch/files/Studium/Tipps/LaTeX_Anleitung.pdf oder http://www.kubieziel.de/computer/latex-tutorial.html

Da gibt es eine Strukturübersicht, eine Übersicht über Kommandos, eine Liste mit möglichen Parametern, Beispiele. Das nenne ich eine Anleitung...


Thomas

Puschel74

#21
Und wer hindert dich daran aktiv zu werden anstatt nur zu "jammern".
Niemand zwingt dich dazu FHEM zu verwenden.
Bring dich ein und erstell eine Anleitung nach "deinem Geschmack" und stell sie zur Verfügung - und achte auch darauf das sie dann aktuell bleibt.
Knuffig was mancher so an Ansprüche stellt aber selbst mithelfen ... na wir werden sehen, oder auch nicht.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Thomas_SH

Zitat von: Puschel74 am 04 August 2015, 20:41:43
Und wer hindert dich daran aktiv zu werden anstatt nur zu "jammern".
Niemand zwingt dich dazu FHEM zu verwenden.
Bring dich ein und erstell eine Anleitung nach "deinem Geschmack" und stell sie zur Verfügung - und achte auch darauf das sie dann aktuell bleibt.
Knuffig was mancher so an Ansprüche stellt aber selbst mithelfen ... na wir werden sehen, oder auch nicht.

Im Moment hindert mich der fehlende Überblick. Leider muß ich mir die Infos aus zu vielen Orten zusammensuchen. Immerhin habe ich die Diagramme jetzt auf einem Stand, der zufriedenstellend ist (Auflösung von Zeit und Werten). Das nächste Thema ist die "Einspeisung" von analogen Werten und die Ansteuerung von Relais. Dazu liegen schon Linksammlungen vor. Wenn die Punkte erledigt sind werde ich meine Erfahrungen als Anleitung zusammenschreiben - und im Gegensatz zu den bisherigen Infos wird meine Anleitung "kabelbasiert" sein (im Gegensatz zu den ganzen Funk-Krams).

Thomas

JoWiemann

off Topic.

Was ist eine "kabelbasiert" Anleitung?

Und die Arbeit von Menschen, die Fhem in ihrer Freizeit entwickeln und dokumentieren als "Funk-Krams" zu bezeichnet ist schon mehr als eine Frechheit.

Viel Spaß beim ALLEINE weiter machen.
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Puschel74

Jaja, die grossen Unterschiede zwischen Kabelgeräten und "Funk-Kram"  ::)
Achtung! FHEM ist das egal ob kabelbasiert oder Funk.
Einzig der physikalische Teil ist anders aber in FHEM sehen alle Geräte (mehr oder weniger) gleich aus und sind auch so zu händeln.
Aber das wirst du sicher noch verstehen lernen.
Ist aber schön zu sehen wie sich manche Anfänger ganz ohne Hilfe immer weiter selbst ins Aus schieben.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Thomas_SH

Zitat von: JoWiemann am 04 August 2015, 21:24:20
off Topic.

Was ist eine "kabelbasiert" Anleitung?

Und die Arbeit von Menschen, die Fhem in ihrer Freizeit entwickeln und dokumentieren als "Funk-Krams" zu bezeichnet ist schon mehr als eine Frechheit.

Viel Spaß beim ALLEINE weiter machen.

Kabelbasiert ist eben das sich die Anleitung auf kabelgebundene Geräte bezieht. Das ist in der derzeitigen Anleitung eben kaum gegeben. Und wer sich bei "Funk-Krams" beleidigt sieht hat selbst ein Problem.

Thomas

Elektrolurch

Zitat:
off Topic.

Was ist eine "kabelbasiert" Anleitung?

Und die Arbeit von Menschen, die Fhem in ihrer Freizeit entwickeln und dokumentieren als "Funk-Krams" zu bezeichnet ist schon mehr als eine Frechheit.

Viel Spaß beim ALLEINE weiter machen.
Moderator informieren    Gespeichert
Jörg Wiemann

@Jörg: Ich habe Deine Geduld bewundert, Du hast ja wirklich mehrfach versucht das bis ins Detail zu erklären. Ich hatte schon beim Beitrag 2 die Nase voll auf Grund der patzigen Antwort.
von @Thomas...und dann hat sich ja auch noch herausgestellt, dass er nicht lesen kann und andere dafür auch noch beschuldigt (->Zeitintervall steht ja ganz klar in der CommandRef).
"kabelbasiert" Anleitung"
könnte zum fhem-Unwort des Jahres werden. Einfach Klasse!!!!
:-)()

Elektrolurch
configDB und Windows befreite Zone!

Thoffi1978

Hallo,
ich habe nun eine ganze Zeit gegoogelt und gelesen. Ich bekomme das einfach nicht hin  >:(

Ich möchte gerne, dass wenn sich der Wert e_Rst_OD_plan_departure_delay_1 ändert,
cmd_7 erneut ausgeführt wird.

Ich habe das nun verschieden ausprobiert. Nun hatte ich gehofft mit:
event-on-change-reading e_.*
event-min-interval .*:2

hinzubekommen. Es klappt jedoch nicht.

Wie schaffe ich es cmd_7 bei Änderung von e_.* erneut ausgeführt wird?


Vielen Dank
Hoffi

CoolTux

Was ist den cmd_7? Wo soll das denn her kommen. Kannst Du bitte mal genau sagen was Du machst und erreichen willst?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Thoffi1978

Entschuldige. Da war ich mit den Gedanken schon weiter.
Der Code ist folgender.
([OD_Rst:plan_departure_delay_1] ne "+0")((set Torsten_WA send [OD_Rst:plan_departure_1], [OD_Rst:plan_departure_delay_1]))

Sobald das cmd einmal sendet, sendet es nicht erneut.
Mit Do always sendet es bei jeder Aktualisierung.