Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

Hmm, seems GitHub has decided not to notify me of new issues/posts to 
issues on my own repos. I have noticed a few there now and will work 
through them IDC.

Gary

On Sunday, 26 July 2020 16:59:01 UTC+10, gjr80 wrote:
>
> I don't mind, Github is probably easier for tracking and hopefully keeps 
> one problem per issue unlike posts here which tend to grow many heads. All 
> I ask is that some appropriate details of the problem are included (eg an 
> explanation of the problem and a startup debug log extract - a list of 
> attached sensors/stations would help too) rather than ' does not work'
>
> Gary
>
> On Sunday, 26 July 2020 16:39:19 UTC+10, NanoG5Kite wrote:
>>
>> Is‘t it better to post possible errors on Githup? In addition to 
>> Radiation I‘m also missing rain and current rain rate now.
>> Will open issues on Github now.
>>
>>

-- 
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/009d4653-48ae-4c66-9c86-48a1d0e15322o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Vetti52]

The setting 'radiation': 'solar_radiation', is copied from interceptor.py, 
which is propagated into radiation in weewx. When changing to gw1000 api 
driver, the data are lost. So I went back to the interceptor.py. You can 
see the little gap in the graph during my test of the gw1000 driver:

[image: radiation.jpg]
I have changed the title into German in Weewx.conf 

Generic
radiation = Sonnenstrahlung

So, somewhere the observation type radiation has to be filled with data. In 
interceptor.py, this is done by 'solar_radiation' which comes from the 
ecowitt-customized upload. I would just like to continue with these data.

Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>
> Whilst there definitely is nothing in the API for retrieving what WeeWX 
> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
> Gain' in the WS View app (interestingly there is no gain setting for 
> anything to do with 'light', luminosity, illuminance etc so it could be a 
> mis-labelling/inconsistent labelling of the parameter in the app). If you 
> have been obtaining 'radiation' data via the interceptor driver can you 
> please give me some further details, it may be a case of the GW1000 
> deriving a radiation value suitable for on-line weather services such as WU 
> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
> it may be that there is something else available in the API that is not 
> documented.
>
> Gary
>
> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>
>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>>
>>> When running reconfigure with prompts, there are two changes, that 
>>> occured in my case without asking:
>>> group_pressure turns to inHg, and group_speed and group_speed2 turn to 
>>> mile_per_hour 
>>> and ~2 respectively.You better diff old and new version before 
>>> restarting.
>>>
>>
>> This almost certainly is an issue with wee_config and your config; the 
>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>> vague recollection that there was a previous issue that was raised (and 
>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>> will make a note to look into this.
>>  
>>
>>> In addition, 'radiation': 'solar_radiation', is missing in 
>>> default_field_map 
>>> in gw1000.py. 
>>>
>>
>> This is intentional. Unfortunately the GW1000 API has no ability to 
>> obtain what in WeeWX parlance we know as field radiation (solar 
>> insolation). The API can return what the API terms 'light' or luminosity in 
>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>> square metre. Some folks derive field radiation from luminosity though I 
>> believe the relationship is somewhat complex. It's not the place for the 
>> GW1000 driver to derive obs such as radiation from other obs, rather 
>> derived observations should be derived by the StdWXCalculate service. 
>> Whilst the StdWXCalculate service does not really lend itself at present 
>> to the addition of user defined derived obs, a user can add simple derived 
>> obs by adding appropriate entries under [StdCalibrate] [[Corrections]] 
>> in weewx.conf, for example:
>>
>> [StdCalibrate]
>> [[Corrections]]
>> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>
>> would create the field new_obs using the (nonsense) formula shown. The 
>> default GW1000 driver mapping passes the light, UV and UV index 
>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>> field UV) so they are available for use in StdCalibrate as required.
>>
>> 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/5c834bb5-bd4a-4a60-9732-14329617a7c1o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

Can you please issue the following two commands(assuming a setyp.py 
install) and post the console output and (WeeWX) log output from each:

$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data

If possible, would also help to know what solar radiation value you are 
seeing at the time the commands were executed. Also, no need to stop the 
interceptor, gw1000 will happily interrogate the GW100 even while the 
GW1000 sends to the interceptor. Note you may have to change the python 
command to python2 or python3 if WeeWX is set to run under a different 
python version to the default on your system.

Gary

On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>
> The setting 'radiation': 'solar_radiation', is copied from 
> interceptor.py, which is propagated into radiation in weewx. When changing 
> to gw1000 api driver, the data are lost. So I went back to the 
> interceptor.py. You can see the little gap in the graph during my test of 
> the gw1000 driver:
>
> [image: radiation.jpg]
> I have changed the title into German in Weewx.conf 
>
> Generic
> radiation = Sonnenstrahlung
>
> So, somewhere the observation type radiation has to be filled with data. 
> In interceptor.py, this is done by 'solar_radiation' which comes from the 
> ecowitt-customized upload. I would just like to continue with these data.
>
> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>
>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>> Gain' in the WS View app (interestingly there is no gain setting for 
>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>> have been obtaining 'radiation' data via the interceptor driver can you 
>> please give me some further details, it may be a case of the GW1000 
>> deriving a radiation value suitable for on-line weather services such as WU 
>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>> it may be that there is something else available in the API that is not 
>> documented.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>>
>>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:

 When running reconfigure with prompts, there are two changes, that 
 occured in my case without asking:
 group_pressure turns to inHg, and group_speed and group_speed2 turn to 
 mile_per_hour 
 and ~2 respectively.You better diff old and new version before 
 restarting.

