Re: [weewx-user] Installing weewx without root access

[vince]

If you're willing to do so, the easiest way is to install the v5 beta via 
'pip' within a python virtual environment, as that defaults to running 
without any privileges required.   Getting it to startup on boot might be 
your only issue that I can think of.  I suppose you could write yourself a 
crontab entry that runs as you on boot as one approach you might try.

On Wednesday, August 9, 2023 at 7:26:11 PM UTC-7 Graham Eddy wrote:

> read up on python ‘virtual environment’ (venv) to get your libraries etc 
> in place.
> running it while not logged in - best way depends upon your o/s (eg user 
> mode of systemd)
> *⊣GE⊢*
>
> On 10 Aug 2023, at 2:06 am, Matthew Fields  wrote:
>
> Might seem like an odd request, but I'm trying to find some guidance on 
> installing weewx as a normal user on a shared linux host without root 
> access.
>
> I'll be using websockets to get weather station data (Tempest 
> Weatherflow), so I don't need serial or USB access on the server. My goal 
> is to have weewx run on a shared cloud webserver (hosted by Bluehost). As a 
> shared server, I do not have root access so I have to run it as a normal 
> user.
>
> I have access to the compiler, so I've been trying to install with the 
> python installation instructions. I manage to get everything installed, 
> though I keep running into a lot of fun trying getting weewx to run. I'm 
> sure it has to be configuration settings I need to make, missing python 
> modules, etc.
>
> Rather than beating my head endlessly, has anyone installed weewx in a 
> shared environment without root access (like bluehost)? Anyone know of any 
> installation guidance for such an environment?
>
> -- 
> You received this message because you are subscribed 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/4272f256-db69-4a31-ae68-956f2ba6a6dcn%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/1e732390-299d-4c81-b68a-89ebbcaab9bdn%40googlegroups.com.

Re: [weewx-user] Installing weewx without root access

[Graham Eddy]

read up on python ‘virtual environment’ (venv) to get your libraries etc in 
place.
running it while not logged in - best way depends upon your o/s (eg user mode 
of systemd)
⊣GE⊢

> On 10 Aug 2023, at 2:06 am, Matthew Fields  wrote:
> 
> Might seem like an odd request, but I'm trying to find some guidance on 
> installing weewx as a normal user on a shared linux host without root access.
> 
> I'll be using websockets to get weather station data (Tempest Weatherflow), 
> so I don't need serial or USB access on the server. My goal is to have weewx 
> run on a shared cloud webserver (hosted by Bluehost). As a shared server, I 
> do not have root access so I have to run it as a normal user.
> 
> I have access to the compiler, so I've been trying to install with the python 
> installation instructions. I manage to get everything installed, though I 
> keep running into a lot of fun trying getting weewx to run. I'm sure it has 
> to be configuration settings I need to make, missing python modules, etc.
> 
> Rather than beating my head endlessly, has anyone installed weewx in a shared 
> environment without root access (like bluehost)? Anyone know of any 
> installation guidance for such an environment?
> 
> -- 
> You received this message because you are subscribed 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/4272f256-db69-4a31-ae68-956f2ba6a6dcn%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/AD949D86-372B-4710-9B3D-E1743DAF9015%40geddy.au.

Re: [weewx-user] Standard Report Time / Date format & weather radar

[William Webb]

Ah,  All is well now.  The change to Locale worked.  I noticed that to my 
surprise, I was not running the Standard skin, I was running the seasons 
skin.  I added my radar lines to Seasons and I am good on both issues.

Thanks,

Bill-AB6OR

On Wednesday, August 9, 2023 at 12:11:42 PM UTC-7 William Webb wrote:

