So, if I'm understanding you correctly, the Arduino produces numbers as
strings. It can also produce the string "nan" when no data are available.
So, when it came time to convert the string to a floating point number in
your driver, you effectively had float("nan"), which is how the Python NaN
was produced. Is that it?
If that's the case, that just sounds like a run-of-the-mill programming
error. There's no end of things like that which could go wrong. We can't
list them all in the Customizing Guide.
-tk
On Sun, Nov 19, 2017 at 4:33 PM, Thomas Carlin <thomascarl...@gmail.com>
wrote:
> Hey Tom
>
> At this point in the code 'nan' is not equivalent to 'Not a Number', it is
> simply a string that is pulled out of an http page, not generated by
> python. Originally, it is generated on my Arduino when data cannot be
> pulled from the temperature sensor. Unfortunately in this case when you
> run float("nan") in python, it returns nan, and that was the extent of my
> sanitization. I'll write a condition into my driver to catch that, and
> should be good to go.
>
> On Sunday, November 19, 2017 at 2:14:59 PM UTC-7, Tom Keffer wrote:
>>
>> But, how did you create a NaN? They are not returned from any of the
>> Python mathematical functions.
>>
>> -tk
>>
>> On Sun, Nov 19, 2017 at 2:04 PM, Thomas Carlin <thomas...@gmail.com>
>> wrote:
>>
>>> I'm pretty sure this is what is happening. Take a look at the output
>>> below:
>>>
>>> ...
>>> DB Entry: extraTemp3
>>> Value: nan
>>> DB Entry: extraHumid3
>>> Value: nan
>>> ...
>>> Unable to access http://192.168.2.105
>>> REC: 2017-11-19 12:38:00 MST (1511120280) ..., *extraHumid3: nan*,
>>> extraTemp1: 55.58, *extraTemp3: nan*, heatindex: 31.7143461695...
>>>
>>> The next attempt to add data to the database resulted in the program
>>> crashing due to a type mismatch.
>>>
>>> May I request that a blurb be added to the documentation here:
>>> http://www.weewx.com/docs/customizing.htm#Adding_2nd_source about
>>> sanitizing the data before it is fed to event.record()?
>>>
>>>
>>> On Sunday, November 19, 2017 at 10:59:29 AM UTC-7, Thomas Carlin wrote:
>>>>
>>>> The plot thickens. Right before I went to bed this morning, I checked
>>>> the current daily summary record for extraTemp3, and it looked as you would
>>>> expect it to. It had data in it for both sum and wsum, unlike the one
>>>> posted above. Roughly an hour later, Weewx crashed with the same error,
>>>> and this morning when I went to look into it, the current record, same one
>>>> as last night, no longer had data in it for the same fields.
>>>>
>>>> After looking a little closer, I noticed that the extraHumid3, which I
>>>> created, did exactly the same thing as extraTemp3. Since both these pieces
>>>> of data come from the same DHT11 sensor, my current theory is that under
>>>> the wrong conditions, my sensor is spitting out garbage that is not being
>>>> properly sanitized, which somehow empties those fields. Then next time the
>>>> loop runs, everything falls apart. I'm setting up a sandbox right now so I
>>>> can play with it without screwing with my 'production' system. Just hoping
>>>> the sandbox crashes like the current system does!
>>>>
>>> --
>>> 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 weewx-user+...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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 weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
