[weewx-user] Re: Interceptor and WH57 Lightning sensor from Ecowitt

[Gert Andersen]

Hi Oliver

I'm using your patched script and it's working fine.

I insert these fields into th database:

[[sensor_map_extensions]]
lightning_strike_count = lightning_num
lightning_distance = lightning

These 2 fields are also coming from the sensor:

lightning_time
wh57batt

But can't be mapped right now as far as I can see. There are other 
lightning types in the extended scheme, but they don't fit with these.

It could also be very nice, to implement the PASSKEY functionality.

Gert

On Tuesday, June 23, 2020 at 9:51:37 PM UTC+2, olicat wrote:
>
> Hi!
>
> Are there any experiences with the adjusted script regarding lightning?
> Does it work for you now?
>
> Regards, Oliver
>
>

-- 
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/6dbef30f-d326-4433-8698-7375f9383a2co%40googlegroups.com.

[weewx-user] Re: Interceptor and WH57 Lightning sensor from Ecowitt

['NanoG5Kite' via weewx-user]

Oli, I don‘t think so. Possible most users like me do not have the 
(scripting/programming) skills to change necessary lines in the 
interceptor.py or weewx to adapt new/additional sensor values.
I gave up for the moment - Even if I could  get the lightning counts 
adapted, I would fail with the needed on the fly conversion of the unix 
time to normal time - last time strike... Without this time not useful for 
me at all and wasted time;-) As it seems  there is no process on the 
interceptor driver development, I take it as it is for now.

Regards,

Matthias



Am Dienstag, 23. Juni 2020 21:51:37 UTC+2 schrieb olicat:
>
> Hi!
>
> Are there any experiences with the adjusted script regarding lightning?
> Does it work for you now?
>
> Regards, Oliver
>
>

-- 
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/474201a7-8215-4cb0-b4fc-7810c4dff5e7o%40googlegroups.com.

Re: [weewx-user] Wunderground doesn't accept my data

[gjr80]

Likewise but not 10+ years

Apologies to Forrest Gump's mother but the first thing that came into my 
head was ' Weather Underground is like a box of chocolatesyou never 
know what your gonna get'

Gary

On Wednesday, 24 June 2020 08:57:20 UTC+10, Tom Keffer wrote:
>
> ... and I'm using v4.1.1, using a password. Works fine.
>
> Over the 10+ years I've dealt with the WU, I've learned to just throw up 
> my hands when weird stuff happens.
>
>

-- 
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/e5512217-af58-4916-885b-aa2e9337650bo%40googlegroups.com.

Re: [weewx-user] Wunderground doesn't accept my data

[Tom Keffer]

... and I'm using v4.1.1, using a password. Works fine.

Over the 10+ years I've dealt with the WU, I've learned to just throw up my
hands when weird stuff happens.

On Tue, Jun 23, 2020 at 3:43 PM Ernest Jillson  wrote:

> OP (David) replied back to me directly. That didn't work for him. But his
> setup is identical to mine. weewx 3.9, davis vp2. I'm using actual site
> password.
>
> On Tuesday, June 23, 2020 at 6:24:03 PM UTC-4, Tom Keffer wrote:
>>
>> Something new every day from the WeatherUnderground.
>>
>>
>>
>> On Tue, Jun 23, 2020 at 3:01 PM Ernest Jillson  wrote:
>>
>>> In weewx.conf:  For the password, instead of entering your site
>>> password, try the key there.  It's NOT the api key. It's under "My Devices"
>>> in your member settings on WU.
>>>
>>> [StdRestful]
>>> [[Wunderground]]
>>> enable = true
>>> station = KCASANFRA11
>>> password = 
>>> rapidfire = True
>>> api_key = xx
>>>
>>>
>>> On Tue, Jun 23, 2020 at 5:46 PM David Barto  wrote:
>>>
 Where (what field) did you plug the key into?

 David

 On Jun 23, 2020, at 2:15 PM, Ernest Jillson  wrote:

 Ok. This IS strange.

 I'm running weewx 3.9x and have my data going to wunderground with
 station ID and site password. The person I was helping is using weewx 4.1
 and station ID and password was failing as mentioned in this thread. Today,
 just for the heck of it, he decided to try using the "key" associated with
 his account. Bingo! Not sure if it's a difference between 3.9x and 4.1 or
 maybe that he has a vue and I have vp2?  At least we got it working. Maybe
 that will work for the OP too!

 

 On Mon, Jun 22, 2020 at 4:29 PM Ernest Jillson 
 wrote:

> I'm helping someone set up a brand new pi with weewx and vantage vue.
> We are getting the same thing in the logs. Failed to publish record. This
> is using python 3 and weewx 4.x (latest). It says it's adding records to
> database, but fails upload to WU. He even tried changing the password.
> Meanwhile I've been running fine with 3.9.2 and python 2.
>
> I'll be following this thread to see what the resolution might end up
> being.
>
>
> On Sun, Jun 21, 2020 at 4:27 PM Tom Keffer  wrote:
>
>> I don't blame you.
>>
>> On Sun, Jun 21, 2020 at 12:23 PM David Barto 
>> wrote:
>>
>>> Perhaps I should just give up on the WU. PWSweather takes my data
>>> just
>>> fine, and I'll add the NWS and a couple of others in the near
>>> future.
>>>
>>> David
>>>
>>> On Jun 21, 2020, at 12:18 PM, Tom Keffer  wrote:
>>>
>>> Sounds like yet another WU SNAFU.
>>>
>>> You could try disabling RapidFire and just use regular postings. RF
>>> has always been unreliable.
>>>
>>> -tk
>>>
>>> On Sun, Jun 21, 2020 at 12:16 PM David Barto 
>>> wrote:
>>>
 Enclosing with quotes didn=E2=80=99t change anything and I logged
 out/in
 from Wunderground and explicitly typed in the password. That worked.

enable = true
station = KCAPOWAY177
password ="AlphaNumericDataH3Re"
# Set the following to True to have weewx use the WU
 "Rapidfire"
# protocol. Not all hardware can support it. See the User's
 Guide.
rapidfire = True

 Still failing. Debug is set to 1, is there anything else that could
 be
 useful?

 David

 On Jun 21, 2020, at 11:42 AM, Tom Keffer  wrote:

 OK, now you have an *upload* problem, which suggests a password
 problem. Make sure you're using the right password. Does it have any
 special characters in it? If so, enclose with quotes in weewx.conf.

 -tk

 On Sun, Jun 21, 2020 at 11:32 AM David Barto 
 wrote:

> Curl gets a 204. So my configuration ’should’ be working.
>
> password is set to the password I login with.
>
> Wunderfixer still returning a 503, so that is unusual.
>
> I’m now seeing.
>
> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF:
> Failed to publish record 2020-06-21 11:26:15 PDT (1592763975): Failed
> upload after 1 tries
> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF:
> Failed to publish record 2020-06-21 11:26:19 PDT (1592763979): Failed
> upload after 1 tries
> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF:
> Failed to publish record 2020-06-21 11:26:25 PDT (1592763985): Failed
> upload after 1 tries
> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF:
> Failed to publish record 2020-06-21 11:26:29 PDT 

Re: [weewx-user] Wunderground doesn't accept my data

[Ernest Jillson]

OP (David) replied back to me directly. That didn't work for him. But his 
setup is identical to mine. weewx 3.9, davis vp2. I'm using actual site 
password. 

On Tuesday, June 23, 2020 at 6:24:03 PM UTC-4, Tom Keffer wrote:
>
> Something new every day from the WeatherUnderground.
>
>
>
> On Tue, Jun 23, 2020 at 3:01 PM Ernest Jillson  > wrote:
>
>> In weewx.conf:  For the password, instead of entering your site password, 
>> try the key there.  It's NOT the api key. It's under "My Devices" in your 
>> member settings on WU.
>>
>> [StdRestful]
>> [[Wunderground]]
>> enable = true
>> station = KCASANFRA11
>> password = 
>> rapidfire = True
>> api_key = xx
>>
>>
>> On Tue, Jun 23, 2020 at 5:46 PM David Barto > > wrote:
>>
>>> Where (what field) did you plug the key into?
>>>
>>> David
>>>
>>> On Jun 23, 2020, at 2:15 PM, Ernest Jillson >> > wrote:
>>>
>>> Ok. This IS strange.
>>>  
>>> I'm running weewx 3.9x and have my data going to wunderground with 
>>> station ID and site password. The person I was helping is using weewx 4.1 
>>> and station ID and password was failing as mentioned in this thread. Today, 
>>> just for the heck of it, he decided to try using the "key" associated with 
>>> his account. Bingo! Not sure if it's a difference between 3.9x and 4.1 or 
>>> maybe that he has a vue and I have vp2?  At least we got it working. Maybe 
>>> that will work for the OP too!
>>>  
>>> 
>>>
>>> On Mon, Jun 22, 2020 at 4:29 PM Ernest Jillson >> > wrote:
>>>
 I'm helping someone set up a brand new pi with weewx and vantage vue. 
 We are getting the same thing in the logs. Failed to publish record. This 
 is using python 3 and weewx 4.x (latest). It says it's adding records to 
 database, but fails upload to WU. He even tried changing the password. 
 Meanwhile I've been running fine with 3.9.2 and python 2.
  
 I'll be following this thread to see what the resolution might end up 
 being.


 On Sun, Jun 21, 2020 at 4:27 PM Tom Keffer >>> > wrote:

> I don't blame you. 
>
> On Sun, Jun 21, 2020 at 12:23 PM David Barto  > wrote:
>
>> Perhaps I should just give up on the WU. PWSweather takes my data just
>> fine, and I'll add the NWS and a couple of others in the near
>> future.
>>
>> David
>>
>> On Jun 21, 2020, at 12:18 PM, Tom Keffer > > wrote:
>>
>> Sounds like yet another WU SNAFU. 
>>
>> You could try disabling RapidFire and just use regular postings. RF 
>> has always been unreliable.
>>
>> -tk
>>
>> On Sun, Jun 21, 2020 at 12:16 PM David Barto > > wrote:
>>
>>> Enclosing with quotes didn=E2=80=99t change anything and I logged 
>>> out/in
>>> from Wunderground and explicitly typed in the password. That worked.
>>>
>>>enable = true
>>>station = KCAPOWAY177
>>>password ="AlphaNumericDataH3Re"
>>># Set the following to True to have weewx use the WU 
>>> "Rapidfire"
>>># protocol. Not all hardware can support it. See the User's 
>>> Guide.
>>>rapidfire = True
>>>
>>> Still failing. Debug is set to 1, is there anything else that could 
>>> be
>>> useful?
>>>
>>> David
>>>
>>> On Jun 21, 2020, at 11:42 AM, Tom Keffer >> > wrote:
>>>
>>> OK, now you have an *upload* problem, which suggests a password 
>>> problem. Make sure you're using the right password. Does it have any 
>>> special characters in it? If so, enclose with quotes in weewx.conf.
>>>
>>> -tk
>>>
>>> On Sun, Jun 21, 2020 at 11:32 AM David Barto >> > wrote:
>>>
 Curl gets a 204. So my configuration ’should’ be working.

 password is set to the password I login with.

 Wunderfixer still returning a 503, so that is unusual.

 I’m now seeing.

 Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: 
 Failed to publish record 2020-06-21 11:26:15 PDT (1592763975): Failed 
 upload after 1 tries
 Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: 
 Failed to publish record 2020-06-21 11:26:19 PDT (1592763979): Failed 
 upload after 1 tries
 Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: 
 Failed to publish record 2020-06-21 11:26:25 PDT (1592763985): Failed 
 upload after 1 tries
 Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: 
 Failed to publish record 2020-06-21 11:26:29 PDT (1592763989): Failed 
 upload after 1 tries
 Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: 
 Failed to publish record 2020-06-21 11:26:35 PDT (1592763995): Failed 
 upload after 1 tries
 Jun 21 11:26:45 Magrathea weewx[23591]: restx: 

Re: [weewx-user] Wunderground doesn't accept my data

[Tom Keffer]

Something new every day from the WeatherUnderground.



On Tue, Jun 23, 2020 at 3:01 PM Ernest Jillson  wrote:

> In weewx.conf:  For the password, instead of entering your site password,
> try the key there.  It's NOT the api key. It's under "My Devices" in your
> member settings on WU.
>
> [StdRestful]
> [[Wunderground]]
> enable = true
> station = KCASANFRA11
> password = 
> rapidfire = True
> api_key = xx
>
>
> On Tue, Jun 23, 2020 at 5:46 PM David Barto  wrote:
>
>> Where (what field) did you plug the key into?
>>
>> David
>>
>> On Jun 23, 2020, at 2:15 PM, Ernest Jillson  wrote:
>>
>> Ok. This IS strange.
>>
>> I'm running weewx 3.9x and have my data going to wunderground with
>> station ID and site password. The person I was helping is using weewx 4.1
>> and station ID and password was failing as mentioned in this thread. Today,
>> just for the heck of it, he decided to try using the "key" associated with
>> his account. Bingo! Not sure if it's a difference between 3.9x and 4.1 or
>> maybe that he has a vue and I have vp2?  At least we got it working. Maybe
>> that will work for the OP too!
>>
>> 
>>
>> On Mon, Jun 22, 2020 at 4:29 PM Ernest Jillson 
>> wrote:
>>
>>> I'm helping someone set up a brand new pi with weewx and vantage vue. We
>>> are getting the same thing in the logs. Failed to publish record. This is
>>> using python 3 and weewx 4.x (latest). It says it's adding records to
>>> database, but fails upload to WU. He even tried changing the password.
>>> Meanwhile I've been running fine with 3.9.2 and python 2.
>>>
>>> I'll be following this thread to see what the resolution might end up
>>> being.
>>>
>>>
>>> On Sun, Jun 21, 2020 at 4:27 PM Tom Keffer  wrote:
>>>
 I don't blame you.

 On Sun, Jun 21, 2020 at 12:23 PM David Barto  wrote:

> Perhaps I should just give up on the WU. PWSweather takes my data just
> fine, and I'll add the NWS and a couple of others in the near
> future.
>
> David
>
> On Jun 21, 2020, at 12:18 PM, Tom Keffer  wrote:
>
> Sounds like yet another WU SNAFU.
>
> You could try disabling RapidFire and just use regular postings. RF
> has always been unreliable.
>
> -tk
>
> On Sun, Jun 21, 2020 at 12:16 PM David Barto 
> wrote:
>
>> Enclosing with quotes didn=E2=80=99t change anything and I logged
>> out/in
>> from Wunderground and explicitly typed in the password. That worked.
>>
>>enable = true
>>station = KCAPOWAY177
>>password ="AlphaNumericDataH3Re"
>># Set the following to True to have weewx use the WU
>> "Rapidfire"
>># protocol. Not all hardware can support it. See the User's
>> Guide.
>>rapidfire = True
>>
>> Still failing. Debug is set to 1, is there anything else that could be
>> useful?
>>
>> David
>>
>> On Jun 21, 2020, at 11:42 AM, Tom Keffer  wrote:
>>
>> OK, now you have an *upload* problem, which suggests a password
>> problem. Make sure you're using the right password. Does it have any
>> special characters in it? If so, enclose with quotes in weewx.conf.
>>
>> -tk
>>
>> On Sun, Jun 21, 2020 at 11:32 AM David Barto 
>> wrote:
>>
>>> Curl gets a 204. So my configuration ’should’ be working.
>>>
>>> password is set to the password I login with.
>>>
>>> Wunderfixer still returning a 503, so that is unusual.
>>>
>>> I’m now seeing.
>>>
>>> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:15 PDT (1592763975): Failed
>>> upload after 1 tries
>>> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:19 PDT (1592763979): Failed
>>> upload after 1 tries
>>> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:25 PDT (1592763985): Failed
>>> upload after 1 tries
>>> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:29 PDT (1592763989): Failed
>>> upload after 1 tries
>>> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:35 PDT (1592763995): Failed
>>> upload after 1 tries
>>> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:39 PDT (1592763999): Failed
>>> upload after 1 tries
>>> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:45 PDT (1592764005): Failed
>>> upload after 1 tries
>>> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF:
>>> Failed to publish record 2020-06-21 11:26:49 PDT (1592764009): 

Re: [weewx-user] Re: Full day highcharts question

[Didier Decoodt]

Hi Pat
After update, the graphic rainTotal does not start at the right date... the
curve should start the 13 jun, not the 1st of june (I have no data before
13 june)
[image: image.png]

Le mar. 23 juin 2020 à 20:46, Manfred Maier  a
écrit :

> Thanks so much, Pat!
> Works perfectly well.
>
> didier@gmail.com schrieb am Dienstag, 23. Juni 2020 um 20:11:16 UTC+2:
>
>> Thanks
>>
>> Le mar. 23 juin 2020 à 19:33, Pat  a écrit :
>>
>>> You can
>>>
>>> a) download the development zip file and run wee_extension --install to
>>> install it again just like you did previously
>>>
>>> or
>>>
>>> b) download the development zip file and manually replace all files
>>>
>>>
>>> On Tuesday, June 23, 2020 at 1:28:26 PM UTC-4, Didier Decoodt wrote:

 Yes I use the development branch. What is the procedure for upgrading?

 Le mar. 23 juin 2020 à 17:23, Pat  a écrit :

>>> I think I have a fix I will add to the development branch. Are you using
> the development branch? Can you try testing it too?
>
> We haven't had rain for a long time, so I am trying this on my year
> chart. You can see attached you can see rainTotal stops today and doesn't
> carry to the end of the year anymore.
>
>
> On Tuesday, June 23, 2020 at 7:09:43 AM UTC-4, Didier Decoodt wrote:
>>
>> I have:
>> aggregate_interval = 86400 # 1 day
>> gapsize = 8640 # 1 day in milliseconds
>> but if aggregate_type=none, then I have a dot each 5 mn (may be it's
>> normal)
>>
>> Le mar. 23 juin 2020 à 02:00, Pat  a écrit :
>>
>>> Change your aggregate_interval to match your gapSize and see if that
>>> helps.
>>>
>>> On Monday, June 22, 2020 at 7:05:00 PM UTC-4, Didier Decoodt wrote:

 Oupss
 It seems to be correct but the aggregate_interval is not correct,
 every 5 mn instead of 1 day for monthly graphic...
 aggregate_type=none is not appropriate...
 (with  aggregate_type=last the curve continue after "now")
 I think the problem is linked with rainTotal variable,

 Le lun. 22 juin 2020 à 22:18, Didier Decoodt 
 a écrit :

