Re: [weewx-user] want to use lux value to calculate value for 'radiation'

[Eric K]

You have to restart weewx before changes made to the weewx.conf file will 
take effect.
If you've restarted weewx, you should start to see additions to the graphs, 
every 5 minutes.

On Friday, September 29, 2023 at 2:49:54 PM UTC-5 Kevin Crivelli wrote:

> Should it reflect in the graphs immediately? I was able to login to ssh 
> from work and make the change but I'm not seeing any change in the graphs
>
> On Fri, Sep 29, 2023, 3:09 PM Kevin Crivelli  wrote:
>
>> Thank you! I'm gonna try this. Let ya know how it works out 
>>
>> On Fri, Sep 29, 2023, 11:17 AM Eric Koester  wrote:
>>
>>> Kevin Crivelli,Here's what my [[Corrections]] section looks like.
>>> Mine uses '> 0' rather than 'not None'
>>>
>>> [StdCalibrate]
>>>>
>>>> [[Corrections]]
>>>> # For each type, an arbitrary calibration expression can be 
>>>> given.
>>>> # It should be in the units defined in the StdConvert section.
>>>> # Example:  foo = foo + 0.2
>>>> radiation = luminosity * 0.00789 if luminosity > 0 else None
>>>> lightning_distance = lightning_distance / 1.609 if 
>>>> lightning_strike_count > 0 else None#convert distance to miles
>>>
>>>
>>> On Wed, Sep 27, 2023 at 6:49 PM Kevin Crivelli  
>>> wrote:
>>>
>>>> [StdCalibrate]
>>>> 
>>>> [[Corrections]]
>>>> windDir = windDir if windSpeed > 0 else None
>>>> lightning_distance = lightning_distance if 
>>>> lightning_strike_count > 0 else None
>>>> # For each type, an arbitrary calibration expression can be 
>>>> given.
>>>> # It should be in the units defined in the StdConvert section.
>>>> # Example:
>>>> foo = foo + 0.2
>>>> radiation = luminosity/126.7 if luminosity is not None else 
>>>> None
>>>>
>>>>
>>>> On Wednesday, September 27, 2023 at 7:11:05 PM UTC-4 Eric K wrote:
>>>>
>>>>> Share the [StdCalibrate]  [[Corrections]] section of your weewx.conf 
>>>>> file with us.
>>>>>
>>>>> On Wednesday, September 27, 2023 at 5:53:10 PM UTC-5 Kevin Crivelli 
>>>>> wrote:
>>>>>
>>>>> I have the same problem but this didn't work for me. any ideas?
>>>>>
>>>>> On Tuesday, May 18, 2021 at 6:04:08 PM UTC-4 Greg Troxel wrote:
>>>>>
>>>>>
>>>>> Eric K <> writes: 
>>>>>
>>>>> > The Acurite Atlas weather sensor provides a UV and a lux value, but 
>>>>> not a 
>>>>> > radiation value. 
>>>>> > I want to use this formula to calculate solar radiation from the lux 
>>>>> sensor 
>>>>> > in the Acurite Atlas: radiation = lux * 0.0079 
>>>>>
>>>>> See also 
>>>>>
>>>>> https://github.com/weewx/weewx/wiki/Watts-and-lux 
>>>>>
>>>>> -- 
>>>> 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/oWp-9LivDJo/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/fc6b65b0-69be-4ec7-9763-675f62302f48n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/fc6b65b0-69be-4ec7-9763-675f62302f48n%40googlegroups.com?utm_medium=email_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/CADh_orjKiziRwWUTK%3DgGN2Kao%3DB3n4FGRvvmTDGn355iLpDRqQ%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/CADh_orjKiziRwWUTK%3DgGN2Kao%3DB3n4FGRvvmTDGn355iLpDRqQ%40mail.gmail.com?utm_medium=email_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/f78c3866-2868-41fa-8a2b-211f71f3d5b9n%40googlegroups.com.

Re: [weewx-user] want to use lux value to calculate value for 'radiation'

[Eric K]

Share the [StdCalibrate]  [[Corrections]] section of your weewx.conf file 
with us.

On Wednesday, September 27, 2023 at 5:53:10 PM UTC-5 Kevin Crivelli wrote:

I have the same problem but this didn't work for me. any ideas?

On Tuesday, May 18, 2021 at 6:04:08 PM UTC-4 Greg Troxel wrote:


Eric K <> writes: 

> The Acurite Atlas weather sensor provides a UV and a lux value, but not a 
> radiation value. 
> I want to use this formula to calculate solar radiation from the lux 
sensor 
> in the Acurite Atlas: radiation = lux * 0.0079 

See also 

https://github.com/weewx/weewx/wiki/Watts-and-lux 

-- 
You received this message because you are subscribed 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/e86ed98a-ef5d-457c-a2e8-d3e95784faa2n%40googlegroups.com.

[weewx-user] Re: affordable lightning detector

[Eric K]

This post shows the AS3935 board setup I put together in 2021.
https://groups.google.com/g/weewx-user/c/TaLWUitdDmE/m/Zt7DPUMTAwAJ

I bought this board, which is cheaper than the Sparkfun board, but not as 
cheap as the Acurite 6045.
https://www.amazon.com/Lightning-Distances-Detection-Interfacing-Electronic/dp/B07SST5GDB

On Thursday, June 22, 2023 at 12:20:14 PM UTC-5 Chris Alemany wrote:

> Hi all,
>
> Any recommendations on lightning detectors that work with weewx and maybe 
> also Raspberry Pi?
>
> cheers
> 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/a838b0e3-c8fb-4ccf-9548-59819fd66290n%40googlegroups.com.

[weewx-user] Re: need help fixing problem in database: can't complete a --rebuild-daily

[Eric K]

--fix-strings did it!
The database is fixed and --rebuild-daily works without errors!

pi@rpi3b:/home/weewx $ sudo bin/wee_database weewx.conf --fix-strings
Using configuration file weewx.conf
Using database binding 'wx_binding', which is bound to database 
'archive_sqlite'
Preparing Null String Fix, this may take a while...
 Checking record: 208266; Timestamp: 2023-06-23 14:00:00 CDT (1687546800)
The following null strings were found:
Timestamp = 1685826300; record['windGustDir'] = ''; ... changed to None
Timestamp = 1685832600; record['outTempBatteryStatus'] = ''; ... changed to 
None
Timestamp = 1685832600; record['windGustDir'] = ''; ... changed to None
Timestamp = 1685832900; record['outTempBatteryStatus'] = ''; ... changed to 
None
4 of 4 null strings found were fixed.
Applied Null String Fix in 43.59 seconds.

On Friday, June 23, 2023 at 12:57:14 PM UTC-5 Eric K wrote:

> I was just looking through the documentation on wee_database.
> http://weewx.com/docs/latest/utilities.htm#wee_database_utility
>
> Can any of the wee_database options be used to search the database for 
> text strings and convert them into floating point numbers for me?
>
> Options: -h, --help show this help message and exit --create Create the 
> WeeWX database and initialize it with the schema. --reconfigure Create a 
> new database using configuration information found in the configuration 
> file. The new database will have the same name as the old database, with a 
> '_new' on the end. --transfer Transfer the WeeWX archive from source 
> database to destination database. --add-column=NAME Add new column NAME to 
> database. --type=TYPE New database column type (INTEGER|REAL) (option 
> --add- column only). Default is 'REAL'. --rename-column=NAME Rename the 
> column with name NAME. --to-name=NEW_NAME New name of the column (option 
> --rename-column only). --drop-columns=NAME1,NAME2,... Drop one or more 
> columns. Names must be separated by commas, with NO SPACES. --check Check 
> the calculations in the daily summary tables. --update Update the daily 
> summary tables if required and recalculate the daily summary maximum 
> windSpeed values. --calc-missing Calculate and store any missing derived 
> observations. --check-strings Check the archive table for null strings that 
> may have been introduced by a SQL editing program. --fix-strings Fix any 
> null strings in a SQLite database. --drop-daily Drop the daily summary 
> tables from a database. --rebuild-daily Rebuild the daily summaries from 
> data in the archive table. --reweight Recalculate the weighted sums in the 
> daily summaries. --config=CONFIG_FILE Use configuration file CONFIG_FILE. 
> --date=-mm-dd This date only (options --calc-missing and --rebuild- 
> daily only). --from=-mm-dd[THH:MM] Start with this date or date-time 
> (options --calc- missing and --rebuild-daily only). --to=-mm-dd[THH:MM] 
> End with this date or date-time (options --calc- missing and 
> --rebuild-daily only). --binding=BINDING_NAME The data binding to use. 
> Default is 'wx_binding'. --dest-binding=BINDING_NAME The destination data 
> binding (option --transfer only). --dry-run Print what would happen but do 
> not do it. Default is False.
>
> On Friday, June 23, 2023 at 11:50:41 AM UTC-5 Eric K wrote:
>
>> I've been running weewx 4.5.1 in a RaspberryPi for the last 2 years.
>> In the past, I have successfully used DB Browser for SQLite to fix 
>> erronous readings created by my system sensor behavior.
>> In the last 30 days, I edited some erronous wind speed values and now the 
>> "sudo bin/wee_database weewx.conf --rebuild-daily" command can't complete 
>> without errors.
>> The error messages suggest that some of my values are text strings rather 
>> than floating point numbers.
>>
>> When I browse the weewx.sdb database with DB Broswer for SQLite, I can't 
>> see any difference between data fields with numbers and strings.
>>
>> I read the page on cleaning up the database 
>> https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data
>> but there are no commands listed to help detect and convert text strings 
>> into floating point numbers.
>>
>> How can I detect the difference between text strings and floating point 
>> numbers in the database?
>>
>> Here is the feedback I get:
>>
>> pi@rpi3b:/home/weewx $ sudo bin/wee_database weewx.conf --rebuild-daily
>> Using configuration file weewx.conf
>> Using database binding 'wx_binding', which is bound to database 
>> 'archive_sqlite'
>> All daily summaries will be rebuilt.
>> Proceed (y/n)? y
>> Rebuilding daily summaries in database 'weewx.sdb' ...
>> Traceback (most recent call last):023-06-

[weewx-user] Re: need help fixing problem in database: can't complete a --rebuild-daily

[Eric K]

I was just looking through the documentation on wee_database.
http://weewx.com/docs/latest/utilities.htm#wee_database_utility

Can any of the wee_database options be used to search the database for text 
strings and convert them into floating point numbers for me?

Options: -h, --help show this help message and exit --create Create the 
WeeWX database and initialize it with the schema. --reconfigure Create a 
new database using configuration information found in the configuration 
file. The new database will have the same name as the old database, with a 
'_new' on the end. --transfer Transfer the WeeWX archive from source 
database to destination database. --add-column=NAME Add new column NAME to 
database. --type=TYPE New database column type (INTEGER|REAL) (option 
--add- column only). Default is 'REAL'. --rename-column=NAME Rename the 
column with name NAME. --to-name=NEW_NAME New name of the column (option 
--rename-column only). --drop-columns=NAME1,NAME2,... Drop one or more 
columns. Names must be separated by commas, with NO SPACES. --check Check 
the calculations in the daily summary tables. --update Update the daily 
summary tables if required and recalculate the daily summary maximum 
windSpeed values. --calc-missing Calculate and store any missing derived 
observations. --check-strings Check the archive table for null strings that 
may have been introduced by a SQL editing program. --fix-strings Fix any 
null strings in a SQLite database. --drop-daily Drop the daily summary 
tables from a database. --rebuild-daily Rebuild the daily summaries from 
data in the archive table. --reweight Recalculate the weighted sums in the 
daily summaries. --config=CONFIG_FILE Use configuration file CONFIG_FILE. 
--date=-mm-dd This date only (options --calc-missing and --rebuild- 
daily only). --from=-mm-dd[THH:MM] Start with this date or date-time 
(options --calc- missing and --rebuild-daily only). --to=-mm-dd[THH:MM] 
End with this date or date-time (options --calc- missing and 
--rebuild-daily only). --binding=BINDING_NAME The data binding to use. 
Default is 'wx_binding'. --dest-binding=BINDING_NAME The destination data 
binding (option --transfer only). --dry-run Print what would happen but do 
not do it. Default is False.

On Friday, June 23, 2023 at 11:50:41 AM UTC-5 Eric K wrote:

> I've been running weewx 4.5.1 in a RaspberryPi for the last 2 years.
> In the past, I have successfully used DB Browser for SQLite to fix 
> erronous readings created by my system sensor behavior.
> In the last 30 days, I edited some erronous wind speed values and now the 
> "sudo bin/wee_database weewx.conf --rebuild-daily" command can't complete 
> without errors.
> The error messages suggest that some of my values are text strings rather 
> than floating point numbers.
>
> When I browse the weewx.sdb database with DB Broswer for SQLite, I can't 
> see any difference between data fields with numbers and strings.
>
> I read the page on cleaning up the database 
> https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data
> but there are no commands listed to help detect and convert text strings 
> into floating point numbers.
>
> How can I detect the difference between text strings and floating point 
> numbers in the database?
>
> Here is the feedback I get:
>
> pi@rpi3b:/home/weewx $ sudo bin/wee_database weewx.conf --rebuild-daily
> Using configuration file weewx.conf
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> All daily summaries will be rebuilt.
> Proceed (y/n)? y
> Rebuilding daily summaries in database 'weewx.sdb' ...
> Traceback (most recent call last):023-06-02 07:45:00 CDT (1685709900)
>   File "/home/weewx/bin/wee_database", line 1138, in 
> main()
>   File "/home/weewx/bin/wee_database", line 236, in main
> rebuildDaily(config_dict, db_binding, options)
>   File "/home/weewx/bin/wee_database", line 345, in rebuildDaily
> nrecs, ndays = dbmanager.backfill_day_summary(start_d=from_d,
>   File "/home/weewx/bin/weewx/manager.py", line 1152, in 
> backfill_day_summary
> day_accum.addRecord(rec, weight=weight)
>   File "/home/weewx/bin/weewx/accum.py", line 436, in addRecord
> func(self, record, obs_type, add_hilo, weight)
>   File "/home/weewx/bin/weewx/accum.py", line 495, in add_value
> self[obs_type].addHiLo(val, record['dateTime'])
>   File "/home/weewx/bin/weewx/accum.py", line 168, in addHiLo
> val = to_float(val)
>   File "/home/weewx/bin/weeutil/weeutil.py", line 1276, in to_float
> return float(x) if x is not None else None
> ValueError: could not convert string to float: ''
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user&q

[weewx-user] need help fixing problem in database: can't complete a --rebuild-daily

[Eric K]

I've been running weewx 4.5.1 in a RaspberryPi for the last 2 years.
In the past, I have successfully used DB Browser for SQLite to fix erronous 
readings created by my system sensor behavior.
In the last 30 days, I edited some erronous wind speed values and now the 
"sudo bin/wee_database weewx.conf --rebuild-daily" command can't complete 
without errors.
The error messages suggest that some of my values are text strings rather 
than floating point numbers.

When I browse the weewx.sdb database with DB Broswer for SQLite, I can't 
see any difference between data fields with numbers and strings.

I read the page on cleaning up the database 
https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data
but there are no commands listed to help detect and convert text strings 
into floating point numbers.

How can I detect the difference between text strings and floating point 
numbers in the database?

Here is the feedback I get:

pi@rpi3b:/home/weewx $ sudo bin/wee_database weewx.conf --rebuild-daily
Using configuration file weewx.conf
Using database binding 'wx_binding', which is bound to database 
'archive_sqlite'
All daily summaries will be rebuilt.
Proceed (y/n)? y
Rebuilding daily summaries in database 'weewx.sdb' ...
Traceback (most recent call last):023-06-02 07:45:00 CDT (1685709900)
  File "/home/weewx/bin/wee_database", line 1138, in 
main()
  File "/home/weewx/bin/wee_database", line 236, in main
rebuildDaily(config_dict, db_binding, options)
  File "/home/weewx/bin/wee_database", line 345, in rebuildDaily
nrecs, ndays = dbmanager.backfill_day_summary(start_d=from_d,
  File "/home/weewx/bin/weewx/manager.py", line 1152, in 
backfill_day_summary
day_accum.addRecord(rec, weight=weight)
  File "/home/weewx/bin/weewx/accum.py", line 436, in addRecord
func(self, record, obs_type, add_hilo, weight)
  File "/home/weewx/bin/weewx/accum.py", line 495, in add_value
self[obs_type].addHiLo(val, record['dateTime'])
  File "/home/weewx/bin/weewx/accum.py", line 168, in addHiLo
val = to_float(val)
  File "/home/weewx/bin/weeutil/weeutil.py", line 1276, in to_float
return float(x) if x is not None else None
ValueError: could not convert string to float: ''

-- 
You received this message because you are subscribed 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/06f547a7-4e29-488b-b6ff-8ea26e7d1f82n%40googlegroups.com.

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

[Eric K]

Maybe the better question is, what version of weewx-sdr do you have?
I installed mine in May 2021.
On Wednesday, June 14, 2023 at 1:12:37 PM UTC-5 Eric K wrote:

> Oh, interesting.  I'm running weewx 4.5.1.  
> What version are you running?
>
> On Wednesday, June 14, 2023 at 11:59:13 AM UTC-5 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/0b2cc889-2d5b-49bc-abd8-4ef2ffe72b4fn%40googlegroups.com.

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

[Eric K]

Oh, interesting.  I'm running weewx 4.5.1.  
What version are you running?

On Wednesday, June 14, 2023 at 11:59:13 AM UTC-5 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/a570e03a-78bc-4b8a-be4a-6b7e5a504d88n%40googlegroups.com.

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

[Eric K]

Ahhh an external Acurite lightning detector.  That explains why your 
lightning data variable does not end in ".AcuriteAtlasPacket"

Of note, unlike the 2nd post in this thread, my [Accumulator] setion of 
weewx.conf file is blank, because the Atlas lightning number is already an 
accuulated value.

#
[Accumulator]

#

On Tuesday, June 13, 2023 at 2:34:24 PM UTC-5 Kevin Crivelli wrote:

> oh I forgot to mention that I use a separate acurite lightning detector 
> than the atlas detector. I do not have the atlas detector even installed 
> because there are too many electronics near the main station that I have 
> false positive lightning strikes when using the atlas detector so I use the 
> acurite lightning detector in a different location for those readings. 
> can't imagine that would have anything to do with my situation however I 
> thought I'd tell you so you wouldn't be confused as to why mine is 
> different than yours even though we both use Atlas's
>
> On Tue, Jun 13, 2023 at 3:17 PM 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
>>
>>
>>
>> On Tue, Jun 13, 2023 at 3:11 PM Eric K  wrote:
>>
>>> I forgot about the [SDR] section of the weewx.conf file.
>>> weewx needs to convert the lightning strike count reported by the 
>>> Acurite Atlas to a lightning strike delta number.
>>> This is because the Atlas counts up lightning strikes and keeps 
>>> incrementing the accumulated strike number (such as 5).
>>> When the next strike ocurrs the Atlas will increment the number to 6, 
>>> and so on.
>>> You need weewx to watch for a change in that Atlas lightning strike 
>>> number and report that difference (delta) between the last count and the 
>>> current count.
>>>
>>> from my weewx.conf file:
>>>
>>> ##
>>>
>>> [SDR]
>>> # This section is for the software-defined radio driver.
>>> # collect data from Acurite-Atlas sensor 0011
>>> 
>>> # The driver to use
>>> driver = user.sdr
>>> cmd = rtl_433 -R 40 -M utc -F json
>>> 
>>> [[sensor_map]]
>>> outTemp = temperature.0011.AcuriteAtlasPacket
>>> outHumidity = humidity.0011.AcuriteAtlasPacket
>>> windSpeed = wind_speed.0011.AcuriteAtlasPacket
>>> windDir = wind_dir.0011.AcuriteAtlasPacket
>>> UV = uv.0011.AcuriteAtlasPacket
>>> luminosity = lux.0011.AcuriteAtlasPacket
>>> Atlas_rain_total = rain_total.0011.AcuriteAtlasPacket
>>> Atlas_strike_count = strike_count.0011.AcuriteAtlasPacket
>>> lightning_distance = strike_distance.0011.AcuriteAtlasPacket
>>> windBatteryStatus = battery.0011.AcuriteAtlasPacket
>>> batteryStatus1 = battery.0011.AcuriteAtlasPacket
>>> 
>

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

[Eric K]

I forgot about the [SDR] section of the weewx.conf file.
weewx needs to convert the lightning strike count reported by the Acurite 
Atlas to a lightning strike delta number.
This is because the Atlas counts up lightning strikes and keeps 
incrementing the accumulated strike number (such as 5).
When the next strike ocurrs the Atlas will increment the number to 6, and 
so on.
You need weewx to watch for a change in that Atlas lightning strike number 
and report that difference (delta) between the last count and the current 
count.

from my weewx.conf file:
##

[SDR]
# This section is for the software-defined radio driver.
# collect data from Acurite-Atlas sensor 0011

# The driver to use
driver = user.sdr
cmd = rtl_433 -R 40 -M utc -F json

[[sensor_map]]
outTemp = temperature.0011.AcuriteAtlasPacket
outHumidity = humidity.0011.AcuriteAtlasPacket
windSpeed = wind_speed.0011.AcuriteAtlasPacket
windDir = wind_dir.0011.AcuriteAtlasPacket
UV = uv.0011.AcuriteAtlasPacket
luminosity = lux.0011.AcuriteAtlasPacket
Atlas_rain_total = rain_total.0011.AcuriteAtlasPacket
Atlas_strike_count = strike_count.0011.AcuriteAtlasPacket
lightning_distance = strike_distance.0011.AcuriteAtlasPacket
windBatteryStatus = battery.0011.AcuriteAtlasPacket
batteryStatus1 = battery.0011.AcuriteAtlasPacket

[[deltas]]
rain = Atlas_rain_total
lightning_strike_count = Atlas_strike_count

##

On Tuesday, June 13, 2023 at 1:58:17 PM UTC-5 Kevin Crivelli wrote:

> I added the line 
> lightning_distance = lightning_distance / 1.609 if lightning_strike_count 
> > 0 else None#convert distance to miles 
>
> to the [StdCalibrate] [[Corrections]] section and I added your chart to my 
> graphs.conf 
>
> I am still getting the persistant distance of 5 miles as per the last 
> lightning distance that was recorded weeks ago. not sure where to go from 
> here but thank you for providing all of that for me. 
>
> [image: lightning5.JPG]
>
>
> On Sunday, June 11, 2023 at 5:09:28 PM UTC-4 Eric K wrote:
>
>> Hi Kevin,
>>
>> In the graphs.conf file (Belchertown skin) I have this:
>>
>> [[chart6]]
>> title = Lightning
>> [[[lightning_strike_count]]]
>> yAxis = 0
>> yAxis_min = 0
>> yAxis_tickInterval = 1
>> yAxis_label = "Number of Strikes"
>> stacking = normal
>> color = "orange"
>> lineWidth = 0
>> marker
>> enabled = true
>> radius = 4
>> states
>> [hover]
>> lineWidthPlus = 0
>> [[[lightning_distance]]]
>> yAxis = 1
>> yAxis_min = 0
>> yAxis_label = "Distance (miles)"
>> stacking = normal
>> color = "blue"
>> lineWidth = 0
>> marker
>> enabled = true
>> radius = 3
>> states
>> [hover]
>> lineWidthPlus = 0 
>>
>>
>> For the distance correction (conversion to miles) I have an entry in the 
>> StdCalibrate section of weewx.conf:
>>
>> ##
>>
>> #   This section can adjust data using calibration expressions.
>>
>> [StdCalibrate]
>> 
>> [[Corrections]]
>> # For each type, an arbitrary calibration expression can be given.
>> # It should be in the units defined in the StdConvert section.
>> # Example:  foo = foo + 0.2
>> outTemp = outTemp + 0.0
>> barometer = barometer + 1.025
>> radiation = luminosity * 0.00789 if luminosity > 0 else None
>> lightning_distance = lightning_distance / 1.609 if 
>> lightning_strike_count > 0 else None#convert distance to miles
>>
>>
>> ##
>>
>>
>>
>> On Sunday, June 11, 2023 at 3:36:30 PM UTC-5 Kevin Crivelli wrote:
>>
>> Eric K, could you provide the chart.conf configuration for that chart and 
>> also what ended up being the correct way to add the correction in 
>> weewx.conf? Your chart is essentially what I am tr

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

[Eric K]

Hi Kevin,

In the graphs.conf file (Belchertown skin) I have this:

[[chart6]]
title = Lightning
[[[lightning_strike_count]]]
yAxis = 0
yAxis_min = 0
yAxis_tickInterval = 1
yAxis_label = "Number of Strikes"
stacking = normal
color = "orange"
lineWidth = 0
marker
enabled = true
radius = 4
states
[hover]
lineWidthPlus = 0
[[[lightning_distance]]]
yAxis = 1
yAxis_min = 0
yAxis_label = "Distance (miles)"
stacking = normal
color = "blue"
lineWidth = 0
marker
enabled = true
radius = 3
states
[hover]
lineWidthPlus = 0 


For the distance correction (conversion to miles) I have an entry in the 
StdCalibrate section of weewx.conf:
##

#   This section can adjust data using calibration expressions.

[StdCalibrate]

[[Corrections]]
# For each type, an arbitrary calibration expression can be given.
# It should be in the units defined in the StdConvert section.
# Example:  foo = foo + 0.2
outTemp = outTemp + 0.0
barometer = barometer + 1.025
radiation = luminosity * 0.00789 if luminosity > 0 else None
lightning_distance = lightning_distance / 1.609 if 
lightning_strike_count > 0 else None#convert distance to miles

##


On Sunday, June 11, 2023 at 3:36:30 PM UTC-5 Kevin Crivelli wrote:

Eric K, could you provide the chart.conf configuration for that chart and 
also what ended up being the correct way to add the correction in 
weewx.conf? Your chart is essentially what I am trying to accomplish

On Tuesday, May 25, 2021 at 12:36:09 PM UTC-4 Eric K wrote:

It's working as desired now!
Thanks for noticing the incorrect location of the [[Corrections]]

[image: lightning_distance working.JPG]

On Monday, May 24, 2021 at 7:39:25 AM UTC-5 gjr80 wrote:

I can't explain it, it would require some detailed knowledge of how the 
Acurite lightning sensor behaves. For example, the Ecowitt lightning sensor 
reports distance when strikes are detected and that distance value persists 
for some time before eventually reporting 0. If you had debug logging of 
the SDR output (as you have in the log extract above) going on for some 
time previous you could probably work through the log looking at the 
distance value being obtained by the SDR driver from the Acurite. One thing 
is certain though, the SDR driver was not applying the correction as the 
SDR driver contains no code to read those config settings. And if the 
correction was not under [StdCalibrate] [[Corrections]] then WeeWX wasn't 
applying the correction either.

Might just have to remain a mystery.

Gary

On Monday, 24 May 2021 at 07:33:56 UTC+10 Eric K wrote:

Thanks for the pointer.  
I also had a [[Corrections]] sections under [StdCalibrate].

I just moved the lightning_distance correction to the [StdCalibrate] 
section.
We'll see if that helps.

Isn't it odd that it worked, when the lightning_distance was something 
other than 10?


On Sunday, May 23, 2021 at 3:10:54 PM UTC-5 gjr80 wrote:

I think you might find the [[Corrections]] stanza belongs under 
[StdCalibrate] <http://weewx.com/docs/usersguide.htm#StdCalibrate> rather 
than the SDR driver.

Gary
On Monday, 24 May 2021 at 02:32:14 UTC+10 Eric K wrote:

Here's a relevant section of the log which shows the Acurite Atlas 
lightning sensor sending the last distance (10) reading over and over.  
This is expected Acurite Atlas behavior, and the reason we have to put the 
"if > 0 else None" statement in our [[Corrections]] section.

Referring back to the 5.64705882352941 value seen in my database:
I wonder if weewx isn't expecting a decimal reading to be in 
lightning_distance?
And that sends it into confusion?

May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: lines=['{"time" 
: "2021-05-23 15:56:20", "model" : "Acurite-Atlas", "id" : 17, "channel" : 
"A", "sequence_num" : 0, "battery_ok" : 1, "message_type" : 38, 
"wind_avg_mi_h" : 4.000, "wind_dir_deg" : 190.000, "rain_in" : 2.040, 
"strike_count" : 45, "strike_distance" : 10, "exception" : 0, "raw_msg" : 
"c011668205f9cc8baab8"}\n', '{"time" : "2021-05-23 15:56:20", "model" : 
"Acurite-Atlas", "id" : 1

Re: [weewx-user] Belchertown graphs stopped working

[Eric K]

Huh.  I didn't do anything and the charts returned.
On Tuesday, May 9, 2023 at 10:58:23 AM UTC-5 Eric K wrote:

> I implemented the workaround posted by James-76 in issue 881 
> <https://github.com/poblabs/weewx-belchertown/issues/881>, and it worked 
> for the last 2 weeks...until this morning.
> I have not looked for clues yet, but I'm betting that Highcharts changed 
> something on their server, and now our links to 10.3.3 code are broken.
> On Wednesday, April 26, 2023 at 9:32:54 AM UTC-5 Didier Decoodt wrote:
>
>> see https://github.com/poblabs/weewx-belchertown/issues/881
>>
>> Le mer. 26 avr. 2023 à 16:30, pannetron  a écrit :
>>
>>> Yesterday my Belchertown skin version 1.2 on weewx 4.10.2 stopped 
>>> generating graphs.  With debug turned on, there are no error messages.  
>>> Before yesterday everything was working perfectly for months, no recent 
>>> changes on my end.  It appears that the Belchertown skin may  access some 
>>> other internet resources to generate its graphs - might one of those have 
>>> changed?   
>>>
>>> -- 
>>> You received this message because you are subscribed 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/f2941161-93af-4659-9cdb-d605f958494cn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/f2941161-93af-4659-9cdb-d605f958494cn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> 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/af71de9b-8567-40b8-b8af-c7ede1c30cf9n%40googlegroups.com.

Re: [weewx-user] Belchertown graphs stopped working

[Eric K]

I implemented the workaround posted by James-76 in issue 881 
, and it worked 
for the last 2 weeks...until this morning.
I have not looked for clues yet, but I'm betting that Highcharts changed 
something on their server, and now our links to 10.3.3 code are broken.
On Wednesday, April 26, 2023 at 9:32:54 AM UTC-5 Didier Decoodt wrote:

> see https://github.com/poblabs/weewx-belchertown/issues/881
>
> Le mer. 26 avr. 2023 à 16:30, pannetron  a écrit :
>
>> Yesterday my Belchertown skin version 1.2 on weewx 4.10.2 stopped 
>> generating graphs.  With debug turned on, there are no error messages.  
>> Before yesterday everything was working perfectly for months, no recent 
>> changes on my end.  It appears that the Belchertown skin may  access some 
>> other internet resources to generate its graphs - might one of those have 
>> changed?   
>>
>> -- 
>> You received this message because you are subscribed 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/f2941161-93af-4659-9cdb-d605f958494cn%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/8ee3ad3b-06a4-46f9-bd95-1d49ee1c310en%40googlegroups.com.

[weewx-user] Belchertown skin - dark theme switchover around sunset

[Eric K]

I have the Belchertown skin theme set to "auto" so it switches over to the 
dark theme around sunset.
I have noted that the Belchertown skin switches over to the dark theme at 
large fractions of an hour before sunset actually occurs.
Then, I got a report from a friend in the Eastern time zone, that the 
webpage theme switched to dark around 6:00pm Eastern time - around 2 hours 
early compared to the local sundown time (7:39pm Central) at my weewx 
weather station.
He said he had not clicked the manual theme switch at the upper right 
corner of the Belchertown page.

So, I started looking through the code to see how the theme change gets 
triggered.

see:  
https://github.com/poblabs/weewx-belchertown/blob/master/skins/Belchertown/js/belchertown.js.tmpl

Around line 507 the current hour and minute get assigned to variables with 
the expressions 
var nowHour = d.getHours();
var nowMinutes = d.getMinutes();
Where is the time being read from? 
1. from the clock of the computer that weewx is running inside?
2. from the clock of webpage visitor's computer?

-- 
You received this message because you are subscribed 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/7eb9e891-52a4-4e1f-9e04-e322bb2460bcn%40googlegroups.com.

Re: [weewx-user] Re: want to have /home/weewx/public_html in a ramdisk

[Eric K]

Vince, thanks for your idea of manually creating the 
/home/weewx/public_html/json directory.
I tried it and it did allow Belchertown to work with the first run of 
wee_reports.

Later, I found if I ran wee_reports a 2nd time, the Belchertown skin 
completes the creation of the web page in the ramdisk, because the first 
run of wee_reports (that fails) creates the /home/weewx/public_html/json 
directory.  That's good enough to succeed after that.

At present, the public_html directory is running inside a ramdisk.
Since it works, I'm going to leave it like this.

I'm using the imagemagick package to add date/time info to each webcam grab.
If nothing else, my webcam pictures are likely loading and processing 
faster.

Eric
On Saturday, March 12, 2022 at 5:10:05 PM UTC-6 Eric K wrote:

> No problem, Doug.  
> Your intention to share helpful information is appreciated!  
>
> On Saturday, March 12, 2022 at 5:00:15 PM UTC-6 do...@dougjenkins.com 
> wrote:
>
>> I am sorry, I didn't read the entire post. 
>>
>> On Sat, Mar 12, 2022, 5:33 PM Eric K  wrote:
>>
>>> Its' a Raspberry Pi 3B+ 
>>>
>>> On Saturday, March 12, 2022 at 4:25:00 PM UTC-6 do...@dougjenkins.com 
>>> wrote:
>>>
>>>> Eric, if you have pi4 with firmware older than 09/2021, you can boot 
>>>> from a usb3 drive. This is what I have been doing with my RPI as I have 
>>>> lost 2 good sdcards due to write failures.
>>>>
>>>> On Sat, Mar 12, 2022, 4:46 PM Eric K  wrote:
>>>>
>>>>> Hi Peter.
>>>>>
>>>>> Correct, extending the life of the SD card is my goal.
>>>>>
>>>>> I am currently rebuilding my weewx Raspberry Pi system because of a 
>>>>> suspected SD card failure.
>>>>> I had 2 local Linux users tell me that the symptoms are consistent 
>>>>> with an SD card corruption.
>>>>> The card is only 9 months old, and it's not bottom-of-the barrel 
>>>>> quality!
>>>>> I reached out for help 2 weeks ago and got zero responses.
>>>>> see:
>>>>>
>>>>> https://forums.raspberrypi.com/viewtopic.php?p=1979221=kernel+panic#p1979221
>>>>>
>>>>>
>>>>>
>>>>> On Saturday, March 12, 2022 at 3:35:06 PM UTC-6 peterq...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> If you're wanting a ramdisk because SD cards are unreliable, I 
>>>>>> wouldn't bother. There is plenty of history of people running Weewx on 
>>>>>> Raspberry Pis for many years without a problem with corrupted SD cards. 
>>>>>>
>>>>>> On Sat, Mar 12, 2022 at 12:55 PM vince  wrote:
>>>>>>
>>>>>>> I would try 'mkdir /home/weewx/public_html/forecast' so the parent 
>>>>>>> directory exists when weewx tries to write it.
>>>>>>>
>>>>>>> I'd also add that doing it your way means your NOAA files will be 
>>>>>>> recreated every time it boots, which could take ages if you have many 
>>>>>>> years 
>>>>>>> of info like many of us do.
>>>>>>>
>>>>>>> One way would be to put something in your rc.local which runs after 
>>>>>>> things mount ala:
>>>>>>>
>>>>>>> if [ -d /home/weewx/public_html ]
>>>>>>> then
>>>>>>># prepopulate things here
>>>>>>>mkdir /home/weewx/public_html/forecast
>>>>>>> else
>>>>>>>logger "error - rc.local could not mkdir for weewx"
>>>>>>> fi
>>>>>>>
>>>>>>> You might run into timing issues if you do too much this way since 
>>>>>>> rc.local tends to run toward the end of the startup sequence, but a 
>>>>>>> quick 
>>>>>>> mkdir should work.
>>>>>>>
>>>>>>> On Saturday, March 12, 2022 at 12:40:49 PM UTC-8 Eric K wrote:
>>>>>>>
>>>>>>>> Currently running weewx 4.5.1 in a Raspberry Pi 3B+ with the 
>>>>>>>> Bullseye version of Raspberry Pi OS.
>>>>>>>> For a Raspberry Pi (using a microSD card as the OS system drive) I 
>>>>>>>> want to create a ramdisk for the /home/weewx/public_html directory.  
>>>>>>>> I followed examples fr

Re: [weewx-user] Re: want to have /home/weewx/public_html in a ramdisk

[Eric K]

No problem, Doug.  
Your intention to share helpful information is appreciated!  

On Saturday, March 12, 2022 at 5:00:15 PM UTC-6 do...@dougjenkins.com wrote:

> I am sorry, I didn't read the entire post. 
>
> On Sat, Mar 12, 2022, 5:33 PM Eric K  wrote:
>
>> Its' a Raspberry Pi 3B+ 
>>
>> On Saturday, March 12, 2022 at 4:25:00 PM UTC-6 do...@dougjenkins.com 
>> wrote:
>>
>>> Eric, if you have pi4 with firmware older than 09/2021, you can boot 
>>> from a usb3 drive. This is what I have been doing with my RPI as I have 
>>> lost 2 good sdcards due to write failures.
>>>
>>> On Sat, Mar 12, 2022, 4:46 PM Eric K  wrote:
>>>
>>>> Hi Peter.
>>>>
>>>> Correct, extending the life of the SD card is my goal.
>>>>
>>>> I am currently rebuilding my weewx Raspberry Pi system because of a 
>>>> suspected SD card failure.
>>>> I had 2 local Linux users tell me that the symptoms are consistent with 
>>>> an SD card corruption.
>>>> The card is only 9 months old, and it's not bottom-of-the barrel 
>>>> quality!
>>>> I reached out for help 2 weeks ago and got zero responses.
>>>> see:
>>>>
>>>> https://forums.raspberrypi.com/viewtopic.php?p=1979221=kernel+panic#p1979221
>>>>
>>>>
>>>>
>>>> On Saturday, March 12, 2022 at 3:35:06 PM UTC-6 peterq...@gmail.com 
>>>> wrote:
>>>>
>>>>> If you're wanting a ramdisk because SD cards are unreliable, I 
>>>>> wouldn't bother. There is plenty of history of people running Weewx on 
>>>>> Raspberry Pis for many years without a problem with corrupted SD cards. 
>>>>>
>>>>> On Sat, Mar 12, 2022 at 12:55 PM vince  wrote:
>>>>>
>>>>>> I would try 'mkdir /home/weewx/public_html/forecast' so the parent 
>>>>>> directory exists when weewx tries to write it.
>>>>>>
>>>>>> I'd also add that doing it your way means your NOAA files will be 
>>>>>> recreated every time it boots, which could take ages if you have many 
>>>>>> years 
>>>>>> of info like many of us do.
>>>>>>
>>>>>> One way would be to put something in your rc.local which runs after 
>>>>>> things mount ala:
>>>>>>
>>>>>> if [ -d /home/weewx/public_html ]
>>>>>> then
>>>>>># prepopulate things here
>>>>>>mkdir /home/weewx/public_html/forecast
>>>>>> else
>>>>>>logger "error - rc.local could not mkdir for weewx"
>>>>>> fi
>>>>>>
>>>>>> You might run into timing issues if you do too much this way since 
>>>>>> rc.local tends to run toward the end of the startup sequence, but a 
>>>>>> quick 
>>>>>> mkdir should work.
>>>>>>
>>>>>> On Saturday, March 12, 2022 at 12:40:49 PM UTC-8 Eric K wrote:
>>>>>>
>>>>>>> Currently running weewx 4.5.1 in a Raspberry Pi 3B+ with the 
>>>>>>> Bullseye version of Raspberry Pi OS.
>>>>>>> For a Raspberry Pi (using a microSD card as the OS system drive) I 
>>>>>>> want to create a ramdisk for the /home/weewx/public_html directory.  
>>>>>>> I followed examples from various webpages on the ramdisk topic.  
>>>>>>> What I've tried thus far doesn't fully work.
>>>>>>> How are others implementing this?
>>>>>>>
>>>>>>> I started by renaming my /home/weewx/public_html directory to 
>>>>>>> /home/weewx/public_html_backup, so there would be no conflict when the 
>>>>>>> ramdisk was created at bootup.  
>>>>>>> Then, I put this line in the /etc/fstab file and rebooted.
>>>>>>> tmpfs   /home/weewx/public_html   tmpfs  
>>>>>>>  defaults,noatime,size=100M   0 0
>>>>>>> I tested it with sudo mount -a and the new partition was visible by 
>>>>>>> using the df command.
>>>>>>>
>>>>>>> After a reboot, a /home/weewx/public_html directory was created as a 
>>>>>>> tmpfs volume.
>>>>>>> To test the functionality, I manually ran wee_reports to force the 
>>&

Re: [weewx-user] Re: want to have /home/weewx/public_html in a ramdisk

[Eric K]

Its' a Raspberry Pi 3B+ 

On Saturday, March 12, 2022 at 4:25:00 PM UTC-6 do...@dougjenkins.com wrote:

> Eric, if you have pi4 with firmware older than 09/2021, you can boot from 
> a usb3 drive. This is what I have been doing with my RPI as I have lost 2 
> good sdcards due to write failures.
>
> On Sat, Mar 12, 2022, 4:46 PM Eric K  wrote:
>
>> Hi Peter.
>>
>> Correct, extending the life of the SD card is my goal.
>>
>> I am currently rebuilding my weewx Raspberry Pi system because of a 
>> suspected SD card failure.
>> I had 2 local Linux users tell me that the symptoms are consistent with 
>> an SD card corruption.
>> The card is only 9 months old, and it's not bottom-of-the barrel quality!
>> I reached out for help 2 weeks ago and got zero responses.
>> see:
>>
>> https://forums.raspberrypi.com/viewtopic.php?p=1979221=kernel+panic#p1979221
>>
>>
>>
>> On Saturday, March 12, 2022 at 3:35:06 PM UTC-6 peterq...@gmail.com 
>> wrote:
>>
>>> If you're wanting a ramdisk because SD cards are unreliable, I wouldn't 
>>> bother. There is plenty of history of people running Weewx on Raspberry Pis 
>>> for many years without a problem with corrupted SD cards. 
>>>
>>> On Sat, Mar 12, 2022 at 12:55 PM vince  wrote:
>>>
>>>> I would try 'mkdir /home/weewx/public_html/forecast' so the parent 
>>>> directory exists when weewx tries to write it.
>>>>
>>>> I'd also add that doing it your way means your NOAA files will be 
>>>> recreated every time it boots, which could take ages if you have many 
>>>> years 
>>>> of info like many of us do.
>>>>
>>>> One way would be to put something in your rc.local which runs after 
>>>> things mount ala:
>>>>
>>>> if [ -d /home/weewx/public_html ]
>>>> then
>>>># prepopulate things here
>>>>mkdir /home/weewx/public_html/forecast
>>>> else
>>>>logger "error - rc.local could not mkdir for weewx"
>>>> fi
>>>>
>>>> You might run into timing issues if you do too much this way since 
>>>> rc.local tends to run toward the end of the startup sequence, but a quick 
>>>> mkdir should work.
>>>>
>>>> On Saturday, March 12, 2022 at 12:40:49 PM UTC-8 Eric K wrote:
>>>>
>>>>> Currently running weewx 4.5.1 in a Raspberry Pi 3B+ with the Bullseye 
>>>>> version of Raspberry Pi OS.
>>>>> For a Raspberry Pi (using a microSD card as the OS system drive) I 
>>>>> want to create a ramdisk for the /home/weewx/public_html directory.  
>>>>> I followed examples from various webpages on the ramdisk topic.  
>>>>> What I've tried thus far doesn't fully work.
>>>>> How are others implementing this?
>>>>>
>>>>> I started by renaming my /home/weewx/public_html directory to 
>>>>> /home/weewx/public_html_backup, so there would be no conflict when the 
>>>>> ramdisk was created at bootup.  
>>>>> Then, I put this line in the /etc/fstab file and rebooted.
>>>>> tmpfs   /home/weewx/public_html   tmpfs   defaults,noatime,size=100M  
>>>>>  0 0
>>>>> I tested it with sudo mount -a and the new partition was visible by 
>>>>> using the df command.
>>>>>
>>>>> After a reboot, a /home/weewx/public_html directory was created as a 
>>>>> tmpfs volume.
>>>>> To test the functionality, I manually ran wee_reports to force the 
>>>>> webpage to be created.
>>>>> When wee_reports ran, the process crashed with errors, because some of 
>>>>> the files don't exist from previous runs of wee_reports.
>>>>>
>>>>> pi@rpi3b:/home/weewx $ sudo bin/wee_reports
>>>>> Using configuration file /home/weewx/weewx.conf
>>>>> Generating for all time
>>>>> Traceback (most recent call last):
>>>>>   File "/home/weewx/bin/user/belchertown.py", line 1390, in 
>>>>> get_extension_list
>>>>> with open(forecast_file, "wb+") as file:
>>>>> FileNotFoundError: [Errno 2] No such file or directory: 
>>>>> '/home/weewx/public_html/json/forecast.json'
>>>>>
>>>>> During handling of the above exception, another exception occurred:
>>>>>
>>>>> Traceback (most 

Re: [weewx-user] Re: want to have /home/weewx/public_html in a ramdisk

[Eric K]

Hi Peter.

Correct, extending the life of the SD card is my goal.

I am currently rebuilding my weewx Raspberry Pi system because of a 
suspected SD card failure.
I had 2 local Linux users tell me that the symptoms are consistent with an 
SD card corruption.
The card is only 9 months old, and it's not bottom-of-the barrel quality!
I reached out for help 2 weeks ago and got zero responses.
see:
https://forums.raspberrypi.com/viewtopic.php?p=1979221=kernel+panic#p1979221



On Saturday, March 12, 2022 at 3:35:06 PM UTC-6 peterq...@gmail.com wrote:

> If you're wanting a ramdisk because SD cards are unreliable, I wouldn't 
> bother. There is plenty of history of people running Weewx on Raspberry Pis 
> for many years without a problem with corrupted SD cards. 
>
> On Sat, Mar 12, 2022 at 12:55 PM vince  wrote:
>
>> I would try 'mkdir /home/weewx/public_html/forecast' so the parent 
>> directory exists when weewx tries to write it.
>>
>> I'd also add that doing it your way means your NOAA files will be 
>> recreated every time it boots, which could take ages if you have many years 
>> of info like many of us do.
>>
>> One way would be to put something in your rc.local which runs after 
>> things mount ala:
>>
>> if [ -d /home/weewx/public_html ]
>> then
>># prepopulate things here
>>mkdir /home/weewx/public_html/forecast
>> else
>>logger "error - rc.local could not mkdir for weewx"
>> fi
>>
>> You might run into timing issues if you do too much this way since 
>> rc.local tends to run toward the end of the startup sequence, but a quick 
>> mkdir should work.
>>
>> On Saturday, March 12, 2022 at 12:40:49 PM UTC-8 Eric K wrote:
>>
>>> Currently running weewx 4.5.1 in a Raspberry Pi 3B+ with the Bullseye 
>>> version of Raspberry Pi OS.
>>> For a Raspberry Pi (using a microSD card as the OS system drive) I want 
>>> to create a ramdisk for the /home/weewx/public_html directory.  
>>> I followed examples from various webpages on the ramdisk topic.  
>>> What I've tried thus far doesn't fully work.
>>> How are others implementing this?
>>>
>>> I started by renaming my /home/weewx/public_html directory to 
>>> /home/weewx/public_html_backup, so there would be no conflict when the 
>>> ramdisk was created at bootup.  
>>> Then, I put this line in the /etc/fstab file and rebooted.
>>> tmpfs   /home/weewx/public_html   tmpfs   defaults,noatime,size=100M   0 
>>> 0
>>> I tested it with sudo mount -a and the new partition was visible by 
>>> using the df command.
>>>
>>> After a reboot, a /home/weewx/public_html directory was created as a 
>>> tmpfs volume.
>>> To test the functionality, I manually ran wee_reports to force the 
>>> webpage to be created.
>>> When wee_reports ran, the process crashed with errors, because some of 
>>> the files don't exist from previous runs of wee_reports.
>>>
>>> pi@rpi3b:/home/weewx $ sudo bin/wee_reports
>>> Using configuration file /home/weewx/weewx.conf
>>> Generating for all time
>>> Traceback (most recent call last):
>>>   File "/home/weewx/bin/user/belchertown.py", line 1390, in 
>>> get_extension_list
>>> with open(forecast_file, "wb+") as file:
>>> FileNotFoundError: [Errno 2] No such file or directory: 
>>> '/home/weewx/public_html/json/forecast.json'
>>>
>>> During handling of the above exception, another exception occurred:
>>>
>>> Traceback (most recent call last):
>>>   File "/home/weewx/bin/weewx/reportengine.py", line 196, in run
>>> obj.start()
>>>   File "/home/weewx/bin/weewx/reportengine.py", line 281, in start
>>> self.run()
>>>   File "/home/weewx/bin/weewx/cheetahgenerator.py", line 152, in run
>>> ngen = self.generate(gen_dict[section_name], self.gen_ts)
>>>   File "/home/weewx/bin/weewx/cheetahgenerator.py", line 222, in generate
>>> ngen += self.generate(section[subsection], gen_ts)
>>>   File "/home/weewx/bin/weewx/cheetahgenerator.py", line 222, in generate
>>> ngen += self.generate(section[subsection], gen_ts)
>>>   File "/home/weewx/bin/weewx/cheetahgenerator.py", line 310, in generate
>>> searchList = self._getSearchList(encoding, timespan,
>>>   File "/home/weewx/bin/weewx/cheetahgenerator.py", line 387, in 
>>> _getSearchList
>>> searchList += obj.get_extension_list

[weewx-user] want to have /home/weewx/public_html in a ramdisk

[Eric K]

Currently running weewx 4.5.1 in a Raspberry Pi 3B+ with the Bullseye 
version of Raspberry Pi OS.
For a Raspberry Pi (using a microSD card as the OS system drive) I want to 
create a ramdisk for the /home/weewx/public_html directory.  
I followed examples from various webpages on the ramdisk topic.  
What I've tried thus far doesn't fully work.
How are others implementing this?

I started by renaming my /home/weewx/public_html directory to 
/home/weewx/public_html_backup, so there would be no conflict when the 
ramdisk was created at bootup.  
Then, I put this line in the /etc/fstab file and rebooted.
tmpfs   /home/weewx/public_html   tmpfs   defaults,noatime,size=100M   0 0
I tested it with sudo mount -a and the new partition was visible by using 
the df command.

After a reboot, a /home/weewx/public_html directory was created as a tmpfs 
volume.
To test the functionality, I manually ran wee_reports to force the webpage 
to be created.
When wee_reports ran, the process crashed with errors, because some of the 
files don't exist from previous runs of wee_reports.

pi@rpi3b:/home/weewx $ sudo bin/wee_reports
Using configuration file /home/weewx/weewx.conf
Generating for all time
Traceback (most recent call last):
  File "/home/weewx/bin/user/belchertown.py", line 1390, in 
get_extension_list
with open(forecast_file, "wb+") as file:
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/weewx/public_html/json/forecast.json'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/weewx/bin/weewx/reportengine.py", line 196, in run
obj.start()
  File "/home/weewx/bin/weewx/reportengine.py", line 281, in start
self.run()
  File "/home/weewx/bin/weewx/cheetahgenerator.py", line 152, in run
ngen = self.generate(gen_dict[section_name], self.gen_ts)
  File "/home/weewx/bin/weewx/cheetahgenerator.py", line 222, in generate
ngen += self.generate(section[subsection], gen_ts)
  File "/home/weewx/bin/weewx/cheetahgenerator.py", line 222, in generate
ngen += self.generate(section[subsection], gen_ts)
  File "/home/weewx/bin/weewx/cheetahgenerator.py", line 310, in generate
searchList = self._getSearchList(encoding, timespan,
  File "/home/weewx/bin/weewx/cheetahgenerator.py", line 387, in 
_getSearchList
searchList += obj.get_extension_list(timespan, db_lookup)
  File "/home/weewx/bin/user/belchertown.py", line 1399, in 
get_extension_list
raise Warning(
Warning: Error writing forecast info to 
/home/weewx/public_html/json/forecast.json. Reason: [Errno 2] No such file 
or directory: '/home/weewx/public_html/json/forecast.json'  

I found that if I copy the contents of my /home/weewx/public_html_backup 
folder into the /home/weewx/public_html ramdisk, then wee_reports completes 
and creates the fully populated /home/weewx/public_html directory.

Is everyone else populating the ramdisk with a backup of the puclic_html 
folder at bootup time?

Thanks,
Eric

-- 
You received this message because you are subscribed 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/5b24c101-f827-4c57-a4ec-252763757e8cn%40googlegroups.com.

Re: [weewx-user] When die the blast wave of the eruption "hit" your station?

[Eric K]

It arrived in Minnesota around 14:20 UTC (8:20am CDT).
[image: 2022-1-15 Tonga Volcano pressure wave wide.JPG]
[image: 2022-1-15 Tonga Volcano pressure wave.JPG]

On Sunday, January 16, 2022 at 12:24:02 PM UTC-6 n0...@n0nb.us wrote:

> * On 2022 16 Jan 11:09 -0600, storm...@gmail.com wrote:
> > If anyone did not see the video, here is the link: 
> > https://spaceweathergallery.com/indiv_upload.php?upload_id=181596
>
> As noted on the page the terminator catches up to the shock wave.
>
> Also, note the interesting glow on the cloud bank east of the eruption
> cloud as darkness falls.
>
> Cool stuff!
>
> - Nate
>
> -- 
> "The optimist proclaims that we live in the best of all
> possible worlds. The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>

-- 
You received this message because you are subscribed 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/cde5f4d6-414d-42c8-b020-2e81a3a2e3b2n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

*Thanks Vince and Rich for the pointers and advice.*

It looks like the 2 biggest Ubuntu 21.04 changes that broke my setup were:
1.  Python changed from 3.8 to 3.9 
2.  mosquitto changed from version 1.6 to 2.0

The fixes that worked:
1.  reloading python3-paho-mqtt with command "sudo apt install 
python3-paho-mqtt" (rather than using pip3)
2.  edited my existing /etc/mosquitto/mosquitto.conf file:
a.  I already had the line "allow_anonymous true" so that stayed 
as-is
b.  changed the "port 1883" line to "listener 1883"
c.  commented out the line with "include_dir /etc/mosquitto/conf.d"
3.  deleted the directory /run/mosquitto with "sudo rm -r /run/mosquitto"
4.  restarted the system

After that, mosquitto started without errors, the MTQQSubscribe service 
subscribed, and weewx was functional again.

After weewx was working in Ubuntu 21.04 I made a backup and tried upgrading 
to 21.10 - worked fine, without breakage!
So, now weewx 4.5.1 is running fine in Ubuntu 21.10.
On Saturday, January 1, 2022 at 12:56:45 PM UTC-6 Eric K wrote:

> I just restarted Ubuntu and made sure the mosquitto.conf file was adjusted 
> for the new 2.x listener command, and mosquitto started working.
>
> I just commented out a couple of lines I had in the mosquitto.conf file 
> (which worked fine in Ubuntu 20.10):
> #pid_file /var/run/mosquitto.pid
> #persistence true
> #persistence_location /var/lib/mosquitto/
> #log_dest file /var/log/mosquitto/mosquitto.log
>
> Earlier, I saw an error about creating /var/log/mosquitto/mosquitto.log 
>
> The mosquitto_sub command now works and mosquitto is receiving my 
> barometric pressure data!
>
> weewx@Ubuntu20-WEEWX:~$ mosquitto -c /etc/mosquitto/mosquitto.conf
> 1641062208: mosquitto version 2.0.10 starting
> 1641062208: Config loaded from /etc/mosquitto/mosquitto.conf.
> 1641062208: Opening ipv4 listen socket on port 1883.
> 1641062208: Error: Address already in use
> weewx@Ubuntu20-WEEWX:~$ mosquitto_sub -h 192.168.7.22 -p 1883 -t 
> tele/BMP280/SENSOR -d
> Client (null) sending CONNECT
> Client (null) received CONNACK (0)
> Client (null) sending SUBSCRIBE (Mid: 1, Topic: tele/BMP280/SENSOR, QoS: 
> 0, Options: 0x00)
> Client (null) received SUBACK
> Subscribed (mid: 1): 0
> Client (null) received PUBLISH (d0, q0, r0, m0, 'tele/BMP280/SENSOR', ... 
> (113 bytes))
>
> {"Time":"2022-01-01T12:38:02","BMP280":{"Temperature":69.7,"Pressure":985.8},"PressureUnit":"hPa","TempUnit":"F"}
> Client (null) sending PINGREQ
> Client (null) received PINGRESP
>
> weewx is running without errors and publishing reports every 300 seconds!
>
> Jan  1 12:35:07 Ubuntu20-WEEWX weewx[1224] DEBUG weewx.engine: Loading 
> service weewx.restx.StdPWSweather
> Jan  1 12:35:07 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: PWSWeather: 
> Data for station WESTGATE1 will be posted
> Jan  1 12:35:07 Ubuntu20-WEEWX weewx[1224] DEBUG weewx.engine: Finished 
> loading service weewx.restx.StdPWSweather
> Jan  1 12:40:22 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: PWSWeather: 
> Published record 2022-01-01 12:40:00 CST (1641062400)
> Jan  1 12:40:22 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: 
> Wunderground-PWS: Published record 2022-01-01 12:40:00 CST (1641062400)
> Jan  1 12:45:19 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: PWSWeather: 
> Published record 2022-01-01 12:45:00 CST (1641062700)
> Jan  1 12:45:19 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: 
> Wunderground-PWS: Published record 2022-01-01 12:45:00 CST (1641062700)
> On Saturday, January 1, 2022 at 11:56:36 AM UTC-6 Eric K wrote:
>
>> I just switched back to the Ubuntu 21.04 VM and collected lots of 
>> evidence of mosquitto not starting properly.
>>
>> These are the commands that Vince requested:
>>
>> weewx@Ubuntu20-WEEWX:/run$ ls -lagd /run/mosquitto
>> drwxr- 2 mosquitto 40 Jan  1 11:37 /run/mosquitto
>>
>> weewx@Ubuntu20-WEEWX:/run$ ls -lagd /run/mosquitto/*
>> ls: cannot access '/run/mosquitto/*': Permission denied
>>
>> weewx@Ubuntu20-WEEWX:/run$ sudo rm -r /run/mosquitto
>>
>> weewx@Ubuntu20-WEEWX:/run$ sudo systemctl start mosquitto
>>
>> Job for mosquitto.service failed because the control process exited with 
>> error code.
>> See "systemctl status mosquitto.service" and "journalctl -xe" for details.
>>
>> weewx@Ubuntu20-WEEWX:/run$ sudo systemctl status mosquitto.service
>>
>> ● mosquitto.service - Mosquitto MQTT Broker
>>  Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; 
>> vendor preset: enabled)
>>  Active: failed (Result

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

I just restarted Ubuntu and made sure the mosquitto.conf file was adjusted 
for the new 2.x listener command, and mosquitto started working.

I just commented out a couple of lines I had in the mosquitto.conf file 
(which worked fine in Ubuntu 20.10):
#pid_file /var/run/mosquitto.pid
#persistence true
#persistence_location /var/lib/mosquitto/
#log_dest file /var/log/mosquitto/mosquitto.log

Earlier, I saw an error about creating /var/log/mosquitto/mosquitto.log 

The mosquitto_sub command now works and mosquitto is receiving my 
barometric pressure data!

weewx@Ubuntu20-WEEWX:~$ mosquitto -c /etc/mosquitto/mosquitto.conf
1641062208: mosquitto version 2.0.10 starting
1641062208: Config loaded from /etc/mosquitto/mosquitto.conf.
1641062208: Opening ipv4 listen socket on port 1883.
1641062208: Error: Address already in use
weewx@Ubuntu20-WEEWX:~$ mosquitto_sub -h 192.168.7.22 -p 1883 -t 
tele/BMP280/SENSOR -d
Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending SUBSCRIBE (Mid: 1, Topic: tele/BMP280/SENSOR, QoS: 0, 
Options: 0x00)
Client (null) received SUBACK
Subscribed (mid: 1): 0
Client (null) received PUBLISH (d0, q0, r0, m0, 'tele/BMP280/SENSOR', ... 
(113 bytes))
{"Time":"2022-01-01T12:38:02","BMP280":{"Temperature":69.7,"Pressure":985.8},"PressureUnit":"hPa","TempUnit":"F"}
Client (null) sending PINGREQ
Client (null) received PINGRESP

weewx is running without errors and publishing reports every 300 seconds!

Jan  1 12:35:07 Ubuntu20-WEEWX weewx[1224] DEBUG weewx.engine: Loading 
service weewx.restx.StdPWSweather
Jan  1 12:35:07 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: PWSWeather: 
Data for station WESTGATE1 will be posted
Jan  1 12:35:07 Ubuntu20-WEEWX weewx[1224] DEBUG weewx.engine: Finished 
loading service weewx.restx.StdPWSweather
Jan  1 12:40:22 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: PWSWeather: 
Published record 2022-01-01 12:40:00 CST (1641062400)
Jan  1 12:40:22 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: 
Wunderground-PWS: Published record 2022-01-01 12:40:00 CST (1641062400)
Jan  1 12:45:19 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: PWSWeather: 
Published record 2022-01-01 12:45:00 CST (1641062700)
Jan  1 12:45:19 Ubuntu20-WEEWX weewx[1224] INFO weewx.restx: 
Wunderground-PWS: Published record 2022-01-01 12:45:00 CST (1641062700)
On Saturday, January 1, 2022 at 11:56:36 AM UTC-6 Eric K wrote:

> I just switched back to the Ubuntu 21.04 VM and collected lots of evidence 
> of mosquitto not starting properly.
>
> These are the commands that Vince requested:
>
> weewx@Ubuntu20-WEEWX:/run$ ls -lagd /run/mosquitto
> drwxr- 2 mosquitto 40 Jan  1 11:37 /run/mosquitto
>
> weewx@Ubuntu20-WEEWX:/run$ ls -lagd /run/mosquitto/*
> ls: cannot access '/run/mosquitto/*': Permission denied
>
> weewx@Ubuntu20-WEEWX:/run$ sudo rm -r /run/mosquitto
>
> weewx@Ubuntu20-WEEWX:/run$ sudo systemctl start mosquitto
>
> Job for mosquitto.service failed because the control process exited with 
> error code.
> See "systemctl status mosquitto.service" and "journalctl -xe" for details.
>
> weewx@Ubuntu20-WEEWX:/run$ sudo systemctl status mosquitto.service
>
> ● mosquitto.service - Mosquitto MQTT Broker
>  Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; 
> vendor preset: enabled)
>  Active: failed (Result: exit-code) since Sat 2022-01-01 11:37:43 CST; 
> 16s ago
>
>Docs: man:mosquitto.conf(5)
>  man:mosquitto(8)
> Process: 3867 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 3868 ExecStartPre=/bin/chown mosquitto: /var/log/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 3869 ExecStartPre=/bin/mkdir -m 740 -p /var/run/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 3870 ExecStartPre=/bin/chown mosquitto: /var/run/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 3871 ExecStart=/usr/sbin/mosquitto -c 
> /etc/mosquitto/mosquitto.conf (code=exited, status=1/FAILURE)
>Main PID: 3871 (code=exited, status=1/FAILURE)
>
> Jan 01 11:37:43 Ubuntu20-WEEWX systemd[1]: mosquitto.service: Scheduled 
> restart job, restart counter is at 5.
> Jan 01 11:37:43 Ubuntu20-WEEWX systemd[1]: Stopped Mosquitto MQTT Broker.
> Jan 01 11:37:43 Ubuntu20-WEEWX systemd[1]: mosquitto.service: Start 
> request repeated too quickly.
> Jan 01 11:37:43 Ubuntu20-WEEWX systemd[1]: mosquitto.service: Failed with 
> result 'exit-code'.
> Jan 01 11:37:43 Ubuntu20-WEEWX systemd[1]: Failed to start Mosquitto MQTT 
> Broker.
>
> weewx@Ubuntu20-WEEWX:/run$ journalctl -xe
> Hint: You are currently not seeing messages from other users and the 
> system.
>   Users in groups 'adm', 'systemd-journal' can see

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

EEWX org.gnome.Nautilus[3883]: from gettext 
import gettext, locale, bindtextdomain, textdomain
Jan 01 11:38:27 Ubuntu20-WEEWX org.gnome.Nautilus[3883]: ImportError: 
cannot import name 'locale' from 'gettext' (/usr/lib/python3.9/gettext>
Jan 01 11:38:27 Ubuntu20-WEEWX nautilus[3883]: Called "net usershare info" 
but it failed: Failed to execute child process “net” (No such fil>
Jan 01 11:41:55 Ubuntu20-WEEWX sudo[3932]:weewx : TTY=pts/0 ; PWD=/run 
; USER=root ; COMMAND=/usr/bin/systemctl start mosquitto
Jan 01 11:41:55 Ubuntu20-WEEWX sudo[3932]: pam_unix(sudo:session): session 
opened for user root by (uid=1001)
Jan 01 11:41:55 Ubuntu20-WEEWX sudo[3932]: pam_unix(sudo:session): session 
closed for user root
lines 3313-3354/3354 (END)

weewx@Ubuntu20-WEEWX:/run$ mosquitto_sub -v -h 192.168.7.22 -p 1883 -t 
tele/BMP280/SENSOR -d
Error: Connection refused

weewx@Ubuntu20-WEEWX:/etc/mosquitto$ mosquitto -c 
/etc/mosquitto/mosquitto.conf
1641059552: mosquitto version 2.0.10 starting
1641059552: Config loaded from /etc/mosquitto/mosquitto.conf.
1641059552: Error: Unable to open pwfile "/etc/mosquitto/pwfile".
1641059552: Error opening password file "/etc/mosquitto/pwfile".

weewx@Ubuntu20-WEEWX:/etc/mosquitto$ sudo mosquitto -c 
/etc/mosquitto/mosquitto.conf
1641059578: mosquitto version 2.0.10 starting
1641059578: Config loaded from /etc/mosquitto/mosquitto.conf.
1641059578: Error: Unable to open pwfile "/etc/mosquitto/pwfile".
1641059578: Error opening password file "/etc/mosquitto/pwfile".

On Saturday, January 1, 2022 at 11:09:48 AM UTC-6 bell...@gmail.com wrote:

> Now that the broker is running, does mosquitto_sub work?
> Also, as Vince suggested, adding the  -v option (verbose) to the mosquitto 
> command would be useful.
> rich
> On Saturday, 1 January 2022 at 11:40:16 UTC-5 Eric K wrote:
>
>> When using, the MQTTSubscirbe driver in weewx, it runs as a weewx service 
>> in the same machine as weewx.
>> see: https://github.com/bellrichm/WeeWX-MQTTSubscribe
>> I'm running the mosquitto broker in the same Ubuntu VM as weewx, because 
>> its convenient, and it works fine in my Ubuntu 20.10 VM.
>>
>> I have a barometric pressure sensor (a stand-alone wifi device on a 
>> different IP from the Ubuntu VM) that sends data to weewx via MQTT and the 
>> MQTTSubscribe driver.
>> So, I need to get that to properly connect with mosquitto in Ubuntu 
>> 21.04, like it does in the Ubuntu 20.10.
>>
>> The connection we saw when I tried running mosquitto with it's internal 
>> default settings was MQTTSubscribe trying to connect to it.
>>
>> weewx@Ubuntu20-WEEWX:~$ mosquitto
>> 1640984406: mosquitto version 2.0.10 starting
>> 1640984406: Using default config.
>> 1640984406: Starting in local only mode. Connections will only be 
>> possible from clients running on this machine.
>> 1640984406: Create a configuration file which defines a listener to allow 
>> remote access.
>> 1640984406: For more details see 
>> https://mosquitto.org/documentation/authentication-methods/
>> 1640984406: Opening ipv4 listen socket on port 1883.
>> 1640984406: Opening ipv6 listen socket on port 1883.
>> 1640984406: mosquitto version 2.0.10 running
>> 1640984413: New connection from 127.0.0.1:42095 on port 1883.
>>
>> *1640984413: New client connected from 127.0.0.1:42095 
>> <http://127.0.0.1:42095/> as MQTTSubscribe-5503 (p2, c1, k60, 
>> u'None').1640984418: Client MQTTSubscribe-5503 disconnected.*
>> On Saturday, January 1, 2022 at 4:39:39 AM UTC-6 jon.bar...@gmail.com 
>> wrote:
>>
>>> Eric,
>>>
>>> In one of your posts above, the mosquito broker says it has a connection 
>>> from a client...and given you're running this in a single VM, that must be 
>>> a client on that machine.
>>> Im struggling to understand why you would want a MQTT broker on the same 
>>> VM as weewx ...when it only needs the client.  as weewx doesnt respond to 
>>> mqtt messages/commands (someone will correct me if Im wrong) - maybe you 
>>> dont need mqtt at all ?
>>> I suggest you test wether the weewx client is working (publishing) by 
>>> using one of the public MQTT brokers such as test.moquito.org (and 
>>> monitor your messages via mqtt explorer.
>>> If you're running the broker in the same vm as weewx, then you must have 
>>> other mqtt devices (clients)...do they work ?
>>> I agree with Vince...and Im starting to lose the plot over what you're 
>>> trying to acheive
>>>
>>>
>>> On Friday, 31 December 2021 at 23:47:59 UTC vince wrote:
>>>
>>>> Work your mosquitto broker pro

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

When using, the MQTTSubscirbe driver in weewx, it runs as a weewx service 
in the same machine as weewx.
see: https://github.com/bellrichm/WeeWX-MQTTSubscribe
I'm running the mosquitto broker in the same Ubuntu VM as weewx, because 
its convenient, and it works fine in my Ubuntu 20.10 VM.

I have a barometric pressure sensor (a stand-alone wifi device on a 
different IP from the Ubuntu VM) that sends data to weewx via MQTT and the 
MQTTSubscribe driver.
So, I need to get that to properly connect with mosquitto in Ubuntu 21.04, 
like it does in the Ubuntu 20.10.

The connection we saw when I tried running mosquitto with it's internal 
default settings was MQTTSubscribe trying to connect to it.

weewx@Ubuntu20-WEEWX:~$ mosquitto
1640984406: mosquitto version 2.0.10 starting
1640984406: Using default config.
1640984406: Starting in local only mode. Connections will only be possible 
from clients running on this machine.
1640984406: Create a configuration file which defines a listener to allow 
remote access.
1640984406: For more details see 
https://mosquitto.org/documentation/authentication-methods/
1640984406: Opening ipv4 listen socket on port 1883.
1640984406: Opening ipv6 listen socket on port 1883.
1640984406: mosquitto version 2.0.10 running
1640984413: New connection from 127.0.0.1:42095 on port 1883.

*1640984413: New client connected from 127.0.0.1:42095 
<http://127.0.0.1:42095/> as MQTTSubscribe-5503 (p2, c1, k60, 
u'None').1640984418: Client MQTTSubscribe-5503 disconnected.*
On Saturday, January 1, 2022 at 4:39:39 AM UTC-6 jon.bar...@gmail.com wrote:

> Eric,
>
> In one of your posts above, the mosquito broker says it has a connection 
> from a client...and given you're running this in a single VM, that must be 
> a client on that machine.
> Im struggling to understand why you would want a MQTT broker on the same 
> VM as weewx ...when it only needs the client.  as weewx doesnt respond to 
> mqtt messages/commands (someone will correct me if Im wrong) - maybe you 
> dont need mqtt at all ?
> I suggest you test wether the weewx client is working (publishing) by 
> using one of the public MQTT brokers such as test.moquito.org (and 
> monitor your messages via mqtt explorer.
> If you're running the broker in the same vm as weewx, then you must have 
> other mqtt devices (clients)...do they work ?
> I agree with Vince...and Im starting to lose the plot over what you're 
> trying to acheive
>
>
> On Friday, 31 December 2021 at 23:47:59 UTC vince wrote:
>
>> Work your mosquitto broker problem and that only.
>> Test with mosquitto_sub and mosquitto_pub and get that to work first.
>> Once that works, try to get weewx to subscribe.
>>
>> Try removing any previous garbage your earlier attempts might have put 
>> into /run.
>>
>> sudo rm -r /run/mosquitto
>> sudo systemctl start mosquitto
>>
>> On my ubuntu 21.10 vm permissions look like:
>>
>> root@ubuntu-focal:/run# ls -lagd /run/mosquitto
>> drwxr- 2 root 60 Dec 31 23:42 /run/mosquitto
>>
>> root@ubuntu-focal:/run# ls -lagd /run/mosquitto/*
>> -rw-r--r-- 1 mosquitto 4 Dec 31 23:42 /run/mosquitto/mosquitto.pid
>>
>> On Friday, December 31, 2021 at 2:36:19 PM UTC-8 Eric K wrote:
>>
>>> No, its not working.  
>>> Running the commands with sudo still failed to generate a pid file.
>>> Running with the default config allowed mosquitto to start and 
>>> MQTTSubscribe tried to connect but it disconnected after 5 seconds.
>>>
>>> When I started weewx and forced wee_reports to run, it bomed out with 
>>> many errors including MQTTSubscribe errors.
>>> I suspect because it couldn't connect to mosquitto.
>>>
>>> Since the mosquitto command changed from "port" to "listener", do I have 
>>> to change the MQTTSubscribe section of weewx.conf so it calls out "listener 
>>> = 1883" rather than "port = 1883"?
>>>
>>>
>>> On Friday, December 31, 2021 at 4:20:01 PM UTC-6 vince wrote:
>>>
>>>> So is it working ?  Not working ?
>>>> We can't read minds and your followups are rather cryptic.
>>>>
>>>> Is there any mosquitto process running ?
>>>> If so stop it and try again with 'sudo systemctl start mosquitto' 
>>>>
>>>> If you want to try to run mosquitto in the foreground to debug it, add 
>>>> the -v switch to make it verbose, and remember to use sudo
>>>>
>>>>

-- 
You received this message because you are subscribed 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/506b8110-5993-49a0-be2d-57e0f06db3e1n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

No, its not working.  
Running the commands with sudo still failed to generate a pid file.
Running with the default config allowed mosquitto to start and 
MQTTSubscribe tried to connect but it disconnected after 5 seconds.

When I started weewx and forced wee_reports to run, it bomed out with many 
errors including MQTTSubscribe errors.
I suspect because it couldn't connect to mosquitto.

Since the mosquitto command changed from "port" to "listener", do I have to 
change the MQTTSubscribe section of weewx.conf so it calls out "listener = 
1883" rather than "port = 1883"?


On Friday, December 31, 2021 at 4:20:01 PM UTC-6 vince wrote:

> So is it working ?  Not working ?
> We can't read minds and your followups are rather cryptic.
>
> Is there any mosquitto process running ?
> If so stop it and try again with 'sudo systemctl start mosquitto' 
>
> If you want to try to run mosquitto in the foreground to debug it, add the 
> -v switch to make it verbose, and remember to use sudo
>
>

-- 
You received this message because you are subscribed 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/3e0a6c71-7aa0-438b-9275-f7f498a67f92n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

* typing errror
allow_anymous true

*should have been
allow_anonymous true


On Friday, December 31, 2021 at 3:02:38 PM UTC-6 Eric K wrote:

> OK, I edited the /etc/mosquitto/mosquitto.conf so it is like your example:
> listener 1883
> allow_anymous true
>
> weewx@Ubuntu20-WEEWX:~$ sudo mosquitto -c /etc/mosquitto/mosquitto.conf
> 1640984047: Error: Unable to write pid file.
>
> weewx@Ubuntu20-WEEWX:~$ mosquitto -c /etc/mosquitto/mosquitto.conf
> 1640984054: Error: Unable to write pid file.
>
> weewx@Ubuntu20-WEEWX:~$ mosquitto
> 1640984406: mosquitto version 2.0.10 starting
> 1640984406: Using default config.
> 1640984406: Starting in local only mode. Connections will only be possible 
> from clients running on this machine.
> 1640984406: Create a configuration file which defines a listener to allow 
> remote access.
> 1640984406: For more details see 
> https://mosquitto.org/documentation/authentication-methods/
> 1640984406: Opening ipv4 listen socket on port 1883.
> 1640984406: Opening ipv6 listen socket on port 1883.
> 1640984406: mosquitto version 2.0.10 running
> 1640984413: New connection from 127.0.0.1:42095 on port 1883.
> 1640984413: New client connected from 127.0.0.1:42095 as 
> MQTTSubscribe-5503 (p2, c1, k60, u'None').
> 1640984418: Client MQTTSubscribe-5503 disconnected.
>
> On Friday, December 31, 2021 at 1:15:31 PM UTC-6 vince wrote:
>
>> On Friday, December 31, 2021 at 11:04:00 AM UTC-8 Eric K wrote:
>>
>>> This confirms that mosquitto 2.x requires passwords (where version 1.x 
>>> does not).
>>> see: https://mosquitto.org/documentation/migrating-to-2-0/
>>>
>>  
>> No, it doesn't.
>> The example I posted worked fine either way.
>>
>> I ran it successfully with allow_anonymous and no user specified.
>> I also ran it with allow_anonymous=false and a user created and specified.
>>
>>
>> The password requirement appears to be the change that breaks my working 
>>> mosquitto setup.
>>>
>>
>> Disagree.
>>  
>>
>>> In Ubuntu 21.04 with mosquitto 2.0.10 using my config file for mosquitto 
>>> 1.6.12:
>>>
>>> weewx@Ubuntu20-WEEWX:~$ mosquitto -c /etc/mosquitto/mosquitto.conf
>>> 1640977238: The 'port' option is now deprecated and will be removed in a 
>>> future version. Please use 'listener' instead.
>>> 1640977238: Error: Unable to write pid file.
>>>
>>>
>> Unable to write pid file is because you are running something requiring 
>> privileges as a unprivileged user 'weewx'.
>> Preface your command with "sudo".
>> You need mosquitto to start as root so it can bind to the privileged port 
>> 1883.
>>  
>>
>>> and using the default mosquitto config (not sure where it's finding that 
>>> default file - no path is shown)
>>>
>>>  
>> If you look at the mosquitto docs, it says it runs a default 
>> configuration in the absence of a specified config file.
>>
>> weewx@Ubuntu20-WEEWX:~$ mosquitto
>>> 1640976300: mosquitto version 2.0.10 starting
>>> 1640976300: Using default config.
>>> 1640976300: Starting in local only mode. Connections will only be 
>>> possible from clients running on this machine.
>>> 1640976300: Create a configuration file which defines a listener to 
>>> allow remote access.
>>>
>>
>> Yes - in this case you didn't specify a config file so it runs 
>> localhost-only for developer debugging purposes.
>> This is documented on their website.
>>
>> You want to read 
>> https://projects.eclipse.org/projects/iot.mosquitto/releases/2.0 more 
>> carefully.
>> It explains.
>>
>> And just go with the example I posted which definitely 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/d43c5c10-66d6-424f-8ada-5010a19742c9n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

OK, I edited the /etc/mosquitto/mosquitto.conf so it is like your example:
listener 1883
allow_anymous true

weewx@Ubuntu20-WEEWX:~$ sudo mosquitto -c /etc/mosquitto/mosquitto.conf
1640984047: Error: Unable to write pid file.

weewx@Ubuntu20-WEEWX:~$ mosquitto -c /etc/mosquitto/mosquitto.conf
1640984054: Error: Unable to write pid file.

weewx@Ubuntu20-WEEWX:~$ mosquitto
1640984406: mosquitto version 2.0.10 starting
1640984406: Using default config.
1640984406: Starting in local only mode. Connections will only be possible 
from clients running on this machine.
1640984406: Create a configuration file which defines a listener to allow 
remote access.
1640984406: For more details see 
https://mosquitto.org/documentation/authentication-methods/
1640984406: Opening ipv4 listen socket on port 1883.
1640984406: Opening ipv6 listen socket on port 1883.
1640984406: mosquitto version 2.0.10 running
1640984413: New connection from 127.0.0.1:42095 on port 1883.
1640984413: New client connected from 127.0.0.1:42095 as MQTTSubscribe-5503 
(p2, c1, k60, u'None').
1640984418: Client MQTTSubscribe-5503 disconnected.

On Friday, December 31, 2021 at 1:15:31 PM UTC-6 vince wrote:

> On Friday, December 31, 2021 at 11:04:00 AM UTC-8 Eric K wrote:
>
>> This confirms that mosquitto 2.x requires passwords (where version 1.x 
>> does not).
>> see: https://mosquitto.org/documentation/migrating-to-2-0/
>>
>  
> No, it doesn't.
> The example I posted worked fine either way.
>
> I ran it successfully with allow_anonymous and no user specified.
> I also ran it with allow_anonymous=false and a user created and specified.
>
>
> The password requirement appears to be the change that breaks my working 
>> mosquitto setup.
>>
>
> Disagree.
>  
>
>> In Ubuntu 21.04 with mosquitto 2.0.10 using my config file for mosquitto 
>> 1.6.12:
>>
>> weewx@Ubuntu20-WEEWX:~$ mosquitto -c /etc/mosquitto/mosquitto.conf
>> 1640977238: The 'port' option is now deprecated and will be removed in a 
>> future version. Please use 'listener' instead.
>> 1640977238: Error: Unable to write pid file.
>>
>>
> Unable to write pid file is because you are running something requiring 
> privileges as a unprivileged user 'weewx'.
> Preface your command with "sudo".
> You need mosquitto to start as root so it can bind to the privileged port 
> 1883.
>  
>
>> and using the default mosquitto config (not sure where it's finding that 
>> default file - no path is shown)
>>
>>  
> If you look at the mosquitto docs, it says it runs a default configuration 
> in the absence of a specified config file.
>
> weewx@Ubuntu20-WEEWX:~$ mosquitto
>> 1640976300: mosquitto version 2.0.10 starting
>> 1640976300: Using default config.
>> 1640976300: Starting in local only mode. Connections will only be 
>> possible from clients running on this machine.
>> 1640976300: Create a configuration file which defines a listener to allow 
>> remote access.
>>
>
> Yes - in this case you didn't specify a config file so it runs 
> localhost-only for developer debugging purposes.
> This is documented on their website.
>
> You want to read 
> https://projects.eclipse.org/projects/iot.mosquitto/releases/2.0 more 
> carefully.
> It explains.
>
> And just go with the example I posted which definitely 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/858c26fb-654a-4658-9599-176d5080ded2n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

I've currently got 2 Ubuntu setups I can switch back and forth between.
mosquitto works fine in Ubuntu 20.10, (works with no passwords).
mosquitto does not work after the Ubuntu 21.04 upgrade.

I just switched from 20.10 to 21.04 and can report.
Ubuntu 20.10 has mosquitto 1.6.12
Ubuntu 21.04 has mosquitto 2.0.10 

This confirms that mosquitto 2.x requires passwords (where version 1.x does 
not).
see: https://mosquitto.org/documentation/migrating-to-2-0/

The password requirement appears to be the change that breaks my working 
mosquitto setup.
They also changed the config file keyword from port to listener.
So "port 1883" becomes "listener 1883"

In Ubuntu 21.04 with mosquitto 2.0.10 using my config file for mosquitto 
1.6.12:

weewx@Ubuntu20-WEEWX:~$ mosquitto -c /etc/mosquitto/mosquitto.conf
1640977238: The 'port' option is now deprecated and will be removed in a 
future version. Please use 'listener' instead.
1640977238: Error: Unable to write pid file.

and using the default mosquitto config (not sure where it's finding that 
default file - no path is shown)

weewx@Ubuntu20-WEEWX:~$ mosquitto
1640976300: mosquitto version 2.0.10 starting
1640976300: Using default config.
1640976300: Starting in local only mode. Connections will only be possible 
from clients running on this machine.
1640976300: Create a configuration file which defines a listener to allow 
remote access.
1640976300: For more details see 
https://mosquitto.org/documentation/authentication-methods/
1640976300: Opening ipv4 listen socket on port 1883.
1640976300: Opening ipv6 listen socket on port 1883.
1640976300: mosquitto version 2.0.10 running



On Friday, December 31, 2021 at 12:09:55 PM UTC-6 vince wrote:

> If your mosquitto server won't start, run it in the foreground and it'll 
> tell you what line is wrong...
>
> mosquitto -c /etc/mosquitto/mosquitto.conf
>
> This is a minimalist /etc/mosquitto/conf.d/myconfig.conf file that works 
> on ubuntu
>
> #---
> ### this is an anonymous listener on the usual port
> #
> # listener 1883
> # allow_anonymous true
> #
> #---
> ### this is a simple username/password pair
> #
> # remember to make a password file entry for the user
> # mosquitto_passwd -c /etc/mosquitto/pwfile myuser
> # (and enter the mosquitto password for that user twice)
> #
> # to subscribe - remember to provide the user and pass you created
> # ala:
> #mosquitto_sub -t mytopic -h myaddress -u myuser -P mypass
> #
> listener 1883
> allow_anonymous false
> password_file /etc/mosquitto/pwfile
> #
> #---
>
>

-- 
You received this message because you are subscribed 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/5111e60c-767d-44e9-a3b9-3825b6cea5e1n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

I forgot to post this:
weewx@Ubuntu20-WEEWX:~$ python3 -c "import 
paho.mqtt.client;print(paho.mqtt.client.__file__)"
/usr/lib/python3/dist-packages/paho/mqtt/client.py

On Thursday, December 30, 2021 at 10:38:58 PM UTC-6 Eric K wrote:

> Simply reinstalling python3-paho-mqtt has not fixed the system.
>
> I tried the mosquitto_sub command and mosquitto refused the connection.
> weewx@Ubuntu20-WEEWX:~$ mosquitto_sub -h 192.168.7.22 -p 1883 -t 
> tele/BMP280/SENSOR -d
> Error: Connection refused
>
> I've got mosquitto.conf set to accpet anymous logins:
> protocol mqtt
> port 1883
> allow_anonymous true
>
> and I've got weewx.conf set for:
> [MQTTSubscribeService]
> enable = true
> host = localhost
> port = 1883
> keepalive = 60
> username = None
> password = None
>
> I tried to manually force mosquitto to start - NO-GO.
> I followed the instructions to get some debug info.
>
> weewx@Ubuntu20-WEEWX:~$ sudo systemctl start mosquitto
> Job for mosquitto.service failed because the control process exited with 
> error code.
> See "systemctl status mosquitto.service" and "journalctl -xe" for details.
>
> weewx@Ubuntu20-WEEWX:~$ systemctl status mosquitto.service
> ● mosquitto.service - Mosquitto MQTT Broker
>  Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; 
> vendor preset: enabled)
>  Active: failed (Result: exit-code) since Thu 2021-12-30 22:23:26 CST; 
> 3min 56s ago
>Docs: man:mosquitto.conf(5)
>  man:mosquitto(8)
> Process: 2797 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 2798 ExecStartPre=/bin/chown mosquitto: /var/log/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 2799 ExecStartPre=/bin/mkdir -m 740 -p /var/run/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 2800 ExecStartPre=/bin/chown mosquitto: /var/run/mosquitto 
> (code=exited, status=0/SUCCESS)
> Process: 2801 ExecStart=/usr/sbin/mosquitto -c 
> /etc/mosquitto/mosquitto.conf (code=exited, status=1/FAILURE)
>Main PID: 2801 (code=exited, status=1/FAILURE)
>
> I'm not sure how many of weewx's dependencies have to be reinstalled?
>
> On Wednesday, December 29, 2021 at 10:36:37 AM UTC-6 vince wrote:
>
>> On Tuesday, December 28, 2021 at 7:45:22 PM UTC-8 Eric K wrote:
>>
>>> After re-installing python3-paho-mqtt into Ubuntu 21.04 with "sudo 
>>> apt-get install python3-paho-mqtt"
>>> /usr/local/lib/python3.9/dist-packages/ is empty
>>> I'm not sure where the reinstalled python3-paho-mqtt files got installed?
>>> Back in /usr/local/lib/python3.8/dist-packages/ ?
>>>
>>
>> Does it really matter as long as it works ?
>>
>> As I mentioned earlier, if you use pip it goes under /usr/local/lib, but 
>> if you use apt then it goes under /usr/lib.
>>
>> But it doesn't really matter.  Just go with it.  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/5c5ed098-a6e5-4a49-97e6-c5dd55464686n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

Simply reinstalling python3-paho-mqtt has not fixed the system.

I tried the mosquitto_sub command and mosquitto refused the connection.
weewx@Ubuntu20-WEEWX:~$ mosquitto_sub -h 192.168.7.22 -p 1883 -t 
tele/BMP280/SENSOR -d
Error: Connection refused

I've got mosquitto.conf set to accpet anymous logins:
protocol mqtt
port 1883
allow_anonymous true

and I've got weewx.conf set for:
[MQTTSubscribeService]
enable = true
host = localhost
port = 1883
keepalive = 60
username = None
password = None

I tried to manually force mosquitto to start - NO-GO.
I followed the instructions to get some debug info.

weewx@Ubuntu20-WEEWX:~$ sudo systemctl start mosquitto
Job for mosquitto.service failed because the control process exited with 
error code.
See "systemctl status mosquitto.service" and "journalctl -xe" for details.

weewx@Ubuntu20-WEEWX:~$ systemctl status mosquitto.service
● mosquitto.service - Mosquitto MQTT Broker
 Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Thu 2021-12-30 22:23:26 CST; 
3min 56s ago
   Docs: man:mosquitto.conf(5)
 man:mosquitto(8)
Process: 2797 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto 
(code=exited, status=0/SUCCESS)
Process: 2798 ExecStartPre=/bin/chown mosquitto: /var/log/mosquitto 
(code=exited, status=0/SUCCESS)
Process: 2799 ExecStartPre=/bin/mkdir -m 740 -p /var/run/mosquitto 
(code=exited, status=0/SUCCESS)
Process: 2800 ExecStartPre=/bin/chown mosquitto: /var/run/mosquitto 
(code=exited, status=0/SUCCESS)
Process: 2801 ExecStart=/usr/sbin/mosquitto -c 
/etc/mosquitto/mosquitto.conf (code=exited, status=1/FAILURE)
   Main PID: 2801 (code=exited, status=1/FAILURE)

I'm not sure how many of weewx's dependencies have to be reinstalled?

On Wednesday, December 29, 2021 at 10:36:37 AM UTC-6 vince wrote:

> On Tuesday, December 28, 2021 at 7:45:22 PM UTC-8 Eric K wrote:
>
>> After re-installing python3-paho-mqtt into Ubuntu 21.04 with "sudo 
>> apt-get install python3-paho-mqtt"
>> /usr/local/lib/python3.9/dist-packages/ is empty
>> I'm not sure where the reinstalled python3-paho-mqtt files got installed?
>> Back in /usr/local/lib/python3.8/dist-packages/ ?
>>
>
> Does it really matter as long as it works ?
>
> As I mentioned earlier, if you use pip it goes under /usr/local/lib, but 
> if you use apt then it goes under /usr/lib.
>
> But it doesn't really matter.  Just go with it.  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/3ed31c0e-80ee-453d-9f5c-024c750df0c9n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

At this point, I'm keeping VM snapshots of both the working Ubuntu 20.10 
and the broken Ubuntu 21.04 so I can bounce back and forth between them.

Python 3.8 is the version in Ubuntu 20.10.
weewx@Ubuntu20-WEEWX:~$ python3 --version
Python 3.8.10

Python 3.9 is the version in Ubuntu 21.04.
weewx@Ubuntu20-WEEWX:~$ python3 --version
Python 3.9.5

After re-installing python3-paho-mqtt into Ubuntu 21.04 with "sudo apt-get 
install python3-paho-mqtt"
/usr/local/lib/python3.9/dist-packages/ is empty
I'm not sure where the reinstalled python3-paho-mqtt files got installed?
Back in /usr/local/lib/python3.8/dist-packages/ ?

The /var/log/syslog errors look like mosquitto isn't working or isn't 
allowing logins from MQTTSubscribe.

Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] DEBUG user.MQTTSubscribe: 
(Service) TopicManager self.cached_fields is {}
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) message_callback_provider_name is 
user.MQTTSubscribe.MessageCallbackProvider
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) clientid is MQTTSubscribe-4939
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) client_session is True
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) host is localhost
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) port is 1883
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) keepalive is 60
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) username is None
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) password is set
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] INFO user.MQTTSubscribe: 
(Service) Archive topic is None
Dec 28 21:19:41 Ubuntu20-WEEWX gnome-shell[1909]: Could not release device 
(13,69): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Dec 28 21:19:41 Ubuntu20-WEEWX wee_reports[3490] ERROR user.MQTTSubscribe: 
(Service) Failed to connect to localhost at 1883. '[Errno 111] Connection 
refused'
Dec 28 21:19:51 Ubuntu20-WEEWX weewx[3489] CRITICAL __main__: Caught 
WeeWxIOError: [Errno 111] Connection refused
Dec 28 21:19:51 Ubuntu20-WEEWX weewx[3489] CRITICAL __main__:  
 Waiting 60 seconds then retrying...
Dec 28 21:19:56 Ubuntu20-WEEWX ntpd[1137]: 38.229.62.9 local addr 
192.168.7.22 -> 
Dec 28 21:20:01 Ubuntu20-WEEWX CRON[3518]: (weewx) CMD (sh 
/home/weewx/webcamgrab.sh)
Dec 28 21:20:03 Ubuntu20-WEEWX CRON[3517]: (CRON) info (No MTA installed, 
discarding output)
On Tuesday, December 28, 2021 at 8:00:32 PM UTC-6 vince wrote:

> You're probably overthinking this one, but I'd suggest you avoid using pip 
> or pip3 unless absolutely necessary.   My recollection is that modern 
> ubuntu/debian/raspbian have everything you need available in packages 
> nowadays.  Using pip should be pretty rarely needed.
>
> apt-get install python3-paho-mqtt
>
> A clean ubuntu 2004 installs it to /usr/lib/python3/dist-packages if you 
> use apt, so you 'likely' used pip3 originally.
>
> FWIW - if you install with apt and do a dist-upgrade, it doesn't delete 
> anything that I can tell.   My paho stuff was still there.
>
> But you're overthinking this one for sure.  Just add the package it wants,
>
>

-- 
You received this message because you are subscribed 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/be27f515-4748-4502-b6e2-9771205882d6n%40googlegroups.com.

Re: [weewx-user] error after update

[Eric K]

I've had weewx 4.5.1 running fine in a Ubuntu 20.10 virtual machine, with 
mqtt-subscribe and the usr.sdr driver for about 9 months.

I just tried to update my Ubuntu virtual machine from 20.10 to 21.04.
(I took a snapshot of the VM before I updated, so I could revert back to a 
working system.)
Upon restart, weewx bomed out with errors.

Does it look like the same as above - missing python3-paho-mqtt package?
Maybe the Ubuntu update removed the python3-paho-mqtt package?
Are the errors with config_dict related or a different broken package?

Pointers appreciated.
Eric
On Saturday, November 13, 2021 at 3:42:45 PM UTC-6 stephen...@gmail.com 
wrote:

> You're missing a paho package for python, and need to install it. if you 
> installation is using python3, "sudo apt-get install python3-paho-mqtt" 
> should do the trick.
>
> On Sun, 14 Nov 2021 at 05:17, miso k  wrote:
>
>> Hello together,
>> I have installed latest OS to my raspberry - Bullseye.
>> during the WeeWX start I get this message:
>>
>> Nov 13 19:14:46 WeeWX weewx[2941] INFO user.interceptor: shutting down 
>> server thread
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__: Caught unrecoverable 
>> exception:
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   No module 
>> named 'paho'
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   Traceback 
>> (most recent call last):
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__: File 
>> "/usr/share/weewx/weewxd", line 151, in main
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   engine 
>> = weewx.engine.StdEngine(config_dict)
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/engine.py", line 93, in __init__
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   
>> self.loadServices(config_dict)
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   obj = 
>> weeutil.weeutil.get_object(svc)(self, config_dict)
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__: File 
>> "/usr/share/weewx/weeutil/weeutil.py", line 1093, in get_object
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   mod = 
>> __import__(module)
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__: File 
>> "/usr/share/weewx/user/MQTTSubscribe.py", line 300, in 
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   import 
>> paho.mqtt.client as mqtt
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   
>> ModuleNotFoundError: No module named 'paho'
>> Nov 13 19:14:47 WeeWX weewx[2941] CRITICAL __main__:   Exiting.
>>
>> what is wrong? do I need to change something?
>>
>> thanks
>> Michal
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/29ced556-10b5-431a-a3b5-37641afb9a6cn%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
>
>   "I and the public know
>   what all schoolchildren learn
>   Those to whom evil is done
>   Do evil in return"  W.H. Auden, "September 1, 1939"
>
>
>

-- 
You received this message because you are subscribed 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/d1b3b8be-ee7c-4264-88da-25f7e9a296c6n%40googlegroups.com.

Re: [weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

I'm rolled back into my working snapshot of Ubuntu 20.10.
Python3 is/was installed and running.
I did a locate to see where the files are, so I can look for them after 
another upgrade attempt:
weewx@Ubuntu20-WEEWX:~$ locate paho
/usr/local/lib/python3.8/dist-packages/paho
/usr/local/lib/python3.8/dist-packages/paho_mqtt-1.5.1.dist-info
/usr/local/lib/python3.8/dist-packages/paho/__init__.py
/usr/local/lib/python3.8/dist-packages/paho/__pycache__
/usr/local/lib/python3.8/dist-packages/paho/mqtt
/usr/local/lib/python3.8/dist-packages/paho/__pycache__/__init__.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__init__.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__
/usr/local/lib/python3.8/dist-packages/paho/mqtt/client.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/matcher.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/packettypes.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/properties.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/publish.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/reasoncodes.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/subscribe.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/subscribeoptions.py
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/__init__.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/client.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/matcher.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/packettypes.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/properties.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/publish.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/reasoncodes.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/subscribe.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho/mqtt/__pycache__/subscribeoptions.cpython-38.pyc
/usr/local/lib/python3.8/dist-packages/paho_mqtt-1.5.1.dist-info/INSTALLER
/usr/local/lib/python3.8/dist-packages/paho_mqtt-1.5.1.dist-info/LICENSE.txt
/usr/local/lib/python3.8/dist-packages/paho_mqtt-1.5.1.dist-info/METADATA
/usr/local/lib/python3.8/dist-packages/paho_mqtt-1.5.1.dist-info/RECORD
/usr/local/lib/python3.8/dist-packages/paho_mqtt-1.5.1.dist-info/WHEEL
/usr/local/lib/python3.8/dist-packages/paho_mqtt-1.5.1.dist-info/top_level.txt
On Tuesday, December 28, 2021 at 5:38:19 PM UTC-6 tke...@gmail.com wrote:

> I very much doubt the update deleted anything. More likely, the default 
> version of Python changed from 2 to 3. Were you using Python 2 before?
>
> In any case, the fix is pretty easy: just install paho for whatever 
> version of Python you are using.
>
> On Tue, Dec 28, 2021 at 3:31 PM Eric K  wrote:
>
>> I saw this thread and the symptoms are VERY similar if not the same:
>> https://groups.google.com/g/weewx-user/c/LS5QyRlJNU4/m/UtBjwkssAgAJ
>>
>> I've had a working weewx 4.5.1 system running inside Ubuntu 20.10 virtual 
>> machine for about 9 months.  I'm running the user.sdr driver and 
>> MQTTsubscribe.
>>
>> I just tried to update from Ubuntu 20.10 to Ubuntu 21.04 and upon restart 
>> weewx generated errors.
>> (I made a snapshot of the virtual machine before the upgrade so I just 
>> rolled back after I saw the errors.)
>> [image: errors after Ubuntu 21.04 update.JPG]
>> Does it look like the Ubuntu update removed the paho.mqtt.client software 
>> that I installed as a dependency for MQTTsubscribe?
>>
>> Thanks for any pointers.
>> Eric
>>
>> -- 
>> You received this message because you are subscribed 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/e519bcc3-9b08-409a-83ea-389981d58446n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/e519bcc3-9b08-409a-83ea-389981d58446n%40googlegroups.com?utm_medium=email_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/e5370695-16af-4cb9-b47a-21a0259db6d8n%40googlegroups.com.

[weewx-user] working weewx 4.5.1 - errors after Ubuntu OS update

[Eric K]

I saw this thread and the symptoms are VERY similar if not the same:
https://groups.google.com/g/weewx-user/c/LS5QyRlJNU4/m/UtBjwkssAgAJ

I've had a working weewx 4.5.1 system running inside Ubuntu 20.10 virtual 
machine for about 9 months.  I'm running the user.sdr driver and 
MQTTsubscribe.

I just tried to update from Ubuntu 20.10 to Ubuntu 21.04 and upon restart 
weewx generated errors.
(I made a snapshot of the virtual machine before the upgrade so I just 
rolled back after I saw the errors.)
[image: errors after Ubuntu 21.04 update.JPG]
Does it look like the Ubuntu update removed the paho.mqtt.client software 
that I installed as a dependency for MQTTsubscribe?

Thanks for any pointers.
Eric

-- 
You received this message because you are subscribed 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/e519bcc3-9b08-409a-83ea-389981d58446n%40googlegroups.com.

Re: [weewx-user] Re: recommend IP cameras that are easy to grab a single frame from?

[Eric K]

I just tried making a symlink to the /tmp/ramdisk directory, inside the 
public_html directory, and that worked.

pi@pi3:/home/weewx $ ln -s /tmp/ramdisk /home/weewx/public_html/ramdisk

NOW the web server is able to pull the image from the ramdisk.








On Tuesday, August 10, 2021 at 5:57:47 PM UTC-5 Eric K wrote:

> I changed my scripts to put the pictures into a ramdisk.
> But, the web server can't find them in the ramdisk.
>
> First I tried this - web server didn't find it:
> 
> 
>  width="640" height="480">
> 
> 
> 
>
> I searched for some guidence and then tried this - web server didn't find 
> it:
> 
> 
>  width="640" height="480">
> 
> 
> 
>
> How are others accessing a ramdisk for webserver photos?
>
>
>
> On Tuesday, August 10, 2021 at 3:58:50 PM UTC-5 Eric K wrote:
>
>> I like the idea of writing to the RAM disk, to avoid multiple rewrites 
>> the micro SD card.
>> I didn't know it was an option.
>>
>> This is all there is to it?  
>> https://www.linuxbabe.com/command-line/create-ramdisk-linux
>> Looks easy!
>> On Tuesday, August 10, 2021 at 3:47:36 PM UTC-5 vince wrote:
>>
>>> I use a cheapo USB cam on a pi and save a still periodically using 
>>> 'motion' as the software on the pi.  I write the file to ramdisk to avoid 
>>> the SD card file write issue and grab the still via cron from my weewx 
>>> 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/90c3ad6d-71d7-4649-bd24-95fa4465074cn%40googlegroups.com.

Re: [weewx-user] Re: recommend IP cameras that are easy to grab a single frame from?

[Eric K]

I changed my scripts to put the pictures into a ramdisk.
But, the web server can't find them in the ramdisk.

First I tried this - web server didn't find it:







I searched for some guidence and then tried this - web server didn't find 
it:







How are others accessing a ramdisk for webserver photos?



On Tuesday, August 10, 2021 at 3:58:50 PM UTC-5 Eric K wrote:

> I like the idea of writing to the RAM disk, to avoid multiple rewrites the 
> micro SD card.
> I didn't know it was an option.
>
> This is all there is to it?  
> https://www.linuxbabe.com/command-line/create-ramdisk-linux
> Looks easy!
> On Tuesday, August 10, 2021 at 3:47:36 PM UTC-5 vince wrote:
>
>> I use a cheapo USB cam on a pi and save a still periodically using 
>> 'motion' as the software on the pi.  I write the file to ramdisk to avoid 
>> the SD card file write issue and grab the still via cron from my weewx 
>> 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/056f9c8b-bdb5-4a40-b3e3-a4186df96e75n%40googlegroups.com.

Re: [weewx-user] Re: recommend IP cameras that are easy to grab a single frame from?

[Eric K]

I like the idea of writing to the RAM disk, to avoid multiple rewrites the 
micro SD card.
I didn't know it was an option.

This is all there is to it?  
https://www.linuxbabe.com/command-line/create-ramdisk-linux
Looks easy!
On Tuesday, August 10, 2021 at 3:47:36 PM UTC-5 vince wrote:

> I use a cheapo USB cam on a pi and save a still periodically using 
> 'motion' as the software on the pi.  I write the file to ramdisk to avoid 
> the SD card file write issue and grab the still via cron from my weewx 
> 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/8508ec63-f3a8-4cd4-ab61-74cefcbdf96cn%40googlegroups.com.

[weewx-user] Re: recommend IP cameras that are easy to grab a single frame from?

[Eric K]

I also want to check out your perl scripts, @mwall!

On Saturday, August 7, 2021 at 5:18:33 PM UTC-5 Eric K wrote:

> Thanks for all the responses.
>
> Shortly after posting this I got a couple of the ESP32-CAM modules and 
> loaded Tasmota firmware into them.
> see:  https://cgomesu.com/blog/Esp32cam-tasmota-webcam-server/
> You have to use the specific Tasmota32 webcam firmware:   
> tasmota32-webcam.bin 
> <http://ota.tasmota.com/tasmota32/release/tasmota32-webcam.bin>
> The maximum resolution of these is only 1600x1200.  
> The upside is that you can easily grab a single frame using a simple URL 
> command:  http://192.168.8.122/snapshot.jpg
> The only downsides I see:  with the plastic lens and jpeg compression, the 
> images are not great for fine detail.
>
> Given the low cost, small size, MIPI camera interface, and wifi capability 
> of the RPi Zero W board, I reconsidered an RPi camera.
> I'm currently assembling a RPi Zero camera with a 5mp camera module.
> I am getting single images out of it with the raspistill application:
> raspistill -v -o /home/pi/Pictures/pi-cam-test.jpg
>
> I'd like to grab an image every 5-10 minutes and have the current image 
> show up in the Belchertown weewx page.
> I'd also like to create a daily time lapse movie like others have done.
> I recall seeing some webcam script examples in this weewx-user group to do 
> these 2 things.  
> I need to search for them again.
> On Sunday, July 4, 2021 at 4:29:31 PM UTC-5 mwall wrote:
>
>> sorry, here is the link to the root level of the ispy database:
>>
>> https://www.ispyconnect.com/cameras
>>
>>

-- 
You received this message because you are subscribed 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/93517f60-6693-45b9-a502-24c8432699a0n%40googlegroups.com.

Re: [weewx-user] recommend IP cameras that are easy to grab a single frame from?

[Eric K]

Long ago I played with a dlink camera and as was able to figure out a
URL that would get a single frame. 

Me too!  I had a Dlink DCS-900 and I could get a single camera image from 
the URL line.
But, I bricked it trying to update its firmware.  
Oh well, it was early-2000s vintage and had a pretty crappy image sensor, 
compared to what's on the market today.
I'm looking for a modern, functional replacement for it.

I would not be surprised if you can find into for your camera on the web
someplace.

The camera with rtsp streaming that I was playing with can only deliver an 
rtsp stream via it's Ethernet port (no wifi).  
I know because it is made by the company I work in.  
I asked some of our software people about grabbing a single image for a 
webpage, and they said, nope, only rtsp via the Ethernet port.
It's primary function is to create full motion video for video 
conferencing, so delivering still frames for webpages was not on the 
required features list.

Eric

On Friday, July 2, 2021 at 5:52:03 PM UTC-5 Greg Troxel wrote:

>
> Eric K  writes:
>
> > Based on first hand experience, can people recommend various IP cameras 
> > (ideally an Ethernet or wifi camera) with a focus towards ease of 
> grabbing 
> > a single frame from a Linux command line?
> > I'd like to be able to grab single frames to use in the weewx webpage.
> >
> > I've tested am Ethernet-connected camera that puts out an rtsp stream. I 
> > successfully used an ffmpeg command line to start the stream, wait 10 
> > seconds and then grab a frame. Sometimes 10 seconds isn't enough and I 
> > have to try 12-15 seconds.
> > *ffmpeg -loglevel info -rtsp_transport tcp -i 
> > "rtsp://192.168.7.51/rtsp-stream" -ss 00:00:10 -r 1 -vframes 1 -y 
> > /home/weewx/Pictures/image.jpg*
> > It works, but I don't think rtsp is the ideal transport method for 
> grabbing 
> > a single frame, because you have to wait about 10+ seconds for the 
> stream 
> > to fully form a valid image.
>
> Long ago I played with a dlink camera and as was able to figure out a
> URL that would get a single frame. You might log into the https
> interface and look at the html on the live view page. Also check out
> the zoneminder wikis and similar for the access methods.
>
> I would not be surprised if you can find into for your camera on the web
> someplace.
>

-- 
You received this message because you are subscribed 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/ac736172-abb5-4281-b653-ffcaaba4ef85n%40googlegroups.com.

[weewx-user] recommend IP cameras that are easy to grab a single frame from?

[Eric K]

Based on first hand experience, can people recommend various IP cameras 
(ideally an Ethernet or wifi camera) with a focus towards ease of grabbing 
a single frame from a Linux command line?
I'd like to be able to grab single frames to use in the weewx webpage.

I don't want an RaspberryPi camera because I'd like multiple cameras and I 
don't want to be tethered to a RaspberryPi via a short ribbon cable.

I've tested am Ethernet-connected camera that puts out an rtsp stream.  I 
successfully used an ffmpeg command line to start the stream, wait 10 
seconds and then grab a frame.  Sometimes 10 seconds isn't enough and I 
have to try 12-15 seconds.
*ffmpeg -loglevel info -rtsp_transport tcp -i 
"rtsp://192.168.7.51/rtsp-stream" -ss 00:00:10 -r 1 -vframes 1 -y 
/home/weewx/Pictures/image.jpg*
It works, but I don't think rtsp is the ideal transport method for grabbing 
a single frame, because you have to wait about 10+ seconds for the stream 
to fully form a valid image.

I wonder if anyone has tried the ESP32-CAMs?  They get connected to an 
ESP6288 wifi module, and are thus small and wireless.
https://www.amazon.com/ESP32-CAM-Bluetooth-Camera-Module-Development/dp/B07S5PVZKV

-- 
You received this message because you are subscribed 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/058f20b9-782e-408a-bca4-fdd8ca1d2d60n%40googlegroups.com.

Re: [weewx-user] Re: lightning sensor made at home cheaply - WORKS!

[Eric K]

There we go!  
Now, I have proof its counting higher than 1!  :)


[image: AS3935 Lightning sensor working.PNG]

Here's my graph config from the Belchertown graphs.conf file:

*[[chart3]]*
*title = Lightning*
*[[[lightning_strike_count]]]*
*yAxis = 0*
*yAxis_label = "Number of Strikes"*
*stacking = normal*
*color = "orange"*
*lineWidth = 0*
*marker*
*enabled = true*
*radius = 4*
*states*
*[hover]*
*lineWidthPlus = 0*
*[[[lightning_distance]]]*
*yAxis = 1*
*yAxis_label = "Distance (miles)"*

*stacking = normal*
*color = "blue"*
*lineWidth = 0*
*marker*
*enabled = true*
*radius = 3*
*states*
*[hover]*
*lineWidthPlus = 0*

These are my settings in the Tasmota firmware for the AS3935:
17:48:03.739 CMD: AS3935settings
*17:48:03.753 MQT: tele/AS3935/RESULT = 
{"AS3935_Settings":{"Gain":"Indoors","NFfloor":7,"uVrms":146,"Tunecaps":2,"MinNumLight":1,"Rejection":2,"Wdthreshold":2,"MinNFstage":0,"NFAutoTime":4,"DisturberAutoTime":1,"Disturber":"On","NFauto":"Off","Disturberauto":"Off","NFautomax":"On","Mqttlightevent":"On","Mqttnoirqevent":"On"}}*
The last 2 surpress MQTT messages when there's no lightning events.
Reference:  https://tasmota.github.io/docs/AS3935/

There have been a LOT of close strikes detected in the last 15 mintues!
This is from the Tasmota console of the ESP-12F module (with AS3935 sensor 
connected):
17:58:07.173 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T17:58:07","AS3935":{"Event":4,"Distance":1,"Energy":372650,"Stage":7}}
17:58:34.168 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T17:58:34","AS3935":{"Event":4,"Distance":1,"Energy":155946,"Stage":7}}
17:59:36.153 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T17:59:36","AS3935":{"Event":4,"Distance":1,"Energy":0,"Stage":7}}
18:00:02.150 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:00:02","AS3935":{"Event":4,"Distance":1,"Energy":77455,"Stage":7}}
18:00:14.167 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:00:14","AS3935":{"Event":4,"Distance":1,"Energy":14477,"Stage":7}}
18:01:34.195 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:01:34","AS3935":{"Event":4,"Distance":1,"Energy":16,"Stage":7}}
18:01:54.162 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:01:54","AS3935":{"Event":4,"Distance":1,"Energy":42975,"Stage":7}}
18:02:33.154 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:02:33","AS3935":{"Event":4,"Distance":1,"Energy":55903,"Stage":7}}
18:04:02.170 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:04:02","AS3935":{"Event":4,"Distance":1,"Energy":59064,"Stage":7}}
18:04:26.163 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:04:26","AS3935":{"Event":4,"Distance":1,"Energy":0,"Stage":7}}
18:04:45.170 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:04:45","AS3935":{"Event":4,"Distance":1,"Energy":25788,"Stage":7}}
18:05:12.146 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:05:12","AS3935":{"Event":4,"Distance":1,"Energy":22788,"Stage":7}}
18:05:50.188 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:05:50","AS3935":{"Event":4,"Distance":1,"Energy":17632,"Stage":7}}
18:07:22.161 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:07:22","AS3935":{"Event":4,"Distance":1,"Energy":51215,"Stage":7}}
18:08:29.185 MQT: tele/AS3935/SENSOR = 
{"Time":"2021-06-28T18:08:29","AS3935":{"Event":4,"Distance":1,"Energy":62226

[weewx-user] Re: lightning sensor made at home cheaply

[Eric K]

Reference:  https://github.com/weewx/weewx/wiki/Accumulators

1. It says that lightning_strike_count is one of the default accumulator 
variables, so I believe that means I do NOT need to declare it in an 
[Accumulators] section of weewx.conf?

2. Where do I put the code that alerts WeeWX that a lightning strike 
occurred?
In the [MQTTSubscribeService] section of the weewx.conf file?

3. How do I tell WeeWX that a lightning strike has occurred?
Set lightning_strike_count =1 and let the accumulator function add 1 to the 
total for me?

Like this?

[MQTTSubscribeService]
[[[tele/AS3935/SENSOR]]]
Time
ignore = true

AS3935_Event
# Use the default variable name from MQTT
# MQTT messages with and event value in the following will 
be ignored.
filter_out_message_when = 0, 2, 3, 4, 5, 6, 7, 8, 9
conversion_type = int
*lightning_strike_count = 1*

AS3935_Distance
# Use the default variable name from MQTT.

AS3935_Energy
name = lightning_energy

AS3935_Stage
ignore = true
On Friday, June 25, 2021 at 8:15:48 PM UTC-5 Eric K wrote:

> I've made some progress and I have MQTT messages getting received into 
> MQTTSubscribe and put into the weewx database file!
>
> Here's the relevant section from the MQTTSubscribe section of weewx.conf:
>
> *[MQTTSubscribeService]*
>
> *enable = true*
>
> *host = localhost*
>
> *port = 1883*
>
> *keepalive = 60*
>
> *username = None*
>
> *password = None*
>
> *binding = loop*
>
> *[[message_callback]]*
>
> *type = json*
>
> *[[[tele/AS3935/SENSOR]]]*
> *Time*
> *ignore = true*
>
> *AS3935_Event*
> *# Use the default variable name from MQTT*
> *# MQTT messages with and event value in the following 
> will be ignored.*
> *filter_out_message_when = 0, 2, 3, 4, 5, 6, 7, 8, 9*
> *conversion_type = int*
>
> *AS3935_Distance*
> *# Use the default variable name from MQTT.*
>
> *AS3935_Energy*
> *name = lightning_energy*
>
> *AS3935_Stage*
> *ignore = true*
>
> Here are a few lines from the /var/log/syslog showing the AS3935 messages 
> coming in and getting conditionally ignored.
> So, we know that part is working.
>
>
> *Jun 25 19:50:46 pi3 weewx[31711] DEBUG user.MQTTSubscribe: (Service) 
> MessageCallbackProvider data-> incoming topic: tele/AS3935/SENSOR, QOS: 0, 
> retain: 0, payload: 
> b'{"Time":"2021-06-25T19:50:46","AS3935":{"Event":0,"Distance":0,"Energy":0,"Stage":7}}'*
> *Jun 25 19:50:46 pi3 weewx[31711] INFO user.MQTTSubscribe: (Service) 
> MessageCallbackProvider on_message_json filtered out tele/AS3935/SENSOR : 
> b'{"Time":"2021-06-25T19:50:46","AS3935":{"Event":0,"Distance":0,"Energy":0,"Stage":7}}'
>  
> with AS3935_Event=[0, 2, 3, 4, 5, 6, 7, 8, 9]*
>
> Then, in the Corrections section of weewx.conf, I am using a conditional 
> statement to assign the AS3935 distance data to the weewx stock variable 
> lightning_distance.
> I wasn't sure if my syntax was correct, but lightning distance data is 
> appearing in the weewx database, so it appears to be working.
>
> *[StdCalibrate]*
>
> *[[Corrections]]*
>
> *outTemp = outTemp - 1.5*
> *barometer = barometer + 1.23*
> *lightning_distance = AS3935_Distance if AS3935_Event == 1 else 
> None*
>
> Finally, I looked in the weewx.sdb database file and saw 3 lightning 
> events listed in the variables lightning_distance and lightning_energy!
> See attached.
>
> I don't have the lightning_strike_count getting accumulated, yethave 
> to try and figure out which of the accumulator type to use.
>
> Progress.
>
>
>
>
>
>
>
>
> On Wednesday, June 16, 2021 at 1:37:57 PM UTC-5 Eric K wrote:
>
>> Very cool, Rich!
>> I'll put some effort into it.
>>
>> Based on your earlier coaching, I've been able to successfully accept 
>> MQTT data from every sensor I've tried, including from a Sonoff Zigbee 
>> Bridge with a bunch of Sonoff SNZB-02 temperature sensors!
>>
>> [[[tele/ZBBridge/SENSOR]]]
>> # 0x4472 is #10 Living Room
>> ZbReceived_0x4472_

[weewx-user] Re: lightning sensor made at home cheaply

[Eric K]

I've made some progress and I have MQTT messages getting received into 
MQTTSubscribe and put into the weewx database file!

Here's the relevant section from the MQTTSubscribe section of weewx.conf:

*[MQTTSubscribeService]*

*enable = true*

*host = localhost*

*port = 1883*

*keepalive = 60*

*username = None*

*password = None*

*binding = loop*

*[[message_callback]]*

*type = json*

*[[[tele/AS3935/SENSOR]]]*
*Time*
*ignore = true*

*AS3935_Event*
*# Use the default variable name from MQTT*
*# MQTT messages with and event value in the following will 
be ignored.*
*filter_out_message_when = 0, 2, 3, 4, 5, 6, 7, 8, 9*
*conversion_type = int*

*AS3935_Distance*
*# Use the default variable name from MQTT.*

*AS3935_Energy*
*name = lightning_energy*

*AS3935_Stage*
*ignore = true*

Here are a few lines from the /var/log/syslog showing the AS3935 messages 
coming in and getting conditionally ignored.
So, we know that part is working.


*Jun 25 19:50:46 pi3 weewx[31711] DEBUG user.MQTTSubscribe: (Service) 
MessageCallbackProvider data-> incoming topic: tele/AS3935/SENSOR, QOS: 0, 
retain: 0, payload: 
b'{"Time":"2021-06-25T19:50:46","AS3935":{"Event":0,"Distance":0,"Energy":0,"Stage":7}}'*
*Jun 25 19:50:46 pi3 weewx[31711] INFO user.MQTTSubscribe: (Service) 
MessageCallbackProvider on_message_json filtered out tele/AS3935/SENSOR : 
b'{"Time":"2021-06-25T19:50:46","AS3935":{"Event":0,"Distance":0,"Energy":0,"Stage":7}}'
 
with AS3935_Event=[0, 2, 3, 4, 5, 6, 7, 8, 9]*

Then, in the Corrections section of weewx.conf, I am using a conditional 
statement to assign the AS3935 distance data to the weewx stock variable 
lightning_distance.
I wasn't sure if my syntax was correct, but lightning distance data is 
appearing in the weewx database, so it appears to be working.

*[StdCalibrate]*

*[[Corrections]]*

*outTemp = outTemp - 1.5*
*barometer = barometer + 1.23*
*lightning_distance = AS3935_Distance if AS3935_Event == 1 else 
None*

Finally, I looked in the weewx.sdb database file and saw 3 lightning events 
listed in the variables lightning_distance and lightning_energy!
See attached.

I don't have the lightning_strike_count getting accumulated, yet....have to 
try and figure out which of the accumulator type to use.

Progress.








On Wednesday, June 16, 2021 at 1:37:57 PM UTC-5 Eric K wrote:

> Very cool, Rich!
> I'll put some effort into it.
>
> Based on your earlier coaching, I've been able to successfully accept MQTT 
> data from every sensor I've tried, including from a Sonoff Zigbee Bridge 
> with a bunch of Sonoff SNZB-02 temperature sensors!
>
> [[[tele/ZBBridge/SENSOR]]]
> # 0x4472 is #10 Living Room
> ZbReceived_0x4472_Device
> ignore = true
>
> ZbReceived_0x4472_Name
> ignore = true
>
> ZbReceived_0x4472_Temperature
> # The WeeWX name.
> # Default is the name from MQTT.
> name = inTemp
>
> ZbReceived_0x4472_Humidity
> # The WeeWX name.
> # Default is the name from MQTT.
> name = inHumidity
>
> ZbReceived_0x4472_BatteryVoltage
> ignore = true
>
> ZbReceived_0x4472_BatteryPercentage
> ignore = true
>
> ZbReceived_0x4472_Endpoint
> ignore = true
>
> ZbRecieved_0x4472_LinkQuality
> ignore = true
>
>
> On Wednesday, June 16, 2021 at 1:00:18 PM UTC-5 bell...@gmail.com wrote:
>
>> Eric,
>> For (2), MQTTSubscribe has a 'filter_out_message_when' option. So, you 
>> would to do something like this in the MQTTSubscribe section
>> [[topics]]
>>   [[[tele/AS3935/SENSOR]]]
>> AS3935_Event
>>   ignore = True
>>   # MQTT messages with and event value in the following will be ignored.
>>   filter_out_message_when = 0, 2, 3, 4, 5, 6, 7, 8, 9
>>   conversion_type = int
>>   .
>>   .
>>   .
>>   
>> A bit more detail on this option can be found here, 
>> https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring-additional-options#filter_out_message_when
>> There is some background information here, 
>> https://github.com/bellrichm/WeeWX-MQTTSubscribe/discussions/112

[weewx-user] Re: lightning sensor made at home cheaply

[Eric K]

Very cool, Rich!
I'll put some effort into it.

Based on your earlier coaching, I've been able to successfully accept MQTT 
data from every sensor I've tried, including from a Sonoff Zigbee Bridge 
with a bunch of Sonoff SNZB-02 temperature sensors!

[[[tele/ZBBridge/SENSOR]]]
# 0x4472 is #10 Living Room
ZbReceived_0x4472_Device
ignore = true

ZbReceived_0x4472_Name
ignore = true

ZbReceived_0x4472_Temperature
# The WeeWX name.
# Default is the name from MQTT.
name = inTemp

ZbReceived_0x4472_Humidity
# The WeeWX name.
# Default is the name from MQTT.
name = inHumidity

ZbReceived_0x4472_BatteryVoltage
ignore = true

ZbReceived_0x4472_BatteryPercentage
ignore = true

ZbReceived_0x4472_Endpoint
ignore = true

ZbRecieved_0x4472_LinkQuality
ignore = true


On Wednesday, June 16, 2021 at 1:00:18 PM UTC-5 bell...@gmail.com wrote:

> Eric,
> For (2), MQTTSubscribe has a 'filter_out_message_when' option. So, you 
> would to do something like this in the MQTTSubscribe section
> [[topics]]
>   [[[tele/AS3935/SENSOR]]]
> AS3935_Event
>   ignore = True
>   # MQTT messages with and event value in the following will be ignored.
>   filter_out_message_when = 0, 2, 3, 4, 5, 6, 7, 8, 9
>   conversion_type = int
>   .
>   .
>   .
>   
> A bit more detail on this option can be found here, 
> https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring-additional-options#filter_out_message_when
> There is some background information here, 
> https://github.com/bellrichm/WeeWX-MQTTSubscribe/discussions/112
>
> For (3), read up on WeeWX accumulators here, 
> https://github.com/weewx/weewx/wiki/Accumulators
>
> If you get this working, this is exactly the type of MQTTSubscribe 
> configuration that I would like to capture as an example to help others in 
> the future.
> - Rich
>
>
> On Tuesday, 15 June 2021 at 19:35:19 UTC-4 Eric K wrote:
>
>> I just assembled this exact setup - AS3935 board with a Wemos D1 mini 
>> clone and Tasmota 9.4.0 sensor firmware.
>> I didn't snap a picture before I deployed it, but it looks very much like 
>> the attached photo.
>> I followed this page: https://tasmota.github.io/docs/AS3935/
>>
>> Its working and I'm getting live data in the Tasmota web interface.
>> I named it AS3935 in the Tasmota MQTT setup and it's sending telemetry to 
>> my mosquitto MQTT broker.
>> The MQTT transmissions (seen from the Tasmota console) look like the 
>> example on the tasmota.github AS3935 page:
>> 18:07:21.164 MQT: tele/AS3935/SENSOR = 
>> {"Time":"2021-06-15T18:07:21","AS3935":{"Event":0,"Distance":0,"Energy":0,"Stage":7}}
>>
>> I think I need to:
>> 1. set the Tasmota setting AS3935lightevent to 1 so it only sends MQTT 
>> messages when there is a lightning strike registered.
>> 2. set up weewx to read the MQTT Event variable so I only react to a 
>> valid lightning strike with distance (event 1)
>> 3. Set up the lightning_count variable as an accumulator?
>>
>> I'm not quite sure:
>> 1. how often I should set Tasmota's MQTT report period so I don't miss 
>> counting a lightning strike?  Once per second?
>> 2. how to set up a conditional statement in the MQTTSubscribe section of 
>> weewx.conf to increment the lightning_count only when valid lightning 
>> events occur.  
>>
>> I'll be looking for example weewx.conf file settings that deal with the 
>> AS3935.
>> On Sunday, December 6, 2020 at 12:51:45 PM UTC-6 misk...@gmail.com wrote:
>>
>>> Hello guys,
>>> did anyone tried to use *Lightning sensor AS3935* tinkered on cheap 
>>> *ESP8266* with WeeWX?
>>>
>>> A time ago, I was user of Tasmota ESP8266 firmware and I know, it can 
>>> publish MQTT + JSON data. Here is the manual how to tinker and flash those 
>>> two together:
>>> https://tasmota.github.io/docs/AS3935/
>>> I assume, that with JSON / MQTT it would be prety easy to fill WeeWX 
>>> database...
>>>
>>> Thanks,
>>> Miso,
>>> Slovakia
>>>
>>

-- 
You received this message because you are subscribed 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/10f9bd8c-2722-4fed-adab-a54b9d965ab8n%40googlegroups.com.

[weewx-user] Re: How to send AS3935 Thunder Board (SwitchDocs) data to weewx.sdb

[Eric K]

I was hoping Mathew Wall would see the question and respond.  It appears he 
wrote it.

I have not downloaded the code and looked.  
Based on the config sections shown on the wiki page, it looks like it's may 
be hard-coded to talk to a Raspberry Pi port.
If that's true, it might not work with the MQTT transport directly, and 
require more rewriting than I am able to do.

I'm primarily a hardware engineer.  I can read and write code, but its not 
my strong suit, or my passion.
I like to find out if something is difficult or impossible, before I spend 
a lot of time on it.

Getting answers from people who already know doesn't require much effort 
from anyone, so its a good plan, in my view.

On Wednesday, June 16, 2021 at 12:52:42 PM UTC-5 vince wrote:

> On Wednesday, June 16, 2021 at 9:50:22 AM UTC-7 Eric K wrote:
>
>> Vince, if you don't know the answer to a question, why do you respond?
>>
>>
> You asked a very open ended question.
> I'm trying to understand what you have already looked into or tried.
>
> I took the time to download and look at the code.
> The answer to your question is very obvious if take just a little time and 
> put just a little effort in.
>
>
>

-- 
You received this message because you are subscribed 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/19aa60ac-ef8a-41f9-afb1-ba8e04d222aen%40googlegroups.com.

[weewx-user] Re: How to send AS3935 Thunder Board (SwitchDocs) data to weewx.sdb

[Eric K]

Vince, if you don't know the answer to a question, why do you respond?

On Wednesday, June 16, 2021 at 11:46:02 AM UTC-5 vince wrote:

> On Wednesday, June 16, 2021 at 9:42:51 AM UTC-7 Eric K wrote:
>
>> I wonder if anyone knows if this AS9395 service 
>> https://github.com/weewx/weewx/wiki/as3935
>> can be configured to work with MQTT data, or if its hard-coded to only 
>> talk to ports on the Raspberry Pi?
>>
>>
> Did you download and look at the code ?
>
>  
>

-- 
You received this message because you are subscribed 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/8f624ea8-9707-4e7b-8cac-6cad273b7fb1n%40googlegroups.com.

[weewx-user] Re: How to send AS3935 Thunder Board (SwitchDocs) data to weewx.sdb

[Eric K]

I wonder if anyone knows if this AS9395 service 
https://github.com/weewx/weewx/wiki/as3935
can be configured to work with MQTT data, or if its hard-coded to only talk 
to ports on the Raspberry Pi?

On Monday, August 20, 2018 at 10:22:36 AM UTC-5 bgra...@umw.edu wrote:

> Pat,

>>>
> This is the board I have:  
> https://shop.switchdoc.com/collections/grove/products/the-thunder-board-i2c-lightning-detector-grove-connectors
>
> It looks as if the weewx extension Matt suggests would be the best but I 
> would prefer to run it in an RPI and not my main weewx server, if possible. 
> The AS3935 board I have is not the one he references but it seems to have 
> the same connections using Grove connectors.
>
> I'm going to play around with the software from SwitchDocs Lab and see 
> what I come up with. If I can eliminate the PubNub host and produce a web 
> page on my own server then that might work. However, since weewx already 
> has a data display and graph built-in then that looks promising also. Sort 
> of mixed up as to what to do at this point... Thanks.
> Bob
>

-- 
You received this message because you are subscribed 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/8ad13457-cbdf-4a02-9c9a-0ffc4e556bb8n%40googlegroups.com.

[weewx-user] Re: help troubleshooting: weewx database stopped accepting data, out of the blue

[Eric K]

Strangely, it posted data to the database around 12:15pm, and then stopped 
again?

Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG user.MQTTSubscribe: 
(Service) data-> final record is 2021-06-10 12:15:00 CDT (1623345300): 
appTemp1: 69.488, Atlas_rain_total: 3.28, Atlas_strike_count: 241.0, 
barometer: 29.874321288124996, beaufort: 0.0, dateTime: 1623345300, 
interval: 5.0, lightning_distance: 0.0, lightning_strike_count: 0.0, 
luminosity: 3720.0, maxSolarRad: 947.8926188082237, radiation: 29.3508, 
rain: 0.0, rainRate: 0.0, usUnits: 1, UV: 1.0, windBatteryStatus: 0.0, 
windDir: None, windGust: 0.0, windGustDir: None, windSpeed: 0.0
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] INFO weewx.manager: Added record 
2021-06-10 12:15:00 CDT (1623345300) to database 'weewx.sdb'
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] INFO weewx.manager: Added record 
2021-06-10 12:15:00 CDT (1623345300) to daily summary in 'weewx.sdb'
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: MQTT: 
Unexpected exception of type 
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: 
Running reports for latest time in the database.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: Report 
'SeasonsReport' not enabled. Skipping.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: Report 
'SmartphoneReport' not enabled. Skipping.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: Report 
'MobileReport' not enabled. Skipping.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: Report 
'StandardReport' not enabled. Skipping.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: 
Running report 'Belchertown'
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: Found 
configuration file /home/weewx/skins/EricBelchertown/skin.conf for report 
'Belchertown'
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.cheetahgenerator: 
Using search list ['weewx.cheetahgenerator.Almanac', 
'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', 
'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 
'weewx.cheetahgenerator.Extras', 'weewx.cheetahgenerator.JSONHelpers', 
'user.belchertown.getData']
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: *** Traceback 
(most recent call last):
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: ***   File 
"/home/weewx/bin/weewx/restx.py", line 381, in run_loop
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: ***
 self.process_record(_record, dbmanager)
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: ***   File 
"/home/weewx/bin/user/mqtt.py", line 494, in process_record
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: ***
 mc.connect(url.hostname, url.port)
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: ***   File 
"/usr/local/lib/python3.8/dist-packages/paho/mqtt/client.py", line 939, in 
connect
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: ***
 self.connect_async(host, port, keepalive,
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: ***   File 
"/usr/local/lib/python3.8/dist-packages/paho/mqtt/client.py", line 1005, in 
connect_async
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: *** raise 
ValueError('Invalid host.')
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] ERROR weewx.restx: *** 
ValueError: Invalid host.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] CRITICAL weewx.restx: MQTT: 
Thread terminating. Reason: Invalid host.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.manager: Daily 
summary version is 4.0
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.restx: 
StationRegistry: Failed upload attempt 1: HTTP Error 502: Bad Gateway
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] INFO weewx.cheetahgenerator: 
Generated 11 files for report Belchertown in 0.33 seconds
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] INFO weewx.reportengine: Copied 
2 files to /home/weewx/public_html
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.manager: Daily 
summary version is 4.0
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] INFO weewx.restx: PWSWeather: 
Published record 2021-06-10 12:15:00 CDT (1623345300)
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: Report 
'FTP' not enabled. Skipping.
Jun 10 12:15:33 Ubuntu20-WEEWX weewx[3673] DEBUG weewx.reportengine: Report 
'RSYNC' not enabled. Skipping.
Jun 10 12:15:34 Ubuntu20-WEEWX weewx[3673] INFO weewx.restx: 
Wunderground-PWS: Published record 2021-06-10 12:15:00 CDT (1623345300)
Jun 10 12:15:36 Ubuntu20-WEEWX weewx[3673] DEBUG user.sdr: lines=[]



On Thursday, June 10, 2021 at 12:53:59 PM UTC-5 Eric K wrote:

> After running for a month without problems, it appears the weewx.sdb file 
> has stopped accepting data.
> It happened about 11:30am today, without any warning or apparent cause.
>
> I'm 

[weewx-user] help troubleshooting: weewx database stopped accepting data, out of the blue

[Eric K]

After running for a month without problems, it appears the weewx.sdb file 
has stopped accepting data.
It happened about 11:30am today, without any warning or apparent cause.

I'm pulling in data via the sdr driver primarily and also from 
MQTTSubscribe.
>From the syslog, I can see that data is still coming in from the sdr and 
MQTTSubscribe, but it's not getting logged to the database, and thus the 
weewx webpage has N/A for all the temp and pressure values.

Restarting weewx did not fix it.
Shutting down weewx and restarting Ubuntu 20 did not fix it.

I wonder if the database file got corrupted somehow?
Is the sqlite database limited to around 5MB in size?
My current sqlite database size info is:
-rw-r--r--  1 weewx weewx 4751360 Jun 10 11:35 weewx.sdb

I was capturing the debug=1 level to the syslog file at that moment.
Can anyone see any clues?

Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] INFO weewx.manager: Added record 
2021-06-10 11:25:00 CDT (1623342300) to database 'weewx.sdb'
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] INFO weewx.manager: Added record 
2021-06-10 11:25:00 CDT (1623342300) to daily summary in 'weewx.sdb'
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.restx: 
StationRegistry: wait interval (410100 < 604800) has not passed for record 
2021-06-10 11:25:00 CDT (1623342300)
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: 
Running reports for latest time in the database.
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: Report 
'SeasonsReport' not enabled. Skipping.
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: Report 
'SmartphoneReport' not enabled. Skipping.
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: Report 
'MobileReport' not enabled. Skipping.
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: Report 
'StandardReport' not enabled. Skipping.
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: 
Running report 'Belchertown'
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: Found 
configuration file /home/weewx/skins/EricBelchertown/skin.conf for report 
'Belchertown'
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.cheetahgenerator: 
Using search list ['weewx.cheetahgenerator.Almanac', 
'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', 
'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 
'weewx.cheetahgenerator.Extras', 'weewx.cheetahgenerator.JSONHelpers', 
'user.belchertown.getData']
Jun 10 11:27:32 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.manager: Daily 
summary version is 4.0
Jun 10 11:27:33 Ubuntu20-WEEWX weewx[4066] INFO weewx.restx: PWSWeather: 
Published record 2021-06-10 11:25:00 CDT (1623342300)
Jun 10 11:27:33 Ubuntu20-WEEWX weewx[4066] INFO weewx.cheetahgenerator: 
Generated 11 files for report Belchertown in 0.32 seconds
Jun 10 11:27:33 Ubuntu20-WEEWX weewx[4066] INFO weewx.reportengine: Copied 
2 files to /home/weewx/public_html
Jun 10 11:27:33 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.manager: Daily 
summary version is 4.0
Jun 10 11:27:33 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: Report 
'FTP' not enabled. Skipping.
Jun 10 11:27:33 Ubuntu20-WEEWX weewx[4066] DEBUG weewx.reportengine: Report 
'RSYNC' not enabled. Skipping.
Jun 10 11:27:33 Ubuntu20-WEEWX weewx[4066] INFO weewx.restx: 
Wunderground-PWS: Published record 2021-06-10 11:25:00 CDT (1623342300)
Jun 10 11:27:35 Ubuntu20-WEEWX weewx[4066] DEBUG user.sdr: lines=[]
Jun 10 11:27:37 Ubuntu20-WEEWX weewx[4066] DEBUG user.MQTTSubscribe: 
(Service) MessageCallbackProvider data-> incoming topic: 
tele/BMP280/SENSOR, QOS: 0, retain: 0, payload: 
b'{"Time":"2021-06-10T11:27:37","BMP280":{"Temperature":20.8,"Pressure":977.1},"PressureUnit":"hPa","TempUnit":"C"}'
Jun 10 11:27:37 Ubuntu20-WEEWX weewx[4066] DEBUG user.MQTTSubscribe: 
(Service) TopicManager data-> incoming tele/BMP280/SENSOR: appTemp1: 20.8, 
barometer: 977.1
Jun 10 11:27:38 Ubuntu20-WEEWX weewx[4066] DEBUG user.sdr: lines=[]
Jun 10 11:27:43 Ubuntu20-WEEWX weewx[4066] DEBUG user.sdr: lines=['{"time" 
: "2021-06-10 16:27:39", "model" : "Acurite-Atlas", "id" : 17, "channel" : 
"A", "sequence_num" : 2, "battery_ok" : 1, "message_type" : 39, 
"wind_avg_mi_h" : 2.000, "uv" : 1, "lux" : 3140, "strike_count" : 241, 
"strike_distance" : 0, "exception" : 0, "raw_msg" : 
"c811e78181823a3ca05a"}\n']
Jun 10 11:27:43 Ubuntu20-WEEWX weewx[4066] DEBUG user.sdr: 
packet={'windSpeed': 2.0, 'UV': 1, 'luminosity': 3140, 
'Atlas_strike_count': 241, 'lightning_distance': 0, 'windBatteryStatus': 0, 
'dateTime': 1623342459, 'usUnits': 1}
Jun 10 11:27:43 Ubuntu20-WEEWX weewx[4066] DEBUG user.MQTTSubscribe: 
(Service) TopicManager data-> outgoing tele/BMP280/SENSOR: appTemp1: 20.8, 
barometer: 977.1, dateTime: 1623342457.4788659, usUnits: 16
Jun 10 11:27:43 Ubuntu20-WEEWX weewx[4066] DEBUG user.MQTTSubscribe: 
(Service) TopicManager data-> outgoing accumulated tele/BMP280/SENSOR: 
appTemp1: 

[weewx-user] Re: weewx stopped for no apparent reason

[Eric K]

@JRJ, it appears this (or something similar) has just happened on my weewx 
4.5.1 installation.
I suppose I should start a new thread on it.  
I'll be watching yours to see if you find out whats going wrong!

On Wednesday, June 9, 2021 at 2:29:39 PM UTC-5 cub...@gmail.com wrote:

> @michael:  No, that is not what I am saying.  In fact, the converse is 
> likely true: that it ALSO stopped recording data in the database, as there 
> are no more messages of the sort "Added record ... to database" INFO level 
> messages in my logs once this occurred, as can be seen in my original post 
> - *all* messages out of weewx stopped at 03:15:18 in that example.  (Of 
> course it did also stop generating reports.)
>
> JRJ
>
> On Wednesday, June 9, 2021 at 1:30:17 PM UTC-5 michael.s...@gmail.com 
> wrote:
>
>> @JRJ: So, you're saying that WeeWX stopped generating reports but data 
>> still was recorded in the database, correct?
>> If yes, it seems unlikely that it's a driver issue and more on the weewx 
>> engine's side.
>>
>> cub...@gmail.com schrieb am Mittwoch, 9. Juni 2021 um 20:22:01 UTC+2:
>>
>>> @chris:  yes, indeed, the issue on my system was that weewx stopped 
>>> producing reports (and also there were no reporting-related messages in the 
>>> log.  I do am now running with debug set to 1 in the config.
>>>
>>> JRJ
>>>
>>> On Wednesday, June 9, 2021 at 12:09:08 PM UTC-5 cjsh...@gmail.com wrote:
>>>
 JRJ:

 Are you saying that weewx stopped generating reports? My weewx stopped 
 generating reports, with no error messages, at 4:00 AM. Restarting service 
 weewx did not fix it. Rebooting my raspberry pi DID fix it. So, I added a 
 crontab entry to reboot my raspberry pi each morning:
 5 4 * * * /sbin/shutdown -r now

 So far, it has not happened again. I'm using a WMII, with serial port 
 connection, using Python3 and the latest version of the driver from 
 JayJaeger

 Chris Shaker

 On Wednesday, June 9, 2021 at 5:46:52 AM UTC-7 cub...@gmail.com wrote:

> @michael:  It should not be related to the SCP upload, which continues 
> even after weewx has gone "night night".  It is running from a cron, not 
> under weewx.  It merely copies the generated HTML/graphics up to another 
> machine.  It runs  every 17  minutes.  If it were, say, locking up a file 
> and causing a report to fail there ought to be a message from Python 
> about 
> that, and there are no such messages.  This same SCP was running with 
> weewx 
> version 3 for many months without issues - originally every 15 minutes, I 
> changed it from 15 to 17 yesterday to put it out of sync from the report 
> generation a bit it after the second failure, just in case.  
>
> [It did occur to me to add a little mod akin to the RSYNC present in 
> weewx itself, or to cut over to using  then RSYNC under weewx after the 
> rest of this gets straightened out.]
>
> I also verified that all of the files and directories are owned by and 
> have the same group as the weewx process, and they are, so it should not 
> be 
> an issue of file permissions during report generation, either.
>
> Regarding the dev release driver, sure, I'll give that a try, and turn 
> on more logging later today.
>
> JRJ
>
> On Wednesday, June 9, 2021 at 1:40:52 AM UTC-5 michael.s...@gmail.com 
> wrote:
>
>> Nah, the logging level change doesn't matter, I've published a dev 
>> release a few days ago making exactly that change.
>>
>> I'd suggest you to try the new driver version anyway since I also 
>> made some changes regarding the HTTP interaction with the WLL. You 
>> should 
>> also enable debug logging so we get a more exhaustive look into what's 
>> going on.
>>
>> My suspicion is that something's wrong with the report generation or 
>> the SCP upload. Was the last iteration of the report actually uploaded 
>> correctly?
>>
>>
>>
>> vince schrieb am Mittwoch, 9. Juni 2021 um 06:10:01 UTC+2:
>>
>>> On Tuesday, June 8, 2021 at 12:43:44 PM UTC-7 cub...@gmail.com 
>>> wrote:
>>>
 (Note: I  did "tweaked" the WLL driver code to suppress the 
 "Emitting poll/(broadcast) messages by changing those two log calls to 
 "log.debug").  
>>>
>>>
>>> I'd suggest running the unaltered driver and especially in this case 
>>> so you get the maximum logging so the author can help you.
>>>
>>> If you start changing his code, eventually it'll be "you changed it, 
>>> you own the results good or bad" when he can't recreate the issue 
>>> because 
>>> your code has diverged from the authoritative version.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an 

Re: [weewx-user] Re: new weewx install not creating database or webpage

[Eric K]

I want to point out an error from above, so no one copies my mistake.
The [[Corrections]] section does not belong in the [SDR] driver section!

Here's how it should look:

##

[SDR]
# This section is for the software-defined radio driver.
# collect data from Acurite Atlas sensor 0011

# The driver to use
driver = user.sdr
cmd = rtl_433 -R 40 -M utc -F json

[[sensor_map]]
outTemp = temperature.0011.AcuriteAtlasPacket
outHumidity = humidity.0011.AcuriteAtlasPacket
windSpeed = wind_speed.0011.AcuriteAtlasPacket
windDir = wind_dir.0011.AcuriteAtlasPacket
UV = uv.0011.AcuriteAtlasPacket
Atlas_rain_total = rain_total.0011.AcuriteAtlasPacket
lux = lux.0011.AcuriteAtlasPacket
Atlas_strike_count = strike_count.0011.AcuriteAtlasPacket
lightning_distance = strike_distance.0011.AcuriteAtlasPacket
BatteryStatus = battery.0011.AcuriteAtlasPacket

[[deltas]]
rain = Atlas_rain_total
lightning_strike_count = Atlas_strike_count

##

[StdCalibrate]

[[Corrections]]
lightning_distance = lightning_distance if Atlas_stike_count > 0 
else None
On Tuesday, April 27, 2021 at 8:39:38 PM UTC-5 peterq...@gmail.com wrote:

> Biggest downside to decreasing the interval is the increase in database 
> size for no real gain in accuracy. I have my interval set at 2 minutes and 
> I am thinking about thinning out some of the historical data because the 
> database is 140MB and goes up by about 4mb a month.
>
> There is a real time extension that operates as fast as the data comes in, 
> so if you're looking at wind speed/direction, you can get that.
>
> On Tue, Apr 27, 2021 at 6:32 PM Eric Koester  wrote:
>
>> Thanks for the hints and suggestions.
>> I'm over the hump.  
>> Data is flowing from rtl_433, to weewx-sdr, to weewx!
>>
>> Now, the fine tuning and preference tweaking can occur!
>>
>> Is there any big downside to lowering the archive interval to 60 seconds?
>> What are your favorite weewx webpage skins?
>>
>> Eric
>> On Tuesday, April 27, 2021 at 1:54:19 PM UTC-5 Eric Koester wrote:
>>
>>> I got some hints/tips on getting the correct variable names from the 
>>> parsed and unparsed data that the sdr.py produces.
>>>
>>> I am now getting data into the database and the index.html file has been 
>>> produced!
>>>
>>> Oddly, the Firefox browser is able to 
>>> display file:///home/weewx/public_html/index.html , but Chromium is not.  I 
>>> get an error from Chromium:
>>>
>>> Access to the file was denied
>>>
>>> The file at *file:///home/weewx/public_html/index.html* is not 
>>> readable. It may have been removed, moved, or file permissions may be 
>>> preventing access.
>>>
>>> Now, I'm tweaking the [sensor_map] variables so they line up with the 
>>> variables in weewx, and all the collected data gets displayed.
>>>
>>>
>>> ##
>>>
>>> [SDR]
>>> # This section is for the software-defined radio driver.
>>> # collect data from Acurite Atlas sensor 0011
>>> 
>>> # The driver to use
>>> driver = user.sdr
>>> cmd = rtl_433 -R 40 -M utc -F json
>>> 
>>> [[sensor_map]]
>>> outTemp = temperature.0011.AcuriteAtlasPacket
>>> outHumidity = humidity.0011.AcuriteAtlasPacket
>>> windSpeed = wind_speed.0011.AcuriteAtlasPacket
>>> windDir = wind_dir.0011.AcuriteAtlasPacket
>>> UV = uv.0011.AcuriteAtlasPacket
>>> rain_total = rain_total.0011.AcuriteAtlasPacket
>>> lux = lux.0011.AcuriteAtlasPacket
>>> strikes_total = strike_count.0011.AcuriteAtlasPacket
>>> strike_distance = strike_distance.0011.AcuriteAtlasPacket
>>> BatteryStatus = battery.0011.AcuriteAtlasPacket
>>> 
>>> [[Corrections]]
>>> strike_distance = strike_distance if Lightning_Strikes > 0 else 
>>> None
>>>
>>>
>>> ##
>>>
>>> On Tuesday, April 27, 2021 at 12:06:43 PM UTC-5 Eric Koester wrote:
>>>
 I just posted a request for help on the weewx-sdr github issues tab.
 I demonstrated weewx-sdr working by calling 
 '/home/weewx/bin/user/sdr.py' and showing the valid weather station output.
 I asked them to look over my weewx.conf file for corrections.

 For my own information, I just ran wee_debug and it confirms the 
 database is empty.

 System info
   Platform:   Linux-5.8.0-50-generic-x86_64-with-glibc2.32
   Python Version: 3.8.6

 Load Information
   1 minute load average:  0.00
   5 minute load average:  0.07
   15 minute load average: 0.11

 General Weewx info
   Weewx version 4.5.1 detected.

 

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

[Eric K]

It's working as desired now!
Thanks for noticing the incorrect location of the [[Corrections]]

[image: lightning_distance working.JPG]

On Monday, May 24, 2021 at 7:39:25 AM UTC-5 gjr80 wrote:

> I can't explain it, it would require some detailed knowledge of how the 
> Acurite lightning sensor behaves. For example, the Ecowitt lightning sensor 
> reports distance when strikes are detected and that distance value persists 
> for some time before eventually reporting 0. If you had debug logging of 
> the SDR output (as you have in the log extract above) going on for some 
> time previous you could probably work through the log looking at the 
> distance value being obtained by the SDR driver from the Acurite. One thing 
> is certain though, the SDR driver was not applying the correction as the 
> SDR driver contains no code to read those config settings. And if the 
> correction was not under [StdCalibrate] [[Corrections]] then WeeWX wasn't 
> applying the correction either.
>
> Might just have to remain a mystery.
>
> Gary
>
> On Monday, 24 May 2021 at 07:33:56 UTC+10 Eric K wrote:
>
>> Thanks for the pointer.  
>> I also had a [[Corrections]] sections under [StdCalibrate].
>>
>> I just moved the lightning_distance correction to the [StdCalibrate] 
>> section.
>> We'll see if that helps.
>>
>> Isn't it odd that it worked, when the lightning_distance was something 
>> other than 10?
>>
>>
>> On Sunday, May 23, 2021 at 3:10:54 PM UTC-5 gjr80 wrote:
>>
>>> I think you might find the [[Corrections]] stanza belongs under 
>>> [StdCalibrate] <http://weewx.com/docs/usersguide.htm#StdCalibrate> 
>>> rather than the SDR driver.
>>>
>>> Gary
>>> On Monday, 24 May 2021 at 02:32:14 UTC+10 Eric K wrote:
>>>
>>>> Here's a relevant section of the log which shows the Acurite Atlas 
>>>> lightning sensor sending the last distance (10) reading over and over.  
>>>> This is expected Acurite Atlas behavior, and the reason we have to put 
>>>> the "if > 0 else None" statement in our [[Corrections]] section.
>>>>
>>>> Referring back to the 5.64705882352941 value seen in my database:
>>>> I wonder if weewx isn't expecting a decimal reading to be in 
>>>> lightning_distance?
>>>> And that sends it into confusion?
>>>>
>>>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
>>>> lines=['{"time" : "2021-05-23 15:56:20", "model" : "Acurite-Atlas", "id" : 
>>>> 17, "channel" : "A", "sequence_num" : 0, "battery_ok" : 1, "message_type" 
>>>> : 
>>>> 38, "wind_avg_mi_h" : 4.000, "wind_dir_deg" : 190.000, "rain_in" : 2.040, 
>>>> "strike_count" : 45, "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>>> "c011668205f9cc8baab8"}\n', '{"time" : "2021-05-23 15:56:20", "model" : 
>>>> "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 1, 
>>>> "battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 4.000, 
>>>> "wind_dir_deg" : 190.000, "rain_in" : 2.040, "strike_count" : 45, 
>>>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>>> "c411668205f9cc8baabc"}\n', '{"time" : "2021-05-23 15:56:20", "model" : 
>>>> "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 2, 
>>>> "battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 4.000, 
>>>> "wind_dir_deg" : 190.000, "rain_in" : 2.040, "strike_count" : 45, 
>>>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>>> "c811668205f9cc8baac0"}\n']
>>>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
>>>> packet={'windSpeed': 4.0, 'windDir': 190.0, 'Atlas_rain_total': 2.04, 
>>>> 'Atlas_strike_count': 45, 'lightning_distance': 10, 'windBatteryStatus': 
>>>> 0, 
>>>> 'dateTime': 1621785380, 'usUnits': 1}
>>>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
>>>> (Service) data-> final packet is 2021-05-23 10:56:20 CDT (1621785380): 
>>>> Atlas_rain_total: 

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

[Eric K]

Thanks for the pointer.  
I also had a [[Corrections]] sections under [StdCalibrate].

I just moved the lightning_distance correction to the [StdCalibrate] 
section.
We'll see if that helps.

Isn't it odd that it worked, when the lightning_distance was something 
other than 10?


On Sunday, May 23, 2021 at 3:10:54 PM UTC-5 gjr80 wrote:

> I think you might find the [[Corrections]] stanza belongs under 
> [StdCalibrate] <http://weewx.com/docs/usersguide.htm#StdCalibrate> rather 
> than the SDR driver.
>
> Gary
> On Monday, 24 May 2021 at 02:32:14 UTC+10 Eric K wrote:
>
>> Here's a relevant section of the log which shows the Acurite Atlas 
>> lightning sensor sending the last distance (10) reading over and over.  
>> This is expected Acurite Atlas behavior, and the reason we have to put 
>> the "if > 0 else None" statement in our [[Corrections]] section.
>>
>> Referring back to the 5.64705882352941 value seen in my database:
>> I wonder if weewx isn't expecting a decimal reading to be in 
>> lightning_distance?
>> And that sends it into confusion?
>>
>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
>> lines=['{"time" : "2021-05-23 15:56:20", "model" : "Acurite-Atlas", "id" : 
>> 17, "channel" : "A", "sequence_num" : 0, "battery_ok" : 1, "message_type" : 
>> 38, "wind_avg_mi_h" : 4.000, "wind_dir_deg" : 190.000, "rain_in" : 2.040, 
>> "strike_count" : 45, "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>> "c011668205f9cc8baab8"}\n', '{"time" : "2021-05-23 15:56:20", "model" : 
>> "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 1, 
>> "battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 4.000, 
>> "wind_dir_deg" : 190.000, "rain_in" : 2.040, "strike_count" : 45, 
>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>> "c411668205f9cc8baabc"}\n', '{"time" : "2021-05-23 15:56:20", "model" : 
>> "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 2, 
>> "battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 4.000, 
>> "wind_dir_deg" : 190.000, "rain_in" : 2.040, "strike_count" : 45, 
>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>> "c811668205f9cc8baac0"}\n']
>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
>> packet={'windSpeed': 4.0, 'windDir': 190.0, 'Atlas_rain_total': 2.04, 
>> 'Atlas_strike_count': 45, 'lightning_distance': 10, 'windBatteryStatus': 0, 
>> 'dateTime': 1621785380, 'usUnits': 1}
>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
>> (Service) data-> final packet is 2021-05-23 10:56:20 CDT (1621785380): 
>> Atlas_rain_total: 2.04, Atlas_strike_count: 45, dateTime: 1621785380, 
>> lightning_distance: 10, lightning_strike_count: 0, rain: 0.0, usUnits: 1, 
>> windBatteryStatus: 0, windDir: 190.0, windSpeed: 4.0
>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
>> packet={'windSpeed': 4.0, 'windDir': 190.0, 'Atlas_rain_total': 2.04, 
>> 'Atlas_strike_count': 45, 'lightning_distance': 10, 'windBatteryStatus': 0, 
>> 'dateTime': 1621785380, 'usUnits': 1}
>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
>> (Service) data-> final packet is 2021-05-23 10:56:20 CDT (1621785380): 
>> Atlas_rain_total: 2.04, Atlas_strike_count: 45, dateTime: 1621785380, 
>> lightning_distance: 10, lightning_strike_count: 0, rain: 0.0, usUnits: 1, 
>> windBatteryStatus: 0, windDir: 190.0, windSpeed: 4.0
>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
>> packet={'windSpeed': 4.0, 'windDir': 190.0, 'Atlas_rain_total': 2.04, 
>> 'Atlas_strike_count': 45, 'lightning_distance': 10, 'windBatteryStatus': 0, 
>> 'dateTime': 1621785380, 'usUnits': 1}
>> May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
>> (Service) data-> final packet is 2021-05-23 10:56:20 CDT (1621785380): 
>> Atlas_rain_total: 2.04, Atlas_strike_count: 45, dateTime: 1621785380, 
>> lightning_distance: 10, lightning_strike_count: 0, rain: 0.0, usUnits: 1, 
>> windBatteryStatus: 0, windDir: 190.0, windSpeed: 4.0
>> May 23 10:56:27 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: lines=[]
>

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

[Eric K]

Here's a relevant section of the log which shows the Acurite Atlas 
lightning sensor sending the last distance (10) reading over and over.  
This is expected Acurite Atlas behavior, and the reason we have to put the 
"if > 0 else None" statement in our [[Corrections]] section.

Referring back to the 5.64705882352941 value seen in my database:
I wonder if weewx isn't expecting a decimal reading to be in 
lightning_distance?
And that sends it into confusion?

May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: lines=['{"time" 
: "2021-05-23 15:56:20", "model" : "Acurite-Atlas", "id" : 17, "channel" : 
"A", "sequence_num" : 0, "battery_ok" : 1, "message_type" : 38, 
"wind_avg_mi_h" : 4.000, "wind_dir_deg" : 190.000, "rain_in" : 2.040, 
"strike_count" : 45, "strike_distance" : 10, "exception" : 0, "raw_msg" : 
"c011668205f9cc8baab8"}\n', '{"time" : "2021-05-23 15:56:20", "model" : 
"Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 1, 
"battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 4.000, 
"wind_dir_deg" : 190.000, "rain_in" : 2.040, "strike_count" : 45, 
"strike_distance" : 10, "exception" : 0, "raw_msg" : 
"c411668205f9cc8baabc"}\n', '{"time" : "2021-05-23 15:56:20", "model" : 
"Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 2, 
"battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 4.000, 
"wind_dir_deg" : 190.000, "rain_in" : 2.040, "strike_count" : 45, 
"strike_distance" : 10, "exception" : 0, "raw_msg" : 
"c811668205f9cc8baac0"}\n']
May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
packet={'windSpeed': 4.0, 'windDir': 190.0, 'Atlas_rain_total': 2.04, 
'Atlas_strike_count': 45, 'lightning_distance': 10, 'windBatteryStatus': 0, 
'dateTime': 1621785380, 'usUnits': 1}
May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
(Service) data-> final packet is 2021-05-23 10:56:20 CDT (1621785380): 
Atlas_rain_total: 2.04, Atlas_strike_count: 45, dateTime: 1621785380, 
lightning_distance: 10, lightning_strike_count: 0, rain: 0.0, usUnits: 1, 
windBatteryStatus: 0, windDir: 190.0, windSpeed: 4.0
May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
packet={'windSpeed': 4.0, 'windDir': 190.0, 'Atlas_rain_total': 2.04, 
'Atlas_strike_count': 45, 'lightning_distance': 10, 'windBatteryStatus': 0, 
'dateTime': 1621785380, 'usUnits': 1}
May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
(Service) data-> final packet is 2021-05-23 10:56:20 CDT (1621785380): 
Atlas_rain_total: 2.04, Atlas_strike_count: 45, dateTime: 1621785380, 
lightning_distance: 10, lightning_strike_count: 0, rain: 0.0, usUnits: 1, 
windBatteryStatus: 0, windDir: 190.0, windSpeed: 4.0
May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: 
packet={'windSpeed': 4.0, 'windDir': 190.0, 'Atlas_rain_total': 2.04, 
'Atlas_strike_count': 45, 'lightning_distance': 10, 'windBatteryStatus': 0, 
'dateTime': 1621785380, 'usUnits': 1}
May 23 10:56:24 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
(Service) data-> final packet is 2021-05-23 10:56:20 CDT (1621785380): 
Atlas_rain_total: 2.04, Atlas_strike_count: 45, dateTime: 1621785380, 
lightning_distance: 10, lightning_strike_count: 0, rain: 0.0, usUnits: 1, 
windBatteryStatus: 0, windDir: 190.0, windSpeed: 4.0
May 23 10:56:27 Ubuntu20-WEEWX weewx[14069] DEBUG user.sdr: lines=[]
May 23 10:56:29 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
(Service) MessageCallbackProvider data-> incoming topic: 
tele/BMP280/SENSOR, QOS: 0, retain: 0, payload: 
b'{"Time":"2021-05-23T10:56:30","BMP280":{"Temperature":20.2,"Pressure":985.1},"PressureUnit":"hPa","TempUnit":"C"}'
May 23 10:56:29 Ubuntu20-WEEWX weewx[14069] DEBUG user.MQTTSubscribe: 
(Service) TopicManager data-> incoming tele/BMP280/SENSOR: appTemp1: 20.2, 
barometer: 985.1


On Sunday, May 23, 2021 at 11:19:26 AM UTC-5 Eric K wrote:

> I am seeing a weird problem with the lightning distance value, where the 
> distance gets stuck reporting 10!
>
> I copied the [[Corrections]] scheme shown earlier in this thread.  
> I'm pretty sure I got it right, because it works most of the time.
>
>
> ##
>
> [SDR]
> # This section is for the software-defined radio driver.
> # collect data from

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

[Eric K]

I am seeing a weird problem with the lightning distance value, where the 
distance gets stuck reporting 10!

I copied the [[Corrections]] scheme shown earlier in this thread.  
I'm pretty sure I got it right, because it works most of the time.

##

[SDR]
# This section is for the software-defined radio driver.
# collect data from Acurite Atlas sensor

# The driver to use
driver = user.sdr
cmd = rtl_433 -R 40 -M utc -F json

[[sensor_map]]
outTemp = temperature.0011.AcuriteAtlasPacket
outHumidity = humidity.0011.AcuriteAtlasPacket
windSpeed = wind_speed.0011.AcuriteAtlasPacket
windDir = wind_dir.0011.AcuriteAtlasPacket
UV = uv.0011.AcuriteAtlasPacket
luminosity = lux.0011.AcuriteAtlasPacket
Atlas_rain_total = rain_total.0011.AcuriteAtlasPacket
Atlas_strike_count = strike_count.0011.AcuriteAtlasPacket
lightning_distance = strike_distance.0011.AcuriteAtlasPacket
windBatteryStatus = battery.0011.AcuriteAtlasPacket

[[deltas]]
rain = Atlas_rain_total
lightning_strike_count = Atlas_strike_count

[[Corrections]]
lightning_distance = lightning_distance if lightning_strike_count > 
0 else None

##

But, I've now seen several storms with lightning and and the 
lightinig_distance value gets stuck reporting 10 forever after!
I see the 10 repeating in the database, so I believe that weewx is 
generating that number and sending it into the database.

Here's a look in the database using DB Browser for SQLite.  
Note how a distance value of 5.64705882352941 from the Acurite Atlas 
appears and then it's 10 thereafter.
You can see the lightning_strike_count is zero.  
The "else None" part of the condition statement appears to stop working?

[image: ksnip_20210523-32.png]

On Thursday, July 23, 2020 at 5:55:55 AM UTC-5 tarob...@gmail.com wrote:

> Thank you for the detailed explanation Gary! I have added the 
>> [Accumulator] section to my weewx.conf for lightning_strike_count -> 
>> extractor = sum and lightning_distance -> extractor = min. Now to wait for 
>> another storm.
>
>
> -Troy 
>

-- 
You received this message because you are subscribed 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/74c16b1a-a35c-4f3d-b630-c31d965900fen%40googlegroups.com.

Re: [weewx-user] want to use lux value to calculate value for 'radiation'

[Eric K]

Yeah, I agree conversion is not the best way to obtain the solar radiation 
value. 
Lux is all Acurite provides us.

I found several places where the sunlight-specific conversion value of of 
1/126.7 (or 0.00789) was referenced, so I went with that.
https://help.ambientweather.net/help/why-is-the-lux-to-w-m-2-conversion-factor-126-7
https://cumulus.hosiene.co.uk/viewtopic.php?t=3979



On Tuesday, May 18, 2021 at 5:04:08 PM UTC-5 Greg Troxel wrote:

>
> Eric K  writes:
>
> > The Acurite Atlas weather sensor provides a UV and a lux value, but not 
> a 
> > radiation value.
> > I want to use this formula to calculate solar radiation from the lux 
> sensor 
> > in the Acurite Atlas: radiation = lux * 0.0079
>
> See also
>
> https://github.com/weewx/weewx/wiki/Watts-and-lux
>

-- 
You received this message because you are subscribed 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/77cc35c9-7a13-4fff-8194-c0b11c48ca76n%40googlegroups.com.

Re: [weewx-user] want to use lux value to calculate value for 'radiation'

[Eric K]

That worked well.  Thanks!
[image: calculated radiation value.JPG]

On Tuesday, May 18, 2021 at 2:58:31 PM UTC-5 lang@googlemail.com wrote:

> in the [StdCalibrate] [[Corrections]] stanza in weewx.conf add the line
>
> radiation = luminosity/126.7 if luminosity is not None else None
>
> Then the calculated value will be stored as radiation in the database and 
> you can use it in your reports/skins
>
> On 18.05.2021 21:10, Eric K wrote:
>
> The Acurite Atlas weather sensor provides a UV and a lux value, but not a 
> radiation value.
> I want to use this formula to calculate solar radiation from the lux 
> sensor in the Acurite Atlas:  radiation = lux * 0.0079
>
> I've been searching the weewx documentation for details and examples of 
> how to create a data value from a calculation.  This calculated data will 
> then go into the weewx database, and graphs in the weewx web page.
>
> It looks like the StdWXCalculate section of the weewx.conf file is the 
> place to do this?
> Is that correct?
> https://weewx.com/docs/usersguide.htm#StdWXCalculate
>
> I've been looking for an example of the StdWXCalculate section showing how 
> a user-created formula is included, and I have not found one.
>
> Can someone show an example of including a user-created formula?
>
> Help appreciated.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/574d19fd-304c-44d9-b73a-68d203e72a82n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/574d19fd-304c-44d9-b73a-68d203e72a82n%40googlegroups.com?utm_medium=email_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/1fca24cc-82e4-40dc-b835-3a9b22c240d9n%40googlegroups.com.

[weewx-user] want to use lux value to calculate value for 'radiation'

[Eric K]

The Acurite Atlas weather sensor provides a UV and a lux value, but not a 
radiation value.
I want to use this formula to calculate solar radiation from the lux sensor 
in the Acurite Atlas:  radiation = lux * 0.0079

I've been searching the weewx documentation for details and examples of how 
to create a data value from a calculation.  This calculated data will then 
go into the weewx database, and graphs in the weewx web page.

It looks like the StdWXCalculate section of the weewx.conf file is the 
place to do this?
Is that correct?
https://weewx.com/docs/usersguide.htm#StdWXCalculate

I've been looking for an example of the StdWXCalculate section showing how 
a user-created formula is included, and I have not found one.

Can someone show an example of including a user-created formula?

Help appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/574d19fd-304c-44d9-b73a-68d203e72a82n%40googlegroups.com.