date:20200523

How about a log from startup for about 30 minutes, we should be able to see if 
those duplicate packets are gone.

Gary

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

[weewx-user] Re: GUI date/time and current conditions frozen

Ok, the multiple duplicate timestamped packets are still there as are the POST 
and GET. Your system stuck at 8pm but you log extract went to 7:59pm, would be 
useful seeing 7:55 to say 8:15.

Gary

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

[weewx-user] Re: GUI date/time and current conditions frozen

I'm confident that the date/time will jump. I'm going to leave it run for 
the night.
I went through Matthew's wiki/how to/issues multiple times, and this is the 
best what I was able to do. I wasn't able to make interceptor listen to my 
network traffic and sniff out the communication between my PWS and WU.
If nothing helps, I'm going to clean up my database, export it, set up 
another virtual machine and install weewx.

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

[weewx-user] Re: GUI date/time and current conditions frozen

Well I am stumped.

The repeat packets seem to be in a reasonably regular routine, a few HTTP GETs
followed by a HTTP POST. I can accept that since you are fooling your station
into thinking the interceptor driver is WU your weather station may not be
seeing the exact response it expects and that causes it to resend the data or
try HTTP POST.

Looking at that last log extract I can see the 8pm archive record being saved,
so that accounts for 8pm appearing on your page. The interceptor started
deeming some of those duplicate packets as out of order and discarding them
(interceptor accepts packets if the timestamp is greater than or equal to the
last packets timestamp, anything else is dropped). I can’t see why it suddenly
started dropping packets. Since no packets are getting through (after 8pm) no
archive records are generated and hence no report cycle and the generated
Seasons page doesn’t change. I expect that later some packets will be accepted
and things will seem to work for a while. Noteworthy that this is a different
symptom to yesterday where the page date-time was jumping ahead.

Would be good to get Matthew’s view (interceptor author) but I know he is busy
with other things.

Only other suggestion I have is to maybe reconfigure your network to have your
weather station update WU and have WeeWX use the interceptor driver to sniff
the packets being sent to WU. Haven’t done that myself so I am not sure how
feasible it is.

Gary

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

Re: [weewx-user] V4 with python2 OWFS errors

2020-05-23 Thread Glenn McKechnie

Looks like another encoding issue.
You could try changing line 274 in the same fashion. No guarantees, as
I can't test it.

change...

sv = ow.get(path)

to include the encode fix...

sv = ow.get(path.encode())

I've raised it as an issue on github, hopefully mathew will be along
and able to apply his expertise to it.

https://github.com/matthewwall/weewx-owfs/issues/3

On 23/05/2020, Gazza  wrote:
>
> Tried that change and it crashed with a different set of errors.
>
>
> Gaz
>
>
>
> --
> You received this message because you are subscribed to the Google 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/ec0c7d16-8d7b-4c0b-8285-982a91157a4b%40googlegroups.com.
>


-- 


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
You received this message because you are subscribed to the Google 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/CAAraAzhBLR2Dhjz687LRPWMXuA8RP4KKafb57yuGWo1zByz%3D9Q%40mail.gmail.com.

[weewx-user] Re: No rain data for Acurite 5n1 - not getting parsed

2020-05-23 Thread 'Rob Series' via weewx-user

I suspect the parsing problem is caused by update to RTL_433 in August 
2019. See my post of 20 May below.
Rob Series

On Thursday, 21 May 2020 16:08:46 UTC+1, Andrew Mackey wrote:
>
> Gary,
>
> thank you for your post.  It has been helpful.  I have made some progress 
> now.
>
> First I think I might be confused about how to set up my config file as to 
> whether I am using the SDR option or the Acurite Option when configuring my 
> station.  I have come to the conclusion that choosing SDR is correct (I am 
> using an SDR to read the data from my weather station as opposed to having 
> the station directly connected to my Pi).
>
> Using you suggestion and configuring for the Acurite option I was able to 
> get the parser to show the total rain (rain_in) when I ran the sdr.py 
> code.  However, when I ran the weewx in direct mode, it said it could not 
> find the device on USB.  So I went back to choosing the SDR option.  I then 
> went to the SDR class and found where the sensor_map section was and added 
> a line for my rain_in fully qualified name.  Then when I re-ran the sdr.py 
> code I was still getting the rain_in/rain_total values showing in my parsed 
> data and when I reun weewx in direct mode it is working again, although no 
> rain data in the loops or in the records.  So that is some progress at 
> least.
>
> Also, I am still not getting any rain data when I look at my generated web 
> page.
>
>  
>
> On Wednesday, May 20, 2020 at 11:55:38 PM UTC-4, gjr80 wrote:
>>
>> Hi,
>>
>> Not a sdr driver or Acurite user but looking at the sdr driver as far as 
>> I can tell the sdr driver expects Acurite5n1PacketV2 rain data to be in 
>> field rain_mm whereas you appear to have rain_in. You could try adding 
>> the following two highlighted lines to /usr/share/weewx/user/sdr.py: 
>>
>> if 'wind_dir_deg' in obj:
>> pkt['wind_dir'] = Packet.get_float(obj, 'wind_dir_deg')
>> if 'rain_mm' in obj:
>> pkt['rain_total'] = Packet.get_float(obj, 'rain_mm') / 25.4
>> if 'rain_in' in obj:
>> pkt['rain_total'] = Packet.get_float(obj, 'rain_in')
>> if 'temperature_F' in obj:
>> pkt['temperature'] = Packet.get_float(obj, 'temperature_F')
>>
>> Save sdr.py then try running sdr.py directly again.
>>
>> Oh, and of course, make sure you keep a back of sdr.py before making any 
>> changes.
>>
>> Gary
>>
>> On Thursday, 21 May 2020 12:54:38 UTC+10, Andrew Mackey wrote:
>>>
>>> After installing the rtl software and the weewx software on my Pi 4 and 
>>> getting everything configured I am getting things to work as expected.  
>>>  Just no rain data.   I was expecting to have this problem because the 
>>> output from running the command sudo PYTHONPATH=/usr/share/weewx python 
>>> /usr/share/weewx/user/sdr.py --cmd="rtl_433 -M utc -F json" is missing the 
>>> rain data in the parsed section.  Notice in the output below that there is 
>>> a value in the 'rain_in' for the out section, but that rain data is not in 
>>> the parsed section.
>>>
>>>
>>> out:[u'{"time" : "2020-05-21 02:27:42", "model" : "Acurite-5n1", 
>>> "subtype" : 49, "id" : 1066, "channel" : "B", "sequence_num" : 0, 
>>> "battery_ok" : 1, "wind_avg_km_h" : 14.245, "wind_dir_deg" : 112.500, 
>>> "rain_in" : 28.500, "mic" : "CHECKSUM"}\n', u'{"time" : "2020-05-21 
>>> 02:27:42", "model" : "Acurite-5n1", "subtype" : 49, "id" : 1066, "channel" 
>>> : "B", "sequence_num" : 1, "battery_ok" : 1, "wind_avg_km_h" : 14.245, 
>>> "wind_dir_deg" : 112.500, "rain_in" : 28.500, "mic" : "CHECKSUM"}\n', 
>>> u'{"time" : "2020-05-21 02:27:42", "model" : "Acurite-5n1", "subtype" : 49, 
>>> "id" : 1066, "channel" : "B", "sequence_num" : 2, "battery_ok" : 1, 
>>> "wind_avg_km_h" : 14.245, "wind_dir_deg" : 112.500, "rain_in" : 28.500, 
>>> "mic" : "CHECKSUM"}\n']
>>>
>>>
>>> parsed: {'wind_speed.042A.Acurite5n1PacketV2': 14.245, 
>>> 'model.042A.Acurite5n1PacketV2': u'Acurite-5n1', 
>>> 'channel.042A.Acurite5n1PacketV2': u'B', 
>>> 'wind_dir.042A.Acurite5n1PacketV2': 112.5, 
>>> 'battery.042A.Acurite5n1PacketV2': 1, 'dateTime': 1590028062, 
>>> 'freq.042A.Acurite5n1PacketV2': None, 'mod.042A.Acurite5n1PacketV2': None, 
>>> 'snr.042A.Acurite5n1PacketV2': None, 
>>> 'sequence_num.042A.Acurite5n1PacketV2': 0, 'noise.042A.Acurite5n1PacketV2': 
>>> None, 'protocol.042A.Acurite5n1PacketV2': None, 
>>> 'rssi.042A.Acurite5n1PacketV2': None, 'msg_type.042A.Acurite5n1PacketV2': 
>>> 49, 'usUnits': 1}
>>>
>>>
>>> I have done a lot of searching on this forum and the web and I 
>>> understand that there have been many changes to the labeling of rain data 
>>> on the Acurite 5n1 system.  Howerver I just can't figure out where in the 
>>> code I can make a change that will accept label that my version of the 
>>> weather station uses for rain.
>>>
>>>
>>> I have done a fair share of programming and I have the help of my son 
>>> who is a computer science graduate.  I feel quite comfortable messing 
>>> around in the

