Vera extended the UPnP service definition to include a <shortCode> tag in the <stateVariable> sections of the service files. This defines the shortcode for the state variable. If not defined, the state variable is not published to an sdata/lu_sdata response.
The UPnP SwitchPower1 (abbrev.) service defined by Vera includes the shortcode status for the SwitchPower1/Status variable, and this is what your switches and Home Remote should be using. Some try to look at Target, but this is functionally wrong (you want the actual state, not the anticipated/commanded state), and there’s no shortcode for it either, so check that.
The problem with all of this, and it’s a huge problem for HomeAssistant and its underlying interface subsystem, pyvera, is that state variable names alone are not unique. State variables are uniquely identified not just by name, but the combination of the service ID and name. It is possible for a device to support several services, and if, for example, those services all define a Status variable with shortcode status for some purpose, then the shortcode names collide when generating the response output and which value you ultimately get is non-deterministic–you get only one “status” shortcode output of the many defined, and you have no access to the rest. Because of this, devices like thermostats with multiple setpoints are difficult to get to work right (as evidenced by the kludging necessary with pyvera and the Hass component). sdata also, as you know, limits the set of accessible state variables to the subset of what the service’s maintainer chose to publish that way, and sometimes you need access to something else.
So sdata is a terrible idea, and was from the start, IMO, and it should not be used. Use the more complete status request instead, which returns service IDs with the state variable names. Vera themselves does not appear to use sdata in their own UI. Go figure. Both the status/lu_status and user_data requests will give you all state variables for devices, the former being somewhat quicker at it. Both will also allow you to pass in a stamp from a previous response so it will give you back only deltas–changed variables since the last response–which greatly improves efficiency on the receiving end. Both also support “long polling” (it won’t return a response until there are deltas or a timeout occurs).
A fast JSON parser helps, too, so for the benefit of anyone who might try to parse user_data or status responses with dkjson, I recommend using opkg to update your dkjson and install LPeg, which improves parsing time by an order of magnitude.
Of course, who knows what the next-gen firmware will bring in this respect…