Re: [weewx-user] weewx 4.x python3 Syslog problem

2021-01-23 Thread vince
On Friday, January 22, 2021 at 11:52:32 PM UTC-8 nady...@gmail.com wrote:

> pi@pi-weewx:/var/log $ logger -p user.debug "This is a debug message"
>
> pi@pi-weewx:/var/log $ ls -l /var/log/syslog*
> -rw-r- 1 root adm  0 Jän 23 00:00 /var/log/syslog
> -rw-r- 1 root adm 284251 Jän 22 19:44 /var/log/syslog.1
> -rw-r- 1 root adm  31249 Jän 20 16:15 /var/log/syslog.2.gz
> -rw-r- 1 root adm 109457 Jän 14 18:44 /var/log/syslog.3.gz
>

See if the logger message got into your logs.

grep "debug message" /var/log/syslog.1

And do a 'ls -l /var/log/messages*' as well, and grep for the same string 
in any messages file that does not have a .gz extension.

 

-- 
You received this message because you are subscribed 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/8ef87c41-53c5-4d7c-9814-f9d0598c20b6n%40googlegroups.com.


Re: [weewx-user] weewx 4.x python3 Syslog problem

2021-01-23 Thread Manfred Nadymacek
Hello,
as i sadly said there is no entry
pi@pi-weewx:/var/log $ ls -l syslog*
-rw-r- 1 root adm  0 Jän 23 00:00 syslog
-rw-r- 1 root adm 284251 Jän 22 19:44 syslog.1
-rw-r- 1 root adm  31249 Jän 20 16:15 syslog.2.gz
-rw-r- 1 root adm 109457 Jän 14 18:44 syslog.3.gz
pi@pi-weewx:/var/log $ grep "debug message" /var/log/syslog*
pi@pi-weewx:/var/log $ ls -l messages*
-rw-r- 1 root adm 274810 Jän 22 19:44 messages
-rw-r- 1 root adm 602120 Jän 20 16:15 messages.1
pi@pi-weewx:/var/log $ grep "debug message" /var/log/messages
pi@pi-weewx:/var/log $


And the .gz is obviously a log file rotator.

kr

Am Sa., 23. Jan. 2021 um 09:20 Uhr schrieb vince :

> On Friday, January 22, 2021 at 11:52:32 PM UTC-8 nady...@gmail.com wrote:
>
>> pi@pi-weewx:/var/log $ logger -p user.debug "This is a debug message"
>>
>> pi@pi-weewx:/var/log $ ls -l /var/log/syslog*
>> -rw-r- 1 root adm  0 Jän 23 00:00 /var/log/syslog
>> -rw-r- 1 root adm 284251 Jän 22 19:44 /var/log/syslog.1
>> -rw-r- 1 root adm  31249 Jän 20 16:15 /var/log/syslog.2.gz
>> -rw-r- 1 root adm 109457 Jän 14 18:44 /var/log/syslog.3.gz
>>
>
> See if the logger message got into your logs.
>
> grep "debug message" /var/log/syslog.1
>
> And do a 'ls -l /var/log/messages*' as well, and grep for the same string
> in any messages file that does not have a .gz extension.
>
>
>
> --
> You received this message because you are subscribed 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/8ef87c41-53c5-4d7c-9814-f9d0598c20b6n%40googlegroups.com
> 
> .
>

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


[weewx-user] Raspberry Pi 4 + WMR89 = CP210X driver problem

2021-01-23 Thread Dani Macías Perea
Hello,

I have a Raspberry Pi 4 model B 8GB running 5.4.79-v7l+. I have bought it 
to replace my previous Raspberry Pi 3. The Pi 3 was connected via USB with 
an Oregon Scientific Weather Station (WMR89) and used CP210X driver to 
communicate with it. As the pair Vendor/Product ID wasn't registered in the 
driver CP210x.c, I added it using

echo 0fde ca0a > /sys/bus/usb-serial/drivers/cp210x/new_id
in boot (rc.local). With the Raspberry Pi 3 the weather station was always 
automatically recognised, drivers loaded and accesible though /dev/ttyUSB 
and weewx run without problems.

However, I am unable to get the same results with the Raspberry Pi 4. I 
have to unplug and plug manually every time the device to get it loaded. I 
have even built a new cp210x module including oregon's pair vendor/product 
ID to see if it helps but I am still stuck in the same point: I need to 
plug and unplug the USB cable from the weather station to make it work. 
Replugging the type A connector in the Raspberry Pi will make no 
difference. I have to replug the mini USB in the weather station to make it 
work (what seems really strange). 

Does anybody has an idea on how to solve this problem?

Thanks!

Daniel  

-- 
You received this message because you are subscribed 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/cdad0220-4505-49c9-8096-389d190ec598n%40googlegroups.com.


[weewx-user] Re: Raspberry Pi 4 + WMR89 = CP210X driver problem

2021-01-23 Thread 'rob.s...@googlemail.com' via weewx-user
I had similar problems. In the end I opted for to use sdr interface and 
pick up the signal dorect from the sensors. Added a BME280 to the RPi for 
pressure and greenhouse temperature. Very pleased with the result.

On Saturday, 23 January 2021 at 10:38:47 UTC dani.mac...@gmail.com wrote:

> Hello,
>
> I have a Raspberry Pi 4 model B 8GB running 5.4.79-v7l+. I have bought it 
> to replace my previous Raspberry Pi 3. The Pi 3 was connected via USB with 
> an Oregon Scientific Weather Station (WMR89) and used CP210X driver to 
> communicate with it. As the pair Vendor/Product ID wasn't registered in the 
> driver CP210x.c, I added it using
>
> echo 0fde ca0a > /sys/bus/usb-serial/drivers/cp210x/new_id
> in boot (rc.local). With the Raspberry Pi 3 the weather station was always 
> automatically recognised, drivers loaded and accesible though /dev/ttyUSB 
> and weewx run without problems.
>
> However, I am unable to get the same results with the Raspberry Pi 4. I 
> have to unplug and plug manually every time the device to get it loaded. I 
> have even built a new cp210x module including oregon's pair vendor/product 
> ID to see if it helps but I am still stuck in the same point: I need to 
> plug and unplug the USB cable from the weather station to make it work. 
> Replugging the type A connector in the Raspberry Pi will make no 
> difference. I have to replug the mini USB in the weather station to make it 
> work (what seems really strange). 
>
> Does anybody has an idea on how to solve this problem?
>
> Thanks!
>
> Daniel  
>

-- 
You received this message because you are subscribed 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/84e106d0-d8f4-4029-b3aa-0508cc19c3d9n%40googlegroups.com.


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

2021-01-23 Thread 'rob.s...@googlemail.com' via weewx-user
I hacked sdr.py to add a pressure reading when it processes the packers 
from the other sensors. Seemed easier than tryi g to run a second service.
On Saturday, 23 January 2021 at 02:52:25 UTC gary@gmail.com wrote:

> I have a retired friend who has been admiring my PWS and my website and 
> now wishes his own.
>
> He doesn't have any other way to obtain the data, so after suggesting the 
> WLL or a logger and finding that his funds are tight, we decided on an SDR 
> and a BMP280 in a Pi.
>
> Thanks to Luc, the SDR is up and running. We interfaced with the BMP280, 
> but I am unable to find a service to read the barometer info into WeeWX.
>
> How do we go about adding the BMP to WeeWX with the SDR?
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/d50fd8c6-7a3d-460e-87c7-8c753b8b12ccn%40googlegroups.com.


Re: [weewx-user] Re: Weewx StdReport FTP is not uploading... ?

2021-01-23 Thread Invisible Man
>1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a location 
usually associated with a Debian package installer, but the rest of weewx 
is in /home/weewx, which is usually >associated with a setup.py install. Is 
that what you intended?

Yes, that's "normal", it is because a long time ago, when there were no 
Debian package yet, I had installed it in /home/weewx. Then, there was a 
Debian package, and I decided to use that but still use lots of things from 
the /home/weewx directory. 

However, it is worth checking, so I checked : I have a weewx.conf only in 
/etc/weewx. There is none for instance in /home/weewx tree. (there are 
still more weewx.conf files than I expected, but I think it is normal).

$ locate weewx.conf
/etc/weewx/apache/conf.d/weewx.conf
/etc/weewx/logwatch/conf/logfiles/weewx.conf
/etc/weewx/logwatch/conf/services/weewx.conf
/etc/weewx/rsyslog.d/weewx.conf
/etc/weewx/weewx.conf
/etc/weewx/weewx.conf-3.5.0
/etc/weewx/weewx.conf-4.1.1
/etc/weewx/weewx.conf-4.2.0
/etc/weewx/weewx.conf-4.3.0
/etc/weewx/weewx.conf.20191208202810
/etc/weewx/weewx.conf.2020163218
/etc/weewx/weewx.conf.20210120225317
/etc/weewx/weewx.conf.20210120225326
/etc/weewx/weewx.conf.bak
/etc/weewx/weewx.conf.dist
/etc/weewx/weewx.conf.dpkg-dist
/etc/weewx/weewx.conf.my.4.2.0
/etc/weewx/weewx.conf~
/home/axelle/anonymized-weewx.conf
/home/axelle/anonymized-weewx.conf~
/var/lib/dpkg/info/weewx.conffiles
/var/lib/dpkg/info/weewx.config

>2. You have both FTP *and* rsync enabled. Is that what you intended?

Yes. My setup is slightly complicated but I am backuping the website 
locally to another host, and using rsync for that. I am also uploading the 
website to an external host, and that host only has FTP. That's why I use 
both. But each is going to a different location.
However, I'll give it a try by disabling some services (but indeed I don't 
think that's the issue).

>3. What happens if you try and use wee_reports? Does that work?

Oh nice idea!
It is failing. But it seems like another issue... A French accent in 
weewx.conf perhaps ?

$ wee_reports /etc/weewx/weewx.conf
Using configuration file /etc/weewx/weewx.conf
Generating for all time
Traceback (most recent call last):
  File "/usr/share/weewx/wee_reports", line 103, in 
main()
  File "/usr/share/weewx/wee_reports", line 99, in main
t.run()
  File "/usr/share/weewx/weewx/reportengine.py", line 141, in run
skin_dict = self._build_skin_dict(report)
  File "/usr/share/weewx/weewx/reportengine.py", line 249, in 
_build_skin_dict
merge_dict = 
weeutil.config.deep_copy(self.config_dict)['StdReport']['Defaults']
  File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
new_value = deep_copy(old_value, new_dict, new_dict.depth+1, 
new_dict.main)
  File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
new_value = deep_copy(old_value, new_dict, new_dict.depth+1, 
new_dict.main)
  File "/usr/share/weewx/weeutil/config.py", line 262, in deep_copy
new_dict.comments[entry] = [str(x) for x in old_dict.comments[entry]]
UnicodeEncodeError: 'ascii' codec can't encode character u'\xb0' in 
position 56: ordinal not in range(128)

On Friday, January 22, 2021 at 11:08:39 PM UTC+1 tke...@gmail.com wrote:

> Rather strange. A few questions:
>
> 1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a location 
> usually associated with a Debian package installer, but the rest of weewx 
> is in /home/weewx, which is usually associated with a setup.py install. Is 
> that what you intended?
>
> 2. You have both FTP *and* rsync enabled. Is that what you intended?
>
> However, I don't know why either of these would cause your reports not to 
> run to completion.
>
> 3. What happens if you try and use wee_reports? Does that work?
>
> -tk
>
>
> On Fri, Jan 22, 2021 at 12:55 PM Invisible Man  
> wrote:
>
>> I've re-read the documentation for the wmr200 driver extension (
>> https://github.com/weewx/weewx-wmr200). I'm not sure my configuration is 
>> correct. I don't understand the doc very well .
>>
>> - Am I meant to have something in sensor_map, or is default correct?
>> - Am I meant to have mode set to something?
>> - Am I meant to uncomment driver = weewx.drivers.simulator ?
>>
>> This is what I have:
>>
>> [WMR200]
>> # This section is for the Oregon Scientific WMR200
>> 
>> # The station model, e.g., WMR200, WMR200A, Radio Shack W200
>> model = WMR200
>> 
>> # The driver to use:
>> driver = user.wmr200
>> 
>> # default is 300 seconds
>> archive_interval = 600
>> 
>> 
>> 
>> ###
>> ###
>> 
>> #[Simulator]
>> # This section for the weewx weather station simulator
>> 
>> # The time (in seconds) between LOOP packets.
>> loop_interval = 2.5
>> erase_archive = False
>> sensor_status = True
>> archive_threshold = 1512000
>> archive_startup = 120
>> user_pc

Re: [weewx-user] Re: weewx 3.8.2 and drivers weather station WS1041

2021-01-23 Thread Sergi Mola
Did you make it work? I received a WS1040 station last Christmas and I 
wanted to connect it to weewx.
Thank you!

On Tuesday, 29 January 2019 at 13:18:36 UTC+1 mwall wrote:

> On Tuesday, January 29, 2019 at 5:14:32 AM UTC-5, Wifi75 wrote:
>>
>> at each time I have already installed everything.
>> just a problem I can not understand this important command to be given:
>> # see how the sensor data from rtl_433 are mapped to fully-qualified names
>> sudo PYTHONPATH = / usr / share / weewx python 
>> /usr/share/weewx/user/sdr.py --cmd = "rtl_433 -M utc -F json -G"
>>
>> weewx is installed on raspberry in home / weewx
>> can you help me to understand the correct command to execute?
>>
>
> please read the wiki page about paths:
>
> https://github.com/weewx/weewx/wiki/Understanding-paths
>
> assuming that rtl_433 works properly, and if you installed using setup.py 
> to /home/weewx, and if your rtl_433 command is the invocation described in 
> the sdr guide, then you probably want something like this:
>
> sudo PYTHONPATH=/home/weewx/bin python /home/weewx/bin/user/sdr.py 
> --cmd="rtl_433 -M utc -F json -G"
>
> 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/e28533ee-64e5-44a0-9489-e6860c75f5d4n%40googlegroups.com.


Re: [weewx-user] Re: Weewx StdReport FTP is not uploading... ?

2021-01-23 Thread Tom Keffer
Yes, that was fixed with commit 624fb9e
.
It's only a problem under Python 2.7.

On Sat, Jan 23, 2021 at 4:35 AM Invisible Man 
wrote:

> >1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a location
> usually associated with a Debian package installer, but the rest of weewx
> is in /home/weewx, which is usually >associated with a setup.py install. Is
> that what you intended?
>
> Yes, that's "normal", it is because a long time ago, when there were no
> Debian package yet, I had installed it in /home/weewx. Then, there was a
> Debian package, and I decided to use that but still use lots of things from
> the /home/weewx directory.
>
> However, it is worth checking, so I checked : I have a weewx.conf only in
> /etc/weewx. There is none for instance in /home/weewx tree. (there are
> still more weewx.conf files than I expected, but I think it is normal).
>
> $ locate weewx.conf
> /etc/weewx/apache/conf.d/weewx.conf
> /etc/weewx/logwatch/conf/logfiles/weewx.conf
> /etc/weewx/logwatch/conf/services/weewx.conf
> /etc/weewx/rsyslog.d/weewx.conf
> /etc/weewx/weewx.conf
> /etc/weewx/weewx.conf-3.5.0
> /etc/weewx/weewx.conf-4.1.1
> /etc/weewx/weewx.conf-4.2.0
> /etc/weewx/weewx.conf-4.3.0
> /etc/weewx/weewx.conf.20191208202810
> /etc/weewx/weewx.conf.2020163218
> /etc/weewx/weewx.conf.20210120225317
> /etc/weewx/weewx.conf.20210120225326
> /etc/weewx/weewx.conf.bak
> /etc/weewx/weewx.conf.dist
> /etc/weewx/weewx.conf.dpkg-dist
> /etc/weewx/weewx.conf.my.4.2.0
> /etc/weewx/weewx.conf~
> /home/axelle/anonymized-weewx.conf
> /home/axelle/anonymized-weewx.conf~
> /var/lib/dpkg/info/weewx.conffiles
> /var/lib/dpkg/info/weewx.config
>
> >2. You have both FTP *and* rsync enabled. Is that what you intended?
>
> Yes. My setup is slightly complicated but I am backuping the website
> locally to another host, and using rsync for that. I am also uploading the
> website to an external host, and that host only has FTP. That's why I use
> both. But each is going to a different location.
> However, I'll give it a try by disabling some services (but indeed I don't
> think that's the issue).
>
> >3. What happens if you try and use wee_reports? Does that work?
>
> Oh nice idea!
> It is failing. But it seems like another issue... A French accent in
> weewx.conf perhaps ?
>
> $ wee_reports /etc/weewx/weewx.conf
> Using configuration file /etc/weewx/weewx.conf
> Generating for all time
> Traceback (most recent call last):
>   File "/usr/share/weewx/wee_reports", line 103, in 
> main()
>   File "/usr/share/weewx/wee_reports", line 99, in main
> t.run()
>   File "/usr/share/weewx/weewx/reportengine.py", line 141, in run
> skin_dict = self._build_skin_dict(report)
>   File "/usr/share/weewx/weewx/reportengine.py", line 249, in
> _build_skin_dict
> merge_dict =
> weeutil.config.deep_copy(self.config_dict)['StdReport']['Defaults']
>   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
> new_value = deep_copy(old_value, new_dict, new_dict.depth+1,
> new_dict.main)
>   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
> new_value = deep_copy(old_value, new_dict, new_dict.depth+1,
> new_dict.main)
>   File "/usr/share/weewx/weeutil/config.py", line 262, in deep_copy
> new_dict.comments[entry] = [str(x) for x in old_dict.comments[entry]]
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xb0' in
> position 56: ordinal not in range(128)
>
> On Friday, January 22, 2021 at 11:08:39 PM UTC+1 tke...@gmail.com wrote:
>
>> Rather strange. A few questions:
>>
>> 1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a location
>> usually associated with a Debian package installer, but the rest of weewx
>> is in /home/weewx, which is usually associated with a setup.py install. Is
>> that what you intended?
>>
>> 2. You have both FTP *and* rsync enabled. Is that what you intended?
>>
>> However, I don't know why either of these would cause your reports not to
>> run to completion.
>>
>> 3. What happens if you try and use wee_reports? Does that work?
>>
>> -tk
>>
>>
>> On Fri, Jan 22, 2021 at 12:55 PM Invisible Man 
>> wrote:
>>
>>> I've re-read the documentation for the wmr200 driver extension (
>>> https://github.com/weewx/weewx-wmr200). I'm not sure my configuration
>>> is correct. I don't understand the doc very well .
>>>
>>> - Am I meant to have something in sensor_map, or is default correct?
>>> - Am I meant to have mode set to something?
>>> - Am I meant to uncomment driver = weewx.drivers.simulator ?
>>>
>>> This is what I have:
>>>
>>> [WMR200]
>>> # This section is for the Oregon Scientific WMR200
>>>
>>> # The station model, e.g., WMR200, WMR200A, Radio Shack W200
>>> model = WMR200
>>>
>>> # The driver to use:
>>> driver = user.wmr200
>>>
>>> # default is 300 seconds
>>> archive_interval = 600
>>>
>>>
>>>
>>> 

Re: [weewx-user] Weewx 4.3.0 and weewx multi on a fresh install

2021-01-23 Thread sc.lep...@gmail.com
Hello  back 

systemctl is the default system to start /stop / manage service on a Debian 
10 / Ubuntu  Centos 7 /8 and in future  Centos  Stream ( ?) 
the two systems coexist (init.d and systemctl) : We can use start / stop 
system via init.d  ,  the weex-multi script is for this system and dont 
work fine  with systemctl service.

I find a wiki page   here https://github.com/weewx/weewx/wiki/systemd  by 
CameronD73 ( but  I dont find  how to contact his author) 

So  i use this system  for  my WMR200 station (weewx-WMR200.service) and 
another file service  wwewx-FROGGIT.service : 
(this file is in tar.gz source weewx).

I put them in /etc/system.d/system/

stef@debian-weewx:/etc/systemd/system$ ls  -l weewx*
-rw-r--r-- 1 root root 460 janv. 22 23:41 weewx-FROGGIT.service
-rw-r--r-- 1 root root 455 janv. 22 23:41 weewx-WMR200.service
stef@debian-weewx:/etc/systemd/system$


I unsunscribe the init.d service ("weewx service") from init.d  (rc)

And now  , I ve to service which control my 2 stations ! 

stef@debian-weewx:/etc/systemd/system$ ps  -ef | grep weewx
avahi  474 1  0 13:32 ?00:00:00 avahi-daemon: running 
[debian-weewx.local]
root   559 1  0 13:32 ?00:00:04 python3 
/usr/share/weewx/weewxd --daemon --log-label weewx-FROGGIT 
--pidfile=/run/weewx-FROGGIT.pid /etc/weewx/FROGGIT.conf
root   632 1  0 13:32 ?00:00:04 python3 
/usr/share/weewx/weewxd --daemon --log-label weewx-WMR200 
--pidfile=/run/weewx-WMR200.pid /etc/weewx/WMR200.conf
stef  1684  1643  0 13:56 pts/000:00:00 grep weewx
stef@debian-weewx:/etc/systemd/system$


I will write a post blog on my website in few days.


Perhaps weex-multi must be write for systemctl control service 

Thansk a lot every one  ! 

I ve got a solution  ;) 

Thanks  Gary, Vince, Eddy 

Stéphane 


Le samedi 23 janvier 2021 à 03:21:45 UTC+1, graha...@gmail.com a écrit :

> hmm just recalled that was only for weewx process owned by non-root user - 
> presumably not relevant
>
> On 23 Jan 2021, at 1:18 pm, Graham Eddy  wrote:
>
> this sounds like the posting i made about 12 months ago where ‘stop’ does 
> not work because the options on start-stop-daemon changed and you had to 
> add an extra argument - without the new arg the ‘stop’ silently fails
>
> On 23 Jan 2021, at 9:02 am, vince  wrote:
>
> Gary - I would agree that 'stop' does not work on a debian10 system but 
> 'start' works fine.   Same problem exists regardless of whether you use the 
> init.d file directly or if you use systemctl to let systemd control the 
> processes.  Start works.  Stop silently does nothing.  Nothing I could see 
> in the logs to indicate that it even tried to shut the processes down. 
>
>
>
>

-- 
You received this message because you are subscribed 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/e3d4bdbd-4412-483c-9b46-a1feefca349en%40googlegroups.com.


Re: [weewx-user] Re: Weewx StdReport FTP is not uploading... ?

2021-01-23 Thread Invisible Man
> Yes, that was fixed with commit 624fb9e 
.
 
It's only a problem under Python 2.7.

Ok, I manually applied the fix to config.py, and now *wee_reports runs* :)

$ wee_reports /etc/weewx/weewx.conf
Using configuration file /etc/weewx/weewx.conf
Generating for all time


   - The files in public_html have been updated :-) (that's my HTML_ROOT)
   - The external website has been updated :-) so the FTP worked for sure.
   - The RSYNC also worked :-)
   - I don't have anything more related to reports in the logs, but perhaps 
   wee_reports does not log there.

So, *it is working with wee_reports* (which is already a workaround), *but 
not automatically.*

Side question: would it help that I use python 3.x instead? 

On Saturday, January 23, 2021 at 1:49:56 PM UTC+1 tke...@gmail.com wrote:

> Yes, that was fixed with commit 624fb9e 
> .
>  
> It's only a problem under Python 2.7.
>
> On Sat, Jan 23, 2021 at 4:35 AM Invisible Man  
> wrote:
>
>> >1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a location 
>> usually associated with a Debian package installer, but the rest of weewx 
>> is in /home/weewx, which is usually >associated with a setup.py install. Is 
>> that what you intended?
>>
>> Yes, that's "normal", it is because a long time ago, when there were no 
>> Debian package yet, I had installed it in /home/weewx. Then, there was a 
>> Debian package, and I decided to use that but still use lots of things from 
>> the /home/weewx directory. 
>>
>> However, it is worth checking, so I checked : I have a weewx.conf only in 
>> /etc/weewx. There is none for instance in /home/weewx tree. (there are 
>> still more weewx.conf files than I expected, but I think it is normal).
>>
>> $ locate weewx.conf
>> /etc/weewx/apache/conf.d/weewx.conf
>> /etc/weewx/logwatch/conf/logfiles/weewx.conf
>> /etc/weewx/logwatch/conf/services/weewx.conf
>> /etc/weewx/rsyslog.d/weewx.conf
>> /etc/weewx/weewx.conf
>> /etc/weewx/weewx.conf-3.5.0
>> /etc/weewx/weewx.conf-4.1.1
>> /etc/weewx/weewx.conf-4.2.0
>> /etc/weewx/weewx.conf-4.3.0
>> /etc/weewx/weewx.conf.20191208202810
>> /etc/weewx/weewx.conf.2020163218
>> /etc/weewx/weewx.conf.20210120225317
>> /etc/weewx/weewx.conf.20210120225326
>> /etc/weewx/weewx.conf.bak
>> /etc/weewx/weewx.conf.dist
>> /etc/weewx/weewx.conf.dpkg-dist
>> /etc/weewx/weewx.conf.my.4.2.0
>> /etc/weewx/weewx.conf~
>> /home/axelle/anonymized-weewx.conf
>> /home/axelle/anonymized-weewx.conf~
>> /var/lib/dpkg/info/weewx.conffiles
>> /var/lib/dpkg/info/weewx.config
>>
>> >2. You have both FTP *and* rsync enabled. Is that what you intended?
>>
>> Yes. My setup is slightly complicated but I am backuping the website 
>> locally to another host, and using rsync for that. I am also uploading the 
>> website to an external host, and that host only has FTP. That's why I use 
>> both. But each is going to a different location.
>> However, I'll give it a try by disabling some services (but indeed I 
>> don't think that's the issue).
>>
>> >3. What happens if you try and use wee_reports? Does that work?
>>
>> Oh nice idea!
>> It is failing. But it seems like another issue... A French accent in 
>> weewx.conf perhaps ?
>>
>> $ wee_reports /etc/weewx/weewx.conf
>> Using configuration file /etc/weewx/weewx.conf
>> Generating for all time
>> Traceback (most recent call last):
>>   File "/usr/share/weewx/wee_reports", line 103, in 
>> main()
>>   File "/usr/share/weewx/wee_reports", line 99, in main
>> t.run()
>>   File "/usr/share/weewx/weewx/reportengine.py", line 141, in run
>> skin_dict = self._build_skin_dict(report)
>>   File "/usr/share/weewx/weewx/reportengine.py", line 249, in 
>> _build_skin_dict
>> merge_dict = 
>> weeutil.config.deep_copy(self.config_dict)['StdReport']['Defaults']
>>   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
>> new_value = deep_copy(old_value, new_dict, new_dict.depth+1, 
>> new_dict.main)
>>   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
>> new_value = deep_copy(old_value, new_dict, new_dict.depth+1, 
>> new_dict.main)
>>   File "/usr/share/weewx/weeutil/config.py", line 262, in deep_copy
>> new_dict.comments[entry] = [str(x) for x in old_dict.comments[entry]]
>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xb0' in 
>> position 56: ordinal not in range(128)
>>
>> On Friday, January 22, 2021 at 11:08:39 PM UTC+1 tke...@gmail.com wrote:
>>
>>> Rather strange. A few questions:
>>>
>>> 1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a location 
>>> usually associated with a Debian package installer, but the rest of weewx 
>>> is in /home/weewx, which is usually associated with a setup.py install. Is 
>>> that what you intended?
>>>
>>> 2. You have both FTP *and* rsync enabled. Is that what you intended?
>>>
>>> However, I do

[weewx-user] PM10 in ecowitt WH41 sensor?

2021-01-23 Thread Graham Eddy
fiddling with SDR trying to find some other sensor, i notice the following from 
rtl_433:
time  : 2021-01-24 00:02:08
model : Fineoffset-WH0290  ID: 4
2.5um Fine Particulate Matter: 8 ug/m3 10um Coarse Particulate 
Matter: 9 ug/m3
Integrity : CRC
which clearly says the ecowitt WH41 is transmitting PM10 value as well as PM2.5

i don't see the PM10 value appearing in WH41 ‘manual’, nor in gary’s gw1000 
driver. is there some way to extract this PM10 value other than via SDR?



-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/75A1DDCC-3F98-4CD6-95BE-3C9A55A2E720%40gmail.com.


Re: [weewx-user] Re: Weewx StdReport FTP is not uploading... ?

2021-01-23 Thread Invisible Man
I'm going to shift to python3. Let you know when it's done. Besides my bug, 
I think it's a good idea to abandon python 2.7 ;-)

On Saturday, January 23, 2021 at 2:20:26 PM UTC+1 Invisible Man wrote:

> > Yes, that was fixed with commit 624fb9e 
> .
>  
> It's only a problem under Python 2.7.
>
> Ok, I manually applied the fix to config.py, and now *wee_reports runs* :)
>
> $ wee_reports /etc/weewx/weewx.conf
> Using configuration file /etc/weewx/weewx.conf
> Generating for all time
>
>
>- The files in public_html have been updated :-) (that's my HTML_ROOT)
>- The external website has been updated :-) so the FTP worked for sure.
>- The RSYNC also worked :-)
>- I don't have anything more related to reports in the logs, but 
>perhaps wee_reports does not log there.
>
> So, *it is working with wee_reports* (which is already a workaround), *but 
> not automatically.*
>
> Side question: would it help that I use python 3.x instead? 
>
> On Saturday, January 23, 2021 at 1:49:56 PM UTC+1 tke...@gmail.com wrote:
>
>> Yes, that was fixed with commit 624fb9e 
>> .
>>  
>> It's only a problem under Python 2.7.
>>
>> On Sat, Jan 23, 2021 at 4:35 AM Invisible Man  
>> wrote:
>>
>>> >1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a 
>>> location usually associated with a Debian package installer, but the rest 
>>> of weewx is in /home/weewx, which is usually >associated with a setup.py 
>>> install. Is that what you intended?
>>>
>>> Yes, that's "normal", it is because a long time ago, when there were no 
>>> Debian package yet, I had installed it in /home/weewx. Then, there was a 
>>> Debian package, and I decided to use that but still use lots of things from 
>>> the /home/weewx directory. 
>>>
>>> However, it is worth checking, so I checked : I have a weewx.conf only 
>>> in /etc/weewx. There is none for instance in /home/weewx tree. (there are 
>>> still more weewx.conf files than I expected, but I think it is normal).
>>>
>>> $ locate weewx.conf
>>> /etc/weewx/apache/conf.d/weewx.conf
>>> /etc/weewx/logwatch/conf/logfiles/weewx.conf
>>> /etc/weewx/logwatch/conf/services/weewx.conf
>>> /etc/weewx/rsyslog.d/weewx.conf
>>> /etc/weewx/weewx.conf
>>> /etc/weewx/weewx.conf-3.5.0
>>> /etc/weewx/weewx.conf-4.1.1
>>> /etc/weewx/weewx.conf-4.2.0
>>> /etc/weewx/weewx.conf-4.3.0
>>> /etc/weewx/weewx.conf.20191208202810
>>> /etc/weewx/weewx.conf.2020163218
>>> /etc/weewx/weewx.conf.20210120225317
>>> /etc/weewx/weewx.conf.20210120225326
>>> /etc/weewx/weewx.conf.bak
>>> /etc/weewx/weewx.conf.dist
>>> /etc/weewx/weewx.conf.dpkg-dist
>>> /etc/weewx/weewx.conf.my.4.2.0
>>> /etc/weewx/weewx.conf~
>>> /home/axelle/anonymized-weewx.conf
>>> /home/axelle/anonymized-weewx.conf~
>>> /var/lib/dpkg/info/weewx.conffiles
>>> /var/lib/dpkg/info/weewx.config
>>>
>>> >2. You have both FTP *and* rsync enabled. Is that what you intended?
>>>
>>> Yes. My setup is slightly complicated but I am backuping the website 
>>> locally to another host, and using rsync for that. I am also uploading the 
>>> website to an external host, and that host only has FTP. That's why I use 
>>> both. But each is going to a different location.
>>> However, I'll give it a try by disabling some services (but indeed I 
>>> don't think that's the issue).
>>>
>>> >3. What happens if you try and use wee_reports? Does that work?
>>>
>>> Oh nice idea!
>>> It is failing. But it seems like another issue... A French accent in 
>>> weewx.conf perhaps ?
>>>
>>> $ wee_reports /etc/weewx/weewx.conf
>>> Using configuration file /etc/weewx/weewx.conf
>>> Generating for all time
>>> Traceback (most recent call last):
>>>   File "/usr/share/weewx/wee_reports", line 103, in 
>>> main()
>>>   File "/usr/share/weewx/wee_reports", line 99, in main
>>> t.run()
>>>   File "/usr/share/weewx/weewx/reportengine.py", line 141, in run
>>> skin_dict = self._build_skin_dict(report)
>>>   File "/usr/share/weewx/weewx/reportengine.py", line 249, in 
>>> _build_skin_dict
>>> merge_dict = 
>>> weeutil.config.deep_copy(self.config_dict)['StdReport']['Defaults']
>>>   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
>>> new_value = deep_copy(old_value, new_dict, new_dict.depth+1, 
>>> new_dict.main)
>>>   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
>>> new_value = deep_copy(old_value, new_dict, new_dict.depth+1, 
>>> new_dict.main)
>>>   File "/usr/share/weewx/weeutil/config.py", line 262, in deep_copy
>>> new_dict.comments[entry] = [str(x) for x in old_dict.comments[entry]]
>>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xb0' in 
>>> position 56: ordinal not in range(128)
>>>
>>> On Friday, January 22, 2021 at 11:08:39 PM UTC+1 tke...@gmail.com wrote:
>>>
 Rather strange. A few questions:

 1. Your weewx.conf file i

Re: [weewx-user] Re: Weewx StdReport FTP is not uploading... ?

2021-01-23 Thread Tom Keffer
It is a good idea to switch. I'll be very interested to hear if it makes
any difference.

On Sat, Jan 23, 2021 at 5:31 AM Invisible Man 
wrote:

> I'm going to shift to python3. Let you know when it's done. Besides my
> bug, I think it's a good idea to abandon python 2.7 ;-)
>
> On Saturday, January 23, 2021 at 2:20:26 PM UTC+1 Invisible Man wrote:
>
>> > Yes, that was fixed with commit 624fb9e
>> .
>> It's only a problem under Python 2.7.
>>
>> Ok, I manually applied the fix to config.py, and now *wee_reports runs*
>> :)
>>
>> $ wee_reports /etc/weewx/weewx.conf
>> Using configuration file /etc/weewx/weewx.conf
>> Generating for all time
>>
>>
>>- The files in public_html have been updated :-) (that's my HTML_ROOT)
>>- The external website has been updated :-) so the FTP worked for
>>sure.
>>- The RSYNC also worked :-)
>>- I don't have anything more related to reports in the logs, but
>>perhaps wee_reports does not log there.
>>
>> So, *it is working with wee_reports* (which is already a workaround), *but
>> not automatically.*
>>
>> Side question: would it help that I use python 3.x instead?
>>
>> On Saturday, January 23, 2021 at 1:49:56 PM UTC+1 tke...@gmail.com wrote:
>>
>>> Yes, that was fixed with commit 624fb9e
>>> .
>>> It's only a problem under Python 2.7.
>>>
>>> On Sat, Jan 23, 2021 at 4:35 AM Invisible Man 
>>> wrote:
>>>
 >1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a
 location usually associated with a Debian package installer, but the rest
 of weewx is in /home/weewx, which is usually >associated with a setup.py
 install. Is that what you intended?

 Yes, that's "normal", it is because a long time ago, when there were no
 Debian package yet, I had installed it in /home/weewx. Then, there was a
 Debian package, and I decided to use that but still use lots of things from
 the /home/weewx directory.

 However, it is worth checking, so I checked : I have a weewx.conf only
 in /etc/weewx. There is none for instance in /home/weewx tree. (there are
 still more weewx.conf files than I expected, but I think it is normal).

 $ locate weewx.conf
 /etc/weewx/apache/conf.d/weewx.conf
 /etc/weewx/logwatch/conf/logfiles/weewx.conf
 /etc/weewx/logwatch/conf/services/weewx.conf
 /etc/weewx/rsyslog.d/weewx.conf
 /etc/weewx/weewx.conf
 /etc/weewx/weewx.conf-3.5.0
 /etc/weewx/weewx.conf-4.1.1
 /etc/weewx/weewx.conf-4.2.0
 /etc/weewx/weewx.conf-4.3.0
 /etc/weewx/weewx.conf.20191208202810
 /etc/weewx/weewx.conf.2020163218
 /etc/weewx/weewx.conf.20210120225317
 /etc/weewx/weewx.conf.20210120225326
 /etc/weewx/weewx.conf.bak
 /etc/weewx/weewx.conf.dist
 /etc/weewx/weewx.conf.dpkg-dist
 /etc/weewx/weewx.conf.my.4.2.0
 /etc/weewx/weewx.conf~
 /home/axelle/anonymized-weewx.conf
 /home/axelle/anonymized-weewx.conf~
 /var/lib/dpkg/info/weewx.conffiles
 /var/lib/dpkg/info/weewx.config

 >2. You have both FTP *and* rsync enabled. Is that what you intended?

 Yes. My setup is slightly complicated but I am backuping the website
 locally to another host, and using rsync for that. I am also uploading the
 website to an external host, and that host only has FTP. That's why I use
 both. But each is going to a different location.
 However, I'll give it a try by disabling some services (but indeed I
 don't think that's the issue).

 >3. What happens if you try and use wee_reports? Does that work?

 Oh nice idea!
 It is failing. But it seems like another issue... A French accent in
 weewx.conf perhaps ?

 $ wee_reports /etc/weewx/weewx.conf
 Using configuration file /etc/weewx/weewx.conf
 Generating for all time
 Traceback (most recent call last):
   File "/usr/share/weewx/wee_reports", line 103, in 
 main()
   File "/usr/share/weewx/wee_reports", line 99, in main
 t.run()
   File "/usr/share/weewx/weewx/reportengine.py", line 141, in run
 skin_dict = self._build_skin_dict(report)
   File "/usr/share/weewx/weewx/reportengine.py", line 249, in
 _build_skin_dict
 merge_dict =
 weeutil.config.deep_copy(self.config_dict)['StdReport']['Defaults']
   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
 new_value = deep_copy(old_value, new_dict, new_dict.depth+1,
 new_dict.main)
   File "/usr/share/weewx/weeutil/config.py", line 251, in deep_copy
 new_value = deep_copy(old_value, new_dict, new_dict.depth+1,
 new_dict.main)
   File "/usr/share/weewx/weeutil/config.py", line 262, in deep_copy
 new_dict.comments[entry] = [str(x) for x in
 old_dict.comments[entry]]
 UnicodeEncodeError: 'ascii' co

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

2021-01-23 Thread Greg Troxel

"gary@gmail.com"  writes:

> Thanks to Luc, the SDR is up and running. We interfaced with the BMP280, 
> but I am unable to find a service to read the barometer info into WeeWX.
>
> How do we go about adding the BMP to WeeWX with the SDR?

What I would do, perhaps more complicated than you need, is to run an
mqtt broker and publish the pressure and use MQTTSubscribe.  But if
there's already a temp path, seems best to extend it for pressure.
(IIRC the BMP280 does not have humidity, and the BME280 does).

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


signature.asc
Description: PGP signature


Re: [weewx-user] weewx 4.x python3 Syslog problem

2021-01-23 Thread Manfred Nadymacek
Hi ,
Meanwhile i install on another Rasberry Pi 3 the complete buster raspbian
again and migrate again weewx on it.
Now rsyslogd is working fine but i compare the installation and found no
difference.
Very strange !
nevertheless thanks to all it's working




Am Sa., 23. Jan. 2021 um 09:48 Uhr schrieb Manfred Nadymacek <
nady2...@gmail.com>:

> Hello,
> as i sadly said there is no entry
> pi@pi-weewx:/var/log $ ls -l syslog*
> -rw-r- 1 root adm  0 Jän 23 00:00 syslog
> -rw-r- 1 root adm 284251 Jän 22 19:44 syslog.1
> -rw-r- 1 root adm  31249 Jän 20 16:15 syslog.2.gz
> -rw-r- 1 root adm 109457 Jän 14 18:44 syslog.3.gz
> pi@pi-weewx:/var/log $ grep "debug message" /var/log/syslog*
> pi@pi-weewx:/var/log $ ls -l messages*
> -rw-r- 1 root adm 274810 Jän 22 19:44 messages
> -rw-r- 1 root adm 602120 Jän 20 16:15 messages.1
> pi@pi-weewx:/var/log $ grep "debug message" /var/log/messages
> pi@pi-weewx:/var/log $
>
>
> And the .gz is obviously a log file rotator.
>
> kr
>
> Am Sa., 23. Jan. 2021 um 09:20 Uhr schrieb vince :
>
>> On Friday, January 22, 2021 at 11:52:32 PM UTC-8 nady...@gmail.com wrote:
>>
>>> pi@pi-weewx:/var/log $ logger -p user.debug "This is a debug message"
>>>
>>> pi@pi-weewx:/var/log $ ls -l /var/log/syslog*
>>> -rw-r- 1 root adm  0 Jän 23 00:00 /var/log/syslog
>>> -rw-r- 1 root adm 284251 Jän 22 19:44 /var/log/syslog.1
>>> -rw-r- 1 root adm  31249 Jän 20 16:15 /var/log/syslog.2.gz
>>> -rw-r- 1 root adm 109457 Jän 14 18:44 /var/log/syslog.3.gz
>>>
>>
>> See if the logger message got into your logs.
>>
>> grep "debug message" /var/log/syslog.1
>>
>> And do a 'ls -l /var/log/messages*' as well, and grep for the same string
>> in any messages file that does not have a .gz extension.
>>
>>
>>
>> --
>> You received this message because you are subscribed 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/8ef87c41-53c5-4d7c-9814-f9d0598c20b6n%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CALNFVsgTBQFbA9pRO-Oe_i%2B3%2BgfhGiseJGKwB6us7yxKSwAJUQ%40mail.gmail.com.


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

2021-01-23 Thread 'rob.s...@googlemail.com' via weewx-user
I have just posted details of how to do it inside sdr.py. Seems a lot 
simpler that messing with the message queue.
https://infiniteknowledge.co.uk/2021/01/23/adding-sensors-to-a-rpi-weather-station/

On Saturday, 23 January 2021 at 13:55:40 UTC Greg Troxel wrote:

>
> "gary@gmail.com"  writes:
>
> > Thanks to Luc, the SDR is up and running. We interfaced with the BMP280, 
> > but I am unable to find a service to read the barometer info into WeeWX.
> >
> > How do we go about adding the BMP to WeeWX with the SDR?
>
> What I would do, perhaps more complicated than you need, is to run an
> mqtt broker and publish the pressure and use MQTTSubscribe. But if
> there's already a temp path, seems best to extend it for pressure.
> (IIRC the BMP280 does not have humidity, and the BME280 does).
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/77385e09-ce5c-4052-afc5-38b51415034fn%40googlegroups.com.


