Rolladen-Funk-Aktor mit Gedächtnis?

[MarkoP]

Es ist eher so, dass fast alle der "Kern"- Module (notify, FileLog, watchdog, ...) intern das Ausgangs- und Endflag ergänzen, wenn irgendwo eine regex anzugeben ist. Die große Ausnahme ist afaik (rate mal:) DOIF.

Ok, das hätte ich nie aus dem Text herausgelesen den ich gesehen habe. Egal, weiß ich bescheid, dass man die Zeichen in der Regel weglässt.

MAn. ja, du hast was übersehen. Bitte darüber nachdenken.

Dann bin ich echt zu blöd es zu raffen. "\d" steht für irgendeine Zahl, also 0-9. "[0-9]" für Zahlen zwischen 0 und 9 einschließlich der genannten bzw. "[1-9]" afaik für alle Zahlen von 1-9.
Also heißt es doch aufgeschlüsselt irgendeine Zahl, gefolgt von irgendeinem Zeichen und wieder irgendeiner Zahl mit einer Zahl zwischen 1-9 dahinter. Das ergibt für mich alles von 0.01 bis 9.99
Die Messwerte bleiben im Einstelligen Bereich immer mit zwei Nachkommastellen. Das sollte von dem Regex also so abgedeckt werden. Ich sehe jedenfalls keinen Fehler, egal wie lange ich es ansehe und aufschlüssele.

Ich verstehe den ganzen Thread ehrlich gesagt nicht. Es fing an mit Homematic, dann habe ich was mit Shelly gelesen und nun was mit Z-Wave.

So geht es mir mit den verschiedenen Ansätzen und Variationen, insofern hat Beta-User ganz recht. Eine neue Möglichkeit bringt im Moment mehr Verwirrung als Lösung. Aber Kurz zusammengefasst ging es los mir einem verrücktspielenden Homematic Rolladenaktor, daher der Threat-Titel. Im Laufe der Analyse wurde klar, dass nicht der Aktor kaputt ist, sondern einfach von einem Notify das auf einen Shelly-Leistungsmesser zugreift eine derartige und widersprüchliche Menge an Kommandos ausgelöst wurden. Daraus hat sich dann der Lösungsversuch entwickelt die Daten des Shelly mit einem watchdog statt einem notify so einzugrenzen, dass der Rollladen eben nicht "verrückt" spielt. Also halt eine typische Entwicklungsstory. Den Rest hat Beta-User schon richtig zusammengefasst.

Ich kann aber inzwischen auch was zu der Zeitspanne sagen: Beim durchsuchen des Device-Logs war die längste Zeit zwischen zwei Leistungsangaben 3 Sekunden. Ich würde also - um einen kleinen Puffer zu haben - 4 Sekunden nutzen. Im watchdog müsste das dann doch folgendermaßen geschrieben werden:

Code Auswählen Erweitern

00:00:04

Desweiteren verstehe ich nicht wieso AMAD nicht funktionieren soll, sofern das Netzwerk korrekt eingerichtet ist sollte alles gehen.

Ich bekam einfach keine Verbindung zustande. Vermutung diesbezüglich ist, dass es wegen der Konstellation mit dem NAS nicht funktioniert. Dazu gibt es aber einen eigenständigen Threat ohne Lösungserfolg.

[Otto123]

@ MarkoP Obwohl die Waffen ja irgendwie schon geschärft werden, will ich nochmal an meinen (wie fast jeden) von Dir ungelesenen/unbeachteten Beitrag #37 erinnern und aufklären:

Threat - ist die Drohung oder Bedrohung
Thread - ist eigentlich der Faden - so bezeichnet man einen Beitrag (der sich in die Länge zieht).

Leider ist dieser Thread zum Threat geworden - aber wir wollen ja nicht aufeinander losgehen 

[Beta-User]

"\d" steht für irgendeine Zahl, also 0-9.

...dachte ich auch mal, bis mir jemand erläutert hat, dass es mehr Ziffern gibt als 0-9 (das Stichwort war mal wieder bereits genannt worden: Unicode).

"[0-9]" für Zahlen zwischen 0 und 9 einschließlich der genannten bzw. "[1-9]" afaik für alle Zahlen von 1-9.

