[weewx-user] Weewx not starting up

[Neil Vass]

sorry noob here!

I have a fresh Raspberry Pi4b with a fresh install of Full Buster. The only 
additions being xrdp and tightvncserver for headless operation along with 
rtl_sdr driver. I have a RTL2832 USB dongle and have used it to confirm 
receiving data from my Misol WH2950 weather station successfully.

However, when I install Weewx it fails to start with the following errors. 

Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine:   self.console = loader_function(config_dict, 
self)
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine: File "/usr/share/weewx/weewx/drivers/fousb.py", 
line 233, in loader
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine:   return FineOffsetUSB(**config_dict[DRIVER_NAME])
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine: File "/usr/share/weewx/weewx/drivers/fousb.py", 
line 968, in __init__
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine:   self.openPort()
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine: File "/usr/share/weewx/weewx/drivers/fousb.py", 
line 1023, in openPort
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine:   raise weewx.WeeWxIOError("Unable to find USB 
device")
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
weewx.engine:   weewx.WeeWxIOError: Unable to find USB device
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL __main__: Unable to load 
driver: Unable to find USB device
Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL 
__main__:   Exiting...

I have spend a whole day searching for info on it so far and have no idea 
why its not starting although it looks to me as if its not finding the USB 
dongle for some reason.

Please can someone point me in the right direction!

Thanks

-- 
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/f4e32798-ba7d-4558-b9b7-96dea1aede26n%40googlegroups.com.

[weewx-user] Missing archive data / wee_device --dump

[Richard G]

I have had a Davis Vantage Pro2 and weewx running on a Pi for several years 
now. I had some issues last year and have a few weeks of data which I can 
browse on the Davis console but are not in the weewx database. I had 
assumed that running

wee_device --dump

Would go through all the archive records stored in the Davis console and 
then dump them into weewx but that doesn't appear to work. I was expecting 
loads of duplicate key entries but I get none and it only seems to go back 
1 month and says added 2560 records. If I run the command again then it 
does exactly the same thing and says added 2560 records.

Firstly I wasn't expecting any recent records to be added as they are unto 
date.
Secondly I would have though the first run would have imported the data and 
the 2nd run would have resulted in duplicates but it doesn't.
Is there any other way of importing the missing data?

Any help appreciated.

-- 
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/018a6252-40f1-4a9d-804b-faa7308fb5edn%40googlegroups.com.

[weewx-user] Weewx Responsive Skin - Aus Forecast Extension

[Darryn Capes-Davis]

Hi All,

Long time since my last post. A few months ago I noticed that my iPhone 
stopped showing the BOM Forecast icons. With the change to everything 
needing to be HTTPS, the BOM HTTP only icons will only continue to 
disappear if you host the Responsive skin on HTTPS, like I do at 
https://carlingfordweather.sydney, and you use a modern strict browser. 

So I took time to source some weather icons and adjust and size to suit the 
Aus Forecast part of the Responsive skin. The changes have been push to 
GitHub - https://github.com/dcapslock/weewx-responsive-skin

Also included is some exception handling to mark corrupt downloaded 
forecast files as stale.

Regards

Darryn Capes-Davis
https://carlingfordweather.sydney 

-- 
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/055fa5a4-2aaf-4783-ad5f-c805d2ec7715n%40googlegroups.com.

[weewx-user] Re: Missing archive data / wee_device --dump

[gjr80]

What does the log say? It will tell you what was/was not written to 
database during the wee_device —dump runs. I can’t recall the exact console 
output from wee_device —dump, but wee_device just causes the archive 
records to be downloaded from the logger, it doesn’t actually know whether 
they are saved to database or not. I would take the reported figure from 
wee_device as the number of records downloaded. The log will tell you 
exactly how many were actually saved to database.

The only ways I am aware of to obtain records from the logger are:

1.  normal WeeWX operation (using hardware record generation)
2. automatic download of new records during WeeWX startup (only records 
newer than the most recent database record are downloaded)
3. wee_device —dump

Gary
On Saturday, 6 February 2021 at 19:27:23 UTC+10 Richard G wrote:

> I have had a Davis Vantage Pro2 and weewx running on a Pi for several 
> years now. I had some issues last year and have a few weeks of data which I 
> can browse on the Davis console but are not in the weewx database. I had 
> assumed that running
>
> wee_device --dump
>
> Would go through all the archive records stored in the Davis console and 
> then dump them into weewx but that doesn't appear to work. I was expecting 
> loads of duplicate key entries but I get none and it only seems to go back 
> 1 month and says added 2560 records. If I run the command again then it 
> does exactly the same thing and says added 2560 records.
>
> Firstly I wasn't expecting any recent records to be added as they are unto 
> date.
> Secondly I would have though the first run would have imported the data 
> and the 2nd run would have resulted in duplicates but it doesn't.
> Is there any other way of importing the missing data?
>
> Any help appreciated.
>
>

-- 
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/d5d4d89c-b790-4f94-8e21-511fa5ff3b27n%40googlegroups.com.

[weewx-user] Re: Missing archive data / wee_device --dump

[Richard G]

Thanks for the prompt response. Nothing was in the log which confused me 
but then I realised my syslog filter didn't redirect the output from 
wee_device

Yes the log file says no data added due to unique constraint failed as 
expected. However, it only goes back until the 2021-01-28 whereas the 
console has 10 years of data stored. I'm wondering whether the older 
archive data stored in the console is only summary or aggregated data so 
can't be used by weewx?

Richard





On Saturday, 6 February 2021 at 09:55:36 UTC gjr80 wrote:

> What does the log say? It will tell you what was/was not written to 
> database during the wee_device —dump runs. I can’t recall the exact console 
> output from wee_device —dump, but wee_device just causes the archive 
> records to be downloaded from the logger, it doesn’t actually know whether 
> they are saved to database or not. I would take the reported figure from 
> wee_device as the number of records downloaded. The log will tell you 
> exactly how many were actually saved to database.
>
> The only ways I am aware of to obtain records from the logger are:
>
> 1.  normal WeeWX operation (using hardware record generation)
> 2. automatic download of new records during WeeWX startup (only records 
> newer than the most recent database record are downloaded)
> 3. wee_device —dump
>
> Gary
> On Saturday, 6 February 2021 at 19:27:23 UTC+10 Richard G wrote:
>
>> I have had a Davis Vantage Pro2 and weewx running on a Pi for several 
>> years now. I had some issues last year and have a few weeks of data which I 
>> can browse on the Davis console but are not in the weewx database. I had 
>> assumed that running
>>
>> wee_device --dump
>>
>> Would go through all the archive records stored in the Davis console and 
>> then dump them into weewx but that doesn't appear to work. I was expecting 
>> loads of duplicate key entries but I get none and it only seems to go back 
>> 1 month and says added 2560 records. If I run the command again then it 
>> does exactly the same thing and says added 2560 records.
>>
>> Firstly I wasn't expecting any recent records to be added as they are 
>> unto date.
>> Secondly I would have though the first run would have imported the data 
>> and the 2nd run would have resulted in duplicates but it doesn't.
>> Is there any other way of importing the missing data?
>>
>> Any help appreciated.
>>
>>

-- 
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/d0762aef-0eb3-4e98-8d68-8bcb9a3ab0e7n%40googlegroups.com.

[weewx-user] Re: Missing archive data / wee_device --dump

[gjr80]

If you have a genuine Davis logger it can only store 2560 records, how long 
that goes back in time depends on the archive interval used by the console. 
If using a 2 hour interval (the maximum) you get 213 days in the logger, if 
using the common five minute archive interval you get about 8 days which 
sort of ties in with the 28 January date you saw.

Gary

On Saturday, 6 February 2021 at 20:19:01 UTC+10 Richard G wrote:

> Thanks for the prompt response. Nothing was in the log which confused me 
> but then I realised my syslog filter didn't redirect the output from 
> wee_device
>
> Yes the log file says no data added due to unique constraint failed as 
> expected. However, it only goes back until the 2021-01-28 whereas the 
> console has 10 years of data stored. I'm wondering whether the older 
> archive data stored in the console is only summary or aggregated data so 
> can't be used by weewx?
>
> Richard
>
>
>
>
>
> On Saturday, 6 February 2021 at 09:55:36 UTC gjr80 wrote:
>
>> What does the log say? It will tell you what was/was not written to 
>> database during the wee_device —dump runs. I can’t recall the exact console 
>> output from wee_device —dump, but wee_device just causes the archive 
>> records to be downloaded from the logger, it doesn’t actually know whether 
>> they are saved to database or not. I would take the reported figure from 
>> wee_device as the number of records downloaded. The log will tell you 
>> exactly how many were actually saved to database.
>>
>> The only ways I am aware of to obtain records from the logger are:
>>
>> 1.  normal WeeWX operation (using hardware record generation)
>> 2. automatic download of new records during WeeWX startup (only records 
>> newer than the most recent database record are downloaded)
>> 3. wee_device —dump
>>
>> Gary
>> On Saturday, 6 February 2021 at 19:27:23 UTC+10 Richard G wrote:
>>
>>> I have had a Davis Vantage Pro2 and weewx running on a Pi for several 
>>> years now. I had some issues last year and have a few weeks of data which I 
>>> can browse on the Davis console but are not in the weewx database. I had 
>>> assumed that running
>>>
>>> wee_device --dump
>>>
>>> Would go through all the archive records stored in the Davis console and 
>>> then dump them into weewx but that doesn't appear to work. I was expecting 
>>> loads of duplicate key entries but I get none and it only seems to go back 
>>> 1 month and says added 2560 records. If I run the command again then it 
>>> does exactly the same thing and says added 2560 records.
>>>
>>> Firstly I wasn't expecting any recent records to be added as they are 
>>> unto date.
>>> Secondly I would have though the first run would have imported the data 
>>> and the 2nd run would have resulted in duplicates but it doesn't.
>>> Is there any other way of importing the missing data?
>>>
>>> Any help appreciated.
>>>
>>>

-- 
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/e6022142-f80b-46dc-ab1c-504121603564n%40googlegroups.com.

[weewx-user] Re: Weewx Responsive Skin - Aus Forecast Extension

[Greg from Oz]

Yes my icons disappeared as my site is https but I changed a setting on the 
browser just for my site.

On chrome it is called insecure content. 

Then the icons came back again.



On Saturday, 6 February 2021 at 20:41:16 UTC+11 Darryn Capes-Davis wrote:

> Hi All,
>
> Long time since my last post. A few months ago I noticed that my iPhone 
> stopped showing the BOM Forecast icons. With the change to everything 
> needing to be HTTPS, the BOM HTTP only icons will only continue to 
> disappear if you host the Responsive skin on HTTPS, like I do at 
> https://carlingfordweather.sydney, and you use a modern strict browser. 
>
> So I took time to source some weather icons and adjust and size to suit 
> the Aus Forecast part of the Responsive skin. The changes have been push to 
> GitHub - https://github.com/dcapslock/weewx-responsive-skin
>
> Also included is some exception handling to mark corrupt downloaded 
> forecast files as stale.
>
> Regards
>
> Darryn Capes-Davis
> https://carlingfordweather.sydney 
>

-- 
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/54c74ea9-3819-4223-a112-d3a7c9cc37den%40googlegroups.com.

[weewx-user] Re: Missing archive data / wee_device --dump

[Richard G]

Gary,

Thank you that explains it. 

I was hoping to be able to get the Davis console monthly summaries out so 
at least these were correct on weewx and therefore the yearly summaries as 
well. I’m guessing the only way I could do that is manually work out the 
difference between the weewx monthly summary and the console summary and 
then insert a few dummy records into the database to make up the missing 
data?

Richard

On Saturday, 6 February 2021 at 10:45:30 UTC gjr80 wrote:

> If you have a genuine Davis logger it can only store 2560 records, how 
> long that goes back in time depends on the archive interval used by the 
> console. If using a 2 hour interval (the maximum) you get 213 days in the 
> logger, if using the common five minute archive interval you get about 8 
> days which sort of ties in with the 28 January date you saw.
>
> Gary
>
> On Saturday, 6 February 2021 at 20:19:01 UTC+10 Richard G wrote:
>
>> Thanks for the prompt response. Nothing was in the log which confused me 
>> but then I realised my syslog filter didn't redirect the output from 
>> wee_device
>>
>> Yes the log file says no data added due to unique constraint failed as 
>> expected. However, it only goes back until the 2021-01-28 whereas the 
>> console has 10 years of data stored. I'm wondering whether the older 
>> archive data stored in the console is only summary or aggregated data so 
>> can't be used by weewx?
>>
>> Richard
>>
>>
>>
>>
>>
>> On Saturday, 6 February 2021 at 09:55:36 UTC gjr80 wrote:
>>
>>> What does the log say? It will tell you what was/was not written to 
>>> database during the wee_device —dump runs. I can’t recall the exact console 
>>> output from wee_device —dump, but wee_device just causes the archive 
>>> records to be downloaded from the logger, it doesn’t actually know whether 
>>> they are saved to database or not. I would take the reported figure from 
>>> wee_device as the number of records downloaded. The log will tell you 
>>> exactly how many were actually saved to database.
>>>
>>> The only ways I am aware of to obtain records from the logger are:
>>>
>>> 1.  normal WeeWX operation (using hardware record generation)
>>> 2. automatic download of new records during WeeWX startup (only records 
>>> newer than the most recent database record are downloaded)
>>> 3. wee_device —dump
>>>
>>> Gary
>>> On Saturday, 6 February 2021 at 19:27:23 UTC+10 Richard G wrote:
>>>
 I have had a Davis Vantage Pro2 and weewx running on a Pi for several 
 years now. I had some issues last year and have a few weeks of data which 
 I 
 can browse on the Davis console but are not in the weewx database. I had 
 assumed that running

 wee_device --dump

 Would go through all the archive records stored in the Davis console 
 and then dump them into weewx but that doesn't appear to work. I was 
 expecting loads of duplicate key entries but I get none and it only seems 
 to go back 1 month and says added 2560 records. If I run the command again 
 then it does exactly the same thing and says added 2560 records.

 Firstly I wasn't expecting any recent records to be added as they are 
 unto date.
 Secondly I would have though the first run would have imported the data 
 and the 2nd run would have resulted in duplicates but it doesn't.
 Is there any other way of importing the missing data?

 Any help appreciated.



-- 
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/53890bd0-67f7-423f-a884-668df61378c7n%40googlegroups.com.

Re: [weewx-user] Weewx not starting up

[Tom Keffer]

It appears that you are using the Fine Offset (fousb) driver, not the sdr
driver. Try switching drivers.

On Sat, Feb 6, 2021 at 12:00 AM Neil Vass  wrote:

> sorry noob here!
>
> I have a fresh Raspberry Pi4b with a fresh install of Full Buster. The
> only additions being xrdp and tightvncserver for headless operation along
> with rtl_sdr driver. I have a RTL2832 USB dongle and have used it to
> confirm receiving data from my Misol WH2950 weather station successfully.
>
> However, when I install Weewx it fails to start with the following errors.
>
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine:   self.console = loader_function(config_dict,
> self)
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine: File "/usr/share/weewx/weewx/drivers/fousb.py",
> line 233, in loader
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine:   return FineOffsetUSB(**config_dict[DRIVER_NAME])
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine: File "/usr/share/weewx/weewx/drivers/fousb.py",
> line 968, in __init__
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine:   self.openPort()
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine: File "/usr/share/weewx/weewx/drivers/fousb.py",
> line 1023, in openPort
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine:   raise weewx.WeeWxIOError("Unable to find USB
> device")
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> weewx.engine:   weewx.WeeWxIOError: Unable to find USB device
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL __main__: Unable to load
> driver: Unable to find USB device
> Feb  6 13:46:08 raspberrypi weewx[1910] CRITICAL
> __main__:   Exiting...
>
> I have spend a whole day searching for info on it so far and have no idea
> why its not starting although it looks to me as if its not finding the USB
> dongle for some reason.
>
> Please can someone point me in the right direction!
>
> Thanks
>
> --
> 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/f4e32798-ba7d-4558-b9b7-96dea1aede26n%40googlegroups.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/CAPq0zEBF%2B3UN84Hc87O3Nv4QPb8BybFqTw_ziM3PMyrXirGaoQ%40mail.gmail.com.

[weewx-user] Belchertown Skin install updates since last release

[Michael Sanphillipo]

I'm  using Belchertown version 1.2.  How do you install the latest commits 
since the last version release? Do you simply download the zip file from 
github and paste into the directories or is the an install method for 
python3?

-- 
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/994aea23-acd4-4ac9-a236-8106f8649e0an%40googlegroups.com.

Re: [weewx-user] Re: Graph not update

[ginfo...@gmail.com]

No way:
I added the timestamp to the images but it doesn't work!

  


Il giorno sabato 6 febbraio 2021 alle 03:18:08 UTC+1 tomn...@frontier.com 
ha scritto:

> Not sure if this is related, but I've got a similar issue with pictures 
> getting posted on the web that "weren't updating."
> Turns out there's a trick to trick the cache into reloading the image 
> file, and it is essentially including an argument
> in the URL of a timestamp for the image.  That defeats the browsers 
> caching mechanism. It looks like this:
>  night 
>    /   day 
> Chris
>
> On Friday, February 5, 2021 at 6:06:20 AM UTC-7 ginfo...@gmail.com wrote:
>
>> I change the skin but nothing
>>
>> Il giorno venerdì 5 febbraio 2021 alle 09:01:26 UTC+1 gjr80 ha scritto:
>>
>>> OK, now I see the plots are sitting on 08:00 (it's 08:50) now and no 
>>> amount of refreshing will update them. In fact if I look at just one of 
>>> your image files directly (eg http://www.meteomestre.it/daywindvec.png) 
>>> it exhibits the same behaviour only stuck on the time I first viewed the 
>>> plot. This was in Firefox. If I look at your site in Chrome it is stuck on 
>>> the same 08:00 plots. Interestingly if I open the same plot file directly 
>>> that I did in Firefox I see the plot is timestamped 08:35. If I open a 
>>> different plot file directly I see the current time stamp (most recent 
>>> upload). No amount of cache clearing will fix it for me (in either Chrome 
>>> or Firefox).
>>>
>>> Clearly the files are being uploaded to your web server OK so that rules 
>>> out WeeWX. The fact that two browsers have the same issue tends to rule out 
>>> browser quirks. Which only leaves your HTML/scripts. Think you need a 
>>> HTMl/javascript/CSS expert, something in there will be doing it.
>>>
>>> Gary
>>>
>>> On Friday, 5 February 2021 at 17:00:35 UTC+10 ginfo...@gmail.com wrote:
>>>
 Obviously I'm talking about the graphs, if you look closely, those of 
 the day are still.
 They should update every 5 minutes ...

 Il giorno venerdì 5 febbraio 2021 alle 07:48:05 UTC+1 
 ginfo...@gmail.com ha scritto:

> If I delete the browser cache, it updates regularly, but then remains 
> blocked there
>
> Il giorno venerdì 5 febbraio 2021 alle 07:45:10 UTC+1 
> ginfo...@gmail.com ha scritto:
>
>> Yes, the station updates regularly and transmits data.
>> These are the graphics that are not transmitted and updated on the 
>> site.
>> I checked the local and remote folder, and the graphs are regularly 
>> updated.
>> It appears to be a cache problem.
>>
>> Il giorno venerdì 5 febbraio 2021 alle 07:35:50 UTC+1 
>> graha...@gmail.com ha scritto:
>>
>>> is this the correct target ftp location?
>>>
>>> On 5 Feb 2021, at 5:24 pm, ginfo...@gmail.com  
>>> wrote:
>>>
>>> Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
>>> Connected to it31.siteground.eu
>>> Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
>>> Uploaded file /home/weewx/public_html/favicon.ico to /public_html/
>>> www.meteomestre.it/favicon.ico
>>>
>>>
>>>

-- 
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/0978bc52-8c1a-4765-a5a2-1f63cac82364n%40googlegroups.com.

Re: [weewx-user] Two instances of RTL_433 ?

[Mark A]

Hi, 
I'd already tried that with very mixed results, with further analysis, 
sensor only seems to transmit when there is delta, so very diffcult to 
capture with frequncy hopping.

Anyhow, what I did - I moved away from the SDR driver. and moved the whole 
show to MQTT as rtl_433 can feed an MQ queue.  
I can now feed that with two instances of RTL.. or more if I want if I find 
other usfull sensors that rtl_433 can decode. 

Hope this helps someone. 

73
On Sunday, 31 January 2021 at 18:16:58 UTC weatherl...@gmail.com wrote:

> For me, using a couple of 433 sensors and one 915, this command works in 
> the SDR config:
>
> [SDR]
> # This section is for the software-defined radio driver.
> 
> # The driver to use
> driver = user.sdr
> # cmd = rtl_433 -M utc -M level -F json # For only 433 sensors
> cmd = rtl_433 -f 433.920M -f 915M -H 30 -M utc -M level -F json # For 
> 433 and 915 sensors
> path = /usr/local/bin/
> log_unknown_sensors = False
> log_unmapped_sensors = False
>
> On 31 Jan, 2021, at 11:36, Mark A  wrote:
>
> G'day. 
>
> I recently purchased a Bresser7in1, (a badged CEL W100 ) and got that 
> working nicely with WeeWx via and RTL-SDR with some fiddling. 
> However, the pressure is not derived at the main sensor, it's done at the 
> console, and at the moment, it's not known if you can interogate the 
> console. 
>
> *(Port 5000 is open, but ... needs someone with greater knowledge than 
> 'thou to investigate.)*
>
> anyhow, in the mean time I have a WH25 kicking about which provides hPa. 
>
> I tried to use RTL_433 hopping between the two QRGs but, that didn't work 
> out so well. 
> The 7in1 trasmits every 12 seconds up on 868, the WH25, on 433 every 70 it 
> seems, plus 433 is quite busy with other sensors. 
>
> The question is, how do get I another  instances of RTL_433 working so 
> that 'loop' sees the json from both proesss?
>
> in weex.conf,  two "cmd"  and it bitches about duplicaate, I tried two 
> sections [SDR0] and [SDR1], but again, no cigar...
>
> Thougths ?
>
>
> btw weewx on ubuntu16.04 via apt install , virtualised on proxmox with USB 
> pass throug,  Skill level, not a coder. but hack a bit of very very simple 
> php and bash at a push.
> python is voodoo so please be gentle.
>
>
> Mark.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/90d534c3-4d0c-4e3c-a8e4-9998ae386c5bn%40googlegroups.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/a4240964-3f21-4f41-b30f-40e95fdedfb5n%40googlegroups.com.

Re: [weewx-user] Re: Graph not update

[John Kline]

Hardcoding a timestamp makes it not a timestamp and will accomplish nothing.

Try this:

#import time
#set $cachebuster = time.time

  


> On Feb 6, 2021, at 6:22 AM, ginfo...@gmail.com  wrote:
> 
> 
> No way:
> I added the timestamp to the images but it doesn't work!
> 
>   "daytempdew.png? v = 1612619365" alt = "$ Extras.Translation.temperatures"> 
> 
> 
> Il giorno sabato 6 febbraio 2021 alle 03:18:08 UTC+1 tomn...@frontier.com ha 
> scritto:
>> Not sure if this is related, but I've got a similar issue with pictures 
>> getting posted on the web that "weren't updating."
>> Turns out there's a trick to trick the cache into reloading the image file, 
>> and it is essentially including an argument
>> in the URL of a timestamp for the image.  That defeats the browsers caching 
>> mechanism. It looks like this:
>> > href="myshake/gifs/RD066_EHZ_AM_00.2019100200.gif?v=1570017689"> night 
>>    /  > href="myshake/gifs/RD066_EHZ_AM_00.2019100212.gif?v=1570060855"> day 
>> 
>> Chris
>> 
>>> On Friday, February 5, 2021 at 6:06:20 AM UTC-7 ginfo...@gmail.com wrote:
>>> I change the skin but nothing
>>> 
>>> Il giorno venerdì 5 febbraio 2021 alle 09:01:26 UTC+1 gjr80 ha scritto:
 OK, now I see the plots are sitting on 08:00 (it's 08:50) now and no 
 amount of refreshing will update them. In fact if I look at just one of 
 your image files directly (eg http://www.meteomestre.it/daywindvec.png) it 
 exhibits the same behaviour only stuck on the time I first viewed the 
 plot. This was in Firefox. If I look at your site in Chrome it is stuck on 
 the same 08:00 plots. Interestingly if I open the same plot file directly 
 that I did in Firefox I see the plot is timestamped 08:35. If I open a 
 different plot file directly I see the current time stamp (most recent 
 upload). No amount of cache clearing will fix it for me (in either Chrome 
 or Firefox).
 
 Clearly the files are being uploaded to your web server OK so that rules 
 out WeeWX. The fact that two browsers have the same issue tends to rule 
 out browser quirks. Which only leaves your HTML/scripts. Think you need a 
 HTMl/javascript/CSS expert, something in there will be doing it.
 
 Gary
 
> On Friday, 5 February 2021 at 17:00:35 UTC+10 ginfo...@gmail.com wrote:
> Obviously I'm talking about the graphs, if you look closely, those of the 
> day are still.
> They should update every 5 minutes ...
> 
> Il giorno venerdì 5 febbraio 2021 alle 07:48:05 UTC+1 ginfo...@gmail.com 
> ha scritto:
>> If I delete the browser cache, it updates regularly, but then remains 
>> blocked there
>> 
>> Il giorno venerdì 5 febbraio 2021 alle 07:45:10 UTC+1 ginfo...@gmail.com 
>> ha scritto:
>>> Yes, the station updates regularly and transmits data.
>>> These are the graphics that are not transmitted and updated on the site.
>>> I checked the local and remote folder, and the graphs are regularly 
>>> updated.
>>> It appears to be a cache problem.
>>> 
>>> Il giorno venerdì 5 febbraio 2021 alle 07:35:50 UTC+1 
>>> graha...@gmail.com ha scritto:
 is this the correct target ftp location?
 
> On 5 Feb 2021, at 5:24 pm, ginfo...@gmail.com  
> wrote:
> 
> Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
> Connected to it31.siteground.eu
> Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
> Uploaded file /home/weewx/public_html/favicon.ico to 
> /public_html/www.meteomestre.it/favicon.ico
> 
 
> 
> -- 
> 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/0978bc52-8c1a-4765-a5a2-1f63cac82364n%40googlegroups.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/9968DD29-C95C-4483-B848-45953E684F29%40johnkline.com.

[weewx-user] I am trying to install wewx on Raspberry PI and fail at (almost) the first hurdle. Following the instructions I get as far as the " wget - qo - http://weewx.com/keys.html | sudo apt-key a

[Allan Robinson]

Any suggestions?

-- 
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/144b41b2-6364-42f5-90ec-9f3688c10b2bn%40googlegroups.com.

[weewx-user] Re: MQTTSubscribe and topics, that are seldom sent

[Karen K]

I saved the requested data to the issue on github.

bell...@gmail.com schrieb am Freitag, 5. Februar 2021 um 16:04:55 UTC+1:

> And your MQTTSubscribe config settings, with any sensitive information 
> removed.
>
> On Friday, 5 February 2021 at 10:02:20 UTC-5 bell...@gmail.com wrote:
>
>> Interesting.  I might have to give you a version with extra logging.  In 
>> the meantime, could you attach the log.
>> Thanks. -rich
>>
>> On Friday, 5 February 2021 at 09:25:20 UTC-5 kk44...@gmail.com wrote:
>>
>>> There is an issue I observed:
>>>
>>> If the MQTT message is received some little seconds after the archive 
>>> interval ends, then the loop record shows the new received value, but the 
>>> archive record shows the old value from the previous interval.
>>>
>>> example: archive interval ends at 15:00:00. MQTT message is received at 
>>> 15:00:10. loop record is sent at 15:00:14. archive record is sent at 
>>> 15:00:18 (with dateTime set to 15:00:00).
>>>
>>> vince schrieb am Donnerstag, 4. Februar 2021 um 21:34:36 UTC+1:
>>>
 On Thursday, February 4, 2021 at 11:50:29 AM UTC-8 kk44...@gmail.com 
 wrote:

> As I did not really know how to update an extension,
>

 Just install the new one.
  

>>>

-- 
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/82bf9af6-b136-4c36-8c85-f93f3dcf94e1n%40googlegroups.com.

Re: [weewx-user] Belchertown Skin install updates since last release

[salinois]

hello

you can use the *.zip

Patrick

Le 06/02/2021 à 15:04, Michael Sanphillipo a écrit :
I'm  using Belchertown version 1.2.  How do you install the latest 
commits since the last version release? Do you simply download the zip 
file from github and paste into the directories or is the an install 
method for python3? --
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/994aea23-acd4-4ac9-a236-8106f8649e0an%40googlegroups.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/b73d04a5-2948-3d15-1f5e-aa7c5b285ac3%40gmail.com.

Re: [weewx-user] Belchertown Skin install updates since last release

[Michael Sanphillipo]

Do I just paste into the different directories or is there an install
method?

On Sat, Feb 6, 2021 at 11:21 AM salinois  wrote:

> hello
>
> you can use the *.zip
>
> Patrick
> Le 06/02/2021 à 15:04, Michael Sanphillipo a écrit :
>
> I'm  using Belchertown version 1.2.  How do you install the latest commits
> since the last version release? Do you simply download the zip file from
> github and paste into the directories or is the an install method for
> python3? --
> 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/994aea23-acd4-4ac9-a236-8106f8649e0an%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/fWo_YSdhmzs/unsubscribe.
> To unsubscribe from this group and all its topics, 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/b73d04a5-2948-3d15-1f5e-aa7c5b285ac3%40gmail.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/CAAsGudq3KdOjxjXbfB%2BvLk5Va7Fu_4b9uextQ-zSc497NrgGuA%40mail.gmail.com.

[weewx-user] Re: I am trying to install wewx on Raspberry PI and fail at (almost) the first hurdle. Following the instructions I get as far as the " wget - qo - http://weewx.com/keys.html | sudo apt-k

[Paul Eaton]

Hi
I think you need an upper case letter O not a lower case o after the q
And it should be -qO no space after the dash and you need a dash at the end.
Best bet is to copy and paste the entry directly from the WeeWX 
installation instructions.
wget -qO - https://weewx.com/keys.html | sudo apt-key add -

Paul

On Saturday, 6 February 2021 at 15:43:40 UTC allanro...@gmail.com wrote:

>
> Any suggestions?
>
>

-- 
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/5fb12bb0-d893-42d4-ae05-788e5af03d91n%40googlegroups.com.

Re: [weewx-user] Belchertown Skin install updates since last release

[salinois]

My install for me

|sudo /usr/local/weewx(or your path)/wee_extension --install /home/pi(or 
your path)/weewx-belchertown-x.x.zip patrick |


Le 06/02/2021 à 17:26, Michael Sanphillipo a écrit :
Do I just paste into the different directories or is there an install 
method?


On Sat, Feb 6, 2021 at 11:21 AM salinois > wrote:


hello

you can use the *.zip

Patrick

Le 06/02/2021 à 15:04, Michael Sanphillipo a écrit :

I'm  using Belchertown version 1.2.  How do you install the
latest commits since the last version release? Do you simply
download the zip file from github and paste into the directories
or is the an install method for python3? --
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/994aea23-acd4-4ac9-a236-8106f8649e0an%40googlegroups.com

.
-- 
You received this message because you are subscribed to a topic in

the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/weewx-user/fWo_YSdhmzs/unsubscribe
.
To unsubscribe from this group and all its topics, 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/b73d04a5-2948-3d15-1f5e-aa7c5b285ac3%40gmail.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/CAAsGudq3KdOjxjXbfB%2BvLk5Va7Fu_4b9uextQ-zSc497NrgGuA%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/13d3b9b1-f8a0-f802-e48e-d2d108c38be4%40gmail.com.

Re: [weewx-user] Re: Graph not update

[ginfo...@gmail.com]

It works !!!

You are a genius, thank you !!

I finally solved the problem of updating the charts for good.

But the code:

*#import time*

*#set $ cachebuster = time.time*


do I always have to repeat it on each pair of images?

Thanks again from the heart !!!
Il giorno sabato 6 febbraio 2021 alle 15:50:14 UTC+1 jo...@johnkline.com ha 
scritto:

> Hardcoding a timestamp makes it not a timestamp and will accomplish 
> nothing.
>
> Try this:
>
> #import time
> #set $cachebuster = time.time
> 
> alt = "$Extras.Translation.temperatures">
> 
>
> On Feb 6, 2021, at 6:22 AM, ginfo...@gmail.com  wrote:
>
> 
>
> No way:
> I added the timestamp to the images but it doesn't work!
>
>   "daytempdew.png? v = 1612619365" alt = "$ Extras.Translation.temperatures"> 
> 
>
> Il giorno sabato 6 febbraio 2021 alle 03:18:08 UTC+1 tomn...@frontier.com 
> ha scritto:
>
>> Not sure if this is related, but I've got a similar issue with pictures 
>> getting posted on the web that "weren't updating."
>> Turns out there's a trick to trick the cache into reloading the image 
>> file, and it is essentially including an argument
>> in the URL of a timestamp for the image.  That defeats the browsers 
>> caching mechanism. It looks like this:
>>  night 
>>    /   day 
>> Chris
>>
>> On Friday, February 5, 2021 at 6:06:20 AM UTC-7 ginfo...@gmail.com wrote:
>>
>>> I change the skin but nothing
>>>
>>> Il giorno venerdì 5 febbraio 2021 alle 09:01:26 UTC+1 gjr80 ha scritto:
>>>
 OK, now I see the plots are sitting on 08:00 (it's 08:50) now and no 
 amount of refreshing will update them. In fact if I look at just one of 
 your image files directly (eg http://www.meteomestre.it/daywindvec.png) 
 it exhibits the same behaviour only stuck on the time I first viewed the 
 plot. This was in Firefox. If I look at your site in Chrome it is stuck on 
 the same 08:00 plots. Interestingly if I open the same plot file directly 
 that I did in Firefox I see the plot is timestamped 08:35. If I open a 
 different plot file directly I see the current time stamp (most recent 
 upload). No amount of cache clearing will fix it for me (in either Chrome 
 or Firefox).

 Clearly the files are being uploaded to your web server OK so that 
 rules out WeeWX. The fact that two browsers have the same issue tends to 
 rule out browser quirks. Which only leaves your HTML/scripts. Think you 
 need a HTMl/javascript/CSS expert, something in there will be doing it.

 Gary

 On Friday, 5 February 2021 at 17:00:35 UTC+10 ginfo...@gmail.com wrote:

> Obviously I'm talking about the graphs, if you look closely, those of 
> the day are still.
> They should update every 5 minutes ...
>
> Il giorno venerdì 5 febbraio 2021 alle 07:48:05 UTC+1 
> ginfo...@gmail.com ha scritto:
>
>> If I delete the browser cache, it updates regularly, but then remains 
>> blocked there
>>
>> Il giorno venerdì 5 febbraio 2021 alle 07:45:10 UTC+1 
>> ginfo...@gmail.com ha scritto:
>>
>>> Yes, the station updates regularly and transmits data.
>>> These are the graphics that are not transmitted and updated on the 
>>> site.
>>> I checked the local and remote folder, and the graphs are regularly 
>>> updated.
>>> It appears to be a cache problem.
>>>
>>> Il giorno venerdì 5 febbraio 2021 alle 07:35:50 UTC+1 
>>> graha...@gmail.com ha scritto:
>>>
 is this the correct target ftp location?

 On 5 Feb 2021, at 5:24 pm, ginfo...@gmail.com  
 wrote:

 Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
 Connected to it31.siteground.eu
 Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
 Uploaded file /home/weewx/public_html/favicon.ico to /public_html/
 www.meteomestre.it/favicon.ico


 -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0978bc52-8c1a-4765-a5a2-1f63cac82364n%40googlegroups.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/666a2e6a-46fb-42f1-aa79-469d2d3923fen%40googlegroups.com.

[weewx-user] Re: I am trying to install wewx on Raspberry PI and fail at (almost) the first hurdle. Following the instructions I get as far as the " wget - qo - http://weewx.com/keys.html | sudo apt-k

[Allan Robinson]

Thank you very much Paul, that fixed it.


On Saturday, 6 February 2021 at 16:44:41 UTC Paul Eaton wrote:

> Hi
> I think you need an upper case letter O not a lower case o after the q
> And it should be -qO no space after the dash and you need a dash at the 
> end.
> Best bet is to copy and paste the entry directly from the WeeWX 
> installation instructions.
> wget -qO - https://weewx.com/keys.html | sudo apt-key add -
>
> Paul
>
> On Saturday, 6 February 2021 at 15:43:40 UTC allanro...@gmail.com wrote:
>
>>
>> Any suggestions?
>>
>>

-- 
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/adbbf71a-51f0-4e8e-890b-e51949393305n%40googlegroups.com.

[weewx-user] Re: Missing archive data / wee_device --dump

[gjr80]

Richard,

Not saying that can’t be done but the WeeWX database structure may make 
that challenging.

In broad terms, WeeWX has the archive table which stores archive records 
and then there are the daily summary tables, one daily summary table per 
observation stored in the archive table, that stores summary/limited 
aggregate data for each day for that observation. Aggregates based on 
multiples of one day (week, month, year etc) are obtained from the daily 
summary tables (aggregates that are not based on multiples of a whole day 
and plots are derived from the archive table).

Gary
On Saturday, 6 February 2021 at 21:57:51 UTC+10 Richard G wrote:

> Gary,
>
> Thank you that explains it. 
>
> I was hoping to be able to get the Davis console monthly summaries out so 
> at least these were correct on weewx and therefore the yearly summaries as 
> well. I’m guessing the only way I could do that is manually work out the 
> difference between the weewx monthly summary and the console summary and 
> then insert a few dummy records into the database to make up the missing 
> data?
>
> Richard
>
> On Saturday, 6 February 2021 at 10:45:30 UTC gjr80 wrote:
>
>> If you have a genuine Davis logger it can only store 2560 records, how 
>> long that goes back in time depends on the archive interval used by the 
>> console. If using a 2 hour interval (the maximum) you get 213 days in the 
>> logger, if using the common five minute archive interval you get about 8 
>> days which sort of ties in with the 28 January date you saw.
>>
>> Gary
>>
>> On Saturday, 6 February 2021 at 20:19:01 UTC+10 Richard G wrote:
>>
>>> Thanks for the prompt response. Nothing was in the log which confused me 
>>> but then I realised my syslog filter didn't redirect the output from 
>>> wee_device
>>>
>>> Yes the log file says no data added due to unique constraint failed as 
>>> expected. However, it only goes back until the 2021-01-28 whereas the 
>>> console has 10 years of data stored. I'm wondering whether the older 
>>> archive data stored in the console is only summary or aggregated data so 
>>> can't be used by weewx?
>>>
>>> Richard
>>>
>>>
>>>
>>>
>>>
>>> On Saturday, 6 February 2021 at 09:55:36 UTC gjr80 wrote:
>>>
 What does the log say? It will tell you what was/was not written to 
 database during the wee_device —dump runs. I can’t recall the exact 
 console 
 output from wee_device —dump, but wee_device just causes the archive 
 records to be downloaded from the logger, it doesn’t actually know whether 
 they are saved to database or not. I would take the reported figure from 
 wee_device as the number of records downloaded. The log will tell you 
 exactly how many were actually saved to database.

 The only ways I am aware of to obtain records from the logger are:

 1.  normal WeeWX operation (using hardware record generation)
 2. automatic download of new records during WeeWX startup (only records 
 newer than the most recent database record are downloaded)
 3. wee_device —dump

 Gary
 On Saturday, 6 February 2021 at 19:27:23 UTC+10 Richard G wrote:

> I have had a Davis Vantage Pro2 and weewx running on a Pi for several 
> years now. I had some issues last year and have a few weeks of data which 
> I 
> can browse on the Davis console but are not in the weewx database. I had 
> assumed that running
>
> wee_device --dump
>
> Would go through all the archive records stored in the Davis console 
> and then dump them into weewx but that doesn't appear to work. I was 
> expecting loads of duplicate key entries but I get none and it only seems 
> to go back 1 month and says added 2560 records. If I run the command 
> again 
> then it does exactly the same thing and says added 2560 records.
>
> Firstly I wasn't expecting any recent records to be added as they are 
> unto date.
> Secondly I would have though the first run would have imported the 
> data and the 2nd run would have resulted in duplicates but it doesn't.
> Is there any other way of importing the missing data?
>
> Any help appreciated.
>
>

-- 
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/57679d07-e8e2-495d-a4df-a9f253430c7fn%40googlegroups.com.

Re: [weewx-user] Belchertown Skin install updates since last release

[Michael Sanphillipo]

After I installed the latest commits I received this error.

Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine: Caught
unrecoverable exception in generator
'weewx.cheetahgenerator.CheetahGenerator'
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  'aqi'
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  Traceback (most recent call last):
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/user/belchertown.py", line 1487, in
get_extension_list
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  aqi = data["aqi"][0]["response"][0]["periods"][0]["aqi"]
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  KeyError: 'aqi'
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:

Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  During handling of the above exception, another exception occurred:
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:

Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  Traceback (most recent call last):
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/weewx/reportengine.py", line 196, in run
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  obj.start()
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/weewx/reportengine.py", line 281, in start
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  self.run()
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/weewx/cheetahgenerator.py", line 150, in run
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  ngen = self.generate(gen_dict[section_name], self.gen_ts)
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/weewx/cheetahgenerator.py", line 220, in
generate
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  ngen += self.generate(section[subsection], gen_ts)
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/weewx/cheetahgenerator.py", line 220, in
generate
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  ngen += self.generate(section[subsection], gen_ts)
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/weewx/cheetahgenerator.py", line 309, in
generate
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  default_binding)
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/weewx/cheetahgenerator.py", line 385, in
_getSearchList
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  searchList += obj.get_extension_list(timespan, db_lookup)
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
File "/usr/share/weewx/user/belchertown.py", line 1495, in
get_extension_list
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  "The URL being used is:\n%s" % (error, data["aqi"], aqi_url)
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  KeyError: 'aqi'
Feb  6 12:48:28 raspberrypi weewx[7471] ERROR weewx.reportengine:
  Generator terminated
Feb  6 12:48:28 raspberrypi weewx[7471] INFO weewx.reportengine: Copied 37
files to /var/www/html/weewx/belchertown

On Sat, Feb 6, 2021 at 11:53 AM salinois  wrote:

> My install for me
>
> sudo /usr/local/weewx(or your path)/wee_extension --install /home/pi(or your 
> path)/weewx-belchertown-x.x.zip
>
> patrick
>
> Le 06/02/2021 à 17:26, Michael Sanphillipo a écrit :
>
> Do I just paste into the different directories or is there an install
> method?
>
> On Sat, Feb 6, 2021 at 11:21 AM salinois  wrote:
>
>> hello
>>
>> you can use the *.zip
>>
>> Patrick
>> Le 06/02/2021 à 15:04, Michael Sanphillipo a écrit :
>>
>> I'm  using Belchertown version 1.2.  How do you install the latest
>> commits since the last version release? Do you simply download the zip file
>> from github and paste into the directories or is the an install method for
>> python3? --
>> 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/994aea23-acd4-4ac9-a236-8106f8649e0an%40googlegroups.com
>> 
>> .
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit
>> https://grou

[weewx-user] Re: I am trying to install wewx on Raspberry PI and fail at (almost) the first hurdle. Following the instructions I get as far as the " wget - qo - http://weewx.com/keys.html | sudo apt-k

[Allan Robinson]

Hi Perhaps I spoke too soon...
Whilst your suggestion didn't return an error (Thanks again) "sudo apt-get 
install weewx" started normally but finally produced "E: Unable to locate 
package weewx"


On Saturday, 6 February 2021 at 16:57:36 UTC Allan Robinson wrote:

> Thank you very much Paul, that fixed it.
>
>
> On Saturday, 6 February 2021 at 16:44:41 UTC Paul Eaton wrote:
>
>> Hi
>> I think you need an upper case letter O not a lower case o after the q
>> And it should be -qO no space after the dash and you need a dash at the 
>> end.
>> Best bet is to copy and paste the entry directly from the WeeWX 
>> installation instructions.
>> wget -qO - https://weewx.com/keys.html | sudo apt-key add -
>>
>> Paul
>>
>> On Saturday, 6 February 2021 at 15:43:40 UTC allanro...@gmail.com wrote:
>>
>>>
>>> Any suggestions?
>>>
>>>

-- 
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/821e2562-d549-4501-a4c7-09e210837463n%40googlegroups.com.

[weewx-user] Re: I am trying to install wewx on Raspberry PI and fail at (almost) the first hurdle. Following the instructions I get as far as the " wget - qo - http://weewx.com/keys.html | sudo apt-k

[vince]

Please re-read the top of http://weewx.com/docs/debian.htm

There are 'four' commands you need to run.

Under 'configure apt':
* run the command under 'Tell your system to trust weewx.com'
* run the command under 'For Debian10 and later, use python3'

Under 'Install':
* run the first command there
* run the second command there

You didn't run all four commands.

On Saturday, February 6, 2021 at 9:55:02 AM UTC-8 allanro...@gmail.com 
wrote:

> Hi Perhaps I spoke too soon...
> Whilst your suggestion didn't return an error (Thanks again) "sudo apt-get 
> install weewx" started normally but finally produced "E: Unable to locate 
> package weewx"
>
>
> On Saturday, 6 February 2021 at 16:57:36 UTC Allan Robinson wrote:
>
>> Thank you very much Paul, that fixed it.
>>
>>
>> On Saturday, 6 February 2021 at 16:44:41 UTC Paul Eaton wrote:
>>
>>> Hi
>>> I think you need an upper case letter O not a lower case o after the q
>>> And it should be -qO no space after the dash and you need a dash at the 
>>> end.
>>> Best bet is to copy and paste the entry directly from the WeeWX 
>>> installation instructions.
>>> wget -qO - https://weewx.com/keys.html | sudo apt-key add -
>>>
>>> Paul
>>>
>>> On Saturday, 6 February 2021 at 15:43:40 UTC allanro...@gmail.com wrote:
>>>

 Any suggestions?



-- 
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/9db2f6ef-b6e7-45e5-a8b1-f946f438b99an%40googlegroups.com.

Re: [weewx-user] Re: Graph not update

[John Kline]

The two lines you are asking about should be entered exactly one time in each 
template where you are adding a ?$cachebuster to an image URL.  It should be 
entered above the first time you use it.

> On Feb 6, 2021, at 8:53 AM, ginfo...@gmail.com  wrote:
> 
> 
> It works !!!
> 
> You are a genius, thank you !!
> 
> I finally solved the problem of updating the charts for good.
> 
> But the code:
> 
> #import time
> 
> #set $ cachebuster = time.time
> 
> 
> 
> do I always have to repeat it on each pair of images?
> 
> Thanks again from the heart !!!
> 
> Il giorno sabato 6 febbraio 2021 alle 15:50:14 UTC+1 jo...@johnkline.com ha 
> scritto:
>> Hardcoding a timestamp makes it not a timestamp and will accomplish nothing.
>> 
>> Try this:
>> 
>> #import time
>> #set $cachebuster = time.time
>> 
>>   >  alt = "$Extras.Translation.temperatures">
>> 
>> 
>>> On Feb 6, 2021, at 6:22 AM, ginfo...@gmail.com  wrote:
>>> 
>>> 
>> 
>>> No way:
>>> I added the timestamp to the images but it doesn't work!
>>> 
>>>  >> "daytempdew.png? v = 1612619365" alt = "$ Extras.Translation.temperatures"> 
>>> 
>>> 
>>> Il giorno sabato 6 febbraio 2021 alle 03:18:08 UTC+1 tomn...@frontier.com 
>>> ha scritto:
 Not sure if this is related, but I've got a similar issue with pictures 
 getting posted on the web that "weren't updating."
 Turns out there's a trick to trick the cache into reloading the image 
 file, and it is essentially including an argument
 in the URL of a timestamp for the image.  That defeats the browsers 
 caching mechanism. It looks like this:
 >>> href="myshake/gifs/RD066_EHZ_AM_00.2019100200.gif?v=1570017689"> night 
    /  >>> href="myshake/gifs/RD066_EHZ_AM_00.2019100212.gif?v=1570060855"> day 
 
 Chris
 
 On Friday, February 5, 2021 at 6:06:20 AM UTC-7 ginfo...@gmail.com wrote:
> I change the skin but nothing
> 
> Il giorno venerdì 5 febbraio 2021 alle 09:01:26 UTC+1 gjr80 ha scritto:
>> OK, now I see the plots are sitting on 08:00 (it's 08:50) now and no 
>> amount of refreshing will update them. In fact if I look at just one of 
>> your image files directly (eg http://www.meteomestre.it/daywindvec.png) 
>> it exhibits the same behaviour only stuck on the time I first viewed the 
>> plot. This was in Firefox. If I look at your site in Chrome it is stuck 
>> on the same 08:00 plots. Interestingly if I open the same plot file 
>> directly that I did in Firefox I see the plot is timestamped 08:35. If I 
>> open a different plot file directly I see the current time stamp (most 
>> recent upload). No amount of cache clearing will fix it for me (in 
>> either Chrome or Firefox).
>> 
>> Clearly the files are being uploaded to your web server OK so that rules 
>> out WeeWX. The fact that two browsers have the same issue tends to rule 
>> out browser quirks. Which only leaves your HTML/scripts. Think you need 
>> a HTMl/javascript/CSS expert, something in there will be doing it.
>> 
>> Gary
>> 
>> On Friday, 5 February 2021 at 17:00:35 UTC+10 ginfo...@gmail.com wrote:
>>> Obviously I'm talking about the graphs, if you look closely, those of 
>>> the day are still.
>>> They should update every 5 minutes ...
>>> 
>>> Il giorno venerdì 5 febbraio 2021 alle 07:48:05 UTC+1 
>>> ginfo...@gmail.com ha scritto:
 If I delete the browser cache, it updates regularly, but then remains 
 blocked there
 
 Il giorno venerdì 5 febbraio 2021 alle 07:45:10 UTC+1 
 ginfo...@gmail.com ha scritto:
> Yes, the station updates regularly and transmits data.
> These are the graphics that are not transmitted and updated on the 
> site.
> I checked the local and remote folder, and the graphs are regularly 
> updated.
> It appears to be a cache problem.
> 
> Il giorno venerdì 5 febbraio 2021 alle 07:35:50 UTC+1 
> graha...@gmail.com ha scritto:
>> is this the correct target ftp location?
>> 
>>> On 5 Feb 2021, at 5:24 pm, ginfo...@gmail.com  
>>> wrote:
>>> 
>>> Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
>>> Connected to it31.siteground.eu
>>> Feb  5 05:55:32 raspberrypi weewx[7414] DEBUG weeutil.ftpupload: 
>>> Uploaded file /home/weewx/public_html/favicon.ico to 
>>> /public_html/www.meteomestre.it/favicon.ico
>>> 
>> 
>>> 
>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/0978bc52-8c1a-4765-a5a2-1f63cac82364n%40googlegroups.com.
> 
> -- 
> You received this me

[weewx-user] Suggestion to weewx after booting with gw1000 driver

[Vetti52]

My Weewx installation was updated to version 4.4.0 using 

sudo apt-get update
sudo apt-get install weewx

under debian buster on a Raspberry Pi 4. The driver is gw1000 version 0.2.0.

After rebooting my Raspberry Pi (this happens only about once or twice a 
year), I realized, that weewx was not running. After systemctl status 
weewx.service (which actually evokes /etc/init.d/weewx status) I was 
confronted with the message

Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
  debug_wind=self.debug_wind)
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
File "/usr/share/weewx/user/gw1000.py", line 2166, in __init__
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
  lost_contact_log_period=lost_contact_log_period)
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
File "/usr/share/weewx/user/gw1000.py", line 2915, in __init__
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
  ip_port_list = self.discover()
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
File "/usr/share/weewx/user/gw1000.py", line 3005, in discover
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
  socket_obj.sendto(packet, (self.broadcast_address, 
self.broadcast_port))
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: 
  OSError: [Errno 101] Das Netzwerk ist nicht erreichbar
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__: Unable 
to load driver: [Errno 101] Das Netzwerk ist nicht erreichbar
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__: 
  Exiting...

After some investigation, I realized, that weewx was not exiting but still 
running. So I had first to stop it and could then start it without any 
issues. I suppose, that while invoking weewx during boot time from the 
/etc/init.d/weewx 
script, the network is not yet up. However, the gw1000 driver relies on an 
existing network and therefore blocks any further actions of weewx, which 
remains running. 
I would therefore propose, to replace the init.d script by a weewx.service 
directive instead.
I realized meanwhile, that there is a /etc/weewx/weewx.service file version 
from 02.02.2020, which is currently not enabled. There are three stanza 
entries
[Unit] 
Requires=time-sync.target
After=time-sync.target
RequiresMountsFor=/home

which I don't know, what they are supposed for, but I think, that for 
stability reason, it should have at least this additional the stanza in

[Unit]
After=network-online.target

and maybe taylor the rest of this file, and after enabling it, take systemctl 
start weeww.service as the regular starting process, instead of the 
/etc/init.d/weewx script.

What speaks against this proposal, or, why is the init.d version still 
preferably 
established?

-Peter

-- 
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/dcbcd2e3-b48b-4cef-9cf0-e46306bc4e63n%40googlegroups.com.

Re: [weewx-user] Belchertown Skin install updates since last release

[Michael Sanphillipo]

Thanks, it's working great.

On Saturday, February 6, 2021 at 11:53:11 AM UTC-5 sali...@gmail.com wrote:

> My install for me
>
> sudo /usr/local/weewx(or your path)/wee_extension --install /home/pi(or your 
> path)/weewx-belchertown-x.x.zip
>
> patrick
>
> Le 06/02/2021 à 17:26, Michael Sanphillipo a écrit :
>
> Do I just paste into the different directories or is there an install 
> method?
>
> On Sat, Feb 6, 2021 at 11:21 AM salinois  wrote:
>
>> hello
>>
>> you can use the *.zip
>>
>> Patrick
>> Le 06/02/2021 à 15:04, Michael Sanphillipo a écrit :
>>
>> I'm  using Belchertown version 1.2.  How do you install the latest 
>> commits since the last version release? Do you simply download the zip file 
>> from github and paste into the directories or is the an install method for 
>> python3? -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/994aea23-acd4-4ac9-a236-8106f8649e0an%40googlegroups.com
>>  
>> 
>> .
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/weewx-user/fWo_YSdhmzs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b73d04a5-2948-3d15-1f5e-aa7c5b285ac3%40gmail.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+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAAsGudq3KdOjxjXbfB%2BvLk5Va7Fu_4b9uextQ-zSc497NrgGuA%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/e977759a-97fb-4a11-bda9-9928fef1ab1en%40googlegroups.com.

[weewx-user] Re: Suggestion to weewx after booting with gw1000 driver

[gjr80]

I make no comment on systemd or service files but if loop_on_init 
 is set True in weewx.conf 
and the GW1000 driver is being used as a driver WeeWX should recover from 
the lack of a network on startup. 

On WeeWX startup when loading the GW1000 driver the GW1000 driver does need 
to contact the GW1000 concerned before allowing WeeWX to continue startup. 
If there is no network connection the GW driver will raise a critical error 
(as shown in the log extract above) and WeeWX will exit. If loop_on_init is 
set True WeeWX should restart in 60 seconds (default) and the GW1000 driver 
will attempt contact again. If loop_on_init is not set True WeeWX will 
exit. This is standard behaviour in many drivers. If the GW1000 driver is 
not exhibiting this behaviour it is a bug and I would appreciate full 
details so it can be fixed.

Gary

On Sunday, 7 February 2021 at 06:24:29 UTC+10 Vetti52 wrote:

> My Weewx installation was updated to version 4.4.0 using 
>
> sudo apt-get update
> sudo apt-get install weewx
>
> under debian buster on a Raspberry Pi 4. The driver is gw1000 version 
> 0.2.0.
>
> After rebooting my Raspberry Pi (this happens only about once or twice a 
> year), I realized, that weewx was not running. After systemctl status 
> weewx.service (which actually evokes /etc/init.d/weewx status) I was 
> confronted with the message
>
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine:   debug_wind=self.debug_wind)
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine: File "/usr/share/weewx/user/gw1000.py", line 
> 2166, in __init__
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine:   lost_contact_log_period=lost_contact_log_period)
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine: File "/usr/share/weewx/user/gw1000.py", line 
> 2915, in __init__
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine:   ip_port_list = self.discover()
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine: File "/usr/share/weewx/user/gw1000.py", line 
> 3005, in discover
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine:   socket_obj.sendto(packet, 
> (self.broadcast_address, self.broadcast_port))
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
> weewx.engine:   OSError: [Errno 101] Das Netzwerk ist nicht 
> erreichbar
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__: Unable 
> to load driver: [Errno 101] Das Netzwerk ist nicht erreichbar
> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__: 
>   Exiting...
>
> After some investigation, I realized, that weewx was not exiting but still 
> running. So I had first to stop it and could then start it without any 
> issues. I suppose, that while invoking weewx during boot time from the 
> /etc/init.d/weewx 
> script, the network is not yet up. However, the gw1000 driver relies on an 
> existing network and therefore blocks any further actions of weewx, which 
> remains running. 
> I would therefore propose, to replace the init.d script by a weewx.service 
> directive instead.
> I realized meanwhile, that there is a /etc/weewx/weewx.service file 
> version from 02.02.2020, which is currently not enabled. There are three 
> stanza entries
> [Unit] 
> Requires=time-sync.target
> After=time-sync.target
> RequiresMountsFor=/home
>
> which I don't know, what they are supposed for, but I think, that for 
> stability reason, it should have at least this additional the stanza in
>
> [Unit]
> After=network-online.target
>
> and maybe taylor the rest of this file, and after enabling it, take systemctl 
> start weeww.service as the regular starting process, instead of the 
> /etc/init.d/weewx script.
>
> What speaks against this proposal, or, why is the init.d version still 
> preferably 
> established?
>
> -Peter
>

-- 
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/a73d7d24-81f8-4c2d-972f-15fa4b095316n%40googlegroups.com.

[weewx-user] Re: Suggestion to weewx after booting with gw1000 driver

[vince]

Peter - the gw1000 has at least two watchdog timers in it, and will reboot 
without being able to contact both the NTP and Web servers at Ecowitt for 
too long a period.  There is some discussion on wxforum.net regarding how 
to set up your own LAN services to fake it out.   Multiple people including 
me have asked Ecowitt to give us a way to disable their watchdogs, but they 
have declined to agree to do that.  They just respond with the same 
information saying how the user can impersonate their servers with some DNS 
and webserver sleight of hand.

-- 
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/18568781-3a70-4f7f-acf0-d01a8ec110c0n%40googlegroups.com.

[weewx-user] Re: Suggestion to weewx after booting with gw1000 driver

[gjr80]

Different but I guess related issue. WeeWX/GW1000 driver will happily 
connect to the GW1000 wether the GW1000 has internet connectivity or not. 
Any data will be at best sporadic or, in some cases, next to useless but 
the lack of internet does not prevent WeeWX/GW1000 driver operation per se.

Gary

On Sunday, 7 February 2021 at 07:05:53 UTC+10 vince wrote:

> Peter - the gw1000 has at least two watchdog timers in it, and will reboot 
> without being able to contact both the NTP and Web servers at Ecowitt for 
> too long a period.  There is some discussion on wxforum.net regarding how 
> to set up your own LAN services to fake it out.   Multiple people including 
> me have asked Ecowitt to give us a way to disable their watchdogs, but they 
> have declined to agree to do that.  They just respond with the same 
> information saying how the user can impersonate their servers with some DNS 
> and webserver sleight of hand.
>
>

-- 
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/cf6a4c7b-817b-41f5-aeb6-3276773c5247n%40googlegroups.com.

Re: [weewx-user] Version 4.4.0

[David Trebacz]

My first upgrade of Wewwx (after years on wview). Upgraded from 4.1.1 to 
4.4.0 with Belchertown 1.2 on a Ubuntu 20.04 VM using the setup.py method. 
Wow that was smooth... Great software and wonderful community.

On Thursday, February 4, 2021 at 7:14:28 AM UTC-7 kk44...@gmail.com wrote:

> Meanwhile I would add, that the update was without problems in my case 
> (Ubuntu apt-get upgrade). I use Belchertown skin and some additional 
> uploaders.
>
> Vetti52 schrieb am Donnerstag, 4. Februar 2021 um 11:04:43 UTC+1:
>
>> Hi,
>> maybe a new thread would be helpful, because the issue is/was very 
>> special and might not be a problem with version 4.4.0:
>>
>> After I realized, that weewx could be run manually, I was inspecting, 
>> what was the difference. I had updated to version 4.4.0 and also had an 
>> update for my Zigbee device driver (deCONZ). Then I had to reboot the 
>> Raspberry Pi and after that the error occured. Finally I realized, that, 
>> the /etc/init.d/weewx start failed, with code=exited but no success. I 
>> misinterpreted this as that weewx was not running, since there were no 
>> syslog entries at all. Repeating to start weewx using the previous 
>> interceptor driver did not work either. So I decided to let it run with 
>> gw1000 driver, but started it manually with sudo weewxd 
>> /etc/weewx/weewx.conf >nul &.  This was successful, and went to sleep
>> Today I decided to look at this issue again and, instead of killing the 
>> manually started weexd properly, I accidently used /etc/init.d/weewx stop, 
>> which indeed stopped weewx, but the manually started weewxd continued. 
>> After I stopped this too, I realized, that weewx had in fact been started 
>> autmatically after reboot, but got stuck, as you say, because of the gw1000 
>> driver. What I did not expect, is, that weewx then did not exit. Any 
>> additional starting command therefore failed. I was cind of silly, not to 
>> look at that, sorry. After stopping the hanging weewx, I could start weewx 
>> as expected, and now it works without any issues. Maybe, it would be better 
>> not to start weewx with its init.d script, but with systemctl using a 
>> separate weewx.service file which should contain a stanza like
>>
>> [Unit]
>> After=network-online.target
>>
>> that would avoid to start weewx before network is up, which seems to be a 
>> crucial step for gw1000. But this should be another thread, I think.
>>
>> Thanks 
>> Peter
>> gjr80 schrieb am Mittwoch, 3. Februar 2021 um 20:33:21 UTC+1:
>>
>>> Ok, can you please set debug=1, restart WeeWX as a daemon and post in a 
>>> new thread the log through until the failure occurs.
>>>
>>> Gary
>>>
>>> On Thursday, 4 February 2021 at 05:28:00 UTC+10 Vetti52 wrote:
>>>
 just to narrow down my problem:

 When starting manually 
  weewxd /etc/weewx/weewx.conf
 it works. Starting with
 systemctl start weewx, 
 it fails.
 Maybe, I will find out, what makes the difference. But, just in case, 
 someone knows the trick, please tell!

 Thanks
 -Peter

 Vetti52 schrieb am Mittwoch, 3. Februar 2021 um 18:20:07 UTC+1:

> Typo: Upgrade from 4.3.0 to 4.4.0.
> Version 4.3.0 had no issues so far.
>
> Vetti52 schrieb am Mittwoch, 3. Februar 2021 um 18:17:46 UTC+1:
>
>> Just upgraded from 4.4.3 to 4.4.0, but it fails.
>> got this in systemctl status weewx.service:
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine:   debug_wind=self.debug_wind)
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine: File "/usr/share/weewx/user/gw1000.py", line 
>> 2166, in __init__
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine:   
>> lost_contact_log_period=lost_contact_log_period)
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine: File "/usr/share/weewx/user/gw1000.py", line 
>> 2915, in __init__
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine:   ip_port_list = self.discover()
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine: File "/usr/share/weewx/user/gw1000.py", line 
>> 3005, in discover
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine:   socket_obj.sendto(packet, 
>> (self.broadcast_address, self.broadcast_port))
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> weewx.engine:   OSError: [Errno 101] Das Netzwerk ist nicht 
>> erreichbar
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__: 
>> Unable to load driver: [Errno 101] Das Netzwerk ist nicht erreichbar
>> Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL 
>> __main__:   Exiting...
>>
>> Hopefully someone knows, what to do.

[weewx-user] Re: MQTTSubscribe and topics, that are seldom sent

[bell...@gmail.com]

Thanks for the log and configuration information. After working through it 
and WeeWX, I believe that everything is working as designed.
>From the log, I will assume your archive_interval is 300 and archive_delay 
is 15.

During this time of the log, MQTTSubscribe is chugging along, but nothing 
has been received and therefore the loop packet is ‘passed through’.
Feb  6 15:44:53 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:44:53 CET (1612622693): dateTime: 
1612622693, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 59, windSpeed: 
9.0
Feb  6 15:44:56 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:44:56 CET (1612622696): dateTime: 
1612622696, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 53, windSpeed: 
11.0
Feb  6 15:44:58 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:44:58 CET (1612622698): dateTime: 
1612622698, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 65, windSpeed: 
12.0

We have now passed the end of archive interval (5 minutes). WeeWX ‘puts 
aside’ the accumulated loop data for this interval (15:40 to 15:45) and 
starts accumulating data for the 15:45 to 15:50 archive interval.
Feb  6 15:45:01 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:45:01 CET (1612622701): dateTime: 
1612622701, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 63, windSpeed: 
12.0
Feb  6 15:45:03 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:45:03 CET (1612622703): dateTime: 
1612622703, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 61, windSpeed: 
12.0
Feb  6 15:45:04 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:45:03 CET (1612622703): altimeter: 
29.905, dateTime: 1612622703, dewpoint: 29.2, heatindex: 31.1, inDewpoint: 
45.5, inHumidity: 42.4, inTemp: 69.3, outHumidity: 92.4, outTemp: 31.1, 
pressure: 29.306, radiation: 7, rain: 0.0, rainRate: 0.0, signal1: 0, 
txBatteryStatus: 0, usUnits: 1, UV: 0.0, windchill: 22.7, windDir: 61, 
windDir10: 69, windGust: 16.0, windGustDir: 44, windSpeed: 12.0, 
windSpeed10: 9.87
Feb  6 15:45:06 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:45:06 CET (1612622706): dateTime: 
1612622706, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 74, windSpeed: 
12.0
Feb  6 15:45:08 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:45:08 CET (1612622708): dateTime: 
1612622708, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 74, windSpeed: 
12.0
Feb  6 15:45:11 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-02-06 15:45:11 CET (1612622711): dateTime: 
1612622711, rain: 0.0, rainRate: 0.0, usUnits: 1, windDir: 64, windSpeed: 
12.0

Incoming MQTT data is received and queued up.
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
MessageCallbackProvider data-> incoming topic: pegel/566055/Q, QOS: 0, 
retain: 0, payload: b'41.3'
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> incoming pegel/566055/Q: Q566055v: 41.3
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
MessageCallbackProvider data-> incoming topic: pegel/566055/W_cm, QOS: 0, 
retain: 0, payload: b'156.0'
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> incoming pegel/566055/W_cm: W566055v: 156.0
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
MessageCallbackProvider data-> incoming topic: pegel/567470/Q, QOS: 0, 
retain: 0, payload: b'87.4'
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> incoming pegel/567470/Q: Q567470v: 87.4
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
MessageCallbackProvider data-> incoming topic: pegel/567470/W_cm, QOS: 0, 
retain: 0, payload: b'153.0'
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> incoming pegel/567470/W_cm: W567470v: 153.0
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> outgoing pegel/566055/W_cm: dateTime: 
1612622713.6558828, usUnits: 16, W566055v: 156.0
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> outgoing accumulated pegel/566055/W_cm: dateTime: 
1612622713, usUnits: 1, W566055v: 5.118110236220472
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> outgoing pegel/566055/Q: dateTime: 1612622713.6551414, 
Q566055v: 41.3, usUnits: 16
Feb  6 15:45:13 LokalWiki weewx[153466] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> outgoing accumulated pegel/566055/Q: dateTime: 
1612622713, Q566055v: 1458.49711,

[weewx-user] Real-Time Gauge Extensions

[tim lambert]

Gary/All,

I'm looking to install the Real Time Extension, however the installation 
instructions reference a 0.5.0 release, which does not appear to be 
available on GitHub.

When I attempt to install the 0.4.2 release, I receive the following:

 















*sudo ./wee_extension 
--install=/home/pi/Downloads/weewx-realtime_gauge-data-0.4.2.tar.gzRequest 
to install 
'/home/pi/Downloads/weewx-realtime_gauge-data-0.4.2.tar.gz'Extracting from 
tar archive 
/home/pi/Downloads/weewx-realtime_gauge-data-0.4.2.tar.gzTraceback (most 
recent call last):  File "./wee_extension", line 88, in main()  
File "./wee_extension", line 80, in main
ext.install_extension(options.install)  File 
"/home/weewx/bin/weecfg/extension.py", line 125, in install_extension
self.install_from_dir(extension_dir)  File 
"/home/weewx/bin/weecfg/extension.py", line 147, in install_from_dir
extension_dir)  File "/home/weewx/bin/weecfg/__init__.py", line 1873, in 
get_extension_installerinstaller = loader()  File 
"/var/tmp/weewx-realtime_gauge-data-0.4.2/install.py", line 86, in loader  
File "/var/tmp/weewx-realtime_gauge-data-0.4.2/install.py", line 95, in 
__init__weewx.UnsupportedFeature: Rtgd 0.4.0 requires weeWX 400.0b1 or 
greater, found 4.4.0*

Any guidance appreciated.

-- Tim

-- 
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/63911aca-d795-46ce-9b56-c2e459747587n%40googlegroups.com.

Re: [weewx-user] Re: WEEWX-WD and Weewx 4.2 to 4.4

[tim lambert]

Team,

A quick update...

I've completed standing up WeeWx 4.4 on a dedicated (for now) Pi 4, with 
the IP-100 extension using the Seasons Skins and FTP the Seasons 
reports/graphs to a remote public server.  The performance stats are:

*Seasons Reports == 1.21 seconds*
*Season Images == 0.54 seconds*
*FTP == 6.89 seconds*
*Total Processing Time == 8.64 seconds*

Next I added in writing to to a MariaDB on a 1TB hard drive connected 
directly to the Pi4.   The aforementioned performance stats did not change.

Next, I implemented the WD Extension, using the local MariaDB to write the 
databases suggested by WD Extensions.  The performance stats:

*Seasons Reports == 1.21 seconds*
*Seasons Images == 0.60 seconds*
*WD Files (testtags, windrose & clientraw files) == 1.13 seconds*
*FTP == 8.26 seconds*
*Total Processing Time == 11.20 seconds*

Finally, I added in the Steel Gauges, which the average performance stats:

*Seasons Reports == 2.42 seconds*
*Seasons Images == 0.63 seconds*

* WD Files (testtags, windrose & clientraw files) == 4.27 seconds *
*Steel Gauges == 0.74 seconds*

*FTP == 16.02 seconds*
*Total Processing Time == 24.08 seconds*

Note:  the only other delta between the original configuration and the new 
configuration, besides moving the MySQL/MariaDB from a remote/hosted server 
to a local server with an HD -- the original configuration also had 
consoleWD from Weather Display.

Conclusion --  the data exchange between weeWX and the remote/hosted server 
was extremely intensive and thus slowing down the reporting process (which 
Gary and Tom both thought was the root cause).

Thanks for helping me sleuth this one -- hopefully others will benefit from 
the errors in my architecture.

-- Tim

On Friday, February 5, 2021 at 10:57:47 PM UTC-8 tim lambert wrote:

> Thanks everyone for your input...  You have all pointed me to what is 
> beginning to look like the root cause -- using a remote MySQL server.
>
> So far, I've stood up another Pi 4 to be dedicated for weewx (for now).  A 
> basic installation using the Seasons skin -- reports/graphs are generating 
> in roughly 1.2 seconds.  FTP of the public_html is taking 7 seconds.   
>
> Tomorrow, I'll stand up Maria DB (Raspberry version of MySQL) on the same 
> Pi, with the DB being on a 1TB attached drive.   Once Maria DB is installed 
> and configured, I'll add in phpMyAdmin (to help with quick DB Table 
> analysis).   Next will be to install WD Extensions and SS Gauges, which 
> will utilize the DB on the attached drive.  
>
> Hoping for a marked performance improvement -- I'll share my learnings.
>
> -- Tim
>
> On Friday, February 5, 2021 at 6:07:50 PM UTC-8 vince wrote:
>
>> Just for kicks, run "*top*", hit '*1*' to see all the cpu cores 
>> individually, and see if you see anything with a percentage other than 0.0 
>> next to "*ni*" in the output.   That'll help us see if you have things 
>> waiting for i/o.
>>
>> You might need to let it run for a little to watch things start/stop and 
>> change states on the various cpus, but concentrate on the '*ni*' item in 
>> each line there.   To get out of top, hit '*q*' for quit.
>>
>> My pi3 reports the following:
>>
>> top - 18:04:58 up 9 days, 30 min,  3 users,  load average: 0.12, 0.15, 
>> 0.12
>> Tasks: 137 total,   2 running, 135 sleeping,   0 stopped,   0 zombie
>> %Cpu0  :  4.0 us,  0.3 sy,  0.0 ni, 95.6 id,  0.0 wa,  0.0 hi,  0.0 si, 
>>  0.0 st
>> %Cpu1  :  1.0 us,  0.0 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si, 
>>  0.0 st
>> %Cpu2  :  1.7 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si, 
>>  0.0 st
>> %Cpu3  :  0.3 us,  1.0 sy,  0.0 ni, 98.6 id,  0.0 wa,  0.0 hi,  0.0 si, 
>>  0.0 st
>> MiB Mem :926.1 total, 30.5 free,349.4 used,546.2 
>> buff/cache
>> MiB Swap:100.0 total, 98.5 free,  1.5 used.443.5 avail Mem
>>
>> On Friday, February 5, 2021 at 5:32:33 PM UTC-8 tim lambert wrote:
>>
>>> Gary,
>>>
>>>  
>>>
>>> I think you hit on the root cause.
>>>
>>>  
>>>
>>> I’m standing up another Pi with an external HD attached to support the 
>>> DB – the idea is to keep the DB traffic off the SD card.
>>>
>>>  
>>>
>>> Regards,
>>>
>>>  
>>>
>>> Tim
>>>
>>>  
>>>
>>> *From: *gjr80
>>> *Sent: *Friday, February 5, 2021 2:42 PM
>>> *To: *weewx-user
>>> *Subject: *Re: [weewx-user] Re: WEEWX-WD and Weewx 4.2 to 4.4
>>>
>>>  
>>>
>>> I’m not sure MySQL is the issue per se, rather I suspect the remote 
>>> connection. The main WeeWX-WD template testtags.php.tmpl has some 1000 odd 
>>> $day, $month, $year tags; of the other four clientraw templates there is 
>>> some 500 $day, $month, $year tags  And we haven’t even gotten to the search 
>>> list extensions of which there are numerous and some quite database 
>>> intensive. I run WeeWX-WD on a RPi 3B+ along with about 10 other skins and 
>>> and my total report generation time is just over 45 seconds. That is using 
>>> MySQL locally and running a second instance of WeeWX-WD to support a GW1000.
>>>
>>>  

[weewx-user] update identifier for HIDEKI-wind and hideki rain to the new style SDR.

[Giuseppe Saia]

greetings to all
it would be possible to please insert an update identifier for HIDEKI-WIND 
and HIDEKI RAIN to the new style SDR.

Feb  7 04:45:14 raspberrypi weewx[7159] DEBUG user.sdr: parse_json: unknown 
model Hideki-Rain
Feb  7 04:45:14 raspberrypi weewx[7159] DEBUG user.sdr: punt unrecognized 
line '{"time" : "2021-02-07 03:45:10", "model" : "Hideki-Rain", "id" : 0, 
"channel" : 4, "battery_ok" : 1, "rain_mm" : 1382.500, "mic" : "CRC"}#012'

Feb  7 04:45:00 raspberrypi weewx[7159] DEBUG user.sdr: parse_json: unknown 
model Hideki-Wind
Feb  7 04:45:00 raspberrypi weewx[7159] DEBUG user.sdr: punt unrecognized 
line '{"time" : "2021-02-07 03:44:54", "model" : "Hideki-Wind", "id" : 8, 
"channel" : 4, "battery_ok" : 1, "temperature_C" : 15.200, "wind_avg_mi_h" 
: 2.600, "wind_max_mi_h" : 2.900, "wind_approach" : 1, "wind_dir_deg" : 
337.500, "mic" : "CRC"}#012'