Re: [weewx-user] Re: Weewx StdReport FTP is not uploading... ?

2021-01-23 Thread Invisible Man
*It works! I have reports!*

Now, I suspect the issue was not coming from python 2.7, but from the 
installation of the WMR200 extension.
When I shifted from python 2.7 to 3.x, after updating the apt sources, I 
re-installed the weewx package. 
I noticed changes in weewx.conf:

1) *station_type = Simulator.* I remember that was something required. But* 
I had done it before the install of the extension*, and *when I installed 
the extension, it reverted to station_type = WMR200* (or did I do something 
wrong?) and I thought it was intentional.

2) there is *a [Simulator] section*, with driver = weewx.drivers.simulator. 

I just wonder how weewx knows it should read also the WMR200 section which 
contains user.wmr200 driver... but it works.

*I have an issue with values however: my temperature is nuts, I have no 
wind etc.* I'm going to look into that and post in a separate thread if I 
can't solve it, because it looks like a different issue.

Thanks.








On Saturday, January 23, 2021 at 2:32:16 PM UTC+1 tke...@gmail.com wrote:

> It is a good idea to switch. I'll be very interested to hear if it makes 
> any difference.
>
> On Sat, Jan 23, 2021 at 5:31 AM Invisible Man  
> wrote:
>
>> I'm going to shift to python3. Let you know when it's done. Besides my 
>> bug, I think it's a good idea to abandon python 2.7 ;-)
>>
>> On Saturday, January 23, 2021 at 2:20:26 PM UTC+1 Invisible Man wrote:
>>
>>> > Yes, that was fixed with commit 624fb9e 
>>> .
>>>  
>>> It's only a problem under Python 2.7.
>>>
>>> Ok, I manually applied the fix to config.py, and now *wee_reports runs* 
>>> :)
>>>
>>> $ wee_reports /etc/weewx/weewx.conf
>>> Using configuration file /etc/weewx/weewx.conf
>>> Generating for all time
>>>
>>>
>>>- The files in public_html have been updated :-) (that's my 
>>>HTML_ROOT)
>>>- The external website has been updated :-) so the FTP worked for 
>>>sure.
>>>- The RSYNC also worked :-)
>>>- I don't have anything more related to reports in the logs, but 
>>>perhaps wee_reports does not log there.
>>>
>>> So, *it is working with wee_reports* (which is already a workaround), *but 
>>> not automatically.*
>>>
>>> Side question: would it help that I use python 3.x instead? 
>>>
>>> On Saturday, January 23, 2021 at 1:49:56 PM UTC+1 tke...@gmail.com 
>>> wrote:
>>>
 Yes, that was fixed with commit 624fb9e 
 .
  
 It's only a problem under Python 2.7.

 On Sat, Jan 23, 2021 at 4:35 AM Invisible Man  
 wrote:

> >1. Your weewx.conf file is in /etc/weewx/weewx.conf, which is a 
> location usually associated with a Debian package installer, but the rest 
> of weewx is in /home/weewx, which is usually >associated with a setup.py 
> install. Is that what you intended?
>
> Yes, that's "normal", it is because a long time ago, when there were 
> no Debian package yet, I had installed it in /home/weewx. Then, there was 
> a 
> Debian package, and I decided to use that but still use lots of things 
> from 
> the /home/weewx directory. 
>
> However, it is worth checking, so I checked : I have a weewx.conf only 
> in /etc/weewx. There is none for instance in /home/weewx tree. (there are 
> still more weewx.conf files than I expected, but I think it is normal).
>
> $ locate weewx.conf
> /etc/weewx/apache/conf.d/weewx.conf
> /etc/weewx/logwatch/conf/logfiles/weewx.conf
> /etc/weewx/logwatch/conf/services/weewx.conf
> /etc/weewx/rsyslog.d/weewx.conf
> /etc/weewx/weewx.conf
> /etc/weewx/weewx.conf-3.5.0
> /etc/weewx/weewx.conf-4.1.1
> /etc/weewx/weewx.conf-4.2.0
> /etc/weewx/weewx.conf-4.3.0
> /etc/weewx/weewx.conf.20191208202810
> /etc/weewx/weewx.conf.2020163218
> /etc/weewx/weewx.conf.20210120225317
> /etc/weewx/weewx.conf.20210120225326
> /etc/weewx/weewx.conf.bak
> /etc/weewx/weewx.conf.dist
> /etc/weewx/weewx.conf.dpkg-dist
> /etc/weewx/weewx.conf.my.4.2.0
> /etc/weewx/weewx.conf~
> /home/axelle/anonymized-weewx.conf
> /home/axelle/anonymized-weewx.conf~
> /var/lib/dpkg/info/weewx.conffiles
> /var/lib/dpkg/info/weewx.config
>
> >2. You have both FTP *and* rsync enabled. Is that what you intended?
>
> Yes. My setup is slightly complicated but I am backuping the website 
> locally to another host, and using rsync for that. I am also uploading 
> the 
> website to an external host, and that host only has FTP. That's why I use 
> both. But each is going to a different location.
> However, I'll give it a try by disabling some services (but indeed I 
> don't think that's the issue).
>
> >3. What happens if you try and use wee_reports? Does that work?
>
> Oh nice idea!
> It is failing. But i

Re: [weewx-user] Re: ERROR weewx.cheetahgenerator: **** MemoryError

2021-01-23 Thread wes...@gmail.com
has anyone filed an issue on the github project for cheetah?

-- 
You received this message because you are subscribed 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/543f628b-9dc1-4c14-83ff-ac6dd2decbd7n%40googlegroups.com.


Re: [weewx-user] Re: alarm module - multiple alarms

2021-01-23 Thread Remy Lavabre
Hi,
Do you know if there is a possibility to modify the py file in order to 
have an alarm delay specific to each alarm (for example 3600 seconds for 
alarm1, 7200 seconds for alarm2 etc)? THANK YOU
Le lundi 5 octobre 2020 à 13:04:00 UTC+2, graha...@gmail.com a écrit :

> should be ‘None’ not ‘none'
>
> On 5 Oct 2020, at 9:44 pm, Ian Prescott  wrote:
>
> Hi Gary
> I have been following this conversation because I have been using previous 
> versions of alarm.py and then alarm_multi.py.
> Thanks for your efforts at enhancing a great program.
> So I have just finished doing this recent change and I have noticed 
> several new lines in syslog since making the changes.
> These occur every 5 minutes.
>
> Oct  5 20:20:19 weatherpi weewx[568] DEBUG user.alarm_multi: name 'none' 
> is not defined
> Oct  5 20:20:19 weatherpi weewx[568] DEBUG user.alarm_multi: name 'none' 
> is not defined
> Oct  5 20:20:19 weatherpi weewx[568] DEBUG user.alarm_multi: name 'none' 
> is not defined
>
> This is my current alarm stanza 
> [Alarm]
> time_wait = 3600
> smtp_host = 
> smtp_user = 
> mailto =
> from =
> include_full_record = False
> count = 3
> expression.0 = "outTemp is not none and outTemp > 95.0"
> subject.0 = "Alarm message from weewx - High outside temperature! > 
> 35deg"
> expression.1 = "inTemp is not none and inTemp > 104.0"
> subject.1 = "Alarm message from weewx - High inside temperature! > 40 
> deg"
> expression.2 = "rain is not none and rain > 00.0"
> subject.2 = "Alarm message from weewx - is it really raining"
>
> This piece (rain is not none) was added a while ago, it solved an issue 
> around (some) rain values that were null (I think) and was causing grief.
> I just added "is not none" to the temp alarms to be consistent. 
> Are these lines a concern? or can "is not none" be removed? 
>
> Thank Ian P
>
>
>
> On Fri, 2 Oct 2020 at 15:01, gjr80  wrote:
>
>> Mikael,
>>
>> I have made some changes to alarm_multi so that it can now lists only 
>> the fields in the triggered expression rather than the entire archive 
>> record (its a fairly basic check and will probably trip on fields whose 
>> name is a subset of another field, eg a field named 'temp' would match '
>> outTemp', 'inTemp', 'extraTemp1' etc as well as 'temp'). While I was at 
>> it I gave the entire file a bit of a refresh and saved it to my WeeWX 
>> utilities repo.
>> To download the reworked alarm_multi.py and set it to list only fields 
>> in the triggered expression:
>>
>> 1. move your existing alarm_multi.py aside
>> $ sudo mv /usr/share/weewx/user/alarm_multi.py 
>> /usr/share/weewx/user/alarm_multi_orig.py
>>
>> 2. download the reworked version of alarm_multi.py:
>> $ wget -P /usr/share/weewx/user 
>> https://raw.githubusercontent.com/gjr80/weewx_utilities/master/services/alarm_multi.py
>>
>> 3. edit weewx.conf and under the [Alarm] stanza add the config item 
>> include_full_record 
>> = False:
>>
>> [Alarm]
>> 
>> include_full_record = False
>>
>> 4. save weewx.conf and restart WeeWX
>>
>> You can go back to displaying the full record by setting 
>> include_full_record to True or deleting the entry in its entirety.
>>
>> Gary
>>
>> On Wednesday, 23 September 2020 at 18:37:32 UTC+10 pligg...@gmail.com 
>> wrote:
>>
>>> Ok thanks Gary for clarifying that! Not a big issue but we'll see what 
>>> you can do about it. 
>>>
>>> //Mikael
>>>
>>> onsdag 23 september 2020 kl. 04:20:58 UTC+2 skrev gjr80:
>>>
 Mikael,

 I believe the old version of alarm.py that had hard coded alarm 
 expressions did print just the offending field but the current version of 
 alarm.py and alarm_multi.py only print the entire record and cannot 
 print just the offending fields. To print just the field would require 
 parsing of the alarm expression to identify the fields involved and then 
 just pass those fields to the mail routine rather than the whole record. 
 Doable but will require a little more code. I will see what I can 
 incorporate in the revised version.

 Gary
 On Tuesday, 22 September 2020 at 05:45:19 UTC+10 pligg...@gmail.com 
 wrote:

> Great!
>
> One more question. When I used alarm.py I somehow managed to get only 
> the "faulty" record to show in the email, not every other reading. Don't 
> remember how I did this. Could you tell me what to change in the code?
>
> Alarm expression "extraTemp1 > 52 " evaluated True at 2020-09-21 
> 14:40:00 CEST (1600692000)
> Record:
> {'outTempBatteryStatus': 0.0, 'outHumidity': 71.0, 'extraHumid1': 
> 99.9, 'maxSolarRad': 428.4915916113489, 'extraTemp2': 68.0, 'interval': 
> 10, 
> 'ET': None, 'ptr': 25408.0, 'rainRate': 0.0, 'heatindex': 
> 60.16181818181818, 'radiation': None, 'delay': 23.818181818181817, 
> 'inTemp': 52.980001, 'inDewpoint': 43.832655655290985, 'status': 
> 0.0, 'barometer': 29.95817287439312, 

[weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread Invisible Man
Hello,

My outside temperature, my barometer, my dew point, my gust wind are 
completely crazy!

Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I had 
to install the WMR200 extension as it is no longer in the main weewx in 
4.3.0. So please consider something might be wrong with my config for the 
extension/simulator.

Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that 
also might be a source of issue.

My configuration is :

   - WMR200 station (using weewx-wmr200 extension)
   - My original WMR200 temperature sensor is KO and I have "replaced" it 
   with a DIY sensor that sends its data using MQTT. Thus the MQTT extension.
   - My wind battery and my UV battery are low (but I wonder if it's not 
   just a detection issue, because they are always low even when I change 
   batteries).
   - I attach my weewx.conf
   

*Temperature: *

The current outside temperature is 9°C. You see below that I receive a MQTT 
message saying it is 9.14. Unit is degrees celsius. This is okay.

Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 0, 
retain: 0, payload: b'9.14'
Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> incoming temperature/jardin: outTemp: 9.14
Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> outgoing temperature/jardin: dateTime: 
1611418222.9963524, outTemp: 9.14, usUnits: 16

I also have an 'accumulated temperature'. Don't know exactly what that is, 
and I'm surprised usUnits is 1. Strange.

Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
TopicManager data-> outgoing accumulated temperature/jardin: dateTime: 
1611418225.0, outTemp: 48.452, usUnits: 1

A bit later, I have this kind of messages:

- outTemp is 48.452. For some reason, this is Fahrenheit. Indeed 48.452F=9C.

Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
31.042868851248706, consBatteryVoltage: 12.564392224893147, dateTime: 
1611418225.0, heatingVoltage: 12.0, inHumidity: 27.78003341310109, inTemp: 
64.10998329344946, inTempBatteryStatus: 0, outHumidity: 78.28606553746118, 
outTemp: 48.452, outTempBatteryStatus: 0, pressure: 31.042868851248706, 
radiation: 46.14176895043754, rain: 0, rainBatteryStatus: 0, 
referenceVoltage: 12.0, rxCheckPercent: 36.11042934389155, supplyVoltage: 
12.0, txBatteryStatus: 0, usUnits: 1, UV: 0.6459847653061255, 
windBatteryStatus: 0, windDir: 349.7163932247671, windGust: 
0.34278689250776395, windGustDir: 349.7163932247671, windSpeed: 
0.28565574375646996

My report in my template displays $current.outTemp to "-0.9°C" !!! This not 
9C, nor 48F :(

*Barometer*

On the WMR console, barometer indicates approx 980 mbar. 
Why does this log say 31??? Other unit?

Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
31.042868851248706,

My report displays $current.barometer to 1053 mbar !!! This is not 980 !!

*Wind gust*

I have currently 3/5 km/h. But my report says 0 km/h. It could happen that 
at a given time it is zero, but still I am suspicious about the value.

I think there's a configuration issue somewhere in my files. This is crazy.


-- 
You received this message because you are subscribed 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/477cec36-536b-4d10-a095-ebc732e09548n%40googlegroups.com.
##
##
#WEEWX CONFIGURATION FILE#
##
# Copyright (c) 2009-2013 Tom Keffer  #
# $Id: weewx.conf 2394 2014-10-11 16:20:03Z tkeffer $
##

# This section is for general configuration information

# Set to 1 for extra debug info, otherwise comment it out or set to zero.
debug = 1

# Root directory of the weewx data file hierarchy for this station.
WEEWX_ROOT = /home/weewx/

# Whether to log successful operations
log_success = True

# Whether to log unsuccessful operations
log_failure = True

# How long to wait before timing out a socket (FTP, HTTP) connection:
socket_timeout = 20

# Do not modify this - it is used by setup.py when installing and updating.
version = 4.3.0

##

[Station]
# This section is for information about your station

 

Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread John Kline
I’m not sure why you keep mentioning simulator (as in extension/simulator).

Do you have the following line in your weewx.conf?

driver = simulator

If so, it should not be there.

> On Jan 23, 2021, at 8:49 AM, Invisible Man  wrote:
> 
> 
> Hello,
> 
> My outside temperature, my barometer, my dew point, my gust wind are 
> completely crazy!
> 
> Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I had to 
> install the WMR200 extension as it is no longer in the main weewx in 4.3.0. 
> So please consider something might be wrong with my config for the 
> extension/simulator.
> 
> Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that also 
> might be a source of issue.
> 
> My configuration is :
> WMR200 station (using weewx-wmr200 extension)
> My original WMR200 temperature sensor is KO and I have "replaced" it with a 
> DIY sensor that sends its data using MQTT. Thus the MQTT extension.
> My wind battery and my UV battery are low (but I wonder if it's not just a 
> detection issue, because they are always low even when I change batteries).
> I attach my weewx.conf
> 
> Temperature: 
> 
> The current outside temperature is 9°C. You see below that I receive a MQTT 
> message saying it is 9.14. Unit is degrees celsius. This is okay.
> 
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 0, 
> retain: 0, payload: b'9.14'
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> incoming temperature/jardin: outTemp: 9.14
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> outgoing temperature/jardin: dateTime: 
> 1611418222.9963524, outTemp: 9.14, usUnits: 16
> 
> I also have an 'accumulated temperature'. Don't know exactly what that is, 
> and I'm surprised usUnits is 1. Strange.
> 
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> outgoing accumulated temperature/jardin: dateTime: 
> 1611418225.0, outTemp: 48.452, usUnits: 1
> 
> A bit later, I have this kind of messages:
> 
> - outTemp is 48.452. For some reason, this is Fahrenheit. Indeed 48.452F=9C.
> 
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) data-> 
> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
> 31.042868851248706, consBatteryVoltage: 12.564392224893147, dateTime: 
> 1611418225.0, heatingVoltage: 12.0, inHumidity: 27.78003341310109, inTemp: 
> 64.10998329344946, inTempBatteryStatus: 0, outHumidity: 78.28606553746118, 
> outTemp: 48.452, outTempBatteryStatus: 0, pressure: 31.042868851248706, 
> radiation: 46.14176895043754, rain: 0, rainBatteryStatus: 0, 
> referenceVoltage: 12.0, rxCheckPercent: 36.11042934389155, supplyVoltage: 
> 12.0, txBatteryStatus: 0, usUnits: 1, UV: 0.6459847653061255, 
> windBatteryStatus: 0, windDir: 349.7163932247671, windGust: 
> 0.34278689250776395, windGustDir: 349.7163932247671, windSpeed: 
> 0.28565574375646996
> 
> My report in my template displays $current.outTemp to "-0.9°C" !!! This not 
> 9C, nor 48F :(
> 
> Barometer
> 
> On the WMR console, barometer indicates approx 980 mbar. 
> Why does this log say 31??? Other unit?
> 
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) data-> 
> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
> 31.042868851248706,
> 
> My report displays $current.barometer to 1053 mbar !!! This is not 980 !!
> 
> Wind gust
> 
> I have currently 3/5 km/h. But my report says 0 km/h. It could happen that at 
> a given time it is zero, but still I am suspicious about the value.
> 
> I think there's a configuration issue somewhere in my files. This is crazy.
> 
> 
> -- 
> You received this message because you are subscribed 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/477cec36-536b-4d10-a095-ebc732e09548n%40googlegroups.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/E3C73A94-B412-4E1B-89AB-5CE6EF3AC700%40johnkline.com.


Re: [weewx-user] yearwindvec calculation problem

2021-01-23 Thread jerry...@gmail.com
Solved.  After rebuilding daily, yearwindvec scale is back to normal.
Thanks, Tom.

On Friday, January 22, 2021 at 6:29:20 PM UTC-8 jerry...@gmail.com wrote:

> Tried running rebuild a second time.  Finished in 1 second and reported it 
> was done.
>
> └─[$] <> sudo ../bin/wee_database --rebuild-daily
> Password:
> Using configuration file /Users//weewx/weewx.conf
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> All daily summaries will be rebuilt.
> Proceed (y/n)? y
> Rebuilding daily summaries in database 'weewx.sdb' ...
> Daily summaries up to date in 'weewx.sdb'
>
> I'll let it run overnight again and see what happens.
>
> On Friday, January 22, 2021 at 5:56:48 PM UTC-8 jerry...@gmail.com wrote:
>
>> Would you recommend trying to run repair first?
>>
>> On Friday, January 22, 2021 at 5:54:51 PM UTC-8 tke...@gmail.com wrote:
>>
>>> Can you try it again?
>>>
>>> I have to confess, I've never tried this under MacOS. 
>>>
>>> On Fri, Jan 22, 2021 at 5:51 PM jerry...@gmail.com  
>>> wrote:
>>>
 mmm.  --drop-daily ran successfully, but --rebuild-daily ran for 10 min 
 or so, then hung on 2020-12-02
 ┌─[@weather] - [~/weewx/archive] - [Fri Jan 22, 16:11]
 └─[$] <> sudo ../bin/wee_database --drop-daily
 Using configuration file /Users//weewx/weewx.conf
 Using database binding 'wx_binding', which is bound to database 
 'archive_sqlite'
 Proceeding will delete all your daily summaries from database 
 'weewx.sdb'
 Are you sure you want to proceed (y/n)? y
 Dropping daily summary tables from 'weewx.sdb' ... 
 Daily summary tables dropped from database 'weewx.sdb' in 1.43 seconds
 ┌─[@weather] - [~/weewx/archive] - [Fri Jan 22, 16:11]
 └─[$] <> sudo ../bin/wee_database --rebuild-daily
 Using configuration file /Users//weewx/weewx.conf
 Using database binding 'wx_binding', which is bound to database 
 'archive_sqlite'
 All daily summaries will be rebuilt.
 Proceed (y/n)? y
 Rebuilding daily summaries in database 'weewx.sdb' ...
 Records processed: 883000; time: 2020-12-02 07:05:00 PST (1606921500)


 On Friday, January 22, 2021 at 4:21:48 PM UTC-8 tke...@gmail.com wrote:

> Thanks.
>
> On Fri, Jan 22, 2021 at 4:04 PM jerry...@gmail.com  
> wrote:
>
>> I upgraded from v4.2 and installed v4.3b(final beta) on Jan 2, then 
>> upgraded to the v4.3 release on Jan 4
>>
>> On Friday, January 22, 2021 at 3:34:09 PM UTC-8 tke...@gmail.com 
>> wrote:
>>
>>> Jerry, two other questions: 
>>>
>>> 1. What version of WeeWX did you use before moving to V4.3?
>>> 2. When did you do the upgrade?
>>>
>>> On Fri, Jan 22, 2021 at 3:24 PM Tom Keffer  wrote:
>>>
 I see the problem, but I'm not quite sure what caused it. I'll have 
 to do some experimentation.

 In the meantime, you can fix things by rebuilding the daily 
 summaries.

 *sudo wee_database --drop-daily*
 *sudo wee_database --rebuild-daily*



 On Fri, Jan 22, 2021 at 3:13 PM jerry...@gmail.com <
 jerry...@gmail.com> wrote:

> python 3.9.1 issues corrected.  No effect on yearwindvec.  Here's 
> sql dump
> └─[$] <> sqlite3 weewx.sdb
> SQLite version 3.32.3 2020-06-18 14:16:19
> Enter ".help" for usage hints.
> sqlite> select dateTime, 
> datetime(dateTime,'unixepoch','localtime'), xsum, ysum, dirsumtime 
> from 
> archive_day_wind where dateTime>1606780800;
> 1606809600|2020-12-01 
> 00:00:00|-130203.553519314|151249.611011778|288
> 1606896000|2020-12-02 
> 00:00:00|-52187.9947583369|334558.809337536|288
> 1606982400|2020-12-03 
> 00:00:00|-153080.843814849|234123.104596637|288
> 1607068800|2020-12-04 
> 00:00:00|-99420.8960079433|191113.904386128|288
> 1607155200|2020-12-05 
> 00:00:00|-190256.166535543|-63997.1159412606|288
> 1607241600|2020-12-06 00:00:00|-34666.8634217707 
> <(863)%20421-7707>|-2021.71578460231|288
> 1607328000|2020-12-07 
> 00:00:00|30124.3625862335|579428.027105184|288
> 1607414400|2020-12-08 
> 00:00:00|-190910.758642127|109709.290467476|288
> 1607500800|2020-12-09 
> 00:00:00|117876.621596901|360564.616051966|288
> 1607587200|2020-12-10 00:00:00|-110801.296843873|-95429.4246456933 
> <(424)%20645-6933>|288
> 1607673600|2020-12-11 00:00:00|-43729.9472371972 
> <(947)%20237-1972>|-309888.485094482|288
> 160776|2020-12-12 00:00:00|220205.009420536|41034.5716043916 
> <(571)%20604-3916>|288
> 1607846400|2020-12-13 
> 00:00:00|-244171.679762325|-169645.365425769|288
> 1607932800|2020-12-14 
> 00:00:00|-102395.07323691|169918.39

Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread Invisible Man
> I’m not sure why you keep mentioning simulator (as in 
extension/simulator).

Because the doc https://github.com/weewx/weewx-wmr200 says "Install WeeWX, 
selecting 'Simulator' driver. See directions at 
http://weewx.com/docs/usersguide.htm#installing";

>driver = simulator

No, I don't have "driver = simulator", but I have: 

   station_type = Simulator

[Simulator]
   driver = weewx.drivers.simulator

Is that normal ?

On Saturday, January 23, 2021 at 5:58:38 PM UTC+1 jo...@johnkline.com wrote:

> I’m not sure why you keep mentioning simulator (as in extension/simulator).
>
> Do you have the following line in your weewx.conf?
>
> driver = simulator
>
> If so, it should not be there.
>
> On Jan 23, 2021, at 8:49 AM, Invisible Man  wrote:
>
> 
>
> Hello,
>
> My outside temperature, my barometer, my dew point, my gust wind are 
> completely crazy!
>
> Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I had 
> to install the WMR200 extension as it is no longer in the main weewx in 
> 4.3.0. So please consider something might be wrong with my config for the 
> extension/simulator.
>
> Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that 
> also might be a source of issue.
>
> My configuration is :
>
>- WMR200 station (using weewx-wmr200 extension)
>- My original WMR200 temperature sensor is KO and I have "replaced" it 
>with a DIY sensor that sends its data using MQTT. Thus the MQTT extension.
>- My wind battery and my UV battery are low (but I wonder if it's not 
>just a detection issue, because they are always low even when I change 
>batteries).
>- I attach my weewx.conf
>
>
> *Temperature: *
>
> The current outside temperature is 9°C. You see below that I receive a 
> MQTT message saying it is 9.14. Unit is degrees celsius. This is okay.
>
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 0, 
> retain: 0, payload: b'9.14'
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> incoming temperature/jardin: outTemp: 9.14
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> outgoing temperature/jardin: dateTime: 
> 1611418222.9963524, outTemp: 9.14, usUnits: 16
>
> I also have an 'accumulated temperature'. Don't know exactly what that is, 
> and I'm surprised usUnits is 1. Strange.
>
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> outgoing accumulated temperature/jardin: dateTime: 
> 1611418225.0, outTemp: 48.452, usUnits: 1
>
> A bit later, I have this kind of messages:
>
> - outTemp is 48.452. For some reason, this is Fahrenheit. Indeed 
> 48.452F=9C.
>
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
> 31.042868851248706, consBatteryVoltage: 12.564392224893147, dateTime: 
> 1611418225.0, heatingVoltage: 12.0, inHumidity: 27.78003341310109, inTemp: 
> 64.10998329344946, inTempBatteryStatus: 0, outHumidity: 78.28606553746118, 
> outTemp: 48.452, outTempBatteryStatus: 0, pressure: 31.042868851248706, 
> radiation: 46.14176895043754, rain: 0, rainBatteryStatus: 0, 
> referenceVoltage: 12.0, rxCheckPercent: 36.11042934389155, supplyVoltage: 
> 12.0, txBatteryStatus: 0, usUnits: 1, UV: 0.6459847653061255, 
> windBatteryStatus: 0, windDir: 349.7163932247671, windGust: 
> 0.34278689250776395, windGustDir: 349.7163932247671, windSpeed: 
> 0.28565574375646996
>
> My report in my template displays $current.outTemp to "-0.9°C" !!! This 
> not 9C, nor 48F :(
>
> *Barometer*
>
> On the WMR console, barometer indicates approx 980 mbar. 
> Why does this log say 31??? Other unit?
>
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
> 31.042868851248706,
>
> My report displays $current.barometer to 1053 mbar !!! This is not 980 !!
>
> *Wind gust*
>
> I have currently 3/5 km/h. But my report says 0 km/h. It could happen that 
> at a given time it is zero, but still I am suspicious about the value.
>
> I think there's a configuration issue somewhere in my files. This is crazy.
>
>
> -- 
> You received this message because you are subscribed 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/477cec36-536b-4d10-a095-ebc732e09548n%40googlegroups.com
>  
> 
> .
> 
>
>

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

Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread Tom Keffer
Did you do step #4?

 sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt


On Sat, Jan 23, 2021 at 9:16 AM Invisible Man 
wrote:

> > I’m not sure why you keep mentioning simulator (as in
> extension/simulator).
>
> Because the doc https://github.com/weewx/weewx-wmr200 says "Install
> WeeWX, selecting 'Simulator' driver. See directions at
> http://weewx.com/docs/usersguide.htm#installing";
>
> >driver = simulator
>
> No, I don't have "driver = simulator", but I have:
>
>station_type = Simulator
>
> [Simulator]
>driver = weewx.drivers.simulator
>
> Is that normal ?
>
> On Saturday, January 23, 2021 at 5:58:38 PM UTC+1 jo...@johnkline.com
> wrote:
>
>> I’m not sure why you keep mentioning simulator (as in
>> extension/simulator).
>>
>> Do you have the following line in your weewx.conf?
>>
>> driver = simulator
>>
>> If so, it should not be there.
>>
>> On Jan 23, 2021, at 8:49 AM, Invisible Man  wrote:
>>
>> 
>>
>> Hello,
>>
>> My outside temperature, my barometer, my dew point, my gust wind are
>> completely crazy!
>>
>> Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I
>> had to install the WMR200 extension as it is no longer in the main weewx in
>> 4.3.0. So please consider something might be wrong with my config for the
>> extension/simulator.
>>
>> Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that
>> also might be a source of issue.
>>
>> My configuration is :
>>
>>- WMR200 station (using weewx-wmr200 extension)
>>- My original WMR200 temperature sensor is KO and I have "replaced"
>>it with a DIY sensor that sends its data using MQTT. Thus the MQTT
>>extension.
>>- My wind battery and my UV battery are low (but I wonder if it's not
>>just a detection issue, because they are always low even when I change
>>batteries).
>>- I attach my weewx.conf
>>
>>
>> *Temperature: *
>>
>> The current outside temperature is 9°C. You see below that I receive a
>> MQTT message saying it is 9.14. Unit is degrees celsius. This is okay.
>>
>> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service)
>> MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 0,
>> retain: 0, payload: b'9.14'
>> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service)
>> TopicManager data-> incoming temperature/jardin: outTemp: 9.14
>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service)
>> TopicManager data-> outgoing temperature/jardin: dateTime:
>> 1611418222.9963524, outTemp: 9.14, usUnits: 16
>>
>> I also have an 'accumulated temperature'. Don't know exactly what that
>> is, and I'm surprised usUnits is 1. Strange.
>>
>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service)
>> TopicManager data-> outgoing accumulated temperature/jardin: dateTime:
>> 1611418225.0, outTemp: 48.452, usUnits: 1
>>
>> A bit later, I have this kind of messages:
>>
>> - outTemp is 48.452. For some reason, this is Fahrenheit. Indeed
>> 48.452F=9C.
>>
>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service)
>> data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer:
>> 31.042868851248706, consBatteryVoltage: 12.564392224893147, dateTime:
>> 1611418225.0, heatingVoltage: 12.0, inHumidity: 27.78003341310109, inTemp:
>> 64.10998329344946, inTempBatteryStatus: 0, outHumidity: 78.28606553746118,
>> outTemp: 48.452, outTempBatteryStatus: 0, pressure: 31.042868851248706,
>> radiation: 46.14176895043754, rain: 0, rainBatteryStatus: 0,
>> referenceVoltage: 12.0, rxCheckPercent: 36.11042934389155, supplyVoltage:
>> 12.0, txBatteryStatus: 0, usUnits: 1, UV: 0.6459847653061255,
>> windBatteryStatus: 0, windDir: 349.7163932247671, windGust:
>> 0.34278689250776395, windGustDir: 349.7163932247671, windSpeed:
>> 0.28565574375646996
>>
>> My report in my template displays $current.outTemp to "-0.9°C" !!! This
>> not 9C, nor 48F :(
>>
>> *Barometer*
>>
>> On the WMR console, barometer indicates approx 980 mbar.
>> Why does this log say 31??? Other unit?
>>
>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service)
>> data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer:
>> 31.042868851248706,
>>
>> My report displays $current.barometer to 1053 mbar !!! This is not 980 !!
>>
>> *Wind gust*
>>
>> I have currently 3/5 km/h. But my report says 0 km/h. It could happen
>> that at a given time it is zero, but still I am suspicious about the value.
>>
>> I think there's a configuration issue somewhere in my files. This is
>> crazy.
>>
>>
>> --
>> You received this message because you are subscribed 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/477cec36-536b-4d10-a095-ebc732e09548n%40googlegroups.com
>> 

Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread Invisible Man
> sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt

I have to do it after an apt upgrade weewx ?

Anyway, I did do it again.
It changes station_type to WMR200 (not Simulator) again.
Is that normal ?


On Saturday, January 23, 2021 at 6:25:46 PM UTC+1 tke...@gmail.com wrote:

> Did you do step #4?
>
>  sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
>
>
> On Sat, Jan 23, 2021 at 9:16 AM Invisible Man  
> wrote:
>
>> > I’m not sure why you keep mentioning simulator (as in 
>> extension/simulator).
>>
>> Because the doc https://github.com/weewx/weewx-wmr200 says "Install 
>> WeeWX, selecting 'Simulator' driver. See directions at 
>> http://weewx.com/docs/usersguide.htm#installing";
>>
>> >driver = simulator
>>
>> No, I don't have "driver = simulator", but I have: 
>>
>>station_type = Simulator
>>
>> [Simulator]
>>driver = weewx.drivers.simulator
>>
>> Is that normal ?
>>
>> On Saturday, January 23, 2021 at 5:58:38 PM UTC+1 jo...@johnkline.com 
>> wrote:
>>
>>> I’m not sure why you keep mentioning simulator (as in 
>>> extension/simulator).
>>>
>>> Do you have the following line in your weewx.conf?
>>>
>>> driver = simulator
>>>
>>> If so, it should not be there.
>>>
>>> On Jan 23, 2021, at 8:49 AM, Invisible Man  wrote:
>>>
>>> 
>>>
>>> Hello,
>>>
>>> My outside temperature, my barometer, my dew point, my gust wind are 
>>> completely crazy!
>>>
>>> Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I 
>>> had to install the WMR200 extension as it is no longer in the main weewx in 
>>> 4.3.0. So please consider something might be wrong with my config for the 
>>> extension/simulator.
>>>
>>> Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that 
>>> also might be a source of issue.
>>>
>>> My configuration is :
>>>
>>>- WMR200 station (using weewx-wmr200 extension)
>>>- My original WMR200 temperature sensor is KO and I have "replaced" 
>>>it with a DIY sensor that sends its data using MQTT. Thus the MQTT 
>>>extension.
>>>- My wind battery and my UV battery are low (but I wonder if it's 
>>>not just a detection issue, because they are always low even when I 
>>> change 
>>>batteries).
>>>- I attach my weewx.conf
>>>
>>>
>>> *Temperature: *
>>>
>>> The current outside temperature is 9°C. You see below that I receive a 
>>> MQTT message saying it is 9.14. Unit is degrees celsius. This is okay.
>>>
>>> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 0, 
>>> retain: 0, payload: b'9.14'
>>> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> TopicManager data-> incoming temperature/jardin: outTemp: 9.14
>>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> TopicManager data-> outgoing temperature/jardin: dateTime: 
>>> 1611418222.9963524, outTemp: 9.14, usUnits: 16
>>>
>>> I also have an 'accumulated temperature'. Don't know exactly what that 
>>> is, and I'm surprised usUnits is 1. Strange.
>>>
>>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> TopicManager data-> outgoing accumulated temperature/jardin: dateTime: 
>>> 1611418225.0, outTemp: 48.452, usUnits: 1
>>>
>>> A bit later, I have this kind of messages:
>>>
>>> - outTemp is 48.452. For some reason, this is Fahrenheit. Indeed 
>>> 48.452F=9C.
>>>
>>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
>>> 31.042868851248706, consBatteryVoltage: 12.564392224893147, dateTime: 
>>> 1611418225.0, heatingVoltage: 12.0, inHumidity: 27.78003341310109, inTemp: 
>>> 64.10998329344946, inTempBatteryStatus: 0, outHumidity: 78.28606553746118, 
>>> outTemp: 48.452, outTempBatteryStatus: 0, pressure: 31.042868851248706, 
>>> radiation: 46.14176895043754, rain: 0, rainBatteryStatus: 0, 
>>> referenceVoltage: 12.0, rxCheckPercent: 36.11042934389155, supplyVoltage: 
>>> 12.0, txBatteryStatus: 0, usUnits: 1, UV: 0.6459847653061255, 
>>> windBatteryStatus: 0, windDir: 349.7163932247671, windGust: 
>>> 0.34278689250776395, windGustDir: 349.7163932247671, windSpeed: 
>>> 0.28565574375646996
>>>
>>> My report in my template displays $current.outTemp to "-0.9°C" !!! This 
>>> not 9C, nor 48F :(
>>>
>>> *Barometer*
>>>
>>> On the WMR console, barometer indicates approx 980 mbar. 
>>> Why does this log say 31??? Other unit?
>>>
>>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
>>> 31.042868851248706,
>>>
>>> My report displays $current.barometer to 1053 mbar !!! This is not 980 !!
>>>
>>> *Wind gust*
>>>
>>> I have currently 3/5 km/h. But my report says 0 km/h. It could happen 
>>> that at a given time it is zero, but still I am suspicious about the value.
>>>
>>> I think there's a configuration issue 

[weewx-user] Re: PM10 in ecowitt WH41 sensor?

2021-01-23 Thread gjr80
Not via the GW1000 API there isn’t. It does not show in any of the raw 
sensor data that is returned from the GW1000.

Gary

On Saturday, 23 January 2021 at 23:30:14 UTC+10 graha...@gmail.com wrote:

> fiddling with SDR trying to find some other sensor, i notice the following 
> from rtl_433:
>
> time  : 2021-01-24 00:02:08
> model : Fineoffset-WH0290  ID: 4
> 2.5um Fine Particulate Matter: 8 ug/m3 10um Coarse Particulate 
> Matter: 9 ug/m3
> Integrity : CRC
>
> which clearly says the ecowitt WH41 is transmitting PM10 value as well as 
> PM2.5
>
> i don't see the PM10 value appearing in WH41 ‘manual’, nor in gary’s 
> gw1000 driver. is there some way to extract this PM10 value other than via 
> SDR?
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e230ac95-954b-4eab-bfc5-c600f92e4823n%40googlegroups.com.


Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread John Kline
I meant to say station_type.

You do not want:
station_type = Simulator

You are seeing dummy data from the simulator.

> On Jan 23, 2021, at 9:43 AM, Invisible Man  wrote:
> 
> 
> > sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
> 
> I have to do it after an apt upgrade weewx ?
> 
> Anyway, I did do it again.
> It changes station_type to WMR200 (not Simulator) again.
> Is that normal ?
> 
> 
>> On Saturday, January 23, 2021 at 6:25:46 PM UTC+1 tke...@gmail.com wrote:
>> Did you do step #4?
>> 
>>  sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
>> 
>> 
>>> On Sat, Jan 23, 2021 at 9:16 AM Invisible Man  wrote:
>>> > I’m not sure why you keep mentioning simulator (as in 
>>> > extension/simulator).
>>> 
>>> Because the doc https://github.com/weewx/weewx-wmr200 says "Install WeeWX, 
>>> selecting 'Simulator' driver. See directions at 
>>> http://weewx.com/docs/usersguide.htm#installing";
>>> 
>>> >driver = simulator
>>> 
>>> No, I don't have "driver = simulator", but I have: 
>>> 
>>>station_type = Simulator
>>> 
>>> [Simulator]
>>>driver = weewx.drivers.simulator
>>> 
>>> Is that normal ?
>>> 
 On Saturday, January 23, 2021 at 5:58:38 PM UTC+1 jo...@johnkline.com 
 wrote:
 I’m not sure why you keep mentioning simulator (as in extension/simulator).
 
 Do you have the following line in your weewx.conf?
 
 driver = simulator
 
 If so, it should not be there.
 
>> On Jan 23, 2021, at 8:49 AM, Invisible Man  wrote:
>> 
> 
 
> Hello,
> 
> My outside temperature, my barometer, my dew point, my gust wind are 
> completely crazy!
> 
> Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I 
> had to install the WMR200 extension as it is no longer in the main weewx 
> in 4.3.0. So please consider something might be wrong with my config for 
> the extension/simulator.
> 
> Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that 
> also might be a source of issue.
> 
> My configuration is :
> WMR200 station (using weewx-wmr200 extension)
> My original WMR200 temperature sensor is KO and I have "replaced" it with 
> a DIY sensor that sends its data using MQTT. Thus the MQTT extension.
> My wind battery and my UV battery are low (but I wonder if it's not just 
> a detection issue, because they are always low even when I change 
> batteries).
> I attach my weewx.conf
> 
> Temperature: 
> 
> The current outside temperature is 9°C. You see below that I receive a 
> MQTT message saying it is 9.14. Unit is degrees celsius. This is okay.
> 
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 
> 0, retain: 0, payload: b'9.14'
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> incoming temperature/jardin: outTemp: 9.14
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> outgoing temperature/jardin: dateTime: 
> 1611418222.9963524, outTemp: 9.14, usUnits: 16
> 
> I also have an 'accumulated temperature'. Don't know exactly what that 
> is, and I'm surprised usUnits is 1. Strange.
> 
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> outgoing accumulated temperature/jardin: dateTime: 
> 1611418225.0, outTemp: 48.452, usUnits: 1
> 
> A bit later, I have this kind of messages:
> 
> - outTemp is 48.452. For some reason, this is Fahrenheit. Indeed 
> 48.452F=9C.
> 
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
> 31.042868851248706, consBatteryVoltage: 12.564392224893147, dateTime: 
> 1611418225.0, heatingVoltage: 12.0, inHumidity: 27.78003341310109, 
> inTemp: 64.10998329344946, inTempBatteryStatus: 0, outHumidity: 
> 78.28606553746118, outTemp: 48.452, outTempBatteryStatus: 0, pressure: 
> 31.042868851248706, radiation: 46.14176895043754, rain: 0, 
> rainBatteryStatus: 0, referenceVoltage: 12.0, rxCheckPercent: 
> 36.11042934389155, supplyVoltage: 12.0, txBatteryStatus: 0, usUnits: 1, 
> UV: 0.6459847653061255, windBatteryStatus: 0, windDir: 349.7163932247671, 
> windGust: 0.34278689250776395, windGustDir: 349.7163932247671, windSpeed: 
> 0.28565574375646996
> 
> My report in my template displays $current.outTemp to "-0.9°C" !!! This 
> not 9C, nor 48F :(
> 
> Barometer
> 
> On the WMR console, barometer indicates approx 980 mbar. 
> Why does this log say 31??? Other unit?
> 
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> data-> final packet is 2021-01-23 17:10:25 CET (16114

[weewx-user] What's the preferred way to add new sensors?

2021-01-23 Thread peterq...@gmail.com
I'm building a new thermostat and the controller (ESP32) has wifi. I'm 
going to capture the data and add it to weewx. The sensor that I'm using 
also has RH and my Accurite 5 in 1 doesn't send the RH values out over the 
USB, so I'm going to grab that too.

I already have a secondary thermometer that connects to my Raspberry Pi 
that runs Weewx. The secondary sensor sends UDP data to a port on the 
Raspi. I have a service running on the Raspi to listen on that port and 
post the data to a text file and I've modified the Weewx Accurite driver to 
get the temperature from the file. 

When it was one piece of data, it made sense to me to just do it simply. If 
it's three pieces of data, I'm wondering if there's a better way or a way 
to extend it.

My naïve thoughts are:
1) Have my new sensor connect via Wifi to the Raspi and post UDP data to a 
second port. Send a string with both the temp and RH, probably comma 
separated.
2) Modify my service to look the second port too and write it to a second 
file.
3) Modify the Accurite driver to read the file and use it when it does it's 
normal processing, adding RH and putting the new data in extraTemp2.

Is there a more elegant solution?

Yes, I could buy a Nest or other commercial solution, but what fun is that. 
I also don't want to have to rely on external internet services. Sending 
the data directly to some cloud service from the sensor and then having 
weewx pull the data from the cloud doesn't appeal to me.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/10ddc9fc-6ab7-460b-9a40-ac83b0251733n%40googlegroups.com.


Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread Invisible Man
> You are seeing dummy data from the simulator.

Hmmm... that's what I was starting to understand.
I really fail to understand why the doc says to do that...
A bit lost there, but as @tke said, I've run "sudo wee_config --reconfigure 
--driver=user.wmr200 --no-prompt" again and that removed the Simulator 
option.

So now, I have station_type = WMR200

and

[WMR200]
# This section is for the Oregon Scientific WMR200

# The station model, e.g., WMR200, WMR200A, Radio Shack W200
model = WMR200

# The driver to use:
driver = user.wmr200


and the data looks better :=) I'm waiting through a cycle to see if data is 
okay + reports too...


On Saturday, January 23, 2021 at 6:49:42 PM UTC+1 jo...@johnkline.com wrote:

> I meant to say station_type.
>
> You do not want:
> station_type = Simulator
>
> You are seeing dummy data from the simulator.
>
> On Jan 23, 2021, at 9:43 AM, Invisible Man  wrote:
>
> 
>
> > sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
>
> I have to do it after an apt upgrade weewx ?
>
> Anyway, I did do it again.
> It changes station_type to WMR200 (not Simulator) again.
> Is that normal ?
>
>
> On Saturday, January 23, 2021 at 6:25:46 PM UTC+1 tke...@gmail.com wrote:
>
>> Did you do step #4?
>>
>>  sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
>>
>>
>> On Sat, Jan 23, 2021 at 9:16 AM Invisible Man  
>> wrote:
>>
>>> > I’m not sure why you keep mentioning simulator (as in 
>>> extension/simulator).
>>>
>>> Because the doc https://github.com/weewx/weewx-wmr200 says "Install 
>>> WeeWX, selecting 'Simulator' driver. See directions at 
>>> http://weewx.com/docs/usersguide.htm#installing";
>>>
>>> >driver = simulator
>>>
>>> No, I don't have "driver = simulator", but I have: 
>>>
>>>station_type = Simulator
>>>
>>> [Simulator]
>>>driver = weewx.drivers.simulator
>>>
>>> Is that normal ?
>>>
>>> On Saturday, January 23, 2021 at 5:58:38 PM UTC+1 jo...@johnkline.com 
>>> wrote:
>>>
 I’m not sure why you keep mentioning simulator (as in 
 extension/simulator).

 Do you have the following line in your weewx.conf?

 driver = simulator

 If so, it should not be there.

 On Jan 23, 2021, at 8:49 AM, Invisible Man  
 wrote:

 

 Hello,

 My outside temperature, my barometer, my dew point, my gust wind are 
 completely crazy!

 Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I 
 had to install the WMR200 extension as it is no longer in the main weewx 
 in 
 4.3.0. So please consider something might be wrong with my config for the 
 extension/simulator.

 Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that 
 also might be a source of issue.

 My configuration is :

- WMR200 station (using weewx-wmr200 extension)
- My original WMR200 temperature sensor is KO and I have "replaced" 
it with a DIY sensor that sends its data using MQTT. Thus the MQTT 
extension.
- My wind battery and my UV battery are low (but I wonder if it's 
not just a detection issue, because they are always low even when I 
 change 
batteries).
- I attach my weewx.conf


 *Temperature: *

 The current outside temperature is 9°C. You see below that I receive a 
 MQTT message saying it is 9.14. Unit is degrees celsius. This is okay.

 Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
 MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 0, 
 retain: 0, payload: b'9.14'
 Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
 TopicManager data-> incoming temperature/jardin: outTemp: 9.14
 Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
 TopicManager data-> outgoing temperature/jardin: dateTime: 
 1611418222.9963524, outTemp: 9.14, usUnits: 16

 I also have an 'accumulated temperature'. Don't know exactly what that 
 is, and I'm surprised usUnits is 1. Strange.

 Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
 TopicManager data-> outgoing accumulated temperature/jardin: dateTime: 
 1611418225.0, outTemp: 48.452, usUnits: 1

 A bit later, I have this kind of messages:

 - outTemp is 48.452. For some reason, this is Fahrenheit. Indeed 
 48.452F=9C.

 Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
 data-> final packet is 2021-01-23 17:10:25 CET (1611418225): barometer: 
 31.042868851248706, consBatteryVoltage: 12.564392224893147, dateTime: 
 1611418225.0, heatingVoltage: 12.0, inHumidity: 27.78003341310109, inTemp: 
 64.10998329344946, inTempBatteryStatus: 0, outHumidity: 78.28606553746118, 
 outTemp: 48.452, outTempBatteryStatus: 0, pressure: 31.042868851248706, 
 radiation: 46.1417

Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread John Kline
> I really fail to understand why the doc says to do that...

When freshly installing weewx, it is not possible to choose a driver UNLESS it 
comes with weewx.  But you need to pick something, so the doc says to pick 
simulator.  Once you install the wmr200 driver, you want to switch to using the 
wmr200 driver and forget about the simulator forever (unless you install weewx 
from scratch again). 

> On Jan 23, 2021, at 10:17 AM, Invisible Man  wrote:
> 
> 
> > You are seeing dummy data from the simulator.
> 
> Hmmm... that's what I was starting to understand.
> I really fail to understand why the doc says to do that...
> A bit lost there, but as @tke said, I've run "sudo wee_config --reconfigure 
> --driver=user.wmr200 --no-prompt" again and that removed the Simulator option.
> 
> So now, I have station_type = WMR200
> 
> and
> 
> [WMR200]
> # This section is for the Oregon Scientific WMR200
> 
> # The station model, e.g., WMR200, WMR200A, Radio Shack W200
> model = WMR200
> 
> # The driver to use:
> driver = user.wmr200
> 
> 
> and the data looks better :=) I'm waiting through a cycle to see if data is 
> okay + reports too...
> 
> 
> On Saturday, January 23, 2021 at 6:49:42 PM UTC+1 jo...@johnkline.com wrote:
>> I meant to say station_type.
>> 
>> You do not want:
>> station_type = Simulator
>> 
>> You are seeing dummy data from the simulator.
>> 
>>> On Jan 23, 2021, at 9:43 AM, Invisible Man  wrote:
>>> 
>>> 
>> 
>>> > sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
>>> 
>>> I have to do it after an apt upgrade weewx ?
>>> 
>>> Anyway, I did do it again.
>>> It changes station_type to WMR200 (not Simulator) again.
>>> Is that normal ?
>>> 
>>> 
>>> On Saturday, January 23, 2021 at 6:25:46 PM UTC+1 tke...@gmail.com wrote:
 Did you do step #4?
 
  sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
 
 
> On Sat, Jan 23, 2021 at 9:16 AM Invisible Man  
> wrote:
> > I’m not sure why you keep mentioning simulator (as in 
> > extension/simulator).
> 
> Because the doc https://github.com/weewx/weewx-wmr200 says "Install 
> WeeWX, selecting 'Simulator' driver. See directions at 
> http://weewx.com/docs/usersguide.htm#installing";
> 
> >driver = simulator
> 
> No, I don't have "driver = simulator", but I have: 
> 
>station_type = Simulator
> 
> [Simulator]
>driver = weewx.drivers.simulator
> 
> Is that normal ?
> 
>> On Saturday, January 23, 2021 at 5:58:38 PM UTC+1 jo...@johnkline.com 
>> wrote:
>> I’m not sure why you keep mentioning simulator (as in 
>> extension/simulator).
>> 
>> Do you have the following line in your weewx.conf?
>> 
>> driver = simulator
>> 
>> If so, it should not be there.
>> 
 On Jan 23, 2021, at 8:49 AM, Invisible Man  
 wrote:
 
>>> 
>> 
>>> Hello,
>>> 
>>> My outside temperature, my barometer, my dew point, my gust wind are 
>>> completely crazy!
>>> 
>>> Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I 
>>> had to install the WMR200 extension as it is no longer in the main 
>>> weewx in 4.3.0. So please consider something might be wrong with my 
>>> config for the extension/simulator.
>>> 
>>> Also, I used to use Python 2.7 and have shifted to Python 3.x. So, that 
>>> also might be a source of issue.
>>> 
>>> My configuration is :
>>> WMR200 station (using weewx-wmr200 extension)
>>> My original WMR200 temperature sensor is KO and I have "replaced" it 
>>> with a DIY sensor that sends its data using MQTT. Thus the MQTT 
>>> extension.
>>> My wind battery and my UV battery are low (but I wonder if it's not 
>>> just a detection issue, because they are always low even when I change 
>>> batteries).
>>> I attach my weewx.conf
>>> 
>>> Temperature: 
>>> 
>>> The current outside temperature is 9°C. You see below that I receive a 
>>> MQTT message saying it is 9.14. Unit is degrees celsius. This is okay.
>>> 
>>> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 
>>> 0, retain: 0, payload: b'9.14'
>>> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> TopicManager data-> incoming temperature/jardin: outTemp: 9.14
>>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> TopicManager data-> outgoing temperature/jardin: dateTime: 
>>> 1611418222.9963524, outTemp: 9.14, usUnits: 16
>>> 
>>> I also have an 'accumulated temperature'. Don't know exactly what that 
>>> is, and I'm surprised usUnits is 1. Strange.
>>> 
>>> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
>>> TopicManager data-> outgoing ac

[weewx-user] Re: Raspberry Pi 4 + WMR89 = CP210X driver problem

2021-01-23 Thread Dani Macías Perea
Thanks for the answer Rob. That is exactly what I was planning to do, I 
already have in my shopping cart an SDR doongle + a GME280 sensor. I had an 
WMR88 station that showed reception problems after some years (RF antenna 
reception in the console was loosing sensitivity) and using an external SDR 
doongle will avoid this problem.
If I may ask, what SDR are you using? I have picked this one Nooelec NESDR 
SMArt v4 Bundle 
,
 
but I have read that some people have drivers issues (probably old 
versions). What model have you used?

Thanks in advance,

Daniel


El sábado, 23 de enero de 2021 a las 12:54:02 UTC+1, 
rob.s...@googlemail.com escribió:

> I had similar problems. In the end I opted for to use sdr interface and 
> pick up the signal dorect from the sensors. Added a BME280 to the RPi for 
> pressure and greenhouse temperature. Very pleased with the result.
>
> On Saturday, 23 January 2021 at 10:38:47 UTC dani.mac...@gmail.com wrote:
>
>> Hello,
>>
>> I have a Raspberry Pi 4 model B 8GB running 5.4.79-v7l+. I have bought it 
>> to replace my previous Raspberry Pi 3. The Pi 3 was connected via USB with 
>> an Oregon Scientific Weather Station (WMR89) and used CP210X driver to 
>> communicate with it. As the pair Vendor/Product ID wasn't registered in the 
>> driver CP210x.c, I added it using
>>
>> echo 0fde ca0a > /sys/bus/usb-serial/drivers/cp210x/new_id
>> in boot (rc.local). With the Raspberry Pi 3 the weather station was 
>> always automatically recognised, drivers loaded and accesible though 
>> /dev/ttyUSB and weewx run without problems.
>>
>> However, I am unable to get the same results with the Raspberry Pi 4. I 
>> have to unplug and plug manually every time the device to get it loaded. I 
>> have even built a new cp210x module including oregon's pair vendor/product 
>> ID to see if it helps but I am still stuck in the same point: I need to 
>> plug and unplug the USB cable from the weather station to make it work. 
>> Replugging the type A connector in the Raspberry Pi will make no 
>> difference. I have to replug the mini USB in the weather station to make it 
>> work (what seems really strange). 
>>
>> Does anybody has an idea on how to solve this problem?
>>
>> Thanks!
>>
>> Daniel  
>>
>

-- 
You received this message because you are subscribed 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/625b62c6-e641-499e-bfe5-ad6a51a52a82n%40googlegroups.com.


[weewx-user] Re: What's the preferred way to add new sensors?

2021-01-23 Thread vince
My suggestions:


   - Never alter a released driver.   If you do so, your changes will be 
   overwritten every time you upgrade weewx.
   - Do all your custom things in extensions.  They go into the bin/user 
   directory and are upgrade safe.
   - Package your custom extension or skin in a format installable by 
   wee_extension.  Makes it far easier to manage.


Lastly, weewx supports multiple databases which is a very powerful feature:


   - Have your custom extension(s) write to additional database(s) and 
   specify which db to get the data from in your skins.   How to configure 
   weewx to do this is documented in the Customization Guide 
    but 
   there are lots of examples for how to do this. If you want to see one 
   full-up example that is installable from via wee_extension you might want 
   to look at my mem extension (github link) 
   


On Saturday, January 23, 2021 at 10:11:36 AM UTC-8 peterq...@gmail.com 
wrote:

> I'm building a new thermostat and the controller (ESP32) has wifi. I'm 
> going to capture the data and add it to weewx. The sensor that I'm using 
> also has RH and my Accurite 5 in 1 doesn't send the RH values out over the 
> USB, so I'm going to grab that too.
>
> I already have a secondary thermometer that connects to my Raspberry Pi 
> that runs Weewx. The secondary sensor sends UDP data to a port on the 
> Raspi. I have a service running on the Raspi to listen on that port and 
> post the data to a text file and I've modified the Weewx Accurite driver to 
> get the temperature from the file. 
>
> When it was one piece of data, it made sense to me to just do it simply. 
> If it's three pieces of data, I'm wondering if there's a better way or a 
> way to extend it.
>
> My naïve thoughts are:
> 1) Have my new sensor connect via Wifi to the Raspi and post UDP data to a 
> second port. Send a string with both the temp and RH, probably comma 
> separated.
> 2) Modify my service to look the second port too and write it to a second 
> file.
> 3) Modify the Accurite driver to read the file and use it when it does 
> it's normal processing, adding RH and putting the new data in extraTemp2.
>
> Is there a more elegant solution?
>
> Yes, I could buy a Nest or other commercial solution, but what fun is 
> that. I also don't want to have to rely on external internet services. 
> Sending the data directly to some cloud service from the sensor and then 
> having weewx pull the data from the cloud doesn't appeal to me.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0e047e42-d738-4da4-afff-af3fe0d607bbn%40googlegroups.com.


Re: [weewx-user] Bad temperature/barometer/dew point

2021-01-23 Thread Invisible Man
ok :)
thanks !

On Saturday, January 23, 2021 at 7:23:40 PM UTC+1 jo...@johnkline.com wrote:

> > I really fail to understand why the doc says to do that...
>
> When freshly installing weewx, it is not possible to choose a driver 
> UNLESS it comes with weewx.  But you need to pick something, so the doc 
> says to pick simulator.  Once you install the wmr200 driver, you want to 
> switch to using the wmr200 driver and forget about the simulator forever 
> (unless you install weewx from scratch again). 
>
> On Jan 23, 2021, at 10:17 AM, Invisible Man  wrote:
>
> 
>
> > You are seeing dummy data from the simulator.
>
> Hmmm... that's what I was starting to understand.
> I really fail to understand why the doc says to do that...
> A bit lost there, but as @tke said, I've run "sudo wee_config 
> --reconfigure --driver=user.wmr200 --no-prompt" again and that removed the 
> Simulator option.
>
> So now, I have station_type = WMR200
>
> and
>
> [WMR200]
> # This section is for the Oregon Scientific WMR200
> 
> # The station model, e.g., WMR200, WMR200A, Radio Shack W200
> model = WMR200
> 
> # The driver to use:
> driver = user.wmr200
>
>
> and the data looks better :=) I'm waiting through a cycle to see if data 
> is okay + reports too...
>
>
> On Saturday, January 23, 2021 at 6:49:42 PM UTC+1 jo...@johnkline.com 
> wrote:
>
>> I meant to say station_type.
>>
>> You do not want:
>> station_type = Simulator
>>
>> You are seeing dummy data from the simulator.
>>
>> On Jan 23, 2021, at 9:43 AM, Invisible Man  wrote:
>>
>> 
>>
>> > sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
>>
>> I have to do it after an apt upgrade weewx ?
>>
>> Anyway, I did do it again.
>> It changes station_type to WMR200 (not Simulator) again.
>> Is that normal ?
>>
>>
>> On Saturday, January 23, 2021 at 6:25:46 PM UTC+1 tke...@gmail.com wrote:
>>
>>> Did you do step #4?
>>>
>>>  sudo wee_config --reconfigure --driver=user.wmr200 --no-prompt
>>>
>>>
>>> On Sat, Jan 23, 2021 at 9:16 AM Invisible Man  
>>> wrote:
>>>
 > I’m not sure why you keep mentioning simulator (as in 
 extension/simulator).

 Because the doc https://github.com/weewx/weewx-wmr200 says "Install 
 WeeWX, selecting 'Simulator' driver. See directions at 
 http://weewx.com/docs/usersguide.htm#installing";

 >driver = simulator

 No, I don't have "driver = simulator", but I have: 

station_type = Simulator

 [Simulator]
driver = weewx.drivers.simulator

 Is that normal ?

 On Saturday, January 23, 2021 at 5:58:38 PM UTC+1 jo...@johnkline.com 
 wrote:

> I’m not sure why you keep mentioning simulator (as in 
> extension/simulator).
>
> Do you have the following line in your weewx.conf?
>
> driver = simulator
>
> If so, it should not be there.
>
> On Jan 23, 2021, at 8:49 AM, Invisible Man  
> wrote:
>
> 
>
> Hello,
>
> My outside temperature, my barometer, my dew point, my gust wind are 
> completely crazy!
>
> Important: this happened after an upgrade from 4.2.0 to 4.3.0, where I 
> had to install the WMR200 extension as it is no longer in the main weewx 
> in 
> 4.3.0. So please consider something might be wrong with my config for the 
> extension/simulator.
>
> Also, I used to use Python 2.7 and have shifted to Python 3.x. So, 
> that also might be a source of issue.
>
> My configuration is :
>
>- WMR200 station (using weewx-wmr200 extension)
>- My original WMR200 temperature sensor is KO and I have 
>"replaced" it with a DIY sensor that sends its data using MQTT. Thus 
> the 
>MQTT extension.
>- My wind battery and my UV battery are low (but I wonder if it's 
>not just a detection issue, because they are always low even when I 
> change 
>batteries).
>- I attach my weewx.conf
>
>
> *Temperature: *
>
> The current outside temperature is 9°C. You see below that I receive a 
> MQTT message saying it is 9.14. Unit is degrees celsius. This is okay.
>
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> MessageCallbackProvider data-> incoming topic: temperature/jardin, QOS: 
> 0, 
> retain: 0, payload: b'9.14'
> Jan 23 17:10:22 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> incoming temperature/jardin: outTemp: 9.14
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data-> outgoing temperature/jardin: dateTime: 
> 1611418222.9963524, outTemp: 9.14, usUnits: 16
>
> I also have an 'accumulated temperature'. Don't know exactly what that 
> is, and I'm surprised usUnits is 1. Strange.
>
> Jan 23 17:10:24 vegan weewx[18515] DEBUG user.MQTTSubscribe: (Service) 
> TopicManager data

[weewx-user] New Units and Unit Groups for MQTT

2021-01-23 Thread Karen K
I installed MQTTSubscribe service. In this case it provides data about 
water level (unit cm) and water flow (unit cubic meter per second) of the 
near river.

As those units and unit group are not included in the standard weewx I have 
to assign them elsewhere.

Because I use the MQTTSubscribe service, there is no need to write an 
extension. On the other hand, no extension file means no place to put the 
assignment of the additional units and unit groups.

Could I declare those units and unit groups somewhere in weewx.conf?

Is there any other possibility?

-- 
You received this message because you are subscribed 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/6bb4393f-6685-4088-ae0a-90d2f79619b8n%40googlegroups.com.


Re: [weewx-user] New Units and Unit Groups for MQTT

2021-01-23 Thread weather list
Karen,

When you have a moment I would be interested in the devices you are using to 
measure water level and flow.

> On 23 Jan, 2021, at 16:18, Karen K  wrote:
> 
> I installed MQTTSubscribe service. In this case it provides data about water 
> level (unit cm) and water flow (unit cubic meter per second) of the near 
> river.
> 
> As those units and unit group are not included in the standard weewx I have 
> to assign them elsewhere.
> 
> Because I use the MQTTSubscribe service, there is no need to write an 
> extension. On the other hand, no extension file means no place to put the 
> assignment of the additional units and unit groups.
> 
> Could I declare those units and unit groups somewhere in weewx.conf?
> 
> Is there any other possibility?
> 
> -- 
> You received this message because you are subscribed 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/6bb4393f-6685-4088-ae0a-90d2f79619b8n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8FA86ECF-33D8-4F8A-80DE-6F79C606F51C%40gmail.com.


[weewx-user] Re: New Units and Unit Groups for MQTT

2021-01-23 Thread bell...@gmail.com
I'll be interested in hearing if there is a better way, but here is what I 
did to add a new observation.
1. Wrote this service.

import weewx

import weewx.units
weewx.units.obs_group_dict['honeywell01'] = 'group_temperature'
weewx.units.obs_group_dict['honeywell02'] = 'group_temperature'
weewx.units.obs_group_dict['honeywell03'] = 'group_temperature'

class Noop(weewx.engine.StdService):
pass

2. Updated weewx.conf
prep_services = weewx.engine.StdTimeSynch , user.bellrichm.Noop

rich

On Saturday, 23 January 2021 at 16:18:28 UTC-5 kk44...@gmail.com wrote:

> I installed MQTTSubscribe service. In this case it provides data about 
> water level (unit cm) and water flow (unit cubic meter per second) of the 
> near river.
>
> As those units and unit group are not included in the standard weewx I 
> have to assign them elsewhere.
>
> Because I use the MQTTSubscribe service, there is no need to write an 
> extension. On the other hand, no extension file means no place to put the 
> assignment of the additional units and unit groups.
>
> Could I declare those units and unit groups somewhere in weewx.conf?
>
> Is there any other possibility?
>

-- 
You received this message because you are subscribed 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/59ab51e6-a608-4e5d-8327-cbf658d8f05bn%40googlegroups.com.


Re: [weewx-user] NOAA Reports showing back to 1969

2021-01-23 Thread weather list
The first record in weewx.sdb had a value of 300 in the dateTime field; all the 
other fields look correct. I removed that, and dropped/rebuilt the dailies. 
Problem persists.

> On 22 Jan, 2021, at 11:51, Tom Keffer  wrote:
> 
> This is probably caused by a record in your database with a very old 
> timestamp. 
> 
> Take a look at this thread 
>  and see 
> if it answers your question.
> 
> On Fri, Jan 22, 2021 at 8:40 AM weather list  > wrote:
> I’m pretty sure I have missed a basic setting about when my station was 
> installed or similar. My NOAA page 
>  is displaying 
> years back to 1969, where of course there is no data. This is a 
> site-in-progress.
> 
> Is there a known fix for this?
> 
> Station hardware: WeatherFlow
> Server uptime: 18 days, 17 hours, 43 minutes
> WeeWX uptime: 1 day, 12 hours, 46 minutes
> WeeWX version: 4.1.1
> Belchertown Skin Version: 1.2
> Debian Raspian Desktop running in a VM on Mac High Sierra
> 
> 
> -- 
> You received this message because you are subscribed 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/AE58767F-D0C1-463F-B325-D2BD8317DF5C%40gmail.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAPq0zEBNKGYQx-pSv-7%2BOBYQ_QBjMaN3htRj-2u5i_0OrUopRQ%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/10775DA8-F53A-4D52-B086-C1E6C1216E7B%40gmail.com.


Re: [weewx-user] NOAA Reports showing back to 1969

2021-01-23 Thread Tom Keffer
If all the other records have a timestamp (field 'dateTime') that truly
looks correct (check!), then the problem may be as simple as waiting for
new files to be regenerated. Or, try deleting all generated files. They
will be automatically regenerated at the next reporting cycle

If you used the setup.py method, this would be

*rm -r /home/weewx/public_html*


If you used a package installer,

*sudo rm -r /var/www/html/weewx*


If the problem still persists, then you still have some old data.

-tk

On Sat, Jan 23, 2021 at 1:54 PM weather list 
wrote:

> The first record in weewx.sdb had a value of 300 in the dateTime field;
> all the other fields look correct. I removed that, and dropped/rebuilt the
> dailies. Problem persists.
>
> On 22 Jan, 2021, at 11:51, Tom Keffer  wrote:
>
> This is probably caused by a record in your database with a very old
> timestamp.
>
> Take a look at this thread
>  and
> see if it answers your question.
>
> On Fri, Jan 22, 2021 at 8:40 AM weather list 
> wrote:
>
>> I’m pretty sure I have missed a basic setting about when my station was
>> installed or similar. My NOAA page
>>  is
>> displaying years back to 1969, where of course there is no data. This is a
>> site-in-progress.
>>
>> Is there a known fix for this?
>>
>>
>>- Station hardware: WeatherFlow
>>- Server uptime: 18 days, 17 hours, 43 minutes
>>- WeeWX uptime: 1 day, 12 hours, 46 minutes
>>- WeeWX version: 4.1.1
>>- Belchertown Skin Version: 1.2
>>- Debian Raspian Desktop running in a VM on Mac High Sierra
>>
>>
>>
>> --
>> You received this message because you are subscribed 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/AE58767F-D0C1-463F-B325-D2BD8317DF5C%40gmail.com
>> 
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/CAPq0zEBNKGYQx-pSv-7%2BOBYQ_QBjMaN3htRj-2u5i_0OrUopRQ%40mail.gmail.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/10775DA8-F53A-4D52-B086-C1E6C1216E7B%40gmail.com
> 
> .
>

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


Re: [weewx-user] NOAA Reports showing back to 1969

2021-01-23 Thread weather list
On 22 Jan, 2021, at 12:56, vince  wrote:
> 
> Any time you see 1969 it means your VM came up with a time of zero seconds 
> (or close) since the unix epoch of 1/1/1970 midnight UTC.   You're seeing 
> 1969 because you are a few hours behind UTC in your timezone. I've never 
> seen this in bringing up many os in VM in VirtualBox/Vagrant on my MacBook 
> Air, but if you want me to try to recreate it, I'd need to know how exactly 
> you're bringing up the VM on the Mac.   Did you perhaps do something custom 
> in your virtualization setup ?

Not sure I follow all your points. This is Raspian desktop, Buster, is a stock, 
follow-the-prompts Parallels VM. WeeWx install using setup.py. Parallels starts 
on boot up, and I launch the VM from the Parallels window. The VM is displaying 
the correct time for EST.

> 
> 
> -- 
> You received this message because you are subscribed 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/28ddcefb-3682-4b9b-b11c-393e56f46f80n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/EFAB7A7A-DD7B-4258-A962-A4176F92151A%40gmail.com.


Re: [weewx-user] NOAA Reports showing back to 1969

2021-01-23 Thread vince
I think if you look at all your VM logs you'll find firstboot started at 
1969 or 1970 and then shortly thereafter it got time from either the host 
os or from an internet ntp site.  There's really no other explanation.

On Saturday, January 23, 2021 at 5:32:01 PM UTC-8 weatherl...@gmail.com 
wrote:

> On 22 Jan, 2021, at 12:56, vince  wrote:
>
>
> Any time you see 1969 it means your VM came up with a time of zero seconds 
> (or close) since the unix epoch of 1/1/1970 midnight UTC.   You're seeing 
> 1969 because you are a few hours behind UTC in your timezone. I've 
> never seen this in bringing up many os in VM in VirtualBox/Vagrant on my 
> MacBook Air, but if you want me to try to recreate it, I'd need to know how 
> exactly you're bringing up the VM on the Mac.   Did you perhaps do 
> something custom in your virtualization setup ?
>
>
> Not sure I follow all your points. This is Raspian desktop, Buster, is a 
> stock, follow-the-prompts Parallels VM. WeeWx install using setup.py. 
> Parallels starts on boot up, and I launch the VM from the Parallels window. 
> The VM is displaying the correct time for EST.
>
>
>
> -- 
> You received this message because you are subscribed 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/28ddcefb-3682-4b9b-b11c-393e56f46f80n%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/48398c21-bbdd-4f5e-b6aa-ba7956a44583n%40googlegroups.com.