FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: klaus.schauer am 23 September 2020, 20:19:55

Titel: UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 23 September 2020, 20:19:55
Für die Implementierung einer neuen Gateway-Funktion fragt die Gegenstelle Gateway-Parameter und Gateway-Status per Simple Service Discovery Protocol (SSDP) ab. Ist UPnP in Fhem bereits als Routine verfügbar oder wie könnte der Dienst bereitgestellt werden?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: amenomade am 24 September 2020, 14:32:21
Ich glaube, das SONOS Modul implementiert UPnP. Aber wahrscheinlich nur zum Zweck des Moduls.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: KölnSolar am 24 September 2020, 15:30:03
im DLNARenderer ist UPnP implementiert.

Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: klaus.schauer am 24 September 2020, 19:49:37
DLNARenderer ist, soweit ich das bisher verstehe, ein SSDP-Client, der auf Meldungen eines SSDP-Dienstes (controlled device) hört. Benötigt wird aber die Funktion eines controlled devices, der Advertisement-Meldungen (Notify M-Search) sendet.   
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: klaus.schauer am 10 Januar 2021, 12:36:31
Soweit ich das sehe, verwenden das Modul 00_SONOS und 98_DLNARenderer das Perl Paket UPnP http://perlupnp.sourceforge.net/ als Basis. Die Teilpakete Common.pm und ControlPoint.pm sind leicht modifiziert in /FHEM/lib/UPnP abgelegt. Da ich UPnP Devicemanager-Funktionen suche, wäre eine Erweiterung um das Modul DeviceManger.pm aus diesem Paket ein möglicher Weg.

Ich frage mich allerdings, ob es sinnvoll ist, nur für mein Vorhaben wieder eine spezielle Lösung zu bauen. Kommen sich die Module nicht in die Quere, wenn man in Fhem mehrere UPnP-Devices über die Module 00_SONOS und 98_DLNARenderer und ggf. ein weiteres parallel betreibt. Schließlich müssen alle Pakete den SSDP-Verkehr über den IP-Port 1900 monitoren bzw. darüber senden. Wäre es deshalb nicht notwendig, diese Kommunikation in ein zentrales SSDP/UPnP-Modul zu kapseln oder sogar in den zentralen Fhem-Loop einzubauen und über DevIO-Funktionen zugänglich zu machen?

Weiterhin war ich überrascht, dass die Module 00_SONOS und 98_DLNARenderer die Logik für die ControlPoint sockets in eigene select-loops legen, die dann als Coprozesse laufen, siehe z. B. Fragestellung zur Optimierung in https://forum.fhem.de/index.php/topic,117623.0.html. Im Perl Paket UPnP http://perlupnp.sourceforge.net/ gibt es hierfür entsprechende Methoden handle, search_X. Welche Gründe gibt es für dieses Vorgehen?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: KölnSolar am 10 Januar 2021, 13:56:49
ZitatIch frage mich allerdings, ob es sinnvoll ist, nur für mein Vorhaben wieder eine spezielle Lösung zu bauen. Kommen sich die Module nicht in die Quere, wenn man in Fhem mehrere UPnP-Devices über die Module 00_SONOS und 98_DLNARenderer und ggf. ein weiteres parallel betreibt. Schließlich müssen alle Pakete den SSDP-Verkehr über den IP-Port 1900 monitoren
Genau.
ZitatWäre es deshalb nicht notwendig, diese Kommunikation in ein zentrales SSDP/UPnP-Modul zu kapseln oder sogar in den zentralen Fhem-Loop einzubauen und über DevIO-Funktionen zugänglich zu machen?
Bin mir unsicher, ob das hinhaut. Was ist die "Zentrale" ? Controler, Renderer, Server....?
ZitatWelche Gründe gibt es für dieses Vorgehen?
Ich vermute historisch. Ich bin da auch gerade mal wieder drüber gestolpert. Im DLNARenderer kommen die Broadcastmessages auf 1900 an, die dann als "unsinnig" wieder verworfen werden.
Wir sollten auf jeden Fall darüber nachdenken, ob mittlerweile vielleicht mehr Standardperl einsetzbar ist...

Wenn ich es so richtig verstehe, nutzt der  98_DLNARenderer es so: als controler bekannt machen, search (einmalig ? u. exclude per IP u. UDN), subscription+renewal(callback-Funktion), discover(callback-Funktion),mit Select-Loop von FHEM u. dann das playing .  Die services werden (meines Erachtens redundant) im Modul konkret auf die Bedürfnisse eines Audio-devices abgefragt.

Ein FHEM-Controler müsste meines Erachtens das selbe machen. Die generierten devices ein Attribut über den Typ bekommen(automatisch ?) und  die events mitgeteilt bekommen. Die Services(z. B. playing) als set-Funktion umgesetzt werden. Klassisches 2-stufiges Modul ? :-\

Letztendlich steht u. fällt das mit der dann doch stellenweise proprietären Umsetzung von upnp. Samsung scheint da ja so ein böser Kandidat zu sein. :'(
Ich hätte relativ schnell ein "Controler-Modul" aus dem 98_DLNARenderer gebaut, welches "originär" funktioniert. Fraglich, ob die devices funktionieren.  :-\
Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: Prof. Dr. Peter Henning am 10 Januar 2021, 14:48:57
Es gibt gerade eine neue Entwicklung, die auch auf Pakete im Netz lauscht. Ist inzwischen sehr komfortabel in Bezug auf das Anlegen von Devices.

https://forum.fhem.de/index.php/topic,117309.0.html

LG

pah
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: KölnSolar am 10 Januar 2021, 15:18:22
Upnp/DLNA ist da aber doch etwas komplexer. ;) Nur IO::Socket::Multicast nutzen reicht da nicht.
Aber auch in dem Fall stellt sich die Frage der 2-Stufigkeit: Allgemeines FHEM-Multicast-Modul, welches die empfangenen Nachrichten an das neue Shelly_Modul weiterreicht.
Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: klaus.schauer am 10 Januar 2021, 19:27:06
Zitat von: KölnSolar am 10 Januar 2021, 13:56:49
Bin mir unsicher, ob das hinhaut. Was ist die "Zentrale" ? Controler, Renderer, Server....?

Wenn ich es so richtig verstehe, nutzt der  98_DLNARenderer es so: als controler bekannt machen, search (einmalig ? u. exclude per IP u. UDN), subscription+renewal(callback-Funktion), discover(callback-Funktion),mit Select-Loop von FHEM u. dann das playing .  Die services werden (meines Erachtens redundant) im Modul konkret auf die Bedürfnisse eines Audio-devices abgefragt.

Ein FHEM-Controler müsste meines Erachtens das selbe machen. Die generierten devices ein Attribut über den Typ bekommen(automatisch ?) und  die events mitgeteilt bekommen. Die Services(z. B. playing) als set-Funktion umgesetzt werden. Klassisches 2-stufiges Modul ? :-\

Meine erste Idee war, dort zu trennen, wo es devicespezifisch wird sowohl für den Controler aus auch den Server, abhängig von der Deviceart im URN: und ggf. zusätzlich von Modell. D. h. das UPnP-Modul kommuniziert mit einem oder mehreren Controler- und Server-Modulen, die dann auch Spezialitäten behandeln können. Sodass z. B. ein UPnP M-SEARCH an das Modul dispatcht wird, das das Device mit der entsprechenden UUID: hält oder das die entsprechende Deviceart bedienen könnte und dann dessen Rückmeldungen in Feldern NT: und USN: entsprechend verarbeitet werden. Dann wären mehrere gerätespezifische Module parallel betreibbar, müsste man sich "nur noch" um die Nutzdaten kümmern und hätte dafür einen Satz von Routinen nach Fhem-Art angelehnt an die Methoden im Perl Paket UPnP http://perlupnp.sourceforge.net/.

Zitat von: KölnSolar am 10 Januar 2021, 13:56:49
Letztendlich steht u. fällt das mit der dann doch stellenweise proprietären Umsetzung von upnp. Samsung scheint da ja so ein böser Kandidat zu sein. :'(
Ich hätte relativ schnell ein "Controler-Modul" aus dem 98_DLNARenderer gebaut, welches "originär" funktioniert. Fraglich, ob die devices funktionieren.  :-\
Grüße Markus
Wie weit dies generisch machbar ist, dazu fehlt mir derzeit leider noch das notwendige Detailwissen. Ich vermute aber auch, dass man da gerätespezifisch einiges investieren müsste. Der Funktionsumfang des 98_DLNARenderer-Moduls scheint z. B. bei einem Technisat DIGITRADIO 143 CD sehr überschaubar zu sein. Die Lautstärke kann man wohl einstellen. Aber schon der aktuelle Wert wird nicht richtig angezeigt. Das wars dann irgendwie, oder ich mache was falsch.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: Prof. Dr. Peter Henning am 10 Januar 2021, 20:03:45
ZitatUpnp/DLNA ist da aber doch etwas komplexer.
Das sagt jeder von seinem Protokoll  ;D

Im Ernst: Mit immer mehr Devices, die via UDP oder IP kommunizieren, sollte man "Endeckungsroutinen" vereinheitlichen.

LG

pah
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: KölnSolar am 10 Januar 2021, 21:26:58
ZitatMeine erste Idee war, dort zu trennen, wo es devicespezifisch wird
Da meinen wir dasselbe. Danach wird es etwas unverständlicher. :-[
ZitatPerl Paket UPnP http://perlupnp.sourceforge.net/.
Das paket kenn ich ja recht gut. ABER  von 2004  ???
Vielleicht sollten wir dann eher auf Net-UPnP (https://metacpan.org/release/Net-UPnP) umschwenken. Ist wesentlich aktueller und cpan auch offizieller.

Erst einmal nur den Controller-Part. Damit könnte man ein get search realisieren. die gefundenen devices als readings. Was mir jetzt schon fehlt: include/exclude IP/UDN. Muss dann ins Modul. Und dann müsste man checken, wie das Modul auf SSDP broadcast-messages bzgl. add/remove(on/off) reagiert.

Was meinst Du ?

Grüße Markus
Edit: mal tiefer ins paket geschnüffelt: scheint upnp nicht komplett umzusetzen. event-steuerung konnte ich auch nicht entdecken. :'(
Edit2: Im Forum u. FHEM recherchiert: Net-UPnP wird in YAMAHA_MC u. DLNAClient(Vorgänger des DLNARenderer) benutzt. Immer wieder Hinweise auf unzureichende DLNA/Upnp-Umsetzung. :'( Dann also doch perlupnp ? :-\ Ich mach mal ein "Controler"-modul aus dem DLNARenderer mit der genannten Funktionalität.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: klaus.schauer am 11 Januar 2021, 06:23:55
Mich wundert auch, dass Perl-Module für UPnP so selten, alt oder unvollständig sind. Gibt wohl wenig Bedarf dafür. Dass Du dich der Sache annehmen will, ist eine gute Nachricht. Danke. Vielleicht kann ich im weiteren Verlauf auch etwas dazu beitragen. Augenblicklich fehlt mir noch das tiefergehende Wissen zu den Protokollen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: KölnSolar am 11 Januar 2021, 09:10:46
Ich hab gestern noch ein wenig gelesen. Dabei ist mir dann klar geworden, dass pah gar nicht soooo falsch lag. Ich hab ständig durch die DLNA-Brille geguckt.  ::) Da ist natürlich auch ne Menge Interaktion dabei. Bei anderen "device-types" u. "servcices" ist das vermutlich gar nicht so wild. "Nur" um ein M-Search auszuführen müsste tatsächlich der multicast-Ansatz genügen.
Hilft aber am Ende dann doch nicht weiter.
ZitatWeiterhin war ich überrascht, dass die Module 00_SONOS und 98_DLNARenderer die Logik für die ControlPoint sockets in eigene select-loops legen
Ich vermute, dass das Verhalten blockierend ist und deshalb notwendigerweise in der FHEM-Loop verarbeitet wird.

Folglich werde ich mal ein "UPNP_Controlpoint" erstellen(Kopie v. 98_DLNARenderer), welches
- alleinig auf Port 1900 lauscht--> ReadFn zur Verarbeitung per handleOnce u. den beiden Callback-Funktionen für discovery u. subscriptions
- exclude/include UDN/IP
- M-Search requests stellt(nur bei Initialisierung, evtl. noch per set-Befehl)
  - attributgesteuert für "device-types"; ohne Attribut werden alle devices u. services im Netz ermittelt
  - readings: friendly-name, UDN, IP, device-type, services je device
- autocreate-Attribut um "client" devices in FHEM automatisch anzulegen
- set subsription Befehl(also Verwaltung der subscriptions, aber initialer "Anstoß" aus dem client-Modul)

Und dann schauen wir mal, was sich da so alles im lokalen Netzwerk tummelt.

Wie ist denn der device-type Deines devices für das Du SSDP-Unterstützung suchst ? Services ?

Wunder Dich nicht, dass ich einiges schreibe. Dient dann der Doku 8), die ich sonst gerne vernachlässige.
Grüße Markus


 


Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
Beitrag von: klaus.schauer am 11 Januar 2021, 11:48:02
Ich sehe Bedarf für ein Modul für das Simple Energy Management Protokoll (SEMP), das es dem Home Manager von SMA ermöglicht Geräte in Abhängigkeit von eigener Energieproduktion, Ladezustand von Energiespeichern, Energiepreis und der aktuellen und der prognostizierten Energiebilanz zu steuern.

