[gelöst] Mysensors und setExtensions

Begonnen von Beta-User, 09 Januar 2019, 07:46:50

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatBei 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

Zitat von: rudolfkoenig am 08 April 2019, 18:36:02
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:

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig


Beta-User

Zitat von: rudolfkoenig am 08 April 2019, 21:07:25
on-till/off-till definiert jeweils ein at.
...hätte ich ja auch drauf kommen können... ;D

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatGibt 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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatSchaltvorgä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

#22
Zitat von: rudolfkoenig am 10 April 2019, 22:49:31Mir 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.

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatWas 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

Zitat von: rudolfkoenig am 15 April 2019, 12:58:10
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatWas 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.


ZitatEigentlich 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

Zitat von: rudolfkoenig am 15 April 2019, 15:17:35
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.)

ZitatOk, 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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatSollte 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: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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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?

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968