[Info] Wilm - selbstprogrammierter Fritz-Aktuator

wilm02

Neuer User
Mitglied seit
25 Okt 2020
Beiträge
21
Punkte für Reaktionen
12
Punkte
3
Ich habe begonnen eine kleine Software zu erstellen, die ich hier kurz vorstellen möchte. In Anlehnung an Fritz habe ich sie "Wilm" getauft. Ein aktueller Stand ist unter https://github.com/wilm02/wilm zu finden.

@admin Auch wenn die hier vorgestellte Software nichts mit DECT zu tun hat, passt sie doch meiner Meinung nach inhaltlich in dieses Unterforum. (Danke an NDiIPP)

Hier eine Kurzbeschreibung:
Wilm ist eine Aktuator-Software für einen ESP8266, der in einem Fritz-Netzwerk als kompatibler SmartHome-Schalter dargestellt wird und analog zu DECT 200/210 oder Powerline 546E verwendet werden kann. Die LED des Microcontrollers kann genauso wie andere Fritz-Aktuatoren geschaltet werden. Wilm ist zwar für einen ESP8266 geschrieben, darüber hinaus läuft Wilm aber auch komplett ohne eigene Hardware in der ESP8266-Simulation unter Linux.

Auch wenn heute (Sommer 2020) SmartHome der Fritzboxen komplett auf DECT aufsetzt, ist auch ohne DECT-Hardware nur über LAN ein SmartHome-Schalter auf einer Fritzbox möglich. Der mittlerweile abgekündigte, schaltbare Fritz-Powerline 546E ist ein Beispiel dafür. Vor einiger Zeit habe ich den Datenverkehr eines 546E zur Fritzbox näher analysiert, ihn auf das unbedingt Notwendige beschränkt und danach auf einem ESP8266 nachprogrammiert:
  1. Die Fritzbox sendet regelmäßig einen Multicast auf Port 1900 mit der Kennung "device:avm-aha", den der SmartHome-Schalter einmalig mit seiner IP-Adresse beantwortet.
  2. Die Fritzbox erfragt danach von dieser IP-Adresse zwei xml-Konfigurations-Dateien über Port 49000.
  3. Schließlich öffnet die Fritzbox den Port 2002, über den dann die gesamte weitere (binäre) Kommunikation mit dem SmartHome-Schalter läuft.
  4. In der SmartHome-Übersicht der Fritzbox wird automatisch ein neuer Schalter ergänzt.
Wer diese Kommunikation mit Wireshark nachvollziehen möchte, kann NICHT die Fritzbox selber nutzen, da das Fritz-OS offensichtlich ausgehende Pakete über Port 2002 NICHT mitprotokolliert! "Natürlich" gibt es keine Doku zu der binären Schnittstelle und immer wieder traf ich auf unerwartete Schwierigkeiten. Inzwischen läuft der Wilm-Aktuator bei mir aber stabil mehrere Tage durch.

Die Onboard-LED des ESP8266 kann mit der Onboard-Taste und allen anderen "üblichen" Bedienelementen der Fritz-Umgebung geschaltet werden: Web-Gui, Android-App, Fritz-Fon... Zusätzlich gibt es noch ein kleinen Webserver auf dem ESP8266 selber. Verbrauchs- oder Spannungs-Statistiken werden bisher nicht unterstützt, genau wie ein Temperatursensor, der an der Powerline 546E leider fehlt und (noch) nicht nachvollzogen werden kann.

Ich hatte angefangen mit der Arduino-IDE unter Windows zu programmieren. Inzwischen nutze ich ausschließlich den Linux-Zweig, der in der IDE unter "zusätzliche Boardverwalter-URLs" heruntergeladen wird, verbunden mit einem Makefile. In diesem Zweig enthalten ist eine Tests-Host-Umgebung für Linux, die ich ausgiebig nutze. Damit laufen die identischen Quellen sowohl direkt auf dem ESP8266 als auch in Simulation unter Linux! Kleine Patches für die unvollständige Tests-Host-Umgebung liefere ich hier mit. Meine gesamte aktuelle Installation kann bei Bedarf mit install/install.sh nachvollzogen werden und ist unter doku/install.txt etwas erklärt.