> Thank you for the speedy reply.  I will test the locale change shortly.  
>
> Here is the extras section of my skin.conf.
>
>
>
> ###
>
> # The following section is for any extra tags that you want to be 
> available in the templates
> [Extras]
> 
> # This radar image would be available as $Extras.radar_img
> radar_img = 
> http://radar.weather.gov/ridge/standard/PACSOUTHWEST_loop.gif
> # radar_img = 
> https://radblast.wunderground.com/cgi-bin/radar/WUNIDS_map?station=RTX=wui=18=15=N0R=0=1.000=1=1=1
> # This URL will be used as the image hyperlink:
> # radar_url = 
> https://radar.weather.gov/?settings=v1_eyJhZ2VuZGEiOnsiaWQiOm51bGwsImNlbnRlciI6Wy0xMjEuOTE3LDQ1LjY2XSwiem9vbSI6OH0sImJhc2UiOiJzdGFuZGFyZCIsImNvdW50eSI6ZmFsc2UsImN3YSI6ZmFsc2UsInN0YXRlIjpmYWxzZSwibWVudSI6dHJ1ZSwic2hvcnRGdXNlZE9ubHkiOmZhbHNlfQ%3D%3D#/
> radar_url = http://radar.weather.gov/region/pacsouthwest/standard
> # If you have a Google Analytics ID, uncomment and edit the next line, 
> and
> # the analytics code will be included in your generated HTML files:
> #googleAnalyticsId = UA-12345678-1
> 
>
> ###
>
> The commented lines appeared to "overrun"  the  e-mail line length.  In 
> the actual file, they are fine.
> On Wednesday, August 9, 2023 at 11:46:45 AM UTC-7 Tom Keffer wrote:
>
>> 1. Why not just continue to use your old skins? For the most part, skins 
>> have been upwardly compatible for a long time. In any event, to answer your 
>> question, we need a little more information. What does your [Extras] 
>> section look like in skin.conf?
>>
>> 2. The WeeWX applications work like any other Unix application: the 
>> date/time formats are set by the environment variable LANG. You didn't say 
>> what your value is for LANG, but I assume some European locale.  To see 
>> what it is, use the locale command:
>>
>> *locale*
>>
>>
>> You can override individual categories by using LC_xxx environment 
>> variables. For example, to use US style dates and times, you could use
>>
>> *LC_TIME=en_US.utf8 weewxd*
>>
>>
>> The GNU documentation does a pretty good job of describing how this all 
>> works 
>> 
>> .
>>
>> On Wed, Aug 9, 2023 at 11:27 AM William Webb  wrote:
>>
>>> I have version 4 of Weewx running well after having used version 3 for a 
>>> very long time.  I have two questions.
>>>
>>> 1. In the standard report, I would like to display weather radar data.  
>>> I added the URL and GIF information into skin.conf. Radar info was not 
>>> displayed.. Likely other changes are needed but I don't know what they 
>>> are.  I don't remember doing anything special in version 3, however, its 
>>> been a while!
>>>
>>> 2.  The date time format default in the standard skin is the European 
>>> format d/m/y.  I would like to use the US format m/d/y globally, all 
>>> charts, all heading, etc. Is there a way to make this global change?  Did I 
>>> miss something?
>>>
>>> -- 
>>> You received this message because you are subscribed 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/b1a73cf3-4dac-4302-a920-b6c3ba75b61bn%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/4c0368ac-0595-4f32-b7db-0a4aa2decc58n%40googlegroups.com.

Re: [weewx-user] Standard Report Time / Date format & weather radar

[William Webb]

Thank you for the speedy reply.  I will test the locale change shortly.  

Here is the extras section of my skin.conf.


###

# The following section is for any extra tags that you want to be available 
in the templates
[Extras]

# This radar image would be available as $Extras.radar_img
radar_img = 
http://radar.weather.gov/ridge/standard/PACSOUTHWEST_loop.gif
# radar_img = 
https://radblast.wunderground.com/cgi-bin/radar/WUNIDS_map?station=RTX=wui=18=15=N0R=0=1.000=1=1=1
# This URL will be used as the image hyperlink:
# radar_url = 
https://radar.weather.gov/?settings=v1_eyJhZ2VuZGEiOnsiaWQiOm51bGwsImNlbnRlciI6Wy0xMjEuOTE3LDQ1LjY2XSwiem9vbSI6OH0sImJhc2UiOiJzdGFuZGFyZCIsImNvdW50eSI6ZmFsc2UsImN3YSI6ZmFsc2UsInN0YXRlIjpmYWxzZSwibWVudSI6dHJ1ZSwic2hvcnRGdXNlZE9ubHkiOmZhbHNlfQ%3D%3D#/
radar_url = http://radar.weather.gov/region/pacsouthwest/standard
# If you have a Google Analytics ID, uncomment and edit the next line, 
and
# the analytics code will be included in your generated HTML files:
#googleAnalyticsId = UA-12345678-1

