Is esp8266ssdp/ssdp working?

[holgerlembke]

Hi.

If I take the esp8266ssdp/ssdp example (just fill in ssid/pwd), my esp does not show up in the devices list.

I have a standard Windows 10 Pro network, no firewall, no additional software installed.

Could some users please verfiy that the example is really working?

Thanks!

[holgerlembke]

adding SSDP.setDeviceType("upnp:rootdevice"); and it starts working.

[me-no-dev]

is this documented somewhere? I mean the device type? When I was reading the specs I was left with the impression that urn:schemas-upnp-org:device:Basic:1 is the one to be used

[holgerlembke]

I don't know.

Reading chapter "Device available - NOTIFY with ssdp:alive" of UPnP-arch-DeviceArchitecture-v2.0-20150220.pdf from https://openconnectivity.org/upnp/specifications it sounds like that is the way its done.

And because it works...

[me-no-dev]

it was working with the schema above as well back when I was writing it.
Reading about it here does not hint on any problem why the info would not display.

[holgerlembke]

I can only state what I observe on this Win10 box...

[me-no-dev]

that's cool. I have Win7 and Win10 virtual machines here and will take a look at the result.

[holgerlembke]

In the other news: right click on the device and requesting the properties does not work, too.

[kiwiwarwick]

Thanks for the info, I a had an issue in getting SSDP working (using the included example), after I added the line - SSDP.setDeviceType("upnp:rootdevice"); then it worked.

But like holgerlembke mentioned, the "Properties" option in Windows 10 doesn't work for this.

[azevedo-manuel]

I've compared some captures with other devices and I see at least there are three NOTIFY messages broadcast to the multicast address, instead of only one like the ESP8266SSDP library.

On a first look, only the NT header field is different on each message:
NT: upnp:root-device
NT: uuid:1406a136-e5ff-11e5-9730-64002d01c3f4
NT: urn:schemas-upnp-org:device:Basic:1

But looks like it might be enough for Windows 10 to complain.

In my case, double-clicking the icon opens the device's webpage, so, this might just as well do.

[saytinh]

I still can not view ESP8266 on Network of Windows after added SSDP.setDeviceType("upnp:rootdevice"); to SSDP.ino example. I used Windows 10 pro. Can you help me. Thanks

[azevedo-manuel]

Saytinh, it works. Be sure you apply it before SSDP.begin(); and that Network Discovery is enabled in your Windows 10.

[saytinh]

Yes, I added before SSDP.begin(); SSDP service is running; but NOT show ESP on network devices with list.
is there possible that my wifi router is not supported SSDP protocol?

[azevedo-manuel]

No clue, but I don't think so. SSDP uses 239.255.255.250 multicast address. If you're connected to the same subnet (computer and ESP are on the same subnet) then the router should have no impact on it, unless it's actively filtering multicast. Anyway, this "issue" forum is for reporting bugs, not troubleshooting particular cases.

[saytinh]

Hi azevedo-manuel,

I already can view ESP on the network list after adding SSDP.setDeviceType("upnp:rootdevice"); But clicking on the property of ESP there are still error like that:

Can you help me?

[luc-github]

Just to complete @holgerlembke finding, as before SSDP was working, here the commit which removed the upnp:root-device :c8d855c

About window 10 issue I can reproduce with some others device like my NAS Synology but not with my Internet access gateway - Is there a way to get description.xml or equivalent from other devices to compare with ESP one ? it may help to understand why properties work under win7 but not win10

[luc-github]

Using GSSDP under linux I was able to get all description of all devices.
I found that device type can be urn:schemas-upnp-org:device:Basic:1 but need to add a service to popup in explorer like upnp:root-device
Edit: i saw even urn:schemas-upnp-org:device:Basic:1 has a NOTIFY and RESPONSE with upnp:root-device inside

About Windows 10 properties, I was not able to find what make properties working on one devices and not on another - so as suggested @azevedo-manuel : should be in broadcasting part

For fancy part (sorry):
I just found that adding "<pnpx:X_deviceCategory xmlns:pnpx=\"http://schemas.microsoft.com/windows/pnpx/2005/11\">NetworkInfrastructure.Gateway</pnpx:X_deviceCategory>" after <device>, will set my ESP in Network devices, instead of Other Devices, which is nice even it does not help on current issue.

[joostjager]

