@wilm02:
Ich habe mir die "ino"-Datei (und das gesamte Repo) schon sehr genau angesehen ... und dabei auch festgestellt, daß Du für weite Teile der binären Pakete bei den Daten noch "unbekannte" Werte 1:1 verwendest (bis hin zum "ETag"-Header, der von AVM hoffentlich ignoriert wird - ansonsten sollte der bei unterschiedlichen Zielen bzw. "Inhalten" in der Antwort auch unterschiedliche Werte enthalten und die MAC-Adressen in den UUIDs sind ja schon mal "different").
Wenn Du nicht tatsächlich nur selbst analysieren (und meinetwegen "herumprobieren", was bei systematischem Vorgehen für mich absolut keinen negativen Touch hat) willst, solltest Du die von Dir getätigten Mitschnitte der Kommunikation auf Port 2002 irgendwo ablegen (ich nehme mal an, daß die MAC-Adressen darin die einzigen "individuellen" Daten sind und die gehen ohnehin nur bis zum nächsten L2-Knoten), weil vermutlich nur sehr wenige hier einen 546E haben werden.
Es ist/war - m.E. - nicht mal "allgemein bekannt", daß AVM bei diesem Gerät (und wenn ich das mit anderen Powerline-Adaptern vergleiche, wohl auch nur einmalig) die Schaltfunktionen mit eingebaut hat und so sehr verbreitet ist schon PLC an sich nicht, erst recht nicht mit AVM-Produkten, von denen dann auch nur ein einziges auf diesem Weg (über "echte" LAN-Kommunikation) in die AHA-Landschaft eingebunden wird (welches obendrein noch abgekündigt und (neu) nur noch schwer zu finden ist).
(Das erinnert mich fast an die Geschichte mit dem "Power"-Button bei der 3370, die wir hier letztens mal hatten - das war auch für die meisten der "alten Hasen" hier ziemlich überraschend, wenn mich mein Eindruck nicht täuschte.)
Das macht es dann entsprechend schwer, sich ein Bild von den verwendeten Datenformaten zu machen ... ich behaupte sogar mal, daß selbst viele "C-Versteher" an Deiner Implementierung von "append_var()" schier verzweifeln werden - die ist schon ziemlich schwer zu "durchschauen", inkl. der Kommentare mit den Hex-Dec-"Umrechnungen" bei deren Aufruf und dem "impliziten" Verbot, das für ein neues Paket zuerst mit einer 0 als drittem Parameter aufzurufen, weil ansonsten wild im Paket-Buffer herumgeschrieben wird, da "last" irgendwohin zeigt, wo es im vorhergehenden Paket zuletzt ein "echtes append" gab.
Die (binäre) Kommunikation würde ich auch - sogar für den eigenen Überblick, wenn ich an Deiner Stelle wäre - sauber dokumentieren (auch damit man sich das nicht erst aus dem Quelltext "herauskramen" muß) ... der SOAP-Teil beim UPnP ist "Standardkost" und größtenteils schon bei AVM selbst dokumentiert, inkl. der meisten Bits in der "functionbitmask":
https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/AHA-HTTP-Interface.pdf, die sich sicherlich zwischen "Client" (wo die FRITZ!Box der Server ist beim AHA - wie im dokumentierten "webservices/homeautoswitch.lua") und "Server" (das eigene Gerät als UPnP-Endpoint, denn wenn ich das richtig lese, wird die Verbindung zum Port 2002 ja von der Box aufgebaut) auch nur wenig unterscheiden werden.
Die UPnP-Templates für den 546E kann man sich (wenn man weiß, daß es die geben muß und es sich lohnt, danach zu suchen, dann findet man die auch) leicht aus der entpackten Firmware für den 546E holen ("aha-template.xml" für die SSDP-Response und "avm-ahaSCPD.xml" für den Endpoint) - hier wäre es ggf. nur interessant zu erfahren, ob AVM irgendwelche Pictures im GUI von der UUID für den Service (an den die MAC-Adresse angehangen wird) abhängig macht oder ob das erst später auf der Basis der Inhalte bei "Pakettyp 5" erfolgt.
Ebenfalls interessant (und wichtig) dürfte/könnte es sein, daß man (a) einerseits ziemlich eng am 546E bleibt und dabei aber auch (b) nicht zu eng, solange man andere Interfaces des 546E (bis hin zum X_AVM-DE_Homeauto-Service, der - nach Ansicht der Firmware für den 546E - auch implementiert sein müßte) nicht ebenfalls implementieren will. Oder bist Du Dir tatsächlich schon sicher, daß es (auch wenn man das GUI dann ausschweifend/in vollem Umfang nutzt) keine weitere Kommunikation jenseits von Port 2002 zwischen FRITZ!Box und "Aktor" mehr gibt und das alles nur noch über 2002 und mit diesem "speziellen" Format läuft?
Was passiert denn, wenn es mehr als eine FRITZ!Box (sowohl mit als auch ohne Mesh) im Netzwerk gibt? Wird der Aktor dann (bei AVM) irgendwie an eine einzelne "gebunden" (was bei den DECT-basierten ja implizit über den DECT-FP erfolgt, aber über SSDP im LAN können natürlich auch mehrere Boxen mit dem Aktor in Verhandlungen treten) oder kann tatsächlich jede der FRITZ!Boxen den Aktor komplett steuern? Letzteres würde ja implizieren, daß das in der FRITZ!Box selbst eher "stateless" hinterlegt ist und tatsächlich alle Daten "live" vom Aktor gelesen werden (und dann ggf. auch geschrieben, wenn es z.B. um zyklisches/automatisches Schalten und die "Planungen" dafür geht) - oder die Änderungen an der einen FRITZ!Box überschreiben die einer anderen einfach wieder.
Ein 546E sollte - ebenfalls wieder nach Ansicht der Firmware, also ohne eigenen Test, weil mir das Gerät dazu fehlt - ein komplettes FRITZ!OS am Laufen haben ... mithin auch eine eigene "Zeitrechnung" und damit auch in der Lage sein, unabhängig von der FRITZ!Box (bzw. irgendeiner FRITZ!Box) solche automatischen Schaltvorgänge auszuführen, solange diese erst einmal "programmiert" wurden. Daher würde auch eine Veröffentlichung von verschiedenen Mitschnitten (spez. bei Pakettyp 5) wohl nur dann etwas bringen, wenn man parallel dazu genau beschreibt, welche Einstellungen man eigentlich geändert hatte bzw. welche (unveränderten) Werte darin enthalten sein müßten.
Nach dem, was ich bisher in "wilm.ino" sehe, ist das bei der Konfiguration (eben mit diesem Pakettyp 5) noch eine Einbahnstraße ... hier meldet zwar der Aktor seine Werte an die FRITZ!Box, aber irgendwelche Einstellungen der Box für den Aktor (jenseits von "Ein/Aus" bei Pakettyp 7 mit Var-ID 15) sind noch nicht implementiert - und vielleicht auch noch nicht analysiert/bekannt.
Das macht es dann etwas schwierig, da irgendwie "mitzumachen" und so kann/müßte man sich nur auf "gute Ratschläge" (wie z.B. das Umschließen der "swapXX"-Makros mit passenden Statements für eine bedingte Übersetzung, damit die das bei einem Host (für die Simulation), der bereits seinerseits "big endian" für die "byte order" benutzt, nicht noch einmal "verdrehen") beschränken - ich zumindest gehöre jetzt nicht unbedingt zu der Zielgruppe, die da nur den Simulator benutzen wollte, um sich am Ein- und/oder Ausschalten einer LED zu erfreuen.
Daher auch meine Fragen, was da wie "zu sehen" ist im AVM-GUI ... ich würde das Reittier eben vom anderen Ende her aufzäumen und - solange die "AHA-Kompatibilität" nicht direkt in einem Tasmota-Image (meinetwegen anstelle von KNX o.ä., je nachdem, wieviel (kostbarer) Platz am Ende benötigt wird) verbaut ist, was sicherlich noch ein sehr weiter Weg sein dürfte - mich viel mehr dafür interessieren, wie AVM die Integration in den Rest der AHA-Landschaft betreibt und ob es da tatsächlich noch eine interne Schnittstelle gäbe, wo man sich einklinken kann.
Es spricht einiges dafür, daß es so etwas geben müßte ... das AHA-Zeug bei AVM (sowohl mit dem 546E als auch mit den ersten DECT-Steckdosen) ist ja auch älter als die HAN-FUN-Integration und wenn AVM da schon eine "Schnittstelle" hatte, dann war es bisher in der überwiegenden Zahl der Fälle so, daß AVM auch dabei geblieben ist und sich lieber immer wieder irgendwelche "Konnektoren" oder "Adapter" gebaut hat, mit denen andere/neue Techniken dann integriert werden können. Das würde/könnte auch erklären, wieso es bei neuen HAN-FUN-Komponenten immer so lange braucht, bis die (vollumfänglich) im FRITZ!OS unterstützt werden ... wenn AVM immer erst die passenden (Software-)"Adapter" implementieren muß, damit die mehr als "Basisfunktionen" eines HAN-FUN-Devices bieten, dauert das eben seine Zeit.
Bisher wurde das AHA-Interface vermutlich (für mich selbst kann ich das auch "definitiv" so sagen) immer als Einbahnstraße gesehen, über das man die AHA-Komponenten, die über eine FRITZ!Box verwaltet werden, entsprechend steuern kann (max. noch, daß sich zwei FRITZ!Boxen darüber "austauschen" hinsichtlich ihrer AHA-Komponenten, was mit "Smart-Home-Funktion im FRITZ!Box-Heimnetz freigeben" auch zugelassen sein muß).
Daß es hier auch eine Kommunikation in Gegenrichtung gibt und daß damit auch solche "Komponenten" darüber mit dem/einem AHA-"Host" kommunizieren, ist die (mind. für mich) neue Erkenntnis, die dank Deiner Mitschnitte erlangt wurde.
Nun stellt sich halt die Frage, was man damit/daraus machen will - einerseits wird es wohl keine automatischen Schaltvorgänge bzw. deren Programmierung über die FRITZ!Box geben, wenn man das als "einfache Steckdose" (oder auch als einfachen Schalter/Taster - die Temperatur-Messungen interessieren mich z.B. überhaupt nicht, weil auch die allermeisten Devices, wo man Tasmota installieren kann, gar keinen passenden Sensor haben) implementieren will und andererseits muß man vermutlich auch aufpassen, daß man kein Gerät "emuliert", was deutlich mehr Fähigkeiten besitzt als diejenigen, auf denen man diese Funktionen für das AHA nachbilden will.
Das geht schon dabei los, daß so manches ESP8266-basierte Device (als "WLAN-Steckdose") zwar über Taster und Relais verfügt und damit einfache Schaltvorgänge sowohl lokal als auch remote ausführen kann, aber schon bei der Verbrauchsmessung gibt es deutliche Unterschiede und das geht erst so richtig los, wenn da noch unterschiedliche Multiplikatoren/Teilerverhältnisse für solche Werte verwendet werden. Wobei bei der Verwendung von Tasmota ja sogar die Programmierung von automatischen Schaltvorgängen (für Steckdosen) drin wäre - was AVM ja auch für die FRITZ!DECT 2x0 (und den 546E) unterstützt.
Das ist natürlich alles "Zukunftsmusik" ... aber vermutlich wird es auch erst dann eine breitere Verwendung finden (können), wenn damit tatsächlich existierende (WLAN-)Steckdosen (für andere Kommunikation als Ethernet/WiFi oder DECT-ULE fehlt der FRITZ!Box ja auch der passende Adapter) einfach anstelle von Tasmota o.ä. geflasht werden können - wobei ich tatsächlich die Möglichkeit, dabei mit einem einfachen ESP8266 eigene Taster zu bauen, die nicht um die 30 EUR kosten (wie die FRITZ!DECT 400-Teile) und mich nicht in den "DECT-ULE-Lock-In" zwingen, viel spannender finde (weil mir da die "Preisdifferenz" zu den AVM-Devices noch viel größer erscheint, als bei den Steckdosen).