Re: [weewx-user] Problem with evapotranspiration after upgrade from 3.9.2 to 4.0

2020-05-23 Thread IL

Hi Tom,

Thanks for coming back to me. I think I have to apologize for starting this 
thread. I found the error that caused the bar diagram to fail and now 
things look quite normal. ET is similar to what I have seen before. Anyhow, 
I send you the output in case you would care to check that they look normal:

sqlite> select min(datetime), max(dateTime), max(outTemp), min(outTemp), 
avg(radiation), avg(windSpeed), max(outHumidity), min(outHumidity), 
min(usUnits), max(usUnits) from archive where dateTime>(select 
max(dateTime)-3600 from archive);
1590210900|1590214200|51.3|50.7|89.211875|4.6775|60.6|52.6|1|1
sqlite> select ET from archive where dateTime>(select max(dateTime)-3600 
from archive);
0.000223473613245717
0.000229618686937834
0.00023451813434357
0.000239598357624378
0.000250680108928587
0.000266873771008581
0.000271250644152054
0.000272915521568785
0.000287344592539979
0.000291979787367749
0.00029852631520853
0.000301432150630844

// Ingemar

Den lördag 23 maj 2020 kl. 02:47:35 UTC+2 skrev Tom Keffer:
>
> Let's check by calculating the ET for the last hour in your database, a 
> time when, hopefully, there is a meaningful ET. Use this select statement:
>
> select min(datetime), max(dateTime), max(outTemp), min(outTemp), 
> avg(radiation), avg(windSpeed), max(outHumidity), min(outHumidity), 
> min(usUnits), max(usUnits) from archive where dateTime>(select 
> max(dateTime)-3600 from archive);
>
> We'll also need the values of ET:
>
> select ET from archive where dateTime>(select max(dateTime)-3600 from 
> archive);
>
> Send me the results, and I'll do the calculation.
>
> -tk
>
> On Fri, May 22, 2020 at 6:08 AM IL > 
> wrote:
>
>> Before upgrade I had a bar diagram for ET (hourly total) in the Seasons 
>> skin showing reasonable values. After upgrade the diagram is still there, 
>> but no bars. When I look into the database there are values > 0. Today, a 
>> day with beautiful weather and bright sunshine, I see values like 0.0009. 
>> Before upgrade values were often > 1. 
>>
>> I would expect the bars to return when I look at a longer period (week, 
>> month, year) which includes the time before the upgrade, but that doesn't 
>> happen. I did edit the configuration files, so some of this may be my 
>> fault. But before looking into that I must get back more reasonable ET 
>> values, and those are calculated and nothing I have tempered with. 
>> Temperature, wind speed, radiation etc. are OK. 
>>
>> Has someone else seen this? Any ideas?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/27def363-689b-4e9f-b087-bcdf5a1a0a40%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/4b96da50-e8f8-4994-83fc-0533cfcf5311%40googlegroups.com.

[weewx-user] Re: GUI date/time and current conditions frozen

Disabling WU didn't help.
>
> May 23 15:00:19 weewx weewx[10289] DEBUG user.interceptor: raw packet: {
'wind_speed': 2.0, 'humidity_in': 46.0, 'temperature_in': 72.9, 
'solar_radiation': 134.81, 'windchill': 54.9, 'dewpoint': 47.8, 
'humidity_out': 77.0, 'uv': 1.0, 'rain': 0.0, 'dateTime': 1590242400, 
'pressure': 30.11, 'temperature_out': 54.9, 'wind_dir': 61.0, 'barometer': 
30.071, 'rain_total': 0.0, 'usUnits': 1, 'wind_gust': 3.4}

I thought using pcap filter is better than in my case.
Switched to "address = 192.168.2.41", cleaned the database, deleted the 
html and started weewx.

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

[weewx-user] Re: Uṕgrade from 2.7.0 to 4.0.0 fail

2020-05-23 Thread BEIJY BUA

Hello

After Uninstall the cmon extension i have only one Problem with the 
Weather34:

May 23 11:55:05 raspberrypi weewxd: w34rt: service version is 0.0.5
May 23 11:55:05 raspberrypi weewxd: w34rt: output goes to 
/var/www/html/weewx/weather34/w34realtime.txt
May 23 11:55:05 raspberrypi weewxd: w34rt: 'None' values will be displayed 
as NULL
May 23 11:55:05 raspberrypi weewxd: w34rt: units will be displayed as 
METRICWX
May 23 11:55:05 raspberrypi weewxd: w34rt: zambretti forecast: False
May 23 11:55:05 raspberrypi weewxd: w34rt: Failed to open config file or 
create dictionary: /var/www/html/weewx/weather34/settings1.php, Error: 
[Errno 2] Datei oder Verzeichnis nicht gefunden: 
u'/var/www/html/weewx/weather34/settings1.php'
May 23 11:55:05 raspberrypi weewxd: w34rt: Weather34 RetainLoopValues in 
cache is: True
May 23 11:55:05 raspberrypi weewxd: w34rt: binding is loop

I have no file with settings1.php in the folder is a file called: 
settings1.default.php ???

Thanx for the Help

Am Mittwoch, 20. Mai 2020 19:34:28 UTC+2 schrieb BEIJY BUA:
>
> Hello Everybody
>
> Sorry for my bad English.
> I have a problem after Upgrade to 4.0.0
> Here is the Post from the status:
>
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>  File "/home/weewx/bin/weewxd", line 148, in main
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>    engine = weewx.engine.StdEngine(config_dict)
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>  File "/home/weewx/bin/weewx/engine.py", line 75, in __init__
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>    self.loadServices(config_dict)
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>  File "/home/weewx/bin/weewx/engine.py", line 138, in loadServices
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>    obj = weeutil.weeutil.get_object(svc)(self,config_dict)
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>  File "/home/weewx/bin/user/cmon.py", line 190, in __init__
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>    self.archive = 
> weewx.archive.Archive.open_with_create(config_dict['Databases'][self.database],
>  
> schema, self.table)
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>    AttributeError: 'module' object has no attribute 'archive'
> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>    Exiting.
>
>
> I hope i became help here .
>
> Many Thnx
>
> Chris
>

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

[weewx-user] Re: GUI date/time and current conditions frozen

Here's the log -> https://pastebin.com/B2zFhnje

-- 
You received this message because you are subscribed to the Google 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/d0ad85c0-ef6a-4b9c-ba7b-9fe6467cdc37%40googlegroups.com.

Re: [weewx-user] V4 with python2 OWFS errors


Tried that change and it crashed with a different set of errors.


Gaz



