date:20201227

Back to topic:
I'm using https://github.com/bellrichm/WeeWX-MQTTSubscribe/ for getting the 
extra readings into weewx. It's configured as a service, so every loop 
interval the MQTT messages in the queue will be integrated into the loop 
package, when I'm correct. When it comes to loop data, depending on the 
loop interval and the MQTT sensors interval, there are loop packages that 
don't contain messages from the ESP/SHT because the queue is empty. This 
leads to a mix of readings.
The other thing is, that the archive value also contains this mix as an 
average of all the values during the archive interval, because ws28xx 
driver doesn't support hardware record generation, I guess.
I probably have to ensure that the MQTT interval is set to a value that at 
least one message is in the queue every loop interval or I could do this 
every archive interval using something like 
this: https://github.com/mKainzbauer/weewx_extensions/blob/master/fronius.py, 
just in a more simple way that only extraHumid1 overwrites outHumidity when 
not None.

michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 19:25:48 UTC+1:

>
> correction: the panel shoulndn't exceed 3.6V...
> michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 19:17:11 
> UTC+1:
>
>> @Peter Quinn, thank you. I'll check the weewx part!
>>
>> Just my 2 off-topic cents: using the breadboard the voltage regulator and 
>> the UART, powered by 5V ist a very inefficient way to run this sensor. The 
>> simplest approach to get more time from the solar/battery combo would be to 
>> use a 3V solar panel (which should exceed a maximum idle voltage of 3.6V) 
>> and directly charge a LiFe battery with it. If you ensure that the ESP 
>> powers off (deep sleep) at the ESP lower limit (datasheet says 2.5V, my 
>> experience says ~2.3V) the LiFe lower discharge limit (2,0V) will probably 
>> never be reached. Even with your LiPo this should be possible this way, but 
>> you can't use all capacity, since you can't charge it over 3.6V, because 
>> this would kill the esp.
>>
>> In brief:
>> - don't use such a breadboard or remove the voltage regulator and the 
>> UARTs supply
>> - connect a LiFe directly to 3V3 and GND
>> - connect a 3V solar panel directly to 3V3 and GND
>> - ensure to power off the ESP when it reaches it's minimum required 
>> voltage (maybe it's never reached), either with a protection circuit 
>> (preferred) or the ESPs internal voltage measurement ability (not 
>> preferred, because ESPs sometime run into a state where they aren't really 
>> running but drawing current from the battery until the battery is flat and 
>> damaged.
>>
>> This will extend your runtime dramatically.
>>
>> Currently I'm running my sensor on a 2500mAh LTO Battery, one sample a 
>> minute with deep sleep in between gives me more than a week runtime. 
>>
>> peterq...@gmail.com schrieb am Sonntag, 27. Dezember 2020 um 18:49:54 
>> UTC+1:
>>
>>> I have a secondary temperature sensor that runs on solar and a battery. 
>>> This time a year in the northern hemisphere there's not enough sunlight to 
>>> charge the battery sufficiently to make it through the night. I handled the 
>>> failover to the main thermometer in my customized driver. Details here: 
>>> https://hackaday.io/project/101680-solar-powered-wifi-temperature-sensor-for-weewx/details
>>>
>>> On Sun, Dec 27, 2020 at 7:53 AM michael.k...@gmx.at  
>>> wrote:
>>>
 The the ESP just reads the SHT35 in a given interval and publishes the 
 reading, nothing else. No calibration necessary, the sensor is really as 
 good as advertised in the data sheet. And only the outHumidity values of 
 the station are off when humidity > 80%rh, other values are pretty much 
 accurate and even outHumidity is very accurate below 80%rh. Since I don't 
 attach too much importance on historical humidity readings, mixing up 
 different source from time to time is no big deal for me. We're talking 
 about >99% availability with the less reliable sensor. But the current 
 dewpoint and windchill are interesting for me, which both require some 
 realistic humidity values.

 "Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it 
 is not the same as hardware record generation nor does ‘prefer_hardware’ 
 have anything to do with corrections. ‘prefer_hardware’ is used with the 
 StdCalculate service, corrections are used with the StdCalibrate service 
 and hardware or software record generation is used with the StdArchive 
 service."

 Thanks for pointing out.

 Greg Troxel schrieb am Sonntag, 27. Dezember 2020 um 15:01:08 UTC+1:

>
> You may also want to think about calibration. Besides absolute 
> calibration there is going to be some offset or other more complicated 
> relationship between your two sensors. Given a "prefer precise if 
> available" this is going to cause some flipping betweeen them. I had a 
> l

Re: [weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

Also, remember under a traditional Davis console/logger/vantage driver 
setup you will see approx 120 loop packets per five minute archive record. 
So seeing an archive record value that is 100 times a loop value is not 
unreasonable for a cumulative field such as ET or rain. The difference here 
is that a traditional Davis console/logger/vantage driver setup you do not 
see loop ET values.

The only way to know if it it working properly is to understand who is 
emitting what and then do the maths to confirm the result one way or 
another.

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/48d8fa17-4102-44c0-b69b-7d1228beaa1en%40googlegroups.com.

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

i forgot to acknowledge the design consideration you raised that by calculating 
value once and storing it in the packet, unlike an xtype it is not 
re-calculated each time it is referenced

> On 28 Dec 2020, at 12:54 pm, Graham Eddy  wrote:
> 
> hmm, the ‘novelty’ i think is having an xtype calculated with values from 
> outside weewx (eg cpu temperature), and the expense of the calculation is not 
> really at issue - though normally they would be light-weight in case they are 
> used often (eg barometer)
> 
> architecturally anything external is supposed to brought into weewx via a 
> service and made available via weewx packet. (the *providing* of an xtype is 
> now positioned as a service, but the xtypes themselves are not.)
> 
> okay, i’ll recast my vitalstats from xtypes_service to data_service and not 
> bypass the packets...
> 
>> On 28 Dec 2020, at 11:40 am, Tom Keffer > > wrote:
>> 
>> That's a novel use of xtypes, but I'm not sure it's always a good idea. In 
>> this case, I think you'd be better off simply adding the type to the LOOP 
>> packet or archive record. 
>> 
>> The intended purpose of xtypes is to calculate derived variables. It's 
>> entirely possible it could be called many times during a reporting cycle, 
>> depending on the template used. Something involving I/O could be very 
>> expensive.
>> 
>> Having said that, xtypes also do database accesses, which can also be very 
>> expensive, so my advice is inconsistent. So, not saying never do it, but 
>> think it through.
> 

-- 
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/929A756F-DAE7-495C-9368-C85D2479E4F7%40gmail.com.

Re: [weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

The json values.txt you provided includes no per-period ET value, only 
cumulative values. So what is calculating that ET value? If the json file 
you posted is a loop ‘packet’ from the wifi logger then does the 
MQTTSubscribe driver calculate ET from successive cumulative ET values? 
StdWXCalculate does not calculate loop based ET so that really only leaves 
the driver.

Then look at the archive record and ask the same question, who is providing 
the ET value? The MQTTSubscribe driver has a genArchiveRecords() method so 
the driver and not StdArchive is responsible for creating and emitting an 
archive record. Does the driver calculate ET or is it received from the 
wifilogger (Davis stations include hourly ET values in the archive record 
at the top of the hour, all other archive records have ET=0, again don’t 
know what the wifilogger does)? If not then in this case StdWXCalculate can 
step in and calculate ET or since ET is appearing in loop packets 
StdArchive could calculate ET by summing the loop packet ET values seen 
during the archive period. I would suggest looking at the archive records 
coming directly out of the driver(note that is different to observing loop 
packets/archive records on the console when running WeeWX directly, running 
WeeWX directly shows packets/records after all services have processed the 
packet/record), if ET is there then you answer lies in the driver. If it is 
not it is StdWXCalculate or StdArchive that is calculating it then we need 
to look at those services.

Gary

On Monday, 28 December 2020 at 13:17:53 UTC+10 gary@gmail.com wrote:

> Ok, I have no idea what I would ask them for.
> The WiFilogger sends good data to the MQTT server and MQTTSubscribe 
> retrieves those accurately into loop packets.
>
> That one of them is multiplied by 100 for display doesn't seem to be on 
> either of them.
>
>
> On Sun, Dec 27, 2020, 8:40 PM gjr80  wrote:
>
>> OK, never used a wifilogger or MQTTSubscribe, suggest you get some help 
>> from the respective developers.
>>
>> Gary
>> On Monday, 28 December 2020 at 11:18:52 UTC+10 gary@gmail.com wrote:
>>
>>> Here's an exported json file content.
>>>
>>>
>>> On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:
>>>
 So where was the ET coming from that was in the loop packet? The 
 vantage driver does not emit field ET in loop packets and the 
 StdWXCalculate service does not calculate an ET field for loop packets. 
 Also are you using software or hardware archive record generation, there 
 are some peculiarities to the hardware archive record ET value emitted by 
 the Vantage driver/station. 

 Gary

 On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com 
 wrote:

> I removed the ET field from the loop and now see ET 0.00 in the 
> Seasons skin.
> It's winter so this value has little meaning for me.
> In the growing season though, I do use it in my irrigation system that 
> is fed local data from WeeWX.
>
>
> On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com 
> wrote:
>
>> Since the ET value wants to be for the loop period, then I'll just 
>> let weewx calculate this value as I have only ETDay as the smallest 
>> interval.
>> These are the fields I can choose from with my current values from 
>> the VP2:
>> "etday":"0.018"
>> "etmon":"0.60"
>> "etyear":"1.95"
>>
>> Either way, it doesn't seem to be incrementing in the skin and 
>> displays a suspicious 100 times the loop value.
>>
>>
>> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com 
>> wrote:
>>
>>> I'm running a VP2+ via WiFiLogger2
>>>
>>> This is a loop from my weewx instance:
>>> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, 
>>> appTemp: 25.040385870017634, barometer: 30.341, cloudbase: 
>>> 2600.178047939499, consBatteryVoltage: 4.76, dateTime: 
>>> 1609115113.643625, 
>>> dewpoint: 20.0, ET: 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 
>>> 40.586487665962366, inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, 
>>> outHumidity: 67.0, outTemp: 30.0, pressure: None, radiation: 0.0, rain: 
>>> 0.0, rainRate: 0.0, usUnits: 1, UV: 0.0, windchill: 30.0, windDir: 
>>> None, 
>>> windGust: 2.0, windGustDir: 247.0, windSpeed: 0.0
>>>
>>> This is where it appears in Seasons skin.
>>> [image: ET.png]
>>> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>>>
 Ultimately ET comes from either your driver or StdWXCalculate, 
 depending on the capabilities of your station (it could also come from 
 another service if your are running a driver that is capable of 
 providing 
 ET as a service). Seasons draws ET data from the database. 

 When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons 
 can dis

Re: [weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

2020-12-27 Thread G Hammer

Ok, I have no idea what I would ask them for.
The WiFilogger sends good data to the MQTT server and MQTTSubscribe
retrieves those accurately into loop packets.

That one of them is multiplied by 100 for display doesn't seem to be on
either of them.


On Sun, Dec 27, 2020, 8:40 PM gjr80  wrote:

> OK, never used a wifilogger or MQTTSubscribe, suggest you get some help
> from the respective developers.
>
> Gary
> On Monday, 28 December 2020 at 11:18:52 UTC+10 gary@gmail.com wrote:
>
>> Here's an exported json file content.
>>
>>
>> On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:
>>
>>> So where was the ET coming from that was in the loop packet? The vantage
>>> driver does not emit field ET in loop packets and the StdWXCalculate
>>> service does not calculate an ET field for loop packets. Also are you using
>>> software or hardware archive record generation, there are some
>>> peculiarities to the hardware archive record ET value emitted by the
>>> Vantage driver/station.
>>>
>>> Gary
>>>
>>> On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com wrote:
>>>
 I removed the ET field from the loop and now see ET 0.00 in the Seasons
 skin.
 It's winter so this value has little meaning for me.
 In the growing season though, I do use it in my irrigation system that
 is fed local data from WeeWX.


 On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com
 wrote:

> Since the ET value wants to be for the loop period, then I'll just let
> weewx calculate this value as I have only ETDay as the smallest interval.
> These are the fields I can choose from with my current values from the
> VP2:
> "etday":"0.018"
> "etmon":"0.60"
> "etyear":"1.95"
>
> Either way, it doesn't seem to be incrementing in the skin and
> displays a suspicious 100 times the loop value.
>
>
> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com
> wrote:
>
>> I'm running a VP2+ via WiFiLogger2
>>
>> This is a loop from my weewx instance:
>> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None,
>> appTemp: 25.040385870017634, barometer: 30.341, cloudbase:
>> 2600.178047939499, consBatteryVoltage: 4.76, dateTime: 1609115113.643625,
>> dewpoint: 20.0, ET: 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint:
>> 40.586487665962366, inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0,
>> outHumidity: 67.0, outTemp: 30.0, pressure: None, radiation: 0.0, rain:
>> 0.0, rainRate: 0.0, usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None,
>> windGust: 2.0, windGustDir: 247.0, windSpeed: 0.0
>>
>> This is where it appears in Seasons skin.
>> [image: ET.png]
>> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>>
>>> Ultimately ET comes from either your driver or StdWXCalculate,
>>> depending on the capabilities of your station (it could also come from
>>> another service if your are running a driver that is capable of 
>>> providing
>>> ET as a service). Seasons draws ET data from the database.
>>>
>>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons
>>> can display a number of different ET values/aggregates. Remember that 
>>> the
>>> loop packet value is the amount of ET in the period covered by the loop
>>> packet,  Seasons can display the cumulative amount of ET over an archive
>>> period, a day, a week, a month or a year depending on what you are 
>>> looking
>>> at.
>>>
>>> This construct:
>>>
>>> $archive.ET.sum.format(add_label=False)
>>>
>>> is used by Seasons to display day, week, month or year ET, so not
>>> really able to be compared to a loop value.
>>>
>>> Gary
>>>
>>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com
>>> wrote:
>>>
 I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after
 getting help from Rich, have it working well.
 In the Seasons skin, I see that ET is reported at 100 times the
 value in the loop packets.
 Loop has ET: 0.018
 Seasons displays ET 1.80 in

 Before I make an entry in weewx.conf StdCalibrate Corrections,
 where is the value calculated for the Seasons skin?
 I only find items like these in the skin files:
 #if $day.ET.has_data and $day.ET.sum.raw > 0.0
 #if $day.ET.has_data and $day.ET.sum.raw > 0.0
 $obs.label.ET
 $unit.label.ET
 $archive.ET.sum.format(add_label=False)

 --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/oo6K0FVMny4/unsubscribe.
> To unsubscribe from this group and all its topics, send an

[weewx-user] Belchertown charts - anyone using Gauges?

2020-12-27 Thread colin....@gmail.com

Hey all

Just wondering if anyone is using the Gauges in Belchertown Charts and has 
any working examples? I can't seem to get anything other than a full circle 
with a fixed line by using the examples here

https://github.com/poblabs/weewx-belchertown/wiki/Belchertown-Charts-Documentation#gauge-chart

Cheers
Colin

-- 
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/37e67c72-c5cf-401b-80f9-3f7cbd7379acn%40googlegroups.com.

Re: [weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

the .html timestamps are all current (assuming Dec 27 19:50 is current).
the .png timestamps are current until middle of the month images, then all old 
→ stopping part way through image generation.
some of the .png timestamps are very late in the 5 minute reporting period → 
maybe not finishing one report before starting the next.
you will need to look at (post here) the detailed log showing from before the 
start of report generation until past the end of completion of report 
generation to see if there is overlap.
or maybe the image generator is crashing part-way → ditto for need to see 
detailed logs

> On 28 Dec 2020, at 12:54 pm, Joe  wrote:
> 
> -rw-r--r-- 1 root root  7357 Dec 27 19:51  daywind.png
> -rw-r--r-- 1 root root  6148 Dec 27 19:51  daywindvec.png
> -rw-r--r-- 1 root root  1150 Dec 27 19:46  favicon.ico
> drwxr-xr-x 2 root root  4096 Dec 25 20:53  font
> -rw-r--r-- 1 root root  7315 Dec 27 19:51 '#FTP.last'
> -rw-r--r-- 1 root root 25919 Dec 27 19:50  index.html
> -rw-r--r-- 1 root root   564 Dec 27 19:46  mobile.css
> -rw-r--r-- 1 root root  2413 Dec 27 19:50  mobile.html
> -rw-r--r-- 1 root root  7606 Dec 25 20:48  monthbarometer.png
> -rw-r--r-- 1 root root 11985 Dec 27 19:50  month.html
> -rw-r--r-- 1 root root  7135 Dec 25 20:48  monthhumidity.png
> -rw-r--r-- 1 root root  6519 Dec 25 20:53  monthhum.png
> -rw-r--r-- 1 root root  8204 Dec 25 20:51  monthinside.png
> -rw-r--r-- 1 root root  5436 Dec 25 20:51  monthpond.png
> -rw-r--r-- 1 root root  7674 Dec 25 20:51  monthradiation.png
> -rw-r--r-- 1 root root  6976 Dec 25 20:48  monthrain.png
> -rw-r--r-- 1 root root  7324 Dec 25 20:51  monthrx.png
> -rw-r--r-- 1 root root  9045 Dec 25 20:48  monthtempchill.png
> -rw-r--r-- 1 root root  9280 Dec 25 20:48  monthtempdew.png
> 

-- 
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/A6FC2CCE-2EE4-45B2-A27E-21CA535665D0%40gmail.com.

Re: [weewx-user] Re: gw1000 driver fail on wifi loss

Comments below.

Gary

On Monday, 28 December 2020 at 11:22:30 UTC+10 vince wrote:

> Agree.
>
> Also thanks for the reminder re: wee_config --reconfigure. I had not seen 
> magic buried in a driver that asked questions when you reconfigure.  That 
> kinda blows up scripted installs to some extent for folks like me who use 
> --no-prompt a lot.
>

A number of the drivers use it (eg, vantage asks for hardware interface). 
Worth the extra effort where you want some user input. Only problem is it’s 
only available via wee_config and you need to get the user to go the extra 
step. 

These might be nits but I thought I'd mention them:
>
>- If you use the --no-prompt switch to wee_config you get only a 
>partial stanza installed (I didn't check the code to see if this matters 
> or 
>not).  You might want to consider having it write out all the items if 
> this 
>matters.
>
> Will look at that. The aim in such cases is to exit with a working 
install, even if some of the settings are not to the users liking. 

>
>- init_on_loop gets added right under the version string in weewx.conf 
>with no comment or whitespace.  That might be easy to overlook later on.
>
> Will look at that too, Tom’s configobj lesson from a few days ago might 
help. I was under the impression that we were fairly limited in the 
comments and formatting we could programmatically add to a config file. Tom 
showed otherwise.

>
>- uninstalling the driver leaves the init_on_loop item in weewx.conf. 
> Admittedly, it is unusual to uninstall a driver as folks would just use 
>wee_config to point to a different one (if they follow the instructions 
>that is :-)
>
> Bit difficult to handle that one as wee_extension will not know anything 
about loop_on_init and if using wee_config to configure a new driver you 
get the new driver’s config prompts (which may or may not include 
loop_on_init). Might end up being another step in the uninstall procedure.
 

-- 
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/cc853a3f-7cce-43a1-baa8-25c14700a963n%40googlegroups.com.

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

hmm, the ‘novelty’ i think is having an xtype calculated with values from 
outside weewx (eg cpu temperature), and the expense of the calculation is not 
really at issue - though normally they would be light-weight in case they are 
used often (eg barometer)

architecturally anything external is supposed to brought into weewx via a 
service and made available via weewx packet. (the *providing* of an xtype is 
now positioned as a service, but the xtypes themselves are not.)

okay, i’ll recast my vitalstats from xtypes_service to data_service and not 
bypass the packets...

> On 28 Dec 2020, at 11:40 am, Tom Keffer  wrote:
> 
> That's a novel use of xtypes, but I'm not sure it's always a good idea. In 
> this case, I think you'd be better off simply adding the type to the LOOP 
> packet or archive record. 
> 
> The intended purpose of xtypes is to calculate derived variables. It's 
> entirely possible it could be called many times during a reporting cycle, 
> depending on the template used. Something involving I/O could be very 
> expensive.
> 
> Having said that, xtypes also do database accesses, which can also be very 
> expensive, so my advice is inconsistent. So, not saying never do it, but 
> think it through.

-- 
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/29A71619-51B9-41B6-A4AB-14E54482FB56%40gmail.com.

Re: [weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

2020-12-27 Thread Joe

SO far Im not seeing any errrors. Other than the files themselves are still 
dated dec 25

Some are 12-27

var/www/weewx

total 852
drwxr-xr-x 7 root root  4096 Dec 27 19:51  .
drwxr-xr-x 3 root root  4096 Dec 25 20:40  ..
drwxr-xr-x 2 root root  4096 Dec 25 20:52  backgrounds
-rw-r--r-- 1 root root  5563 Dec 27 19:51  celestial.html
-rw-r--r-- 1 root root  7635 Dec 27 19:51  daybarometer.png
-rw-r--r-- 1 root root  6141 Dec 27 19:50  dayhumidity.png
-rw-r--r-- 1 root root  5387 Dec 27 19:51  dayhum.png
-rw-r--r-- 1 root root  9734 Dec 27 19:50  dayinside.png
-rw-r--r-- 1 root root  5382 Dec 27 19:50  daypond.png
-rw-r--r-- 1 root root  6543 Dec 27 19:51  dayradiation.png
-rw-r--r-- 1 root root  5813 Dec 27 19:51  dayrain.png
-rw-r--r-- 1 root root  6554 Dec 27 19:51  dayrx.png
-rw-r--r-- 1 root root  9199 Dec 27 19:50  daytempchill.png
-rw-r--r-- 1 root root  8421 Dec 27 19:51  daytempdew.png
-rw-r--r-- 1 root root  7835 Dec 27 19:51  daytempfeel.png
-rw-r--r-- 1 root root  7402 Dec 27 19:51  daytempin.png
-rw-r--r-- 1 root root  7825 Dec 27 19:51  daytemp.png
-rw-r--r-- 1 root root  5675 Dec 27 19:51  dayuv.png
-rw-r--r-- 1 root root 11334 Dec 27 19:51  dayvolt.png
-rw-r--r-- 1 root root  5620 Dec 27 19:51  daywinddir.png
-rw-r--r-- 1 root root  7357 Dec 27 19:51  daywind.png
-rw-r--r-- 1 root root  6148 Dec 27 19:51  daywindvec.png
-rw-r--r-- 1 root root  1150 Dec 27 19:46  favicon.ico
drwxr-xr-x 2 root root  4096 Dec 25 20:53  font
-rw-r--r-- 1 root root  7315 Dec 27 19:51 '#FTP.last'
-rw-r--r-- 1 root root 25919 Dec 27 19:50  index.html
-rw-r--r-- 1 root root   564 Dec 27 19:46  mobile.css
-rw-r--r-- 1 root root  2413 Dec 27 19:50  mobile.html
-rw-r--r-- 1 root root  7606 Dec 25 20:48  monthbarometer.png
-rw-r--r-- 1 root root 11985 Dec 27 19:50  month.html
-rw-r--r-- 1 root root  7135 Dec 25 20:48  monthhumidity.png
-rw-r--r-- 1 root root  6519 Dec 25 20:53  monthhum.png
-rw-r--r-- 1 root root  8204 Dec 25 20:51  monthinside.png
-rw-r--r-- 1 root root  5436 Dec 25 20:51  monthpond.png
-rw-r--r-- 1 root root  7674 Dec 25 20:51  monthradiation.png
-rw-r--r-- 1 root root  6976 Dec 25 20:48  monthrain.png
-rw-r--r-- 1 root root  7324 Dec 25 20:51  monthrx.png
-rw-r--r-- 1 root root  9045 Dec 25 20:48  monthtempchill.png
-rw-r--r-- 1 root root  9280 Dec 25 20:48  monthtempdew.png
-rw-r--r-- 1 root root  8541 Dec 25 20:53  monthtempfeel.png
-rw-r--r-- 1 root root  7629 Dec 25 20:53  monthtempin.png
-rw-r--r-- 1 root root  7808 Dec 25 20:53  monthtemp.png
-rw-r--r-- 1 root root  6344 Dec 25 20:51  monthuv.png
-rw-r--r-- 1 root root 12216 Dec 25 20:53  monthvolt.png
-rw-r--r-- 1 root root  6489 Dec 25 20:51  monthwinddir.png
-rw-r--r-- 1 root root  8153 Dec 25 20:51  monthwind.png
-rw-r--r-- 1 root root  6142 Dec 25 20:51  monthwindvec.png
drwxr-xr-x 2 root root  4096 Dec 27 19:50  NOAA
drwxr-xr-x 2 root root  4096 Dec 27 19:50  RSS
-rw-r--r-- 1 root root  6273 Dec 27 19:51  rss.xml
-rw-r--r-- 1 root root  5106 Dec 27 19:46  seasons.css
-rw-r--r-- 1 root root  6232 Dec 27 19:46  seasons.js
drwxr-xr-x 3 root root  4096 Dec 27 19:50  smartphone
-rw-r--r-- 1 root root 18994 Dec 27 19:50  statistics.html
-rw-r--r-- 1 root root  4724 Dec 27 19:51  tabular.html
-rw-r--r-- 1 root root  7191 Dec 27 19:51  telemetry.html
-rw-r--r-- 1 root root  8922 Dec 25 20:47  weekbarometer.png
-rw-r--r-- 1 root root 11995 Dec 27 19:50  week.html
-rw-r--r-- 1 root root  7023 Dec 25 20:52  weekhum.png
-rw-r--r-- 1 root root  8599 Dec 25 20:48  weekinside.png
-rw-r--r-- 1 root root  5919 Dec 25 20:47  weekpond.png
-rw-r--r-- 1 root root  9554 Dec 25 20:48  weekradiation.png
-rw-r--r-- 1 root root  7927 Dec 25 20:47  weekrain.png
-rw-r--r-- 1 root root  8094 Dec 25 20:48  weekrx.png
-rw-r--r-- 1 root root 11098 Dec 25 20:47  weektempchill.png
-rw-r--r-- 1 root root 11207 Dec 25 20:47  weektempdew.png
-rw-r--r-- 1 root root  9494 Dec 25 20:52  weektempfeel.png
-rw-r--r-- 1 root root  7420 Dec 25 20:52  weektempin.png
-rw-r--r-- 1 root root  8094 Dec 25 20:52  weektemp.png
-rw-r--r-- 1 root root  7026 Dec 25 20:48  weekuv.png
-rw-r--r-- 1 root root 11923 Dec 25 20:53  weekvolt.png
-rw-r--r-- 1 root root  7525 Dec 25 20:48  weekwinddir.png
-rw-r--r-- 1 root root  9247 Dec 25 20:48  weekwind.png
-rw-r--r-- 1 root root  7552 Dec 25 20:48  weekwindvec.png
-rw-r--r-- 1 root root  3533 Dec 27 19:46  weewx.css
-rw-r--r-- 1 root root  7767 Dec 25 20:51  yearbarometer.png
-rw-r--r-- 1 root root  9579 Dec 25 20:51  yearhilow.png
-rw-r--r-- 1 root root  7912 Dec 27 19:50  year.html
-rw-r--r-- 1 root root  7607 Dec 25 20:51  yearhumidity.png
-rw-r--r-- 1 root root  7017 Dec 25 20:53  yearhum.png
-rw-r--r-- 1 root root  8469 Dec 25 20:51  yearinside.png
-rw-r--r-- 1 root root  5372 Dec 25 20:51  yearpond.png
-rw-r--r-- 1 root root  7446 Dec 25 20:52  yearradiation.png
-rw-r--r-- 1 root root  6565 Dec 25 20:51  yearrain.png
-rw-r--r-- 1 root root  7311 Dec 25 20:51  yearrx.png
-rw-r--r-- 1 root root  9379 Dec 25 20:51  yeartempchill.png
-rw-r--r-- 1

Re: [weewx-user] Re: WeeWx error "Vantage: LOOP read error. Try ... "

Do you have multiple instances of weewxd running? It's normal to see two
PIDs, one of the original process, one of the fork, but I'm seeing three.

On Sun, Dec 27, 2020 at 5:43 PM Rob Cranfill  wrote:

> And I have tried "sudo wee_device --dump" and "sudo wee_device
> --clear-memory" several times.
>
> On Sunday, December 27, 2020 at 5:42:05 PM UTC-8 Rob Cranfill wrote:
>
>> I've been running weewx for years, and now all of a sudden I am having
>> this problem over and over again.
>>
>> Now, this is a new build on this same RPI - I had a SSD crash - but it
>> seems substantially the same as before, yet here I am.
>>
>> I realize this has to do with the OS's time not being "correct",
>> whatever that means. So why does this confuse me?
>>
>> pi@pi3b:~ $ wee_device --info | grep time
>>   Onboard time: 2020-12-27 17:37:04
>> pi@pi3b:~ $ date
>> Sun 27 Dec 2020 05:37:09 PM PST
>>
>> Is this really the cause of my problems?
>>
>> Dec 27 17:36:22 pi3b systemd[1]: Starting LSB: weewx weather system...
>> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Initializing weewx
>> version 4.2.0
>> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Using Python 3.7.3
>> (default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0]
>> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Platform
>> Linux-5.4.79-v7+-armv7l-with-debian-10.7
>> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Locale is 'en_US'
>> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: PID file is
>> /var/run/weewx.pid
>> Dec 27 17:36:22 pi3b weewx[7659] INFO __main__: Using configuration file
>> /etc/weewx/weewx.conf
>> Dec 27 17:36:22 pi3b weewx[7659] INFO __main__: Debug is 1
>> Dec 27 17:36:22 pi3b weewx[7644]: Starting weewx weather system: weewx.
>> Dec 27 17:36:22 pi3b systemd[1]: Started LSB: weewx weather system.
>>
>>
>> Dec 27 17:36:27 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try
>> #1; error: Expected to read 99 chars; got 0 instead
>> Dec 27 17:36:31 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try
>> #2; error: Expected to read 99 chars; got 0 instead
>> Dec 27 17:36:35 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try
>> #3; error: Expected to read 99 chars; got 0 instead
>> ^C
>>
>>
>>
>> On Sunday, December 27, 2020 at 8:12:00 AM UTC-8 sche...@gmail.com wrote:
>>
>>> try to set your date and time before start weewx
>>>
>>> Il giorno domenica 27 dicembre 2020 alle 13:12:19 UTC+1 gjr80 ha scritto:
>>>
 Hi,

 You can try using

 $ wee_device —dump

 before clearing the loggers memory, this will dump all available
 archive records to database. It may or may not get any records from the
 logger that have not previously been downloaded, but it is about the best
 you can do at this stage.

 Gary
 On Sunday, 27 December 2020 at 21:35:38 UTC+10 jputt...@gmail.com
 wrote:

> Hi, suddenly the Raspi Py did not read out any data (console Vantage
> Pro 2).
> *ERROR weewx.drivers.vantage: LOOP try #1; error: Expected to read 99
> chars; got 0 instead*
> Removing and reconnecting the USB connector and rebooting the Raspi
> did not help.
> Command *wee_device --clear* and then  *sudo service weewx restart*
> solved the problem.
> Unfortunately, measurement data was lost in the process.
> Is there another solution without data loss? ( for the future)
>
> Joachim
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/cf2f1912-7af8-4c96-bf44-d4e1b40af229n%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/CAPq0zEB7tg95Mw2YeN5jbxe8n3cxNsUJAJJwij9uDsYKCrR5%2BQ%40mail.gmail.com.

[weewx-user] Re: WeeWx error "Vantage: LOOP read error. Try ... "

And I have tried "sudo wee_device --dump" and "sudo wee_device 
--clear-memory" several times.

On Sunday, December 27, 2020 at 5:42:05 PM UTC-8 Rob Cranfill wrote:

> I've been running weewx for years, and now all of a sudden I am having 
> this problem over and over again. 
>
> Now, this is a new build on this same RPI - I had a SSD crash - but it 
> seems substantially the same as before, yet here I am.
>
> I realize this has to do with the OS's time not being "correct", 
> whatever that means. So why does this confuse me?
>
> pi@pi3b:~ $ wee_device --info | grep time
>   Onboard time: 2020-12-27 17:37:04
> pi@pi3b:~ $ date
> Sun 27 Dec 2020 05:37:09 PM PST
>
> Is this really the cause of my problems?
>
> Dec 27 17:36:22 pi3b systemd[1]: Starting LSB: weewx weather system...
> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Initializing weewx version 
> 4.2.0
> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Using Python 3.7.3 
> (default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0]
> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Platform 
> Linux-5.4.79-v7+-armv7l-with-debian-10.7
> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Locale is 'en_US'
> Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: PID file is 
> /var/run/weewx.pid
> Dec 27 17:36:22 pi3b weewx[7659] INFO __main__: Using configuration file 
> /etc/weewx/weewx.conf
> Dec 27 17:36:22 pi3b weewx[7659] INFO __main__: Debug is 1
> Dec 27 17:36:22 pi3b weewx[7644]: Starting weewx weather system: weewx.
> Dec 27 17:36:22 pi3b systemd[1]: Started LSB: weewx weather system.
>
>
> Dec 27 17:36:27 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try #1; 
> error: Expected to read 99 chars; got 0 instead
> Dec 27 17:36:31 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try #2; 
> error: Expected to read 99 chars; got 0 instead
> Dec 27 17:36:35 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try #3; 
> error: Expected to read 99 chars; got 0 instead
> ^C
>
>
>
> On Sunday, December 27, 2020 at 8:12:00 AM UTC-8 sche...@gmail.com wrote:
>
>> try to set your date and time before start weewx
>>
>> Il giorno domenica 27 dicembre 2020 alle 13:12:19 UTC+1 gjr80 ha scritto:
>>
>>> Hi,
>>>
>>> You can try using 
>>>
>>> $ wee_device —dump
>>>
>>> before clearing the loggers memory, this will dump all available archive 
>>> records to database. It may or may not get any records from the logger that 
>>> have not previously been downloaded, but it is about the best you can do at 
>>> this stage.
>>>
>>> Gary
>>> On Sunday, 27 December 2020 at 21:35:38 UTC+10 jputt...@gmail.com wrote:
>>>
 Hi, suddenly the Raspi Py did not read out any data (console Vantage 
 Pro 2).
 *ERROR weewx.drivers.vantage: LOOP try #1; error: Expected to read 99 
 chars; got 0 instead*
 Removing and reconnecting the USB connector and rebooting the Raspi did 
 not help.
 Command *wee_device --clear* and then  *sudo service weewx restart* 
 solved the problem.
 Unfortunately, measurement data was lost in the process.
 Is there another solution without data loss? ( for the future) 

 Joachim



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

[weewx-user] Re: WeeWx error "Vantage: LOOP read error. Try ... "

I've been running weewx for years, and now all of a sudden I am having this 
problem over and over again. 

Now, this is a new build on this same RPI - I had a SSD crash - but it 
seems substantially the same as before, yet here I am.

I realize this has to do with the OS's time not being "correct", 
whatever that means. So why does this confuse me?

pi@pi3b:~ $ wee_device --info | grep time
  Onboard time: 2020-12-27 17:37:04
pi@pi3b:~ $ date
Sun 27 Dec 2020 05:37:09 PM PST

Is this really the cause of my problems?

Dec 27 17:36:22 pi3b systemd[1]: Starting LSB: weewx weather system...
Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Initializing weewx version 
4.2.0
Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Using Python 3.7.3 
(default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0]
Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Platform 
Linux-5.4.79-v7+-armv7l-with-debian-10.7
Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: Locale is 'en_US'
Dec 27 17:36:22 pi3b weewx[7655] INFO __main__: PID file is 
/var/run/weewx.pid
Dec 27 17:36:22 pi3b weewx[7659] INFO __main__: Using configuration file 
/etc/weewx/weewx.conf
Dec 27 17:36:22 pi3b weewx[7659] INFO __main__: Debug is 1
Dec 27 17:36:22 pi3b weewx[7644]: Starting weewx weather system: weewx.
Dec 27 17:36:22 pi3b systemd[1]: Started LSB: weewx weather system.


Dec 27 17:36:27 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try #1; 
error: Expected to read 99 chars; got 0 instead
Dec 27 17:36:31 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try #2; 
error: Expected to read 99 chars; got 0 instead
Dec 27 17:36:35 pi3b weewx[7659] ERROR weewx.drivers.vantage: LOOP try #3; 
error: Expected to read 99 chars; got 0 instead
^C



On Sunday, December 27, 2020 at 8:12:00 AM UTC-8 sche...@gmail.com wrote:

> try to set your date and time before start weewx
>
> Il giorno domenica 27 dicembre 2020 alle 13:12:19 UTC+1 gjr80 ha scritto:
>
>> Hi,
>>
>> You can try using 
>>
>> $ wee_device —dump
>>
>> before clearing the loggers memory, this will dump all available archive 
>> records to database. It may or may not get any records from the logger that 
>> have not previously been downloaded, but it is about the best you can do at 
>> this stage.
>>
>> Gary
>> On Sunday, 27 December 2020 at 21:35:38 UTC+10 jputt...@gmail.com wrote:
>>
>>> Hi, suddenly the Raspi Py did not read out any data (console Vantage Pro 
>>> 2).
>>> *ERROR weewx.drivers.vantage: LOOP try #1; error: Expected to read 99 
>>> chars; got 0 instead*
>>> Removing and reconnecting the USB connector and rebooting the Raspi did 
>>> not help.
>>> Command *wee_device --clear* and then  *sudo service weewx restart* 
>>> solved the problem.
>>> Unfortunately, measurement data was lost in the process.
>>> Is there another solution without data loss? ( for the future) 
>>>
>>> Joachim
>>>
>>>

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

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

OK, never used a wifilogger or MQTTSubscribe, suggest you get some help 
from the respective developers.

Gary
On Monday, 28 December 2020 at 11:18:52 UTC+10 gary@gmail.com wrote:

> Here's an exported json file content.
>
>
> On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:
>
>> So where was the ET coming from that was in the loop packet? The vantage 
>> driver does not emit field ET in loop packets and the StdWXCalculate 
>> service does not calculate an ET field for loop packets. Also are you using 
>> software or hardware archive record generation, there are some 
>> peculiarities to the hardware archive record ET value emitted by the 
>> Vantage driver/station. 
>>
>> Gary
>>
>> On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com wrote:
>>
>>> I removed the ET field from the loop and now see ET 0.00 in the Seasons 
>>> skin.
>>> It's winter so this value has little meaning for me.
>>> In the growing season though, I do use it in my irrigation system that 
>>> is fed local data from WeeWX.
>>>
>>>
>>> On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com 
>>> wrote:
>>>
 Since the ET value wants to be for the loop period, then I'll just let 
 weewx calculate this value as I have only ETDay as the smallest interval.
 These are the fields I can choose from with my current values from the 
 VP2:
 "etday":"0.018"
 "etmon":"0.60"
 "etyear":"1.95"

 Either way, it doesn't seem to be incrementing in the skin and displays 
 a suspicious 100 times the loop value.


 On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com 
 wrote:

> I'm running a VP2+ via WiFiLogger2
>
> This is a loop from my weewx instance:
> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, 
> ET: 
> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
> windGustDir: 247.0, windSpeed: 0.0
>
> This is where it appears in Seasons skin.
> [image: ET.png]
> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>
>> Ultimately ET comes from either your driver or StdWXCalculate, 
>> depending on the capabilities of your station (it could also come from 
>> another service if your are running a driver that is capable of 
>> providing 
>> ET as a service). Seasons draws ET data from the database. 
>>
>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons 
>> can display a number of different ET values/aggregates. Remember that 
>> the 
>> loop packet value is the amount of ET in the period covered by the loop 
>> packet,  Seasons can display the cumulative amount of ET over an archive 
>> period, a day, a week, a month or a year depending on what you are 
>> looking 
>> at.
>>
>> This construct:
>>
>> $archive.ET.sum.format(add_label=False)
>>
>> is used by Seasons to display day, week, month or year ET, so not 
>> really able to be compared to a loop value.
>>
>> Gary
>>
>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com 
>> wrote:
>>
>>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after 
>>> getting help from Rich, have it working well.
>>> In the Seasons skin, I see that ET is reported at 100 times the 
>>> value in the loop packets.
>>> Loop has ET: 0.018
>>> Seasons displays ET 1.80 in
>>>
>>> Before I make an entry in weewx.conf StdCalibrate Corrections, where 
>>> is the value calculated for the Seasons skin?
>>> I only find items like these in the skin files:
>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>> $obs.label.ET
>>> $unit.label.ET
>>> $archive.ET.sum.format(add_label=False)
>>>
>>>

-- 
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/8a28d3c5-4df5-425f-ac7e-7e20dbcfa7a1n%40googlegroups.com.

Re: [weewx-user] Re: Super simple skin

Altho, once again, my station is offline due to the dread WeeWX time sync 
issue:-/

On Sunday, December 27, 2020 at 3:06:27 PM UTC-8 Rob Cranfill wrote:

> I have pared it down it even more - perhaps too much. ;-) The wind 
> alternates between current speed and recent (30 minute) max. (The 
> stylesheet background/border needs to be fixed a bit.)
>
>
>
> http://robcranfill.net/weather/Crandard/
>
>
> On Sun, Dec 27, 2020 at 14:54 Rob Cranfill  wrote:
>
>> I’m glad you found it useful! Thanks for letting me know. Yes, STandard 
>> would be quite appropriate. :-)
>>
>>
>> On Sun, Dec 27, 2020 at 07:17 Sven Täveby  wrote:
>>
>>> A big Thank You!
>>> Made some changes and transladed to Swedish. Maybe I'll change the name 
>>> to STandard? :-) 
>>> http://teff.se/v2/Crandard
>>> Outdoor/indoor/max ut/min out/rain today/rain totalt last 7 days/last 
>>> updated.
>>>
>>> Looks great on my wall, using a Raspberry Pi touchscreen (and a BME280 
>>> sensor to report indoor temp to weewx on the master Pi.
>>> Cheers
>>> /Sven
>>>  
>>> Den söndag 8 november 2020 kl. 21:14:41 UTC+1 skrev Sven Täveby:

 Thx. Will check it out.
 /Sven

 söndag 8 november 2020 kl. 00:30:05 UTC+1 skrev robcr...@gmail.com:

> Sven, if you're addressing me, I've got it posted at
>
>   https://github.com/RobCranfill/Crandard
>
> Does that work for you?
>  /rob
>
> PS - I've gotten a little sidetracked from updating the code, because 
> 1) I can see that I will indeed be able to do what I want with WeeWX, but 
> 2) the hardware I was going to use to display it is proving to be a 
> problem, so I'm re-thinking that. :-]
>
> On Saturday, November 7, 2020 at 1:33:44 PM UTC-8 sven@gmail.com 
> wrote:
>
>> Can You share that skin?
>> Exactly what I want (except maybe units).
>>
>> /Sven 
>>
> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "weewx-user" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/weewx-user/AKIAQ1knwvc/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/ef4c91fc-ffc2-49ca-9893-3cce73e25d97o%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/65284448-759d-4591-a3c0-d3bdd93af942n%40googlegroups.com.

Re: [weewx-user] Re: gw1000 driver fail on wifi loss

Agree.

Also thanks for the reminder re: wee_config --reconfigure. I had not seen 
magic buried in a driver that asked questions when you reconfigure.  That 
kinda blows up scripted installs to some extent for folks like me who use 
--no-prompt a lot.

These might be nits but I thought I'd mention them:

   - If you use the --no-prompt switch to wee_config you get only a partial 
   stanza installed (I didn't check the code to see if this matters or not). 
You might want to consider having it write out all the items if this 
   matters.


   - init_on_loop gets added right under the version string in weewx.conf 
   with no comment or whitespace.  That might be easy to overlook later on.


   - uninstalling the driver leaves the init_on_loop item in weewx.conf. 
Admittedly, it is unusual to uninstall a driver as folks would just use 
   wee_config to point to a different one (if they follow the instructions 
   that is :-)

But the driver has been rock solid for me here, so it's of course much 
appreciated.

On Sunday, December 27, 2020 at 4:30:55 PM UTC-8 gjr80 wrote:

> I think the install instructions are clear and concise. At the end of the 
> day if you choose not to follow them a degree of caveat emptor applies. I 
> believe the current loop_on_init setting is appropriate and see no need to 
> change it (experience shows if I did then the ‘stop polluting my logs’ 
> brigade will start complaining).
>
> Of course anyone is free to fork the driver...
>
> 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/76fec035-b204-43a6-a9a3-bfb8c456f974n%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

Here's an exported json file content.


On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:

> So where was the ET coming from that was in the loop packet? The vantage 
> driver does not emit field ET in loop packets and the StdWXCalculate 
> service does not calculate an ET field for loop packets. Also are you using 
> software or hardware archive record generation, there are some 
> peculiarities to the hardware archive record ET value emitted by the 
> Vantage driver/station. 
>
> Gary
>
> On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com wrote:
>
>> I removed the ET field from the loop and now see ET 0.00 in the Seasons 
>> skin.
>> It's winter so this value has little meaning for me.
>> In the growing season though, I do use it in my irrigation system that is 
>> fed local data from WeeWX.
>>
>>
>> On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com 
>> wrote:
>>
>>> Since the ET value wants to be for the loop period, then I'll just let 
>>> weewx calculate this value as I have only ETDay as the smallest interval.
>>> These are the fields I can choose from with my current values from the 
>>> VP2:
>>> "etday":"0.018"
>>> "etmon":"0.60"
>>> "etyear":"1.95"
>>>
>>> Either way, it doesn't seem to be incrementing in the skin and displays 
>>> a suspicious 100 times the loop value.
>>>
>>>
>>> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com 
>>> wrote:
>>>
 I'm running a VP2+ via WiFiLogger2

 This is a loop from my weewx instance:
 LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
 consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
 inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
 outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
 usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
 windGustDir: 247.0, windSpeed: 0.0

 This is where it appears in Seasons skin.
 [image: ET.png]
 On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:

> Ultimately ET comes from either your driver or StdWXCalculate, 
> depending on the capabilities of your station (it could also come from 
> another service if your are running a driver that is capable of providing 
> ET as a service). Seasons draws ET data from the database. 
>
> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
> display a number of different ET values/aggregates. Remember that the 
> loop 
> packet value is the amount of ET in the period covered by the loop 
> packet, 
>  Seasons can display the cumulative amount of ET over an archive period, 
> a 
> day, a week, a month or a year depending on what you are looking at.
>
> This construct:
>
> $archive.ET.sum.format(add_label=False)
>
> is used by Seasons to display day, week, month or year ET, so not 
> really able to be compared to a loop value.
>
> Gary
>
> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com 
> wrote:
>
>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>> help from Rich, have it working well.
>> In the Seasons skin, I see that ET is reported at 100 times the value 
>> in the loop packets.
>> Loop has ET: 0.018
>> Seasons displays ET 1.80 in
>>
>> Before I make an entry in weewx.conf StdCalibrate Corrections, where 
>> is the value calculated for the Seasons skin?
>> I only find items like these in the skin files:
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> $obs.label.ET
>> $unit.label.ET
>> $archive.ET.sum.format(add_label=False)
>>
>>

-- 
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/a0781a7d-b563-4e98-a747-1c91a5e34d03n%40googlegroups.com.
Client mosq-QNW4O3mQboJaoyTTGN received PUBLISH (d0, q0, r0, m0, 
'weather/wflexp.json', ... (3712 bytes))
{"stnname":"WiFiLogger"
"stnmod":16
"ver":3.83
"mac":"x"
"apmac":"x"
"ip":"x"
"ssid":"x"
"rssi":-44
"wifimod":0
"lastboot":1609002808
"uptime":6536
"wflver":"2.34"
"loctime":1608991335
"utctime":1609009335
"tzone":10
"units":4
"conlati":492
"conlongi":-925
"wfllati":-300.000
"wfllongi":-300.000
"tempout":"31.4"
"humout":"53"
"tempin":"73.9"
"humin":"30"
"windspd":"3.0"
"winddir":"280"
"windavg2":"6.3"
"windavg10":"5.2"
"gust":"13.0"
"gustdir":"270"
"bar":"29.788

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

I have a WiFiLogger2 installed exporting json to my mosquitto server. Then 
WeeWX-MQTTSubscribe pulls in the data from the MQTT server.
In StdWXCalculate  ET = prefer_hardware
In StdArchive  record_generation = hardware
On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:

> So where was the ET coming from that was in the loop packet? The vantage 
> driver does not emit field ET in loop packets and the StdWXCalculate 
> service does not calculate an ET field for loop packets. Also are you using 
> software or hardware archive record generation, there are some 
> peculiarities to the hardware archive record ET value emitted by the 
> Vantage driver/station. 
>
> Gary
>
> On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com wrote:
>
>> I removed the ET field from the loop and now see ET 0.00 in the Seasons 
>> skin.
>> It's winter so this value has little meaning for me.
>> In the growing season though, I do use it in my irrigation system that is 
>> fed local data from WeeWX.
>>
>>
>> On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com 
>> wrote:
>>
>>> Since the ET value wants to be for the loop period, then I'll just let 
>>> weewx calculate this value as I have only ETDay as the smallest interval.
>>> These are the fields I can choose from with my current values from the 
>>> VP2:
>>> "etday":"0.018"
>>> "etmon":"0.60"
>>> "etyear":"1.95"
>>>
>>> Either way, it doesn't seem to be incrementing in the skin and displays 
>>> a suspicious 100 times the loop value.
>>>
>>>
>>> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com 
>>> wrote:
>>>
 I'm running a VP2+ via WiFiLogger2

 This is a loop from my weewx instance:
 LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
 consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
 inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
 outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
 usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
 windGustDir: 247.0, windSpeed: 0.0

 This is where it appears in Seasons skin.
 [image: ET.png]
 On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:

> Ultimately ET comes from either your driver or StdWXCalculate, 
> depending on the capabilities of your station (it could also come from 
> another service if your are running a driver that is capable of providing 
> ET as a service). Seasons draws ET data from the database. 
>
> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
> display a number of different ET values/aggregates. Remember that the 
> loop 
> packet value is the amount of ET in the period covered by the loop 
> packet, 
>  Seasons can display the cumulative amount of ET over an archive period, 
> a 
> day, a week, a month or a year depending on what you are looking at.
>
> This construct:
>
> $archive.ET.sum.format(add_label=False)
>
> is used by Seasons to display day, week, month or year ET, so not 
> really able to be compared to a loop value.
>
> Gary
>
> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com 
> wrote:
>
>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>> help from Rich, have it working well.
>> In the Seasons skin, I see that ET is reported at 100 times the value 
>> in the loop packets.
>> Loop has ET: 0.018
>> Seasons displays ET 1.80 in
>>
>> Before I make an entry in weewx.conf StdCalibrate Corrections, where 
>> is the value calculated for the Seasons skin?
>> I only find items like these in the skin files:
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> $obs.label.ET
>> $unit.label.ET
>> $archive.ET.sum.format(add_label=False)
>>
>>

-- 
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/1907bf85-8bd0-4f65-82f8-a1627ba49bfcn%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

So where was the ET coming from that was in the loop packet? The vantage 
driver does not emit field ET in loop packets and the StdWXCalculate 
service does not calculate an ET field for loop packets. Also are you using 
software or hardware archive record generation, there are some 
peculiarities to the hardware archive record ET value emitted by the 
Vantage driver/station. 

Gary

On Monday, 28 December 2020 at 10:57:05 UTC+10 gary@gmail.com wrote:

> I removed the ET field from the loop and now see ET 0.00 in the Seasons 
> skin.
> It's winter so this value has little meaning for me.
> In the growing season though, I do use it in my irrigation system that is 
> fed local data from WeeWX.
>
>
> On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com wrote:
>
>> Since the ET value wants to be for the loop period, then I'll just let 
>> weewx calculate this value as I have only ETDay as the smallest interval.
>> These are the fields I can choose from with my current values from the 
>> VP2:
>> "etday":"0.018"
>> "etmon":"0.60"
>> "etyear":"1.95"
>>
>> Either way, it doesn't seem to be incrementing in the skin and displays a 
>> suspicious 100 times the loop value.
>>
>>
>> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com 
>> wrote:
>>
>>> I'm running a VP2+ via WiFiLogger2
>>>
>>> This is a loop from my weewx instance:
>>> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
>>> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
>>> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
>>> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
>>> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
>>> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
>>> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
>>> windGustDir: 247.0, windSpeed: 0.0
>>>
>>> This is where it appears in Seasons skin.
>>> [image: ET.png]
>>> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>>>
 Ultimately ET comes from either your driver or StdWXCalculate, 
 depending on the capabilities of your station (it could also come from 
 another service if your are running a driver that is capable of providing 
 ET as a service). Seasons draws ET data from the database. 

 When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
 display a number of different ET values/aggregates. Remember that the loop 
 packet value is the amount of ET in the period covered by the loop packet, 
  Seasons can display the cumulative amount of ET over an archive period, a 
 day, a week, a month or a year depending on what you are looking at.

 This construct:

 $archive.ET.sum.format(add_label=False)

 is used by Seasons to display day, week, month or year ET, so not 
 really able to be compared to a loop value.

 Gary

 On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com 
 wrote:

> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
> help from Rich, have it working well.
> In the Seasons skin, I see that ET is reported at 100 times the value 
> in the loop packets.
> Loop has ET: 0.018
> Seasons displays ET 1.80 in
>
> Before I make an entry in weewx.conf StdCalibrate Corrections, where 
> is the value calculated for the Seasons skin?
> I only find items like these in the skin files:
> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
> $obs.label.ET
> $unit.label.ET
> $archive.ET.sum.format(add_label=False)
>
>

-- 
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/a007c1a3-2b91-48ed-b619-6e1d7a00abd8n%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

I removed the ET field from the loop and now see ET 0.00 in the Seasons 
skin.
It's winter so this value has little meaning for me.
In the growing season though, I do use it in my irrigation system that is 
fed local data from WeeWX.


On Sunday, December 27, 2020 at 7:38:52 PM UTC-5 gary@gmail.com wrote:

> Since the ET value wants to be for the loop period, then I'll just let 
> weewx calculate this value as I have only ETDay as the smallest interval.
> These are the fields I can choose from with my current values from the VP2:
> "etday":"0.018"
> "etmon":"0.60"
> "etyear":"1.95"
>
> Either way, it doesn't seem to be incrementing in the skin and displays a 
> suspicious 100 times the loop value.
>
>
> On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com wrote:
>
>> I'm running a VP2+ via WiFiLogger2
>>
>> This is a loop from my weewx instance:
>> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
>> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
>> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
>> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
>> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
>> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
>> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
>> windGustDir: 247.0, windSpeed: 0.0
>>
>> This is where it appears in Seasons skin.
>> [image: ET.png]
>> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>>
>>> Ultimately ET comes from either your driver or StdWXCalculate, depending 
>>> on the capabilities of your station (it could also come from another 
>>> service if your are running a driver that is capable of providing ET as a 
>>> service). Seasons draws ET data from the database. 
>>>
>>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
>>> display a number of different ET values/aggregates. Remember that the loop 
>>> packet value is the amount of ET in the period covered by the loop packet, 
>>>  Seasons can display the cumulative amount of ET over an archive period, a 
>>> day, a week, a month or a year depending on what you are looking at.
>>>
>>> This construct:
>>>
>>> $archive.ET.sum.format(add_label=False)
>>>
>>> is used by Seasons to display day, week, month or year ET, so not really 
>>> able to be compared to a loop value.
>>>
>>> Gary
>>>
>>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com wrote:
>>>
 I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
 help from Rich, have it working well.
 In the Seasons skin, I see that ET is reported at 100 times the value 
 in the loop packets.
 Loop has ET: 0.018
 Seasons displays ET 1.80 in

 Before I make an entry in weewx.conf StdCalibrate Corrections, where is 
 the value calculated for the Seasons skin?
 I only find items like these in the skin files:
 #if $day.ET.has_data and $day.ET.sum.raw > 0.0
 #if $day.ET.has_data and $day.ET.sum.raw > 0.0
 $obs.label.ET
 $unit.label.ET
 $archive.ET.sum.format(add_label=False)



-- 
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/fc0fa503-6963-4a48-8b49-f7e14c31efa5n%40googlegroups.com.

Re: [weewx-user] SFTP upload error ftplib.py

WeeWX supports FTPS, which is FTP over TLS. It does *not* support SFTP,
which uses a Secure Socket Shell protocol. I'm guessing your FTP server
simply does not support FTPS.

Can you use rsync? It's better in almost every way.

On Sun, Dec 27, 2020 at 1:47 PM 'Stefan Ferber' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Cannot find the defect in my sftp configuration. Could you please check?
>
> [[SmartphoneReport]]
> # The SmartphoneReport uses the 'Smartphone' skin, and the images
> and
> # files are placed in a dedicated subdirectory.
> skin = Smartphone
> enable = true
> HTML_ROOT = /var/www/html/weewx/smartphone
>
> [[MobileReport]]
> # The MobileReport uses the 'Mobile' skin, and the images and files
> # are placed in a dedicated subdirectory.
> skin = Mobile
> enable = true
> HTML_ROOT = /var/www/html/weewx/mobile
>
> [[StandardReport]]
> # This is the old "Standard" skin. By default, it is not enabled.
> skin = Standard
> enable = false
>
> [[FTP]]
> # FTP'ing the results to a webserver is treated as just another
> report,
> # albeit one with an unusual report generator!
> skin = Ftp
>
> # If you wish to use FTP, set "enable" to "true", then
> # fill out the next four lines.
> # Use quotes around passwords to guard against parsing errors.
> enable = true
> user = 
> password = ""
> server = home15604585.1and1-data.host# The ftp server name,
> e.g, www.myserver.org
> path = /SmartFerber/weewx# The destination directory, e.g.,
> /weather
>
> # Set to True for an FTP over TLS (FTPS) connection. Not all
> servers
> # support this.
> secure_ftp = true
>
> # To upload files from something other than what HTML_ROOT is set
> # to above, specify a different HTML_ROOT here.
> #HTML_ROOT = /var/www/html/weewx
>
> # Most FTP servers use port 21
> port = 22
>
> # Set to 1 to use passive mode, zero for active mode
> passive = 1
>
> getting multiple errors:
>
> Dec 27 22:35:51 raspberrypi weewx[24064] INFO weewx.cheetahgenerator:
> Generated 8 files for report SeasonsReport in 28.09 seconds
> Dec 27 22:35:58 raspberrypi weewx[24064] INFO weewx.imagegenerator:
> Generated 15 images for report SeasonsReport in 6.71 seconds
> Dec 27 22:35:58 raspberrypi weewx[24064] INFO weewx.reportengine: Copied 5
> files to /var/www/html/weewx
> Dec 27 22:36:01 raspberrypi weewx[24064] INFO weewx.cheetahgenerator:
> Generated 6 files for report SmartphoneReport in 2.09 seconds
> Dec 27 22:36:03 raspberrypi weewx[24064] INFO weewx.imagegenerator:
> Generated 6 images for report SmartphoneReport in 2.40 seconds
> Dec 27 22:36:03 raspberrypi weewx[24064] INFO weewx.reportengine: Copied 6
> files to /var/www/html/weewx/smartphone
> Dec 27 22:36:04 raspberrypi weewx[24064] INFO weewx.cheetahgenerator:
> Generated 1 files for report MobileReport in 0.78 seconds
> Dec 27 22:36:06 raspberrypi weewx[24064] INFO weewx.imagegenerator:
> Generated 4 images for report MobileReport in 1.65 seconds
> Dec 27 22:36:06 raspberrypi weewx[24064] INFO weewx.reportengine: Copied 2
> files to /var/www/html/weewx/mobile
> Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
> ftpgenerator: (0): caught exception '': timed out
> Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
>    Traceback (most recent call last):
> Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
>  File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
> Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
>    n = ftp_data.run()
> Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
>  File "/usr/share/weewx/weeutil/ftpupload.py", line 127, in run
> Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
>    ftp_server.connect(self.server, self.port)
> Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 155, in connect
> Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
>    self.welcome = self.getresp()
> Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 236, in getresp
> Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
>    resp = self.getmultiline()
> Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 226, in getmultiline
> Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
>    nextline = self.getline()
> Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 204, in getline
> Dec 27 22:36:27 raspberrypi we

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

That's a novel use of xtypes, but I'm not sure it's always a good idea. In
this case, I think you'd be better off simply adding the type to the LOOP
packet or archive record.

The intended purpose of xtypes is to calculate derived variables. It's
entirely possible it could be called many times during a reporting cycle,
depending on the template used. Something involving I/O could be very
expensive.

Having said that, xtypes also do database accesses, which can also be very
expensive, so my advice is inconsistent. So, not saying never do it, but
think it through.

-tk

On Sun, Dec 27, 2020 at 3:44 PM Graham Eddy  wrote:

> an alternative to repurposing an existing data_type is to define an xtype
> (e.g. see https://github.com/g-eddy/weewx-vitalstats)
>
> On 28 Dec 2020, at 9:05 am, Kevin Chapman  wrote:
>
> Thank you.  I will check it out.
>
> On Sun, Dec 27, 2020 at 6:00 AM Mike Revitt  wrote:
>
>> Sorry it has taken so long to respond to this, but I have just finished
>> documenting how I added the CPU Temperature to my website, this is all
>> documented here
>> 
>>
>> https://www.cougar.eu.com/useful-guides/weewx-guides/rasberry-pi/read-cpu-temp.html
>>
>
> --
> 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/6B658B72-0127-4CA6-BC85-60A52CB0A9E7%40gmail.com
> 
> .
>

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

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

Since the ET value wants to be for the loop period, then I'll just let 
weewx calculate this value as I have only ETDay as the smallest interval.
These are the fields I can choose from with my current values from the VP2:
"etday":"0.018"
"etmon":"0.60"
"etyear":"1.95"

Either way, it doesn't seem to be incrementing in the skin and displays a 
suspicious 100 times the loop value.


On Sunday, December 27, 2020 at 7:29:25 PM UTC-5 gary@gmail.com wrote:

> I'm running a VP2+ via WiFiLogger2
>
> This is a loop from my weewx instance:
> LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
> 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
> consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
> 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
> inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
> outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
> usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
> windGustDir: 247.0, windSpeed: 0.0
>
> This is where it appears in Seasons skin.
> [image: ET.png]
> On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:
>
>> Ultimately ET comes from either your driver or StdWXCalculate, depending 
>> on the capabilities of your station (it could also come from another 
>> service if your are running a driver that is capable of providing ET as a 
>> service). Seasons draws ET data from the database. 
>>
>> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
>> display a number of different ET values/aggregates. Remember that the loop 
>> packet value is the amount of ET in the period covered by the loop packet, 
>>  Seasons can display the cumulative amount of ET over an archive period, a 
>> day, a week, a month or a year depending on what you are looking at.
>>
>> This construct:
>>
>> $archive.ET.sum.format(add_label=False)
>>
>> is used by Seasons to display day, week, month or year ET, so not really 
>> able to be compared to a loop value.
>>
>> Gary
>>
>> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com wrote:
>>
>>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>>> help from Rich, have it working well.
>>> In the Seasons skin, I see that ET is reported at 100 times the value in 
>>> the loop packets.
>>> Loop has ET: 0.018
>>> Seasons displays ET 1.80 in
>>>
>>> Before I make an entry in weewx.conf StdCalibrate Corrections, where is 
>>> the value calculated for the Seasons skin?
>>> I only find items like these in the skin files:
>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>>> $obs.label.ET
>>> $unit.label.ET
>>> $archive.ET.sum.format(add_label=False)
>>>
>>>

-- 
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/efb9c3ec-e932-4167-85a1-f46783708102n%40googlegroups.com.

Re: [weewx-user] Re: gw1000 driver fail on wifi loss

I think the install instructions are clear and concise. At the end of the 
day if you choose not to follow them a degree of caveat emptor applies. I 
believe the current loop_on_init setting is appropriate and see no need to 
change it (experience shows if I did then the ‘stop polluting my logs’ 
brigade will start complaining).

Of course anyone is free to fork the driver...

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/c60dee92-4386-488d-a387-670758c4a6cfn%40googlegroups.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

I'm running a VP2+ via WiFiLogger2

This is a loop from my weewx instance:
LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 
25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, 
consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 
0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, 
inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, 
outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, 
usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, 
windGustDir: 247.0, windSpeed: 0.0

This is where it appears in Seasons skin.
[image: ET.png]
On Sunday, December 27, 2020 at 6:27:05 PM UTC-5 gjr80 wrote:

> Ultimately ET comes from either your driver or StdWXCalculate, depending 
> on the capabilities of your station (it could also come from another 
> service if your are running a driver that is capable of providing ET as a 
> service). Seasons draws ET data from the database. 
>
> When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
> display a number of different ET values/aggregates. Remember that the loop 
> packet value is the amount of ET in the period covered by the loop packet, 
>  Seasons can display the cumulative amount of ET over an archive period, a 
> day, a week, a month or a year depending on what you are looking at.
>
> This construct:
>
> $archive.ET.sum.format(add_label=False)
>
> is used by Seasons to display day, week, month or year ET, so not really 
> able to be compared to a loop value.
>
> Gary
>
> On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com wrote:
>
>> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting 
>> help from Rich, have it working well.
>> In the Seasons skin, I see that ET is reported at 100 times the value in 
>> the loop packets.
>> Loop has ET: 0.018
>> Seasons displays ET 1.80 in
>>
>> Before I make an entry in weewx.conf StdCalibrate Corrections, where is 
>> the value calculated for the Seasons skin?
>> I only find items like these in the skin files:
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
>> $obs.label.ET
>> $unit.label.ET
>> $archive.ET.sum.format(add_label=False)
>>
>>

-- 
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/d4816686-0177-4fc9-bdd9-f05d1ff5afcdn%40googlegroups.com.

Re: [weewx-user] Re: gw1000 driver fail on wifi loss

FWIW - I didn't do it via wee_config here, which likely explains what I got 
as a result.

I tend to install weewx with --no-prompt which defines using the simulator, 
then add the extension/driver, then hand-edit weewx.conf to point to the 
other driver once I get everything else edited in there.  Admittedly, 
that's not following the expected procedure I guess, but it does explain 
how I got my result here.

On Sunday, December 27, 2020 at 4:01:51 PM UTC-8 gjr80 wrote:

> > loop_on_init hadn't been set by the install script...
>
> Did you run wee_config —reconfigure to reconfigure WeeWX to use the GW1000 
> driver after installing the driver? wee_config —reconfigure will ask if you 
> want to set loop_on_init. If you did run wee_config —reconfigure did you 
> set loop_on_init or not? Did the resulting setting in weewx.conf agree 
> without you4 selection?
>
> loop_on_init is a general WeeWX option set in the top level of weewx.conf. 
> It is covered under General  in 
> The configuration file weewx.conf section 
>  in the Users Guide. 
> Placing it in [GW1000] will have no effect.
>
> Gary
> On Monday, 28 December 2020 at 09:36:33 UTC+10 lang@googlemail.com 
> wrote:
>
>> I had the same issue like Vince the other day - and  loop_on_init 
>> hadn't been set by the install script...
>> I assume it's to set in the [GW1000] stanza - that's where I added it now.
>>
>>
>>  Forwarded Message  
>> Subject: [weewx-user] Re: gw1000 driver fail on wifi loss 
>> Date: Sun, 27 Dec 2020 13:12:19 -0800 (PST) 
>> From: gjr80  
>> Reply-To: weewx...@googlegroups.com 
>> To: weewx-user  
>>
>> That would explain the behaviour then, if loop_on_init is not set the 
>> loss of connectivity with the station (for whatever reason) will cause 
>> WeeWX tobeen exit as it does with any other driver. I will make a point of 
>> pulling the network on my GW1000 and confirming the driver and loop_on_init 
>> work as expected. 
>>
>> Gary
>>
>> On Monday, 28 December 2020 at 07:08:28 UTC+10 vince wrote:
>>
>>> (unsure if this blasted google groups new interface ate my draft reply - 
>>> grr...) 
>>>
>>> loop_on_init was not set at all, so it's sure acting like the default is 
>>> False.
>>> I'll define it as True for the next time, which hopefully won't need 
>>> testing for a long time
>>>
>>> Thanks.
>>>
>>> On Sunday, December 27, 2020 at 11:53:08 AM UTC-8 gjr80 wrote:
>>>
 Vince, 

 Thank you. From memory the driver should retry continuously when the 
 network returns if loop_on_init = True in weewx.conf (though I am not sure 
 I tested this by turning of my network). Can you confirm the loop_on_init 
 setting at the time? 

 Gary

 On Monday, 28 December 2020 at 03:54:33 UTC+10 vince wrote:

> Gary - I wanted to pass along some logs from a gw1000 driver abort 
> yesterday. 
>
> I had my home network down for a bit yesterday to do some firmware 
> updates on my Ubiquiti USG, Switch and AcLite access point and weewx 
> aborted rather quickly. 
>
> The external, wired, and wifi networks were indeed down for some 
> minutes so missing some readings was expected, but I was hopeful that the 
> driver would recover gracefully after things were back up,  however weewx 
> totally aborted and the process was gone.
>
> Just passing along the logs in case you wanted to take a look.  Thanks.
>
>
>
> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
> live sensor data
> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main loop 
> exiting. Shutting engine down.
> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Shutting down 
> StdReport thread
> Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine: Unable to shut 
> down StdReport thread
> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
> live sensor data
> Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000: Gw1000Collector 
> thread has been terminated
> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught 
> WeeWxIOError: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' 
> after 3 attempts
> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:  
>  Waiting 60 seconds then retrying...
> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...
> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using configuration 
> file /etc/weewx/weewx.conf
> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0
> D

Re: [weewx-user] Re: gw1000 driver fail on wifi loss

> loop_on_init hadn't been set by the install script...

Did you run wee_config —reconfigure to reconfigure WeeWX to use the GW1000 
driver after installing the driver? wee_config —reconfigure will ask if you 
want to set loop_on_init. If you did run wee_config —reconfigure did you 
set loop_on_init or not? Did the resulting setting in weewx.conf agree 
without you4 selection?

loop_on_init is a general WeeWX option set in the top level of weewx.conf. 
It is covered under General  in 
The configuration file weewx.conf section 
 in the Users Guide. 
Placing it in [GW1000] will have no effect.

Gary
On Monday, 28 December 2020 at 09:36:33 UTC+10 lang@googlemail.com 
wrote:

> I had the same issue like Vince the other day - and  loop_on_init 
> hadn't been set by the install script...
> I assume it's to set in the [GW1000] stanza - that's where I added it now.
>
>
>  Forwarded Message  
> Subject: [weewx-user] Re: gw1000 driver fail on wifi loss 
> Date: Sun, 27 Dec 2020 13:12:19 -0800 (PST) 
> From: gjr80  
> Reply-To: weewx...@googlegroups.com 
> To: weewx-user  
>
> That would explain the behaviour then, if loop_on_init is not set the loss 
> of connectivity with the station (for whatever reason) will cause WeeWX 
> tobeen exit as it does with any other driver. I will make a point of 
> pulling the network on my GW1000 and confirming the driver and loop_on_init 
> work as expected. 
>
> Gary
>
> On Monday, 28 December 2020 at 07:08:28 UTC+10 vince wrote:
>
>> (unsure if this blasted google groups new interface ate my draft reply - 
>> grr...) 
>>
>> loop_on_init was not set at all, so it's sure acting like the default is 
>> False.
>> I'll define it as True for the next time, which hopefully won't need 
>> testing for a long time
>>
>> Thanks.
>>
>> On Sunday, December 27, 2020 at 11:53:08 AM UTC-8 gjr80 wrote:
>>
>>> Vince, 
>>>
>>> Thank you. From memory the driver should retry continuously when the 
>>> network returns if loop_on_init = True in weewx.conf (though I am not sure 
>>> I tested this by turning of my network). Can you confirm the loop_on_init 
>>> setting at the time? 
>>>
>>> Gary
>>>
>>> On Monday, 28 December 2020 at 03:54:33 UTC+10 vince wrote:
>>>
 Gary - I wanted to pass along some logs from a gw1000 driver abort 
 yesterday. 

 I had my home network down for a bit yesterday to do some firmware 
 updates on my Ubiquiti USG, Switch and AcLite access point and weewx 
 aborted rather quickly. 

 The external, wired, and wifi networks were indeed down for some 
 minutes so missing some readings was expected, but I was hopeful that the 
 driver would recover gracefully after things were back up,  however weewx 
 totally aborted and the process was gone.

 Just passing along the logs in case you wanted to take a look.  Thanks.



 Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
 response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
 Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
 live sensor data
 Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main loop 
 exiting. Shutting engine down.
 Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Shutting down 
 StdReport thread
 Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine: Unable to shut 
 down StdReport thread
 Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
 response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
 Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
 live sensor data
 Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000: Gw1000Collector 
 thread has been terminated
 Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught 
 WeeWxIOError: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' 
 after 3 attempts
 Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:   Waiting 
 60 seconds then retrying...
 Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...
 Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using configuration 
 file /etc/weewx/weewx.conf
 Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0
 Dec 26 16:27:44 pi3jr weewx[18939] INFO weewx.engine: Loading station 
 type GW1000 (user.gw1000)
 Dec 26 16:28:08 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
 response to command 'CMD_READ_STATION_MAC' after 3 attempts
 Dec 26 16:28:08 pi3jr weewx[18939] ERROR weewx.engine: Import of driver 
 failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 
 3 
 attempts ()
 Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
  Traceback (most recent call last):
 Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.e

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

an alternative to repurposing an existing data_type is to define an xtype (e.g. 
see https://github.com/g-eddy/weewx-vitalstats)

> On 28 Dec 2020, at 9:05 am, Kevin Chapman  wrote:
> 
> Thank you.  I will check it out.  
> 
> On Sun, Dec 27, 2020 at 6:00 AM Mike Revitt  > wrote:
> Sorry it has taken so long to respond to this, but I have just finished 
> documenting how I added the CPU Temperature to my website, this is all 
> documented here 
> 
>  
> https://www.cougar.eu.com/useful-guides/weewx-guides/rasberry-pi/read-cpu-temp.html
>  
> 

-- 
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/6B658B72-0127-4CA6-BC85-60A52CB0A9E7%40gmail.com.

[weewx-user] Re: gw1000 driver fail on wifi loss

2020-12-27 Thread Rainer Lang

I had the same issue like Vince the other day - and  loop_on_init 
hadn't been set by the install script...

I assume it's to set in the [GW1000] stanza - that's where I added it now.

 Forwarded Message 
Subject:[weewx-user] Re: gw1000 driver fail on wifi loss
Date:   Sun, 27 Dec 2020 13:12:19 -0800 (PST)
From:   gjr80 
Reply-To:   weewx-user@googlegroups.com
To: weewx-user 

That would explain the behaviour then, if loop_on_init is not set the 
loss of connectivity with the station (for whatever reason) will cause 
WeeWX tobeen exit as it does with any other driver. I will make a point 
of pulling the network on my GW1000 and confirming the driver and 
loop_on_init work as expected.

Gary

On Monday, 28 December 2020 at 07:08:28 UTC+10 vince wrote:

   (unsure if this blasted google groups new interface ate my draft
   reply - grr...)

   loop_on_init was not set at all, so it's sure acting like the
   default is False.
   I'll define it as True for the next time, which hopefully won't need
   testing for a long time

   Thanks.

   On Sunday, December 27, 2020 at 11:53:08 AM UTC-8 gjr80 wrote:

   Vince,

   Thank you. From memory the driver should retry continuously when
   the network returns if loop_on_init = True in weewx.conf (though
   I am not sure I tested this by turning of my network). Can you
   confirm the loop_on_init setting at the time?

   Gary

   On Monday, 28 December 2020 at 03:54:33 UTC+10 vince wrote:

   Gary - I wanted to pass along some logs from a gw1000 driver
   abort yesterday.

   I had my home network down for a bit yesterday to do some
   firmware updates on my Ubiquiti USG, Switch and AcLite
   access point and weewx aborted rather quickly.

   The external, wired, and wifi networks were indeed down for
   some minutes so missing some readings was expected, but I
   was hopeful that the driver would recover gracefully after
   things were back up,  however weewx totally aborted and the
   process was gone.

   Just passing along the logs in case you wanted to take a
   look.  Thanks.

   Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed
   to obtain response to command 'CMD_GW1000_LIVEDATA' after 3
   attempts
   Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable
   to obtain live sensor data
   Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main
   loop exiting. Shutting engine down.
   Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine:
   Shutting down StdReport thread
   Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine:
   Unable to shut down StdReport thread
   Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed
   to obtain response to command 'CMD_GW1000_LIVEDATA' after 3
   attempts
   Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable
   to obtain live sensor data
   Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000:
   Gw1000Collector thread has been terminated
   Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught
   WeeWxIOError: Failed to obtain response to command
   'CMD_GW1000_LIVEDATA' after 3 attempts
   Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:    
     Waiting 60 seconds then retrying...
   Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...
   Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using
   configuration file /etc/weewx/weewx.conf
   Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0
   Dec 26 16:27:44 pi3jr weewx[18939] INFO weewx.engine:
   Loading station type GW1000 (user.gw1000)
   Dec 26 16:28:08 pi3jr weewx[18939] ERROR user.gw1000: Failed
   to obtain response to command 'CMD_READ_STATION_MAC' after 3
   attempts
   Dec 26 16:28:08 pi3jr weewx[18939] ERROR weewx.engine:
   Import of driver failed: Failed to obtain response to
   command 'CMD_READ_STATION_MAC' after 3 attempts ()
   Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
    Traceback (most recent call last):
   Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
      File "/usr/share/weewx/weewx/engine.py", line
   109, in setupStation
   Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
        self.console = loader_function(config_dict, self)
   Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
      File "/usr/share/weewx/user/gw1000.py", line
   1293, in loader
   Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
        return Gw1000Driver

Re: [weewx-user] Re: gw1000 driver fail on wifi loss

suggestion: gw1000 install set loop_on_init to true by default. we will always 
have this kind of problem when the wifi (re)starts and weewx races ahead of it

> On 28 Dec 2020, at 8:12 am, gjr80  wrote:
> 
> That would explain the behaviour then, if loop_on_init is not set the loss of 
> connectivity with the station (for whatever reason) will cause WeeWX to exit 
> as it does with any other driver. I will make a point of pulling the network 
> on my GW1000 and confirming the driver and loop_on_init work as expected.

-- 
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/5BC374A7-1FB4-47B2-859B-B47A6F030715%40gmail.com.

[weewx-user] Re: ET Incorrect In Seasons Skin- Calculated Where?

Ultimately ET comes from either your driver or StdWXCalculate, depending on 
the capabilities of your station (it could also come from another service 
if your are running a driver that is capable of providing ET as a service). 
Seasons draws ET data from the database. 

When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can 
display a number of different ET values/aggregates. Remember that the loop 
packet value is the amount of ET in the period covered by the loop packet, 
 Seasons can display the cumulative amount of ET over an archive period, a 
day, a week, a month or a year depending on what you are looking at.

This construct:

$archive.ET.sum.format(add_label=False)

is used by Seasons to display day, week, month or year ET, so not really 
able to be compared to a loop value.

Gary

On Monday, 28 December 2020 at 08:58:49 UTC+10 gary@gmail.com wrote:

> I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting help 
> from Rich, have it working well.
> In the Seasons skin, I see that ET is reported at 100 times the value in 
> the loop packets.
> Loop has ET: 0.018
> Seasons displays ET 1.80 in
>
> Before I make an entry in weewx.conf StdCalibrate Corrections, where is 
> the value calculated for the Seasons skin?
> I only find items like these in the skin files:
> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
> #if $day.ET.has_data and $day.ET.sum.raw > 0.0
> $obs.label.ET
> $unit.label.ET
> $archive.ET.sum.format(add_label=False)
>
>

-- 
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/00d0ee35-1073-4e14-8143-fe3425132e00n%40googlegroups.com.

Re: [weewx-user] Re: Super simple skin

I have pared it down it even more - perhaps too much. ;-) The wind
alternates between current speed and recent (30 minute) max. (The
stylesheet background/border needs to be fixed a bit.)



http://robcranfill.net/weather/Crandard/


On Sun, Dec 27, 2020 at 14:54 Rob Cranfill  wrote:

> I’m glad you found it useful! Thanks for letting me know. Yes, STandard
> would be quite appropriate. :-)
>
>
> On Sun, Dec 27, 2020 at 07:17 Sven Täveby  wrote:
>
>> A big Thank You!
>> Made some changes and transladed to Swedish. Maybe I'll change the name
>> to STandard? :-)
>> http://teff.se/v2/Crandard
>> Outdoor/indoor/max ut/min out/rain today/rain totalt last 7 days/last
>> updated.
>>
>> Looks great on my wall, using a Raspberry Pi touchscreen (and a BME280
>> sensor to report indoor temp to weewx on the master Pi.
>> Cheers
>> /Sven
>>
>> Den söndag 8 november 2020 kl. 21:14:41 UTC+1 skrev Sven Täveby:
>>>
>>> Thx. Will check it out.
>>> /Sven
>>>
>>> söndag 8 november 2020 kl. 00:30:05 UTC+1 skrev robcr...@gmail.com:
>>>
 Sven, if you're addressing me, I've got it posted at

   https://github.com/RobCranfill/Crandard

 Does that work for you?
  /rob

 PS - I've gotten a little sidetracked from updating the code, because
 1) I can see that I will indeed be able to do what I want with WeeWX, but
 2) the hardware I was going to use to display it is proving to be a
 problem, so I'm re-thinking that. :-]

 On Saturday, November 7, 2020 at 1:33:44 PM UTC-8 sven@gmail.com
 wrote:

> Can You share that skin?
> Exactly what I want (except maybe units).
>
> /Sven
>
 --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/weewx-user/AKIAQ1knwvc/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/ef4c91fc-ffc2-49ca-9893-3cce73e25d97o%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/CAOVFAvqj38bGKvg65iRtCNb66yd%3D3RGVk%2BwjR2RLkRwiJXusXQ%40mail.gmail.com.

[weewx-user] ET Incorrect In Seasons Skin- Calculated Where?

I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting help 
from Rich, have it working well.
In the Seasons skin, I see that ET is reported at 100 times the value in 
the loop packets.
Loop has ET: 0.018
Seasons displays ET 1.80 in

Before I make an entry in weewx.conf StdCalibrate Corrections, where is the 
value calculated for the Seasons skin?
I only find items like these in the skin files:
#if $day.ET.has_data and $day.ET.sum.raw > 0.0
#if $day.ET.has_data and $day.ET.sum.raw > 0.0
$obs.label.ET
$unit.label.ET
$archive.ET.sum.format(add_label=False)

-- 
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/81787de8--4d16-b34e-80a951eba244n%40googlegroups.com.

Re: [weewx-user] Re: Super simple skin

I’m glad you found it useful! Thanks for letting me know. Yes, STandard
would be quite appropriate. :-)


On Sun, Dec 27, 2020 at 07:17 Sven Täveby  wrote:

> A big Thank You!
> Made some changes and transladed to Swedish. Maybe I'll change the name to
> STandard? :-)
> http://teff.se/v2/Crandard
> Outdoor/indoor/max ut/min out/rain today/rain totalt last 7 days/last
> updated.
>
> Looks great on my wall, using a Raspberry Pi touchscreen (and a BME280
> sensor to report indoor temp to weewx on the master Pi.
> Cheers
> /Sven
>
> Den söndag 8 november 2020 kl. 21:14:41 UTC+1 skrev Sven Täveby:
>>
>> Thx. Will check it out.
>> /Sven
>>
>> söndag 8 november 2020 kl. 00:30:05 UTC+1 skrev robcr...@gmail.com:
>>
>>> Sven, if you're addressing me, I've got it posted at
>>>
>>>   https://github.com/RobCranfill/Crandard
>>>
>>> Does that work for you?
>>>  /rob
>>>
>>> PS - I've gotten a little sidetracked from updating the code, because 1)
>>> I can see that I will indeed be able to do what I want with WeeWX, but 2)
>>> the hardware I was going to use to display it is proving to be a problem,
>>> so I'm re-thinking that. :-]
>>>
>>> On Saturday, November 7, 2020 at 1:33:44 PM UTC-8 sven@gmail.com
>>> wrote:
>>>
 Can You share that skin?
 Exactly what I want (except maybe units).

 /Sven

>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/AKIAQ1knwvc/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ef4c91fc-ffc2-49ca-9893-3cce73e25d97o%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/CAOVFAvrd4t53K0HNDkE1t6%2BG%3Dw25DSwTZ2Qv12ZUqNN9bT8yvQ%40mail.gmail.com.

[weewx-user] Unrecognized parameter from WH3000/WH2900

2020-12-27 Thread dohna...@gmail.com

Hi, I have PWS Eurochron EFWS2900 (Conrad brand). Its equl to Froggit WH300 
or Fine Offset WH2900 (od Ambient weather WS2902. Its version with internal 
station with display and wifi connection.
I resend data from it to my Weewx everythik works ok.
But when I type "sudo service weewx status" there are some wrong status:

Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter baromrelin=29.472
Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter maxdailygust=27.3
Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter totalrainin=0.000
Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter rainratein=0.000
Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter hourlyrainin=0.000
Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter freq=868M
Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter model=WS2900_V2.01.10
Dec 27 23:36:44 raspberrypi weewx[24055]: interceptor: MainThread: 
unrecognized parameter stationtype=EasyWeatherV1.5.6


Is there any way how to cerrect this?

-- 
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/38c928d0-6936-44e2-bd89-322208d85568n%40googlegroups.com.

[weewx-user] SFTP upload error ftplib.py

2020-12-27 Thread 'Stefan Ferber' via weewx-user

Cannot find the defect in my sftp configuration. Could you please check?

[[SmartphoneReport]]
# The SmartphoneReport uses the 'Smartphone' skin, and the images 
and
# files are placed in a dedicated subdirectory.
skin = Smartphone
enable = true 
HTML_ROOT = /var/www/html/weewx/smartphone

[[MobileReport]]
# The MobileReport uses the 'Mobile' skin, and the images and files
# are placed in a dedicated subdirectory.
skin = Mobile
enable = true 
HTML_ROOT = /var/www/html/weewx/mobile

[[StandardReport]]
# This is the old "Standard" skin. By default, it is not enabled.
skin = Standard
enable = false

[[FTP]]
# FTP'ing the results to a webserver is treated as just another 
report,
# albeit one with an unusual report generator!
skin = Ftp

# If you wish to use FTP, set "enable" to "true", then
# fill out the next four lines.
# Use quotes around passwords to guard against parsing errors.
enable = true 
user =   
password = ""
server = home15604585.1and1-data.host# The ftp server name, 
e.g, www.myserver.org
path = /SmartFerber/weewx# The destination directory, e.g., 
/weather

# Set to True for an FTP over TLS (FTPS) connection. Not all servers
# support this.
secure_ftp = true 

# To upload files from something other than what HTML_ROOT is set
# to above, specify a different HTML_ROOT here.
#HTML_ROOT = /var/www/html/weewx

# Most FTP servers use port 21
port = 22

# Set to 1 to use passive mode, zero for active mode
passive = 1

getting multiple errors:

Dec 27 22:35:51 raspberrypi weewx[24064] INFO weewx.cheetahgenerator: 
Generated 8 files for report SeasonsReport in 28.09 seconds
Dec 27 22:35:58 raspberrypi weewx[24064] INFO weewx.imagegenerator: 
Generated 15 images for report SeasonsReport in 6.71 seconds
Dec 27 22:35:58 raspberrypi weewx[24064] INFO weewx.reportengine: Copied 5 
files to /var/www/html/weewx
Dec 27 22:36:01 raspberrypi weewx[24064] INFO weewx.cheetahgenerator: 
Generated 6 files for report SmartphoneReport in 2.09 seconds
Dec 27 22:36:03 raspberrypi weewx[24064] INFO weewx.imagegenerator: 
Generated 6 images for report SmartphoneReport in 2.40 seconds
Dec 27 22:36:03 raspberrypi weewx[24064] INFO weewx.reportengine: Copied 6 
files to /var/www/html/weewx/smartphone
Dec 27 22:36:04 raspberrypi weewx[24064] INFO weewx.cheetahgenerator: 
Generated 1 files for report MobileReport in 0.78 seconds
Dec 27 22:36:06 raspberrypi weewx[24064] INFO weewx.imagegenerator: 
Generated 4 images for report MobileReport in 1.65 seconds
Dec 27 22:36:06 raspberrypi weewx[24064] INFO weewx.reportengine: Copied 2 
files to /var/www/html/weewx/mobile
Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine: 
ftpgenerator: (0): caught exception '': timed out
Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
   Traceback (most recent call last):
Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
 File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
   n = ftp_data.run()
Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
 File "/usr/share/weewx/weeutil/ftpupload.py", line 127, in run
Dec 27 22:36:26 raspberrypi weewx[24064] ERROR weewx.reportengine:
   ftp_server.connect(self.server, self.port)
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
 File "/usr/lib/python3.7/ftplib.py", line 155, in connect
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
   self.welcome = self.getresp()
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
 File "/usr/lib/python3.7/ftplib.py", line 236, in getresp
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
   resp = self.getmultiline()
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
 File "/usr/lib/python3.7/ftplib.py", line 226, in getmultiline
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
   nextline = self.getline()
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
 File "/usr/lib/python3.7/ftplib.py", line 204, in getline
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
   line = self.file.readline(self.maxline + 1)
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
 File "/usr/lib/python3.7/socket.py", line 589, in readinto
Dec 27 22:36:27 raspberrypi weewx[24064] ERROR weewx.reportengine:
   return self._sock.recv_into(b)
Dec 27 22:36:27 raspberrypi weewx[24064]

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem


Don’t really see this as being too much of an issue. The main python 2/3 
issue that seems to come up is lack of prerequisites (for whatever reason). 
Since WeeWX is running fine (with just an ftp error) this suggests all the 
prerequisites are there. I’d suggest you don’t go down the path of trying 
to change an existing python2 (WeeWX) install from python2 to python3 just 
yet or you may well start having prerequisites issues.

Gary
On Monday, 28 December 2020 at 07:16:24 UTC+10 kon...@apfelmanufaktur.de 
wrote:

> $ sudo cat /etc/os-release
> PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="10"
> VERSION="10 (buster)"
> VERSION_CODENAME=buster
> ID=raspbian
> ID_LIKE=debian
> HOME_URL="http://www.raspbian.org/";
> SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
> BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";
>
>
> Version 10.4
>
> $ sudo cat /boot/issue.txt
> Raspberry Pi reference 2020-08-20
> Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 
> 9a3a10bf1019ebb2d59053564dc6b90068bad27d, stage4
>
>
>
>
>
> vince schrieb am Sonntag, 27. Dezember 2020 um 21:54:26 UTC+1:
>
>> Also, your log had things in it like "/usr/lib/python2.7/socket.py" which 
>> tells me it is trying to use python2 when a modern raspi os uses python3 as 
>> the default.   Did you use the wrong instructions when you installed weewx 
>> ?  You should have used the python3 instructions.
>>
>> Please provide the output of:
>>
>>- sudo cat /etc/os-release
>>- sudo cat /etc/debian_version
>>- sudo cat /boot/issue.txt
>>
>>
>> On Sunday, December 27, 2020 at 12:22:13 PM UTC-8 gjr80 wrote:
>>
>>> I am no ftp expert but it seems you WeeWX machine is unable to resolve 
>>> your ftp server URL. Can you ftp  to 
>>> your ftp server from the command line on you WeeWX machine?
>>>
>>> Gary
>>>
>>> On Monday, 28 December 2020 at 06:15:20 UTC+10 kon...@apfelmanufaktur.de 
>>> wrote:
>>>
 thanks for the advice with the webserver, now I can reach the website! 
 Nice!
 I still have the FTP problem

 @ gjr80 here is the log file, I still cannot attach the file, I don't 
 know why

 Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: 
 File "/usr/lib/python2.7/Queue.py", line 177, in get
 Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
 self.not_empty.wait(remaining)
 Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: 
 File "/usr/lib/python2.7/threading.py", line 359, in wait
 Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
 _sleep(delay)
 Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: 
 File "/usr/share/weewx/weewxd", line 257, in sigTERMhandler
 Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
 raise Terminate
 Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
 Terminate
 Dec 27 20:58:09 raspberrypi weewx[2509]: Stopping weewx weather system: 
 weewx..
 Dec 27 20:58:09 raspberrypi systemd[1]: weewx.service: Succeeded.
 Dec 27 20:58:09 raspberrypi systemd[1]: Stopped LSB: weewx weather 
 system.
 Dec 27 20:58:50 raspberrypi systemd[1]: Starting LSB: weewx weather 
 system...
 Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Initializing 
 weewx version 4.2.0
 Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Using Python 
 2.7.16 (default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
 Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Platform 
 Linux-5.4.51-v7+-armv7l-with-debian-10.4
 Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Locale is 'de_DE'
 Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: PID file is 
 /var/run/weewx.pid
 Dec 27 20:58:51 raspberrypi weewx[2592]: Starting weewx weather system: 
 weewx.
 Dec 27 20:58:51 raspberrypi systemd[1]: Started LSB: weewx weather 
 system.
 Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Using 
 configuration file /etc/weewx/weewx.conf
 Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Debug is 1
 Dec 27 20:58:51 raspberrypi weewx[2609] DEBUG __main__: Initializing 
 engine
 Dec 27 20:58:51 raspberrypi weewx[2609] INFO weewx.engine: Loading 
 station type GW1000 (user.gw1000)
 Dec 27 20:58:51 raspberrypi weewx[2609] INFO user.gw1000: field map is 
 {'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 'daymaxwind': 
 'daymaxwind', 'dewpoint': 'dewpoint', 'extraHumid1': 'humid1', 
 'extraHumid2': 'humid2', 'extraHumid3': 'humid3', 'extraHumid4': 'humid4', 
 'extraHumid5': 'humid5', 'extraHumid6': 'humid6', 'extraHumid7': 'humid7', 
 'extraHumid8': 'humid8', 'extraTemp1': 'temp1', 'extraTemp2': 'temp2', 
 'extraTemp3': 'temp3', 'extraTemp4': 'temp4', 'extraTemp5': 'temp5', 
 'extraTemp6': 'temp6', '

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

$ sudo cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/";
SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";


Version 10.4

$ sudo cat /boot/issue.txt
Raspberry Pi reference 2020-08-20
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 
9a3a10bf1019ebb2d59053564dc6b90068bad27d, stage4





vince schrieb am Sonntag, 27. Dezember 2020 um 21:54:26 UTC+1:

> Also, your log had things in it like "/usr/lib/python2.7/socket.py" which 
> tells me it is trying to use python2 when a modern raspi os uses python3 as 
> the default.   Did you use the wrong instructions when you installed weewx 
> ?  You should have used the python3 instructions.
>
> Please provide the output of:
>
>- sudo cat /etc/os-release
>- sudo cat /etc/debian_version
>- sudo cat /boot/issue.txt
>
>
> On Sunday, December 27, 2020 at 12:22:13 PM UTC-8 gjr80 wrote:
>
>> I am no ftp expert but it seems you WeeWX machine is unable to resolve 
>> your ftp server URL. Can you ftp  to 
>> your ftp server from the command line on you WeeWX machine?
>>
>> Gary
>>
>> On Monday, 28 December 2020 at 06:15:20 UTC+10 kon...@apfelmanufaktur.de 
>> wrote:
>>
>>> thanks for the advice with the webserver, now I can reach the website! 
>>> Nice!
>>> I still have the FTP problem
>>>
>>> @ gjr80 here is the log file, I still cannot attach the file, I don't 
>>> know why
>>>
>>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
>>> "/usr/lib/python2.7/Queue.py", line 177, in get
>>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>>> self.not_empty.wait(remaining)
>>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
>>> "/usr/lib/python2.7/threading.py", line 359, in wait
>>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>>> _sleep(delay)
>>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
>>> "/usr/share/weewx/weewxd", line 257, in sigTERMhandler
>>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>>> raise Terminate
>>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>>> Terminate
>>> Dec 27 20:58:09 raspberrypi weewx[2509]: Stopping weewx weather system: 
>>> weewx..
>>> Dec 27 20:58:09 raspberrypi systemd[1]: weewx.service: Succeeded.
>>> Dec 27 20:58:09 raspberrypi systemd[1]: Stopped LSB: weewx weather 
>>> system.
>>> Dec 27 20:58:50 raspberrypi systemd[1]: Starting LSB: weewx weather 
>>> system...
>>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Initializing 
>>> weewx version 4.2.0
>>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Using Python 
>>> 2.7.16 (default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
>>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Platform 
>>> Linux-5.4.51-v7+-armv7l-with-debian-10.4
>>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Locale is 'de_DE'
>>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: PID file is 
>>> /var/run/weewx.pid
>>> Dec 27 20:58:51 raspberrypi weewx[2592]: Starting weewx weather system: 
>>> weewx.
>>> Dec 27 20:58:51 raspberrypi systemd[1]: Started LSB: weewx weather 
>>> system.
>>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Using 
>>> configuration file /etc/weewx/weewx.conf
>>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Debug is 1
>>> Dec 27 20:58:51 raspberrypi weewx[2609] DEBUG __main__: Initializing 
>>> engine
>>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO weewx.engine: Loading 
>>> station type GW1000 (user.gw1000)
>>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO user.gw1000: field map is 
>>> {'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 'daymaxwind': 
>>> 'daymaxwind', 'dewpoint': 'dewpoint', 'extraHumid1': 'humid1', 
>>> 'extraHumid2': 'humid2', 'extraHumid3': 'humid3', 'extraHumid4': 'humid4', 
>>> 'extraHumid5': 'humid5', 'extraHumid6': 'humid6', 'extraHumid7': 'humid7', 
>>> 'extraHumid8': 'humid8', 'extraTemp1': 'temp1', 'extraTemp2': 'temp2', 
>>> 'extraTemp3': 'temp3', 'extraTemp4': 'temp4', 'extraTemp5': 'temp5', 
>>> 'extraTemp6': 'temp6', 'extraTemp7': 'temp7', 'extraTemp8': 'temp8', 
>>> 'heatindex': 'heatindex', 'hourRain': 'rainhour', 'inHumidity': 'inhumid', 
>>> 'inTemp': 'intemp', 'leak1': 'leak1', 'leak2': 'leak2', 'leak3': 'leak3', 
>>> 'leak4': 'leak4', 'lightning_distance': 'lightningdist', 
>>> 'lightning_last_det_time': 'lightningdettime', 'lightning_strike_count': 
>>> 'lightning_strike_count', 'luminosity': 'light', 'monthRain': 'rainmonth', 
>>> 'outHumidity': 'outhumid', 'outTemp': 'outtemp', 'pm2_5': 'pm251', 
>>> 'pm2_51_24hav': 'pm251_24hav', 'pm2_52': 'pm252', 'pm2_52_24hav': 
>>> 'pm252_24hav', 'pm2_53': 'pm253', 'pm2_53_24hav': 'pm253_24hav', 'pm2_54

[weewx-user] Re: gw1000 driver fail on wifi loss

That would explain the behaviour then, if loop_on_init is not set the loss 
of connectivity with the station (for whatever reason) will cause WeeWX to 
exit as it does with any other driver. I will make a point of pulling the 
network on my GW1000 and confirming the driver and loop_on_init work as 
expected.

Gary

On Monday, 28 December 2020 at 07:08:28 UTC+10 vince wrote:

> (unsure if this blasted google groups new interface ate my draft reply - 
> grr...)
>
> loop_on_init was not set at all, so it's sure acting like the default is 
> False.
> I'll define it as True for the next time, which hopefully won't need 
> testing for a long time
>
> Thanks.
>
> On Sunday, December 27, 2020 at 11:53:08 AM UTC-8 gjr80 wrote:
>
>> Vince,
>>
>> Thank you. From memory the driver should retry continuously when the 
>> network returns if loop_on_init = True in weewx.conf (though I am not sure 
>> I tested this by turning of my network). Can you confirm the loop_on_init 
>> setting at the time?
>>
>> Gary
>>
>> On Monday, 28 December 2020 at 03:54:33 UTC+10 vince wrote:
>>
>>> Gary - I wanted to pass along some logs from a gw1000 driver abort 
>>> yesterday.
>>>
>>> I had my home network down for a bit yesterday to do some firmware 
>>> updates on my Ubiquiti USG, Switch and AcLite access point and weewx 
>>> aborted rather quickly.
>>>
>>> The external, wired, and wifi networks were indeed down for some minutes 
>>> so missing some readings was expected, but I was hopeful that the driver 
>>> would recover gracefully after things were back up,  however weewx totally 
>>> aborted and the process was gone.
>>>
>>> Just passing along the logs in case you wanted to take a look.  Thanks.
>>>
>>>
>>>
>>> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
>>> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
>>> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
>>> live sensor data
>>> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main loop exiting. 
>>> Shutting engine down.
>>> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Shutting down 
>>> StdReport thread
>>> Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine: Unable to shut 
>>> down StdReport thread
>>> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
>>> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
>>> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
>>> live sensor data
>>> Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000: Gw1000Collector 
>>> thread has been terminated
>>> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught 
>>> WeeWxIOError: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' 
>>> after 3 attempts
>>> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:   Waiting 
>>> 60 seconds then retrying...
>>> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...
>>> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using configuration 
>>> file /etc/weewx/weewx.conf
>>> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0
>>> Dec 26 16:27:44 pi3jr weewx[18939] INFO weewx.engine: Loading station 
>>> type GW1000 (user.gw1000)
>>> Dec 26 16:28:08 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
>>> response to command 'CMD_READ_STATION_MAC' after 3 attempts
>>> Dec 26 16:28:08 pi3jr weewx[18939] ERROR weewx.engine: Import of driver 
>>> failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
>>> attempts ()
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>>  Traceback (most recent call last):
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>>  File "/usr/share/weewx/weewx/engine.py", line 109, in setupStation
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>>  self.console = loader_function(config_dict, self)
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>>  File "/usr/share/weewx/user/gw1000.py", line 1293, in loader
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>>  return Gw1000Driver(**config_dict[DRIVER_NAME])
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>>  File "/usr/share/weewx/user/gw1000.py", line 1568, in __init__
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>>  super(Gw1000Driver, self).__init__(**stn_dict)
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>>  File "/usr/share/weewx/user/gw1000.py", line 767, in __init__
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>>  debug_wind=self.debug_wind)
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>>  File "/usr/share/weewx/user/gw1000.py", line 1870, in __init__
>>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>>  lost_contact_log_period=lost_contact_log_period)
>>> Dec 26 16:28:08 pi3

[weewx-user] Re: gw1000 driver fail on wifi loss

(unsure if this blasted google groups new interface ate my draft reply - 
grr...)

loop_on_init was not set at all, so it's sure acting like the default is 
False.
I'll define it as True for the next time, which hopefully won't need 
testing for a long time

Thanks.

On Sunday, December 27, 2020 at 11:53:08 AM UTC-8 gjr80 wrote:

> Vince,
>
> Thank you. From memory the driver should retry continuously when the 
> network returns if loop_on_init = True in weewx.conf (though I am not sure 
> I tested this by turning of my network). Can you confirm the loop_on_init 
> setting at the time?
>
> Gary
>
> On Monday, 28 December 2020 at 03:54:33 UTC+10 vince wrote:
>
>> Gary - I wanted to pass along some logs from a gw1000 driver abort 
>> yesterday.
>>
>> I had my home network down for a bit yesterday to do some firmware 
>> updates on my Ubiquiti USG, Switch and AcLite access point and weewx 
>> aborted rather quickly.
>>
>> The external, wired, and wifi networks were indeed down for some minutes 
>> so missing some readings was expected, but I was hopeful that the driver 
>> would recover gracefully after things were back up,  however weewx totally 
>> aborted and the process was gone.
>>
>> Just passing along the logs in case you wanted to take a look.  Thanks.
>>
>>
>>
>> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
>> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
>> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
>> live sensor data
>> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main loop exiting. 
>> Shutting engine down.
>> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Shutting down 
>> StdReport thread
>> Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine: Unable to shut 
>> down StdReport thread
>> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
>> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
>> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
>> live sensor data
>> Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000: Gw1000Collector 
>> thread has been terminated
>> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught 
>> WeeWxIOError: Failed to obtain response to command 'CMD_GW1000_LIVEDATA' 
>> after 3 attempts
>> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:   Waiting 
>> 60 seconds then retrying...
>> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...
>> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using configuration 
>> file /etc/weewx/weewx.conf
>> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0
>> Dec 26 16:27:44 pi3jr weewx[18939] INFO weewx.engine: Loading station 
>> type GW1000 (user.gw1000)
>> Dec 26 16:28:08 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
>> response to command 'CMD_READ_STATION_MAC' after 3 attempts
>> Dec 26 16:28:08 pi3jr weewx[18939] ERROR weewx.engine: Import of driver 
>> failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
>> attempts ()
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  Traceback (most recent call last):
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/weewx/engine.py", line 109, in setupStation
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  self.console = loader_function(config_dict, self)
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/user/gw1000.py", line 1293, in loader
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  return Gw1000Driver(**config_dict[DRIVER_NAME])
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/user/gw1000.py", line 1568, in __init__
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  super(Gw1000Driver, self).__init__(**stn_dict)
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/user/gw1000.py", line 767, in __init__
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  debug_wind=self.debug_wind)
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/user/gw1000.py", line 1870, in __init__
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  lost_contact_log_period=lost_contact_log_period)
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/user/gw1000.py", line 2276, in __init__
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  self.mac = self.get_mac_address()
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/user/gw1000.py", line 2407, in get_mac_address
>> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>>  return self.send_cmd_wi

[weewx-user] Missing channel 5 for TE923 in html-report

2020-12-27 Thread 'Stefan Ferber' via weewx-user

Thx for providing WeeWx - really impressed by the ease of installation and 
configuration options. Running for two weeks now ;-)

I have 5 external sensors (temp, humidity, battery status) connected to my 
TE923. WeeWx is fetching the data correctly 
$ sudo wee_device --current
Using configuration file /etc/weewx/weewx.conf
Using TE923 driver version 0.41.1 (weewx.drivers.te923)
Querying the station for current weather data...
dateTime: 1609093626
forecast: 0
 h_1: 64
   h_1_state: ok
 h_2: 38
   h_2_state: ok
 h_3: 41
   h_3_state: ok
 h_4: 47
   h_4_state: ok
 h_5: 37
   h_5_state: ok
h_in: 36
  h_in_state: ok
rain: 3087
  rain_state: ok
 slp: 948.625
   slp_state: ok
   storm: 0
 t_1: 2.7
   t_1_state: ok
 t_2: 22.1
   t_2_state: ok
 t_3: 20.8
   t_3_state: ok
 t_4: 21.6
   t_4_state: ok
 t_5: 20.8
   t_5_state: ok
t_in: 22.85
  t_in_state: ok
  uv: None
uv_state: no_link
   windchill: 1.9
 windchill_state: ok
 winddir: 2
   winddir_state: ok
windgust: 0.0
  windgust_state: ok
   windspeed: 0.0
 windspeed_state: ok

but the last channel 5 is not shown in the temperature graphs.  The mapping 
is a little bit confusing but this graph should show 4 channels but is 
providing only 3 channels. 
[image: daytemp.png]

Therefore, I added a new line for the missing channel "extraTemp4" in the 
weewx.conf 
and change the names to my rooms:

# The labels to be used for each observation type
[[[Labels]]]

# Set to hemisphere abbreviations suitable for your location:
hemispheres = N, S, E, W

# Formats to be used for latitude whole degrees, longitude whole
# degrees, and minutes:
latlon_formats = %02d, %03d, %05.2f

# Generic labels, keyed by an observation type.
Generic
barometer = Barometer
<...>
windvec = Wind Vector
extraTemp1 = Living Room
extraTemp2 = Kitchen
extraTemp3 = Bath
extraTemp4 = Kids Room

But the report still contains only 3 channels. 
[image: daytemp (1).png]


What do I have to do 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/8cd66287-dc9a-45be-9f6d-47848d2c10b3n%40googlegroups.com.

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

Also, your log had things in it like "/usr/lib/python2.7/socket.py" which 
tells me it is trying to use python2 when a modern raspi os uses python3 as 
the default.   Did you use the wrong instructions when you installed weewx 
?  You should have used the python3 instructions.

Please provide the output of:

   - sudo cat /etc/os-release
   - sudo cat /etc/debian_version
   - sudo cat /boot/issue.txt


On Sunday, December 27, 2020 at 12:22:13 PM UTC-8 gjr80 wrote:

> I am no ftp expert but it seems you WeeWX machine is unable to resolve 
> your ftp server URL. Can you ftp  to 
> your ftp server from the command line on you WeeWX machine?
>
> Gary
>
> On Monday, 28 December 2020 at 06:15:20 UTC+10 kon...@apfelmanufaktur.de 
> wrote:
>
>> thanks for the advice with the webserver, now I can reach the website! 
>> Nice!
>> I still have the FTP problem
>>
>> @ gjr80 here is the log file, I still cannot attach the file, I don't 
>> know why
>>
>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
>> "/usr/lib/python2.7/Queue.py", line 177, in get
>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>> self.not_empty.wait(remaining)
>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
>> "/usr/lib/python2.7/threading.py", line 359, in wait
>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>> _sleep(delay)
>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
>> "/usr/share/weewx/weewxd", line 257, in sigTERMhandler
>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>> raise Terminate
>> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
>> Terminate
>> Dec 27 20:58:09 raspberrypi weewx[2509]: Stopping weewx weather system: 
>> weewx..
>> Dec 27 20:58:09 raspberrypi systemd[1]: weewx.service: Succeeded.
>> Dec 27 20:58:09 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
>> Dec 27 20:58:50 raspberrypi systemd[1]: Starting LSB: weewx weather 
>> system...
>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Initializing weewx 
>> version 4.2.0
>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Using Python 
>> 2.7.16 (default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Platform 
>> Linux-5.4.51-v7+-armv7l-with-debian-10.4
>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Locale is 'de_DE'
>> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: PID file is 
>> /var/run/weewx.pid
>> Dec 27 20:58:51 raspberrypi weewx[2592]: Starting weewx weather system: 
>> weewx.
>> Dec 27 20:58:51 raspberrypi systemd[1]: Started LSB: weewx weather system.
>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Using 
>> configuration file /etc/weewx/weewx.conf
>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Debug is 1
>> Dec 27 20:58:51 raspberrypi weewx[2609] DEBUG __main__: Initializing 
>> engine
>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO weewx.engine: Loading 
>> station type GW1000 (user.gw1000)
>> Dec 27 20:58:51 raspberrypi weewx[2609] INFO user.gw1000: field map is 
>> {'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 'daymaxwind': 
>> 'daymaxwind', 'dewpoint': 'dewpoint', 'extraHumid1': 'humid1', 
>> 'extraHumid2': 'humid2', 'extraHumid3': 'humid3', 'extraHumid4': 'humid4', 
>> 'extraHumid5': 'humid5', 'extraHumid6': 'humid6', 'extraHumid7': 'humid7', 
>> 'extraHumid8': 'humid8', 'extraTemp1': 'temp1', 'extraTemp2': 'temp2', 
>> 'extraTemp3': 'temp3', 'extraTemp4': 'temp4', 'extraTemp5': 'temp5', 
>> 'extraTemp6': 'temp6', 'extraTemp7': 'temp7', 'extraTemp8': 'temp8', 
>> 'heatindex': 'heatindex', 'hourRain': 'rainhour', 'inHumidity': 'inhumid', 
>> 'inTemp': 'intemp', 'leak1': 'leak1', 'leak2': 'leak2', 'leak3': 'leak3', 
>> 'leak4': 'leak4', 'lightning_distance': 'lightningdist', 
>> 'lightning_last_det_time': 'lightningdettime', 'lightning_strike_count': 
>> 'lightning_strike_count', 'luminosity': 'light', 'monthRain': 'rainmonth', 
>> 'outHumidity': 'outhumid', 'outTemp': 'outtemp', 'pm2_5': 'pm251', 
>> 'pm2_51_24hav': 'pm251_24hav', 'pm2_52': 'pm252', 'pm2_52_24hav': 
>> 'pm252_24hav', 'pm2_53': 'pm253', 'pm2_53_24hav': 'pm253_24hav', 'pm2_54': 
>> 'pm254', 'pm2_54_24hav': 'pm254_24hav', 'pressure': 'absbarometer', 'rain': 
>> 'rain', 'rainRate': 'rainrate', 'relbarometer': 'relbarometer', 
>> 'soilMoist1': 'soilmoist1', 'soilMoist2': 'soilmoist2', 'soilMoist3': 
>> 'soilmoist3', 'soilMoist4': 'soilmoist4', 'soilMoist5': 'soilmoist5', 
>> 'soilMoist6': 'soilmoist6', 'soilMoist7': 'soilmoist7', 'soilMoist8': 
>> 'soilmoist8', 'soilMoist9': 'soilmoist9', 'soilMoist10': 'soilmoist10', 
>> 'soilMoist11': 'soilmoist11', 'soilMoist12': 'soilmoist12', 'soilMoist13': 
>> 'soilmoist13', 'soilMoist14': 'soilmoist14', 'soilMoist15': 'soilmoist15', 
>> 'soilMoist16': 'soilmoist16', 'soilTemp1': 'soiltemp1', 'soilTemp2': 
>> 'soiltemp2'

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

I am no ftp expert but it seems you WeeWX machine is unable to resolve your 
ftp server URL. Can you ftp  to your ftp 
server from the command line on you WeeWX machine?

Gary

On Monday, 28 December 2020 at 06:15:20 UTC+10 kon...@apfelmanufaktur.de 
wrote:

> thanks for the advice with the webserver, now I can reach the website! 
> Nice!
> I still have the FTP problem
>
> @ gjr80 here is the log file, I still cannot attach the file, I don't know 
> why
>
> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
> "/usr/lib/python2.7/Queue.py", line 177, in get
> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
> self.not_empty.wait(remaining)
> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
> "/usr/lib/python2.7/threading.py", line 359, in wait
> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
> _sleep(delay)
> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
> "/usr/share/weewx/weewxd", line 257, in sigTERMhandler
> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
> raise Terminate
> Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   Terminate
> Dec 27 20:58:09 raspberrypi weewx[2509]: Stopping weewx weather system: 
> weewx..
> Dec 27 20:58:09 raspberrypi systemd[1]: weewx.service: Succeeded.
> Dec 27 20:58:09 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
> Dec 27 20:58:50 raspberrypi systemd[1]: Starting LSB: weewx weather 
> system...
> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Initializing weewx 
> version 4.2.0
> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Using Python 2.7.16 
> (default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Platform 
> Linux-5.4.51-v7+-armv7l-with-debian-10.4
> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Locale is 'de_DE'
> Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: PID file is 
> /var/run/weewx.pid
> Dec 27 20:58:51 raspberrypi weewx[2592]: Starting weewx weather system: 
> weewx.
> Dec 27 20:58:51 raspberrypi systemd[1]: Started LSB: weewx weather system.
> Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Using configuration 
> file /etc/weewx/weewx.conf
> Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Debug is 1
> Dec 27 20:58:51 raspberrypi weewx[2609] DEBUG __main__: Initializing engine
> Dec 27 20:58:51 raspberrypi weewx[2609] INFO weewx.engine: Loading station 
> type GW1000 (user.gw1000)
> Dec 27 20:58:51 raspberrypi weewx[2609] INFO user.gw1000: field map is 
> {'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 'daymaxwind': 
> 'daymaxwind', 'dewpoint': 'dewpoint', 'extraHumid1': 'humid1', 
> 'extraHumid2': 'humid2', 'extraHumid3': 'humid3', 'extraHumid4': 'humid4', 
> 'extraHumid5': 'humid5', 'extraHumid6': 'humid6', 'extraHumid7': 'humid7', 
> 'extraHumid8': 'humid8', 'extraTemp1': 'temp1', 'extraTemp2': 'temp2', 
> 'extraTemp3': 'temp3', 'extraTemp4': 'temp4', 'extraTemp5': 'temp5', 
> 'extraTemp6': 'temp6', 'extraTemp7': 'temp7', 'extraTemp8': 'temp8', 
> 'heatindex': 'heatindex', 'hourRain': 'rainhour', 'inHumidity': 'inhumid', 
> 'inTemp': 'intemp', 'leak1': 'leak1', 'leak2': 'leak2', 'leak3': 'leak3', 
> 'leak4': 'leak4', 'lightning_distance': 'lightningdist', 
> 'lightning_last_det_time': 'lightningdettime', 'lightning_strike_count': 
> 'lightning_strike_count', 'luminosity': 'light', 'monthRain': 'rainmonth', 
> 'outHumidity': 'outhumid', 'outTemp': 'outtemp', 'pm2_5': 'pm251', 
> 'pm2_51_24hav': 'pm251_24hav', 'pm2_52': 'pm252', 'pm2_52_24hav': 
> 'pm252_24hav', 'pm2_53': 'pm253', 'pm2_53_24hav': 'pm253_24hav', 'pm2_54': 
> 'pm254', 'pm2_54_24hav': 'pm254_24hav', 'pressure': 'absbarometer', 'rain': 
> 'rain', 'rainRate': 'rainrate', 'relbarometer': 'relbarometer', 
> 'soilMoist1': 'soilmoist1', 'soilMoist2': 'soilmoist2', 'soilMoist3': 
> 'soilmoist3', 'soilMoist4': 'soilmoist4', 'soilMoist5': 'soilmoist5', 
> 'soilMoist6': 'soilmoist6', 'soilMoist7': 'soilmoist7', 'soilMoist8': 
> 'soilmoist8', 'soilMoist9': 'soilmoist9', 'soilMoist10': 'soilmoist10', 
> 'soilMoist11': 'soilmoist11', 'soilMoist12': 'soilmoist12', 'soilMoist13': 
> 'soilmoist13', 'soilMoist14': 'soilmoist14', 'soilMoist15': 'soilmoist15', 
> 'soilMoist16': 'soilmoist16', 'soilTemp1': 'soiltemp1', 'soilTemp2': 
> 'soiltemp2', 'soilTemp3': 'soiltemp3', 'soilTemp4': 'soiltemp4', 
> 'soilTemp5': 'soiltemp5', 'soilTemp6': 'soiltemp6', 'soilTemp7': 
> 'soiltemp7', 'soilTemp8': 'soiltemp8', 'soilTemp9': 'soiltemp9', 
> 'soilTemp10': 'soiltemp10', 'soilTemp11': 'soiltemp11', 'soilTemp12': 
> 'soiltemp12', 'soilTemp13': 'soiltemp13', 'soilTemp14': 'soiltemp14', 
> 'soilTemp15': 'soiltemp15', 'soilTemp16': 'soiltemp16', 'stormRain': 
> 'rainevent', 'totalRain': 'raintotals', 'uvradiation': 'uv', 'weekRain': 
> 'rainweek', 'wh25_batt': 'wh25_batt', 'wh26_batt': 'wh26_batt', 
> 'wh31_ch1

Re: [weewx-user] Weewx Seasons Skin Monthly & Yearly Reports dropdown menus do not work

2020-12-27 Thread mwall

On Sunday, December 27, 2020 at 11:08:46 AM UTC-5 72604... wrote:

> Hi TK.  What is the function of the "tabular.html?report=" portion of the 
> address?  Is this something that gets filled in when you have a webserver 
> installed?  

the javascript in tabular.html uses the 'report=xxx' to determine which 
NOAA file should be displayed.  when you read tabular.html directly (i.e., 
no web server), your browser interprets the javascript but refuses to open 
the file, since most browsers now consider opening a file to be a nefarious 
activity.

it just happens that the path is 'NOAA/xxx' so that when you remove the 
'?report=' the url is simply a path, not a path plus cgi arguments.

-- 
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/a8e707eb-95ba-40b0-b16c-038a19fa09f4n%40googlegroups.com.

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

thanks for the advice with the webserver, now I can reach the website! Nice!
I still have the FTP problem

@ gjr80 here is the log file, I still cannot attach the file, I don't know 
why

Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
"/usr/lib/python2.7/Queue.py", line 177, in get
Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
self.not_empty.wait(remaining)
Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
"/usr/lib/python2.7/threading.py", line 359, in wait
Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   
_sleep(delay)
Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__: File 
"/usr/share/weewx/weewxd", line 257, in sigTERMhandler
Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   raise 
Terminate
Dec 27 20:58:04 raspberrypi weewx[2469] DEBUG __main__:   Terminate
Dec 27 20:58:09 raspberrypi weewx[2509]: Stopping weewx weather system: 
weewx..
Dec 27 20:58:09 raspberrypi systemd[1]: weewx.service: Succeeded.
Dec 27 20:58:09 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Dec 27 20:58:50 raspberrypi systemd[1]: Starting LSB: weewx weather 
system...
Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Initializing weewx 
version 4.2.0
Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Using Python 2.7.16 
(default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Platform 
Linux-5.4.51-v7+-armv7l-with-debian-10.4
Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: Locale is 'de_DE'
Dec 27 20:58:51 raspberrypi weewx[2605] INFO __main__: PID file is 
/var/run/weewx.pid
Dec 27 20:58:51 raspberrypi weewx[2592]: Starting weewx weather system: 
weewx.
Dec 27 20:58:51 raspberrypi systemd[1]: Started LSB: weewx weather system.
Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Using configuration 
file /etc/weewx/weewx.conf
Dec 27 20:58:51 raspberrypi weewx[2609] INFO __main__: Debug is 1
Dec 27 20:58:51 raspberrypi weewx[2609] DEBUG __main__: Initializing engine
Dec 27 20:58:51 raspberrypi weewx[2609] INFO weewx.engine: Loading station 
type GW1000 (user.gw1000)
Dec 27 20:58:51 raspberrypi weewx[2609] INFO user.gw1000: field map is 
{'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 'daymaxwind': 
'daymaxwind', 'dewpoint': 'dewpoint', 'extraHumid1': 'humid1', 
'extraHumid2': 'humid2', 'extraHumid3': 'humid3', 'extraHumid4': 'humid4', 
'extraHumid5': 'humid5', 'extraHumid6': 'humid6', 'extraHumid7': 'humid7', 
'extraHumid8': 'humid8', 'extraTemp1': 'temp1', 'extraTemp2': 'temp2', 
'extraTemp3': 'temp3', 'extraTemp4': 'temp4', 'extraTemp5': 'temp5', 
'extraTemp6': 'temp6', 'extraTemp7': 'temp7', 'extraTemp8': 'temp8', 
'heatindex': 'heatindex', 'hourRain': 'rainhour', 'inHumidity': 'inhumid', 
'inTemp': 'intemp', 'leak1': 'leak1', 'leak2': 'leak2', 'leak3': 'leak3', 
'leak4': 'leak4', 'lightning_distance': 'lightningdist', 
'lightning_last_det_time': 'lightningdettime', 'lightning_strike_count': 
'lightning_strike_count', 'luminosity': 'light', 'monthRain': 'rainmonth', 
'outHumidity': 'outhumid', 'outTemp': 'outtemp', 'pm2_5': 'pm251', 
'pm2_51_24hav': 'pm251_24hav', 'pm2_52': 'pm252', 'pm2_52_24hav': 
'pm252_24hav', 'pm2_53': 'pm253', 'pm2_53_24hav': 'pm253_24hav', 'pm2_54': 
'pm254', 'pm2_54_24hav': 'pm254_24hav', 'pressure': 'absbarometer', 'rain': 
'rain', 'rainRate': 'rainrate', 'relbarometer': 'relbarometer', 
'soilMoist1': 'soilmoist1', 'soilMoist2': 'soilmoist2', 'soilMoist3': 
'soilmoist3', 'soilMoist4': 'soilmoist4', 'soilMoist5': 'soilmoist5', 
'soilMoist6': 'soilmoist6', 'soilMoist7': 'soilmoist7', 'soilMoist8': 
'soilmoist8', 'soilMoist9': 'soilmoist9', 'soilMoist10': 'soilmoist10', 
'soilMoist11': 'soilmoist11', 'soilMoist12': 'soilmoist12', 'soilMoist13': 
'soilmoist13', 'soilMoist14': 'soilmoist14', 'soilMoist15': 'soilmoist15', 
'soilMoist16': 'soilmoist16', 'soilTemp1': 'soiltemp1', 'soilTemp2': 
'soiltemp2', 'soilTemp3': 'soiltemp3', 'soilTemp4': 'soiltemp4', 
'soilTemp5': 'soiltemp5', 'soilTemp6': 'soiltemp6', 'soilTemp7': 
'soiltemp7', 'soilTemp8': 'soiltemp8', 'soilTemp9': 'soiltemp9', 
'soilTemp10': 'soiltemp10', 'soilTemp11': 'soiltemp11', 'soilTemp12': 
'soiltemp12', 'soilTemp13': 'soiltemp13', 'soilTemp14': 'soiltemp14', 
'soilTemp15': 'soiltemp15', 'soilTemp16': 'soiltemp16', 'stormRain': 
'rainevent', 'totalRain': 'raintotals', 'uvradiation': 'uv', 'weekRain': 
'rainweek', 'wh25_batt': 'wh25_batt', 'wh26_batt': 'wh26_batt', 
'wh31_ch1_batt': 'wh31_ch1_batt', 'wh31_ch2_batt': 'wh31_ch2_batt', 
'wh31_ch3_batt': 'wh31_ch3_batt', 'wh31_ch4_batt': 'wh31_ch4_batt', 
'wh31_ch5_batt': 'wh31_ch5_batt', 'wh31_ch6_batt': 'wh31_ch6_batt', 
'wh31_ch7_batt': 'wh31_ch7_batt', 'wh31_ch8_batt': 'wh31_ch8_batt', 
'wh40_batt': 'wh40_batt', 'wh41_ch1_batt': 'wh41_ch1_batt', 
'wh41_ch2_batt': 'wh41_ch2_batt', 'wh41_ch3_batt': 'wh41_ch3_batt', 
'wh41_ch4_batt': 'wh41_ch4_batt', 'wh51_ch1_batt':

[weewx-user] Re: gw1000 driver fail on wifi loss

Vince,

Thank you. From memory the driver should retry continuously when the 
network returns if loop_on_init = True in weewx.conf (though I am not sure 
I tested this by turning of my network). Can you confirm the loop_on_init 
setting at the time?

Gary

On Monday, 28 December 2020 at 03:54:33 UTC+10 vince wrote:

> Gary - I wanted to pass along some logs from a gw1000 driver abort 
> yesterday.
>
> I had my home network down for a bit yesterday to do some firmware updates 
> on my Ubiquiti USG, Switch and AcLite access point and weewx aborted rather 
> quickly.
>
> The external, wired, and wifi networks were indeed down for some minutes 
> so missing some readings was expected, but I was hopeful that the driver 
> would recover gracefully after things were back up,  however weewx totally 
> aborted and the process was gone.
>
> Just passing along the logs in case you wanted to take a look.  Thanks.
>
>
>
> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
> Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
> live sensor data
> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main loop exiting. 
> Shutting engine down.
> Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Shutting down 
> StdReport thread
> Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine: Unable to shut down 
> StdReport thread
> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
> response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
> Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain 
> live sensor data
> Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000: Gw1000Collector 
> thread has been terminated
> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught WeeWxIOError: 
> Failed to obtain response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
> Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:   Waiting 60 
> seconds then retrying...
> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...
> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using configuration file 
> /etc/weewx/weewx.conf
> Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0
> Dec 26 16:27:44 pi3jr weewx[18939] INFO weewx.engine: Loading station type 
> GW1000 (user.gw1000)
> Dec 26 16:28:08 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
> response to command 'CMD_READ_STATION_MAC' after 3 attempts
> Dec 26 16:28:08 pi3jr weewx[18939] ERROR weewx.engine: Import of driver 
> failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
> attempts ()
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  Traceback (most recent call last):
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/weewx/engine.py", line 109, in setupStation
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  self.console = loader_function(config_dict, self)
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/user/gw1000.py", line 1293, in loader
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  return Gw1000Driver(**config_dict[DRIVER_NAME])
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/user/gw1000.py", line 1568, in __init__
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  super(Gw1000Driver, self).__init__(**stn_dict)
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/user/gw1000.py", line 767, in __init__
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  debug_wind=self.debug_wind)
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/user/gw1000.py", line 1870, in __init__
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  lost_contact_log_period=lost_contact_log_period)
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/user/gw1000.py", line 2276, in __init__
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  self.mac = self.get_mac_address()
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/user/gw1000.py", line 2407, in get_mac_address
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
> "/usr/share/weewx/user/gw1000.py", line 2532, in send_cmd_with_retries
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  raise GW1000IOError(_msg)
> Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
>  user.gw1000.GW1000IOError: Failed to obtain response to command 
> 'CMD_READ_

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

Hi,

Really going to see that log. The wiki entry Help! Posting to weewx user 
 might 
help.

Alternatively, try copy and pasting directly rather than attaching a file. 
While you are at it can you make sure you set debug = 1 in weewx.conf and 
you restart WeeWX and let it run for a few archive periods. Then take a 
copy and of the log from when you started WeeWX through until the few 
archive periods have elapsed. Post the log extract here. 

Gary
On Monday, 28 December 2020 at 02:05:17 UTC+10 kon...@apfelmanufaktur.de 
wrote:

> I cannot attach my log files, why ?
>
>

-- 
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/2a392907-ac71-450d-8e4f-9a364667577dn%40googlegroups.com.

Re: [weewx-user] Fallback reading possible?


correction: the panel shoulndn't exceed 3.6V...
michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 19:17:11 UTC+1:

> @Peter Quinn, thank you. I'll check the weewx part!
>
> Just my 2 off-topic cents: using the breadboard the voltage regulator and 
> the UART, powered by 5V ist a very inefficient way to run this sensor. The 
> simplest approach to get more time from the solar/battery combo would be to 
> use a 3V solar panel (which should exceed a maximum idle voltage of 3.6V) 
> and directly charge a LiFe battery with it. If you ensure that the ESP 
> powers off (deep sleep) at the ESP lower limit (datasheet says 2.5V, my 
> experience says ~2.3V) the LiFe lower discharge limit (2,0V) will probably 
> never be reached. Even with your LiPo this should be possible this way, but 
> you can't use all capacity, since you can't charge it over 3.6V, because 
> this would kill the esp.
>
> In brief:
> - don't use such a breadboard or remove the voltage regulator and the 
> UARTs supply
> - connect a LiFe directly to 3V3 and GND
> - connect a 3V solar panel directly to 3V3 and GND
> - ensure to power off the ESP when it reaches it's minimum required 
> voltage (maybe it's never reached), either with a protection circuit 
> (preferred) or the ESPs internal voltage measurement ability (not 
> preferred, because ESPs sometime run into a state where they aren't really 
> running but drawing current from the battery until the battery is flat and 
> damaged.
>
> This will extend your runtime dramatically.
>
> Currently I'm running my sensor on a 2500mAh LTO Battery, one sample a 
> minute with deep sleep in between gives me more than a week runtime. 
>
> peterq...@gmail.com schrieb am Sonntag, 27. Dezember 2020 um 18:49:54 
> UTC+1:
>
>> I have a secondary temperature sensor that runs on solar and a battery. 
>> This time a year in the northern hemisphere there's not enough sunlight to 
>> charge the battery sufficiently to make it through the night. I handled the 
>> failover to the main thermometer in my customized driver. Details here: 
>> https://hackaday.io/project/101680-solar-powered-wifi-temperature-sensor-for-weewx/details
>>
>> On Sun, Dec 27, 2020 at 7:53 AM michael.k...@gmx.at  
>> wrote:
>>
>>> The the ESP just reads the SHT35 in a given interval and publishes the 
>>> reading, nothing else. No calibration necessary, the sensor is really as 
>>> good as advertised in the data sheet. And only the outHumidity values of 
>>> the station are off when humidity > 80%rh, other values are pretty much 
>>> accurate and even outHumidity is very accurate below 80%rh. Since I don't 
>>> attach too much importance on historical humidity readings, mixing up 
>>> different source from time to time is no big deal for me. We're talking 
>>> about >99% availability with the less reliable sensor. But the current 
>>> dewpoint and windchill are interesting for me, which both require some 
>>> realistic humidity values.
>>>
>>> "Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it 
>>> is not the same as hardware record generation nor does ‘prefer_hardware’ 
>>> have anything to do with corrections. ‘prefer_hardware’ is used with the 
>>> StdCalculate service, corrections are used with the StdCalibrate service 
>>> and hardware or software record generation is used with the StdArchive 
>>> service."
>>>
>>> Thanks for pointing out.
>>>
>>> Greg Troxel schrieb am Sonntag, 27. Dezember 2020 um 15:01:08 UTC+1:
>>>

 You may also want to think about calibration. Besides absolute 
 calibration there is going to be some offset or other more complicated 
 relationship between your two sensors. Given a "prefer precise if 
 available" this is going to cause some flipping betweeen them. I had a 
 little trouble following this thread, and perhaps StdCalibrate runs 
 before the choice. 

 But if not, and maybe you want to do this anyway, basically 
 cross-correlated the data from both over a wide range, calculate a 
 mapping function, and put that in the ESP8266 code so that it emits 
 values that are consistent with your other sensor. 

 I did this with an ESP8266 that is measuring a 12V lead-acid battery. 
 While I can calculate expected values from the divider resistors and 
 the 
 data sheet, I ended up just measuring the battery and looking at the 
 raw 
 values and figuring out a divisor, which I stored in a calibration 
 file. 

>>> -- 
>>> 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/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com
>>>  
>>>

Re: [weewx-user] Fallback reading possible?

@Peter Quinn, thank you. I'll check the weewx part!

Just my 2 off-topic cents: using the breadboard the voltage regulator and 
the UART, powered by 5V ist a very inefficient way to run this sensor. The 
simplest approach to get more time from the solar/battery combo would be to 
use a 3V solar panel (which should exceed a maximum idle voltage of 3.6V) 
and directly charge a LiFe battery with it. If you ensure that the ESP 
powers off (deep sleep) at the ESP lower limit (datasheet says 2.5V, my 
experience says ~2.3V) the LiFe lower discharge limit (2,0V) will probably 
never be reached. Even with your LiPo this should be possible this way, but 
you can't use all capacity, since you can't charge it over 3.6V, because 
this would kill the esp.

In brief:
- don't use such a breadboard or remove the voltage regulator and the UARTs 
supply
- connect a LiFe directly to 3V3 and GND
- connect a 3V solar panel directly to 3V3 and GND
- ensure to power off the ESP when it reaches it's minimum required voltage 
(maybe it's never reached), either with a protection circuit (preferred) or 
the ESPs internal voltage measurement ability (not preferred, because ESPs 
sometime run into a state where they aren't really running but drawing 
current from the battery until the battery is flat and damaged.

This will extend your runtime dramatically.

Currently I'm running my sensor on a 2500mAh LTO Battery, one sample a 
minute with deep sleep in between gives me more than a week runtime. 

peterq...@gmail.com schrieb am Sonntag, 27. Dezember 2020 um 18:49:54 UTC+1:

> I have a secondary temperature sensor that runs on solar and a battery. 
> This time a year in the northern hemisphere there's not enough sunlight to 
> charge the battery sufficiently to make it through the night. I handled the 
> failover to the main thermometer in my customized driver. Details here: 
> https://hackaday.io/project/101680-solar-powered-wifi-temperature-sensor-for-weewx/details
>
> On Sun, Dec 27, 2020 at 7:53 AM michael.k...@gmx.at  
> wrote:
>
>> The the ESP just reads the SHT35 in a given interval and publishes the 
>> reading, nothing else. No calibration necessary, the sensor is really as 
>> good as advertised in the data sheet. And only the outHumidity values of 
>> the station are off when humidity > 80%rh, other values are pretty much 
>> accurate and even outHumidity is very accurate below 80%rh. Since I don't 
>> attach too much importance on historical humidity readings, mixing up 
>> different source from time to time is no big deal for me. We're talking 
>> about >99% availability with the less reliable sensor. But the current 
>> dewpoint and windchill are interesting for me, which both require some 
>> realistic humidity values.
>>
>> "Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it 
>> is not the same as hardware record generation nor does ‘prefer_hardware’ 
>> have anything to do with corrections. ‘prefer_hardware’ is used with the 
>> StdCalculate service, corrections are used with the StdCalibrate service 
>> and hardware or software record generation is used with the StdArchive 
>> service."
>>
>> Thanks for pointing out.
>>
>> Greg Troxel schrieb am Sonntag, 27. Dezember 2020 um 15:01:08 UTC+1:
>>
>>>
>>> You may also want to think about calibration. Besides absolute 
>>> calibration there is going to be some offset or other more complicated 
>>> relationship between your two sensors. Given a "prefer precise if 
>>> available" this is going to cause some flipping betweeen them. I had a 
>>> little trouble following this thread, and perhaps StdCalibrate runs 
>>> before the choice. 
>>>
>>> But if not, and maybe you want to do this anyway, basically 
>>> cross-correlated the data from both over a wide range, calculate a 
>>> mapping function, and put that in the ESP8266 code so that it emits 
>>> values that are consistent with your other sensor. 
>>>
>>> I did this with an ESP8266 that is measuring a 12V lead-acid battery. 
>>> While I can calculate expected values from the divider resistors and the 
>>> data sheet, I ended up just measuring the battery and looking at the raw 
>>> values and figuring out a divisor, which I stored in a calibration file. 
>>>
>> -- 
>> 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/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Peter Quinn
> (415)794-2264 <(415)%20794-2264>
>

-- 
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

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

This comes up frequently.
A webserver is not installed in the Rasperry Pi os by default.
You have to install the one of your choosing.

Simply run:
sudo apt-get install nginx

Then the URL you are trying to access will work.


On Sunday, December 27, 2020 at 8:03:05 AM UTC-8 kon...@apfelmanufaktur.de 
wrote:

>
> Hello,
>
> I am new with linux and weewx. I use a Froggit DP1500 Gateway with 
> different DP50 sensors and a WH3000 on a Raspberry Pi 3 Model A+.
>
> I installed weewx on the pi and the driver for GW1000. Attached you can 
> find the log file created with debug = 2
>
>  
>
> My problem is now that I have no access to the data. If I use 
> localhost/weewx in the browser to show weatherdata on the Pi no site will 
> appear and the upload of the data to my ftp doesn’t work too.
>
> I would like to test the site from another computer in my network because 
> the chromium browser is extremely slow on the pi. 
>
> I tried 192.168.178.24/weewx/index.html but it doesn’t work. 24 is the 
> adress of the pi.
>
> I have access to the sensors with WS View App on Android and I upload the 
> data to ecowitt.
> If I use wee_config --reconfigure --driver=user.gw1000 
>
> I use the ip address of the station I can see in WS View, it is 
> 192.168.178.34 . Which port should I use ? Standard is 45000 ?
>
> In the log file there are errors because of the FTP service.
>
> I don’t know what I have to do or where to start? The first step for me 
> would be to see weather data in a browser. Sorry I am a beginner
>
> Thank you in advance for your help!
>
> Attached is the mylog file, weewx.config and skin.conf
>
> Regards
>
> Thomas
>

-- 
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/9756f5fe-d697-44b7-bfd9-4e9d6d20d787n%40googlegroups.com.

[weewx-user] gw1000 driver fail on wifi loss

Gary - I wanted to pass along some logs from a gw1000 driver abort 
yesterday.

I had my home network down for a bit yesterday to do some firmware updates 
on my Ubiquiti USG, Switch and AcLite access point and weewx aborted rather 
quickly.

The external, wired, and wifi networks were indeed down for some minutes so 
missing some readings was expected, but I was hopeful that the driver would 
recover gracefully after things were back up,  however weewx totally 
aborted and the process was gone.

Just passing along the logs in case you wanted to take a look.  Thanks.



Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
Dec 26 16:26:16 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain live 
sensor data
Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Main loop exiting. 
Shutting engine down.
Dec 26 16:26:16 pi3jr weewx[18939] INFO weewx.engine: Shutting down 
StdReport thread
Dec 26 16:26:36 pi3jr weewx[18939] ERROR weewx.engine: Unable to shut down 
StdReport thread
Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
Dec 26 16:26:43 pi3jr weewx[18939] ERROR user.gw1000: Unable to obtain live 
sensor data
Dec 26 16:26:44 pi3jr weewx[18939] INFO user.gw1000: Gw1000Collector thread 
has been terminated
Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__: Caught WeeWxIOError: 
Failed to obtain response to command 'CMD_GW1000_LIVEDATA' after 3 attempts
Dec 26 16:26:44 pi3jr weewx[18939] CRITICAL __main__:   Waiting 60 
seconds then retrying...
Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: retrying...
Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Using configuration file 
/etc/weewx/weewx.conf
Dec 26 16:27:44 pi3jr weewx[18939] INFO __main__: Debug is 0
Dec 26 16:27:44 pi3jr weewx[18939] INFO weewx.engine: Loading station type 
GW1000 (user.gw1000)
Dec 26 16:28:08 pi3jr weewx[18939] ERROR user.gw1000: Failed to obtain 
response to command 'CMD_READ_STATION_MAC' after 3 attempts
Dec 26 16:28:08 pi3jr weewx[18939] ERROR weewx.engine: Import of driver 
failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
attempts ()
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 Traceback (most recent call last):
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/engine.py", line 109, in setupStation
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 self.console = loader_function(config_dict, self)
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 1293, in loader
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 return Gw1000Driver(**config_dict[DRIVER_NAME])
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 1568, in __init__
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 super(Gw1000Driver, self).__init__(**stn_dict)
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 767, in __init__
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 debug_wind=self.debug_wind)
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 1870, in __init__
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 lost_contact_log_period=lost_contact_log_period)
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 2276, in __init__
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 self.mac = self.get_mac_address()
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 2407, in get_mac_address
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 2532, in send_cmd_with_retries
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 raise GW1000IOError(_msg)
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL weewx.engine:  
 user.gw1000.GW1000IOError: Failed to obtain response to command 
'CMD_READ_STATION_MAC' after 3 attempts
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL __main__: Unable to load 
driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
attempts
Dec 26 16:28:08 pi3jr weewx[18939] CRITICAL __main__:   Exiting...

-- 
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

Re: [weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

2020-12-27 Thread p q

If you want to show your data on another computer using a web browser,
you'll want to set up a web server on the PI. It's not hard to set up
Apache. Performance-wise, it will run fine on a Raspi3.

On Sun, Dec 27, 2020 at 8:05 AM Thomas Hackler 
wrote:

> I cannot attach my log files, why ?
>
> --
> 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/1a11b43b-24dd-4048-9900-d85c91eb457dn%40googlegroups.com
> 
> .
>


-- 
Peter Quinn
(415)794-2264

-- 
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/CAA1SM20P%2BOAPvFe7dtkUfLNMn6zXBkbPG9AomQ2EPdpx6adJYQ%40mail.gmail.com.

Re: [weewx-user] Fallback reading possible?

2020-12-27 Thread p q

I have a secondary temperature sensor that runs on solar and a battery.
This time a year in the northern hemisphere there's not enough sunlight to
charge the battery sufficiently to make it through the night. I handled the
failover to the main thermometer in my customized driver. Details here:
https://hackaday.io/project/101680-solar-powered-wifi-temperature-sensor-for-weewx/details

On Sun, Dec 27, 2020 at 7:53 AM michael.k...@gmx.at <
michael.kainzba...@gmx.at> wrote:

> The the ESP just reads the SHT35 in a given interval and publishes the
> reading, nothing else. No calibration necessary, the sensor is really as
> good as advertised in the data sheet. And only the outHumidity values of
> the station are off when humidity > 80%rh, other values are pretty much
> accurate and even outHumidity is very accurate below 80%rh. Since I don't
> attach too much importance on historical humidity readings, mixing up
> different source from time to time is no big deal for me. We're talking
> about >99% availability with the less reliable sensor. But the current
> dewpoint and windchill are interesting for me, which both require some
> realistic humidity values.
>
> "Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it is
> not the same as hardware record generation nor does ‘prefer_hardware’ have
> anything to do with corrections. ‘prefer_hardware’ is used with the
> StdCalculate service, corrections are used with the StdCalibrate service
> and hardware or software record generation is used with the StdArchive
> service."
>
> Thanks for pointing out.
>
> Greg Troxel schrieb am Sonntag, 27. Dezember 2020 um 15:01:08 UTC+1:
>
>>
>> You may also want to think about calibration. Besides absolute
>> calibration there is going to be some offset or other more complicated
>> relationship between your two sensors. Given a "prefer precise if
>> available" this is going to cause some flipping betweeen them. I had a
>> little trouble following this thread, and perhaps StdCalibrate runs
>> before the choice.
>>
>> But if not, and maybe you want to do this anyway, basically
>> cross-correlated the data from both over a wide range, calculate a
>> mapping function, and put that in the ESP8266 code so that it emits
>> values that are consistent with your other sensor.
>>
>> I did this with an ESP8266 that is measuring a 12V lead-acid battery.
>> While I can calculate expected values from the divider resistors and the
>> data sheet, I ended up just measuring the battery and looking at the raw
>> values and figuring out a divisor, which I stored in a calibration file.
>>
> --
> 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/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com
> 
> .
>


-- 
Peter Quinn
(415)794-2264

-- 
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/CAA1SM23Sy%3DZv7Ykxg2UnMZSUY7mwvL7Kt42j_UFERpatLVZTsA%40mail.gmail.com.

[weewx-user] Re: WeeWx error "Vantage: LOOP read error. Try ... "

2020-12-27 Thread Claudio

try to set your date and time before start weewx

Il giorno domenica 27 dicembre 2020 alle 13:12:19 UTC+1 gjr80 ha scritto:

> Hi,
>
> You can try using 
>
> $ wee_device —dump
>
> before clearing the loggers memory, this will dump all available archive 
> records to database. It may or may not get any records from the logger that 
> have not previously been downloaded, but it is about the best you can do at 
> this stage.
>
> Gary
> On Sunday, 27 December 2020 at 21:35:38 UTC+10 jputt...@gmail.com wrote:
>
>> Hi, suddenly the Raspi Py did not read out any data (console Vantage Pro 
>> 2).
>> *ERROR weewx.drivers.vantage: LOOP try #1; error: Expected to read 99 
>> chars; got 0 instead*
>> Removing and reconnecting the USB connector and rebooting the Raspi did 
>> not help.
>> Command *wee_device --clear* and then  *sudo service weewx restart* 
>> solved the problem.
>> Unfortunately, measurement data was lost in the process.
>> Is there another solution without data loss? ( for the future) 
>>
>> Joachim
>>
>>

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

Re: [weewx-user] Weewx Seasons Skin Monthly & Yearly Reports dropdown menus do not work

2020-12-27 Thread ExprmntAl

Hi TK.  What is the function of the "tabular.html?report=" portion of the 
address?  Is this something that gets filled in when you have a webserver 
installed?  When I remove this portion of the address and hit enter, 
Chromium Browser opens the file.   This address works without setting any 
permissions - "file:///var/www/html/weewx/NOAA/NOAA-2020.txt".

I will re-install a webserver when I re-install my weewx-weather34 
extension and see if that works at some point when I get some time.  I have 
to re-read the thread a few months ago where you helped me through that 
process. ;)

On Sunday, December 27, 2020 at 6:35:48 AM UTC-6 tke...@gmail.com wrote:

> Chrome does not allow access to local files from Javascript unless you 
> give it explicit permission. You have two options: (1) run a local 
> webserver; or (2) give it permission:
>
> *google-chrome --allow-file-access-from-files*
>
>
> -tk
>
> On Sat, Dec 26, 2020 at 8:22 PM ExprmntAl <72604...@compuserve.com> wrote:
>
>> I noticed a few months ago that the Seasons Skin dropdown menus for the 
>> NOAA MOnthly and Yearly reports did not work, and wondered if I had broken 
>> something in Weewx along the way, but I just did a fresh install of Weewx a 
>> few days ago and noticed that the dropdown menus for the NOAA Monthly and 
>> Yearly reports still did not work properly in the Chromium Browser in 
>> Raspberry Pi OS (Buster).  It seems like the address for the files has some 
>> extra text in it highlighted below:
>>
>> file:///var/www/html/weewx/tabular.html?report=NOAA/NOAA-2020.txt
>>
>> If I remove the highlighted text, the link correctly pulls up the file.  
>> Has anyone else noticed this?  Does the Seasons Skin Index.html file need 
>> to be modified to correct this or is there a more appropriate way?
>>
>> -- 
>> 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/5f3da712-da28-4a85-88b8-f8dd2ee42d97n%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/291e2c25-758a-4047-bee5-86c17d56ca73n%40googlegroups.com.

[weewx-user] Re: Beginner problems: no access to weather data in browser ? FTP problem

I cannot attach my log files, why ?

-- 
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/1a11b43b-24dd-4048-9900-d85c91eb457dn%40googlegroups.com.

[weewx-user] Beginner problems: no access to weather data in browser ? FTP problem

Hello,

I am new with linux and weewx. I use a Froggit DP1500 Gateway with
different DP50 sensors and a WH3000 on a Raspberry Pi 3 Model A+.

I installed weewx on the pi and the driver for GW1000. Attached you can
find the log file created with debug = 2

My problem is now that I have no access to the data. If I use
localhost/weewx in the browser to show weatherdata on the Pi no site will
appear and the upload of the data to my ftp doesn’t work too.

I would like to test the site from another computer in my network because
the chromium browser is extremely slow on the pi.

I tried 192.168.178.24/weewx/index.html but it doesn’t work. 24 is the
adress of the pi.

I have access to the sensors with WS View App on Android and I upload the
data to ecowitt.
If I use wee_config --reconfigure --driver=user.gw1000

I use the ip address of the station I can see in WS View, it is
192.168.178.34 . Which port should I use ? Standard is 45000 ?

In the log file there are errors because of the FTP service.

I don’t know what I have to do or where to start? The first step for me
would be to see weather data in a browser. Sorry I am a beginner

Thank you in advance for your help!

Attached is the mylog file, weewx.config and skin.conf

Regards

Thomas

--
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/d3b52b60-51bc-486e-9591-96a02e13677en%40googlegroups.com.

Re: [weewx-user] Fallback reading possible?

The the ESP just reads the SHT35 in a given interval and publishes the 
reading, nothing else. No calibration necessary, the sensor is really as 
good as advertised in the data sheet. And only the outHumidity values of 
the station are off when humidity > 80%rh, other values are pretty much 
accurate and even outHumidity is very accurate below 80%rh. Since I don't 
attach too much importance on historical humidity readings, mixing up 
different source from time to time is no big deal for me. We're talking 
about >99% availability with the less reliable sensor. But the current 
dewpoint and windchill are interesting for me, which both require some 
realistic humidity values.

"Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it is 
not the same as hardware record generation nor does ‘prefer_hardware’ have 
anything to do with corrections. ‘prefer_hardware’ is used with the 
StdCalculate service, corrections are used with the StdCalibrate service 
and hardware or software record generation is used with the StdArchive 
service."

Thanks for pointing out.

Greg Troxel schrieb am Sonntag, 27. Dezember 2020 um 15:01:08 UTC+1:

>
> You may also want to think about calibration. Besides absolute
> calibration there is going to be some offset or other more complicated
> relationship between your two sensors. Given a "prefer precise if
> available" this is going to cause some flipping betweeen them. I had a
> little trouble following this thread, and perhaps StdCalibrate runs
> before the choice.
>
> But if not, and maybe you want to do this anyway, basically
> cross-correlated the data from both over a wide range, calculate a
> mapping function, and put that in the ESP8266 code so that it emits
> values that are consistent with your other sensor.
>
> I did this with an ESP8266 that is measuring a 12V lead-acid battery.
> While I can calculate expected values from the divider resistors and the
> data sheet, I ended up just measuring the battery and looking at the raw
> values and figuring out a divisor, which I stored in a calibration file.
>

-- 
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/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com.

[weewx-user] Re: Super simple skin

2020-12-27 Thread Sven Täveby


Also added autorefresh to web page...
/ST
Den söndag 27 december 2020 kl. 16:17:27 UTC+1 skrev Sven Täveby:
>
> A big Thank You!
> Made some changes and transladed to Swedish. Maybe I'll change the name to 
> STandard? :-) 
> http://teff.se/v2/Crandard
> Outdoor/indoor/max ut/min out/rain today/rain totalt last 7 days/last 
> updated.
>
> Looks great on my wall, using a Raspberry Pi touchscreen (and a BME280 
> sensor to report indoor temp to weewx on the master Pi).
> Cheers
> /Sven
>  
> Den söndag 8 november 2020 kl. 21:14:41 UTC+1 skrev Sven Täveby:
>>
>> Thx. Will check it out.
>> /Sven
>>
>> söndag 8 november 2020 kl. 00:30:05 UTC+1 skrev robcr...@gmail.com:
>>
>>> Sven, if you're addressing me, I've got it posted at
>>>
>>>   https://github.com/RobCranfill/Crandard
>>>
>>> Does that work for you?
>>>  /rob
>>>
>>> PS - I've gotten a little sidetracked from updating the code, because 1) 
>>> I can see that I will indeed be able to do what I want with WeeWX, but 2) 
>>> the hardware I was going to use to display it is proving to be a problem, 
>>> so I'm re-thinking that. :-]
>>>
>>> On Saturday, November 7, 2020 at 1:33:44 PM UTC-8 sven@gmail.com 
>>> wrote:
>>>
 Can You share that skin?
 Exactly what I want (except maybe units).

 /Sven 

>>>

-- 
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/9b2f3310-5de2-4b27-8f98-f57d786fo%40googlegroups.com.

[weewx-user] Re: Super simple skin

2020-12-27 Thread Sven Täveby

A big Thank You!
Made some changes and transladed to Swedish. Maybe I'll change the name to 
STandard? :-) 
http://teff.se/v2/Crandard
Outdoor/indoor/max ut/min out/rain today/rain totalt last 7 days/last 
updated.

Looks great on my wall, using a Raspberry Pi touchscreen (and a BME280 
sensor to report indoor temp to weewx on the master Pi.
Cheers
/Sven
 
Den söndag 8 november 2020 kl. 21:14:41 UTC+1 skrev Sven Täveby:
>
> Thx. Will check it out.
> /Sven
>
> söndag 8 november 2020 kl. 00:30:05 UTC+1 skrev robcr...@gmail.com:
>
>> Sven, if you're addressing me, I've got it posted at
>>
>>   https://github.com/RobCranfill/Crandard
>>
>> Does that work for you?
>>  /rob
>>
>> PS - I've gotten a little sidetracked from updating the code, because 1) 
>> I can see that I will indeed be able to do what I want with WeeWX, but 2) 
>> the hardware I was going to use to display it is proving to be a problem, 
>> so I'm re-thinking that. :-]
>>
>> On Saturday, November 7, 2020 at 1:33:44 PM UTC-8 sven@gmail.com 
>> wrote:
>>
>>> Can You share that skin?
>>> Exactly what I want (except maybe units).
>>>
>>> /Sven 
>>>
>>

-- 
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/ef4c91fc-ffc2-49ca-9893-3cce73e25d97o%40googlegroups.com.

Re: [weewx-user] Fallback reading possible?

2020-12-27 Thread Greg Troxel


You may also want to think about calibration.  Besides absolute
calibration there is going to be some offset or other more complicated
relationship between your two sensors.  Given a "prefer precise if
available" this is going to cause some flipping betweeen them.  I had a
little trouble following this thread, and perhaps StdCalibrate runs
before the choice.

But if not, and maybe you want to do this anyway, basically
cross-correlated the data from both over a wide range, calculate a
mapping function, and put that in the ESP8266 code so that it emits
values that are consistent with your other sensor.

I did this with an ESP8266 that is measuring a 12V lead-acid battery.
While I can calculate expected values from the divider resistors and the
data sheet, I ended up just measuring the battery and looking at the raw
values and figuring out a divisor,  which I stored in a calibration file.

-- 
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/rmiblef8i1w.fsf%40s1.lexort.com.


signature.asc
Description: PGP signature

[weewx-user] Re: Fallback reading possible?

Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it is 
not the same as hardware record generation nor does ‘prefer_hardware’ have 
anything to do with corrections. ‘prefer_hardware’ is used with the 
StdCalculate service, corrections are used with the StdCalibrate service 
and hardware or software record generation is used with the StdArchive 
service.

Gary

On Sunday, 27 December 2020 at 23:10:23 UTC+10 michael.k...@gmx.at wrote:

> Thank you Gary. I use "prefer_hardware", so I am very confident the 
> expression will do what I want to achieve.
>
> gjr80 schrieb am Sonntag, 27. Dezember 2020 um 13:23:07 UTC+1:
>
>> If extraHumid1 and outHumidity are not in that same loop packet then a 
>> correction expression will have no effect on the loop packet. If you are 
>> using hardware record generation then the correction will be applied to the 
>> archive record as well so that may do what you want for archive records. If 
>> you are using software record generation then no corrections are applied to 
>> archive records.
>>
>> Gary
>>
>> On Sunday, 27 December 2020 at 22:14:36 UTC+10 michael.k...@gmx.at wrote:
>>
>>>
>>> But thinking further I have another question: will [[Corrections]] work 
>>> with every loop package or every archive interval or both? If on every loop 
>>> package is archive value computed from the loop data a mix of both sensors, 
>>> since the sensors won't deliver their readings with the same loop package? 
>>> Or won't outHumidity be affected at all, because the never is a extraHumid1 
>>> value available?
>>> michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 12:58:47 
>>> UTC+1:
>>>

 Good Question. Since I am currently only thinking about how everything 
 *could 
 *work out, I can't answer this at the moment. But I guess my question 
 is answered. If there would be an error, how would one handle it? Or is a 
 "nasty" log an no effect on "outHumidity" all?
 gjr80 schrieb am Sonntag, 27. Dezember 2020 um 12:50:51 UTC+1:

> Hi,
>
> You want something like:
>
> outHumidity = outHumidity if extraHumid1 is None else extraHumid1
>
> My only question is what behaviour do you see when extraHumid1 is not 
> provided; is extraHumid1 set to None (in which case the above will work 
> as 
> you want) or is extraHumid1 omitted from the packet (in which case the 
> above will produce an error and have no effect on outHumidity (which 
> arguably is what you want)).
>
> Gary
>
> On Sunday, 27 December 2020 at 21:22:34 UTC+10 michael.k...@gmx.at 
> wrote:
>
>> Let's say I have two sensors, "outHumidity" and "extraHumid1".
>> "outHumidity" ist a sensor that delivers data very reliable but not 
>> very precise measurements, it's the stations built-in sensor.  
>> "extraHumid1" delivers data a little less reliable, but very precise 
>> values. It's a custom built ESP8266 using a SHT35, sending data over 
>> MQTT.
>>
>> Is it possible to prefer extraHumid1 over outHumidity, if there are 
>> extraHumid1 values in the archive Interval? If not, use outHumidity?
>>
>> Something like
>> [[Corrections]]
>> outHumidity = if extraHumid1 == 'None' outHumidity else extraHumid1
>>
>>
>>

-- 
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/27a5c8d7-9122-4b44-a49b-9f6c340e72ben%40googlegroups.com.

[weewx-user] Re: Fallback reading possible?

Thank you Gary. I use "prefer_hardware", so I am very confident the 
expression will do what I want to achieve.

gjr80 schrieb am Sonntag, 27. Dezember 2020 um 13:23:07 UTC+1:

> If extraHumid1 and outHumidity are not in that same loop packet then a 
> correction expression will have no effect on the loop packet. If you are 
> using hardware record generation then the correction will be applied to the 
> archive record as well so that may do what you want for archive records. If 
> you are using software record generation then no corrections are applied to 
> archive records.
>
> Gary
>
> On Sunday, 27 December 2020 at 22:14:36 UTC+10 michael.k...@gmx.at wrote:
>
>>
>> But thinking further I have another question: will [[Corrections]] work 
>> with every loop package or every archive interval or both? If on every loop 
>> package is archive value computed from the loop data a mix of both sensors, 
>> since the sensors won't deliver their readings with the same loop package? 
>> Or won't outHumidity be affected at all, because the never is a extraHumid1 
>> value available?
>> michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 12:58:47 
>> UTC+1:
>>
>>>
>>> Good Question. Since I am currently only thinking about how everything 
>>> *could 
>>> *work out, I can't answer this at the moment. But I guess my question 
>>> is answered. If there would be an error, how would one handle it? Or is a 
>>> "nasty" log an no effect on "outHumidity" all?
>>> gjr80 schrieb am Sonntag, 27. Dezember 2020 um 12:50:51 UTC+1:
>>>
 Hi,

 You want something like:

 outHumidity = outHumidity if extraHumid1 is None else extraHumid1

 My only question is what behaviour do you see when extraHumid1 is not 
 provided; is extraHumid1 set to None (in which case the above will work as 
 you want) or is extraHumid1 omitted from the packet (in which case the 
 above will produce an error and have no effect on outHumidity (which 
 arguably is what you want)).

 Gary

 On Sunday, 27 December 2020 at 21:22:34 UTC+10 michael.k...@gmx.at 
 wrote:

> Let's say I have two sensors, "outHumidity" and "extraHumid1".
> "outHumidity" ist a sensor that delivers data very reliable but not 
> very precise measurements, it's the stations built-in sensor.  
> "extraHumid1" delivers data a little less reliable, but very precise 
> values. It's a custom built ESP8266 using a SHT35, sending data over MQTT.
>
> Is it possible to prefer extraHumid1 over outHumidity, if there are 
> extraHumid1 values in the archive Interval? If not, use outHumidity?
>
> Something like
> [[Corrections]]
> outHumidity = if extraHumid1 == 'None' outHumidity else extraHumid1
>
>
>

-- 
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/8de9a1f2-e70e-4010-a8ff-31f9e92ed07fn%40googlegroups.com.

Re: [weewx-user] Weewx Seasons Skin Monthly & Yearly Reports dropdown menus do not work

Chrome does not allow access to local files from Javascript unless you give
it explicit permission. You have two options: (1) run a local webserver; or
(2) give it permission:

*google-chrome --allow-file-access-from-files*


-tk

On Sat, Dec 26, 2020 at 8:22 PM ExprmntAl <72604.3...@compuserve.com> wrote:

> I noticed a few months ago that the Seasons Skin dropdown menus for the
> NOAA MOnthly and Yearly reports did not work, and wondered if I had broken
> something in Weewx along the way, but I just did a fresh install of Weewx a
> few days ago and noticed that the dropdown menus for the NOAA Monthly and
> Yearly reports still did not work properly in the Chromium Browser in
> Raspberry Pi OS (Buster).  It seems like the address for the files has some
> extra text in it highlighted below:
>
> file:///var/www/html/weewx/tabular.html?report=NOAA/NOAA-2020.txt
>
> If I remove the highlighted text, the link correctly pulls up the file.
> Has anyone else noticed this?  Does the Seasons Skin Index.html file need
> to be modified to correct this or is there a more appropriate way?
>
> --
> 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/5f3da712-da28-4a85-88b8-f8dd2ee42d97n%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/CAPq0zEC%3DOfMdbM8WOtx59qgWqAsO7hVLz9FDavGUe2kgxTNEFw%40mail.gmail.com.

[weewx-user] Re: Fallback reading possible?

If extraHumid1 and outHumidity are not in that same loop packet then a 
correction expression will have no effect on the loop packet. If you are 
using hardware record generation then the correction will be applied to the 
archive record as well so that may do what you want for archive records. If 
you are using software record generation then no corrections are applied to 
archive records.

Gary

On Sunday, 27 December 2020 at 22:14:36 UTC+10 michael.k...@gmx.at wrote:

>
> But thinking further I have another question: will [[Corrections]] work 
> with every loop package or every archive interval or both? If on every loop 
> package is archive value computed from the loop data a mix of both sensors, 
> since the sensors won't deliver their readings with the same loop package? 
> Or won't outHumidity be affected at all, because the never is a extraHumid1 
> value available?
> michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 12:58:47 
> UTC+1:
>
>>
>> Good Question. Since I am currently only thinking about how everything 
>> *could 
>> *work out, I can't answer this at the moment. But I guess my question is 
>> answered. If there would be an error, how would one handle it? Or is a 
>> "nasty" log an no effect on "outHumidity" all?
>> gjr80 schrieb am Sonntag, 27. Dezember 2020 um 12:50:51 UTC+1:
>>
>>> Hi,
>>>
>>> You want something like:
>>>
>>> outHumidity = outHumidity if extraHumid1 is None else extraHumid1
>>>
>>> My only question is what behaviour do you see when extraHumid1 is not 
>>> provided; is extraHumid1 set to None (in which case the above will work as 
>>> you want) or is extraHumid1 omitted from the packet (in which case the 
>>> above will produce an error and have no effect on outHumidity (which 
>>> arguably is what you want)).
>>>
>>> Gary
>>>
>>> On Sunday, 27 December 2020 at 21:22:34 UTC+10 michael.k...@gmx.at 
>>> wrote:
>>>
 Let's say I have two sensors, "outHumidity" and "extraHumid1".
 "outHumidity" ist a sensor that delivers data very reliable but not 
 very precise measurements, it's the stations built-in sensor.  
 "extraHumid1" delivers data a little less reliable, but very precise 
 values. It's a custom built ESP8266 using a SHT35, sending data over MQTT.

 Is it possible to prefer extraHumid1 over outHumidity, if there are 
 extraHumid1 values in the archive Interval? If not, use outHumidity?

 Something like
 [[Corrections]]
 outHumidity = if extraHumid1 == 'None' outHumidity else extraHumid1




-- 
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/6fd9760f-8a23-449a-af5b-f979f6252722n%40googlegroups.com.

[weewx-user] Re: Fallback reading possible?

Actually, looking at the StdCalibrate code if extraHumid1 is not present in 
the packet the error generated by the above correction expression will be 
ignored. So the expression above will effectively cover both cases.

Gary

On Sunday, 27 December 2020 at 21:58:47 UTC+10 michael.k...@gmx.at wrote:

>
> Good Question. Since I am currently only thinking about how everything *could 
> *work out, I can't answer this at the moment. But I guess my question is 
> answered. If there would be an error, how would one handle it? Or is a 
> "nasty" log an no effect on "outHumidity" all?
> gjr80 schrieb am Sonntag, 27. Dezember 2020 um 12:50:51 UTC+1:
>
>> Hi,
>>
>> You want something like:
>>
>> outHumidity = outHumidity if extraHumid1 is None else extraHumid1
>>
>> My only question is what behaviour do you see when extraHumid1 is not 
>> provided; is extraHumid1 set to None (in which case the above will work as 
>> you want) or is extraHumid1 omitted from the packet (in which case the 
>> above will produce an error and have no effect on outHumidity (which 
>> arguably is what you want)).
>>
>> Gary
>>
>> On Sunday, 27 December 2020 at 21:22:34 UTC+10 michael.k...@gmx.at wrote:
>>
>>> Let's say I have two sensors, "outHumidity" and "extraHumid1".
>>> "outHumidity" ist a sensor that delivers data very reliable but not very 
>>> precise measurements, it's the stations built-in sensor.  
>>> "extraHumid1" delivers data a little less reliable, but very precise 
>>> values. It's a custom built ESP8266 using a SHT35, sending data over MQTT.
>>>
>>> Is it possible to prefer extraHumid1 over outHumidity, if there are 
>>> extraHumid1 values in the archive Interval? If not, use outHumidity?
>>>
>>> Something like
>>> [[Corrections]]
>>> outHumidity = if extraHumid1 == 'None' outHumidity else extraHumid1
>>>
>>>
>>>

-- 
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/3446bb20-3169-4c65-b853-ac04f6c44c2en%40googlegroups.com.

[weewx-user] Re: Fallback reading possible?


But thinking further I have another question: will [[Corrections]] work 
with every loop package or every archive interval or both? If on every loop 
package is archive value computed from the loop data a mix of both sensors, 
since the sensors won't deliver their readings with the same loop package? 
Or won't outHumidity be affected at all, because the never is a extraHumid1 
value available?
michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 12:58:47 UTC+1:

>
> Good Question. Since I am currently only thinking about how everything *could 
> *work out, I can't answer this at the moment. But I guess my question is 
> answered. If there would be an error, how would one handle it? Or is a 
> "nasty" log an no effect on "outHumidity" all?
> gjr80 schrieb am Sonntag, 27. Dezember 2020 um 12:50:51 UTC+1:
>
>> Hi,
>>
>> You want something like:
>>
>> outHumidity = outHumidity if extraHumid1 is None else extraHumid1
>>
>> My only question is what behaviour do you see when extraHumid1 is not 
>> provided; is extraHumid1 set to None (in which case the above will work as 
>> you want) or is extraHumid1 omitted from the packet (in which case the 
>> above will produce an error and have no effect on outHumidity (which 
>> arguably is what you want)).
>>
>> Gary
>>
>> On Sunday, 27 December 2020 at 21:22:34 UTC+10 michael.k...@gmx.at wrote:
>>
>>> Let's say I have two sensors, "outHumidity" and "extraHumid1".
>>> "outHumidity" ist a sensor that delivers data very reliable but not very 
>>> precise measurements, it's the stations built-in sensor.  
>>> "extraHumid1" delivers data a little less reliable, but very precise 
>>> values. It's a custom built ESP8266 using a SHT35, sending data over MQTT.
>>>
>>> Is it possible to prefer extraHumid1 over outHumidity, if there are 
>>> extraHumid1 values in the archive Interval? If not, use outHumidity?
>>>
>>> Something like
>>> [[Corrections]]
>>> outHumidity = if extraHumid1 == 'None' outHumidity else extraHumid1
>>>
>>>
>>>

-- 
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/de01e02e-c5bd-4a18-a806-8511d34dae6an%40googlegroups.com.

[weewx-user] Re: WeeWx error "Vantage: LOOP read error. Try ... "

Hi,

You can try using 

$ wee_device —dump

before clearing the loggers memory, this will dump all available archive 
records to database. It may or may not get any records from the logger that 
have not previously been downloaded, but it is about the best you can do at 
this stage.

Gary
On Sunday, 27 December 2020 at 21:35:38 UTC+10 jputt...@gmail.com wrote:

> Hi, suddenly the Raspi Py did not read out any data (console Vantage Pro 
> 2).
> *ERROR weewx.drivers.vantage: LOOP try #1; error: Expected to read 99 
> chars; got 0 instead*
> Removing and reconnecting the USB connector and rebooting the Raspi did 
> not help.
> Command *wee_device --clear* and then  *sudo service weewx restart* 
> solved the problem.
> Unfortunately, measurement data was lost in the process.
> Is there another solution without data loss? ( for the future) 
>
> Joachim
>
>

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

[weewx-user] Re: Fallback reading possible?


Good Question. Since I am currently only thinking about how everything *could 
*work out, I can't answer this at the moment. But I guess my question is 
answered. If there would be an error, how would one handle it? Or is a 
"nasty" log an no effect on "outHumidity" all?
gjr80 schrieb am Sonntag, 27. Dezember 2020 um 12:50:51 UTC+1:

> Hi,
>
> You want something like:
>
> outHumidity = outHumidity if extraHumid1 is None else extraHumid1
>
> My only question is what behaviour do you see when extraHumid1 is not 
> provided; is extraHumid1 set to None (in which case the above will work as 
> you want) or is extraHumid1 omitted from the packet (in which case the 
> above will produce an error and have no effect on outHumidity (which 
> arguably is what you want)).
>
> Gary
>
> On Sunday, 27 December 2020 at 21:22:34 UTC+10 michael.k...@gmx.at wrote:
>
>> Let's say I have two sensors, "outHumidity" and "extraHumid1".
>> "outHumidity" ist a sensor that delivers data very reliable but not very 
>> precise measurements, it's the stations built-in sensor.  
>> "extraHumid1" delivers data a little less reliable, but very precise 
>> values. It's a custom built ESP8266 using a SHT35, sending data over MQTT.
>>
>> Is it possible to prefer extraHumid1 over outHumidity, if there are 
>> extraHumid1 values in the archive Interval? If not, use outHumidity?
>>
>> Something like
>> [[Corrections]]
>> outHumidity = if extraHumid1 == 'None' outHumidity else extraHumid1
>>
>>
>>

-- 
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/e733e08f-a8f6-4825-8821-4c1c7acf998en%40googlegroups.com.

[weewx-user] Re: Fallback reading possible?

Hi,

You want something like:

outHumidity = outHumidity if extraHumid1 is None else extraHumid1

My only question is what behaviour do you see when extraHumid1 is not 
provided; is extraHumid1 set to None (in which case the above will work as 
you want) or is extraHumid1 omitted from the packet (in which case the 
above will produce an error and have no effect on outHumidity (which 
arguably is what you want)).

Gary

On Sunday, 27 December 2020 at 21:22:34 UTC+10 michael.k...@gmx.at wrote:

> Let's say I have two sensors, "outHumidity" and "extraHumid1".
> "outHumidity" ist a sensor that delivers data very reliable but not very 
> precise measurements, it's the stations built-in sensor.  
> "extraHumid1" delivers data a little less reliable, but very precise 
> values. It's a custom built ESP8266 using a SHT35, sending data over MQTT.
>
> Is it possible to prefer extraHumid1 over outHumidity, if there are 
> extraHumid1 values in the archive Interval? If not, use outHumidity?
>
> Something like
> [[Corrections]]
> outHumidity = if extraHumid1 == 'None' outHumidity else extraHumid1
>
>
>

-- 
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/f3ea66f8-36e2-4b3f-86ca-a36ab3dd0259n%40googlegroups.com.

[weewx-user] WeeWx error "Vantage: LOOP read error. Try ... "

2020-12-27 Thread Joachim Puttkammer

Hi, suddenly the Raspi Py did not read out any data (console Vantage Pro 2).
*ERROR weewx.drivers.vantage: LOOP try #1; error: Expected to read 99 
chars; got 0 instead*
Removing and reconnecting the USB connector and rebooting the Raspi did not 
help.
Command *wee_device --clear* and then  *sudo service weewx restart* solved 
the problem.
Unfortunately, measurement data was lost in the process.
Is there another solution without data loss? ( for the future) 

Joachim

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

[weewx-user] Fallback reading possible?