jUPnP: Search for a specific Service

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?

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.

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.

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.

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