Nebenbei ist eine Simulation (test/fbsim) entstanden, die rudimentär die SmartHome-Kommunikation der Fritzbox mit Wilm nachstellt.

Momentan sehe ich das Projekt noch als Proof-of-Concept. Eine Ergänzung um weiter nutzbare Functionbits ist derzeit das vorrangige Ziel. Stand heute kann ein Taster eingelesen und eine LED/Relais geschaltet werden. Eine Temperaturmessung ist in Arbeit... Die Bedienung erfolgt - wie gesagt - völlig analog zu bisherigen Fritz-Aktuatoren und Fritz-Sensoren. Da alles out-of-the-box funktioniert, sind auch Gruppenbefehle und eine Steuerung über das AHA-HTTP-Interface möglich.

Die aktuelle Version auf github läuft bei mir seit 10 Tagen im Alltagsbetrieb störungsfrei durch. Über eine Strecke von 10m durch zwei Hauswände wird damit täglich eine Katzenklappe gesteuert.

Wenn jemandem im Code die Katzenklappensteuerung stört, müssen nur die mit Catflap gekennzeichneten Stellen auskommentiert werden. Je nach Bedarf kann man dort natürlich etwas anderes eintragen.
 
Wie sieht denn die (Detail-)Seite für so ein emuliertes (FRITZ!something-)Gerät unter "Smart Home" aus?
 
Meinst Du diese Seiten?
1)
1603833163726.png
1603833263864.png
2)
1603833194660.png
[Edit Novize: Riesenbilder gemäß der Forumsregeln auf Vorschau verkleinert]
 
Zuletzt bearbeitet von einem Moderator:
Wie sieht denn die (Detail-)Seite für so ein emuliertes (FRITZ!something-)Gerät unter "Smart Home" aus?

Zum Verständnis:

In einer internen Vorgängerversion von wilm hätte die Seite bei dir exakt genauso ausgesehen, wie wenn mein 546E in deinem Fritznetzwerk gesteckt hätte. Ich versuche ja 1:1 den relevanten SmartHome-betreffenden Datenverkehr nachzubilden. Dass der dann statt über LAN über WLAN und auf einer anderen Hardware läuft, ist der Fritzbox offensichtlich egal.
Nach und nach habe ich dann in dem binären Wald-und-Wiesen-Muster Strukturen nachvollzogen. Einzelne Pakete bildeten sich heraus. Nachdem die Struktur einigermaßen klar war, ging es um den Inhalt. Mit kleinen Änderungen kann ich inzwischen den Gerätenamen, die AIN und die Firmware-Version nach Belieben ändern. Viele Informationen zum Datenaustausch sind offensichtlich, einige jedoch nicht... Hier ist Intuition und Ausdauer gefragt.
So kann ich einer noch internen neuesten Testversion von wilm zwar schon Temperaturen ausgeben, die Statistikanzeige für die Temperaturen bleibt mir jedoch ein völliges Rätsel...

Wer nur einmal mit wilm experimentieren möchte, wen aber dabei der ständige Wechsel zwischen Cross-Entwicklungsumgebung und Ziel-Hardware stört, der kann die offenbar wenig genutzte Host-Test-Umgebung der Arduino-IDE nutzen. Damit kann der wilm-Sketch im Originalzustand auch direkt unter Linux laufen! Ich habe die Host-Test-Umgebung für meine Belange minimal erweitert. So brauche ich nur für einen finalen Test einen Upload auf die ESP-Hardware zu machen, kann aber für alle Tests unter Linux bleiben. Die Skripte make_sim.sh und run_sim.sh werden benötigt.
 
  • Like
Reaktionen: HarryHase
Ist es möglich einen Arduino Mega 2560 mit Ethernet-Shield zu verwenden oder ist da der Speicher zu klein?
 