> Thanks for this documentation
>
> Le lun. 22 juin 2020 à 21:10, Pat  a écrit :
>
>> rain total works? That's good though I don't know how! :)
>>
>> For the aggregates, Belchertown borrows that from weewx's Seasons
>> and Standard skins. Here's more information from their
>> documentation
>> .
>>
>> On Monday, June 22, 2020 at 2:47:40 PM UTC-4, Didier Decoodt
>> wrote:
>>>
>>> Pat, I put aggregate_type = none instead of max, and it's work!!!
>>> I don't really understand aggregate_type effect
>>> differences between none, sum, min, max and avg?
>>> [image: image.png]
>>>
>>> Le lun. 22 juin 2020 à 19:40, Pat  a
>>> écrit :
>>>
>> I raised this as an issue
 and Tom mentioned
 for the day charts you should probably be using last as the 
 aggregate, not
 max.

 I'll look into rainTotal since that's a Belchertown
 observation.


 On Friday, June 19, 2020 at 2:02:44 PM UTC-4, Pat wrote:
>
> No, not sure. I assume it's because the data points aren't
> reset to "None" using this new way of getting data for the rain 
> observation?
>
> Gary - did you create an issue for this? I'd hate to patch
> something in the skin to only undo it if/when Tom properly 
> patches this.
>
> On Friday, June 19, 2020 at 1:06:11 PM UTC-4,
> didier@gmail.com wrote:
>>
>> Oh, just a small problem:
>> For Rain graph, the curve continue after "now"! (screenshot
>> attached)
>> All others curves stop at datetime=now, it's correct)
>> The problem concern "rainTotal" and is also available for
>> day, week, month and year time_length
>> Have you an idea?
>>
>> hereafter the part of grah.conf
>>
>> [week]
>> # Chart Timespan Defaults
>> title = "Cette semaine"
>> show_button = true
>> button_text = "SEMAINE"
>> time_length = week
>> tooltip_date_format = ""
>> type = spline
>> aggregate_type = max
>> aggregate_interval = 3600 # 1 hour
>> gapsize = 360 # 1 hour in milliseconds
>>
>> [[chart1]]
>> 

Re: [weewx-user] Wunderground doesn't accept my data

[Ernest Jillson]

In weewx.conf:  For the password, instead of entering your site password,
try the key there.  It's NOT the api key. It's under "My Devices" in your
member settings on WU.

[StdRestful]
[[Wunderground]]
enable = true
station = KCASANFRA11
password = 
rapidfire = True
api_key = xx


On Tue, Jun 23, 2020 at 5:46 PM David Barto  wrote:

> Where (what field) did you plug the key into?
>
> David
>
> On Jun 23, 2020, at 2:15 PM, Ernest Jillson  wrote:
>
> Ok. This IS strange.
>
> I'm running weewx 3.9x and have my data going to wunderground with station
> ID and site password. The person I was helping is using weewx 4.1 and
> station ID and password was failing as mentioned in this thread. Today,
> just for the heck of it, he decided to try using the "key" associated with
> his account. Bingo! Not sure if it's a difference between 3.9x and 4.1 or
> maybe that he has a vue and I have vp2?  At least we got it working. Maybe
> that will work for the OP too!
>
> 
>
> On Mon, Jun 22, 2020 at 4:29 PM Ernest Jillson 
> wrote:
>
>> I'm helping someone set up a brand new pi with weewx and vantage vue. We
>> are getting the same thing in the logs. Failed to publish record. This is
>> using python 3 and weewx 4.x (latest). It says it's adding records to
>> database, but fails upload to WU. He even tried changing the password.
>> Meanwhile I've been running fine with 3.9.2 and python 2.
>>
>> I'll be following this thread to see what the resolution might end up
>> being.
>>
>>
>> On Sun, Jun 21, 2020 at 4:27 PM Tom Keffer  wrote:
>>
>>> I don't blame you.
>>>
>>> On Sun, Jun 21, 2020 at 12:23 PM David Barto  wrote:
>>>
 Perhaps I should just give up on the WU. PWSweather takes my data just
 fine, and I'll add the NWS and a couple of others in the near
 future.

 David

 On Jun 21, 2020, at 12:18 PM, Tom Keffer  wrote:

 Sounds like yet another WU SNAFU.

 You could try disabling RapidFire and just use regular postings. RF has
 always been unreliable.

 -tk

 On Sun, Jun 21, 2020 at 12:16 PM David Barto  wrote:

> Enclosing with quotes didn=E2=80=99t change anything and I logged
> out/in
> from Wunderground and explicitly typed in the password. That worked.
>
>enable = true
>station = KCAPOWAY177
>password ="AlphaNumericDataH3Re"
># Set the following to True to have weewx use the WU "Rapidfire"
># protocol. Not all hardware can support it. See the User's
> Guide.
>rapidfire = True
>
> Still failing. Debug is set to 1, is there anything else that could be
> useful?
>
> David
>
> On Jun 21, 2020, at 11:42 AM, Tom Keffer  wrote:
>
> OK, now you have an *upload* problem, which suggests a password
> problem. Make sure you're using the right password. Does it have any
> special characters in it? If so, enclose with quotes in weewx.conf.
>
> -tk
>
> On Sun, Jun 21, 2020 at 11:32 AM David Barto 
> wrote:
>
>> Curl gets a 204. So my configuration ’should’ be working.
>>
>> password is set to the password I login with.
>>
>> Wunderfixer still returning a 503, so that is unusual.
>>
>> I’m now seeing.
>>
>> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:15 PDT (1592763975): Failed
>> upload after 1 tries
>> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:19 PDT (1592763979): Failed
>> upload after 1 tries
>> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:25 PDT (1592763985): Failed
>> upload after 1 tries
>> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:29 PDT (1592763989): Failed
>> upload after 1 tries
>> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:35 PDT (1592763995): Failed
>> upload after 1 tries
>> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:39 PDT (1592763999): Failed
>> upload after 1 tries
>> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:45 PDT (1592764005): Failed
>> upload after 1 tries
>> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:49 PDT (1592764009): Failed
>> upload after 1 tries
>> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF:
>> Failed to publish record 2020-06-21 11:26:55 PDT (1592764015): Failed
>> upload after 1 tries
>> Jun 21 11:27:05 Magrathea weewx[23591]: restx: 

Re: [weewx-user] Wunderground doesn't accept my data

[David Barto]

Where (what field) did you plug the key into?

David

> On Jun 23, 2020, at 2:15 PM, Ernest Jillson  wrote:
> 
> Ok. This IS strange.
>  
> I'm running weewx 3.9x and have my data going to wunderground with station ID 
> and site password. The person I was helping is using weewx 4.1 and station ID 
> and password was failing as mentioned in this thread. Today, just for the 
> heck of it, he decided to try using the "key" associated with his account. 
> Bingo! Not sure if it's a difference between 3.9x and 4.1 or maybe that he 
> has a vue and I have vp2?  At least we got it working. Maybe that will work 
> for the OP too!
>  
> 
> 
> On Mon, Jun 22, 2020 at 4:29 PM Ernest Jillson  > wrote:
> I'm helping someone set up a brand new pi with weewx and vantage vue. We are 
> getting the same thing in the logs. Failed to publish record. This is using 
> python 3 and weewx 4.x (latest). It says it's adding records to database, but 
> fails upload to WU. He even tried changing the password. Meanwhile I've been 
> running fine with 3.9.2 and python 2.
>  
> I'll be following this thread to see what the resolution might end up being.
> 
> 
> On Sun, Jun 21, 2020 at 4:27 PM Tom Keffer  > wrote:
> I don't blame you. 
> 
> On Sun, Jun 21, 2020 at 12:23 PM David Barto  > wrote:
> Perhaps I should just give up on the WU. PWSweather takes my data just
> fine, and I'll add the NWS and a couple of others in the near
> future.
> 
>   David
> 
>> On Jun 21, 2020, at 12:18 PM, Tom Keffer > > wrote:
>> 
>> Sounds like yet another WU SNAFU. 
>> 
>> You could try disabling RapidFire and just use regular postings. RF has 
>> always been unreliable.
>> 
>> -tk
>> 
>> On Sun, Jun 21, 2020 at 12:16 PM David Barto > > wrote:
>> Enclosing with quotes didn=E2=80=99t change anything and I logged out/in
>> from Wunderground and explicitly typed in the password. That worked.
>> 
>>enable = true
>>station = KCAPOWAY177
>>password ="AlphaNumericDataH3Re"
>># Set the following to True to have weewx use the WU "Rapidfire"
>># protocol. Not all hardware can support it. See the User's Guide.
>>rapidfire = True
>> 
>> Still failing. Debug is set to 1, is there anything else that could be
>> useful?
>> 
>>  David
>> 
>>> On Jun 21, 2020, at 11:42 AM, Tom Keffer >> > wrote:
>>> 
>>> OK, now you have an upload problem, which suggests a password problem. Make 
>>> sure you're using the right password. Does it have any special characters 
>>> in it? If so, enclose with quotes in weewx.conf.
>>> 
>>> -tk
>>> 
>>> On Sun, Jun 21, 2020 at 11:32 AM David Barto >> > wrote:
>>> Curl gets a 204. So my configuration ’should’ be working.
>>> 
>>> password is set to the password I login with.
>>> 
>>> Wunderfixer still returning a 503, so that is unusual.
>>> 
>>> I’m now seeing.
>>> 
>>> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload after 1 
>>> tries
>>> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload after 1 
>>> tries
>>> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload after 1 
>>> tries
>>> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload after 1 
>>> tries
>>> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload after 1 
>>> tries
>>> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload after 1 
>>> tries
>>> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload after 1 
>>> tries
>>> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload after 1 
>>> tries
>>> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload after 1 
>>> tries
>>> Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>>> publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload after 1 
>>> tries
>>> 
>>> And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 
>>>  still reports 
>>> ‘offline’.
>>> 
>>> I’ve got ‘debug = 1’ in my configuration, so what else would be useful to 
>>> include to finish this up?
>>> 