>>>
>>> This almost certainly is an issue with wee_config and your config; the 
>>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>>> vague recollection that there was a previous issue that was raised (and 
>>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>>> will make a note to look into this.
>>>  
>>>
 In addition, 'radiation': 'solar_radiation', is missing in 
 default_field_map 
 in gw1000.py. 

>>>
>>> This is intentional. Unfortunately the GW1000 API has no ability to 
>>> obtain what in WeeWX parlance we know as field radiation (solar 
>>> insolation). The API can return what the API terms 'light' or luminosity in 
>>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>>> square metre. Some folks derive field radiation from luminosity though 
>>> I believe the relationship is somewhat complex. It's not the place for the 
>>> GW1000 driver to derive obs such as radiation from other obs, rather 
>>> derived observations should be derived by the StdWXCalculate service. 
>>> Whilst the StdWXCalculate service does not really lend itself at 
>>> present to the addition of user defined derived obs, a user can add simple 
>>> derived obs by adding appropriate entries under [StdCalibrate] 
>>> [[Corrections]] in weewx.conf, for example:
>>>
>>> [StdCalibrate]
>>> [[Corrections]]
>>> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>>
>>> would create the field new_obs using the (nonsense) formula shown. The 
>>> default GW1000 driver mapping passes the light, UV and UV index 
>>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>>> field UV) so they are available for use in StdCalibrate as required.
>>>
>>> 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/c9e4338c-492c-41e4-a81a-57599a6c22eao%40googlegroups.com.

Re: [weewx-user] StdWXCalculate: beaufort = prefer_hardware

[Vetti52]

Well, there is still low wind activity, but currently at least 5 km/h. And 
$current.beaufort 
shows 0 bft. $current_beaufort shows 1 bft, as it should. What is going on 
here? Maybe things change, when moving to gw1000 api driver?

 

> Well, I had to wait for some wind first. Now, after sunset, wind seems to 
> be growing. And this is the latest archive record:
>
> REC:2020-07-23 20:50:00 CEST (1595530200) altimeter: 
> 29.94844953418796, appTemp: 64.63492618774067, barometer: 
> 29.8973336, beaufort: 0., cloudbase: 
> 2464.8536620841987, dateTime: 1595530200, dewpoint: 53.68325395886734, ET: 
> 0.000133188221454822, extraTemp1: 133.6604, heatindex: 64.06, 
> humidex: 68.17774431413599, inDewpoint: 61.099461593234274, inHumidity: 
> 75.77, inTemp: 69.08, interval: 5.0, maxSolarRad: 
> 10.611708312518399, outHumidity: 69.0, outTemp: 64.06, 
> pressure: 29.832333, radiation: 15.478889, rain: 0.0, 
> rainEvent: 0.0, rainRate: 0.0, txBatteryStatus: 0.0, usUnits: 1, UV: 0.0, 
> windchill: 64.06, windDir: 171.3974954238297, windGust: 4.92, 
> windGustDir: 202.0, windrun: 0.08481481481481483, windSpeed: 
> 1.018
>
> At least, there is a value for beaufort. But it is still displayed as 0 
> bft in the skin. To be sure, I will have to wait for more wind, until 
> tomorrow.
>
> kind of curious
> Peter
>
> Am Donnerstag, 23. Juli 2020 15:20:06 UTC+2 schrieb gjr80:
>>
>> If you have beaufort in the loop packets then you should end up with 
>> beaufort in archive records. Does it work now? If not $current.x 
>> tags come from the archive record hence the suggestion to run WeeWX 
>> directly for at least a full archive period to confirm that beaufort is 
>> appearing in archive records.
>>
>> Gary
>>
>> On Thursday, 23 July 2020 22:38:14 UTC+10, Vetti52 wrote:
>>>
>>> Hi, Gary!
>>> Thanks for the hints. In deed, there is a value for beaufort in the loop:
>>> LOOP:   2020-07-23 14:16:36 CEST (1595506596) altimeter: 
>>> 30.065488730750573, appTemp: 69.20122805363343, barometer: 30.014, 
>>> beaufort: 1, cloudbase: 3824.7354273385445, dateTime: 1595506596, dewpoint: 
>>> 52.73310752508154, heatindex: 69.1, humidex: 72.72248011924633, inDewpoint: 
>>> 54.980122811806766, inHumidity: 64.0, inTemp: 67.6, maxSolarRad: 
>>> 820.4582989978796, outHumidity: 56.0, outTemp: 69.1, pressure: 29.949, 
>>> radiation: 604.7, rain: None, rainEvent: 0.0, rainRate: 0.0, 
>>> txBatteryStatus: 0.0, usUnits: 1, UV: 5.0, windchill: 69.1, windDir: 240.0, 
>>> windGust: 3.36, windSpeed: 1.34
>>>
>>> I did not wait for the REC: record.
>>> So then I should have a look into the skin/skin config. However, I use 
>>> the seasons skin with some translations of the descriptions into German and 
>>> just added the value, as Tom posted above. I put it into current.inc here
>>>   
>>>   
>>> 
>>>   
>>> $obs.label.outTemp
>>> $current.outTemp
>>>   
>>>   
>>> $obs.label.heatindex
>>> $current.heatindex
>>>   
>>>   
>>> $obs.label.windchill
>>> $current.windchill
>>>   
>>>   
>>> $obs.label.dewpoint
>>> $current.dewpoint
>>>   
>>>   
>>> $obs.label.outHumidity
>>> $current.outHumidity
>>>   
>>>   
>>> $obs.label.barometer
>>> $current.barometer (Trend: 
>>> $trend.barometer.formatted)
>>>   
>>>   
>>> $obs.label.wind
>>> $current.windSpeed ($current.beaufort bft) 
>>> $current.windDir.ordinal_compass 
>>> ($current.windDir)$word_current_beaufortBöen 
>>> $current_gust_beaufort
>>>   
>>>
>>>
>>> gjr80 schrieb am Mittwoch, 22. Juli 2020 um 04:54:16 UTC+2:
>>>
 Hi,

 If you have beaufort = prefer_hardware under [StdWXCalculate] then you 
 should be seeing field beaufort in loop packets and archive records 
 provided you have field windSpeed in the same packet/record. I would 
 go back to basics as far as you can and run WeeeWX directly 
  for at least 
 an archive interval (you want to see at least one archive record) and 
 observe the loop packets (lines starting with LOOP:) and archive records 
 (lines starting with REC:) on the console. Do they have a field 
 windSpeed and what is its value, do they have a field beaufort and 
 what is its value? If you have windSpeed and no beaufort or have 
 windSpeed and have an incorrect beaufort value then something is wrong 
 and we need to dig deeper. If the loop packets/archive records are correct 
 then the issue is downstream in the skin/skin config.

 Gary

 On Tuesday, 21 July 2020 at 20:55:37 UTC+10 Vetti52 wrote:

> Hi, Tom!
>
> As there was almost no wind last week, I just tried to activate 
> $current.beaufort. I decided to show both values, such as 
> $curre

Re: [weewx-user] Re: New GW1000 Driver available for testing

['NanoG5Kite' via weewx-user]

Several samples posted on Github seems to be e.g. uv: 9.1 x 10 = 
91,9w/m²

Matthias

Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>
> Can you please issue the following two commands(assuming a setyp.py 
> install) and post the console output and (WeeWX) log output from each:
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>
> If possible, would also help to know what solar radiation value you are 
> seeing at the time the commands were executed. Also, no need to stop the 
> interceptor, gw1000 will happily interrogate the GW100 even while the 
> GW1000 sends to the interceptor. Note you may have to change the python 
> command to python2 or python3 if WeeWX is set to run under a different 
> python version to the default on your system.
>
> Gary
>
> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>
>> The setting 'radiation': 'solar_radiation', is copied from 
>> interceptor.py, which is propagated into radiation in weewx. When changing 
>> to gw1000 api driver, the data are lost. So I went back to the 
>> interceptor.py. You can see the little gap in the graph during my test of 
>> the gw1000 driver:
>>
>> [image: radiation.jpg]
>> I have changed the title into German in Weewx.conf 
>>
>> Generic
>> radiation = Sonnenstrahlung
>>
>> So, somewhere the observation type radiation has to be filled with data. 
>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>> the ecowitt-customized upload. I would just like to continue with these 
>> data.
>>
>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>>
>>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>>> Gain' in the WS View app (interestingly there is no gain setting for 
>>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>>> have been obtaining 'radiation' data via the interceptor driver can you 
>>> please give me some further details, it may be a case of the GW1000 
>>> deriving a radiation value suitable for on-line weather services such as WU 
>>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>>> it may be that there is something else available in the API that is not 
>>> documented.
>>>
>>> Gary
>>>
>>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:

 On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>
> When running reconfigure with prompts, there are two changes, that 
> occured in my case without asking:
> group_pressure turns to inHg, and group_speed and group_speed2 turn 
> to mile_per_hour and ~2 respectively.You better diff old and new 
> version before restarting.
>

 This almost certainly is an issue with wee_config and your config; the 
 GW1000 driver has no ability to change WeeWX units/unit system. I do have 
 a 
 vague recollection that there was a previous issue that was raised (and 
 fixed) regarding unexpected unit changes (it may have been on upgrade). I 
 will make a note to look into this.
  

> In addition, 'radiation': 'solar_radiation', is missing in 
> default_field_map 
> in gw1000.py. 
>

 This is intentional. Unfortunately the GW1000 API has no ability to 
 obtain what in WeeWX parlance we know as field radiation (solar 
 insolation). The API can return what the API terms 'light' or luminosity 
 in 
 Lux as well as UV index and what the API terms 'UV' in microWatts per 
 square metre. Some folks derive field radiation from luminosity though 
 I believe the relationship is somewhat complex. It's not the place for the 
 GW1000 driver to derive obs such as radiation from other obs, rather 
 derived observations should be derived by the StdWXCalculate service. 
 Whilst the StdWXCalculate service does not really lend itself at 
 present to the addition of user defined derived obs, a user can add simple 
 derived obs by adding appropriate entries under [StdCalibrate] 
 [[Corrections]] in weewx.conf, for example:

 [StdCalibrate]
 [[Corrections]]
 new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)

 would create the field new_obs using the (nonsense) formula shown. The 
 default GW1000 driver mapping passes the light, UV and UV index 
 observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
 field UV) so they are available for use in StdCalibrate as required.

 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...@googlegroup

[weewx-user] Belchertown Question about "yAxis_tickinterval"

[Geni 0815]

I have Belchertown Skin Version: 1.2rc2
"YAxis_tickinterval" doesn't work for me.

 [[chart4]]
 title = air pressure
 type = spline
 [[[barometer]]]
 yAxis_tickinterval = 2
 color = "# BECC00"

  still produces the following graphic:

[image: belch06.jpg] 

I expect this

[image: belch07.jpg]



-- 
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/d2356b6f-5bd4-4f13-9fe6-a9ce708a9d10o%40googlegroups.com.

Re: [weewx-user] Re: Bad Data after Maintenance

[Vetti52]

This thread is a very practical recipe for deleting unwanted data. I could 
reproduce it step by step, except, that the data was shown in 
archive_day_rain. Thanks a lot!

One thing, I had to consider, was, that after rebuilding, the wrong data in 
the archive_day_rain were shown again. I found, that the data existed in 
the archive filed rain also, which were obviously written back to the 
archive_day_rain table. As I am not familiar with SQL, I found with 
sqliteadmin.exe a nice graphical explorer and editor to proceed. 
So I just replaced the entries with 0 in both data sets and wrote it back 
to its original site. I hope, this is ok like that. At least, it looks nice 
now on the weewx web site.
Well, as I did this in a runnig system, all of it had to be completed 
within 5 minutes.

Peter