-- 
You received this message because you are subscribed to the Google 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/ec0c7d16-8d7b-4c0b-8285-982a91157a4b%40googlegroups.com.
ay 23 22:00:59 GazPi4 weewx[1120] INFO __main__: Initializing weewx version 
4.0.0
May 23 22:00:59 GazPi4 weewx[1120] INFO __main__: Using Python 2.7.16 (default, 
Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
May 23 22:00:59 GazPi4 weewx[1120] INFO __main__: Platform 
Linux-4.19.97-v7l+-armv7l-with-debian-10.4
May 23 22:00:59 GazPi4 weewx[1120] INFO __main__: Locale is 'en_AU'
May 23 22:00:59 GazPi4 weewx[1120] INFO __main__: Using configuration file 
weewx.conf
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.engine: Loading station type SDR 
(user.sdr)
May 23 22:00:59 GazPi4 weewx[1120] INFO user.sdr: driver version is 0.77
May 23 22:00:59 GazPi4 weewx[1120] INFO user.sdr: sensor map is {u'windGust': 
u'wind_gust.38.FOWHx080Packet', u'outTempBatteryStatus': 
u'battery.38.FOWHx080Packet', u'rain_total': u'rain_total.38.FOWHx080Packet', 
u'windSpeed': u'wind_speed.38.FOWHx080Packet', u'windDir': 
u'wind_dir.38.FOWHx080Packet', u'outHumidity': u'humidity.38.FOWHx080Packet', 
u'outTemp': u'temperature.38.FOWHx080Packet', u'extraTemp1': 
u'temperature.32D1.AcuriteTowerPacketV2', u'batteryStatus1': 
u'battery.32D1.AcuriteTowerPacketV2', u'extraTemp2': 
u'temperature.39.ProloguePacket', u'extraHumid2': 
u'humidity.39.ProloguePacket', u'batteryStatus2': u'battery.39.ProloguePacket', 
u'extraTemp3': u'temperature.1:180.NexusTemperaturePacket', u'extraHumid3': 
u'humidity.1:180.NexusTemperaturePacket', u'batteryStatus3': 
u'battery.1:180.NexusTemperaturePacket', u'extraTemp4': 
u'temperature.5.ProloguePacket', u'extraHumid4': u'humidity.5.ProloguePacket', 
u'batteryStatus4': u'battery.5.ProloguePacket'}
May 23 22:00:59 GazPi4 weewx[1120] INFO user.sdr: deltas is {'strikes': 
'strikes_total', 'rain': 'rain_total'}
May 23 22:00:59 GazPi4 weewx[1120] INFO user.sdr: startup process 'rtl_433 -M 
utc -F json'
May 23 22:00:59 GazPi4 weewx[1120] INFO user.owfs: service version is 0.23
May 23 22:00:59 GazPi4 weewx[1120] INFO user.owfs: binding is archive
May 23 22:00:59 GazPi4 weewx[1120] INFO user.owfs: interface is /dev/i2c-1
May 23 22:00:59 GazPi4 weewx[1120] INFO user.owfs: sensor map is 
{u'extraTemp5': u'/uncached/28.E1044104/temperature'}
May 23 22:00:59 GazPi4 weewx[1120] INFO user.owfs: sensor type map is {}
May 23 22:00:59 GazPi4 weewx[1120] INFO user.owfs: sensor unit system is metric
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.engine: StdConvert target unit is 
0x1
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.wxservices: The following values 
will be calculated: pressure=prefer_hardware, altimeter=prefer_hardware, 
appTemp=prefer_hardware, barometer=prefer_hardware, beaufort=prefer_hardware, 
cloudbase=prefer_hardware, dewpoint=prefer_hardware, ET=prefer_hardware, 
heatindex=prefer_hardware, humidex=prefer_hardware, inDewpoint=prefer_hardware, 
maxSolarRad=prefer_hardware, rainRate=prefer_hardware, 
windchill=prefer_hardware, windrun=prefer_hardware
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.wxservices: The following 
algorithms will be used for calculations: altimeter=aaASOS, maxSolarRad=RS
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.engine: Archive will use data 
binding wx_binding
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.engine: Record generation will be 
attempted in 'hardware'
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.engine: Using archive interval of 
300 seconds (specified in weewx configuration)
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.restx: StationRegistry: 
Registration not requested.
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.restx: Wunderground: Posting not 
enabled.
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.restx: PWSweather: Posting not 
enabled.
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.restx: CWOP: Posting not enabled.
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.restx: WOW: Posting not enabled.
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.restx: AWEKAS: Posting not 
enabled.
May 23 22:00:59 GazPi4 weewx[1120] INFO __main__: Starting up weewx version 
4.0.0
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.manager: Starting backfill of 
daily summaries
May 23 22:00:59 GazPi4 weewx[1120] INFO weewx.engine: Starting main packet loop.
May 23 22:00:59 GazPi4 kernel: [  870.052667] r820t 8-001a: destroying instance
May 23 22:00:59 GazPi4 kernel: [  870.053082] dvb_usb_v2: 'Realtek RTL2832U 
reference design:1-1.2' successfully deinitialized and disconnected
May 23 22:02:15 GazPi4 systemd[1]: Starting Cleanup of Temporary

[weewx-user] Re: sdr.py not parsing Oregon WGR800X output correctly.

2020-05-23 Thread 'Rob Series' via weewx-user

Hi,
I have done some more research and it looks like there was a change in 
RTL_433 at tag 19.08 (August 2019) that changed the naming convention for a 
significant number of wind related fields for lots of sensors. I guess 
sdr.py needs to be updated to take this into account. I would offer but my 
main programming was over 20 years ago and have never programmed in Python 
so I would probably do more harm than good.

https://github.com/merbanan/rtl_433/commit/6d21cad0f158fbc6064d66ddd1abf96d6ba4867b#diff-06935eba6ba3c8d3e4b0d4d59d294ac8

see also:

https://github.com/merbanan/rtl_433/blob/6d75c7db86793072f854a33efa0a88a83e06e796/src/devices/oregon_scientific.c#L637-L654

On Wednesday, 20 May 2020 14:00:38 UTC+1, Rob Series wrote:
>
> Hi,
>
> Please could anyone help. I'm having problems using an Oregon wind speed 
> sensor using instructions on /weewx/weewx/wiki/sdr-rpi-recipe.
> This was working, but following an upgrade from an old WGR800 to the newer 
> WGR800X it seems to have broken. 
>  
> Output from sdr.py shows its getting the correct wind speed, but the parse 
> is breaking. The crazy thin is it works with my older WGR800 unit where the 
> input appears to be the same format. Is it possibly related to the \n
>
> WEEWX SDR FILTER OUTPUT
> ===
> * pi@raspberrypi:~ $ sudo PYTHONPATH=/usr/share/weewx python 
> /usr/share/weewx/user/sdr.py --cmd="rtl_433 -M utc -F json" --debug*
>
> out:[u'{"time" : "2020-05-20 12:24:03", "brand" : "OS", "model" : 
> "Oregon-WGR800", "id" : 100, "channel" : 0, "battery_ok" : 1, 
> "wind_max_m_s" : 1.700, "wind_avg_m_s" : 0.600, "wind_dir_deg" : 202.500
> }\n']
>
> parsed: {'battery.0:100.OSWGR800Packet': 1, 
> 'wind_dir.0:100.OSWGR800Packet': None, 'dateTime': 1589977443, 
> 'wind_speed.0:100.OSWGR800Packet': None, 
> 'wind_gust.0:100.OSWGR800Packet': None, 'usUnits': 17}
>
>
> *weewx.conf*
>
> ...
>   [SDR]
> # This section is for the software-defined radio driver.
> 
> # The driver to use
> driver = user.sdr
> cmd = rtl_433 -M utc -F json
> path=/usr/local/bin/
> log_unknown_sensors = True
> log_unmapped_sensors = True
> 
> [[sensor_map]]  
> # Wind sensor
> windSpeed = wind_speed.0:100.OSWGR800Packet
> windGust = wind_gust.0:100.OSWGR800Packet
> windDir = wind_dir.0:100.OSWGR800Packet
> windBatteryStatus = battery.0:100.OSWGR800Packet
>
>
> Other info
> ==
> pi@raspberrypi:~ $ sudo PYTHONPATH=/usr/share/weewx python 
> /usr/share/weewx/user/sdr.py --version
> sdr driver version 0.77
>
> pi@raspberrypi:~ $ rtl_433 -V
> rtl_433 version 20.02-55-gc1d1f9f branch master at 202005162227 inputs 
> file rtl_tcp RTL-SDR
>
>
>
> ALSO
> 
> If anyone has access to edit the sdr-rpi-recepie page, could the add 
> appropriate 'cmd' and 'path' lines to the conf file (or should thhs have 
> been added automativally by weewx_conf and the install script?
> It took me some time to figure it out.
>
> Many thanks for a great product.
>
>
>
>

-- 
You received this message because you are subscribed to the Google 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/f314cf81-9a25-404f-9b49-e17a50535a4d%40googlegroups.com.

[weewx-user] Re: GUI date/time and current conditions frozen

We have 8:22PM, it stopped at last report wast generated at 8PM.
Here's the log of the first 30 minutes, of the actual run
https://pastebin.com/uhyCkPvX

-- 
You received this message because you are subscribed to the Google 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/02730962-94ae-4b07-ac7b-8612c286aceb%40googlegroups.com.

Re: [weewx-user] How to calculate, process and store a derived variable

2020-05-23 Thread Maarten van der Hoeven

Thanks Tom for the pointer. Already busy implementing

Op zaterdag 23 mei 2020 02:52:39 UTC+2 schreef Tom Keffer:
>
> Sounds like a perfect job for the xtypes system. See this wiki article: 
> *WeeWX 
> V4 user defined types (xtypes)* 
> . See if 
> it answers your question.
>
> If you define a derived variable using xtypes, it becomes a first-class 
> type and can be used in plots, or tagged expressions. If it appears in your 
> database schema, it will also be put in the database.
>
> -tk
>
> On Fri, May 22, 2020 at 7:14 AM Maarten van der Hoeven  > wrote:
>
>> Hi group,
>>
>> Running weewx 4, Python 3, Mysql-database, Vantage Pro 2 with solar, UV.
>>
>> Within Weewx, I want to calculate a derived value from two existing 
>> values that's provided by my weather station. To be more specific, in the 
>> Netherlands, the shortage of precipitation is calculated by the amount of 
>> rainfall minus the amount of evapotransipration (sum of max ET-values every 
>> day). During the period of april till september, it;'s a drought indicator.
>>
>> My SQL-query to do show is, where 'tekort'  (Dutch) stands for 
>> 'shortage'. 
>>
>> select abs(round(sum(archive_day_rain.sum)-sum(archive_day_ET.sum),0)) as 
>> tekort from archive_day_ET,archive_day_rain where 
>> from_unixtime(archive_day_rain.datetime,'%Y')=year(curdate()) and 
>> month(from_unixtime(archive_day_rain.datetime)) >= 4 and 
>> month(from_unixtime(archive_day_rain.datetime)) <= 9 and 
>> archive_day_rain.datetime=archive_day_ET.datetime;
>>
>> What I am doing right now, is running a crontab job, and start my 
>> PHP-script every minute to calculate the outcome of the SQL-script above 
>> and writes the outcome to a plan txt-file. Next step is to grab this value 
>> from the txt-file and show it (javascript) on my website. See 
>> http://www.weerinwelsum.nl, below the webcam. It says ' Doorlopend 
>> neerslagtekort', [amount of millimeters]. This is the value I am talking 
>> about.
>>
>> What I really want to achieve, is that I calculate this derived valu by 
>> WeeWX itself, and make this derived value available for everything that's 
>> wants to use is. For example, store this derived value in a database-field 
>> I am not using (for example, soilTemp4) and make this derived value 
>> available for whatever skin (in my case, Belchertown). In other words, 
>> Weewx calculates this new value and makes it available for the complete 
>> WeeWX-ecosystem (if you understand what I mean).
>>
>> Am I clear in what I want to achieve? And is this possible, and what are 
>> the pointers to do so?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/d48cfc39-5e17-4795-a75f-ac4c266e73b0%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/550c4e0a-fad5-4169-bb3a-cc530f383a55%40googlegroups.com.

[weewx-user] Re: weewx output plugin/extension for WXSIM weather simulator?

2020-05-23 Thread Russell Swan

Add me to the list of users who would find this adaptation useful. 

On Wednesday, May 13, 2020 at 3:38:09 AM UTC-4, Ville Helander wrote:
>
> Hi Christian!
>
> Did you get anythink working after this? 
> Is there way to enhance the crt extension to create monthly files also?
> Or is weewx-wd better option?
>
> -Ville-
>
>
> perjantai 4. tammikuuta 2019 16.33.00 UTC+2 Christian Peters kirjoitti:
>>
>> Hm...
>>
>> yesthere is the 'crt' extension which emitts a cumulus style file, 
>> but not a monthly report but a realtime.txt.
>>
>> Am Freitag, 4. Januar 2019 14:14:00 UTC+1 schrieb pmcg...@gmail.com:
>>>
>>> The Cumulus Wiki shows the format of their monthly log files, if you 
>>> generated a similar report it could work.
>>>
>>> https://cumuluswiki.wxforum.net/a/Monthly_log_files
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google 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/d6402966-4e2b-4e91-b16d-d54cb5b2e0fd%40googlegroups.com.

[weewx-user] Re: AcuRite 5-in-1 sensor and barometric pressure

2020-05-23 Thread Greg Gowins

So I have a similar setup to this that had been running fine in 3.9.x, 
except I also have an Acurite Lightning Meter and a BME280 chip connected, 
using the weewx extension from here to run it:  
https://gitlab.com/wjcarpenter/bme280wx

I upgraded to Weewx 4 last night, and everything seems to be running ok 
except for weewx processing the data.  In the logs I see that it is reading 
the data from the chip fine, but it isn't making it in to the weewx .  When 
I see it process, it appears to be trying to put the BME280 data into 
fields for the lightning meter:

May 23 10:02:13 weatherstation weewxd: bme280: BME280 data 
compensated_reading(id=6e6ccd6e-39bd-42bb-8648-d9e1e855719c, 
timestamp=2020-05-23 10:02:13.100774, temp=27.089 °C, pressure=977.55 hPa, 
humidity=42.11 % rH)
May 23 10:02:13 weatherstation weewxd: bme280: {u'distance': 0, 
u'lastStrikeTime': 1590246128, u'strikes_total': 15, u'strikes': 0, 
'dateTime': 1590246128, 'usUnits': 1}
May 23 10:02:13 weatherstation weewxd: sdr: MainThread: 
packet={u'distance': 0, u'lastStrikeTime': 1590246128, 'dateTime': 
1590246128, 'usUnits': 1, u'strikes_total': 15}
May 23 10:02:13 weatherstation weewx[593] INFO weewx.restx: MQTT: Published 
record 2020-05-23 10:02:08 CDT (1590246128)

Any clue on where to look for troubleshooting this one?  When I upgraded 
weewx to 4, I used the existing weewx.conf.  I looked through the 
weewx.conf-4.0.0 to to see if anything jumped out, but nothing did.  Any 
info is appreciated.  Thanks!

Greg


On Thursday, May 21, 2020 at 6:49:14 PM UTC-5, Bryan Parke wrote:
>
> Hi all.  Weewx is great! I'm very impressed with all that it can do.  Here 
> is a bit about my setup.
>
> 1) AcuRite 5-in-1 pro broadcasting on 433mhz
> 2) Raspberry Pi with rtl-sdr capturing data using rtl_433
> 3) Using the sdr driver
> 4) Using mosquitto to publish real-time weather data and viewing that in 
> belchertown realtime
> 5) Pushing every 10 minutes to the CWOP for APRS (
> https://aprs.fi/info/a/KM6YFK-13) 
>
> All is working as expected, no issues at all.
>
> My question is this: I'd like to get barometric pressure also, but the 
> 5-in-1 doesn't have that.  My understanding is that in order to get 
> barometric pressure, I would need to purchase the AcuRite receiver/screen 
> and plug it in via USB to my raspberry pi; in that the barometric pressure 
> sensor is actually in the screen/display unit.  
>
> 1) is that true?  Or is there actually another way to get the pressure 
> using the 5-in-1? 
> 2) Is there another device that you all like that would accomplish the 
> same thing?
>
> Hopefully I'm asking the right question in the right way.  Ultimately I 
> just want to also include the air pressure in my weather reports (see 
> attachment, sad bottom right corner with no barometer info).
>
> Thanks!
> Bryan
>
>
>

-- 
You received this message because you are subscribed to the Google 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/1f62991a-23b5-4b72-9b23-41d6839f7c54%40googlegroups.com.

[weewx-user] Re: Problem with alarm.py in Weewx 4.0

2020-05-23 Thread Remy Lavabre

Hello,

In fact I found a solution:

alarm.py has been placed in the folder /usr/share/weewx/weewx (with 
engine.py, cheetagenerator.py and other..) ;

and I changed the line in the weewx.conf : 

report_services = weewx.engine.StdPrint, weewx.engine.StdReport, 
weewx.alarm.MyAlarm

Now it works well!

By cons I still have a question ...(!!!) : is it possible (*and how!*) To 
make an alarm with several conditions (example: outdoor temperature> 40 AND 
outdoor humidity> 90)?

Thank you very much for your contribution


-- 
You received this message because you are subscribed to the Google 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/7bc48c0d-801a-4c2f-88a4-98e30510271f%40googlegroups.com.

Re: [weewx-user] Re: Uṕgrade from 2.7.0 to 4.0.0 fail

2020-05-23 Thread steeple ian

Hi Beijy,
The settings1.php file is created the first time you open the settings
page. It uses the default file that you mentioned as the basis for this.
So, in your browser go to the easyW34skinSetup.php file which will open the
settings page. Once you have applied your preferences and save,
settings1.php will be created. You can then access the settings page from
the menu if you need to make any other changes in the future.
Ian

On Sat, 23 May 2020 at 11:16, BEIJY BUA  wrote:

> Hello
>
> After Uninstall the cmon extension i have only one Problem with the
> Weather34:
>
> May 23 11:55:05 raspberrypi weewxd: w34rt: service version is 0.0.5
> May 23 11:55:05 raspberrypi weewxd: w34rt: output goes to
> /var/www/html/weewx/weather34/w34realtime.txt
> May 23 11:55:05 raspberrypi weewxd: w34rt: 'None' values will be displayed
> as NULL
> May 23 11:55:05 raspberrypi weewxd: w34rt: units will be displayed as
> METRICWX
> May 23 11:55:05 raspberrypi weewxd: w34rt: zambretti forecast: False
> May 23 11:55:05 raspberrypi weewxd: w34rt: Failed to open config file or
> create dictionary: /var/www/html/weewx/weather34/settings1.php, Error:
> [Errno 2] Datei oder Verzeichnis nicht gefunden:
> u'/var/www/html/weewx/weather34/settings1.php'
> May 23 11:55:05 raspberrypi weewxd: w34rt: Weather34 RetainLoopValues in
> cache is: True
> May 23 11:55:05 raspberrypi weewxd: w34rt: binding is loop
>
> I have no file with settings1.php in the folder is a file called:
> settings1.default.php ???
>
> Thanx for the Help
>
> Am Mittwoch, 20. Mai 2020 19:34:28 UTC+2 schrieb BEIJY BUA:
>>
>> Hello Everybody
>>
>> Sorry for my bad English.
>> I have a problem after Upgrade to 4.0.0
>> Here is the Post from the status:
>>
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>  File "/home/weewx/bin/weewxd", line 148, in main
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>    engine = weewx.engine.StdEngine(config_dict)
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>  File "/home/weewx/bin/weewx/engine.py", line 75, in __init__
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>    self.loadServices(config_dict)
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>  File "/home/weewx/bin/weewx/engine.py", line 138, in loadServices
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>    obj = weeutil.weeutil.get_object(svc)(self,config_dict)
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>  File "/home/weewx/bin/user/cmon.py", line 190, in __init__
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>    self.archive =
>> weewx.archive.Archive.open_with_create(config_dict['Databases'][self.database],
>> schema, self.table)
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>    AttributeError: 'module' object has no attribute 'archive'
>> Mai 20 19:32:11 raspberrypi weewxd[496]: weewx[496] CRITICAL __main__:
>>    Exiting.
>>
>>
>> I hope i became help here .
>>
>> Many Thnx
>>
>> Chris
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/d24ca613-e0c9-4f84-9ce1-f1469f826570%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/CADASSaQn1aepjED8n6ufVF%3DcnooXrxi3stGc%3DUyT%3DG_NEn23xA%40mail.gmail.com.

[weewx-user] Upgrade 3.9.2>4.0 Problem with TE923 Nexus driver (unable to load driver)

2020-05-23 Thread Felix Maltzahn

Hey, 

After upgrading weewx to V.4.0 I have a big problem with reading my TFA 
Nexus (TE923). If I downgrade to 3.9.2 all works fine.
In the tail log I found the following messages:

 sudo tail -f /var/log/syslog
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
  self.read_memory_size()
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
File "/usr/share/weewx/weewx/drivers/te923.py", line 1752, in 
read_memory_size
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
  buf = self._read(0xfc)
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
File "/usr/share/weewx/weewx/drivers/te923.py", line 1722, in _read
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
  buf = self._raw_read(addr)
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
File "/usr/share/weewx/weewx/drivers/te923.py", line 1582, in 
_raw_read
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
  reqbuf[5] = (reqbuf[1] ^ reqbuf[2] ^ reqbuf[3] ^ reqbuf[4])
May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine:   
TypeError: unsupported operand type(s) for ^: 'int' and 'float'
May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__: Unable to load 
driver: unsupported operand type(s) for ^: 'int' and 'float'
May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__:   
Exiting.. 

Can anybody help me?
Sorry for my bad english ;) Greetings from Germany

-- 
You received this message because you are subscribed to the Google 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/cb693d1a-d6dc-45af-9cb6-3ba86a8ab425%40googlegroups.com.

[weewx-user] Reading Atlas signal w/Rpi3 and SDR

2020-05-23 Thread Preston

Hello, So I have tried getting this working and giving up about 8 months
ago as the SDR had not been developed enough to read the AcuRite Atlas
signals. I have found a renewed interest in trying to get this working
again as it looks like people are getting there Atlas's into WeeWx. But I'm
running into a different issue this time. I have followed this guide (
https://github.com/weewx/weewx/wiki/sdr-rpi-recipe). In that guide hes
using matthewwall weewx-sdr driver (
https://github.com/matthewwall/weewx-sdr.git). When looking through the
change logs it looks like the Atlas was added back in update 0.73.

When i had tried doing this a few months ago, running:
rtl_433 -G
it cam up with some gibberish,...More or less it couldn't read the signal.
If i remember it correctly it detected my Atlas as a 5n1

But now when I run the rtl_433 -G command it does not detect my Atlas at
all. It will detect my AcuRite 06002M, so i know the RTL-SDR dongle is
working. And i know the Atlas is sending a signal, because my AcuRite
access is showing its connected, and its updating the myacurite.com page
with the weather stats.

For reference I have the Nooelec NESDR Mini USB RTL-SDR from Amazon
https://www.amazon.com/gp/product/B009U7WZCA
Raspberry Pi 3+ with 5v 2.5A Power Supply

What am i doing wrong, How are you guys getting the Atlas to work with your
Raspberry Pi's?

Any ideas or things that I'm probably doing wrong?

--
You received this message because you are subscribed to the Google 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/cced3f2f-5024-4d0a-9a7e-af7ac6455a1b%40googlegroups.com.

[weewx-user] Re: Upgrade 3.9.2>4.0 Problem with TE923 Nexus driver (unable to load driver)

2020-05-23 Thread Felix Maltzahn

Thank you! The weatherstation service is my first RPI project. Where I can 
find the driver files on my RPI? 

Am Samstag, 23. Mai 2020 19:59:04 UTC+2 schrieb Michael:
>
> Hi Felix,
>
> try this 
> https://raw.githubusercontent.com/weewx/weewx/development/bin/weewx/drivers/te923.py
> see: 
> https://groups.google.com/forum/#!searchin/weewx-user/te923%7Csort:date/weewx-user/Bx4tSRnz7aw/sZ8QPU4hBAAJ
>
> Michael
>
>
> Am Samstag, 23. Mai 2020 19:38:02 UTC+2 schrieb Felix Maltzahn:
>>
>> Hey, 
>>
>> After upgrading weewx to V.4.0 I have a big problem with reading my TFA 
>> Nexus (TE923). If I downgrade to 3.9.2 all works fine.
>> In the tail log I found the following messages:
>>
>>  sudo tail -f /var/log/syslog
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>   self.read_memory_size()
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>> File "/usr/share/weewx/weewx/drivers/te923.py", line 1752, in 
>> read_memory_size
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>   buf = self._read(0xfc)
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>> File "/usr/share/weewx/weewx/drivers/te923.py", line 1722, in _read
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>   buf = self._raw_read(addr)
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>> File "/usr/share/weewx/weewx/drivers/te923.py", line 1582, in 
>> _raw_read
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>   reqbuf[5] = (reqbuf[1] ^ reqbuf[2] ^ reqbuf[3] ^ reqbuf[4])
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>   TypeError: unsupported operand type(s) for ^: 'int' and 'float'
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__: Unable to 
>> load driver: unsupported operand type(s) for ^: 'int' and 'float'
>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__:   
>> Exiting.. 
>>
>> Can anybody help me?
>> Sorry for my bad english ;) Greetings from Germany
>>
>

-- 
You received this message because you are subscribed to the Google 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/d6e7ea06-b81b-4138-89df-378f3c61962a%40googlegroups.com.

[weewx-user] Re: Upgrade 3.9.2>4.0 Problem with TE923 Nexus driver (unable to load driver)

2020-05-23 Thread Michael

Hi Felix,

try this 
https://raw.githubusercontent.com/weewx/weewx/development/bin/weewx/drivers/te923.py
see: 
https://groups.google.com/forum/#!searchin/weewx-user/te923%7Csort:date/weewx-user/Bx4tSRnz7aw/sZ8QPU4hBAAJ

Michael


Am Samstag, 23. Mai 2020 19:38:02 UTC+2 schrieb Felix Maltzahn:
>
> Hey, 
>
> After upgrading weewx to V.4.0 I have a big problem with reading my TFA 
> Nexus (TE923). If I downgrade to 3.9.2 all works fine.
> In the tail log I found the following messages:
>
>  sudo tail -f /var/log/syslog
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>   self.read_memory_size()
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/te923.py", line 1752, in 
> read_memory_size
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>   buf = self._read(0xfc)
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/te923.py", line 1722, in _read
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>   buf = self._raw_read(addr)
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
> File "/usr/share/weewx/weewx/drivers/te923.py", line 1582, in 
> _raw_read
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>   reqbuf[5] = (reqbuf[1] ^ reqbuf[2] ^ reqbuf[3] ^ reqbuf[4])
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine:   
> TypeError: unsupported operand type(s) for ^: 'int' and 'float'
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__: Unable to 
> load driver: unsupported operand type(s) for ^: 'int' and 'float'
> May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__:   
> Exiting.. 
>
> Can anybody help me?
> Sorry for my bad english ;) Greetings from Germany
>

-- 
You received this message because you are subscribed to the Google 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/8210c5f8-0352-4f21-808a-0072313006e8%40googlegroups.com.

[weewx-user] Re: Upgrade 3.9.2>4.0 Problem with TE923 Nexus driver (unable to load driver)

2020-05-23 Thread Michael

depends on the type of installation:
setup.py -> /home/weewx/bin/weewx/drivers

Am Samstag, 23. Mai 2020 20:12:47 UTC+2 schrieb Felix Maltzahn:
>
> Thank you! The weatherstation service is my first RPI project. Where I can 
> find the driver files on my RPI? 
>
> Am Samstag, 23. Mai 2020 19:59:04 UTC+2 schrieb Michael:
>>
>> Hi Felix,
>>
>> try this 
>> https://raw.githubusercontent.com/weewx/weewx/development/bin/weewx/drivers/te923.py
>> see: 
>> https://groups.google.com/forum/#!searchin/weewx-user/te923%7Csort:date/weewx-user/Bx4tSRnz7aw/sZ8QPU4hBAAJ
>>
>> Michael
>>
>>
>> Am Samstag, 23. Mai 2020 19:38:02 UTC+2 schrieb Felix Maltzahn:
>>>
>>> Hey, 
>>>
>>> After upgrading weewx to V.4.0 I have a big problem with reading my TFA 
>>> Nexus (TE923). If I downgrade to 3.9.2 all works fine.
>>> In the tail log I found the following messages:
>>>
>>>  sudo tail -f /var/log/syslog
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>>   self.read_memory_size()
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>> File "/usr/share/weewx/weewx/drivers/te923.py", line 1752, in 
>>> read_memory_size
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>>   buf = self._read(0xfc)
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>> File "/usr/share/weewx/weewx/drivers/te923.py", line 1722, in _read
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>>   buf = self._raw_read(addr)
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>> File "/usr/share/weewx/weewx/drivers/te923.py", line 1582, in 
>>> _raw_read
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>>   reqbuf[5] = (reqbuf[1] ^ reqbuf[2] ^ reqbuf[3] ^ reqbuf[4])
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL weewx.engine: 
>>>   TypeError: unsupported operand type(s) for ^: 'int' and 'float'
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__: Unable to 
>>> load driver: unsupported operand type(s) for ^: 'int' and 'float'
>>> May 23 18:58:38 wetterstation weewx[1950] CRITICAL __main__:   
>>> Exiting.. 
>>>
>>> Can anybody help me?
>>> Sorry for my bad english ;) Greetings from Germany
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/09c272ec-1ee9-4b87-85cf-1f8c237137ad%40googlegroups.com.

[weewx-user] Re: Belchertown MQTT update time is chaotic

2020-05-23 Thread Jaap de Munck

Hallo Keimpe,

I use

belchertown_locale = nl_NL.*UTF-8*

and that is ok.

Regards,
Jaap