[weewx-user] Re: Retroactively calculate database fields

[vince]

On Tuesday, June 23, 2020 at 1:16:09 PM UTC-7, Manfred Maier wrote:
>
> Pushing once.
> Is there a way to perform the calculations of 3rd party extensions for 
> historic timestamps in the database?
>
>
Probably not without writing something equally custom.

The algorithms are (hopefully) well enough known to let a determined 
developer cook up some utility to do so.

-- 
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/2cb6546b-e797-4012-87b6-be5affca7aedo%40googlegroups.com.

Re: [weewx-user] Wunderground doesn't accept my data

[Ernest Jillson]

Ok. This IS strange.

I'm running weewx 3.9x and have my data going to wunderground with station
ID and site password. The person I was helping is using weewx 4.1 and
station ID and password was failing as mentioned in this thread. Today,
just for the heck of it, he decided to try using the "key" associated with
his account. Bingo! Not sure if it's a difference between 3.9x and 4.1 or
maybe that he has a vue and I have vp2?  At least we got it working. Maybe
that will work for the OP too!

[image: WU_PWS_Key.JPG]

On Mon, Jun 22, 2020 at 4:29 PM Ernest Jillson  wrote:

> I'm helping someone set up a brand new pi with weewx and vantage vue. We
> are getting the same thing in the logs. Failed to publish record. This is
> using python 3 and weewx 4.x (latest). It says it's adding records to
> database, but fails upload to WU. He even tried changing the password.
> Meanwhile I've been running fine with 3.9.2 and python 2.
>
> I'll be following this thread to see what the resolution might end up
> being.
>
>
> On Sun, Jun 21, 2020 at 4:27 PM Tom Keffer  wrote:
>
>> I don't blame you.
>>
>> On Sun, Jun 21, 2020 at 12:23 PM David Barto  wrote:
>>
>>> Perhaps I should just give up on the WU. PWSweather takes my data just
>>> fine, and I'll add the NWS and a couple of others in the near
>>> future.
>>>
>>> David
>>>
>>> On Jun 21, 2020, at 12:18 PM, Tom Keffer  wrote:
>>>
>>> Sounds like yet another WU SNAFU.
>>>
>>> You could try disabling RapidFire and just use regular postings. RF has
>>> always been unreliable.
>>>
>>> -tk
>>>
>>> On Sun, Jun 21, 2020 at 12:16 PM David Barto  wrote:
>>>
 Enclosing with quotes didn=E2=80=99t change anything and I logged out/in
 from Wunderground and explicitly typed in the password. That worked.

enable = true
station = KCAPOWAY177
password ="AlphaNumericDataH3Re"
# Set the following to True to have weewx use the WU "Rapidfire"
# protocol. Not all hardware can support it. See the User's
 Guide.
rapidfire = True

 Still failing. Debug is set to 1, is there anything else that could be
 useful?

 David

 On Jun 21, 2020, at 11:42 AM, Tom Keffer  wrote:

 OK, now you have an *upload* problem, which suggests a password
 problem. Make sure you're using the right password. Does it have any
 special characters in it? If so, enclose with quotes in weewx.conf.

 -tk

 On Sun, Jun 21, 2020 at 11:32 AM David Barto  wrote:

> Curl gets a 204. So my configuration ’should’ be working.
>
> password is set to the password I login with.
>
> Wunderfixer still returning a 503, so that is unusual.
>
> I’m now seeing.
>
> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload 
> after
> 1 tries
> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload 
> after
> 1 tries
> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload 
> after
> 1 tries
> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload 
> after
> 1 tries
> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload 
> after
> 1 tries
> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload 
> after
> 1 tries
> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload 
> after
> 1 tries
> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload 
> after
> 1 tries
> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload 
> after
> 1 tries
> Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
> to publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload 
> after
> 1 tries
>
> And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 still
> reports ‘offline’.
>
> I’ve got ‘debug = 1’ in my configuration, so what else would be useful
> to include to finish this up?
>
> David
>
> On Jun 21, 2020, at 10:48 AM, Tom Keffer  wrote:
>
> Blank page is probably good, and hopefully means that it's accepting
> the API key. To be sure, try curl:
>
> curl -i 

[weewx-user] Re: Retroactively calculate database fields

[Manfred Maier]

Pushing once.
Is there a way to perform the calculations of 3rd party extensions for 
historic timestamps in the database?

Manfred Maier schrieb am Sonntag, 21. Juni 2020 um 22:22:43 UTC+2:

> Hi,
> I've added new fields to the database (e.g. sunshineTime) and I'm 
> populating them with an adapted version of the radiationhours.py extension. 
>
> Is there a way to also populate those fields for data records of past 
> times?
> I've tried "wee_database --calc-missing", but had no success.
>
> Ideas and hints highly appreciated!
>
> Thanks!
> Manfred 
>

-- 
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/29b86d4a-4836-43a5-ac3d-006eda168f52n%40googlegroups.com.

[weewx-user] Re: Interceptor and WH57 Lightning sensor from Ecowitt

['olicat' via weewx-user]

Hi!

Are there any experiences with the adjusted script regarding lightning?
Does it work for you now?

Regards, Oliver

-- 
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/cbdb79ed-eed1-44ac-96e6-33056e2ed9b4o%40googlegroups.com.

Re: [weewx-user] Re: Full day highcharts question

[Manfred Maier]

Thanks so much, Pat!
Works perfectly well.

didier@gmail.com schrieb am Dienstag, 23. Juni 2020 um 20:11:16 UTC+2:

> Thanks 
>
> Le mar. 23 juin 2020 à 19:33, Pat  a écrit :
>
>> You can 
>>
>> a) download the development zip file and run wee_extension --install to 
>> install it again just like you did previously
>>
>> or 
>>
>> b) download the development zip file and manually replace all files
>>
>>
>> On Tuesday, June 23, 2020 at 1:28:26 PM UTC-4, Didier Decoodt wrote:
>>>
>>> Yes I use the development branch. What is the procedure for upgrading?
>>>
>>> Le mar. 23 juin 2020 à 17:23, Pat  a écrit :
>>>
>> I think I have a fix I will add to the development branch. Are you using 
 the development branch? Can you try testing it too?

 We haven't had rain for a long time, so I am trying this on my year 
 chart. You can see attached you can see rainTotal stops today and doesn't 
 carry to the end of the year anymore. 


 On Tuesday, June 23, 2020 at 7:09:43 AM UTC-4, Didier Decoodt wrote:
>
> I have:
> aggregate_interval = 86400 # 1 day
> gapsize = 8640 # 1 day in milliseconds
> but if aggregate_type=none, then I have a dot each 5 mn (may be it's 
> normal)
>
> Le mar. 23 juin 2020 à 02:00, Pat  a écrit :
>
>> Change your aggregate_interval to match your gapSize and see if that 
>> helps. 
>>
>> On Monday, June 22, 2020 at 7:05:00 PM UTC-4, Didier Decoodt wrote:
>>>
>>> Oupss
>>> It seems to be correct but the aggregate_interval is not correct, 
>>> every 5 mn instead of 1 day for monthly graphic...
>>> aggregate_type=none is not appropriate...
>>> (with  aggregate_type=last the curve continue after "now")
>>> I think the problem is linked with rainTotal variable, 
>>>
>>> Le lun. 22 juin 2020 à 22:18, Didier Decoodt  
>>> a écrit :
>>>
 Thanks for this documentation

 Le lun. 22 juin 2020 à 21:10, Pat  a écrit :

> rain total works? That's good though I don't know how! :)
>
> For the aggregates, Belchertown borrows that from weewx's Seasons 
> and Standard skins. Here's more information from their 
> documentation 
> . 
>
> On Monday, June 22, 2020 at 2:47:40 PM UTC-4, Didier Decoodt wrote:
>>
>> Pat, I put aggregate_type = none instead of max, and it's work!!!
>> I don't really understand aggregate_type effect
>> differences between none, sum, min, max and avg?
>> [image: image.png]
>>
>> Le lun. 22 juin 2020 à 19:40, Pat  a 
>> écrit :
>>
> I raised this as an issue 
>>> and Tom mentioned 
>>> for the day charts you should probably be using last as the 
>>> aggregate, not 
>>> max. 
>>>
>>> I'll look into rainTotal since that's a Belchertown observation. 
>>>
>>>
>>> On Friday, June 19, 2020 at 2:02:44 PM UTC-4, Pat wrote:

 No, not sure. I assume it's because the data points aren't 
 reset to "None" using this new way of getting data for the rain 
 observation?

 Gary - did you create an issue for this? I'd hate to patch 
 something in the skin to only undo it if/when Tom properly patches 
 this.

 On Friday, June 19, 2020 at 1:06:11 PM UTC-4, 
 didier@gmail.com wrote:
>
> Oh, just a small problem:
> For Rain graph, the curve continue after "now"! (screenshot 
> attached)
> All others curves stop at datetime=now, it's correct)
> The problem concern "rainTotal" and is also available for day, 
> week, month and year time_length
> Have you an idea?
>
> hereafter the part of grah.conf
>
> [week]
> # Chart Timespan Defaults
> title = "Cette semaine"
> show_button = true
> button_text = "SEMAINE"
> time_length = week
> tooltip_date_format = ""
> type = spline
> aggregate_type = max
> aggregate_interval = 3600 # 1 hour
> gapsize = 360 # 1 hour in milliseconds
>
> [[chart1]]
> title = Température
> [[[outTemp]]]
> color = "#b2df8a"
> [[[dewpoint]]]
> yAxis_label = ( °C )
> yAxis_tickInterval = 2
> yAxis_softMin = 0
> 
> [[chart2]]
> title = Pluie

