UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul

[klaus.schauer]

Sieht doch schon gut aus! Diverse Geräte im Subnetz werden gefunden. Die Fritz!Box mit mehreren Einträgen, da von dem Gerät mehrere unterschiedliche location-Einträge zu den und verschiedenen urn-Einträge publiziert werden. Vielleicht wäre es sinnvoll den $uniqueDeviceName zu normieren. Der wird derzeit mal mit "-" vorab sowie in HEX-Groß- und Kleinschreibung ausgeben

>> Fritz!Box sowohl als -E0286D46??? E0286D46???E)
>> weitere Geräte mit e0286d46d??? oder 7bc_25c8_48e3_9c??_1f147e0????3

Dann wäre des Ausgabe etwas übersichtlicher.

Der SMA Home Manager ist aus zwei Gründen nicht auffindbar. Ich wollte das Gerät erst beschaffen, wenn ich mir sicher bin, es auch zusammen mit Fhem einsetzen zu können. Zudem ist der Home Manager ein ControlPoint, der nach der urn:schema-simple-energy-management-protocol:device:Gateway:1 sucht. Fhem muss nicht als ControlPoint sondern als DeviceManager agieren.

[KölnSolar]

Der wird derzeit mal mit "-" vorab sowie in HEX-Groß- und Kleinschreibung ausgeben

Das ist ein Problem, das mir vorher nicht bewusst war. Eigentlich ist der ja viiiieeeel länger.Am Beispiel der Fritte

Code Auswählen Erweitern

AVM FRITZ!Mediaserver   uuid:fa095ecc-e13e-40e7-8e6c-bc0????604f6
FRITZ!Box Fon WLAN 7390 uuid:123402409-bccb-40e7-8e6c-BC0????04F6
FRITZ!Box Fon WLAN 7390 uuid:95802409-bccb-40e7-8e6c-BC0????604F6
FRITZ!Box Fon WLAN 7390 uuid:75802409-bccb-40e7-8e6c-BC0????604F6
Im DLNARenderer fiel das nicht auf. Da hat Dominik ja nur EIN "logisches" device benötigt u. die letzten 12 Stellen genommen. Ich probier es mal über IP:port aus der location. Die müsste ja  gut als Sortierkriterium der logischen devices eines physischen devices funktionieren. Ansonsten bleibt es halt unübersichtlich, aber es ist ja auch kein Modul, welches man sich täglich anguckt. 

Edit: puh, hab ich mich mit der Fritte gequält. Ich hab sie jetzt indiziert. Ist jetzt übersichtlicher und sortierter. Probier mal. Am besten

Code Auswählen Erweitern

reload 98_UPNPController
deletereading UPNP_Controller .*

Zudem ist der Home Manager ein ControlPoint, der nach der urn:schema-simple-energy-management-protocol:device:Gateway:1 sucht.

War mir gestern auch klar.

Fhem muss nicht als ControlPoint sondern als DeviceManager agieren.

Was soll denn der DeviceManager sein ? Das Gateway ?

Edit: Modulversion removed.

[klaus.schauer]

UDN:
Das ist das was das device "sagt". Aber interessant. Tritt nur bei QNAP auf. Ich spekulierte schon, dass das Perl-Paket den String "uuid:" fälschlicherweise hinzufügt. Aber am Beispiel des QNAP ist das widerlegt und scheinbar tatsächlich genau so im device abgelegt.

Wichtig wäre, die unterschiedlichen Rohdaten im Basismodul zu normalisieren. Sonst wäre das im Einzelfall in den nachgelagerten Modulen notwendig.

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. Wohl aber die uuid=universal_unique_identifier. Syntax: . Außerdem:UUID = 4 * <hexOctet> "-" 2 * <hexOctet> "-" 2 * <hexOctet> "-" 2 * <hexOctet> "-" 6 * <hexOctet>. Daran halten sich leider die Hersteller nicht.  Und deshalb sagt die Spec auch, dass ein Controller Fehler akzeptieren MUSS .

Ist ja grundsätzlich nicht schlimm, sofern des dennoch eindeutig bleibt.

Ja genau. Ich benutze IP:Port nur als Sortierkriterium und wegen der Übersichtlichkeit. Im hash ist dann die Übersetzung von readingsname zu UDN(uuid).

Da ein Gerät mehrere uuid: bekannt machen kann, wäre es wahrscheinlich sinnvoll für jede uuid ein nachgelagertes Device anzulegen.

Konntest Du nennenswertes blockierendes Verhalten feststellen ? Ich arbeite auf meinem Test-Rpi und der hat eh Netzwerkprobleme(Powerline), so dass ich blockierendes Verhalten nicht erkennen kann.

Mir ist auf den ersten Blick nichts aufgefallen. Müsste man aber wahrscheinlich genauer untersuchen.

Ich arbeite jetzt erst einmal an einem sauberen delete des devices. Das hat mich am DLNARenderer schon immer gestört.

