Just a side-note of caution here, since I see it has come up a few times:
sdata is really to be avoided if you’re intending to do any kind of integration or bridge. It has a fatal flaw: the “shortcodes” are not qualified with a service ID, so if a device has two different services that happen to use the same shortcode, one will overwrite the other in sdata (only one instance of each shortcode is injected), and that’s not deterministic. This creates problems for devices like thermostats, particularly dual-setpoint thermostats: there are two setpoint services active on the device (one for heating, one for cooling), but the shortcode for each is
setpoint and you only see it one time in
sdata, and whether it’s heating or cooling is random (whoever writes last wins). This is why pyvera, which is used by Hass for its bridge component, is such a mess.
user_data for an initial query followed by
status queries is the way to go. These requests also can take
loadtime parameters, so you can do incremental updates (only changed states/devices) with long-polling, and it’s fairly efficient in most cases.
So, not sure what you’re using
sdata for, but there be monsters…