[weewx-user] Best Skin for Kiosk (8 inch tablet) Mode

[gary....@gmail.com]

What is the best skin to run unattended on an 8 inch display Android tablet?
I tried Belchertown and while it works, it is mighty small at 4+ feet.

-- 
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/f0ad4ee2-40c9-42f3-a917-7471d8f575f8n%40googlegroups.com.

Re: [weewx-user] Best Skin for Kiosk (8 inch tablet) Mode

[gary....@gmail.com]

It doesn't update, so not useful for a tablet running unattended.

On Saturday, December 19, 2020 at 5:55:59 PM UTC-5 kb1...@gmail.com wrote:

> Look at this one.
>  http://kc1azz.ddns.net/weather/phone.html
>
> Dave-KB1PVH
>
>
> Sent from my Galaxy S9
>
> On Sat, Dec 19, 2020, 5:49 PM gary@gmail.com  
> wrote:
>
>> What is the best skin to run unattended on an 8 inch display Android 
>> tablet?
>> I tried Belchertown and while it works, it is mighty small at 4+ feet.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/f0ad4ee2-40c9-42f3-a917-7471d8f575f8n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/f0ad4ee2-40c9-42f3-a917-7471d8f575f8n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/940d0c54-1529-4198-bf89-2d2b71f553ebn%40googlegroups.com.

Re: [weewx-user] Has Anyone Reached out to Ecowitt about an API or Some other Connectivity with Weewx?

[gary....@gmail.com]

>From the readme:
*As the default GW1000 poll interval is 60 seconds not all loop packets 
will be augmented with GW1000 data.*

You can put whatever value you want in the GW1000 stanza like this for a 15 
second poll.
*poll_interval = 15*


On Saturday, December 19, 2020 at 2:35:32 PM UTC-5 ch...@chrismaness.com 
wrote:

> Is it 20minute poll by default, or 20s?  It only updated once in about the 
> past 25 minutes.
>
> -Chris KQ6UP
> On 12/19/20 7:51 AM, Graham Eddy wrote:
>
> via wifi, see https://github.com/gjr80/weewx-gw1000
>
> On 20 Dec 2020, at 12:37 am, ch...@chrismaness.com wrote:
>
> an API for weewx to poll or receive broadcasts directly from their GW-1000?
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/D48DA951-E007-4AE8-AC1A-8962B52E88E6%40gmail.com
>  
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/adabdf27-36a8-49c9-a74f-a7c3977f17bfn%40googlegroups.com.

[weewx-user] ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting help 
from Rich, have it working well.
In the Seasons skin, I see that ET is reported at 100 times the value in 
the loop packets.
Loop has ET: 0.018
Seasons displays ET 1.80 in

Before I make an entry in weewx.conf StdCalibrate Corrections, where is the 
value calculated for the Seasons skin?
I only find items like these in the skin files:
#if $day.ET.has_data and $day.ET.sum.raw > 0.0
#if $day.ET.has_data and $day.ET.sum.raw > 0.0
$obs.label.ET
$unit.label.ET
$archive.ET.sum.format(add_label=False)

-- 
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/81787de8--4d16-b34e-80a951eba244n%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

I'm running a VP2+ via WiFiLogger2

This is a loop from my weewx instance:
LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
windGustDir: 247.0, windSpeed: 0.0

This is where it appears in Seasons skin.
[image: ET.png]
On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:

> Ultimately ET comes from either your driver or StdWXCalculate, depending 
> on the capabilities of your station (it could also come from another 
> service if your are running a driver that is capable of providing ET as a 
> service). Seasons draws ET data from the database. 
>
> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
> display a number of different ET values/aggregates. Remember that the loop 
> packet value is the amount of ET in the period covered by the loop packet, 
>  Seasons can display the cumulative amount of ET over an archive period, a 
> day, a week, a month or a year depending on what you are looking at.
>
> This construct:
>
> $archive.ET.sum.format(add_label=False)
>
> is used by Seasons to display day, week, month or year ET, so not really 
> able to be compared to a loop value.
>
> Gary
>
> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com wrote:
>
>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>> help from Rich, have it working well.
>> In the Seasons skin, I see that ET is reported at 100 times the value in 
>> the loop packets.
>> Loop has ET: 0.018
>> Seasons displays ET 1.80 in
>>
>> Before I make an entry in weewx.conf StdCalibrate Corrections, where is 
>> the value calculated for the Seasons skin?
>> I only find items like these in the skin files:
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> $obs.label.ET
>> $unit.label.ET
>> $archive.ET.sum.format(add_label=False)
>>
>>

-- 
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/d4816686-0177-4fc9-bdd9-f05d1ff5afcdn%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

Since the ET value wants to be for the loop period, then I'll just let 
weewx calculate this value as I have only ETDay as the smallest interval.
These are the fields I can choose from with my current values from the VP2:
"etday":"0.018"
"etmon":"0.60"
"etyear":"1.95"

Either way, it doesn't seem to be incrementing in the skin and displays a 
suspicious 100 times the loop value.


On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com wrote:

> I'm running a VP2+ via WiFiLogger2
>
> This is a loop from my weewx instance:
> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
> windGustDir: 247.0, windSpeed: 0.0
>
> This is where it appears in Seasons skin.
> [image: ET.png]
> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>
>> Ultimately ET comes from either your driver or StdWXCalculate, depending 
>> on the capabilities of your station (it could also come from another 
>> service if your are running a driver that is capable of providing ET as a 
>> service). Seasons draws ET data from the database. 
>>
>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
>> display a number of different ET values/aggregates. Remember that the loop 
>> packet value is the amount of ET in the period covered by the loop packet, 
>>  Seasons can display the cumulative amount of ET over an archive period, a 
>> day, a week, a month or a year depending on what you are looking at.
>>
>> This construct:
>>
>> $archive.ET.sum.format(add_label=False)
>>
>> is used by Seasons to display day, week, month or year ET, so not really 
>> able to be compared to a loop value.
>>
>> Gary
>>
>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com wrote:
>>
>>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>>> help from Rich, have it working well.
>>> In the Seasons skin, I see that ET is reported at 100 times the value in 
>>> the loop packets.
>>> Loop has ET: 0.018
>>> Seasons displays ET 1.80 in
>>>
>>> Before I make an entry in weewx.conf StdCalibrate Corrections, where is 
>>> the value calculated for the Seasons skin?
>>> I only find items like these in the skin files:
>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>> $obs.label.ET
>>> $unit.label.ET
>>> $archive.ET.sum.format(add_label=False)
>>>
>>>

-- 
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/efb9c3ec-e932-4167-85a1-f46783708102n%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

I removed the ET field from the loop and now see ET 0.00 in the Seasons 
skin.
It's winter so this value has little meaning for me.
In the growing season though, I do use it in my irrigation system that is 
fed local data from WeeWX.


On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com wrote:

> Since the ET value wants to be for the loop period, then I'll just let 
> weewx calculate this value as I have only ETDay as the smallest interval.
> These are the fields I can choose from with my current values from the VP2:
> "etday":"0.018"
> "etmon":"0.60"
> "etyear":"1.95"
>
> Either way, it doesn't seem to be incrementing in the skin and displays a 
> suspicious 100 times the loop value.
>
>
> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com wrote:
>
>> I'm running a VP2+ via WiFiLogger2
>>
>> This is a loop from my weewx instance:
>> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
>> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
>> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
>> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
>> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
>> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
>> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
>> windGustDir: 247.0, windSpeed: 0.0
>>
>> This is where it appears in Seasons skin.
>> [image: ET.png]
>> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>>
>>> Ultimately ET comes from either your driver or StdWXCalculate, depending 
>>> on the capabilities of your station (it could also come from another 
>>> service if your are running a driver that is capable of providing ET as a 
>>> service). Seasons draws ET data from the database. 
>>>
>>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
>>> display a number of different ET values/aggregates. Remember that the loop 
>>> packet value is the amount of ET in the period covered by the loop packet, 
>>>  Seasons can display the cumulative amount of ET over an archive period, a 
>>> day, a week, a month or a year depending on what you are looking at.
>>>
>>> This construct:
>>>
>>> $archive.ET.sum.format(add_label=False)
>>>
>>> is used by Seasons to display day, week, month or year ET, so not really 
>>> able to be compared to a loop value.
>>>
>>> Gary
>>>
>>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com wrote:
>>>
>>>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>>>> help from Rich, have it working well.
>>>> In the Seasons skin, I see that ET is reported at 100 times the value 
>>>> in the loop packets.
>>>> Loop has ET: 0.018
>>>> Seasons displays ET 1.80 in
>>>>
>>>> Before I make an entry in weewx.conf StdCalibrate Corrections, where is 
>>>> the value calculated for the Seasons skin?
>>>> I only find items like these in the skin files:
>>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>>> $obs.label.ET
>>>> $unit.label.ET
>>>> $archive.ET.sum.format(add_label=False)
>>>>
>>>>

-- 
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/fc0fa503-6963-4a48-8b49-f7e14c31efa5n%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

I have a WiFiLogger2 installed exporting json to my mosquitto server. Then 
WeeWX-MQTTSubscribe pulls in the data from the MQTT server.
In StdWXCalculate  ET = prefer_hardware
In StdArchive  record_generation = hardware
On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:

> So where was the ET coming from that was in the loop packet? The vantage 
> driver does not emit field ET in loop packets and the StdWXCalculate 
> service does not calculate an ET field for loop packets. Also are you using 
> software or hardware archive record generation, there are some 
> peculiarities to the hardware archive record ET value emitted by the 
> Vantage driver/station. 
>
> Gary
>
> On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com wrote:
>
>> I removed the ET field from the loop and now see ET 0.00 in the Seasons 
>> skin.
>> It's winter so this value has little meaning for me.
>> In the growing season though, I do use it in my irrigation system that is 
>> fed local data from WeeWX.
>>
>>
>> On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com 
>> wrote:
>>
>>> Since the ET value wants to be for the loop period, then I'll just let 
>>> weewx calculate this value as I have only ETDay as the smallest interval.
>>> These are the fields I can choose from with my current values from the 
>>> VP2:
>>> "etday":"0.018"
>>> "etmon":"0.60"
>>> "etyear":"1.95"
>>>
>>> Either way, it doesn't seem to be incrementing in the skin and displays 
>>> a suspicious 100 times the loop value.
>>>
>>>
>>> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com 
>>> wrote:
>>>
>>>> I'm running a VP2+ via WiFiLogger2
>>>>
>>>> This is a loop from my weewx instance:
>>>> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
>>>> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
>>>> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
>>>> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
>>>> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
>>>> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
>>>> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
>>>> windGustDir: 247.0, windSpeed: 0.0
>>>>
>>>> This is where it appears in Seasons skin.
>>>> [image: ET.png]
>>>> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>>>>
>>>>> Ultimately ET comes from either your driver or StdWXCalculate, 
>>>>> depending on the capabilities of your station (it could also come from 
>>>>> another service if your are running a driver that is capable of providing 
>>>>> ET as a service). Seasons draws ET data from the database. 
>>>>>
>>>>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
>>>>> display a number of different ET values/aggregates. Remember that the 
>>>>> loop 
>>>>> packet value is the amount of ET in the period covered by the loop 
>>>>> packet, 
>>>>>  Seasons can display the cumulative amount of ET over an archive period, 
>>>>> a 
>>>>> day, a week, a month or a year depending on what you are looking at.
>>>>>
>>>>> This construct:
>>>>>
>>>>> $archive.ET.sum.format(add_label=False)
>>>>>
>>>>> is used by Seasons to display day, week, month or year ET, so not 
>>>>> really able to be compared to a loop value.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>>>>>> help from Rich, have it working well.
>>>>>> In the Seasons skin, I see that ET is reported at 100 times the value 
>>>>>> in the loop packets.
>>>>>> Loop has ET: 0.018
>>>>>> Seasons displays ET 1.80 in
>>>>>>
>>>>>> Before I make an entry in weewx.conf StdCalibrate Corrections, where 
>>>>>> is the value calculated for the Seasons skin?
>>>>>> I only find items like these in the skin files:
>>>>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>>>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>>>>> $obs.label.ET
>>>>>> $unit.label.ET
>>>>>> $archive.ET.sum.format(add_label=False)
>>>>>>
>>>>>>

-- 
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/1907bf85-8bd0-4f65-82f8-a1627ba49bfcn%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

Here's an exported json file content.


On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:

> So where was the ET coming from that was in the loop packet? The vantage 
> driver does not emit field ET in loop packets and the StdWXCalculate 
> service does not calculate an ET field for loop packets. Also are you using 
> software or hardware archive record generation, there are some 
> peculiarities to the hardware archive record ET value emitted by the 
> Vantage driver/station. 
>
> Gary
>
> On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com wrote:
>
>> I removed the ET field from the loop and now see ET 0.00 in the Seasons 
>> skin.
>> It's winter so this value has little meaning for me.
>> In the growing season though, I do use it in my irrigation system that is 
>> fed local data from WeeWX.
>>
>>
>> On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com 
>> wrote:
>>
>>> Since the ET value wants to be for the loop period, then I'll just let 
>>> weewx calculate this value as I have only ETDay as the smallest interval.
>>> These are the fields I can choose from with my current values from the 
>>> VP2:
>>> "etday":"0.018"
>>> "etmon":"0.60"
>>> "etyear":"1.95"
>>>
>>> Either way, it doesn't seem to be incrementing in the skin and displays 
>>> a suspicious 100 times the loop value.
>>>
>>>
>>> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com 
>>> wrote:
>>>
>>>> I'm running a VP2+ via WiFiLogger2
>>>>
>>>> This is a loop from my weewx instance:
>>>> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
>>>> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
>>>> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
>>>> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
>>>> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
>>>> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
>>>> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
>>>> windGustDir: 247.0, windSpeed: 0.0
>>>>
>>>> This is where it appears in Seasons skin.
>>>> [image: ET.png]
>>>> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>>>>
>>>>> Ultimately ET comes from either your driver or StdWXCalculate, 
>>>>> depending on the capabilities of your station (it could also come from 
>>>>> another service if your are running a driver that is capable of providing 
>>>>> ET as a service). Seasons draws ET data from the database. 
>>>>>
>>>>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
>>>>> display a number of different ET values/aggregates. Remember that the 
>>>>> loop 
>>>>> packet value is the amount of ET in the period covered by the loop 
>>>>> packet, 
>>>>>  Seasons can display the cumulative amount of ET over an archive period, 
>>>>> a 
>>>>> day, a week, a month or a year depending on what you are looking at.
>>>>>
>>>>> This construct:
>>>>>
>>>>> $archive.ET.sum.format(add_label=False)
>>>>>
>>>>> is used by Seasons to display day, week, month or year ET, so not 
>>>>> really able to be compared to a loop value.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>>>>>> help from Rich, have it working well.
>>>>>> In the Seasons skin, I see that ET is reported at 100 times the value 
>>>>>> in the loop packets.
>>>>>> Loop has ET: 0.018
>>>>>> Seasons displays ET 1.80 in
>>>>>>
>>>>>> Before I make an entry in weewx.conf StdCalibrate Corrections, where 
>>>>>> is the value calculated for the Seasons skin?
>>>>>> I only find items like these in the skin files:
>>>>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>>>>> #if $day.ET.ha