###

The commented lines appeared to "overrun"  the  e-mail line length.  In the 
actual file, they are fine.
On Wednesday, August 9, 2023 at 11:46:45 AM UTC-7 Tom Keffer wrote:

> 1. Why not just continue to use your old skins? For the most part, skins 
> have been upwardly compatible for a long time. In any event, to answer your 
> question, we need a little more information. What does your [Extras] 
> section look like in skin.conf?
>
> 2. The WeeWX applications work like any other Unix application: the 
> date/time formats are set by the environment variable LANG. You didn't say 
> what your value is for LANG, but I assume some European locale.  To see 
> what it is, use the locale command:
>
> *locale*
>
>
> You can override individual categories by using LC_xxx environment 
> variables. For example, to use US style dates and times, you could use
>
> *LC_TIME=en_US.utf8 weewxd*
>
>
> The GNU documentation does a pretty good job of describing how this all 
> works 
> 
> .
>
> On Wed, Aug 9, 2023 at 11:27 AM William Webb  wrote:
>
>> I have version 4 of Weewx running well after having used version 3 for a 
>> very long time.  I have two questions.
>>
>> 1. In the standard report, I would like to display weather radar data.  I 
>> added the URL and GIF information into skin.conf. Radar info was not 
>> displayed.. Likely other changes are needed but I don't know what they 
>> are.  I don't remember doing anything special in version 3, however, its 
>> been a while!
>>
>> 2.  The date time format default in the standard skin is the European 
>> format d/m/y.  I would like to use the US format m/d/y globally, all 
>> charts, all heading, etc. Is there a way to make this global change?  Did I 
>> miss something?
>>
>> -- 
>> You received this message because you are subscribed 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/b1a73cf3-4dac-4302-a920-b6c3ba75b61bn%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/14241291-cb44-4193-92ad-c1e45db2a72an%40googlegroups.com.

Re: [weewx-user] Standard Report Time / Date format & weather radar

[Tom Keffer]

1. Why not just continue to use your old skins? For the most part, skins
have been upwardly compatible for a long time. In any event, to answer your
question, we need a little more information. What does your [Extras]
section look like in skin.conf?

2. The WeeWX applications work like any other Unix application: the
date/time formats are set by the environment variable LANG. You didn't say
what your value is for LANG, but I assume some European locale.  To see
what it is, use the locale command:

*locale*


You can override individual categories by using LC_xxx environment
variables. For example, to use US style dates and times, you could use

*LC_TIME=en_US.utf8 weewxd*


The GNU documentation does a pretty good job of describing how this all
works

.

On Wed, Aug 9, 2023 at 11:27 AM William Webb  wrote:

> I have version 4 of Weewx running well after having used version 3 for a
> very long time.  I have two questions.
>
> 1. In the standard report, I would like to display weather radar data.  I
> added the URL and GIF information into skin.conf. Radar info was not
> displayed.. Likely other changes are needed but I don't know what they
> are.  I don't remember doing anything special in version 3, however, its
> been a while!
>
> 2.  The date time format default in the standard skin is the European
> format d/m/y.  I would like to use the US format m/d/y globally, all
> charts, all heading, etc. Is there a way to make this global change?  Did I
> miss something?
>
> --
> You received this message because you are subscribed 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/b1a73cf3-4dac-4302-a920-b6c3ba75b61bn%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/CAPq0zEBcUNsLzuY_iHfqT0ZsvCqyNzkE1sxXVGRNymxixXpicA%40mail.gmail.com.

[weewx-user] Standard Report Time / Date format & weather radar

[William Webb]

I have version 4 of Weewx running well after having used version 3 for a 
very long time.  I have two questions.

1. In the standard report, I would like to display weather radar data.  I 
added the URL and GIF information into skin.conf. Radar info was not 
displayed.. Likely other changes are needed but I don't know what they 
are.  I don't remember doing anything special in version 3, however, its 
been a while!

2.  The date time format default in the standard skin is the European 
format d/m/y.  I would like to use the US format m/d/y globally, all 
charts, all heading, etc. Is there a way to make this global change?  Did I 
miss something?