Wie man im Sketch sieht ist das jetzt der "Geradeausfall" daher auch hart coded WiFi Credential und einiges mehr. Den Hüttenzauber drumherum ist zwar nur Fleißarbeit, da es hunderte Beispiele gibt, aber in dieser frühen Phase schwierig. Dazu zählen auch die Anpassungen für ethernet. Ich habe auch schon esp32-Eth devices hier, sogar mit Relais drauf.
Wir sollten aber erst mal so viel wie möglich über die Kommunikation inkl. Parameter herausbekommen und dann die entsprechenden Plattformen austesten.

@wilm02 : hier schon mal geschaut? https://github.com/mperlet/PyDect200/tree/master/PyDect200
 
  • Like
Reaktionen: wutz65
@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).
 
Zuletzt bearbeitet:
BTW:
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 [...]
Ich hätte diese generelle "Unkenntnis" bzgl. des 546E eigentlich nicht vermutet (im Gegensatz zum Power-Button der 3370 ;)). Es gab hier im Forum imo auch schon ein paar Themen, die sich mit den "Smarthome-Funktionen" des 546E befasst hatten. Hatte wegen diesem Feature des 546E vor ein paar Jahren auch schon einmal über den Erwerb nachgedacht (wo ich dann aber die PLC-Fähigkeit nicht genutzt hätte). Aber zum Glück kamen dann die ESP8266 basierten Stecker (auf die Du mich u.a. aufmerksam gemacht hattest, denn das war mir wiederum nicht wirklich bekannt), weshalb ich dann vom 546E wieder abgesehen hatte. Es gab hier im Forum bspw. auch schon eine entsprechende Nachfrage nach einem Nachfolger des 546E:
 
Wie geschrieben ... speziell für mich war das tatsächlich "neu". Nun bin ich aber ohnehin nicht der Fan des ganzen AVM-Zubehörs und habe ja auch schon heftig dagegen argumentiert - erst recht zu einer Zeit, wo es die HAN-FUN-Unterstützung noch nicht gab und jede weitere FRITZ!DECT-Steckdose die Nutzer tiefer in die Abhängigkeit von AVM trieb, wie es bei den FRITZ!Fon-Geräten (die auch ohne Box nicht nutzbar sind) auch schon der Fall war/ist. Daher habe ich bisher tatsächlich nur 2x selbst zu einem FRITZ!Fon gegriffen (zuerst zu einem MT-F, was dann leider kaputt ging und auch durch die Gehäuse-Spende hier im Board nicht mehr gerettet werden konnte und durch ein C5 ersetzt wurde) und einmal zu einer FRITZ!DECT 210 - das Ganze aber auch nur deshalb, weil ich diesen Teil der Firmware auch mal auf Schwachstellen abklopfen wollte/will und das nur aktiviert wird, wenn auch die passenden Geräte vorhanden sind.

Ansonsten liegt das - wie auch "Mesh" - einigermaßen jenseits meiner Interessen und so mag es tatsächlich sein, daß ich einer der wenigen "Unaufgeklärten" hier bin, was die Schaltmöglichkeiten mit dem 546E angeht ... und erst recht die Tatsache, daß der diese Fähigkeiten nicht nur lokal bereithält und sie dann über die oben schon erwähnte "SmartHome-Freigabe" (im FRITZ!OS auf dem 546E) anderen FRITZ!Boxen zugänglich macht (und wo diese dann selbst über die X_AVM-DE_Homeauto-Schnittstelle auf den 546E zugreifen), sondern von diesen (zusätzlich?) noch über eine direkte TCP-Verbindung gesteuert werden kann/muß.