Fhem müsste dafür per UPnP-Server als Gateway mit einer Anzahl von virtuellen Aktor-Devices agieren. Dabei propagiert sich das Gateway über SSDP. Die Steuerung erfolgt dann über HTTP-Sequenzen. Ob und in welchem Umfang die HTTP-Sequenzen im UPnP-Funktionsumfang abgedeckt sind, ist mir noch nicht klar.

Siehe https://www.photovoltaikforum.com/core/attachment/37918-20141026-short-introduction-semp-sma-pdf/. Die Beschreibung der SEMP-Schnittstelle findet man unter https://www.sma.de/produkte/sma-developer.html.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 11 Januar 2021, 21:56:35
Ah, interessant. Passt schön in meine PV-Welt.  ;)

Anbei eine erste Version. Einfach define UPNP_Controller UPNPController Es sind die ersten 3 Punkte umgesetzt: lauschen auf 1900, M-SEARCH(initial u. per set mit searchterm(ssdp:all, upnp:rootdevice......), add(also Reaktion auf ein notify eines devices), Einschränkung über IP/UDN.


Achtung, kann sich leicht blockierend verhalten !
Nach einiger Zeit solltest Du sämtliche devices mit ihren services(..._s_....) u. children(...._c_....) in Deinem LAN als readings erhalten. Bei mir wurden gefunden: Fritte, Frittenverstärker, IPCAM, TV, 2*miniDLNA, WindowsMediaPlayer auf dem PC. Interessant war, dass die Fritte mehrfach auftaucht: unterschiedliche services=unterschiedliche devices UND die Anzeige erfolgt mit verkürzter UDN. Im Falle der Fritte ist das falsch, will heißen die Einträge werden überschrieben.

Bin gespannt ob Dein Sunny-Homemanager und Dein Technissat gefunden wird und welche services die mitbringen.

Grüße Markus
Edit: hier (https://forum.fhem.de/index.php/topic,82890.msg1034866.html#msg1034866) u. hier (https://forum.fhem.de/index.php/topic,82890.msg1034868.html#msg1034868) findest Du ein paar ergänzende Informationen zu Installation, Funktionsweise ... des DLNARenderers. Das UPNPControlpoint verhält sich gleich.
Edit2: Ah, verstehe. Du brauchst
ZitatThe concatenation of the contents "semp:server" and "semp:basePath" ("<semp:server><semp:basePath>")
results in the BaseURL. It is used by the EM as a prefix for the creation of request URLs
Du brauchst die location. Ueber die URI kommst Du dann an die benötigten Daten für die BaseURL. Hab die Location als zusätzliches reading eingebaut.

Edit: test version removed
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 12 Januar 2021, 18:56:19
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.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 12 Januar 2021, 19:48:38
ZitatDer 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 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.  ;D

Edit: puh, hab ich mich mit der Fritte gequält. Ich hab sie jetzt indiziert. Ist jetzt übersichtlicher und sortierter. Probier mal. Am bestenreload 98_UPNPController
deletereading UPNP_Controller .*


Zitat
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.
ZitatFhem muss nicht als ControlPoint sondern als DeviceManager agieren.
Was soll denn der DeviceManager sein ? Das Gateway ?

Edit: Modulversion removed.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 16 Januar 2021, 10:58:45
Zitat von: KölnSolar am 13 Januar 2021, 21:08:22
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.
Zitat
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 :o.
Ist ja grundsätzlich nicht schlimm, sofern des dennoch eindeutig bleibt.
Zitat
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.
Zitat
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.
Zitat
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.
Zitat
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 ;D).
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.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 17 Januar 2021, 11:03:32
Der Name der Readings wird im LOG als fehlerhaft ausgewiesen:
Zitat
2021.01.17 10:59:28 3: UPNP_Controller: bad reading name '192.168.6.131:2870_UDN' (allowed chars: A-Za-z/\d_\.-)
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: gvzdus am 18 Januar 2021, 13:48:58
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.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 18 Januar 2021, 14:15:38
Ich sehe im Augenblick nicht, wie es möglich wäre im EEBUS-Kontext beliebige Fhem-Devices zu monitoren und zu schalten.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 18 Januar 2021, 20:34:03
dann lösen wir uns mal wieder von dem SMA-Thema und kommen zum Kern zurück

ZitatDer 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.  ::)
ZitatWichtig 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.
ZitatSonst 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.
ZitatUniqueDeviceName. 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.
ZitatDa 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. ;D

Edit2: Testversion removed
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 19 Januar 2021, 18:09:27
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.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 19 Januar 2021, 21:35:29
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. 8)
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
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 23 Januar 2021, 10:29:14
Zitat von: KölnSolar am 19 Januar 2021, 21:35:29
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. 8)
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.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 23 Januar 2021, 13:32:48
ZitatIch 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.
Zitatjeweils ein gerätespez. IP-Port zu definieren
Ich denke, das Perl-Paket legt die Verbindung an u. das Modul holt sich den Port.

ZitatX_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. :'(
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: justme1968 am 23 Januar 2021, 15:15:11
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.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 23 Januar 2021, 15:43:11
Hi Andre,
Zitatkomme aber leider nicht zu mehr.
Das merkt man leider.  ;)

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