-- 
You received this message because you are subscribed 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/b1a73cf3-4dac-4302-a920-b6c3ba75b61bn%40googlegroups.com.

[weewx-user] Installing weewx without root access

[Matthew Fields]

Might seem like an odd request, but I'm trying to find some guidance on 
installing weewx as a normal user on a shared linux host without root 
access.

I'll be using websockets to get weather station data (Tempest Weatherflow), 
so I don't need serial or USB access on the server. My goal is to have 
weewx run on a shared cloud webserver (hosted by Bluehost). As a shared 
server, I do not have root access so I have to run it as a normal user.

I have access to the compiler, so I've been trying to install with the 
python installation instructions. I manage to get everything installed, 
though I keep running into a lot of fun trying getting weewx to run. I'm 
sure it has to be configuration settings I need to make, missing python 
modules, etc.

Rather than beating my head endlessly, has anyone installed weewx in a 
shared environment without root access (like bluehost)? Anyone know of any 
installation guidance for such an environment?

-- 
You received this message because you are subscribed 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/4272f256-db69-4a31-ae68-956f2ba6a6dcn%40googlegroups.com.

Re: [weewx-user] Re: Lightning Data Stored in weewx.sdb

[michael.k...@gmx.at]

I have an ecowitt WH57 and exactly the same correction 
term: lightning_distance = lightning_distance if lightning_strike_count > 0 
else None
[image: 2023-08-09 18_35_16-The weather in AT, Salzburg, Hallein, Rif - 
Brave.png]

And just a few mintues ago, there were lightnings detected:

The little yellow dot between 25 and 30km. 


I've queried the database:
select datetime, lightning_distance, lightning_strike_count from archive 
order by datetime desc;

[image: 2023-08-09 18_37_13-Window.png]
Just as excpected.

I don't know how your chart handles this, the above chart is a scatter 
chart with the lightning distance on the y-axis and the size of the dot is 
equivalent to the lightning_strike_count. What does your database show with 
the above query?
Stefan Gliessmann schrieb am Mittwoch, 9. August 2023 um 16:49:45 UTC+2:

> Hello everybody ;)
>
> I have a smilier issue with last lightning distance been charted ...
> I used the above information to generate my chart which looks like this:
>
> [image: Screenshot 2023-08-09 at 16.43.03.png]
>
> This is with 
> [[Corrections]]
> lightning_distance = lightning_distance if lightning_strike_count 
> > 0 else None
>
> I do not have an AcuRite, but an Ecowitt lightning detector ...
>
> Any hint to have the distance been zero when there isn't and lightning 
> would be appreciated.
>
> TIA,
> Stefan
> On Thursday, June 15, 2023 at 6:03:12 AM UTC+2 William Reading wrote:
>
>> I was going to submit a pull request to fix this and realized that the 
>> Atlas driver uses "strike_count" and the rest of them use "strikes_total", 
>> so fixing the defaults would be a breaking change. I went ahead and just 
>> put the delta in my weewx.conf file to work around it.
>>
>> [[sensor_map]]
>> ...
>> atlas_lightning_strike_count = strike_count..AcuriteAtlasPacket
>> ...
>>
>> [[deltas]]
>> lightning_strike_count = atlas_lightning_strike_count
>> On Wednesday, June 14, 2023 at 12:59:13 PM UTC-4 Mark Fraser wrote:
>>
>>> On 13/06/2023 20:17, Kevin Crivelli wrote: 
>>> > mines definitely a little different. This is what I already have. It 
>>> > seems to follow the logic you shared above in your configuration but 
>>> my 
>>> > packets are named differently. where you have "Atlas_strike_count = 
>>> > strike_count.0011.AcuriteAtlasPacket" I have "strikes_total = 
>>> > strikes_total.1255.AcuriteLightningPacket". from looking at my deltas 
>>> > section, does it look as though I have this set up correctly or am I 
>>> off 
>>> > a little bit? 
>>> > 
>>> > [SDR] 
>>> > # This section is for the software-defined radio driver. 
>>> > 
>>> > # The driver to use 
>>> > driver = user.sdr 
>>> > 
>>> > 
>>> > [[sensor_map]] 
>>> > outTemp = temperature.030B.AcuriteAtlasPacket 
>>> > outHumidity = humidity.030B.AcuriteAtlasPacket 
>>> > windSpeed = wind_speed.030B.AcuriteAtlasPacket 
>>> > windDir = wind_dir.030B.AcuriteAtlasPacket 
>>> > UV = uv.030B.AcuriteAtlasPacket 
>>> > rain_total = rain_total.030B.AcuriteAtlasPacket 
>>> > radiation = lux.030B.AcuriteAtlasPacket 
>>> > lux = lux.030B.AcuriteAtlasPacket 
>>> > outTempBatteryStatus = battery.030B.AcuriteAtlasPacket 
>>> > lightning_distance = distance.1255.AcuriteLightningPacket 
>>> > strikes_total = strikes_total.1255.AcuriteLightningPacket 
>>> > inTemp = temperature.3071.AcuriteTowerPacketV2 
>>> > inHumidity = humidity.3071.AcuriteTowerPacketV2 
>>> > pressure = pressure.171.FOWH32BPacket 
>>> > 
>>> > 
>>> > [[deltas]] 
>>> > rain = rain_total 
>>> > lightning_strike_count = strikes_total 
>>>
>>> I think there is a bug in the sdr.py from 
>>> https://github.com/matthewwall/weewx-sdr/blob/master/bin/user/sdr.py 
>>> where the deltas are listed as: 
>>>
>>> DEFAULT_DELTAS = { 
>>> 'rain': 'rain_total', 
>>> 'strikes': 'strikes_total'} 
>>>
>>> Which I couldn't get to work, so I changed mine to: 
>>> DEFAULT_DELTAS = { 
>>> 'rain': 'rain_total', 
>>> 'lightning_strike_count': 'strikes_total'} 
>>> And it works without having to add a deltas section to weewx.conf. 
>>>
>>>