Daher kriegte ich auch wieder gleich ganz große Ohren (oder waren's die Augen?), als ich davon las, daß durch irgendwelche Änderungen an den binären Paketen, die auf Port 2002 ausgetauscht werden, das FRITZ!OS abgeschossen werden konnte - DAS finde ich sogar noch interessanter als die UPnP-Kommunikation zwischen 546E und FRITZ!OS, weil jede dieser Möglichkeiten natürlich auch wieder ein Einfallstor für einen (erzwungenen) Restart ist, der bei (un)passendem Bootloader zur Übernahme der gesamten Box führen kann.

Ich habe mich mal etwas umgesehen, wo man so einen 546E noch kriegt bzw. was der dann kosten würde (die PLC-Funktionen kann/will ich natürlich auch nicht nutzen, ich habe extra Kabel in die obere Etage gelegt, damit das nicht erforderlich ist) - mal sehen, wie sich die Preise in der Bucht so entwickeln. Nur zur (eigenen) Erkundung der Kommunikation zwischen Host und Aktor will ich - auch wegen der "Grundsatzkritik" an diesem AVM-Lock-In, den man mit dem Kauf dieser Gerätschaften Vorschub leistet - jetzt aber auch keine 100 EUR für einen neuen 546E auf den Tisch legen - zumal ich weiterhin eher die Nutzung eines Proxys, der zwischen Tasmota-HTTP-Kommandos/-Abfragen und AHA "vermittelt", präferieren würde, weil MQTT/openHAB/Node-Red schon weiterhin bzw. parallel zum AHA möglich sein sollten und man erst mal abwarten muß, wieviel Platz in einem (Tasmota-)Image für den ESP8266 so ein zusätzlicher AHA-Support jetzt einnehmen würde und was dafür am Ende weichen muß.

Ich hatte ja (an anderer Stelle) schon mal erwähnt, daß ich bereits an die Stelle der direkten Tasmota-Kommandos über das "Live-Bild" einen Proxy gesetzt hatte, der - in Abhängigkeit vom (finalen) Zustand nach einem "toggle"-Kommando - auch die passenden Icons als Media-File bereitstellte und damit "etwas mehr Komfort" in diese Aufrufe der URLs gebracht hat.

Wenn ich das jetzt so "ummodeln" kann, daß dieser Proxy die (meist SP111-)Steckdosen direkt in das FRITZ!OS-GUI integriert und sie damit als "FRITZ!Aktoren" auch wieder über ein Telefon und/oder die AHA-Schnittstelle/eine MyFRITZ!-App ansprechbar sind, dann ist mir (bzw. den Leuten, für die ich das gemacht habe, denn ich selbst habe ja nur die eine Steckdose und das eine Telefon für Testzwecke) erst einmal deutlich mehr geholfen, als wenn da erst noch ein anderes Image auf die Steckdosen geflasht werden muß (auch wenn das i.d.R. OTA klappt, solange da schon ein passendes Tasmota läuft).
 
Ich hatte mal ein paar 546e. Die sind ganz nett da mal lan+wlan+powerline+messen+schalten in 1 Gerät hat. Scheinbar war aber alles in einem zu kleinen Gehäuse verbaut und die Dinger sind mir regelmässig abgefackelt, obwohl kein PLC aktiv war. Das war noch vor FOS 7, und da war das SmartHome Zeug noch ein richtiges mesh, dh jeder Fritzbox zeigte alle AHA Geräte im Netzwerk an und konnte alle konfigurieren. Auffällig am 546e ist dass diese im Gegensatz zu den Dect Geräten eine MAC statt AIN haben.
In RRDstats gibt es ein Script zum bedienen von AHA, ich nutze das für beliebig viele Schaltzeitpunkte+Werte via cron. In Freetz-NG gibt es auch Patches um nicht-öffentlich Werte wie Powerfactor etc auszulesen, was auch mit RRDstats geloggt werden kann https://freetz-ng.github.io/freetz-ng/make/rrdstats.html#smarthome
 
@PeterPawn @wilm02 : Zu einem Proxy zwischen tasmota und Fritzbox:
Wenn ich das richtig verstehe müsste doch mit dem codeschnipsel von wilm02 die Kommunikationsseite zur Fritzbox schon möglich sein, da fehlt dann noch der mqtt-part auf der anderen Seite und natürlich die Verwaltung, was soll von wo nach wo gemappt werden. Vermutlich wäre das auch der einfachere Weg als das Ganze in Tasmota oder espeasy zu integrieren. Könnte dann auf eine raspberry mitlaufen?!
 
Wegen der umständlicheren Modifikation?! Von dem Thema alles auf der Fritz mitlaufen zu lassen habe ich mich schon vor Jahren verabschiedet. Ein Raspberry ist viel schneller aufgesetzt, rebootet und auch ersetzt als die fritzbox, die ja meist eine primäre andere Aufgabe hat. Aber ja das wäre natürlich auch eine Lösung!
 
Ein Problem gibt es, wenn man das auf der Box laufen lassen will. Der "aha" von AVM setzt selbst ein (TCP-)"listen()" auf Port 2002 ab und das auch noch auf eine "unspecified address" - zumindest dann, wenn da mind. ein Aktor gefunden wird (bei mir ist es die DECT 210). Ohne passende Geräte, faßt der "aha" den Port wohl auch nicht an ... in einer 113.07.21 ist da jedenfalls (ohne angemeldete 210) mit "netstat -anp" nichts zu sehen.

Das heißt dann, daß man da nicht ohne weiteres einen anderen Prozess (den Proxy) ebenso aufsetzen kann. Man müßte vermutlich eine neue Bridge hinzufügen (die über "dev lan" auch erreichbar ist, wobei es fast so aussieht, als würde das "listen()" des "aha" auch im Gastnetz aktiv sein) und dieser Bridge dann irgendein virtuelles Interface hinzufügen (z.B. ein TUN-Device), auf dem man dann pro emuliertem Device eine neue IP-Adresse verwendet.

Genau deshalb wäre ich ja erst einmal auf der Suche danach, ob es irgendwo eine interne Schnittstelle gibt, über die DECT (für die HAN-FUN- bzw. ULE-Komponenten) und der "aha" miteinander kommunizieren, damit man das nicht zwangsläufig über TCP abwickeln muß (sondern u.U. über irgendeinen UNIX-Socket o.ä.).

Gibt es das nicht, ist es tatsächlich wieder einfacher, das auf einem externen Device zu machen - wobei auch da die nächste Frage wäre, wieviele solcher "Steckdosen" gleichzeitig (als Sub-Devices) von einem AHA-"Client" angeboten werden können - bisher gibt es m.W. bei AVM ja noch keine Mehrfachsteckdosen.

Ohne eine solche Funktion, müßte sicherlich auch der Proxy nach dem Prinzip "Eine IP-Adresse für eine (AHA-)Steckdose." verfahren, schon damit der AHA-Host dann auf dieser Adresse am Port 2002 mit ihm Kontakt aufnehmen kann.

Hat man erst mal einen passenden Proxy, ist der Aufwand zum Modifizieren des FRITZ!OS wie immer halt Ansichtssache. Wobei das dann auch wieder von der Anzahl der existierenden FRITZ!Boxen und vom Verhalten des AHA-Clients beim Vorhandensein von mehr als einer Box abhängig ist ... es wäre sicherlich Unsinn (bzw. fast unmachbar), sich für den Proxy da auch noch auf UDP 1900 zu klemmen, damit die anderen Boxen den Proxy auch per SSDP-Broadcast finden und verwenden können. Verwendet man hier ein externes Gerät, ist das wieder kein Problem ... zumindest nicht im Rahmen der Freiheiten, die einem die AHA-Implementierung läßt (Fragen dazu hatte ich weiter oben ja schon aufgeworfen), wenn es um das Verhalten mit mehr als einem "AHA-Host" geht.
 
Bist du so gut im Fotoeditor?
Oder woher hast du das?
 
@eisbaerin
Na die Schnittkanten sieht man doch! Wenn man gut mit einer Bildbearbeitung umgehen kann bzw. sich die Zeit nehmen würde (wäre hier imo für diesen Zweck etwas übertrieben), würde man die nicht mehr sehen. ;)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.