Re: [weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

This seems to work. Currently ET at the logger is 0.002 so it is being 
reported in loop packets as 0.0
I'll see later in the day, but it sounds like exactly what is needed in 
this case.

On Monday, December 28, 2020 at 10:26:13 AM UTC-5 bell...@gmail.com wrote:

> I think the next step would be to capture the loop packets between two 
> archive records and manually sum up the ET values. Or you could estimate 
> the number of loop packets between archive records and if it is close to 
> 100 call it done. Net, it seems like everything is working as expected. 
> MQTTSubscribeDriver is creating the packets. WeeWX is summing the ET values 
> in the packets to create the archive record.
> Mulling this over a bit more, I think setting contains_total = true for 
> your etday field might be the answer. This was added for MQTT rain data 
> that is cumulative to calculate a delta for WeeWX.
> rich
>
> On Sunday, 27 December 2020 at 23:24:59 UTC-5 gjr80 wrote:
>
>> Also, remember under a traditional Davis console/logger/vantage driver 
>> setup you will see approx 120 loop packets per five minute archive record. 
>> So seeing an archive record value that is 100 times a loop value is not 
>> unreasonable for a cumulative field such as ET or rain. The difference here 
>> is that a traditional Davis console/logger/vantage driver setup you do not 
>> see loop ET values.
>>
>> The only way to know if it it working properly is to understand who is 
>> emitting what and then do the maths to confirm the result one way or 
>> another.
>>
>> 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/2ee16cbb-5f40-4ec0-8be9-5d23ee1eda13n%40googlegroups.com.

Re: [weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

Perhaps I need a tutorial on ET as used by reported by WeeWX.
So, I have made the setting change suggested.
Loop values have remained at  ET: 0.0

I'd think the actual value sent by the logger should be the value displayed 
by the skin. Kinda like weatherlink does.

[image: ET-WL.PNG][image: ET-WW1.PNG]

On Monday, December 28, 2020 at 11:10:13 AM UTC-5 gary@gmail.com wrote:

> This seems to work. Currently ET at the logger is 0.002 so it is being 
> reported in loop packets as 0.0
> I'll see later in the day, but it sounds like exactly what is needed in 
> this case.
>
> On Monday, December 28, 2020 at 10:26:13 AM UTC-5 bell...@gmail.com wrote:
>
>> I think the next step would be to capture the loop packets between two 
>> archive records and manually sum up the ET values. Or you could estimate 
>> the number of loop packets between archive records and if it is close to 
>> 100 call it done. Net, it seems like everything is working as expected. 
>> MQTTSubscribeDriver is creating the packets. WeeWX is summing the ET values 
>> in the packets to create the archive record.
>> Mulling this over a bit more, I think setting contains_total = true for 
>> your etday field might be the answer. This was added for MQTT rain data 
>> that is cumulative to calculate a delta for WeeWX.
>> rich
>>
>> On Sunday, 27 December 2020 at 23:24:59 UTC-5 gjr80 wrote:
>>
>>> Also, remember under a traditional Davis console/logger/vantage driver 
>>> setup you will see approx 120 loop packets per five minute archive record. 
>>> So seeing an archive record value that is 100 times a loop value is not 
>>> unreasonable for a cumulative field such as ET or rain. The difference here 
>>> is that a traditional Davis console/logger/vantage driver setup you do not 
>>> see loop ET values.
>>>
>>> The only way to know if it it working properly is to understand who is 
>>> emitting what and then do the maths to confirm the result one way or 
>>> another.
>>>
>>> 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/05684c3e-9fbc-4fdf-b7cf-10d1dfa0d3c1n%40googlegroups.com.

Re: [weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

Thanks for the detailed ET tutorial.
I do have a couple of lingering questions.

For my purposes, it isn't critical to use the MQTT server for data 
acquisition. So, I reset the WeeWX instance to stock/clean state and ran 
./bin/wee_config --reconfig selecting Vantage driver, answering ethernet to 
connection method. In the weewx.conf I do notice I can choose LOOP1, LOOP2, 
or both. I left all at the defaults.

I made one change to the resulting weewx.conf file adding loop_on_init = 
True

With the stock/default settings, I let weewx run for awhile before and 
after the hour.

The first report cycle, the Seasons skin had no ET displayed.
As you said, after the top of the hour, there is ET displayed. However, it 
is 0.00, the High/Low has 0.00 0.00  The loop packet has  dayET: 0.013

I see this in the current.inc and it looks like there should be data 
displayed.
#if $day.ET.has_data and $day.ET.sum.raw is not None and $day.ET.sum.raw > 
0.0
  
$obs.label.ET
$current.ET

My question is this. If the console is reporting ET values, and the skin 
wants to show ET values, when would the skin display the ET value?
On Monday, December 28, 2020 at 11:09:16 PM UTC-5 tke...@gmail.com wrote:

> In WeeWX, ET is treated like any other extensive quantity: a record 
> contains the amount of evaporation that happened during the archive period, 
> *not* the total for the day. Think of it as anti-rain. 
>
> One complication: the Vantage series hardware emits ET only on the top of 
> an hour. It is the amount of evaporation that happened during the hour. So, 
> if you use hardware record generation, expect a non-zero value only once an 
> hour. If you use software generation, it will appear with every archive 
> record. 
>
> That's how WeeWX treats it. As for how it's arriving from your MQTT feed, 
> I have no idea.
>
> Finally, how it appears in a skin depends on what tag is used. Usually you 
> want something like $day.ET.sum, which would be the total ET for the day, 
> just like $day.rain.sum is the total rain for the day.
>
> -tk
>
> On Mon, Dec 28, 2020 at 6:30 PM G Hammer  wrote:
>
>> Well, it reset the etday at midnight I'm going to say. Nothing has been 
>> displayed until now and ET is accumulated mostly during the day.
>> I'm puzzled with this one as it makes zero sense.
>> The way ET works on the console, the WLL and weatherlink.com, and in the 
>> real-time stats from WiFiLogger is as the various parameters that make up 
>> ET grow during a day, the etday is updated. At the end of the day, it is 
>> zeroed.
>>
>> So, the ET value in WeeWX does not accumulate/add that value each time it 
>> is reported. It stays 100 times what is in the loop. etday=1 ET=100, 
>> etday=2 ET=200, if etday stops growing at 2, ET will remain at 200.
>> Somewhere, the calculation is just flat incorrect. WeeWX has no idea what 
>> device is sending the data as the driver is not tied to hardware. No more 
>> records are being sent than are reflected in the loop records, archives are 
>> being created every 300 seconds.
>> I'm going to install a different skin tomorrow and see if this remains 
>> the same.
>> Stay tuned.
>>
>> On Mon, Dec 28, 2020 at 6:58 PM bell...@gmail.com  
>> wrote:
>>
>>> You and me both... It might be worth seeing what a full day looks like. 
>>> Also, if it would work for you using the day/month/year ET values might 
>>> make sense...
>>>
>>> On Monday, 28 December 2020 at 17:31:42 UTC-5 gary@gmail.com wrote:
>>>
>>>> Perhaps I need a tutorial on ET as used by reported by WeeWX.
>>>> So, I have made the setting change suggested.
>>>> Loop values have remained at  ET: 0.0
>>>>
>>>> I'd think the actual value sent by the logger should be the value 
>>>> displayed by the skin. Kinda like weatherlink does.
>>>>
>>>> [image: ET-WL.PNG][image: ET-WW1.PNG]
>>>>
>>>> On Monday, December 28, 2020 at 11:10:13 AM UTC-5 gary@gmail.com 
>>>> wrote:
>>>>
>>>>> This seems to work. Currently ET at the logger is 0.002 so it is being 
>>>>> reported in loop packets as 0.0
>>>>> I'll see later in the day, but it sounds like exactly what is needed 
>>>>> in this case.
>>>>>
>>>>> On Monday, December 28, 2020 at 10:26:13 AM UTC-5 bell...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> I think the next step would be to capture the loop packets between 
>>>>>> two archive records and manually sum up the ET values. Or you could 
>>&g

[weewx-user] Davis VP2 Console Logger Loop 1 vs Loop 2

[gary....@gmail.com]

What is the difference between Loop1 and Loop 2 for WeeWX?
I ask because using Loop 2 alone my transmitter battery value is shown as 
low where the value is Ok with Loop 1.

-- 
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/bb30d1f1-e868-4ba7-bd14-68124489682an%40googlegroups.com.

[weewx-user] Davis VP2, SDR, BMP280

[gary....@gmail.com]

I have a retired friend who has been admiring my PWS and my website and now 
wishes his own.

He doesn't have any other way to obtain the data, so after suggesting the 
WLL or a logger and finding that his funds are tight, we decided on an SDR 
and a BMP280 in a Pi.

Thanks to Luc, the SDR is up and running. We interfaced with the BMP280, 
but I am unable to find a service to read the barometer info into WeeWX.

How do we go about adding the BMP to WeeWX with the SDR?



-- 
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/fc77b0c7-b0a2-4f22-b6ac-e72022120fc1n%40googlegroups.com.

Re: [weewx-user] Davis VP2, SDR, BMP280

[gary....@gmail.com]

I'll take a look at editing in the 280. Since it is a Davis, we have to use 
rtldavis, not the sdr.py driver. In the end, the SDR method gives the basic 
data that comes from the ISS. I may decide if I want to keep the WiFiLogger 
or the WLL and give the other to my friend. Either are easier in WeeWX, and 
more important for him, no worries about updating things. That's my main 
concern with editing/hacking a driver.

On Saturday, January 23, 2021 at 10:02:38 AM UTC-5 rob.s...@googlemail.com 
wrote:

> I have just posted details of how to do it inside sdr.py. Seems a lot 
> simpler that messing with the message queue.
>
> https://infiniteknowledge.co.uk/2021/01/23/adding-sensors-to-a-rpi-weather-station/
>
> On Saturday, 23 January 2021 at 13:55:40 UTC Greg Troxel wrote:
>
>>
>> "gary@gmail.com"  writes:
>>
>> > Thanks to Luc, the SDR is up and running. We interfaced with the 
>> BMP280, 
>> > but I am unable to find a service to read the barometer info into WeeWX.
>> >
>> > How do we go about adding the BMP to WeeWX with the SDR?
>>
>> What I would do, perhaps more complicated than you need, is to run an
>> mqtt broker and publish the pressure and use MQTTSubscribe. But if
>> there's already a temp path, seems best to extend it for pressure.
>> (IIRC the BMP280 does not have humidity, and the BME280 does).
>>
>>

-- 
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/8876f403-e6b4-4ddb-bc8b-75e90c33d880n%40googlegroups.com.

Re: [weewx-user] Davis VP2, SDR, BMP280

[gary....@gmail.com]

Excellent! Just what I was looking for.
Thanks!

On Sunday, January 24, 2021 at 5:33:38 PM UTC-5 storm...@gmail.com wrote:

> Take a look at this driver: https://gitlab.com/wjcarpenter/bme280wx.  It 
> might work with the BMP280.
>
> On Sunday, January 24, 2021 at 3:54:42 PM UTC-5 gary....@gmail.com wrote:
>
>> I'll take a look at editing in the 280. Since it is a Davis, we have to 
>> use rtldavis, not the sdr.py driver. In the end, the SDR method gives the 
>> basic data that comes from the ISS. I may decide if I want to keep the 
>> WiFiLogger or the WLL and give the other to my friend. Either are easier in 
>> WeeWX, and more important for him, no worries about updating things. That's 
>> my main concern with editing/hacking a driver.
>>
>> On Saturday, January 23, 2021 at 10:02:38 AM UTC-5 
>> rob.s...@googlemail.com wrote:
>>
>>> I have just posted details of how to do it inside sdr.py. Seems a lot 
>>> simpler that messing with the message queue.
>>>
>>> https://infiniteknowledge.co.uk/2021/01/23/adding-sensors-to-a-rpi-weather-station/
>>>
>>> On Saturday, 23 January 2021 at 13:55:40 UTC Greg Troxel wrote:
>>>
>>>>
>>>> "gary@gmail.com"  writes: 
>>>>
>>>> > Thanks to Luc, the SDR is up and running. We interfaced with the 
>>>> BMP280, 
>>>> > but I am unable to find a service to read the barometer info into 
>>>> WeeWX. 
>>>> > 
>>>> > How do we go about adding the BMP to WeeWX with the SDR? 
>>>>
>>>> What I would do, perhaps more complicated than you need, is to run an 
>>>> mqtt broker and publish the pressure and use MQTTSubscribe. But if 
>>>> there's already a temp path, seems best to extend it for pressure. 
>>>> (IIRC the BMP280 does not have humidity, and the BME280 does). 
>>>>
>>>>

-- 
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/c6ce0cf5-4bfe-4aea-b005-a3dbe3d5d799n%40googlegroups.com.

[weewx-user] Belchertown Skin, MQTT, Firefox Fail to Connect Kinda Solved

[gary....@gmail.com]

I had an issue where my website worked fine on all browsers except Firefox.
This persisted for many updates of WeeWX, Belchertown skin, and Firefox.

Today, thanks to a kind soul, the issue is 'solved'

It is because of a bug in mosquitto server and its interaction with the way 
Firefox gets the wss connection.

See the info and the solution here:
MQTT Connection Failure with Firefox 


-- 
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/109b258b-ac8c-48d2-827e-dd1b3d749066n%40googlegroups.com.

[weewx-user] Re: Belchertown MQTT Error Firefox

[gary....@gmail.com]

This is a long time issue that FF has not addressed.
At any rate, there is a workaround, at least this worked awhile back:
You set network.http.spdy.websockets to false in about:config
Won't help if the general public using FF tries the site.

More- https://github.com/eclipse/mosquitto/issues/1211

On Tuesday, April 26, 2022 at 5:13:44 PM UTC-4 Martin wrote:

> Hello, I have installed the Belchertown Skin with MQTT Updates. It works 
> online in Edge/Safari Browser with life update.
> The Firefox display " Failed connecting to the weather station".
> Debug information: Cannot connect to MQTT broker
> What is wrong for the Firefox?
> Thank you
> Regards,
> Martin
>

-- 
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/274b0032-a419-4675-8a85-7549d3975ba7n%40googlegroups.com.

Re: [weewx-user] Belchertown Skin - UV & Solar Radiation Sensors

[gary....@gmail.com]

Find this line in weewx.conf
station_observations = "barometer", "dewpoint", "outHumidity", 
"rainWithRainRate"
Add UV and radiation
On Sunday, August 14, 2022 at 1:34:35 PM UTC-4 ccroom wrote:

> I am currently using a data logger.  I also have a Weatherlink Live device 
> and have used the WLLDriver but not using it to extract data at this time.  
> Clay
>
> On Sunday, August 14, 2022 at 12:37:04 PM UTC-4 do...@dougjenkins.com 
> wrote:
>
>> Clay:
>>
>> I have the same setup and I am able to show both UV and Solar Radiation 
>> sensors. First how are you connecting WeeWX to the station? Are you using a 
>> data logger or WeatherLink Live?
>>
>> On Sun, Aug 14, 2022 at 12:23 PM ccroom  wrote:
>>
>>> I just upgrade my station to a Davis Vantage Pro2+ with UV & Solar 
>>> Radiation Sensors.  I am using the basic Belchertown skin and would like it 
>>> now to show the readings from these 2 new sensors.  I have looked at the 
>>> Belchertown instructions and reviewed the weesx.conf file but can't find 
>>> anything to point me in the right direction.  Can someone assist?  Clay
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/fe725267-0a67-4392-8758-27d56be01476n%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/b8ea57c6-c553-4c81-910a-c1f6ad38f681n%40googlegroups.com.

Re: [weewx-user] Belchertown Skin - UV & Solar Radiation Sensors

[gary....@gmail.com]

You can make changes in the skin.conf but that file is replaced when the 
skin is updated. So, you make changes in the Belchertown stanza in 
weewx.conf and that does not change.
The skin is not driver dependent.


On Tuesday, August 16, 2022 at 7:26:09 AM UTC-4 ccroom wrote:

> Gary, that line is in the Belchertown skin.conf file.  I had tried just as 
> you suggested but I must have used an incorrect description for the station 
> observation.  In any event, I made the addition and it populated just 
> fine.  If I decide to revert to the WLLDriver do you know what if any 
> change needs to be made with that driver?  Thought I would ask should 
> someone else may want to know.  Thank you for your help, Clay
>
> On Tuesday, August 16, 2022 at 7:06:39 AM UTC-4 gary@gmail.com wrote:
>
>> Find this line in weewx.conf
>> station_observations = "barometer", "dewpoint", "outHumidity", 
>> "rainWithRainRate"
>> Add UV and radiation
>> On Sunday, August 14, 2022 at 1:34:35 PM UTC-4 ccroom wrote:
>>
>>> I am currently using a data logger.  I also have a Weatherlink Live 
>>> device and have used the WLLDriver but not using it to extract data at this 
>>> time.  Clay
>>>
>>> On Sunday, August 14, 2022 at 12:37:04 PM UTC-4 do...@dougjenkins.com 
>>> wrote:
>>>
>>>> Clay:
>>>>
>>>> I have the same setup and I am able to show both UV and Solar Radiation 
>>>> sensors. First how are you connecting WeeWX to the station? Are you using 
>>>> a 
>>>> data logger or WeatherLink Live?
>>>>
>>>> On Sun, Aug 14, 2022 at 12:23 PM ccroom  wrote:
>>>>
>>>>> I just upgrade my station to a Davis Vantage Pro2+ with UV & Solar 
>>>>> Radiation Sensors.  I am using the basic Belchertown skin and would like 
>>>>> it 
>>>>> now to show the readings from these 2 new sensors.  I have looked at the 
>>>>> Belchertown instructions and reviewed the weesx.conf file but can't find 
>>>>> anything to point me in the right direction.  Can someone assist?  Clay
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "weewx-user" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to weewx-user+...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/weewx-user/fe725267-0a67-4392-8758-27d56be01476n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/weewx-user/fe725267-0a67-4392-8758-27d56be01476n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>

-- 
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/1d76225a-0fbb-4cd0-85fa-c97be1cade42n%40googlegroups.com.

Re: [weewx-user] Re: Power outage without RTC module

[gary....@gmail.com]

Though I have an RTC on both Pi, I install always install chrony
On my primary server, I have chrony running using NTS servers as its time 
source. I allow clients from the LAN on this machine.
I have all other machines that can run it use chrony with my LAN server as 
the only source. If a device only has a time source (NTP) field, I use the 
LAN address of the main server.
Though the load is low, it keeps additional traffic off my WAN and has 
proven to be accurate over the years. More so that NTPD in my location.

I too have come to look for fake-hwclock and remove it.
On Tuesday, August 23, 2022 at 12:06:10 PM UTC-4 cric...@pobox.com wrote:

> My solution was to install ntp, plus add a wait routine in 
> bin/user/extensions that waits for ntpq -pn to
> report sync'd time.  I use that code on the rest of my Rpi's as well.  Can 
> send if interested.  FWIW, the RPi that
> runs my weather station does have a RTC stacked on the serial port 
> (pre-dates said code block).
>
> On Monday, August 22, 2022 at 5:34:27 PM UTC-6 pa...@pauland.net wrote:
>
>> fake-hwclock is just plain silly, by design it sets the OS time to a 
>> known wrong state with the premise that it's a better than nothing choice.
>> Funny the further down the rabbit hole I go the more I see that I don't 
>> like.  Such as debian setting NTPD or timesyncd to use 
>> debian.pool.ntp.org ntp servers.
>> I certainly don't trust their list of rotating servers to all be 
>> accurate. Always set systems to use known highly available servers I trust.
>> It's a jungle out there a minimum you need, Belt, Suspenders, and of 
>> course a good quality Tin Foil Hat.
>>
>> Paul
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> so strange that a simple thing lige starting
>>
>> On Mon, Aug 22, 2022 at 5:28 PM vince  wrote:
>>
>>> On Monday, August 22, 2022 at 10:12:59 AM UTC-7 pa...@pauland.net wrote:
>>>
 Problem I've seen in the past was that on a Rasberry Pi installrd NTP , 
 like I have on every system I've installed since 2004, yet after a power 
 outage weeWx started with a bad Os Time. Investigated and found that if I 
 removed purged fake-hwclock the expected wait for ntp worked. Now on some 
 systems I install ntp others I don't, if it's a PI remove fake-hwclock and 
 even if the machine has a RTC I enable systemd-time-wait-sync.

>>>
>>> Yes - but be careful there.  Lots of os now have that blasted 
>>> fake-hwclock kludge.
>>>
>>> I remove fake-hwclock and install/enable ntpd everywhere and it's nice 
>>> and simple and reliable.  No need to edit anything in weewx at all, which 
>>> is an added plus.
>>>
>>> The pi time-related details are in the FAQ 
>>>  and wiki 
>>> .
>>>
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/221eacc6-2833-420d-ad00-0d6cb4d56c00n%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/e2ac455b-f4bf-459a-a2e0-67d7e626b2cfn%40googlegroups.com.

[weewx-user] Re: How do you enable forecast in Weewx-wdc

[gary....@gmail.com]

weewx.conf
Adjust HTML_ROOT to your paths
Use your WU API key
Get your NWS values and use those.

[[WdcReport]]
skin = weewx-wdc
enable = true
HTML_ROOT = /home/web/wdc
lang = en

[[forecast]]
skin = forecast
HTML_ROOT = /home/web/forecast

[Forecast]
data_binding = forecast_binding
#[[XTide]]
#location = "INSERT_LOCATION_HERE (e.g., Boston)"
[[Zambretti]]
hemisphere = NORTH
[[NWS]]
lid = MAZ011
foid = BOX
[[WU]]
api_key = 
#[[OWM]]
#api_key = INSERT_OWM_API_KEY_HERE
#[[UKMO]]
#api_key = INSERT_UKMO_API_KEY_HERE
#location = INSERT_UK_LOCATION_HERE
#[[Aeris]]
#client_id = INSERT_AERIS_CLIENT_ID_HERE
#client_secret = INSERT_AERIS_CLIENT_SECRET_HERE
#[[WWO]]
#api_key = INSERT_WWO_API_KEY_HERE
#[[DS]]
#api_key = INSERT_DS_API_KEY_HERE


skin.conf
Make adjustments for your location.

# configuration file for the weewx-wdc skin
SKIN_NAME = Weather Data Center
SKIN_VERSION = 2.1.0

[Extras]
# Show a link to the GitHub respository of this skin. Set to False to 
hide.
github_link = True

# This radar image would be available as $Extras.radar_img
#radar_img = https://www.dwd.de/DWD/wetter/radar/radfilm_sac_akt.gif
# This URL will be used as the image hyperlink:
#radar_url =   
 https://www.dwd.de/DE/leistungen/radarbild_film/radarbild_film.html

[[forecast_zambretti]]
enable = True
hemisphere = NORTH  

[[forecast_table_settings]]
source = WU
num_periods = 72
num_days = 5
show_legend = 1
show_hourly = 0
show_day = 1
show_date = 1
show_outlook = 1
show_temp = 1
show_dewpoint = 0
show_humidity = 0
show_wind = 1
show_tides = 0
show_sun = 0
show_moon = 0
show_pop = 1
show_precip = 1
show_obvis = 0

On Thursday, September 29, 2022 at 2:42:44 PM UTC-4 scott.d...@gmail.com 
wrote:

> I am having difficulty enabling the forecast feature in weewx-wdc
> What needs to be included in weewx.conf to have a forecast from WU, AERIS, 
> or NWS?
>
>

-- 
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/06480f6c-add5-4800-97f2-0cba1b33a711n%40googlegroups.com.

[weewx-user] Re: How do you enable forecast in Weewx-wdc

[gary....@gmail.com]

Don't forget that you will need to add the following to the skin. conf
[CheetahGenerator]
search_list_extensions 

user.forecast.ForecastVariables, user.weewx_wdc_forecast.WdcForecastUtil

On Sunday, October 2, 2022 at 11:57:44 AM UTC-4 gary@gmail.com wrote:

> weewx.conf
> Adjust HTML_ROOT to your paths
> Use your WU API key
> Get your NWS values and use those.
>
> [[WdcReport]]
> skin = weewx-wdc
> enable = true
> HTML_ROOT = /home/web/wdc
> lang = en
>
> [[forecast]]
> skin = forecast
> HTML_ROOT = /home/web/forecast
>
> [Forecast]
> data_binding = forecast_binding
> #[[XTide]]
> #location = "INSERT_LOCATION_HERE (e.g., Boston)"
> [[Zambretti]]
> hemisphere = NORTH
> [[NWS]]
> lid = MAZ011
> foid = BOX
> [[WU]]
> api_key = 
> #[[OWM]]
> #api_key = INSERT_OWM_API_KEY_HERE
> #[[UKMO]]
> #api_key = INSERT_UKMO_API_KEY_HERE
> #location = INSERT_UK_LOCATION_HERE
> #[[Aeris]]
> #client_id = INSERT_AERIS_CLIENT_ID_HERE
> #client_secret = INSERT_AERIS_CLIENT_SECRET_HERE
> #[[WWO]]
> #api_key = INSERT_WWO_API_KEY_HERE
> #[[DS]]
> #api_key = INSERT_DS_API_KEY_HERE
>
>
> skin.conf
> Make adjustments for your location.
>
> # configuration file for the weewx-wdc skin
> SKIN_NAME = Weather Data Center
> SKIN_VERSION = 2.1.0
>
> [Extras]
> # Show a link to the GitHub respository of this skin. Set to False to 
> hide.
> github_link = True
>
> # This radar image would be available as $Extras.radar_img
> #radar_img = https://www.dwd.de/DWD/wetter/radar/radfilm_sac_akt.gif
> # This URL will be used as the image hyperlink:
> #radar_url =
> https://www.dwd.de/DE/leistungen/radarbild_film/radarbild_film.html
>
> [[forecast_zambretti]]
> enable = True
> hemisphere = NORTH  
>
> [[forecast_table_settings]]
> source = WU
> num_periods = 72
> num_days = 5
> show_legend = 1
> show_hourly = 0
> show_day = 1
> show_date = 1
> show_outlook = 1
> show_temp = 1
> show_dewpoint = 0
> show_humidity = 0
> show_wind = 1
> show_tides = 0
> show_sun = 0
> show_moon = 0
> show_pop = 1
> show_precip = 1
> show_obvis = 0
>
> On Thursday, September 29, 2022 at 2:42:44 PM UTC-4 scott.d...@gmail.com 
> wrote:
>
>> I am having difficulty enabling the forecast feature in weewx-wdc
>> What needs to be included in weewx.conf to have a forecast from WU, 
>> AERIS, or NWS?
>>
>>

-- 
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/0bf02b15-e5b0-4a8e-85f7-52c887a946a7n%40googlegroups.com.

Re: [weewx-user] Need help for a "fresh" upgrade

[gary....@gmail.com]

Are you using / as the WEEWX_ROOT?
That would be the problem.
Look at the exiting/old weewx.conf and change the WEEWX_ROOT to that old 
value.

Mine, for example is
# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /home/weewx
On Sunday, September 25, 2022 at 9:02:45 PM UTC-4 Yves Martin wrote:

> it does not. See what I did before in the previous message. I believe I 
> forget something.
>
> YM[image: Screen Shot 2022-09-25 at 9.02.07 PM.png]
>
> Le dimanche 25 septembre 2022 à 12 h 13 min 34 s UTC-4, 
> peterq...@gmail.com a écrit :
>
>> The upgrade should ask which to use and leave a copy of the old one as 
>> weewx.conf-4.8.0 in ./etc/weewx directory
>>
>> On Sun, Sep 25, 2022 at 8:01 AM Yves Martin  wrote:
>>
>>> Hi,
>>>
>>> I'm using weewx since years now and it works like a charm. I've decided 
>>> to upgrade my old version 3.9.2 to the last one 4.8.x ... and in the same 
>>> time, change the Raspberry Pi 2 to the version 4. The objective is to be 
>>> able to use the AirLink from Davis and integrate it in the meteo station. 
>>> For that, I need a more recent version, and an upgrade of python.
>>>
>>> What I did :
>>> - Installed a fresh new version of Debian on a new Raspberry Pi 4b.
>>> Copied all files on my weewx to the new one following the documentation :
>>>
>>> WeeWX root directoryWEEWX_ROOT/
>>> ExecutablesBIN_ROOT/usr/share/weewx/
>>> Configuration directoryCONFIG_ROOT/etc/weewx/
>>> Skins and templatesSKIN_ROOT/etc/weewx/skins/
>>> SQLite databasesSQLITE_ROOT/var/lib/weewx/
>>> Web pages and imagesHTML_ROOT/var/www/html/weewx/
>>> DocumentationDOC_ROOT/usr/share/doc/weewx/
>>> ExamplesEXAMPLE_ROOT/usr/share/doc/weewx/examples/
>>> User directory/usr/share/weewx/user
>>>
>>> then I try to upgrade the version I have to the version 4 : /etc/weewx# 
>>> dpkg -i python-weewx_4.0.0-1_all.deb
>>>
>>> My issue is, the upgrade do not use my old "weewx.conf" and will create 
>>> a new conf file...
>>>
>>> Is there something I've missed?
>>>
>>> Regards,
>>> YMartin.com/meteo
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/4d54b085-9c69-47b1-a6a5-58bee4b35e92n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Peter Quinn
>> (415)794-2264 <(415)%20794-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/62c4ee7c-335f-4c24-8670-e81120670dfan%40googlegroups.com.

[weewx-user] Re: rtgd-0.5.5 extension Wind Direction Average

[gary....@gmail.com]

Use the MQTT driver which takes the data directly from your mosquitto 
server.
Avoids all the middleware.
I use Rich's excellent package.
https://github.com/bellrichm/WeeWX-MQTTSubscribe


On Monday, October 31, 2022 at 3:34:05 PM UTC-4 marsha...@gmail.com wrote:

> Built a new station using an esp32 which mqtt’s data every second to a 
> Raspi. A python program converts this to a txt file which I then file parse 
> into weewx. All ok.
> I have successfully installed the steelseries gauges and the rtgd 
> extension. All works fine and it is fantastic to see the gauges updating in 
> real time.
>
> Just one small problem - the Wind Direction gauge shows latest and 
> average, but the average is always the same as the latest. Tried playing 
> with the rtgd.py program but even when I set data[avgdirection] to a 
> different value, nothing  changes.
>
> Any ideas?
>

-- 
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/a297ee91-d20e-444e-9162-025ec99419e7n%40googlegroups.com.

[weewx-user] Re: Weewx won't Install Correctly Mint 20.3 UNA

[gary....@gmail.com]

Vantage console may need the driver at the end of this thread.

https://groups.google.com/g/weewx-user/c/E6qRpJHKwHw


On Friday, November 11, 2022 at 5:23:26 PM UTC-5 timwill...@gmail.com wrote:

> sudo tail -f /var/log/syslog
> Nov 11 16:19:39 willie-ThinkPad-X131e weewx[10244] INFO __main__: PID file 
> is /var/run/weewx.pid
> Nov 11 16:19:39 willie-ThinkPad-X131e weewx[10247] DEBUG __main__: 
> Initializing engine
> Nov 11 16:19:39 willie-ThinkPad-X131e weewx[10247] INFO weewx.engine: 
> Loading station type Vantage (weewx.drivers.vantage)
> Nov 11 16:19:39 willie-ThinkPad-X131e weewx[10247] DEBUG 
> weewx.drivers.vantage: Driver version is 3.4.0
> Nov 11 16:19:39 willie-ThinkPad-X131e weewx[10247] DEBUG 
> weewx.drivers.vantage: Option loop_request=1
> Nov 11 16:19:39 willie-ThinkPad-X131e weewx[10247] DEBUG 
> weewx.drivers.vantage: Opened up serial port /dev/ttyUSB0; baud 19200; 
> timeout 4.00
> Nov 11 16:19:39 willie-ThinkPad-X131e weewx[10222]:...done.
> Nov 11 16:19:39 willie-ThinkPad-X131e systemd[1]: Started LSB: weewx 
> weather system.
> Nov 11 16:19:43 willie-ThinkPad-X131e weewx[10247] DEBUG 
> weewx.drivers.vantage: Wakeup retry #1 failed: Expected to read 2 chars; 
> got 0 instead
> Nov 11 16:19:48 willie-ThinkPad-X131e weewx[10247] DEBUG 
> weewx.drivers.vantage: Wakeup retry #2 failed: Expected to read 2 chars; 
> got 0 instead
> Nov 11 16:19:53 willie-ThinkPad-X131e weewx[10247] DEBUG 
> weewx.drivers.vantage: Wakeup retry #3 failed: Expected to read 2 chars; 
> got 0 instead
> Nov 11 16:19:58 willie-ThinkPad-X131e weewx[10247] DEBUG 
> weewx.drivers.vantage: Wakeup retry #4 failed: Expected to read 2 chars; 
> got 0 instead
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] ERROR 
> weewx.drivers.vantage: Unable to wake up Vantage console
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] ERROR weewx.engine: 
> Import of driver failed: Unable to wake up Vantage console ( 'weewx.WakeupError'>)
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   Traceback (most recent call last):
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/engine.py", line 119, in 
> setupStation
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   self.console = loader_function(config_dict, self)
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/vantage.py", line 40, in 
> loader
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   return VantageService(engine, config_dict)
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/vantage.py", line 1939, in 
> __init__
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   Vantage.__init__(self, **config_dict[DRIVER_NAME])
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/vantage.py", line 521, in 
> __init__
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   self._setup()
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/vantage.py", line 1340, in 
> _setup
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   self.port.wakeup_console(max_tries=self.max_tries)
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/vantage.py", line 118, in 
> wakeup_console
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   raise weewx.WakeupError("Unable to wake up Vantage console")
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL weewx.engine: 
>   weewx.WakeupError: Unable to wake up Vantage console
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL __main__: 
> Unable to load driver: Unable to wake up Vantage console
> Nov 11 16:20:00 willie-ThinkPad-X131e weewx[10247] CRITICAL __main__: 
>   Exiting...
>
>
>
>
> On Thursday, November 10, 2022 at 10:15:25 PM UTC-6 Tim Williams wrote:
>
>> updated Log: 
>>
>> Nov 10 22:04:43 willie-ThinkPad-X131e weewx[17857] CRITICAL weewx.engine: 
>>   Vantage.__init__(self, **config_dict[DRIVER_NAME])
>> Nov 10 22:04:43 willie-ThinkPad-X131e weewx[17857] CRITICAL weewx.engine: 
>> File "/usr/share/weewx/weewx/drivers/vantage.py", line 521, in 
>> __init__
>> Nov 10 22:04:43 willie-ThinkPad-X131e weewx[17857] CRITICAL weewx.engine: 
>>   self._setup()
>> Nov 10 22:04:43 willie-ThinkPad-X131e weewx[17857] CRITICAL weewx.engine: 
>> File "/usr/share/weewx/weewx/drivers/vantage.py", line 1340, in 
>> _setup
>> Nov 10 22:04:43 willie-Thin

[weewx-user] Re: WeeWX 4.6.2 Working Well

[gary....@gmail.com]

No, no need for anything other than the in-built driver.
Pretty self explanatory once you config with the Davis driver.

##

[Vantage]
# This section is for the Davis Vantage series of weather stations.

# Connection type: serial or ethernet 
#  serial (the classic VantagePro)
#  ethernet (the WeatherLinkIP or Serial-Ethernet bridge)
type = ethernet

# If the connection type is serial, a port must be specified:
#   Debian, Ubuntu, Redhat, Fedora, and SuSE:
# /dev/ttyUSB0 is a common USB port name
# /dev/ttyS0   is a common serial port name
#   BSD:
# /dev/cuaU0   is a common serial port name
port = /dev/ttyUSB0

# If the connection type is ethernet, an IP Address/hostname is 
required:
host = 10.10.10.10

##
# The rest of this section rarely needs any attention. 
# You can safely leave it "as is."
##

# Serial baud rate (usually 19200)
baudrate = 19200

# TCP port (when using the WeatherLinkIP)
tcp_port = 2

# TCP send delay (when using the WeatherLinkIP):
tcp_send_delay = 0.5

# The type of LOOP packet to request: 1 = LOOP1; 2 = LOOP2; 3 = both
loop_request = 3

# The id of your ISS station (usually 1). If you use a wind meter 
connected
# to a anemometer transmitter kit, use its id
iss_id = 1

# How long to wait for a response from the station before giving up (in
# seconds; must be greater than 2)
timeout = 4

# How long to wait before trying again (in seconds)
wait_before_retry = 1.2

# How many times to try before giving up:
max_tries = 4

# Vantage model Type: 1 = Vantage Pro; 2 = Vantage Pro2
model_type = 2

# The driver to use:
driver = weewx.drivers.vantage

##
On Wednesday, November 16, 2022 at 12:30:00 PM UTC-5 Kev D wrote:

> Hi Gary,
>
> I have just upgraded my setup to  VP2, WifiLogger2, and Belchertown skin 
> as well. Would you mind sharing your configuration setup in weewx to grab 
> data from the WifiLogger2? Are you also using the interceptor driver for 
> this config?
>
> Thanks!
>
> On Friday, February 11, 2022 at 9:00:57 AM UTC-5 gary@gmail.com wrote:
>
>> With the rapid succession of releases, I just wanted to say that my 
>> upgrade to 4.6.2 went well and all is working with the VP2, WifiLogger2, 
>> and Belchertown skin.
>>
>> Thanks for an amazing system!
>>
>

-- 
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/ac88d0b0-6adf-4048-8359-b031954f188an%40googlegroups.com.

Re: [weewx-user] Re: mqtt issues

[gary....@gmail.com]

What are you using to try the connection?
I'd recommend https://mqtt-explorer.com/ to see what the mosquitto server 
is showing. MQTT Explorer has the option to look at websockets as well as 
MQTT. But first you want to see the loop values in MQTT.

If you are using Firefox, you should also get the latest mosquitto server 
direct from the developer by using the repository. Once I did that, my 
Firefox issues went away. Depending on distro, version, etc your distro may 
not have a current/new enough mosquitto server to solve the FF issue.

We'd also need to see your mosquitto.conf including if you followed Pat's 
guide, myconfig.conf. It could also be your acl file, or that the password 
is not correct, but if weewx is sending data and it is accepted, unlikely 
it is that.

On Saturday, November 26, 2022 at 2:38:32 PM UTC-5 vanuxe...@gmail.com 
wrote:

> I installed mqtt as an wee_extensions,
> And followed the instructions.
>
> I installed the mqtt broker as instructed, mosquito, as instructed on the 
> belchertown wiki. 
>
> Both portsaus 1883 and 9001 are open in my ubuntu running in a virtual box 
> environment.
>
> I checked your links, thx for that. But that also was followed.
>
> By glad if you had more specifics 
>
>
> Thx
>
>
>
> Op za 26 nov. 2022 20:17 schreef vince :
>
>> Connection refused means the computer you specified (localhost) is not 
>> listening on the port you specified (9001).   So you have more software to 
>> install and configure in addition to weewx and the skin.
>>
>> Reread 
>> https://github.com/poblabs/weewx-belchertown#mqtt-and-mqtt-websockets-optional
>>  
>> and https://github.com/poblabs/weewx-belchertown#mqtt-brokers for what 
>> is needed and how to do it.
>>
>> On Saturday, November 26, 2022 at 5:52:55 AM UTC-8 vanuxe...@gmail.com 
>> wrote:
>>
>>> Hi 
>>>
>>> I'm trying to set mqtt inside the belchertown skin.
>>>
>>> i can see that my data is getting published in the syslog.
>>>
>>> however the connection fails in my website
>>>
>>> in the developer i get this: 
>>>
>>> WebSocket connection to 'ws://localhost:9001/mqtt' failed: Error in 
>>> connection establishment: net::ERR_CONNECTION_REFUSED
>>>
>>> my set in the belchertown skin.conf is this
>>>
>>> # MQTT Websockets defaults
>>> mqtt_websockets_enabled = 1
>>> mqtt_websockets_host = "localhost"
>>> mqtt_websockets_port = 9001
>>> mqtt_websockets_ssl = 0
>>> mqtt_websockets_topic = "weather"
>>> disconnect_live_website_visitor = 180
>>>
>>> in weewx.conf its this
>>>
>>> [[MQTT]]
>>> server_url = mqtt://alex:passwd@localhost:1883/
>>> topic = weather
>>> unit_system = METRIC
>>> binding = archive, loop
>>> aggregation = aggregate
>>>
>>> can somebody point me in the direct direction, please?
>>>
>>> thank 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/841ec5a0-f416-45db-938b-74753ccd645an%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/a1cb8ac4-5a5b-4dfa-9f26-0656e84efb1en%40googlegroups.com.

Re: [weewx-user] Re: mqtt issues

[gary....@gmail.com]

I'll agree that localhost can't be used, for testing I use the LAN address. 
For me it  is 10.10.10.15
It's how I run my test server instance which has no SSL certs.
http://tester.lan/jas/ for example brings up the jas skin with websockets 
functioning from any device on my LAN.
But, if you have no local DNS resolver, http://10.10.100.15/jas would be 
needed.


On Sunday, November 27, 2022 at 5:05:10 AM UTC-5 mh081...@gmail.com wrote:

> Hi,
>
> you  shouldn't use "localhost" in your config.If you connect to your 
> website with your browser, then locahlost are used to connect to the mqtt 
> server.
> This failed if you try to connect from your client. I think it will only 
> be possible when you start the browser from the mqtt server direct.
>
> From my Config (i use ssl):
>
> # weewx.confall configs from belchertown are in my weewx.conf 
> because of possible update of weewx#
> [[MQTT]]
> server_url = mqtt://pi:pass...@gw.martenhinrichs.de:8883/ 
> <http://pi:passw...@gw.martenhinrichs.de:8883/>
>
> topic = weather
> unit_system = METRIC
> binding = archive, loop
> aggregation = aggregate
> log_success = False
> log_failure = True
> [[[tls]]]
> tls_version = tlsv12
> ca_certs = /etc/ssl/certs/ca-certificates.crt
> [[[inputs]]]
> dayRain
> name = dayRain_mm
> units = mm
> rainRate
> name = rainRate_mm_per_hour
> units = mm_per_hour
> #
>
> #/etc/mosquitto/conf.d/myconfig.conf
> allow_anonymous true
> password_file /etc/mosquitto/passwd
> acl_file /etc/mosquitto/acl
> persistence false
>
> # mqtt
> listener 1883 localhost
> listener 8883
> certfile /etc/letsencrypt/live/gw.martenhinrichs.de/cert.pem
> cafile /etc/letsencrypt/live/gw.martenhinrichs.de/chain.pem
> keyfile /etc/letsencrypt/live/gw.martenhinrichs.de/privkey.pem
> protocol mqtt
>
> # websockets
> listener 9001
> certfile /etc/letsencrypt/live/gw.martenhinrichs.de/cert.pem
> cafile /etc/letsencrypt/live/gw.martenhinrichs.de/chain.pem
> keyfile /etc/letsencrypt/live/gw.martenhinrichs.de/privkey.pem
> protocol websockets
> #
>
> # /etc/mosquitto/mosquitto.conf
> pid_file /run/mosquitto/mosquitto.pid
>
> persistence true
> persistence_location /var/lib/mosquitto/
>
> log_dest file /var/log/mosquitto/mosquitto.log
> log_type error
> log_type warning
> connection_messages false
> #
>
> gary@gmail.com schrieb am Sonntag, 27. November 2022 um 03:38:46 
> UTC+1:
>
>> What are you using to try the connection?
>> I'd recommend https://mqtt-explorer.com/ to see what the mosquitto 
>> server is showing. MQTT Explorer has the option to look at websockets as 
>> well as MQTT. But first you want to see the loop values in MQTT.
>>
>> If you are using Firefox, you should also get the latest mosquitto server 
>> direct from the developer by using the repository. Once I did that, my 
>> Firefox issues went away. Depending on distro, version, etc your distro may 
>> not have a current/new enough mosquitto server to solve the FF issue.
>>
>> We'd also need to see your mosquitto.conf including if you followed Pat's 
>> guide, myconfig.conf. It could also be your acl file, or that the password 
>> is not correct, but if weewx is sending data and it is accepted, unlikely 
>> it is that.
>>
>> On Saturday, November 26, 2022 at 2:38:32 PM UTC-5 vanuxe...@gmail.com 
>> wrote:
>>
>>> I installed mqtt as an wee_extensions,
>>> And followed the instructions.
>>>
>>> I installed the mqtt broker as instructed, mosquito, as instructed on 
>>> the belchertown wiki. 
>>>
>>> Both portsaus 1883 and 9001 are open in my ubuntu running in a virtual 
>>> box environment.
>>>
>>> I checked your links, thx for that. But that also was followed.
>>>
>>> By glad if you had more specifics 
>>>
>>>
>>> Thx
>>>
>>>
>>>
>>> Op za 26 nov. 2022 20:17 schreef vince :
>>>
>>>> Connection refused means the computer you specified (localhost) is not 
>>>> listening on the port you specified (9001).   So you have more software to 
>>>> install and configure in addition to weewx and the skin.
>>>>
>>>> Reread 
>>>> https://github.com/poblabs/weewx-belchertown#mqtt-and-mqtt-websockets-optional
>>>>  
>>>> and https://github.com/p

Re: [weewx-user] Re: mqtt issues

[gary....@gmail.com]

You are trying to mix secure with non-secure and that is not going to work.

Mixed Content: The page at 
'https://www.sint-katelijne-waver-meteo.be/weewx/' was loaded over HTTPS, 
but attempted to connect to the insecure WebSocket endpoint 
'ws://192.168.0.125:9001/mqtt'. This request has been blocked; this 
endpoint must be available over WSS.

Uncaught DOMException: Failed to construct 'WebSocket': An insecure 
WebSocket connection may not be initiated from a page loaded over HTTPS.

Either test using http (no 's') or add the certs to your mosquitto config 
and change the belchertown settings accordingly.

On Sunday, November 27, 2022 at 4:25:16 PM UTC-5 vanuxe...@gmail.com wrote:

> hi all,
>
> at  https://mqtt-explorer.com i can see data coming in, also i can test 
> by publishing "hello world"
>
> i've downloaded the latest version from the mosquitto developer
>
> if i change the localhost to 192.168.0.125 i get a wss error, the 
> connection doesn't fail anymore but is trying to connect endlessly.
>
> if I change even the weewx.conf with
>  log_success = False
> log_failure = True
>  
> my weewx will not start
>
> i tried to set up a domain with duckdns.org with suces but can't create a 
> ssl certificate.
>
> please advise, i'm lost now.
>
> please find all the logs in the attached txt file.
>
> i guess my paid server will not allow websockets?
>
> also i'm running a ubuntu in a virtual box, and is bridged with my windows 
> machine
> my windows ip is 192.168.0.189
> my ubuntu local is 127.0.0.1
> my bridged ubuntu is 192.168.0.125
>
> chrome, edge, firefox give the same error
>
> thank you so much!!
>
>
>
> Op zondag 27 november 2022 om 16:54:14 UTC+1 schreef gary@gmail.com:
>
>> I'll agree that localhost can't be used, for testing I use the LAN 
>> address. For me it  is 10.10.10.15
>> It's how I run my test server instance which has no SSL certs.
>> http://tester.lan/jas/ for example brings up the jas skin with 
>> websockets functioning from any device on my LAN.
>> But, if you have no local DNS resolver, http://10.10.100.15/jas would be 
>> needed.
>>
>>
>> On Sunday, November 27, 2022 at 5:05:10 AM UTC-5 mh081...@gmail.com 
>> wrote:
>>
>>> Hi,
>>>
>>> you  shouldn't use "localhost" in your config.If you connect to your 
>>> website with your browser, then locahlost are used to connect to the mqtt 
>>> server.
>>> This failed if you try to connect from your client. I think it will only 
>>> be possible when you start the browser from the mqtt server direct.
>>>
>>> From my Config (i use ssl):
>>>
>>> # weewx.confall configs from belchertown are in my weewx.conf 
>>> because of possible update of weewx#
>>> [[MQTT]]
>>> server_url = mqtt://pi:pass...@gw.martenhinrichs.de:8883/ 
>>> <http://pi:passw...@gw.martenhinrichs.de:8883/>
>>>
>>> topic = weather
>>> unit_system = METRIC
>>> binding = archive, loop
>>> aggregation = aggregate
>>> log_success = False
>>> log_failure = True
>>> [[[tls]]]
>>> tls_version = tlsv12
>>> ca_certs = /etc/ssl/certs/ca-certificates.crt
>>> [[[inputs]]]
>>> dayRain
>>> name = dayRain_mm
>>> units = mm
>>> rainRate
>>> name = rainRate_mm_per_hour
>>> units = mm_per_hour
>>> #
>>>
>>> #/etc/mosquitto/conf.d/myconfig.conf
>>> allow_anonymous true
>>> password_file /etc/mosquitto/passwd
>>> acl_file /etc/mosquitto/acl
>>> persistence false
>>>
>>> # mqtt
>>> listener 1883 localhost
>>> listener 8883
>>> certfile /etc/letsencrypt/live/gw.martenhinrichs.de/cert.pem
>>> cafile /etc/letsencrypt/live/gw.martenhinrichs.de/chain.pem
>>> keyfile /etc/letsencrypt/live/gw.martenhinrichs.de/privkey.pem
>>> protocol mqtt
>>>
>>> # websockets
>>> listener 9001
>>> certfile /etc/letsencrypt/live/gw.martenhinrichs.de/cert.pem
>>> cafile /etc/letsencrypt/live/gw.martenhinrichs.de/chain.pem
>>> keyfile /etc/letsencrypt/live/gw.martenhinrichs.de/privkey.pem
>>> protocol websockets
>>> #
>>>
>>> # /etc/mosquitto/mosquitto.conf
>>> pid_file 

Re: [weewx-user] Re: weewx server?

[gary....@gmail.com]

Thanks for this. I have a use case for the tunnels and had no idea this 
existed.

On Wednesday, January 4, 2023 at 7:17:48 AM UTC-5 tke...@gmail.com wrote:

> Pretty cool. I had no idea Cloudflare offered this.
>
> On Tue, Jan 3, 2023 at 6:40 PM Doug Jenkins  wrote:
>
>> If you are willing to roll up your sleeves and get technical, serving 
>> your website at home can be done safely and securely without changing your 
>> firewall. There are some steps to do, but at the end it will save you money 
>> and it will give you some real-world IT experience.
>>
>> So to self-host your WeeWX website, I would do the following
>>
>> NOTE: This is a high-level checklist. there are lot of steps for each 
>> item.
>>
>> 1. Get a domain name. Porkbun.com is cheap, but Google Domains works too.
>> 2. You need to have a NameServer Service to tell the internet where your 
>> website is. My checklist will use CloudFlare (free). They have a bunch of 
>> services that we are going to use to make this happen.
>> 3. Once you buy your domain name, you will need to point it to 
>> Cloudflare's Servers. Cloudflare's setup will walk you through it. This 
>> will take 4 - 24 hours to propagate across the internet (your response may 
>> vary).
>> 4. Once it is propagated (Cloudflare sends an email to you), You will 
>> setup your website inside the tool. We are going to setup "Zero Trust" 
>> tunnel that will create a secure tunnel between cloudflare and your server. 
>> I have a video that walks this whole process through (including configuring 
>> cloudflare)
>>
>> https://youtu.be/eojWaJQvqiw
>>
>> This tunnel is the KEY. This tunnel will encrypt the traffic coming to 
>> your domain, secure your domain with an SSL Certificate, and essentially 
>> expose it directly on your server. Again this service is free for small 
>> domains (like weather station sites!) and does not expose your network to 
>> the internet directly.
>>
>> 5. Within the tool you will configure your Server name and the port (80) 
>> that your webserver is now hosting your WeeWX site. You will have to 
>> install a package from Cloudflare to act as the broker for the connection. 
>> The video goes over a container-approach, but in Cloudflare's 
>> documentation, they cover a linux server install.
>>
>> The benefits of doing this approach are:
>>
>> 1. Site gets a free SSL certificate (https:) that is handled by Cloudflare
>> 2. Cloudflare acts as a reverse proxy to broker your connection from the 
>> internet to your server and port. 
>> 3. connection between Cloudflare and your server is secure. You do not 
>> need to open a port for this.
>> 4. You get website statistics and other security features for your 
>> website for free from cloudflare.
>>
>> Check out the video and let me know if this helps. There are other 
>> resources on the internet that can help on this setup.
>>
>> Doug Jenkins
>>
>> On Tue, Jan 3, 2023 at 11:46 AM vince  wrote:
>>
>>> If you're asking that question, you really shouldn't do it for security 
>>> reasons.  There are s many bots and automated scanners out there 
>>> looking for victim sites that you'd be massively attacked within literally 
>>> a minute or two. Please don't.  Really.
>>>
>>> But to answer - you'd need to alter your home firewall to permit 
>>> incoming web traffic to 'only' that computer and tcp/ip port.  Ideally you 
>>> would have your webserver also running 'only' https (a bit hard on a LAN to 
>>> do), have lots of logging (syslog), blocking typical attacks (fail2ban) and 
>>> hopefully even alerting that attacks are even happening.  You should also 
>>> segment your network so it's on an isolated VLAN so it can't be used as a 
>>> jumping off point to attack your other home network devices.  That requires 
>>> special network hardware usually, and some additional level of expertise.  
>>> It's a big lift to do correctly.
>>>
>>> Simpler answer is to spend a few bucks/month and spin up a AWS Lightsail 
>>> VM and use weewx's RSYNC uploader to update the Internet webserver with the 
>>> weewx-generated data automatically.  Lightsail is free for 3 months trial, 
>>> then $3.50/month.  Small price to pay for peace of mind.
>>>
>>> You'd still have to harden your Lightsail VM, but that's far easier to 
>>> learn how to do.  Get a lets-encrypt ssl certificate to use only https.  
>>> Use the Lightsail console to let 'just' https in.  Install fail2ban.   Very 
>>> doable.  Lots of guides out there for how to do so if you google a bit.
>>>
>>>
>>> On Tuesday, January 3, 2023 at 4:23:59 AM UTC-8 kb3...@gmail.com wrote:
>>>
 I was able to get the local network page of my weewx station but how do 
 you see this from the public ip?

 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web vi

[weewx-user] Re: 433Mhz Barometer?

[gary....@gmail.com]

Ecowitt has a few options that include barometer.
https://shop.ecowitt.com/products/wh32-indoor
https://www.ecowitt.com/shop/goodsDetail/107

Either will have more than simply barometer, but you can always ignore them.

On Thursday, January 19, 2023 at 9:33:04 PM UTC-5 collin...@gmail.com wrote:

> Hi everyone.  Does anyone know of a barometer that transmits on 433Mhz? I 
> have one that transmits on 915Mhz but not to my liking. I'm interested in 
> consolidating into one frequency to make my setup easier.
>
> I've been searching searching and have yet to find one out of the US.
>
> Thanks
>
> Glen Collins
>
>
>

-- 
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/686713fa-9a35-4e39-b36a-1227e943739en%40googlegroups.com.

[weewx-user] Re: new river level monitor

[gary....@gmail.com]

Very nice.
This post gave me incentive to restart my LoRaWAN testing with some new 
equipment.
On Thursday, January 19, 2023 at 8:30:47 PM UTC-5 Graham Eddy wrote:

> i posted some time ago about my trusty old river level monitor. i am still 
> receiving occasional enquiries about it - yes, unfortunately that product i 
> used is no longer available. whilst it is still working for me, i have now 
> deployed a new river level monitor in parallel, some details below
>
> *old river level monitor*
>
> Aquagauge provided a radio receiver with serial interface and a number of 
> sensor types with radio transmitters. a receiver could support up to 8 
> transmitters. the radio and serial protocols are proprietary
>
> i wrote a weewx service that read the serial interface and inserted the 
> data values into weewx packets. later i migrated this to a daemon that 
> emitted the data as mqtt messages, and weewx reads the mqtt messages. this 
> works fine; it is still in use
>
> this river level sensor is pressure-based i.e. the probe sits on river 
> bottom (in my case wrapped around a brick and tucked into a river bank 
> nook) and measures the water pressure. there is a very inconvenient cable 
> from the probe to the transmitter. the latter measures atmospheric 
> pressure, the pressure difference is the weight of the water above the 
> sensor thence deriving water depth. it proved to be quite accurate
>
> the transmitter has suffered many travails, the latest being going for a 
> swim during a flood when the bridge it was on was swept downstream. it is 
> very robust but now failing more often and i fear one day soon not being 
> able to rescusitate it → motivation for replacement. this product is no 
> longer sold or supported
>
> *new river level sensor*
>
> i decided to try an ultrasound sensor i.e. the probe measures round-trip 
> time for a signal reflected from river surface back to probe with known 
> speed of signal. this means there is no cable needed to run into the river
>
> my river level sensor must be a commercial off-the-shelf product, for 
> which i am happy to write interface software. it also has to be wireless 
> connection to RPi at least 50 meters away and be powered by long-life 
> battery
>
> i picked a Dragino LDDS75 Distance Detector (
> https://www.dragino.com/products/distance-level-sensor/item/161-ldds75.html). 
> i mounted it under the sparkling new bridge i built over the river, higher 
> than the old bridge. it sends quite large and complex messages via mqtt, so 
> i wrote a daemon that plucks the salient data and re-publishes as simple 
> message, imported into weewx. my daemon also configures a fix-point height 
> for the sensor, so the simplified mqtt message includes a ‘level’ field as 
> well as ‘distance’ for easy digestion
>
> this is a LoRaWAN device so provides the long distance and battery 
> longevity i require
>
> *radio receiver server*
>
> the new river level sensor is the first of several sensors on my new open 
> radio network, as opposed to the closed proprietary radio network per 
> Aquagauge, so i need a radio transceiver to talk to them. i assume 
> familiarity with LoRaWAN (
> https://www.thethingsnetwork.org/docs/lorawan/architecture/)
>
> for the local LoWRaWAN gateway, i put a RAK 2245 LoRaWAN HAT (
> https://www.rakwireless.com/en-us/products/lpwan-gateways-and-concentrators/rak2245-pihat)
>  
> on an RPi 4B and installed RAK’s gateway software from their GitHub
>
> i tried using the chirpstack LoRaWAN stack running on local server but 
> couldn’t get it to work reliably, it seemed to work only intermittently. i 
> think i was having trouble with not picking up the radio packet preamble 
> but, not being a radiohead, gave it up as too much like hard work. i tried 
> The Things Network stack (
> https://www.thethingsindustries.com/docs/getting-started/ttn/) and, to 
> paraphrase steve jobs, ‘it just worked’. i am using the ’community 
> edition’, which is a subscribed but free service. the downside is that the 
> network server and join server run on TTN’s hardware over the internet so i 
> lose device connectivity when internet link is down. they provide the 
> software to run your own copy of the stack, which i plan to do in future
>
> so, the river level sensor emits radio packets, my RPi gateway receives 
> the packets and sends to TTN stack, the TTN stack processes and emits them 
> as complex mqtt messages, which my dameon picks up and simplifies, then 
> weewx digests the simplified mqtt messages. (i have chosen to put LoRaWAN 
> gateway on a separate RPi from the weewx RPi)
>
> the TTN stack’s mqtt broker is on their remote server. i have chosen to 
> bridge that mqtt broker to my RPi gateway so that, from my home network’s 
> perspective, all that LoRaWAN stuff is happening on my RPi gateway. this 
> fits my plan to move the TTN stack to the RPi gateway in future
>
> the RAK 2245 includes an itty bitty antenna. i get a good signal and 
> reliable conn

[weewx-user] Re: incomplete data due to internet interuptions

[gary....@gmail.com]

During a AWS outage a few months back, my WLL failed to update WeeWX. 
Nothing wrong with the WLL, my Internet, WeeWX. It seemed to depend on the 
Internet though I only was looking for local data.

It's my understanding that the WLL does have a logger function, saves data 
until it can be transmitted.
That is NOT available to you. There is no call to the WLL that a user can 
use to get the data. It will only send to Davis.
The data is available from Davis with some WLL driver, I forget which one. 
That needs a paid account and it goes to the Davis website/server to get 
the historical data.


On Tuesday, March 16, 2021 at 3:42:25 PM UTC-4 Artvd wrote:

> Thank you for looking in to this. I will ask NeoWX. 
>
> Op dinsdag 16 maart 2021 om 20:23:12 UTC+1 schreef kk44...@gmail.com:
>
>> What I see from you link is that you are using NeoWX skin. I looked into 
>> the Github repository of NeoWX, especially into skin.conf, and found out, 
>> that this skin does not use WeeWX's image generator but some other plot 
>> generator. Unfortunately I do not know how that generator works. So I can 
>> only say, that the problem is some NeoWX issue. Maybe, they do not create 
>> the whole plot every archive cycle but save some data by themselves. You 
>> need to ask the NeoWX people.
>>
>> Artvd schrieb am Dienstag, 16. März 2021 um 20:08:15 UTC+1:
>>
>>> Round 12 hours i did the same exercise i.e. have WLL and RPI on a switch 
>>> and then take away the internet for more then an hour. On my website the 
>>> holes of the time without internet are not filled later on as you can see 
>>> here:  https://bit.ly/3vuDmDT
>>>
>>> Op dinsdag 16 maart 2021 om 17:14:32 UTC+1 schreef kk44...@gmail.com:
>>>
 The log says

 Mar 16 15:48:16 raspberrypi weewx[527] INFO weewx.manager: Added record 
 2021-03-16 15:48:00 CET (1615906080) to database 'weewx.sdb'
 Mar 16 15:48:16 raspberrypi weewx[527] INFO weewx.manager: Added record 
 2021-03-16 15:48:00 CET (1615906080) to daily summary in 'weewx.sdb'

 That means, data are saved to the database of WeeWX. You can do nothing 
 more to save your data.

 The ERROR messages you see are normal if Internet is down. As soon as 
 Internet is up again, WeeWX uploads the reports again. And those reports 
 include all the data collected while the Internet was down.

 Could you provide some info where there are "holes" within the data?
 Artvd schrieb am Dienstag, 16. März 2021 um 16:05:38 UTC+1:

> I have a switch which connects WLL and RPI. In the log you can see it 
> continously adds current records. And they are published with FTP. But it 
> stops when take of the internetcable from the switch. But afterwards the 
> data is not updated. Here is the log (from starting up the RPI). I 
> removed 
> the internet cable At 15.48 h and put i back at 15.50
>
> :~ $ sudo tail -f /var/log/syslog
> Mar 16 15:17:15 raspberrypi dbus-daemon[574]: [session uid=1000 
> pid=574] Activating via systemd: service 
> name='org.gtk.vfs.GoaVolumeMonitor' 
> unit='gvfs-goa-volume-monitor.service' 
> requested by ':1.7' (uid=1000 pid=680 comm="pcmanfm --desktop --profile 
> LXDE-pi ")
> Mar 16 15:17:15 raspberrypi systemd[555]: Starting Virtual filesystem 
> service - GNOME Online Accounts monitor...
> Mar 16 15:17:15 raspberrypi dbus-daemon[574]: [session uid=1000 
> pid=574] Successfully activated service 'org.gtk.vfs.GoaVolumeMonitor'
> Mar 16 15:17:15 raspberrypi systemd[555]: Started Virtual filesystem 
> service - GNOME Online Accounts monitor.
> Mar 16 15:17:15 raspberrypi dbus-daemon[574]: [session uid=1000 
> pid=574] Activating via systemd: service 
> name='org.gtk.vfs.AfcVolumeMonitor' 
> unit='gvfs-afc-volume-monitor.service' 
> requested by ':1.7' (uid=1000 pid=680 comm="pcmanfm --desktop --profile 
> LXDE-pi ")
> Mar 16 15:17:15 raspberrypi systemd[555]: Starting Virtual filesystem 
> service - Apple File Conduit monitor...
> Mar 16 15:17:15 raspberrypi gvfs-afc-volume-monitor[798]: Volume 
> monitor alive
> Mar 16 15:17:15 raspberrypi dbus-daemon[574]: [session uid=1000 
> pid=574] Successfully activated service 'org.gtk.vfs.AfcVolumeMonitor'
> Mar 16 15:17:15 raspberrypi systemd[555]: Started Virtual filesystem 
> service - Apple File Conduit monitor.
> Mar 16 15:17:19 raspberrypi systemd[1]: systemd-rfkill.service: 
> Succeeded.
> Mar 16 15:17:35 raspberrypi systemd[1]: systemd-fsckd.service: 
> Succeeded.
> Mar 16 15:44:38 raspberrypi systemd-timesyncd[318]: Synchronized to 
> time server for the first time 45.87.77.15:123 (2.debian.pool.ntp.org
> ).
> Mar 16 15:44:46 raspberrypi systemd[1]: systemd-hostnamed.service: 
> Succeeded.
> Mar 16 15:44:55 raspberrypi weewx[527] INFO weewx.cheetahgenerator: 
> Generated 12 files for report SeasonsReport in 1660.61 s

[weewx-user] Re: Belchertown skin - Feels Like Temperature

[gary....@gmail.com]

I gave this a try and end up with no display of AppTemp or the desired thsw 
value. It's like I didn't choose to display anything.
I edited the two files and since I am in the US, changed the Apparent 
Temperature US lines in  belchertown.js.tmpl to be thsw then again to thsw_F
In index.html.tmpl I changed $current.appTemp to $current.thsw

There is thsw data sent to and recorded by WeeWX.

Any ideas?

[image: Clipboard Image.jpg]
On Friday, February 26, 2021 at 4:36:35 AM UTC-5 kk44...@gmail.com wrote:

> In /etc/weewx/skins/Belchertown/index.html.tmpl, line 192. replace 
> `$current.appTemp` by the desired value. 
> In /etc/weewx/skins/Belchertown/js/belchertown.js.tmpl, line 1547, replace 
> the same, but be aware of the "_C" at the end.
>
> I hope, that are all occurences of appTemp.
>
> grua...@gmail.com schrieb am Freitag, 26. Februar 2021 um 10:13:35 UTC+1:
>
>> hello,
>>
>> i want to display here the column "thsw" from the database, can i change 
>> this in weewx.conf somehow?
>>
>> [image: feelslike.JPG]
>> regards,
>> chris
>>
>

-- 
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/c5947dd9-572d-4bb2-89b3-f582efe139b2n%40googlegroups.com.

[weewx-user] Re: Belchertown skin - Feels Like Temperature

[gary....@gmail.com]

Thanks for the suggestion, you were correct.
Currently, THSW_F is 105.0 and now the Feels like: matches!

On Monday, June 7, 2021 at 11:25:56 AM UTC-4 kk44...@gmail.com wrote:

> Could it be that the observation is called "THSW" instead of "thsw"?
>
> If you look at the MQTT broker by a client (like MQTT explorer), is there 
> a line "thsw_F"? Be careful about uppercase and lowercase characters.
>
> gary@gmail.com schrieb am Montag, 7. Juni 2021 um 15:33:25 UTC+2:
>
>> I gave this a try and end up with no display of AppTemp or the desired 
>> thsw value. It's like I didn't choose to display anything.
>> I edited the two files and since I am in the US, changed the Apparent 
>> Temperature US lines in  belchertown.js.tmpl to be thsw then again to thsw_F
>> In index.html.tmpl I changed $current.appTemp to $current.thsw
>>
>> There is thsw data sent to and recorded by WeeWX.
>>
>> Any ideas?
>>
>> [image: Clipboard Image.jpg]
>> On Friday, February 26, 2021 at 4:36:35 AM UTC-5 kk44...@gmail.com wrote:
>>
>>> In /etc/weewx/skins/Belchertown/index.html.tmpl, line 192. replace 
>>> `$current.appTemp` by the desired value. 
>>> In /etc/weewx/skins/Belchertown/js/belchertown.js.tmpl, line 1547, 
>>> replace the same, but be aware of the "_C" at the end.
>>>
>>> I hope, that are all occurences of appTemp.
>>>
>>> grua...@gmail.com schrieb am Freitag, 26. Februar 2021 um 10:13:35 
>>> UTC+1:
>>>
>>>> hello,
>>>>
>>>> i want to display here the column "thsw" from the database, can i 
>>>> change this in weewx.conf somehow?
>>>>
>>>> [image: feelslike.JPG]
>>>> regards,
>>>> chris
>>>>
>>>

-- 
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/fe4d7718-7e63-4f2e-97c1-ae45b674a655n%40googlegroups.com.

[weewx-user] Belchertown Skin and Mosquitto 2.x Breaking Change

[gary....@gmail.com]

If you have not gotten an upgraded mosquitto broker yet, you likely will.
Running Pop!_OS 21.04, I was upgraded to v2 last night and my mosquitto 
broker refused to start afterwards.
Among other changes, mosquitto no longer runs as root and therefore can't 
read the ssl cert files.
After looking at other solutions, I took the easy (but unsecure) way out.
I added the line 
user root
to the main mosquitto.conf file
A restart of mosquitto and all is well again.

-- 
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/ae4f94fa-e7de-4b5b-b02c-bd864ad8de49n%40googlegroups.com.

[weewx-user] Re: Broadcast to weewx from Weatherflow tempest station

[gary....@gmail.com]

Perhaps check the Wiki:
Home · weewx/weewx Wiki · GitHub 



On Wednesday, June 30, 2021 at 11:05:12 AM UTC-4 seano...@gmail.com wrote:

> Hi,
>
> After many months of not being able to identify why an Acurite 5-in-1 
> randomly goes offline or broadcasts a zero wind speed when the wind is 
> often above 10 knots, I have decided to try a different station. I have 
> purchased a weather flow tempest which works really well using the app.
>
> I am wondering if there is any way to take the weather information from 
> this station and get it onto WindGuru? If anyone has any suggestions, 
> please let me know.
>
> Thanks,
> Sean.
>

-- 
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/868303cd-c2ed-49c6-b3d5-bc5099468c46n%40googlegroups.com.

[weewx-user] Belchertown Skin, Websockets, Firefox Fail to Connect

[gary....@gmail.com]

I have a curious issue here.
I normally use Edge from Windows 10 to browse. All is working fine.
I use Firefox in troubleshooting and browsed to my weather page.
No connection to the websocket feed.
Open Edge, no problem. Chrome from my phone, no problem. Safari from my 
wife's iPhone, no problem.

Disabled all plugins in Firefox, still get  Failed connecting to the 
weather station. Please try again later! 

Tried from a Linux machine using Firefox, same result.

Any ideas?

-- 
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/a434173b-cb72-4421-87aa-4e80419c687cn%40googlegroups.com.

[weewx-user] weewx.pid and systemd

[gary....@gmail.com]

I had a strange thing happen today. Power failed during the tropical storm.
I shut down the server as the UPS will only hold for 30 minutes.
However, after 25 minutes, the power returned and I started the server.
After a couple of hours, I checked my weather page and found it hadn't 
updated since right before the shutdown.
So, I checked logs and found little past this:

Aug  4 20:35:50 srvr systemd[1]: /etc/systemd/system/weewx.service:13: 
PIDFile= references a path below legacy directory /var/run/, updating 
/var/run/weewx.pid → /run/weewx.pid; please update the unit file 
accordingly.

Surely that wouldn't stop weewx from running, so I restarted the server. 
Same behavior.
I also noticed that mosquitto didn't seem to run properly.:

FIFO /tmp/dlt cannot be opened. Retrying later...

Eventually after unproductively chasing the mosquitto/dlt error, I stopped 
weewxd then started from the command line. It ran and produced loop data. 
CTL-C out and started the service.

Runs fine.

Beyond my level for sure. Any ideas/requests for logs, etc would be 
appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/998fdce4-11ff-46df-bbb9-595fdef094d3n%40googlegroups.com.

Re: [weewx-user] Re: weewx.pid and systemd

[gary....@gmail.com]

mount | grep tmpfs
udev on /dev type devtmpfs 
(rw,nosuid,noexec,relatime,size=8118412k,nr_inodes=2029603,mode=755)
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=1632724k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=1632720k,mode=700,uid=1000,gid=1000)
tmpfs on /run/user/0 type tmpfs 
(rw,nosuid,nodev,relatime,size=1632720k,mode=700)
On Tuesday, August 4, 2020 at 11:34:27 PM UTC-4 graha...@gmail.com wrote:

> /run and /tmp are both (usually) tmpfs file systems - maybe something 
> screwed up tmpfs then the files/dirs/symlinks meant to be auto-created by 
> tmpfiles.d didn’t happen - would be interested to see `mount | grep tmpfs` 
> and also, if /run and /tmp mounted correctly, what is under them pre-mount 
> (which is hard for these particular mount points because of running system 
> dependencies)
>
> On 5 Aug 2020, at 12:35 pm, Greg from Oz  wrote:
>
> Edit /etc/systemd/system/weewx.service
> If the above file doesn't exist then edit /etc/init.d/weewx 
> Wherever /var/run is change to /run/
> Restart and see what happens.
>
>
> On Wednesday, 5 August 2020 at 12:03:06 UTC+10 gary@gmail.com wrote:
>
>> I had a strange thing happen today. Power failed during the tropical 
>> storm.
>> I shut down the server as the UPS will only hold for 30 minutes.
>> However, after 25 minutes, the power returned and I started the server.
>> After a couple of hours, I checked my weather page and found it hadn't 
>> updated since right before the shutdown.
>> So, I checked logs and found little past this:
>>
>> Aug  4 20:35:50 srvr systemd[1]: /etc/systemd/system/weewx.service:13: 
>> PIDFile= references a path below legacy directory /var/run/, updating 
>> /var/run/weewx.pid → /run/weewx.pid; please update the unit file 
>> accordingly.
>>
>> Surely that wouldn't stop weewx from running, so I restarted the server. 
>> Same behavior.
>> I also noticed that mosquitto didn't seem to run properly.:
>>
>> FIFO /tmp/dlt cannot be opened. Retrying later...
>>
>> Eventually after unproductively chasing the mosquitto/dlt error, I 
>> stopped weewxd then started from the command line. It ran and produced loop 
>> data. CTL-C out and started the service.
>>
>> Runs fine.
>>
>> Beyond my level for sure. Any ideas/requests for logs, etc would be 
>> appreciated.
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/51c4a7ba-855d-47c0-b428-aa21d2a7003bn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/51c4a7ba-855d-47c0-b428-aa21d2a7003bn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>

-- 
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/4c82b777-be7b-4255-9207-b9c4f4c8098dn%40googlegroups.com.

[weewx-user] Upgrade PWS- WLL or WiFiLogger2?

[gary....@gmail.com]

I am thinking of upgrading my PWS to a Davis 6163.
To get the data into WeeWX, I am looking at two devices.
The Davis 6100 (WLL) or the WiFiLogger2

I can find no real information about the WLL an local LAN.
I see a couple of user created drivers for the WLL and WeeWX, but they seem 
to have issues.

The WiFiLogger2 has the ability to be used as a data logger via WiFi or it 
can provide a MQTT feed.

Why the WLL or WiFiLogger? I don't wish to have my console located with my 
WeeWX server.

Any feedback on either device?
I'd like to move forward, but if I can't get my data into WeeWX, then it's 
a non-starter.


-- 
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/788e7e5b-755f-4f6a-8dc1-a26183754936n%40googlegroups.com.

[weewx-user] Re: Upgrade PWS- WLL or WiFiLogger2?

[gary....@gmail.com]

That is the information I was looking for.
I plan to run it with Rich's MQTTSubscribe. Then the WiFiLogger2 will 
simply write to my mosquitto server every 3 seconds allowing it to talk 
with the console at will. WeeWX will handle all other reporting.
Wojtek is a great resource, I have been exchanging email with him and he is 
very clear on exactly what the device can/can't/shouldn't do.
Ryan at Scaled Instruments has been great as well.

WeeWX-MQTTSubscribe <https://github.com/bellrichm/WeeWX-MQTTSubscribe>

On Tuesday, October 6, 2020 at 3:15:11 AM UTC-4 jerry...@gmail.com wrote:

> I recently switched from a 3 hop retransmit across 1000 ft by multiple 
> Davis Vantage Pro2 links to WiFiLogger2 across an AirMax backhaul and the 
> weewx server has been running well for several months.  I had one problem 
> with the WiFiLogger2.  It seemed to disconnect from its vLAN network every 
> 4 days or so, which caused weewx to going into a waiting mode and not 
> reconnect.  WiFiLogger2 eventually reconnects after about 2 hours, but 
> weewx needs to be restarted after that.  I fixed this problem by running a 
> short shell script as a cron job once a day to restart WiFiLogger2.  
> WifiLogger2 has been stable if restarted once a day.  
>
> WifiLogger2 replaced a Davis Weather Envoy 6316 with a USB interface.  I 
> found the 6316 would freeze every 8 days (running 5 minute update 
> intervals). This was the case under WeatherLink for Windows, WeatherLink 
> for Mac, and Weewx.  Must be the USB driver.  Again, a cron job to restart 
> weewx (or the other programs) every 7 days fixed the problem.
> Wojtek at WiFiLogger2 has been very responsive in helping to trouble shoot 
> the disconnect issues.  I am happy with WiFiLogger2.
>
>
>
> On Monday, October 5, 2020 at 12:58:45 PM UTC-7 gary@gmail.com wrote:
>
>> I am thinking of upgrading my PWS to a Davis 6163.
>> To get the data into WeeWX, I am looking at two devices.
>> The Davis 6100 (WLL) or the WiFiLogger2
>>
>> I can find no real information about the WLL an local LAN.
>> I see a couple of user created drivers for the WLL and WeeWX, but they 
>> seem to have issues.
>>
>> The WiFiLogger2 has the ability to be used as a data logger via WiFi or 
>> it can provide a MQTT feed.
>>
>> Why the WLL or WiFiLogger? I don't wish to have my console located with 
>> my WeeWX server.
>>
>> Any feedback on either device?
>> I'd like to move forward, but if I can't get my data into WeeWX, then 
>> it's a non-starter.
>>
>>
>>

-- 
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/001f4c37-d234-46e8-8c85-42a8e479e63cn%40googlegroups.com.

[weewx-user] Re: Upgrade PWS- WLL or WiFiLogger2?

[gary....@gmail.com]

Thanks for the Linux version of the script.

On Tuesday, October 6, 2020 at 4:33:35 AM UTC-4 mh081...@gmail.com wrote:

> Thanks for the script. I changed it to be runnable from raspberry pi 
> (Debian 10.4)
>
> #!/bin/sh
> # Shell script to restart the weatherLogger wifi device in the Davis 
> Vantage Pro 2 in the Harbormaster Building
> # The weather logger tends to disconnect from network every 4 days causing 
> weewx to crash in a waiting state
> # Currently set to run by rycweather as a cron job once a day at 8:07 am.
> # check to see if weatherLogger is connected on Harbormaster vlan
> /bin/ping -c 1 WiFiLogger.fritz.box
> if [ "$?" = "0" ]; then
> weatherLoggerStatus="weatherLogger is online"
> #   Using curl
> curl --connect-timeout 5 --fail 
> http://WiFiLogger.fritz.box/admin/restart
> #   wait to launch and load javascript function of URL
> sleep 30
> else
> weatherLoggerStatus="weatherLogger is OFFLINE"
> fi
> # Check weatherLogger is connected again
> /bin/ping -c 1 WiFiLogger.fritz.box
> if [ "$?" = "0" ]; then
> newWeatherLoggerStatus="weatherlogger is back online"
> else
> newWeatherLoggerStatus="weatherLogger is OFFLINE after restart"
> fi
> echo "$weatherLoggerStatus and after restart $newWeatherLoggerStatus" | 
> sendemail -f mailadr...@mail.com -t mailad...@mail.com -u "WifiLogger 
> Restart" -s mailserver.mail.com -xu "username" -xp "password" -o tls=yes 
> -o message-content-type=auto
> exit
>
>
> jerry...@gmail.com schrieb am Dienstag, 6. Oktober 2020 um 09:36:22 UTC+2:
>
>> WifiLogger2 doesn't have an ssh port open, but it does respond on port 80 
>> to a restart command from http.  Under macOS I use the shell script command 
>> to open the Safair browser to the restart javascript command.
>> #!/bin/sh
>> # Shell script to restart the weatherLogger wifi device in the Davis 
>> Vantage Pro 2 in the Harbormaster Building
>> # The weather logger tends to disconnect from network every 4 days 
>> causing weewx to crash in a waiting state
>> # Currently set to run by rycweather as a cron job once a day at 8:07 am.
>> # check to see if weatherLogger is connected on Harbormaster vlan
>> /sbin/ping -c 1 192.168.145.106
>> if [[ "$?" == "0" ]]; then
>> weatherLoggerStatus="weatherLogger is online"
>> #   Using Safari browser
>> open -a Safari http://192.168.145.106/admin/restart
>> #   wait for Safari to launch and load javascript function of URL
>> sleep 60
>> #   close Safari
>> killall Safari
>> else
>> weatherLoggerStatus="weatherLogger is OFFLINE"
>> fi
>> # Check weatherLogger is connected again
>> /sbin/ping -c 1 192.168.145.106
>> if [[ "$?" == "0" ]]; then
>> newWeatherLoggerStatus="weatherlogger is back online"
>> else
>> newWeatherLoggerStatus="weatherLogger is OFFLINE after restart"
>> fi
>> echo "$weatherLoggerStatus and after restart $newWeatherLoggerStatus" | 
>> mail -s "weatherLogger restart" xxx
>> exit
>>
>>
>> On Tuesday, October 6, 2020 at 12:23:03 AM UTC-7 mh081...@gmail.com 
>> wrote:
>>
>>> Hi,
>>>
>>> can you provide me this shell script to restart  WifiLogger2  by cron? 
>>> How did you connect to WifiLogger2 remotely? I have the same problem that 
>>> WifiLogger2 disconnects from wlan after several days.
>>>
>>> jerry...@gmail.com schrieb am Dienstag, 6. Oktober 2020 um 09:15:11 
>>> UTC+2:
>>>
>>>> I recently switched from a 3 hop retransmit across 1000 ft by multiple 
>>>> Davis Vantage Pro2 links to WiFiLogger2 across an AirMax backhaul and the 
>>>> weewx server has been running well for several months.  I had one problem 
>>>> with the WiFiLogger2.  It seemed to disconnect from its vLAN network every 
>>>> 4 days or so, which caused weewx to going into a waiting mode and not 
>>>> reconnect.  WiFiLogger2 eventually reconnects after about 2 hours, but 
>>>> weewx needs to be restarted after that.  I fixed this problem by running a 
>>>> short shell script as a cron job once a day to restart WiFiLogger2.  
>>>> WifiLogger2 has been stable if restarted once a day.  
>>>>
>>>> WifiLogger2 replaced a Davis Weather Envoy 6316 with a USB interface.  
>>>> I found the 6316 would freeze every 8 days (running 5 minute update 
>>>> inte

[weewx-user] WeeWX 4.1.1, WU RapidFire, Logging

[gary....@gmail.com]

I have enabled Weather Underground data with RapidFire.
I see that weewx.restx logs each time data is sent.
I like to see the rest of the logged info, is there a way to turn logging 
off just for the WU sending?


-- 
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/f1ecc869-c528-48ca-83e0-4d59b9494de5n%40googlegroups.com.

Re: [weewx-user] Davis WeatherLink Live: Which driver is best?

[gary....@gmail.com]

Take a look at this one, it's well documented and the author is quite 
responsive.
https://github.com/michael-slx/weewx-weatherlink-live

This one performs well too and also has a responsive author.
https://github.com/grebleem/weewx-weatherlinkliveudp

On Sunday, November 1, 2020 at 7:12:55 AM UTC-5 didier@gmail.com wrote:

> it's a fork of https://github.com/vinceskahan/weewx-weatherlinklive-json
>
> Le dim. 1 nov. 2020 à 12:21, Karen K  a écrit :
>
>> didier@gmail.com schrieb am Sonntag, 1. November 2020 um 11:36:36 
>> UTC+1:
>>
>>> I'm using this one : 
>>> https://github.com/Drealine/weatherlinklive-driver-weewx
>>>
>>
>> Oh, I think, this one is not listed at 
>> https://github.com/weewx/weewx/wiki .
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/64cfc036-5576-46bf-8b31-9b4ce55da912n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Quel temps fait-il à Auffargis  ?
>

-- 
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/ef7473db-2898-4226-9ee5-080499f63df7n%40googlegroups.com.

Re: [weewx-user] Davis WeatherLink Live: Which driver is best?

[gary....@gmail.com]

I have the WeatherLinkLiveUDP driver (bugfix_october20) installed and in 
weewx I see identical readings with Davis Bulletin page for my PWS.
[image: weewx.PNG]   [image: WLL.PNG]

-- 
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/28dd4307-c412-40e7-9192-7e81e93881b5n%40googlegroups.com.

Re: [weewx-user] Davis WeatherLink Live: Which driver is best?

[gary....@gmail.com]

Here's a handy link.
https://github.com/weewx/weewx/wiki/Barometer,-pressure,-and-altimeter

On Saturday, November 21, 2020 at 10:09:22 AM UTC-5 didier@gmail.com 
wrote:

> Ooops, after 10 mn the 2 values have diverged (only 1 mbar)
> The explanation is that weatherlinkliveudp driver uses "altimeter" and 
> WLLDriver uses "barometer" for the station info
>
> After change all is correct
> It was not a mystery.
>
> Le sam. 21 nov. 2020 à 15:30, Didier Decoodt  a 
> écrit :
>
>> I have completely restarted my machine and now I have the same 
>> values..
>> It's a mystery, but it's OK now
>>
>> Sorry
>>
>> Le sam. 21 nov. 2020 à 14:58, G Hammer  a écrit :
>>
>>> I may do that later, but I fail to see the point.
>>> Do you think WeeWX and Davis are both applying a conversion factor to 
>>> the raw data and just happened upon the same value?
>>>
>>>
>>> On Sat, Nov 21, 2020, 4:16 AM Didier Decoodt  
>>> wrote:
>>>
>>>> Strange...
>>>> Could you check these values by using http://"@IP of WLL"/v1/ 
>>>> current_conditions
>>>> I'm using master github, I think that this is the same distribution of 
>>>> bugfix_october20
>>>>
>>>> Le sam. 21 nov. 2020 à 02:06, gary@gmail.com  
>>>> a écrit :
>>>>
>>>>> I have the WeatherLinkLiveUDP driver (bugfix_october20) installed and 
>>>>> in weewx I see identical readings with Davis Bulletin page for my PWS.
>>>>> [image: weewx.PNG]   [image: WLL.PNG]
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "weewx-user" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to weewx-user+...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/weewx-user/28dd4307-c412-40e7-9192-7e81e93881b5n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/weewx-user/28dd4307-c412-40e7-9192-7e81e93881b5n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Quel temps fait-il à Auffargis <https://meteo-auffargis.decoodt.eu> ?
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to a topic in the 
>>>> Google Groups "weewx-user" group.
>>>> To unsubscribe from this topic, visit 
>>>> https://groups.google.com/d/topic/weewx-user/PvJbjlLZNeE/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to 
>>>> weewx-user+...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/weewx-user/CAAvt3%3DTVkh1fidO_u2jMPUEw6pnyrW0cD0iinVju368bxvNbog%40mail.gmail.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/CAAvt3%3DTVkh1fidO_u2jMPUEw6pnyrW0cD0iinVju368bxvNbog%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/CALBRR-2PCAfwyPn8MdZpmnh_b9_6p7A77kTw0jHgp%3Dz%3Dej5WFA%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/CALBRR-2PCAfwyPn8MdZpmnh_b9_6p7A77kTw0jHgp%3Dz%3Dej5WFA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> Quel temps fait-il à Auffargis <https://meteo-auffargis.decoodt.eu> ?
>>
>
>
> -- 
> Quel temps fait-il à Auffargis <https://meteo-auffargis.decoodt.eu> ?
>

-- 
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/c4e558c1-0175-46fd-bce3-8652fd0c3b16n%40googlegroups.com.

Re: [weewx-user] Weewx fails in Fedora 39

[gary....@gmail.com]

See
weewx doesn't start after upgrade to fedoar 39 (google.com) 


On Wednesday, November 15, 2023 at 4:54:29 AM UTC-5 Jonathan Ryshpan wrote:

> On Wed, 2023-11-15 at 01:26 -0800, Jonathan Ryshpan wrote:
>
> I have just upgraded to Fedora 39 and weewx has stopped working. 
> Initiation fails with the following messages. Any ideas what's wrong or how 
> to investigate?
>
> The version of weewx is:
> $ rpm -q weewx 
> weewx-4.10.2-1.el8.noarch
>
> Sorry for not putting this in the original post.
>
> -- 
>
> Sincerely Jonathan Ryshpan 
>
> Every rocky mountain slope
> A corrugated washing board
> Every snowflake Fuller's Soap
> And the dirty land 
> Scrubbed by His Hand
> On the washboard of the Lord.
>
>

-- 
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/67862e61-3b83-46da-b987-83c5784928a1n%40googlegroups.com.

Re: [weewx-user] Pipe errors etc

[gary....@gmail.com]

I went with a WiFiLogger2 which has performed without a hitch for a couple 
of years now.
The maker also has an Ethernet unit if you don't want the added heat from a 
radio in your console.

https://wifilogger.net/

https://wifilogger.net/ethernet.html

On Tuesday, December 5, 2023 at 6:54:14 AM UTC-5 hind...@gmail.com wrote:

> I have recently moved a BT Wholehome Wifi disc a little closer to the 
> Console  (10cm now; was 100cm)  , so I guess that *might* be 
> "interfering" in some way  - I will try moving it further away again to see 
> if that solves the problem.  I have already re-seated the WLIP logger a few 
> times. Incidentally, if Davis no longer make the WLIP logger, does anyone 
> know what the the preferred method now is of getting the data from the 
> weather station to weewx etc?
>
> I may also try the different drive that was suggested in 
> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/7difZtkUAgAJ.
>
> Regarding the question in 
> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/J9W5KA7rAQAJ, I 
> haven't changed anything on my network, other than moving a few ethernet 
> cables for other devices around, due to an unstable Sky TV connection.
>
> Thanks to everyone that has commented on this to help me find a solution.  
> Much appreciated.
>
> David.
>
> On Tuesday 5 December 2023 at 00:25:06 UTC Tom Keffer wrote:
>
>> That's certainly possible. I'd say ask Davis, but this logger has been so 
>> long out of production that I doubt David would get any satisfaction out of 
>> them.
>>
>> I'm also suspicious when electronic devices "just break." That's very 
>> rare. But, it does happen.
>>
>> One thing you could try: reseating the logger. 
>>
>> Oh, and is there any new source of RF nearby? A new router? Satellite 
>> dish? 5 kW pirate radio?
>>
>> On Mon, Dec 4, 2023 at 4:17 PM Graham Eddy  wrote:
>>
>>> the vantage IP device seems to accept a connection, work for a while, 
>>> then stop responding, then connection is reset → sounds like on device side 
>>> it seizes up and the ip protocol times out; establishing new connection 
>>> just repeats the cycle. the device apparently has been working for years 
>>> and is now failing → sounds like device has broken
>>> *⊣GE⊢*
>>>
>>> On 5 Dec 2023, at 9:23 am, vince  wrote:
>>>
>>> Just a thought, but when I see "weewx.drivers.vantage: ip-read error: 
>>> timed out" that makes me think your network is unstable.   From your 
>>> posts in the thread it 'sounds' like it has been working for years without 
>>> issues.  Did you change anything on your network ? Did you change any 
>>> firewall settings on your pi or install something like fail2ban or pihole 
>>> recently ?
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/6B5C1B94-55F5-484D-8E8E-3142F471AE4C%40geddy.au
>>>  
>>> 
>>> .
>>>
>>

-- 
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/021e0ca9-fd6a-4178-b932-fc30c9cfadfen%40googlegroups.com.

[weewx-user] Re: WeatherLink Live extensions for WeeWX 5.x

[gary....@gmail.com]

I'm using WeatherLinkLive been running fine on v5
I don't use CRT.
Why not give it a try and let everyone know?
On Monday, December 18, 2023 at 11:52:32 AM UTC-5 G400 wrote:

> Which extension for Davis WeatherLink Live is recommended for WeeWX 5.x 
> (current development version is 5.0.0b17-4)?
>
> There are (at least) two options:
> 1.* weewx-weatherlink-live* (
> https://github.com/michael-slx/weewx-weatherlink-live)
> 2. *weewx-wll* (https://github.com/jonotaegi/weewx-wll) 
>
> For writing data that WeeWX emits in the format used by Cumulus 
> realtime.txt it seems *CRT *found at 
> https://github.com/weewx/weewx/wiki/crt is the only option.
>
> Is CRT compatible with both options?
>
> I'm hoping to get feedback from anyone that have tested/from developers of 
> the extensions.
>
> Thank's in advance!
>

-- 
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/4f22b01a-a337-4352-bd5c-8c5302c786a9n%40googlegroups.com.

[weewx-user] Re: Weewx and Meteobridge - website update

[gary....@gmail.com]

What skin are you using?

On Sunday, January 7, 2024 at 1:36:16 PM UTC-5 bhouseski wrote:

> Recently I was able to get Weewx running on a Raspberry Pi 4B, pulling 
> data from a Vantage Pro2 connected to a D-Link DIR-505 loaded with 
> Meteobridge (vantage is connected to the Meteobridge via USB).  All is well 
> except I cannot get the website to autoload new data (I have to keep 
> hitting refresh on my web browser).  I have played around with the archive 
> interval, but have had no success.
>
> any idea's how to make this work?
>

-- 
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/62f46aac-7e59-496b-95ed-ee49388c2909n%40googlegroups.com.

[weewx-user] Re: weewx5 separated wind sensor via weatherlink-live driver - no wind

[gary....@gmail.com]

Try this in weewx.conf for your mapping

mapping = th:1, rain:1, wind:2, uv:1, solar:1, windchill:1, thw:1, 
thsw:1:appTemp, th_indoor, baro, battery:1:outTemp:rain:uv, battery:2:wind

On Wednesday, January 10, 2024 at 2:24:29 PM UTC-5 puckthefly wrote:

> Hello,
>
> I've been trying to get a Davis Weatherlink 6100 to run with the 
> WeatherlinkLive Driver in weewx5 for days.
> Unfortunately this doesn't work completely, my wind sensor is separated on 
> ID2 and the data doesn't seem to arrive in weewx5.
> In weewx5 I only see the data from the ISS, in my case via ID1 - but no 
> data for wind.
>
> As far as I understand the documentation, it would have to be adjusted 
> like this:
> mapping = th:1, rain:1, wind:2, th_indoor, baro, battery:1:outTemp:rain, 
> battery:2:wind
>
> Has anyone successfully implemented this with a remote wind sensor?
>
> But ID2 definitely comes with values that I see live on the console and I 
> can also see them on the Davis WeatherLink Live 6100 
> (/v1/current_conditions):
>
>
> {"data":{"did":"001D0A7145F8","ts":1704740156,"conditions":[{"lsid":612618,"data_structure_type":1,"
> *txid":1*,"temp": 22.8, "hum":88.8,"dew_point": 20.0,"wet_bulb": 
> 21.8,"heat_index": 
> 22.8,"wind_chill":null,"thw_index":null,"thsw_index":null,"wind_speed_last":null,"wind_dir_last
>  
> ":null,"wind_speed_avg_last_1_min":null,"wind_dir_scalar_avg_last_1_min":null,"wind_speed_avg_last_2_min":null,"wind_dir_scalar_avg_last_2_min":null,"wind_speed_hi_last_2_min":null,"wind_dir_at_hi_speed_last_2_min":null,"wind_speed_avg_last_10
>  
> *min":null,"wind_dir_scalar_avg_last_10_min": 
> null,"wind_speed_hi_last_10_min":null,"wind_dir_at_hi_speed_last_10_min":null,"rain_size":2,"rain_rate_last":0,"rain_rate_hi":0,"rainfall_last_15_min":0,"rain_rate_hi_last_15_min":0,"rainfall_last_60_min":0,
>  
> "rainfall_last_24_hr":0,"rain_storm":0,"rain_storm_start_at":null,"solar_rad":null,"uv_index":null,"rx_state":0,"trans_battery_flag":0,"rainfall_daily":0,"rainfall_monthly":162,"rainfall_year":162,"rain_storm_last":162,"rain_storm_last_start_at":1704176821,"rain_storm_last_end_at":1704715261},{"lsid":612663,"data_structure_type":1,"txid":2,"temp
>  
> ":null,"hum":null,"dew_point":null,"wet_bulb":null,"heat_index":null,"wind_chill":null,"thw_index":null,"thsw_index":null,"wind_speed_last":
>  
> 4.00,"wind_dir_last":47,"wind_speed_avg_last_1_min":5.31,"wind_dir_scalar_avg_last_1_min":47,"wind_speed_avg_last_2_min":4.75,"wind_dir_scalar_avg_last_2_min":45,"wind_speed_hi_last_2_min":9.00,"wind_dir_at*
>  
> hi_speed_last_2_min":54,"wind_speed_avg_last_10_min":4.37, 
> "wind_dir_scalar_avg_last_10_min":42,"wind_speed_hi_last_10_min":9.00,"wind_dir_at_hi_speed_last_10_min":54,"rain_size":1,"rain_rate_last":0,"rain_rate_hi":0,"rainfall_last_15_min":0,"rain_rate_hi_last_15_min":0,"rainfall_last_
>  
> 60_min 
> ":0,"rainfall_last_24_hr":0,"rain_storm":null,"rain_storm_start_at":null,"solar_rad":null,"uv_index":null,"rx_state":0,"trans_battery_flag":0,"rainfall_daily":
>  
> 0,"rainfall_monthly":0,"rainfall_year":0,"rain_storm_last":null,"rain_storm_last_start_at":null,"rain_storm_last_end_at":null},{"lsid":612617,"data_structure_type":4,"temp_in":
>  
> 76.6,"hum_in":29.9,"dew_point_in": 42.8,"heat_index_in": 
> 74.6},{"lsid":612616,"data_structure_type":3,"bar_sea_level":30.227,"bar_trend":
>  
> 0.043,"bar_absolute": 28,501}]},"error":null}
>

-- 
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/1b86bf94-b7e4-4abf-8fa6-ba94b169a815n%40googlegroups.com.

[weewx-user] Re: Driver permission error when starting Weewx

[gary....@gmail.com]

sudo only issues the command as root.
What is in the service file for user and group?
That is who weewx is running as.

On Monday, January 22, 2024 at 11:43:48 AM UTC-5 Tomasz Lewicki wrote:

> I run weewx as root:
>
> sudo systemctl start weewx
>
> If I set higher port (8080), weewx starts but I have empty queue for 
> interceptor.
>
> niedziela, 21 stycznia 2024 o 18:49:48 UTC+1 matthew wall napisał(a):
>
>> On Sunday, January 21, 2024 at 12:23:34 PM UTC-5 Tomasz Lewicki wrote:
>>
>>
>> Jan 21 18:14:17 FR24 weewxd[14285]: INFO weewx.engine: Loading station 
>> type Interceptor (user.interceptor)
>> Jan 21 18:14:17 FR24 weewxd[14285]: INFO user.interceptor: driver version 
>> is 0.60
>> Jan 21 18:14:17 FR24 weewxd[14285]: INFO user.interceptor: device type: 
>> observer
>> Jan 21 18:14:17 FR24 weewxd[14285]: INFO user.interceptor: hardware name: 
>> weatherstation via interceptor
>> Jan 21 18:14:17 FR24 weewxd[14285]: INFO user.interceptor: mode is listen
>> Jan 21 18:14:17 FR24 weewxd[14285]: INFO user.interceptor: listen on :80
>>
>>
>> if you listen on port 80, then the process must run as root (only root 
>> can listen on lower ports).
>>
>> so either run weewxd as root, or configure interceptor (and the station) 
>> to communicate on a higher port.
>>  
>>
>

-- 
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/9b9e0009-ad67-4325-8ec2-67a092836408n%40googlegroups.com.

[weewx-user] Re: MQTTSubscribe and paho mqtt heads up

[gary....@gmail.com]

pip install paho-mqtt==1.6.1

Downgraded paho-mqtt in my venv, restarted weewx and all is well.

On Saturday, February 10, 2024 at 5:44:36 PM UTC-5 bell...@gmail.com wrote:

> There is new release of paho mqtt, 2.0.0. This has a breaking change for 
> all clients using this library. I'll let you know when MQTTSubscribe 
> supports it.
> Sigh, backwards compatibility is overrated.
> rich
>

-- 
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/65c25bbc-9fa2-4319-af6d-3d060e4484d1n%40googlegroups.com.

[weewx-user] Re: Upgrade to 5.0.x does not start

[gary....@gmail.com]

Your weewx repository has been disabled.
I'd remove the entry and re-create it. From what I've read, you may need to 
get the signing keys as well.

On Monday, February 12, 2024 at 9:01:52 AM UTC-5 geni08...@gmail.com wrote:

> # deb [arch=all] http://weewx.com/apt/python3 buster main # disabled on 
> upgrade to jammy
> and
> Paketdateien:
>  100 /var/lib/dpkg/status
>  release a=now
>  500 http://archive.raspberrypi.org/debian bullseye/main armhf Packages
>  release o=Raspberry Pi Foundation,a=oldstable,n=bullseye,l=Raspberry 
> Pi Foundation,c=main,b=armhf
>  origin archive.raspberrypi.org
>  500 http://archive.raspberrypi.org/debian bullseye/main arm64 Packages
>  release o=Raspberry Pi Foundation,a=oldstable,n=bullseye,l=Raspberry 
> Pi Foundation,c=main,b=arm64
>  origin archive.raspberrypi.org
>  500 http://deb.debian.org/debian bullseye-updates/main armhf Packages
>  release 
> v=11-updates,o=Debian,a=oldstable-updates,n=bullseye-updates,l=Debian,c=main,b=armhf
>  origin deb.debian.org
>  500 http://deb.debian.org/debian bullseye-updates/main arm64 Packages
>  release 
> v=11-updates,o=Debian,a=oldstable-updates,n=bullseye-updates,l=Debian,c=main,b=arm64
>  origin deb.debian.org
>  500 http://security.debian.org/debian-security bullseye-security/main 
> armhf Packages
>  release 
> v=11,o=Debian,a=oldstable-security,n=bullseye-security,l=Debian-Security,c=main,b=armhf
>  origin security.debian.org
>  500 http://security.debian.org/debian-security bullseye-security/main 
> arm64 Packages
>  release 
> v=11,o=Debian,a=oldstable-security,n=bullseye-security,l=Debian-Security,c=main,b=arm64
>  origin security.debian.org
>  500 http://deb.debian.org/debian bullseye/non-free armhf Packages
>  release 
> v=11.9,o=Debian,a=oldstable,n=bullseye,l=Debian,c=non-free,b=armhf
>  origin deb.debian.org
>  500 http://deb.debian.org/debian bullseye/non-free arm64 Packages
>  release 
> v=11.9,o=Debian,a=oldstable,n=bullseye,l=Debian,c=non-free,b=arm64
>  origin deb.debian.org
>  500 http://deb.debian.org/debian bullseye/contrib armhf Packages
>  release 
> v=11.9,o=Debian,a=oldstable,n=bullseye,l=Debian,c=contrib,b=armhf
>  origin deb.debian.org
>  500 http://deb.debian.org/debian bullseye/contrib arm64 Packages
>  release 
> v=11.9,o=Debian,a=oldstable,n=bullseye,l=Debian,c=contrib,b=arm64
>  origin deb.debian.org
>  500 http://deb.debian.org/debian bullseye/main armhf Packages
>  release v=11.9,o=Debian,a=oldstable,n=bullseye,l=Debian,c=main,b=armhf
>  origin deb.debian.org
>  500 http://deb.debian.org/debian bullseye/main arm64 Packages
>  release v=11.9,o=Debian,a=oldstable,n=bullseye,l=Debian,c=main,b=arm64
>  origin deb.debian.org
> Mit Pinning verwaltete Pakete:
> matthew wall schrieb am Montag, 12. Februar 2024 um 13:25:03 UTC+1:
>
>> On Monday, February 12, 2024 at 3:35:38 AM UTC-5 geni08...@gmail.com 
>> wrote:
>>
>> PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
>>
>>
>> good! and what is the content of weewx.list?
>>
>> cat /etc/apt/sources.list.d/weewx.list
>>
>>  and what is the upgrade/update policy for yoiur machine?
>>
>> apt-cache policy
>>
>>

-- 
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/fc667d0d-dd4c-47f7-8a84-332d21219d59n%40googlegroups.com.

[weewx-user] How to upgrade from setup.py v4 install to pip v5 install

[gary....@gmail.com]

I've had a test install of v5 since early alphas. Now, it is time to 
upgrade my production install.
I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
couple of additional internet uploaders (Windy and WeatherCloud). I run two 
skins, Belchertown and weewx-wdc

All is and has been quite stable. So, I hesitate to poke at it. But, v5 is 
the new standard, so I need to get this done.

I don't see many who have trod this path. How to go about 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/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

[gary....@gmail.com]

I understand coming from v5 that would be a way.
I need to upgrade my v4 setup.py to v5 though.


On Wednesday, February 21, 2024 at 10:39:47 AM UTC-5 Tom Keffer wrote:

The pip installs are super easy to back up. Just copy ~/weewx-venv and 
~/weewx-data and you have everything you need.

Then activate the virtual environment, then "pip install weewx --upgrade". 
It should be that easy. If something fails, just roll things back.

On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com  
wrote:

I've had a test install of v5 since early alphas. Now, it is time to 
upgrade my production install.
I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
couple of additional internet uploaders (Windy and WeatherCloud). I run two 
skins, Belchertown and weewx-wdc

All is and has been quite stable. So, I hesitate to poke at it. But, v5 is 
the new standard, so I need to get this done.

I don't see many who have trod this path. How to go about 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+...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com
 
<https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com?utm_medium=email&utm_source=footer>
.

-- 
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/68e9b77e-5d25-492f-bfa5-448ac39b8cedn%40googlegroups.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

[gary....@gmail.com]

Thanks for the options.

I don't want to have a "hybrid" so won't be following the migration guide 
method.
Makes more sense to me to install new, install extensions and skins, edit 
in my config from the existing (old) weewx.conf, copy the database over, 
remove the old systemd service file, add the new systemd service, move the 
old install to weewx.old, run the new.

May be a tiny bit more effort but then should be easier for me to 
maintain/update in the future.



On Wednesday, February 21, 2024 at 11:07:46 AM UTC-5 Tom Keffer wrote:

> Oh, I thought we were talking about upgrading from an alpha version of v5.
>
> Not much difference. Just set up a V5 virtual environment, then point it 
> at /home/weewx. Follow the directions in the migration guide 
> <https://github.com/weewx/weewx/wiki/v5-upgrade>. 
>
> On Wed, Feb 21, 2024 at 7:44 AM gary@gmail.com  
> wrote:
>
>> I understand coming from v5 that would be a way.
>> I need to upgrade my v4 setup.py to v5 though.
>>
>>
>> On Wednesday, February 21, 2024 at 10:39:47 AM UTC-5 Tom Keffer wrote:
>>
>> The pip installs are super easy to back up. Just copy ~/weewx-venv and 
>> ~/weewx-data and you have everything you need.
>>
>> Then activate the virtual environment, then "pip install weewx 
>> --upgrade". It should be that easy. If something fails, just roll things 
>> back.
>>
>> On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com  
>> wrote:
>>
>> I've had a test install of v5 since early alphas. Now, it is time to 
>> upgrade my production install.
>> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
>> couple of additional internet uploaders (Windy and WeatherCloud). I run two 
>> skins, Belchertown and weewx-wdc
>>
>> All is and has been quite stable. So, I hesitate to poke at it. But, v5 
>> is the new standard, so I need to get this done.
>>
>> I don't see many who have trod this path. How to go about 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/68e9b77e-5d25-492f-bfa5-448ac39b8cedn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/68e9b77e-5d25-492f-bfa5-448ac39b8cedn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/fbb6b339-9284-4e54-a97b-85d99d787a61n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

[gary....@gmail.com]

Amen to that. Funny how things creep in and when you try to change one 
thing, others break.
I just did that with mosquitto. Didn't want it running as root anymore. I 
found it is quite picky about the SSL certs location and permissions.

Take the time to install properly with a fresh OS and weewx. Edit in your 
changes to weewx.conf and skins.
You'll thank yourself later.

On Wednesday, February 21, 2024 at 7:21:04 PM UTC-5 vince wrote:

FWIW, it's a good opportunity to (re)take control of your system a little 
and document what you have there.  Over time and a lot of hand tweaks it's 
easy to lose track of the configuration in good detail.  But yes having 
'before' backups always helps.



-- 
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/c7575837-9666-4a86-8a29-1680f108daa2n%40googlegroups.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

[gary....@gmail.com]

I took advantage of the opportunity to start with a new OS install and did 
a pip install. After installing extensions and copying the database to the 
new location, I edited in the changes from my old weewx.conf file. 
Surprisingly, I had old driver detritus like interceptor entries that no 
longer apply.
I use MQTT for several things. Mosquitto doesn't like to share anything SSL 
related when not running as root. Once done, every piece of the puzzle runs 
as a user. No more root.


On Wednesday, March 6, 2024 at 6:19:41 AM UTC-5 Mark Jenks wrote:

> I think that is the direction I am going to go in also.   I've been using 
> setup.py since the beginning since there was no rpm yet.
>
> I'm going to do the pip install, move all my files around to the new 
> format and restart it there.   Running mariadb, so all my data is in one 
> place already.
>
> Been here since 2011, and it's time to clean up the install anyways.
>
> On Thursday, February 22, 2024 at 9:13:16 AM UTC-6 Tom Keffer wrote:
>
>> There's nothing special about /home/weewx. You could do
>>
>> *cp -rp /home/weewx ~/weewx-data*
>> *cd ~/weewx-data*
>> *mv bin bin.old*
>> *mkdir bin*
>> *cp -r ./bin.old/user bin *
>>
>>
>> You'll have to adjust your systemd service file to reflect the new 
>> location.
>>
>> -tk
>>
>> On Thu, Feb 22, 2024 at 6:28 AM gary@gmail.com  
>> wrote:
>>
>>> Thanks for the options.
>>>
>>> I don't want to have a "hybrid" so won't be following the migration 
>>> guide method.
>>> Makes more sense to me to install new, install extensions and skins, 
>>> edit in my config from the existing (old) weewx.conf, copy the database 
>>> over, remove the old systemd service file, add the new systemd service, 
>>> move the old install to weewx.old, run the new.
>>>
>>> May be a tiny bit more effort but then should be easier for me to 
>>> maintain/update in the future.
>>>
>>>
>>>
>>> On Wednesday, February 21, 2024 at 11:07:46 AM UTC-5 Tom Keffer wrote:
>>>
>>>> Oh, I thought we were talking about upgrading from an alpha version of 
>>>> v5.
>>>>
>>>> Not much difference. Just set up a V5 virtual environment, then point 
>>>> it at /home/weewx. Follow the directions in the migration guide 
>>>> <https://github.com/weewx/weewx/wiki/v5-upgrade>. 
>>>>
>>>> On Wed, Feb 21, 2024 at 7:44 AM gary@gmail.com  
>>>> wrote:
>>>>
>>>>> I understand coming from v5 that would be a way.
>>>>> I need to upgrade my v4 setup.py to v5 though.
>>>>>
>>>>>
>>>>> On Wednesday, February 21, 2024 at 10:39:47 AM UTC-5 Tom Keffer wrote:
>>>>>
>>>>> The pip installs are super easy to back up. Just copy ~/weewx-venv and 
>>>>> ~/weewx-data and you have everything you need.
>>>>>
>>>>> Then activate the virtual environment, then "pip install weewx 
>>>>> --upgrade". It should be that easy. If something fails, just roll things 
>>>>> back.
>>>>>
>>>>> On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com  
>>>>> wrote:
>>>>>
>>>>> I've had a test install of v5 since early alphas. Now, it is time to 
>>>>> upgrade my production install.
>>>>> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. 
>>>>> A couple of additional internet uploaders (Windy and WeatherCloud). I run 
>>>>> two skins, Belchertown and weewx-wdc
>>>>>
>>>>> All is and has been quite stable. So, I hesitate to poke at it. But, 
>>>>> v5 is the new standard, so I need to get this done.
>>>>>
>>>>> I don't see many who have trod this path. How to go about 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+...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-3

Re: [weewx-user] Re: Cumulus MX -> weewx

[gary....@gmail.com]

Is your CMX install still active? My logger doesn't accept multiple 
connections.

On Tuesday, March 19, 2024 at 8:39:35 PM UTC-4 Sidney wrote:

> Thank you. I'm on it. Getting some issues error messages unfortunately. Do 
> you please have an idea what's wrong?
>
> root@kralovice:~# weectl device --info
>
> Using configuration file */etc/weewx/weewx.conf*
>
> Using driver weewx.drivers.vantage.
>
> Using Vantage driver version 3.6.2 (weewx.drivers.vantage)
>
> Traceback (most recent call last):
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 354, in openPort
>
> self.socket.connect((self.host, self.port))
>
> socket.timeout: timed out
>
>
> During handling of the above exception, another exception occurred:
>
>
> Traceback (most recent call last):
>
>   File "/usr/share/weewx/weectl.py", line 74, in 
>
> main()
>
>   File "/usr/share/weewx/weectl.py", line 42, in main
>
> weectllib.device_actions.device()
>
>   File "/usr/share/weewx/weectllib/device_actions.py", line 91, in device
>
> configurator.configure(config_dict)
>
>   File "/usr/share/weewx/weewx/drivers/__init__.py", line 71, in configure
>
> self.do_options(options, parser, config_dict, not options.noprompt)
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 2238, in 
> do_options
>
> station = Vantage(**config_dict[DRIVER_NAME])
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 536, in __init__
>
> self.port.openPort()
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 359, in openPort
>
> raise weewx.WeeWxIOError(ex)
>
> weewx.WeeWxIOError: timed out
>
> root@kralovice:~# weectl device --info
>
> Using configuration file */etc/weewx/weewx.conf*
>
> Using driver weewx.drivers.vantage.
>
> Using Vantage driver version 3.6.2 (weewx.drivers.vantage)
>
> Traceback (most recent call last):
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 354, in openPort
>
> self.socket.connect((self.host, self.port))
>
> socket.timeout: timed out
>
>
> During handling of the above exception, another exception occurred:
>
>
> Traceback (most recent call last):
>
>   File "/usr/share/weewx/weectl.py", line 74, in 
>
> main()
>
>   File "/usr/share/weewx/weectl.py", line 42, in main
>
> weectllib.device_actions.device()
>
>   File "/usr/share/weewx/weectllib/device_actions.py", line 91, in device
>
> configurator.configure(config_dict)
>
>   File "/usr/share/weewx/weewx/drivers/__init__.py", line 71, in configure
>
> self.do_options(options, parser, config_dict, not options.noprompt)
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 2238, in 
> do_options
>
> station = Vantage(**config_dict[DRIVER_NAME])
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 536, in __init__
>
> self.port.openPort()
>
>   File "/usr/share/weewx/weewx/drivers/vantage.py", line 359, in openPort
>
> raise weewx.WeeWxIOError(ex)
>
> weewx.WeeWxIOError: timed out
>
> On Wednesday, March 20, 2024 at 1:33:24 AM UTC+1 Rainer Lang wrote:
>
>> in addition, look up
>>
>>
>> https://weewx.com/docs/5.0/utilities/weectl-station/#create-a-new-station-data-directory
>>
>> there you find the example how to create a Vantage station (of course the 
>> values for altitude, longitude, latitude have to be replaced by your values)
>>
>> weectl station create --no-prompt --driver=weewx.drivers.vantage \
>> --altitude="400,foot" --latitude=45.1 --longitude=-105.9 \ 
>> --location="My Special Station"
>>
>> the result should be a properly configured weewx.conf
>>
>> On 20.03.2024 01:20, Rainer Lang wrote:
>>
>> try reading (and applying) https://weewx.com/docs/5.0/hardware/vantage/
>> On 20.03.2024 01:07, Sidney wrote:
>>
>> Type: Davis Vantage Pro2/Vue  
>> Station model: WeatherDuino 4Pro DB 
>> Connection: TCP/IP 
>> IP: http://192.168.0.39
>>
>> Thank you Rainer. 
>> On Wednesday, March 20, 2024 at 12:42:51 AM UTC+1 Rainer Lang wrote:
>>
>>> I'm not sure if you have understood the weewx concepts ...
>>>
>>> What would be the use of changing skins - except you don't like the 
>>> Seasons skin 
>>> But  before you do this, you better get weewx running with the default 
>>> Seasons skin.
>>> Once running, you can add or switch skins.
>>>
>>> You probably want to use data from your station - then you have to 
>>> change your station, not the skin
>>>
>>> You need to install the driver for your station ...
>>>
>>> So you have to install the respective weewx driver for your station 
>>> which would then replace the Simulator station.
>>>
>>> What's your station ? Brand, model ?
>>> On 20.03.2024 00:35, Sidney wrote:
>>>
>>> I was able to instal nginx. yay! Thanks for advising me. 
>>> [image: Screenshot 2024-03-20 at 0.26.53.png]
>>> I'm now trying:
>>> change the skin and get out of simulation to real data. Unfortunately, I 
>>> have no luck with it.
>>> I'm using the following:
>>>
>>> # Stop the daemon sudo systemctl stop weewx # Reconfigure to use your 
>>> har

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[gary....@gmail.com]

I have added these lines to my weewx service file for just such an instance.
Add under StandardError=journal+console entry in the [Service] stanza

Restart=on-failure
RestartSec=30

Restarts weewx after waiting for 30 seconds to allow whatever interfered to 
(hopefully) clear.

On Monday, March 25, 2024 at 6:26:44 PM UTC-4 vince wrote:

> Perhaps this setting (link) 
> 
>  is 
> something to try if you want to experiment and let us know if it works…
>
> On Monday, March 25, 2024 at 3:11:41 PM UTC-7 Thomas Hackler wrote:
>
>> thank you for the answer, then it was maybe soemthing wrong with the wifi
>>
>> does it make sense to increase the attempts before exit ?
>>
>> I try to find something to check if the process is running
>> I have some experience with monit, so maybe I find an example or anything 
>> else
>>
>>
>> vince schrieb am Montag, 25. März 2024 um 22:09:58 UTC+1:
>>
>>> I have also seen my gw1000 weewx setup abort on the pi4 occasionally 
>>> when the wifi network bounces for some reason.  Mine's been up for 6 weeks 
>>> now so it is definitely a transient kind of thing.
>>>
>>> Writing yourself a little cron job to look for the weewxd process and if 
>>> it's not there restart it wouldn't be too tough to do.   Perhaps there is 
>>> some systemd configuration magic that is possible, but I'm not sure there 
>>> what a safe+effective way to leverage systemd would look like.  I know how 
>>> cron works :-)
>>>
>>> On Monday, March 25, 2024 at 1:56:10 PM UTC-7 Thomas Hackler wrote:
>>>
 Hello,
 my weewx stopped yesterday unexpected. The last logs are attached. It 
 ran stable for over 1 week. I have restarts of my raspberry pi with cron 
 every 1 or 2 days. What is the reason that the gw1000 driver has suddenly 
 a 
 problem? How can I avoid it in future? Should I increase the attemps if 
 there is a short problem with the wifi connection?
 It is a problem of my gw1000 device? I see no problems with the ecowitt 
 app.
 Thank you!
 Regards
 Thomas

>>>

-- 
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/ef87a5ba-2185-4d09-8f79-d2882d7e358en%40googlegroups.com.

[weewx-user] WeeWX 4.6.2 Working Well

[gary....@gmail.com]

With the rapid succession of releases, I just wanted to say that my upgrade 
to 4.6.2 went well and all is working with the VP2, WifiLogger2, and 
Belchertown skin.

Thanks for an amazing system!

-- 
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/05ca4f00-9b2a-4ad1-99bc-2c3dcc59fbe2n%40googlegroups.com.

[weewx-user] Calculated Data Missing Intermittently in Graphs

[gary....@gmail.com]

I noticed that calculated data goes missing randomly on my install.
The actual data is graphed continuously, so to me, doesn't look like a 
reception issue.
The ISS Receive Stats also do not show a drop out.

Any ideas?


-- 
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/202fa466-cdc9-4816-9674-059ce6d1bb18n%40googlegroups.com.

[weewx-user] Re: WeeWx 4.7.0 and TE923 weather station running on a Pi4. Problem when restarting (sudo /etc/init.d/weewx restart or Pi reboot)

[gary....@gmail.com]

You are going to need to post your weewx.conf, but the error says the 
archive interval is 129, which is apparently not a supported value. Change 
that to 300 (for 5 minutes) and see what transpires.

Follow this link on how to post a help request:
https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user

On Tuesday, April 19, 2022 at 6:17:11 AM UTC-4 Pierre-Yves wrote:

> Hello,
>
> After having made a small change to the weewx.conf (station website 
> registration), I experienced problems for restarting, typing "sudo 
> /etc/init.d/weewx restart". Same result when rebooting the PI4.
> About 20 times, the restart failed with the following syslog messages :
>
> Apr 18 19:12:50 weewx weewx[2225] ERROR weewx.drivers.te923: Unrecognized 
> archive interval '129'
> Apr 18 19:12:50 weewx weewx[2225] INFO weewx.engine: Main loop exiting. 
> Shutting engine down.
> Apr 18 19:12:50 weewx weewx[2225] CRITICAL __main__: Caught WeeWxIOError: 
> Unrecognized archive interval '129'
> Apr 18 19:12:50 weewx weewx[2225] CRITICAL __main__:   Waiting 60 
> seconds then retrying...
>
> Finally at 19:37:29, weewx restart succeeded and since works fine.
>
> I noticed also this syslog line :
>
> Apr 18 19:12:50 weewx weewx[2225] INFO weewx.drivers.te923: station time 
> is 1650236400.0, computer time is 1650301970
>
> I do not understand why the station and computer timestamps are so 
> different.
>
> Syslog is attached
>
> Any idea on what could cause that behavior ?
>
> Thanks a lot,
>
> Pierre-Yves

-- 
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/9537afa8-31be-4702-8d1c-f4cc2dda3c16n%40googlegroups.com.

[weewx-user] Re: Bootstrap skin a.k.a "fuzzy-archer" v4.0 preview available

[gary....@gmail.com]

I see no configuration instructions.
Surely there must be some if this uses MQTT for live updates.

On Saturday, March 4, 2023 at 6:10:31 PM UTC-5 michael.k...@gmx.at wrote:

> Another week over, I've fixed several bugs, added missing functionality 
> and did some little enhancements on the styles. I've put everything in the 
> master branch by now, so if you want to updated, the feature branch is now 
> obsolete. By the way, thanks for the feedback and issues on github. Also 
> thanks to Tom, who is always precise in his feedback, helps a lot.
>
> Still: there is help needed for skin specific translations.
>
>
>
>
> michael.k...@gmx.at schrieb am Sonntag, 26. Februar 2023 um 15:05:02 
> UTC+1:
>
>> Hi all,
>>
>> there is a new version of the Bootstrap skin in the pipeline. Last year 
>> this skin has been modernized and updated with interactive gauges and 
>> charts, also, using MQTT live updates were made available.
>>
>> Preview: https://www.kainzbauer.net/weather/Rif/en/
>>
>> The version is still under development, to install it anyway, 
>> download the "lang" branch here:
>>
>> https://github.com/brewster76/fuzzy-archer/archive/refs/heads/lang.zip
>>
>> wee_extension --install lang.zip
>>
>> Although I've installed it on several test environments, I cannot 
>> guarantee everything will work flawlessly by now.
>>
>> If you encounter problems, please file any issues here: 
>> https://github.com/brewster76/fuzzy-archer/issues and let me know in 
>> this thread. 
>>
>> Version 4 now has few new features so far, but in another way it is 
>> completely new:
>>
>> New in v4.0:
>>
>>- Complete and thorough overhaul of the skin, many breaking changes. 
>>It is recommended to start over with a fresh install
>>- This skin used to consist of three skins, now reduced to one
>>- Localization is now done the WeeWX way (hopefully Tom doesn't 
>>disagree on this one)
>>- Less and easier configuration
>>- Many customization can now be done by configuration only, no more 
>>need to touch the templates
>>- Day/night background in Live Charts (needs pyephem installed)
>>- Bug fixes and other enhancements
>>
>> However, there are still some things to do, help is needed doing the 
>> translations for:
>>
>>- traditional chinese
>>- czech
>>- spanish
>>- finnish (there isn't even a language file stub yet)
>>- french
>>- greek
>>- italian
>>- korean (there isn't even a language file stub yet)
>>- dutch
>>- thai
>>
>> Let me know, if you try you manage to run it without any issues also:)
>>
>

-- 
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/2b1e7715-cb27-44b7-9be9-9bd380b7b8cfn%40googlegroups.com.

[weewx-user] Re: Webpage won't connect to MQTT

[gary....@gmail.com]

It's likely that the websockets port is not 443 as that is https and you do 
have your reverse proxy set for 9001


On Sunday, March 5, 2023 at 7:47:25 PM UTC-5 Rich M wrote:

> I've been setting up Weewx with Belchertown, and everything seems to be 
> working great...except that I cannot connect to the MQTT within the skin.
>
> My Mosquito server is running in a docker on my Unraid server, and I have 
> an Ubuntu VM that is gathering UDP packets from my Tempest Weatherflow 
> station.  Weewx is writing the data to the Mosquito server without 
> problem.  I can connect to the server on my local network with MQTT 
> Explorer, and I can see the weather data & loop.  
>
> For the web page, I'm running a Cloudflare tunnel into my network, and I 
> have a CaddyV2 reverse proxy between the tunnel and the web server.  I'm 
> able to access the website from the Internet without problem:  
> https://www.2whippets.org/weather/belchertown/
>
> I have a DNS entry for mqtt.whippets.org set up in cloudflare for the 
> websockets, and I'm able to use MQTT Explorer to connect to the tunnel from 
> the internet.  wg://mqtt.2whippets.org on port 443 (with TLS 
> encryption).  It goes through the cloudflare tunnel to the caddy proxy that 
> has a config as such:
>
> {
>   log
>   tls internal
>   reverse_proxy 192.168.254.3:9001 
> }
>
> And it works through MQTT Explorer.  
>
> However, in my Weewx.conf file, my connection looks like this:
>
> #--- MQTT Websockets (for Real Time Streaming) Options ---
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "ws://mqtt.2whippets.org"
> mqtt_websockets_port = 443
> mqtt_websockets_ssl = 0
> mqtt_websockets_topic = "weather/#"
> # disconnect_live_website_visitor = 180
>
> It doesn't seem to make any difference if I turn on Websockets_ssl.  It 
> still fails.  
>
> I'm using the cloudflare tunnel so that all of the certificates are taken 
> care of by cloudflare...and I don't have to open any ports on my firewall.  
>
> Any ideas of where to troubleshoot?
>
> Thanks
>
> rm
>

-- 
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/aa7e51f6-9ec3-49ea-8c97-71290db33f88n%40googlegroups.com.

[weewx-user] Re: Bootstrap skin a.k.a "fuzzy-archer" v4.0 preview available

[gary....@gmail.com]

Thanks for that.
See your github discussions.

On Monday, March 6, 2023 at 3:41:40 AM UTC-5 michael.k...@gmx.at wrote:

> Hi Gary,
>
> in some of the latest commits I've put some instructions and example in 
> the shipped configs, yet they are neither complete nor very exhaustive. 
> Maybe we can improve this.
>
> First, where to start from?
>
> The basics: for having live data shown in the charts and gauges, you need:
>
>- A data source (in most cases this your weather station, but it is 
>not limited to this unique source)
>- A MQTT Broker for publishing data from the source and subscribing to 
>the topics you publish
>- Enabling the data source to emit data using MQTT. With weewx, 
>install https://github.com/matthewwall/weewx-mqtt and get it running
>   - Bind to loop packets for have data available more or less 
>   instantly:
>   [StdRestful]
>   [[MQTT]]
>   server_url = mqtt://broker.hivemq.com:1883/
>   topic = 
>   weather_{any_distinctive_string_that_is_valid_for_topics}
>   unit_system = METRIC # or whatever you prefer *but note, 
>   this will have an impact on the "payload_key" for charts and gauges*
>   binding = loop
>   - The MQTT Broker must be publicly available for viewing live data 
>over the internet, to make it easy for now, the assumption is, you use a 
>public MQTT without needing any credentials
>- You need to set up the MQTT client for the frontend in skin.conf:
>   - [JSONGenerator]
>   ...
>   [[MQTT]]
>   [[[connections]]]
>   public_mqtt
>   broker_connection = ws://broker.hivemq.com:8000/mqtt 
>   # wss (encrypted) websocket connection
>   [topics]
>   
>   
> [[weather_{any_distinctive_string_that_is_valid_for_topics}/loop]]
>   type = JSON
>
>
> That should be a working, basic setup, if I didn't miss anything. *Note*: 
> on a https:// linke you need to set up an encrypted broker connection also 
> (wss://) or it won't work.
>
> For the payload_key of each reading:
>
> This is depending of the data source. If you set up everything as 
> described above, for showing "outTemp" it will be outTemp_F. If you use 
> METRIC or METRICWX it will be outTemp_C:
> From skin.conf:
> [LiveGauges]
> [[outTemp]]
> payload_key = outTemp_F# outTemp_C if target_unit 
> 'METRICWX', or 'METRIC'
> minvalue = 0
> maxvalue = 100
> splitnumber = 10   # choose a splitnumber 
> fitting minvalue and maxvalue: e.g.: 0/100: 10, for -20/40: 6
> lineColor = '#428bca', '#b44242'   # colors are RGBa
> lineColorUntil = 32, maxvalue  # color from start of gauge 
> to value, change color of gauge ring to show important marks: 32 is 
> freezing point
> decimals = 1   # decimals for current 
> value in gauge
> #heatMapEnabled = false# disabled heatmap for 
> gauge, default true
> #animation = False # default true
>
> Things will get a bit more complicated if you use a broker that requires 
> user accounts and login credentials.
> gary@gmail.com schrieb am Montag, 6. März 2023 um 02:25:31 UTC+1:
>
>> I see no configuration instructions.
>> Surely there must be some if this uses MQTT for live updates.
>>
>> On Saturday, March 4, 2023 at 6:10:31 PM UTC-5 michael.k...@gmx.at wrote:
>>
>>> Another week over, I've fixed several bugs, added missing functionality 
>>> and did some little enhancements on the styles. I've put everything in the 
>>> master branch by now, so if you want to updated, the feature branch is now 
>>> obsolete. By the way, thanks for the feedback and issues on github. Also 
>>> thanks to Tom, who is always precise in his feedback, helps a lot.
>>>
>>> Still: there is help needed for skin specific translations.
>>>
>>>
>>>
>>>
>>> michael.k...@gmx.at schrieb am Sonntag, 26. Februar 2023 um 15:05:02 
>>> UTC+1:
>>>
>>>> Hi all,
>>>>
>>>> there is a new version of the Bootstrap skin in the pipeline. Last year 
>>>> this skin has been modernized and updated with interactive gauges and 
>>>> charts, also, using MQTT live updates were made available.
>>>>
>>>> Previe

Re: [weewx-user] Re: WDC Skin

[gary....@gmail.com]

Version 3.1.1 has been released and this is now one of the nicest skins 
I've used.
Clear text, excellent graphs, histograms, live data from MQTT.
Scales well to tablets.
For my needs, replaced the Belchertown skin.
On Friday, August 5, 2022 at 10:43:52 AM UTC-4 Andrea Di Saverio wrote:

> Sorry for my late replay.
>
> Yes, the suggestion solved my problem. I was not installing as root user.
> Thank you.
>
> Il giorno giovedì 4 agosto 2022 alle 01:46:26 UTC+2 david@gmail.com 
> ha scritto:
>
>> @disaveri Did this solve your problem?
>>
>> Btw: I released 2.0.1 which resolves the "non-web-root"-issue, the 
>> "Pressure diagram with inHg unit"-issue and includes a few other bugfixes: 
>> https://github.com/Daveiano/weewx-wdc/releases/tag/v2.0.1
>>
>> Thanks for your input!
>>
>> vince schrieb am Dienstag, 2. August 2022 um 00:54:05 UTC+2:
>>
>>> On Monday, August 1, 2022 at 3:32:23 PM UTC-7 disaveri...@gmail.com 
>>> wrote:
>>>
  the root cause is possibly something else?

>>>
>>> Yes.  The 'root' cause indeed. 
>>>
>>> See the  FAQ - https://github.com/weewx/weewx/wiki/faq-permission-denied
>>>  
>>>
>>

-- 
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/88b49132-df91-4836-b570-6f91e9fa66d4n%40googlegroups.com.

Re: [weewx-user] MQTT issues with sites hosted through cloudflare

[gary....@gmail.com]

If you read their docs/faq carefully, you will note that a ws/wss 
connection is not supported.
I get around this by proxying all except the mqtt server. That one is the 
same server, just a different cname.
Give that a try. It is the only 'solution' I could come up with.

On Monday, July 24, 2023 at 11:49:06 AM UTC-4 Kevin Davis wrote:

> Do you know what ports ARE available to you?  You can change the port from 
> 1883 in config.xml.
>
> -Kevin 
>
> On Mon, Jul 24, 2023 at 8:20 AM Kevin Crivelli  
> wrote:
>
>> I have been able to get MQTT to work via my local address inside my 
>> network however when I attempt to do this at my website 
>> https://kevinheaven.net which goes through cloudflare I am unable to get 
>> this to work. I had discovered that cloudflare does not support the ports 
>> that mqtt work through. I am wondering if anyone else has run into this 
>> issue and if so has found a work around for it. I am using a public MQTT 
>> broker hive.mq.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/0a014d25-6dc5-432c-b53e-0d6ccc299288n%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/94e58efa-9a56-4141-9758-7ec8ecf4548bn%40googlegroups.com.

Re: [weewx-user] MQTT issues with sites hosted through cloudflare

[gary....@gmail.com]

Doesn't matter where the mosquitto server is hosted, cloudflare doesn't 
allow WS or WSS
Yes, my server has it's own SSL cert and is a cname, no proxy via 
cloudflare.


On Tuesday, July 25, 2023 at 9:55:05 PM UTC-4 Kevin Crivelli wrote:

> I get that in theory and I think I got close to setting that up right 
> before but could you give me some more details on your setup? Do you just 
> make like anl cname for the mqtt like mqtt.yourdnsname.com and turn off 
> proxy for it. Here's the thing tho, I'm using a public mqtt server. Thought 
> that would get around it.. I'm just confused but on the right track 
>
> On Tue, Jul 25, 2023, 9:47 PM gary@gmail.com  
> wrote:
>
>> If you read their docs/faq carefully, you will note that a ws/wss 
>> connection is not supported.
>> I get around this by proxying all except the mqtt server. That one is the 
>> same server, just a different cname.
>> Give that a try. It is the only 'solution' I could come up with.
>>
>> On Monday, July 24, 2023 at 11:49:06 AM UTC-4 Kevin Davis wrote:
>>
>>> Do you know what ports ARE available to you?  You can change the port 
>>> from 1883 in config.xml.
>>>
>>> -Kevin 
>>>
>>> On Mon, Jul 24, 2023 at 8:20 AM Kevin Crivelli  
>>> wrote:
>>>
>>>> I have been able to get MQTT to work via my local address inside my 
>>>> network however when I attempt to do this at my website 
>>>> https://kevinheaven.net which goes through cloudflare I am unable to 
>>>> get this to work. I had discovered that cloudflare does not support the 
>>>> ports that mqtt work through. I am wondering if anyone else has run into 
>>>> this issue and if so has found a work around for it. I am using a public 
>>>> MQTT broker hive.mq.
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "weewx-user" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to weewx-user+...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/weewx-user/0a014d25-6dc5-432c-b53e-0d6ccc299288n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/0a014d25-6dc5-432c-b53e-0d6ccc299288n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/94e58efa-9a56-4141-9758-7ec8ecf4548bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/94e58efa-9a56-4141-9758-7ec8ecf4548bn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/e81e26ae-3b59-4022-bac9-d23469a2642fn%40googlegroups.com.

Re: [weewx-user] MQTT issues with sites hosted through cloudflare

[gary....@gmail.com]

What cloudflare service are you using?
I just do my DDNS with them, then I proxy all except the MQTT.
I thought about using their tunnel, but it would have required wholesale 
changes which I didn't want to do.
On Wednesday, July 26, 2023 at 7:40:51 AM UTC-4 gary@gmail.com wrote:

> Doesn't matter where the mosquitto server is hosted, cloudflare doesn't 
> allow WS or WSS
> Yes, my server has it's own SSL cert and is a cname, no proxy via 
> cloudflare.
>
>
> On Tuesday, July 25, 2023 at 9:55:05 PM UTC-4 Kevin Crivelli wrote:
>
>> I get that in theory and I think I got close to setting that up right 
>> before but could you give me some more details on your setup? Do you just 
>> make like anl cname for the mqtt like mqtt.yourdnsname.com and turn off 
>> proxy for it. Here's the thing tho, I'm using a public mqtt server. Thought 
>> that would get around it.. I'm just confused but on the right track 
>>
>> On Tue, Jul 25, 2023, 9:47 PM gary@gmail.com  
>> wrote:
>>
>>> If you read their docs/faq carefully, you will note that a ws/wss 
>>> connection is not supported.
>>> I get around this by proxying all except the mqtt server. That one is 
>>> the same server, just a different cname.
>>> Give that a try. It is the only 'solution' I could come up with.
>>>
>>> On Monday, July 24, 2023 at 11:49:06 AM UTC-4 Kevin Davis wrote:
>>>
>>>> Do you know what ports ARE available to you?  You can change the port 
>>>> from 1883 in config.xml.
>>>>
>>>> -Kevin 
>>>>
>>>> On Mon, Jul 24, 2023 at 8:20 AM Kevin Crivelli  
>>>> wrote:
>>>>
>>>>> I have been able to get MQTT to work via my local address inside my 
>>>>> network however when I attempt to do this at my website 
>>>>> https://kevinheaven.net which goes through cloudflare I am unable to 
>>>>> get this to work. I had discovered that cloudflare does not support the 
>>>>> ports that mqtt work through. I am wondering if anyone else has run into 
>>>>> this issue and if so has found a work around for it. I am using a public 
>>>>> MQTT broker hive.mq.
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "weewx-user" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to weewx-user+...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/weewx-user/0a014d25-6dc5-432c-b53e-0d6ccc299288n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/weewx-user/0a014d25-6dc5-432c-b53e-0d6ccc299288n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/94e58efa-9a56-4141-9758-7ec8ecf4548bn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/94e58efa-9a56-4141-9758-7ec8ecf4548bn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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/06bf9e3c-0aad-43c1-a47d-508ea86effebn%40googlegroups.com.

Re: [weewx-user] Certificate Verify failed

[gary....@gmail.com]

Since they just consolidated several sites/services, I just 'reset' my 
password to the current one.
If there is anything tied to the WU password, it'll be fine.

On Saturday, August 5, 2023 at 3:46:06 PM UTC-4 Paul R Anderson wrote:

> 2 days ago I changed my password on Weather Underground after they 
> requested I do so. My new password is accepted when logging on to their 
> site. However  if I update my weewx.conf with the new password uploads 
> fail. Setting weewx.conf with the old password uploading works. I'm 
> assuming that Weather Underground doesn't sync new passwords across their 
> services on a timely basis. So just check my log daily and when uploads 
> stop working then it's time to set weewx.conf to the new password.
>
> Classic Weather Underground behavior actually they have always had flaky 
> api's and services, and things have gone from bad to worse since IBM bought 
> them. Often wonder why I still bother uploading my data to them and the 
> only reason is that I've been doing so for about 20 years.
>
> Paul  
>
> On Fri, Aug 4, 2023 at 6:07 PM Tom Keffer  wrote:
>
>> Sorry. I missed that piece of information. 
>>
>> I believe the WU uses DigiCert, so if an expired certificate is the 
>> problem, your goal is to update the DigiCert root certificate. I'm not sure 
>> how to do that on a Mac, although I'm sure there are instructions 
>> somewhere. Perhaps you can download a .pem file directly from their 
>> website. Check around.
>>
>> One thing to try is the app Keychain Access. Click on "System Roots" and 
>> look for the DigiCert certificates and see how old they are.
>>
>> Sorry I don't have anything more helpful.
>>
>> On Fri, Aug 4, 2023 at 2:33 PM David Barto  wrote:
>>
>>> This is a MacOS install, apt-get doesn’t exist. 8^(
>>>
>>> David
>>>
>>> On Aug 4, 2023, at 2:25 PM, Tom Keffer  wrote:
>>>
>>> Can't speak for the problem with forecast, but for your 
>>> CERTIFICATE_VERIFY_FAILED error, try refreshing the certificates on your 
>>> machine:
>>>
>>> *sudo apt-get update*
>>> *sudo apt-get install --reinstall ca-certificates*
>>>
>>>
>>> On Fri, Aug 4, 2023 at 2:13 PM David Barto  wrote:
>>>
 But only after I changed my password on the Wunderground.com 
  site because they asked me to. (Bas..rds)

 So it went from fine:
 Aug  1 20:43:15 Magrathea weewx[58335]: manager: Added record 
 2023-08-01 20:43:00 PDT (1690947780) to database 'weewx.sdb'
 Aug  1 20:43:15 Magrathea weewx[58335]: manager: Added record 
 2023-08-01 20:43:00 PDT (1690947780) to daily summary in 'weewx.sdb'
 Aug  1 20:43:15 Magrathea weewx[58335]: restx: CWOP: wait interval (240 
 < 600) has not passed for record 2023-08-01 20:43:00 PDT (1690947780)
 Aug  1 20:43:15 Magrathea weewx[58335]: restx: StationRegistry: wait 
 interval (85440 < 604800) has not passed for record 2023-08-01 20:43:00 
 PDT 
 (1690947780)
 Aug  1 20:43:16 Magrathea weewx[58335]: forecast: WUThread: WU: failed 
 attempt 1 to download forecast: HTTP Error 503: Service Unavailable
 Aug  1 20:43:18 Magrathea weewx[58335]: forecast: WUThread: WU: failed 
 attempt 2 to download forecast: HTTP Error 503: Service Unavailable
 Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed 
 attempt 3 to download forecast: HTTP Error 503: Service Unavailable
 Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed 
 to download forecast
 Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: no 
 forecast data for KCAPOWAY187 from http://api.wunderground.com/api

 to this:

 Aug  4 00:57:18 Magrathea weewx[58335]: manager: Added record 
 2023-08-04 00:57:00 PDT (1691135820) to database 'weewx.sdb'
 Aug  4 00:57:18 Magrathea weewx[58335]: manager: Added record 
 2023-08-04 00:57:00 PDT (1691135820) to daily summary in 'weewx.sdb'
 Aug  4 00:57:18 Magrathea weewx[58335]: restx: StationRegistry: wait 
 interval (273480 < 604800) has not passed for record 2023-08-04 00:57:00 
 PDT (1691135820)
 Aug  4 00:57:18 Magrathea weewx[58335]: restx: CWOP: wait interval (480 
 < 600) has not passed for record 2023-08-04 00:57:00 PDT (1691135820)
 Aug  4 00:57:19 Magrathea weewx[58335]: restx 
 *alert: Wunderground-PWS: Failed upload attempt 1: >>> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>*Aug  
 4 00:57:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed attempt 
 1 
 to download forecast: HTTP Error 503: Service Unavailable
 Aug  4 00:57:20 Magrathea weewx[58335]: forecast: WUThread: WU: failed 
 attempt 2 to download forecast: HTTP Error 503: Service Unavailable
 Aug  4 00:57:20 Magrathea weewx[58335]: forecast: WUThread: WU: failed 
 attempt 3 to download forecast: HTTP Error 503: Service Unavailable
 Aug  4 00:57:20 Magrathea weewx[58335]: forecast: WUThread: WU: failed 
 to dow

Re: [weewx-user] Connecting to new Davis Console model 6313

[gary....@gmail.com]

I have had good luck with the Davis WLL, though it is not my data source 
for my primary weewx instance. I use it to feed my in home tablet displays.
I have run a SDR setup in the past and while it is NOT the easiest to 
configure, it did work well once all the pieces were in place. I did need 
to get a separate device (BMP380) to provide the barometer though. If you 
run on a Pi, no problem doing that. I run off a PC with Proxmox, so I had 
to add the Pi to have barometer.

If I were the OP, I'd get the additional hardware to do SDR.
Ecowitt may be cheaper, but it certainly isn't a Davis.

On Wednesday, August 9, 2023 at 1:14:43 AM UTC-4 Graham Eddy wrote:

> swap vantage to ecowitt and you lose the data logger (stored in local 
> hardware) → one day you lose critical data
>
> ecowitt already have a ‘regularly call home' to china built in that adds 
> no value to customer, only a dependency on ecowitt company. if ecowitt turn 
> off their ‘ok’ response, everyone’s stations will reboot continually. i 
> expect them to introduce paid-only access - but they are clever not to 
> restrict the data but to disable the devices. (you might want to be wary of 
> accepting their firmware upgrades in future, for existing devices.)
>
> it is like the printer market - they flog you a printer really cheap but 
> 'charge like a wounded bull' for the ink. ditto future weather stations: 
> cheap hardware, but lock you into constant revenue stream for service. as 
> the weather station vendors try to lock down into paid-only services, i 
> plan to migrate to open lorawan devices (because i want COTS or public 
> domain products rather than build my own - more effective use of my time)
>
> but i do like my current setup, with vantage providing core weather data 
> and ecowitt lots of other inexpensive nearby sensors augmenting it, plus 
> lorawan for some more distant and more complex sensors than ecowitt 
> provides. 
> *⊣GE⊢*
>
> On 9 Aug 2023, at 1:35 pm, Bob Rose  wrote:
>
> I have been using the Ecowitt on my home weather station going on three 
> years now. I can not say anything bad about it. The Davis 6313 I am dealing 
> with is for an organization I belong to. It replaced the failing VP2. They 
> are really bummed that they spent so much money for something that does not 
> have accessible archives. I have even thought about sneaking an Ecowitt 
> system out there and telling them “I got it working”. 
>
> On Tuesday, August 8, 2023 at 8:05:51 PM UTC-7 Colin Larsen wrote:
>
>> Strangely enough I just replaced all my DIY hardware (weatherduino) with 
>> an Ecowitt setup and it's excellent for the money
>>
>> Colin
>>
>> On Wed, 9 Aug 2023 at 14:35, vince  wrote:
>>
>>> rtl_davis driver can help somewhat at a higher complexity level FWIW
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/72f7c54d-ed55-4631-8eeb-0339cbf93588n%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+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/3bbbaaf3-61b5-4574-8078-91992aca8ad4n%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/3a9e7f06-6495-4081-aab8-8ce51c17b239n%40googlegroups.com.

[weewx-user] WeeWX v5 pip Install into venv

[gary....@gmail.com]

I installed v5 from an alpha long ago. I've upgraded along the way with 
little issue.

This was on my test machine, a drive went sideways and a complete rebuild 
was in order. One good thing, a shiny new SSD is in place.

Now, it seems that a venv is preferred.

So, how to accomplish that? I have zero experience with a venv. I have had 
to use the package manager to get a couple of python packages though and 
don't know how that will work with a venv.

How will this work for systemctl (service)?
I install and manage WeeWX as root on v4.x.x but I'm going to attempt to 
run as a user with venv. Where will the WeeWX directories reside?

If there is an up to date doc/wiki dealing with this, kindly point me 
towards it.

-- 
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/3b85870b-4709-435d-8512-e94c1a4cdc1bn%40googlegroups.com.

Re: [weewx-user] WeeWX v5 pip Install into venv

[gary....@gmail.com]

Thanks guys, installed into a new ubuntu 23.04 instance using venv and as a 
normal user.
I like the new install from a url for extensions.

On Friday, August 25, 2023 at 7:23:16 PM UTC-4 Greg from Oz wrote:

> I am running V5 and I put all my venv files into /opt so I have to 
> remember to run the full path:
> EG sudo /opt/weewx/weewx-venv/bin/wee_reports 
> --config=/opt/weewx/weewx-data/weewx.conf
>
> To use the venv I run :source /opt/weewx/weewx-venv/bin/activate
> also if you want to exit the venv type the command: *deactivate*
>
> Like Tom said the systemctl uses the full path:
> ExecStart=/opt/weewx/weewx-venv/bin/python3 
> /opt/weewx/weewx-venv/lib/python3.11/site-packages/weewxd.py 
> /opt/weewx/weewx-data/weewx.conf
>
> I am running weewx as root user but my config files have my user 
> permissions and ownership.
>
> On Saturday, 26 August 2023 at 09:12:48 UTC+10 Tom Keffer wrote:
>
>> Running the venv's binaries (versus activation) is completely acceptable. 
>> Indeed, that's what the systemctl unit file does.
>>
>> On Fri, Aug 25, 2023 at 3:27 AM Greg Troxel  wrote:
>>
>>> Graham Eddy  writes:
>>>
>>> > use ‘python3 -m venv ~/venv’ to create the environment in ~/venv.
>>> > then in your shell run ’source ~/venv/bin/activate’ to set up the 
>>> shell environment (initialised python bindary, PYTHONPATH etc). i put this 
>>> in my ~/.bashrc
>>> >
>>> > a key trick is that running the initialised python binary 
>>> (~/venv/bin/python3) on its own sucks in the environment - really, really 
>>> handy in systemctl unit files
>>> > ⊣GE⊢
>>>
>>> I have never activated a venv and always been puzzled by this being the
>>> standard approach.  Simply running the venv' python binary, either
>>> explicitly on the command line, or via a #!, has been entirely fine.  I
>>> have home assistant working this way, which is super comlicated compared
>>> to weewx.
>>>
>>> I also run, when in the venv dir
>>>
>>>   bin/pip install foo
>>>
>>> which runs the venv's pip which uses the venv's python.
>>>
>>> I'm glad to hear that there is no special 'have to activate' rule about
>>> weewx.
>>>
>>>
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/rmi1qfre7t2.fsf%40s1.lexort.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/db1e2eb8-c149-42c5-8fe4-4ecfd9791551n%40googlegroups.com.

Re: [weewx-user] weewx V5 report not updating

[gary....@gmail.com]

It'll only do that once. I only have data back to 2016, but it took a long 
time to finish. Afterwards, just as quick as any other skin.
I think it is the NOAA reports.

On Sunday, September 3, 2023 at 10:39:39 PM UTC-4 vince wrote:

> Perhaps try turning WDC off and see if the problem goes away.  Certainly a 
> skin taking longer than your archive period to complete is going to cause 
> havoc for your setup
>
> On Sunday, September 3, 2023 at 7:34:39 PM UTC-7 Greg from Oz wrote:
>
>> It has been doing it days
>> There were a lot of entries in the syslog.
>>
>>
>> On Monday, 4 September 2023 at 12:32:27 UTC+10 Graham Eddy wrote:
>>
>>> perhaps it was generating all reports, as from a clean slate, and in 
>>> future it could just be incremental and less of an issue
>>> *⊣GE⊢*
>>>
>>> On 4 Sep 2023, at 12:10 pm, Greg from Oz  wrote:
>>>
>>> I guess it was wdc:
>>> Sep  3 00:21:24 moonbi weewx[1440347] INFO weewx.cheetahgenerator: 
>>> Generated 11 files for report WdcReport in 330.15 seconds
>>>
>>>
>>>

-- 
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/d7e58a60-ee38-49b2-b7c3-011e266c7c8en%40googlegroups.com.

Re: [weewx-user] weewx V5 report not updating

[gary....@gmail.com]

What version of WDC? I'm on 3.3.0


On Monday, September 4, 2023 at 5:11:20 PM UTC-4 Greg from Oz wrote:

> It was running for weeks.
> I only have 1 year of data.
> Something must have changed somewhere.
> I have disabled that skin and all is running as it was before.
>
>
> On Tuesday, 5 September 2023 at 06:38:50 UTC+10 gary@gmail.com wrote:
>
>> It'll only do that once. I only have data back to 2016, but it took a 
>> long time to finish. Afterwards, just as quick as any other skin.
>> I think it is the NOAA reports.
>>
>> On Sunday, September 3, 2023 at 10:39:39 PM UTC-4 vince wrote:
>>
>>> Perhaps try turning WDC off and see if the problem goes away.  Certainly 
>>> a skin taking longer than your archive period to complete is going to cause 
>>> havoc for your setup
>>>
>>> On Sunday, September 3, 2023 at 7:34:39 PM UTC-7 Greg from Oz wrote:
>>>
>>>> It has been doing it days
>>>> There were a lot of entries in the syslog.
>>>>
>>>>
>>>> On Monday, 4 September 2023 at 12:32:27 UTC+10 Graham Eddy wrote:
>>>>
>>>>> perhaps it was generating all reports, as from a clean slate, and in 
>>>>> future it could just be incremental and less of an issue
>>>>> *⊣GE⊢*
>>>>>
>>>>> On 4 Sep 2023, at 12:10 pm, Greg from Oz  wrote:
>>>>>
>>>>> I guess it was wdc:
>>>>> Sep  3 00:21:24 moonbi weewx[1440347] INFO weewx.cheetahgenerator: 
>>>>> Generated 11 files for report WdcReport in 330.15 seconds
>>>>>
>>>>>
>>>>>

-- 
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/96ae002f-eca4-4cc5-88c5-4b1d6c1ac4cen%40googlegroups.com.

Re: [weewx-user] weewx V5 report not updating

[gary....@gmail.com]

You may wish to look at
https://github.com/Daveiano/weewx-wdc/issues/14

On Wednesday, September 6, 2023 at 6:30:21 PM UTC-4 Greg from Oz wrote:

> # configuration file for the weewx-wdc skin
> SKIN_NAME = Weather Data Center
> SKIN_VERSION = 3.0.0
>
> On Wednesday, 6 September 2023 at 23:52:14 UTC+10 gary@gmail.com 
> wrote:
>
>> What version of WDC? I'm on 3.3.0
>>
>>
>> On Monday, September 4, 2023 at 5:11:20 PM UTC-4 Greg from Oz wrote:
>>
>>> It was running for weeks.
>>> I only have 1 year of data.
>>> Something must have changed somewhere.
>>> I have disabled that skin and all is running as it was before.
>>>
>>>
>>> On Tuesday, 5 September 2023 at 06:38:50 UTC+10 gary@gmail.com 
>>> wrote:
>>>
>>>> It'll only do that once. I only have data back to 2016, but it took a 
>>>> long time to finish. Afterwards, just as quick as any other skin.
>>>> I think it is the NOAA reports.
>>>>
>>>> On Sunday, September 3, 2023 at 10:39:39 PM UTC-4 vince wrote:
>>>>
>>>>> Perhaps try turning WDC off and see if the problem goes away. 
>>>>>  Certainly a skin taking longer than your archive period to complete is 
>>>>> going to cause havoc for your setup
>>>>>
>>>>> On Sunday, September 3, 2023 at 7:34:39 PM UTC-7 Greg from Oz wrote:
>>>>>
>>>>>> It has been doing it days
>>>>>> There were a lot of entries in the syslog.
>>>>>>
>>>>>>
>>>>>> On Monday, 4 September 2023 at 12:32:27 UTC+10 Graham Eddy wrote:
>>>>>>
>>>>>>> perhaps it was generating all reports, as from a clean slate, and in 
>>>>>>> future it could just be incremental and less of an issue
>>>>>>> *⊣GE⊢*
>>>>>>>
>>>>>>> On 4 Sep 2023, at 12:10 pm, Greg from Oz  wrote:
>>>>>>>
>>>>>>> I guess it was wdc:
>>>>>>> Sep  3 00:21:24 moonbi weewx[1440347] INFO weewx.cheetahgenerator: 
>>>>>>> Generated 11 files for report WdcReport in 330.15 seconds
>>>>>>>
>>>>>>>
>>>>>>>

-- 
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/fe694291-ada1-4730-bc90-31f1ae404663n%40googlegroups.com.

[weewx-user] #!/bin/sh does not equal #!/bin/bash

[gary....@gmail.com]

I use systemd timers for various things and after decommissioning a very 
old machine that used busybox, I recycled a cron script.

I could run the script from the cli, but it never ran via the timer.
Timer was fine, no errors were ever logged anywhere. The expected output 
just didn't occur.

Yesterday, I was looking through all my scripts adding comments to help me 
in the future.

When I opened the script that never runs, I found the problem.

#!/bin/sh does not equal #!/bin/bash

At least when calling a script via the service file fired by a systemd timer

Changed from sh to bash and voila! Change back to sh, fails silently again.

I'm sure >90% of the folks here knew this, but for those like me I figured 
I'd post.

How's this related to WeeWX? I use a systemd timer to backup the database. 
That one works a treat as I used bash, not sh

-- 
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/c2bd4a26-de51-44ba-8103-8efe020cbee9n%40googlegroups.com.

Re: [weewx-user] Can I self-host my Weewx site?

[gary....@gmail.com]

Cloudflare tunnel will do this for you.
https://blog.cloudflare.com/tunnel-for-everyone

https://www.reddit.com/r/CloudFlare/comments/zta0co/use_cloud_flare_to_bypass_cgnat/


On Tuesday, September 26, 2023 at 6:38:33 PM UTC-4 Greg from Oz wrote:

> Yes CGNAT is a pain.
> I changed ISP and now I have a fixed IP address for no extra expense.
>
> Also I have my weather on my local LAN http://192.168.1.164/weather/ and 
> ftp it to https://weather.ubeaut.work/
>
> The local site is running apache.
>
> On Wednesday, 27 September 2023 at 06:29:25 UTC+10 Kidney wrote:
>
>> For sure you can, mine is hosted on my nas system (nas does the mttq, 
>> httpd and ftp server), with 2 raspberry pi ftp’ing everything to the nas.
>>
>> http://www.gestionlgt.com/Chalet/
>> And
>> http://www.gestionlgt.com/Maison/
>>
>>
>>
>> On Sep 26, 2023, at 15:57, Eric Gammeter  wrote:
>>
>> Having trouble with my ISP's CGNAT and the MQTT (Websockets) Sub/Pub 
>> process.  Might it be possible to use the Apache web server on my 
>> RaspberryPi to host my own site?  I realize that I may still have the CGNAT 
>> issue- but at least I would no longer have to outside of my LAN to have a 
>> web presence. 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/723eadb5-b597-4c58-bf3e-cb0b3775fefdn%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/ac357391-932a-43d7-bd0c-db4b7aa79dedn%40googlegroups.com.

Re: [weewx-user] Can I self-host my Weewx site?

[gary....@gmail.com]

I didn't use a guide, but this one looks complete. Not at all difficult to 
do.
https://omar2cloud.github.io/cloudflare/cloudflared/cloudflare/
The github page for cloudflared has lots of info
https://github.com/cloudflare/cloudflared
Finally, the tunnel docs
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/


On Wednesday, September 27, 2023 at 12:55:20 PM UTC-4 Kevin Crivelli wrote:

> Gary, is there a guide to setting up the cloudflare tunneling for use with 
> the mqtt broker?
>
> On Wednesday, September 27, 2023 at 11:07:58 AM UTC-4 gary@gmail.com 
> wrote:
>
>> Cloudflare tunnel will do this for you.
>> https://blog.cloudflare.com/tunnel-for-everyone
>>
>>
>> https://www.reddit.com/r/CloudFlare/comments/zta0co/use_cloud_flare_to_bypass_cgnat/
>>
>>
>> On Tuesday, September 26, 2023 at 6:38:33 PM UTC-4 Greg from Oz wrote:
>>
>>> Yes CGNAT is a pain.
>>> I changed ISP and now I have a fixed IP address for no extra expense.
>>>
>>> Also I have my weather on my local LAN http://192.168.1.164/weather/ 
>>> and ftp it to https://weather.ubeaut.work/
>>>
>>> The local site is running apache.
>>>
>>> On Wednesday, 27 September 2023 at 06:29:25 UTC+10 Kidney wrote:
>>>
>>>> For sure you can, mine is hosted on my nas system (nas does the mttq, 
>>>> httpd and ftp server), with 2 raspberry pi ftp’ing everything to the nas.
>>>>
>>>> http://www.gestionlgt.com/Chalet/
>>>> And
>>>> http://www.gestionlgt.com/Maison/
>>>>
>>>>
>>>>
>>>> On Sep 26, 2023, at 15:57, Eric Gammeter  wrote:
>>>>
>>>> Having trouble with my ISP's CGNAT and the MQTT (Websockets) Sub/Pub 
>>>> process.  Might it be possible to use the Apache web server on my 
>>>> RaspberryPi to host my own site?  I realize that I may still have the 
>>>> CGNAT 
>>>> issue- but at least I would no longer have to outside of my LAN to have a 
>>>> web presence. 
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "weewx-user" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to weewx-user+...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/weewx-user/723eadb5-b597-4c58-bf3e-cb0b3775fefdn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/723eadb5-b597-4c58-bf3e-cb0b3775fefdn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>>

-- 
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/d23e2fb6-3f53-430f-b6e1-22266fa8d057n%40googlegroups.com.

[weewx-user] Re: 6100 Davis WeatherLink Live and 'stock' WeeWX

[gary....@gmail.com]

You may be able to use this. I have this and a WLL and like the WFL better.
https://www.scaledinstruments.com/shop/shop-by-category/data-loggers/wifilogger2/


On Wednesday, October 11, 2023 at 10:41:35 AM UTC-4 Tom Hogland wrote:

> I currently have a VP2 and use the 6316 Envoy and 6510Ser datalogger 
> connected to the PC running weewx. If you have the VP2 console close to the 
> PC you want to use for weewx you can install the new datalogger in it and 
> run the cord to the PC - nothing else required. If not, then you can either 
> use the 6316 Envoy and a 6510 datalogger in place of the console and put it 
> by your PC, or you can get a 6100 WLL. WLL replaces the Envoy and 
> datalogger and uploads directly to Davis Cloud - the "weatherlinklive" 
> driver would sniff the network and intercept those packets coming from the 
> WLL and inject them to weewx. 
>
> Note that the WLL has temp/humidity and barometer built in. It can read 
> additional wireless sensors, but so can the Envoy - each has 8 channels it 
> can listen to. Both are pricey, but it appears that WLL is the "way of the 
> future" for them, rather than the Envoy.
>
> My VP2 combination has been online since about 2004 without issue, and 
> using weewx since wview went defunct several years ago. I also run a 
> Tempest, and I'm looking forward to replacing my weird "dual station" 
> configuration with two small containers using v5.
>
> -Tom
>
>
> On Wednesday, October 11, 2023 at 5:54:29 AM UTC-8 Rich Strle wrote:
>
>> Question: Will the ‘stock’ WeeWX driver communicate with the 6100 Davis 
>> WeatherLink Live?
>>
>>
>> Detail:
>>
>>
>> I have upgraded to a Davis VantagePro2 (VP2) from a VantagePro1 (VP1).
>>
>>
>> Currently I get data from the VP1 from a Davis Envoy product number 6314 
>> with a serial data logger installed.
>>
>>
>> To get the same functionality in my VP2 I need a new Davis Envoy product 
>> number 6316 Data Envoy and a new data logger 6510USB Davis WeatherLink 
>> Computer Interface.
>>
>>
>> Would I be better off with a 6100 Davis WeatherLink Live? It seems to 
>> offer more functionality like adding additional sensors including the Davis 
>> Airline air quality sensor.
>>
>>
>> In the Vantage Notes section:
>>
>>
>> “The Davis Vantage stations include a variety of models and 
>> configurations. The WeeWX driver can communicate with a console or envoy 
>> using serial, USB, or TCP/IP interface.”
>>
>>
>> Poking around in the drivers section of the wiki, I see a weatherlinklive 
>> weewx-driver. Is that my best option to feed data into weewx?
>>
>>
>> Or will the ‘stock’ WeeWX driver communicate with the 6100 Davis 
>> WeatherLink Live?
>>
>>
>> Apologies for the long drawn out question. My VP1 ran since 2001 and fed 
>> data to my website since then. A lot has changed since then.
>>
>

-- 
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/eae2b3a9-6774-4c05-ba69-c63cbd5c6a64n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gary....@gmail.com]

I see that b5 maps 'luminosity': 'light'
In my weewx.conf I have
radiation = light / 126.7 if light is not None else None

To display that value in the Belchertown skin I have 
station_observations = barometer, dewpoint, outHumidity, rainWithRainRate, 
radiation, UV

When running with the Interceptor driver I have a value, running with this 
driver I have N/A

Any ideas?

-- 
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/2310c260-1695-455b-bc5c-9126ba918340n%40googlegroups.com.

[weewx-user] Re: Belchertown MQTT live stats problem

[gary....@gmail.com]

Try removing the IP from your config and try.

#  netstat -ntap | grep 9001
tcp6   0  0 :::9001 :::*LISTEN  
1365/mosquitto
tcp6   0  0 10.10.100.110:9001  10.10.100.1:10021  
 ESTABLISHED 1365/mosquitto


On Sunday, July 26, 2020 at 5:21:24 PM UTC-4 sgra...@gmail.com wrote:

> No worries... just very strange the live stats dont work anymore even 
> though it 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/11e8c2ca-9012-4148-bcc4-b5b81260f611n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gary....@gmail.com]

This is a 915 MHz unit

Interrogating GW1000 at 10.10.100.125:45000

GW1000 frequency: 2 (Unknown)
GW1000 sensor type: 1 (WH65)
GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
GW1000 timezone: 19


On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:

> v0.1.0b6 added the --system-params command line option to the driver to 
> display a number of GW1000 system parameters, eg:
>
> GW1000 frequency: 0 (433MHz)
> GW1000 sensor type: 0 (WH24)
> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
> GW1000 timezone: 94
>
> Whilst I know which byte to look at for the frequency, and what value 
> represents 433MHz as used on my GW1000, I do not know what value is used to 
> represent operation on 868MHZ and 915MHz. Was wondering if any users of 
> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
> frequency their GW1000 uses as well as the output from the following 
> command (adjusting python version and path as required):
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>
> I don't believe any of the information is particularly sensitive, but if 
> you are concerned I really just need to know the frequncy your GW1000 
> operates on as well as the line starting 'GW1000 frequency'. If you don't 
> know what frequency your GW1000 operates on it should be printed on the 
> back of your GW1000 (well at least mine is like that!)
>
> thanks,
> 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/1e253425-6509-4538-9dfe-3a44c80f2e14n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gary....@gmail.com]

Though this is not a WH65

I have a GW1000, WS68, WH40, WH32-EP, WH32B

On Monday, July 27, 2020 at 8:58:54 PM UTC-4 gary@gmail.com wrote:

> This is a 915 MHz unit
>
> Interrogating GW1000 at 10.10.100.125:45000
>
> GW1000 frequency: 2 (Unknown)
> GW1000 sensor type: 1 (WH65)
> GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
> GW1000 timezone: 19
>
>
> On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:
>
>> v0.1.0b6 added the --system-params command line option to the driver to 
>> display a number of GW1000 system parameters, eg:
>>
>> GW1000 frequency: 0 (433MHz)
>> GW1000 sensor type: 0 (WH24)
>> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
>> GW1000 timezone: 94
>>
>> Whilst I know which byte to look at for the frequency, and what value 
>> represents 433MHz as used on my GW1000, I do not know what value is used to 
>> represent operation on 868MHZ and 915MHz. Was wondering if any users of 
>> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
>> frequency their GW1000 uses as well as the output from the following 
>> command (adjusting python version and path as required):
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>>
>> I don't believe any of the information is particularly sensitive, but if 
>> you are concerned I really just need to know the frequncy your GW1000 
>> operates on as well as the line starting 'GW1000 frequency'. If you don't 
>> know what frequency your GW1000 operates on it should be printed on the 
>> back of your GW1000 (well at least mine is like that!)
>>
>> thanks,
>> 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/b11f99dc-951e-4a4e-bbe7-4b27529b5d1fn%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gary....@gmail.com]

My wind results have been corrected.

On Tuesday, July 28, 2020 at 9:55:22 AM UTC-4 gjr80 wrote:

> Bill, the incorrect wind direction decode likely accounts for your wind 
> direction discrepancies. Not sure about the pressure issues, as far as I am 
> aware pressure is being correctly decoded. I will look into it further in 
> the morning.
>
> Gary
>
> On Monday, 27 July 2020 20:03:01 UTC+10, Bill Arthur wrote:
>>
>> Thanks Gary.  
>> Your instructions worked perfectly.
>>
>> I'm still seeing a couple of things. Here are links to two reporting 
>> stations. They both receive data from the same GW-1000
>> The -1 station uses the old push method. The -5 station uses the new API 
>> method.  I'm seeing differences in wind direction and barometer
>> -1 Station 
>> -5 Station 
>>
>

-- 
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/640a1857-01a3-498d-9819-ab152372ae2fn%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gary....@gmail.com]

I have installed b8 successfully and note that nothing was changed in my 
weewx.conf except the addition of the extractors.



On Thursday, July 30, 2020 at 2:08:46 AM UTC-4 gjr80 wrote:

> I have released v0.1.0b8 on Github 
>  which:
>
> - fixes an incorrect mapping of GW1000 field relbarometer that will have 
> resulted in incorrect barometer and altimeter fields in WeeWX
> - changes default field mappings of GW1000 fields rainhour, rainday, 
> rainweek, rainmonth, rainyear, raintotals and rainevent to hourRain, 
> dayRain, weekRain, monthRain, yearRain, totalRain and stormRain respectively
> - changes default field mapping of GW1000 field uv from uvRadiaition to 
> uvradiation
> - fixes a bug that resulted in battery state mappings not being included 
> in the default field map displayed with the --default-map command line 
> option
> - adds extractors for all fields from default field map (incl battery 
> state map) that need an extractor function other than avg
>
> As b8 includes extractor functions for a number of fields b8 requires 
> changes to weewx.conf. For this reason the best way to upgrade to or 
> install b8 is by downloading the extension package and installing using 
> wee_extension. I will update the manual install instructions on the GW1000 
> driver wiki shortly. Upgrading by installing the extension package should 
> retain any customised settings you may have made to weewx.conf, in any case 
> a timestamped backup copy of weewx.conf is made by wee_extension and it 
> might pay to check that any customisations in the [GW1000] stanza have been 
> retained.
>
> For those that may have incorrect barometer/altimeter data as a result of 
> the incorrect relbarometer mapping, users of WeeWX 4.0.0 or later should be 
> able to recalculate the incorrect data by first deleting the incorrect 
> barometer and altimeter data from the archive and then running wee_database 
> using the --calc-missing action. You will then need to rebuild your daily 
> summaries using --rebuild-daily. i will publish some detailed instructions 
> later tonite.
>
> 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/996540e6-1c7c-45e8-a29b-9b43f2718d71n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gary....@gmail.com]

I have reinstall b8 and now have both the old and new rain related entries 
in weewx.conf

[[stormRain]][[hourRain]][[dayRain]][[weekRain]][[monthRain]][[yearRain]][[totalRain]]

[[rainevent]][[rainhour]][[rainday]][[rainweek]][[rainmonth]][[rainyear]][[raintotals]]

On Thursday, July 30, 2020 at 7:07:10 AM UTC-4 gjr80 wrote:

> Good, just check that you have [Accumulator] entries for hourRain, dayRain 
> etc and not rainhour, rainday etc. If you don’t download the b8 extension 
> package again and re-install. I had an upload issue with the package 
> earlier today.
>
> 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/30a5d402-8e45-4bc5-98c4-91e57a9f7d7an%40googlegroups.com.

[weewx-user] Re: What do I need?

[gary....@gmail.com]

The WLL (Not new console) works great with my Davis setup.
The weewx-weatherlink-live driver is rock solid.

On Tuesday, July 23, 2024 at 6:58:35 PM UTC-4 Barton Phillips wrote:

> I looked at all the wll implementation you mentioned in your former post 
> Vince, and https://github.com/michael-slx/weewx-weatherlink-live looks 
> like the most recently updated. It also uses the new weectl function. 
> I have not done much python programming. During my career days I 
> programmed mostly in C and later C++. Now that I am retired I have been 
> doing some web programming in PHP, JavaScript and a little node.
> I would love to try to build a wll test generator but I don't think I have 
> the patients to slog through learning python. I hope someone has already 
> done the work.
> Thanks
>
> On Tuesday, July 23, 2024 at 6:17:54 PM UTC-4 Barton Phillips wrote:
>
>> Does anyone know of a testing program that could simulate the WLL sending 
>> data over the WiFi network. That might be a helpful tool.
>>
>> On Monday, July 22, 2024 at 8:53:55 PM UTC-4 vince wrote:
>>
>>> No, weewx supports all kinds of interfaces including network depending 
>>> on which gear you have.
>>>
>>> Tom was likely suggesting the hardware datalogger because it 'is' pretty 
>>> nice if you have the old console and can direct connect to the weewx system 
>>> because of the logging and backfill functionality, but there are a lot of 
>>> ways of connecting stuff up end to end.
>>>
>>> There are a bunch of old WLL drivers if you google search for "weewx 
>>> WLL" and poke around a bit.   (wow - I wrote one too ages ago according to 
>>> https://www.wxforum.net/index.php?topic=41328.0 that I again forgot. 
>>>  Back then in 2020 a bunch of folks did initial versions.)
>>>
>>> https://github.com/michael-slx/weewx-weatherlink-live seems most 
>>> current and maintained.  A quick search of the weewx map shows over 35 
>>> registered WLL systems so there have to be a lot more actual users.   A 
>>> quick look at the driver's installation web page seems to say you need to 
>>> configure the ip address of the WLL device so weewx can talk to it over the 
>>> network, so you probably are looking pretty good for a Vue plus WLL unless 
>>> I'm reading it wrong.
>>>
>>> I can't speak to whether there are lower cost options, but if it was 
>>> 'me' considering I have the gear, I'd just do a Vue sensor suite and 
>>> rtldavis using a rtl-sdr dongle and antenna (which I already have) so that 
>>> gets it into the $100 plus Vue sensor suite kind of price range.  WLL adds 
>>> more stuff of course and is more turnkey at some large additional price. 
>>>  Really comes down to the time-value of your labor and blood pressure to 
>>> integrate and support it all.
>>>
>>>
>>> On Monday, July 22, 2024 at 5:20:14 PM UTC-7 Barton Phillips wrote:
>>>
 I am sorry for the confusion. I had emailed Tom Keffer with some 
 questions about the WLL model 6100 and he answered me saying I should use 
 the Windows Data Logger. I replied that I do not use Windows; I use Ubuntu 
 22.04 Linux. I asked if the Vantage Vue plus the WLL would work. He 
 replied 
 that I should post on the weewx-user group. I have not purchased either 
 the 
 Vantage Vue or the WLL yet as I want to make sure that they will work with 
 weewx. I had a AcuRite Isis 5 in 1 that I sent back to Amazon because I 
 could not figure out how to capture the WiFi that is sent to Weather 
 Underground. So that is the rest of the story.

 Now I want to know if the weewx program can be used with the Vantage 
 Vue and the WLL before I purchase them from Amazon. The WLL has both WiFi 
 and an Eithernet port. It does not have USB. Can the Eithernet be run into 
 my desktop computer (it does not have WiFi) and can I somehow capture the 
 data and route it to weewx? Does weewx only work with serial or USB?

 Thanks.

 On Monday, July 22, 2024 at 6:09:24 PM UTC-4 vince wrote:

> Uncertain what exactly you're asking there.  Are you replying to a 
> post that isn't visible or an email or something perhaps ?
>
> If you have the old original 1970s-LCD-looking ugly console, you can 
> use the absurdly overpriced Davis USB or serial datalogger to connect it 
> to 
> your weewx computer (and throw the unnecessary Windows software in the 
> trash). I have a serial version and use a serial2usb converter to connect 
> it to my raspi.  There are a variety of third-party variants that do 
> basically the same thing for less cost.  Meteopi is one of those. 
> https://www.scaledinstruments.com/product-category/shop-by-category/data-loggers/
>  
> has some others.
>
> If you have the new tablet-like color console, you can not connect 
> that directly to your weewx computer because Davis provides no way to do 
> so 
> at all.  There's also no programming interface.  Ugh.
>
> Th

[weewx-user] Re: Belchertown and MQTT configuration error

[gary....@gmail.com]

Do you have an acl and does it resemble this?
# Allow anonymous access to the sys
topic read $SYS/#
 
# Allow anonymous to read weather
topic read weather/#
topic read tester/#
 
# weewx readwrite to the loop
user weewx
topic weather/#
topic tester/#

Did you create a password for the weewx user (not the linux user, the mqtt 
user)?

Does your mosquitto conf file resemble this?
persistence false
allow_anonymous true
password_file /etc/mosquitto/pwfile
acl_file /etc/mosquitto/acl
# Insecure mqtt to localhost only, and secure mqtt
listener 1883
listener 8883
certfile /etc/mosquitto/certs/cert.pem
cafile /etc/mosquitto/certs/chain.pem
keyfile /etc/mosquitto/certs/privkey.pem
protocol mqtt
 
# websockets
listener 8080
certfile /etc/mosquitto/certs/cert.pem
cafile /etc/mosquitto/certs/chain.pem
keyfile /etc/mosquitto/certs/privkey.pem
protocol websockets
On Wednesday, July 31, 2024 at 11:47:46 PM UTC-4 M&M wrote:

> I checked mosquitto.conf and it has "listener 1883" in it.  I also 
> disabled my pihole and checked that my raspberry pi is listening on port 
> 1883.  
>
> On Friday, July 26, 2024 at 11:23:25 PM UTC-4 M&M wrote:
>
>> I checked journalctl and now I'm seeing this error:
>>
>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>> AmbientAPI get_devices() returned empty dict
>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: ambientweatherapi driver 
>> encountered an error.
>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>> ambientweatherapi driver encountered an error.
>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: Error caught was: AmbientAPI 
>> get_devices() returned empty dict
>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>> Error caught was: AmbientAPI get_devices() returned empty dict
>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: ambientweatherapi driver had 
>> an error sending data to weewx.
>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>> ambientweatherapi driver had an error sending data to weewx.
>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: Error caught was: Previous 
>> error occured, skipping packet build.
>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>> Error caught was: Previous error occured, skipping packet build.
>>
>> On Friday, July 26, 2024 at 11:20:51 PM UTC-4 M&M wrote:
>>
>>> Making some progress.  I am back to having weewx running and I now have 
>>> mosquito running as well.  I was able to test that service by mosquitto_sub 
>>> and mosquitto_pub which worked by sending "hello world".  However when I 
>>> check my local Belchertown page, it now says this at the top:
>>>
>>> Failed connecting to the weather station. Please try again later! Last 
>>> Updated 26 July 2024, 23:10:00
>>>
>>> On Friday, July 26, 2024 at 2:02:17 PM UTC-4 M&M wrote:
>>>
 Oh thats right!  I edited the /etc/default/locales file.  I changed it 
 from en_GB.UTF-8 to en_US.UTF-8 since I was trying to fix the time in 
 Belchertown skin to show a 12h time format.  I believe I fixed it and for 
 some reason, i decided to edit the locales file.  I'll change that back 
 when I get to that system.

 Thanks.  I believe that is what will fix it.

 On Friday, July 26, 2024 at 12:17:42 PM UTC-4 vince wrote:

>
> https://stackoverflow.com/questions/14547631/python-locale-error-unsupported-locale-settling
>
> Have you messed with system locale at the os level or edited it in 
> some weewx or mqtt config file ? There have been some skeletal reports 
> about this over the years but I've never really understood the 
> explanations.
>
> On Friday, July 26, 2024 at 3:41:42 AM UTC-7 Mark Jenks wrote:
>
>> Make sure MQTT is running correctly. You can test it via CLI.
>>  This page goes into configuring a cert, you can stop reading at that 
>> point.
>>
>>
>> https://medium.com/gravio-edge-iot-platform/how-to-set-up-a-mosquitto-mqtt-broker-securely-using-client-certificates-82b2aaaef9c8
>>
>>
>> On Thursday, July 25, 2024 at 10:27:54 PM UTC-5 M&M wrote:
>>
>>> Also I tried commenting out all of the MQTT lines in weewx.conf so 
>>> that I could get the service running again but it isn't running at all. 
>>>  
>>> Giving me the same error as I posted above.
>>>
>>> On Thursday, July 25, 2024 at 11:11:15 PM UTC-4 M&M wrote:
>>>
 I'm getting closer.  Mosquito service is running but weewx gives me 
 the follow error in journalctl:

 Jul 25 22:59:55 raspberrypi weewxd[25852]: INFO __main__: 
 Terminating weewx version 5.0.2
 Jul 25 22:59:55 raspberrypi systemd[1]: weewx.service: Succeeded.
 Jul 25 22:59:55 raspberrypi systemd[1]: Stopped WeeWX.
 Jul 25 22:59:55 raspberrypi systemd[1]: weewx.service: Consumed 3h 
 44min 13.462s CPU time.
 Jul 25 23:00:51 raspbe

[weewx-user] Re: Belchertown and MQTT configuration error

[gary....@gmail.com]

I see you haven't done much research.
If you want to understand this and get the Belchertown skin to work, you 
need to do some.
A default mosquitto.conf isn't going to work as you want.
You will likely need SSL certs in order to have websockets work via the 
internet vs local LAN.
You should have writing to mosquitto password protected, but 
allow anonymous reading.

When MQTT/Websockets works, it is great. Getting there requires a passing 
familiarity with the care and feeding of mosquitto.

On Thursday, August 1, 2024 at 11:38:28 PM UTC-4 M&M wrote:

> Where can I find out if I have acl?
>
> My mosquitto.conf file looks a bit different.  I didn't change any of it 
> after it was installed besides the two listener lines.  It looks like this:
>
> pi@raspberrypi:~ $ more /etc/mosquitto/mosquitto.conf
> # Place your local configuration in /etc/mosquitto/conf.d/
> #
> # A full description of the configuration file is at
> # /usr/share/doc/mosquitto/examples/mosquitto.conf.example
>
> pid_file /run/mosquitto/mosquitto.pid
>
> persistence true
> persistence_location /var/lib/mosquitto/
>
> log_dest file /var/log/mosquitto/mosquitto.log
>
> include_dir /etc/mosquitto/conf.d
>
> listener 1883
> listener 9001
> protocol websockets
>
> On Thursday, August 1, 2024 at 9:38:48 AM UTC-4 gary@gmail.com wrote:
>
>> Do you have an acl and does it resemble this?
>> # Allow anonymous access to the sys
>> topic read $SYS/#
>>  
>> # Allow anonymous to read weather
>> topic read weather/#
>> topic read tester/#
>>  
>> # weewx readwrite to the loop
>> user weewx
>> topic weather/#
>> topic tester/#
>>
>> Did you create a password for the weewx user (not the linux user, the 
>> mqtt user)?
>>
>> Does your mosquitto conf file resemble this?
>> persistence false
>> allow_anonymous true
>> password_file /etc/mosquitto/pwfile
>> acl_file /etc/mosquitto/acl
>> # Insecure mqtt to localhost only, and secure mqtt
>> listener 1883
>> listener 8883
>> certfile /etc/mosquitto/certs/cert.pem
>> cafile /etc/mosquitto/certs/chain.pem
>> keyfile /etc/mosquitto/certs/privkey.pem
>> protocol mqtt
>>  
>> # websockets
>> listener 8080
>> certfile /etc/mosquitto/certs/cert.pem
>> cafile /etc/mosquitto/certs/chain.pem
>> keyfile /etc/mosquitto/certs/privkey.pem
>> protocol websockets
>> On Wednesday, July 31, 2024 at 11:47:46 PM UTC-4 M&M wrote:
>>
>>> I checked mosquitto.conf and it has "listener 1883" in it.  I also 
>>> disabled my pihole and checked that my raspberry pi is listening on port 
>>> 1883.  
>>>
>>> On Friday, July 26, 2024 at 11:23:25 PM UTC-4 M&M wrote:
>>>
>>>> I checked journalctl and now I'm seeing this error:
>>>>
>>>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>>>> AmbientAPI get_devices() returned empty dict
>>>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: ambientweatherapi driver 
>>>> encountered an error.
>>>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>>>> ambientweatherapi driver encountered an error.
>>>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: Error caught was: 
>>>> AmbientAPI get_devices() returned empty dict
>>>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>>>> Error caught was: AmbientAPI get_devices() returned empty dict
>>>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: ambientweatherapi driver 
>>>> had an error sending data to weewx.
>>>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>>>> ambientweatherapi driver had an error sending data to weewx.
>>>> Jul 26 23:16:30 raspberrypi weewxd.py[1141]: Error caught was: Previous 
>>>> error occured, skipping packet build.
>>>> Jul 26 23:16:30 raspberrypi weewxd[1141]: ERROR user.ambientweatherapi: 
>>>> Error caught was: Previous error occured, skipping packet build.
>>>>
>>>> On Friday, July 26, 2024 at 11:20:51 PM UTC-4 M&M wrote:
>>>>
>>>>> Making some progress.  I am back to having weewx running and I now 
>>>>> have mosquito running as well.  I was able to test that service by 
>>>>> mosquitto_sub and mosquitto_pub which worked by sending "hello world".  
>>>>> However when I check my local Belchertown page, it now says this at the 
>>>>> top:
>>>>>
>>>>> 

[weewx-user] Re: Access OGC Servers to Download Weather Maps, Warn Maps, Satellite Pictures etc.

[gary....@gmail.com]

Thank you! Very enlightening.

On Saturday, August 17, 2024 at 11:25:44 AM UTC-4 Karen K wrote:

>
>- I added an English description, containing an example for querying 
>the NOAA server: Query Open Geospatial Consortium (OGC) Servers 
>(English) 
>
> 
>.
>- The german description as at: Open Geospatial Consortium (OGC) 
>Server abfragen 
>
> 
>.
>
>
> A lot of weather services (like NOAA, DWD etc.) operate an OGC server to 
> provide weather maps, warnings maps, satellite pictures etc. What data to 
> download is defined by a special set of URL parameters. weewx-DWD 
>  provides a configuration interface 
> to access such servers. You can easily set up the download parameters in 
> weewx.conf as described in the Wiki pages mentioned above.
>
> Besides querying OGC servers the module can also download arbitrary files 
> from every server specified in weewx.conf by the url key.
>
>

-- 
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/360850f2-6770-4d1d-9806-3db1eb08c379n%40googlegroups.com.

[weewx-user] ISS and Anemometer Transmitter weewx.conf Question

[gary....@gmail.com]

I have both transmitters, one for the ISS, ID 1, and one for the 
anemometer, ID 2.
I'm sure it has always been there, but I just noticed the comments in the 
config.

# The id of your ISS station (usually 1). If you use a wind meter 
connected
# to a anemometer transmitter kit, use its id

I've always had this set to 1.

So, though all is working as I would think, I'm curious how if I were to 
use only the anemometer ID the ISS data would be picked up. So I changed 
the ID to 2. Watching the MQTT data, it seemed that only wind info along 
with apptemp and dew point were changing.

How weewx would know the IDs as the data is coming via a WiFi logger.

Perhaps I need to do more testing...




-- 
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/213fbbf2-1841-40d4-9e92-3816d1d67e87n%40googlegroups.com.

[weewx-user] Re: Failure to transfer

[gary....@gmail.com]

Can you manually ftp to the remote site from the weewx machine?


On Tuesday, October 8, 2024 at 4:47:39 AM UTC-4 Francesco Fasano wrote:

> Good morning,
> from Saturday 5 October at 10.39 am I saw the following error in the log
>
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weeutil.ftpupload: Failed 
> uploading /var/www/html/weewx/belchertown/json/month.json to server 
> ftp.meteocivitavecchia.it. Reason: '451-Timeout#012451-Transfer 
> aborted#012451 180.407 seconds (measured here), 9.81 Kbytes per second'
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
> ftpgenerator: (0): caught exception '': 
> 451-Timeout#012451-Transfer aborted#012451 180.407 seconds (measured here), 
> 9.81 Kbytes per second
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   Traceback (most recent call last):
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
> File "/usr/share/weewx/weewx/reportengine.py", line 519, in run
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   n = ftp_data.run()
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
> File "/usr/share/weewx/weeutil/ftpupload.py", line 208, in run
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   ftp_server.storbinary(stor_cmd, fd)
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
> File "/usr/lib/python3.9/ftplib.py", line 502, in storbinary
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   return self.voidresp()
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
> File "/usr/lib/python3.9/ftplib.py", line 257, in voidresp
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   resp = self.getresp()
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
> File "/usr/lib/python3.9/ftplib.py", line 250, in getresp
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   raise error_temp(resp)
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   ftplib.error_temp: 451-Timeout
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   451-Transfer aborted
> Oct  5 10:39:11 raspberrypi weewxd[690]: ERROR weewx.reportengine: 
>   451 180.407 seconds (measured here), 9.81 Kbytes per second
>
> weewx version is 5.1.0
> Belchertown skins 1.3.1
> extended weewx scheme
> python 3.9.1
> s.o debian bullseye
> Raspberry pi
>
> From that day on, the web pages no longer update or if they do, they do so 
> after an indefinite amount of time. I have tried all the solutions but 
> without success.
> my site is www.meteocivitavecchia.it there is an active skin dubug.
> Thank 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/8e978493-e413-4f6b-9022-0d0b14c6f366n%40googlegroups.com.

[weewx-user] Re: Belchertown / HTTPS / Firefox using Mosquitto MQTT issues

[gary....@gmail.com]

It's also possible to accomplish the same thing with apache2 or nginx proxy.
I use apache2 here and do not have to do anything with mosquitto or ssl 
certs.
This does indeed take care of the annoying Firefox issue with secure 
Websockets.


On Thursday, October 3, 2024 at 4:59:58 PM UTC-4 Rich Mulvey wrote:

> The subject of problems with Firefox/Safari browsers not being able to get 
> real-time updates from the Belchertown skin using the Mosquitto MQTT server 
> has come up a bunch of times, so I thought I'd provide a bare-bones 
> description of how to get around it relatively easily.
>
> This is VERY much a nerd-centric set of steps, but my assumption is that 
> if you know what I'm talking about you can figure out the specific details 
> of your particular setup.
>
> The essential issue is that Firebox does the "wrong" thing when attempting 
> to connect to the websocket provided by the Mosquitto websocket process. It 
> tries to use HTTP/2, and when Mosquitto says it can't handle that, instead 
> of falling back to http/1 like other browsers, it just gives up.
>
> The solution is as follows:
>
> 1) Install the haproxy server on your webserver. Usually it will be 
> something like 'apt-get install haproxy', depending on your package manager.
>
> 2) Using whatever is the default haproxy config, often 
> /etc/haproxy/haproxy.cfg, we're going to set up a proxy that transforms 
> http/2 requests into http/1 that mosquitto can handle. We're going to 
> listen on port 9010 ( change to whatever you want ) and redirect the 
> websocket calls to the mosquitto server on port 9001 using http/1, assuming 
> that's what you're using for the setup if you followed the original 
> Belchertown instructions.
>
> So, add lines like the following to the haproxy.cfg file:
>
> # Frontend for handling WebSocket traffic (WSS) on port 9010
> frontend wss_frontend
> bind *:9010 ssl crt /etc/haproxy/certs/mycerts.pem alpn h2,http/1.1
> mode http
> option tcplog
>
> http-request set-header X-Forwarded-Proto https if { ssl_fc }
>
>
> # Use the backend to forward traffic to the non-SSL WebSocket
> use_backend ws_backend 
>
> # Backend for forwarding WebSocket traffic to port 9001 without SSL
> backend ws_backend
> mode http
> option tcplog
> option tcp-check
> option http-server-close  # Ensure that HTTP/1.1 is used
> server weather_backend 127.0.0.1:9001 check
>
> The bind *:9010 ssl crt /etc/haproxy/certs/mycerts.pem alpn 
> h2,http/1.1
>
> line will need to be changed to whatever your cert file is for the https 
> support in your webserver. Restart the haproxy server to read the new 
> config.
>
> 3) Next, update your weewx.conf file so that the mqtt_websockets_port 
> option is changed from the 9001 Belchertown standard to 9010. This will 
> tell it to use the new proxy port. Restart weewx.
>
> 4) Update your Mosquitto config file on your webserver so that any of the 
> SSL config options under the websockets/listener 9001 line are commented 
> out. i.e. There should be no active certfile/cafile/keyfile options. Those 
> options DO still need to be associated with the listener 1883/listener 8883 
> options. Restart the mosquitto server.
>
> 5) Let weewx run for several minutes so that the webpages get updated with 
> the new port 9010/etc option, uploaded to your webserver, etc.
>
> At this point, you should be able to hit your Belchertown skin from any 
> browser and get real-time updates.
>
> https://weather.mulveyfamily.com/ is my personal site, for example.
>
> Hope this helps!
>
> - Rich
>
>

-- 
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/9705b338-600d-4272-b189-2c639690c042n%40googlegroups.com.

Re: [weewx-user] Caution Vantage Vue users, bad CR123 battery vendor

[gary....@gmail.com]

I don't know the country, but in the US, Home Depot and Lowes sell CR123A 
batteries. Lowes is less expensive than HD in my area.
For Amazon/Walmart/Etc, just remember that they are the same as EBay. They 
actively recruit vendors to post their merchandise for sale with little 
care if the items are old, fake, whatever.
If it is something I really need to work, I only buy if it is sold by and 
shipped by Amazon/Walmart.

On Tuesday, October 1, 2024 at 9:04:25 PM UTC-4 Tom Keffer wrote:

> My apologies. For some reason I thought we were talking about the console. 
> No idea where I got that idea from!
>
> On Tue, Oct 1, 2024 at 5:06 PM Gerard Cerchio  wrote:
>
>> The station reported low battery for the 2 weeks that the counterfeit  
>> battery was installed. Normally the low transmitter battery indication goes 
>> off within a day. The kicker was that the station went dead last night and 
>> picked up once the solar cells lit up at dawn. I ran out to home depot and 
>> purchased a replacement and that is working perfectly and the low 
>> transmitter battery indicator went off immediately. I looked further and 
>> the name of the Amazon seller has changed at least once in the comments. 
>> There is no doubt it is just another Amazon scammer.
>>
>> On Tuesday, October 1, 2024 at 4:10:44 PM UTC-7 Tom Keffer wrote:
>>
>>> It's certainly possible that you got a bad battery, but double check 
>>> that your AC charger is working. I say that because it takes about 2 weeks 
>>> for a VP2 to go dead if you unplug it.
>>>
>>> On Tue, Oct 1, 2024 at 3:13 PM Gerard Cerchio  wrote:
>>>
 Here is a warning to people who have stations that use the CR123 
 lithium battery.
 AmazonMy vendor  Battery Suplier is selling bad Panasonic batteries. 
 this is the  URL  
 
  
 The battery totally failed in 2 weeks.

 -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/0a57d2cd-8975-40ae-b5d6-72a5eaf829b1n%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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/aecd5cf5-0da3-4ec5-9558-fd037829f5d9n%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/dd051db9-690a-4518-988c-1b580049dba8n%40googlegroups.com.

[weewx-user] Re: paho-mqtt 1.6.1 Still Required for WeeWX 5.x?

[gary....@gmail.com]

Yeah, I read the stackoverflow thread and it doesn't suggest that the issue 
was fixed. The breaking changes are still there, just a workaround for 
developers. Or so it seems. Perhaps the extension in question is a limited 
circumstance.
I'll give it a try and report back. I'm doing a favor install for a friend 
who requires SDR and a BMP for pressure. For this install, I'll just stay 
with 1.6.1

*Update 2024-05*

Version 2.1 
<https://github.com/eclipse/paho.mqtt.python/releases/tag/v2.1.0> has now 
been released. This now defaults to CallbackAPIVersion.VERSION1 which will, 
in limited circumstances, mean old code still runs. This will not help if 
you pass positional parameters to client (e.g. 
mqtt.Client("thisIsMyClientID")) and specifying a callback version is 
recommended to avoid future confusion (because this has an impact on the 
parameters passed to callbacks
On Tuesday, October 1, 2024 at 10:05:46 PM UTC-4 vince wrote:

> weewx itself does not require paho-mqtt at all, although some extensions 
> of course do require that library.
>
> A quick search says there were breaking changes in paho-mqtt 2.0.0 which 
> came out in January but these were reportedly fixed in the default config 
> in 2.1.0 according to a followup in 
> https://stackoverflow.com/questions/77984857/paho-mqtt-unsupported-callback-api-version-error
>  
> if you want to do the reading.
>
> You can certainly pin your setup to 1.6.1 if you want to do so and if 
> you're running a pip installation.   Looks like 1.6.1 is the current 
> version for raspi os if you use their dpkg.
>
> You'd have to find whatever 'issue' you are thinking of for folks to 
> answer yes/no on whatever question you can't remember.  Or give it a try 
> and let us all know !
>
> On Tuesday, October 1, 2024 at 6:23:47 PM UTC-7 gary@gmail.com wrote:
>
>> There was an issue with paho-mqtt that needed version 1.6.1 installed as 
>> a workaround.
>> I've lost track of the issue and would like to know if this workaround is 
>> still needed.
>> 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/6748fb25-0157-48f8-b7ec-1401869da6b4n%40googlegroups.com.