-- 
You received this message because you are subscribed 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/1c0205a8-cb0f-4a34-8c2b-dd0d288da2fen%40googlegroups.com.

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

[michael.k...@gmx.at]

Certainly an interesting spin-off discussion: developing a platform to 
ensure our data will remain our data. A first approach could be designing a 
console. Many stations out there, modular or not, use wireless sensors that 
only transmit their readings unencrypted and simplex. It should be possible 
to design a console that receives the popular sensors out there and 
provides data on the (W)LAN they are connected to. An internal storage with 
a REST interface for data access and a GUI for maintaining settings and 
there you go. The idea isn't new, doesn't sound too complicated but would 
be a long way to go, if the goal is to provide something that deserves the 
label "product". Anyway, I'd be on board. :D 
gary@gmail.com schrieb am Mittwoch, 9. August 2023 um 15:36:52 UTC+2:

> 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 

Re: [weewx-user] WeeWX in an RV?

[Tom Keffer]

One way of doing this...

Station altitude, latitude, and longitude are always obtained from an
instance of StationInfo
,
held in the engine. From this, various views are constructed, including
what's used as a tag, such as $station.altitude.

So, with every new archive record you could replace that instance with a
fresh instance, created in a WeeWX service, using updated values.
The instance is available as engine.stn_info in the service.

How does your service get its information? One way would be to add new
observation types altitude, latitude, and longitude to the archive record.
Then your new service can get the values from there.

If you also want values in the database, add altitude,  longitude, and
latitude to the schema and they will automatically be populated if the
archive record holds matching types.

That's off the top of my head. It's a nice approach because it does not
involve modifying any base weewx code. But, I'm sure I've missed
something...

-tk


On Wed, Aug 9, 2023 at 8:00 AM Stefan Gliessmann <
stefan.gliessm...@gmail.com> wrote:

> After running into major issues with my LTE router in my RV, weewx and
> Belchertown w/ MQTT are up and running :)
> Check it out here: https://t.ly/4icFe
>
> My RV router is actually a serious professional LTE router which can
> provide GPS data, too (once I have a GPs receiver installed).
> Now, I still have to figure out how to push the GPS data into weewx db and
> have weewx use it for the weather forecasts using aeris within the
> Belchertown skin.
> Since I have MQTT already working and my router can send the GPS data as
> MQTT packages, maybe that is a way to do so.
> In weewx.conf the long, latitude and altitude are specified. Is there a
> way to not update these in the weewx.conf, but have them read from the db
> and considered accordingly?
>
> Thanks for brainstorming this with me ;)
>
> TIA,
> Stefan
>
> On Monday, July 31, 2023 at 4:25:05 AM UTC+2 Cameron D wrote:
>
>> This would be my suggestion as well.  Certainly use a dedicated DB for
>> the task, then populate it according to the effort you want to put into it.
>> Options would be:
>>
>>- custom GPS unit along the lines Vince suggested
>>- use a normal in-car GPS unit that records your tracks and
>>download/export data each day.  I combine my car and walking gps tracks 
>> for
>>geotagging photos.
>>- manually enter data once a day
>>
>> When I do long trips, I often take a simple handheld temp/RH logger that
>> I download occasionally - every few days.
>> I also have a second table with one row per day, where I manually enter
>> comments about where the device was located and anything unusual that might
>> have influenced the results.  Probably less necessary in an RV with fixed
>> locations, but my logger might end up left inside the tent, outside the
>> tent, or left inside the car on different days.  This table could also
>> double as a more general diary.
>>
>> On Sunday, 30 July 2023 at 6:39:28 am UTC+10 vince wrote:
>>
>>> On Saturday, July 29, 2023 at 1:11:25 PM UTC-7 Stefan Gliessmann wrote:
>>>
>>> That would work. But I would miss out on the location and elevation data
>>> … I would like to include location in a database …
>>>
>>>
>>> Sure. Get a GPS module for your pi and write a little script to seed a
>>> custom field in the db.   Shouldn't be a big deal.  Just write to a
>>> secondary sqlite db.
>>>
>>>
>>>
>> --
> You received this message because you are subscribed 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/c0a89ba0-e981-4e58-8a3b-9412bbd0b1c4n%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/CAPq0zECNoy6YbZTHN7DvwhN0n0SEJF5AR4GYEWEjf0hdkomcAA%40mail.gmail.com.

Re: [weewx-user] WeeWX in an RV?

[Stefan Gliessmann]

After running into major issues with my LTE router in my RV, weewx and 
Belchertown w/ MQTT are up and running :)
Check it out here: https://t.ly/4icFe

My RV router is actually a serious professional LTE router which can 
provide GPS data, too (once I have a GPs receiver installed).
Now, I still have to figure out how to push the GPS data into weewx db and 
have weewx use it for the weather forecasts using aeris within the 
Belchertown skin.
Since I have MQTT already working and my router can send the GPS data as 
MQTT packages, maybe that is a way to do so.
In weewx.conf the long, latitude and altitude are specified. Is there a way 
to not update these in the weewx.conf, but have them read from the db and 
considered accordingly?

Thanks for brainstorming this with me ;)

TIA,
Stefan

On Monday, July 31, 2023 at 4:25:05 AM UTC+2 Cameron D wrote:

> This would be my suggestion as well.  Certainly use a dedicated DB for the 
> task, then populate it according to the effort you want to put into it.
> Options would be:
>
>- custom GPS unit along the lines Vince suggested
>- use a normal in-car GPS unit that records your tracks and 
>download/export data each day.  I combine my car and walking gps tracks 
> for 
>geotagging photos.
>- manually enter data once a day
>
> When I do long trips, I often take a simple handheld temp/RH logger that I 
> download occasionally - every few days.
> I also have a second table with one row per day, where I manually enter 
> comments about where the device was located and anything unusual that might 
> have influenced the results.  Probably less necessary in an RV with fixed 
> locations, but my logger might end up left inside the tent, outside the 
> tent, or left inside the car on different days.  This table could also 
> double as a more general diary.
>
> On Sunday, 30 July 2023 at 6:39:28 am UTC+10 vince wrote:
>
>> On Saturday, July 29, 2023 at 1:11:25 PM UTC-7 Stefan Gliessmann wrote:
>>
>> That would work. But I would miss out on the location and elevation data 
>> … I would like to include location in a database …
>>
>>
>> Sure. Get a GPS module for your pi and write a little script to seed a 
>> custom field in the db.   Shouldn't be a big deal.  Just write to a 
>> secondary sqlite db.
>>
>>  
>>
>

