Hauptmenü

Event erzeugen

Begonnen von stera, 06 September 2017, 03:51:36

Vorheriges Thema - Nächstes Thema

stera

Hallo,

ist es irgendwie möglich ein Event alle 30min zu erzeugen.. Die ganzen attr. event-on-update, interval, change usw... machen ja immer das Gegenteil... Ich würde gerne, auch wenn keine Änderung kommt, alle 30min den Wert in die Datenbank schreiben.
Momentan behelfe ich mich schon mit einen DoIf, der den gleiche Status nochmal wieder reinschreibt aber vll. gibt es auch eine einfachere elegantere Lösung.

Gruß,
SteRa

CoolTux

Schau Dir mal event-min-interval an.
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

gloob

#2
Ich nutze immer:

event-on-change-reading
event-on-min-interval


Damit wird nur bei einer Änderung geloggt und zusätzlich alle x Minuten. 

Funktioniert allerdings auch nur wenn regelmäßig Events kommen.

Edit: warten wir mal ab was der Thread Ersteller sagt, was er wirklich genau machen möchte.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Thyraz

@CoolTux / gloob

Mein Verständnis von event-min-interval war immer, dass es eben erst beim nächsten Update nach der Zeitspanne ein Event gibt.
Er will das Event ja aber in einem festen Zeitraster unabhängig davon ob das Gerät zu diesem Zeitpunkt etwas liefert.

Mir würde da nur ein at (oder eben DOIF) einfallen.
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Wzut

Zitat von: stera am 06 September 2017, 03:51:36
Ich würde gerne, auch wenn keine Änderung kommt, alle 30min den Wert in die Datenbank schreiben.
https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Grinsekatze

Wie Cool-Tux schon schrieb: Das Attribut event-min-interval ist die richtige Wahl - aber eben sicherstellen, dass auch Events generiert werden. Sonst musst Du mit einem Notify regelmäßig das Device aktivieren und den gewünschten Event erzeugen.

In der Regel wird on-Change in Kombination mit min-Interval benutzt um sicherzustellen, dass z.B. der Plot nicht abreißt (aber eben trotzdem das Log nicht vollgespamt wird).

stera

Zitat von: Grinsekatze am 06 September 2017, 11:11:29
Wie Cool-Tux schon schrieb: Das Attribut event-min-interval ist die richtige Wahl - aber eben sicherstellen, dass auch Events generiert werden. Sonst musst Du mit einem Notify regelmäßig das Device aktivieren und den gewünschten Event erzeugen.

In der Regel wird on-Change in Kombination mit min-Interval benutzt um sicherzustellen, dass z.B. der Plot nicht abreißt (aber eben trotzdem das Log nicht vollgespamt wird).

Vielen Dank für eure ganze Antworten.. Dann ist meine Variante mit dem DoIf wohl schon eine gute Alternative.. Teilweise gibt es ja Sensoren die nur melden, wenn eine Aktion ausgeführt wird.. Hier will ich den Plotabriss auch gerne vermeiden.. Schade das es nicht so eine Art Zwangsevent gibt.. Aber was es nicht gibt, kann es ja vll. irgendwann nochmal als attr. geben..

Danke,
SteRa

DS_Starter

#7
Zusätzlich zu dem bereits geschriebenen noch der Hinweis dass es inzwischen eine in DbLog integrierte addlog-Funktion gibt.

Zitat
set <name> addLog <devspec>:<Reading> [Value]

    Fügt einen zusatzlichen Logeintrag einer Device/Reading-Kombination in die Datenbank ein. Optional kann "Value" für den Readingwert angegeben werden. Ist Value nicht angegeben, wird der aktuelle Wert des Readings in die DB eingefügt. Das Feld "$EVENT" wird automatisch mit "addLog" belegt. Das Device kann als Geräte-Spezifikation angegeben werden. "Reading" wird als regulärer Ausdruck ausgewertet. Es wird KEIN zusätzlicher Event im System erzeugt !

    Beispiele:
    set <name> addLog SMA_Energymeter:Bezug_Wirkleistung
    set <name> addLog TYPE=SSCam:state
    set <name> addLog MyWetter:(fc10.*|fc8.*)
    set <name> addLog MyWetter:(wind|wind_ch.*) 20
    set <name> addLog TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=subType!=(virtual|):(measured-temp|desired-temp|actuator)

Es können devspecs angegeben werden was mitunter hilfreich sein kann um die Werte ganzer Devicetypen mit addlog wegschreiben zu können.
Man braucht keine Programmteile in 99_myUtils schreiben. Es wird auch kein zusätzlicher Event im System erzeugt. Dadurch wird das System nicht zusätzlich belastet.
Das Ganze kann mit einem einfachen AT alle 30 Minuten angestartet werden.

Grüße
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stera

Zitat von: DS_Starter am 07 September 2017, 00:09:24
Zusätzlich zu dem bereits geschriebenen noch der Hinweis dass es inzwischen eine in DbLog integrierte addlog-Funktion gibt.

Es können devspecs angegeben werden was mitunter hilfreich sein kann um die Werte ganzer Devicetypen mit addlog wegschreiben zu können.
Man braucht keine Programmteile in 99_myUtils schreiben. Es wird auch kein zusätzlicher Event im System erzeugt. Dadurch wird das System nicht zusätzlich belastet.
Das Ganze kann mit einem einfachen AT alle 30 Minuten angestartet werden.

Grüße
Heiko

Hallo Heiko,

das ist doch eine viel bessere Alternative. Habe alles umgestellt und geht wunderbar  :D :D :D

Vielen Dank.

Gruß,
SteRa