Re: [weewx-user] Re: Full day highcharts question

[Didier Decoodt]

Thanks

Le mar. 23 juin 2020 à 19:33, Pat  a écrit :

> You can
>
> a) download the development zip file and run wee_extension --install to
> install it again just like you did previously
>
> or
>
> b) download the development zip file and manually replace all files
>
>
> On Tuesday, June 23, 2020 at 1:28:26 PM UTC-4, Didier Decoodt wrote:
>>
>> Yes I use the development branch. What is the procedure for upgrading?
>>
>> Le mar. 23 juin 2020 à 17:23, Pat  a écrit :
>>
> I think I have a fix I will add to the development branch. Are you using
>>> the development branch? Can you try testing it too?
>>>
>>> We haven't had rain for a long time, so I am trying this on my year
>>> chart. You can see attached you can see rainTotal stops today and doesn't
>>> carry to the end of the year anymore.
>>>
>>>
>>> On Tuesday, June 23, 2020 at 7:09:43 AM UTC-4, Didier Decoodt wrote:

 I have:
 aggregate_interval = 86400 # 1 day
 gapsize = 8640 # 1 day in milliseconds
 but if aggregate_type=none, then I have a dot each 5 mn (may be it's
 normal)

 Le mar. 23 juin 2020 à 02:00, Pat  a écrit :

> Change your aggregate_interval to match your gapSize and see if that
> helps.
>
> On Monday, June 22, 2020 at 7:05:00 PM UTC-4, Didier Decoodt wrote:
>>
>> Oupss
>> It seems to be correct but the aggregate_interval is not correct,
>> every 5 mn instead of 1 day for monthly graphic...
>> aggregate_type=none is not appropriate...
>> (with  aggregate_type=last the curve continue after "now")
>> I think the problem is linked with rainTotal variable,
>>
>> Le lun. 22 juin 2020 à 22:18, Didier Decoodt  a
>> écrit :
>>
>>> Thanks for this documentation
>>>
>>> Le lun. 22 juin 2020 à 21:10, Pat  a écrit :
>>>
 rain total works? That's good though I don't know how! :)

 For the aggregates, Belchertown borrows that from weewx's Seasons
 and Standard skins. Here's more information from their
 documentation
 .

 On Monday, June 22, 2020 at 2:47:40 PM UTC-4, Didier Decoodt wrote:
>
> Pat, I put aggregate_type = none instead of max, and it's work!!!
> I don't really understand aggregate_type effect
> differences between none, sum, min, max and avg?
> [image: image.png]
>
> Le lun. 22 juin 2020 à 19:40, Pat  a écrit :
>
 I raised this as an issue
>> and Tom mentioned for
>> the day charts you should probably be using last as the aggregate, 
>> not max.
>>
>> I'll look into rainTotal since that's a Belchertown observation.
>>
>>
>> On Friday, June 19, 2020 at 2:02:44 PM UTC-4, Pat wrote:
>>>
>>> No, not sure. I assume it's because the data points aren't reset
>>> to "None" using this new way of getting data for the rain 
>>> observation?
>>>
>>> Gary - did you create an issue for this? I'd hate to patch
>>> something in the skin to only undo it if/when Tom properly patches 
>>> this.
>>>
>>> On Friday, June 19, 2020 at 1:06:11 PM UTC-4,
>>> didier@gmail.com wrote:

 Oh, just a small problem:
 For Rain graph, the curve continue after "now"! (screenshot
 attached)
 All others curves stop at datetime=now, it's correct)
 The problem concern "rainTotal" and is also available for day,
 week, month and year time_length
 Have you an idea?

 hereafter the part of grah.conf

 [week]
 # Chart Timespan Defaults
 title = "Cette semaine"
 show_button = true
 button_text = "SEMAINE"
 time_length = week
 tooltip_date_format = ""
 type = spline
 aggregate_type = max
 aggregate_interval = 3600 # 1 hour
 gapsize = 360 # 1 hour in milliseconds

 [[chart1]]
 title = Température
 [[[outTemp]]]
 color = "#b2df8a"
 [[[dewpoint]]]
 yAxis_label = ( °C )
 yAxis_tickInterval = 2
 yAxis_softMin = 0

 [[chart2]]
 title = Pluie
 [[[rainTotal]]]  <
 Problem
 color = "#f7a35c"
 name = Cumul
 [[[rain]]]
 color = "#268bd2"
 aggregate_type = sum
 name = pluie
 type = 

Re: [weewx-user] Cydia pomonella

[Tom Keffer]

Cool.

I don't see why the new xtypes facility
 can't be
used to calculate your version of growing degree days. It allows you to
define new types. Take a look at it and see if it helps.

On Tue, Jun 23, 2020 at 10:40 AM Chuck Rhode 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, 22 Jun 2020 18:39:28 -0700
> Tom Keffer  wrote:
>
> > First, "growing degree days
> > " is now a
> > first-class type, analogous to heating- and cooling-degree days.
>
> Thanks for your reply.  Yes, but it's more than analogous; it's the
> identical code to cooling-degree days.  This is the max-min
> calculation used in crop science.
>
> What I refer to as growing-degree-days is a wide family of
> insect-development models.  These depend on temperature but, like
> max-min, are non-linear at the threshold.  Whether they become
> independent of temperature above the cutoff or actually decline is up
> to the modeler's interpretation of the behavior of his favorite insect
> (sub)species, and he has various mathematical techniques with which to
> work his will.
>
> I hope to be able to provide *python* functions for
> growing-degree-days on daily max/min temps, threshold, and cutoff that
> will exhaust the research literature.
>
> Here is why I regard growing-degree-days models superior to max-min.
> For me in Sheboygan:
>
>   The growing degree-days (GDD) calculated by Baskerville and Emin's
>   single sine horizontal cutoff method outruns the conventional
>   degree-days (DD) calculated by the max-min method by about a week.
>
> o http://lacusveris.com/cydia/models.shtml#x83
>
> > Second, see issue #341 ,
> > which discusses support for generating JSON series using the Cheetah
> > generator. The intention was to use these series to drive things like
> > Highchart plots. Nothing much has happened to the issue recently
> > (it's nearly 2 years old), but perhaps this is what you had in mind?
>
> Yes, *json* or *csv*-formatted strings (wrapped to sensible margin
> widths, of course) would be nifty.  This would make *html*-embedded
> *javascript* code very terse.
>
> I'm under the impression the absence of the patch is not a stopper
> because I've been generating *.csv files from *cheetah* all along ...
> with *for* loops, of course.
>
> I'm also under the impression that *cheetah* can generate *python*
> code from a template.  I'd hope to keep all the specs for an image or
> a suite of images together in one *python* module including the data,
> cutoff dates, curve names, colors, axis labels, titles, etc, etc, etc.
> It's not something you'd do with a compiled language, but interpreted
> languages almost beg to be abused in this way.
>
> I haven't tried any of this, yet.  I reserve the right to change my
> mind.
>
> - --
> .. Be Seeing You,
> .. Chuck Rhode, Sheboygan, WI, USA
> .. Weather:  http://LacusVeris.com/WX
> ..
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iEYEARECAAYFAl7yPqAACgkQYNv8YqSjllLjDgCdHq+dKB0k8gLDjZU5dMJHaJlF
> dKQAni3fbSe33utKBToZ6ojJtFA6xcmd
> =iQZf
> -END PGP SIGNATURE-
>
> --
> 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/20200623124048.5f5ff7e9%40quixote.LacusVeris.com
> .
>

-- 
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/CAPq0zEAJBqFqe8%2BRGP3%2BmbRSAKoYmK7dQUkFcMisbVhPkq%2BmFA%40mail.gmail.com.

Re: [weewx-user] Cydia pomonella

[Chuck Rhode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 22 Jun 2020 18:39:28 -0700
Tom Keffer  wrote:

> First, "growing degree days
> " is now a
> first-class type, analogous to heating- and cooling-degree days.

Thanks for your reply.  Yes, but it's more than analogous; it's the
identical code to cooling-degree days.  This is the max-min
calculation used in crop science.

What I refer to as growing-degree-days is a wide family of
insect-development models.  These depend on temperature but, like
max-min, are non-linear at the threshold.  Whether they become
independent of temperature above the cutoff or actually decline is up
to the modeler's interpretation of the behavior of his favorite insect
(sub)species, and he has various mathematical techniques with which to
work his will.

I hope to be able to provide *python* functions for
growing-degree-days on daily max/min temps, threshold, and cutoff that
will exhaust the research literature.

Here is why I regard growing-degree-days models superior to max-min.
For me in Sheboygan:

  The growing degree-days (GDD) calculated by Baskerville and Emin's
  single sine horizontal cutoff method outruns the conventional
  degree-days (DD) calculated by the max-min method by about a week.

o http://lacusveris.com/cydia/models.shtml#x83

> Second, see issue #341 ,
> which discusses support for generating JSON series using the Cheetah
> generator. The intention was to use these series to drive things like
> Highchart plots. Nothing much has happened to the issue recently
> (it's nearly 2 years old), but perhaps this is what you had in mind?

Yes, *json* or *csv*-formatted strings (wrapped to sensible margin
widths, of course) would be nifty.  This would make *html*-embedded
*javascript* code very terse.

I'm under the impression the absence of the patch is not a stopper
because I've been generating *.csv files from *cheetah* all along ...
with *for* loops, of course.

I'm also under the impression that *cheetah* can generate *python*
code from a template.  I'd hope to keep all the specs for an image or
a suite of images together in one *python* module including the data,
cutoff dates, curve names, colors, axis labels, titles, etc, etc, etc.
It's not something you'd do with a compiled language, but interpreted
languages almost beg to be abused in this way.

I haven't tried any of this, yet.  I reserve the right to change my
mind.

- -- 
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather:  http://LacusVeris.com/WX
.. 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAl7yPqAACgkQYNv8YqSjllLjDgCdHq+dKB0k8gLDjZU5dMJHaJlF
dKQAni3fbSe33utKBToZ6ojJtFA6xcmd
=iQZf
-END PGP SIGNATURE-

-- 
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/20200623124048.5f5ff7e9%40quixote.LacusVeris.com.

Re: [weewx-user] Re: Full day highcharts question

[Pat]

You can 

a) download the development zip file and run wee_extension --install to 
install it again just like you did previously

or 

b) download the development zip file and manually replace all files


On Tuesday, June 23, 2020 at 1:28:26 PM UTC-4, Didier Decoodt wrote:
>
> Yes I use the development branch. What is the procedure for upgrading?
>
> Le mar. 23 juin 2020 à 17:23, Pat > a 
> écrit :
>
>> I think I have a fix I will add to the development branch. Are you using 
>> the development branch? Can you try testing it too?
>>
>> We haven't had rain for a long time, so I am trying this on my year 
>> chart. You can see attached you can see rainTotal stops today and doesn't 
>> carry to the end of the year anymore. 
>>
>>
>> On Tuesday, June 23, 2020 at 7:09:43 AM UTC-4, Didier Decoodt wrote:
>>>
>>> I have:
>>> aggregate_interval = 86400 # 1 day
>>> gapsize = 8640 # 1 day in milliseconds
>>> but if aggregate_type=none, then I have a dot each 5 mn (may be it's 
>>> normal)
>>>
>>> Le mar. 23 juin 2020 à 02:00, Pat  a écrit :
>>>
 Change your aggregate_interval to match your gapSize and see if that 
 helps. 

 On Monday, June 22, 2020 at 7:05:00 PM UTC-4, Didier Decoodt wrote:
>
> Oupss
> It seems to be correct but the aggregate_interval is not correct, 
> every 5 mn instead of 1 day for monthly graphic...
> aggregate_type=none is not appropriate...
> (with  aggregate_type=last the curve continue after "now")
> I think the problem is linked with rainTotal variable, 
>
> Le lun. 22 juin 2020 à 22:18, Didier Decoodt  a 
> écrit :
>
>> Thanks for this documentation
>>
>> Le lun. 22 juin 2020 à 21:10, Pat  a écrit :
>>
>>> rain total works? That's good though I don't know how! :)
>>>
>>> For the aggregates, Belchertown borrows that from weewx's Seasons 
>>> and Standard skins. Here's more information from their documentation 
>>> . 
>>>
>>> On Monday, June 22, 2020 at 2:47:40 PM UTC-4, Didier Decoodt wrote:

 Pat, I put aggregate_type = none instead of max, and it's work!!!
 I don't really understand aggregate_type effect
 differences between none, sum, min, max and avg?
 [image: image.png]

 Le lun. 22 juin 2020 à 19:40, Pat  a écrit :