Am Mittwoch, 8. Juli 2020 10:28:17 UTC+2 schrieb gjr80:
>
> Just use wee_database to rebuild the daily summaries for that day only 
> (use the —rebuild-daily and —date command line options). 
>
> 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/e80239e4-4dd3-4473-88ac-1aa0eb5a9075o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Vetti52]

That's the output:
root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 -m 
user.gw1000 --debug=3 --sensors
Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

Sensor Status
WH65   sensor ID: f9  signal: 0  battery: 4
WS68   sensor is registering...
WS80   sensor is registering...
WH40   sensor is registering...
WH32   sensor is registering...
WH31 ch1   sensor is registering...
WH31 ch2   sensor is registering...
WH31 ch3   sensor is registering...
WH31 ch4   sensor is registering...
WH31 ch5   sensor is registering...
WH31 ch6   sensor is registering...
WH31 ch7   sensor is registering...
WH31 ch8   sensor is registering...
WH51 ch1   sensor is registering...
WH51 ch2   sensor is registering...
WH51 ch3   sensor is registering...
WH51 ch4   sensor is registering...
WH51 ch5   sensor is registering...
WH51 ch6   sensor is registering...
WH51 ch7   sensor is registering...
WH51 ch8   sensor is registering...
WH41 ch1   sensor is registering...
WH41 ch2   sensor is registering...
WH41 ch3   sensor is registering...
WH41 ch4   sensor is registering...
WH57   sensor is registering...
WH55 ch1   sensor is registering...
WH55 ch2   sensor is registering...
WH55 ch3   sensor is registering...
WH55 ch4   sensor is registering...

root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 -m 
user.gw1000 --debug=3 --live-data
Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

GW1000 live sensor data: absbarometer: 1005.9, datetime: 1595765605, 
daymaxwind: 8.4, gustspeed: 3.0, inhumid: 76, intemp: 20.7, light: 117722.0, 
outhumid: 82, outtemp: 19.8, rainday: 10.2, rainevent: 10.2, rainmonth: 83.9
, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, relbarometer: 1008.1, uv: 
367.5, uvi: 9, winddir: 27.8, windspeed: 1.8




Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>
> Can you please issue the following two commands(assuming a setyp.py 
> install) and post the console output and (WeeWX) log output from each:
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>
> If possible, would also help to know what solar radiation value you are 
> seeing at the time the commands were executed. Also, no need to stop the 
> interceptor, gw1000 will happily interrogate the GW100 even while the 
> GW1000 sends to the interceptor. Note you may have to change the python 
> command to python2 or python3 if WeeWX is set to run under a different 
> python version to the default on your system.
>
> Gary
>
> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>
>> The setting 'radiation': 'solar_radiation', is copied from 
>> interceptor.py, which is propagated into radiation in weewx. When changing 
>> to gw1000 api driver, the data are lost. So I went back to the 
>> interceptor.py. You can see the little gap in the graph during my test of 
>> the gw1000 driver:
>>
>> [image: radiation.jpg]
>> I have changed the title into German in Weewx.conf 
>>
>> Generic
>> radiation = Sonnenstrahlung
>>
>> So, somewhere the observation type radiation has to be filled with data. 
>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>> the ecowitt-customized upload. I would just like to continue with these 
>> data.
>>
>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>>
>>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>>> Gain' in the WS View app (interestingly there is no gain setting for 
>>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>>> have been obtaining 'radiation' data via the interceptor driver can you 
>>> please give me some further details, it may be a case of the GW1000 
>>> deriving a radiation value suitable for on-line weather services such as WU 
>>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>>> it may be that there is something else available in the API that is not 
>>> documented.
>>>
>>> Gary
>>>
>>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:

 On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>
> When running reconfigure with prompts, there are two changes, that 
> occured in my case without asking:
> group_pressure turns to inHg, and group_speed and group_speed2 turn 
> to mile_per_hour and ~2 respectively.You better diff old and new 
> version before restarting.
>

 This almost certainly is an issue with wee_config and your config; the 
 GW1000 driver has no ability to change WeeWX units/unit system. I do have 
 a 
 vague recollection that there was a previous issue that was raised (and 
 fixed)

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Vetti52]

Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

GW1000 live sensor data: absbarometer: 1006.2, datetime: 1595765980, 
daymaxwind: 8.4, gustspeed: 0.7, inhumid: 76, intemp: 20.7, light: 24226.0, 
outhumid: 82, outtemp: 19.7, rainday: 10.2, rainevent: 10.2, rainmonth: 83.9
, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, relbarometer: 1008.4, uv: 
49.1, uvi: 1, winddir: 27.4, windspeed: 0.3


solar radiation acutally is
853 W/m²

Sorry, I forgot

Peter

Am Sonntag, 26. Juli 2020 10:18:52 UTC+2 schrieb NanoG5Kite:
>
> Several samples posted on Github seems to be e.g. uv: 9.1 x 10 = 
> 91,9w/m²
>
> Matthias
>
> Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>>
>> Can you please issue the following two commands(assuming a setyp.py 
>> install) and post the console output and (WeeWX) log output from each:
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>>
>> If possible, would also help to know what solar radiation value you are 
>> seeing at the time the commands were executed. Also, no need to stop the 
>> interceptor, gw1000 will happily interrogate the GW100 even while the 
>> GW1000 sends to the interceptor. Note you may have to change the python 
>> command to python2 or python3 if WeeWX is set to run under a different 
>> python version to the default on your system.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>>
>>> The setting 'radiation': 'solar_radiation', is copied from 
>>> interceptor.py, which is propagated into radiation in weewx. When changing 
>>> to gw1000 api driver, the data are lost. So I went back to the 
>>> interceptor.py. You can see the little gap in the graph during my test of 
>>> the gw1000 driver:
>>>
>>> [image: radiation.jpg]
>>> I have changed the title into German in Weewx.conf 
>>>
>>> Generic
>>> radiation = Sonnenstrahlung
>>>
>>> So, somewhere the observation type radiation has to be filled with data. 
>>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>>> the ecowitt-customized upload. I would just like to continue with these 
>>> data.
>>>
>>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:

 Whilst there definitely is nothing in the API for retrieving what WeeWX 
 knows as 'radiation', there is a calibration setting labelled 'SolarRad 
 Gain' in the WS View app (interestingly there is no gain setting for 
 anything to do with 'light', luminosity, illuminance etc so it could be a 
 mis-labelling/inconsistent labelling of the parameter in the app). If you 
 have been obtaining 'radiation' data via the interceptor driver can you 
 please give me some further details, it may be a case of the GW1000 
 deriving a radiation value suitable for on-line weather services such as 
 WU 
 and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
 it may be that there is something else available in the API that is not 
 documented.

 Gary

 On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>
> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>
>> When running reconfigure with prompts, there are two changes, that 
>> occured in my case without asking:
>> group_pressure turns to inHg, and group_speed and group_speed2 turn 
>> to mile_per_hour and ~2 respectively.You better diff old and new 
>> version before restarting.
>>
>
> This almost certainly is an issue with wee_config and your config; 
> the GW1000 driver has no ability to change WeeWX units/unit system. I do 
> have a vague recollection that there was a previous issue that was raised 
> (and fixed) regarding unexpected unit changes (it may have been on 
> upgrade). I will make a note to look into this.
>  
>
>> In addition, 'radiation': 'solar_radiation', is missing in 
>> default_field_map 
>> in gw1000.py. 
>>
>
> This is intentional. Unfortunately the GW1000 API has no ability to 
> obtain what in WeeWX parlance we know as field radiation (solar 
> insolation). The API can return what the API terms 'light' or luminosity 
> in 
> Lux as well as UV index and what the API terms 'UV' in microWatts per 
> square metre. Some folks derive field radiation from luminosity 
> though I believe the relationship is somewhat complex. It's not the place 
> for the GW1000 driver to derive obs such as radiation from other obs, 
> rather derived observations should be derived by the StdWXCalculate 
> service. Whilst the StdWXCalculate service does not really lend 
> itself at present to the addition of user defined derived obs, a user can 
> add simple derived obs by adding appropriate entries under [StdCalibrate] 
> [[Corrections]] in weewx.conf, for example:
>>>

Re: [weewx-user] Re: New GW1000 Driver available for testing

['NanoG5Kite' via weewx-user]

It´s in process on Github now... better to post there.

https://github.com/gjr80/weewx-gw1000/issues/6

Am Sonntag, 26. Juli 2020 14:15:18 UTC+2 schrieb Vetti52:
>
> That's the output:
> root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 
> -m user.gw1000 --debug=3 --sensors
> Using configuration file /etc/weewx/weewx.conf
>
> Interrogating GW1000 at 192.168.100.150:45000
>
> Sensor Status
> WH65   sensor ID: f9  signal: 0  battery: 4
> WS68   sensor is registering...
> WS80   sensor is registering...
> WH40   sensor is registering...
> WH32   sensor is registering...
> WH31 ch1   sensor is registering...
> WH31 ch2   sensor is registering...
> WH31 ch3   sensor is registering...
> WH31 ch4   sensor is registering...
> WH31 ch5   sensor is registering...
> WH31 ch6   sensor is registering...
> WH31 ch7   sensor is registering...
> WH31 ch8   sensor is registering...
> WH51 ch1   sensor is registering...
> WH51 ch2   sensor is registering...
> WH51 ch3   sensor is registering...
> WH51 ch4   sensor is registering...
> WH51 ch5   sensor is registering...
> WH51 ch6   sensor is registering...
> WH51 ch7   sensor is registering...
> WH51 ch8   sensor is registering...
> WH41 ch1   sensor is registering...
> WH41 ch2   sensor is registering...
> WH41 ch3   sensor is registering...
> WH41 ch4   sensor is registering...
> WH57   sensor is registering...
> WH55 ch1   sensor is registering...
> WH55 ch2   sensor is registering...
> WH55 ch3   sensor is registering...
> WH55 ch4   sensor is registering...
>
> root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 
> -m user.gw1000 --debug=3 --live-data
> Using configuration file /etc/weewx/weewx.conf
>
> Interrogating GW1000 at 192.168.100.150:45000
>
> GW1000 live sensor data: absbarometer: 1005.9, datetime: 1595765605, 
> daymaxwind: 8.4, gustspeed: 3.0, inhumid: 76, intemp: 20.7, light: 
> 117722.0, outhumid: 82, outtemp: 19.8, rainday: 10.2, rainevent: 10.2, 
> rainmonth: 83.9, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, 
> relbarometer: 1008.1, uv: 367.5, uvi: 9, winddir: 27.8, windspeed: 1.8
>
>
>
>
> Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>>
>> Can you please issue the following two commands(assuming a setyp.py 
>> install) and post the console output and (WeeWX) log output from each:
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>>
>> If possible, would also help to know what solar radiation value you are 
>> seeing at the time the commands were executed. Also, no need to stop the 
>> interceptor, gw1000 will happily interrogate the GW100 even while the 
>> GW1000 sends to the interceptor. Note you may have to change the python 
>> command to python2 or python3 if WeeWX is set to run under a different 
>> python version to the default on your system.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>>
>>> The setting 'radiation': 'solar_radiation', is copied from 
>>> interceptor.py, which is propagated into radiation in weewx. When changing 
>>> to gw1000 api driver, the data are lost. So I went back to the 
>>> interceptor.py. You can see the little gap in the graph during my test of 
>>> the gw1000 driver:
>>>
>>> [image: radiation.jpg]
>>> I have changed the title into German in Weewx.conf 
>>>
>>> Generic
>>> radiation = Sonnenstrahlung
>>>
>>> So, somewhere the observation type radiation has to be filled with data. 
>>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>>> the ecowitt-customized upload. I would just like to continue with these 
>>> data.
>>>
>>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:

 Whilst there definitely is nothing in the API for retrieving what WeeWX 
 knows as 'radiation', there is a calibration setting labelled 'SolarRad 
 Gain' in the WS View app (interestingly there is no gain setting for 
 anything to do with 'light', luminosity, illuminance etc so it could be a 
 mis-labelling/inconsistent labelling of the parameter in the app). If you 
 have been obtaining 'radiation' data via the interceptor driver can you 
 please give me some further details, it may be a case of the GW1000 
 deriving a radiation value suitable for on-line weather services such as 
 WU 
 and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
 it may be that there is something else available in the API that is not 
 documented.

 Gary

 On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>
> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>
>> When running reconfigure with prompts, there are two changes, that 
>> occured in my case without asking:
>> group_pressure turns to inHg, and group_speed and group_speed2 turn 
>> to mile_per_hour and ~2 respective

Re: [weewx-user] Belchertown Question about "yAxis_tickinterval"

[Didier Decoodt]

Hi

I think you have a mistake in the name, this is "yAxis_tickInterval"

  [[[barometer]]]
yAxis_label = ( mbar )
decimals = 0
color = "#e4d354"
yAxis_tickInterval = 2
yAxis_softMin = 1000
yAxis_softMax = 1030

Didier

Le dim. 26 juil. 2020 à 12:41, Geni 0815  a écrit :

> I have Belchertown Skin Version: 1.2rc2
> "YAxis_tickinterval" doesn't work for me.
>
>  [[chart4]]
>  title = air pressure
>  type = spline
>  [[[barometer]]]
>  yAxis_tickinterval = 2
>  color = "# BECC00"
>
>   still produces the following graphic:
>
> [image: belch06.jpg]
>
> I expect this
>
> [image: belch07.jpg]
>
>
>
> --
> 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/d2356b6f-5bd4-4f13-9fe6-a9ce708a9d10o%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/CAAvt3%3DTjDsUpEeEe6E04NNJLCcFnARk6pNr-POvioSvwcvziSw%40mail.gmail.com.

Re: [weewx-user] Belchertown Question about "yAxis_tickinterval"

[geni08...@gmail.com]

Hi Didier,
the lowercase "I" was like you noticed, Small cause big effect, thank you 
very much
Geni

didier@gmail.com schrieb am Sonntag, 26. Juli 2020 um 15:17:54 UTC+2:

> Hi
>
> I think you have a mistake in the name, this is "yAxis_tickInterval"
>
>   [[[barometer]]]
> yAxis_label = ( mbar )
> decimals = 0
> color = "#e4d354"
> yAxis_tickInterval = 2
> yAxis_softMin = 1000
> yAxis_softMax = 1030
>
> Didier
>
> Le dim. 26 juil. 2020 à 12:41, Geni 0815  a écrit :
>
>> I have Belchertown Skin Version: 1.2rc2
>> "YAxis_tickinterval" doesn't work for me.
>>
>>  [[chart4]]
>>  title = air pressure
>>  type = spline
>>  [[[barometer]]]
>>  yAxis_tickinterval = 2
>>  color = "# BECC00"
>>
>>   still produces the following graphic:
>>
>> [image: belch06.jpg]
>>
>> I expect this
>>
>> [image: belch07.jpg]
>>
>>
>>
>> -- 
>> 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/d2356b6f-5bd4-4f13-9fe6-a9ce708a9d10o%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/a7420a49-d460-489e-8a09-bfc5af019a4cn%40googlegroups.com.

[weewx-user] StdCalibrate from different sources

[Norbert F]

Hello
I am using weewx feeded from two different mqtt sources (mqtt-subscribe), is 
there a way to use StdCalibrate to calulate from different sources.

Example:
source1 feeds: outTemp, outHumidity...
source2 feeds: barometer, windSpeed, rain..

If i try

[StdCalibrate]
[[Corrections]]
outTemp = outTemp /  outHumidity

this is working, but when i use values from different sources like

[StdCalibrate]
[[Corrections]]
outTemp = outTemp /  barometer

nothing is calculated. ( This formulas are only silly examples )

Thanks for help.

-- 
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/7e07e58c-b5bf-47e8-a798-924d8062a177o%40googlegroups.com.

[weewx-user] DIY weather station + Weewx on Raspberry Pi - how to join them?

[Norbert F]

You can use mqtt.
Look at https://github.com/bellrichm/WeeWX-MQTTSubscribe

-- 
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/e7f6d9f2-41be-49af-9c12-bec7c2ab1299o%40googlegroups.com.

Re: [weewx-user] StdCalibrate from different sources

[Tom Keffer]

I think you've fallen into a corner case.

All variables referenced in a [[Corrections]] must be in the same packet or
record. So, if the two MQTT feeds are creating separate LOOP packets, then
any correction won't have all the variables it needs and will fail.

However, archive records are different. By then, the two streams should
have been combined into a single archive record (by the accumulators).
However, the engine figures that the corrections were already applied in
the LOOP packets, so it does not apply them again. So, the correction is
never tried.

To do what you want to do you'll have to write a service that looks for new
archive record events and applies the calculation there. It would be quite
simple. Using your silly example, it would look something like this (NOT
TESTED):

# File user/mqttfix.py:
import weewx
from weewx.engine import StdService

class MQTTFix(StdService):
def __init__(self, engine, config_dict):
super(MQTTFix, self).__init__(engine, config_dict)

self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)

def new_archive_record(self, event):
# The record may not have 'outTemp' and 'barometer', so be prepared
for a key error exception
try:
event.record['outTemp'] = event.record['outTemp'] /
event.record['barometer']
except KeyError:
pass

Then you add user.mqttfix.MQTTFix to the end of process_services in
weewx.conf

-tk

On Sun, Jul 26, 2020 at 8:23 AM Norbert F  wrote:

> Hello
> I am using weewx feeded from two different mqtt sources (mqtt-subscribe),
> is there a way to use StdCalibrate to calulate from different sources.
>
> Example:
> source1 feeds: outTemp, outHumidity...
> source2 feeds: barometer, windSpeed, rain..
>
> If i try
>
> [StdCalibrate]
> [[Corrections]]
> outTemp = outTemp /  outHumidity
>
> this is working, but when i use values from different sources like
>
> [StdCalibrate]
> [[Corrections]]
> outTemp = outTemp /  barometer
>
> nothing is calculated. ( This formulas are only silly examples )
>
> Thanks for help.
>
> --
> 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/7e07e58c-b5bf-47e8-a798-924d8062a177o%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/CAPq0zEBD%2Bqv3iHL6ox9DXRrCrdCY52dqZVdvDsYomRNDekxZ7g%40mail.gmail.com.

[weewx-user] Extra temperature sensors Belchertown

[Norbert F]

Look for station_observations in skin.conf ?

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

[weewx-user] Belchertown MQTT live stats problem

[Scott Grayban]

Anyone?

-- 
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/97b447a0-fc53-4aae-a291-b71fb85064b1o%40googlegroups.com.

[weewx-user] Belchertown MQTT live stats problem

[Paul Anderson]

Fist thing is check if your MQTT server is running, and that websockets is 
enabled.
If your running Mosquito on say Debian check etc/mosquitto/mosquitto.conf
Verify websockets is enabled on port 9001.
One possibility as to why it suddenly stopped working, I believe Debian had a 
recent update to MQTT server, if you updated it should have prompted you to 
keep your current configuration file or replace it with the new release 
version. If you didn't choose to keep your config, by default web sockets is 
disabled. Obviously if it's disabled just edit the config file, enable it and 
restart MQTT.

-- 
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/8feb154b-4e3a-4c8e-89c0-d5a5cb03c5d2o%40googlegroups.com.

[weewx-user] Re: Belchertown MQTT live stats problem

[Scott Grayban]

This is what I have in /myconfig.conf 

persistence false
> allow_anonymous true
> password_file /etc/mosquitto/passwd
> acl_file /etc/mosquitto/acl
> listener 1883 0.0.0.0
> protocol mqtt
> # websockets
> listener 9001 0.0.0.0
> protocol websockets


netstats shows

# netstat -ntap |grep 9001
> tcp0  0 0.0.0.0:90010.0.0.0:*  
>  LISTEN  6928/mosquitto


wscat shows

# wscat -c "ws://63.230.134.165:9001"
> connected (press CTRL+C to quit)

 
So I am assuming its working ?

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

[weewx-user] Re: Belchertown MQTT live stats problem

[Scott Grayban]

Also I can subscribe to the weather/weewx/loop topic via MQTTBox app and I 
get responses. I wonder if something broke in jquery...

-- 
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/1a363c35-9ba8-4a76-8bfb-4d8e7409f5f5o%40googlegroups.com.

[weewx-user] Re: Belchertown MQTT live stats problem

[Paul Anderson]

Sure seems like it's running and WebSockets is enabled for 9001. Must be some 
other issue. I actually don't even run belchertown, however I do run mosquito 
MQTT, and I recall quite a while ago being bitten by just the issue I mentioned 
where I upgraded and forgot to keep my existing config. Sorry I couldn't be of 
more help.

-- 
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/33826bf6-943e-49f4-879a-e66bc46329afo%40googlegroups.com.

[weewx-user] Re: Belchertown MQTT live stats problem

[Scott Grayban]

No worries... just very strange the live stats dont work anymore even 
though it works

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

Re: [weewx-user] Re: MQTT weather data as input to weewx

[Tomasz Lewicki]

Hi Ørjan.

Did you get your config to work? If yes, where was the problem?


W dniu niedziela, 2 września 2018 23:41:39 UTC+2 użytkownik Ørjan Hofstad 
napisał:
>
> Here is what I have tried. But cant get it to work. I was just testing 
> over mqtt client. Maybe Im sending the data wrong or something.
>
>
> This is the setting I have set in /etc/weewx/weewx.conf
>
> loop_on_init=true
> station_type = wxMesh
>
> [wxMesh]
> host = 127.0.0.1
> client = Arduino-station
> username = username
> password = password
> topic = weather
> driver = user.wxMesh
> poll_interval = 1
>
> [[label_map]]
> TIME = dateTime
> HUMT = outTemp
> RHUM = outHumidity
> INTE = inTemp
> INHU = inHumidity
> BARP = barometer
> IRRA = radiation
> PHOV = supplyVoltage
> BATV = consBatteryVoltage
> AMBT = extraTemp1
> SYST = extraTemp2
>
> This is the setting I have set in /usr/share/weewx/user/wxMesh.py
>
> where to find the data file
>   self.host = stn_dict.get('host', '127.0.0.1')
>   self.topic = stn_dict.get('topic', 'weather')
>   self.username = stn_dict.get('username', 'username')
>   self.password = stn_dict.get('password', 'password')
>   self.client_id = stn_dict.get('client', 'Arduino-station') # MQTT client 
> id - adjust $
>
>

-- 
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/93819061-9f7e-4432-8549-c2f06db92402o%40googlegroups.com.

[weewx-user] FTP Stopped Working After Updating Station Hardware

[Pat W.]

Hi All,

I've been using weewx for a couple years with an old WMR-918 and all works 
fine, including an FTP upload to my personal web page every five minutes. 
Recently bought a Weatherflow Tempest and installed the WeatherFlowUDP 
extension. Weewx appears to be receiving data from the station properly, 
but the FTP function has stopped working and I can't find any references to 
it in the syslog. I reinstalled weewx from scratch (installed via apt-get 
on Raspberry Pi 4) after the hardware change to no avail. 