Zitatmit einer solchen idee angefangen
Ich fand leider keinen Quellcode, den man weiter bearbeiten oder drauf aufsetzen könnte.  :-\

Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: gvzdus am 23 Januar 2021, 20:39:15
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?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 23 Januar 2021, 23:09:52
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....
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 24 Januar 2021, 10:36:18
Zitat von: KölnSolar am 23 Januar 2021, 13:32:48
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
Das 2-stufige Modell hat über die X_Parse-Funktion u. a. den Vorteil, dass die nachgelagerten Module automatisch Devices anlegen können, sobald sie die für sie passenden SSDP-notify-Meldungen eines für sie noch unbekannten DeviceManagers erhalten. Dies über eine permanente Überwachung von Fhem-notifys durch die nachgelagerten Module machen zu wollen, führt dazu dass die SSDP-notifys permanent Fhem-notifys auslösen müssten. Dies gilt auch für die SSDP-bye-Meldungen.

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

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. :'(
Ich hatte angenommen, dass das SSDP-Paket einen Parallelbetrieb der ControlPoint- und DeviceManager-Funktionen ermöglich. Schade wenn es nicht so wäre.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: Wzut am 24 Januar 2021, 11:13:09
Zitat von: KölnSolar am 18 Januar 2021, 20:34:03
danach geht alles wie von selbst und über die Zeit sammeln sich die readings
Wollte ich bei mir mal testen , aber selbst bei verbose 5 blieb das Log leer :(
Im nächsten Schritt habe ich set searchterm ssdp:all versucht : die ersten Zeilen im Log über gefundene Geräte, aber keine neuen Readings.
Schritt zwei :   in der sub _addedDevice das $testflag auf 1 gesetzt , jetzt gibt es einige neue Readings.
In Summe hat er zwei FBs erkannt und das Synologie NAS, aber vom SMA HM2.0 ist da nichts zu sehen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 24 Januar 2021, 16:34:46
Zitat von: Wzut am 24 Januar 2021, 11:13:09
Wollte ich bei mir mal testen ... In Summe hat er zwei FBs erkannt und das Synologie NAS, aber vom SMA HM2.0 ist da nichts zu sehen.
Der SMA HomeManager ist in UPnP-ControlPoint, der UPnP-DeviceManager sucht. Fhem müsste also ein UPnP-DeviceManager sein. Diese Funktion ist bisher in Fhem nicht vorhanden.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 25 Januar 2021, 09:36:24
Ja. Ein Controlpoint sendet keine Notify-messages und empfängt sie nur. Entweder auf eigenen request oder periodisch(in der Regel wohl 30min.) durch ein device(keep-alive) ausgelöst.
ZitatIm nächsten Schritt habe ich set searchterm ssdp:all versucht : die ersten Zeilen im Log über gefundene Geräte, aber keine neuen Readings.
Das wundert mich. Logging und Anlage von readings findet gleichzeitig statt. Ich hab zwischenzeitlich noch einmal die searchterms über Wireshark getestet, weil auch bei mir irgendwie unklar war, auf welchen searchterm die devices reagieren. In der letzten Version hab ich bei der Initialisierung upnp:rootdevice. Da konnte ich aber jetzt mit Wireshark gar keine Reaktion feststellen. Wohl aber mit ssdp:all Warte auch mal  die 30min. ab, um vielleicht devices zu bekommne, die nicht auf einen search-request reagieren.
ZitatBei 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?
Ich hab dann mal den Quellcode studiert. Für 1900 wird tatsächlich reuse benutzt. Hilft nur leider wenig, denn meines Erachtens kann die FHEM-selectloop ja nur einen filedescriptor bedienen. Wäre  auch nicht so schlimm. Ich hab es jetzt so definiert, dass nur der Controlpoint lauscht und per ReadFn bedient wird. Nun hab ich aber das Problem, dass ich hier  (https://forum.fhem.de/index.php/topic,117623.0.html) bereits ähnlich und unbeantwortet angefragt hatte: Lesen ohne "Leeren" der message queue, um zu entscheiden, wer die Nachricht verarbeiten soll und dort dann auch noch die message zur Verfügung steht.
ZitatDas 2-stufige Modell hat über die X_Parse-Funktion u. a. den Vorteil, dass die nachgelagerten Module automatisch Devices anlegen können, sobald sie die für sie passenden SSDP-notify-Meldungen eines für sie noch unbekannten DeviceManagers erhalten. Dies über eine permanente Überwachung von Fhem-notifys durch die nachgelagerten Module machen zu wollen, führt dazu dass die SSDP-notifys permanent Fhem-notifys auslösen müssten. Dies gilt auch für die SSDP-bye-Meldungen.
Bei dem bisher "sichtbaren" Bedarf halte ich das in der Entwicklung zu aufwändig. Und eigentlich muss doch sowieso alles manuell angelegt werden. Die "nachgelagerten" Module kennen doch gar kein SSDP. :-\ Umgekeht könnt ich mir eher noch vorstellen, dass bei der Definition eines devices eines "nachgelagerten" Moduls ein passendes UPNPdevice erzeugt wird.

Ich lass jetzt mal den Controlpoint und DeviceManager in 2 unterschiedlichen FHEM-System laufen, um den SHM zu simulieren. Sobald es stabil läuft attache ich die Versionen und beschreibe es ein wenig.

Grüße Markus

Edit: Ich attache mal meine xml-Beschreibung zum SEMP-device. Basis ist die Specification von SMA u. Literale habe ich mal angepasst. Uns fehlen der deviceType(müsste man mal wissen, was ein Gateway da nutzt bzw. der SHM "will") und eine uuid(der Einfachheit halber sollte die durch den user ermittelt und ins Template eingetragen werden. Ich hab mal http://www.uuid.online dazu ausprobiert).
So sehen dann im Controlpoint die readings aussetstate UPNP_Controller 2021-01-25 11:05:05 192.168.x.y:4004-UDN uuid:UUID
setstate UPNP_Controller 2021-01-25 11:05:05 192.168.x.y:4004-friendlyName this is just a test device
setstate UPNP_Controller 2021-01-25 11:05:05 192.168.x.y:4004-location http://192.168.x.y:4004/opt/fhem/SEMPdevice.xml
setstate UPNP_Controller 2021-01-25 11:05:05 192.168.x.y:4004-manufacturer FHEM
setstate UPNP_Controller 2021-01-25 11:05:05 192.168.x.y:4004-modelName FHEM UPNP SEMP device
setstate UPNP_Controller 2021-01-25 11:05:05 192.168.x.y:4004-presence online

Und so der Aufruf der "location" über einen Browser. Man sieht, dass das Modul die URLBase generiert und hinzugefügt hat.<?xml version="1.0"?>
-<root xmlns="urn:schemas-upnp-org:device-1-0">
-<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
-<device>
<deviceType>urn:domain-name:device:deviceType:ver</deviceType>
<friendlyName>this is just a test device</friendlyName>
<manufacturer>FHEM</manufacturer>
<modelName>FHEM UPNP SEMP device</modelName>
<UDN>uuid:UUID</UDN>
<serviceList> </serviceList>
<deviceList> </deviceList>
-<semp:X_SEMPSERVICE xmlns:semp="urn:schemas-simple-energy-management-protocol:service-1-0">
<semp:server>http://IP[:port]</semp:server>
<semp:basePath>/SEMP</semp:basePath>
<semp:transport>HTTP/Pull</semp:transport>
<semp:exchangeFormat>XML</semp:exchangeFormat>
<semp:wsVersion>x.y.z</semp:wsVersion>
</semp:X_SEMPSERVICE>
</device>
<URLBase>http://192.168.x.y:4004</URLBase>
</root>
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 26 Januar 2021, 16:50:31
Der Einstieg in die UPnP DeviceManager-Funktionen ist ja auch schon gemacht. Damit habe ich jetzt noch gar nicht gerecht, super und danke. Im u. a. File habe ich mal hoffentlich brauchbare Parameter aus der SEMP-Spezifikation eingetragen. Die IP-Adressen müssten für Tests nur noch passend gemacht werden. Dann könnte ein stolzer Besitzer eines SMA Home Managers mal sehen, was das Gateway mit den Parametern anstellt. Eigentlich sollte es dann periodisch versuchen, das Gateway abzufragen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 27 Januar 2021, 10:20:33
Wieso hast Du einen service eingetragen ? Wir haben doch gar keinen UPnP-service beim Gateway.  :-\ UPnP/SSDP wird doch "nur" für connect/disconnect benutzt und nach einem connect entnimmt der SHM aus dem Abschnitt semp:X_SEMPSERVICE die Daten für den http-SEMP-server u. Pfad.

Ich hab noch Probleme von blockierendem Verhalten. Ich blicke noch nicht, was da blockiert. Erst wenn ich da schlauer bin, veröffentliche ich die Version.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 27 Januar 2021, 10:31:19
In der SEMP-Spezifikation Kap. 3.2.2/Service List wird empfohlen, einen NULL-service als dummy service aufzunehmen, siehe auch Beispiel auf Seite 16.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 27 Januar 2021, 11:32:44
Ah ja, so weit hatte ich gar nicht gelesen.  ::) Ich halte es aber trotzdem für sinnfrei einen service im Netz zu propagieren, den es nicht gibt. Keine Information auf die ein anderes device subscriben könnte, keine action, die ein Controller auslösen könnte. Oder anders formuliert: Ein Service ohne Leistung ist doch kein service.  ;D Und der SHM(das einzige device, das sich wirklich für das Gateway "interessiert") braucht es nicht.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 28 Januar 2021, 10:21:30
Hab ichs mir doch irgendwie gedacht. War aber zu unbedarft, zumal seltsamerweise(für mich) die Perl warning PERL WARNING: Loading device description failed with error: 500 read timeout (Location: http://192.168.x.y:4004/opt/fhem/SEMPdevice.xml)erst nach Einschalten von stacktrace gelogged wurde. :o Und stacktrace sagt, dass es das parallel laufende UPNPController ist, das das Problem hat, wenn es das advertisement auf 1900 empfängt und das device anlegen möchte. Dabei tritt dann der unspezifische 500 auf. Irgendwo in den Modulen LWP, HTTP...

t.b.c.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 31 Januar 2021, 20:21:33
kurzes update: der 3*20s freeze kommt aus dem Controlpoint(3 notifys vom DeviceManager) . Ich bin ihm(u. dem timeout=20s) näher gekommen, aber noch nicht identifiziert. Ich hab daher ein wenig am Modul bzgl. defmod etc. und exclusion gearbeitet und als workaround nun die IP ausgeschlossen. ::)

Der neue Renderer(DLNAManager ?) bekommt als logisches Modul schon die events vom Controlpoint zur Verarbeitung u. autocreate funktioniert auch(tw.).
Nächste Schritte:
- Befehle vom logischen Modul über den Controlpoint an das enddevice
- initial subscription bei device definition
- disable-flag(unsubscribe)
- finales Design
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 15 Februar 2021, 20:39:30
So, ich hab jetzt mal einen neuen Thread zu meiner Entwicklung (https://forum.fhem.de/index.php/topic,118837.msg1132817.html#msg1132817) mit den Attachements aufgemacht. Weil UPNPDevice eher uninteressant für den gewöhnlichen Anwender ist, sollten wir die weitere Entwicklung hier diskutieren. Neue Versionen würde ich im anderen Thread ablegen. Das description.xml ist Dein letzter Stand für das SEMPdevice.

Viel hab ich nicht mehr geändert. Die wenige Funktionalität start, stop, advertise sollte funktionieren. Und dann wäre das meines Erachtens schon fast erledigt.(mal abgesehen von der freeze-Thematik.

Nun bin ich gespannt auf Deinen Testbericht.

Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 16 Februar 2021, 12:39:33
Herzlichen Dank für Deine Arbeit an den Modulen. Nach dem ersten Start , bisher ohne UPNPDevice, werden diverse UPnP-Manager Devices gefunden und DLNA-Devices angelegt. Leider gibt es beim Fhem-Restart aber Probleme. Fhem start nach der Fehlermeldung

2021.02.16 12:26:44 2: UPNPController: UPNP Controller v0.0.1 started
Can't call method "services" on an undefined value at ./FHEM/98_UPNPController.pm line 947, <$fh> line 947.

mit

2021.02.16 12:26:45 1: Including fhem.cfg

immer wieder neu.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 16 Februar 2021, 13:01:59
Hi,
danke fürs testen.

Ähnliche Probleme hab ich befürchtet(getestet hatte ich den restart nie  :-[). Ich nehme an, Du hattest services subscribed ? Dann ist die Problematik sicherlich, dass die vorhandenen readings(per setstate) noch nicht wieder gefunden wurden. Hast Du dann erneut subscribed oder war das dann ein renewal, also subscribed,shutdown,restart ?

Ich hatte mir schon überlegt, ob es nicht einfacher, sogar sinnvoller ist, bei jedem define sämtliche readings des Controllers zu löschen. Die vorhandenen logischen devices müssten solange in den presence=offline Status(könnte man evtl. beim restart generell machen). Was meinst Du ?

Nach längerer Zeit hab ich dann auch  mal wieder UPNPDevice getestet. Ich fiel auf die Nase. :o Irgendwie war das Problem der filename. Teste also bitte erst einmal mit der im Thread attachten description.xml. Dort hab ich gegenüber Deiner letzten Version nur minimalste Veränderungen vorgenommen, weil sonst spaces/tabs/lf im reading stehen.

Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 16 Februar 2021, 13:17:10
Zitat von: KölnSolar am 16 Februar 2021, 13:01:59
Ähnliche Probleme hab ich befürchtet(getestet hatte ich den restart nie  :-[). Ich nehme an, Du hattest services subscribed ? Dann ist die Problematik sicherlich, dass die vorhandenen readings(per setstate) noch nicht wieder gefunden wurden. Hast Du dann erneut subscribed oder war das dann ein renewal, also subscribed,shutdown,restart ?
Ich habe bisher keine Aktionen ausgelöst. Folgende Devices wurden automatisch angelegt:

define UPNP_Controller UPNPController
setuuid UPNP_Controller ?
attr UPNP_Controller userattr acceptedUDNs defaultRoom ignoreUDNs
define DLNAManager_192.168.6.41_8080 DLNAManager 192.168.6.41_8080
setuuid DLNAManager_192.168.6.41_8080 ?
attr DLNAManager_192.168.6.41_8080 userattr channel_01 channel_02 channel_03 channel_04 channel_05 channel_06 channel_07 channel_08 channel_09 channel_10 multiRoomGroups ttsLanguage
attr DLNAManager_192.168.6.41_8080 IODev UPNP_Controller
attr DLNAManager_192.168.6.41_8080 room DLNAManager
define FileLog_DLNAManager_192.168.6.41_8080 FileLog ./log/DLNAManager_192.168.6.41_8080-%Y.log DLNAManager_192.168.6.41_8080
setuuid FileLog_DLNAManager_192.168.6.41_8080 ?
attr FileLog_DLNAManager_192.168.6.41_8080 logtype text
attr FileLog_DLNAManager_192.168.6.41_8080 room DLNAManager
define DLNAManager_192.168.6.40_8080 DLNAManager 192.168.6.40_8080
setuuid DLNAManager_192.168.6.40_8080 ?
attr DLNAManager_192.168.6.40_8080 userattr channel_01 channel_02 channel_03 channel_04 channel_05 channel_06 channel_07 channel_08 channel_09 channel_10 multiRoomGroups ttsLanguage
attr DLNAManager_192.168.6.40_8080 IODev UPNP_Controller
attr DLNAManager_192.168.6.40_8080 room DLNAManager
define FileLog_DLNAManager_192.168.6.40_8080 FileLog ./log/DLNAManager_192.168.6.40_8080-%Y.log DLNAManager_192.168.6.40_8080
setuuid FileLog_DLNAManager_192.168.6.40_8080 ?
attr FileLog_DLNAManager_192.168.6.40_8080 logtype text
attr FileLog_DLNAManager_192.168.6.40_8080 room DLNAManager

Zitat
Ich hatte mir schon überlegt, ob es nicht einfacher, sogar sinnvoller ist, bei jedem define sämtliche readings des Controllers zu löschen. Die vorhandenen logischen devices müssten solange in den presence=offline Status(könnte man evtl. beim restart generell machen). Was meinst Du ?
Das kann ich nicht beurteilen, da ich die Auswirkungen auf die logischen Devices nicht abschätzen kann.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 16 Februar 2021, 14:24:31
 ;D ;D ;D
ZitatIch habe bisher keine Aktionen ausgelöst
Doch hast Du.
ZitatFolgende Devices wurden automatisch angelegt
Bei der Anlage wird auch automatisch das subscribe ausgeführt.  ;)
Das Problem liegt dann darin, dass beim restart natürlich auch wieder für das DLNA-device subscribed werden soll. Warum das dann aber nicht fluppt, muss ich mir im Hinblick auf den restart mal in Ruhe angucken. Oder nein, jetzt wird's mir klar. Das DLNA-device wird angelegt. Die subscription geht dann in die Hose, weil der Controller den service noch gar nicht kennt(noch gar kein alive-NOTIFY angekommen ist).

Muss ich mir in Ruhe zu Gemüte führen.

Auf die Schnelle könntest Du so um Zeile 240 rum das
  my ($dev) = $hash->{helper}{$uniqueDeviceName};
  my $upnpService = UPNPController_GetService($hash, $dev, $service);

durch das my ($dev) = $hash->{helper}{$uniqueDeviceName};
return if (!defined($dev));
  my $upnpService = UPNPController_GetService($hash, $dev, $service);
ersetzen.

ZitatDas kann ich nicht beurteilen, da ich die Auswirkungen auf die logischen Devices nicht abschätzen kann.
Doch, kannst Du.  ;) Es ist ja so, dass die reading-names des Controller sich NIE verändern, egal, ob man später per IP oder UDN einschränkt, das device gar nicht mehr im LAN existiert..... Da würde es meines Erachtens Sinn machen, wenn wenigstens zu jedem restart eine Löschung erfolgt. "Noch" vorhandene/gewünschte devices werden beim Restart, spätestens beim nächsten Einschalten wieder gefunden. Man hat dann wieder eine aktuelle Übersicht bzw. nur die gewünschten devices. Sonst schleppt man den reading-"Schrott" ewig mit sich rum. Das logische device muss eh erst einmal im offline-Status verbleiben, bis es vom Controller "entdeckt" wurde und dadurch in den online-state wechselt. Ansonsten ist der Zustand undefiniert und in der jetzigen Version passiert dann das von Dir geschilderte Problem.
Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 16 Februar 2021, 18:26:12
Der Neustart-Fehler ist mit der zusätzlichen Abfrage weg. Die DLNAManager Devices sind nach dem Neustart einige Zeit "offline". Das passt doch, oder so?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 16 Februar 2021, 18:48:25
Ja, eigentlich schon. Aber ich muss sowieso mal alles gedanklich durchspielen und dann weitere Prüfungen etc. einbauen. So ist z.B. im Augenblick alles über die IP "verbunden". Erst dachte ich, machen wir ja in vielen Modulen so. Und bei mir ist das kein Problem, weil ich zwar DHCP nutze, aber dann dem DHCP sage, dass eine MAC immer dieselbe IP zu bekommen hat. Es gibt aber bestimmt auch andere Fälle u. wenn die IP sich ändert, bricht das fragile Konstrukt zusammen.  ;D :'( Manche devices sind vermutlich auch im Port variabel.  :(

Aber im Augenblick kommt es mir auf die Kernfunktionalitäten an. Ich bin schon auf Werbetour, dass zukünftig UPnP nur noch über UPNPController läuft.  :)
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 16 Februar 2021, 19:12:14
Die Namen der Module sind nicht für Funktion relevant; sind aber für's Verständnis nicht ganz unwichtig. Wie wäre es etwas so:

- UPNPController >> UPNPIO: Wäre passender, weil das Modul doch die Basis für DLNAManager (DLNAController) und UPNPDevice (UPNPManager) ist, oder?
- DLNAManager >> DLNAController: War je eh klar.
- UPNPDevice >> UPNPManager (>> UPNPDevice): Weil es eben die Funktion des UPnP-Managers hat. Ob es dahinter so etwas wie UPNPDevices geben muss, wird sich noch zeigen.

Oder habe ich die Funktionsaufteilung noch nicht verstanden?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 16 Februar 2021, 20:20:35
ZitatDie Namen der Module sind nicht für Funktion relevant; sind aber für's Verständnis nicht ganz unwichtig.
Sehe ich auch so. Bei UPnP herrscht irgendwie ein ziemliches durcheinander mit den Begriffen. Das Perlupnp mit UPnP::DeviceManager tut sein übriges dazu. Ich hab ne Menge gelesen. Sich an die UPnP-Spezifikation zu halten, finde ich da noch am sinnvollsten.

Demnach ist der Controller ein device, welches in meinen Augen als Steuergerät zu verstehen ist. Nimmt man DLNA, das auf UPnP aufsetzt, so "verbindet" der Controller Mediaserver(z.B. miniDLNA) mit Renderern(z.B. TV). Ein TV kann aber auch Controllerfunktionalität haben, dann nennt man es wohl DLNAPlayer. FHEM sehe ich daher prinzipiell als Controller an, so "schiebt" mein DLNAController ein file auf den DLNARenderer(TV). Was wir bisher nicht als allgemeine Funktionalität in FHEM haben, ist die "Verwaltung" eines DLNAServers: Liste der files, Suchfunktion....Das ließe sich auch am UPNPController "andocken".

Dein SEMP-Gateway sehe  ich vergleichbar zu DLNA als zu "steuerndes" device. Der SHM ist der Controller. Wenn wir das Gateway in FHEM abbilden, so ist es ein  "Enddevice", welches dem Controller events liefert oder durch den Controller gesteuert werden kann. Warum der Autor von perlupnp das Modul DeviceManager genannt hat ist mir ein Rätsel. Gemanaged wird da ja gar nichts(bei Deinem Gateway ist das was anderes, aber diese Funktionalität kommt ja auf die andere Seite des Gateways).

Betrachtet man es technisch, dann hat ein Controller keine xml-description(location), kein device, keinen service, es kann nichts bei ihm subscribed werden. Umgekehrt hat das device eine location, services, die von anderen subscribed werden können und actions über die es gesteuert werden kann. Selber subscribed es nicht und steuert auch nichts.

Zitatweil das Modul doch die Basis für DLNAManager (DLNAController) und UPNPDevice (UPNPManager) ist, oder?
Nein. UPNPDevice ist völlig unabhängig vom Controller. Es besteht keinerlei informationstechnische Verbindung zwischen diesen beiden Module(ist so natürlich auch nicht ganz richtig, weil es noch das Modul Common.pm gibt, welches beide Module benutzen). Entweder wendet man das eine an oder das andere.

Ich denke es wird vielleicht klarer, wenn Du Dir anguckst, was "unser" SEMP-device macht. Es broadcastet im Netzwerk nur, dass es vorhanden ist, oder meldet sich ggfs. per byebye ab.
Der Controller nimmt die broadcast-messages an und bei Interesse wird subscribed(beim SEMP-device aber nicht, da es gar keine services hat). Das SEMP-device ist also vergleichbar, den devices, die der Controller sonst noch so findet. Bei mir die miniDLNA-Server, die Windows-Mediaplayer, meine Samsung-TVs, eine IP-CAM, die Fritte, ein Frittenverstärker. Bei Dir sind es Router, NAS, Radio.

Klarer oder anderer Meinung ?

Edit: Weil Bilder mehr als mein Geschwafel sagen, guck mal hier (https://de.wikipedia.org/wiki/IGD-Protokoll#/media/Datei:UPnP_discovery_phase.jpg)Das FHEM-SEMPGateway, TV.... liegen rechts, Controller liegen links. In FHEM besteht ein Controller aus dem physischen(technische Basis=UPNPController) UND logischen Modul(servicespezifisch; z.B.  DLNAController).
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 02 März 2021, 18:04:02
Inzwischen habe ich einen UPnP-Controller und ein UPnP-Device auf getrennten Fhem-Installationen laufen. Das UPnP-Device mit der SEMP-Konfiguration wird vom UPnP-Controller entsprechend angezeigt. Nun erste Erkenntnisse aus meinen Tests:

1. Ruft man die SEMP URL "location" auf, so wird der Inhalt der xlm-Datei angezeigt, danach blockiert Fhem, auf dem das UPnP-Device läuft, 40 s oder mehr. Dann kommt die Fehlermeldung

2021.03.01 19:31:54 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.

2. Das Attribut "file" zieht irgendwie nicht. Im Modulcode sehe ich nicht, warum das so ist. Erst wenn man in sub UPNPDevice_setupDevice die Standardeinstellung

my $file = AttrVal($name,"file","/opt/fhem/description.xml"); #SEMPdevice.xml

selbst anpasst, wird dies übernommen.
3. Wie soll ermöglichst werden, dass man auf einer Fhem-Installation mehrere UPnP-Devices parallel definiert? Mehrere UPNPDevice kann ich derzeit zwar definieren, diese laufen aber nicht. Das scheitert ja schon daran, dass man für jedes UPnP-Devices ein sep. UPnP-Beschreibungsdokument angeben können müsste. Oder sollen mehrere UPnP-Devices in einem XML-Beschreibungsdokument eingetragen werden?
4. Wie und an welcher Stelle soll in dem Konstrukt insbesondere z. B. der SEMP-spezifische Code abgebildet werden? Soll es das vorliegende Modul UPNPDevice um diese Funktionen angereichert werden oder wird das Modul UPNPDevice noch ausgebaut, sodass die mehrere SUB-Devices sich dem Modul UPNPDevice bedienen können?
5. Gibt es in bestehenden Modulen ein brauchbares Programmbeispiel für einen WEB-Server, der für das SEMP-Device benötigt wird? Bei den anderen von mir betreuten Modulen gab es dafür noch keinen Bedarf. Für mich wäre deshalb ein Beispiel hilfreich.


Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 02 März 2021, 19:52:07
Zitat1. Ruft man die SEMP URL "location" auf, so wird der Inhalt der xlm-Datei angezeigt, danach blockiert Fhem, auf dem das UPnP-Device läuft, 40 s oder mehr. Dann kommt die Fehlermeldung
Bei mir nicht, wenn
ZitatUPnP-Controller und ein UPnP-Device auf getrennten Fhem-Installationen laufen
oder meinst Du mit
ZitatRuft man die SEMP URL "location" auf
im Browser ?
Zitat2. Das Attribut "file" zieht irgendwie nicht.
Ja, das schrieb ich ja. Keine Ahnung wo es da hakt. Ich kümmere mich...
ZitatOder sollen mehrere UPnP-Devices in einem XML-Beschreibungsdokument eingetragen werden?
Nein, das ist nicht der Plan, sondern mehrere devices mit jeweils eigener location.
(hab ich aber noch nicht ausprobiert. Wird daran scheitern, dass Port 4004 nicht mehrfach nutzbar ist)
Zitat4. Wie und an welcher Stelle soll in dem Konstrukt insbesondere z. B. der SEMP-spezifische Code abgebildet werden? Soll es das vorliegende Modul UPNPDevice um diese Funktionen angereichert werden oder wird das Modul UPNPDevice noch ausgebaut, sodass die mehrere SUB-Devices sich dem Modul UPNPDevice bedienen können?
Der UPnP-Part für SEMP ist meines Erachtens in der vorliegenden Version erledigt. Alles weitere müsste in ein eigenes Modul. Dieses Modul würde dann das UPNPDevice per set über "start" u. "stop" steuern, um dem SHM die Bereitschaft anzuzeigen.
Zitat5. Gibt es in bestehenden Modulen ein brauchbares Programmbeispiel für einen WEB-Server, der für das SEMP-Device benötigt wird? Bei den anderen von mir betreuten Modulen gab es dafür noch keinen Bedarf. Für mich wäre deshalb ein Beispiel hilfreich.
Ich kenne keins.  :'( Ich würd mal per grep in den Source-Codes nach LWP, Net::http... suchen. Vielleicht lässt sich auch aus FHEMWEB oder MQTT was Server ableiten.  :-\


Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 02 März 2021, 20:41:40
Zitat von: KölnSolar am 02 März 2021, 19:52:07
Bei mir nicht, wenn oder meinst Du mit im Browser ?
Genau, der Fehler tritt auf, wenn man die XML im Browser aufruft.
Zitat
Oder sollen mehrere UPnP-Devices in einem XML-Beschreibungsdokument eingetragen werden?
Nein, das ist nicht der Plan, sondern mehrere devices mit jeweils eigener location.
Sollte das denn derzeit schon gehen? Wenn ja, wie? Dann müsste ich doch irgendwie die Devices mit mehrfachen "file"-Attributen definieren und per getrennter "set"-Befehle starten und stoppen können.
Zitat
Der UPnP-Part für SEMP ist meines Erachtens in der vorliegenden Version erledigt. Alles weitere müsste in ein eigenes Modul. Dieses Modul würde dann das UPNPDevice per set über "start" u. "stop" steuern, um dem SHM die Bereitschaft anzuzeigen.
Das kann man sicherlich als Einstieg so machen und wird wahrscheinlich funktionieren. Irgendwie widerstebt mir dieses Konstrukt aber als endgültige Lösung. Wie soll ein Anwender das verstehen, der einfach nur Devices damit steuern will. Aber erst einmal eins nach dem anderen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 02 März 2021, 22:32:48
ZitatWie soll ein Anwender das verstehen, der einfach nur Devices damit steuern will
Der kriegt ja nichts davon mit. Der upnp-Kram sind nur prerequesites, die einmalig installiert werden müssen(ginge theoretisch auch im Hintergrund. Ich meine aber, der User sollte es "bewusst" installieren.)
Der User nutzt nur das SEMP-Modul/device. start/stop des UPNPDevices im Gleichklang mit dem disable-Attribut ?
ZitatSollte das denn derzeit schon gehen? Wenn ja, wie? Dann müsste ich doch irgendwie die Devices mit mehrfachen "file"-Attributen definieren und per getrennter "set"-Befehle starten und stoppen können.
:-\ Du kannst doch zig devices anlegen, z.B. SEMP1, SEMP2...
Was natürlich erst funktioniert, wenn ich den Fehler beseitigt habe. Ist glaub das ist ein Anfängerfehler  ::) :-[ Ich bau dann auch gleich die notwendigen Maßnahmen bei Änderung/Löschung der file/path Attribute ein. Dauert dann wohl Richtung Wochenende. :(
ZitatGenau, der Fehler tritt auf, wenn man die XML im Browser aufruft
Tatsache. Aber kein freeze bei mir. Und dann verschmerzbar.

Edit: Wenn Du nichts anderes findest, kannst Dir ja mal die Serverfunktionsweise von Port 4004 in DeviceManager.pm ansehen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 03 März 2021, 07:01:21
Zitat von: KölnSolar am 02 März 2021, 22:32:48
Du kannst doch zig devices anlegen, z.B. SEMP1, SEMP2... Was natürlich erst funktioniert, wenn ich den Fehler beseitigt habe. Ist glaub das ist ein Anfängerfehler  ::) :-[
Ist mir eben auch eingefallen... Die Attribute sind zum Ausführungszeitpunkt noch nicht eingelesen.
Zitat
Wenn Du nichts anderes findest, kannst Dir ja mal die Serverfunktionsweise von Port 4004 in DeviceManager.pm ansehen.
Genau, hat ja u. U. ähnliche Anforderungen zu erfüllen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 05 März 2021, 16:34:35
ZitatDu kannst doch zig devices anlegen, z.B. SEMP1, SEMP2...
dachte ich. ::) Der Notification- u. der Device-Port können leider nicht mehrfach belegt werden. :'(
Da Du bisher der einzige Nutzer bist(u. ich befürchte bleiben wirst), schlage ich vor, dass wir die Anzahl der devices(sofern überhaupt nötig) über das descrption file steuern. D'accord ?
Ich probier es jetzt mal aus....
Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 05 März 2021, 17:35:35
Na ja die SMA Home Manager sind ja nicht ganz so selten. Da wird schon noch der eine oder andere Gefallen an der Steuerung von Fhem-Devices darüber finden.

Sicher, wenn man mehrere Devices über ein UPnP-Definitionsfile publizieren kann, ist das doch ein gangbarer Weg. Aber warum muss es denn unterschiedliche Ports geben? Reicht es nicht auf einem Port unterschiedliche UPnP-Definitionsfiles anzugeben. Bei der Fritz!Box gibt es

http://192.168.x.y:49000/l2tpv3.xml
http://192.168.x.y:49000/igd2desc.xml
http://192.168.x.y:49000/MediaServerDevDesc.xml

Diese Beschreibungsfiles werden ja unabhängig voneinander publiziert, wenn ich z. B. den MediaServer ein- / oder ausschalte.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 05 März 2021, 19:13:09
Ich kriegs nicht hin. Absturz mit deep recursion u. out of memory.  :'( . JETZT hab ich aber die "Ebenen" richtig verstanden
DeviceManager
   NotificationPort -> Advertisement
   SSDP-listen-Port 1900
   Registration of each device
   Device(s)
      description -> location
      http-server (device-port)
      start, stop, advertise

Eigentlich müsste man es also auch als 2 stufiges Modul aufbauen.  :-\

ZitatDa wird schon noch der eine oder andere Gefallen an der Steuerung von Fhem-Devices darüber finden.
Ja, schon, User, aber nicht Module/devices.
ZitatAber warum muss es denn unterschiedliche Ports geben?
Frag den perlupnp-Entwickler.  ;) Ich hab mir echt einen abgebrochen. UPNP-specification studiert.... Ich sehe keinen Fehler
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:domain-name:device:deviceType:ver</deviceType>
<friendlyName>this is just a test device</friendlyName>
<manufacturer>FHEM</manufacturer>
<modelName>FHEM UPNP SEMP device</modelName>
<UDN>uuid:fc655837-3054-4670-b1d2-4c7e8aeada08</UDN>
<serviceList>
</serviceList>
<semp:X_SEMPSERVICE
xmlns:semp="urn:schemas-simple-energy-management-protocol:service-1-0">
<semp:server>http://IP[:port]</semp:server>
<semp:basePath>/SEMP</semp:basePath>
<semp:transport>HTTP/Pull</semp:transport>
<semp:exchangeFormat>XML</semp:exchangeFormat>
<semp:wsVersion>x.y.z</semp:wsVersion>
</semp:X_SEMPSERVICE>
<deviceList>
<device>
<deviceType>urn:domain-name:device:deviceType:2</deviceType>
<friendlyName>this is just a 2nd test device</friendlyName>
<manufacturer>FHEM</manufacturer>
<modelName>FHEM UPNP SEMP device 2</modelName>
<UDN>uuid:fc655837-3054-4670-b1d1-4c7e8aeada08</UDN>
<serviceList>
</serviceList>
</device>
</deviceList>
</device>
</root>
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 18 November 2021, 18:11:19
Aufgeschoben ist nicht aufgehoben. In der Zwischenzeit habe ich mit hin und wieder an dem Grundkonzept für das SEMP-Device weitergearbeitet; auch zur Umstellung auf ein zweistufiges Modulmodel.

Jetzt nehmen meine PV-Anlagen Pläne Fahrt auf. Den SMA Sunny Home Manager habe ich schon.

Stehen geblieben waren wir insbesondere bei den Blockaden des Fhem-Prozesses, sobald man die in "location" hinterlegte Adresse, wie http://192.168.6.46:4004/opt/fhem/description.xml aufruft. Zwei Testsysteme zeigen ein identisches Verhalten. Auf den beiden Systemen laufen nur die UPNPDevice Prozesse. Wechselwirkungen mit dem UPNPController können es deshalb nicht sein.

Wie könnte man die Fehler eingrenzen und beheben? Sofern das nicht in den Griff zu bekommen ist, kann man sich die weitere Arbeit zum SEMP erst einmal sparen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 18 November 2021, 21:33:28
Uih, doch noch Interesse. Mir schwante es bei Deiner Kommunikation mit Rudi zu PEN.

ZitatStehen geblieben waren wir insbesondere bei den Blockaden des Fhem-Prozesses
Da muss ich mich jetzt erst einmal wieder einfuchsen und ein SEMP-device anlegen.

Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 19 November 2021, 06:02:58
Zitat von: KölnSolar am 18 November 2021, 21:33:28
Da muss ich mich jetzt erst einmal wieder einfuchsen und ein SEMP-device anlegen.
Das wäre schön, danke.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 04 Januar 2022, 19:53:37
Hi Klaus,
habs jetzt wieder laufen.
UPNPController auf dem Produktivsystem
UPNPSEMP auf dem Testsystem

kein freeze, wenn ich die location-URL im Broser eines 3. Systems aufrufe.

Zitat
1. Ruft man die SEMP URL "location" auf, so wird der Inhalt der xlm-Datei angezeigt, danach blockiert Fhem, auf dem das UPnP-Device läuft, 40 s oder mehr. Dann kommt die Fehlermeldung

Code: [Auswählen]

2021.03.01 19:31:54 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.
Kriegst Du das rekonstruiert ?
Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 04 Januar 2022, 20:19:09
Welche Daten könnten bei der Analyse weiterhelfen? Soweit ich das beurteilen kann, steht der Perl-Prozess. Da sieht man natürlich nichts im Fhem-LOG.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 05 Januar 2022, 06:25:14
Ich müsste es ja nachgestellt bekommen. In der o.g. Konstellation gibt es keinen freeze bei mir. Folglich musst Du ja irgendeine andere Konstellation haben. Ich häng Dir mal meine  aktuelle Version an, damit wir auch hier "Gleichstand" haben.  ;)
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 05 Januar 2022, 13:14:46
Erst einmal danke, dass Du dich der Sache wieder annimmst.

Ich hatte tatsächlich noch die Version 0.0.1. Der Fehler tritt aber auch bei der Version 0.0.2 auf. Folgende Meldungen erhalte ich im LOG:
-Fhem Start

2022.01.05 12:09:46 3: UPNPDevice: device  UPNPSEMP registered with /opt/fhem/description.xml
2022.01.05 12:09:46 3: UPNPDevice: UPNPSEMP: socket device UPNPSocket-UPNPSEMP-1900.  Port: 1900 created.
2022.01.05 12:09:46 3: UPNPDevice: UPNPSEMP: socket device UPNPSocket-UPNPSEMP-4004.  Port: 4004 created.
2022.01.05 12:09:46 3: UPNPDevice: starting device UPNPSEMP
2022.01.05 12:09:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UPNPDevice.pm line 443, <FH> line 33.

Mit Aufruf von

http://192.168.6.46:4004/opt/fhem/description.xml

wird die Datei ausgegeben und danach blockiert Fhem. Nach Ende der Blockade kommen Fehlermeldungen wie diese:

2022.01.05 12:22:37 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.



2022.01.05 12:39:57 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UPNPDevice.pm line 437.
2022.01.05 12:39:57 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UPNPDevice.pm line 443.
2022.01.05 12:42:02 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.


Die Blockaden dauern unterschiedlich lange, z. B. ca. 160 s oder 350 s. Während der Blockade von Fhem kann man weiterhin

http://192.168.6.46:4004/opt/fhem/description.xml

aufrufen und erhält auch sofort eine Ausgabe. Ruft man diese Seite mehrfach während der Blockade auf, so scheint das WEB-Interface von Fhem nach drei bis fünf Aufrufen kurzeitig wieder zu reagieren. Blockiert danach aber sofort wieder.

Könnte es sein, dass der Prozess zur Ausgabe der html-Seite nicht zuverlässig schließt und später irgendein timeout zuschlägt?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 05 Januar 2022, 18:27:57
Und Du rufst das von einem Gerät ungleich 192.168.6.46 auf ?
ZitatUPNPDevice: handleOnce failed
Das sagt nur aus, dass irgendetwas auf den Ports angekommen ist und nun in der Blackbox des Perl-Pakets weiterverarbeitet wird. Dort können dann auch freezes entstehen, auf die ich keinen (direkten) Einfluss habe, weil es ja ein "fertiges" Perl-Paket ist. Bei einem freeze müssten da aber ganz andere Meldungen kommen.
Am einfachsten ist, wenn Du freezemon aktivierst. Dann sieht man wie lange(wahrscheinlich nicht wie Du beschrieben hast, sondern x*20s)einzelne freezes tatsächlich dauern und wahrscheinlich auch, ob das wirklich im Zusammenhang mit dem Browseraufruf steht und nicht vielleicht sogar generell auftritt. Freezemon hat den riesen Vorteil, dass man den verbose-level nicht extra setzen muss(wir haben ja 2 Socket-devices im Hintergrund und das UPNP-device) und man sieht im Freezemon-Log alle Log-Ausgaben eines devices zum Zeitpunkt(kurz davor und danach) des freezes.

Ob das SEMP (https://forum.fhem.de/index.php/topic,118837.msg1198264.html#msg1198264) ist ?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 06 Januar 2022, 18:53:12
Zitat von: KölnSolar am 05 Januar 2022, 18:27:57
Und Du rufst das von einem Gerät ungleich 192.168.6.46 auf?
Ja, von einem Windows Client mit Egde-Browser.
Zitat
Das sagt nur aus, dass irgendetwas auf den Ports angekommen ist und nun in der Blackbox des Perl-Pakets weiterverarbeitet wird. Dort können dann auch freezes entstehen, auf die ich keinen (direkten) Einfluss habe, weil es ja ein "fertiges" Perl-Paket ist. Bei einem freeze müssten da aber ganz andere Meldungen kommen.
Entscheidet ist, ob wir einen UPnP Dienst ans Laufen bringen, der insgesamt nicht blockiert. Der SMA Home Manager fragt in regelmäßigen Abständen von 60 s oder weniger an.

Welche Meldungen müssten denn bei einer Blockade z. B. kommen?
Zitat
Am einfachsten ist, wenn Du freezemon aktivierst. Dann sieht man wie lange(wahrscheinlich nicht wie Du beschrieben hast, sondern x*20s)einzelne freezes tatsächlich dauern und wahrscheinlich auch, ob das wirklich im Zusammenhang mit dem Browseraufruf steht und nicht vielleicht sogar generell auftritt. Freezemon hat den riesen Vorteil, dass man den verbose-level nicht extra setzen muss(wir haben ja 2 Socket-devices im Hintergrund und das UPNP-device) und man sieht im Freezemon-Log alle Log-Ausgaben eines devices zum Zeitpunkt(kurz davor und danach) des freezes.
Ein list freezemon liefert:

Internals:
   CFGFN     
   FUUID      61d72391-f33f-dda0-daa5-01a1dbc2ebf09a15
   NAME       freezemon
   NR         196
   NTFY_ORDER 99-freezemon
   STATE      s:18:17:57 e:18:19:03 f:66.594 d:tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) tmr-FW_closeInactiveClients(N/A) tmr-MQTT2_CLIENT_keepalive(MQTT_wald1_4) tmr-FHEM::Log2Syslog::calcTrate(syslog) tmr-TCM_msgCounter(TCM_ESP3_0)
   TYPE       freezemon
   VERSION    0.0.31
   .attraggr:
   .attrminint:
   READINGS:
     2022-01-06 18:19:03   .fm_freezes     2022-01-06: s:18:17:00 e:18:17:19 f:19.15 d:tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) ,2022-01-06: s:18:17:21 e:18:17:32 f:11.251 d:tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) ,2022-01-06: s:18:17:34 e:18:17:56 f:22.284 d:tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) ,2022-01-06: s:18:17:57 e:18:19:03 f:66.594 d:tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) tmr-FW_closeInactiveClients(N/A) tmr-MQTT2_CLIENT_keepalive(MQTT_wald1_4) tmr-FHEM::Log2Syslog::calcTrate(syslog) tmr-TCM_msgCounter(TCM_ESP3_0)
     2022-01-06 18:15:57   .lastDay        2022-01-06
     2022-01-06 18:19:03   fcDay           4
     2022-01-06 18:19:03   freezeDevice    tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) tmr-FW_closeInactiveClients(N/A) tmr-MQTT2_CLIENT_keepalive(MQTT_wald1_4) tmr-FHEM::Log2Syslog::calcTrate(syslog) tmr-TCM_msgCounter(TCM_ESP3_0)
     2022-01-06 18:19:03   freezeTime      66.594
     2022-01-06 18:19:03   ftDay           119.279
     2022-01-06 18:27:55   perfmon         not active
     2022-01-06 18:19:03   state           s:18:17:57 e:18:19:03 f:66.594 d:tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) tmr-FW_closeInactiveClients(N/A) tmr-MQTT2_CLIENT_keepalive(MQTT_wald1_4) tmr-FHEM::Log2Syslog::calcTrate(syslog) tmr-TCM_msgCounter(TCM_ESP3_0)
   helper:
     DISABLED   0
     TIMER      1641490118
     apptime   
     fn         
     freeze     66.5941679477692
     intCount   42
     msg        [Freezemon] freezemon: possible freeze starting at 18:17:57, delay is 66.594 possibly caused by: tmr-CODE(0x55938f1cc0)(GetUpdate) tmr-CODE(0x5593892750)(ProcessRequestQueue) tmr-FW_closeInactiveClients(N/A) tmr-MQTT2_CLIENT_keepalive(MQTT_wald1_4) tmr-FHEM::Log2Syslog::calcTrate(syslog) tmr-TCM_msgCounter(TCM_ESP3_0)
     now        1641489543.59417
     inAt:
       HASH(0x55946d9bf8)
       HASH(0x559485c460)
       HASH(0x55946fa540)
       HASH(0x559484c950)
       HASH(0x55948569e8)
       HASH(0x5594859fd8)
       HASH(0x55946e1360)
       HASH(0x559484e280)
       HASH(0x55946fa630)
       HASH(0x5594868e90)
       HASH(0x55949b0b90)
       HASH(0x5594859b40)
       HASH(0x5593226008)
     logfilequeue:
     logqueue:
Attributes:
 
Ich sehe auf Anhieb nicht, wie die Auflistung der Module, die als Verursacher in Frage kommen könnten, weiterhelfen könnte.
Zitat
Ob das SEMP (https://forum.fhem.de/index.php/topic,118837.msg1198264.html#msg1198264) ist ?
Nein, Kostal hat wohl einen Energiezähler, der UPnP nutzt. Es fehlen aber die für SEMP notwendigen Sevicebeschreibungen:

<semp:X_SEMPSERVICE xmlns:semp="urn:schemas-simple-energy-management-protocol:service-1-0">
<semp:server>http://192.168.x.y:4004</semp:server>
<semp:basePath>/opt/fhem/FHEM/lib/semp</semp:basePath>
<semp:transport>HTTP/Pull</semp:transport>
<semp:exchangeFormat>XML</semp:exchangeFormat>
<semp:wsVersion>1.1.5</semp:wsVersion>
</semp:X_SEMPSERVICE>
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 06 Januar 2022, 20:02:24
Zitatscheidet ist, ob wir einen UPnP Dienst ans Laufen bringen, der insgesamt nicht blockiert
Da sind wir uns einig.  ;)

Mit freezeemon hast Du mehrere Möglichkeiten der Überwachung/Analyse
- der aktuelle state zeigt den letzten freeze u. mögliche Verursacher
- mit verbose=3 werden die freezes im FHEMlog gelogged(lässt sich per attr freezemondevice fm_log ... verfeinern/individualisieren)
- mit get freezemondevice freezes bekommt man eine Liste der letzten 20 freezes
- Detailausgaben bekommt man durch  attr freezemondevice fm_logFile ....
  es wird ein separates file beschrieben, welches loglevel 5 zeigt
  lässt sich auch direkt über get freezemondevice log .... anzeigen