>>> I raised this as an issue 
> and Tom mentioned for 
> the day charts you should probably be using last as the aggregate, 
> not max. 
>
> I'll look into rainTotal since that's a Belchertown observation. 
>
>
> On Friday, June 19, 2020 at 2:02:44 PM UTC-4, Pat wrote:
>>
>> No, not sure. I assume it's because the data points aren't reset 
>> to "None" using this new way of getting data for the rain 
>> observation?
>>
>> Gary - did you create an issue for this? I'd hate to patch 
>> something in the skin to only undo it if/when Tom properly patches 
>> this.
>>
>> On Friday, June 19, 2020 at 1:06:11 PM UTC-4, 
>> didier@gmail.com wrote:
>>>
>>> Oh, just a small problem:
>>> For Rain graph, the curve continue after "now"! (screenshot 
>>> attached)
>>> All others curves stop at datetime=now, it's correct)
>>> The problem concern "rainTotal" and is also available for day, 
>>> week, month and year time_length
>>> Have you an idea?
>>>
>>> hereafter the part of grah.conf
>>>
>>> [week]
>>> # Chart Timespan Defaults
>>> title = "Cette semaine"
>>> show_button = true
>>> button_text = "SEMAINE"
>>> time_length = week
>>> tooltip_date_format = ""
>>> type = spline
>>> aggregate_type = max
>>> aggregate_interval = 3600 # 1 hour
>>> gapsize = 360 # 1 hour in milliseconds
>>>
>>> [[chart1]]
>>> title = Température
>>> [[[outTemp]]]
>>> color = "#b2df8a"
>>> [[[dewpoint]]]
>>> yAxis_label = ( °C )
>>> yAxis_tickInterval = 2
>>> yAxis_softMin = 0
>>> 
>>> [[chart2]]
>>> title = Pluie
>>> [[[rainTotal]]]  < 
>>> Problem
>>> color = "#f7a35c"
>>> name = Cumul
>>> [[[rain]]]
>>> color = "#268bd2"
>>> aggregate_type = sum
>>> name = pluie
>>> type = column
>>> yAxis_tickInterval = 1
>>> yAxis_label = ( mm )
>>> yAxis_min = 0
>>>
>>>

Re: [weewx-user] Re: Full day highcharts question

[Didier Decoodt]

Yes I use the development branch. What is the procedure for upgrading?

Le mar. 23 juin 2020 à 17:23, Pat  a écrit :

> I think I have a fix I will add to the development branch. Are you using
> the development branch? Can you try testing it too?
>
> We haven't had rain for a long time, so I am trying this on my year chart.
> You can see attached you can see rainTotal stops today and doesn't carry to
> the end of the year anymore.
>
>
> On Tuesday, June 23, 2020 at 7:09:43 AM UTC-4, Didier Decoodt wrote:
>>
>> I have:
>> aggregate_interval = 86400 # 1 day
>> gapsize = 8640 # 1 day in milliseconds
>> but if aggregate_type=none, then I have a dot each 5 mn (may be it's
>> normal)
>>
>> Le mar. 23 juin 2020 à 02:00, Pat  a écrit :
>>
>>> Change your aggregate_interval to match your gapSize and see if that
>>> helps.
>>>
>>> On Monday, June 22, 2020 at 7:05:00 PM UTC-4, Didier Decoodt wrote:

 Oupss
 It seems to be correct but the aggregate_interval is not correct, every
 5 mn instead of 1 day for monthly graphic...
 aggregate_type=none is not appropriate...
 (with  aggregate_type=last the curve continue after "now")
 I think the problem is linked with rainTotal variable,

 Le lun. 22 juin 2020 à 22:18, Didier Decoodt  a
 écrit :

> Thanks for this documentation
>
> Le lun. 22 juin 2020 à 21:10, Pat  a écrit :
>
>> rain total works? That's good though I don't know how! :)
>>
>> For the aggregates, Belchertown borrows that from weewx's Seasons and
>> Standard skins. Here's more information from their documentation
>> .
>>
>> On Monday, June 22, 2020 at 2:47:40 PM UTC-4, Didier Decoodt wrote:
>>>
>>> Pat, I put aggregate_type = none instead of max, and it's work!!!
>>> I don't really understand aggregate_type effect
>>> differences between none, sum, min, max and avg?
>>> [image: image.png]
>>>
>>> Le lun. 22 juin 2020 à 19:40, Pat  a écrit :
>>>
>> I raised this as an issue and
 Tom mentioned for the day charts you should probably be using last as 
 the
 aggregate, not max.

 I'll look into rainTotal since that's a Belchertown observation.


 On Friday, June 19, 2020 at 2:02:44 PM UTC-4, Pat wrote:
>
> No, not sure. I assume it's because the data points aren't reset
> to "None" using this new way of getting data for the rain observation?
>
> Gary - did you create an issue for this? I'd hate to patch
> something in the skin to only undo it if/when Tom properly patches 
> this.
>
> On Friday, June 19, 2020 at 1:06:11 PM UTC-4, didier@gmail.com
> wrote:
>>
>> Oh, just a small problem:
>> For Rain graph, the curve continue after "now"! (screenshot
>> attached)
>> All others curves stop at datetime=now, it's correct)
>> The problem concern "rainTotal" and is also available for day,
>> week, month and year time_length
>> Have you an idea?
>>
>> hereafter the part of grah.conf
>>
>> [week]
>> # Chart Timespan Defaults
>> title = "Cette semaine"
>> show_button = true
>> button_text = "SEMAINE"
>> time_length = week
>> tooltip_date_format = ""
>> type = spline
>> aggregate_type = max
>> aggregate_interval = 3600 # 1 hour
>> gapsize = 360 # 1 hour in milliseconds
>>
>> [[chart1]]
>> title = Température
>> [[[outTemp]]]
>> color = "#b2df8a"
>> [[[dewpoint]]]
>> yAxis_label = ( °C )
>> yAxis_tickInterval = 2
>> yAxis_softMin = 0
>>
>> [[chart2]]
>> title = Pluie
>> [[[rainTotal]]]  <
>> Problem
>> color = "#f7a35c"
>> name = Cumul
>> [[[rain]]]
>> color = "#268bd2"
>> aggregate_type = sum
>> name = pluie
>> type = column
>> yAxis_tickInterval = 1
>> yAxis_label = ( mm )
>> yAxis_min = 0
>>
>>
>> Le lundi 15 juin 2020 à 14:58:26 UTC+2, Pat a écrit :
>>
>>> Awesome! Glad that it worked for you
>>>
>>>
>>> On Monday, June 15, 2020 at 5:29:59 AM UTC-4,
>>> didier@gmail.com wrote:

 Thanks it's work 


 Le lundi 15 juin 2020 à 11:12:27 UTC+2, Manfred Maier a écrit :

