Well I am embarrased to say that to say I did not know about nan/NaN and
python, today's lesson I guess.
Gary
On Tuesday, 21 November 2017 01:30:57 UTC+10, Thomas Carlin wrote:
>
> Tom,
> Your interpretation is exactly correct, and yes it is a coding error on my
> side. My thought was just a single sentence there about the Weewx engine
> not doing any sanitation, and that being the responsibility of the driver.
> If not, no worries, just a thought.
>
> Gary,
> No worries on the delay. You got me going in the right direction, and we
> got it figured out! It's not like you get paid for doing this. Until
> yesterday, the extent of the sanitation that I was doing on the incoming
> data was running float(data), and catching any ValueError exception. Now,
> because nan is a special 'string', when you run float('nan'), it returns
> NaN, but now it is the Python 'number' NaN. When you add a number to NaN,
> your result is always NaN. When this is stuffed into the database,
> apparently it is interpreted as SQL NULL. Next time the loop runs, Python
> queries the database, and interprets SQL NULL as None, and then we get the
> type mismatch.
>
> I have added some more sanitation for this, and we are back up and
> running, and it *should* conform to expected behavior.
>
> Does that make sense?
>
> Thank you for the input on the driver. I have a laundry list of things
> that I would like to add to make it more robust, and I'll add the loop
> output to that. I may be converting to a queue as well, simply due to the
> number of sensors that are being polled, and the "couple of seconds" note
> in the Second Datasource section of the docs. But that is a project for
> another day!
>
>
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
