Re: [weewx-user] Re: weewx not updating after upgrade from 3.9 to 4.1.1

[Tom Keffer]

The log you showed is very short, and does not include the start up of
weewx. See the article *Help! Posting to weewx-user
* for how
to get a good log.

-tk

On Sun, Jun 21, 2020 at 1:58 AM miso k  wrote:

> Can I downgrade to previous version?
>
> Dňa nedeľa, 21. júna 2020 10:57:09 UTC+2 miso k napísal(a):
>>
>> Hello,
>> I just recently updated my RPi weewx 3.9.x to latest 4.1.1.
>>
>> I have not upgraded my conf files - choosed N option, during update.
>>
>> The webpage actualisations are not working. Can anybody help me, please?
>> What should I change?
>>
>> sudo tail  /var/log/syslog
>>> Jun 21 10:44:18 raspberrypi systemd[1]: systemd-hostnamed.service:
>>> Succeeded.
>>> Jun 21 10:44:49 raspberrypi systemd[1]: Started Session c3 of user pi.
>>> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Activating via
>>> systemd: service name='org.freedesktop.PackageKit'
>>> unit='packagekit.service' requested by ':1.26' (uid=0 pid=1138
>>> comm="/usr/bin/gdbus call --system --dest org.freedeskto")
>>> Jun 21 10:45:40 raspberrypi systemd[1]: Starting PackageKit Daemon...
>>> Jun 21 10:45:40 raspberrypi PackageKit: daemon start
>>> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Successfully
>>> activated service 'org.freedesktop.PackageKit'
>>> Jun 21 10:45:40 raspberrypi systemd[1]: Started PackageKit Daemon.
>>> Jun 21 10:50:45 raspberrypi PackageKit: daemon quit
>>> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Main process
>>> exited, code=killed, status=15/TERM
>>> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Succeeded.
>>
>>
>> Thanks,
>> Michal
>>
> --
> 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/19b8ed5a-cd01-4983-8903-c725d01880d1o%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/CAPq0zEAUbLez%2BRcRgOtuqdaq-gTU-D6_C%2Bvwm%2Bx8gwU3%3DY76XA%40mail.gmail.com.

Re: [weewx-user] Re: weewx not updating after upgrade from 3.9 to 4.1.1

[Tom Keffer]

I don't know what you mean by "the same thing."

On Sun, Jun 21, 2020 at 5:13 AM miso k  wrote:

> Actually I have an old backup of SD card - rolled back and updated with
> the new Database file.
> So I am running the 3.9.2 WeeWX again.
>
> Will the updating with setup.py do the same thing, as updating throug DEB
> package?
>
>
> Dňa nedeľa, 21. júna 2020 13:46:05 UTC+2 Tom Keffer napísal(a):
>>
>> The log you showed is very short, and does not include the start up of
>> weewx. See the article *Help! Posting to weewx-user
>> * for
>> how to get a good log.
>>
>> -tk
>>
>> On Sun, Jun 21, 2020 at 1:58 AM miso k  wrote:
>>
>>> Can I downgrade to previous version?
>>>
>>> Dňa nedeľa, 21. júna 2020 10:57:09 UTC+2 miso k napísal(a):

 Hello,
 I just recently updated my RPi weewx 3.9.x to latest 4.1.1.

 I have not upgraded my conf files - choosed N option, during update.

 The webpage actualisations are not working. Can anybody help me,
 please? What should I change?

 sudo tail  /var/log/syslog
> Jun 21 10:44:18 raspberrypi systemd[1]: systemd-hostnamed.service:
> Succeeded.
> Jun 21 10:44:49 raspberrypi systemd[1]: Started Session c3 of user pi.
> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Activating via
> systemd: service name='org.freedesktop.PackageKit'
> unit='packagekit.service' requested by ':1.26' (uid=0 pid=1138
> comm="/usr/bin/gdbus call --system --dest org.freedeskto")
> Jun 21 10:45:40 raspberrypi systemd[1]: Starting PackageKit Daemon...
> Jun 21 10:45:40 raspberrypi PackageKit: daemon start
> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Successfully
> activated service 'org.freedesktop.PackageKit'
> Jun 21 10:45:40 raspberrypi systemd[1]: Started PackageKit Daemon.
> Jun 21 10:50:45 raspberrypi PackageKit: daemon quit
> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Main
> process exited, code=killed, status=15/TERM
> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Succeeded.


 Thanks,
 Michal

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/19b8ed5a-cd01-4983-8903-c725d01880d1o%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/9bd888a3-88b9-4148-8ef1-4addfbba67cbo%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/CAPq0zEAm_oTiONs7hXtz_BTYTM%3D5EC25RMjgD6rNtRfSsEkZPQ%40mail.gmail.com.

[weewx-user] weewx not updating after upgrade from 3.9 to 4.1.1

[miso k]

Hello,
I just recently updated my RPi weewx 3.9.x to latest 4.1.1. 

I have not upgraded my conf files - choosed N option, during update.

The webpage actualisations are not working. Can anybody help me, please? 
What should I change?

sudo tail  /var/log/syslog
> Jun 21 10:44:18 raspberrypi systemd[1]: systemd-hostnamed.service: 
> Succeeded.
> Jun 21 10:44:49 raspberrypi systemd[1]: Started Session c3 of user pi.
> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Activating via 
> systemd: service name='org.freedesktop.PackageKit' 
> unit='packagekit.service' requested by ':1.26' (uid=0 pid=1138 
> comm="/usr/bin/gdbus call --system --dest org.freedeskto")
> Jun 21 10:45:40 raspberrypi systemd[1]: Starting PackageKit Daemon...
> Jun 21 10:45:40 raspberrypi PackageKit: daemon start
> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Successfully 
> activated service 'org.freedesktop.PackageKit'
> Jun 21 10:45:40 raspberrypi systemd[1]: Started PackageKit Daemon.
> Jun 21 10:50:45 raspberrypi PackageKit: daemon quit
> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Main process 
> exited, code=killed, status=15/TERM
> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Succeeded.


Thanks,
Michal

-- 
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/e1e30dac-39d1-4c09-a24a-a628d1e8f628o%40googlegroups.com.

[weewx-user] Re: retrieving old data from DAVIS VANTAGE PRO2

[Frank von Thienen]

Hi Gary,
sorry for beeing late, but the job is difficult at the moment, Software 
release for a big furniture dealer in Germany.
If swapping back, I get the same errors again, SLQite no issue, MySQL error.
But the normal readings of the actual values are correct retrieved. So 
MySQL is storing the 15 minutes values, but not reading the backlog import.
And that is odd

Thanks
Frank

Am Montag, 15. Juni 2020 12:29:19 UTC+2 schrieb gjr80:
>
> That seems odd, the error shown is the driver encountering a crc error on 
> data downloaded from the station. The driver has no access to the database 
> so I can’t see how the database in use could cause a driver crc error. If 
> you change back to MySQL again does it work? 
>
> Gary

-- 
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/f4280701-7430-401e-a9fa-16a13f29fa0co%40googlegroups.com.

[weewx-user] Re: weewx not updating after upgrade from 3.9 to 4.1.1

[miso k]

Can I downgrade to previous version?

Dňa nedeľa, 21. júna 2020 10:57:09 UTC+2 miso k napísal(a):
>
> Hello,
> I just recently updated my RPi weewx 3.9.x to latest 4.1.1. 
>
> I have not upgraded my conf files - choosed N option, during update.
>
> The webpage actualisations are not working. Can anybody help me, please? 
> What should I change?
>
> sudo tail  /var/log/syslog
>> Jun 21 10:44:18 raspberrypi systemd[1]: systemd-hostnamed.service: 
>> Succeeded.
>> Jun 21 10:44:49 raspberrypi systemd[1]: Started Session c3 of user pi.
>> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Activating via 
>> systemd: service name='org.freedesktop.PackageKit' 
>> unit='packagekit.service' requested by ':1.26' (uid=0 pid=1138 
>> comm="/usr/bin/gdbus call --system --dest org.freedeskto")
>> Jun 21 10:45:40 raspberrypi systemd[1]: Starting PackageKit Daemon...
>> Jun 21 10:45:40 raspberrypi PackageKit: daemon start
>> Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Successfully 
>> activated service 'org.freedesktop.PackageKit'
>> Jun 21 10:45:40 raspberrypi systemd[1]: Started PackageKit Daemon.
>> Jun 21 10:50:45 raspberrypi PackageKit: daemon quit
>> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Main process 
>> exited, code=killed, status=15/TERM
>> Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Succeeded.
>
>
> Thanks,
> Michal
>

-- 
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/19b8ed5a-cd01-4983-8903-c725d01880d1o%40googlegroups.com.

Re: [weewx-user] Re: weewx not updating after upgrade from 3.9 to 4.1.1

[miso k]

Actually I have an old backup of SD card - rolled back and updated with the 
new Database file.
So I am running the 3.9.2 WeeWX again.

Will the updating with setup.py do the same thing, as updating throug DEB 
package?


Dňa nedeľa, 21. júna 2020 13:46:05 UTC+2 Tom Keffer napísal(a):
>
> The log you showed is very short, and does not include the start up of 
> weewx. See the article *Help! Posting to weewx-user 
> * for 
> how to get a good log.
>
> -tk
>
> On Sun, Jun 21, 2020 at 1:58 AM miso k > 
> wrote:
>
>> Can I downgrade to previous version?
>>
>> Dňa nedeľa, 21. júna 2020 10:57:09 UTC+2 miso k napísal(a):
>>>
>>> Hello,
>>> I just recently updated my RPi weewx 3.9.x to latest 4.1.1. 
>>>
>>> I have not upgraded my conf files - choosed N option, during update.
>>>
>>> The webpage actualisations are not working. Can anybody help me, please? 
>>> What should I change?
>>>
>>> sudo tail  /var/log/syslog
 Jun 21 10:44:18 raspberrypi systemd[1]: systemd-hostnamed.service: 
 Succeeded.
 Jun 21 10:44:49 raspberrypi systemd[1]: Started Session c3 of user pi.
 Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Activating via 
 systemd: service name='org.freedesktop.PackageKit' 
 unit='packagekit.service' requested by ':1.26' (uid=0 pid=1138 
 comm="/usr/bin/gdbus call --system --dest org.freedeskto")
 Jun 21 10:45:40 raspberrypi systemd[1]: Starting PackageKit Daemon...
 Jun 21 10:45:40 raspberrypi PackageKit: daemon start
 Jun 21 10:45:40 raspberrypi dbus-daemon[312]: [system] Successfully 
 activated service 'org.freedesktop.PackageKit'
 Jun 21 10:45:40 raspberrypi systemd[1]: Started PackageKit Daemon.
 Jun 21 10:50:45 raspberrypi PackageKit: daemon quit
 Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Main 
 process exited, code=killed, status=15/TERM
 Jun 21 10:50:45 raspberrypi systemd[1]: packagekit.service: Succeeded.
>>>
>>>
>>> Thanks,
>>> Michal
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/19b8ed5a-cd01-4983-8903-c725d01880d1o%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/9bd888a3-88b9-4148-8ef1-4addfbba67cbo%40googlegroups.com.

Re: [weewx-user] Re: retrieving old data from DAVIS VANTAGE PRO2

[Tom Keffer]

Could we see a little more of the log? If the driver is unable to download
a page of memory from the logger, it should do a retry, yet I am seeing
only one try. What happens after the snippet you posted?

-tk

On Sun, Jun 21, 2020 at 3:48 AM Frank von Thienen 
wrote:

> Hi Gary,
> sorry for beeing late, but the job is difficult at the moment, Software
> release for a big furniture dealer in Germany.
> If swapping back, I get the same errors again, SLQite no issue, MySQL
> error.
> But the normal readings of the actual values are correct retrieved. So
> MySQL is storing the 15 minutes values, but not reading the backlog import.
> And that is odd
>
> Thanks
> Frank
>
> Am Montag, 15. Juni 2020 12:29:19 UTC+2 schrieb gjr80:
>>
>> That seems odd, the error shown is the driver encountering a crc error on
>> data downloaded from the station. The driver has no access to the database
>> so I can’t see how the database in use could cause a driver crc error. If
>> you change back to MySQL again does it work?
>>
>> Gary
>
> --
> 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/f4280701-7430-401e-a9fa-16a13f29fa0co%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/CAPq0zEDRKMBKKRTBDYs6zw_fxB%3DA-8qdPPsp%3DuY0VcRFzerunA%40mail.gmail.com.

[weewx-user] problem with css/style of embedded forecast in Responsive skin...

['Christian Peters' via weewx-user]

Hi all,

maybe some can help me. :-) 
I'm not familiar with css and web content. 
I trry to include the weewx forcast extension into the responsive skin. 
The forcast plugin is working, even with the right formatting if I open the 
forcast demo pages. (Pic 2)

I included the forecast_table.inc file in my html.tmpl, copied the icons to 
my skin, but the formatting isn't as expected?
How do I get the formatting provided for this snippet inside my skin?

That's my code:

Code hier eingeben...## Forecast start
 
  

  
5-Tage Trend
  

  
  

  
#set $periods = 
$forecast.weather_periods('OWM',max_events=6)
#include '/etc/weewx/skins/forecast/forecast_table.inc'
   

  

## Forecast end

It looks like Pic 1 now, it should look like Pic 2...!? 

Any idea how I get the formatting for this table inside my skin!?

Thanks in advance!

Regard,

Christian 

-- 
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/7cc53055-f606-4996-a15c-0802bbc46fd5o%40googlegroups.com.

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

[David Barto]

Weird, when presented my very long API key I get back a blank page. I’ll assume 
that is good. When I give it the short key I get back


