[Gelöst] Gosund Steckdosenleiste mit Tasmota

[Otto123]

Richtig verstanden und richtig beantwortet - Danke!

[Beta-User]

Danke!

Immer wieder gerne, vor allem bei Leuten wie dir, die solche Infos dann auch gerne weitergeben, wenn's paßt ...

(Btw.: das mit dem subscriptions-Reading war irgendwie auch lange "unter" meinem persönlichen Radar geflogen, ist aber ein super feature, wenn man bei SERVER-Einsatz was über die Topic-Struktur an sich und/oder die Topics wissen will, unter denen das Gerät Befehle erwartet...)

[Moonlightkid]

Hallo Beta-User,

auch für mich macht Dein Gedanke dazu Sinn:

Eine Anmerkung noch zu dem hier:Ich war früher auch eher ein Freund der "Gesamtdevices", aber zwischenzeitlich bin ich eher auf Rudi's Linie, der bei schaltbaren Devices (v.a., wenn sie - wie MQTT2_DEVICE - SetExtensions unterstützen (können)) die split-Variante bevorzugt.

Von daher: Man kann das so machen, aber wer mit dem Thema erst einsteigt (und auch mit FHEM eher noch am Anfang steht), sollte es sich überlegen, ob er nicht lieber den geringfügigen Overhead für die weiteren MQTT2_DEVICEs in Kauf nimmt, das kann sich hinterher an Stellen auszahlen, die man vorher nicht bedacht hatte...

Just my2ct.

... was ggf. das Schalten mehrerer Aktoren eines solchen devices angeht.

Mit der unified-Variante kann ich die einzelnen Aktoren mit einem passenden notify ansprechen.
Aber mehr als einen gleichzeitig ist wieder knifflig. Damit eine Gruppe generieren, oder mit einer UND-Logik ist für mich (zumindest mit meiner erheblichen Schwäche bei PERL) trivial bis unmöglich. Da wäre es mit tatsächlich einzelnen devices deutlich leichter.

Dafür funktioniert set toggle super (wenn man die wenigen Fälle vernachlässigt, wo das Licht gleich wieder aus oder an geht / je nach vorigem Zustand)
Und toggle brauch ich für meinen Kenntnisstand, um mit jedem der 4 Knöpfe jeweils einen Aktor zu schalten.

Ich fühl mich wohl mit FHEM, was ich soweit habe funktioniert schonmal, auch mit Eurem Knowhow 👍🏻

[Otto123]

Mit der unified-Variante kann ich die einzelnen Aktoren mit einem passenden notify ansprechen.
Aber mehr als einen gleichzeitig ist wieder knifflig. Damit eine Gruppe generieren, oder mit einer UND-Logik ist für mich (zumindest mit meiner erheblichen Schwäche bei PERL) trivial bis unmöglich. Da wäre es mit tatsächlich einzelnen devices deutlich leichter.

Hi,

Es gibt unterschiedliche Möglichkeiten solche Gruppen zu bilden, eine davon ist auch die Benennung der Geräte. Ich glaube darum ging es in deinem Einwand?
Hier mal ein Beispiel zum selbst Testen, wirfst Du einfach so komplett in die "große Eingabe" der Raw Definition - das große Plus oben links :

Code Auswählen Erweitern

define S1 dummy
define S2 dummy
define S3 dummy
define S4 dummy
define n_S notify S[1,4]:(on|off) set L_$NAME $EVENT
define L_S1 dummy
define L_S2 dummy
define L_S3 dummy
define L_S4 dummy
attr L_S[1-4] room TestS
attr S[1-4] room TestS
attr n_S room TestS


Mit set S[1-4] on kannst Du alle  mit einem mal anschalten.
Das geht natürlich auch mit einem Device und den Aktoren als Reading, müsste so ähnlich wie das single Device sein:

Code Auswählen Erweitern

define S dummy
attr S setList POWER1 POWER2 POWER3 POWER4
attr S readingList POWER1 POWER2 POWER3 POWER4
attr S room TestS
defmod n_S notify S:POWER[1-4]:.(on|off) {my $n = $EVTPART0;; $n =~ /([1-4])/;; fhem("set S$1 $EVTPART1")}

Ein set S POWER2 on schaltet den Dummy S2

Neben der Namensgebung gibt es sowas wie structure. Also FHEM ist ziemlich "bunt"

Mit dem Befehl delete room=TestS kannst Du alle TestS wieder löschen

Gruß Otto

[Beta-User]

...natürlich kann man Wege finden, auch Unter-Kanäle in einem Einheitsdevice zu schalten, und etwas Regex kann auch nicht schaden.

Ich gebe nur zu bedenken, dass vermutlich

Code Auswählen Erweitern

S:POWER[1-4]:.(on|off) nicht optimal ist...

Code Auswählen Erweitern

{ notifyRegexpCheck('S:POWER[1-4]:.(on|off)') }
liefert:

S:POWER[1-4]:.(on: device S (OK)
off): unknown (ignored)

