UDP anomaly: hub_status.firmware_revision is "126" instead of 126

Doesn’t look like the documentation has changed, and obs_st.firmware_revision looks like:

but hub_status.firmware_revision looks like:

And the extra quotes are causing my SQL to blow up.

Any idea if I’m doing something wrong, or if that particular hub firmware is buggy?


Oops? My mistake, the documentation says it has quotes around it. I guess I’ll write a separate workaround for just that difference…

As a former coworker used to say - “the code always wins”.

It is interesting though that none of the other firmware_revisions are strings.

I looked up my python code and found much to my surprise that I have a special case for this too:

hub_status["firmware_revision"]   = int(data["firmware_revision"])

Of course I’m toast when they have a firmware_revision ala v1.2.3.4 but I’ll deal with that if it ever happens…

Turns out the reset_flags are also extra-quoted, so I’ve got another special case workaround for that. Here’s hoping they never fix it. 8*)

What do you mean by extra-quoted?

Sorry, that wasn’t well explained. They have quotes around them, so when I put them into a Redis database, Redis puts another set of quotes around them, so they end up with ““foo”” in Redis, and then when I pull those out of Redis and write them to SQL, SQL blows up on “”

I did a couple of workarounds and it’s working, but it’s counter-intuitive that some numbers (and other things) have quotes around them while others don’t. But it’s documented, so changing it risks breaking existing code, so “oh well”.

You have to code to the API, whatever it contains.

Unfortunately that was missed in the early beta testing. Fortunately all devices report as a number.

And my actual problem was getting the data into Redis, which says more about my programming skills than it does the original format of the data. I ended up with:

    if (isinstance(RedisValue,unicode)):