Soweit richtig, aber anders als \d eben wirklich nur für die arabischen Ziffern

Also heißt es doch aufgeschlüsselt irgendeine Zahl, gefolgt von irgendeinem Zeichen und wieder irgendeiner Zahl mit einer Zahl zwischen 1-9 dahinter. Das ergibt für mich alles von 0.01 bis 9.99

Was ist mit 0.10? Oder 9.80?

Die Messwerte bleiben im Einstelligen Bereich immer mit zwei Nachkommastellen. Das sollte von dem Regex also so abgedeckt werden. Ich sehe jedenfalls keinen Fehler, egal wie lange ich es ansehe und aufschlüssele.

Was bei mir ankam: Der Erhaltungsstrom liegt dann wieder bei >1W. Das würde ich "vor dem Komma" abfragen und daher so schreiben:
[1-9]\.[0-9][0-9]
(Exkurs: Man kann "irgendeine einstellige Zahl mit zwei Stellen hinter dem Komma in arabischer Notation, aber nicht 0.00" auch mit regex ausdrücken. Das wäre dann sowas:

Code Auswählen Erweitern

(?!0[.]00)[0-9][.][0-9][0-9]
Das scheint sogar eine unter FHEM-Gesichtspunkten taugliche bzw. "gute" Regex zu sein, denn zum einen scheint das in meinem Testsystem zu passen und zum anderen meldet

Code Auswählen Erweitern

{ notifyRegexpCheck('shellydevice:relay_0_energy:.(?!0[.]00)[0-9][.][0-9][0-9]') }
(ok).
Warum Exkurs: Zum einen ist das (nach meinem Verständnis) nicht mehr ganz "standard knowledge" mit dem "negative lookahead" (und wohl auch performancemäßig nicht der Brüller), zum anderen ist das mit notifyRegexpCheck() eher ein Hinweis an die erfahreneren Mitleser, dass eine funktionierende Regex noch lange keine "optimale" Regex sein muß: Die Funktion zeigt, wie fhem.pl die Regex intern zerlegt, und das muß nicht zwangsläufig ganz dasselbe sein wie das, was Seiten wie regexr.com&Co anzeigen...)

Ich kann aber inzwischen auch was zu der Zeitspanne sagen: Beim durchsuchen des Device-Logs war die längste Zeit zwischen zwei Leistungsangaben 3 Sekunden. Ich würde also - um einen kleinen Puffer zu haben - 4 Sekunden nutzen. Im watchdog müsste das dann doch folgendermaßen geschrieben werden:

Code Auswählen Erweitern

00:00:04

Das mit den 4 Sekunden halte ich für suboptimal. Damit wärst du zwar noch im Bereich einer "ziemlich direkten Reaktion", aber die Verzögerung z.B. beim Lichtanschalten wäre noch zu groß, um nicht zu irritieren. Ich würde eher dafür plädieren, die Events weiter auszudünnen und bestenfalls alle Minute einen Event durchzulassen, es sei denn, es läge ein Sprung um mehr wie 4W vor. Aber das ist (jedenfalls ganz überwiegend) Geschmackssache...

[MarkoP]

...dachte ich auch mal, bis mir jemand erläutert hat, dass es mehr Ziffern gibt als 0-9 (das Stichwort war mal wieder bereits genannt worden: Unicode).

Ok, soll nicht vermessen klingen aber ich bin purer Deutscher, von daher habe ich nicht an irgendwelche Sonderzeichen oder andere Schriften gedacht. das gebe ich zu. Für mich sind ausschließlich 0-9 Ziffern. Aber genaugenommen hast du selbstverständlich recht. Also wenn ich dich recht verstehe, würde "\d" also beispielweise auch bei einer römischen 1 eine Übereinstimmung melden.

Was ist mit 0.10? Oder 9.80?

Stimmt natürlich, nicht bis zu Letzt durchdacht. Das sind halt wirklich Lernprozesse, die man sich aneignen muss. Man übersieht halt viel zu schnell irgendwelche Einzelfälle.

Was bei mir ankam: Der Erhaltungsstrom liegt dann wieder bei >1W. Das würde ich "vor dem Komma" abfragen und daher so schreiben:

Genaugenommen liegt er soweit ich gesehen habe sogar immer über 2W. Doch da ich in dem Zusammenhang schon zu viel übersehen habe, wollte ich eben gerade so genau wie möglich abfangen. Also halt alles ab 0.01 aufwärts. Aber ich denke inzwischen auch, dass ich da viel zu viel wollte bzw. es eben wesentlich leichter geht.
Der Backslash maskiert in dem Zusammenhang den Punkt, richtig? So muss es wirklich ein "." sein und eben nicht irgendein Zeichen.

(?!0[.]00)[0-9][.][0-9][0-9]

Ich verstehe den ersten Teil nicht, also das "(?!0[.]00)". Wozu dient diese Dopplung? Die Angabe auf der Analysewebsite verstehe ich so, dass alles was in der folgenden Regex zutreffend ist umgekehrt - also nicht zutreffend - ist.
Und wieso setzt du den Punkt dabei in eckige Klammern? Der Punkt als solches ist doch ohne eckige Klammern schon ein Platzhalter. Verändert sich das Verhalten des Platzhalters durch die Klammern?

Das mit den 4 Sekunden halte ich für suboptimal. Damit wärst du zwar noch im Bereich einer "ziemlich direkten Reaktion", aber die Verzögerung z.B. beim Lichtanschalten wäre noch zu groß, um nicht zu irritieren. Ich würde eher dafür plädieren, die Events weiter auszudünnen und bestenfalls alle Minute einen Event durchzulassen, es sei denn, es läge ein Sprung um mehr wie 4W vor. Aber das ist (jedenfalls ganz überwiegend) Geschmackssache...

Mein Gedankliches Problem bei einer derartigen Lösung ist, dass ich nicht kontrollieren könnte ob ggf. nach einer Minute dann wieder der 0W-Wert vorliegt. Ist zwar Zufall, aber nach meiner Logik doch im Bereich des Möglichen.
Dazu sei gesagt, die Leistungsangaben ändern sich im Zeitrahmen zwischen 1 und 3 Sekunden und in der Regel folgen auf einen 0W Zustand 4-5 leicht verschiedene Zustände um die 2,5W und dann fängt der Zyklus wieder von vorne an. Wenn ich also immer nur einen Wert pro Minuten durchlassen würde - was ich mit eocr und abhängigen Attributen machen müsste - könnte es vorkommen, dass innerhalb des beim watchdog gesetzten Zeitrahmens kein abweichender Wert als 0W ausgegebenen würde. Klar, extrem Fall, aber genau diese versuche ich ja auch abzufangen. Oder habe ich hier wieder einen Denkfehler?

Jetzt aber mal ehrlich, wie lange hast du gebraucht bis du alle diese Variationen und Sonderfälle gelernt hast? Ich glaube nicht, dass dies jemand ohne Anleitung einer anderen Person von Heute auf Morgen schafft
Selbst die Analyseseiten bieten ja kein vollständiges Lexikon der einzelnen Funktionen. Zum Beispiel habe ich das mit dem Maskieren nirgendwo gefunden bei den Funktionserklärungen.

[Otto123]

würde "\d" also beispielweise auch bei einer römischen 1 eine Übereinstimmung melden.

Immer deine rum Raterei und vorschnellen, eigenen Interpretationen 
Es gibt für alles eine Doku, klar die musst Du wieder lesen (wollen): https://perldoc.perl.org/perlre.html

gerade zum Thema digits ist da sehr viel erklärt - ja, es ist nicht einfach.

Diese "regExp Schlacht" im Thread ist vielleicht das Einzige, was es für Mitleser noch etwas interessant macht

[Beta-User]

Jetzt aber mal ehrlich, wie lange hast du gebraucht bis du alle diese Variationen und Sonderfälle gelernt hast? Ich glaube nicht, dass dies jemand ohne Anleitung einer anderen Person von Heute auf Morgen schafft

...ewig, und ich bin sicher nicht "fertig" mit lernen....!