Vermutlich ist es aber nicht klug, die nachgelagerten Devices einfach zu löschen, wenn die turnusmäßigen alive-Meldungen z. B. durch eine Netzwerkstörung ausbleiben. Dann wären ja auch die Konfigurationsdaten des Devices weg.

Schreib doch mal etwas mehr, was Du konkret bzgl. SMA vorhast. Mir ist immer noch nicht klar, für was Du FHEM dabei einsetzen willst(außer dass wir natürlich gerne alle devices u. deren Informationen in FHEM haben wollen ).

Der SMA Home Manager steuert u. a. Verbraucher. Über SEMP können Geräte nach bestimmten Kriterien geschaltet werden. Der SMA Home Manager fragt dazu von den Verbrauchern Daten ab wie max. und aktuelle Leistung, notwendige bzw. optionale Einschaltzeiten. Ein entsprechendes SEMP-Device in Fhem soll ganau dies ermöglichen und von einem beliebigen damit gekoppelten Device diese Daten abfragen und dieses dann schalten.

Der SMA Home Manager selbst ist ein ControlPoint, der nach entsprechenden DeviceManagern (Gateway) mit den urn:schema-simple-energy-management-protocol:device:Gateway:1 sucht und diese minütlich abfragt und Steuerbefehle sendet.

[klaus.schauer]

Der Name der Readings wird im LOG als fehlerhaft ausgewiesen:

2021.01.17 10:59:28 3: UPNP_Controller: bad reading name '192.168.6.131:2870_UDN' (allowed chars: A-Za-z/\d_\.-)

[gvzdus]

Hi Klaus, hi Markus,

gleich mal meine frisch gewonnenen Developer-Gruppenrechte ausnutzend: Wieso SEMP? SMA geht doch Richtung EEBUS weg von seinem proprietären SEMP. Leider fehlt mir wegen SolarEdge statt SMA ein EEBUS-Gerät zum Entwicklen und Testen.

[klaus.schauer]

Ich sehe im Augenblick nicht, wie es möglich wäre im EEBUS-Kontext beliebige Fhem-Devices zu monitoren und zu schalten.

[KölnSolar]

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[klaus.schauer]

Ich bin gespannt auf die weiteren Schritte und Ergebnisse zu den UPnP-ControlPoint-Funktionen. Mein vordringliches Interesse liegt in den DeviceManager-Funktionen, um entsprechende Gateway-Dienste aufzubauen. In der Hoffnung, dass auch dies zu einem späteren Zeitpunkt integriert werden wird, würde ich mich dann wieder einbringen.

[KölnSolar]

Aus Deiner Antwort lese ich Enttäuschung. Daher hab ich mir noch einmal Gedanken über Dein Ziel gemacht. Nun hab ich es auch endlich verstanden.
Du möchtest genau das Gegenteil des Controlpoints 
Das gibt es bisher noch gar nicht in FHEM. Ich denke auch nicht, dass es großen Bedarf gibt.  Da ich recht viel mit dem Perl-Paket gemacht hab und es ja "nur" das Gegenstück zum Controlpoint ist, unterstütze ich gerne. Der kleinste Aufwand ist sicherlich ein "Basismodul"(Ist ja nur 3.1 unter Berücksichtigung von 3.2 der SEMP-Specification). Weit mehr die Definition von device description, services....und der HTTP-Part.

Grüße Markus

[klaus.schauer]

Aus Deiner Antwort lese ich Enttäuschung. Daher hab ich mir noch einmal Gedanken über Dein Ziel gemacht. Nun hab ich es auch endlich verstanden.
Du möchtest genau das Gegenteil des Controlpoints 
Das gibt es bisher noch gar nicht in FHEM. Ich denke auch nicht, dass es großen Bedarf gibt.  Da ich recht viel mit dem Perl-Paket gemacht hab und es ja "nur" das Gegenstück zum Controlpoint ist, unterstütze ich gerne. Der kleinste Aufwand ist sicherlich ein "Basismodul"(Ist ja nur 3.1 unter Berücksichtigung von 3.2 der SEMP-Specification). Weit mehr die Definition von device description, services....und der HTTP-Part.

Nein enttäuscht bin ich nicht. Gut dass jetzt eine Funktionalität geschaffen wird, um SSDP gleichzeitig von mehreren Modulen nutzen zu können. Wenn dann nach den Controlpoint-Funkionen im zweiten Schritt auch Devicemanager-Dienste bereit stehen, sind wir doch auf dem richtigen Weg, danke dafür.

SEMP wird natürlich in einem nachgelagerten Modul implementiert werden. Ich bin mir im Augenblick nicht sicher, ob nicht auch die http-Kommunikation vom SSDP-Basispaket bedient wird bzw. sollte, Kap. 4 der SEMP-Spezifikation. In den Unterlagen zu dem UPnP-Modul http://perlupnp.sourceforge.net/ ist ja auch jeweils ein gerätespez. IP-Port zu definieren. Ich versehe das so, dass darüber nach der Registrierung die eigentliche Kommunikation zwischen Device und Controlpoint läuft und das UPnP-Modul den Port überwacht.