> Thanks, Gary, for this 

Re: [weewx-user] Re: Full day highcharts question

[Pat]

I think I have a fix I will add to the development branch. Are you using 
the development branch? Can you try testing it too?

We haven't had rain for a long time, so I am trying this on my year chart. 
You can see attached you can see rainTotal stops today and doesn't carry to 
the end of the year anymore. 


On Tuesday, June 23, 2020 at 7:09:43 AM UTC-4, Didier Decoodt wrote:
>
> I have:
> aggregate_interval = 86400 # 1 day
> gapsize = 8640 # 1 day in milliseconds
> but if aggregate_type=none, then I have a dot each 5 mn (may be it's 
> normal)
>
> Le mar. 23 juin 2020 à 02:00, Pat > a 
> écrit :
>
>> Change your aggregate_interval to match your gapSize and see if that 
>> helps. 
>>
>> On Monday, June 22, 2020 at 7:05:00 PM UTC-4, Didier Decoodt wrote:
>>>
>>> Oupss
>>> It seems to be correct but the aggregate_interval is not correct, every 
>>> 5 mn instead of 1 day for monthly graphic...
>>> aggregate_type=none is not appropriate...
>>> (with  aggregate_type=last the curve continue after "now")
>>> I think the problem is linked with rainTotal variable, 
>>>
>>> Le lun. 22 juin 2020 à 22:18, Didier Decoodt  a 
>>> écrit :
>>>
 Thanks for this documentation

 Le lun. 22 juin 2020 à 21:10, Pat  a écrit :

> rain total works? That's good though I don't know how! :)
>
> For the aggregates, Belchertown borrows that from weewx's Seasons and 
> Standard skins. Here's more information from their documentation 
> . 
>
> On Monday, June 22, 2020 at 2:47:40 PM UTC-4, Didier Decoodt wrote:
>>
>> Pat, I put aggregate_type = none instead of max, and it's work!!!
>> I don't really understand aggregate_type effect
>> differences between none, sum, min, max and avg?
>> [image: image.png]
>>
>> Le lun. 22 juin 2020 à 19:40, Pat  a écrit :
>>
> I raised this as an issue and 
>>> Tom mentioned for the day charts you should probably be using last as 
>>> the 
>>> aggregate, not max. 
>>>
>>> I'll look into rainTotal since that's a Belchertown observation. 
>>>
>>>
>>> On Friday, June 19, 2020 at 2:02:44 PM UTC-4, Pat wrote:

 No, not sure. I assume it's because the data points aren't reset to 
 "None" using this new way of getting data for the rain observation?

 Gary - did you create an issue for this? I'd hate to patch 
 something in the skin to only undo it if/when Tom properly patches 
 this.

 On Friday, June 19, 2020 at 1:06:11 PM UTC-4, didier@gmail.com 
 wrote:
>
> Oh, just a small problem:
> For Rain graph, the curve continue after "now"! (screenshot 
> attached)
> All others curves stop at datetime=now, it's correct)
> The problem concern "rainTotal" and is also available for day, 
> week, month and year time_length
> Have you an idea?
>
> hereafter the part of grah.conf
>
> [week]
> # Chart Timespan Defaults
> title = "Cette semaine"
> show_button = true
> button_text = "SEMAINE"
> time_length = week
> tooltip_date_format = ""
> type = spline
> aggregate_type = max
> aggregate_interval = 3600 # 1 hour
> gapsize = 360 # 1 hour in milliseconds
>
> [[chart1]]
> title = Température
> [[[outTemp]]]
> color = "#b2df8a"
> [[[dewpoint]]]
> yAxis_label = ( °C )
> yAxis_tickInterval = 2
> yAxis_softMin = 0
> 
> [[chart2]]
> title = Pluie
> [[[rainTotal]]]  < 
> Problem
> color = "#f7a35c"
> name = Cumul
> [[[rain]]]
> color = "#268bd2"
> aggregate_type = sum
> name = pluie
> type = column
> yAxis_tickInterval = 1
> yAxis_label = ( mm )
> yAxis_min = 0
>
>
> Le lundi 15 juin 2020 à 14:58:26 UTC+2, Pat a écrit :
>
>> Awesome! Glad that it worked for you
>>
>>
>> On Monday, June 15, 2020 at 5:29:59 AM UTC-4, 
>> didier@gmail.com wrote:
>>>
>>> Thanks it's work 
>>>
>>>
>>> Le lundi 15 juin 2020 à 11:12:27 UTC+2, Manfred Maier a écrit :
>>>
 Thanks, Gary, for this comprehensive explanation.

 Based on what you wrote I was now able to plot an entire day.

 [image: Bildschirmfoto 2020-06-15 um 11.07.53.png]

 The trick 

[weewx-user] Re: Interceptor and WH57 Lightning sensor from Ecowitt

[John Burricelli]

You would have to script it, but this command will convert the date.

# date -d @1592562248
Fri 19 Jun 06:24:08 EDT 2020

On Friday, June 19, 2020 at 6:28:10 AM UTC-4, NanoG5Kite wrote:
>
> Hi Gert,
>
> then you are further than me the last time and I also did another error 
> last time, using: 
>
> [[sensor_map]]insteadt of [[sensor_map_extensions]]
>
> So I have no really good answer for now. But will try also over the weekend.
>
> What I know so far. The lightning_time is Unix time - so for now/noon 
> something like : 
> 1592562248 - for me without further conversion to a normal/understandable 
> time string not usable...
>
> Br, Matthias
>
>
>
> Am Freitag, 19. Juni 2020 09:53:49 UTC+2 schrieb Gert Andersen:
>>
>> Hi Matthias
>>
>> Yes I have the data and data inserted into the DB. But with this setting:
>>
>> [[sensor_map_extensions]]
>> lightning_strike_count = lightning_num
>> lightning_distance = lightning
>>
>> You're missing this information:
>> lightning_time
>> wh57batt
>>
>> Because these fields are not mapped to any fields in the DB. So the 
>> question is, should I extend the DB to include these fields or are there 
>> any other solution. What have you done? If you have done the mapping which 
>> types are you then mapping lightning_time and wh57batt to in the weewx.sdb.
>>
>> I'm using the extended scheme.
>>
>> Gert
>>
>> On Friday, June 19, 2020 at 7:28:47 AM UTC+2, NanoG5Kite wrote:
>>>
>>> Hi Gert,
>>>
>>> I‘m not sure about the Battery Value, but has your sensor and gw1000 
>>> ever detected one strike before? You need this first strike to get all data 
>>> points.
>>>
>>> Br,
>>>
>>> Matthias
>>>
>>> Am Freitag, 19. Juni 2020 06:42:15 UTC+2 schrieb Gert Andersen:

 Hi 
 I'm also waiting to the next strike.

 What do you do with the 2 other fields:
 lightning_time
 wh57batt

 Currently they are not in the database, so have you updated the 
 database with these fields or just forget them?

 Thanks to Oliver for the help.

 Gert


 On Saturday, June 6, 2020 at 10:28:48 AM UTC+2, Gert Andersen wrote:
>
> Hi
>
> I get these infos from the log:
>
> INFO user.interceptor: unrecognized parameter lightning_time=
> INFO user.interceptor: unrecognized parameter lightning_num=0
> INFO user.interceptor: unrecognized parameter lightning=
> INFO user.interceptor: unrecognized parameter wh57batt=5
>
> I could not see a new version at Github, the latest version include 
> wh40 and is 4 month old. Seems to be version 0.53
>
> Is there a newer version around which include the lightning sensor.
>
> Gert
>


-- 
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/633f6256-5481-4d25-bef7-d3f09f7f750ao%40googlegroups.com.

Re: [weewx-user] Monthly Summaries are empty

[Tom Keffer]

Hmmm, OK.

A line is printed only if it contains one of temperature, rain, or wind. It
seems unlikely, but perhaps you are missing all three? To test that, in the
template NOAA-%Y-%m.txt.tmpl, change the lines

#for $day in $month.days
#if $day.outTemp.count.raw or $day.rain.count.raw or $day.wind.count.raw
$day.dateTime.format($D, add_label=False)
$day.outTemp.avg.format($Temp,$NONE,add_label=False)
$day.outTemp.max.format($Temp,$NONE,add_label=False)
$day.outTemp.maxtime.format($Time,add_label=False)
$day.outTemp.min.format($Temp,$NONE,add_label=False)
$day.outTemp.mintime.format($Time,add_label=False)
$day.heatdeg.sum.format($Temp,$NONE,add_label=False)
$day.cooldeg.sum.format($Temp,$NONE,add_label=False)
$day.rain.sum.format($Rain,$NONE,add_label=False)
$day.wind.avg.format($Wind,$NONE,add_label=False)
$day.wind.max.format($Wind,$NONE,add_label=False)
$day.wind.maxtime.format($Time,add_label=False)
$day.wind.vecdir.format($Dir,$NONE,add_label=False)
#else
$day.dateTime.format($D)
#end if
#end for