Deswegen kann man ja u.a. auch hier um Rat fragen - sofern man die Forenregeln beachtet, wird einem in der Regel auch geholfen. Zu diesen gehört es auch, wenigstens den Versuch zu unternehmen, sich die Grundlagen anzueignen, bestimmte Infos zu liefern und anderen mit Respekt zu begegnen. Weil es hier an der einen oder anderen Stelle massiv gehapert hat, hat es in diesem Fall so lang gedauert, bis wir in der Nähe einer Lösung und eines gewissen gegenseitigen Verständnisses sind .

Ansonsten habe ich zuhauf Dinge falsch gemacht und daraus auch das eine oder andere an "lesson learned" gezogen.

Selbst die Analyseseiten bieten ja kein vollständiges Lexikon der einzelnen Funktionen. Zum Beispiel habe ich das mit dem Maskieren nirgendwo gefunden bei den Funktionserklärungen.

Das steht (vermutlich) wieder irgendwo in der commandref, ist aber "Allgemeingut", wenn man es mit Regex zu tun hat, und auf regexr.com kommt dann zu einer Regex "\." auch direkt die Erläuterung "Escaped character. Matches ..." (Ich hatte übrigens beide Varianten, wie man genau einen Punkt "meinen" kann, auch die mit dem "[.]" - hübsch aufbereitet gehabt auf die vermeintliche OT-Zwischenfrage ).

Regexr liefert auch Infos zu den anderen Regex-Fragen, wenn da nach etwas "Spielen auf der Seite" wirklich (!) noch Fragen offen sind, kannst du das nochmal vertiefen, aber bitte nicht gleich zu sowas wie "negative lookahead"; das braucht man eher selten, und wenn man glaubt, dass doch, ist es - wie hier - oft besser, nochmal zu checken, ob es eine weniger exakte Lösung auch täte.

[...] würde "\d" also beispielweise auch bei einer römischen 1 eine Übereinstimmung melden.

Ähm, vermutlich nicht. Eher bei einer chinesischen oder indischen (grade keine Lust, für Details in Zeichensätze zu sehen).
Nachtrag:

Es gibt für alles eine Doku, klar die musst Du wieder lesen (wollen): https://perldoc.perl.org/perlre.html

@Otto: Danke für den Link!

Stimmt natürlich, nicht bis zu Letzt durchdacht.

Nochmal die Bitte: Wenn dir jemand, der es vermutlich besser weiß andeutet, dass du auf dem Holzweg bist, solltest du in der Tat davon ausgehen, dass auf deiner Seite des Bildschirms was faul ist. (Und das war jetzt noch keine Raketenwissenschaft, also nimm das als feedback zum Justieren des Selbstverständnis zum Thema Lösen von abstrakten Problemen).

Mein Gedankliches Problem bei einer derartigen Lösung ist, dass ich nicht kontrollieren könnte ob ggf. nach einer Minute dann wieder der 0W-Wert vorliegt. [...] Oder habe ich hier wieder einen Denkfehler?

Der "Trick" dürfte darin liegen, eine geeignete Hysterese (EDIT: besser "Schwelle" oder "threshold") für event-on-change-reading für dieses spezielle Reading zu definieren. 0.7 könnte ein guter Wert sein... (Die links zum Wiki und dem speziellen "Shelly-MQTT2-Thread", in dem es um einen "mustergültigen" Satz der fraglichen Attribute ging, sollten eigentlich bereits hier zu finden sein).

Diese "regExp Schlacht" im Thread ist vielleicht das Einzige, was es für Mitleser noch etwas interessant macht

...vielleicht (das beste kommt bekanntlich immer zum Schluss), vielleicht aber auch solche Links wie der auf perldoc/perlre

(Jetzt bin ich aber damit auch ziemlich durch, und meine Erwartung wäre, dass wir dann von MarkoP als nächstes einen vollständigen und getesteten Code zu sehen bekommen )

[rudolfkoenig]

Es gibt für alles eine Doku, klar die musst Du wieder lesen (wollen): https://perldoc.perl.org/perlre.html

Das ist die ueber Internet abrufbare Variante des "offline" Programmes perldoc, was man in einem Terminal aufruft.
Beispiele:
perldoc perlretut
perldoc Math::Trig
perldoc -f grep
perldoc perlfaq3

[Prof. Dr. Peter Henning]

