I would like to implement a listener to an UPNP service. For that I need to subscribe (simple http request with some specific headers items - see code) and create an http instance for incoming notification.
Is there anything available in Node-RED what I can reuse?
I could not find "SUBSCRIBE" - only POST, GET, ... in the http nodes.
Any node.on for this kind of subscription, port 4000
Looks interesting.
Is there any documentation for "receive event"?
UUID might be RINCON_5CAAFD00223601400 but also RINCON_5CAAFD00223601400_MR. Both show green.
Service type is what? I tried upnp:event but an error occurs.
Where do I have to enter the service endpoint -for instance "MediaRenderer/RenderingControl/Event"
Service type depends on what you want to receive events from.
I read sonos in your first post, so I guess you maybe want urn:schemas-upnp-org:service:AVTransport:1
You can also pull in the mediaRenderer node, which receives events from urn:schemas-upnp-org:service:AVTransport:1 and you can play, pause, stop, set media etc.
If you explain me what you want to do, I might can help. I went through the rabbit hole and have read a lot of the UPnP specifications.
About the UUID, you get it from discovery. Send the payload ssdp:all to the discovery node and it will shout out a lot of messages (put a debug node behind it). Then find the service you want to have and then also the associated UUID from that. But if it shows the green status, then it is already good So you might already found the right one.
I have just read in your post that you want to do rendering control,
then urn:schemas-upnp-org:service:RenderingControl:3 should be the service type.
However, rendering control is not really useful for a loudspeaker, except for changing the volume.
For node receive event, field Service Type: urn:schemas-upnp-org:service:AVTransport:1
and in the configuration node, field uuid RINCON_5CAAFD00223601400_MR
The node status turns green and the debug node provide the error: Error: Service urn:schemas-upnp-org:service:AVTransport:1 not available
can you maybe also post the device description xml file? During discovery, you should find the device description url somewhere in the message (headers.LOCATION), open that in the browser and post the content here.
UPnP is a complex topic, the little code you have shown above would definitively not do the right thing (or I misinterpret it), because the CALLBACK should not be the device you want to receive the state from, but an http endpoint the device will report its state to. Furthermore, you have to resubscribe after the timeout etc.
I googled myself for the device description xml of a sonos device (could be that it is a different one to yours) and it appears that sonos devices make use of so-called embedded upnp devices (just another unnecessary feature of the upnp spec)
I have not implement this, since I don't own a device that has this feature.
If you are willing to test things, I can try to implement this, which should be pretty easy, however, it is hard to do for me since I cannot test it.
Testing: Yes - sure I will do the tests. One restriction: from 16 to 25 of June I am not at home and don't have access to the SONOS devices.
Little Code: Yes, I know. The "little" code only does the "subscribe" but we need an event receiver, unsubscribe, renew subscription, ... - that's why your package is needed.
Additional info: There are 4 player endpoints I would like to subscribe to:
MediaRenderer/AVTransport/Event, MediaRenderer/RenderingControl/Event, MediaRenderer/GroupRenderingControl/Event, MediaRenderer/Queue/Event
and 2 global endpoints but so far I dont need them:
AlarmClock/Event, ZoneGroupTopology/Event
Before being able to subscribe, the event receiver must be up an running - otherwise the subscription will return error 412.
There are already packages providing the events node sonos and notify but they crash to often on my system.
In the event node urn:schemas-upnp-org:service:AVTransport:1 as I said before.
And don't use "use hardcoded device description URL" and don't put something into "device description url" and especially not an event URL.
The option "use hardcoded device description URL" is for avoiding discovery, which in some networks is unreliable.
Edit: If you want to use the hardcoded description URL, you have to put http://192.168.178.37:1400/xml/device_description.xml into it, but this would assume that the device always has the same IP. If you use discovery, it can deal with changing IPs etc.
If you also want rendering control, you need a second event node with urn:schemas-upnp-org:service:RenderingControl:1 as the service type.
Yes, the discovery sometimes makes problems, so if you go with the hardcoded device description url and a static IP, it is more reliable and also a tiny bit faster.
One disclaimer though: UPnP is really a complex topic, mainly because I think there is not a single implementation out there that adheres to the spec (libupnp for linux does not completely, and my one also not). Therefore, I do not promise that it does not crash, ok?
That is also the reason why I never published that node on npm (also due to lack of documentation).
Still, for my UPnP devices, that node runs stable for over a year without any problems and is used every day.
So you might already found the right one.
