Rolladen-Funk-Aktor mit Gedächtnis?

Begonnen von MarkoP, 04 September 2020, 07:13:32

Vorheriges Thema - Nächstes Thema

Nobbynews

@Beta-User:
Zwar OT, aber da ich mit RegExp auf Kriegsfuß stehe mal eine Frage zum Verständnis:
Zitat von: Beta-User am 14 September 2020, 15:52:59
defmod wd_test watchdog shellydevice:relay_0_energy:.0.0 00:00:20 shellydevice:relay_0_energy:.[1-5].[0-9] set deindummy absent;; trigger wd_test .

Das müsste doch bedeuten, dass der wd_test bei energy = 0 triggert und wenn nicht innerhalb von 20s für energy ein Wert 10 >= energy <= 59 kommt, der Befehl ausgeführt wird?

Beta-User

#46
Zitat von: Nobbynews am 15 September 2020, 07:30:24
@Beta-User:
Zwar OT, aber da ich mit RegExp auf Kriegsfuß stehe mal eine Frage zum Verständnis:Das müsste doch bedeuten, dass der wd_test bei energy = 0 triggert und wenn nicht innerhalb von 20s für energy ein Wert 10 >= energy <= 59 kommt, der Befehl ausgeführt wird?
Nicht ganz...

Genauer: Ein Event vom Gerät "shellydevice" des Readings "relay_0_energy", das der regex 0.0 entspricht (also "0.0", oder (unwahrscheinlich) "0B0", "0y0" (=> noch genauer wäre "0\.0" oder 0[.]0)) löst das Ding aus, es wird 20 Sek. gewartet, und wenn dann nichts kommt, was der anderen Regex entspricht, wird der Befehl ausgeführt und der watchdog reaktiviert. Dabei wird davon ausgegangen, dass der Event zwischen dem Readingnamen und dem Wert einen Doppelpunkt und ein Leerzeichen enthält (so liefert das jedenfalls mein Test-Shelly, eigentlich war das also mMn. ziemlich mundfertig vorbereitet :'( ).

Die 2. Regex würde also auch auf "1x9" "anspringen, gedacht war das aber (aufgrund der hier konkret auftretenden Events) eben für alles, was mind. eine 1 "vor dem Komma" hat, also "1.0" bis "5.9".
Falls man also die 2. Regex genauer und für mehr Stellen vor oder hinter dem Komma haben wollte, müßte man das erweitern zu (z.B.) "[^0]\.[0-9]+".

Falls du Lesestoff dazu suchst: Ich teste sowas bei Bedarf mit regexr.com oder regex101.com, da sind auch jeweils Hilfen zu finden, falls man mal eine "kryptische" Regex zugespielt bekommt oder findet und sich erklären lassen will, wie das Ding "tickt" ;) .

(Aber eigentlich habe ich keine große Lust mehr, in diesem Thread hier was beizutragen :( . Das was der TE schreibt, kommt bei mir so an, als würde jede taugliche Info bewußt überlesen und dann nebenbei vielleicht (!) noch unterstellt, man würde ihn verschaukeln...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Nobbynews

Hallo Beta-User,

Danke für die ausführliche Erklärung.
Das mit "0.0" hatte ich schon vermutet. Damit ergibt sich dann auch automatisch der der andere Wertebereich.

Beta-User

Zitat von: Nobbynews am 15 September 2020, 08:11:54
Das mit "0.0" hatte ich schon vermutet. Damit ergibt sich dann auch automatisch der der andere Wertebereich.
(Im Prinzip) ja, wobei es nicht mehr ganz so einfach wird, wenn man mehr Stellen als eine hat und auch noch 0.01 usw. erfassen wollte. Da paßt dann meine Beispiel-Regex auch nicht mehr, dafür müßte man vermutlich eher sowas schreiben (ungetestet):
[1-9]([0-9]+)?\.[0-9]+|0\.([0-9]+)?[1-9]

Man muß halt mal verstanden haben, dass es im Prinzip ein Textvergleich ist und kein mathematischer...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MarkoP

Also ich habe es mit folgenden Schreibweisen versucht:
([Ladeschale_Marko:relay_0_power] < 1)
Ladeschale_Marko relay_0_power < 1
Ladeschale_Marko.relay_0_power < 1
Ladeschale_Marko:relay_0_power < 1
Alle Varianten ohne Erfolgt, wenn nicht die Fehlermeldungen von oben kamen, dann wurde der Timespec angemeckert obwohl er genau wie gefordert geschrieben ist.

Die Logik nach der man Device (also "Ladeschale_Marko") und reading (also "relay_0_power") schreibt bzw. trennt, also den Regex schreibt, erklärt sich mir nicht.
Ich habe den Eindruck mal wird es so und mal so geschrieben. Übrigens stammt die zweite Variante ohne Punkt oder Doppelpunkt als Trenner aus dem Event-Monitor.

Bei mir handelt es sich aber doch um mathematische Werte, sonst würde in dem funktionierenden DOIF (was übrigens mit der ersten Formulierung, das angeblich kein Regex ist) ja kein größer als funktionieren, oder?

Wenn ich jetzt alles zusammen nehme müsste folgender Code doch eigentlich funktionieren, oder nicht?
define w_Nachtlicht_Marko_Morgens watchdog Ladeschale_Marko:relay_0_power:0 00:00:04 Ladeschale_Marko:relay_0_power:<1 set test on-for-timer 1;; trigger w_Nachtlicht_Marko_Morgens .

Oder funktionert die Abfrage größer/kleiner als in einem DOIF, aber in einem watchdog nicht?
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

Beta-User

Zu DOIF mache ich keine Aussage, denn da verstehe ich die Syntax nicht, und deswegen nutze ich das auch nicht mehr, aber wie bereits geschrieben will watchdog (ausweislich der commandref) eine Regex haben (Ergo: eben keine mathematischen Ausdrücke). Daher ist es auch wichtig zu beachten, ob das Event (=> Event-Monitor!)
Ladeschale_Marko:relay_0_power:0
oder
Ladeschale_Marko:relay_0_power:.0
oder eben
Ladeschale_Marko:relay_0_power:.0.0
GESCHRIEBEN wird (Textvergleich, keine Mathematik...)

Aus diesem Grund war auch meine Empfehlung hier irgendwann in ferner Vergangenheit, die keinen mehr kümmert, beide Regexe je gesondert mit einem notify zu testen ;) .

Und nochmal: die Syntax von DOIF ist speziell, das Verhalten läßt sich mit "ein bißchen Attribut" komplett ändern. Daher bleibt meine Empfehlung: Hände für die ersten Schritte weglassen und auch die Syntax nicht woanders hin übertragen wollen, solange die Grundlagen nicht klar sind!
Und da gehört ein Grundverständnis des Stichworts Regex eben dazu, ohne das wird es früher oder später auch mit Helferlein wie DOIF nichts...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

#51
Nachdem der Hinweis EventMonitor schon gefallen ist:

mit dem EventMonitor kann man sich ja (bekanntlich) notify/DOIF "erzeugen lassen".

EDIT: und watchdog! ;)

