jUPnP: Search for a specific Service

Add-ons Bindings
,
1

Hi!

We try to write a OH2 plugin for pilight. I want to discover the instance via UPnP.
Because a UpnpDiscoveryParticipant does not came up with that service, I wrote an AbstractDiscoveryService, which asks directly for urn:schemas-upnp-org:service:pilight:1 with that code:

ServiceType udaType = new ServiceType("schemas-upnp-org", "pilight", 1);
upnpService.getControlPoint().search(new ServiceTypeHeader(udaType));

In wireshark I see an answer for that M-SEARCH Request:

Frame 1103: 1067 bytes on wire (8536 bits), 1067 bytes captured (8536 bits) on interface 0
Ethernet II, Src: Raspberr_3e:31:84 (b8:27:eb:3e:31:84), Dst: AsixElec_c6:a2:a2 (00:0e:c6:c6:a2:a2)
Internet Protocol Version 4, Src: 10.0.0.64, Dst: 10.0.0.77
User Datagram Protocol, Src Port: 1900, Dst Port: 49832
Simple Service Discovery Protocol

NOTIFY * HTTP/1.1\r\n
    Host:239.255.255.250:1900\r\n
    Cache-Control:max-age=900\r\n
    Location:10.0.0.64:35232\r\n
    NT:urn:schemas-upnp-org:service:pilight:1\r\n
    USN:uuid:0000-b8-27-eb-3e3284::urn:schemas-upnp-org:service:pilight:1\r\n
    NTS:ssdp:alive\r\n
    SERVER: Debian/0.0 UPnP/1.1 pilight (homegear)/7.0\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]
    File Data: 742 bytes
    Data (742 bytes)

(10.0.0.64 Raspi with pilight, 10.0.0.77 my dev machine with OH2)

But no upnpService-Callbacks are called with these device infos. Any ideas about that behavior?

2

I set jUPnP loglevel to trace and I saw the moment of processing the answer of pilight. But it’s hard to distinguish between different thready which seem to decode the received data:

2017-12-29 23:57:29.345 [DEBUG] [.transport.impl.DatagramIOImpl:113  ] - UDP datagram received from: 10.0.0.64:1900 on: /10.0.0.77:0
2017-12-29 23:57:29.345 [TRACE] [ransport.spi.DatagramProcessor:49   ] - ===================================== DATAGRAM BEGIN ============================================
2017-12-29 23:57:29.345 [TRACE] [ransport.spi.DatagramProcessor:50   ] - NOTIFY * HTTP/1.1
Host:239.255.255.250:1900
Cache-Control:max-age=900
Location:10.0.0.64:35232
NT:urn:schemas-upnp-org:service:pilight:1
USN:uuid:0000-b8-27-eb-3e3284::urn:schemas-upnp-org:service:pilight:1
NTS:ssdp:alive
SERVER: Debian/0.0 UPnP/1.1 pilight (homegear)/7.0

2017-12-29 23:57:29.345 [TRACE] [upnp.model.message.UpnpHeaders:58   ] - Parsing all HTTP headers for known UPnP headers: 8
2017-12-29 23:57:29.345 [TRACE] [odel.message.header.UpnpHeader:169  ] - Trying to parse 'EXT' with class: EXTHeader
2017-12-29 23:57:29.345 [TRACE] [ransport.spi.DatagramProcessor:51   ] - -===================================== DATAGRAM END =============================================
2017-12-29 23:57:29.345 [TRACE] [odel.message.header.UpnpHeader:175  ] - Invalid header value for tested type: STAllHeader - Invalid ST header value (not ALL): urn:schemas-upnp-org:service:pilight:1
2017-12-29 23:57:29.345 [TRACE] [jupnp.protocol.ProtocolFactory:83   ] - Creating protocol for incoming asynchronous: (IncomingDatagramMessage) NOTIFY
2017-12-29 23:57:29.345 [TRACE] [upnp.model.message.UpnpHeaders:83   ] - Adding parsed header: (EXTHeader) ''
2017-12-29 23:57:29.345 [TRACE] [odel.message.header.UpnpHeader:169  ] - Trying to parse 'ST' with class: RootDeviceHeader
2017-12-29 23:57:29.345 [DEBUG] [org.jupnp.transport.Router    :268  ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
2017-12-29 23:57:29.345 [TRACE] [odel.message.header.UpnpHeader:175  ] - Invalid header value for tested type: RootDeviceHeader - Invalid root device NT header value: urn:schemas-upnp-org:service:pilight:1
2017-12-29 23:57:29.345 [TRACE] [odel.message.header.UpnpHeader:169  ] - Trying to parse 'ST' with class: STAllHeader
2017-12-29 23:57:29.345 [TRACE] [odel.message.header.UpnpHeader:169  ] - Trying to parse 'ST' with class: UDADeviceTypeHeader
2017-12-29 23:57:29.345 [TRACE] [upnp.model.message.UpnpHeaders:58   ] - Parsing all HTTP headers for known UPnP headers: 7
2017-12-29 23:57:29.345 [DEBUG] [.transport.impl.DatagramIOImpl:113  ] - UDP datagram received from: 10.0.0.89:1900 on: /10.0.0.77:100:

The last entry just logs the receiving of the next datagram.

3

It looks like you need to “patch” JUPnP to fully hydrate the device. This will be hard work, I did the same for WeMo discovery.

Compared to “normal” M-SEARCH answers, there are a couple of tags missing:

OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: [don't know the correct value for pilight]
ST: upnp:rootdevice

Even the location tag should point to something like setup.xml, which will be used to build the services.

4

After checking pilight website, I would suggest not to use UPnP discovery, but write your own SSDP discovery.
WeMo Binding 1.x was based on such and the first version of WeMo ESH Binding was.

5

Thank you! That helps!

I saw that thread about WeMo, but I wasn’t sure that this fit to my problem as well.

1 Like