[weewx-user] Re: [ANNOUNCE] weewx-aqi: A Plugin for Air Quality Index Calculations

[jonathan koren]

weewx-aqi actually doesn’t talk to sensors, it reads from databases that 
whatever sensor plugins walked to. So in that sense it should work with 
whatever. The configuration lets you define which column from which 
database corresponds to what reading. I’ve used this with Purple Air and 
helped someone with a bespoke sensor setup.  If you need help, let me know.

-- 
jonathan

On Sunday, December 22, 2019 at 9:19:47 AM UTC-6, Muireadach O Connor wrote:
>
> Thanks very much for taking the time to write this.
> Does the current version support the Luftdaten.info type sensors out of 
> the box so to speak?, I had a read of the instructions on Github for using 
> with other sensors and I'm not really sure i'd know where to start though 
> I'd certainly give it a go once I see what the generated data looks like. 
>
> Many thanks,
>
> Muireadach.
>
> On Thursday, May 17, 2018 at 7:48:16 AM UTC+1, jonathan koren wrote:
>>
>>
>> I'd like to announce a new plugin for WeeWx, weewx-aqi 
>> .
>>  
>> weewx-aqi calculates various air quality indices using data from a linked 
>> air quality sensor, such as weewx-purpleair 
>> .
>>  
>> An air quality index, is a government defined scaled that is meant to 
>> succinctly describe how safe the air is. weewx-aqi can currently calculate 
>> the following AQIs:
>>
>> * Canada's Air Quality Health Index
>> * India's National Air Quality Index
>> * Mexico's Índice Metropolitano de la Calidad del Aire
>> * United Kingdom's Daily Air Quality Index
>> * United States's Air Quality Index
>> * United States's NowCast Air Quality Index
>>
>> Download link: 
>> https://github.com/jonathankoren/weewx-aqi/releases/tag/v1.0.0
>>
>> I personally use this plugin with my Purple Air sensor to calculate a PM 
>> 2.5 NowCast AQI. I hope others find this interesting and/or useful. I 
>> especially would like to hear from anyone that has an air quality sensor 
>> integrated into WeeWx that is not a Purple Air, as the plugin is written to 
>> be as sensor agnostic as possible. Finally, requests for additional AQIs 
>> are welcome. (Coming soon, the European Air Quality Index.)
>>
>> Thanks.
>>
>> --
>> jonathankoren
>>
>

-- 
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/a274f9df-9a1a-4320-96f2-3a92a2085048%40googlegroups.com.

[weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[rich T]

I'm using this sensor. 
https://www.amazon.com/Diymall-Pressure-Temperature-Sensor-Arduino/dp/B0118XCKTG
  
Works fine for what I need it for.

On Monday, December 23, 2019 at 5:40:55 PM UTC-5, Gert Andersen wrote:
>
> Hi
> I'm running a configuration with the Ecowitt GW1000/Froggit DP1500(no 
> console) and some senors (rain, wind temp, etc). Data from these sensors 
> are received via the weewx SDR driver and rtl_433. So the GW1000 is not 
> seen by the SDR system and therefore no pressure data are received.
>
> Question, it it possible to add a pressure sensor, which can be seen from 
> the SDR driver or  is there another solution.
>
> Thanks
> Gert
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5f061184-f1e3-4445-80be-a4b2bbebce8a%40googlegroups.com.

Re: [weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[Thomas Keffer]

Nothing wrong with that!

I wish the data sheet
 gave more
information --- it's hard to determine its repeatable accuracy. It claims
1.5 Pascal resolution, but doesn't give any clues as to linearity or drift.

My application was offshore sailboat racing, where you need absolute
accuracy with little drift. It helps you determine where you are relative
to a high pressure cell. The Dracal's form factor is also perfect for
plugging into the navigational computer.

-tk

On Fri, Dec 27, 2019 at 5:04 PM p q  wrote:

> I was thinking more on the opposite end of the spectrum - cheap and do it
> yourself  https://www.adafruit.com/product/1893
>
> But either will work.
>
> On Fri, Dec 27, 2019 at 2:56 PM Thomas Keffer  wrote:
>
>> This is an option. It's pretty expensive, but it is super accurate
>> :
>>  0.2
>> mbar across 990 to 1040 mbar. I have one and like it a lot.
>>
>> I've written a weewx service for reading XDR pressure data
>> .
>>
>> https://www.dracal.com/store/products/usb_bar20_n/index.php
>> [image: image.png]
>>
>> On Fri, Dec 27, 2019 at 2:01 PM p q  wrote:
>>
>>> Or buy a pressure sensor and hook it up to your computer directly.
>>>
>>> On Fri, Dec 27, 2019 at 12:36 PM galfert  wrote:
>>>
 Correct. There is no console that broadcasts barometric pressure via
 RF. There wouldn't be a need. Any console that has built in barometric
 pressure has not need to broadcast that via RF as it is already built in,
 and therefore the console has the data that it needs from the barometric
 sensor to then upload to the supported online services. A station only
 needs one barometric sensor. That is the purpose of the WH32B for use on
 the HP2551-C which does not have a built in barometric sensor. The reason
 the HP2551-C doesn't have this sensor built in was probably a function
 first of the temperature/humidity sensor so that it would not cause
 erroneous indoor temperatures as having those inside the display console
 would cause those sensors to overheat and report a too high of a
 temperature. Different display technology like the one in the WH2910C are
 not prone to temperature increase due to display technology (it is LED vs
 LCD). The LCD displays overheat, which is why the HP2551-C has the
 temperature/humidity sensor external via the WH32B. So while we are at it
 the WH32B also incorporated the barometric sensor on that device. This
 allows you to have multiple displays at a lower cost all sharing the one
 indoor WH32B sensor. Ecowitt does not list the WH32B on their websites but
 if you contact them and tell them that you need the sensor with barometric
 sensor that would normally be paired with the HP2551-C they will know what
 you are referring to. I'm calling it a WH32B because that is what Ambient
 Weather Calls it. I don't really know for sure what Ecowitt calls it
 officially. There is different regular WH32 that is for outdoor use and
 that one does not have the barometric sensorso you don't want that one.

 On Friday, December 27, 2019 at 1:02:22 PM UTC-5, Gert Andersen wrote:
>
> Hi
>
> So there are no display consoles that transmit a barometric signal
> that can be intercepted by SDR?
>
> Gert
>
> On Friday, December 27, 2019 at 3:08:30 PM UTC+1, galfert wrote:
>>
>> Yet another solution to keep using SDR is to get a WH32B from Ecowitt
>> that includes barometric pressure. This would be the same sensor that you
>> would need for the HP2551-C display console as it doesn't have a built in
>> barometric sensor.
>
> --
 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/fa1f883b-0b6d-4719-a5a8-f462eaf469ee%40googlegroups.com
 
 .

>>>
>>>
>>> --
>>> Peter Quinn
>>> (415)794-2264
>>>
>>> --
>>> 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/CAA1SM21%2B%2BH59NMW1uxKgFOtNE1yq9MV_O7YucPNXB0TTwKgxNw%40mail.gmail.com
>>> 

Re: [weewx-user] Newbie Install Possible Issues

[Ron Short]

Hi,

Well, I have not forgotten nor given up on this project.

I found a couple settings not turned on in the RPi. The i2c and the serial
port as per the Meteo-Pi author. Nice guy for sure.

I also found a few other issues within the RPi as well and unfortunately I
s a m in the process if re-flashing the SD card.

BTW, I retired recently and forgot to turn off the Signature option. Please
accept my apologies on this oversight on my part.

Ron

On Thu, Dec 26, 2019 at 20:53 Ron Short  wrote:

> True, I will send .conf and what the results are after running the debug
> program.
>
> Ron
>
> On Thu, Dec 26, 2019 at 20:49 gjr80  wrote:
>
>> Your choice, but that’s an awful lot of work when we haven’t even seen a
>> config file yet. This could be as simple as one or two incorrect settings.
>>
>> 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/d3f8424c-a932-4af5-b112-7ba40b24979f%40googlegroups.com
>> .
>>
> --
> Regards,
>
>
> Ron
>

-- 
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/CAAn2D61e7PC%3D-%3DS_C-V0pG4bfCQyYa4N%3DTJq8PdeBpDeh1PT4Q%40mail.gmail.com.

Re: [weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[p q]

I was thinking more on the opposite end of the spectrum - cheap and do it
yourself  https://www.adafruit.com/product/1893

But either will work.

On Fri, Dec 27, 2019 at 2:56 PM Thomas Keffer  wrote:

> This is an option. It's pretty expensive, but it is super accurate
> :
>  0.2
> mbar across 990 to 1040 mbar. I have one and like it a lot.
>
> I've written a weewx service for reading XDR pressure data
> .
>
> https://www.dracal.com/store/products/usb_bar20_n/index.php
> [image: image.png]
>
> On Fri, Dec 27, 2019 at 2:01 PM p q  wrote:
>
>> Or buy a pressure sensor and hook it up to your computer directly.
>>
>> On Fri, Dec 27, 2019 at 12:36 PM galfert  wrote:
>>
>>> Correct. There is no console that broadcasts barometric pressure via RF.
>>> There wouldn't be a need. Any console that has built in barometric pressure
>>> has not need to broadcast that via RF as it is already built in, and
>>> therefore the console has the data that it needs from the barometric sensor
>>> to then upload to the supported online services. A station only needs one
>>> barometric sensor. That is the purpose of the WH32B for use on the HP2551-C
>>> which does not have a built in barometric sensor. The reason the HP2551-C
>>> doesn't have this sensor built in was probably a function first of the
>>> temperature/humidity sensor so that it would not cause erroneous indoor
>>> temperatures as having those inside the display console would cause those
>>> sensors to overheat and report a too high of a temperature. Different
>>> display technology like the one in the WH2910C are not prone to temperature
>>> increase due to display technology (it is LED vs LCD). The LCD displays
>>> overheat, which is why the HP2551-C has the temperature/humidity sensor
>>> external via the WH32B. So while we are at it the WH32B also incorporated
>>> the barometric sensor on that device. This allows you to have multiple
>>> displays at a lower cost all sharing the one indoor WH32B sensor. Ecowitt
>>> does not list the WH32B on their websites but if you contact them and tell
>>> them that you need the sensor with barometric sensor that would normally be
>>> paired with the HP2551-C they will know what you are referring to. I'm
>>> calling it a WH32B because that is what Ambient Weather Calls it. I don't
>>> really know for sure what Ecowitt calls it officially. There is different
>>> regular WH32 that is for outdoor use and that one does not have the
>>> barometric sensorso you don't want that one.
>>>
>>> On Friday, December 27, 2019 at 1:02:22 PM UTC-5, Gert Andersen wrote:

 Hi

 So there are no display consoles that transmit a barometric signal that
 can be intercepted by SDR?

 Gert

 On Friday, December 27, 2019 at 3:08:30 PM UTC+1, galfert wrote:
>
> Yet another solution to keep using SDR is to get a WH32B from Ecowitt
> that includes barometric pressure. This would be the same sensor that you
> would need for the HP2551-C display console as it doesn't have a built in
> barometric sensor.

 --
>>> 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/fa1f883b-0b6d-4719-a5a8-f462eaf469ee%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Peter Quinn
>> (415)794-2264
>>
>> --
>> 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/CAA1SM21%2B%2BH59NMW1uxKgFOtNE1yq9MV_O7YucPNXB0TTwKgxNw%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/CAPq0zEA3kJgpQr%3DfySSvcH%3DWTYXaemRbd3zTADsOKBtpxT_FUg%40mail.gmail.com
> 
> .
>


-- 
Peter Quinn
(415)794-2264

-- 
You received this message because you are subscribed 

Re: [weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[Thomas Keffer]

This is an option. It's pretty expensive, but it is super accurate
:
0.2
mbar across 990 to 1040 mbar. I have one and like it a lot.

I've written a weewx service for reading XDR pressure data
.

https://www.dracal.com/store/products/usb_bar20_n/index.php
[image: image.png]

On Fri, Dec 27, 2019 at 2:01 PM p q  wrote:

> Or buy a pressure sensor and hook it up to your computer directly.
>
> On Fri, Dec 27, 2019 at 12:36 PM galfert  wrote:
>
>> Correct. There is no console that broadcasts barometric pressure via RF.
>> There wouldn't be a need. Any console that has built in barometric pressure
>> has not need to broadcast that via RF as it is already built in, and
>> therefore the console has the data that it needs from the barometric sensor
>> to then upload to the supported online services. A station only needs one
>> barometric sensor. That is the purpose of the WH32B for use on the HP2551-C
>> which does not have a built in barometric sensor. The reason the HP2551-C
>> doesn't have this sensor built in was probably a function first of the
>> temperature/humidity sensor so that it would not cause erroneous indoor
>> temperatures as having those inside the display console would cause those
>> sensors to overheat and report a too high of a temperature. Different
>> display technology like the one in the WH2910C are not prone to temperature
>> increase due to display technology (it is LED vs LCD). The LCD displays
>> overheat, which is why the HP2551-C has the temperature/humidity sensor
>> external via the WH32B. So while we are at it the WH32B also incorporated
>> the barometric sensor on that device. This allows you to have multiple
>> displays at a lower cost all sharing the one indoor WH32B sensor. Ecowitt
>> does not list the WH32B on their websites but if you contact them and tell
>> them that you need the sensor with barometric sensor that would normally be
>> paired with the HP2551-C they will know what you are referring to. I'm
>> calling it a WH32B because that is what Ambient Weather Calls it. I don't
>> really know for sure what Ecowitt calls it officially. There is different
>> regular WH32 that is for outdoor use and that one does not have the
>> barometric sensorso you don't want that one.
>>
>> On Friday, December 27, 2019 at 1:02:22 PM UTC-5, Gert Andersen wrote:
>>>
>>> Hi
>>>
>>> So there are no display consoles that transmit a barometric signal that
>>> can be intercepted by SDR?
>>>
>>> Gert
>>>
>>> On Friday, December 27, 2019 at 3:08:30 PM UTC+1, galfert wrote:

 Yet another solution to keep using SDR is to get a WH32B from Ecowitt
 that includes barometric pressure. This would be the same sensor that you
 would need for the HP2551-C display console as it doesn't have a built in
 barometric sensor.
>>>
>>> --
>> 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/fa1f883b-0b6d-4719-a5a8-f462eaf469ee%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Peter Quinn
> (415)794-2264
>
> --
> 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/CAA1SM21%2B%2BH59NMW1uxKgFOtNE1yq9MV_O7YucPNXB0TTwKgxNw%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/CAPq0zEA3kJgpQr%3DfySSvcH%3DWTYXaemRbd3zTADsOKBtpxT_FUg%40mail.gmail.com.

Re: [weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[p q]

Or buy a pressure sensor and hook it up to your computer directly.

On Fri, Dec 27, 2019 at 12:36 PM galfert  wrote:

> Correct. There is no console that broadcasts barometric pressure via RF.
> There wouldn't be a need. Any console that has built in barometric pressure
> has not need to broadcast that via RF as it is already built in, and
> therefore the console has the data that it needs from the barometric sensor
> to then upload to the supported online services. A station only needs one
> barometric sensor. That is the purpose of the WH32B for use on the HP2551-C
> which does not have a built in barometric sensor. The reason the HP2551-C
> doesn't have this sensor built in was probably a function first of the
> temperature/humidity sensor so that it would not cause erroneous indoor
> temperatures as having those inside the display console would cause those
> sensors to overheat and report a too high of a temperature. Different
> display technology like the one in the WH2910C are not prone to temperature
> increase due to display technology (it is LED vs LCD). The LCD displays
> overheat, which is why the HP2551-C has the temperature/humidity sensor
> external via the WH32B. So while we are at it the WH32B also incorporated
> the barometric sensor on that device. This allows you to have multiple
> displays at a lower cost all sharing the one indoor WH32B sensor. Ecowitt
> does not list the WH32B on their websites but if you contact them and tell
> them that you need the sensor with barometric sensor that would normally be
> paired with the HP2551-C they will know what you are referring to. I'm
> calling it a WH32B because that is what Ambient Weather Calls it. I don't
> really know for sure what Ecowitt calls it officially. There is different
> regular WH32 that is for outdoor use and that one does not have the
> barometric sensorso you don't want that one.
>
> On Friday, December 27, 2019 at 1:02:22 PM UTC-5, Gert Andersen wrote:
>>
>> Hi
>>
>> So there are no display consoles that transmit a barometric signal that
>> can be intercepted by SDR?
>>
>> Gert
>>
>> On Friday, December 27, 2019 at 3:08:30 PM UTC+1, galfert wrote:
>>>
>>> Yet another solution to keep using SDR is to get a WH32B from Ecowitt
>>> that includes barometric pressure. This would be the same sensor that you
>>> would need for the HP2551-C display console as it doesn't have a built in
>>> barometric sensor.
>>
>> --
> 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/fa1f883b-0b6d-4719-a5a8-f462eaf469ee%40googlegroups.com
> 
> .
>


-- 
Peter Quinn
(415)794-2264

-- 
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/CAA1SM21%2B%2BH59NMW1uxKgFOtNE1yq9MV_O7YucPNXB0TTwKgxNw%40mail.gmail.com.

[weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[galfert]

Correct. There is no console that broadcasts barometric pressure via RF. 
There wouldn't be a need. Any console that has built in barometric pressure 
has not need to broadcast that via RF as it is already built in, and 
therefore the console has the data that it needs from the barometric sensor 
to then upload to the supported online services. A station only needs one 
barometric sensor. That is the purpose of the WH32B for use on the HP2551-C 
which does not have a built in barometric sensor. The reason the HP2551-C 
doesn't have this sensor built in was probably a function first of the 
temperature/humidity sensor so that it would not cause erroneous indoor 
temperatures as having those inside the display console would cause those 
sensors to overheat and report a too high of a temperature. Different 
display technology like the one in the WH2910C are not prone to temperature 
increase due to display technology (it is LED vs LCD). The LCD displays 
overheat, which is why the HP2551-C has the temperature/humidity sensor 
external via the WH32B. So while we are at it the WH32B also incorporated 
the barometric sensor on that device. This allows you to have multiple 
displays at a lower cost all sharing the one indoor WH32B sensor. Ecowitt 
does not list the WH32B on their websites but if you contact them and tell 
them that you need the sensor with barometric sensor that would normally be 
paired with the HP2551-C they will know what you are referring to. I'm 
calling it a WH32B because that is what Ambient Weather Calls it. I don't 
really know for sure what Ecowitt calls it officially. There is different 
regular WH32 that is for outdoor use and that one does not have the 
barometric sensorso you don't want that one.

On Friday, December 27, 2019 at 1:02:22 PM UTC-5, Gert Andersen wrote:
>
> Hi
>
> So there are no display consoles that transmit a barometric signal that 
> can be intercepted by SDR?
>
> Gert
>
> On Friday, December 27, 2019 at 3:08:30 PM UTC+1, galfert wrote:
>>
>> Yet another solution to keep using SDR is to get a WH32B from Ecowitt 
>> that includes barometric pressure. This would be the same sensor that you 
>> would need for the HP2551-C display console as it doesn't have a built in 
>> barometric sensor. 
>
>

-- 
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/fa1f883b-0b6d-4719-a5a8-f462eaf469ee%40googlegroups.com.

Re: [weewx-user] Failing to upload to web server

[Thomas Keffer]

Whatever works! Sorry I couldn't be of more help.

One other option: try Matthew's SFTP generator:
https://github.com/matthewwall/weewx-sftp

Or, of course, rsync. It's much faster, as well as secure.

-tk

On Fri, Dec 27, 2019 at 10:36 AM Neil S  wrote:

> That doesnt work either but then I didnt expect it to as
> ftp.mycomain.co.uk and mydomain.co.uk and www.mydomain.co.uk all resolve
> to the same IP address which is what I tried om Post #3
>
> Anyway thanks for the pointers on lftp. Hammer and possibly nut here but I
> have now got uploads on the go again.
>
> Installed lftp on the weewxx machine (Raspberry Pi) and in the
> \etc\lftp.conf put the lines
>
> *set ssl:verify-certificate no*
> *set ftp:ssl-protect-data true*
>
> (OK I know that ignores the certificate but think that it is OK in this
> instance as it is my ISP and all I am uploading is public web pages)
>
> Then upload the files into the weather subdirectory on the server...
>
> *lftp -p 21 -u user,password  ftp.mydomain.co.uk
>  -e "mput /var/www/weewx/* -O /weather/; bye"*
>
> Bingo - files uploaded from weewx folder to public web pages.
>
> Now the weewx generates the pages every five minutes (on hour, 5 past 10
> past etc) and in general takes about 80 secs to complete its generation and
> various uploads to Wunderground, WOW Weather etc. So at 2 minutes past, 7
> minutes past, 12 minutes past etc I run the lftp comman as a cron job using
> ..
>
> *2-59/5  *  *  *  *  lftp -p 21 -u user,password  ftp.mydomain.co.uk
>  -e "mput /var/www/weewx/* -O /weather/; bye"*
>
>
> As I said most probably, nut , hammer, crack, nut etc etc  but at least
> things are working again.
>
> Neil
>
>
>
> On Monday, 23 December 2019 23:52:31 UTC, Thomas Keffer wrote:
>>
>> It would appear so, but I'm not much of a SSL expert.
>>
>> What happens if you try to connect to simply mydomain.co.uk. that is,
>> without the 'ftp' in front?
>>
>> -tk
>>
>>
>>
>> On Mon, Dec 23, 2019 at 8:15 AM Neil S  wrote:
>>
>>> Yes WinSCP is on Win10 machine. Tried Filezilla on Win10 machine and
>>> popped up an error about certificates not matching. (Which is reasonable as
>>> the core cert is footholds.net
>>>
>>> Tried lftp on the raspberry pi itself and came up with this
>>>
>>> root@pi-Weather:~# lftp -p 21 -u x,yy ftp.mydomain.co.uk
>>> lftp xxx...@ftp.mydomain.co.uk:~> ls
>>> ls: Fatal error: Certificate verification: certificate common name
>>> doesn't match requested host name 'ftp.mydomain.co.uk'
>>> lftp xxx...@ftp.mydomain.co.uk:~>
>>>
>>>
>>> Note I have replaced username with , password with Y and my
>>> domain name with mydomain
>>>
>>> Is it an issues with the remote certificate not being the correct name '
>>> ftpg.mydomain.co.uk' ?
>>>
>>> Neil
>>>
>>>
>>> On Monday, 23 December 2019 12:09:54 UTC, Thomas Keffer wrote:

 Not sure what's happening.

 If I run nmap from my end, it reveals that your ISP is using an
 implementation of Pure-FTPd. Looking through the Pure-FTPd documentation,
 it lists WinSCP
  as being
 compatible, but it doesn't say anything one way or another about Python's
 client implementation. It's possible there's an incompatibility (although I
 doubt it).

 It's also possible it's a firewall issue, although the fact that nmap
 was able to scan the port suggests not.

 You mention you are able to connect with WinSCP. I assume that's on a
 Windows host, not a Linux host. Are you able to connect using any client on
 your Linux box, such as FileZilla, or the FTP command line?

 -tk

 On Mon, Dec 23, 2019 at 2:29 AM Neil S  wrote:

> Have set Debug=2 but there doesn’t seem to be much more useful info.
> Presume I have to look at syslog?
>
> Have also checked messages and user.log but doesn’t seem to be
> anything extra in there either?
>
> I have also replaced the website ftp with the direct IP for the time
> being.
>
>
>
> *With **secure_ftp = true* I get the following in syslog
>
>
>
> root@pi-Weather:~# tail -f /var/log/syslog
>
> Dec 23 09:10:17 localhost weewx[9522]: restx: Ambient: url:
> https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw=ILONDONXXX=XXX=weewx-3.9.2=2019-12-23%2009%3A10%3A00=0.00=135=1.6=1.6=0.00
>
> Dec 23 09:10:17 localhost weewx[9522]: reportengine: Running reports
> for latest time in the database.
>
> Dec 23 09:10:17 localhost weewx[9522]: reportengine: Report
> 'StandardReport' not enabled. Skipping.
>
> Dec 23 09:10:17 localhost weewx[9522]: reportengine: Running report
> 'SeasonsReport'
>
> Dec 23 09:10:18 localhost weewx[9522]: restx: WOW: Published record
> 2019-12-23 09:10:00 GMT (1577092200)
>
> Dec 23 09:10:18 

[weewx-user] slightly related - how do I stop Google from editing my posts in realtime ?

[vince]

I've noticed that Google has a 'very' annoying tendency to edit my posts 
while I'm typing.  This started a few months ago.  I've turned off 
everything I can find.

Result is I can type weewx and other technical terms (here) and it edits 
the blasted thing on me making my posts nonsensical.  ok, more nonsensical 
than normal :-)

This seems to happen in every browser and os, so it's Google 'helping' too 
much.   Does anybody know how to turn it off so I can have it just save 
what I wrote exactly without making any changes on me ?

-- 
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/014f7f22-a1f5-4efd-9e31-d3b75cacfb94%40googlegroups.com.

Re: [weewx-user] Re: Configuration management with WeeWX

[vince]

On Thursday, December 26, 2019 at 9:06:36 PM UTC-8, Ben Cotton wrote:
>
> But in my ideal scenario, I'd like to see something like the way 
> Apache httpd and other daemons parse configs. So there would be 
> /etc/weewx/weewx.conf that would have the default settings and then I 
> could overwrite things as needed in /etc/weewx/weewx.local and/or 
> /etc/weewx/conf.d/*. 
>
>
Yup - there have been multiple discussions along those lines over the 
years, but there were as many 'cons' as there were 'pros' and there was a 
many-thousand-sites pre-existing condition already out there in the field, 
so it was basically decided to stay the course.

Perhaps you might itemize exactly which tasks you are trying to automate 
specifically and maybe we can collectively get you there within the current 
implementation.

For my raspi (not my main site), I settled on:

   - be able to get a working Simulator setup in one step via a bash 
   script, with 'some' of my edits to weewx.conf where sed does the job easily.
   - install all skins with the wee_extension utility
   - install all extensions with the wee_extension utility
   - keep all 'my' skins+extensions+scripts in GitHub since I'd never 
   find's otherwise :-)

At that point, all I'd need to do would be to add in my edits to 
weewx.conf, which admittedly is still to-do:

   - ansible lineinfile is very weak and doesn't work too well with 
   weewx.conf's configobj format
   - ansible blockinfile 'probably' could handle editing skin blocks 
   (example - I have a zillion lines to tweak Belchertown) but I haven't 
   tested it

And of course I'd need to switch from Simulator to my real Driver (could 
have been done in the first step above probably).

But it's not generally a big deal to automate enough.not 100%but 
good enough for my needs.

Some repos you might surf:

   - 
https://github.com/vinceskahan/weewx-install-script/blob/master/install-weewx.sh
 
   - this is a one-step script to install via setup.py that lets you pick your 
   version and git branch 'or' alternately use the dpkg versions.   Edit a 
   couple variables at the top and run on a clean raspi or equivalent 
   Debian(ish) system.
   - I have lots of other repos there for Dockerizing, using Vagrant, etc.
   - Many of them have snippets for using sed to edit in lat/lon and other 
   variables many people edit that are unique enough that it's doable without 
   breaking weewx.conf


Regardless - suggest you start with "I need to automate doing this" and ask 
away.  Somebody's likely already figured out how to do it.  Then you'd just 
need to connect the Legos into a whole that works for you.

-- 
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/236292f7-4d73-405d-91fb-15823a7ecfda%40googlegroups.com.

[weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[Gert Andersen]

Hi

So there are no display consoles that transmit a barometric signal that can 
be intercepted by SDR?

Gert

On Friday, December 27, 2019 at 3:08:30 PM UTC+1, galfert wrote:
>
> Yet another solution to keep using SDR is to get a WH32B from Ecowitt that 
> includes barometric pressure. This would be the same sensor that you would 
> need for the HP2551-C display console as it doesn't have a built in 
> barometric sensor. 

-- 
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/b047ceaf-c33b-4fb1-886c-feda7e68f92f%40googlegroups.com.

Re: [weewx-user] Re: Configuration management with WeeWX

[Ben Cotton]

On Fri, Dec 27, 2019 at 9:57 AM mwall  wrote:
>
>
>
> On Friday, December 27, 2019 at 12:06:36 AM UTC-5, Ben Cotton wrote:
>
>> Another approach would be, at least on RPM-based systems, for the RPM
>> to just write an .rpmnew file and leave the existing config in place.
>
> if you install/update weewx using the redhat (or suse) rpm package, then you 
> get exactly this.
>
No you don't. Updates via the RPM package will overwrite the existing config:
https://github.com/weewx/weewx/blob/master/pkg/weewx.spec.in#L153

So while it writes the .rpmnew file, but it still makes updates to the
existing config file, which is not what I said.


-- 
Ben Cotton

-- 
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/CAJox117faiwAdJ%3DV4DM%3DAbR_T7HSAtevCwHk0jhbBE7moZkzEQ%40mail.gmail.com.

Re: [weewx-user] Failing to upload to web server

[Neil S]

That doesnt work either but then I didnt expect it to as ftp.mycomain.co.uk 
and mydomain.co.uk and www.mydomain.co.uk all resolve to the same IP 
address which is what I tried om Post #3

Anyway thanks for the pointers on lftp. Hammer and possibly nut here but I 
have now got uploads on the go again.

Installed lftp on the weewxx machine (Raspberry Pi) and in the 
\etc\lftp.conf put the lines

*set ssl:verify-certificate no*
*set ftp:ssl-protect-data true*

(OK I know that ignores the certificate but think that it is OK in this 
instance as it is my ISP and all I am uploading is public web pages)

Then upload the files into the weather subdirectory on the server...

*lftp -p 21 -u user,password  ftp.mydomain.co.uk -e "mput /var/www/weewx/* 
-O /weather/; bye"*

Bingo - files uploaded from weewx folder to public web pages.

Now the weewx generates the pages every five minutes (on hour, 5 past 10 
past etc) and in general takes about 80 secs to complete its generation and 
various uploads to Wunderground, WOW Weather etc. So at 2 minutes past, 7 
minutes past, 12 minutes past etc I run the lftp comman as a cron job using 
..

*2-59/5  *  *  *  *  lftp -p 21 -u user,password  ftp.mydomain.co.uk -e 
"mput /var/www/weewx/* -O /weather/; bye"*


As I said most probably, nut , hammer, crack, nut etc etc  but at least 
things are working again. 

Neil



On Monday, 23 December 2019 23:52:31 UTC, Thomas Keffer wrote:
>
> It would appear so, but I'm not much of a SSL expert. 
>
> What happens if you try to connect to simply mydomain.co.uk. that is, 
> without the 'ftp' in front?
>
> -tk
>
>
>
> On Mon, Dec 23, 2019 at 8:15 AM Neil S > 
> wrote:
>
>> Yes WinSCP is on Win10 machine. Tried Filezilla on Win10 machine and 
>> popped up an error about certificates not matching. (Which is reasonable as 
>> the core cert is footholds.net
>>
>> Tried lftp on the raspberry pi itself and came up with this
>>
>> root@pi-Weather:~# lftp -p 21 -u x,yy ftp.mydomain.co.uk
>> lftp xxx...@ftp.mydomain.co.uk:~> ls
>> ls: Fatal error: Certificate verification: certificate common name 
>> doesn't match requested host name 'ftp.mydomain.co.uk'
>> lftp xxx...@ftp.mydomain.co.uk:~>
>>
>>
>> Note I have replaced username with , password with Y and my 
>> domain name with mydomain
>>
>> Is it an issues with the remote certificate not being the correct name '
>> ftpg.mydomain.co.uk' ?
>>
>> Neil
>>
>>
>> On Monday, 23 December 2019 12:09:54 UTC, Thomas Keffer wrote:
>>>
>>> Not sure what's happening.
>>>
>>> If I run nmap from my end, it reveals that your ISP is using an 
>>> implementation of Pure-FTPd. Looking through the Pure-FTPd documentation, 
>>> it lists WinSCP 
>>>  as being 
>>> compatible, but it doesn't say anything one way or another about Python's 
>>> client implementation. It's possible there's an incompatibility (although I 
>>> doubt it).
>>>
>>> It's also possible it's a firewall issue, although the fact that nmap 
>>> was able to scan the port suggests not.
>>>
>>> You mention you are able to connect with WinSCP. I assume that's on a 
>>> Windows host, not a Linux host. Are you able to connect using any client on 
>>> your Linux box, such as FileZilla, or the FTP command line?
>>>
>>> -tk
>>>
>>> On Mon, Dec 23, 2019 at 2:29 AM Neil S  wrote:
>>>
 Have set Debug=2 but there doesn’t seem to be much more useful info. 
 Presume I have to look at syslog? 

 Have also checked messages and user.log but doesn’t seem to be anything 
 extra in there either?

 I have also replaced the website ftp with the direct IP for the time 
 being. 

  

 *With **secure_ftp = true* I get the following in syslog

  

 root@pi-Weather:~# tail -f /var/log/syslog

 Dec 23 09:10:17 localhost weewx[9522]: restx: Ambient: url: 
 https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw=ILONDONXXX=XXX=weewx-3.9.2=2019-12-23%2009%3A10%3A00=0.00=135=1.6=1.6=0.00

 Dec 23 09:10:17 localhost weewx[9522]: reportengine: Running reports 
 for latest time in the database.

 Dec 23 09:10:17 localhost weewx[9522]: reportengine: Report 
 'StandardReport' not enabled. Skipping.

 Dec 23 09:10:17 localhost weewx[9522]: reportengine: Running report 
 'SeasonsReport'

 Dec 23 09:10:18 localhost weewx[9522]: restx: WOW: Published record 
 2019-12-23 09:10:00 GMT (1577092200)

 Dec 23 09:10:18 localhost weewx[9522]: restx: StationRegistry: 
 Published record 2019-12-23 09:10:00 GMT (1577092200)

 Dec 23 09:10:19 localhost weewx[9522]: restx: Wunderground-PWS: 
 Published record 2019-12-23 09:10:00 GMT (1577092200)

 Dec 23 09:10:19 localhost weewx[9522]: reportengine: Found 
 configuration file /etc/weewx/skins/Seasons/skin.conf for report 
 'SeasonsReport'

 Dec 23 09:10:25 

[weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[Gert Andersen]

Hi

Thanks a lot for the advise, I'll look at that solution as well.

Rgds
Gert

On Friday, December 27, 2019 at 3:08:30 PM UTC+1, galfert wrote:
>
> Yet another solution to keep using SDR is to get a WH32B from Ecowitt that 
> includes barometric pressure. This would be the same sensor that you would 
> need for the HP2551-C display console as it doesn't have a built in 
> barometric sensor. 

-- 
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/dd7afc03-7714-476f-813b-22bd11733130%40googlegroups.com.

Re: [weewx-user] Re: Configuration management with WeeWX

[mwall]

On Friday, December 27, 2019 at 12:06:36 AM UTC-5, Ben Cotton wrote:

Another approach would be, at least on RPM-based systems, for the RPM 
> to just write an .rpmnew file and leave the existing config in place. 
>

if you install/update weewx using the redhat (or suse) rpm package, then 
you get exactly this.

-- 
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/3a3229ba-3528-4f46-9cb6-e99ef621ada0%40googlegroups.com.

[weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[galfert]

Yet another solution to keep using SDR is to get a WH32B from Ecowitt that 
includes barometric pressure. This would be the same sensor that you would need 
for the HP2551-C display console as it doesn't have a built in barometric 
sensor. 

-- 
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/ab2552cb-1565-4690-9e12-9849af86e0f2%40googlegroups.com.

[weewx-user] Re: Pressure data - SDR - Ecowitt GW1000/Froggit DP1500

[galfert]

Alternative solution is to use the Interceptor driver with the GW1000 sending 
data with its "Customized Server" settings. But that only sends basic sensors 
and not any of the extra sensors. 

-- 
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/be08ddc6-f0af-401d-aa0a-a3f2ad4a6210%40googlegroups.com.

Re: [weewx-user] Re: weewx unresponsive

[Thomas Keffer]

The debug option tells the system to "log up to" syslog.DEBUG, instead of
the default. So, more information is kept in the log. I don't have a
Raspbian machine around me right now, but I would be surprised if it
changed the destination.

In any case, it's a better idea to look at /var/log/syslog, as it has both
system and weewx messages, making it easy to correlate the two.

-tk

On Fri, Dec 27, 2019 at 1:54 AM Franklin Bockstael 
wrote:

> As asked earlier in this thread I changed debug=0 to debug=1 in
> weewx..conf. From then it started to log to /var/log/weewx.log.
> I thought this was the normal behaviour? Before, when debug=0, it all was
> logged to /var/log/syslog.
> I am a bit confused now on what to show you here from what logfile.
>
> Op donderdag 26 december 2019 23:34:19 UTC+1 schreef Thomas Keffer:
>>
>> It looks to me that neither of these last two log excerpts correspond
>> with the earlier ones you posted. The first is the wrong date (the crash
>> happened on the 24th, not the 25th), and the second is too early in the day.
>>
>> I'm surprised you are not seeing weewx entries in /var/log/syslog. Did
>> you change the logging in any way?
>>
>> I should add that I am traveling, so I do not have an RPi available to
>> remind me of what gets logged where.
>>
>> -tk
>>
>> On Thu, Dec 26, 2019 at 8:37 AM Franklin Bockstael 
>> wrote:
>>
>>> Hi Thomas.
>>>
>>> We are looking at /var/log/weewx.log
>>> This is the output of /var/log/syslog around the time of the first error
>>>
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: entropy added to kernel pool:
>>> 724608
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2 successes: 39
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2 failures: 0
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10)
>>> Monobit: 0
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) Poker: 0
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) Runs: 0
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) Long
>>> run: 0
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10)
>>> Continuous run: 0
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: HRNG source speed:
>>> (min=86.238; avg=499.925; max=835.776)Kibits/s
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS tests speed: (min=1.401;
>>> avg=4.988; max=6.191)Mibits/s
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: Lowest ready-buffers level: 2
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: Entropy starvations: 0
>>> Dec 25 17:11:51 Grandix rngd[526]: stats: Time spent starving for
>>> entropy: (min=0; avg=0.000; max=0)us
>>> Dec 25 17:15:01 Grandix CRON[13002]: (pi) CMD (/home/pi/upload >
>>> /dev/null)
>>> Dec 25 17:15:01 Grandix CRON[13003]: (pi) CMD (/home/pi/launch.sh)
>>> Dec 25 17:15:01 Grandix CRON[12994]: (CRON) info (No MTA installed,
>>> discarding output)
>>> Dec 25 17:17:01 Grandix CRON[13028]: (root) CMD (   cd / && run-parts
>>> --report /etc/cron.hourly)
>>> Dec 25 17:20:01 Grandix CRON[13046]: (pi) CMD (/home/pi/launch.sh)
>>> Dec 25 17:20:01 Grandix CRON[13047]: (pi) CMD (/home/pi/upload >
>>> /dev/null)
>>> Dec 25 17:20:01 Grandix CRON[13038]: (CRON) info (No MTA installed,
>>> discarding output)
>>>
>>>
>>> And on the time of the second error
>>>
>>> Dec 25 22:15:02 Grandix CRON[14832]: (pi) CMD (/home/pi/launch.sh)
>>> Dec 25 22:15:02 Grandix CRON[14833]: (pi) CMD (/home/pi/upload >
>>> /dev/null)
>>> Dec 25 22:15:02 Grandix CRON[14823]: (CRON) info (No MTA installed,
>>> discarding output)
>>> Dec 25 22:17:01 Grandix CRON[14855]: (root) CMD (   cd / && run-parts
>>> --report /etc/cron.hourly)
>>> Dec 25 22:20:01 Grandix CRON[14874]: (pi) CMD (/home/pi/upload >
>>> /dev/null)
>>> Dec 25 22:20:01 Grandix CRON[14877]: (pi) CMD (/home/pi/launch.sh)
>>> Dec 25 22:20:01 Grandix CRON[14866]: (CRON) info (No MTA installed,
>>> discarding output)
>>> Dec 25 22:22:30 Grandix kernel: [0.00] Booting Linux on physical
>>> CPU 0x0
>>> Dec 25 22:22:30 Grandix fake-hwclock[82]: Wed 25 Dec 21:17:01 UTC 2019
>>>
>>>
>>> The fake-hwclock is giving a time of 21:17:01 wich should be 21:22:30.
>>> This is more than 300 seconds difference (the time between 2 messages from
>>> the Vantage console?). Am I very wrong if Isuspect this is the thing that
>>> is giving me those errors and freezes?
>>>
>>> Several pid on startup is caused by me rebooting manually the RPi but in
>>> the log I sometimes find multiple instances of weewx or a new instance with
>>> aother pid.
>>> The question is why the RPi is thinking it should start a new weewx
>>> process.
>>> I looked at top and there is nothing abnormal there. Just one process of
>>> weewx and no abnormal load. Weewx is the only process that is running on
>>> that RPi.
>>> What I see with that strange thing is the dates of occuring and the
>>> timestamp that is mentioned in the log.
>>>
>>> Op donderdag 26 december 2019 13:22:38 UTC+1 schreef Thomas Keffer:

 Could be a systemd issue. 

Re: [weewx-user] Re: Configuration management with WeeWX

[Thomas Keffer]

Through the years, I've looked at lots of different configuration schemes,
but haven't found any I like better.

The big advantage of the present system is that all the state is held in a
single place: weewx.conf. That makes support easy: just post the file. It
also makes it easy to run more than one instance of weewx: just point each
daemon to an appropriate config file. Upgrade merges are easy: just upgrade
a single file, usually through a simple configobj merge.

By contrast, the weewx.d approach spreads state over multiple places.

I have also looked at "drop in" architectures, similar to Apache's
"sites-available" approach. To enable a service, you would symlink its
python file from "services-available" to "services-enabled". I can't
remember exactly why I abandoned the idea, but it came down to python not
liking symbolic links. It also makes remote debugging tough.

No perfect system, but this one has served us well.

-tk


On Thu, Dec 26, 2019 at 10:06 PM Ben Cotton 
wrote:

> On Mon, Dec 23, 2019 at 3:06 PM vince  wrote:
> >
> > Ben - I've asked for changes in the last few years (and Matthew+Tom have
> made many) along the lines of making it a bit easier to do weewx with
> DevOps mindset.   What in particular are you battling ?
> >
> I may be battling my own tendency to over-engineer more than anything.
> I'm really looking at a hypothetical problem than a real one. What
> I've done for now is set up a playbook to install today's current
> version. As infrequently as I reinstall this machine (before
> yesterday, I last did an install probably 10-ish years ago), that's a
> fine approach. I can always update the playbook with a post-upgrade
> config file as needed.
>
> But in my ideal scenario, I'd like to see something like the way
> Apache httpd and other daemons parse configs. So there would be
> /etc/weewx/weewx.conf that would have the default settings and then I
> could overwrite things as needed in /etc/weewx/weewx.local and/or
> /etc/weewx/conf.d/*.
>
> Another approach would be, at least on RPM-based systems, for the RPM
> to just write an .rpmnew file and leave the existing config in place.
> I'm not sure how much effort that would take to keep weewx happy—I
> haven't looked in detail to see what sort of things get changed in the
> config file between releases. Along this line, I'd briefly looked at
> packaging weewx in the Fedora repos (or at least a COPR build), but
> the amount of shell script in the RPM spec file changed my mind. :-)
>
> --
> 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/CAJox116eGQWipneTqwW5jQHamoqNvj-X%2Bk8u9kgJE0OHpZA6_Q%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/CAPq0zEBXmgpGGvgAcddmD2%2BzY1dCtn7rtZ-3wVbPWK-sYNkh-A%40mail.gmail.com.

Re: [weewx-user] Re: weewx unresponsive

[Franklin Bockstael]

As asked earlier in this thread I changed debug=0 to debug=1 in 
weewx..conf. From then it started to log to /var/log/weewx.log.
I thought this was the normal behaviour? Before, when debug=0, it all was 
logged to /var/log/syslog.
I am a bit confused now on what to show you here from what logfile.

Op donderdag 26 december 2019 23:34:19 UTC+1 schreef Thomas Keffer:
>
> It looks to me that neither of these last two log excerpts correspond with 
> the earlier ones you posted. The first is the wrong date (the crash 
> happened on the 24th, not the 25th), and the second is too early in the day.
>
> I'm surprised you are not seeing weewx entries in /var/log/syslog. Did you 
> change the logging in any way?
>
> I should add that I am traveling, so I do not have an RPi available to 
> remind me of what gets logged where.
>
> -tk
>
> On Thu, Dec 26, 2019 at 8:37 AM Franklin Bockstael  > wrote:
>
>> Hi Thomas.
>>
>> We are looking at /var/log/weewx.log
>> This is the output of /var/log/syslog around the time of the first error
>>
>> Dec 25 17:11:51 Grandix rngd[526]: stats: entropy added to kernel pool: 
>> 724608
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2 successes: 39
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2 failures: 0
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) Monobit: 
>> 0
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) Poker: 0
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) Runs: 0
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) Long 
>> run: 0
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS 140-2(2001-10-10) 
>> Continuous run: 0
>> Dec 25 17:11:51 Grandix rngd[526]: stats: HRNG source speed: (min=86.238; 
>> avg=499.925; max=835.776)Kibits/s
>> Dec 25 17:11:51 Grandix rngd[526]: stats: FIPS tests speed: (min=1.401; 
>> avg=4.988; max=6.191)Mibits/s
>> Dec 25 17:11:51 Grandix rngd[526]: stats: Lowest ready-buffers level: 2
>> Dec 25 17:11:51 Grandix rngd[526]: stats: Entropy starvations: 0
>> Dec 25 17:11:51 Grandix rngd[526]: stats: Time spent starving for 
>> entropy: (min=0; avg=0.000; max=0)us
>> Dec 25 17:15:01 Grandix CRON[13002]: (pi) CMD (/home/pi/upload > 
>> /dev/null)
>> Dec 25 17:15:01 Grandix CRON[13003]: (pi) CMD (/home/pi/launch.sh)
>> Dec 25 17:15:01 Grandix CRON[12994]: (CRON) info (No MTA installed, 
>> discarding output)
>> Dec 25 17:17:01 Grandix CRON[13028]: (root) CMD (   cd / && run-parts 
>> --report /etc/cron.hourly)
>> Dec 25 17:20:01 Grandix CRON[13046]: (pi) CMD (/home/pi/launch.sh)
>> Dec 25 17:20:01 Grandix CRON[13047]: (pi) CMD (/home/pi/upload > 
>> /dev/null)
>> Dec 25 17:20:01 Grandix CRON[13038]: (CRON) info (No MTA installed, 
>> discarding output)
>>
>>
>> And on the time of the second error
>>
>> Dec 25 22:15:02 Grandix CRON[14832]: (pi) CMD (/home/pi/launch.sh)
>> Dec 25 22:15:02 Grandix CRON[14833]: (pi) CMD (/home/pi/upload > 
>> /dev/null)
>> Dec 25 22:15:02 Grandix CRON[14823]: (CRON) info (No MTA installed, 
>> discarding output)
>> Dec 25 22:17:01 Grandix CRON[14855]: (root) CMD (   cd / && run-parts 
>> --report /etc/cron.hourly)
>> Dec 25 22:20:01 Grandix CRON[14874]: (pi) CMD (/home/pi/upload > 
>> /dev/null)
>> Dec 25 22:20:01 Grandix CRON[14877]: (pi) CMD (/home/pi/launch.sh)
>> Dec 25 22:20:01 Grandix CRON[14866]: (CRON) info (No MTA installed, 
>> discarding output)
>> Dec 25 22:22:30 Grandix kernel: [0.00] Booting Linux on physical 
>> CPU 0x0
>> Dec 25 22:22:30 Grandix fake-hwclock[82]: Wed 25 Dec 21:17:01 UTC 2019
>>
>>
>> The fake-hwclock is giving a time of 21:17:01 wich should be 21:22:30. 
>> This is more than 300 seconds difference (the time between 2 messages from 
>> the Vantage console?). Am I very wrong if Isuspect this is the thing that 
>> is giving me those errors and freezes? 
>>
>> Several pid on startup is caused by me rebooting manually the RPi but in 
>> the log I sometimes find multiple instances of weewx or a new instance with 
>> aother pid.
>> The question is why the RPi is thinking it should start a new weewx 
>> process.
>> I looked at top and there is nothing abnormal there. Just one process of 
>> weewx and no abnormal load. Weewx is the only process that is running on 
>> that RPi.
>> What I see with that strange thing is the dates of occuring and the 
>> timestamp that is mentioned in the log.
>>
>> Op donderdag 26 december 2019 13:22:38 UTC+1 schreef Thomas Keffer:
>>>
>>> Could be a systemd issue. Perhaps your RPi was low on memory, and 
>>> systemd had to kill weewxd? 
>>>
>>> Things to try:
>>> 1. Which log are we looking at here? If it's a systemd issue, it should 
>>> have told us that it is killing a process. But, not all logs show all 
>>> messages, so it's possible that the systemd messages are ending up 
>>> someplace else.
>>> 2. There are several process IDs appearing on start up. Double check 
>>> that only one instance of weewxd is running.
>>> 3. Using a tool such as "top", check the