I'm a linux novice but can find my way around. This one has me stumped. Any 
help is appreciated. mylog and wee_debug files attached

Pat W.

-- 
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/d5cd1209-4b4c-4165-b857-39f237300f8co%40googlegroups.com.


mylog
Description: Binary data


wee_debug-07-26-2020
Description: Binary data

Re: [weewx-user] FTP Stopped Working After Updating Station Hardware

[Tom Keffer]

I have my suspicions about what's going on here, but first let me ask you
two questions.

1. Is there any evidence that anything is getting stored in the database?
Take a look in your database. This will show the timestamps of the last 10
records that have been stored in the database:

*sqlite3 /var/lib/weewx/weewx.sdb*
sqlite> *select datetime(dateTime,'unixepoch','localtime') from archive
order by dateTime desc limit 10;*

2. Is there any evidence that reports have been generated at all (let alone
FTP'd)?


*ls -l /var/www/html/weewx*

-tk

On Sun, Jul 26, 2020 at 3:24 PM Pat W.  wrote:

> Hi All,
>
> I've been using weewx for a couple years with an old WMR-918 and all works
> fine, including an FTP upload to my personal web page every five minutes.
> Recently bought a Weatherflow Tempest and installed the WeatherFlowUDP
> extension. Weewx appears to be receiving data from the station properly,
> but the FTP function has stopped working and I can't find any references to
> it in the syslog. I reinstalled weewx from scratch (installed via apt-get
> on Raspberry Pi 4) after the hardware change to no avail.
>
> I'm a linux novice but can find my way around. This one has me stumped.
> Any help is appreciated. mylog and wee_debug files attached
>
> Pat W.
>
> --
> 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/d5cd1209-4b4c-4165-b857-39f237300f8co%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/CAPq0zED%3DkQe%3Di%2B7U3p1BW68ogToaN-6Z6zGZP07MrBi%2BXBa0Bw%40mail.gmail.com.

[weewx-user] Bloomsky on Weewx 4.1.1

[stevefnz]

New install on a pi3 with rasp os lite , weewx 4.1.1 python3 all seemed ok 
except these errors and bloomsky.py will not run 

Any ideas ?? 

Jul 26 10:17:00 raspberrypi weewx[4928] CRITICAL main:  File 
"/usr/share/weewx/weewx/engine.py", line 92, in setupStation
Jul 26 10:17:00 raspberrypi weewx[4928] CRITICAL main:  import(driver)
Jul 26 10:17:00 raspberrypi weewx[4913]: Starting weewx weather system: 
weewx.
Jul 26 10:17:00 raspberrypi weewx[4928] CRITICAL main:  File 
"/usr/share/weewx/user/bloomsky.py", line 1003
Jul 26 10:17:00 raspberrypi systemd[1]: Started LSB: weewx weather system.
Jul 26 10:17:00 raspberrypi weewx[4928] CRITICAL main:  print "Using 
configuration file %s" % config_path
Jul 26 10:17:00 raspberrypi weewx[4928] CRITICAL main:  ^
Jul 26 10:17:00 raspberrypi weewx[4928] CRITICAL main:  SyntaxError: 
Missing parentheses in call to 'print'. Did you mean print("Using config 
uration file %s" % config_path)?
Jul 26 10:17:00 raspberrypi weewx[4928] CRITICAL main:  Exiting.
Jul 26 10:17:01 raspberrypi CRON[4953]: (root) CMD ( cd / && run-parts 
--report /etc/cron.hourly)

-- 
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/b8503db2-e9c1-4928-92a2-35c29ece00cdo%40googlegroups.com.

[weewx-user] Bloomsky on Weewx 4.1.1

[gjr80]

Yes, I need to finish porting the Bloomsky driver to WeeWX 4/python3. Give us a 
day to two.

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/00eb6254-14b3-4715-912f-9a7fd07c7272o%40googlegroups.com.

Re: [weewx-user] Re: MQTT weather data as input to weewx

[Norbert F]

Herein is another driver that works Gold for me   
https://github.com/bellrichm/WeeWX-MQTTSubscribe

-- 
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/8ce4cf18-4596-4984-b371-955a3c57b31co%40googlegroups.com.

Re: [weewx-user] Re: MQTT weather data as input to weewx

[Norbert F]

Here is another driver that works good for me   
https://github.com/bellrichm/WeeWX-MQTTSubscribe

-- 
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/5982a9bb-b8d7-47cd-8495-839bebbe85a9o%40googlegroups.com.

[weewx-user] Re: Bloomsky on Weewx 4.1.1

[gjr80]

Refer to my comment on the GitHub issue you raised earlier.

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/154e0163-9864-466c-b661-408f6ef00244o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

I have released v0.1.0b6 on Github 
. A summary of the 
significant changes can be found against the v0.1.0b6 release on Github. It 
has not (fully) addressed the issue of some battery states not making their 
way through to the loop packets, unfortunately that is still a  work in 
progress.

Those that have already installed the driver can download and install 
v0.1.0b6 using the following commands depending on your WeeWX install type:

for setup.py installs:

$ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.py
$ sudo wget -P /home/weewx/bin/user https:
//raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py

for package installs:

$ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/gw1000_orig.
py
$ sudo wget -P /usr/share/weewx/user https:
//raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py

There has been no change to the [GW1000] structure so you can just restart 
WeeWX/run v0.1.0b6 directly without further changes.

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/a88dee6c-8fb5-4a44-91f6-51549374a18eo%40googlegroups.com.

Re: [weewx-user] Re: MQTT weather data as input to weewx

[Ørjan Hofstad]

Hi,
No the plugin does not work. But there is another guy that have made a new 
plugin. Maybe that will work.

https://github.com/bellrichm/WeeWX-MQTTSubscribe

-- 
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/abb6dfb4-9c5b-4185-aa85-aba22d6c1aafo%40googlegroups.com.