D.h. die dort genutzte RegEx müsste ja dann auch für Watchdog passen ;)

ABER: eben nur der RegEx-Teil!!


Gruß, Joachim

P.S.: und ja ohne RegEx (ich "mag" es auch nicht ;)  ) geht leider nix viel was hier...
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Im Event-Monitor steht watchdog als Eventhandler (und noch mehr!) ebenfalls zur Auswahl :-* ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

#53
Zitat von: Beta-User am 15 September 2020, 12:20:18
Im Event-Monitor steht watchdog als Eventhandler (und noch mehr!) ebenfalls zur Auswahl :-* ...

Hab noch nie einen watchdog an die Kette gelegt ;)

EDIT: ziehe (aus Gewohnheit) (immer) ein at auf, weil dann kann ich auch alles mögliche andere "prüfen" (und sogar diesselbe Sub mit der Kennung "at" erneut aufrufen und spare mir so Programmierung ;)  ), das aber nur am Rande... ;)

Korrigiert und gemerkt! :)

Danke, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MarkoP

Wenn Regex keine mathematischen Begriffe kennt ist alles weitere sinnfrei, da ich ja zwingend abfragen muss ob der Wert größer X ist.
Ich kann nicht mit einem festen Wert vergleichen, dafür ist die Variation zu hoch und damit die Treffsicherheit viel zu gering.

Oder gibt es eine Alternative für Regex?
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

Prof. Dr. Peter Henning

#55
Ich mach noch einmal einen Versuch.

Erst einmal ist es Unsinn, von "mathematischen Begriffen" zu sprechen. Auch eine Zahl ist ein mathematischer Begriff - und Reguläre Ausdrücke kennen sehr wohl Zahlen. Gemeint ist wohl, ob Reguläre Ausdrücke mathematische Operationen durchführen können. Nein, können sie nicht.

Zweitens kann man aber auch mit Regulären Ausdrücken Werte testen. Beispielsweise ist der Zahlenwert eines zweistelligen Ziffernstrings, der mit 9 beginnt, sicher größer oder gleich dem festen Wert 90.

Bitte endlich mal mit den Grundlagen befassen !

LG

pah


Beta-User

?

Funktioniert denn meine 2. Regex für deinen Anwendungsfall nicht? (Ach, ich vergaß, dein System ist ja nicht verfügbar, und die Events auf einem Testsystem mit trigger zu erzeugen und zu Testen kam dir bisher nicht in den Sinn, lieber schnell mal was ... schreiben statt ausnahmsweise mal lesen und nachdenken...?)

Man KANN solche Problemstellungen auch mit regex lösen, aber weil das für Einsteiger nicht ganz so einfach ist, gab's hier c&p-Code samt Erläuterung... (für die, die sich auch mal einen Wachhund zulegen wollten und _wirklich_ wissen wollten, wie es geht...).