Wie die $address- und $message-Parameter in den X_Parse- und X_Write-Funktionen sowie das Matching des zweistufigen Modulmodells https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module konkret gestaltet werden, muss sicherlich noch diskutiert werden. Auch dazu bringe ich mich selbstverständlich ein.

[KölnSolar]

Ich versehe das so, dass darüber nach der Registrierung die eigentliche Kommunikation zwischen Device und Controlpoint läuft und das UPnP-Modul den Port überwacht

Nein. Das ist lediglich der Port von dem bzgl. UPNP gesendet(an SHM:1900) u. empfangen wird. In der NOTIFY message des devices(gateway) werden dem SHM server u. port des http-servers des devices für SEMP mitgeteilt. Könnte also sogar ein anderes physisches device sein.
Daher scheint mir das auch so easy bzgl UPnP.

jeweils ein gerätespez. IP-Port zu definieren

Ich denke, das Perl-Paket legt die Verbindung an u. das Modul holt sich den Port.

X_Parse- und X_Write-Funktionen sowie das Matching des zweistufigen Modulmodells

Da ja gar keine "echte" Kommunikation stattfindet, braucht es das glaub ich gar nicht.

Folgendes muss ablaufen:
- 3 NOTIFY-messages als "advertisement"(quasi "server hello") als multicast an 239.255.255.250:1900
  - rootdevice mit parameter: location, devicetype,urn
  - device UUID...
  - devicetype(service)...
- 3 NOTIFY-messages als "advertisement"(quasi "disconnect") als multicast an 239.255.255.250:1900
  (keine "neuen" Parameter nötig)
 
Die Parameter könnte man als "Schnittstelle" über Attribute definieren

Spannend wird es dann mit der "Forderung", dass auch auf Port 1900 gelauscht werden soll, für den Fall, dass der SHM connected NACHDEM das device sich zuvor connected hatte. Entweder haben wir nun einen Konflikt(Controlpoint lauscht bereits auf 1900), weil das DeviceManager-device auch port 1900 öffnen will oder das Paket ist so gebaut, dass der Controlpoint genutzt wird. Müsste man ausprobieren wie sich das beim DeviceManager verhält.
Bei letzterem Fall müsste der Controlpoint den search request an das device weiterreichen. Dieses sendet als Antwort die o.g. 3 notifys.

Anders als im 2-stufigen Modell, würde es genügen, dass das eigentliche(SEMP) device-Modul bei der Initialisierung per set-Befehl die notifys auslöst und sich per ReadingsVal die Daten abholt, die ja unveränderlich sind.

Das wars aus meiner Sicht. Attributsteuerung ?

Edit: Ich bin so weit. Nur leider wurde ich bestätigt: Es "krallt" sich den Port 1900. Gut, dann wieder schließen und UPNPControlpoint danach definieren. Aber dann gehen die requests vom SHM unter. Keine Idee wie ich das dem Controlpoint entlockt bekomme. Das Problem ist ja, dass das Lesen u. verarbeiten eingehender search-messages in der black-box upnp-Paket erfolgen.

[justme1968]

es gibt in fhem schon diverse module die ssdp/upnp verwenden. ich denke es wäre gut das ein mal zentral zu haben. ich hatte hier: https://forum.fhem.de/index.php/topic,67368.msg880001.html#msg880001 schon mal mit einer solchen idee angefangen. komme aber leider nicht zu mehr.

ich habe gerade hier: https://forum.fhem.de/index.php/topic,117961.msg1124953.html#msg1124953 auch noch etwas dazu geschrieben.

[KölnSolar]

Hi Andre,

komme aber leider nicht zu mehr.

Das merkt man leider. 

ich denke es wäre gut das ein mal zentral zu haben

Sehen wir ja auch so. Deshalb in Unkenntnis Deiner Vorarbeit der Versuch hier für ssdp/upnp.

mit einer solchen idee angefangen

Ich fand leider keinen Quellcode, den man weiter bearbeiten oder drauf aufsetzen könnte. 

Grüße Markus

[gvzdus]

Ich verfolge den Thread auch aus dem Augenwinkel.
Ich habe Deine Überlegung um "den Port belegen" nicht so ganz verstanden.

Bei ShellyMonitor verwende ich die IO::Socket::Multicast-Bibliothek. Den Socket öffne ich mit

$conn = IO::Socket::Multicast->new(LocalPort=>5683, ReuseAddr=>1) or $err = "Cannot open Multicast socket: $^E";

damit eben "auch andere" ihn belauschen können. Ist das eine Lösung für Dein Problem, oder habe ich da etwas nicht verstanden?

[KölnSolar]

Danke, könnte eine Möglichkeit sein. Ich bau die Verbindung aber nicht selber auf. Das passiert im Paket perlupnp und ich müsste es modifizieren. Ich gucke....