I have been experimenting with the problem that SSDP properties are not shown in Win 10. What I currently think is that - after right clicking properties - a very specific discover request is made where the search target contains the device UUID. What I see then is that the device is not replying with that exact search target, but with the more general device type. I made a small change to the ssdp code to reply with the same search target that was present in the request. Then the properties are shown in Windows.

Although the properties then seem to work, the device mysteriously disappears from the devices overview at the same time the property page is displayed.

[fngstudios]

Could you please share the modifications you made to the ssdp code? Im trying to get properties too.

Thank you.

[dalbert2]

Did anyone get the properties working under Windows 10?

[saytinh]

Yes. It worked. Just follow this guide: http://www.esp8266.com/viewtopic.php?f=32&t=10459&sid=3593b5ed2eee8b9265f721f9dfc49607&start=4

[azevedo-manuel]

@saytinh, I think @dalbert2 is mentioning the properties page. I still can't make it work. For my case it's enough when somebody double clicks the device to open the device's webpage in a browser.

[dalbert2]

Thank you azevedo-manuel, I was indeed referring to the properties page in Windows 10; the device shows just fine in the network view, but if you right click and request properties it does not work.

[manvir-singh]

Can anyone post a full working sketch?
This didn't work

SSDP.setDeviceType("upnp:rootdevice");

[PawelDino]

Standard SSDP unit will not be working. I also needed SSDP support so I rewritten the unit and now it works as it should. I attach my version, I hope it will be useful to someone.

SSDPDevice.zip
MySSDP.zip

[devyte]

Maybe this should be turned into a PR?

…

On May 6, 2017 9:07 AM, "PawelDino" ***@***.***> wrote: Standard SSDP unit will not be working. I also needed SSDP support so I rewritten the unit and now it works as it should. I attach my version, I hope it will be useful to someone. SSDPDevice.zip <https://github.com/esp8266/Arduino/files/980894/SSDPDevice.zip> MySSDP.zip <https://github.com/esp8266/Arduino/files/980896/MySSDP.zip> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2283 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQC6BoL5pMBeV-ysRJW6xVptcBD1FnoQks5r3GKBgaJpZM4JMaTX> .

[ThatJCB]

@PawelDino Excellent work. Everything works as it should. Thank you.
I like the inclusion in the Home Automation category, good touch.

[holgerlembke]

I would suggest to raise SSDP_MULTICAST_TTL to 3.

(In case there are WifiRouter->Router->Router situation, not so unusual.)

[devyte]

I think the current example merits updating with the attached, after testing.

[dalbert2]

Hi Pawel,
Thank you for posting your SSDPDevice class!

2 minor suggestions for you or anyone else who uses this: you should probably move the template strings out of the header file and into the cpp file. The send() method should also provide a default for the switch on parameters->udn to set all of the strings to an empty string so there is no chance they will be used uninitialized later.

Do you have any sources for the available upnp device types?

Thanks again!!!

[devyte]

A PR with the update would be appreciated, as well as feedback from testing.

[dalbert2]

@devyte I would be happy to submit a PR, but I don't know whether your comment was directed to me or to @PawelDino who contributed the class. His class works quite nicely, I've been using it for some time without issue.

Another suggested change which is required for the class to build with lwip2:

IP addresses must be declared as follows:
ip_addr_t ip = { WiFi.localIP() };
rather than this (which won't compile with lwip2):
unsigned long ip = WiFi.localIP();
(as described in issue #4481)

[devyte]

@dalbert2 if you've tested the proposal in the zip above, it'd be enough to move forward. A PR would help to get a review going.

[gitpeut]

fyi: based on Pawel Dino's code, I made SSDP working on the ESP32.
https://github.com/gitpeut/esp32SSDP

[gonzabrusco]

Pawel's code worked perfectly on Arduino IDE. But It gives me tons of compiler errors on PlatformIO. What I'm doing wrong? Is the platformIO compiller much more "strict"?

I don't know how to share with you all the errors but they are mostly related to:

• Does not find the macro IP2STR
• ambiguous overload for 'operator==' (operand types are 'uint32_t {aka unsigned int}' and 'const IPAddress')
• more than one conversion function from "const IPAddress" to a built-in type applies: -- function "IPAddress::operator uint32_t() const" -- function "IPAddress::operator u32_t() const" -- function "IPAddress::operator bool() const"

Mostly types incompatibilities. Why Arduino IDE can compile it anyway?