(@MarkoP:
JETZT wäre die Gelegenheit, dich bei allen zu entschuldigen, denen du absichtlich oder unabsichtlich auf die Füße getreten bist, ansonsten ist es jedenfalls für meine Person zu spät. Und eine Verbesserung des "Überlese-Verhaltens" wäre auch angezeigt...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MarkoP

@Beta-User
Deine zweite Ausführung war:Ladeschale_Marko:relay_0_power:.0 und du hast unter alle geschrieben das es sich dabei um einen Textvergleich handelt und nicht um einen mathematischen vergleich - so ist es für mich zumindest rauszulesen. Da die Leistungswerte selten bis nie identisch sind sondern im Kommabereich stetig schwanken bringt es mir nichts auf einen einzelnen Wert (Textvergleich) zu prüfen, da ich keine Sicherheit habe ob dieser überhaupt einmal in der Nacht auftritt. Also was habe ich jetzt überlesen oder nicht bedacht? Ganz ehrlich, denn ich kann deinen Sarkasmus gerade nicht verstehen. Was stört dich? Das ich geantwortet habe, weil ich keinen praktischen Test gemacht habe bei dem ich das Ergebnis vorher schon kenne?

@Prof. Dr. Peter Henning
Natürlich ist 0,91 - 0,99 größer als 0,90, doch wenn ich im Regex kein "Größer als" nutzen kann, dann nützt mir dieses Wissen nichts. Oder wo steht in den Grundlagen, dass ein Textvergleich bei dem lediglich die Zeichen verglichen werden einen Unterschied feststellt. Bei einem Textvergleich wird lediglich zurückgegeben ob der Wert stimmt oder nicht, klappt also wunderbar mit 1/0, on/off, etc., aber nicht bei einer mathematischen Bestimmung. Was nützt es mir einen Textvergleich auf den Wert ".09" vorzunehmen, wenn ich nicht garantieren kann, dass überhaupt ein Wert mit ".09" vorkommt? Die Leistungswerte schwanken im Sekundentakt im Hunderstellbereich und es werden stets die Endpunkte der linearen Größenänderung im Log registriert.
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

Prof. Dr. Peter Henning

#58
Hmm. Der letzte Anlauf war ein Fehler - weil der TE wieder lieber wortreich schreibt, als nachzudenken. Also letzter Hinweis, und dann bin ich wirklich kuriert:

Wenn ein Messwert in FHEM im Sekundentakt schwankt, hat jemand etwas Grundlegendes nicht verstanden.

pah

Beta-User

Zitat von: MarkoP am 15 September 2020, 13:56:12
Was stört dich? Das ich geantwortet habe, weil ich keinen praktischen Test gemacht habe bei dem ich das Ergebnis vorher schon kenne?
Ja! (Unter anderem)

Ich hatte 3 (!) Varianten die regex für das "0"-Event genannt und verschiedene für "nicht 0", das ganze in der Hoffnung, dass du ggf. mal deine konkreten Events (! die fehlen bis heute!) mit Hilfe von regexr.com testest und uns dann verrätst, welche funktionieren bzw. welche Änderungen ggf. noch erforderlich wären. Das ist übrigens nicht neu, unmittelbar, nachdem wir geklärt hatten, dass du unbedingt "eocr .*" beibehalten möchtest (das paßt btw. übrigens wieder zu dem, was pah eben geschrieben hat) hatte ich mal folgendes in den Raum gestellt:
Zitat von: Beta-User am 06 September 2020, 07:41:46
Die Schwierigkeit hier besteht halt darin, dass wir vermutlich nicht davon ausgehen können, dass es nicht geringfügige Schwankungen gibt... Aber da das immer einstellig ist (?), sollte als 2. Event sowas wie "[1-5].[0-9]" gehen.
Von daher wäre meine Mindesterwartung sowas wie "ich habe jetzt alle drei verwendet, keine hat funktioniert. Das Event ist hinter dem Komma zweistellig und hat hinten noch ein W, das sieht im Event-Monitor so bzw. so aus (Wert kann schwanken): ... regexr habe ich ausprobiert, aber ich bekomme das trotzdem nicht hin, und was das mit dem Punkt in den regexen sein soll, erschließt sich mir immer noch nicht. Kann mir das bitte jemand nochmal erklären oder hat einen link, wo dazu Beispiele zu finden sind?"

Was mich also viel mehr stört als dieser Einzelfall ist die blinde Konsequenz, mit der du deine falschen "Überzeugungen" verteidigst, obwohl du eigentlich gemerkt haben solltest, dass du mit deinen "Überzeugungen" und "logischen Herleitungen in der Theorie" in deinem Projekt keinen einzigen Millimeter vorwärtskommst. Fazit aus meiner Sicht: da sind Hopfen und Malz verloren, es macht für mich nicht mal mehr Sinn wegen der eventuellen Mitleser, die daraus ggf. was lernen können. Ab jetzt ist es nur noch traurig.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors