Re: [weewx-user] Can't create a weewx MySQL database

[Luc Heijst]

Hello Paul,

I didn't make up these port numbers. They are the default port numbers for 
my Synology NAS. 
You can install both MariaDB versions 5 and 10 on the same NAS.
The databases are on my DS216j model running DSM 6.2.4.

Luc

Op zaterdag 15 mei 2021 om 16:07:13 UTC-3 schreef paul.ba...@gmail.com:

> Hello Luc and Tom,
>
> The problem is solved, but with a wrong solution. 3306 is the normal 
> "port" for all versions of mysql AND mariadb .  Do you have both running? 
> mariadb even use the same configuration at installation.
> Port numbers are defined by default in the system. From 0 to 1024 they are 
> "hard" defined and can not be changed. Above, they are defined for many 
> applications that can receive data from outside, including mysql, mariadb 
> and postgress, ssh, ftp etc. You can change them at your own risk, 
> including the fact that, being not standard, all other applications must 
> then be adapted.
>
> You can see all ports in use in your system with the command
>
>sudo netstat -tulpn
>
> or, if you want just mysql (== mariadb):
>
>sudo netstat -tulpn | egrep mysql
>
> Regards, Paul
>
>
>
>
> Le Friday, May 14, 2021 à 7:56:40 PM UTC+2, Luc Heijst a écrit :
>
>> Tom,
>>
>> You were right (as usual!)
>> Port 3306 is of a non-existing mariadb 5 configuration. I had to use port 
>> 3307 for mariadb 10
>> Problem solved. Thanks for your help.
>>
>> Luc
>>
>> Op vrijdag 14 mei 2021 om 14:22:49 UTC-3 schreef tke...@gmail.com:
>>
>>> Most likely the host and/or port is wrong.
>>>
>>> Experiment using the tool mysql:
>>>
>>> *mysql --host=192.168.0.15 --port=3306 -u weewx -p*
>>>
>>>
>>>
>>> On Fri, May 14, 2021 at 10:07 AM Luc Heijst  wrote:
>>>
>>>> Weewx version 4.5.1, Python 3.7.1
>>>>
>>>> When in weewx.conf a sqlite database is selected, then a new database 
>>>> is created and initialized.
>>>> But when in weewx.conf a MySQL database is selected, then no database 
>>>> is created.
>>>> Also I can't create a MySQL database with command 'wee_database'; see 
>>>> logging below
>>>>
>>>> Luc
>>>>
>>>>
>>>> No MySQL database 'sdr1' is created at startup of weewx, see logging 
>>>> below. An error occurs: Can't connect to MySQL server
>>>> =
>>>> May 14 13:39:25 pi32 sdr1[11692] INFO __main__: Initializing weewx 
>>>> version 4.5.1
>>>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Using Python 3.7.3 
>>>> (default, Jan 22 2021, 20:04:44) #012[GCC 8.3.0]
>>>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Platform 
>>>> Linux-5.10.17-v7+-armv7l-with-debian-10.9
>>>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Locale is 'en_GB.UTF-8'
>>>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: PID file is 
>>>> /var/run/weewx_sdr1.pid
>>>> May 14 13:39:25 pi32 sdr1[10695] INFO __main__: Using configuration 
>>>> file /home/weewx/weewx_sdr1.conf
>>>> May 14 13:39:25 pi32 sdr1[10695] INFO __main__: Debug is 2
>>>> May 14 13:39:25 pi32 sdr1[10695] DEBUG __main__: Initializing engine
>>>> May 14 13:39:25 pi32 sdr1[10695] INFO weewx.engine: Loading station 
>>>> type SDR (user.sdr)
>>>> May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: driver version is 0.78
>>>> May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: sensor map is {'temp1': 
>>>> 'temperature.6A55.TFA_1Packet', 'humidity1': 'humidity.6A55.TFA_1Packet', 
>>>> 'rssi1': 'rssi.6A55.TFA_1Packet', 'batteryStatus1': 
>>>> 'lowbat.6A55.TFA_1Packet', 'temp2': 'temperature.7131.TFA_1Packet', 
>>>> 'humidity2': 'humidity.7131.TFA_1Packet', 'rssi2': 
>>>> 'rssi.7131.TFA_1Packet', 
>>>> 'batteryStatus2': 'lowbat.7131.TFA_1Packet', 'temp3': 
>>>> 'temperature.6C85.TFA_1Packet', 'humidity3': 'humidity.6C85.TFA_1Packet', 
>>>> 'rssi3': 'rssi.6C85.TFA_1Packet', 'batteryStatus3': 
>>>> 'lowbat.6C85.TFA_1Packet', 'temp4': 'temperature.55C7.TFA_1Packet', 
>>>> 'humidity4': 'humidity.55C7.TFA_1Packet', 'rssi4': 
>>>> 'rs

Re: [weewx-user] Can't create a weewx MySQL database

[Luc Heijst]

Tom,

You were right (as usual!)
Port 3306 is of a non-existing mariadb 5 configuration. I had to use port 
3307 for mariadb 10
Problem solved. Thanks for your help.

Luc

Op vrijdag 14 mei 2021 om 14:22:49 UTC-3 schreef tke...@gmail.com:

> Most likely the host and/or port is wrong.
>
> Experiment using the tool mysql:
>
> *mysql --host=192.168.0.15 --port=3306 -u weewx -p*
>
>
>
> On Fri, May 14, 2021 at 10:07 AM Luc Heijst  wrote:
>
>> Weewx version 4.5.1, Python 3.7.1
>>
>> When in weewx.conf a sqlite database is selected, then a new database is 
>> created and initialized.
>> But when in weewx.conf a MySQL database is selected, then no database is 
>> created.
>> Also I can't create a MySQL database with command 'wee_database'; see 
>> logging below
>>
>> Luc
>>
>>
>> No MySQL database 'sdr1' is created at startup of weewx, see logging 
>> below. An error occurs: Can't connect to MySQL server
>> =
>> May 14 13:39:25 pi32 sdr1[11692] INFO __main__: Initializing weewx 
>> version 4.5.1
>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Using Python 3.7.3 
>> (default, Jan 22 2021, 20:04:44) #012[GCC 8.3.0]
>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Platform 
>> Linux-5.10.17-v7+-armv7l-with-debian-10.9
>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Locale is 'en_GB.UTF-8'
>> May 14 13:39:25 pi32 sdr1[10691] INFO __main__: PID file is 
>> /var/run/weewx_sdr1.pid
>> May 14 13:39:25 pi32 sdr1[10695] INFO __main__: Using configuration file 
>> /home/weewx/weewx_sdr1.conf
>> May 14 13:39:25 pi32 sdr1[10695] INFO __main__: Debug is 2
>> May 14 13:39:25 pi32 sdr1[10695] DEBUG __main__: Initializing engine
>> May 14 13:39:25 pi32 sdr1[10695] INFO weewx.engine: Loading station type 
>> SDR (user.sdr)
>> May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: driver version is 0.78
>> May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: sensor map is {'temp1': 
>> 'temperature.6A55.TFA_1Packet', 'humidity1': 'humidity.6A55.TFA_1Packet', 
>> 'rssi1': 'rssi.6A55.TFA_1Packet', 'batteryStatus1': 
>> 'lowbat.6A55.TFA_1Packet', 'temp2': 'temperature.7131.TFA_1Packet', 
>> 'humidity2': 'humidity.7131.TFA_1Packet', 'rssi2': 'rssi.7131.TFA_1Packet', 
>> 'batteryStatus2': 'lowbat.7131.TFA_1Packet', 'temp3': 
>> 'temperature.6C85.TFA_1Packet', 'humidity3': 'humidity.6C85.TFA_1Packet', 
>> 'rssi3': 'rssi.6C85.TFA_1Packet', 'batteryStatus3': 
>> 'lowbat.6C85.TFA_1Packet', 'temp4': 'temperature.55C7.TFA_1Packet', 
>> 'humidity4': 'humidity.55C7.TFA_1Packet', 'rssi4': 'rssi.55C7.TFA_1Packet', 
>> 'batteryStatus4': 'lowbat.55C7.TFA_1Packet', 'temp5': 
>> 'temperature.61AA.TFA_1Packet', 'humidity5': 'humidity.61AA.TFA_1Packet', 
>> 'rssi5': 'rssi.61AA.TFA_1Packet', 'batteryStatus5': 
>> 'lowbat.61AA.TFA_1Packet', 'temp6': 'temperature..TFA_1Packet', 
>> 'humidity6': 'humidity..TFA_1Packet', 'rssi6': 'rssi..TFA_1Packet', 
>> 'batteryStatus6': 'lowbat..TFA_1Packet', 'temp7': 
>> 'temperature.4562.TFA_1Packet', 'humidity7': 'humidity.4562.TFA_1Packet', 
>> 'rssi7': 'rssi.4562.TFA_1Packet', 'batteryStatus7': 
>> 'lowbat.4562.TFA_1Packet', 'temp8': 'temperature.5565.TFA_1Packet', 
>> 'humidity8': 'humidity.5565.TFA_1Packet', 'rssi8': 'rssi.5565.TFA_1Packet', 
>> 'batteryStatus8': 'lowbat.5565.TFA_1Packet'}
>> May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: deltas is {'rain': 
>> 'rain_total', 'strikes': 'strikes_total'}
>> May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: startup process 'rtl_433 
>> -M utc -F json -R 150 -f 868.250M -s 1536k'
>> May 14 13:39:25 pi32 sdr1[10695] DEBUG user.sdr: start async reader for 
>> stdout-thread
>> May 14 13:39:25 pi32 sdr1[10695] DEBUG user.sdr: start async reader for 
>> stderr-thread
>> May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Loading service 
>> weewx.engine.StdTimeSynch
>> May 14 13:39:25 pi32 sdr1[10695

[weewx-user] Can't create a weewx MySQL database

[Luc Heijst]

Weewx version 4.5.1, Python 3.7.1

When in weewx.conf a sqlite database is selected, then a new database is 
created and initialized.
But when in weewx.conf a MySQL database is selected, then no database is 
created.
Also I can't create a MySQL database with command 'wee_database'; see 
logging below

Luc


No MySQL database 'sdr1' is created at startup of weewx, see logging below. 
An error occurs: Can't connect to MySQL server
=
May 14 13:39:25 pi32 sdr1[11692] INFO __main__: Initializing weewx version 
4.5.1
May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Using Python 3.7.3 
(default, Jan 22 2021, 20:04:44) #012[GCC 8.3.0]
May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Platform 
Linux-5.10.17-v7+-armv7l-with-debian-10.9
May 14 13:39:25 pi32 sdr1[10691] INFO __main__: Locale is 'en_GB.UTF-8'
May 14 13:39:25 pi32 sdr1[10691] INFO __main__: PID file is 
/var/run/weewx_sdr1.pid
May 14 13:39:25 pi32 sdr1[10695] INFO __main__: Using configuration file 
/home/weewx/weewx_sdr1.conf
May 14 13:39:25 pi32 sdr1[10695] INFO __main__: Debug is 2
May 14 13:39:25 pi32 sdr1[10695] DEBUG __main__: Initializing engine
May 14 13:39:25 pi32 sdr1[10695] INFO weewx.engine: Loading station type 
SDR (user.sdr)
May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: driver version is 0.78
May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: sensor map is {'temp1': 
'temperature.6A55.TFA_1Packet', 'humidity1': 'humidity.6A55.TFA_1Packet', 
'rssi1': 'rssi.6A55.TFA_1Packet', 'batteryStatus1': 
'lowbat.6A55.TFA_1Packet', 'temp2': 'temperature.7131.TFA_1Packet', 
'humidity2': 'humidity.7131.TFA_1Packet', 'rssi2': 'rssi.7131.TFA_1Packet', 
'batteryStatus2': 'lowbat.7131.TFA_1Packet', 'temp3': 
'temperature.6C85.TFA_1Packet', 'humidity3': 'humidity.6C85.TFA_1Packet', 
'rssi3': 'rssi.6C85.TFA_1Packet', 'batteryStatus3': 
'lowbat.6C85.TFA_1Packet', 'temp4': 'temperature.55C7.TFA_1Packet', 
'humidity4': 'humidity.55C7.TFA_1Packet', 'rssi4': 'rssi.55C7.TFA_1Packet', 
'batteryStatus4': 'lowbat.55C7.TFA_1Packet', 'temp5': 
'temperature.61AA.TFA_1Packet', 'humidity5': 'humidity.61AA.TFA_1Packet', 
'rssi5': 'rssi.61AA.TFA_1Packet', 'batteryStatus5': 
'lowbat.61AA.TFA_1Packet', 'temp6': 'temperature..TFA_1Packet', 
'humidity6': 'humidity..TFA_1Packet', 'rssi6': 'rssi..TFA_1Packet', 
'batteryStatus6': 'lowbat..TFA_1Packet', 'temp7': 
'temperature.4562.TFA_1Packet', 'humidity7': 'humidity.4562.TFA_1Packet', 
'rssi7': 'rssi.4562.TFA_1Packet', 'batteryStatus7': 
'lowbat.4562.TFA_1Packet', 'temp8': 'temperature.5565.TFA_1Packet', 
'humidity8': 'humidity.5565.TFA_1Packet', 'rssi8': 'rssi.5565.TFA_1Packet', 
'batteryStatus8': 'lowbat.5565.TFA_1Packet'}
May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: deltas is {'rain': 
'rain_total', 'strikes': 'strikes_total'}
May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: startup process 'rtl_433 -M 
utc -F json -R 150 -f 868.250M -s 1536k'
May 14 13:39:25 pi32 sdr1[10695] DEBUG user.sdr: start async reader for 
stdout-thread
May 14 13:39:25 pi32 sdr1[10695] DEBUG user.sdr: start async reader for 
stderr-thread
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Loading service 
weewx.engine.StdTimeSynch
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdTimeSynch
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Loading service 
weewx.engine.StdConvert
May 14 13:39:25 pi32 sdr1[10695] INFO weewx.engine: StdConvert target unit 
is 0x10
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdConvert
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Loading service 
weewx.engine.StdCalibrate
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdCalibrate
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Loading service 
weewx.engine.StdQC
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdQC
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.engine: Loading service 
weewx.wxservices.StdWXCalculate
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.wxservices: Calculations for 
LOOP packets: {'windDir': 'software', 'windGustDir': 'software'}
May 14 13:39:25 pi32 sdr1[10695] DEBUG weewx.wxservices: Calculations for 
archive records: {'windDir': 'software', 'windGustDir': 'software'}
May 14 13:39:25 pi32 sdr1[10695] INFO user.sdr: shutdown process rtl_433 -M 
utc -F json -R 150 -f 868.250M -s 1536k
May 14 13:39:25 pi32 sdr1[10695] DEBUG user.sdr: waiting for stdout-thread
May 14 13:39:35 pi32 sdr1[10695] INFO user.sdr: timed out waiting for 
stdout-thread
May 14 13:39:35 pi32 sdr1[10695] DEBUG user.sdr: waiting for stderr-thread
May 14 13:39:45 pi32 sdr1[10695] INFO user.sdr: timed out waiting for 
stderr-thread
May 14 13:39:45 pi32 sdr1[10695] DEBUG user.sdr: close stdout
May 14 13:39:45 pi32 sdr1[10695] DEBUG user.sdr: close stderr
May 14 13:39:46 pi32 sdr1[10695] DEBUG user.sdr: kill process
May 14 13:39:46 pi3

Re: [weewx-user] (nested) Deadlocks found

[Luc Heijst]

The backup of weewx_wbx1 normally takes 10-11 seconds. This morning (with 
the deathlock error) it took 16 seconds. 
I have added option --skip-lock-tables

Op zaterdag 1 mei 2021 om 12:03:41 UTC-3 schreef tke...@gmail.com:

> OK, what I suspected. 
>
> We could add a retry to the transaction. However, the database backup is 
> likely to take a lot longer than the weewx write, so even with a couple of 
> retries, it may still deadlock, unless very lengthy delays are added. This 
> would be undesirable because the weewx writes are in the main thread. So, 
> the program will block, waiting for your database dump to finish, which in 
> some cases could be several minutes.
>
> I'm not an expert on this, but how about instructing mysqldump not to lock 
> the database by using option --lock-table=false? Or, is there a way to get 
> mysqldump to do a retry? It's likely to be more successful than having 
> weewx do the retry.
>
> -tk
>
>
> On Sat, May 1, 2021 at 7:26 AM Luc Heijst  wrote:
>
>> The weewx instances run on 11 different raspberry pi's. weewx_wbx1 and 
>> weewx_cmon(33) run on the same PI.
>> They all run weewx v.4.4.0 and Python 3.7.3.
>> All weewx instances write to remote MySQL databases on my Synology NAS. 
>>
>> See below the backup on my NAS.and some more of my syslog file
>>
>> 
>> #! /bin/sh
>> # Dayly backup of main weewx tables
>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>> echo "$DATETIME start"
>> BACKUP="/usr/local/mariadb10/bin/mysqldump -uroot -p"
>> OUTDIR=/volume1/data-h5/_mysql
>> ...
>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>> echo "$DATETIME cmon33"
>> $BACKUP cmon33 > $OUTDIR/cmon33.sql
>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>> ...
>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>> echo "$DATETIME weewx_wbx1"
>> $BACKUP weewx_wbx1 > $OUTDIR/weewx_wbx1.sql
>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>> echo "$DATETIME finished"
>>
>> 
>>
>> May  1 03:15:14 pi33 wbx1[495] DEBUG user.meteostick: meteostick: 
>> data['rxCheckPercent']: 94
>> May  1 03:15:14 pi33 wbx1[495] DEBUG user.meteostick: meteostick: RF 
>> summary: rf_sensitivity=73 (values in dB)
>> May  1 03:15:14 pi33 wbx1[495] DEBUG user.meteostick: meteostick: 
>> Station   max   min   avg   last  count [missed] [good]
>> May  1 03:15:14 pi33 wbx1[495] DEBUG user.meteostick: meteostick: iss
>>-49   -52   -50   -51   104   8  93   
>> May  1 03:15:14 pi33 wbx1[495] DEBUG user.meteostick: meteostick: 
>> anemometer-58   -59   -58   -59   107   7  94   
>> May  1 03:15:14 pi33 wbx1[495] DEBUG user.meteostick: meteostick: 
>> leaf_soil -43   -46   -43   -4694   6  94   
>> May  1 03:15:15 pi33 cmon[544] INFO weewx.manager: Added record 
>> 2021-05-01 03:15:15 -03 (1619849715) to database 'cmon33'
>> May  1 03:15:26 pi33 cmon[544] INFO weewx.manager: Added record 
>> 2021-05-01 03:15:15 -03 (1619849715) to daily summary in 'cmon33'
>> May  1 03:15:32 pi33 cmon[544] INFO weewx.manager: Added record 
>> 2021-05-01 03:15:00 -03 (1619849700) to database 'wx_cmon33'
>> May  1 03:15:36 pi33 cmon[544] INFO weewx.manager: Added record 
>> 2021-05-01 03:15:00 -03 (1619849700) to daily summary in 'wx_cmon33'
>> May  1 03:15:36 pi33 cmon[544] DEBUG weewx.reportengine: Running reports 
>> for latest time in the database.
>> May  1 03:15:36 pi33 cmon[544] DEBUG weewx.reportengine: Running report 
>> 'cmon33'
>> May  1 03:15:36 pi33 cmon[544] DEBUG weewx.reportengine: Found 
>> configuration file /home/weewx/skins/cmon33/skin.conf for report 'cmon33'
>> May  1 03:15:36 pi33 cmon[544] DEBUG weewx.cheetahgenerator: Using search 
>> list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 
>> 'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 
>> 'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
>> May  1 03:15:36 pi33 cmon[544] DEBUG weewx.manager: Daily summary version 
>> is 4.0
>> May  1 03:15:42 pi33 cmon[544] DEBUG weewx.manager: Daily summary version 
>> is 4.0
>> May  1 03:15:47 pi33 wbx1[495] INFO weewx.manager: Added record 
>> 2021-05-01 03:15:00 -03 (1619849700) to database 'weewx_wbx1'
>> May  1 03:15:51 pi33 wbx1[495] INFO weewx.manager: Added record 
>>

Re: [weewx-user] (nested) Deadlocks found

[Luc Heijst]

:20:43 pi33 wbx1[495] CRITICAL __main__:   
cursor.execute(sql_insert_stmt, value_list)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/home/weewx/bin/weedb/mysql.py", line 61, in guarded_fn
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   raise 
klass(e)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
weedb.DatabaseError: (1213, 'Deadlock found when trying to get lock; try 
restarting transaction')
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   Exiting.
May  1 03:21:00 pi33 cmon[544] DEBUG weewx.reportengine: Report 'FTP' not 
enabled. Skipping.
May  1 03:21:00 pi33 cmon[544] DEBUG weewx.reportengine: Report 'RSYNC' not 
enabled. Skipping.
May  1 03:25:22 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:25:23 -03 (1619850323) to database 'cmon33'
May  1 03:25:24 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:25:23 -03 (1619850323) to daily summary in 'cmon33'
May  1 03:25:27 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:25:00 -03 (1619850300) to database 'wx_cmon33'
May  1 03:25:28 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:25:00 -03 (1619850300) to daily summary in 'wx_cmon33'
May  1 03:25:28 pi33 cmon[544] DEBUG weewx.reportengine: Running reports 
for latest time in the database.
May  1 03:25:28 pi33 cmon[544] DEBUG weewx.reportengine: Running report 
'cmon33'
May  1 03:25:28 pi33 cmon[544] DEBUG weewx.reportengine: Found 
configuration file /home/weewx/skins/cmon33/skin.conf for report 'cmon33'
May  1 03:25:28 pi33 cmon[544] DEBUG weewx.cheetahgenerator: Using search 
list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 
'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 
'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
May  1 03:25:28 pi33 cmon[544] DEBUG weewx.manager: Daily summary version 
is 4.0
May  1 03:25:35 pi33 cmon[544] DEBUG weewx.manager: Daily summary version 
is 4.0
May  1 03:25:49 pi33 cmon[544] DEBUG weewx.reportengine: Report 'FTP' not 
enabled. Skipping.
May  1 03:25:49 pi33 cmon[544] DEBUG weewx.reportengine: Report 'RSYNC' not 
enabled. Skipping.
May  1 03:30:19 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:30:19 -03 (1619850619) to database 'cmon33'
May  1 03:30:21 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:30:19 -03 (1619850619) to daily summary in 'cmon33'
May  1 03:30:27 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:30:00 -03 (1619850600) to database 'wx_cmon33'
May  1 03:30:29 pi33 cmon[544] INFO weewx.manager: Added record 2021-05-01 
03:30:00 -03 (1619850600) to daily summary in 'wx_cmon33'
May  1 03:30:29 pi33 cmon[544] DEBUG weewx.reportengine: Running reports 
for latest time in the database.
May  1 03:30:29 pi33 cmon[544] DEBUG weewx.reportengine: Running report 
'cmon33'
May  1 03:30:29 pi33 cmon[544] DEBUG weewx.reportengine: Found 
configuration file /home/weewx/skins/cmon33/skin.conf for report 'cmon33'
May  1 03:30:29 pi33 cmon[544] DEBUG weewx.cheetahgenerator: Using search 
list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 
'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 
'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
May  1 03:30:29 pi33 cmon[544] DEBUG weewx.manager: Daily summary version 
is 4.0
May  1 03:30:40 pi33 cmon[544] DEBUG weewx.manager: Daily summary version 
is 4.0
May  1 03:30:58 pi33 cmon[544] DEBUG weewx.reportengine: Report 'FTP' not 
enabled. Skipping.
May  1 03:30:58 pi33 cmon[544] DEBUG weewx.reportengine: Report 'RSYNC' not 
enabled. Skipping.


Op zaterdag 1 mei 2021 om 10:54:15 UTC-3 schreef tke...@gmail.com:

> Trying to understand your setup
>
> 1. You have many instances of weewx running simultaneously.
> 2. They all get backed up every day.
> 3. One of them, weewx_wbx1, crashes about once a month during the backup.
> 4. What version of WeeWX?
>
> I don't attach any significance to the three different nested exceptions: 
> that's how the stack would normally get unwound from a database exception. 
> However, I don't understand the last one: dbmanager.addRecord(). By itself, 
> this does not lock the database. Is there more to the log? Something below 
> where you cut it off?
>
> Depending on the answer to that, we may have to retry the transaction. 
> Right now, there is only one attempt.
>
> -tk
>
>
>
> On Sat, May 1, 2021 at 4:58 AM Luc Heijst  wrote:
>
>> Once a day my weewx MySQL databases are backupped, see log of the backup 

[weewx-user] (nested) Deadlocks found

[Luc Heijst]

Once a day my weewx MySQL databases are backupped, see log of the backup 
below.
The weewx programs are not stopped during these backups.
One weewx program (weewx_wbx1) crashes once in a wile (once per month) with 
a number of deadlock found messages.

It looks like weewx gets two more nested deadlock errors before a retry 
could be invoked.

Any solutions?

Backup log:
=
Taak: mysql_backup
Starttijd: Sat, 01 May 2021 03:00:02 GMT
Stoptijd: Sat, 01 May 2021 03:21:38 GMT
Huidige status: 0 (Normaal)
Standaard uitvoer/fout:
2021-05-01 03:00:03 start
2021-05-01 03:00:03 cmon11
2021-05-01 03:00:10 cmon21
2021-05-01 03:00:27 cmon31
2021-05-01 03:02:31 cmon32
2021-05-01 03:02:37 cmon33
2021-05-01 03:02:48 cmon34
2021-05-01 03:03:05 cmon35
2021-05-01 03:03:22 cmon36
2021-05-01 03:03:49 cmon37
2021-05-01 03:04:09 cmon41
2021-05-01 03:04:12 cmon42
2021-05-01 03:04:15 lightning
2021-05-01 03:04:15 mbemdevices
2021-05-01 03:05:51 weewx_klim
2021-05-01 03:07:45 weewx_mbem
2021-05-01 03:14:26 weewx_mstk
2021-05-01 03:17:18 weewx_rtld
2021-05-01 03:18:03 weewx_tfrc
2021-05-01 03:18:26 weewx_vpro
2021-05-01 03:20:06 weewx_wamo
2021-05-01 03:20:40 weewx_wamodevices
2021-05-01 03:21:21 weewx_wbx1
2021-05-01 03:21:37 finished

weewx error log:
=
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: Caught unrecoverable 
exception:
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   (1213, 
'Deadlock found when trying to get lock; try restarting transaction')
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   Traceback (most 
recent call last):
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 214, in run
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet))
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 245, in dispatchEvent
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
callback(event)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 617, in check_loop
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   raise 
BreakLoop
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
weewx.engine.BreakLoop
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   During handling 
of the above exception, another exception occurred:
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   Traceback (most 
recent call last):
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/home/weewx/bin/weedb/mysql.py", line 52, in guarded_fn
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   return 
fn(*args, **kwargs)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/home/weewx/bin/weedb/mysql.py", line 262, in execute
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
self.cursor.execute(mysql_string, tuple(sql_tuple))
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 250, in execute
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
self.errorhandler(self, exc, value)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 50, in 
defaulterrorhandler
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   raise 
errorvalue
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 247, in execute
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   res = 
self._query(query)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 411, in _query
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   rowcount = 
self._do_query(q)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 374, in _do_query
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   db.query(q)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 292, in query
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
_mysql.connection.query(self, query)
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
_mysql_exceptions.OperationalError: (1213, 'Deadlock found when trying to 
get lock; try restarting transaction')
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   
May  1 03:20:43 pi33 wbx1[495] CRITICAL __main__:   During handling 
of the above exception, another exception occurred:
May  1 03:20:43 p

[weewx-user] Re: CRITICAL __main__: **** must be real number, not NoneType OR CRITICAL __main__:*** %x formatpe or : an integer is required, not float

[Luc Heijst]

Hi Co,

The error on line 938 occurs when no single message is received from the 
Davis station during an archive interval (typical 5 minutes).
The error on line 1200 occurs when data is reveived from an analog 
temperature sensor. The 12-bit raw data is converted to 10 bits causing the 
integer type to be changed to a float.
(This type of sensor is seldom used with Davis stations.)

Luc

Op zaterdag 2 januari 2021 om 10:47:10 UTC-3 schreef covan...@gmail.com:

> Hi all,
>
>  
>
> Ik hope someone can help me to automate errorhandling………. 
>
>  
>
> The Rpi with SDR (weewx 4.2 / Mysql / apache) runs well, at inexplicable 
> moments the loop is interrupted, see parts op the logfile.
>
>  
>
> the weewx.service remains active only sub-processes have been stopped. a 
> /etc/init.d./weewx restart reactivate the loop until the next error.
>
>  
>
> Question: my idea is a workaround, does anyone know how I can read out the 
> last 6 minutes of / var / log / syslog using a cron job (or script) and if 
> a text CRITICAL __main occurs that /etc/init.d./weewx restart will be 
> executed.
>
>  
>
> or is there an easier way for a workaround.
>
> or will it cause other problems in the long term?
>
>  
>
> Thnx a lot, in the meantime I'm going to consider a reinstall on another 
> Rpi 
>
>  
>
> (29-12-202) @7:50  
>
> · weewx.engine: Main loop exiting. Shutting engine down.
>
> · weewx.engine: Shutting down StdReport thread
>
> · user.rtldavis: shutdown process /home/pi/work/bin/rtldavis -ex 
> 200 -tf EU -tr 1
>
> · user.rtldavis: rtldavis with pid 1166 killed
>
> · *CRITICAL __main__:* Caught unrecoverable exception:
>
> · CRITICAL __main__:   must be real number, not NoneType
>
>  
>
> earlier error (27-11-2020)
>
> · CRITICAL __main__:   %x format: an integer is required, 
> not float
>
>  
>
>  
>
>  
>
>  
>
>  
>
> LOGFILES -> ---
>
>  
>
> Dec 29 02:05:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:05:00 CET (1609203900) to database 'weewx'
>
> Dec 29 02:05:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:05:00 CET (1609203900) to daily summary in 'weewx'
>
> Dec 29 02:10:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:10:00 CET (1609204200) to database 'weewx'
>
> Dec 29 02:10:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:10:00 CET (1609204200) to daily summary in 'weewx'
>
> Dec 29 02:10:16 wsb-meteo weewx[1162] INFO weewx.engine: Garbage collected 
> 21556 objects in 0.09 seconds
>
> Dec 29 02:15:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:15:00 CET (1609204500) to database 'weewx'
>
> Dec 29 02:15:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:15:00 CET (1609204500) to daily summary in 'weewx'
>
> --loop still runs well 
> --
>
> Dec 29 07:45:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 07:45:00 CET (1609224300) to database 'weewx'
>
> Dec 29 07:45:17 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 07:45:00 CET (1609224300) to daily summary in 'weewx'
>
>  
>
> Error started
>
>  
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO weewx.engine: Main loop 
> exiting. Shutting engine down.
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO weewx.engine: Shutting down 
> StdReport thread
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO user.rtldavis: shutdown process 
> /home/pi/work/bin/rtldavis -ex 200 -tf EU -tr 1
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO user.rtldavis: rtldavis with 
> pid 1166 killed
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: Caught 
> unrecoverable exception:
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   must be 
> real number, not NoneType
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> Traceback (most recent call last):
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: File 
> "/home/weewx/bin/weewx/engine.py", line 210, in run
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet))
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: File 
> "/home/weewx/bin/weewx/engine.py", line 241, in dispatchEvent
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> callback(event)
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: File 
> "/home/weewx/bin/weewx/engine.py", line 630, in check_loop
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> raise BreakLoop
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> weewx.engine.BreakLoop
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
>
> Dec 29 07:50:16

[weewx-user] Re: CRITICAL __main__: **** must be real number, not NoneType OR CRITICAL __main__:*** %x formatpe or : an integer is required, not float

[Luc Heijst]

The errors are fixed in version 0.20

these are the changes:
line 935
if total_max_count > 0:
if total_max_count > 0 and self.stats['pct_good_all'] is not 
None:
line 941
if self.stats['curr_cnt'][i] > 0 and self.stats['count'][i] 
> 0:
if self.stats['curr_cnt'][i] > 0 and self.stats['count'][i] 
> 0 and self.stats['pct_good'] is not None:

line 1199
dbg_parse(2, "thermistor temp_raw=0x%03x temp_c=%s"
dbg_parse(2, "thermistor temp_raw=%s temp_c=%s"

Op zaterdag 2 januari 2021 om 10:47:10 UTC-3 schreef covan...@gmail.com:

> Hi all,
>
>  
>
> Ik hope someone can help me to automate errorhandling………. 
>
>  
>
> The Rpi with SDR (weewx 4.2 / Mysql / apache) runs well, at inexplicable 
> moments the loop is interrupted, see parts op the logfile.
>
>  
>
> the weewx.service remains active only sub-processes have been stopped. a 
> /etc/init.d./weewx restart reactivate the loop until the next error.
>
>  
>
> Question: my idea is a workaround, does anyone know how I can read out the 
> last 6 minutes of / var / log / syslog using a cron job (or script) and if 
> a text CRITICAL __main occurs that /etc/init.d./weewx restart will be 
> executed.
>
>  
>
> or is there an easier way for a workaround.
>
> or will it cause other problems in the long term?
>
>  
>
> Thnx a lot, in the meantime I'm going to consider a reinstall on another 
> Rpi 
>
>  
>
> (29-12-202) @7:50  
>
> · weewx.engine: Main loop exiting. Shutting engine down.
>
> · weewx.engine: Shutting down StdReport thread
>
> · user.rtldavis: shutdown process /home/pi/work/bin/rtldavis -ex 
> 200 -tf EU -tr 1
>
> · user.rtldavis: rtldavis with pid 1166 killed
>
> · *CRITICAL __main__:* Caught unrecoverable exception:
>
> · CRITICAL __main__:   must be real number, not NoneType
>
>  
>
> earlier error (27-11-2020)
>
> · CRITICAL __main__:   %x format: an integer is required, 
> not float
>
>  
>
>  
>
>  
>
>  
>
>  
>
> LOGFILES -> ---
>
>  
>
> Dec 29 02:05:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:05:00 CET (1609203900) to database 'weewx'
>
> Dec 29 02:05:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:05:00 CET (1609203900) to daily summary in 'weewx'
>
> Dec 29 02:10:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:10:00 CET (1609204200) to database 'weewx'
>
> Dec 29 02:10:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:10:00 CET (1609204200) to daily summary in 'weewx'
>
> Dec 29 02:10:16 wsb-meteo weewx[1162] INFO weewx.engine: Garbage collected 
> 21556 objects in 0.09 seconds
>
> Dec 29 02:15:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:15:00 CET (1609204500) to database 'weewx'
>
> Dec 29 02:15:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 02:15:00 CET (1609204500) to daily summary in 'weewx'
>
> --loop still runs well 
> --
>
> Dec 29 07:45:16 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 07:45:00 CET (1609224300) to database 'weewx'
>
> Dec 29 07:45:17 wsb-meteo weewx[1162] INFO weewx.manager: Added record 
> 2020-12-29 07:45:00 CET (1609224300) to daily summary in 'weewx'
>
>  
>
> Error started
>
>  
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO weewx.engine: Main loop 
> exiting. Shutting engine down.
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO weewx.engine: Shutting down 
> StdReport thread
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO user.rtldavis: shutdown process 
> /home/pi/work/bin/rtldavis -ex 200 -tf EU -tr 1
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] INFO user.rtldavis: rtldavis with 
> pid 1166 killed
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: Caught 
> unrecoverable exception:
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   must be 
> real number, not NoneType
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> Traceback (most recent call last):
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: File 
> "/home/weewx/bin/weewx/engine.py", line 210, in run
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet))
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: File 
> "/home/weewx/bin/weewx/engine.py", line 241, in dispatchEvent
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> callback(event)
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__: File 
> "/home/weewx/bin/weewx/engine.py", line 630, in check_loop
>
> Dec 29 07:50:16 wsb-meteo weewx[1162] CRITICAL __main__:   
> raise BreakLoop
>
> Dec 29 07:50:16 ws

Re: [weewx-user] Re: TFA Klimalogg PRO on RaspberryPi

[Luc Heijst]

Herman,
For tfrec working in Buster, see my 
post https://groups.google.com/g/weewx-user/c/b-GiJ1qkdF8
Luc

Op dinsdag 17 november 2020 om 09:51:02 UTC-3 schreef cool...@gmail.com:

> Working again...:)) A lot of changes to the config file...  Good lesson to 
> backup a working weewx.conf..
> But still interested in tfrec working in Buster..
> regards
> Herman
>
> Op dinsdag 17 november 2020 om 12:50:59 UTC+1 schreef cool...@gmail.com:
>
>> a dump from the tail of syslog:
>>
>> Nov 17 12:45:14 central weewx[20281] INFO __main__: Starting up weewx 
>> version 4.2.0
>>
>> Nov 17 12:45:14 central weewx[20281] INFO weewx.engine: Main loop 
>> exiting. Shutting engine down.
>>
>> Nov 17 12:46:14 central weewx[20281] ERROR user.kl: unable to terminate 
>> RF thread after 60 seconds
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__: Caught 
>> unrecoverable exception:
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   Unknown 
>> data binding 'u'kl_binding''
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> Traceback (most recent call last):
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__: File 
>> "/usr/share/weewx/weewxd", line 154, in main
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> engine.run()
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/engine.py", line 173, in run
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> self.dispatchEvent(weewx.Event(weewx.STARTUP))
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/engine.py", line 241, in dispatchEvent
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> callback(event)
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/engine.py", line 562, in startup
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> dbmanager = self.engine.db_binder.get_manager(self.data_binding, 
>> initialize=True)
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/manager.py", line 529, in get_manager
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> default_binding_dict=defaults)
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__: File 
>> "/usr/share/weewx/weewx/manager.py", line 634, in 
>> get_manager_dict_from_config
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> raise weewx.UnknownBinding("Unknown data binding '%s'" % e)
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   
>> UnknownBinding: Unknown data binding 'u'kl_binding''
>>
>> Nov 17 12:46:14 central weewx[20281] CRITICAL __main__:   Exiting.
>>
>>
>> Op dinsdag 17 november 2020 om 12:40:26 UTC+1 schreef cool...@gmail.com:
>>
>>> Hello Luc,
>>>
>>> Since the last update of weewx (I stupidly accepted the change in the 
>>> config file) my klimmalogg setup is broken. I tried to copy back some info 
>>> I had from previous whew.conf backups but it seems that some things are 
>>> changed within weewx itself. I can't get it to work anymore. e.g. kl.py is 
>>> not in the drivers directory. 
>>> other example is the change from  weewx.manager.WXDaySummaryManager into 
>>> weewx.manager.DaySummaryManager in the conf file. 
>>> I tried reinstalling the plugin from scratch but that didn't help 
>>> either. Any idea about this update and the impact on KL?
>>>
>>> And for sure I would like to do the same as Walter Speth and just push 
>>> the data on an MQTT topic to flow into an influxdb. So yes, a bit curious 
>>> how you got tired working. I didn't manage to go that way.
>>>
>>> Regards
>>> Herman
>>>
>>> Op maandag 24 augustus 2020 om 13:23:57 UTC+2 schreef Luc Heijst:
>>>
>>>> Hi Walter,
>>>>
>>>> I don't know if your approach is working. The software in the KlimaLogg 
>>>> PRO station is very time critical.
>>>> Perhaps you try the driver first within weewx and when it is working 
>>>> y

[weewx-user] Installattion of tfrec on Raspberry PI with Raspbian Buster

[Luc Heijst]

Program tfrec can read the data of the KlimaLogg Pro sensors directly with 
use of a rtl-sdr dongle.
The KlimaLogg Pro console is not needed anymore. The advantages are:
1. No need for pressing a USB button on the Klimalogg Pro console after 
each restart of the weewx driver.
2. No need for 'learning' the sensor data (e.g. after replacing worn out 
batteries of the console).
3. The number of Klimalogg Pro sensors are not limited to eight anymore.
4. For new configurations one doesn't have to buy the console anymore; only 
the sensors will do.

For the weewx driver see readme file of 
https://github.com/matthewwall/weewx-tfrc

For Raspbian these are the steps:

sudo apt-get install clang cmake git pkg-config librtlsdr-dev -y

b) install rtl-sdr:
cd /home/weewx
git clone https://github.com/steve-m/librtlsdr.git
cd librtlsdr
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig

c) install tfrc:
cd /home/weewx
sudo git clone https://github.com/baycom/tfrec.git
cd tfrec

For Rapbbian Stretch:
Compile tfrec source:
For RasPI3 use:
sudo make -f Makefile.arm
for RasPI 2 or Zero:
make -f Makefile.raspi2

For Raspbian Buster:
Note: In Raspbian Buster the make command gets undefined reference errors 
like:
/usr/bin/ld: sdr.o: in function `sdr::read_thread()':
sdr.cpp:(.text+0xd8): undefined reference to `rtlsdr_read_async'
 
The followings steps will fix this error:  

1. modify file /home/weewx/librtlsdr/build/librtlsdr.pc

Change the first four lines:
prefix=
exec_prefix=
libdir=
includedir=
into:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

2. modify file /home/weewx/tfrec/Makefile.arm 
(or file /home/weewx/tfrec/Makefile.raspi2 for RasPI 2 or Zero)
 
Change the first line:
PACKAGES= librtlsdr
into:
PACKAGES= /home/weewx/librtlsdr/build/librtlsdr.pc

3. repeat the make command
sudo make -f Makefile.arm
Now the make command will finish without errors:

Test tfrec:
/home/weewx/tfrec/tfrec -D -T 1

Luc

-- 
You received this message because you are subscribed 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/77c7b6df-0cf2-467f-9120-e7e9eeb7749bn%40googlegroups.com.

Re: [weewx-user] CRC-error in weewx release

[Luc Heijst]

Possible, but I downloaded the file twice. The 64-bit version 19.00 of 7zip 
had the error.
I tried the 20.02 alpha version of 7zip and this version had no problems 
with the unpacking.

Op maandag 9 november 2020 om 23:55:46 UTC-3 schreef Cameron D:

> I just tried it on a windows 10 system, 7zip had no problems - Was it just 
> a corrupted download?
>
> On Monday, 9 November 2020 at 12:30:50 am UTC+10 Luc Heijst wrote:
>
>> Tom,
>>
>> So far 7zip never gave problems with unzipping weewx .tar.gz files.
>> Just installed winzip version 25 (evaluation version) and this program 
>> couldn't uncompress the 4.2.0 file at all.
>>
>> The following Win10 command (runned as administrator) worked without 
>> errors:
>> tar -xvzf C:\Users\ljmhe\Downloads\weewx-4.2.0.tar.gz -C 
>> C:\Users\ljmhe\Downloads\lh
>>
>> Luc
>>
>> Op zondag 8 november 2020 om 10:55:07 UTC-3 schreef tke...@gmail.com:
>>
>>> Probably an issue with 7zip. Why not just use an ordinary 'tar' command?
>>>
>>> *tar xvf weewx-4.2.0.tar.gz*
>>>
>>> -tk
>>>
>>> On Sun, Nov 8, 2020 at 4:50 AM Luc Heijst  wrote:
>>>
>>>> Tom, Matthew,
>>>> File weewx.com/downloads/weewx-4.2.0.tar.gz got a 'CRC failed' error 
>>>> when unpacked with 7zip. The release only contains the directory 'bin'.
>>>>
>>>> -- 
>>>> You received this message because you are subscribed 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/e2144291-e0cc-4e7b-900c-8382ebeb4f05n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/e2144291-e0cc-4e7b-900c-8382ebeb4f05n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/58db58cb-8708-4355-a3f2-649363cfb112n%40googlegroups.com.

Re: [weewx-user] CRC-error in weewx release

[Luc Heijst]

Tom,

So far 7zip never gave problems with unzipping weewx .tar.gz files.
Just installed winzip version 25 (evaluation version) and this program 
couldn't uncompress the 4.2.0 file at all.

The following Win10 command (runned as administrator) worked without errors:
tar -xvzf C:\Users\ljmhe\Downloads\weewx-4.2.0.tar.gz -C 
C:\Users\ljmhe\Downloads\lh

Luc

Op zondag 8 november 2020 om 10:55:07 UTC-3 schreef tke...@gmail.com:

> Probably an issue with 7zip. Why not just use an ordinary 'tar' command?
>
> *tar xvf weewx-4.2.0.tar.gz*
>
> -tk
>
> On Sun, Nov 8, 2020 at 4:50 AM Luc Heijst  wrote:
>
>> Tom, Matthew,
>> File weewx.com/downloads/weewx-4.2.0.tar.gz got a 'CRC failed' error 
>> when unpacked with 7zip. The release only contains the directory 'bin'.
>>
>> -- 
>> You received this message because you are subscribed 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/e2144291-e0cc-4e7b-900c-8382ebeb4f05n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/e2144291-e0cc-4e7b-900c-8382ebeb4f05n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/bd3997c5-64b3-4d04-be76-7c237e38bf8bn%40googlegroups.com.

[weewx-user] CRC-error in weewx release

[Luc Heijst]

Tom, Matthew,
File weewx.com/downloads/weewx-4.2.0.tar.gz got a 'CRC failed' error when 
unpacked with 7zip. The release only contains the directory 'bin'.

-- 
You received this message because you are subscribed 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/e2144291-e0cc-4e7b-900c-8382ebeb4f05n%40googlegroups.com.

[weewx-user] Database deadlock during database backup

[Luc Heijst]

My weewx application TFRC crashed during the backup of the database, see 
logging below.

Weewx version: 4.1.1
Python version: 3.7.3.
on Raspberry PI 3B+

Database: MariaDB 10.3.21-0063 on Synology NAS in the same local network

Usually a weewx program continues after the short period a database is not 
available (duration typically 90 seconds or less), but this time a database 
deadlock occurred.

Note: I did not set "loop_on_init = True" in weewx_tfrc.conf, but I wonder 
if weewx was restarted in this case if I did include the loop_on_init 
command.

Luc


Jun 16 03:10:20 pi31 tfrc[490] INFO user.tfrc: shutdown process 
/home/weewx/tfrec/tfrec -D -T 1
Jun 16 03:10:20 pi31 tfrc[490] INFO user.tfrc: tfrec with pid 6712 killed
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: Caught unrecoverable 
exception:
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   (1213, 
'Deadlock found when trying to get lock; try restarting transaction')
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   Traceback (most 
recent call last):
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 195, in run
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet))
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 224, in dispatchEvent
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
callback(event)
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 578, in check_loop
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   raise 
BreakLoop
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
weewx.engine.BreakLoop
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   During handling 
of the above exception, another exception occurred:
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   Traceback (most 
recent call last):
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 594, in post_loop
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
self._catchup(self.engine.console.genArchiveRecords)
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 638, in _catchup
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   for record 
in generator(lastgood_ts):
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weewx/drivers/__init__.py", line 30, in genArchiveRecords
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   raise 
NotImplementedError("Method 'genArchiveRecords' not implemented")
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
NotImplementedError: Method 'genArchiveRecords' not implemented
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   During handling 
of the above exception, another exception occurred:
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   Traceback (most 
recent call last):
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weedb/mysql.py", line 52, in guarded_fn
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   return 
fn(*args, **kwargs)
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/home/weewx/bin/weedb/mysql.py", line 262, in execute
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
self.cursor.execute(mysql_string, tuple(sql_tuple))
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 250, in execute
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   
self.errorhandler(self, exc, value)
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 50, in 
defaulterrorhandler
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   raise 
errorvalue
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 247, in execute
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   res = 
self._query(query)
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 411, in _query
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   rowcount = 
self._do_query(q)
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__: File 
"/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 374, in _do_query
Jun 16 03:10:20 pi31 tfrc[490] CRITICAL __main__:   db.quer

[weewx-user] Re: FUN with RPi

[Luc Heijst]

Xant,

The smart meter was no part of my house power installation. The 
installation has three phase 230 V, mainly for the airco’s and three phase 
130 V for equipment and light.
I have installed the smart meter myself. By wiring 3 phase wires (6 mm2) 
from the main power switch to the smart meter and the 3 outgoing wires to 
the power rails. I followed studies electro technics, so I know what I’m 
doing.
The maximum input current of the meter is 100 A, so I didn’t have to use 
extra current transformers.
I bought a modbus to usb adapter which is wired to one of the usb inputs of 
the raspberry pi.

So, without a smart power meter with a modbus interface you are not a 
candidate for my modbus energy monitor I’m afraid.

Luc


On Monday, 8 June 2020 17:54:50 UTC-3, Xant wrote:
>
>
> Luc
>
> The Modbus Energy Monitor seems very enticing as next RPi Project.
>
> But as seen in snapshots your house power-panel seems much more "cleaner" 
> and high-tech than mine, which has the usual standard (and probably old) 
> power-switches/circuit-breaker and no "smart-meter".
>
> That said, think my house may not be a "candidate" for Modbus Energy 
> Monitor, correct?
>
> Xant
>

-- 
You received this message because you are subscribed 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/d8798a8f-8ee0-42f3-b579-bca6a3a4e1a2o%40googlegroups.com.

[weewx-user] Re: FUN with RPi

[Luc Heijst]

I use my Raspberry Pi model 2B as an airprint server for my old HP Laserjet 
4050 printer.

See: 
https://www.reddit.com/r/raspberry_pi/comments/dbknom/how_to_turn_your_old_usbonly_hp_printer_into_a/

Note: the printer has a Centronix serial connection, I use a serial to USB 
adapter cable between the printer and the RPI.

The printer is automaticly recognised by my iPad 6 (IOS 13.4.1) and Windows 
laptop (Windows 10 - 64 bits).

Luc

-- 
You received this message because you are subscribed 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/94001219-95f6-4899-94da-98039afb9fd4o%40googlegroups.com.

[weewx-user] Re: meteostick - rf_sensitivity (90)

[Luc Heijst]

Joachim,

In the Meteostick section of weewx.conf. change the rf_sensitivity 
parameter followed by a restart of weewx..

[Meteostick]
rf_sensitivity = 90

Luc


On Wednesday, 3 June 2020 07:44:42 UTC-3, Joachim Puttkammer wrote:
>
> Hi
>
> WARNING: rf_sensitivity (90) might be too low for channel 4
>
> where can I change the sensitivity?
>
> Joachim
>

-- 
You received this message because you are subscribed 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/2fb9376d-8916-4f03-87e8-677ae7a2ec1c%40googlegroups.com.

[weewx-user] Re: Can't run from USB-disk in debian buster on Raspberry PI models 1B and 2B (SOLVED)

[Luc Heijst]

Another approach for setting up the wifi is connect the RPi (the first 
time) with an ethernet cable to the network, 
Remote log in with a putty session and configure wifi with raspi-config.
I also configure a static ip-address for the network module(s) in my router.
BTW the models 1B and 2B don’t have on board wifi.

On Sunday, 31 May 2020 19:27:44 UTC-3, vince wrote:
>
> On Sunday, May 31, 2020 at 1:47:51 PM UTC-7, Luc Heijst wrote:
>>
>> The boot process from a USB-stick as described above is simplified.
>> See: 
>> https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md
>>
>>
>>
> I might add - add a correct wpa_supplicant.conf file as well, if you want 
> to bring up wifi at first boot without needing a keyboard and monitor to 
> configure things.
>

-- 
You received this message because you are subscribed 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/241832ba-891d-41ce-8289-acbf1e8e0689%40googlegroups.com.

[weewx-user] Re: Can't run from USB-disk in debian buster on Raspberry PI models 1B and 2B (SOLVED)

[Luc Heijst]

The boot process from a USB-stick as described above is simplified.
See: 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md

Follow these steps:
1. Format a SD-card with fat32.
2. Write file bootcode.bin to the SD-card.
3. Write with program balenaEther the zip file of Raspbian Buster (aka 
Raspberry Pi OS (32-bit)) to the USB-stick.
4. To enable ssh, write an empty file with name 'ssh' to the root of the 
USB-stick.
5. Put both SD-card and USB-stick in the Raspberry PI 2 B (or PI B) slots.
Power up the RPi 2B

Done!



On Saturday, 4 April 2020 09:56:48 UTC-3, Luc Heijst wrote:
>
> I used to change the root=PARTUUID= setting in cmdline.txt of the (micro) 
> sd-card of RPI 1B and 2B models to the PARTUUID of the USB-disk.
> Then the RPI will run with root on the SDA parttion.
>
> When raspbian buster (or the latest version of stretch) is written with 
> balenaEtcher, both sd-card and usb-disk get the same PARTUUID. See below.
>
> blkid
> /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" 
> TYPE="vfat" PARTUUID="738a4d67-01"
> /dev/mmcblk0p2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
> TYPE="ext4" PARTUUID="738a4d67-02"
> /dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" 
> PARTUUID="738a4d67-01"
> /dev/sda2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
> TYPE="ext4" PARTUUID="738a4d67-02"
> /dev/mmcblk0: PTUUID="738a4d67" PTTYPE="dos"
>
> With the set-ptuuid script downloaded from:
> https://www.raspberrypi.org/forums/viewtopic.php?t=253562 we can change 
> the PARTUUID of the USB-disk (or the sd-card).
> The script also changes the PARTUUID settings in cmdline.txt and other 
> files.
>
> Example
> =
> Boot from the sd-card with the usb-disk connected
>
> Now change the PTUUID of the USB-disk
> ./set-ptuuid /dev/sda random
> Set PTUUID on /dev/sda to e4f3c2c9 (y/n)?
> PTUUID on /dev/sda is set to e4f3c2c9
>
> blkid
> /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" 
> TYPE="vfat" PARTUUID="738a4d67-01"
> /dev/mmcblk0p2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
> TYPE="ext4" PARTUUID="738a4d67-02"
> /dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" 
> PARTUUID="e4f3c2c9-01"
> /dev/sda2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
> TYPE="ext4" PARTUUID="e4f3c2c9-02"
> /dev/mmcblk0: PTUUID="738a4d67" PTTYPE="dos"
>
> cat cmdline.txt
> console=serial0,115200 console=tty1 root=PARTUUID=e4f3c2c9-02 
> rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet 
> init=/usr/lib/raspi-config/init_resize.sh
>
> Now reboot the RPI with the sd-card and USB-disk still connected
> The RPI will now have it's root set to /dev/sda2
>
> cat /etcfstab
> proc/proc   procdefaults  0   0
> PARTUUID=e4f3c2c9-01  /boot   vfatdefaults  0   2
> PARTUUID=e4f3c2c9-02  /   ext4defaults,noatime  0   1
> # a swapfile is not a swap partition, no line here
> #   use  dphys-swapfile swap[on|off]  for that
> =
>
> Luc
>

-- 
You received this message because you are subscribed 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/9271e240-75bf-4e13-9150-50c9f443030a%40googlegroups.com.

[weewx-user] Installattion of tfrec on Raspberry PI with Raspbian Buster

[Luc Heijst]

See readme file of https://github.com/matthewwall/weewx-tfrc


For Raspbian Stretch and Raspbian Buster these are the steps:


sudo apt-get install clang cmake git pkg-config librtlsdr-dev -y


b) install rtl-sdr:

cd /home/weewx

git clone https://github.com/steve-m/librtlsdr.git

cd librtlsdr

mkdir build

cd build

cmake ../ -DINSTALL_UDEV_RULES=ON

make

sudo make install

sudo ldconfig


c) install tfrc:

cd /home/weewx

sudo git clone https://github.com/baycom/tfrec.git

cd tfrec


For Rapbbian Stretch

Compile tfrec source:

For RasPI3 use:

sudo make -f Makefile.arm

for RasPI 2 or Zero:

make -f Makefile.raspi2


For Raspbian Buster:

Note: In Raspbian Buster the make command gets undefined reference errors 
like:

/usr/bin/ld: sdr.o: in function `sdr::read_thread()':

sdr.cpp:(.text+0xd8): undefined reference to `rtlsdr_read_async'


The followings steps will fix this error: 


1. modify file /home/weewx/librtlsdr/build/librtlsdr.pc


Change the first four lines:

prefix=

exec_prefix=

libdir=

includedir=

into:

prefix=/usr/local

exec_prefix=${prefix}

libdir=${exec_prefix}/lib

includedir=${prefix}/include


2. modify file /home/weewx/tfrec/Makefile.arm 

(or file /home/weewx/tfrec/Makefile.raspi2 for RasPI 2 or Zero)


Change the first line:

PACKAGES= librtlsdr

into:

PACKAGES= /home/weewx/librtlsdr/build/librtlsdr.pc


3. repeat the make command

sudo make -f Makefile.arm

Now the make command will finish without errors


Test tfrec:

/home/weewx/tfrec/tfrec -D -T 1


Luc

-- 
You received this message because you are subscribed 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/9b70d249-95fa-4ca4-b71b-a61f38166983%40googlegroups.com.

Re: [weewx-user] Looking for somewhat 'open' weather station to use with Raspberry based projects

[Luc Heijst]

Tom,

The data protocol of their (not so cheap) data-loggers is publiced by 
Davis, but I know from first hand that the raw data the sensors send to the 
console is not public. I have put a lot of time in decoding the signals 
(among others) and still we don’t know the full protocol yet.

Luc

On Sunday, 17 May 2020 21:34:27 UTC-3, Tom Keffer wrote:
>
> Just to correct the record, the Vantage protocol was not reverse 
> engineered. They are one of the few vendors who have published their 
> protocol 
> ,
>  
> and have for many years.
>
> On Sun, May 17, 2020 at 5:13 PM Greg Troxel > 
> wrote:
>
>> "'Ben Luria' via weewx-user" > 
>> writes:
>>
>> > apologies if this topic came up before or in case I am off-topic here. 
>> I'm 
>> > toying with SDR and home automation on a Raspberry Pi and would like to 
>> add 
>> > weather data via WeeWX and a weather station. Is there any particular 
>> brand 
>> > / model I should go for or maybe avoid? Am looking for something solar 
>> > powered optimally, but that is not a must.
>>
>> You put "open" in quotes, which means that I don't know what you mean by
>> that word :-)
>>
>> There are a few things you could mean:
>>
>>   1) well-understood interfaces and existing drivers so that you can get
>>   at the weather data and use it, and not have problems due to closed
>>   interfaces
>>
>>   2) open protocol, or perhaps reverse-engineered protocols, for the
>>   sensor suite (outside part) to talk to the console (inside, that you
>>   look at, and that usually is interfaced to a computer), so that you
>>   can sniff it with an SDR instead of using the console receiver.
>>
>>   3) being able to get at the weather data locally, without the device
>>   talking to some cloud service (not under your control, subject to the
>>   company stopping it, and likely run with proprietary software)
>>
>>   3A) separately from transport via cloud, can the local station produce
>>   observations by itself, or does it need a (perhaps implemented with
>>   proprietary software) cloud service to do that?
>>
>>   4) firmware/software for the weather station equipment being open source
>>
>>   5) an open hardware design for the station, even if it uses proprietary
>>   chips
>>
>>   6) full-on open, meaning open licenses for all silicon in the station,
>>   including CPUs and sensors, which leads you to RISC-V and for
>>   temp/humidity I'm really not sure what.
>>
>>
>> You mentioned home automation, so I would recommend you check out the
>> mqtt extension, which is I think what most use to bridge weewx data into
>> an automation system (such as Home Assistant, which is the natural
>> choice for weewx fans, being open source and python).
>>   https://github.com/weewx/weewx/wiki/mqtt
>>
>>
>> For 1, there are lots of choices, and basically you should look at what
>> weewx supports.
>>
>> For 2, I am not really aware of anything open, except for build-your-own
>> kinds of stations.  But maybe weatherflow is UDP over IP and counts
>> here.  The Davis VP2 protocol has been reverse engineered and there is
>> rtldavis.  However, the Davis datalogger/interface in the console has
>> the really nice property that when your computer goes down, it keeps
>> storing data, and then when you straighten out your computer from the
>> botched upgrade, or you get power back, weewx reads the data and your
>> historical record is 100% fine, as if you never went down.   So I don't
>> really want to get my data with an SDR on a unix computer, even though
>> I'd like to try that, because I really like it that I haven't lost data
>> the probably 6 times I've had an issue in about 2.5 years.
>>
>> For 3, Davis is fine, and some acurite setups have local USB.  Various
>> other systems have "interceptor" drivers that snoop the data going to
>> the cloud, and I have the impression that sometimes people fetch their
>> own data back from the cloud because that's all they can do.
>>
>> For 3a, note Vince's comments about weatherflow and rain.  (I think
>> weatherflow is really interesting and don't mean to knock them.  I just
>> find the notion that you don't know how much rain you got without the
>> internet quite curious.  On the other hand sometimes with Davis it rains
>> and you conclude from the readings that you have a bird's nest, wasp's
>> nest or pine needles in your rain collector or blocking the tipping
>> bucket from tipping.)
>>
>> For 4, and even more so for 5, I'm not aware of any contenders, other
>> than build-your-own with arduino and e.g. i2c sensors.  But this is
>> very interesting and may qualify:
>>   
>> https://www.tinkerforge.com/en/doc/Kits/WeatherStation/WeatherStation.html
>>   https://www.tinkerforge.com/en/shop/bricklets/sensors.html
>> However, I don't see rain and wind.
>>
>> For 6, my impresssion is that I will be viewed as crazy just for
>> bringing it up.
>>
>>
>> T

Re: [weewx-user] Re: Interceptor 0.40 "skipping rain measurement"

[Luc Heijst]

Tom,

When a check is done on the timestamp of the last_rain value in the 
database, we could skip using the value when it is too old, e.g. elder than 
twice the archive period.

Luc

On Sunday, 19 August 2018 18:16:50 UTC-3, Thomas Keffer wrote:
>
> (btw, one utility function that might be useful for driver developers 
>> would be to get the last rain total from the database, if one exists.  then 
>> we could use that value instead of just saying "no last value".  almost 
>> every driver has to deal with this for rain or any other delta 
>> observations.)
>>
>>
> Hmm, I guess I don't like that idea so much. 
>
> The last value in the database is likely to be very out-of-date, resulting 
> in an archive record with a big value of rain. That violates our 2nd and 
> 3rd laws for writing a device driver 
> : don't make 
> stuff up.
>
> -tk
>

-- 
You received this message because you are subscribed 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/b4e48146-370b-4f2d-8d81-70bda15034a2%40googlegroups.com.

[weewx-user] Re: Interceptor 0.40 "skipping rain measurement"

[Luc Heijst]

Matthew,

The last_rain value is set to None in the driver init section. Each time 
the driver is started during rainfall we will miss the registered value of 
the last archive period. Why not write value last_rain to the database and 
read it back next archive cycle?

Luc

On Sunday, 19 August 2018 11:45:29 UTC-3, mwall wrote:
>
>
>
> On Monday, August 13, 2018 at 4:30:43 PM UTC-4, G Hammer wrote:
>>
>> I have been having fairly steady rain here and see this come up in the 
>> logs.
>> Aug 13 15:48:32 PlexSrv weewx[14290]: interceptor: MainThread: skipping 
>> rain measurement of 0.03: no last rain
>>
>> Once this happens, the rain total is off for further periods.
>> For example, once I saw the 0.03 skipped entry here, the rainfall amount 
>> stayed at 0.03
>> Ambient and WU both have a higher amount recorded.
>>
>> I'll look at this again later as another rain shower hits and see if the 
>> total changes and is correct compared to Ambient and WU.
>>
>
> what kind of weather station is this?
>
> do you ever see this other than when weewx starts up?
>
> please be more specific about "the rain total is off for further periods".
>
> the rain values in weewx are delta measurements, but most hardware reports 
> rain totals.  so any driver must have two data points before it can report 
> a value for rain delta.
>
> the message "skipping rain measurement...: no last rain" indicates that 
> the driver got a non-zero value for the rain total, but since it had no 
> previous value it cannot calculate a rain delta.
>
> the message lets you know that some rain data might have been missed.
>
> (btw, one utility function that might be useful for driver developers 
> would be to get the last rain total from the database, if one exists.  then 
> we could use that value instead of just saying "no last value".  almost 
> every driver has to deal with this for rain or any other delta 
> observations.)
>
> if the weewx rain totals do not agree with a canonical reference, you can 
> fix your rain counts by manually adding values to the weewx database
>
> m
>

-- 
You received this message because you are subscribed 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/cd71181a-1545-48a3-904d-499d69b8287b%40googlegroups.com.

[weewx-user] weewx-cmon doesn't read cpu_temp of Raspberri PI

[Luc Heijst]

Recently I downloaded the latest version of weewx-cmon (v 0.20) which was 
converted to use with python3.
This version, and also elder versions of cmon.py, did not read the cpu-temp 
of my Raspberri PI systems (models 1B, 2B, 3B and 3B+).

On my raspberry PI the following statement is true: *os.path.exists(tdir)*, 
still 
a cpu-temp could not be found in this section
The *elif os.path.exists(tfile):* statement caused the bottem section to be 
skipped and that is the section that reads the RPI cpu-temp.

See the modifications in yellow which fixed this problem.

Luc

--- snipped of cmon.py ---
# read cpu temperature
tdir = '/sys/class/hwmon/hwmon0/device'
# rpi keeps cpu temperature in a different location
tfile = '/sys/class/thermal/thermal_zone0/temp'
*temp_found = False*
if os.path.exists(tdir):
try:
for f in os.listdir(tdir):
if f.endswith('_input'):
s = self._readproc_line(os.path.join(tdir, f))
if s and len(s):
*temp_found = True*
n = f.replace('_input', '')
t_C = int(s) / 1000 # degree C
record['cpu_' + n] = t_C
except Exception as e:
logdbg("read failed for %s: %s" % (tdir, e))
### elif os.path.exists(tfile):  ### original statement
if* not temp_found and *os.path.exists(tfile):
try:
s = self._readproc_line(tfile)
t_C = int(s) / 1000 # degree C
record['cpu_temp'] = t_C
except Exception as e:
logdbg("read failed for %s: %s" % (tfile, e))

---

-- 
You received this message because you are subscribed 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/db0db811-94ac-4762-ad31-9eb39b561bb9%40googlegroups.com.

[weewx-user] Re: Weewx will only work for a week then stops

[Luc Heijst]

Hi Luc,

The error:
ValueError: accum: ScalarStats.addHiLo expected float or int, got type 
'' ('4552332')
is caused by an old version of weewx_cmon. The latest version (0.20) solves 
this, See: https://github.com/matthewwall/weewx-cmon

Also your syslog show several errors with outTemp, like:
cheetahgenerator:  Reason: Unknown daily summary type outTemp

Check your database if you have a value outTemp. 
If not, check your skin files for the use of outTemp.

Luc Heijst

On Saturday, 2 May 2020 02:33:45 UTC-3, Luc Theoret wrote:
>
> Hi,
>
> I have been trying to get weewx to record my acurite data using sdr 
> RTL_433 for about a year now.
> The system I have almost running is a raspberry pi 3 running on respbian 
> stretch. it has an external real time clock attached.
> weewx runs consistently for a week then stops. I was finally find the log 
> entry for the stop, see attached file.
> In the file is the last successful update, then the error and the exit. 
> I also included the config file.
>
>
> I have tried to reinstall on new SD card with Buster but cannot get the 
> radio to work. tried blackballing stuff blindly (not knowing what doing).
> Then I went back to this SD card. changed a couple of things and it ran. 
> But as usual after a week like clockwork it stopped.
>
> Luc
>

-- 
You received this message because you are subscribed 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/9aee7de0-73d0-4290-8c36-2b99c2cc28eb%40googlegroups.com.

[weewx-user] Can't run from USB-disk in debian buster on Raspberry PI models 1B and 2B (SOLVED)

[Luc Heijst]

I used to change the root=PARTUUID= setting in cmdline.txt of the (micro) 
sd-card of RPI 1B and 2B models to the PARTUUID of the USB-disk.
Then the RPI will run with root on the SDA parttion.

When raspbian buster (or the latest version of stretch) is written with 
balenaEtcher, both sd-card and usb-disk get the same PARTUUID. See below.

blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" 
TYPE="vfat" PARTUUID="738a4d67-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
TYPE="ext4" PARTUUID="738a4d67-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" 
PARTUUID="738a4d67-01"
/dev/sda2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
TYPE="ext4" PARTUUID="738a4d67-02"
/dev/mmcblk0: PTUUID="738a4d67" PTTYPE="dos"

With the set-ptuuid script downloaded 
from:https://www.raspberrypi.org/forums/viewtopic.php?t=253562 we can 
change the PARTUUID of the USB-disk (or the sd-card).
The script also changes the PARTUUID settings in cmdline.txt and other 
files.

Example
=
Boot from the sd-card with the usb-disk connected

Now change the PTUUID of the USB-disk
./set-ptuuid /dev/sda random
Set PTUUID on /dev/sda to e4f3c2c9 (y/n)?
PTUUID on /dev/sda is set to e4f3c2c9

blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" 
TYPE="vfat" PARTUUID="738a4d67-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
TYPE="ext4" PARTUUID="738a4d67-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" 
PARTUUID="e4f3c2c9-01"
/dev/sda2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" 
TYPE="ext4" PARTUUID="e4f3c2c9-02"
/dev/mmcblk0: PTUUID="738a4d67" PTTYPE="dos"

cat cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=e4f3c2c9-02 
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet 
init=/usr/lib/raspi-config/init_resize.sh

Now reboot the RPI with the sd-card and USB-disk still connected
The RPI will now have it's root set to /dev/sda2

cat /etcfstab
proc/proc   procdefaults  0   0
PARTUUID=e4f3c2c9-01  /boot   vfatdefaults  0   2
PARTUUID=e4f3c2c9-02  /   ext4defaults,noatime  0   1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
=

Luc

-- 
You received this message because you are subscribed 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/69b6640f-7752-430b-8fe9-d50539243ff9%40googlegroups.com.

[weewx-user] Re: Weewx crashing with error associated with ScalarStats.addHiLo

[Luc Heijst]

On Tuesday, 7 May 2019 03:50:13 UTC-3, Redanman wrote:
>
> My system configuration is :
> cmon version = 0.16
>

Hi Redanman,

This is a known issue, see: 
https://groups.google.com/forum/#!searchin/weewx-user/cmon%7Csort:date/weewx-user/p8xhPGK38s4/a3HAj6eFCQAJ

For 64-bit systems the net stats values will have type bigint in python2 
when they have reached their max values.
Note: Even when the net stats value is in the range of 0..maxint, the type 
will still be bigint in such a case.
See my solutions in the tread mentioned.

Luc 

-- 
You received this message because you are subscribed 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/3ea181a1-f4c9-4851-b6e0-629cb5eeb9ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle Update

[Luc Heijst]

On Sunday, 21 April 2019 01:54:08 UTC-3, rich T wrote:
>
> Not saying there is an issue, but just check it at your end.
>

Rich,

Today it's very rainy in Paramaribo. Total 68.2 mm rain in the morning. 
There is more rain expected this noon.

Both meteostick and rtldavis show the same rain values.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle Update

[Luc Heijst]

On Saturday, 20 April 2019 00:32:42 UTC-3, rich T wrote:
>
> Did you observed any differences with the rain total?
>
> I will have a look the coming days.. Until a week ago we had the longest 
period without rain here and recently I reorganized all my pi-systems and 
got no reliable data.
Also I have two Vantage Pro 2 systems. I will check the results of the 
meteostick with the rtldavis.driver which will both read the data of three 
Davis stations (ISS, wind and leaf-soil).

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle Update

[Luc Heijst]

On Friday, 19 April 2019 15:41:17 UTC-3, kobuki wrote:
>
> Right, but the point is, another driver most likely won't fix it.
>

I installed the (depreciated) Adafruit driver (Adafruit_Python_BMP-master) 
for the BMP280. Same pressure results as you already pointed out.
I have now set a correction of -4.0 hPa in weewx-rtldavis.
 [StdCalibrate] 
[[Corrections]]
pressure = pressure - 4.0 # BMP280 sensor reading too high

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle Update

[Luc Heijst]

On Friday, 19 April 2019 15:09:03 UTC-3, kobuki wrote:
>
> Most cheap modules use chips of unknown origin and I've seen variance 
> between samples in the past
>

My Adafruit BMP280 chip wasn't cheap:12.95 euro. I have seen other 'BMP280' 
chips priced as low as 3.75 Euro

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle Update

[Luc Heijst]

On Tuesday, 16 April 2019 23:21:13 UTC-3, rich T wrote:
>
> Drivers I'm currently using are:
> bme280wx  https://gitlab.com/wjcarpenter/bme280wx
>
> Rich,

I followed the instructions for my BMP280 sensor in your link because 
WJCarpenter wrote in the release notes of bme280wx: "This interface seems 
to work correctly for a BMP280 as well" 

I did gave it a try and I think WJCarpenter is wrong. The pressure readings 
I get from my BMP280 sensor are way higher than my other preasure readings, 
see table below.

Vantage Pro console:1009.23794422608
Meteostick: 1009.266
Weather365 Wetterbox:   1010.935
Rtldavis with BME280wx: 1013.28862385024

BTW. The BMP280 module has I2C address 0x77, so I had to change that in the 
BME280 setting.

So, work to do to find a better BMP280 driver.

Luc 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

On Thursday, 4 April 2019 12:25:44 UTC-3, Thomas Keffer wrote:
>
> Interesting that the post to weather365 has a timestamp of 1554322200. Any 
> thoughts why the timestamp for the AWEKAS uploader would be different?
>

Tom,

I'm so sorry!

I just discovered that I copied accidently restx v4.0.0 to the v3.9.1 
environment. So all time we were looking at the wrong version.
Strange enough the 4.0.0 version of restx could run in the 3.9.1 
environment without (other) errors.

Sorry I have wasted your time.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

Tom, 

Below the data sent to weather365, just before the exception:
It has time stamp 1554322200, so the record was stored in the database in 
time. Notice how few data is present (because NULL/None data is not send).

raind=0.00
txbattery=0
soiltemp3=28.8
datum=201904031710
long=-55.21904
rainh=0.00
prec_time=60
lat=5.82184
et=0.01901
alt=4.0
relhum=66
windrun=103.3
utcstamp=1554322200

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

On Thursday, 4 April 2019 11:57:12 UTC-3, Thomas Keffer wrote:
>
> Well, then there are two possibilities:
> 1.  r['dateTime'] was a different value than 1554322200; or
> 2. There was some kind of delay getting the record into the database. The 
> AWEKAS code did its query before the record had appeared.
>

As you can see at the syslog below, record with time stamp 1554322200 is 
stored at 17:10:13, one second before the exception.

Apr  3 17:10:13 pi21 mstk[14530]: manager: Added record 2019-04-03 17:10:00 
-03 (1554322200) to database 'weewx_mstk'
Apr  3 17:10:14 pi21 mstk[14530]: manager: Added record 2019-04-03 17:10:00 
-03 (1554322200) to daily summary in 'weewx_mstk'
Apr  3 17:10:14 pi21 mstk[14530]: reportengine: Running reports for latest 
time in the database.
Apr  3 17:10:14 pi21 mstk[14530]: reportengine: Report 'SeasonsReport' not 
enabled. Skipping.
Apr  3 17:10:14 pi21 mstk[14530]: reportengine: Report 'SmartphoneReport' 
not enabled. Skipping.
Apr  3 17:10:14 pi21 mstk[14530]: reportengine: Report 'MobileReport' not 
enabled. Skipping.
Apr  3 17:10:14 pi21 mstk[14530]: reportengine: Report 'StandardReport' not 
enabled. Skipping.
Apr  3 17:10:14 pi21 mstk[14530]: reportengine: Running report 'mstkReport'
Apr  3 17:10:14 pi21 klim[13367]: KlimaLogg: RFComm: handleHistoryData: 
time=2019-04-03 17:10:00 this=17229 (0xf69a0) latest=17229 (0xf69a0) nrec=0
Apr  3 17:10:14 pi21 mstk[14530]: restx: Weather365: url: 
https://channel1.weather365.net/stations/index.php?soilmoisture3=200.0&raind=0.00&txbattery=0&soiltemp3=28.8&datum=201904031710&long=-55.21904&stationid=285CDPC186&rainh=0.00&prec_time=60&lat=5.82184&et=0.01901&alt=4.0&relhum=66&windrun=103.3&utcstamp=1554322200
Apr  3 17:10:14 pi21 mstk[14530]: restx: AWEKAS: Unexpected exception of 
type 
Apr  3 17:10:14 pi21 mstk[14530]: restx: Weather365: Data uploaded to 
https://channel1.weather365.net/stations/index.php is: 
(https://channel1.weather365.net/stations/index.php?soilmoisture3=200.0&raind=0.00&txbattery=0&soiltemp3=28.8&datum=201904031710&long=-55.21904&stationid=285CDPC186&rainh=0.00&prec_time=60&lat=5.82184&et=0.01901&alt=4.0&relhum=66&windrun=103.3&utcstamp=1554322200)
Apr  3 17:10:14 pi21 mstk[14530]: *** Traceback (most recent call last):
Apr  3 17:10:14 pi21 mstk[14530]: reportengine: Found configuration file 
/home/weewx/skins/mstk/skin.conf for report 'mstkReport'
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/weewx/restx.py", line 350, in run_loop
Apr  3 17:10:14 pi21 mstk[14530]: *** self.process_record(_record, 
dbmanager)
Apr  3 17:10:14 pi21 mstk[14530]: restx: WeatherCloud: Unexpected exception 
of type 
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/weewx/restx.py", line 1693, in process_record
Apr  3 17:10:14 pi21 mstk[14530]: *** r = self.get_record(record, 
dbmanager)
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/weewx/restx.py", line 1689, in get_record
Apr  3 17:10:14 pi21 mstk[14530]: *** r['rainRate'] = rr[0]
Apr  3 17:10:14 pi21 mstk[14530]: *** TypeError: 'NoneType' object has no 
attribute '__getitem__'
Apr  3 17:10:14 pi21 mstk[14530]: restx: AWEKAS: Thread exiting. Reason: 
'NoneType' object has no attribute '__getitem__'
Apr  3 17:10:14 pi21 mstk[14530]: *** Traceback (most recent call last):
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/weewx/restx.py", line 350, in run_loop
Apr  3 17:10:14 pi21 mstk[14530]: *** self.process_record(_record, 
dbmanager)
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/user/wcloud.py", line 249, in process_record
Apr  3 17:10:14 pi21 mstk[14530]: *** r = self.get_record(record, dbm)
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/user/wcloud.py", line 271, in get_record
Apr  3 17:10:14 pi21 mstk[14530]: *** if rec['windDir'] is not None:
Apr  3 17:10:14 pi21 mstk[14530]: *** KeyError: 'windDir'
Apr  3 17:10:14 pi21 mstk[14530]: restx: WeatherCloud: Thread exiting. 
Reason: 'windDir' 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

On Thursday, 4 April 2019 11:21:08 UTC-3, Thomas Keffer wrote:
>
>  It is None because the record *was not in the database*. Why?
>

I don't agree: the record *is* in the database; these are the values:

INSERT INTO `archive` (`dateTime`, `usUnits`, `interval`, `barometer`, 
`pressure`, `altimeter`, `inTemp`, `outTemp`, `inHumidity`, `outHumidity`, 
`windSpeed`, `windDir`, `windGust`, `windGustDir`, `rainRate`, `rain`, 
`dewpoint`, `windchill`, `heatindex`, `ET`, `radiation`, `UV`, 
`extraTemp1`, `extraTemp2`, `extraTemp3`, `soilTemp1`, `soilTemp2`, 
`soilTemp3`, `soilTemp4`, `leafTemp1`, `leafTemp2`, `extraHumid1`, 
`extraHumid2`, `soilMoist1`, `soilMoist2`, `soilMoist3`, `soilMoist4`, 
`leafWet1`, `leafWet2`, `rxCheckPercent`, `txBatteryStatus`, 
`consBatteryVoltage`, `hail`, `hailRate`, `heatingTemp`, `heatingVoltage`, 
`supplyVoltage`, `referenceVoltage`, `windBatteryStatus`, 
`rainBatteryStatus`, `outTempBatteryStatus`, `inTempBatteryStatus`, 
`cloudbase`, `humidex`, `appTemp`, `beaufort`, `windrun`, `maxSolarRad`) 
VALUES
(1554322200, 16, 5, NULL, 1009.14, 1009.31912168591, 37.2, NULL, NULL, 
65.8, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 
0.00190080488960694, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 
28.8287556510223, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 200, NULL, 
NULL, NULL, NULL, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 0, 
NULL, NULL, NULL, NULL, NULL, NULL, 103.266753335247, 321.291353463412);

The value of rainRate is NULL (sorry, I said before the value is None).

Look at lines 278, 292, 310 in restx.py:
  if _result is not None and _result[0] is not None:

Should we not do here the same?
  if rr is not None and rr[0] is not None:

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

On Thursday, 4 April 2019 10:26:56 UTC-3, Thomas Keffer wrote:
>
> #2 is what is happening here.
>

Tom,

The error has nothing to do with the database call. I agree: the value of 
rr is None.

When an object is None you can't get any attributes from it, like rr[0], 
rr[1] etc.
So the exception is complaining you want an attribute from a NoneType object

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

On Thursday, 4 April 2019 09:48:59 UTC-3, Luc Heijst wrote:
>
> else:
> r['rainRate'] = None
>
Tom,
 
Leave these two lines out. We don't send  None value to AWEKAS.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

On Thursday, 4 April 2019 09:31:11 UTC-3, Thomas Keffer wrote:
>
> The problem here is that the record itself was not in the database. 
>

I see it different.
The value in the database is None because no loop value was received when 
the record was written.
The value for rr is None.
The exception says: TypeError: 'NoneType' object has no attribute 
'__getitem__'
Thus: rr[0] throws an error.
Solution [not tested]:
try:
rr = dbmanager.getSql('select rainRate from %s where 
dateTime=?' %
  dbmanager.table_name, (r['dateTime'],))
except weedb.OperationalError:
pass
else:
if rr is not None:
r['rainRate'] = rr[0]
else:
r['rainRate'] = None
return r


-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

On Wednesday, 3 April 2019 22:58:19 UTC-3, Thomas Keffer wrote:
>
> I don't understand why there would not be a record with the record's 
> timestamp in the database, but I added a check just in case.
>

Tom,

Weewx with the meteostick driver was started seconds before the new archive 
period started.
Several values in the database have value None, among others rainRate.

BTW I have set rainRate calculations setr to hardware.

[StdWXCalculate] 
[[Calculations]]
rainRate = hardware 

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Exception error in module restx of version 3.9.1.

[Luc Heijst]

Tom,

I got an exception error in module restx of version 3.9.1.

Apr  3 17:19:36 pi21 mstk[15364]: engine: Caught unrecoverable exception in 
engine:
Apr  3 17:10:14 pi21 mstk[14530]: restx: AWEKAS: Unexpected exception of 
type 
Apr  3 17:10:14 pi21 mstk[14530]: *** Traceback (most recent call last):
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/weewx/restx.py", line 350, in run_loop
Apr  3 17:10:14 pi21 mstk[14530]: *** self.process_record(_record, 
dbmanager)
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/weewx/restx.py", line 1693, in process_record
Apr  3 17:10:14 pi21 mstk[14530]: *** r = self.get_record(record, 
dbmanager)
Apr  3 17:10:14 pi21 mstk[14530]: ***   File 
"/home/weewx/bin/weewx/restx.py", line 1689, in get_record
Apr  3 17:10:14 pi21 mstk[14530]: *** r['rainRate'] = rr[0]
Apr  3 17:10:14 pi21 mstk[14530]: *** TypeError: 'NoneType' object has no 
attribute '__getitem__'
Apr  3 17:10:14 pi21 mstk[14530]: restx: AWEKAS: Thread exiting. Reason: 
'NoneType' object has no attribute '__getitem__'

# Otherwise, augment with rainRate, which AWEKAS expects. If the
# archive does not have rainRate, an exception will be raised.
# Be prepare to catch it.
try:
rr = dbmanager.getSql('select rainRate from %s where 
dateTime=?' %
  dbmanager.table_name, (r['dateTime'],))
except weedb.OperationalError:
pass
else:
r['rainRate'] = rr[0]
return r

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

To all,

Some progress with the rtldavis program and the weewx-rtldavis driver.
See this thread in the weewx development forum: 
https://groups.google.com/forum/m/#!topic/weewx-development/jhGleLxu-p0

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

>
> On Monday, 18 March 2019 20:32:15 UTC-3, rich T wrote:
>>
>> Trying to run the as a standalone driver but it crashes within 10 seconds.
>>
>
Rich,

Although the standalone version is very limited in its functions, the 
'show-packets' option should not end after 10 seconds.
It now runs as long as process rtldavis is active.

Fixed in commit 762ad49 


Luc 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

On Monday, 18 March 2019 20:32:15 UTC-3, rich T wrote:
>
> Trying to run the as a standalone driver but it crashes within 10 seconds.
>

Rich,

The standalone driver is very limited in its functions. It is there because 
each driver should have a stand-alone section.
In the standalone version the received data from rtldavis is not parsed and 
the program ends as soon as the buffer is empty.
There is a typo in the code for the err: data, but that should not change 
anything.

Something else:
Sometime rtldavis stopped with reading and outputting data (this happend 
once a day or less). I could not detect the cause so far and therefore 
weewx-rtld checks if the rtldavis process is stalled.

The 'rtldavis process is stalled' timeout is currently 45 seconds. When 
this timeout is exceeded, weewx-rtld will end with a WeeWxIOError message 
and restart itself after 1 minute.

I realize this 45 sec timeout is too short for the US version, because the 
US init can take 133 seconds.

I will extend this timeout to 150 seconds.

if int(time.time()) - time_last_received > 150:
raise weewx.WeeWxIOError("rtldavis process stalled")

Luc
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

No it is not! I decided to keep the rtldavis program and the weewx driver for 
it in one place. Sorry!

The right link is: https://github.com/lheijst/weewx-rtldavis/archive/master.zip

I will change the readme.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

On Sunday, 17 March 2019 17:30:17 UTC-3, Phil Green wrote:
>
> So what to I have to do to make it work?
> Or is it something in the program which you can fix?


Sorry, I can't think of anything you can do. 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

On Sunday, 17 March 2019 16:02:23 UTC-3, Phil Green wrote:
>
> However, I am still not receiving anything.
>

Hi Phil,

I'm sitting here with a blush on my face. 

I have modified program rtldavis to work with EU frequencies and multi 
Davis transmitters while I don't know almost nothing about RTL-SDR (both 
hardware and software).

I have had a similar situation on my Raspberry PI (i.e. not receiving any 
data packets) after I had uninstalled librtlsdr0
The reason why I uninstalled librtlsdr0 was the error: "rtlsdr.go:503: 
undefined reference to `rtlsdr_set_bias_tee'".
After I installed librtlsdr0 again, the data packets were received normally.

I'm afraid this won't much any help for you. I'm sorry.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Phil,

My instructions are nor clear, sorry.
Add the following 3 lines at the ens of your .profile file.
export GOROOT=/usr/lib/go 
export GOPATH=$HOME/work 
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin 
Then save the file.
To activate the changes in the profile right away, type command:
source ~/.profile 

The program doesn't run at its own on future restarts.
I have set a cronjob for program weewx (with the weewx-rtld driver 
installed) which will start program rtldavis.

crontab -e
Add at the end:
@reboot /home/weewx/util/init.d/weewx.debian restart

The weewx-rtld driver can be found 
here: https://github.com/lheijst/weewx-rtld

Beware: the first action is to get program rtldavis collecting the raw 
data. Without this raw data the weewx-rtld program is useless.

After each successful data collection program rtldavis reports the 
frequency-offset between the RTL-SDR dongle and the Davis transmitter of 
that message.
Program rtldavis has an option to preset an overall frequency correction: 
-fc xxx (in Hz) for all configured transmitters (often there is only one 
transmitter).

Please report the output of program rtldavis to get more information what 
is happening.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: cmon v0.16 crashes in weewx version 3.9.1

[Luc Heijst]

On Saturday, 16 March 2019 11:11:10 UTC-3, Peter Hurn wrote:
>
> Unfortunately despite adding the integer to the line in cmon.py in my 
> /use/share/weewx/user folder I am still getting the following error, any 
> ideas?
>
... 

> Feb 14 11:10:15 pi21 vpro[28175]:   ValueError: accum: 
>> ScalarStats.addHiLo expected float or int, got 3392911048
>>
>
Hii Peter,

The maximum positive value for an int in Python 2 is 2147483648 (2^31). The 
value at the time of the crash is bigger (3392911048), so this value is 
still a long integer.
Such big numbers should only occur if you have very heavy network traffic 
and/or a long archive period.

A quick-and-dirty workaround might be to preset the value of x to maxint in 
case it is bigger, like (not tested):
if k in self.last_net[iface]:
x = int(values[i]) - self.last_net[iface][k]
if x < 0:
maxcnt = 0x1 # 32-bit counter
if x + maxcnt < 0:
maxcnt = 0x1 # 64-bit 
counter
x += maxcnt
if x > 2147483648:
x = 2147483648
record['net_' + iface + '_' + k] = int(x)
self.last_net[iface][k] = int(values[i])

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

New test function in program rtldavis

To all,

The rtldavis program has now an embedded frequency test function.
With this function the frequencies can be detected used by Davis Vantage 
weather stations.

Usage: $GOPATH/bin/rtldavis -tr 1 -tf US -startfreq 90200 -endfreq 
92800 -stepfreq 4

Warning: For the US, AU and NZ bands this test will take a long time!

-stepfreq 1: 4 days!
-stepfreq 2: 2 days!
-stepfreq 4: 24 h
-stepfreq 8: 12 h


Below the output of the test for the EU frequency band

My command was: $GOPATH/bin/rtldavis -tr 15 -startfreq 86800 -endfreq 
86860 -stepfreq 2000
Note: I used -tr 15 because I have 4 transmitters, but you will get better 
results to do the test with just one sensor.

$GOPATH/bin/rtldavis -tr 1 -startfreq 86800 -endfreq 86860 
-stepfreq 2000

08:33:08.507848 TESTFREQ 1: Frequency 86800: NOK
08:33:25.009595 TESTFREQ 2: Frequency 868002000: NOK
...
08:39:11.631768 TESTFREQ 23: Frequency 868044000: NOK
08:39:28.132553 TESTFREQ 24: Frequency 868046000: NOK
08:39:42.645072 TESTFREQ 25: Frequency 868048000 (freqError=3999): OK, 
msg.data: F20AF7FF80C09F85
08:39:56.081804 TESTFREQ 26: Frequency 86805 (freqError=335): OK, 
msg.data: F269C0C0E084
08:40:12.582245 TESTFREQ 27: Frequency 868052000: NOK
08:40:29.083291 TESTFREQ 28: Frequency 868054000: NOK
...
08:42:08.090752 TESTFREQ 34: Frequency 868066000: NOK
08:42:24.591295 TESTFREQ 35: Frequency 868068000: NOK
08:42:31.260564 TESTFREQ 36: Frequency 86807 (freqError=-1309): OK, 
msg.data: E07A05006B04
08:42:31.643522 TESTFREQ 37: Frequency 868072000 (freqError=7117): OK, 
msg.data: 83016F31190076D3
08:42:34.643106 TESTFREQ 38: Frequency 868074000 (freqError=5597): OK, 
msg.data: F2498A5000C091F9
08:42:44.073708 TESTFREQ 39: Frequency 868076000 (freqError=2658): OK, 
msg.data: 50FF7500485B
08:42:45.392137 TESTFREQ 40: Frequency 868078000 (freqError=1285): OK, 
msg.data: E3006F120100D6D6
08:42:48.081458 TESTFREQ 41: Frequency 86808 (freqError=-310): OK, 
msg.data: F229C0C0F1EC
08:42:55.757607 TESTFREQ 42: Frequency 868082000 (freqError=-2895): OK, 
msg.data: 51006AFF73009624
08:42:56.886751 TESTFREQ 43: Frequency 868084000 (freqError=-4454): OK, 
msg.data: A0733D0013B9
08:43:08.883213 TESTFREQ 44: Frequency 868086000 (freqError=-6600): OK, 
msg.data: A1016A0003006AF3
08:43:25.389468 TESTFREQ 45: Frequency 868088000: NOK
08:43:41.890787 TESTFREQ 46: Frequency 86809: NOK
...
08:53:52.563306 TESTFREQ 83: Frequency 868164000: NOK
08:54:09.069653 TESTFREQ 84: Frequency 868166000: NOK
08:54:24.140318 TESTFREQ 85: Frequency 868168000 (freqError=-8497): OK, 
msg.data: F2498A5040C09C35
08:54:37.578287 TESTFREQ 86: Frequency 86817 (freqError=142): OK, 
msg.data: F229C0C0F1EC
08:54:54.079549 TESTFREQ 87: Frequency 868172000: NOK
08:55:10.580273 TESTFREQ 88: Frequency 868174000: NOK
...
08:56:49.587907 TESTFREQ 94: Frequency 868186000: NOK
08:57:06.089362 TESTFREQ 95: Frequency 868188000: NOK
08:57:16.139749 TESTFREQ 96: Frequency 86819 (freqError=-2123): OK, 
msg.data: F209CEFFC0C0A305
08:57:16.757656 TESTFREQ 97: Frequency 868192000 (freqError=6352): OK, 
msg.data: 51006BFF710086F2
08:57:19.888636 TESTFREQ 98: Frequency 868194000 (freqError=5415): OK, 
msg.data: 43007CFFC30025D3
08:57:23.001305 TESTFREQ 99: Frequency 868196000 (freqError=4096): OK, 
msg.data: E07A05006B04
08:57:29.577161 TESTFREQ 100: Frequency 868198000 (freqError=2329): OK, 
msg.data: F22A00FF40C04F05
08:57:29.881575 TESTFREQ 101: Frequency 86820 (freqError=-1211): OK, 
msg.data: 41006BFFC100827B
08:57:33.652214 TESTFREQ 102: Frequency 868202000 (freqError=-2126): OK, 
msg.data: 83007C315B003757
08:57:35.814617 TESTFREQ 103: Frequency 868204000 (freqError=-1629): OK, 
msg.data: 50FF7500485B
08:57:47.390072 TESTFREQ 104: Frequency 868206000 (freqError=-5924): OK, 
msg.data: E3007C12030030CF
08:58:03.891633 TESTFREQ 105: Frequency 868208000: NOK
08:58:20.393632 TESTFREQ 106: Frequency 86821: NOK
08:58:36.909603 TESTFREQ 107: Frequency 868212000: NOK
...
09:08:47.506290 TESTFREQ 144: Frequency 868286000: NOK
09:09:04.007169 TESTFREQ 145: Frequency 868288000: NOK
09:09:05.635746 TESTFREQ 146: Frequency 86829 (freqError=-7983): OK, 
msg.data: F209CEFF40C0B89D
09:09:22.136064 TESTFREQ 147: Frequency 868292000: NOK
09:09:38.637292 TESTFREQ 148: Frequency 868294000: NOK
...
09:11:34.191784 TESTFREQ 155: Frequency 868308000: NOK
09:11:50.692624 TESTFREQ 156: Frequency 86831: NOK
09:11:50.881275 TESTFREQ 157: Frequency 868312000 (freqError=-885): OK, 
msg.data: C1012A0003005B77
09:11:54.386142 TESTFREQ 158: Frequency 868314000 (freqError=6129): OK, 
msg.data: E3011D120300B5F8
09:11:57.651033 TESTFREQ 159: Frequency 868316000 (freqError=3815): OK, 
msg.data: F20AFCFF40C097CE
09:12:01.928609 TESTFREQ 160: Frequency 868318000 (freqError=1144): OK, 
msg.data: 8032AD0014C7
09:12:04.005218 TESTFREQ 161: F

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

Both transmitters work with the same sets of frequencies, so it is likely they 
both fail or succeed at a given frequency.

It is a good idea to start a tread in weewx-development, which I just did, so 
we can continue from there.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

We need another approach. As I said before, the frequencies of RFM69 didn’t 
work for my EU transmitter either.
Note: the lowest and highest frequencies in the RFM69 table were not modified 
by me, so that can’t be a cause here.

I plan to write a testprogram as follows.
1. Start with a frequency in the lower US band. 
2. Start the init proces to see if any messages can be read. When you configure 
both of your sensors with parameter -tr 7 this process may take less time.
3a. When a message is read succesful; continue right away. This frequency is 
(more or less) good.
3b. When a timeout occurred; this frequency is no good. Also continue.
4. Increase the frequency with a certain amount. The amount must be small 
enough not to miss any good frequencies.
5a. When the increased frequency is bigger than the max frequency (at the end 
of the US band), we are ready to analyse the logging.
5b. If not, continue with step 2.

The logfile will show a list with evenly spreaded frequencies and for each 
frequency a true or false message received.
With this info we create our first new hopping list. The program will show for 
each received message a frequency error for that channel.
With the frequency error data we can fine-tune each channel frequency.

Note: On my test site the rtldavis program will function normaly with maximum 
frequency errors of + and - 10,000 Hz.

What do you think?

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Rich,

You can read both transmitters simultanious with option -tr 3. 

AFAIK, the Davis console (and the weewx Vantage driver) won’t show the UV data 
when it is not coming from the same transmitter as the ISS. 

Anyhow, the rtldavis driver will read the data. I have my solar sensor mounted 
on the same pole as my anemometer. On a high location, while my ISS is at 1.5 m 
above groud level as advised. An other advantage of the rtldavis driver will be 
a five to ten time smaller resolution of temperature, leaf wetness and soil 
moistness.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

I forgot to tell one more thing about the frequencies. In the RFM69 table the 
frequencies are sorted in the sequence they are transmitted.
In the rtldavis program the frequencies are sorted from low to high and the 
frequency order used for the hopping comes from the hop table.

h.ChannelIdx = p.hopPattern[p.hopIdx]
h.ChannelFreq = p.channels[h.ChannelIdx]

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

As the ID of the second station is 1, it could be from an anemometer kit. 
I, for example, have set my ISS to 0, my anemometer station to 1, and my 
leaf-soil station to 2.
But a reception range of 2 miles? It’s way above Davis specifications!

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Rich, 

FSTEP = 32MHz  / (2^19)  = 61.xxx Hz. So the formula is: freq from table * 
61.xxx

After translating the table I did another step. I calculated the difference 
between each two frequencies. As they were close to each other, but all 
different, I thought the frequencies might differ each the same number of Hz. 
And so I did for my table. If those frequencies won’t work, we can use the ones 
without my ‘correction’.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Rich,

I was just thinking abouth the battery-low indication of your station and the 
other station in the neighboorhood where we have received the data from.

Are the days short in the region where you live? If so, the supercapacitor 
which suplies the power at night might have unsufficient voltage and then the 
lithium battery comes in to deliver extra power. When the battery power is low, 
you get the warning.

But also the power of the tranmitter of your Davis weather station will be low. 
That might be the reason you won’t see them with your scan tool.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

The US, AU and NZ Davis models hop with 51 different channel frequencies. The 
EU Davis models hop with only 5 different channel frequencies.
For the first transmitter (with id=0) the hop period is 2.5 + 1/16 second, i.e. 
2.5625 seconds.
One channel is this revisited after 51 * 2.5625 seconds (130.7 seconds).

During the init phase I notised long periods before your station message was 
received on the channel 0.

For EU models this period is much shorter, 5 * 2.5625 is 12.8 seconds.

You might try the following US frequencies.
902381897, 902883656, 903385415, 903887174, 904388933, 
904890692, 
905392451, 905894210, 906395969, 906897728, 907399487, 
907901246, 
908403005, 908904764, 909406523, 909908282, 910410042, 
910911801, 
911413560, 911915319, 912417078, 912918837, 913420596, 
913922355, 
914424114, 914925873, 915427632, 915929391, 916431150, 
916932909, 
917434668, 917936427, 918438186, 918939945, 919441704, 
919943463, 
920445222, 920946981, 921448740, 921950499, 922452258, 
922954017, 
923455776, 923957535, 924459294, 924961053, 925462813, 
925964572, 
926466331, 926968090, 927469849, 

Replace the US ones in file protocol.go and recompile the program, then start 
program rtldavis to see if these frequencies are better.
BTW The US hopping sequence is OK.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

When I look at the frequencies used in file DavisRFM69.h (see: 
https://github.com/kobuki/VPTools/blob/master/DavisRFM69.h), I believe all 
the US frequencies in protocol.go are 26300 Hz too low.

BTW. The EU frequencies in the same DavisRFM69.h file seem not useful for 
my EU Davis transmitters.


It took a while to find the conversion formula for those three byte numbers 
in the DavisRFM69.h file.

The formula is:
Frequency (Hz) = (HEX) Frequency DavisRFM69.h * 32,000,000 / (2^19)

Example: *{0xE3, 0xDA, 0x7C}*, = HEX: E3DA7C = Dec: 14932604. Frequency in 
Hz is: 14932604 * 3200 / 61.03515625 = *911413818.4*

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

Great!  I judt started with the use of RTL-SDR dongles and know very little of 
the ins and outs. I tried to find my EU frequences with SDRsharp, but didn’t 
know how to use the program in the way you plan to do. 
I changed my two RTL dongles yesterday and the rtldavis program showed an 
average jump of +9000 Hz of the frequency errors for all of my 4 davis channels.
The other RTL dongle is used by weewx-tfrc which reads the data of my 9 
Klimalogg temp/hum sensors. After the switch the signal quality of one of the 
sensors dropped a lot while for the other 8 the values remain the same.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

As the hopping is not working for the US frequencies, I believe the frequencies 
in the program and/or the hopping sequence are wrong.
I will do some research on the internet to try to find better values.
The problem with the internet is that faulty stuff is copied over and over 
without being looked at seriously and it hides the spare good stuff.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

On Monday, 11 March 2019 02:24:29 UTC-3, Luc Heijst wrote:
>
> The ‘8’ message can be declared, it is channel 0 with the battery-low bit 
> set. 


 I found the problem for the array out of bound violation.

Fixed bug where battery-low bit wasn't filtered out (commit 24adb68)

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

The ‘8’ message can be declared, it is channel 0 with the battery-low bit set. 
The ‘9’ message should be channel 1 with also the battery-low bit set.
The program logs all received messages, so also from Vantage Pro and Vue 
systems in the neigbourhood.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Rich,

The two messages you received should have 0 as second digit (the transmitter 
id: which should be in the range 0-7), but they are 8 and 9. Those messages. 
should not have passed the crc check.
Another thing: I could not test the program with the US frequencies, so one or 
more frequency might be wrong.
The original driver started with a random frequency channel, but mine always 
starts with channel 0.
I will have to add more debug logging to get an idea what is happening.
More to come.
Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Modified rtldavis package available for download.

OK, for you who can't wait!  [image: :grin:]

I have put the modified rtldavis package on my github account, see: 
https://github.com/lheijst/rtldavis

This package reads the raw data packets from the configured stations and 
output them on stderr.

Comments are welcome.

The weewx-rtldavis driver (not published yet) will read and parse this data 
and store the values in the weewx database.

More to come.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

On Tuesday, 5 March 2019 19:23:31 UTC-3, mwall wrote:
>
>
> luc, please do NOT put barometer code into any sdr driver.  reading 
> pressure from the bme or other pi/arduino-specific hardware does not belong 
> in an sdr driver.  it belongs in a separate service.
>
> m
>

Thanks for the explanation, Matthew. What I meant was a provision for 
reading the barometer code on the same machine as the sdr driver. I did not 
study yet what and how.

Luc 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Jude,

There are several ways to read the weather data of Vantage Pro and Vue 
stations.

   - Via a Davis datalogger inserted in the Davis console
   - Via a Meteostick
   - Via a Moteino module
   - Via various other modules I can't come up now

All modules are working fine.

My program adds another way:

   - Via a RTL-SDR dongle (it's not new, I combined and modified existent 
   programs)

Luc

On Tuesday, 5 March 2019 18:45:13 UTC-3, Jude Mwenda wrote:
>
> Sorry, newbie here without a Davis Pro. Is it because getting the data out 
> into the weewx is inconsistent? or not working?
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Hi Ruben,

The python and go programs are ready for alpha-testing.

What need to be done is:

   - Write installation and user instructions
   - Remove personal data from the programs like skins, passwords etc. 
   - Create a deliver zip file
   - Test the installation
   - Currently there is no provision for pressure (barometer) data; we need 
   a pressure sensor and code in the driver to read the sensor data 

Luc

On Tuesday, 5 March 2019 16:07:37 UTC-3, Ruben Navarro Huedo wrote:
>
> Luc: Tell me if you need beta-testing.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

On Monday, 4 March 2019 20:41:52 UTC-3, rich T wrote:
>
> Switch several of my older dongles to this one: 
> https://www.amazon.com/dp/B01HA642SW/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B01HA642SW&pd_rd_w=JtW8R&pf_rd_p=733540df-430d-45cd-9525-21bc15b0e6cc&pd_rd_wg=fH2H2&pf_rd_r=YKVSGSYAFB36QD0YPV4W&pd_rd_r=2faf93c1-3ed6-11e9-936e-01fa71378c68
>  .  
> This dongle seems not to drift much at the higher frequencies.
>

Thanks, Rich.

When I need another SDR I will buy the combi-set with the 3 antennas.
For testing my driver I better use 'bad quality' SDR's though!

Luc 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

On Monday, 4 March 2019 10:40:00 UTC-3, Thomas Keffer wrote:
>
> Impressive, Luc. I admire your persistence!
>

Thanks, Tom! 

When I looked at the rtldavis package I had the feeling it could be done, 
although I know nothing about radio signals and the rtl-sdr library.

I still have to discover why the frequency errors sometimes have huge 
differences.
The average frequency errors vary with the temperature of the dongle (i.e. 
the room temperature of the raspberry pi), which can be explained for cheap 
rtl-sdr dongles without temperature compensation.

I plan to hook up a pressure sensor (BMP280) to make the weewx_rtld driver 
complete.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] LaCrosse Temperature Sensor ID changes with battery change?

[Luc Heijst]

Yes, this is normal for some TFA temp sensors. See the doc of program tfrec at: 
https://github.com/baycom/tfrec

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Recently my attention was brought to a SDR tool for receiving wireless 
sensor data (TFA IT+ KlimaLogg Pro, LaCrosse, WeatherHub). See: 
https://github.com/baycom/tfrec.

I wrote a weewx driver which parsed and stored the tfrec data of my 9 
KlimaLogg sensors. The weewx driver can be found here: 
https://github.com/matthewwall/weewx-tfrc

After this success I searched for a package that reads the radio data of 
Vantage Pro weather stations with a (cheap) RTL-SDR dongle and found: the 
rtldavis package on: https://github.com/bemasher/rtldavis.

With this package were a few problems:
1. The development of the package stopped three years ago.
2. The set of European frequencies appeared not to be useful.
3. The package could only handle one transmitter (at a time).
4. The package is written in GO. Not a big issue, but the GO language is 
new for me.

With two Vantage Pro2 systems, an anemometer station and a leaf-soil 
station the challenge was to get this package concurrently working for more 
than one transmitter (four in my case).

With some modifications of main.go and protocol.go and trial and error I 
could find a reasonable set of the European frequencies which are used in 
the frequency hop sequence.
The next step was to get the data of more than one sensor wich each its own 
hopping timing. 
The last step will be to parse the data packets and store the data in 
Weewx. This part is easy because this was already done by me via the 
parsing of the raw meteostick data in the weewx-meteostick driver, see: 
https://github.com/matthewwall/weewx-meteostick.

The hopping mechanism has some prograss today. The principle is as follows.
1. Wait long enough on a fixed frequency until you have seen at least one 
message of each transmitter. For the five EU frequencies this process takes 
17 seconds or less. For the 51 US frequencies this will take about ten 
times as much time.
2, Calculate with help of the lastVisitedTimes of all transmitters what the 
nextVisitTimes (in the near future) will be and how many hops would be 
needed to get here.
3. Detect the smallest nextVisitTime. This will be of the transmitter which 
follows first.
4. Calculate the hop channel for this transmitter.
5. Calculate the loopPeriod for this transmitter. In case the signal of 
this transmitter is missed we don't want to wait too long and miss packets 
of other transmitters too.
6. Start the hop process and wait for new data.

I combined the weewx-sdr and weewx-meteostick drivers fr this weewx-rtld 
driver.
The results so far:

The first 1000 messages were read with the new driver.
Average percentage of received signals is 94,8 %, see table.

 ok missed tot  pctGood
 341  19 360  94,7
 335  16 351  95,4
 324  20 344  94,2
  --   
tot 1000  55 1055  94,8

The FreqError in general varies between -1000 and +1000.
When abs(FreqError) > 1 the weewx-rtld driver will restart program 
rtldavis.

For a comparison between the Meteostick and rtld driver data see: 
http://www.lucdesign.nl/_weewx/bootstrap_rtld/hour.html

There is one challence left: how to get local barometer data in my 
Raspberry PI? 
I could use a BMP280 pressure/temp sensor... so, more to come.

Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin version: 0.9rc6 crashed when used with non-standard database name

[Luc Heijst]

On Sunday, 17 February 2019 15:48:47 UTC-3, Pat wrote:
>
>  I think I'll leave it alone for now unless you have insight on that? 
>

Hi Pat,

I have a working solution.

In Belchertown.py
Change:
# Find what kind of database we're working with and specify the 
correctly tailored SQL Query for each type of database
dbtype = 
self.generator.config_dict['DataBindings']['wx_binding']['database']
if dbtype == "archive_sqlite":
year_rainiest_month_sql = 'SELECT strftime("%%m", 
datetime(dateTime, "unixepoch")) as month, ROUND( SUM( sum ), 2 ) as total 
FROM archive_day_rain WHERE strftime("%%Y", datetime(dateTime, 
"unixepoch")) = "%s" GROUP BY month ORDER BY total DESC LIMIT 1;' % 
time.strftime( "%Y", time.localtime( time.time() ) )
at_rainiest_month_sql = 'SELECT strftime("%m", 
datetime(dateTime, "unixepoch")) as month, strftime("%Y", 
datetime(dateTime, "unixepoch")) as year, ROUND( SUM( sum ), 2 ) as total 
FROM archive_day_rain GROUP BY month, year ORDER BY total DESC LIMIT 1;'
year_rain_data_sql = 'SELECT dateTime, ROUND( sum, 2 ) FROM 
archive_day_rain WHERE strftime("%%Y", datetime(dateTime, "unixepoch")) = 
"%s";' % time.strftime( "%Y", time.localtime( time.time() ) )
at_rain_data_sql = 'SELECT dateTime, ROUND( sum, 2 ) FROM 
archive_day_rain;'
# The all stats from http://www.weewx.com/docs/customizing.htm 
doesn't seem to calculate "Total Rainfall for" all time stat correctly. 
at_rain_highest_year_sql = 'SELECT strftime("%Y", 
datetime(dateTime, "unixepoch")) as year, ROUND( SUM( sum ), 2 ) as total 
FROM archive_day_rain GROUP BY year ORDER BY total DESC LIMIT 1;'
elif dbtype == "archive_mysql":
year_rainiest_month_sql = 'SELECT FROM_UNIXTIME( dateTime, 
"%%m" ) AS month, ROUND( SUM( sum ), 2 ) AS total FROM archive_day_rain 
WHERE year( FROM_UNIXTIME( dateTime ) ) = "{0}" GROUP BY month ORDER BY 
total DESC LIMIT 1;'.format( time.strftime( "%Y", time.localtime( 
time.time() ) ) ) # Why does this one require .format() but the other's 
don't?
at_rainiest_month_sql = 'SELECT FROM_UNIXTIME( dateTime, "%%m" 
) AS month, FROM_UNIXTIME( dateTime, "%%Y" ) AS year, ROUND( SUM( sum ), 2 
) AS total FROM archive_day_rain GROUP BY month, year ORDER BY total DESC 
LIMIT 1;'
year_rain_data_sql = 'SELECT dateTime, ROUND( sum, 2 ) FROM 
archive_day_rain WHERE year( FROM_UNIXTIME( dateTime ) ) = "%s";' % 
time.strftime( "%Y", time.localtime( time.time() ) )
at_rain_data_sql = 'SELECT dateTime, ROUND( sum, 2 ) FROM 
archive_day_rain;'
# The all stats from http://www.weewx.com/docs/customizing.htm 
doesn't seem to calculate "Total Rainfall for" all time stat correctly. 
at_rain_highest_year_sql = 'SELECT FROM_UNIXTIME( dateTime, 
"%%Y" ) AS year, ROUND( SUM( sum ), 2 ) AS total FROM archive_day_rain 
GROUP BY year ORDER BY total DESC LIMIT 1;'

into:
# Find what kind of database we're working with and specify the 
correctly tailored SQL Query for each type of database
dataBinding = 
self.generator.config_dict['StdArchive']['data_binding']
database = 
self.generator.config_dict['DataBindings'][dataBinding]['database']
databaseType = 
self.generator.config_dict['Databases'][database]['database_type']
driver = 
self.generator.config_dict['DatabaseTypes'][databaseType]['driver']
if driver == "weedb.sqlite":
year_rainiest_month_sql = 'SELECT strftime("%%m", 
datetime(dateTime, "unixepoch")) as month, ROUND( SUM( sum ), 2 ) as total 
FROM archive_day_rain WHERE strftime("%%Y", datetime(dateTime, 
"unixepoch")) = "%s" GROUP BY month ORDER BY total DESC LIMIT 1;' % 
time.strftime( "%Y", time.localtime( time.time() ) )
at_rainiest_month_sql = 'SELECT strftime("%m", 
datetime(dateTime, "unixepoch")) as month, strftime("%Y", 
datetime(dateTime, "unixepoch")) as year, ROUND( SUM( sum ), 2 ) as total 
FROM archive_day_rain GROUP BY month, year ORDER BY total DESC LIMIT 1;'
year_rain_data_sql = 'SELECT dateTime, ROUND( sum, 2 ) FROM 
archive_day_rain WHERE strftime("%%Y", datetime(dateTime, "unixepoch")) = 
"%s";' % time.strftime( "%Y", time.localtime( time.time() ) )
at_rain_data_sql = 'SELECT dateTime, ROUND( sum, 2 ) FROM 
archive_day_rain;'
# The all stats from http://www.weewx.com/docs/customizing.htm 
doesn't seem to calculate "Total Rainfall for" all time stat correctly. 
at_rain_highest_year_sql = 'SELECT strftime("%Y", 
datetime(dateTime, "unixepoch")) as year, ROUND( SUM( sum ), 2 ) as total 
FROM archive_day_rain GROUP BY year ORDER BY total DESC LIMIT 1;'
elif driver == "weedb.mysql":
year_rainiest_month_sql = 'SELECT FROM_UNIXTIME( dateTime, 
"%%m" ) AS month, ROUND( SUM( sum ), 2 ) AS total FROM archive_day_rain 
WHERE year( FROM_UNIXTIME( dateTime ) ) = "{0}" GROUP BY month ORDER BY 
total DESC LIMIT 1;'.

[weewx-user] Re: cmon v0.16 crashes in weewx version 3.9.1

[Luc Heijst]

I forgot to say the net stat value (transmitted number of bytes last achive 
period) of cmon gets type long when the 64-bit net counter turned around from 
max-long to zero, but the net stat value itself was always in the range of 1 to 
max-int. So only the new type check in accum caused the exception.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: cmon v0.16 crashes in weewx version 3.9.1

[Luc Heijst]

Hi Gary,

Accum v.3.9 throws an exception if the parameter is not a float or an int where 
accum v.3.8.2 didn’t.
So I believe the long parameter of cmon itself is not the problem because it 
didn’t cause any exceptions before.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: New weewx_tfrc driver for reading TFA KlimaLogg (and other) sensors with a sdr-rtl dongle

[Luc Heijst]

Well...

Matthew Wall is fast, verry fast !

He already put my first version of weewx_tfrc on github and a link in the 
weewx wiki.

See: https://github.com/matthewwall/weewx-tfrc

Thanks very much Matthew!

Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin version: 0.9rc6 crashed when used with non-standard database name

[Luc Heijst]

On Sunday, 17 February 2019 15:48:47 UTC-3, Pat wrote:
>
> Interesting! That is a busy Pi. I'm not sure how I'd be able to support 
> your custom integrations with the few custom sql queries I have, so I think 
> I'll leave it alone for now unless you have insight on that? So far I think 
> you're the only one using the skin with such an elaborate setup :)
>

It's ok to leave it for now, Pat. I can patch future releases of 
belchertown.py myself.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin version: 0.9rc6 crashed when used with non-standard database name

[Luc Heijst]

Hi Pat,

My weewx config file says:

[StdArchive]
data_binding = vpro_binding

[DataBindings]
[[vpro_binding]]
database = vpro_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = schemas.wview.schema

[Databases]
[[vpro_mysql]]
database_type = MySQL
database_name = weewx_vpro

[DatabaseTypes]
[[MySQL]]
driver = weedb.mysql
host = 192.168.0.14
port = 3307  # 3306=mariadb 5, 3307=mariadb 10
user = 
password = 

In my oppinion with the proper commands is is doable to detect a generic 
database name and type.

Cheers, Luc


-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] New weewx_tfrc driver for reading TFA KlimaLogg (and other) sensors with a sdr-rtl dongle

[Luc Heijst]

In 2018 Georg Acher & Deti Fliegl developed tfrec - A SDR tool for 
receiving wireless sensor data, 
see: https://github.com/baycom/tfrec

In the documentation they mention our weewx_klimalogg driver, 
see: https://github.com/matthewwall/weewx-klimalogg 

I wrote a weewx-tfrc driver based upon Matthew Walls weewx-sdr driver.
The weewx-tfrc driver parses the data of the tfrec package and stores the 
output in the weewx database.

Differences between the weewx-tfrc and weewx-klimalogg drivers:
- weewx-tfrc reads the radio data of the individual sensors with use of a 
rtl-sdr dongle.
- weewx-klimalogg reads the sensor data with use of the KlimaLogg Pro base 
station usb-dongle.
- weewx-klimalogg can read the history of 51.000 temp/humidity records from 
the base station where weewx-tfrec has no history.
- the learning (pairing) of new sensors in weewx-klimalogg is a bit of a 
hassle.
- reading new sensors in weewx-tfrc is done by adding the sensor data in 
weewx.conf and restarting weewx.
- the maximum number of connected sensors in weewx-klimalogg is 8.
- the maximum number of connected sensors in weewx-tfrc is only limited by 
the cpu power of the system.
- weewx-klimalogg can only read sensor data from type TFA_1: (KlimaLoggPro)
- weewx-tfrc can read sensor data from types: TFA_1 (KlimaLoggPro),  TFA_2 
(17240bit/s), TFA_3 (9600bit/s), TX22 (8842bit/s) and WeatherHub (6000bit/s)

I have the weewx-tfrc driver running without any problems for a week for 9 
TFA KlimaLogg sensors.
The parsing of the non-TFA_1 sensor data is not finished because I don't 
have such type sensors.

Please drop a mail at ljm.heijst at gmail.com if you are interested in 
participating testing the other type sensors.
Besides a system running with weewx you need to install tfrec and use a 
rtl-sdr dongle to read the data.

Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin version: 0.9rc6 crashed when used with non-standard database name

[Luc Heijst]

Sorry,

The PI2B runs the weewx_mben (modbus energy driver) and not the tfrec 
driver.
Both weewx_mben and weewx_tfrec are new drivers developed by me.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin version: 0.9rc6 crashed when used with non-standard database name

[Luc Heijst]

Hi Pat,

My Raspberry PI2B system is a busy one: it runs via BerryBoot four weewx 
instances on a Synolofy NAS and writes the data to six different external 
MariaDB 10 databases:
It has drivers for Vantage, Meteostick, KlimaLogg and tfrec and numerous 
skins.

*weewx_vpro*
bindings:
[[vpro_binding]]
database = vpro_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = schemas.wview.schema
[[mstk_binding]]
database = mstk_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = schemas.wview.schema
[[klim_binding]]
database = klim_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = user.klschema.schema
[[forecast_binding]]
database = forecast_mysql#lh forecast_sqlite
[[cmon_binding]]
database = cmon_mysql
table_name = archive
manager = weewx.manager.DaySummaryManager
schema = user.cmon.schema

*weewx_mstk*
[[mstk_binding]]
database = mstk_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = schemas.wview.schema

*weewx_klim*
[[klim_binding]]
database = klim_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = user.klschema.schema

*weewx_mben*
[[mben_binding]]
database = archive_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = user.modbusenergy.schema

To keep track of everything I try to avoid the standard wx-binding and 
database naming

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Belchertown Skin version: 0.9rc6 crashed when used with non-standard database name

[Luc Heijst]

Hi Pat,

I installed Belchertown Skin Version: 0.9rc6 from scratch (no update) in 
weewx 3.9.1.

At first the generation of the skin crashed with the following error:
Feb 17 12:12:25 pi21 vpro[9234]: cheetahgenerator: Generated 4 files for 
report Highcharts_Belchertown in 122.54 seconds
Feb 17 12:12:25 pi21 vpro[9234]: copygenerator: copied 0 files to 
/var/www/html/vpro/data/weewx/belchertown
Feb 17 12:12:25 pi21 vpro[9234]: reportengine: Running report 'Belchertown'
Feb 17 12:12:25 pi21 vpro[9234]: reportengine: Found configuration file 
/home/weewx/skins/Belchertown/skin.conf for report 'Belchertown'
Feb 17 12:12:25 pi21 vpro[9234]: cheetahgenerator: using search list 
['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 
'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 
'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras', 
'user.belchertown.getData']
Feb 17 12:12:25 pi21 vpro[9234]: manager: Daily summary version is 2.0
Feb 17 12:12:25 pi21 vpro[9234]: Belchertown Extension: version 0.9rc6
Feb 17 12:12:26 pi21 vpro[9234]: reportengine: Caught unrecoverable 
exception in generator 'weewx.cheetahgenerator.CheetahGenerator'
Feb 17 12:12:26 pi21 vpro[9234]:   local variable 
'year_rainiest_month_sql' referenced before assignment
Feb 17 12:12:26 pi21 vpro[9234]:   Traceback (most recent call 
last):
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/weewx/reportengine.py", line 204, in run
Feb 17 12:12:26 pi21 vpro[9234]:   obj.start()
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/weewx/reportengine.py", line 300, in start
Feb 17 12:12:26 pi21 vpro[9234]:   self.run()
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 160, in run
Feb 17 12:12:26 pi21 vpro[9234]:   ngen = 
self.generate(gen_dict[section_name], self.gen_ts)
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 234, in generate
Feb 17 12:12:26 pi21 vpro[9234]:   ngen += 
self.generate(section[subsection], gen_ts)
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 234, in generate
Feb 17 12:12:26 pi21 vpro[9234]:   ngen += 
self.generate(section[subsection], gen_ts)
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 322, in generate
Feb 17 12:12:26 pi21 vpro[9234]:   default_binding)
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 374, in _getSearchList
Feb 17 12:12:26 pi21 vpro[9234]:   searchList += 
obj.get_extension_list(timespan, db_lookup)
Feb 17 12:12:26 pi21 vpro[9234]: File 
"/home/weewx/bin/user/belchertown.py", line 228, in get_extension_list
Feb 17 12:12:26 pi21 vpro[9234]:   
year_rainiest_month_query = wx_manager.getSql( year_rainiest_month_sql )
Feb 17 12:12:26 pi21 vpro[9234]:   UnboundLocalError: local 
variable 'year_rainiest_month_sql' referenced before assignment
Feb 17 12:12:26 pi21 vpro[9234]:   Generator terminated

This is a result of my non-standard weewx configuration.
Differences:
- startup file is weewx_vpro.conf instead of weewx.conf
- [StdArchive] data_binding = vpro_binding instead of wx_binding
[[vpro_binding]]
database = vpro_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
schema = schemas.wview.schema
Because of the non-standard binding some parts of belchertown.py are not 
executed.
- line 212 in belchertown.py should be (in my case):
 if dbtype == "vpro_sqlite":
  instead of:
 if dbtype == "weewx_sqlite":
- line 219 in belchertown.py should be (in my case):
 if dbtype == "vpro_mysql":
  instead of:
 if dbtype == "weewx_mysql":

After I have changed lines 212 and 219 in belchertow.py the skin was 
generated succesfully.

Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: cmon v0.16 crashes in weewx version 3.9.1

[Luc Heijst]

Hallo Sef,

The problem will occur only on systems with 64-bit net counters when the 
counter reaches the maximum value and starts with zero again. When you have low 
network traffic this may take a while.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[Luc Heijst]

Thanks Tom, Matthew and other contributants for this new version 3.9.x of 
weewx. For me the organisation of reports and skins is more efficient and 
better to understand. It took a few days before my five RPI weewx systems were 
converted.

I have two systems with cmon, simulator and a webcam,
One system with cmon, vantage pro driver, meteostick driver, klimalogg driver 
and (self written) weewx-mben modbus energy driver which will read my (to be 
received from China) smart 3-phase energy meter with modbus interface and a 
modbus-usb dongle.
On a fourth RPI I am still experimenting with the rtldavis package which will 
read vantage weather station data with a rtl-sdr dongle.
And my fifth RPI system with cmon reads with the tfrec package and a rtl-sdr 
dongle data from KlimaLogg temp and humidity sensors (without the need of a 
Klimalogg Base station and the hassle of learning new sensors. Also the number 
of sensors to be read can be ‘unlimited’ when the system is fast enough.) The 
radio data is read with a (self written) weewx-tfrec driver based upon Matthews 
weewx-sdr driver. This driver also reads data from other type sensors or 
weather stations, but because I don’t have these hardware it is difficult for 
me to test it.

Cheers, 
Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] cmon v0.16 crashes in weewx version 3.9.1

[Luc Heijst]

cmon v0.16 crashes in weewx version 3.9.1

See crashlog:
Feb 14 11:10:15 pi21 vpro[28175]: manager: Added record 2019-02-14 11:10:15 
-03 (1550153415) to database 'cmon21'
Feb 14 11:10:15 pi21 vpro[28175]: engine: Main loop exiting. Shutting 
engine down.
Feb 14 11:10:15 pi21 vpro[28175]: engine: Shutting down StdReport thread
Feb 14 11:10:15 pi21 vpro[28175]: engine: StdReport thread has been 
terminated
Feb 14 11:10:15 pi21 vpro[28175]: engine: Caught unrecoverable exception in 
engine:
Feb 14 11:10:15 pi21 vpro[28175]:   accum: ScalarStats.addHiLo 
expected float or int, got 3809297
Feb 14 11:10:15 pi21 vpro[28175]:   Traceback (most recent call 
last):
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/engine.py", line 890, in main
Feb 14 11:10:15 pi21 vpro[28175]:   engine.run()
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/engine.py", line 202, in run
Feb 14 11:10:15 pi21 vpro[28175]:   
self.dispatchEvent(weewx.Event(weewx.POST_LOOP))
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/engine.py", line 224, in dispatchEvent
Feb 14 11:10:15 pi21 vpro[28175]:   callback(event)
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/engine.py", line 580, in post_loop
Feb 14 11:10:15 pi21 vpro[28175]:   
self._catchup(self.engine.console.genArchiveRecords)
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/engine.py", line 635, in _catchup
Feb 14 11:10:15 pi21 vpro[28175]:   origin='hardware'))
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/engine.py", line 224, in dispatchEvent
Feb 14 11:10:15 pi21 vpro[28175]:   callback(event)
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/user/cmon.py", line 714, in new_archive_record
Feb 14 11:10:15 pi21 vpro[28175]:   
self.save_data(self.get_data(now, self.last_ts))
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/user/cmon.py", line 721, in save_data
Feb 14 11:10:15 pi21 vpro[28175]:   self.dbm.addRecord(record)
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/manager.py", line 246, in addRecord
Feb 14 11:10:15 pi21 vpro[28175]:   
self._addSingleRecord(record, cursor, log_level)
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/manager.py", line 1216, in _addSingleRecord
Feb 14 11:10:15 pi21 vpro[28175]:   
_day_summary.addRecord(record, weight=_weight)
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/accum.py", line 256, in addRecord
Feb 14 11:10:15 pi21 vpro[28175]:   func(self, record, 
obs_type, add_hilo, weight)
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/accum.py", line 314, in add_value
Feb 14 11:10:15 pi21 vpro[28175]:   self[obs_type].addHiLo(val, 
record['dateTime'])
Feb 14 11:10:15 pi21 vpro[28175]: File 
"/home/weewx/bin/weewx/accum.py", line 77, in addHiLo
Feb 14 11:10:15 pi21 vpro[28175]:   raise ValueError("accum: 
ScalarStats.addHiLo expected float or int, got %s" % val)
Feb 14 11:10:15 pi21 vpro[28175]:   ValueError: accum: 
ScalarStats.addHiLo expected float or int, got 3809297
Feb 14 11:10:15 pi21 vpro[28175]:   Exiting.

The problem is caused by the net_eth0_tbytes calculation in cmon.py, see 
below. 
   # get network usage
fn = '/proc/net/dev'
try:
netinfo = self._readproc_dict(fn)
if netinfo:
for iface in netinfo:
values = netinfo[iface].split()
for i, k in enumerate(self._NET_KEYS):
if iface not in self.last_net:
self.last_net[iface] = {}
if k in self.last_net[iface]:
x = int(values[i]) - self.last_net[iface][k]
if x < 0:
maxcnt = 0x1 # 32-bit counter
if x + maxcnt < 0:
maxcnt = 0x1 # 64-bit 
counter
x += maxcnt
record['net_' + iface + '_' + k] = *x*
self.last_net[iface][k] = int(values[i])
except Exception, e:
logdbg("read failed for %s: %s" % (fn, e))

The value of net_eth0_tbytes is a long integer ('net_eth0_tbytes': *108233L*,) 
and accum.py (of version 3.9.1) expects a float or an integer, but NOT a 
long.

To solve this, the cmon value must be converted to an integer in line 463 
of cmon.py
record['net_' + iface + '_' + k] = *int(x)*

Luc

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group

[weewx-user] Re: weewx is stopping with errors

[Luc Heijst]

After upgrading today from 3.8.2 to v3.9.1 I noticed on some raspberry pi’s 
similar error messages. I have 5 pi’s with cmon installed.
The error did not return after rebooting the systems.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Klimalogg Pro on Synology NAS

[Luc Heijst]

Hi,

Today I discovered a bug in version 1.3.6 of the Klimalogg driver.
It only effects when used with command wee_device --current

This is solved in version 1.3.7 (I just sent a copy to Matthew Wall).
You can add (the red marked) line 1618 in version 1.3.6 of kl.py to solve 
this for now.

def show_current(self, maxtries):
"""Get current weather observation."""
print 'Querying the station for current weather data...'
start_ts = None
ntries = 0
self.station.clear_wait_at_start()  # let rf communication start
while ntries < maxtries or maxtries == 0:

I have five Synology NAS'es to test the KL-driver with (207, 207+, 209+ii, 
211 and 216j).
Can you tell me the steps you took to install weewx on your ds111? Then I 
can have a look at the syslogs not working.

Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: 'rainBatteryStatus' on TFA Opus

[Luc Heijst]

Sorry, I forgot, the signals of the wind and rain sensors are received by the 
outside temp/hygro sensor.
The outside temp/hygro sensor send these signals together with its own values 
to the console.
The wind and rain sensors have a reach of 50 meters (maximum) and the 
temp/hygro sensor 100 meters.
So dashes for the rain value might be a combination of lower voltages on the 
rain sensor and/or lower voltages on the temp/hygro sensor.
Other factors are distance between the sensors and plants and trees which 
influence the communication.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: 'rainBatteryStatus' on TFA Opus

[Luc Heijst]

When your rain data show dashes on the console you probably won't have 
communication between the rain sensor and the console. 
This could be caused by batteries with lower voltage. The voltage might be high 
enough to not trigger yet the low-battery warning.
You might try to change the location of the rain sensor or console to get a 
better radio reception.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] 'rainBatteryStatus' on TFA Opus

[Luc Heijst]

In 2014 I did some tests with low voltage batteries for the TFA Primus station 
(similar to the TFA Opus except for battry powered rain module). i discoveredd 
the  bits which indicate 'low battery' per sensor (rain, wind etc.). Can't say 
which is first: bad value readings or the battery low indication. See thread: 
https://groups.google.com/forum/m/#!search/Rain$20battery$20status/weewx-user/LGpAJojtxA4
Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] KlimaLogg Pro - Auto USB setting

[Luc Heijst]

The newer version of the KlimaLogg Pro main station has an extra basic 
setting: Automatic USB-connection: ON/OFF.
(For example: manufacture date 08/2017)

The default setting of Auto USB is ON (activate).
When activated the device tries to connect at every full hour.

Note: elder versions of the KlimaLogg Pro main station, which didn't have 
this basic option, try to connect only once a day at 00:00.

I checked the configuration messages read by the weewx klimalogg driver and 
noticed no differences between the Auto USB ON and Auto USB OFF settings.
So, no changes are needed for the driver.

Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Reading historical data from Klimalogg Pro

[Luc Heijst]

The klimalogg driver tries to calculate where to start with collecting 'missed' 
data. This calculation will be wrong when the klimalogg memory is filled with 
data of different intervals. Example: the first 20.000 records have an interval 
of 30 minutes, then 15.000 records with an interval of 1 minute and the newer 
records have an interval of 5 minutes.

Also the data in the klimalogg memory can have the time stamps not in 
increasing order.
We have seen problems with the reception of the DCF time. Then 10 march 2017 
suddenly was read as 10 february 2017. One day later the time was normal again 
(11 march 2017 in this example). The logic in the klimalogg driver tries to 
overcome such timestamp jumps and will skip the records the logic thinks are 
bad. 
It might also do not foreseen actions when a number of such wrong timestamps 
come close next after each other.

When such a situation occurs the only cure might be to clear all data in the 
klimalogg memory.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Reading historical data from Klimalogg Pro

[Luc Heijst]

Hi Eddy,

At startup the klimalogg driver reads the timestamp of the most recent record 
in the weewx database.
It then tries to read all records in the klimalogg memory with a bigger time 
stamp until no newer records can't be found.
Then the driver starts collecting the recent data each five minutes.
When you want to start all over with reading all records of the klimalogg (this 
can be as many as 51.200 !!) you will have to stop weewx, delete or rename your 
weewx database file and start weewx. This process can take many hours, 
sometimes several days, to complete depending of the speed of your 
computersystem.

If you don't want to start all over, but read the data back since a certain 
date, you need to delete all newer records in the weewx database and then 
restart weewx.

Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Weewx and Meteotemplate

[Luc Heijst]

Hi Marty,
I tried to convince a year ago a meteorologist and the ceo at WU that they had 
to solve the problems of their data aquisition, but it seemed to be to deaf 
ears. 
I wouldn't gamble one single penny on their stock market nowadays.
Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Weewx and Meteotemplate

[Luc Heijst]

To all,

As you might probably know already, I'm addicted to WeeWX and Meteotemplate.
I don't have to explain to you the benefits of WeeWX, do I?

For the presentation and analysis of my weather data I use Meteotemplate.

Recently Meteotemplate created its own dedicated forum, see: 
http://www.meteotemplate.com/forum/index.php

Cheers, Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWX, Meteostick & Davis Repeater Issues

[Luc Heijst]

To all,
The messages which are received via a repeater in the meteostick device use a 
different kind of CRC16 check.
We detected how it works. First of all we need the 10-byte raw data instead of 
the 8-byte raw data we used in the past.
For the calculation we have to combine bytes 1 to 6 and 9 to 10 in one 8-byte 
array.
Then calculate the CRC16 value.
The result then must be equal to the value in bytes 7 to 8.
Currently this new meteostick driver is in test.
Luc

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: cmon service graphs of mem_used on RPi

[Luc Heijst]

Hi Neil,

Attached three monthmem graphs from cmon.
21: Raspberry PI 2 running three instances of weewx: vantage driver, 
meteostick driver and klimalogg driver.
31: Raspberry PI 3 running weewx simulator driver and taking webcam 
snapshots between 07:00 and 19:00 each two minutes.
32: Raspberry PI 3 running weewx simulator driver and taking webcam 
snapshots between 07:00 and 19:00 each two minutes.

See: www.lucdesign.nl

Cheers, Luc

On Thursday, 27 July 2017 05:04:14 UTC-3, Neil Trimboy wrote:
>
> I'd be grateful if someone could post some cmon service graphs of mem_used 
> of weewx running on a Pi.
> Id like to know/see typical use.
> Attached is mine...I am in the process of setting up my weewx install. so 
> the large spikes are updates/installs and several reboots, but it looks 
> like I have a memory leak somewhere, which would not be a surprise and I 
> have some bits of my own code running
>
> Thanks
>
>
> 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWX, Meteostick & Davis Repeater Issues

[Luc Heijst]

Hi Michael,

Currently weewx is receiving your stations pressure data from the sensor 
inside the meteostick device.
As outside temperature and -humidity are not received currently from the 
ISS, the calculated values for barometer are not valid and preset with NONE.

Luc

On Sunday, 30 July 2017 05:52:51 UTC-3, aschaue...@gmail.com wrote:
>
> Hi folks,
>
> i want to migrate from meteohub system (via serial interface) to weewx 
> with meteostick.
>
> with meteostick and meteohub i had the problem with poor reception quality 
> of meteostick.
> i have a davis repeater here, and brought it into operation. with the 
> repeater i got good reception of ISS, soil station and additional temp/hum. 
> only the wireless anemometer station is near enough to be received directly.
>
> meanwhile i´ve set up a weewx system with raspian and got the meteostick 
> driver running. but there are a few issues:
> wind sensor is received by meteostick directly and displayed on the weewx 
> startpage. all other stations (ISS, SoilTemp, additional TempHum) are not 
> displayed on the weewx start page. interestingly the values of the 
> tempsensor on the stick is displayed, but not the values of the pressure 
> sensor.
> when i got meteostick working, pressure values were displayed, but quitted 
> after few hours. so the only values i get are winddir and speed (via direct 
> reception) and inside temperature. data via the davis repeater are not 
> displayed.
>
> maybe i´ve overseen oder forgotten some .conf customizing? file ist 
> attached. i appreciate every help.
>
> thx, Michael
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWX, Meteostick & Davis Repeater Issues

[Luc Heijst]

Hi Michael,

The raw data received from the Davis equipment can be read as 8-byte data 
and 10-byte data.
The current meteostick driver only reads the 8-bit data.

The 10-bit data is used for raw data received from a repeater, As we so far 
didn't had any testers with a repeater, we couldn't find out the used 
protocol.
As you might know Davis nor Smartbedded were giving details about these 
protocols. 

I like to help you (and you are helping me!) discovering this 10-byte 
protocol to be able to extend the meteostick driver for use with repeaters.
I will contact you via private mail.

Cheers, Luc

On Sunday, 30 July 2017 05:52:51 UTC-3, aschaue...@gmail.com wrote:
>
> Hi folks,
>
> i want to migrate from meteohub system (via serial interface) to weewx 
> with meteostick.
>
> with meteostick and meteohub i had the problem with poor reception quality 
> of meteostick.
> i have a davis repeater here, and brought it into operation. with the 
> repeater i got good reception of ISS, soil station and additional temp/hum. 
> only the wireless anemometer station is near enough to be received directly.
>
> meanwhile i´ve set up a weewx system with raspian and got the meteostick 
> driver running. but there are a few issues:
> wind sensor is received by meteostick directly and displayed on the weewx 
> startpage. all other stations (ISS, SoilTemp, additional TempHum) are not 
> displayed on the weewx start page. interestingly the values of the 
> tempsensor on the stick is displayed, but not the values of the pressure 
> sensor.
> when i got meteostick working, pressure values were displayed, but quitted 
> after few hours. so the only values i get are winddir and speed (via direct 
> reception) and inside temperature. data via the davis repeater are not 
> displayed.
>
> maybe i´ve overseen oder forgotten some .conf customizing? file ist 
> attached. i appreciate every help.
>
> thx, Michael
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: LaCrosse 2813U on Rpi Zero W - A little help for the new guy please

[Luc Heijst]

Dan,

Check the stations altitude in weewx.conf
The units must be foot and not feet.

Luc


On Thursday, 13 July 2017 12:45:53 UTC-3, Dan Blanchard wrote:
>
> I see a syslog and a syslog1 which I have attached both.  Will this help?  
>
> On Thursday, July 13, 2017 at 8:30:59 AM UTC-7, Andrew Milner wrote:
>>
>> If you have a separate weewx log then that one - else syslog
>>
>>
>>
>> On Thursday, 13 July 2017 18:27:00 UTC+3, Dan Blanchard wrote:
>>
>>> Andrew, I understand your point and meant to send the log but got 
>>> wrapped up in thinking it was working last night.  Which log are you asking 
>>> for?  There are several logs at /var/log
>>>
>>> On Wednesday, July 12, 2017 at 10:31:17 PM UTC-7, Andrew Milner wrote:

 As Matthew said in his post - attaching the log from just before 
 start-up of weewx would help us all to know exactly what is happening, and 
 what (if any) error messages you are receiving.

 If the log by itself does not provide all the information you may need 
 to stop weewx, set debug=1 in weewx.conf, restart weewx and get additional 
 debug information.

 Trying to help without seeing the log is a little bit like looking for 
 a needle in a haystack - virtually impossible!!

 The log is usually key to all problems, and seeing the log through the 
 whole start-up process up to the end of the first archive period usually 
 sheds some light on problems and issues in most situations.  Remember - 
 the 
 log is the key!!





 On Thursday, 13 July 2017 08:09:45 UTC+3, Dan Blanchard wrote:

> Further to this issue, I found that if I type sudo wee_device --info then 
> press the [Set] button on my station, the Tx and Rx start communicating 
> again for a few minutes. But I can't seem to keep them connected. 
>
> Is there some trick to keep them paired once I finally get them 
> paired?  I'm going to leave it on overnight and see what happens.
>
>  
>
>
> On Wednesday, July 12, 2017 at 9:06:27 PM UTC-7, Dan Blanchard wrote:
>>
>> Thanks for the info Gary, that was the problem, I got it to pair, but 
>> then in un-paired after about 2-3 minutes.  Any thoughts there?
>>
>>
>>
>> On Wednesday, July 12, 2017 at 5:57:05 PM UTC-7, gjr80 wrote:
>>>
>>> On Thursday, 13 July 2017 10:28:36 UTC+10, Dan Blanchard wrote:

 usb.USBError: error sending control message: Operation not 
 permitted 

>>>
>>> Hi,
>>>
>>> Sounds like a permission issue, try prefixing the command with sudo:
>>>
>>> $ sudo wee_device --pair
>>>
>>> Gary
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.