[gelöst] Mysensors und setExtensions

[Beta-User]

Hallo zusammen,

jüngst ist mir aufgefallen, dass die setExtensions wohl zwar irgendwie im code der MySensors-Module drin sind, aber scheinbar nicht (mehr?) funktionieren.

Hat jemand Info, seit wann das ggf. ein Problem ist? (Ich habe dazu nur einen Beitrag aus Anfang 2018 gefunden, aber da war das scheinbar schon länger ein Problem.

Anbei eine Beispielkonfiguration für Hilfswillige, die keine MySensors-Devices im Einsatz haben...

Gruß, Beta-User

[rudolfkoenig]

Kontext: die OT Bitte hier: https://forum.fhem.de/index.php/topic,97989.msg922860.html#msg922860

Ich meine folgender Patch "fixt" das Problem (oder auch: im Zweifel einfacher ist besser):

Index: FHEM/10_MYSENSORS_DEVICE.pm===================================================================
--- FHEM/10_MYSENSORS_DEVICE.pm    (revision 19009)
+++ FHEM/10_MYSENSORS_DEVICE.pm    (working copy)
@@ -250,7 +250,7 @@
       $hash->{sets}->{fwType} = join(",", MYSENSORS::getFirmwareTypes($hash->{IODev}));
       my $list = join(" ", map {$hash->{sets}->{$_} ne "" ? "$_:$hash->{sets}->{$_}" : $_} sort keys %{$hash->{sets}});
       $hash->{sets}->{fwType} = "";
-      return grep (/(^on$)|(^off$)/,keys %{$hash->{sets}}) == 2 ? SetExtensions($hash, $list, $name, $command, @values) : "Unknown argument $command, choose one of $list";
+      return SetExtensions($hash, $list, $name, $command, @values);
     }
     
     COMMAND_HANDLER: {

Mit dem alten Code ist on und off notwendig, damit Setextensions (und dadurch AttrTemplate) aufgerufen wird, aber das kann SetExtensions schon selbst feststellen, und ist prinzipiell nicht auch on und off angewiesen.

[Beta-User]

Vorab mal ein herzliches Dankeschön!

So ist zumindest attrTemplate sichtbar und auch funktional  .
(Muß nur das model-Attribut noch zulassen).
Das hilft mir schon mal sehr weiter .

Vermutlich muß ich jetzt "nur noch" die Readings, die bisher (nur) über on/off schaltbar waren, noch mit einem Parameter für die setExtensions erweitern, denn in den per on/off schaltbaren Kanälen sehe ich (nachvollziehbarerweise, so ist es eben derzeit festgelegt) nur on/off.

[rudolfkoenig]

Vermutlich muß ich jetzt "nur noch" die Readings, die bisher (nur) über on/off schaltbar waren, noch mit einem Parameter für die setExtensions erweitern, denn in den per on/off schaltbaren Kanälen sehe ich (nachvollziehbarerweise, so ist es eben derzeit festgelegt) nur on/off.

Wenn ich das verstehen soll, dann brauche ich eine anders formulierte Erklaerung.
Achtung: ich habe keine MySensors Erfahrung.

[Beta-User]

Sorry, wollte erst mal kurz Rückmeldung geben, dass ein gutes Stück des Weges funktioniert hat.

Also erst mal eine kurze Info, wie MySensors tickt:

Es werden alle Infos in eine bestimmte Message-Struktur gepackt, bei der bestimmte Ziffern an bestimmten Stellen angeben, um was es sich bei einem "Sensor" eigentlich handelt, wo die Message herkommt, für wen sie bestimmt ist usw., am Ende steht dann in der Regel eine payload, ähnlich wie bei MQTT.
M.E. eine gute Zusammenfassung, was am Ende eigentlich ein Gateway an der seriellen Konsole abliefert (also da, wo das GW-Modul die Daten abholt), wäre hier zu finden: https://www.mysensors.org/download/serial_api_20.

An sich ist der Hauptteil Sensorik, es gibt jetzt nur ganz wenige Typen an "Sensoren", die als _schaltbare_ Untertypen (also im Prinzip Aktor-Kanäle) definiert sind, nämlich alles, was in der Liste in "my %static_types" ab Zeile 108 der 10_...Device-pm einen Eintrag in "receives =>" namens "V_STATUS" enthält (damit eigentlich nur die beiden Einträge in Zeilen 112 und 113).

"my %static_mappings" (ab Zeile 151) macht daraus jetzt (in Sende- und Empfangsrichtung) ein "on" und "off".

Beispiel: Im Egebnis wird daher bei einem schaltbaren Reading am Ende in FHEMWEB angezeigt, dass dieses on und off geschaltet werden kann, nicht aber, was aus den setExtensions kommen würde.

Anbei ein screenshot, ein Bild erklärt ja ggf. mehr als viele Worte.

Zwischenzeitlich würde ich behaupten, dass das wieder durch das Attribut "setReading_(.+)" gesteuert wird, das eben erst mal per default mit on,off gefüllt wird und dann scheinbar mit dem alten Code automatisch funktional mit den setExtensions-Ergänzungen angereichert worden zu sein scheint.

Sehr verwirrend...

Werde jetzt mal bei Gelegenheit testen, ob ein on-for-timer an die setExtensions durchgereicht wird, wenn im Kommandfeld abgesetzt, oder ob man zusätzlich auch das Attribut ergänzen muß. Danach sehen wir ggf. weiter, ob und wie man das ggf. in das Attribut reinbekommt.

Übrigens: MQTT_DEVICE (ohne 2) hat evtl. ein ebenfalls damit zusammenhängendes Problem: https://forum.fhem.de/index.php/topic,82240.msg897191.html#msg897191

[Beta-User]

Nochmal ein update dazu:

Ich kann zwar ein

set MYSENSOR_96 status1 on-for-timer 10

über die Kommandozeile absetzen, ohne dass (bei verbose 3) irgendwas im log erscheint. Das ändert aber nur einmalig das betreffende Reading, das bleibt dann aber "für immer" so (on-for-timer 10) stehen. Ich bin auch ziemlich sicher, dass den Aktor kein "on"-Befehl erreicht hat, sonst müßte  ich in der Realität die Folgen sehen können.

Auch wenn ich die Node mit Ack-Anforderung versehe, kommt keine Rückmeldung, dass bei status1 ein "on" angekommen wäre (bei gesetztem requestAck wird eine Bestätigung von der Node verlangt und in der Regel auch verschickt, dass der Befehl angekommen ist; kommt die nicht zeitnah, wird der Befehl wieder verschickt usw.)...

Bin daher weiterhin ratlos, was den über "attrTemplate" hinausgehenden funktionalen Teil angeht. Aber "wenigstens" das funktioniert nun stressfrei, von daher kann ich mal anfangen, auch die template-file "auf Stand" zu bringen, bisher habe ich nur eine, die grade mal so für schnelle Tests taugt...

[rudolfkoenig]

set MYSENSOR_96 status1 on-for-timer 10

SetExtensions braucht fuer die on-* Funktionen die Befehle on und off.
Im Klartext: wenn "set XX on" und "set XX off" gibt, dann spendiert SetExtensions "set XX on-for-timer YY", "set XX blink Y Z", usw.

Kompliziertere Varianten wie "set XX status1 on" oder "set XX holidayMode on" versteht SetExtensions nicht.

[Beta-User]

Danke schon mal für die Rückmeldung, dann brauche ich nicht weiter suchen und unterstelle mal, dass MQTT_DEVICE tatsächlich dasselbe Problem hat...

Ist das schon immer so? Dann hätte Norberts Code ja nie funktioniert .

Einstweilen müssen User dann also auf ReadingsProxy ausweichen, das ist bei reinen on/off-Geräten/Kanälen ja nicht das Problem. Aber für einen Dimmer oä. braucht man dann schon eine ReadingsGroup, hmmm, nicht soo schön. Muß mal sehen, ob ich irgendwie den state wieder frei bekomme und ggf. _einen_ on/off-Kanal darauf umgebogen. Wird dann vielleicht ein Projekt für 2020 .

Thema ist jedenfalls vorläufig soweit [geklärt].

[rudolfkoenig]

Ist das schon immer so?

Ja, seit Anbeginn der Zeit

Ist auch einer der Gruende, warum ich "Mehrkanalgeraete" meide, und lieber ein Geraet fuer jedes Kanal anlege.

[Beta-User]

Ist auch einer der Gruende, warum ich "Mehrkanalgeraete" meide, und lieber ein Geraet fuer jedes Kanal anlege.

.
Das hatte ich nach den ganzen Diskussionen dazu auch so eingeordnet.

Weiter gibt es vermutlich dann noch das Thema dass Textfelder in der 3. Ebene (also da, wo der on-for-timer-Text hin müßte) nicht vorgesehen sind (es gab da neulich eine Anfrage von anderer Seite dazu).

Bleibt die Frage, was der beste Weg ist, da weiterzumachen. ReadingsProxy ist vorhanden, kann aber nicht mehrere Teilaspekte (z.B. on/off+Dimm-Level). Irgendwo hatte auch mal jemand mehrere MYSENSORS_DEVICE-Geräte mit derselben Node-ID angelegt, aber da vermute ich, dass es (aus Usersicht) eher was mit Stochastik zu tun hat, wie das funktioniert (technisch: abhängig von der Reihenfolge in der cfg).
Muß ich mir mal ansehen, vielleicht wäre das ein Ansatzpunkt, "direkt schaltbare" Sub-Devices hinzubekommen.

(Wenn du eine Idee hast: gerne! Aber bitte: das war bisher nicht dringend und ist es jetzt daher auch nicht... Der wesentliche Teil mit attrTemplate funktioniert ja!)

[rudolfkoenig]

Wenn du eine Idee hast: gerne!

Bin nicht ganz sicher (ich verstehe MYSENSORS noch nicht), aber es klingt nach dem Umbau zu einem Zweistufen-Modul (MQTT2_SERVER / MQTT2_DEVICE).
Alternativ zu sowas wie bridgeDevice/KanalDevice, wird auch in ZWave fuer Mehrkanalgeraete praktiziert.

[Beta-User]

Bin nicht ganz sicher (ich verstehe MYSENSORS noch nicht), aber es klingt nach dem Umbau zu einem Zweistufen-Modul (MQTT2_SERVER / MQTT2_DEVICE).
Alternativ zu sowas wie bridgeDevice/KanalDevice, wird auch in ZWave fuer Mehrkanalgeraete praktiziert.

Eher letzteres, MySensors ist m.E. bereits zweistufig gebaut; das IO-Modul ist 00_MYSENSORS.pm, die sub dort zur Ermittlung, welches Client-Gerät eine Message erhalten soll ist "matchClient()" ab Zeile 560, die ihrerseits intern wieder was aus GPUtils (?) aufruft...

Hast du mir einen Lesetip im zwave-code? (Ich bin bisher über gescheiterte Experimente mit Zwave-Geräten nicht rausgekommen, kenne also diese Variante nicht in der Praxis). CUL_HM ist da anders gestrickt, oder? (Da gibt's aber auch Hauptgeräte mit 6-stelliger ID und 8-stellige Kanal-Devices). Pfff, alles reichlich kompliziert; dabei bin ich eigentlich schon froh, dass ich scheinbar den MySensors-Code halbwegs verstanden habe, jedenfalls solange nicht auch noch diese Hintergrundfunktionen in GPUtils ins Spiel kommen .

[rudolfkoenig]

Hast du mir einen Lesetip im zwave-code?

Das ZWave Modul ist nicht wirklich was zum Ueben/Abschreiben, dafuer werden zu viele Spezialitaeten direkt behandelt.

Bei Geraeten mit der Klasse MULTI_CHANNEL wird bei der Assoziation per "init" Hook "set $NAME mcCreateAll" ausgefuehrt, was wiederum erst Anzahl der Kanaele mit dem Befehl mcEndpoints holt, und dann fuer alle Kanaele mit mcCapability die Eigenschaften.
Falls eine mcCapability Nachricht eines unbekannten Kanals eintrifft, dann wird ein "global UNDEFINED" Event mit passenden Werten erzeugt, so dass autocreate das neue "Kanalgeraet" anlegen kann. Diese haben einen extra langen id, was GeraeteId plus Kanal kodiert. Befehle zu diesem Geraet erkennen anhand dieser langen id, dass sie den Befehl noch per MULTI_CHANNEL CMD_ENCAP einpacken muessen, auf diesem "Umschlag" steht neben ID auch noch KanalId.

CUL_HM kenne ich nicht mehr, das was ich weitergegeben habe, war noch 50k, der Code ist inzwischen auf 800k+ gewachsen.

[Beta-User]

Danke, ich glaube, das hilft zwar konkret nur bedingt weiter, aber einen wichtigen Gedanken habe ich glaube ich jetzt:

Für "Teilgeräte" sollte man schlicht eine erweiterte DEF nehmen, also den Kanal dazunehmen; das machen sowohl ZWave wie CUL_HM so. Sollte unproblematisch gehen, da der "Adressraum" in MySensors per Definition von 0-255 geht:

Ein MySensors-GW kann ein "Netz" von jeweils max. 255 Microcontrollern (Nodes) bedienen. Die erste Node (0) ist immer das GW selbst (da können aber auch Sensoren dran sein), 255 ist für broadcasts vorgesehen. Jeder Sensor hat in der Regel eine frei festlegbare ChildID (wieder 0-254). Eine Information aus dem MySensors-Netz ist also über diese beiden Datenpunkte bestimmbar, wobei auch mehrere Datentypen über dieselbe ChildID kommen können (ein DS18B20 kann also unter derselben Node/Child-Kombination sowohl seine ID wie die gemessene Temperatur liefern und FHEM/das Modul kann das unterscheiden).

Da der "Kanal" (die ChildID) frei belegbar ist, sind auch die Kombinationen recht frei, das macht es uU. kniffelig.

(Mehr als note an mich selber):
- DEF also erweiterbar machen auf "nnn_a x,y,z"? Das könnte bedeuten: Wir haben ein Subdevice zum Device "nnn" mit der Subdevice-ID "a", darin sind die ChildID's x,y und z gemappt; die erste Angabe (x) soll als state verwendet werden (genauer: das schaltbare Reading, das ggf. präsentiert wird).
- Klären, auf welcher Ebene die Trennung erfolgen soll (IO-Modul oder DEVICE-Modul)
-- IO-Modul: Prüfung müßte zweistufig sein, erst nachsehen, ob ein Subdevice exisitert, erst danach das Hauptdevice bedienen
-- DEVICE-Modul: Erstellung von Subdevices evtl. nur über ein Attribut?

- Schweirigkeiten:
-- Doppelte Datenhaltung; wie Readings etc. löschen im Hauptevice, wie ggf. Zustände konsistent halten?

[Beta-User]

@Rudi:

sieht so aus, als wäre auch on-for-timer&co wieder (?) an Bord, es gab da zusätzlich noch ein Attribut "setCommands", das bisher unter meinem Radar lag, was die Sache deutlich beschleunigt hat...

Wie dem auch sei, ein schaltbarer Kanal pro device direkt als "set device on" ist (mit on/off) realisierbar, und es scheint sogar so, als würde das mit dem Code aus https://forum.fhem.de/index.php/topic,95298.msg928274.html#msg928274 im großen und ganzen ganz ordentlich auch in den "state" geschrieben und angezeigt. Dabei wird der Schaltzustand jeweils aus $hash->{TIMED_OnOff}{CMD} geholt.

Bei on-till und off-till (und evtl. blink) scheint das mit der Auswertung für state nicht zu klappen, da die Internal-Struktur nicht angelegt wird, oder übersehe ich da was?

[rudolfkoenig]

Bei on-till und off-till (und evtl. blink) scheint das mit der Auswertung für state nicht zu klappen, da die Internal-Struktur nicht angelegt wird, oder übersehe ich da was?

Ich vermute, dass Du im state "on-till xxx" erwartest, das war aber mWn noch nie so, da steht nur on (bzw. off)
Wenn ich mich ver-raten habe, dann sag Bescheid.

[Beta-User]

Ich vermute, dass Du im state "on-till xxx" erwartest, das war aber mWn noch nie so, da steht nur on (bzw. off)
Wenn ich mich ver-raten habe, dann sag Bescheid.

Ganz von allein steht sogar überhaupt nichts im "state"-Reading, sogar das muß man als Modulautor selber machen, was aber ok ist .
Soweit erkennbar, ist die einzige Stelle, über die man am Gerät erkennen kann, dass die SetExtensions mitwirken, das zu sein, was im Internal "TIMED_OnOff" steht. Diese Angaben gibt es aber nur bei on/off-for-timer, nicht bei on-till, jedenfalls habe ich nichts im list gefunden. Das sieht z.B. bei aktivem off-for-timer auszugsweise so aus:

Code Auswählen Erweitern

Internals:
   DEF        98
   FUUID      5c432277-f33f-d171-d807-bdf65835c4d84345
   IODev      MySensorsRS485GW
   NAME       MYSENSOR_98
   NR         293
   STATE      alive
<br>Zwischenkeller:
2:off
1:off
<br>Gang:
4:off
<br>Heizraum:
3:off

   TYPE       MYSENSORS_DEVICE
   ack        0
   protocol   2.3.0-alpha
   radioId    98
   repeater   0
   timeoutAck 20
   timeoutAlive 700
   READINGS:
     2019-03-31 12:13:20   SKETCH_NAME     Zwischenkeller
     2019-03-31 12:13:20   SKETCH_VERSION  0.2
     2019-04-08 18:31:27   flow6           0.00
     2019-04-08 19:51:22   heartbeat       alive
     2019-03-31 12:13:20   parentId        0
     2019-04-08 19:52:01   state           off-for-timer
     2019-04-08 19:52:01   status1         off
     2019-04-08 19:52:11   temperature20   15.5
     2019-04-08 19:52:12   temperature21   11.6
     2019-04-08 19:52:12   temperature22   35.6
     2019-04-08 19:52:13   temperature23   32.1
     2019-04-08 19:52:13   temperature24   31.0
     2019-04-08 19:52:14   temperature25   33.6
     2019-04-08 19:52:14   temperature26   28.5
     2019-04-08 19:01:09   temperature27   35.8
     2019-04-08 17:39:25   temperature28   22.5
     2019-04-08 19:01:10   temperature29   34.6
     2019-04-08 19:01:11   temperature30   28.6
     2019-04-08 17:34:20   temperature31   22.4
     2019-04-08 18:22:06   tripped2        off
     2019-04-08 18:22:06   tripped3        off
     2019-04-08 18:22:07   tripped4        off
     2019-04-08 18:26:28   value16         168
     2019-04-08 18:26:28   volume6         1.680
   TIMED_OnOff:
     CMD        off-for-timer
     DURATION   100
     NEXTCMD    on
     START      1554745921
     START_FMT  2019-04-08 19:52:01
   gets:
   readingMappings:
     0:
       24:
         name       value1...

Was mich also eigentlich interessiert ist die Frage, ob man auch die anderen SetExtensions-Modi irgendwie ohne Klimmzüge rausbekommen kann.

[rudolfkoenig]

on-till/off-till definiert jeweils ein at.

[Beta-User]

on-till/off-till definiert jeweils ein at.

...hätte ich ja auch drauf kommen können...

Aber ganz allgemein: Das ist eventuell nicht wirklich stringent. Gibt es einen Eingriff von anderer Seite (automatisch oder nutzergesteuert), schlägt irgendwann der Timer zu (ist aber bei on-for-timer auch nicht anders). Gibt es da eine allgemeine Strategie, wie man als Modulautor damit umgeht? Soweit ich mich entsinne, stand da in der DevelopmentModuleIntro nirgends wesentlich mehr dazu, als der grobe Hinweis, wie man die SetExtensions überhaupt ans Laufen bekommt. Den am Modul sichtbaren Prozess kann ich ja irgendwie canceln, aber alle möglichen Stellen "abzuklappern", um alle Eventualitäten abzufrühstücken, ist doch etwas mühselig.

(Aber allgemein ist das v.a. hier nicht besonders wichtig, das sind jetzt eher noch Schönheitsfragen; aber sowas wird ggf. "interessant", wenn mehr Leute MQTT2 einsetzen und sich dann mit den Untiefen beschäftigen; es gab da neulich schon einen Thread, der das für FRM_OUT wissen wollte).

[rudolfkoenig]

Gibt es da eine allgemeine Strategie, wie man als Modulautor damit umgeht?

Wenn der Modulautor SetExtensions verwendet, dann sollte er bei on/off und anderen vergleichbaren Befehlen SetExtensionsCancel aufrufen, damit die Timer entfernt werden.

Jetzt wo ich das schreibe faellt mir ein: das muss ich noch in MQTT2_DEVICE einbauen
Habs gerade nachgeholt.

[Beta-User]

Thx, werde ich ebenfalls einbauen.

Es gibt da aber noch einen "blinden Fleck":
Schaltvorgänge , die lokal am Device ausgelöst werden (das betrifft sowohl MQTT2_DEVICE wie MYSENSORS_DEVICE). Da bekommen wir zwar jeweils eine Message, dass was geschaltet wurde, aber keine Ursache (also "nur" FHEM-seitig ausgelösten Befehl ausgeführt oder lokale Schaltung).

In MYSENSORS_DEVICE habe ich vermutlich die Chance, das zuzuordnen, weil ich bei Messages vom Device her sehe, ob es sich um eine Bestätigung (ACK) handelt, oder um was anderes; was anderes ist eigentlich immer ein lokaler Schaltvorgang (ich habe da einige Logiken auf den Arduinos am laufen, die ggf. nur an FHEM zurückmelden, was der Status ist; einfaches Beispiel: Bewegungsmelder mit angeschlossenem Licht, der nach definierter Zeit wieder ausschaltet).

Für MQTT2_DEVICE gibt es vermutlich nichts vergleichbares; man könnte höchstens noch was basteln auf Basis der Zeit zwischen Versenden der Nachricht und Reaktion.

[rudolfkoenig]

Schaltvorgänge , die lokal am Device ausgelöst werden (das betrifft sowohl MQTT2_DEVICE wie MYSENSORS_DEVICE). Da bekommen wir zwar jeweils eine Message, dass was geschaltet wurde, aber keine Ursache

Mir faellt z.Zt. nicht ein, warum man die Ursache braucht, aber fuer solche Faelle koennte man evtl. setStateList verwenden.

[Beta-User]

Mir faellt z.Zt. nicht ein, warum man die Ursache braucht, aber fuer solche Faelle koennte man evtl. setStateList verwenden.

Was ich eigentlich erreichen will, ist eine Anzeige im DeviceOverview, aus der ersichtlich ist, ob das Device "einfach an oder aus" ist, oder ob noch irgendein Timer (über die SetExtensions) dazu läuft. Dazu müßte man lokale Bedienungen am Gerät selbst erkennen können. Das mit setStateList klingt im Moment für mich einleuchtend, um dieses Ziel ggf. zu erreichen.

Im Prinzip ist es bei MQTT2_DEVICE so ähnlich wie bei MySensors im ACK-Pfad. Ist das ACK angefordert, wird der state in MySensors zunächst auf dem alten Stand gehalten und erst geändert, wenn die passende ACK-Message zurückkommt (in der pm ab Zeile 687, konkret: 699). Wäre vergleichbar mit dem setStateList.

Ich habe das bisher noch nicht intensivst getestet, aber für den ACK-Pfad scheint das jetzt so zu passen, weil wir da einen zeitlichen Verzug zwischen der SetExtensions-Anweisung und der Auswertung der Rückmeldung haben.

Was aber Probleme macht, sind Nodes ohne ACK-Anforderung (der Abschnitt in der Set-Funktion ab Zeile 303 bzw. 313). Das bekomme ich nicht für alle Fälle der SetExtensions sauber hin. Je nachdem, wie ich die Abfragen in 316/318 nacheinander anordne, stimmt der laufende oder der abschließende Status nicht. So herum ist es wenigstens für on-till am Ende ok und für die -for-timer Funktionen für den laufenden Timer. Aber ganz doof sieht toggle am Ende aus...

Im Prinzip hängt es daran, dass man nicht erkennen kann, ob die letzte Anweisung aus den SetExtensions vorliegt, oder ob noch was nachkommt.

Da das reichlich schwierig in Worten zu beschreiben ist, anbei neben der pm noch zwei RAW-Definitionen für ein GW und ein DEVICE; damit kann man auch ohne Hardware testen.

Code Auswählen Erweitern

defmod MyGateway MYSENSORS /dev/serial/by-id/usb-FTDI_MySensorsGW_74336002-if00-port0@115200 #/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@115200
attr MyGateway OTA_firmwareConfig MySensors_firmwares.csv
attr MyGateway autocreate 1
attr MyGateway group Interfaces
attr MyGateway icon cul
attr MyGateway room Unsorted
attr MyGateway stateFormat connection

setstate MyGateway disconnected
setstate MyGateway 2019-04-11 09:46:40 state disconnected

defmod MYSENSOR_98 MYSENSORS_DEVICE 98
attr MYSENSOR_98 IODev MyGateway
attr MYSENSOR_98 devStateIcon (set.)?on:on (set.)?off:off on.for.timer:on-for-timer off.for.timer:off-for-timer
attr MYSENSOR_98 icon lan_rs485
attr MYSENSOR_98 mapReading_power1 1 power
attr MYSENSOR_98 mapReading_status1 1 status
attr MYSENSOR_98 mode node
attr MYSENSOR_98 model A_24a_Relay_Actuator
attr MYSENSOR_98 room Unsorted
attr MYSENSOR_98 setCommands on:status1:on off:status1:off
attr MYSENSOR_98 setReading_status1 off,on
attr MYSENSOR_98 timeoutAck 20
attr MYSENSOR_98 timeoutAlive 700
attr MYSENSOR_98 webCmd :

setstate MYSENSOR_98 se_on
setstate MYSENSOR_98 2019-04-11 09:46:39 heartbeat alive
setstate MYSENSOR_98 2019-04-11 09:47:20 state on
setstate MYSENSOR_98 2019-04-11 09:47:20 status1 on


Vielleicht hast du ja eine Idee, wie man das besser machen kann; ansonsten ist es halt ein Schönheitsfehler, mit dem man leben muß oder ich deaktiviere das für den "ohne-ACK"-Zweig. Mal schauen.

[rudolfkoenig]

Was ich eigentlich erreichen will, ist eine Anzeige im DeviceOverview, aus der ersichtlich ist, ob das Device "einfach an oder aus" ist, oder ob noch irgendein Timer (über die SetExtensions) dazu läuft.

Ab sofort setzt setExtensions fuer die Dauer der Befehlsausfuehrung das SetExtensionsCommand Internal, was von dummy, ZWave und MQTT2_DEVICE auswertet wird, falls das setExtensionsEvent Attribut (jeweils pro Device) gesetzt ist.
D.h. in diesem Fall wird statt on das "urspruengliche" on-for-timer, etc als Event und Reading gesetzt.

Bin etwas unsicher, ob es in MQTT2_DEVICE mit setStateList zusammen gut funktioniert, vmtl. eher nicht, habe aber fuer diesen Fall noch keine gute Idee.
Und ich bin auch unsicher, ob das genau das ist, was Du wolltest, aber ich fand diesen Schritt (state/STATE entspricht auch mit SetExtensions dem, was man gesetzt hat) richtig

[Beta-User]

Und ich bin auch unsicher, ob das genau das ist, was Du wolltest, aber ich fand diesen Schritt (state/STATE entspricht auch mit SetExtensions dem, was man gesetzt hat) richtig

Es ist jedenfalls für MySensors sogar genauer, als das, was ich mal im Sinn hatte, und dazu sind die Eingriffe minimal, die noch erforderlich waren .

Vielen lieben Dank dafür!

Was mir noch nicht so klar ist: Sollte auch für MySensors das mit dem Attribut eingebaut werden?
Da es bisher dazu gar keine Rückmeldung nach state gab, gibt es auch keine (negativen) Überraschungen für die User, es kommt lediglich was dazu. Das scheint mir hier anders zu sein als bei den Modulen, die du jetzt geändert hast. Oder spricht was dafür (das ich noch nicht kenne oder übersehe), das auch hier per Attribut einschaltbar zu machen? (Bei der Gelegenheit: Eigentlich würde ich für das noch junge MQTT2 auch eher für eine "opt-out"-Lösung plädieren; die user müßten ggf. die Eventhandler mal durchsehen und komplexere devStateIcons festlegen).

Für MQTT2/setStateList schaue ich mir das bei Gelegenheit auch mal an, nur vom Lesen sehe ich das Problem noch nicht, allerdings immer noch das "andere": vermutlich geht state in dem Moment wieder auf "pure on" (usw.), wenn die Bestätigung vom Aktor kommt, dass geschaltet wurde. Das hätte aber m.E. nichts mit setStateList zu tun, sondern mit dem Zeitverzug. Vielleicht wäre es hier gut, noch einen kurzen Zeitpuffer einzubauen, der zwischen "set on-for..." und "on" (vom Aktor) liegen darf, in dem dann das "on" nicht als manuelle Schaltung bewertet wird, also der SE-Command erhalten bleibt. Muß aber erst testen, damit ich selbst da nicht nur theoretische Anmerkungen machen kann...

[rudolfkoenig]

Was mir noch nicht so klar ist: Sollte auch für MySensors das mit dem Attribut eingebaut werden?

Vermutlich ja, siehe 98_dummy.pm fuer Vorlage.

Eigentlich würde ich für das noch junge MQTT2 auch eher für eine "opt-out"-Lösung plädieren;

Ok, erinnere mich bitte in ein/zwei Wochen daran.
Da SetExtensions omnipresent ist, wuerde ich gerne eine Weile mit "opt-in" testen.

[Beta-User]

Vermutlich ja, siehe 98_dummy.pm fuer Vorlage.

Erforderlich ist es nicht, das wäre eher was im Sinne von Durchgängigkeit/Einheitlichkeit;
letztlich würde die durchgängige Verwendung bei allen Modulen den SetExtensions ggf. ermöglichen, selbst festzustellen, was gewünscht ist... (Grummel, ich spare ja gerne Attribute ein, wenn sie nicht erforderlich sind, aber dann mache ich das wohl als Präventiv-Maßnahme.)

Ok, erinnere mich bitte in ein/zwei Wochen daran.
Da SetExtensions omnipresent ist, wuerde ich gerne eine Weile mit "opt-in" testen.

Kann ich machen, wobei das mit der Omnipräsenz sicher ein wichtiges Argument ist und MQTT2_DEVICE zwischenzeitlich auch weit verbreitet, zumeist vermutlich auch als schaltbare Hardware. Ist also sicherer, das soherum zu machen. Und im Sinne der Einheitlichkeit ist es evtl. ganz gut, wenn das Attribut in Verwendung kommt.
Bliebe die Frage, ob ich das in die mqtt2.templates gleich reinpflegen soll? (geht sicher nicht auf einen Rutsch, da auch die devStateIcons anzupassen wären.)
Bei der Gelegenheit: Sollte man zigbee2mqtt_devStateIcon255() (in MQTT2_DEVICE) so anpassen, dass laufende Timer vorrangig berücksichtigt werden? Ich wäre dafür, das ist hier aber ein seltsamer Platz, das zu diskutieren. Wie wäre es mit optionalen Parametern? Einen zweiten für die Farbe (Verweis auf ein Farbreading, das RRGGBB sein muß), einen dritten für den SE-Status?

[rudolfkoenig]

Sollte man zigbee2mqtt_devStateIcon255() (in MQTT2_DEVICE) so anpassen, dass laufende Timer vorrangig berücksichtigt werden?

Kannst du das bitte so formulieren, dass ich das ohne durchlesen des Forums verstehen kann?
Ich ueberfliege zwar die MQTT-Beitraege, aber wenn ich keinen direkten Handlungsbedarf fuer mich sehe, dann verdraenge ich sie auch direkt

[Beta-User]

Gibt gar nichts, was man dazu bisher im Forum nachlesen könnte .

Mal der Versuch, das in Code zu fassen, ist vermutlich einfacher:

Code Auswählen Erweitern

sub
zigbee2mqtt_devStateIcon255($;$$)
{
  my ($name,$rgb,$se) = @_;
  return ".*:off:toggle" if(lc(ReadingsVal($name,"state","ON")) eq "off" );
  my $pct = ReadingsNum($name,"brightness","255");
  $rgb = ReadingsVal($name,$rgb,"000000");
  my $s = "on";
  if (defined $se && $se && ReadingsVal($name,"state","on") =~ m/(o.*-.*|blink)/s) {
    $s = ReadingsVal($name,"state","on") =~ m/on-.*/s ? "on-for-timer" : ReadingsVal($name,"state","on") =~ m/off-.*/s ? "off-for-timer" : "light_toggle";
  } elsif ($pct < 254) {
    $s = sprintf("dim%02d%%",int((1+int($pct/18))*6.25));
  }
  if ($rgb ne "000000") {
    $s .= "@#$rgb";
  }
  return ".*:$s:off";
}
Man kann damit (hoffentlich) optional
- ein beliebiges rgb-Reading benennen, '' ist möglich, dann bleibt die normale Hintergrundfarbe;
- einen (als boolschen Wert intendiertes) Flag setzen, um laufende Timer grafisch angezeigt zu bekommen. Hab's kurz angetestet, aber leider im Moment noch keine Hardware dahinter, um abschließend beurteilen zu können, ob das auch noch funktioniert, wenn der Aktor Vollzug meldet.

[justme1968]

@rudi:

ich glaube die änderung auf $hash bei InternalTimer durch version 19189 macht probleme.

- wenn ein modul selber ein RemoveInternalTimer auf sich selber macht verschwindet auch der SetExtension timer. das sollte nicht passieren. deshalb hatte der timer extra nicht $hash als parameter.

- die umstellung ist nicht vollständig: SetExtensionsCancel verwendet immer noch SE $name $cmd

kannst du das bitte wieder zurück bauen?

[rs]

...

das hat die Auswirkung, dass "on-for-timer" nicht mehr funktioniert; heisst, die Lampen schalten sich nicht mehr ab.
Bei mir gilt das für HUE Lampen.

/R

[rudolfkoenig]

ich glaube die änderung auf $hash bei InternalTimer durch version 19189 macht probleme.

Danke fuer den Hinweis, habs gefixt und (eingeschraenkt) getestet, Feedback ist willkommen.

[rs]

Ja,  bestätige, on-for-timer funktioniert wieder.

VIelen Dank
Roland

[rudolfkoenig]

Mal der Versuch, das in Code zu fassen, ist vermutlich einfacher:

Bin nicht sicher, ob das fuers Verstehen deiner Absicht auch gilt

Ich sehe, dass fuer on-*/off-*/blink eine Transformation durchgefuehrt wird (das schliesst on-till/off-till auch ein), verstehe aber noch nicht, warum man nicht einfach state uebernimmt.

Warum wird bei $rgb die Indirektion ueber ein Reading genommen?

[Beta-User]

So, nochmal eine grob angetestete Variante, die zumindest für die MiLight-Bulbs zu funktionieren scheint:

Code Auswählen Erweitern

sub milight_devStateIcon255($;$$) {
  my ($name,$rgb,$se) = @_;
  if(lc(ReadingsVal($name,"state","on")) eq "off"){
    return ".*:off:toggle" unless (defined $se && $se && defined $defs{$name}->{TIMED_OnOff}->{CMD});
  };
  my $pct = ReadingsNum($name,"brightness","255");
  $rgb = ReadingsVal($name,$rgb,"FFFFFF");
  my $s = "on";
  if (defined $se && $se && $defs{$name}->{TIMED_OnOff}->{CMD} =~ m/(o.*-.*|blink)/s) {
    $s = $defs{$name}->{TIMED_OnOff}->{CMD} =~ m/on-.*/s ? "on-for-timer" : $defs{$name}->{TIMED_OnOff}->{CMD} =~ m/off-.*/s ? "off-for-timer" : ReadingsVal($name,"state","on") =~ m/off-.*/s ? "off-for-timer" : "light_toggle";
  } elsif ($pct < 254) {
    $s = sprintf("dim%02d%%",int((1+int($pct/18))*6.25));
  }
  if ($rgb ne "FFFFFF") {
    $s .= "@#$rgb";
  }
  return ".*:$s:toggle";
}
state kann man aus zwei Gründen nicht wirklich verwenden: Zum einen wird state wieder überschrieben, wenn das Zieldevice jeweils Vollzug meldet (state kommt über den JSON als Rückmeldung zum setzen des status), zum anderen ist da das Brightness-Thema nicht berücksichtigt, es wird also bei "on" ein anderes Reading herangezogen (bzw. gleich zwei, wenn man die rgb-Variante will); letzteres war der Grund, warum es überhaupt die Ausgangsfunktion in MQTT2_DEVICE gibt.

Die Indirektion kommt daher, dass wir nur den Namen des Readings kennen (und flexibel an die Funktion übergeben können wollen), aber noch nicht den Inhalt (es mag verwirrend sein, dass der code aus dem Namen den Inhalt ableitet und intern dieselbe Variable nutzt, das könnte man auch anders lösen, aber da man den Ausgangswert nie mehr braucht, habe ich das einfach umetikettiert).

Für Verbesserungsvorschläge bin ich aber offen, will nicht behaupten, da Experte zu sein.

Anbei noch ein list -r von dem Device, mit dem ich getestet habe (leider ohne den MQTT-Verkehr):

Code Auswählen Erweitern

defmod Licht_Spuele MQTT2_DEVICE milight_0xBE59_3
attr Licht_Spuele IODev MQTT2_FHEM_Server
attr Licht_Spuele alias Spüle
attr Licht_Spuele devStateIcon {milight_devStateIcon255($name,'hex',1)}
attr Licht_Spuele eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
attr Licht_Spuele group Licht
attr Licht_Spuele icon light_control
attr Licht_Spuele model X_01_esp_milight_hub_rgbw_bulb
attr Licht_Spuele readingList milight/states/0xBE59/rgbw/3:.* { json2nameValue($EVENT) }\
   milight/states/0xBE59/rgbw/0:.* { json2nameValue($EVENT) }\
   milight/updates/0xBE59/rgbw/3:.* { json2nameValue($EVENT) }\
   milight/updates/0xBE59/rgbw/0:.* { json2nameValue($EVENT) }
attr Licht_Spuele room Esszimmer
attr Licht_Spuele setExtensionsEvent 1
attr Licht_Spuele setList on milight/0xBE59/rgbw/3 {"status":"ON"}\
   off milight/0xBE59/rgbw/3 {"status":"OFF"}\
   brightness:colorpicker,BRI,0,15,255 milight/0xBE59/rgbw/3 {"$EVTPART0":"$EVTPART1"}\
   hue:colorpicker,HUE,0,1,359 milight/0xBE59/rgbw/3 {"$EVTPART0":"$EVTPART1"}\
   command:uzsuSelectRadio,Weiss,Nacht milight/0xBE59/rgbw/3 {"$EVTPART0":"$EVTPART1"}
attr Licht_Spuele setStateList on off
attr Licht_Spuele userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
attr Licht_Spuele webCmd brightness:hue:command

setstate Licht_Spuele OFF
setstate Licht_Spuele 2019-04-24 20:10:30 brightness 112
setstate Licht_Spuele 2019-04-24 20:10:30 bulb_mode white
setstate Licht_Spuele 2019-04-12 19:44:01 button_id 0
setstate Licht_Spuele 2019-04-24 20:10:30 color_b 255
setstate Licht_Spuele 2019-04-24 20:10:30 color_g 255
setstate Licht_Spuele 2019-04-24 20:10:30 color_r 255
setstate Licht_Spuele 2019-04-18 06:42:07 command set_white
setstate Licht_Spuele 2019-04-24 20:10:30 hex FFFFFF
setstate Licht_Spuele 2019-04-24 20:10:30 hue 0
setstate Licht_Spuele 2019-04-18 07:20:57 myDimmDir 0
setstate Licht_Spuele 2019-04-18 07:25:40 myLastShort 2
setstate Licht_Spuele 2019-04-24 20:10:30 state OFF

[rudolfkoenig]

Ich habe die Funktion "umformatiert", und sie unter dem alten Namen als zigbee2mqtt_devStateIcon255 eingecheckt.

Da du mit Perl zunehmend mehr machst , hier ein paar nicht offensichtliche Punkte:
- auch wenn ein Test wie $defs{$name}->{TIMED_OnOff}->{CMD} fehlschlaegt, es werden alle Hashes bis auf dem Letzten angelegt, d.h. nach der Pruefung existiert $defs{$name}->{TIMED_OnOff}. Ist in FHEM ein sehr "beliebter" Weg Verwirrung zu stiften.
- die Pruefung auf $se impliziert defined($se)
- im Regexp ist .* am Ende ueberfluessig, wenn man kein $ spezifiziert.
- das s Modifier ist fuer Mehrzeiler relevant (siehe perldoc perlre), ich erwarte fuer state sowas nicht.
Die letzten Punkte machen mAn den Code kuerzer, und damit einfacher lesbar.

[Beta-User]

Danke für's Einchecken und (v.a. auch) die hilfreichen Hinweise!
Es ist für mich immer wieder erhellend, was rauskommt, wenn sich ein echter Experte so einer Sache annimmt .
Jetzt muß ich das "nur noch" entsprechend in MYSENSORS_DEVICE einbauen ...