Es muss außerdem noch festgestellt werden, dass die vom TE vorgetragenen Behauptungen über "verrückt spielende" Aktoren keinen sachlichen Hintergrund haben, dass sowohl die Hardware als auch FHEM sich vollkommen regelkonform verhalten.

Desweiteren macht es keinen Sinn, irgendwelche Datenwerte im Sekundenabstand abzufragen. So genau ist weder das Messverhalten der Shelly-Geräte, noch lässt sich aus solchen Schwankungen ein sinnvolles Verhalten eines Aktors ableiten.

Das Problem der Anwesenheitserkennung beschäftigt uns schon seit etlichen Jahren, und jeder, der sich wirklich damit befasst hat, kennt die Probleme im Detail.

pah

[Beta-User]

...jetzt muß ich doch nochmal was schreiben...

Es muss außerdem noch festgestellt werden, dass die vom TE vorgetragenen Behauptungen über "verrückt spielende" Aktoren keinen sachlichen Hintergrund haben, dass sowohl die Hardware als auch FHEM sich vollkommen regelkonform verhalten.

Das ist _fast_ richtig:

P.S.:
Hab schon mal ins Log reingeschaut (Kopiere es heute Abend vom PC hier rein). In der betreffenden Zeit +/- 20 Minuten als der Fehler auftrat konnte ich keinen einzigen Eintrag zum Rollladenaktor im Log finden.

In dem Fall war ich es, der das irgendwie überlesen bzw. nicht vollst. zutreffend interpretiert hatte, denn ohne ohne Einträge im Log sah es ggf. in der Tat so aus, dass die Aktoren irgendein seltsames Eigenleben geführt hatten.

Irgendwie ist es wohl so, dass just in dieser fraglichen Zeitspanne - entgegen dem vorherigen langjährigen Verhalten - Schaltanweisungen von FHEM aus _nicht_ im Log zu finden waren, was mir aber erst mal entgangen war, aber als Rückmeldung an MarkoP ggf. hilfreich gewesen wäre. Da das aber in allen anderen Aspekten eine andere Baustelle ist, sollten wir diesen Aspekt jetzt wirklich auf sich beruhen lassen...

Desweiteren macht es keinen Sinn, irgendwelche Datenwerte im Sekundenabstand abzufragen. So genau ist weder das Messverhalten der Shelly-Geräte, noch lässt sich aus solchen Schwankungen ein sinnvolles Verhalten eines Aktors ableiten.

Ohne das jetzt im Detail geprüft zu haben, gehe ich davon aus, dass die Aktoren tatsächlich wie vom TE geschildert über MQTT von sich aus extrem gesprächig sind und daher teilweise sogar im Sub-Sekundentakt irgendwelche Daten senden, bei denen man dann entscheiden muss, ob man die wirklich braucht. "Abgefragt" wird dabei nichts, das passiert automatisch. Allerdings würde mich ggf. immer noch interessieren, wie man den Shellys das ggf. (teilweise) austreiben kann, denn es wäre zielführender, z.B. eine Schwelle von 10% Änderungswert auf dem Shelly direkt zu setzten, als die Infos dann auf der FHEM-Seite aufwändig wegzukonfigurieren...

(Aber auch das hatten wir an anderer Stelle schon mal in einem partiell ähnlichen Kreis andiskutiert).

[MarkoP]

... anderen mit Respekt zu begegnen.

Soll ich jetzt wirklich alle Punkte rausschreiben wo mir nicht mit Respekt begegnet wurde, wo man mich unbegründet gebasht und gemobbt hat? Da brauchen wir ja nur ganz kurz nach oben oder unter deinen Post zu scrollen um schon zwei Stellen zu finden. Ja, Respekt ist wichtig, aber der gilt in beide Richtungen. Entschuldige das gilt nicht dir persönlich, sondern ist eine generelle Feststellung.

Das steht (vermutlich) wieder irgendwo in der commandref, ist aber "Allgemeingut", wenn man es mit Regex zu tun hat