Aus Deinem list sehe ich auch nur die furchterregende freeze-Dauer. wir brauchen das freezelog.
ZitatWelche Meldungen müssten denn bei einer Blockade z. B. kommen?
Im FHEMlog z.B. UPNPDevice: handleOnce failed, $@  ($@ kommt aus perlupnp z.B. "Can't connect to IP:Port (No route to host)")

ZitatEs fehlen aber die für SEMP notwendigen Sevicebeschreibungen
Schon klar. Aber wozu sonst UPnP ohne Services ?  :-\
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 11 Januar 2022, 08:34:40
Hier mal ein LOG-Versuch mit freezemon. Vielleicht ergeben sich daraus Anhaltspunkte für weitere Überlegungen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 11 Januar 2022, 14:22:34
Lösch doch bitte mal das UPNPSocket-UPNPSEMP-1900. Das macht für unsere test ja erst einmal überhaupt keinen Sinn, da wir ja keinen echten Service anbieten.

Ich versuch dem
Zitat2022.01.11 08:14:02.535 4: UPNPDevice: UPNPSocket-UPNPSEMP-1900, received ssdp search or advertise event
--- log skips    94.954 secs.
2022.01.11 08:15:37.494 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.
2022.01.11 08:15:37.495 4: UPNPDevice: UPNPSocket-UPNPSEMP-4004, received message on HTTP handler port: 4004, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.
mal auf den Grund zu gehen.

