Noch ein Un-Verständnis: Im Bild unten ist eine Meßwertkurve (blau) gezeigt. Zu erkennen ist, das die Werte um 1/10 (oder weniger) Grad schwankend geloggt werden, also auch entsprechend viele Dateieinträge produziert werden. In dazugehörendem Parameterfeld ist jedoch bei "event-on-change-reading" eine Schwelle von 2 eingetragen. Warum wirkt/funktioniert die nicht?
Thomas
Zitat
"event-on-change-reading" eine Schwelle von 2 eingetragen. Warum wirkt/funktioniert die nicht?
event-on-change-reading hat als Parameter jene readings (oder auch einen regex wie .*) für die es gelten soll.
Matched ein reading, welches in event-on-change-reading eingetragen ist wenn das device einen Wert liest, so wird geprüft, ob der neue Wert ungleich dem alten Wert ist. Wenn ja, wird ein Ereignis erzeugt, ist der neue Wert gleich dem alten Wert, wird kein Ereignis generiert.
Lies in der Commandref noch mal den Abschnitt zu den FN-Attributen durch, dann wirst Dui finden, was Du benötigst.
Gruß Elektrolurch
Zitat von: Elektrolurch am 04 August 2015, 16:31:12
Matched ein reading, welches in event-on-change-reading eingetragen ist wenn das device einen Wert liest, so wird geprüft, ob der neue Wert ungleich dem alten Wert ist. Wenn ja, wird ein Ereignis erzeugt, ist der neue Wert gleich dem alten Wert, wird kein Ereignis generiert.
Commandref HABE ich mehrfach gelesen, aber nicht verstanden. Aber dein Satz oben ist noch unverständlicher.
Thomas
Dann ein zweiter Versuch:
event-on-change-reading => mache etwas, wenn sich ein reading (gelesener Wert) ändert
Benötigt wird, auf welches reading geprüft werden soll.
Beispiel bei einem FS20 Aktor (Funksteckdose)
Dort gibt es das reading "state" und die Definition lautet:
attr <device> event-on-change-reading state
Bei jeder Änderung von "state" wird nun geprüft, ob der neue Werte ungleich dem Alten ist. Ist das der Fall, dann wird ein Event ausgelöst, dass z.B. über ein notify abgefragt werden kann.
Es gibt nun devices, wie die KS300, die mehrere readings haben. Hier kann ich nun über eine "regular Expression" auch mehrere readings adressieren.
attr KS300 event-on-change-reading rain.*
Damit würden die readings: rain, rain_raw und rain_raw_adj geprüft werden.
Grüße Jörg
dein event-min-interval ist falsch, da fehlt das reading in der angabe
ich würde es einmal löschen und jedes attr einzeln setzten und probieren wie sich die attr verhalten für deine Anwendung
Zitat von: fhem-hm-knecht am 04 August 2015, 17:02:04
dein event-min-interval ist falsch, da fehlt das reading in der angabe
ich würde es einmal löschen und jedes attr einzeln setzten und probieren wie sich die attr verhalten für deine Anwendung
Laut commandref ist ein Wert anzugeben, der die Anzahl von Sekunden nennt bis was passiert. Was ist also an "300" falsch?
Commandref:
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 minInterval Sekunden vergangen sind.Hm, das mit den "Paare"n hatte ich überlesen. Der letzte Satz aber ist entweder unvollständig oder falsch, denn dort wird nur EIN Wert beschrieben. Was soll im zweitem Wert (des Paares) drin stehen? Ein Null? Ein weiteres 300? Eine unendlich grosse Zahl? Woher soll ich erkennen, was der zweite Wert sein soll?
Thomas
entweder so für alle Readings
event-min-interval .*:300
odere einzelne
event-min-interval temperature:300,temperature2:900 usw
Zitat von: JoWiemann am 04 August 2015, 17:00:35
Dann ein zweiter Versuch:
event-on-change-reading => mache etwas, wenn sich ein reading (gelesener Wert) ändert
Benötigt wird, auf welches reading geprüft werden soll.
Soweit gut...
Zitat von: JoWiemann am 04 August 2015, 17:00:35
Beispiel bei einem FS20 Aktor (Funksteckdose)
Dort gibt es das reading "state" und die Definition lautet:
attr <device> event-on-change-reading state
Bei jeder Änderung von "state" wird nun geprüft, ob der neue Werte ungleich dem Alten ist. Ist das der Fall, dann wird ein Event ausgelöst, dass z.B. über ein notify abgefragt werden kann.
Es gibt nun devices, wie die KS300, die mehrere readings haben. Hier kann ich nun über eine "regular Expression" auch mehrere readings adressieren.
attr KS300 event-on-change-reading rain.*
Damit würden die readings: rain, rain_raw und rain_raw_adj geprüft werden.
Grüße Jörg
Sorry, wenn ich mich jetzt blöd anhöre, aber du schreibst genauso ein ungenaues Blubber wie die Commandref - Wenig Text mit noch weniger Infos.
Dein Beispiel mit FS20 nützt mir nichts, denn den Inhalt des ersten Satzes wußte ich schon. Nur was nützt mir das bei meiner Frage?
Dein Beispiel mit KS300 ist überflüssig, denn das hilft mir nicht um zu verstehen, warum meine Parameter nicht funktionieren.
Also kann ich das nicht nachvollziehen. Wenn du an meinem konkretem Problem gezeigt hättest, WAS ich WO einzustellen habe, damit nur ein Logeintrag in die Datei geschrieben wird wenn sich der Messwert um 2 oder mehr Grad ändert, dann wäre mir geholfen und vielleicht würde ich dann das System auch verstehen.
Thomas
Zitat von: fhem-hm-knecht am 04 August 2015, 17:19:13
entweder so für alle Readings
event-min-interval .*:300
odere einzelne
event-min-interval temperature:300,temperature2:900 usw
NÖ!Laut commandref ist "event-min-interval" ein Befehl für eine Zeitangabe. Da hat "temperature" also gar nichts drin zu suchen. Ausserdem soll nur was passieren, wenn die Temperatur um 2 Grad abweicht, nicht um 300 Grad. Dafür soll spätestens alle 300 SEKUNDEN ein Wert geschrieben werden.
ODER IST DIE COMMANDREF FALSCH???
Thomas
ZitatKommata getrennte Liste von "readings:minInterval" Paare
Was heißt denn hier NO!
ist temperature denn kein readings ? bei dir?
event-min-interval temperature:300
ZitatNÖ!
doch...
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.
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.
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.
Zitat von: fhem-hm-knecht am 04 August 2015, 17:40:07
Was heißt denn hier NO!
ist temperature denn kein readings ? bei dir?
event-min-interval temperature:300
Das Ereignis soll bei
*2* Grad passieren, nicht bei 300 Grad. Entweder "Nö" oder die Commanref ist falsch (im Sinne von unvollständig).
Thomas
oder du liest nicht was über deinem beitrag steht...
event-min-interval ist eine andere Funktion wie event-on-change-reading
du vermischt das gerade,
und welche Funktion wann sticht , bin ich mir gerade nicht sicher ob das dir klar ist
Zitat von: Thomas_SH am 04 August 2015, 17:47:10
Das Ereignis soll bei *2* Grad passieren, nicht bei 300 Grad. Entweder "Nö" oder die Commanref ist falsch (im Sinne von unvollständig).
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
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?
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
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
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.
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.
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
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.
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
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.
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.
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
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
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
Was ist den cmd_7? Wo soll das denn her kommen. Kannst Du bitte mal genau sagen was Du machst und erreichen willst?
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.
Die Frage gehört in das DOIF-Board - hier wird sie untergehen.
Zitat von: Thoffi1978 am 01 Dezember 2016, 07:41:52
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.
am Ende ein
DOELSE ()
([OD_Rst:plan_departure_delay_1] ne "+0")((set Torsten_WA send [OD_Rst:plan_departure_1], [OD_Rst:plan_departure_delay_1])) DOELSE ()
und das do always dann weg
Das habe ich, die Änderung beim Reading löst aber trotzdem kein neues Senden aus.
Das Doif "springt" nicht auf das DOELSE zurück.
Ich habe das DOIF mal gekürtzt. Anbei die List:
Internals:
CHANGED
DEF ([Rst_OD:plan_departure_delay_1] ne "+9")((set Torsten_WA send [Rst_OD:plan_departure_1], [Rst_OD:plan_departure_delay_1] Abfahrt,[Rst_OD:plan_arrival_delay_1] Ankunft,[Rst_OD:travel_note_link_1]))
DOELSEIF
([OD_Rst:plan_departure_delay_1] ne "+9")((set Torsten_WA send [OD_Rst:plan_departure_1], [OD_Rst:plan_departure_delay_1]))
DOELSE
(set Torsten_WA send Bahn faehrt wieder puenktlich)
NAME DBPlan_Whatsapp
NR 256
NTFY_ORDER 50-DBPlan_Whatsapp
STATE cmd_1
TYPE DOIF
Readings:
2016-12-01 21:25:01 Device Rst_OD
2016-12-01 20:17:46 cmd 1
2016-12-01 20:17:46 cmd_event Rst_OD
2016-12-01 20:17:46 cmd_nr 1
2016-12-01 21:25:01 e_Rst_OD_plan_departure_delay_1 Hinweise
2016-12-01 20:17:46 state cmd_1
2016-12-01 21:26:01 wait_timer no timer
Condition:
0 ReadingValDoIf($hash,'Rst_OD','plan_departure_delay_1','','',AttrVal($hash->{NAME},'notexist',undef)) ne "+9"
1 ReadingValDoIf($hash,'OD_Rst','plan_departure_delay_1','','',AttrVal($hash->{NAME},'notexist',undef)) ne "+9"
Devices:
0 Rst_OD
1 OD_Rst
all Rst_OD OD_Rst
Do:
0:
0 (set Torsten_WA send [Rst_OD:plan_departure_1], [Rst_OD:plan_departure_delay_1] Abfahrt,[Rst_OD:plan_arrival_delay_1] Ankunft,[Rst_OD:travel_note_link_1])
1:
0 (set Torsten_WA send [OD_Rst:plan_departure_1], [OD_Rst:plan_departure_delay_1])
2:
0 set Torsten_WA send Bahn faehrt wieder puenktlich
Helper:
event travel_note_text_1: Aktuelle Informationen liegen vor,travel_departure_1: Gl. 1
,travel_destination_1: Gl. 3
globalinit 1
last_timer 0
sleepdevice Rst_OD
sleepsubtimer -1
sleeptimer -1
timerdev Rst_OD
timerevent travel_note_text_1: Aktuelle Informationen liegen vor,travel_departure_1: Gl. 1
,travel_destination_1: Gl. 3
triggerDev Rst_OD
timerevents:
travel_note_text_1: Aktuelle Informationen liegen vor
travel_departure_1: Gl. 1
travel_destination_1: Gl. 3
timereventsState:
travel_note_text_1: Aktuelle Informationen liegen vor
travel_departure_1: Gl. 1
travel_destination_1: Gl. 3
triggerEvents:
travel_note_text_1: Aktuelle Informationen liegen vor
travel_departure_1: Gl. 1
travel_destination_1: Gl. 3
triggerEventsState:
travel_note_text_1: Aktuelle Informationen liegen vor
travel_departure_1: Gl. 1
travel_destination_1: Gl. 3
Internals:
Itimer:
Readings:
0 Rst_OD:plan_departure_delay_1
1 OD_Rst:plan_departure_delay_1
all Rst_OD:plan_departure_delay_1 OD_Rst:plan_departure_delay_1
Regexp:
0:
All:
State:
Trigger:
Attributes:
event-min-interval .*:2
event-on-change-reading e_.*
room yowsup,ÖPNV
wait 20:20