Ja und genau das ist mein Problem, es gibt zu viele Quellen. Sucht man A muss man in X schauen, suchst du B must du in Y nachgucken und suchst du eine Kombination aus A und B must du nicht in de Quellen X und Y sondern in Dokument Z schauen. Das war auch das was ich mit durcheinander gewürfelter Dokumentation meinte. Du weißt wo du nachschauen must, ich muss jedes mal überlegen und nicht nur das, ich muss zusätzlich überlegen welche Quellen es denn überhaupt alles gibt, denn die Übersicht hat man auch erst nach Jahren.

Nochmal die Bitte: Wenn dir jemand, der es vermutlich besser weiß andeutet, dass du auf dem Holzweg bist, solltest du in der Tat davon ausgehen, dass auf deiner Seite des Bildschirms was faul ist. (Und das war jetzt noch keine Raketenwissenschaft, also nimm das als feedback zum Justieren des Selbstverständnis zum Thema Lösen von abstrakten Problemen)

Die Bitte ist ja auch vollkommen berechtigt, aber ich kann doch nicht jedes mal wenn irgendjemand meint ich wäre auf dem Holzweg die halbe Hardware neu kaufen. Wo soll das denn dann enden? in einer Müllhalde aus Aktoren und Sensoren, wo die Hälfte ungenutzt rumfliegt? Betrachte es doch mal aus meiner Sicht, ich habe nicht dutzende von Hardwareteilen herum liegen. Bei der Hälfte aller Vorschläge wäre das aber zwingend notwendig gewesen. Und das weil dann irgendjemand einfach nur einen anderen Weg bevorzugt.

(Jetzt bin ich aber damit auch ziemlich durch, und meine Erwartung wäre, dass wir dann von MarkoP als nächstes einen vollständigen und getesteten Code zu sehen bekommen )

Damit wir uns nicht missverstehen, was verstehst du unter Code? Ein List, den define Befehl, Log-Auszug - liefere ich alles gerne, muss nur wissen was genau. Wird aber vermutlich bis Anfang kommender Woche dauern, da ich am Wochenende Besuch habe und vorher noch die Bude aufräumen muss, von der Renovierung ganz zu schweigen.


Zu den restlichen Postings außer dem von rudolfkoenig sage ich besser nichts, sonst endet es wieder in einer Schlammschlacht. Es sollte aber beispielweise reichen, dass ein gewisser studierter Herr mich jetzt auch schon  privat belästigt oder in bereits als gelöst markierten Threats noch mit Bashing und unlauteren Behauptungen nachtritt. Kein würdiges Verhalten für einen Akademiker. Vielleicht bin gar nicht ich es, der mal sein Verhalten überdenken sollte. Vielleicht, ganz vielleicht, ist es einfach der Punkt, dass manche Personen sich einfach mal öfter an ihre Anfangszeiten erinnern sollten. Von mir Anfänger wird hier erwartet wofür andere erfahrene User wie Beta-User nach eigener Aussage Jahre gebraucht haben. Also mal ehrlich Leute, was stimmt an diesem Verhältnis nicht?

[Beta-User]

Damit wir uns nicht missverstehen, was verstehst du unter Code? Ein List, den define Befehl, Log-Auszug - liefere ich alles gerne, muss nur wissen was genau.

Minimalfassung wäre:
Ein list von dem funktionierenden watchdog.

Optimal wäre:
Ein list von dem funktionierenden watchdog, eins von dem mit den "richtigen" eocr-&Co-Attributen versehenen MQTT2_DEVICE (das du übrigens gerne dazu nutzen kannst, den "presence-Status" des Handy's (direkt mit setreading aus dem watchdog raus) da reinzuschreiben, dann brauchst du keinen extra-Dummy, um das in ROOMATE abzubilden, aber das wäre dann Kür...).
Dazu die Events aus dem Event-Monitor, aber eben nur die, die irgendwas mit dem watchdog zu tun haben (also das Auslöser-Reading und die vom watchdog dann ausgelösten Kommandos und was dazugehört (Events im Event-Monitor kann man mit der passenden Regex beschränken, der Umgang mit regexr.com ist ja zwischenzeitlich hoffentlich klar, und das ist eine weitere gute Übung dafür), das ganze dann für eine gewisse Dauer, so dass man nachvollziehen kann, wie das Ding tickt und ob dann alles zusammenpaßt.

[...] es gibt zu viele Quellen. [...]

Irrtum. Die letzten Posts beschäftigten sich - was dein konkretes Problem anbelangt - NUR mit regex und die Lerninhalte können mit der einen genannten Quelle allesamt (ziemlich) vollständig erarbeitet werden, ohne dass man woanders hingucken muß.

Die Bitte ist ja auch vollkommen berechtigt, aber ich kann doch nicht jedes mal wenn irgendjemand meint ich wäre auf dem Holzweg die halbe Hardware neu kaufen.

Äpfel und Birnen... Dein Zoo ist suboptimal, aber zuletzt ging es nicht um den Zoo im Allgemeinen, sondern um eine sehr konkrete Frage zu einer bestimmten Regex. Und genau dazu war mein Signal: Du bist auf dem Holzweg, (und damit indirekt zum x-ten Mal: schau doch nochmal nach, ob es nicht etwas anders "geschickter" geht und hier nicht schon die Lösung versteckt ist).



Zum interpersonalen Rest sollten jetzt ALLE (!) einfach stille schweigen, wäre jedenfalls meine Meinung.

[Prof. Dr. Peter Henning]

dass die Aktoren tatsächlich wie vom TE geschildert über MQTT von sich aus extrem gesprächig sind und daher teilweise sogar im Sub-Sekundentakt irgendwelche Daten senden

Nein, das tun sie nicht. Von sich aus alle 1 Minute bei den Shelly-Devices, zusätzlich bei allen internen Schaltvorgängen und bei starken Änderungen der gemessenen Leistung (je nach Device)

Darüber hinaus ist die Präzision der Strommessung mit 1% nicht sonderlich hoch. Bei einer Belastungsgrenze von 2,5 kW kann man jedenfalls absolut sicher davon ausgehen, dass die erste Nachkommastelle unsicher und die zweite Nachkommastelle der angezeigten Leistung rein zufällig ist.

LG

pah

[Beta-User]

Nein, das tun sie nicht. Von sich aus alle 1 Minute bei den Shelly-Devices, zusätzlich bei allen internen Schaltvorgängen und bei starken Änderungen der gemessenen Leistung (je nach Device)

Werde mir das auch nochmal ansehen, ich habe irgendwo noch einen shelly1pm rumfliegen, meine aber, dass der - bei nicht zwangsläufig groß schwankenden Lasten, ohne Änderung des Intervalls (wie?) und ohne jedwede Schaltanweisung - häufiger wie 60 Sek. sendet. Kann aber auch an der firmwareversion gelegen haben oder meiner Unfähigkeit, auf die Schnelle den richtigen Dreh' (über das Web-Interface) zu finden, um einen passenden Schwellwert einzustellen. Ist auch schon eine ganze Zeit her, dass ich mich mit dem Ding beschäftigt hatte. Weiß nur noch, dass ich das nicht gut und intuitiv fand...



Dass das ganze in diesem Minimalst-Lastbereich messtechnisch fraglich sein kann, ist ein weiteres Thema, aber manchmal schlägt ja die Praxis die Theorie; das wäre schließlich nicht das erste Mal, dass etwas funktioniert, das eigentlich nicht gehen kann...

[amenomade]

@pah (leicht OT):
Bislang habe ich keinen signifikanten Unterschied zwischen dem von dir hier propagierten regex101.com und regexr.com erkennen können, ich habe irgendwann - vermutlich aus optischen Gründen - eine gewisse Präferenz für regexr entwickelt. Übersehe ich mal wieder was?

regex101 hat auch diese Funktionalität, die u.a. sehr hilfreich sein kann, um die Performanz einer Regex zu verbessern, und um zu verstehen, wie eine Regex funktioniert (inkl Backreferenzen, Lookahead, Lookbehind, Unterschied zwischen .*? und .*)
https://regex101.com/r/qELRQ2/1/debugger
Und ich finde die Darstellung mit allem auf einem Screen besser... Geschmacksache.

[Otto123]

Leider gibt es in diesem Forum offenbar keine Ignore-Liste, daher muss ein zukünftiges überlesen deiner Post leider reichen.

Die Liste ist etwas versteckt in den eigenen Profileinstellungen, siehe Bild

Gruß Otto