Op maandag 18 mei 2020 19:44:51 UTC+2 schreef Keimpe Bleeker:
>
> Another try to find a solution for a weird problem! 
>
> Problem: MQTT updates are working perfect, but the text and time of the 
> last update on the website is chaotic (see screenshot and website 
> ). All the other dates and times served by moments.js 
> are 
> 100% OK. Everything is built from scratch on a formatted SDcard, because 
> the same problem occurred since I upgraded Weewx 3.9.# and Belchertown...
>
> System info:
> - Raspberrry Pi 4 Model B Rev 1.2, Debian 10.4, 32GB
> - Weewx 4.0
> - Belchertown 1.1
>
> As far as I know, all the envolved skin.conf issues are:
> ...
> ...
> belchertown_locale = "auto"
> #  belchertown_locale = "nl_NL.utf8"  #checked this setting, without 
> results
> theme = light
> ...
> ...
>  # MQTT Websockets defaults
>  mqtt_websockets_enabled = 1
>  mqtt_websockets_host = my.external.ip.address
>  mqtt_websockets_port = 9001
>  mqtt_websockets_ssl = 0
>  mqtt_websockets_topic = weather/loop
>  disconnect_live_website_visitor = 180
> ...
> ...
> # Show an alert if the page updated timestamp is older than expected 
> with this setting. Does not apply to MQTT Websocket enabled websites
> # The late time threshold is defined in seconds. This should be 
> greater than your archive_interval from weewx.conf.
> # Typically you would want this 2 or 3 times archive_interval
> show_last_updated_alert = 0
> last_updated_alert_threshold = 1800
>
> # If mqtt_websockets_enabled is set to 0, but want the page to full 
> reload on an interval, specify this below in milliseconds. 30 = 5 
> minutes
> webpage_autorefresh = 0
> ...
> ...
> header_last_updated= Laatste update
> mqtt_websockets_connecting   = Real-time verbonden met weerstation
> mqtt_websockets_waiting = Verbonden, wacht op data.
> mqtt_websockets_connected= Real-time verbonden met weerstation
> mqtt_websockets_stopped= Real-time updates zijn gestopt
> mqtt_websockets_continue   = Updates hervatten
> mqtt_websockets_failed= Verbinding verbroken
> mqtt_websockets_lost   = Verbinding verbroken
> ...
> ...
> # moment.js default labels formats
> time_earthquake= "LLL"
> time_lastUpdated   = "LL, LTS"
> time_snapshot_records_today_header  = ", LL"
> time_snapshot_records_month_header = " "
> time_sunrise   = "LT"
> time_sunset= "LT"
> time_darksky_alert_expires   = "LLL"
> time_darksky_forecast_date  = "ddd DD/M"
> time_forecast_last_updated   = "LLL"
> time_mqtt_websockets_last_updated= "LL, LTS"
> time_records_page_full_date = "LLL"
> time_records_page_month_day_year= "LL"
> time_records_page_rainfall_range_begin  = " DD"
> time_records_page_rainfall_range_end= "LL"
> ...
> ...
>
> The website is running in DEBUG-mode (http://oentsjerk.eu/?debug=true), 
> if you like to spend a minute to investigate, you are very welcome!
>
> Regards, Keimpe
>

-- 
You received this message because you are subscribed to the Google 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/b9544a78-d877-4b06-97a6-ea8457e3f687%40googlegroups.com.

[weewx-user] Re: Upgrade 3.9.2>4.0 Problem with TE923 Nexus driver (unable to load driver)

2020-05-23 Thread Jan Stelling


>
> Same problem here. I took the driver from the Github repo, copied it to 
> /usr/share/weewx/weewx/drivers/, restarted weewx, but no luck.
> Any ideas?
>

Sorry, the driver works. I faced another problem with my WeatherCloud 
extension that needed an update as well... 

-- 
You received this message because you are subscribed to the Google 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/1234f0fc-0dbe-4f0a-a255-cb57b142d599%40googlegroups.com.

[weewx-user] Re: Upgrade 3.9.2>4.0 Problem with TE923 Nexus driver (unable to load driver)

2020-05-23 Thread Jan Stelling

Same problem here. I took the driver from the Github repo, copied it to 
/usr/share/weewx/weewx/drivers/, restarted weewx, but no luck.
Any ideas?

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

[weewx-user] Re: Weahterdata from meteohub to weewx convert

2020-05-23 Thread Kimmo Hassinen

Hi.

Did you manage to get data from meteohub to weewx?

lauantai 11. huhtikuuta 2020 4.52.35 UTC+3 gjr80 kirjoitti:
>
> Hello,
>
> Is this the csv file you referred to in your earlier post in another 
> thread 
> ? If 
> so wee_import is the tool to use but it cannot import the data in it's 
> present format. You would need to merge the date (Datum) and time (Zeit) 
> fields into a single field, eg 01.02.2020 and 00:00 would need to be 
> 01.02.2020 00:00. wee_import is fairly flexible in terms of the format of 
> the single date-time field (any format, any order) but it must be a single 
> field. Perhaps you can do this relatively easily using a spreadsheet or 
> other editor? Another minor point but you will need to delete the second, 
> third and fourth lines; wee_import requires the csv file consist of only 
> a header line and lines of data to be imported. This is easily taken care 
> of though.
>
> Gary
>
> On Friday, 10 April 2020 23:21:28 UTC+10, Meteo Oberwallis wrote:
>>
>> Hello. 
>>
>> I have from meteohub the .csv created. here is an example. 
>>
>> Is it possible to adapt this file so that it can be copied into the SQL 
>> table?
>>
>> Thx for Help
>>
>>
>>
>> Am Montag, 30. März 2020 12:50:27 UTC+2 schrieb Meteo Oberwallis:
>>>
>>> Hi Guys.
>>> I used meteohub before using weewx. I have now collected weather data for 
>>> years. Since the switch, however, I have now lacked this data. Meteohub 
>>> saves the data in a .raw file. Does any of you have that too? Does anyone 
>>> have a solution how to convert the data and read it into weewx afterwards? 
>>> In the SQLite would be great.
>>> I would appreciate your help. The Page Meteohub: 
>>> https://wiki.meteohub.de/Main_Page 
>>>
>>> Thanks 
>>> Stefan
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google 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/969c560b-2c0b-4410-ae68-6514cb645b6a%40googlegroups.com.

[weewx-user] Issue with BME280 after upgrade to weewx 4

2020-05-23 Thread Greg Gowins

I posted this in another thread, but figured it might be better seen if I
started a new topic.

For a while I have been running an Acurite 5-n-1 and Acurite Lightning
sensor via SDR, and have a BME280 connected to the Pi, with the weewx
extension from here to run it: https://gitlab.com/wjcarpenter/bme280wx.

I upgraded to Weewx 4 from 3.9.1 last night, and everything seems to be
running ok except for weewx processing the data from the BME280. When I
see it process, it appears to be trying to put the BME280 data into fields
for the lightning meter:

May 23 10:02:13 weatherstation weewxd: bme280: BME280 data
compensated_reading(id=6e6ccd6e-39bd-42bb-8648-d9e1e855719c,
timestamp=2020-05-23 10:02:13.100774, temp=27.089 °C, pressure=977.55 hPa,
humidity=42.11 % rH)
May 23 10:02:13 weatherstation weewxd: bme280: {u'distance': 0,
u'lastStrikeTime': 1590246128, u'strikes_total': 15, u'strikes': 0,
'dateTime': 1590246128, 'usUnits': 1}
May 23 10:02:13 weatherstation weewxd: sdr: MainThread:
packet={u'distance': 0, u'lastStrikeTime': 1590246128, 'dateTime':
1590246128, 'usUnits': 1, u'strikes_total': 15}
May 23 10:02:13 weatherstation weewx[593] INFO weewx.restx: MQTT: Published
record 2020-05-23 10:02:08 CDT (1590246128)

It appears that somehow the barometric pressure info is making it into the
processing engine, as I'm getting barometric pressure successfully
calculated and displayed via Belchertown. But the inTemp in the DB isn't
being populated from the BME280 so obviously no data displayed. Any clue
on where to look for troubleshooting this one? When I upgraded weewx to 4,
I used the existing weewx.conf. I looked through the weewx.conf-4.0.0 to
to see if anything jumped out, but nothing did. Any info is appreciated.
Thanks!

Greg

--
You received this message because you are subscribed to the Google 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/2ca32289-dfe9-49a8-a301-278925087134%40googlegroups.com.

[weewx-user] Not getting parsed output

2020-05-23 Thread 'dvdhns' via weewx-user

When running rtl_433 I can see several sensors.

However, when I run weewx with the sdr driver, I can only see the 
Acurite5n1 sensor. None of the others are parsed. Because they're not 
parsed, I'm not able to add them to the Sensor Map in the weewx.config file 
(or guessing hasn't worked).

For example here's the output for just the Arcurite5n1:
pi@raspberrypi:~ $ sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/
user/sdr.py --cmd="rtl_433 -M utc -F json -R 40"

out:[u'{"time" : "2020-05-24 01:35:54", "model" : "Acurite-5n1", "subtype" 
: 56, "id" : 2288, "channel" : "B", "sequence_num" : 0, "battery_ok" : 0, 
"wind_avg_km_h" : 0.000, "temperature_F" : 74.700, "humidity" : 30, "mic" : 
"CHECKSUM"}\n', ***repeats twice, removed for readability*** ]
parsed: {'battery.08F0.Acurite5n1PacketV2': 0, 
'noise.08F0.Acurite5n1PacketV2': None, 'temperature.08F0.Acurite5n1PacketV2'
: 74.7, 'msg_type.08F0.Acurite5n1PacketV2': 56, 
'wind_speed.08F0.Acurite5n1PacketV2': 0.0, 'freq.08F0.Acurite5n1PacketV2': 
None, 'dateTime': 1590284154, 'rssi.08F0.Acurite5n1PacketV2': None, 
'model.08F0.Acurite5n1PacketV2': u'Acurite-5n1', 
'protocol.08F0.Acurite5n1PacketV2': None, 'humidity.08F0.Acurite5n1PacketV2'
: 30.0, 'mod.08F0.Acurite5n1PacketV2': None, 
'channel.08F0.Acurite5n1PacketV2': u'B', 'snr.08F0.Acurite5n1PacketV2': None
, 'usUnits': 1, 'sequence_num.08F0.Acurite5n1PacketV2': 0} 
***repeats twice, removed for readability*** 

Here's the example for the output for everything but the Acurite5n1:
pi@raspberrypi:~ $ sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/
user/sdr.py --cmd="rtl_433 -M utc -F json -R -40"

out:[u'{"time" : "2020-05-24 01:41:41", "model" : "Acurite-606TX", "id" : 
206, "battery_ok" : 1, "temperature_C" : 22.200, "mic" : "CHECKSUM"}\n', 
u'{"time" 
: "2020-05-24 01:41:43", "brand" : "OS", "model" : "Oregon-v1", "id" : 7, 
"channel" : 3, "battery_ok" : 1, "temperature_C" : 23.400, "mic" : 
"CHECKSUM"}\n', u'{"time" : "2020-05-24 01:41:43", "brand" : "OS", "model" 
: "Oregon-v1", "id" : 7, "channel" : 3, "battery_ok" : 1, "temperature_C" : 
23.400, "mic" : "CHECKSUM"}\n']
out:[u'{"time" : "2020-05-24 01:41:50", "model" : "LaCrosse-TX141THBv2", 
"id" : 96, "channel" : 0, "battery_ok" : 1, "temperature_C" : 23.800, 
"humidity" : 23, "test" : "No"}\n']
The "parsed" part is never displayed?

Since rtl_433 can "hear" the sensors, I'm guessing it's with the sdr.py, 
but I don't think there's any configuration settings for that?  Any ideas?





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

[weewx-user] Re: Not getting parsed output


This is another case where the rtl_433 version 20.02-26-ge571a05 from Feb 
2020 has changed the reported info from what is expected by sdr.py V0.77.

For the Acurite-606TX, try changing 'IDENTIFIER =' line in the class 
'Acurite606TXPacket(Packet):' section of sdr.py

fromIDENTIFIER = "Acurite 606TX Sensor"
to  IDENTIFIER = "Acurite-606TX"


For the LaCrosse-TX141THBv2, try changing 'IDENTIFIER =' line in the class 
'class LaCrosseTX141THBv2Packet(Packet):' section of sdr.py

fromIDENTIFIER = "LaCrosse TX141TH-Bv2 sensor"
to  IDENTIFIER = "LaCrosse-TX141THBv2"


I'm not sure about the other sensor as the 'Oregon-v1' reported doesn't 
give enough info to pick the sensor model.



Gaz

-- 
You received this message because you are subscribed to the Google 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/78091b7f-83cf-4f6e-bdf1-07a670bb5663%40googlegroups.com.

[weewx-user] Re: Issue with BME280 after upgrade to weewx 4


Slightly off topic, the info on the bme280wx site says it works with python 
2 and not python 3.

I have gone back to python2 so I can use owfs and the next bit to get 
working was to be the bme280w based barometer.

So what version of python are you running with your V4 weewx ? 


Gaz

-- 
You received this message because you are subscribed to the Google 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/ac8b1e18-1a1d-4258-89e8-e32d2e3f1e37%40googlegroups.com.

[weewx-user] Re: Belchertown MQTT update time is chaotic

2020-05-23 Thread Keimpe Bleeker

Thanks Jaap, tried that allready without result. Searching now for the module 
or routine where text 'Laatste update' and time are compiled to the string 
which has to be presented in the webpage. Weird, because that should be 
standard and not influenced by config settings. 

-- 
You received this message because you are subscribed to the Google 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/631f3102-e727-43c6-8c85-00efd99f4c9a%40googlegroups.com.

[weewx-user] Re: Issue with BME280 after upgrade to weewx 4

Hi,

I don't think the BME280 extension is trying to do anything with the 
lightning data per se. If you look at the BME280 extension code you will 
see that it attempts to add temperature, pressure and humidity data to the 
loop packet. The last thing it does is log the packet. What I suspect is 
happening is the lightning data is already in the loop packet when the 
BME280 extension is executed (this is almost certainly the case if you are 
using the SDR driver). The BME280 is unable to obtain any temperature, 
pressure and humidity data but it still logs the packet before it exits 
hence you see a bme280: prefixed log entry with lightning data but no 
BME280 data.

I would be looking at these lines:

if all(must_have in packet for must_have in self.pressure_must_have): 
pressurePA = (bme280data.pressure, 'mbar', 'group_pressure') 
converted = converter.convert(pressurePA) 
for key in self.pressureKeys: 
packet[key] = converted[0] 
if all(must_have in packet for must_have in self.temperature_must_have): 
temperatureC = (bme280data.temperature, 'degree_C', 'group_temperature') 
converted = converter.convert(temperatureC) 
for key in self.temperatureKeys: 
packet[key] = converted[0] 
if all(must_have in packet for must_have in self.humidity_must_have): 
humidityPCT = (bme280data.humidity, 'percent', 'group_percent') 
converted = converter.convert(humidityPCT) 
for key in self.humidityKeys: 
packet[key] = converted[0]

The first log entry indicates the BME280 data is being successfully read but I 
suspect those three conditionals are failing somewhere and hence no BME280 data 
makes it into the packet.

Gary


On Sunday, 24 May 2020 10:15:05 UTC+10, Greg Gowins wrote:
>
>
> I posted this in another thread, but figured it might be better seen if I 
> started a new topic.
>
> For a while I have been running an Acurite 5-n-1 and Acurite Lightning 
> sensor via SDR, and have a BME280 connected to the Pi, with the weewx 
> extension from here to run it:  https://gitlab.com/wjcarpenter/bme280wx.  
>
> I upgraded to Weewx 4  from 3.9.1 last night, and everything seems to be 
> running ok except for weewx processing the data from the BME280.   When I 
> see it process, it appears to be trying to put the BME280 data into fields 
> for the lightning meter:
>
> May 23 10:02:13 weatherstation weewxd: bme280: BME280 data 
> compensated_reading(id=6e6ccd6e-39bd-42bb-8648-d9e1e855719c, 
> timestamp=2020-05-23 10:02:13.100774, temp=27.089 °C, pressure=977.55 hPa, 
> humidity=42.11 % rH)
> May 23 10:02:13 weatherstation weewxd: bme280: {u'distance': 0, 
> u'lastStrikeTime': 1590246128, u'strikes_total': 15, u'strikes': 0, 
> 'dateTime': 1590246128, 'usUnits': 1}
> May 23 10:02:13 weatherstation weewxd: sdr: MainThread: 
> packet={u'distance': 0, u'lastStrikeTime': 1590246128, 'dateTime': 
> 1590246128, 'usUnits': 1, u'strikes_total': 15}
> May 23 10:02:13 weatherstation weewx[593] INFO weewx.restx: MQTT: 
> Published record 2020-05-23 10:02:08 CDT (1590246128)
>
> It appears that somehow the barometric pressure info is making it into the 
> processing engine, as I'm getting barometric pressure successfully 
> calculated and displayed via Belchertown.  But the inTemp in the DB isn't 
> being populated from the BME280 so obviously no data displayed.  Any clue 
> on where to look for troubleshooting this one?  When I upgraded weewx to 4, 
> I used the existing weewx.conf.  I looked through the weewx.conf-4.0.0 to 
> to see if anything jumped out, but nothing did.  Any info is appreciated.  
> Thanks!
>
> Greg
>
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google 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/def94380-140a-49d8-bb4e-cde892e118d9%40googlegroups.com.

[weewx-user] Re: Issue with BME280 after upgrade to weewx 4

2020-05-23 Thread Greg Gowins

Thanks, that did give me something to go on.  In the weewx.conf file, you 
set the 'must_have', to add the value to the packet and here's what I had:

[Bme280wx]
temperature_must_have = ""
humidityKeys = inHumidity
pressureKeys = pressure
pressure_must_have = outTemp
i2c_port = 1
humidity_must_have = ""
i2c_address = 0x77
usUnits = US
temperatureKeys = inTemp

The only thing that is a must have is outTemp, which I have in some other 
log entries:

May 23 21:25:21 weatherstation weewxd: bme280: BME280 data 
compensated_reading(id=9d035f02-3164-4c84-9667-8c4e5e6f6034, 
timestamp=2020-05-23 21:25:21.684878, temp=26.483 °C, pressure=973.67 hPa, 
humidity=42.11 % rH)
May 23 21:25:21 weatherstation weewxd: bme280: {u'lastStrikeTime': 
1590287118, u'outHumidity': 75.0, 'dateTime': 1590287118, u'outTemp': 79.9, 
u'windSpeed': 5.7650962506369074, u'pressure': 28.752361215071698, 
'usUnits': 1}


The pressure key was indeed appearing when the outTemp key was there, so 
that's how it was working.  I then changed the entries for 
temperature_must_have and humidity_must_have to be outTemp as well, and 
when I restarted weewx, it put those entries into the packet.  

May 23 21:32:46 weatherstation weewxd: bme280: BME280 data 
compensated_reading(id=77b48509-c677-4e4e-80e4-22bb7d69aa2d, 
timestamp=2020-05-23 21:32:46.365347, temp=26.697 °C, pressure=973.76 hPa, 
humidity=42.78 % rH)
May 23 21:32:46 weatherstation weewxd: bme280: {u'lastStrikeTime': 
1590287562, u'outHumidity': 76.0, 'dateTime': 1590287562, u'outTemp': 79.7, 
u'windSpeed': 3.193234493643357, u'inHumidity': 42.9308621109, 
u'inTemp': 80.05406480135397, u'pressure': 28.755112653832978, 'usUnits': 1}

Thanks again for the suggestion on where to look. 

tldr, you have to now specify something in *_must_have to get the value 
added to the packet loop.  I guess the "" is now being evaluated in weewx 4 
as a value to match.

Greg

On Saturday, May 23, 2020 at 8:25:48 PM UTC-5, gjr80 wrote:
>
> Hi,
>
> I don't think the BME280 extension is trying to do anything with the 
> lightning data per se. If you look at the BME280 extension code you will 
> see that it attempts to add temperature, pressure and humidity data to the 
> loop packet. The last thing it does is log the packet. What I suspect is 
> happening is the lightning data is already in the loop packet when the 
> BME280 extension is executed (this is almost certainly the case if you are 
> using the SDR driver). The BME280 is unable to obtain any temperature, 
> pressure and humidity data but it still logs the packet before it exits 
> hence you see a bme280: prefixed log entry with lightning data but no 
> BME280 data.
>
> I would be looking at these lines:
>
> if all(must_have in packet for must_have in self.pressure_must_have): 
> pressurePA = (bme280data.pressure, 'mbar', 'group_pressure') 
> converted = converter.convert(pressurePA) 
> for key in self.pressureKeys: 
> packet[key] = converted[0] 
> if all(must_have in packet for must_have in self.temperature_must_have): 
> temperatureC = (bme280data.temperature, 'degree_C', 'group_temperature') 
> converted = converter.convert(temperatureC) 
> for key in self.temperatureKeys: 
> packet[key] = converted[0] 
> if all(must_have in packet for must_have in self.humidity_must_have): 
> humidityPCT = (bme280data.humidity, 'percent', 'group_percent') 
> converted = converter.convert(humidityPCT) 
> for key in self.humidityKeys: 
> packet[key] = converted[0]
>
> The first log entry indicates the BME280 data is being successfully read but 
> I suspect those three conditionals are failing somewhere and hence no BME280 
> data makes it into the packet.
>
> Gary
>
>
> On Sunday, 24 May 2020 10:15:05 UTC+10, Greg Gowins wrote:
>>
>>
>> I posted this in another thread, but figured it might be better seen if I 
>> started a new topic.
>>
>> For a while I have been running an Acurite 5-n-1 and Acurite Lightning 
>> sensor via SDR, and have a BME280 connected to the Pi, with the weewx 
>> extension from here to run it:  https://gitlab.com/wjcarpenter/bme280wx
>> .  
>>
>> I upgraded to Weewx 4  from 3.9.1 last night, and everything seems to be 
>> running ok except for weewx processing the data from the BME280.   When I 
>> see it process, it appears to be trying to put the BME280 data into fields 
>> for the lightning meter:
>>
>> May 23 10:02:13 weatherstation weewxd: bme280: BME280 data 
>> compensated_reading(id=6e6ccd6e-39bd-42bb-8648-d9e1e855719c, 
>> timestamp=2020-05-23 10:02:13.100774, temp=27.089 °C, pressure=977.55 hPa, 
>> humidity=42.11 % rH)
>> May 23 10:02:13 weatherstation weewxd: bme280: {u'distance': 0, 
>> u'lastStrikeTime': 1590246128, u'strikes_total': 15, u'strikes': 0, 
>> 'dateTime': 1590246128, 'usUnits': 1}
>> May 23 10:02:13 weatherstation weewxd: sdr: MainThread: 
>> packet={u'distance': 0, u'lastStrikeTime': 1590246128, 'dateTime': 
>>

Re: [weewx-user] Import from Weathercat

Ville,

Did you get around to trying the wee_import WeatherCat module?

Gary

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

[weewx-user] Re: Monitoring WeeWX with Nagios

2020-05-23 Thread Xant

Update

Matthew Wall nagios plugin works.

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

[weewx-user] Re: sdr.py not parsing Oregon WGR800X output correctly.