thank you all

-- 
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/dd457906-e2ea-473e-ba52-9b8be1d0de2dn%40googlegroups.com.

[weewx-user] Re: Real-Time Gauge Extensions

[gjr80]

My apologies Tim, apart form the obvious bug in the rtgd v0.4.2 installer I 
seem to have ended up in the situation where my GitHub v0.5.0 is 
substantially different to v0.5.0 I have here at home. Give me a day or two 
to sort through the differences and I will have v0.5.0 released.

Gary

On Sunday, 7 February 2021 at 10:43:58 UTC+10 tim lambert wrote:

> Gary/All,
>
> I'm looking to install the Real Time Extension, however the installation 
> instructions reference a 0.5.0 release, which does not appear to be 
> available on GitHub.
>
> When I attempt to install the 0.4.2 release, I receive the following:
>
>  
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *sudo ./wee_extension 
> --install=/home/pi/Downloads/weewx-realtime_gauge-data-0.4.2.tar.gzRequest 
> to install 
> '/home/pi/Downloads/weewx-realtime_gauge-data-0.4.2.tar.gz'Extracting from 
> tar archive 
> /home/pi/Downloads/weewx-realtime_gauge-data-0.4.2.tar.gzTraceback (most 
> recent call last):  File "./wee_extension", line 88, in main()  
> File "./wee_extension", line 80, in main
> ext.install_extension(options.install)  File 
> "/home/weewx/bin/weecfg/extension.py", line 125, in install_extension
> self.install_from_dir(extension_dir)  File 
> "/home/weewx/bin/weecfg/extension.py", line 147, in install_from_dir
> extension_dir)  File "/home/weewx/bin/weecfg/__init__.py", line 1873, in 
> get_extension_installerinstaller = loader()  File 
> "/var/tmp/weewx-realtime_gauge-data-0.4.2/install.py", line 86, in loader  
> File "/var/tmp/weewx-realtime_gauge-data-0.4.2/install.py", line 95, in 
> __init__weewx.UnsupportedFeature: Rtgd 0.4.0 requires weeWX 400.0b1 or 
> greater, found 4.4.0*
>
> Any guidance appreciated.
>
> -- Tim
>

-- 
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/fc5a6268-3edd-424e-ae21-59a320e0adf8n%40googlegroups.com.