[gelöst] Mysensors und setExtensions

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

Vorheriges Thema - Nächstes Thema

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

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):
Zitat
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.
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

ZitatVermutlich 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

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

Beta-User

Nochmal ein update dazu:

Ich kann zwar ein
Zitatset 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...
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

Zitatset 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].

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

#8
ZitatIst 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

Zitat von: rudolfkoenig am 26 März 2019, 10:09:40
Ist auch einer der Gruende, warum ich "Mehrkanalgeraete" meide, und lieber ein Geraet fuer jedes Kanal anlege.
;D .
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!)
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

ZitatWenn 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

Zitat von: rudolfkoenig am 26 März 2019, 11:29:34
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 :-\ .
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

ZitatHast 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?
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

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?
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