dann lösen wir uns mal wieder von dem SMA-Thema und kommen zum Kern zurück
Der Name der Readings wird im LOG als fehlerhaft ausgewiesen:
Ja, korrekt. Ich glaub die Doppelpunkte stören... Ändere ich erst einmal nicht, weil ich nicht den spontanen Gedanken habe, wie ich die "übliche" Darstellung von IP:Port zu FHEM-konformen readingnames vergewaltigen soll.
Wichtig wäre, die unterschiedlichen Rohdaten im Basismodul zu normalisieren.
Das sehe ich anders. Der "Fehler" liegt ja im device bzw. beim Hersteller. Bei unendlich vielen Fehlermöglichkeiten sehe ich da erst recht die Transparenz, dass das anders gehandhabt wird, im Vordergrund.
Sonst wäre das im Einzelfall in den nachgelagerten Modulen notwendig.
Jein. Ich sehe im nachgelagerten Modul gar keinen Bedarf etwas zu korrigieren. Es handelt sich ja um Schlüssel, die das device vorgibt. Die werden für die Kommunikation in FHEM benutzt. Für die Anwendung hat das gar keine Bedeutung.
UniqueDeviceName. Kommt als Methode mit dem Kürzel UDN aus dem Perl-Paket. Ist aber wohl kein offizieller Begriff und wird in der upnp-device-architecture nicht erwähnt.
Ich muss mich korrigieren. UDN wird auch in der UPNP-Spec genauso erwähnt.
Da ein Gerät mehrere uuid: bekannt machen kann, wäre es wahrscheinlich sinnvoll für jede uuid ein nachgelagertes Device anzulegen.
Hier scheiden sich die Geister, was das Modul überhaupt können/machen soll. Ich fasse mal aus meiner Sicht zusammen:
Basis: Perl-Paket UPNP::Controlpoint(modifizierte Version aus ..../FHEM/lib/UPNP/.....)
- zentraler UPNP-Controller in/für FHEM
- exclude/include UDN/IP (nutzerabhängiger Filter)
- alleinig auf Port 1900 lauschen--> per ReadFn zur Verarbeitung per handleOnce eingehende notify-messages verarbeiten(readings zum device anlegen;presence-status offline/online(Stecker ziehen bewirkt keine status-Änderung !!!))
- M-Search requests: bei define u. per set-Befehl mit separatem port(ermittelt über Controlpoint), Verarbeitung eingehender responses wie zuvor beschrieben
- subscription, subscription renewal, unsubscription, event-handling; über einen 3. port(ermittelt über Controlpoint)
- subscription individuell(per Anforderung durch ein UPNP-client-device oder manuell per set)
- unsubscription individuell(per Anforderung durch ein UPNP-client-device oder manuell per set)
- renewal der subscription automatisch
- "Dokumentation" des subscription-status über ein einzelnes service-reading mit den Zuständen:
- a) urn nach Ermittlung des services b) "subscribe" nach subscription c) nach subscription response: SID, timeout, property d) subscription/renewal failure e) "unsubscribe" nach unsubscription f) earlier subscribed service .... of device ....went offline
- Empfang von events eines physischen devices und Weiterleitung an das UPNP-client-device(vergleichbar 2-stufige Module)
- autocreate von UPNP-client-devices sehe ich im Augenblick nicht. Aktuell haben wir einerseits das SONOS-Modul, welches individuell für einen Hersteller/devicetyp zugeschnitten ist. Andererseits den DLNARenderer, der mit DLNA einen unabhängigen Standard unterstützt. Ich persönlich finde eine Übersicht ALLER devices informativ(möchte sie also eher gar nicht ausfiltern). Andererseits kann ich mir kaum vorstellen, dass es UPNP-client-Module zur FritzBox od. WindowsMediaplayer oder miniDLNA….. geben wird.
UPNP-client-Modul:
- definition(über IP:Port) nur möglich, wenn auch bereits im Controller-device vorhanden
- initiale subscription-Anforderung kommt aus dem Modul
- events(Status-Änderungen) kommen raw vom Controller-Modul; konkrete Verarbeitung erfolgt im client-Modul
- actions(Befehle an das physische device) werden in dem client-Modul detailliert definiert und über das Controllermodul(ohne dortige Prüfung der message) an das physische device gesendet
Insgesamt hätten wir dann 4+x devices(das eigentliche device + 3 socket-devices(eins je Port)+x client-devices)Die attachte Version kann nun die beschriebenen Basisfunktionen. für subscribe/unsubscribe muss man den readingnamen als Parameter in den set-Befehl kopieren(später dann als Liste zur Selektion vorgegeben).
Was natürlich noch nicht geht ist die Übertragung an/von client-FHEM-devices, weil es ja noch kein entsprechendes Modul gibt. Ich denke, dass sich der FHEM-Standard für 2-stufige Module anwenden lässt(habe ich zwar noch nie gemacht, aber der Theorie nach sollte es funktionieren). Meine nächste task ist dann, das DLNARenderer Modul für eine 2-Stufigkeit vorzubereiten, also alles was mit search, subscription zu tun hat generell rauszuschmeissen und zusätzlich die Schnittstelle zum UPNPController zu entwickeln.
Die derzeitige Version sollte vorerst nur in Testumgebungen eingesetzt werden. Nicht nur, weil es FHEM in die Knie zwingen könnte(bei mir läufts problemlos), sondern eher noch, weil es ja Wechselwirkungen zum DLNARenderer- u./o. SONOS-Modul geben könnte, da die ja heute auf port 1900 lauschen und sich um das UPNP-discovery,subscribing kümmern. Genau das soll das neue Modul dann später zentral machen.
Kommentare, Vorschläge, Ergänzungen zum Grundkonzept u. der Testversion wie immer willkommen.
Have fun
Markus
Edit: Vielleicht noch kurz für die, die an dieser Stelle erst hineinstolpern: Definition ganz simpel
define DeinUPNPController UPNPControllerdanach geht alles wie von selbst und über die Zeit sammeln sich die readings, so dass man dann erst einmal mit dem Verständnis der Vielzahl der devices beschäftigt ist.
Edit2: Testversion removed
