[weewx-user] Re: Dew point from WH31

[gjr80]

Hi,

Best done as a very simple XType that calls the dew point function you 
mention. Provided you store the result in an existing (and preferably 
unused) field in your database schema (eg dewpoint1 if you are using the 
extended schema) then WeeWX will automatically save your new dewpoint to 
database making it available for use in plots and aggregates in reports.

Gary

On Friday, 18 June 2021 at 09:16:16 UTC+10 Acacia wrote:

> Still quite new to WeeWX and how to configure it.
>
> I have a WH31 connected to a GW1000 which is delivering extraTemp1 and 
> extraHumid1 to WeeWX. I'd like to monitor the dew point from the WH31 
> sensor.
>
> In looking over the documentation and code, I see the dewpoint and 
> inDewpoint are calculated (and there is a nice calculator function to 
> compute the dew point). I also see a dewpoint1, but that doesn't seem to be 
> calculated from anything and is empty.
>
> What is the best way to add the dew point for extraTemp1 and extraHumid1?
>
> Do I need to create a new XType? 
>
> That struck me as a little more complex than I was expecting, so figured 
> I'd see if there is a simpler way to calculate, monitor and store the dew 
> point from the WH31.
>
> Thank you for helping a newbie,
> j.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a97778ff-1317-47f8-aa39-e028f57f265en%40googlegroups.com.

[weewx-user] Re: weewx stopped for no apparent reason

[Jay Jaeger]

Yes, everything has been working fine since the changes.  No, there isn't 
anything else talking to the WLL, except that the WLL posts to the Davis 
WLL website - but those are all outbound.  Since I changed the check on the 
counter from 1 to 2 I have seen none of those warning messages.

I wait to install your new code once it arrives until week after next, as I 
will be out of town, and I know what I have now is stable - so, no rush.

THANKS!

JRJ

On Friday, June 18, 2021 at 9:38:16 AM UTC-5 michael.s...@gmail.com wrote:

> OK, I've just taken a look into the 5 minutes thing. Forget my point from 
> above, the 5 minutes correspond to the 300 second archive interval.
> I was able to confirm this by changing the interval.
>
> Michael Schantl schrieb am Freitag, 18. Juni 2021 um 15:41:57 UTC+2:
>
>> OK, will push a new release shortly with the change you suggested.
>> Did everything work in the last few days?
>>
>> On the topic of the regular messages, is there any other device or 
>> process talking to the WLL. I've noticed that the WLL's HTTP server can act 
>> weird when there are too many connections in too quick succession.
>>
>> - Michael
>>
>>
>> cub...@gmail.com schrieb am Dienstag, 15. Juni 2021 um 23:42:40 UTC+2:
>>
>>> FYI, now that I am monitoring for the WARNING messages, I am seeing them 
>>> like clockwork every 5 minutes - in the SAME SECOND for which I see weewx 
>>> "Added record" messages.  Doubt it is a coincidence - correlation is nearly 
>>> 99% (once in a while there is no WARNING.  Suggest only issuing the warning 
>>> if >= 2 misses.
>>>
>>> JRJ
>>>
>>> On Saturday, June 12, 2021 at 1:50:39 PM UTC-5 michael.s...@gmail.com 
>>> wrote:
>>>
 Hi JRJ,
 thank you for the extensive debugging.
 I've just pushed a new dev release 
 
 .

 Yeah, you're right with the missing timeout. I had assumed the requests 
 library honors the socket timeout configured globally, but apparently not. 
 The standard WeeWX timeout option is now also used for the HTTP requests.
 Additionally, for good measures, I've also added a watchdog for when no 
 packets are received. It has an option to configure the iterations allowed 
 without data. See the changelog for details.

 - Michael

 cub...@gmail.com schrieb am Freitag, 11. Juni 2021 um 18:13:15 UTC+2:

> I noticed that there is no timeout keyword on the request call 
> davis_http.request_current.  I will add one to see if it helps.  (I also 
> note that there is no timeout on the call in start_broadcast either.
>
> JRJ
>
> On Friday, June 11, 2021 at 10:58:48 AM UTC-5 Jay Jaeger wrote:
>
>> I just noticed that the call to _poll_callback()  [to 
>> WllPollHost.poll] is indeed apparently not returning - noticed in the 
>> above 
>> logs that there is NO message "Polled current conditions".  Working 
>> theory: 
>> if it receives a UDP (broadcast) packet while it is doing the HTTP poll 
>> request, the driver gets confused.
>>
>> On Friday, June 11, 2021 at 10:35:39 AM UTC-5 Jay Jaeger wrote:
>>
>>>
>>> Happened again while I was looking at logs.  Just for grins, I fired 
>>> off an HTTP request from my PC, and it woke back up.
>>>
>>> So:  for some reason the WLL driver scheduler _do_tick method call 
>>> to _poll_callback() never returns, so that _do_tick never returns to 
>>> _scheduler_tick and thus it goes off to sleepy-land.   QUERY:  Is there 
>>> some reason it is calling _do_tick() before scheduling the next tick by 
>>> calling enterabs?  (And no, there is no exception being caught, as far 
>>> as I 
>>> can tell.)
>>>
>>> Adding a log.debug call after the _poll_callback() call - but I have 
>>> no doubt that under these conditions it will not be triggered.
>>>
>>> On Friday, June 11, 2021 at 10:06:10 AM UTC-5 Jay Jaeger wrote:
>>>
 Here are some more datapoints from the log that confirm that the 
 needed HTTP request to the WLL box is not occurring:

 Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
 user.weatherlink_live.scheduler: 13scheduler ticks until next push 
 refresh
 Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
 user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
 03:37:11 
 Z
 Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
 user.weatherlink_live.scheduler: Scheduler tick
 Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
 user.weatherlink_live.scheduler: Notifying poll callback
 Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
 user.weatherlink_live.scheduler: 12scheduler ticks until next push 
 refresh
 Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
 user.weatherlink_live.scheduler: Next scheduler 

[weewx-user] Re: weewx stopped for no apparent reason

[Michael Schantl]

OK, I've just taken a look into the 5 minutes thing. Forget my point from 
above, the 5 minutes correspond to the 300 second archive interval.
I was able to confirm this by changing the interval.

Michael Schantl schrieb am Freitag, 18. Juni 2021 um 15:41:57 UTC+2:

> OK, will push a new release shortly with the change you suggested.
> Did everything work in the last few days?
>
> On the topic of the regular messages, is there any other device or process 
> talking to the WLL. I've noticed that the WLL's HTTP server can act weird 
> when there are too many connections in too quick succession.
>
> - Michael
>
>
> cub...@gmail.com schrieb am Dienstag, 15. Juni 2021 um 23:42:40 UTC+2:
>
>> FYI, now that I am monitoring for the WARNING messages, I am seeing them 
>> like clockwork every 5 minutes - in the SAME SECOND for which I see weewx 
>> "Added record" messages.  Doubt it is a coincidence - correlation is nearly 
>> 99% (once in a while there is no WARNING.  Suggest only issuing the warning 
>> if >= 2 misses.
>>
>> JRJ
>>
>> On Saturday, June 12, 2021 at 1:50:39 PM UTC-5 michael.s...@gmail.com 
>> wrote:
>>
>>> Hi JRJ,
>>> thank you for the extensive debugging.
>>> I've just pushed a new dev release 
>>> 
>>> .
>>>
>>> Yeah, you're right with the missing timeout. I had assumed the requests 
>>> library honors the socket timeout configured globally, but apparently not. 
>>> The standard WeeWX timeout option is now also used for the HTTP requests.
>>> Additionally, for good measures, I've also added a watchdog for when no 
>>> packets are received. It has an option to configure the iterations allowed 
>>> without data. See the changelog for details.
>>>
>>> - Michael
>>>
>>> cub...@gmail.com schrieb am Freitag, 11. Juni 2021 um 18:13:15 UTC+2:
>>>
 I noticed that there is no timeout keyword on the request call 
 davis_http.request_current.  I will add one to see if it helps.  (I also 
 note that there is no timeout on the call in start_broadcast either.

 JRJ

 On Friday, June 11, 2021 at 10:58:48 AM UTC-5 Jay Jaeger wrote:

> I just noticed that the call to _poll_callback()  [to 
> WllPollHost.poll] is indeed apparently not returning - noticed in the 
> above 
> logs that there is NO message "Polled current conditions".  Working 
> theory: 
> if it receives a UDP (broadcast) packet while it is doing the HTTP poll 
> request, the driver gets confused.
>
> On Friday, June 11, 2021 at 10:35:39 AM UTC-5 Jay Jaeger wrote:
>
>>
>> Happened again while I was looking at logs.  Just for grins, I fired 
>> off an HTTP request from my PC, and it woke back up.
>>
>> So:  for some reason the WLL driver scheduler _do_tick method call to 
>> _poll_callback() never returns, so that _do_tick never returns to 
>> _scheduler_tick and thus it goes off to sleepy-land.   QUERY:  Is there 
>> some reason it is calling _do_tick() before scheduling the next tick by 
>> calling enterabs?  (And no, there is no exception being caught, as far 
>> as I 
>> can tell.)
>>
>> Adding a log.debug call after the _poll_callback() call - but I have 
>> no doubt that under these conditions it will not be triggered.
>>
>> On Friday, June 11, 2021 at 10:06:10 AM UTC-5 Jay Jaeger wrote:
>>
>>> Here are some more datapoints from the log that confirm that the 
>>> needed HTTP request to the WLL box is not occurring:
>>>
>>> Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: 13scheduler ticks until next push 
>>> refresh
>>> Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
>>> 03:37:11 
>>> Z
>>> Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: Scheduler tick
>>> Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: Notifying poll callback
>>> Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: 12scheduler ticks until next push 
>>> refresh
>>> Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
>>> 03:37:22 
>>> Z
>>> Jun 10 22:37:22 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: Scheduler tick
>>> Jun 10 22:37:22 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: Notifying poll callback
>>> Jun 10 22:37:23 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: 11scheduler ticks until next push 
>>> refresh
>>> Jun 10 22:37:23 mythtv2 weewx[239040] DEBUG 
>>> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
>>> 03:37:33 
>>> Z
>>> Jun 10 22:37:33 mythtv2 weewx[239040] DEBUG 

[weewx-user] Re: weewx stopped for no apparent reason

[Michael Schantl]

OK, will push a new release shortly with the change you suggested.
Did everything work in the last few days?

On the topic of the regular messages, is there any other device or process 
talking to the WLL. I've noticed that the WLL's HTTP server can act weird 
when there are too many connections in too quick succession.

- Michael


cub...@gmail.com schrieb am Dienstag, 15. Juni 2021 um 23:42:40 UTC+2:

> FYI, now that I am monitoring for the WARNING messages, I am seeing them 
> like clockwork every 5 minutes - in the SAME SECOND for which I see weewx 
> "Added record" messages.  Doubt it is a coincidence - correlation is nearly 
> 99% (once in a while there is no WARNING.  Suggest only issuing the warning 
> if >= 2 misses.
>
> JRJ
>
> On Saturday, June 12, 2021 at 1:50:39 PM UTC-5 michael.s...@gmail.com 
> wrote:
>
>> Hi JRJ,
>> thank you for the extensive debugging.
>> I've just pushed a new dev release 
>> 
>> .
>>
>> Yeah, you're right with the missing timeout. I had assumed the requests 
>> library honors the socket timeout configured globally, but apparently not. 
>> The standard WeeWX timeout option is now also used for the HTTP requests.
>> Additionally, for good measures, I've also added a watchdog for when no 
>> packets are received. It has an option to configure the iterations allowed 
>> without data. See the changelog for details.
>>
>> - Michael
>>
>> cub...@gmail.com schrieb am Freitag, 11. Juni 2021 um 18:13:15 UTC+2:
>>
>>> I noticed that there is no timeout keyword on the request call 
>>> davis_http.request_current.  I will add one to see if it helps.  (I also 
>>> note that there is no timeout on the call in start_broadcast either.
>>>
>>> JRJ
>>>
>>> On Friday, June 11, 2021 at 10:58:48 AM UTC-5 Jay Jaeger wrote:
>>>
 I just noticed that the call to _poll_callback()  [to WllPollHost.poll] 
 is indeed apparently not returning - noticed in the above logs that there 
 is NO message "Polled current conditions".  Working theory: if it receives 
 a UDP (broadcast) packet while it is doing the HTTP poll request, the 
 driver gets confused.

 On Friday, June 11, 2021 at 10:35:39 AM UTC-5 Jay Jaeger wrote:

>
> Happened again while I was looking at logs.  Just for grins, I fired 
> off an HTTP request from my PC, and it woke back up.
>
> So:  for some reason the WLL driver scheduler _do_tick method call to 
> _poll_callback() never returns, so that _do_tick never returns to 
> _scheduler_tick and thus it goes off to sleepy-land.   QUERY:  Is there 
> some reason it is calling _do_tick() before scheduling the next tick by 
> calling enterabs?  (And no, there is no exception being caught, as far as 
> I 
> can tell.)
>
> Adding a log.debug call after the _poll_callback() call - but I have 
> no doubt that under these conditions it will not be triggered.
>
> On Friday, June 11, 2021 at 10:06:10 AM UTC-5 Jay Jaeger wrote:
>
>> Here are some more datapoints from the log that confirm that the 
>> needed HTTP request to the WLL box is not occurring:
>>
>> Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: 13scheduler ticks until next push 
>> refresh
>> Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
>> 03:37:11 
>> Z
>> Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Scheduler tick
>> Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Notifying poll callback
>> Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: 12scheduler ticks until next push 
>> refresh
>> Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
>> 03:37:22 
>> Z
>> Jun 10 22:37:22 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Scheduler tick
>> Jun 10 22:37:22 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Notifying poll callback
>> Jun 10 22:37:23 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: 11scheduler ticks until next push 
>> refresh
>> Jun 10 22:37:23 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
>> 03:37:33 
>> Z
>> Jun 10 22:37:33 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Scheduler tick
>> Jun 10 22:37:33 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: Notifying poll callback
>> Jun 10 22:37:34 mythtv2 weewx[239040] DEBUG 
>> user.weatherlink_live.scheduler: 10scheduler ticks until next push 
>> refresh
>> Jun 10 22:37:34 mythtv2 weewx[239040] DEBUG 
>>