Custom Device Type, Appropriate Responses, Custom TTL, and uint32_t Serial Number #1399
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
the v1.1 upnp spec indicates that the default TTL should be set to 2 (and should also be configurable): * http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
* can now specify the TTL programmatically * can now define the device type urn (up to 64 chars) ** still defaults to `Basic:1` * can now set the serial number using a `uint32_t`, formatted as %08X
silly goof, it's a string
also a small formatting fix. this should now allow the system to actually respond to SSDP discoveries that are issued on the network ... i'm still not 100% certain if this is right due to the way that the switch() statement is setup; it could be processing more than it should
igrr
added a commit
that referenced
this pull request
Jan 10, 2016
Custom Device Type, Appropriate Responses, Custom TTL, and uint32_t Serial Number
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses 3 major things that I ran into while building an SSDP based device using the esp8266 (and 1 ease of use)
SSDP_MULTICAST_TTL 2and a helper function to set the TTL,setMulticastTTL()is now included. This should allow the user to customize responses when needed.deviceTypeattribute: The default device type ofurn:schemas-upnp-org:device:Basic:1is great but it covers a lot of things and when in down, you should be more specific than not. The default is still the same; however, asetDeviceType()now exists allowing the user to specify a custom URN for the device type, just like the basic one. Based on the upnp 1.1 specification, this should technically be unlimited in length; however, that's not really reasonable with the way the rest of the library is written so I've set the max size toSSDP_DEVICE_TYPE_SIZE 64to keep consistent with the rest of the code and should fit the 80% case in the device type descriptors I looked up.ssdp:all... although, we might want to consider responding tossdp:discoversince it appears we should be ... but that might be too much traffic so this seemed like a good compromise for now). Now when the ST: matches the deviceType set bysetDeviceType()or the default, we will correctly respond with anHTTP 200 OKpacket (allowing things like SmartThings to successfully discover us).setSerialNumber()can directly take the input fromESP.getChipId()