HankLloydRight
No Roads
That's not what I'm seeing. I get the "id" property and use that for requesting details. My "id" response in the vehicle status JSON is the same as id_s. The prior isn't bound by quotes, and the latter is bounded by quotes.
That's not the point at all. {id_s} is 'bounded by quotes' because it is (or was) just the string version of {id} (hence the '_s' suffix). The value of {id_s} itself does not include the quotes, as do none of the other JSON string values. That's just how strings are represented in JSON. Just like the string value of {state} is online not "online".
Up until recently, {id_s} was just the string version of the integer {id}. But since we're using it to construct a URL (string) to pass back to the API, you could use {id_s} directly if you didn't want to (or couldn't) convert the integer {id} to a string in your programming language of choice. (which is odd, since what language doesn't allow you to do that?). My guess is that {id_s} was included as a string version of {id} since some languages might have trouble handing/converting {id} as a long integer and it was getting mangled. But who knows for sure.
But the main point now is that for some unknown reason, and only for some people, {id} and {id_s} are not the same value and differ +/- 1 or 2. So when your code using {id} stops working, you too will have to just switch to {id_s} to get it working again.