{"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
 apiKey."}}]}

What debugging do I need to turn on (and where to look on the Mac) to see the 
URL being sent when I’m using wunderfixer to see what it is sending?

David


> On Jun 21, 2020, at 9:25 AM, Tom Keffer  wrote:
> 
> Odds are it's a WU thing. 
> 
> If you're comfortable manipulating URLs, you can try a GET request directly. 
> Use the URL
> 
> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>  
> 
> 
> where X is your API key. Sometimes this will give you additional detail.
> 
> Interestingly, when I try the above with my own API key, I get a 204 ("No 
> Content") error, not a 403.
> 
> -tk
> 
> 
> 
> On Sun, Jun 21, 2020 at 8:58 AM David Barto  > wrote:
> The key, password, and API all match with the station name.
> 
> When I look at the station under https://www.wunderground.com/member/devices 
>  -> My Devices, it shows Offline.
> 
> I’m assuming that is because I’m not sending data rather than some other step 
> in the setup process that I’m not able to discern. Web searches don’t show 
> any registration steps that I’ve missed.
> 
> Is it just a WU thing, or am I really just missing something obvious?
> 
>   David
> 
>> On Jun 20, 2020, at 5:59 PM, Tom Keffer > > wrote:
>> 
>> Normally, if you give the wrong API key, you get a 401 error. You are 
>> getting a 403 error, which implies that the key may be right, but you do not 
>> have authorization to access the data. Are you sure you have the right 
>> station?
>> 
>> Also, double check the API key. You can find it here 
>> . Does it match what you have 
>> in weewx.conf?
>> 
>> -tk
>> 
>> On Sat, Jun 20, 2020 at 5:39 PM David Barto > > wrote:
>> I’ve got a new Station KCAPOWAY177
>> 
>> I’ve got an API key  and a ‘key’ <8 alpha numeric key> and 
>> my password to log into the site.
>> 
>> No matter which of the 3 I choose for my password, the response to 
>> wunderfixer is always the same.
>> 
>> $ ./bin/wunderfixer --test --config=$(pwd)/weewx.conf --station=KCAPOWAY177 
>> —password= --verbose
>> Using configuration file /Users/Shared/weewx/weewx.conf.
>> Using database binding 'wx_binding', which is bound to database 
>> 'archive_sqlite'
>> Weather Underground Station:   KCAPOWAY177
>> Date to check: 2020-06-20
>> Number of archive records: 1055
>> Unable to open Weather Underground station KCAPOWAY177  or  HTTP Error 403: 
>> Forbidden
>> Could not get Weather Underground data. Exiting.
>> 
>> 
>> Any idea of where to go now?
>> 
>>  David
>> 
>> 
>> -- 
>> 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/4DA82895-538B-4EC3-9D85-4E148E4CFB29%40kdbarto.org
>>  
>> .
>> 
>> -- 
>> 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/CAPq0zEAE940H%3DAuHD30LC_Zx2oC1Myv041LbRGGv5hVshaxWQg%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/ECC4C459-B688-49DD-B5E0-63EF36ED6DC6%40kdbarto.org
>  
> .
> 
> -- 
> 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 

Re: [weewx-user] Re: No solar reading from Davis Vantage Pro2

[Tom Keffer]

The DMPAFT log entry is normal.

Is a value for solar radiation appearing on the console?

If you run weewxd directly from the command line, does it show a value for
radiation?

-tk

On Sun, Jun 21, 2020 at 1:26 PM peter  wrote:

> Thanks, vince,
> I will install it and see if it works better. I assume the issue is in the
> correct date? Why then only for a solar reading?
> The issue only happens on this setup but not on other 2 I own, that's why
> I'm surprised.
>
>
> Dne nedelja, 21. junij 2020 22.18.50 UTC+2 je oseba vince napisala:
>>
>> I'd start by ensuring the pi has quality time.  Generally running NTP
>> works better than the built-in systemd time software.  An inexpensive
>> realtime clock module also tends to help.  There are 'dozens' of posts here
>> about the importance of having accurate date+time especially on devices
>> like a pi that have no built-in RTC typically.
>>
> --
> 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/77d21fb5-8909-41bb-b782-1e3be910dc34o%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/CAPq0zEAZ-RdaBkFY7dB_C_-mX-w37DtqcdsxKtNNPTmyE9e5ig%40mail.gmail.com.

Re: [weewx-user] Suggestions on best way to upgrade to 4.1.1

[Tom Keffer]

No, it will not overwrite the existing weewx.conf file, nor the database.

Do a backup if you are concerned.

-tk

On Sun, Jun 21, 2020 at 11:03 AM Michael Form  wrote:

> Thanks again for the very rapid response.
>
> If I update using Python 2, will this overwrite the existing weewx.conf
> and database?
>
> I will look into "Adding a New Type..." to see if it is not too confusing
> to me and keep using 3.9.2.
>
> Michael
>
>
>
> On 6/21/2020 1:58 PM, Tom Keffer wrote:
>
> You can add more temperature sensors to your existing schema. Follow the
> directions in the section *Adding a new type to the database* in the copy
> of the Customizing Guide *that came with your 3.9.X version* (Version 4.x
> uses a different method).
>
> If you wish to use Python 2 on buster, use the Debian 9 (squeeze)
> instructions:
>
>
>
>
>
> *wget -qO - http://weewx.com/keys.html  | sudo
> apt-key add - wget -qO - http://weewx.com/apt/weewx-python2.list
>  | sudo tee
> /etc/apt/sources.list.d/weewx.list sudo apt-get update sudo apt-get install
> weewx *
>
> -tk
>
>
> On Sun, Jun 21, 2020 at 10:44 AM Michael Form  wrote:
>
>> Tom:
>>
>> Thank you for your response. I was aware of this issue which is the
>> reason that I asked if there was a way around it. The thread does not seem
>> to indicate a solution.
>>
>> Assuming there is a workaround, how to upgrade without losing the
>> configuration (weewx.conf) and the previous data in the database, etc.
>>
>> One of the reasons that I would like to update to 4.1.1 is the greater
>> number of temperature inputs in the schema. I have run out of temperature
>> inputs and still have four or five more to add. I assume that I can add to
>> the 3.92 database setup but I am a hardware designer and am afraid of
>> messing thing up in Linux and Python and so forth.
>>
>> If there is no solution to using owfs under Python 3, how do I install
>> 4.1.1 and specify to use Python 2?
>>
>> Thanks for your help in getting this resolved.
>>
>> Michael
>>
>> On 6/20/2020 4:58 PM, Tom Keffer wrote:
>>
>> There seems to be an issue with using owfs with Python 3 under buster.
>> See this thread:
>> https://groups.google.com/d/msg/weewx-user/ntrwrTl1xew/37u0_b7nAgAJ
>>
>> -tk
>>
>> On Fri, Jun 19, 2020 at 10:30 AM michael form 
>> wrote:
>>
>>> I have Weewx 3.92 running on a Raspberry  Pi3 using One-Wire sensors for
>>> all measurements via a USB to 1-Wire interface (DS9490). The Pi is running
>>> Buster and I installed Weewx using the Debian installation package.
>>> Everything is now working fine and I want to tempt fate by upgrading to
>>> Weewx 4.1.1 (and Python 3).
>>>
>>> What is the easiest and most reliable way to do this? Do I just install
>>> Weewx again on the same Pi using the procedure for an initial install of
>>> the Debian package? Will it keep the database and conf files or do I have
>>> to save them and put them back when done? Do I need to do anything with
>>> OWFS to work with Python 3? Should I follow the procedure in installation
>>> guide:
>>>
>>> Tell your system to trust weewx.com:
>>>
>>> wget -qO - http://weewx.com/keys.html | sudo apt-key add -
>>>
>>> For Debian10 and later, use python3:
>>>
>>> wget -qO - http://weewx.com/apt/weewx-python3.list | sudo tee 
>>> /etc/apt/sources.list.d/weewx.list
>>>
>>>
>>> Basically, how best to upgrade without losing the old data and keeping
>>> things working?
>>>
>>> Thanks for any guidance.
>>>
>>> Michael
>>> --
>>> 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/ff7326d5-d1cf-4523-b963-eb9104dc1e0fo%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/CAPq0zEAsJvWhUMzpBFPrAj6nTEh5U-bWdBX1iRo9DLJZiEF%3DwA%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/CAPq0zEDpNaybJLDrQyVhPNfm%2BxDc5huQxra_oONNDZ6CRr5%2B%3DQ%40mail.gmail.com.

Re: [weewx-user] Graphs not updating

[michael form]

I have attached a section of the syslog file. Somewhere around 3:13:54 AM 
on 20 June the system seems to have lost track of the time. If you need me 
to supply a more detailed log with debug=1, let me know.

The station type is USB using a DS9490 USB to 1-Wire interface with OWFS.

I have confirmed that the Pi has the correct date and time and that the 
database has current correct values even though the graphs/plots are not 
updating.

Questions:

1. How to get the plots to update correctly now that the system has been 
rebooted?

2. Why did the system get confused with the time? This is probably more 
difficult to answer. How to prevent this in the future, if possible?

Thanks.

Michael

On Sunday, June 21, 2020 at 3:01:59 PM UTC-4, Tom Keffer wrote:
>
> Impossible to say with the limited information you're giving us. At a 
> minimum, how about the type of station, and the log?
>
> See the Wiki article *Help! Posting to weewx-user 
> *.
>
> On Sun, Jun 21, 2020 at 11:45 AM michael form  > wrote:
>
>> I have Weewx 3.9.2 running on a Raspberry Pi 3 using the Debiam install. 
>> Until this morning, everything was working fine. When I went to look at the 
>> web page this afternoon, the system was unresponsive. This included the Pi 
>> itself. I rebooted the system and it came up OK but now the graphs on the 
>> web page are not updating, although it seems that the sensors are sending 
>> back valid data, that is the temperature readings are reasonable and the 
>> date and time are correct. However, the graphs are not updating and are 
>> stuck at around 3:00 AM this morning, which is when the system seems to 
>> have stopped. 
>>
>> I have no idea on why things got stuck, as the system has been running 
>> without a problem for over a month. The problem could be with the Pi and/or 
>> Raspbian, but that does not explain why everything rebooted and is working 
>> except the plots.
>>
>> Any ideas on where to look?
>>
>> Thanks.
>>
>> Michael
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/e2d9a7dc-0cd1-4013-a817-2d58123b16deo%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/a05202cc-820c-4f37-989d-a23cef4182eco%40googlegroups.com.


portion of syslog1
Description: Binary data

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

[Tom Keffer]

I don't blame you.

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

> Perhaps I should just give up on the WU. PWSweather takes my data just
> fine, and I'll add the NWS and a couple of others in the near
> future.
>
> David
>
> On Jun 21, 2020, at 12:18 PM, Tom Keffer  wrote:
>
> Sounds like yet another WU SNAFU.
>
> You could try disabling RapidFire and just use regular postings. RF has
> always been unreliable.
>
> -tk
>
> On Sun, Jun 21, 2020 at 12:16 PM David Barto  wrote:
>
>> Enclosing with quotes didn=E2=80=99t change anything and I logged out/in
>> from Wunderground and explicitly typed in the password. That worked.
>>
>>enable = true
>>station = KCAPOWAY177
>>password ="AlphaNumericDataH3Re"
>># Set the following to True to have weewx use the WU "Rapidfire"
>># protocol. Not all hardware can support it. See the User's Guide.
>>rapidfire = True
>>
>> Still failing. Debug is set to 1, is there anything else that could be
>> useful?
>>
>> David
>>
>> On Jun 21, 2020, at 11:42 AM, Tom Keffer  wrote:
>>
>> OK, now you have an *upload* problem, which suggests a password problem.
>> Make sure you're using the right password. Does it have any special
>> characters in it? If so, enclose with quotes in weewx.conf.
>>
>> -tk
>>
>> On Sun, Jun 21, 2020 at 11:32 AM David Barto  wrote:
>>
>>> Curl gets a 204. So my configuration ’should’ be working.
>>>
>>> password is set to the password I login with.
>>>
>>> Wunderfixer still returning a 503, so that is unusual.
>>>
>>> I’m now seeing.
>>>
>>> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload after
>>> 1 tries
>>> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload after
>>> 1 tries
>>> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload after
>>> 1 tries
>>> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload after
>>> 1 tries
>>> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload after
>>> 1 tries
>>> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload after
>>> 1 tries
>>> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload after
>>> 1 tries
>>> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload after
>>> 1 tries
>>> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload after
>>> 1 tries
>>> Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed
>>> to publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload after
>>> 1 tries
>>>
>>> And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 still
>>> reports ‘offline’.
>>>
>>> I’ve got ‘debug = 1’ in my configuration, so what else would be useful
>>> to include to finish this up?
>>>
>>> David
>>>
>>> On Jun 21, 2020, at 10:48 AM, Tom Keffer  wrote:
>>>
>>> Blank page is probably good, and hopefully means that it's accepting the
>>> API key. To be sure, try curl:
>>>
>>> curl -i '
>>> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>> '
>>>
>>>
>>> where, again, X is your API key. This will give you the returned
>>> status code. I would expect 204.
>>>
>>> NB: the API key is necessary to *download* data, the password is
>>> necessary to *upload* data. So, you want the API key.
>>>
>>> -tk
>>>
>>> On Sun, Jun 21, 2020 at 9:48 AM David Barto  wrote:
>>>
 Weird, when presented my very long API key I get back a blank page.
 I’ll assume that is good. When I give it the short key I get back

 {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
 apiKey."}}]}

 What debugging do I need to turn on (and where to look on the Mac) to
 see the URL being sent when I’m using wunderfixer to see what it is 
 sending?

 David


 On Jun 21, 2020, at 9:25 AM, Tom Keffer  wrote:

 Odds are it's a WU thing.

 If you're comfortable manipulating URLs, you can try a GET request
 directly. Use the URL


 https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X


 where X is your API key. Sometimes this will give you additional
 detail.

 Interestingly, when I try the 

[weewx-user] Re: No solar reading from Davis Vantage Pro2

[peter]

Thanks, vince,
I will install it and see if it works better. I assume the issue is in the 
correct date? Why then only for a solar reading?
The issue only happens on this setup but not on other 2 I own, that's why 
I'm surprised.


Dne nedelja, 21. junij 2020 22.18.50 UTC+2 je oseba vince napisala:
>
> I'd start by ensuring the pi has quality time.  Generally running NTP 
> works better than the built-in systemd time software.  An inexpensive 
> realtime clock module also tends to help.  There are 'dozens' of posts here 
> about the importance of having accurate date+time especially on devices 
> like a pi that have no built-in RTC typically.
>

-- 
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/77d21fb5-8909-41bb-b782-1e3be910dc34o%40googlegroups.com.

Re: [weewx-user] Graphs not updating

[Tom Keffer]

1. Just delete the plots. They will all get regenerated.

2. You had the classic "no clock" symptoms: when the reboot happened, the
system started with the last time it had saved, which was hours old. This
always causes unpredictable results. See the wiki article *Raspberry Pi
*.

It's well worth spending the $5 and installing a realtime clock.

-tk

On Sun, Jun 21, 2020 at 12:42 PM michael form  wrote:

> I have attached a section of the syslog file. Somewhere around 3:13:54 AM
> on 20 June the system seems to have lost track of the time. If you need me
> to supply a more detailed log with debug=1, let me know.
>
> The station type is USB using a DS9490 USB to 1-Wire interface with OWFS.
>
> I have confirmed that the Pi has the correct date and time and that the
> database has current correct values even though the graphs/plots are not
> updating.
>
> Questions:
>
> 1. How to get the plots to update correctly now that the system has been
> rebooted?
>
> 2. Why did the system get confused with the time? This is probably more
> difficult to answer. How to prevent this in the future, if possible?
>
> Thanks.
>
> Michael
>
> On Sunday, June 21, 2020 at 3:01:59 PM UTC-4, Tom Keffer wrote:
>>
>> Impossible to say with the limited information you're giving us. At a
>> minimum, how about the type of station, and the log?
>>
>> See the Wiki article *Help! Posting to weewx-user
>> *.
>>
>> On Sun, Jun 21, 2020 at 11:45 AM michael form  wrote:
>>
>>> I have Weewx 3.9.2 running on a Raspberry Pi 3 using the Debiam install.
>>> Until this morning, everything was working fine. When I went to look at the
>>> web page this afternoon, the system was unresponsive. This included the Pi
>>> itself. I rebooted the system and it came up OK but now the graphs on the
>>> web page are not updating, although it seems that the sensors are sending
>>> back valid data, that is the temperature readings are reasonable and the
>>> date and time are correct. However, the graphs are not updating and are
>>> stuck at around 3:00 AM this morning, which is when the system seems to
>>> have stopped.
>>>
>>> I have no idea on why things got stuck, as the system has been running
>>> without a problem for over a month. The problem could be with the Pi and/or
>>> Raspbian, but that does not explain why everything rebooted and is working
>>> except the plots.
>>>
>>> Any ideas on where to look?
>>>
>>> Thanks.
>>>
>>> Michael
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/e2d9a7dc-0cd1-4013-a817-2d58123b16deo%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/a05202cc-820c-4f37-989d-a23cef4182eco%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/CAPq0zEBgs8yTP%3DaOiTqZbBQR4qk_b9VpaTD%2Bw7JX4mEP0LpuHA%40mail.gmail.com.

Re: [weewx-user] Re: No solar reading from Davis Vantage Pro2

[peter]

 
>
> Is a value for solar radiation appearing on the console?
>
> I don't know, sorry. The setup is located at a remote location. I'll try 
and find out once it happens again.

If you run weewxd directly from the command line, does it show a value for 
> radiation?
>

I haven't tried this yet. I guess the run command is provided with 
instructions but if you could just post the command, that would help.

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/7a3d85f5-5899-486d-92ed-591df7b0c275o%40googlegroups.com.

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

[Tom Keffer]

Odds are it's a WU thing.

If you're comfortable manipulating URLs, you can try a GET request
directly. Use the URL

https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X


where X is your API key. Sometimes this will give you additional detail.

Interestingly, when I try the above with my own API key, I get a 204 ("No
Content") error, not a 403.

-tk



On Sun, Jun 21, 2020 at 8:58 AM David Barto  wrote:

> The key, password, and API all match with the station name.
>
> When I look at the station under
> https://www.wunderground.com/member/devices -> My Devices, it shows
> Offline.
>
> I’m assuming that is because I’m not sending data rather than some other
> step in the setup process that I’m not able to discern. Web searches don’t
> show any registration steps that I’ve missed.
>
> Is it just a WU thing, or am I really just missing something obvious?
>
> David
>
> On Jun 20, 2020, at 5:59 PM, Tom Keffer  wrote:
>
> Normally, if you give the wrong API key, you get a 401 error. You are
> getting a 403 error, which implies that the key may be right, but you do
> not have authorization to access the data. Are you sure you have the right
> station?
>
> Also, double check the API key. You can find it here
> . Does it match what you
> have in weewx.conf?
>
> -tk
>
> On Sat, Jun 20, 2020 at 5:39 PM David Barto  wrote:
>
>> I’ve got a new Station KCAPOWAY177
>>
>> I’ve got an API key  and a ‘key’ <8 alpha numeric key>
>> and my password to log into the site.
>>
>> No matter which of the 3 I choose for my password, the response to
>> wunderfixer is always the same.
>>
>> $ ./bin/wunderfixer --test --config=$(pwd)/weewx.conf
>> --station=KCAPOWAY177 —password= --verbose
>> Using configuration file /Users/Shared/weewx/weewx.conf.
>> Using database binding 'wx_binding', which is bound to database
>> 'archive_sqlite'
>> Weather Underground Station:   KCAPOWAY177
>> Date to check: 2020-06-20
>> Number of archive records: 1055
>> Unable to open Weather Underground station KCAPOWAY177  or  HTTP Error
>> 403: Forbidden
>> Could not get Weather Underground data. Exiting.
>>
>>
>> Any idea of where to go now?
>>
>> David
>>
>>
>> --
>> 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/4DA82895-538B-4EC3-9D85-4E148E4CFB29%40kdbarto.org
>> 
>> .
>>
>
> --
> 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/CAPq0zEAE940H%3DAuHD30LC_Zx2oC1Myv041LbRGGv5hVshaxWQg%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/ECC4C459-B688-49DD-B5E0-63EF36ED6DC6%40kdbarto.org
> 
> .
>

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

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

[Tom Keffer]

Blank page is probably good, and hopefully means that it's accepting the
API key. To be sure, try curl:

curl -i '
https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
'


where, again, X is your API key. This will give you the returned status
code. I would expect 204.

NB: the API key is necessary to *download* data, the password is necessary
to *upload* data. So, you want the API key.

-tk

On Sun, Jun 21, 2020 at 9:48 AM David Barto  wrote:

> Weird, when presented my very long API key I get back a blank page. I’ll
> assume that is good. When I give it the short key I get back
>
> {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
> apiKey."}}]}
>
> What debugging do I need to turn on (and where to look on the Mac) to see
> the URL being sent when I’m using wunderfixer to see what it is sending?
>
> David
>
>
> On Jun 21, 2020, at 9:25 AM, Tom Keffer  wrote:
>
> Odds are it's a WU thing.
>
> If you're comfortable manipulating URLs, you can try a GET request
> directly. Use the URL
>
>
> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>
>
> where X is your API key. Sometimes this will give you additional
> detail.
>
> Interestingly, when I try the above with my own API key, I get a 204 ("No
> Content") error, not a 403.
>
> -tk
>
>
>
> On Sun, Jun 21, 2020 at 8:58 AM David Barto  wrote:
>
>> The key, password, and API all match with the station name.
>>
>> When I look at the station under
>> https://www.wunderground.com/member/devices -> My Devices, it shows
>> Offline.
>>
>> I’m assuming that is because I’m not sending data rather than some other
>> step in the setup process that I’m not able to discern. Web searches don’t
>> show any registration steps that I’ve missed.
>>
>> Is it just a WU thing, or am I really just missing something obvious?
>>
>> David
>>
>> On Jun 20, 2020, at 5:59 PM, Tom Keffer  wrote:
>>
>> Normally, if you give the wrong API key, you get a 401 error. You are
>> getting a 403 error, which implies that the key may be right, but you do
>> not have authorization to access the data. Are you sure you have the right
>> station?
>>
>> Also, double check the API key. You can find it here
>> . Does it match what you
>> have in weewx.conf?
>>
>> -tk
>>
>> On Sat, Jun 20, 2020 at 5:39 PM David Barto  wrote:
>>
>>> I’ve got a new Station KCAPOWAY177
>>>
>>> I’ve got an API key  and a ‘key’ <8 alpha numeric key>
>>> and my password to log into the site.
>>>
>>> No matter which of the 3 I choose for my password, the response to
>>> wunderfixer is always the same.
>>>
>>> $ ./bin/wunderfixer --test --config=$(pwd)/weewx.conf
>>> --station=KCAPOWAY177 —password= --verbose
>>> Using configuration file /Users/Shared/weewx/weewx.conf.
>>> Using database binding 'wx_binding', which is bound to database
>>> 'archive_sqlite'
>>> Weather Underground Station:   KCAPOWAY177
>>> Date to check: 2020-06-20
>>> Number of archive records: 1055
>>> Unable to open Weather Underground station KCAPOWAY177  or  HTTP Error
>>> 403: Forbidden
>>> Could not get Weather Underground data. Exiting.
>>>
>>>
>>> Any idea of where to go now?
>>>
>>> David
>>>
>>>
>>> --
>>> 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/4DA82895-538B-4EC3-9D85-4E148E4CFB29%40kdbarto.org
>>> 
>>> .
>>>
>>
>> --
>> 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/CAPq0zEAE940H%3DAuHD30LC_Zx2oC1Myv041LbRGGv5hVshaxWQg%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/ECC4C459-B688-49DD-B5E0-63EF36ED6DC6%40kdbarto.org
>> 
>> .
>>
>
> --
> You received this message because you are 

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

[David Barto]

Curl gets a 204. So my configuration ’should’ be working.

password is set to the password I login with.

Wunderfixer still returning a 503, so that is unusual.

I’m now seeing.

Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload after 1 tries
Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload after 1 tries
Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload after 1 tries
Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload after 1 tries
Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload after 1 tries
Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload after 1 tries
Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload after 1 tries
Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload after 1 tries
Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload after 1 tries
Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload after 1 tries

And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 
 still reports 
‘offline’.

I’ve got ‘debug = 1’ in my configuration, so what else would be useful to 
include to finish this up?

David

> On Jun 21, 2020, at 10:48 AM, Tom Keffer  wrote:
> 
> Blank page is probably good, and hopefully means that it's accepting the API 
> key. To be sure, try curl:
> 
> curl -i 
> 'https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>  
> '
> 
> where, again, X is your API key. This will give you the returned status 
> code. I would expect 204.
> 
> NB: the API key is necessary to download data, the password is necessary to 
> upload data. So, you want the API key. 
> 
> -tk
> 
> On Sun, Jun 21, 2020 at 9:48 AM David Barto  > wrote:
> Weird, when presented my very long API key I get back a blank page. I’ll 
> assume that is good. When I give it the short key I get back
> 
>   
> {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
>  apiKey."}}]}
> 
> What debugging do I need to turn on (and where to look on the Mac) to see the 
> URL being sent when I’m using wunderfixer to see what it is sending?
> 
>   David
> 
> 
>> On Jun 21, 2020, at 9:25 AM, Tom Keffer > > wrote:
>> 
>> Odds are it's a WU thing. 
>> 
>> If you're comfortable manipulating URLs, you can try a GET request directly. 
>> Use the URL
>> 
>> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>  
>> 
>> 
>> where X is your API key. Sometimes this will give you additional detail.
>> 
>> Interestingly, when I try the above with my own API key, I get a 204 ("No 
>> Content") error, not a 403.
>> 
>> -tk
>> 
>> 
>> 
>> On Sun, Jun 21, 2020 at 8:58 AM David Barto > > wrote:
>> The key, password, and API all match with the station name.
>> 
>> When I look at the station under https://www.wunderground.com/member/devices 
>>  -> My Devices, it shows 
>> Offline.
>> 
>> I’m assuming that is because I’m not sending data rather than some other 
>> step in the setup process that I’m not able to discern. Web searches don’t 
>> show any registration steps that I’ve missed.
>> 
>> Is it just a WU thing, or am I really just missing something obvious?
>> 
>>  David
>> 
>>> On Jun 20, 2020, at 5:59 PM, Tom Keffer >> > wrote:
>>> 
>>> Normally, if you give the wrong API key, you get a 401 error. You are 
>>> getting a 403 error, which implies that the key may be right, but you do 
>>> not have authorization to access the data. Are you sure you have the right 
>>> station?
>>> 
>>> Also, double check the API key. You can find it here 
>>> . Does it match what you have 
>>> in weewx.conf?
>>> 
>>> -tk
>>> 
>>> On Sat, Jun 20, 2020 at 5:39 PM David Barto >> 

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

[David Barto]

Perhaps I should just give up on the WU. PWSweather takes my data just
fine, and I'll add the NWS and a couple of others in the near
future.

David

> On Jun 21, 2020, at 12:18 PM, Tom Keffer  wrote:
> 
> Sounds like yet another WU SNAFU. 
> 
> You could try disabling RapidFire and just use regular postings. RF has 
> always been unreliable.
> 
> -tk
> 
> On Sun, Jun 21, 2020 at 12:16 PM David Barto  > wrote:
> Enclosing with quotes didn=E2=80=99t change anything and I logged out/in
> from Wunderground and explicitly typed in the password. That worked.
> 
>enable = true
>station = KCAPOWAY177
>password ="AlphaNumericDataH3Re"
># Set the following to True to have weewx use the WU "Rapidfire"
># protocol. Not all hardware can support it. See the User's Guide.
>rapidfire = True
> 
> Still failing. Debug is set to 1, is there anything else that could be
> useful?
> 
>   David
> 
>> On Jun 21, 2020, at 11:42 AM, Tom Keffer > > wrote:
>> 
>> OK, now you have an upload problem, which suggests a password problem. Make 
>> sure you're using the right password. Does it have any special characters in 
>> it? If so, enclose with quotes in weewx.conf.
>> 
>> -tk
>> 
>> On Sun, Jun 21, 2020 at 11:32 AM David Barto > > wrote:
>> Curl gets a 204. So my configuration ’should’ be working.
>> 
>> password is set to the password I login with.
>> 
>> Wunderfixer still returning a 503, so that is unusual.
>> 
>> I’m now seeing.
>> 
>> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload after 1 
>> tries
>> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload after 1 
>> tries
>> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload after 1 
>> tries
>> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload after 1 
>> tries
>> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload after 1 
>> tries
>> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload after 1 
>> tries
>> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload after 1 
>> tries
>> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload after 1 
>> tries
>> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload after 1 
>> tries
>> Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
>> publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload after 1 
>> tries
>> 
>> And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 
>>  still reports 
>> ‘offline’.
>> 
>> I’ve got ‘debug = 1’ in my configuration, so what else would be useful to 
>> include to finish this up?
>> 
>>  David
>> 
>>> On Jun 21, 2020, at 10:48 AM, Tom Keffer >> > wrote:
>>> 
>>> Blank page is probably good, and hopefully means that it's accepting the 
>>> API key. To be sure, try curl:
>>> 
>>> curl -i 
>>> 'https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>>  
>>> '
>>> 
>>> where, again, X is your API key. This will give you the returned status 
>>> code. I would expect 204.
>>> 
>>> NB: the API key is necessary to download data, the password is necessary to 
>>> upload data. So, you want the API key. 
>>> 
>>> -tk
>>> 
>>> On Sun, Jun 21, 2020 at 9:48 AM David Barto >> > wrote:
>>> Weird, when presented my very long API key I get back a blank page. I’ll 
>>> assume that is good. When I give it the short key I get back
>>> 
>>> 
>>> {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
>>>  apiKey."}}]}
>>> 
>>> What debugging do I need to turn on (and where to look on the Mac) to see 
>>> the URL being sent when I’m using wunderfixer to see what it is sending?
>>> 
>>> David
>>> 
>>> 
 On Jun 21, 2020, at 9:25 AM, Tom Keffer >>> > wrote:
 
 Odds are it's a WU thing. 
 
 If you're comfortable manipulating URLs, you can try a GET request 
 directly. Use the 

Re: [weewx-user] Re: No solar reading from Davis Vantage Pro2

[Tom Keffer]

See the section *Running directly
* in the User's
Guide. Be sure to stop weewx first.

On Sun, Jun 21, 2020 at 1:55 PM peter  wrote:

>
>>
>> Is a value for solar radiation appearing on the console?
>>
>> I don't know, sorry. The setup is located at a remote location. I'll try
> and find out once it happens again.
>
> If you run weewxd directly from the command line, does it show a value for
>> radiation?
>>
>
> I haven't tried this yet. I guess the run command is provided with
> instructions but if you could just post the command, that would help.
>
> 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/7a3d85f5-5899-486d-92ed-591df7b0c275o%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/CAPq0zEB%2BDGDoA5hVXdyqL3HJXM5a8kOK_FkMNT6ACxfWWxNp%3Dg%40mail.gmail.com.

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

[Tom Keffer]

Sounds like yet another WU SNAFU.

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

-tk

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

> Enclosing with quotes didn=E2=80=99t change anything and I logged out/in
> from Wunderground and explicitly typed in the password. That worked.
>
>enable = true
>station = KCAPOWAY177
>password ="AlphaNumericDataH3Re"
># Set the following to True to have weewx use the WU "Rapidfire"
># protocol. Not all hardware can support it. See the User's Guide.
>rapidfire = True
>
> Still failing. Debug is set to 1, is there anything else that could be
> useful?
>
> David
>
> On Jun 21, 2020, at 11:42 AM, Tom Keffer  wrote:
>
> OK, now you have an *upload* problem, which suggests a password problem.
> Make sure you're using the right password. Does it have any special
> characters in it? If so, enclose with quotes in weewx.conf.
>
> -tk
>
> On Sun, Jun 21, 2020 at 11:32 AM David Barto  wrote:
>
>> Curl gets a 204. So my configuration ’should’ be working.
>>
>> password is set to the password I login with.
>>
>> Wunderfixer still returning a 503, so that is unusual.
>>
>> I’m now seeing.
>>
>> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload after 1
>> tries
>> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload after 1
>> tries
>> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload after 1
>> tries
>> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload after 1
>> tries
>> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload after 1
>> tries
>> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload after 1
>> tries
>> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload after 1
>> tries
>> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload after 1
>> tries
>> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload after 1
>> tries
>> Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
>> publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload after 1
>> tries
>>
>> And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 still reports
>> ‘offline’.
>>
>> I’ve got ‘debug = 1’ in my configuration, so what else would be useful to
>> include to finish this up?
>>
>> David
>>
>> On Jun 21, 2020, at 10:48 AM, Tom Keffer  wrote:
>>
>> Blank page is probably good, and hopefully means that it's accepting the
>> API key. To be sure, try curl:
>>
>> curl -i '
>> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>> '
>>
>>
>> where, again, X is your API key. This will give you the returned
>> status code. I would expect 204.
>>
>> NB: the API key is necessary to *download* data, the password is
>> necessary to *upload* data. So, you want the API key.
>>
>> -tk
>>
>> On Sun, Jun 21, 2020 at 9:48 AM David Barto  wrote:
>>
>>> Weird, when presented my very long API key I get back a blank page. I’ll
>>> assume that is good. When I give it the short key I get back
>>>
>>> {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
>>> apiKey."}}]}
>>>
>>> What debugging do I need to turn on (and where to look on the Mac) to
>>> see the URL being sent when I’m using wunderfixer to see what it is sending?
>>>
>>> David
>>>
>>>
>>> On Jun 21, 2020, at 9:25 AM, Tom Keffer  wrote:
>>>
>>> Odds are it's a WU thing.
>>>
>>> If you're comfortable manipulating URLs, you can try a GET request
>>> directly. Use the URL
>>>
>>>
>>> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>>
>>>
>>> where X is your API key. Sometimes this will give you additional
>>> detail.
>>>
>>> Interestingly, when I try the above with my own API key, I get a 204
>>> ("No Content") error, not a 403.
>>>
>>> -tk
>>>
>>>
>>>
>>> On Sun, Jun 21, 2020 at 8:58 AM David Barto  wrote:
>>>
 The key, password, and API all match with the station name.

 When I look at the station under
 https://www.wunderground.com/member/devices -> My Devices, it shows
 Offline.

 I’m assuming that is because I’m not sending data rather than 

[weewx-user] No solar reading from Davis Vantage Pro2

[peter]

Hi,
I've searched through this forum and found a similar issue but still 
slightly different.
I have a RPi 3B+ connected to a USB data logger in the DVP2 console with 
original USB cable. The setup has been working fine for about 6-7 months 
with similar uptime. Then the solar reading showed N/A. This has been going 
on for some days until I rebooted the RPi. After a reboot, the solar value 
was read OK for the next one or two days. After few such interventions, I 
need to do one or more reboots to get it working OK.
I've checked the syslog, here is an excerpt:

> Jun 21 00:01:16 raspberrypi weewx[449]: vantage: Getting archive packets 
> since 2020-06-21 00:00:00 CEST (1592690400)
> Jun 21 00:01:16 raspberrypi weewx[449]: vantage: Gentle wake up of console 
> successful
> Jun 21 00:01:16 raspberrypi weewx[449]: vantage: Retrieving 1 page(s); 
> starting index= 3
> Jun 21 00:01:16 raspberrypi weewx[449]: manager: Added record 2020-06-21 
> 00:01:00 CEST (1592690460) to database 'weewx.sdb'
> Jun 21 00:01:16 raspberrypi weewx[449]: manager: Added record 2020-06-21 
> 00:01:00 CEST (1592690460) to daily summary in 'weewx.sdb'
> Jun 21 00:01:16 raspberrypi weewx[449]: vantage: DMPAFT complete: page 
> timestamp 2020-06-19 05:22:00 CEST (1592536920) less than final timestamp 
> 2020-06-21 00:01:00 CEST (1592690460)
> Jun 21 00:01:16 raspberrypi weewx[449]: vantage: Catch up complete.
> Jun 21 00:01:16 raspberrypi weewx[449]: reportengine: Running reports for 
> latest time in the database.
> Jun 21 00:01:16 raspberrypi weewx[449]: vantage: Requesting 200 LOOP 
> packets.
>
> I suspect the issue is related to DMPAFT row.

Any hint what may be causing this? I am confused why the setup worked OK 
for a long time before.
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/e9664d07-a06b-4528-a1a6-962513ded6dao%40googlegroups.com.

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

[David Barto]

The key, password, and API all match with the station name.

When I look at the station under https://www.wunderground.com/member/devices 
 -> My Devices, it shows Offline.

I’m assuming that is because I’m not sending data rather than some other step 
in the setup process that I’m not able to discern. Web searches don’t show any 
registration steps that I’ve missed.

Is it just a WU thing, or am I really just missing something obvious?

David

> On Jun 20, 2020, at 5:59 PM, Tom Keffer  wrote:
> 
> Normally, if you give the wrong API key, you get a 401 error. You are getting 
> a 403 error, which implies that the key may be right, but you do not have 
> authorization to access the data. Are you sure you have the right station?
> 
> Also, double check the API key. You can find it here 
> . Does it match what you have 
> in weewx.conf?
> 
> -tk
> 
> On Sat, Jun 20, 2020 at 5:39 PM David Barto  > wrote:
> I’ve got a new Station KCAPOWAY177
> 
> I’ve got an API key  and a ‘key’ <8 alpha numeric key> and 
> my password to log into the site.
> 
> No matter which of the 3 I choose for my password, the response to 
> wunderfixer is always the same.
> 
> $ ./bin/wunderfixer --test --config=$(pwd)/weewx.conf --station=KCAPOWAY177 
> —password= --verbose
> Using configuration file /Users/Shared/weewx/weewx.conf.
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> Weather Underground Station:   KCAPOWAY177
> Date to check: 2020-06-20
> Number of archive records: 1055
> Unable to open Weather Underground station KCAPOWAY177  or  HTTP Error 403: 
> Forbidden
> Could not get Weather Underground data. Exiting.
> 
> 
> Any idea of where to go now?
> 
>   David
> 
> 
> -- 
> 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/4DA82895-538B-4EC3-9D85-4E148E4CFB29%40kdbarto.org
>  
> .
> 
> -- 
> 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/CAPq0zEAE940H%3DAuHD30LC_Zx2oC1Myv041LbRGGv5hVshaxWQg%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/ECC4C459-B688-49DD-B5E0-63EF36ED6DC6%40kdbarto.org.

[weewx-user] Retroactively calculate database fields

[Manfred Maier]

Hi,
I've added new fields to the database (e.g. sunshineTime) and I'm 
populating them with an adapted version of the radiationhours.py extension. 

Is there a way to also populate those fields for data records of past times?
I've tried "wee_database --calc-missing", but had no success.

Ideas and hints highly appreciated!

Thanks!
Manfred 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/33b40c35-9e2b-4cf1-85c3-af035c82ff94n%40googlegroups.com.

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

[David Barto]

Following up to myself, the entry for WU in the weewx.conf file looks like the 
following

enable = true
station = KCAPOWAY177
apiKey = "Very long API key from the WU”
# password = "login password”
rapid-fire = true

David

> On Jun 21, 2020, at 9:48 AM, David Barto  wrote:
> 
> Weird, when presented my very long API key I get back a blank page. I’ll 
> assume that is good. When I give it the short key I get back
> 
>   
> {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
>  apiKey."}}]}
> 
> What debugging do I need to turn on (and where to look on the Mac) to see the 
> URL being sent when I’m using wunderfixer to see what it is sending?
> 
>   David
> 
> 
>> On Jun 21, 2020, at 9:25 AM, Tom Keffer > > wrote:
>> 
>> Odds are it's a WU thing. 
>> 
>> If you're comfortable manipulating URLs, you can try a GET request directly. 
>> Use the URL
>> 
>> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>  
>> 
>> 
>> where X is your API key. Sometimes this will give you additional detail.
>> 
>> Interestingly, when I try the above with my own API key, I get a 204 ("No 
>> Content") error, not a 403.
>> 
>> -tk
>> 
>> 
>> 
>> On Sun, Jun 21, 2020 at 8:58 AM David Barto > > wrote:
>> The key, password, and API all match with the station name.
>> 
>> When I look at the station under https://www.wunderground.com/member/devices 
>>  -> My Devices, it shows 
>> Offline.
>> 
>> I’m assuming that is because I’m not sending data rather than some other 
>> step in the setup process that I’m not able to discern. Web searches don’t 
>> show any registration steps that I’ve missed.
>> 
>> Is it just a WU thing, or am I really just missing something obvious?
>> 
>>  David
>> 
>>> On Jun 20, 2020, at 5:59 PM, Tom Keffer >> > wrote:
>>> 
>>> Normally, if you give the wrong API key, you get a 401 error. You are 
>>> getting a 403 error, which implies that the key may be right, but you do 
>>> not have authorization to access the data. Are you sure you have the right 
>>> station?
>>> 
>>> Also, double check the API key. You can find it here 
>>> . Does it match what you have 
>>> in weewx.conf?
>>> 
>>> -tk
>>> 
>>> On Sat, Jun 20, 2020 at 5:39 PM David Barto >> > wrote:
>>> I’ve got a new Station KCAPOWAY177
>>> 
>>> I’ve got an API key  and a ‘key’ <8 alpha numeric key> 
>>> and my password to log into the site.
>>> 
>>> No matter which of the 3 I choose for my password, the response to 
>>> wunderfixer is always the same.
>>> 
>>> $ ./bin/wunderfixer --test --config=$(pwd)/weewx.conf --station=KCAPOWAY177 
>>> —password= --verbose
>>> Using configuration file /Users/Shared/weewx/weewx.conf.
>>> Using database binding 'wx_binding', which is bound to database 
>>> 'archive_sqlite'
>>> Weather Underground Station:   KCAPOWAY177
>>> Date to check: 2020-06-20
>>> Number of archive records: 1055
>>> Unable to open Weather Underground station KCAPOWAY177  or  HTTP Error 403: 
>>> Forbidden
>>> Could not get Weather Underground data. Exiting.
>>> 
>>> 
>>> Any idea of where to go now?
>>> 
>>> David
>>> 
>>> 
>>> -- 
>>> 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/4DA82895-538B-4EC3-9D85-4E148E4CFB29%40kdbarto.org
>>>  
>>> .
>>> 
>>> -- 
>>> 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/CAPq0zEAE940H%3DAuHD30LC_Zx2oC1Myv041LbRGGv5hVshaxWQg%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 
>> 

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

[Tom Keffer]

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

-tk

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

> Curl gets a 204. So my configuration ’should’ be working.
>
> password is set to the password I login with.
>
> Wunderfixer still returning a 503, so that is unusual.
>
> I’m now seeing.
>
> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload after 1
> tries
> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload after 1
> tries
> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload after 1
> tries
> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload after 1
> tries
> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload after 1
> tries
> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload after 1
> tries
> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload after 1
> tries
> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload after 1
> tries
> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload after 1
> tries
> Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to
> publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload after 1
> tries
>
> And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 still reports
> ‘offline’.
>
> I’ve got ‘debug = 1’ in my configuration, so what else would be useful to
> include to finish this up?
>
> David
>
> On Jun 21, 2020, at 10:48 AM, Tom Keffer  wrote:
>
> Blank page is probably good, and hopefully means that it's accepting the
> API key. To be sure, try curl:
>
> curl -i '
> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
> '
>
>
> where, again, X is your API key. This will give you the returned
> status code. I would expect 204.
>
> NB: the API key is necessary to *download* data, the password is
> necessary to *upload* data. So, you want the API key.
>
> -tk
>
> On Sun, Jun 21, 2020 at 9:48 AM David Barto  wrote:
>
>> Weird, when presented my very long API key I get back a blank page. I’ll
>> assume that is good. When I give it the short key I get back
>>
>> {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
>> apiKey."}}]}
>>
>> What debugging do I need to turn on (and where to look on the Mac) to see
>> the URL being sent when I’m using wunderfixer to see what it is sending?
>>
>> David
>>
>>
>> On Jun 21, 2020, at 9:25 AM, Tom Keffer  wrote:
>>
>> Odds are it's a WU thing.
>>
>> If you're comfortable manipulating URLs, you can try a GET request
>> directly. Use the URL
>>
>>
>> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>
>>
>> where X is your API key. Sometimes this will give you additional
>> detail.
>>
>> Interestingly, when I try the above with my own API key, I get a 204 ("No
>> Content") error, not a 403.
>>
>> -tk
>>
>>
>>
>> On Sun, Jun 21, 2020 at 8:58 AM David Barto  wrote:
>>
>>> The key, password, and API all match with the station name.
>>>
>>> When I look at the station under
>>> https://www.wunderground.com/member/devices -> My Devices, it shows
>>> Offline.
>>>
>>> I’m assuming that is because I’m not sending data rather than some other
>>> step in the setup process that I’m not able to discern. Web searches don’t
>>> show any registration steps that I’ve missed.
>>>
>>> Is it just a WU thing, or am I really just missing something obvious?
>>>
>>> David
>>>
>>> On Jun 20, 2020, at 5:59 PM, Tom Keffer  wrote:
>>>
>>> Normally, if you give the wrong API key, you get a 401 error. You are
>>> getting a 403 error, which implies that the key may be right, but you do
>>> not have authorization to access the data. Are you sure you have the right
>>> station?
>>>
>>> Also, double check the API key. You can find it here
>>> . Does it match what you
>>> have in weewx.conf?
>>>
>>> -tk
>>>
>>> On Sat, Jun 20, 2020 at 5:39 PM David Barto  wrote:
>>>
 I’ve got a new Station KCAPOWAY177

 I’ve got an API key  and a ‘key’ <8 alpha numeric
 key> and 

[weewx-user] Graphs not updating

[michael form]

I have Weewx 3.9.2 running on a Raspberry Pi 3 using the Debiam install. 
Until this morning, everything was working fine. When I went to look at the 
web page this afternoon, the system was unresponsive. This included the Pi 
itself. I rebooted the system and it came up OK but now the graphs on the 
web page are not updating, although it seems that the sensors are sending 
back valid data, that is the temperature readings are reasonable and the 
date and time are correct. However, the graphs are not updating and are 
stuck at around 3:00 AM this morning, which is when the system seems to 
have stopped. 

I have no idea on why things got stuck, as the system has been running 
without a problem for over a month. The problem could be with the Pi and/or 
Raspbian, but that does not explain why everything rebooted and is working 
except the plots.

Any ideas on where to look?

Thanks.

Michael


-- 
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/e2d9a7dc-0cd1-4013-a817-2d58123b16deo%40googlegroups.com.

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

[David Barto]

Enclosing with quotes didn=E2=80=99t change anything and I logged out/in
from Wunderground and explicitly typed in the password. That worked.

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

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

David

> On Jun 21, 2020, at 11:42 AM, Tom Keffer  wrote:
> 
> OK, now you have an upload problem, which suggests a password problem. Make 
> sure you're using the right password. Does it have any special characters in 
> it? If so, enclose with quotes in weewx.conf.
> 
> -tk
> 
> On Sun, Jun 21, 2020 at 11:32 AM David Barto  > wrote:
> Curl gets a 204. So my configuration ’should’ be working.
> 
> password is set to the password I login with.
> 
> Wunderfixer still returning a 503, so that is unusual.
> 
> I’m now seeing.
> 
> Jun 21 11:26:19 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:15 PDT (1592763975): Failed upload after 1 
> tries
> Jun 21 11:26:24 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:19 PDT (1592763979): Failed upload after 1 
> tries
> Jun 21 11:26:30 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:25 PDT (1592763985): Failed upload after 1 
> tries
> Jun 21 11:26:35 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:29 PDT (1592763989): Failed upload after 1 
> tries
> Jun 21 11:26:40 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:35 PDT (1592763995): Failed upload after 1 
> tries
> Jun 21 11:26:45 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:39 PDT (1592763999): Failed upload after 1 
> tries
> Jun 21 11:26:50 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:45 PDT (1592764005): Failed upload after 1 
> tries
> Jun 21 11:26:55 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:49 PDT (1592764009): Failed upload after 1 
> tries
> Jun 21 11:27:00 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:26:55 PDT (1592764015): Failed upload after 1 
> tries
> Jun 21 11:27:05 Magrathea weewx[23591]: restx: Wunderground-RF: Failed to 
> publish record 2020-06-21 11:27:01 PDT (1592764021): Failed upload after 1 
> tries
> 
> And https://www.wunderground.com/dashboard/pws/KCAPOWAY177 
>  still reports 
> ‘offline’.
> 
> I’ve got ‘debug = 1’ in my configuration, so what else would be useful to 
> include to finish this up?
> 
>   David
> 
>> On Jun 21, 2020, at 10:48 AM, Tom Keffer > > wrote:
>> 
>> Blank page is probably good, and hopefully means that it's accepting the API 
>> key. To be sure, try curl:
>> 
>> curl -i 
>> 'https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>  
>> '
>> 
>> where, again, X is your API key. This will give you the returned status 
>> code. I would expect 204.
>> 
>> NB: the API key is necessary to download data, the password is necessary to 
>> upload data. So, you want the API key. 
>> 
>> -tk
>> 
>> On Sun, Jun 21, 2020 at 9:48 AM David Barto > > wrote:
>> Weird, when presented my very long API key I get back a blank page. I’ll 
>> assume that is good. When I give it the short key I get back
>> 
>>  
>> {"metadata":{"transaction_id":"##"},"success":false,"errors":[{"error":{"code":"CDN-0001","message":"Invalid
>>  apiKey."}}]}
>> 
>> What debugging do I need to turn on (and where to look on the Mac) to see 
>> the URL being sent when I’m using wunderfixer to see what it is sending?
>> 
>>  David
>> 
>> 
>>> On Jun 21, 2020, at 9:25 AM, Tom Keffer >> > wrote:
>>> 
>>> Odds are it's a WU thing. 
>>> 
>>> If you're comfortable manipulating URLs, you can try a GET request 
>>> directly. Use the URL
>>> 
>>> https://api.weather.com/v2/pws/observations/all/1day?stationId=KCAPOWAY177=json=m=X
>>>  
>>> 
>>> 
>>> where X is your API key. Sometimes this will give you additional detail.
>>> 
>>> Interestingly, when I try the above with my own API key, I get a 204 ("No 
>>> Content") error, not a 403.
>>> 
>>> -tk
>>> 
>>> 
>>> 
>>> On Sun, Jun 21, 2020 at 8:58 AM David Barto >> > wrote:
>>> The key, password, and API all match with the station name.
>>> 
>>> When I 

Re: [weewx-user] Suggestions on best way to upgrade to 4.1.1

[Michael Form]

Tom:

Thank you for your response. I was aware of this issue which is the 
reason that I asked if there was a way around it. The thread does not 
seem to indicate a solution.


Assuming there is a workaround, how to upgrade without losing the 
configuration (weewx.conf) and the previous data in the database, etc.


One of the reasons that I would like to update to 4.1.1 is the greater 
number of temperature inputs in the schema. I have run out of 
temperature inputs and still have four or five more to add. I assume 
that I can add to the 3.92 database setup but I am a hardware designer 
and am afraid of messing thing up in Linux and Python and so forth.


If there is no solution to using owfs under Python 3, how do I install 
4.1.1 and specify to use Python 2?


Thanks for your help in getting this resolved.

Michael

On 6/20/2020 4:58 PM, Tom Keffer wrote:
There seems to be an issue with using owfs with Python 3 under buster. 
See this thread: 
https://groups.google.com/d/msg/weewx-user/ntrwrTl1xew/37u0_b7nAgAJ


-tk

On Fri, Jun 19, 2020 at 10:30 AM michael form > wrote:


I have Weewx 3.92 running on a Raspberry  Pi3 using One-Wire
sensors for all measurements via a USB to 1-Wire interface
(DS9490). The Pi is running Buster and I installed Weewx using the
Debian installation package. Everything is now working fine and I
want to tempt fate by upgrading to Weewx 4.1.1 (and Python 3).

What is the easiest and most reliable way to do this? Do I just
install Weewx again on the same Pi using the procedure for an
initial install of the Debian package? Will it keep the database
and conf files or do I have to save them and put them back when
done? Do I need to do anything with OWFS to work with Python 3?
Should I follow the procedure in installation guide:

Tell your system to trust weewx.com :

wget -qO -http://weewx.com/keys.html  | sudo apt-key add -

For Debian10 and later, use python3:

wget -qO -http://weewx.com/apt/weewx-python3.list  | sudo tee 
/etc/apt/sources.list.d/weewx.list


Basically, how best to upgrade without losing the old data and
keeping things working?

Thanks for any guidance.

Michael
-- 
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/ff7326d5-d1cf-4523-b963-eb9104dc1e0fo%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/CAPq0zEAsJvWhUMzpBFPrAj6nTEh5U-bWdBX1iRo9DLJZiEF%3DwA%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/c55a6064-a7ba-6d5a-206e-e2e91588e134%40verizon.net.

Re: [weewx-user] Graphs not updating

[Tom Keffer]

Impossible to say with the limited information you're giving us. At a
minimum, how about the type of station, and the log?

See the Wiki article *Help! Posting to weewx-user
*.

On Sun, Jun 21, 2020 at 11:45 AM michael form  wrote:

> I have Weewx 3.9.2 running on a Raspberry Pi 3 using the Debiam install.
> Until this morning, everything was working fine. When I went to look at the
> web page this afternoon, the system was unresponsive. This included the Pi
> itself. I rebooted the system and it came up OK but now the graphs on the
> web page are not updating, although it seems that the sensors are sending
> back valid data, that is the temperature readings are reasonable and the
> date and time are correct. However, the graphs are not updating and are
> stuck at around 3:00 AM this morning, which is when the system seems to
> have stopped.
>
> I have no idea on why things got stuck, as the system has been running
> without a problem for over a month. The problem could be with the Pi and/or
> Raspbian, but that does not explain why everything rebooted and is working
> except the plots.
>
> Any ideas on where to look?
>
> Thanks.
>
> Michael
>
>
> --
> 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/e2d9a7dc-0cd1-4013-a817-2d58123b16deo%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/CAPq0zEBYgG%2BM2%3DTae9iQHUpzuAEtgzdm%2BD35rJrOCq-epN1bng%40mail.gmail.com.

[weewx-user] Re: problem with css/style of embedded forecast in Responsive skin...

['Christian Peters' via weewx-user]

Ok, solved. 

I copied the content of
 forecast_table.css

in the head of the html file surrounded by 


.




..this works.:-) 


-- 
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/fd5580d2-3259-475a-af26-05b4b14fe787o%40googlegroups.com.

Re: [weewx-user] Graphs not updating

[michael form]

I just checked and things seem to be working once  again. However, data is 
missing around 03:00 yesterday until around 14:00 today. I was planning on 
installing the RTC but saw no need since I assumed that the system would 
get the correct time from a time server. This, evidently, was an incorrect 
assumption. Do you have any idea on why this did not happen? Why did it 
take so long to begin displaying "correctly" again. I would have thought 
that it would start up right after the reboot. Does Weewx itself query a 
time server or do I have to explicitly do this? 

Speaking of "explicitly", I wanted to explicitly thank you and other  group 
members for their help for those of us that need it. Thank you.

Michael

On Sunday, June 21, 2020 at 4:35:05 PM UTC-4, Tom Keffer wrote:
>
> 1. Just delete the plots. They will all get regenerated.
>
> 2. You had the classic "no clock" symptoms: when the reboot happened, the 
> system started with the last time it had saved, which was hours old. This 
> always causes unpredictable results. See the wiki article *Raspberry Pi 
> *.
>
> It's well worth spending the $5 and installing a realtime clock.
>
> -tk
>
> On Sun, Jun 21, 2020 at 12:42 PM michael form  > wrote:
>
>> I have attached a section of the syslog file. Somewhere around 3:13:54 AM 
>> on 20 June the system seems to have lost track of the time. If you need me 
>> to supply a more detailed log with debug=1, let me know.
>>
>> The station type is USB using a DS9490 USB to 1-Wire interface with OWFS.
>>
>> I have confirmed that the Pi has the correct date and time and that the 
>> database has current correct values even though the graphs/plots are not 
>> updating.
>>
>> Questions:
>>
>> 1. How to get the plots to update correctly now that the system has been 
>> rebooted?
>>
>> 2. Why did the system get confused with the time? This is probably more 
>> difficult to answer. How to prevent this in the future, if possible?
>>
>> Thanks.
>>
>> Michael
>>
>> On Sunday, June 21, 2020 at 3:01:59 PM UTC-4, Tom Keffer wrote:
>>>
>>> Impossible to say with the limited information you're giving us. At a 
>>> minimum, how about the type of station, and the log?
>>>
>>> See the Wiki article *Help! Posting to weewx-user 
>>> *.
>>>
>>> On Sun, Jun 21, 2020 at 11:45 AM michael form  wrote:
>>>
 I have Weewx 3.9.2 running on a Raspberry Pi 3 using the Debiam 
 install. Until this morning, everything was working fine. When I went to 
 look at the web page this afternoon, the system was unresponsive. This 
 included the Pi itself. I rebooted the system and it came up OK but now 
 the 
 graphs on the web page are not updating, although it seems that the 
 sensors 
 are sending back valid data, that is the temperature readings are 
 reasonable and the date and time are correct. However, the graphs are not 
 updating and are stuck at around 3:00 AM this morning, which is when the 
 system seems to have stopped. 

 I have no idea on why things got stuck, as the system has been running 
 without a problem for over a month. The problem could be with the Pi 
 and/or 
 Raspbian, but that does not explain why everything rebooted and is working 
 except the plots.

 Any ideas on where to look?

 Thanks.

 Michael


 -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/e2d9a7dc-0cd1-4013-a817-2d58123b16deo%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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/a05202cc-820c-4f37-989d-a23cef4182eco%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/c8653f23-b0cc-4a38-8de0-b44163407baao%40googlegroups.com.

Re: [weewx-user] Graphs not updating

[vince]

On Sunday, June 21, 2020 at 3:54:56 PM UTC-7, michael form wrote:
>
> ...saw no need since I assumed that the system would get the correct time 
> from a time server. 
>

 [...]

 I would have thought that it would...
>


Not usually a good move to assume anything.   You have to understand how 
the computer you're running on does (or does not) achieve accurate time.

On a Raspberry Pi I'd suggest doing both A+B on the link Tom provided.   If 
you install+enable+start ntpd, then the systemd time daemon stuff gets 
superseded with something that actually works.   Disabling the fake-hwclock 
thing better ensures that the system doesn't try to save a (possibly bogus) 
time and reinitialize to that on the subsequent power-up.

If your pi never takes a power down/up, the software solution usually works 
ok, but a RTC would belt+suspenders things even more.



-- 
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/0710f6dc-9879-4835-8f69-8e9bc7d2dcfco%40googlegroups.com.

Re: [weewx-user] Suggestions on best way to upgrade to 4.1.1

[Glenn McKechnie]

On 22/06/2020, michael form  wrote:
> Glenn:
>
> I will follow up on what you said and hopefully, things will go smoothly
> with the upgrade to 4.1.1.

To be hoped.
And let us know either way.  :-)

Information is king.

Hopefully I've supplied enough over on my fork, I've update the readme
with a note to read the pydoc output at bin/user/pydoc_owfs.txt which
is in the repo (also the zip file) if you need to know more (possibly
than you want to) about some of the quirks of the drivers
installation.

If you find them lacking in some measure, let us know, here or at github.

When you're close to something it takes a special skill to write good
documentation as we all tend to make assumptions from our own
knowledge base.

Now that this driver can run with 1 of 2 modules, as well as the 2
python versions involved it's all got a lot more complicated and
that's without adding owserver and the busmaster devices into the mix.

>From your end.

1.
If you need to send a log extract, include plenty of it, and forget
about sending the short systemd log. Make it a copy, or large extract
from syslog, from start to finish.
The owfs.py driver will log the module it is using straight after
weewx starts up and that alone is valuable information. weewx also
logs the python version that it is using and that is also essential in
this case.

2.
Need to know the complete [OWFS] entry from weewx.conf, In fact, it's
best to use the  wee_debug tool and send the lot.

3.
Finally your complete /etc/owfs.conf file

> I will certainly let you know if it doesn't. :)

:-) And when it does work!

Good luck.

> Michael


-- 


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
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/CAAraAzi6bqdzZsDQkOEtS-3CMYaxrj6CcQ0t5zJK59vjZCSUDw%40mail.gmail.com.

Re: [weewx-user] Suggestions on best way to upgrade to 4.1.1

[Glenn McKechnie]

On 22/06/2020, Michael Form  wrote:
> Tom:
>
> Thank you for your response. I was aware of this issue which is the
> reason that I asked if there was a way around it. The thread does not
> seem to indicate a solution.

That thread was restarted as "V4 with python2 OWFS errors" and was
resolved there, with two working installations at the finish of it.
One with python2.7, the other with python3.

I also have direct access to 3 weewx4 installs, 2 under Debian Buster
and 1 under Devuan ascii. They all use owserver with either python-ow,
python3-ow (yep, python3-ow) or pyownet  running owfs.py. They all
work with either python2.7 or python3 (dual installations)

https://groups.google.com/d/topic/weewx-user/FqGbLbH0Gcs/discussion

[...]
> If there is no solution to using owfs under Python 3, how do I install 4.1.1 
> and specify to use Python 2?

python3-ow has disappeared from the repos but the modified driver will
use pyownet as a drop in replacement. So you can run weewx4 and
owfs.py with either python version.

If you install weewx4, whether you use python2.7 or 3, you will be
using a different driver to the owfs.py driver you are using now. (I
don't think the 0.21 owfs.py driver was officially ported? You could
of course try it anyway with a weewx4/python2.7 install but I'd expect
it to fail.)

In short , there is a version of owfs which runs under weewx4 and
python3, or python2.7

The driver at

https://github.com/matthewwall/weewx-owfs

had some issues which were resolved in that second thread by using my fork at

https://github.com/glennmckechnie/weewx-owfs

My fork definitely works for weewx4 and python3 or python2.7 and if it
doesn't I'll do my best to fix it. That fork is also in mathews long
queue to be merged (where appropriate) back into his long standing,
and supported, driver so there is and will be ongoing support for owfs
from the one source.

The only issue left is with owserver and that has a possible solution
for a vague problem. And that's if it is even an issue on your
installation. The readme.txt on my fork covers what has changed and
solutions where they are known.
It also covers the configuration of owserver.

I'm not sure whether you are running owserver (I've lost track along
the way) and if you were uncertain, then installing owserver first and
seeing if it starts and runs for you would be one approach before
actually committing to any change.

Rest assured, if you go the down the path of weewx4 and owfs.py you
won't be left stranded by weewx-user and issues with owfs.py

My only nervousness is with owserver as there has been no definitive
solution for that vague, but occasional, show stopping issue. Once
owserver does start it seems to keep going, judging by the silence -
go figure!

I should add, the issue with owserver is a system issue (Buster
specifically), it is not a weewx issue. That's why if you have
owserver  running already then I don't see any problem, The owfs.py
driver is working, and it can be modified if need be.

-- 


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
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/CAAraAzhQQ1%3Db_bhJn%2By1227UBWTi6%2B70ycccb%2Bs-SRcXKS6idA%40mail.gmail.com.

Re: [weewx-user] Graphs not updating

[michael form]

I am not sure why the Pi would restart as it is powered by a UPS so the 
issue is somewhat of a mystery why it got confused. A second Pi, also 
running Weewx, powered by the same UPS did not run into any problems. In 
any event, I have ordered two RTC modules and will install them on the two 
Pis when they arrive later this week and hopefully, the problem will never 
come up again.

Thanks for your response.

Michael

On Sunday, June 21, 2020 at 8:57:24 PM UTC-4, vince wrote:
>
>
> On Sunday, June 21, 2020 at 3:54:56 PM UTC-7, michael form wrote:
>>
>> ...saw no need since I assumed that the system would get the correct time 
>> from a time server. 
>>
>
>  [...]
>
>  I would have thought that it would...
>>
>
>
> Not usually a good move to assume anything.   You have to understand how 
> the computer you're running on does (or does not) achieve accurate time.
>
> On a Raspberry Pi I'd suggest doing both A+B on the link Tom provided.   
> If you install+enable+start ntpd, then the systemd time daemon stuff gets 
> superseded with something that actually works.   Disabling the fake-hwclock 
> thing better ensures that the system doesn't try to save a (possibly bogus) 
> time and reinitialize to that on the subsequent power-up.
>
> If your pi never takes a power down/up, the software solution usually 
> works ok, but a RTC would belt+suspenders things even more.
>
>
>
>

-- 
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/fe72a125-9adf-4ec6-9311-10b6046b1466o%40googlegroups.com.

Re: [weewx-user] Graphs not updating

[Glenn McKechnie]

On 22/06/2020, michael form  wrote:
> I am not sure why the Pi would restart as it is powered by a UPS so the
> issue is somewhat of a mystery why it got confused. A second Pi, also
> running Weewx, powered by the same UPS did not run into any problems.

Have a look in syslog (or syslog.1 or older gz file) and see if there
is a hint in there.
It may have run out of memory in which case they will reboot if the
memory killer can't resolve it.


-- 


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
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/CAAraAziaaVxk4%2BRPR6i%3DzbHTftp4_-nnpjcB1GK%2B_6ehQrU%2BRw%40mail.gmail.com.

Re: [weewx-user] Suggestions on best way to upgrade to 4.1.1

[michael form]

Glenn:

I will follow up on what you said and hopefully, things will go smoothly 
with the upgrade to 4.1.1. I will certainly let you know if it doesn't. :)

Michael

On Sunday, June 21, 2020 at 8:25:00 PM UTC-4, Glenn McKechnie wrote:
>
> On 22/06/2020, Michael Form > wrote: 
> > Tom: 
> > 
> > Thank you for your response. I was aware of this issue which is the 
> > reason that I asked if there was a way around it. The thread does not 
> > seem to indicate a solution. 
>
> That thread was restarted as "V4 with python2 OWFS errors" and was 
> resolved there, with two working installations at the finish of it. 
> One with python2.7, the other with python3. 
>
> I also have direct access to 3 weewx4 installs, 2 under Debian Buster 
> and 1 under Devuan ascii. They all use owserver with either python-ow, 
> python3-ow (yep, python3-ow) or pyownet  running owfs.py. They all 
> work with either python2.7 or python3 (dual installations) 
>
> https://groups.google.com/d/topic/weewx-user/FqGbLbH0Gcs/discussion 
>
> [...] 
> > If there is no solution to using owfs under Python 3, how do I install 
> 4.1.1 and specify to use Python 2? 
>
> python3-ow has disappeared from the repos but the modified driver will 
> use pyownet as a drop in replacement. So you can run weewx4 and 
> owfs.py with either python version. 
>
> If you install weewx4, whether you use python2.7 or 3, you will be 
> using a different driver to the owfs.py driver you are using now. (I 
> don't think the 0.21 owfs.py driver was officially ported? You could 
> of course try it anyway with a weewx4/python2.7 install but I'd expect 
> it to fail.) 
>
> In short , there is a version of owfs which runs under weewx4 and 
> python3, or python2.7 
>
> The driver at 
>
> https://github.com/matthewwall/weewx-owfs 
>
> had some issues which were resolved in that second thread by using my fork 
> at 
>
> https://github.com/glennmckechnie/weewx-owfs 
>
> My fork definitely works for weewx4 and python3 or python2.7 and if it 
> doesn't I'll do my best to fix it. That fork is also in mathews long 
> queue to be merged (where appropriate) back into his long standing, 
> and supported, driver so there is and will be ongoing support for owfs 
> from the one source. 
>
> The only issue left is with owserver and that has a possible solution 
> for a vague problem. And that's if it is even an issue on your 
> installation. The readme.txt on my fork covers what has changed and 
> solutions where they are known. 
> It also covers the configuration of owserver. 
>
> I'm not sure whether you are running owserver (I've lost track along 
> the way) and if you were uncertain, then installing owserver first and 
> seeing if it starts and runs for you would be one approach before 
> actually committing to any change. 
>
> Rest assured, if you go the down the path of weewx4 and owfs.py you 
> won't be left stranded by weewx-user and issues with owfs.py 
>
> My only nervousness is with owserver as there has been no definitive 
> solution for that vague, but occasional, show stopping issue. Once 
> owserver does start it seems to keep going, judging by the silence - 
> go figure! 
>
> I should add, the issue with owserver is a system issue (Buster 
> specifically), it is not a weewx issue. That's why if you have 
> owserver  running already then I don't see any problem, The owfs.py 
> driver is working, and it can be modified if need be. 
>
> -- 
>
>
> Cheers 
>  Glenn 
>
> rorpi - read only raspberry pi & various weewx addons 
> https://github.com/glennmckechnie 
>

-- 
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/a10a19d8-ac9f-4e40-b570-1b3cec5abe20o%40googlegroups.com.

Re: [weewx-user] Suggestions on best way to upgrade to 4.1.1

[Tom Keffer]

Thanks for setting us straight, Glenn!

On Sun, Jun 21, 2020 at 5:24 PM Glenn McKechnie 
wrote:

> On 22/06/2020, Michael Form  wrote:
> > Tom:
> >
> > Thank you for your response. I was aware of this issue which is the
> > reason that I asked if there was a way around it. The thread does not
> > seem to indicate a solution.
>
> That thread was restarted as "V4 with python2 OWFS errors" and was
> resolved there, with two working installations at the finish of it.
> One with python2.7, the other with python3.
>
> I also have direct access to 3 weewx4 installs, 2 under Debian Buster
> and 1 under Devuan ascii. They all use owserver with either python-ow,
> python3-ow (yep, python3-ow) or pyownet  running owfs.py. They all
> work with either python2.7 or python3 (dual installations)
>
> https://groups.google.com/d/topic/weewx-user/FqGbLbH0Gcs/discussion
>
> [...]
> > If there is no solution to using owfs under Python 3, how do I install
> 4.1.1 and specify to use Python 2?
>
> python3-ow has disappeared from the repos but the modified driver will
> use pyownet as a drop in replacement. So you can run weewx4 and
> owfs.py with either python version.
>
> If you install weewx4, whether you use python2.7 or 3, you will be
> using a different driver to the owfs.py driver you are using now. (I
> don't think the 0.21 owfs.py driver was officially ported? You could
> of course try it anyway with a weewx4/python2.7 install but I'd expect
> it to fail.)
>
> In short , there is a version of owfs which runs under weewx4 and
> python3, or python2.7
>
> The driver at
>
> https://github.com/matthewwall/weewx-owfs
>
> had some issues which were resolved in that second thread by using my fork
> at
>
> https://github.com/glennmckechnie/weewx-owfs
>
> My fork definitely works for weewx4 and python3 or python2.7 and if it
> doesn't I'll do my best to fix it. That fork is also in mathews long
> queue to be merged (where appropriate) back into his long standing,
> and supported, driver so there is and will be ongoing support for owfs
> from the one source.
>
> The only issue left is with owserver and that has a possible solution
> for a vague problem. And that's if it is even an issue on your
> installation. The readme.txt on my fork covers what has changed and
> solutions where they are known.
> It also covers the configuration of owserver.
>
> I'm not sure whether you are running owserver (I've lost track along
> the way) and if you were uncertain, then installing owserver first and
> seeing if it starts and runs for you would be one approach before
> actually committing to any change.
>
> Rest assured, if you go the down the path of weewx4 and owfs.py you
> won't be left stranded by weewx-user and issues with owfs.py
>
> My only nervousness is with owserver as there has been no definitive
> solution for that vague, but occasional, show stopping issue. Once
> owserver does start it seems to keep going, judging by the silence -
> go figure!
>
> I should add, the issue with owserver is a system issue (Buster
> specifically), it is not a weewx issue. That's why if you have
> owserver  running already then I don't see any problem, The owfs.py
> driver is working, and it can be modified if need be.
>
> --
>
>
> Cheers
>  Glenn
>
> rorpi - read only raspberry pi & various weewx addons
> https://github.com/glennmckechnie
>
> --
> 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/CAAraAzhQQ1%3Db_bhJn%2By1227UBWTi6%2B70ycccb%2Bs-SRcXKS6idA%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/CAPq0zECQfb_sO72fLfj%3D-XkTP3MNwf%3D%3DEg%3DTuZChZaF_c7vcQg%40mail.gmail.com.

[weewx-user] Monthly Summaries are empty

[jhn.p...@gmail.com]

I upgraded to 4.1.latest a few weeks ago, its running on an RPi3 w/ 
Raspbian Stretch (and installed via apt-get from the Stretch 
repositories)...

I just noticed, my monthly summary tables are content-free, other than the 
current month... see 
https://freescruz.com/weewx/tabular.html?report=NOAA/NOAA-2020-05.txt for 
an example.

oh, the annual summaries for previous years are empty, too.

do I need to run something special to generate these?   afaik my database 
goes back 2-3 years.   I'm using mysql on an external server... actually 
mariadb 10.3.13, installed from FreeBSD 11.3 Ports.

-- 
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/95e85665-b226-4de1-a778-0a7c983f54a6n%40googlegroups.com.

[weewx-user] Re: GUI date/time and current conditions frozen

[Zsolt Máté]

After a month of trial and error, I'm still struggling with this issue.
I've changed my VM from turnkey linux to a full ubuntu server, didn't help. 
Tried minimal installations, mysql vs sqlite, no joy. My date is being 
messed up somehow.

-- 
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/c130bebe-ae49-4064-9a76-1d441d57a20eo%40googlegroups.com.

Re: [weewx-user] Suggestions on best way to upgrade to 4.1.1

[Tom Keffer]

You can add more temperature sensors to your existing schema. Follow the
directions in the section *Adding a new type to the database* in the copy
of the Customizing Guide *that came with your 3.9.X version* (Version 4.x
uses a different method).

If you wish to use Python 2 on buster, use the Debian 9 (squeeze)
instructions:





*wget -qO - http://weewx.com/keys.html  | sudo
apt-key add -wget -qO - http://weewx.com/apt/weewx-python2.list
 | sudo tee
/etc/apt/sources.list.d/weewx.listsudo apt-get updatesudo apt-get install
weewx*

-tk


On Sun, Jun 21, 2020 at 10:44 AM Michael Form  wrote:

> Tom:
>
> Thank you for your response. I was aware of this issue which is the reason
> that I asked if there was a way around it. The thread does not seem to
> indicate a solution.
>
> Assuming there is a workaround, how to upgrade without losing the
> configuration (weewx.conf) and the previous data in the database, etc.
>
> One of the reasons that I would like to update to 4.1.1 is the greater
> number of temperature inputs in the schema. I have run out of temperature
> inputs and still have four or five more to add. I assume that I can add to
> the 3.92 database setup but I am a hardware designer and am afraid of
> messing thing up in Linux and Python and so forth.
>
> If there is no solution to using owfs under Python 3, how do I install
> 4.1.1 and specify to use Python 2?
>
> Thanks for your help in getting this resolved.
>
> Michael
>
> On 6/20/2020 4:58 PM, Tom Keffer wrote:
>
> There seems to be an issue with using owfs with Python 3 under buster. See
> this thread:
> https://groups.google.com/d/msg/weewx-user/ntrwrTl1xew/37u0_b7nAgAJ
>
> -tk
>
> On Fri, Jun 19, 2020 at 10:30 AM michael form  wrote:
>
>> I have Weewx 3.92 running on a Raspberry  Pi3 using One-Wire sensors for
>> all measurements via a USB to 1-Wire interface (DS9490). The Pi is running
>> Buster and I installed Weewx using the Debian installation package.
>> Everything is now working fine and I want to tempt fate by upgrading to
>> Weewx 4.1.1 (and Python 3).
>>
>> What is the easiest and most reliable way to do this? Do I just install
>> Weewx again on the same Pi using the procedure for an initial install of
>> the Debian package? Will it keep the database and conf files or do I have
>> to save them and put them back when done? Do I need to do anything with
>> OWFS to work with Python 3? Should I follow the procedure in installation
>> guide:
>>
>> Tell your system to trust weewx.com:
>>
>> wget -qO - http://weewx.com/keys.html | sudo apt-key add -
>>
>> For Debian10 and later, use python3:
>>
>> wget -qO - http://weewx.com/apt/weewx-python3.list | sudo tee 
>> /etc/apt/sources.list.d/weewx.list
>>
>>
>> Basically, how best to upgrade without losing the old data and keeping
>> things working?
>>
>> Thanks for any guidance.
>>
>> Michael
>> --
>> 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/ff7326d5-d1cf-4523-b963-eb9104dc1e0fo%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/CAPq0zEAsJvWhUMzpBFPrAj6nTEh5U-bWdBX1iRo9DLJZiEF%3DwA%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/CAPq0zEChjX_T2ZVwZBzJq-yT5aN49H%3DpXi_z3DcbQR33q0DVRg%40mail.gmail.com.

[weewx-user] Re: No solar reading from Davis Vantage Pro2

[vince]

I'd start by ensuring the pi has quality time.  Generally running NTP works 
better than the built-in systemd time software.  An inexpensive realtime 
clock module also tends to help.  There are 'dozens' of posts here about 
the importance of having accurate date+time especially on devices like a pi 
that have no built-in RTC typically.

-- 
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/440b558c-1d02-47ae-b159-b307a9764247o%40googlegroups.com.

[weewx-user] Re: problem with css/style of embedded forecast in Responsive skin...

['Christian Peters' via weewx-user]

Ok, solved. 

I copied the content of
 forecast_table.inc

in the head of the html file surrounded by 


.




..this works.:-) 



Am Sonntag, 21. Juni 2020 17:17:53 UTC+2 schrieb Christian Peters:
>
> Hi all,
>
> maybe some can help me. :-) 
> I'm not familiar with css and web content. 
> I trry to include the weewx forcast extension into the responsive skin. 
> The forcast plugin is working, even with the right formatting if I open 
> the forcast demo pages. (Pic 2)
>
> I included the forecast_table.inc file in my html.tmpl, copied the icons 
> to my skin, but the formatting isn't as expected?
> How do I get the formatting provided for this snippet inside my skin?
>
> That's my code:
>
> Code hier eingeben...## Forecast start
>  
>   
> 
>parent="#accordionTwo" href="#collapseAccTwoE">
> 5-Tage Trend
>   
> 
>   
>   
> 
>   
> #set $periods = 
> $forecast.weather_periods('OWM',max_events=6)
> #include '/etc/weewx/skins/forecast/forecast_table.inc
> '
>
> 
>   
> 
> ## Forecast end
>
> It looks like Pic 1 now, it should look like Pic 2...!? 
>
> Any idea how I get the formatting for this table inside my skin!?
>
> Thanks in advance!
>
> Regard,
>
> Christian 
>

-- 
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/bb1d5610-8aa8-4d10-9b5f-47a51b53d1ffo%40googlegroups.com.