Autor Thema: UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul  (Gelesen 4733 mal)

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
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?
« Letzte Änderung: 11 Januar 2021, 13:51:29 von klaus.schauer »

Offline amenomade

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7416
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #1 am: 24 September 2020, 14:32:21 »
Ich glaube, das SONOS Modul implementiert UPnP. Aber wahrscheinlich nur zum Zweck des Moduls.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #2 am: 24 September 2020, 15:30:03 »
im DLNARenderer ist UPnP implementiert.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #3 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.   

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #4 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?

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #5 am: 10 Januar 2021, 13:56:49 »
Zitat
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
Genau.
Zitat
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?
Bin mir unsicher, ob das hinhaut. Was ist die "Zentrale" ? Controler, Renderer, Server....?
Zitat
Welche 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Online Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8007
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #6 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

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #7 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #8 am: 10 Januar 2021, 19:27:06 »
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/.

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.

Online Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8007
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #9 am: 10 Januar 2021, 20:03:45 »
Zitat
Upnp/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
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #10 am: 10 Januar 2021, 21:26:58 »
Zitat
Meine erste Idee war, dort zu trennen, wo es devicespezifisch wird
Da meinen wir dasselbe. Danach wird es etwas unverständlicher. :-[
Zitat
Perl Paket UPnP http://perlupnp.sourceforge.net/.
Das paket kenn ich ja recht gut. ABER  von 2004  ???
Vielleicht sollten wir dann eher auf 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.
« Letzte Änderung: 10 Januar 2021, 22:25:49 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #11 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.
« Letzte Änderung: 11 Januar 2021, 06:28:55 von klaus.schauer »

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #12 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.
Zitat
Weiterhin 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


 


RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) in Fhem verfügbar?
« Antwort #13 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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #14 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 u. hier findest Du ein paar ergänzende Informationen zu Installation, Funktionsweise ... des DLNARenderers. Das UPNPControlpoint verhält sich gleich.
Edit2: Ah, verstehe. Du brauchst
Zitat
The 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
« Letzte Änderung: 12 Januar 2021, 23:42:51 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #15 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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #16 am: 12 Januar 2021, 19:48:38 »
Zitat
Der wird derzeit mal mit "-" vorab sowie in HEX-Groß- und Kleinschreibung ausgeben
Das ist ein Problem, das mir vorher nicht bewusst war. Eigentlich ist der ja viiiieeeel länger.Am Beispiel der Fritte 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.
Zitat
Fhem muss nicht als ControlPoint sondern als DeviceManager agieren.
Was soll denn der DeviceManager sein ? Das Gateway ?

Edit: Modulversion removed.
« Letzte Änderung: 18 Januar 2021, 20:35:23 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #17 am: 16 Januar 2021, 10:58:45 »
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.
« Letzte Änderung: 16 Januar 2021, 11:13:46 von klaus.schauer »

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #18 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_\.-)

Offline gvzdus

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 825
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #19 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.

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #20 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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #21 am: 18 Januar 2021, 20:34:03 »
dann lösen wir uns mal wieder von dem SMA-Thema und kommen zum Kern zurück

Zitat
Der Name der Readings wird im LOG als fehlerhaft ausgewiesen:
Ja, korrekt. Ich glaub die Doppelpunkte stören... Ändere ich erst einmal nicht, weil ich nicht den spontanen Gedanken habe, wie ich die "übliche" Darstellung von IP:Port zu FHEM-konformen readingnames vergewaltigen soll.  ::)
Zitat
Wichtig wäre, die unterschiedlichen Rohdaten im Basismodul zu normalisieren.
Das sehe ich anders. Der "Fehler" liegt ja im device bzw. beim Hersteller. Bei unendlich vielen Fehlermöglichkeiten sehe ich da erst recht die Transparenz, dass das anders gehandhabt wird, im Vordergrund.
Zitat
Sonst wäre das im Einzelfall in den nachgelagerten Modulen notwendig.
Jein. Ich sehe im nachgelagerten Modul gar keinen Bedarf etwas zu korrigieren. Es handelt sich ja um Schlüssel, die das device vorgibt. Die werden für die Kommunikation in FHEM benutzt. Für die Anwendung hat das gar keine Bedeutung.
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.
Ich muss mich korrigieren. UDN wird auch in der UPNP-Spec genauso erwähnt.
Zitat
Da ein Gerät mehrere uuid: bekannt machen kann, wäre es wahrscheinlich sinnvoll für jede uuid ein nachgelagertes Device anzulegen.
Hier scheiden sich die Geister, was das Modul überhaupt können/machen soll. Ich fasse mal aus meiner Sicht zusammen:Basis: Perl-Paket UPNP::Controlpoint(modifizierte Version aus ..../FHEM/lib/UPNP/.....)
- zentraler UPNP-Controller in/für FHEM
- exclude/include UDN/IP (nutzerabhängiger Filter)
- alleinig auf Port 1900 lauschen--> per ReadFn zur Verarbeitung per handleOnce eingehende notify-messages verarbeiten(readings zum device anlegen;presence-status offline/online(Stecker ziehen bewirkt keine status-Änderung !!!))
- M-Search requests: bei define u. per set-Befehl mit separatem port(ermittelt über Controlpoint), Verarbeitung eingehender responses wie zuvor beschrieben
- subscription, subscription renewal, unsubscription, event-handling; über einen 3. port(ermittelt über Controlpoint)
  - subscription individuell(per Anforderung durch ein UPNP-client-device oder manuell per set)
  - unsubscription individuell(per Anforderung durch ein UPNP-client-device oder manuell per set)
  - renewal der subscription automatisch
  - "Dokumentation" des subscription-status über ein einzelnes service-reading mit den Zuständen:
      - a) urn nach Ermittlung des services b) "subscribe" nach subscription c) nach subscription response: SID, timeout, property d) subscription/renewal failure e) "unsubscribe" nach unsubscription f) earlier subscribed service .... of device ....went offline
  - Empfang von events  eines physischen devices und Weiterleitung  an das UPNP-client-device(vergleichbar 2-stufige Module)
- autocreate von UPNP-client-devices sehe ich im Augenblick nicht. Aktuell haben wir einerseits das SONOS-Modul, welches individuell für einen Hersteller/devicetyp zugeschnitten ist. Andererseits den DLNARenderer, der mit DLNA einen unabhängigen Standard unterstützt. Ich persönlich finde eine Übersicht ALLER devices informativ(möchte sie also eher gar nicht ausfiltern). Andererseits kann ich mir kaum vorstellen, dass es UPNP-client-Module zur FritzBox od. WindowsMediaplayer oder miniDLNA….. geben wird.
UPNP-client-Modul:
- definition(über IP:Port) nur möglich, wenn auch bereits im Controller-device vorhanden
- initiale subscription-Anforderung kommt aus dem Modul
- events(Status-Änderungen) kommen raw vom Controller-Modul; konkrete Verarbeitung erfolgt im client-Modul
- actions(Befehle an das physische device) werden in  dem client-Modul detailliert definiert und über das Controllermodul(ohne dortige Prüfung der message) an das physische device gesendet
Insgesamt hätten wir dann 4+x devices(das eigentliche device + 3 socket-devices(eins je Port)+x client-devices)

Die attachte Version kann nun die beschriebenen Basisfunktionen. für subscribe/unsubscribe muss man den readingnamen als Parameter in den set-Befehl kopieren(später dann als Liste zur Selektion vorgegeben).

Was natürlich noch nicht geht ist die Übertragung an/von client-FHEM-devices, weil es ja noch kein entsprechendes Modul  gibt. Ich denke, dass sich der FHEM-Standard für 2-stufige Module anwenden lässt(habe ich zwar noch nie gemacht, aber der Theorie nach sollte es funktionieren). Meine nächste task ist dann, das DLNARenderer Modul für eine 2-Stufigkeit vorzubereiten, also alles was mit search, subscription zu tun hat generell rauszuschmeissen und zusätzlich die Schnittstelle zum UPNPController zu entwickeln.

Die derzeitige Version sollte vorerst nur in Testumgebungen eingesetzt werden. Nicht nur, weil es FHEM in die Knie zwingen könnte(bei mir läufts problemlos), sondern eher noch, weil es ja Wechselwirkungen zum DLNARenderer- u./o. SONOS-Modul geben könnte, da die ja heute auf port 1900 lauschen und sich um das UPNP-discovery,subscribing kümmern. Genau das soll das neue Modul dann später zentral machen.

Kommentare, Vorschläge, Ergänzungen zum Grundkonzept u. der Testversion wie immer willkommen.

Have fun
Markus


Edit: Vielleicht noch kurz für die, die an dieser Stelle erst hineinstolpern: Definition ganz simpel define DeinUPNPController UPNPControllerdanach geht alles wie von selbst und über die Zeit sammeln sich die readings, so dass man dann erst einmal mit dem Verständnis der Vielzahl der devices beschäftigt ist. ;D
« Letzte Änderung: 18 Januar 2021, 20:50:20 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #22 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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #23 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #24 am: 23 Januar 2021, 10:29:14 »
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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #25 am: 23 Januar 2021, 13:32:48 »
Zitat
Ich versehe das so, dass darüber nach der Registrierung die eigentliche Kommunikation zwischen Device und Controlpoint läuft und das UPnP-Modul den Port überwacht
Nein. Das ist lediglich der Port von dem bzgl. UPNP gesendet(an SHM:1900) u. empfangen wird. In der NOTIFY message des devices(gateway) werden dem SHM server u. port des http-servers des devices für SEMP mitgeteilt. Könnte also sogar ein anderes physisches device sein.
Daher scheint mir das auch so easy bzgl UPnP.
Zitat
jeweils ein gerätespez. IP-Port zu definieren
Ich denke, das Perl-Paket legt die Verbindung an u. das Modul holt sich den Port.

Zitat
X_Parse- und X_Write-Funktionen sowie das Matching des zweistufigen Modulmodells
Da ja gar keine "echte" Kommunikation stattfindet, braucht es das glaub ich gar nicht.

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

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

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

Das wars aus meiner Sicht. Attributsteuerung ?

Edit: Ich bin so weit. Nur leider wurde ich bestätigt: Es "krallt" sich den Port 1900. Gut, dann wieder schließen und UPNPControlpoint danach definieren. Aber dann gehen die requests vom SHM unter. Keine Idee wie ich das dem Controlpoint entlockt bekomme. Das Problem ist ja, dass das Lesen u. verarbeiten eingehender search-messages in der black-box upnp-Paket erfolgen. :'(
« Letzte Änderung: 23 Januar 2021, 19:40:58 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20695
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #26 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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #27 am: 23 Januar 2021, 15:43:11 »
Hi Andre,
Zitat
komme aber leider nicht zu mehr.
Das merkt man leider.  ;)

Zitat
ich denke es wäre gut das ein mal zentral zu haben
Sehen wir ja auch so. Deshalb in Unkenntnis Deiner Vorarbeit der Versuch hier für ssdp/upnp.

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

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline gvzdus

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 825
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #28 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?

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #29 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....
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #30 am: 24 Januar 2021, 10:36:18 »
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.

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4458
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #31 am: 24 Januar 2021, 11:13:09 »
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #32 am: 24 Januar 2021, 16:34:46 »
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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #33 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.
Zitat
Im 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.
Zitat
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?
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 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.
Zitat
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.
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>
« Letzte Änderung: 25 Januar 2021, 14:33:00 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #34 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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #35 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.
« Letzte Änderung: 27 Januar 2021, 10:25:29 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #36 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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #37 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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #38 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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #39 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #40 am: 15 Februar 2021, 20:39:30 »
So, ich hab jetzt mal einen neuen Thread zu meiner Entwicklung 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #41 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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #42 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #43 am: 16 Februar 2021, 13:17:10 »
Ä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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #44 am: 16 Februar 2021, 14:24:31 »
 ;D ;D ;D
Zitat
Ich habe bisher keine Aktionen ausgelöst
Doch hast Du.
Zitat
Folgende 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.

Zitat
Das 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #45 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?

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #46 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.  :)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #47 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?

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #48 am: 16 Februar 2021, 20:20:35 »
Zitat
Die 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.

Zitat
weil 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 hierDas 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).
« Letzte Änderung: 16 Februar 2021, 20:31:59 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #49 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.



Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #50 am: 02 März 2021, 19:52:07 »
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
Bei mir nicht, wenn
Zitat
UPnP-Controller und ein UPnP-Device auf getrennten Fhem-Installationen laufen
oder meinst Du mit
Zitat
Ruft man die SEMP URL "location" auf
im Browser ?
Zitat
2. Das Attribut "file" zieht irgendwie nicht.
Ja, das schrieb ich ja. Keine Ahnung wo es da hakt. Ich kümmere mich...
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.
(hab ich aber noch nicht ausprobiert. Wird daran scheitern, dass Port 4004 nicht mehrfach nutzbar ist)
Zitat
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?
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.
Zitat
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.
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.  :-\


RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #51 am: 02 März 2021, 20:41:40 »
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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #52 am: 02 März 2021, 22:32:48 »
Zitat
Wie 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 ?
Zitat
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.
:-\ 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. :(
Zitat
Genau, 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.
« Letzte Änderung: 02 März 2021, 23:01:55 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #53 am: 03 März 2021, 07:01:21 »
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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #54 am: 05 März 2021, 16:34:35 »
Zitat
Du 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
« Letzte Änderung: 05 März 2021, 19:06:02 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #55 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.
« Letzte Änderung: 05 März 2021, 17:47:57 von klaus.schauer »

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5100
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #56 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.  :-\

Zitat
Da wird schon noch der eine oder andere Gefallen an der Steuerung von Fhem-Devices darüber finden.
Ja, schon, User, aber nicht Module/devices.
Zitat
Aber 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>
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

 

decade-submarginal