Code Auswählen Erweitern

{ notifyRegexpCheck('S:POWER[1-4]:.o[nf]+)') }
dagegen meint

S:POWER[1-4]:.o[nf]+): device S (OK)

(@Moonlightkid: das ist der Kurs für Fortgeschrittene , nicht irritieren lassen...)

[Otto123]

Oh je jetzt verlassen wir den Pfad des Threads

nicht optimal ist...

oder notifyRegexpCheck ist unvollkommen? Weil sagt ja unknown (ignored) - es funktioniert aber dann prächtig!
Ich weiß, der Ausdruck mit den "Capturing Groups (on|off) wird in FHEM an vielen Stellen nicht als richtiger Syntax erkannt.

Ja: o[nf] sieht auch effektiver aus (https://regex101.com/) - match aber genau genommen auf on und of - nicht exakt auf off.

[Beta-User]

Oh je jetzt verlassen wir den Pfad des Threads

oder notifyRegexpCheck ist unvollkommen? Weil sagt ja unknown (ignored) - es funktioniert aber dann prächtig!
Ich weiß, der Ausdruck mit den "Capturing Groups (on|off) wird in FHEM an vielen Stellen nicht als richtiger Syntax erkannt.

Ja: o[nf] sieht auch effektiver aus (https://regex101.com/) - match aber genau genommen auf on und of - nicht exakt auf off.

notifyRegexpCheck() zeigt, wie (u.a.) "notify" "denkt"... Das Problem scheint zu sein, dass fhem.pl intern etwas anders "tickt" wie "normales regex", um gewisse Optimierungen vornehmen zu können. So wie ich das verstanden habe, geht alles, was (ok) ist "zackig", weil direkt klar ist, welches NotifyFn von welchem Device aufgerufen werden muß, ist es unspezifisch, muß erst aufwändig geschaut werden, zu wem _der ganze Ausdruck_ ggf. paßt.

Und du unterschlägst ein "+", was in diesem Zusammenhang nicht "nett" ist, weil es sehr wichtig ist, und etwas andere Ergebnisse erzeugt, als man zunächst denkt...

Code Auswählen Erweitern

o[nf]+matcht nämlich schon auf "off" (und "on"), aber eben auch auf "onnnnnnn", "offf" oder "of" (alles immer gedacht bis zum Ende des Gesamtstrings!). Nur kommen eben derartige Strings nicht unbedingt häufig vor, von daher kann man damit m.E. besser leben wie mit einem "nicht zugeordneten" "off)".

(EDIT: Da war noch eine runde Klammer in der regex, die muss selbstredend raus, hat aber keinen Einfluss auf die eigentliche Aussage...:

Code Auswählen Erweitern

{ notifyRegexpCheck('S:POWER[1-4]:.o[nf]+') } /EDIT)

(Falls ich hier Unsinn verzapfe, mag mich jemand der "Wissenden" bitte deutlich korrigieren...!)

[Otto123]

sorry das + habe ich echt übersehen  wollte ich nicht.

[Beta-User]

...paßt schon...

War eine gute Gelegenheit, das nochmal zu erklären und ich hoffe, das ist jetzt halbwegs nachvollziehbar?

Vielleicht noch etwas mehr Hintergrund: So wie ich das jetzt im Zusammenhang mit der Umstellung von Twilight (von polling auf NotifyFn für useExtWeather) verstanden habe, bekommt man als "empfangendes Device" eigentlich nur zwei Informationen: "Wer bin ich?" (=> eigener Hash des Eventhandlers, z.b. in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/91_notify.pm#L81) und "Wer bist du?" (also von wem stammt der Event bzw. stammen die Events, können ja bulk-update sein). Den Rest muss man sich in der NotifFn selbst zusammensuchen...
(Steht etwas schöner geschrieben auch hier: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify)

Von daher muss der "Event-Verteiler" in fhem.pl nur wissen, wen er eigentlich informieren muss, und das sollte man ihm eben möglichst akkurat mitteilen, weil sonst ggf. ziemlicher Ressourcenverbrauch passieren kann, wenn man das dann noch "passend" kombiniert, wie z.B. hier: https://forum.fhem.de/index.php/topic,114426.msg1087615.html#msg1087615 (_kann_ sein, dass das dort schlimmer aussieht, wie es ist, weil ggf. im Hintergrund ein bulk-update "alles auf einmal" verursacht und verarbeitet, aber das ist teilweise Glückssache. Von daher finde ich die JSON-Variante mit "alles auf einmal" nicht nur schlecht, weil einzelne Topics sonst auch in jedem Fall einzelne trigger mit sich bringen, um mal wieder auf MQTT2_DEVICE zurückzukommen...

[Moonlightkid]

Okay. Auch als Noob wäre ein Teil für mich nachvollziehbar.
Nur im geeigneten Moment werde ich mich u.U. nicht daran erinnern, da ich mit dem bisschen was ich brauche soweit zurecht komme.

Aber krass, wenn man sich auskennt, was alles möglich ist 👍🏻