Mit welchem Browser arbeitest Du ? Ggfs. mal mit MS Edge probieren, damit ich das nachstellen kann.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 11 Januar 2022, 15:58:09
Zitat von: KölnSolar am 11 Januar 2022, 14:22:34
Lösch doch bitte mal das UPNPSocket-UPNPSEMP-1900. Das macht für unsere test ja erst einmal überhaupt keinen Sinn, da wir ja keinen echten Service anbieten.
Mir ist nicht klar, wie das erreicht werden kann. Diesen Serviceport habe ich - wissentlich - nicht aktiviert. Aktiviert habe ich das Modul mit

define UPNPSEMP UPNPDevice

und mit den Daten aus dem bekannten description.xml File vorsorgt.
Zitat
Mit welchem Browser arbeitest Du ? Ggfs. mal mit MS Edge probieren, damit ich das nachstellen kann.
MS Edge
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 11 Januar 2022, 19:08:41
ZitatDiesen Serviceport habe ich - wissentlich - nicht aktiviert
Schon klar...
einfach nur delete UPNPSocket-UPNPSEMP-1900in FHEM

Solltest Du ein shutdown restart machen, dann immer danach dieses device löschen, weil es automatisch angelegt wird.

Zitatmit den Daten aus dem bekannten description.xml File vorsorgt.
Da kommt mir dann in den Sinn das mal wirklich abzugleichen. Ich starte mit

define UPNPSEMP UPNPDevice
attr UPNPSEMP file /opt/fhem/SEMPdevice.xml
attr UPNPSEMP path /opt/fhem/
attr UPNPSEMP verbose 5

und SEMPdevice.xml
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:domain-name:device:deviceType:ver</deviceType>
<friendlyName>this is just a test device</friendlyName>
<manufacturer>FHEM</manufacturer>
<modelName>FHEM UPNP SEMP device</modelName>
<UDN>uuid:fc655837-3054-4670-b1d2-4c7e8aeada08</UDN>
<serviceList>
</serviceList>
<deviceList>
</deviceList>
<semp:X_SEMPSERVICE
xmlns:semp="urn:schemas-simple-energy-management-protocol:service-1-0">
<semp:server>http://IP[:port]</semp:server>
<semp:basePath>/SEMP</semp:basePath>
<semp:transport>HTTP/Pull</semp:transport>
<semp:exchangeFormat>XML</semp:exchangeFormat>
<semp:wsVersion>x.y.z</semp:wsVersion>
</semp:X_SEMPSERVICE>
</device>
</root>
Aufruf in MS Edge ergibt dann völlig freezefrei<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:domain-name:device:deviceType:ver</deviceType>
<friendlyName>this is just a test device</friendlyName>
<manufacturer>FHEM</manufacturer>
<modelName>FHEM UPNP SEMP device</modelName>
<UDN>uuid:fc655837-3054-4670-b1d2-4c7e8aeada08</UDN>
<serviceList> </serviceList>
<deviceList> </deviceList>
<semp:X_SEMPSERVICE xmlns:semp="urn:schemas-simple-energy-management-protocol:service-1-0">
<semp:server>http://IP[:port]</semp:server>
<semp:basePath>/SEMP</semp:basePath>
<semp:transport>HTTP/Pull</semp:transport>
<semp:exchangeFormat>XML</semp:exchangeFormat>
<semp:wsVersion>x.y.z</semp:wsVersion>
</semp:X_SEMPSERVICE>
</device>
<URLBase>http://MeineFHEMIP:4004</URLBase>
</root>
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 11 Januar 2022, 20:04:17
Ich hab die Konfiguration entsprechend eingestellt.

Beim ersten Aufruf von

http://192.168.6.46:4004/opt/fhem/SEMPdevice.xml