-- 
You received this message because you are subscribed 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/c0a89ba0-e981-4e58-8a3b-9412bbd0b1c4n%40googlegroups.com.

Re: [weewx-user] Re: Lightning Data Stored in weewx.sdb

[Stefan Gliessmann]

Hello everybody ;)

I have a smilier issue with last lightning distance been charted ...
I used the above information to generate my chart which looks like this:

[image: Screenshot 2023-08-09 at 16.43.03.png]

This is with 
[[Corrections]]
lightning_distance = lightning_distance if lightning_strike_count > 
0 else None

I do not have an AcuRite, but an Ecowitt lightning detector ...

Any hint to have the distance been zero when there isn't and lightning 
would be appreciated.

TIA,
Stefan
On Thursday, June 15, 2023 at 6:03:12 AM UTC+2 William Reading wrote:

> I was going to submit a pull request to fix this and realized that the 
> Atlas driver uses "strike_count" and the rest of them use "strikes_total", 
> so fixing the defaults would be a breaking change. I went ahead and just 
> put the delta in my weewx.conf file to work around it.
>
> [[sensor_map]]
> ...
> atlas_lightning_strike_count = strike_count..AcuriteAtlasPacket
> ...
>
> [[deltas]]
> lightning_strike_count = atlas_lightning_strike_count
> On Wednesday, June 14, 2023 at 12:59:13 PM UTC-4 Mark Fraser wrote:
>
>> On 13/06/2023 20:17, Kevin Crivelli wrote: 
>> > mines definitely a little different. This is what I already have. It 
>> > seems to follow the logic you shared above in your configuration but my 
>> > packets are named differently. where you have "Atlas_strike_count = 
>> > strike_count.0011.AcuriteAtlasPacket" I have "strikes_total = 
>> > strikes_total.1255.AcuriteLightningPacket". from looking at my deltas 
>> > section, does it look as though I have this set up correctly or am I 
>> off 
>> > a little bit? 
>> > 
>> > [SDR] 
>> > # This section is for the software-defined radio driver. 
>> > 
>> > # The driver to use 
>> > driver = user.sdr 
>> > 
>> > 
>> > [[sensor_map]] 
>> > outTemp = temperature.030B.AcuriteAtlasPacket 
>> > outHumidity = humidity.030B.AcuriteAtlasPacket 
>> > windSpeed = wind_speed.030B.AcuriteAtlasPacket 
>> > windDir = wind_dir.030B.AcuriteAtlasPacket 
>> > UV = uv.030B.AcuriteAtlasPacket 
>> > rain_total = rain_total.030B.AcuriteAtlasPacket 
>> > radiation = lux.030B.AcuriteAtlasPacket 
>> > lux = lux.030B.AcuriteAtlasPacket 
>> > outTempBatteryStatus = battery.030B.AcuriteAtlasPacket 
>> > lightning_distance = distance.1255.AcuriteLightningPacket 
>> > strikes_total = strikes_total.1255.AcuriteLightningPacket 
>> > inTemp = temperature.3071.AcuriteTowerPacketV2 
>> > inHumidity = humidity.3071.AcuriteTowerPacketV2 
>> > pressure = pressure.171.FOWH32BPacket 
>> > 
>> > 
>> > [[deltas]] 
>> > rain = rain_total 
>> > lightning_strike_count = strikes_total 
>>
>> I think there is a bug in the sdr.py from 
>> https://github.com/matthewwall/weewx-sdr/blob/master/bin/user/sdr.py 
>> where the deltas are listed as: 
>>
>> DEFAULT_DELTAS = { 
>> 'rain': 'rain_total', 
>> 'strikes': 'strikes_total'} 
>>
>> Which I couldn't get to work, so I changed mine to: 
>> DEFAULT_DELTAS = { 
>> 'rain': 'rain_total', 
>> 'lightning_strike_count': 'strikes_total'} 
>> And it works without having to add a deltas section to weewx.conf. 
>>
>>

-- 
You received this message because you are subscribed 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/c31d91eb-24d9-472e-8476-60af931c04e8n%40googlegroups.com.

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.