to

#for $day in $month.days
$day.dateTime.format($D, add_label=False)
$day.outTemp.avg.format($Temp,$NONE,add_label=False)
$day.outTemp.max.format($Temp,$NONE,add_label=False)
$day.outTemp.maxtime.format($Time,add_label=False)
$day.outTemp.min.format($Temp,$NONE,add_label=False)
$day.outTemp.mintime.format($Time,add_label=False)
$day.heatdeg.sum.format($Temp,$NONE,add_label=False)
$day.cooldeg.sum.format($Temp,$NONE,add_label=False)
$day.rain.sum.format($Rain,$NONE,add_label=False)
$day.wind.avg.format($Wind,$NONE,add_label=False)
$day.wind.max.format($Wind,$NONE,add_label=False)
$day.wind.maxtime.format($Time,add_label=False)
$day.wind.vecdir.format($Dir,$NONE,add_label=False)
#end for

This will print something for every line.

-tk

On Mon, Jun 22, 2020 at 4:42 PM John Pierce  wrote:

>
>
> On Mon, Jun 22, 2020 at 4:51 AM Tom Keffer  wrote:
>
>> This is a known problem with v4.1.0. An upgrade to V4.1.1 will fix you up.
>>
>> After the upgrade, delete all your NOAA files and let WeeWX
>> regenerate them.
>>
>
> so I was already on 4.1.1...
>
>
> well, I stopped weewx, deleted /var/weewx/reports/NOAA/*.txt, and
> restarted weewx, and still no-go on those summaries...  The current month
> is partially populated as expected, but all previous months are empty.
>
> https://freescruz.com/weewx/tabular.html?report=NOAA/NOAA-2020-05.txt
> as an example of said previous month.
>
> ditto current year is partially populated, but the prior years since i
> started running weewx are empty.
>
>
>
>
>
>
> --
> -john r pierce
>   recycling used bits in santa cruz
>
> --
> 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/CAJnkzX%2B%2BA_Q%2BOy%2BOMfJhMROiPmoy4LWDDRWup6VS80LmeHJ3WQ%40mail.gmail.com
> 
> .
>

-- 
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/CAPq0zEAL8PvyuB9-AQK6rGUM4LiknYhLcL872Ybrch4_EpJ3DQ%40mail.gmail.com.

Re: [weewx-user] Send captured data to Weewx

[Greg Troxel]

DrBytes  writes:

> Hi
>
> Two weeks back I did this : 
> https://www.reddit.com/r/homeassistant/comments/h7vnrb/weather_station_and_weather_underground_work/
> TIL: I trap the data my Bresser Pro 5-in-1 Weatherstation sends to Weatyher 
> Underground at the router and redirect it to my Homeassistant server that 
> then parses the results and throws it onto MQTT.

There are two parts to weather processing: getting the data out of the
station, and storing it / making display pages / sending it to various
places.  weewx does both halves.   If you are doing the "get data" half
otherwise, that's fine, but you may want to replumb that into weewx.

> Anyways, in the thread Weewx was suggested, as it can trap the data using a 
> SDR Dongle and so it would be an alternative to what I'm doing. I don't 
> really need another dongle but the idea of having weewx running was 
> intriguing so I installed it so it can send the data I capture to the 
> openweathermap and such.
>
> So is there a way I can pipe my data into Weewx? I've now set up a software 
> weather station, I have the data I capture in MQTT and also in Mysql/mariadb
> If someone can point me in the right direction, that'd be great.

* option 1 is replumb to have the interception into weewx.

Probably this is the right approach; I'm not sure the existing code
deals with your station but I would expect there is support someplace.
See https://github.com/matthewwall/weewx-interceptor

Once you do, you can publish to mqtt from weewx.
See https://github.com/weewx/weewx/wiki/mqtt

* option 2 is to have weewx ingest the data you are already capturing
  from mqtt.

See https://github.com/bellrichm/WeeWX-MQTTSubscribe

This is the easy path for you, given where you are now.

-- 
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/rmi5zbivvat.fsf%40s1.lexort.com.

[weewx-user] Send captured data to Weewx

[DrBytes]

Hi

Two weeks back I did this : 
https://www.reddit.com/r/homeassistant/comments/h7vnrb/weather_station_and_weather_underground_work/
TIL: I trap the data my Bresser Pro 5-in-1 Weatherstation sends to Weatyher 
Underground at the router and redirect it to my Homeassistant server that 
then parses the results and throws it onto MQTT.

Anyways, in the thread Weewx was suggested, as it can trap the data using a 
SDR Dongle and so it would be an alternative to what I'm doing. I don't 
really need another dongle but the idea of having weewx running was 
intriguing so I installed it so it can send the data I capture to the 
openweathermap and such.

So is there a way I can pipe my data into Weewx? I've now set up a software 
weather station, I have the data I capture in MQTT and also in Mysql/mariadb
If someone can point me in the right direction, that'd be great.


Regards

-- 
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/14292666-9d02-4354-86ea-2a33ec4a9d90o%40googlegroups.com.

Re: [weewx-user] Re: Full day highcharts question

[Didier Decoodt]

I have:
aggregate_interval = 86400 # 1 day
gapsize = 8640 # 1 day in milliseconds
but if aggregate_type=none, then I have a dot each 5 mn (may be it's normal)

Le mar. 23 juin 2020 à 02:00, Pat  a écrit :

> Change your aggregate_interval to match your gapSize and see if that
> helps.
>
> On Monday, June 22, 2020 at 7:05:00 PM UTC-4, Didier Decoodt wrote:
>>
>> Oupss
>> It seems to be correct but the aggregate_interval is not correct, every 5
>> mn instead of 1 day for monthly graphic...
>> aggregate_type=none is not appropriate...
>> (with  aggregate_type=last the curve continue after "now")
>> I think the problem is linked with rainTotal variable,
>>
>> Le lun. 22 juin 2020 à 22:18, Didier Decoodt  a
>> écrit :
>>
>>> Thanks for this documentation
>>>
>>> Le lun. 22 juin 2020 à 21:10, Pat  a écrit :
>>>
 rain total works? That's good though I don't know how! :)

 For the aggregates, Belchertown borrows that from weewx's Seasons and
 Standard skins. Here's more information from their documentation
 .

 On Monday, June 22, 2020 at 2:47:40 PM UTC-4, Didier Decoodt wrote:
>
> Pat, I put aggregate_type = none instead of max, and it's work!!!
> I don't really understand aggregate_type effect
> differences between none, sum, min, max and avg?
> [image: image.png]
>
> Le lun. 22 juin 2020 à 19:40, Pat  a écrit :
>
 I raised this as an issue and
>> Tom mentioned for the day charts you should probably be using last as the
>> aggregate, not max.
>>
>> I'll look into rainTotal since that's a Belchertown observation.
>>
>>
>> On Friday, June 19, 2020 at 2:02:44 PM UTC-4, Pat wrote:
>>>
>>> No, not sure. I assume it's because the data points aren't reset to
>>> "None" using this new way of getting data for the rain observation?
>>>
>>> Gary - did you create an issue for this? I'd hate to patch something
>>> in the skin to only undo it if/when Tom properly patches this.
>>>
>>> On Friday, June 19, 2020 at 1:06:11 PM UTC-4, didier@gmail.com
>>> wrote:

 Oh, just a small problem:
 For Rain graph, the curve continue after "now"! (screenshot
 attached)
 All others curves stop at datetime=now, it's correct)
 The problem concern "rainTotal" and is also available for day,
 week, month and year time_length
 Have you an idea?

 hereafter the part of grah.conf

 [week]
 # Chart Timespan Defaults
 title = "Cette semaine"
 show_button = true
 button_text = "SEMAINE"
 time_length = week
 tooltip_date_format = ""
 type = spline
 aggregate_type = max
 aggregate_interval = 3600 # 1 hour
 gapsize = 360 # 1 hour in milliseconds

 [[chart1]]
 title = Température
 [[[outTemp]]]
 color = "#b2df8a"
 [[[dewpoint]]]
 yAxis_label = ( °C )
 yAxis_tickInterval = 2
 yAxis_softMin = 0

 [[chart2]]
 title = Pluie
 [[[rainTotal]]]  <
 Problem
 color = "#f7a35c"
 name = Cumul
 [[[rain]]]
 color = "#268bd2"
 aggregate_type = sum
 name = pluie
 type = column
 yAxis_tickInterval = 1
 yAxis_label = ( mm )
 yAxis_min = 0


 Le lundi 15 juin 2020 à 14:58:26 UTC+2, Pat a écrit :

> Awesome! Glad that it worked for you
>
>
> On Monday, June 15, 2020 at 5:29:59 AM UTC-4, didier@gmail.com
> wrote:
>>
>> Thanks it's work 
>>
>>
>> Le lundi 15 juin 2020 à 11:12:27 UTC+2, Manfred Maier a écrit :
>>
>>> Thanks, Gary, for this comprehensive explanation.
>>>
>>> Based on what you wrote I was now able to plot an entire day.
>>>
>>> [image: Bildschirmfoto 2020-06-15 um 11.07.53.png]
>>>
>>> The trick is quite simple: I just had to define an aggregation
>>> for the daily charts. I.e. adding the following two lines to the
>>> graphs.conf:
>>>
>>> aggregate_type = max
>>>
>>> aggregate_interval = 300
>>>
>>>
>>>
>>> --
>> 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...@googlegroups.com.
>> To view