gab es auf den ersten Blick diesmal kein Problem. Ich habe dann ein paar Sekunden später nochmals einen Aufruf abgesetzt, der beantwortet wurde, aber dann blockierte. Wie schon letztlich beschrieben, scheint sich bei mehrmaligen Aufrufen - in Abständen von einigen Aufrufen - kurzzeitig die Blockade zu lösen.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 11 Januar 2022, 20:11:13
ZitatBeim ersten Aufruf von http://192.168.6.46:4004/opt/fhem/SEMPdevice.xml
gab es auf den ersten Blick diesmal kein Problem. Ich habe dann ein paar Sekunden später nochmals einen Aufruf abgesetzt, der beantwortet wurde, aber dann blockierte. Wie schon letztlich beschrieben, scheint sich bei mehrmaligen Aufrufen - in Abständen von einigen Aufrufen - kurzzeitig die Blockade zu lösen.
Das ist halt wieder subjektiv. Du kennst doch jetzt freezemon.  ;) Ich ruf das zigmal hintereinander oder in größeren Abständen auf: kein freeze in freezemon sichtbar.

Mir gehen die Ideen aus, was in Deiner Umgebung anders als bei mir ist.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 12 Januar 2022, 09:05:52
Vielleicht finden wir eine andere Möglichkeit, die Abläufe bei den Blockaden transparent zu machen. Freezemon scheint da wohl nicht weiterzuhelfen. Die letzte LOG-Datei umfasst den Zeitraum, indem ich die Beschreibungsdatei mehrfach abgerufen habe und das System blockiert war.

Auf meinen Systemen sind neben dem UPnP Prototyp insbesondere die Module TCM, EnOcean und PIFACE aktiv. In allen Modulen laufen an mehreren Stellen Timer über die Funktion InternalTimer; bei PIFACE z. B. im Sekundentakt. Timingprobleme oder Blockaden haben sich daraus aber bisher nie ergeben. Auch pendelt sich die CPU-Auslastung bei einem Raspberry 4B im stationären Betrieb auf 2 % bis 5 % ein, beim Raspberry der ersten Generation sind es ca. 20 % CPU-Last.

Ich frage mich allerdings, ob es da einen Zusammenhang geben kann. Nur habe ich keine Idee, wie man das verifizieren könnte. Klar erst einmal UPnP-Test ohne diese Module. Aber wie könnte es weitergehen, wenn sich die Vermutung bestätigt oder auch nicht?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 12 Januar 2022, 11:38:53
Der Fehler tritt auch in einer Konfiguration auf, die ausschließlich UPNPDevice enthält. Fehlerursachen sind im freezelog nicht zu finden, siehe Anlage.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 13 Januar 2022, 07:20:13
Hi Klaus,
das hab ich kaum anders erwartet.
Mittlerweile bin ich mir sicher, dass der Unterschied in unseren System viel "tiefer" liegt. Nämlich in den Perl-Paketen wie HTTP, SOAP.... Die lassen sich dann weder debuggen, noch werfen sie Logausgaben aus. Ich hab mir damals eigene Print-Ausgaben eingebaut, um "näher" an die freeze-Verursacher zu kommen. Es kann auch sein, dass ich dort etwas modifiziert habe. Sehe dort aber kein Eingreifen meinerseits. In meinen Aufzeichnungen habe ich nur gefunden, dass auch ich damals irgendwelche freeze-Problem hatte, die in einem System vorhanden waren, im anderen nicht.
Ich kann jetzt nur hingehen und erst einmal mein System(Rpi/buster) komplett auf einen "frischen" Auslieferungszustand bzgl. Perl(und perlupnp) zurücksetzen.

Was mich bei Deinen freezes wundert, ist das völlig undefinierte Zeitverhalten. Die freezes, die ich bisher im Zusammenhang mit perlupnp kenne, basieren immer auf irgendwelchen HTTP-Zugriffsproblemen, die wenigstens über "timeouts" regelmäßig waren. Z.B. immer 20s. Außerdem sind entsprechende Probleme immer in perlupnp mit carp/croak "abgefangen". Durch ein eval meinerseits lässt sich dann der Absturz verhindern und die Meldung loggen.

Mir scheint, dass Dein Problem ganz woanders liegt(sowas wie ne firewall ?). Du müsstest also mal ein bißchen mehr Statistik über das freeze-Verhalten machen, damit wir überhaupt mal eine Idee entwickeln können, wo es klemmt. Vielleicht auch mal den Datentraffic aufzeichnen(Wireshark/tcpdump) und analysieren.

Welche OS-Version und Releasestand hast Du ?

Grüße Markus

Edit: Gerade ist mir noch in den Sinn gekommen, dass der UPNPController seine Server ja auch nicht anders aufbaut. Im Gegensatz zu UPNPDevice ist es aber auf einigen Systemen problemlos. Läuft der UPNPController(mit freezemon) auf Deinem Testsystem problemlos ? Werden DLNA-devices automatisch angelegt, was dann bedeuten würde, dass auch der subscription process mit seinem Server problemlos läuft ?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 14 Januar 2022, 08:38:18
Auf den Servern läuft Raspberry Pi OS Buster in der jeweils aktuellen Version, Raspi 1B mit 32 bit oder Raspi 4B mit 64 bit. Folgende Pakete sind installiert:


perl libdevice-serialport-perl libio-socket-ssl-perl libwww-perl libdatetime-format-strptime-perl
liblist-moreutils-perl libxml-simple-perl libtext-csv-perl libarchive-extract-perl libcrypt-rijndael-perl
libcrypt-random-source-perl libstring-random-perl libdata-random-perl libyaml-perl sendemail libjson-perl
sqlite3 libdbd-sqlite3-perl libtext-diff-perl libdbi-perl libcgi-pm-perl libio-socket-multicast-perl libdigest-crc-perl
unattended-upgrades wiringpi libmodule-pluggable-perl git ser2net
libwww-perl libsoap-lite-perl libxml-parser-lite-perl


Der UPNPController auf dem Raspi 1B scheint problemlos zu laufen. Die UPnP-Devices im Netz werden alle gelistet.

Es gibt zwar viele freezemon-Meldungen, siehe Anlage. Das scheint mir aber auf das laufenden PIFACE-Modul zurückzuführen zu sein. Das startet im Sekundentakt mehrere Aufrufe auf Shell-Ebene über wiringpi zur Abfrage der GPIOs. Die durchschnittliche CPU-Last des Servers liegt bei ca. 20 % bis 25 %. Das Modul freezemon scheint auch zusätzlichen einen Anteil daran zu haben. Ein Raspi 1B ist nicht der schnellste.

Blockaden im Datentransfer sehe ich nicht. Die Geräte hängen alle an internen Switchen ohne Firewallfunktionen oder Portsperren.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 14 Januar 2022, 10:25:04
[Freezemon] freezemon: possible freeze starting at 01:55:01, delay is 1.235 possibly caused by: tmr-PIFACE_GetUpdate(N/A) tmr-PIFACE_Watchdog(N/A)
2022.01.14 01:55:00.565 5: UPNPController: incoming message; will be processed by perlupnp handleOnce
2022.01.14 01:55:00.573 5: UPNPController: UPNPSocket-UPNP_Controller-1900, received ssdp event: was checked by discoverCallback for removed or added devices against pending search requests
2022.01.14 01:55:01.553 5: UPNPController: incoming message; will be processed by perlupnp handleOnce
2022.01.14 01:55:01.554 5: UPNPController: UPNPSocket-UPNP_Controller-1900, received ssdp event: was checked by discoverCallback for removed or added devices against pending search requests
2022.01.14 01:55:02.236 5: [Freezemon] freezemon: ----------- Starting Freeze handling at 2022.01.14 01:55:02.235 ---------------------
[Freezemon] freezemon: possible freeze starting at 01:55:01, delay is 1.235 possibly caused by: tmr-PIFACE_GetUpdate(N/A) tmr-PIFACE_Watchdog(N/A)
Ich glaube fast, dass Du richtig liegst wegen der Einschätzung zu piface. Ich weiß leider auch nicht, wie freezemon auf die Idee kommt , dass der freeze von piface sein könnte. Aber wenn man auf die Log-Zeilen guckt, sieht man immer wieder ein ähnliches Muster: es kommt ein ssdp-event rein, wird blitzschnell verarbeitet und mit der "was checked" Meldung wird das Modul beendet. Danach tritt dann der freeze auf. Im obigen Log-Extrakt gut zu erkennen, dass nach Beendigung des Moduls 1s später erst die nächste message zur Verarbeitung startet, ohne dass ein FHEM-Logging dazwischen liegt.
Nur für meine Neugierde: Weißt Du, ob diese piface-Zugriffe per BlockingCall laufen ?

ZitatDie UPnP-Devices im Netz werden alle gelistet.
Und da sind auch devices mit DLNA dabei, die per autocreate angelegt und deren services subscribed wurden ?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 22 Januar 2022, 21:47:42
Seeeehr mühsam bin ich weiter. Ich denke es ist ein LAN/WLAN Problem. Ersetze mal die UPNPDevice_setupDevice mitsub UPNPDevice_setupDevice {
  my ($hash) = @_;
  my $name = $hash->{NAME};
  my $error;
  my $file = AttrVal($name,"file","/opt/fhem/description.xml"); #SEMPdevice.xml
  my $path = AttrVal($name,"path","/opt/fhem/");
  my $port = AttrVal($name,"port","4004");

  if (open(my $handle,"<",$file)) {
     close $handle;
  do {
$hash->{helper}{device} = $hash->{helper}{dm}->registerDevice(DevicePort => $port,
DescriptionFile => $file,   
DescriptionURI => $file,
ResourceDirectory => $path);
if($@) {
   $hash->{helper}{device} = undef;
   $error = "registration failed with error $@";
   Log3 $hash, 2, "UPNPDevice: device $name. $error";
   readingsSingleUpdate($hash,"state",$error,1);
   return $error;
}
else { 
   Log3 $hash, 3, "UPNPDevice: device $name returned handler-socket ".$hash->{helper}{device}{_handler}->socket." listening on port ".$hash->{helper}{device}->{_handler}->socket->sockport;
   Log3 $hash, 5, "UPNPDevice: device $name details: descriptionURI: ".$hash->{helper}{device}{_handler}->{_descriptionURI}.", DeviceDescription: ".$hash->{helper}{device}{_handler}->{_description}.", ResourceDirectory: ".$hash->{helper}{device}{_handler}->{_resourceDir}.", Server: ".$hash->{helper}{device}{_handler}->{_server};
   $hash->{helper}{device}{_handler}->socket->timeout(1); #avoid freezes longer than 1s
   UPNPDevice_addSocketDeviceToMainloop($hash);
}
   } # while($error);
  }
  else {
     Log3 $hash, 2, "UPNPDevice: device  $name failed to open $file $!";
  } 

  readingsSingleUpdate($hash,"state","registered",1);

  return undef;
}
was den freeze auf 1s begrenzen sollte.

Der
2022.01.05 12:22:37 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.
steht im Zusammenhang. Ist im FHEM/lib/UPnP/DeviceManager.pm nicht sauber programmiert, aber nicht so wichtig(Halten wir mal im Hinterkopf ggfs. das perlupnp zu modifizieren.)
Grüße Markus
PS: Das Ganze hatte aber wenigstens den positiven Lerneffekt, dass ich auf eine andere Modifikation in perlupnp verzichten kann und denselben Effekt im FHEM-Modul erreiche. 8)
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 23 Januar 2022, 10:23:02
Danke für die weitere Fehleranalyse.
Zitat
Ich denke es ist ein LAN/WLAN Problem.
Grundsätzlich oder u. U. bei meiner Netz- / oder Serverkonfiguration?

Nach dem Tausch des Routine UPNPDevice_setupDevice startet Fhem ständig neu. Die dort aufgerufene Routine UPNPDevice_addSocketDeviceToMainloop kann in UPNPDevice nicht gefunden werden. Ist diese identisch zur bisherigen Routine UPNPDevice_addSocketsToMainloop?
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 23 Januar 2022, 11:22:39
ZitatGrundsätzlich oder u. U. bei meiner Netz- / oder Serverkonfiguration?
Ich denke grundsätzlich. Alles sehr ominös(für mich). Die freezedauer ist performance-abhängig, weshalb bei Deinem Rpi1 sehr lange freezes auftreten.
ZitatDie dort aufgerufene Routine UPNPDevice_addSocketDeviceToMainloop kann in UPNPDevice nicht gefunden werden
Sorry. Bei mir ist viel mehr geändert. Lass diese Zeile einfach weg.
Ich brauch noch etwas bis zur nächsten Version.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 23 Januar 2022, 12:45:44
Bei den ersten Tests kann ich keine Blockaden mehr feststellen. freezemon liefert auch keine Meldungen mehr. Es kommen aber weiterhin Meldungen wie:

2022.01.23 12:31:25 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.


Auch kann man das Attribut "file" nicht per Kommando ändern. Die WEB-Seite reagiert danach für einige Sekunden nicht mehr. Die Änderungen werden nicht übernommen. freezemon liefert aber keine Meldung. Falls man statt dessen das fhem.cfg manuell editiert, werden die Änderungen nach einem Restart übernommen. Wenn ich mich recht erinnere, ist das aber ein bereits bekannter Fehler.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 23 Januar 2022, 13:11:12
ZitatBei den ersten Tests kann ich keine Blockaden mehr feststellen
sehr schön
Zitat2022.01.23 12:31:25 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.
Schrieb ich ja.Kannst Du ignorieren.
ZitatAuch kann man das Attribut "file" nicht per Kommando ändern
Gemach. daran arbeite ich aktuell.
Mach Du mal Deine SEMP-Konfiguration, dass wir feststellen, was das Modul noch können muss.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 31 Januar 2022, 19:36:48
Neue Version im Entwicklungsthread veröffentlicht. Fehlerbehebungen, keine neuen Funktionalitäten.

Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 06 Februar 2022, 09:49:52
Danke für die Überarbeitungen. Bei der Ausgabe des XML-Datei treten jetzt manchmal Blockaden auf. In diesen Fällen wird eine Abfrage wie

http://192.168.6.46:4004/opt/fhem/description.xml

erst nach Ende der Blockade beantwortet. Vorher meldet der Browser, die Seite sei nicht erreichbar. Im Fhem log kommt die Meldung:

2022.02.06 09:27:39 3: UPNPDevice: UPNPSocket-UPNPSEMP-4004, message from 192.168.6.138:51260: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.

2022.02.06 09:27:42 1: PERL WARNING: Use of uninitialized value $client_port in concatenation (.) or string at ./FHEM/98_UPNPDevice.pm line 188.
2022.02.06 09:27:42 3: UPNPDevice: UPNPSocket-UPNPSEMP-4004, message from :: handleOnce failed, accept: timeout
2022.02.06 09:27:42 1: [Freezemon] freezemon: possible freeze starting at 09:27:41, delay is 1.407 possibly caused by: tmr-CODE(0x55b7ded338)(GetUpdate) tmr-CODE(0x55b7d8be28)(ProcessRequestQueue)

freezemon liefert:

2022-02-06_09:27:42 freezemon s:09:27:41 e:09:27:42 f:1.407 d:tmr-CODE(0x55b7ded338)(GetUpdate) tmr-CODE(0x55b7d8be28)(ProcessRequestQueue)
2022-02-06_09:27:42 freezemon freezeTime: 1.407
2022-02-06_09:27:42 freezemon fcDay: 1
2022-02-06_09:27:42 freezemon ftDay: 1.407
2022-02-06_09:27:42 freezemon freezeDevice: tmr-CODE(0x55b7ded338)(GetUpdate) tmr-CODE(0x55b7d8be28)(ProcessRequestQueue)

Die Blockaden dauern - soweit ich das sehen kann - unter zwei Sekunden.

Bei den Anfragen, die unmittelbar ohne Blockaden beantwortet werden, werden keine log-Meldungen ausgegeben. Bisher war ja auch in diesen Fällen Meldungen wie

... Can't call method "uri" on an undefined value ...

zu sehen.

Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 06 Februar 2022, 16:10:40
Hi Klaus,
ja, das ist die Modifikation, die ich vor ein paar Posts beschrieben hatte. Ausschließen lässt sich der freeze nicht. Nur reduzieren.
ZitatMach Du mal Deine SEMP-Konfiguration, dass wir feststellen, was das Modul noch können muss.
Und dann kann man sich die Mühe machen das Ganze non-blocking zu realisieren(womit es immer noch eine unschöne Response time gäbe aber FHEM nicht mehr behindert wird).
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 16 Februar 2022, 18:27:10
Gut dann als nächsten Schritt ein Vorschlag zur Umstellung auf ein zweistufige Modulkommunikation.

Auch könnte man ggf. den Modul-Start von UPNPDevice noch automatisieren, indem man in den nachgelagerten Modulen prüft, ob das passende IODev (UPNPDevice) definiert ist.

Falls das grundsätzlich so machbar wäre, müssten wir festlegen, wie wir die notwendigen Anpassungen in UPNPDevice organisieren. Um das SEMP-Modul kümmere ich mich natürlich.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 17 Februar 2022, 09:41:07
Hallo Klaus,
kann man ja alles so machen. Bevor ich weiteren Aufwand investiere, möchte ich aber erst einmal Deine konkrete Anwendung/Konzept zu SEMP sehen.
Zitat
Mach Du mal Deine SEMP-Konfiguration, dass wir feststellen, was das Modul noch können muss.
Ich entwickle daran ja nicht, weil ich Spaß an Perl habe, sondern weil ich notwendige/hilfreiche Funktionalität für FHEM bereitstellen möchte. Das erfüllt die jetzige Version ja jetzt bereits. Wenn Automatismen fehlen, lässt sich das zumindest halbmanuell durchspielen.
Den Umgang mit dem 2-stufigen Modulkonzept kriege ich problemlos hin, da ich das über UPNP-/DLNAController ganz gut gelernt habe.  ;)
Grüße Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: justme1968 am 17 Februar 2022, 10:47:54
nicht um hier etwas weg zu nehmen, sondern weil ich denke upnp/ssdp und mdns/dns-sd zusammen gehören: ich habe hier gerade eine erste version einer mdns/dns-sd implementierung für fhem gepostet: https://forum.fhem.de/index.php/topic,126262.0.html .

auch wenn ich gerade nicht besonders schnell mit dem thema und dem netdiscover modul bin gibt es einige berührungspunkte und es wäre schön wenn zumindest die dinge wie das automatische sammeln der daten im hintergrund und diese dann für andere module bereitstellen nicht komplett auseinander laufen.

ps: ihr scheint zumindest zum teil vorhandene perl upnp libs zu verwenden, mein ziel ist bisher vor allem so weit es geht ohne externe module auszukommen. ich hoffe auch das beisst sich nicht.
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 07 Juli 2022, 16:23:42
Nun kann ich die Funktionalität des Moduls UPNPDevice zusammen mit dem SEMP testen. Der Prototyp des SEMP Web-Service Dienstes in Fhem ist fertig, sodass alle Funktion für den Test der Kommunikation mit dem Home Manager vorhanden sind. Leider reagiert der Home Manager nicht auf die NOTIFY-Telegramme des UPNPDevice Modules. Folgendes ist mir aufgefallen:

1. Die UPnP Device Beschreibung (description.xml) wird von diesem nicht auf Fhem abgerufen. Die ssdp-Telegramme sehen auf den ersten Blick gut aus. Ungewöhnlich sind die Steuerzeichen an den Zeilenenden - \n statt \r\n -. Vielleicht hat der Home Manager damit ein Problem. Die mitgeschnittenen Telegramme sind in der angehängten Textdatei zu finden.

2. Die NOTIFY  ssdp:byebye-Telegramme werden beim FHEM shutdown nicht gesendet. Mit dem Kommando "stop" klappt es.

3. Der Home Manager sendet regelmäßig M-Search Requests. Das Modul UPNPDevice antwortet darauf aber nicht. Ein Beispiel für ein passendes M-Search Response ist ebenfalls in der Textdatei enthalten.

4. Im SEMP Kontext wird erwartet, dass die NOTIFY ssdp:alive Telegramme z. B. bei CACHE-CONTROL: max-age = 1800 in Abständen von ca. 900 s gesendet werden. Das Modul UPNPDevice sendet derzeit alle 1800 s. Ob das eine SEMP-Besonderheit ist oder so im ssdp-Standard vorgesehen ist, kann ich augenblicklich nicht beurteilen.

Um beim SEMP-Modul wirklich weiterzukommen, benötige ich erst einmal eine funktionsfähige Kommunikation mit dem Home Manager. Aus den Unterlagen ist für mich nicht eindeutig zu erkennen, wie das SEMP-Gateway in Fhem zur Steuerung mehrerer Devices gestaltet werden muss. Das sollte sich aber klären, sobald die Kommunikation mit einer Testkonfiguration klappt.

In der Datei description.xml gab es noch einen Fehler. Deshalb sende ich diese nochmals.

Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: KölnSolar am 07 Juli 2022, 21:36:11
Hi Klaus,

schön, dass Du noch dran bist. Im Augenblick hab ich wenig Zeit, aber ich probier mal auf die Fragen einzugehen.

1. Kann ich mir eigentlich nicht vorstellen, dass das Probleme macht. Der UPNPController hat ja auch keine Probleme damit. Man könnte jetzt höchstens noch die messages von anderen UPNP-devices darauf prüfen.

2. OK, aber erst einmal nicht wichtig.

3. Dann mal ein Log mit verbose 5, damit wir sehen, ob etwas auf Port 1900 empfangen wird. Angelegt wird der Socket mit     SSDP_IP => "239.255.255.250",  SSDP_PORT => 1900,
    Haben wir vielleicht Probleme, weil der UPNPController auch auf diesem Port lauscht ? Müsste man evtl. dann mal im UPNPController-Hilfsdevice(UPNPSocket-DEINUPNPControllername-1900) loggen.

4. Ist eine Besonderheit. Könnte man über ein Attribut steuern. Was passiert denn, wenn nicht alle 900s gesendet wird ?
    Du kannst erst einmal in der Funktion UPNPDevice_setupDevice den Aufruf $hash->{helper}{device} = $hash->{helper}{dm}->registerDevice(DevicePort => $port,
DescriptionFile => $file,   
DescriptionURI => $file,
ResourceDirectory => $path);
in $hash->{helper}{device} = $hash->{helper}{dm}->registerDevice(DevicePort => $port,
LeaseTime       => 900,   
DescriptionFile => $file,   
DescriptionURI => $file,
ResourceDirectory => $path);
ändern.

Grüße
Markus
Titel: Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
Beitrag von: klaus.schauer am 28 Juli 2022, 16:53:12
Danke für die Unterstützung und Rückmeldung.

zu 1.: Ich kann das - wie gesagt - nicht prüfen, da der Home Manager nicht reagiert. Ich habe das Modul DeviceManager angepasst, siehe geänderte Datei. Jetzt wird \r\n statt \n gesendet. Das führt aber - soweit ich das sehen kann - nicht zu einer Veränderung.

zu 3.: Im Log werden keine empfangenen Pakete protokolliert.

zu 4.: Der Home Manager erwartet bei CACHE-CONTROL: max-age = 1800 nach ca. der Hälfte der Zeit schon ein Notity. Da hilft es nichts max-age auf 900 zu verkürzen.

Da ich leider augenblicklich in der vorhandenen Konstellation nicht weitergekommen bin, habe ich erst einmal eine andere funktionsfähige Lösung gesucht und gefunden. Ich verwende den Smart Appliance Enabler (https://github.com/camueller/SmartApplianceEnabler), der als SEMP Gateway fungiert. Die Kommunikation von Fhem zu dem Smart Appliance Enabler stellt das neue Modul HTTPAPI her. Das klappt sehr gut. Ich stelle das Modul umgehend für alle Interessierte zur Verfügung.

Nochmals vielen Dank für die Unterstützung. Falls die ursprünglich geplante Lösung doch noch ans Laufen gebracht werden kann, würde mich das freuen. Manchmal sind es ja nur Kleinigkeiten... wenn man sie denn findet. Ich werde jedenfalls dran bleiben.