[weewx-user] Re: raspi4 users yet ?

2019-07-15 Thread kar ss
I managed to install Weewx on a Raspberry Pi 4 (1GB) with Raspbian Buster 
and the installation went without any issue. The board temperature (with a 
heat sink on the processor) is around 50 +/- 2C on continuous running of 
weewx and broadcasting data to Wunderground. I don't get what you mean by 
time to process skins as I am not familiar with Raspbian OS and also new to 
Raspberry Pi. 

On Thursday, 27 June 2019 20:32:08 UTC+5:30, vince wrote:
>
> Anybody have a raspi4 yet ?   I'm curious what the time to process skins 
> is on this one vs. a pi3b+ since the new one is reportedly much faster in 
> general.
>

-- 
You 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/d5ff3df3-edaf-441e-ad5b-d438f5426b80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: raspi4 users yet ?

2019-07-15 Thread kar ss
I managed to install Weewx on a Raspberry Pi 4 (1GB) with Raspbian Duster 
and the installation went without any issue. The board temperature (with a 
heat sink on the processor) is around 50 +/- 2C on continuous running of 
weewx and broadcasting data to Wunderground. I don't get what you mean by 
time to process skins as I am not familiar with Raspbian OS and also new to 
Raspberry Pi. 

On Thursday, 27 June 2019 20:32:08 UTC+5:30, vince wrote:
>
> Anybody have a raspi4 yet ?   I'm curious what the time to process skins 
> is on this one vs. a pi3b+ since the new one is reportedly much faster in 
> general.
>

-- 
You 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/6ed47960-490b-42d5-8d9e-f3baf18ed6c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: SteelSeries Gauges and Weather Forecast?

2019-07-15 Thread Steve2Q
I have my Steel Gauges using the forecast from Darksky and it is accurate. You 
can see it here: 
 http://photokinetics.org/Weather/ss/

-- 
You 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/2ee943fd-37c3-4812-85c0-ba7cecee57ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: AS3935 database issue

2019-07-15 Thread Steve2Q
Mikael..yes, I agree with Dan. I tried a long time ago to get my sensor 
working, but never was successful. If you could make a "cookbook" that would be 
very helpful  

Steve 

-- 
You 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/3aae97b9-da54-4a2c-8dd7-92aae877a3e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread mwall

On Monday, July 15, 2019 at 10:50:26 AM UTC-4, Kike .Asekas wrote:
>
> Well. The problem was here. The SDR driver was not in utc.I put the 
> parameter and all go well now. Thanks
> Closed
>

in the weewx-sdr driver, the default rtl_433 command is:

rtl_433 -M utc -F json -G

you must have removed the '-M utc' at some point, which results in 
localtime in the SDR timestamps instead of UTC

you can replace the '-G' with whatever '-R xxx' options you need, but you 
really do not want to remove the '-M utc' option

m 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/09b2e209-c289-4db6-ad68-b06f9ce00255%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: importing data from Weather Display log files

2019-07-15 Thread Peter Leban
Hi Gary,

many thanks for your answer. My setup is as follows:
* WD running on Windows. Keeps 3.5 years of data
* Vantage Vue with USB datalogger
* temperature sensor in jar via 1-wire USB interface to log the "solar" 
radiation

Don't rush with instructions; I'll wait. I have all hardware in place and 
can start working on it anytime.
I will follow your suggestion how to start converting the data, looks 
reasonable and risk-free.

Side question: is there a special setting in weewx that enables data 
extraction from the Davis datalogger?

Peter

Hi, 
>
> A WD import module was added to wee_import a few months ago and I am aware 
> of at least one user that has used it to successfully import numerous years 
> of WD monthly log file data. The WD capable version of wee_import can be 
> found in the WeeWX github development branch but will not be included in a 
> WeeWX release until the next release. If you are using WeeWX 3.9.0 or later 
> I can give you some fairly straightforward instructions to download, 
> install and use the WD capable version of wee_import if you are interested. 
> Unfortunately I am travelling at the moment and it will likely take at 
> least a couple of days for me to put together the instructions. 
>
> In terms of what approach to take when doing the import/changeover to 
> WeeWX will depend on a few factors. Namely what weather station you have 
> (in particular whether the station has a data logger ala the Davis 
> stations), how much WD data you have to import and how anal you are about 
> losing data. If it were me and I had a significant amount of WD data to 
> import, I would continue to run WD but install WeeWX on a machine and 
> import all WD data except the current month. If necessary I would then 
> install WeeWX on the final target machine (if not already done so), check 
> it works with your station, stop WD, copy the WeeWX database containing the 
> imported data to the WeeWX machine, import the current months WD data then 
> finally start WeeWX. If you have a station with a logger then things are a 
> little easier, you can afford to stop WD and take your time to install 
> WeeWX on the final machine and import all WD data. When you finally start 
> WeeWX it will download all the data held in the logger since WD was shut 
> down. These are but two approaches and there are number of variations you 
> can make. 
>
> In terms of time taken to import I think the user I referred to had about 
> 11 years of WD data that took overnight (or maybe slightly longer) to 
> import on a relatively new RPi. 
>
> 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/6503d0e1-6070-4201-8c0a-94cbfc5f46b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] weewx steelseries gauges weather station information elevation defaults to feet

2019-07-15 Thread Rune Lægreid
Hi,

The weewx steelseries gauges weather station information elevation defaults 
to feet although everything else is in metric.
How this be controlled?

-- 
You 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/f01a4f65-6cce-4727-92e7-714e64ec3775%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Re: heating_base and cooling_base values seems to be ignored in degreedays/NOAA reports

2019-07-15 Thread Thomas Keffer
Fixed in commit abb2538
,
to appear in Version 4.0.

-tk

On Sun, Jul 14, 2019 at 9:06 AM mph  wrote:

> Hello Thomas,
>
> you're welcome ;-)
> I thank you for fast and helpfull response. Your advice works.
>
> There's still a problem when using degree_C with *_base values.
> I had to convert my *_base values to degree_F to receive valid NOAA
> records.
>
> This issue is already being tracked somewhere.
>
> Pavel
>
>
> Dne neděle 14. července 2019 10:32:29 UTC+2 mph napsal(a):
>>
>>
>> Hello,
>>
>> I'd decided to change my base temperatures for DegreeDays and NOAA
>> reports.
>>
>> I've changed the values in /etc/weewx/weex.conf
>>
>> pi@rpi-meteo:~ $ grep "_base" -r /etc/weewx/*
>>> /etc/weewx/weewx.conf:heating_base = 21, degree_C
>>> /etc/weewx/weewx.conf:cooling_base = 25, degree_C
>>>
>>
>> then restarted weewx and deleted all the content of the
>> var/weewx/reports/NOAA directory.
>>
>> The NOAA reports were re-generated, but the reports and thus base
>> temperatures are still the same (avg_temp - cool_days_deg = 18.3 ~ 65,
>> degree_F)
>> I've dropped and regenerated the weewx daily data
>>
>> sudo service weewx stop
>>> sudo wee_database --drop-daily
>>> sudo wee_database --rebuild-daily
>>> sudo service weewx start
>>>
>>
>> Then I've slightly modified the NOAA templates to be sure the reports are
>> newly generated, and then removed the old reports again.
>> The reports were re-generated, see example NOAA-2019-06.txt in
>> attachment. But there's still no change in the DegDays calculations -
>> compare to an old NOAA-2019-06_backup.txt.
>>
>> Seems the weewx.conf values are ignored, the default *_base value "65,
>> degree_F" is always used.
>> Or am I doing something wrong?
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/abea1cd7-25ee-48c2-ab02-1b312cfad1fb%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You 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/CAPq0zEB5ERkrhabMar6Sprb0FiFTMWtx%3DPpJhk_2d1wp2vhYpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Re: WS3080 Lockup - FineOffsetUsb workaround not working.

2019-07-15 Thread HoracioDos
Thanks Johannes and Dave for your quick answer.
I have realized that I got confused between raspberry pi models. My old Pi 
1 model B works perfectly fine with weewx but it is not supported by 
uhubctl. I have five pi 1 model B and two Pi 2 model B that still do their 
job without any problems running raspbian buster. I'm going to swap micro 
usb cards between them and check if uhubctl works. Supported models are: 
B+, 2 B, 3 B (port 2 only)
Thanks again!

On Monday, July 15, 2019 at 11:27:04 AM UTC-3, Dave (G1OGY) wrote:
>
> uhubctl works fine on my Pi.
>
> pi@raspberrypi4:/home/weewx $ sudo ./powercycleusb
>
> Current status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
>   Port 2: 0100 power
> Sent power off request
> New status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
>   Port 2:  off
> Current status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
>   Port 2:  off
> Sent power on request
> New status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
>   Port 2: 0100 power
>
>
> My current command line is:
>
> # /uhubctl -d 15 -a cycle -p 2
>
> And the O/S is
>
> PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
>
> pi@raspberrypi4:/home/weewx $ uname -a
> Linux raspberrypi4 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 
> armv7l GNU/Linux
>
>
> This Pi is a 3-B v1.2 (quad core).
>
> Bear in mind that you must not have any other power source for the 
> WeatherStation.  You must take the batteries out and/or disconnect any 
> wall-wart; thus powering the Station ~only~ from the Pi's USB port.
>
> Dave, G1OGY
>
>
> On Mon, 15 Jul 2019 at 14:08, HoracioDos > 
> wrote:
>
>> Hello Dave.
>>
>> Did uhubctl work for you? Which raspberry pi model do you have? Are you 
>> using a usb hub?
>> uhubctl can disable port 2 but it still provide power to the weather 
>> station.so it can reset the WS.
>>
>> Any hint will be welcome.
>> Thanks in advance!
>>
>>
>> On Monday, July 15, 2019 at 7:06:46 AM UTC-3, Dave (G1OGY) wrote:
>>>
>>> Good news, Johannes!
>>> I'm pleased it helps.
>>>
>>>
>>> On Mon, 15 Jul 2019, 10:54 'Johannes Ebner' via weewx-user, <
>>> weewx...@googlegroups.com> wrote:
>>>
 Thanks, works perfectly for me!

 Br,
 Johannes

 Am Sonntag, 23. Juni 2019 10:06:18 UTC+2 schrieb Dave, G1OGY:
>
>
>
> On Sunday, 23 June 2019 07:30:53 UTC+1, Johannes Ebner wrote:
>>
>> How is this script working?
>>
>> Do you run it once and it stays in the background? Or do you run it 
>> via crontab?
>>
>>
>>>
> ATM it is running from the command line as I did not want to reboot 
> the Pi:
>
>  /home/weewx/monitorlockup &
>
> I have also added that command line to /etc/rc.local so that the 
> script will start on reboot.
>
> The monitoring script sits in the background waiting for a log print.  
> When weewx writes to the log file the script wakes up and checks the new 
> log line(s) for "Errno 110".  If the string is absent the script goes 
> back 
> to waiting for the next log print.  If the print is an error line then it 
> fires off the second script to powercycle the relevant USB port.
> You can watch it come alive every 5 minutes with `top(1)`.
>
> Obviously, you will need to have acquired and built the source of 
> `uhubctrl` in advance.
>
 -- 
 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/owhSpmklNlc/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 weewx...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/3ad78732-5dd1-4d75-94f3-f1a8caef38d0%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> 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/owhSpmklNlc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/51dc66c7-d2ca-4e85-bb11-5e44f657fb63%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[weewx-user] Re: UV Sensor Battery Indicator

2019-07-15 Thread Neil S
So as mwall suggested I removed the two lines `#if 
#day.uvBatteryStatus.has_data` and `#end if`

I now have:-

UV Battery  OK

Displayed on the web page.

Thanks mwall. 

N.


On Saturday, 29 June 2019 12:12:22 UTC+1, Neil S wrote:
>
> So I have just upgraded to 3.9.1 (on Raspberry Pi).  Using the nice new 
> skin but cannot work out how to get the UV Sensor battery to show on the 
> web page. UV levels etc show OK but cant get battery status to show 
> (despite some config file fiddling)
>
> (WRM88 weather station) 
>
> Is it possible?
>
> Neil
>

-- 
You 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/ff8201b8-0e6f-4f09-a983-e575ec6008e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Kike .Asekas
Well. The problem was here. The SDR driver was not in utc.I put the 
parameter and all go well now. Thanks
Closed

El lunes, 15 de julio de 2019, 16:24:43 (UTC+2), Andrew Milner escribió:
>
> I suspect you should not be using the dateTime field in the SDR packet as 
> that appears to be a local time and not UTC time - this results in other 
> parts of weewx looking for dates in the future - which of course will not 
> be found.
>
>
>
> On Monday, 15 July 2019 17:17:03 UTC+3, Kike .Asekas wrote:
>>
>> The problem looks like is in current object in the datetime function I 
>> think. Where is the code of current object?
>>
>>
>>

-- 
You 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/bb2f08b0-a57f-4ccf-9626-abfd50cf1958%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Getting wind speed spikes... Software or hardware?

2019-07-15 Thread vince
On Sunday, July 14, 2019 at 11:34:36 PM UTC-7, Alec Bennett wrote:
>
> Lately about once a week I'll get a wind reading of about 150 knots for a 
> few minutes from my Davis Vantage Pro. The reading is on the console as 
> well as weewx so I have a feeling it's the amenometer, but before replacing 
> that I wanted to see if anyone has another theory? 
>
>
>
Sounds like anemometer failing.   Mine did a similar thing last year (after 
9 years in service), reading crazy high, far higher than reasonable.   I 
replaced it with a new anemometer for about $105 or so which is kinda 
pricey for sure. 
https://www.scaledinstruments.com/shop/shop-by-product/anemometer/davis-6410-anemometer-for-vantage-pro2-vantage-pro/
 
is where I got mine.

The newer ones have a replaceable cartridge, so then it would only be $25 
or so.   
https://www.scaledinstruments.com/shop/davis-instruments/parts/vantage-pro2-parts/anemometer-parts/davis-7345-999-pro2-anemometer-wind-speed-cartridge/
 
for one link.   Be sure you know which hardware you have so you don't try 
to buy a replacement cartridge for an old anemometer that it won't fit.   
There's a diagram on the cartridge web page, it's pretty obvious.

When in doubt call Davis support.   They diagnosed my problem as perhaps a 
short in the cable due to the cable cracking or something, and sent me a 
diagnostic cable to try to use to test the sensor and station.   I got ok 
results, but finally just decided to throw the money at it and replace the 
anemometer completely.   The Davis folks were great as always in terms of 
support.


 

-- 
You 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/496d503b-b981-4e9a-96bf-bc36da07d953%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Re: WS3080 Lockup - FineOffsetUsb workaround not working.

2019-07-15 Thread Dave (G1OGY)
uhubctl works fine on my Pi.

pi@raspberrypi4:/home/weewx $ sudo ./powercycleusb

Current status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
  Port 2: 0100 power
Sent power off request
New status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
  Port 2:  off
Current status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
  Port 2:  off
Sent power on request
New status for hub 1-1 [0424:9514, USB 2.00, 5 ports]
  Port 2: 0100 power


My current command line is:

# /uhubctl -d 15 -a cycle -p 2

And the O/S is

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"

pi@raspberrypi4:/home/weewx $ uname -a
Linux raspberrypi4 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019
armv7l GNU/Linux


This Pi is a 3-B v1.2 (quad core).

Bear in mind that you must not have any other power source for the
WeatherStation.  You must take the batteries out and/or disconnect any
wall-wart; thus powering the Station ~only~ from the Pi's USB port.

Dave, G1OGY


On Mon, 15 Jul 2019 at 14:08, HoracioDos  wrote:

> Hello Dave.
>
> Did uhubctl work for you? Which raspberry pi model do you have? Are you
> using a usb hub?
> uhubctl can disable port 2 but it still provide power to the weather
> station.so it can reset the WS.
>
> Any hint will be welcome.
> Thanks in advance!
>
>
> On Monday, July 15, 2019 at 7:06:46 AM UTC-3, Dave (G1OGY) wrote:
>>
>> Good news, Johannes!
>> I'm pleased it helps.
>>
>>
>> On Mon, 15 Jul 2019, 10:54 'Johannes Ebner' via weewx-user, <
>> weewx...@googlegroups.com> wrote:
>>
>>> Thanks, works perfectly for me!
>>>
>>> Br,
>>> Johannes
>>>
>>> Am Sonntag, 23. Juni 2019 10:06:18 UTC+2 schrieb Dave, G1OGY:



 On Sunday, 23 June 2019 07:30:53 UTC+1, Johannes Ebner wrote:
>
> How is this script working?
>
> Do you run it once and it stays in the background? Or do you run it
> via crontab?
>
>
>>
 ATM it is running from the command line as I did not want to reboot the
 Pi:

  /home/weewx/monitorlockup &

 I have also added that command line to /etc/rc.local so that the script
 will start on reboot.

 The monitoring script sits in the background waiting for a log print.
 When weewx writes to the log file the script wakes up and checks the new
 log line(s) for "Errno 110".  If the string is absent the script goes back
 to waiting for the next log print.  If the print is an error line then it
 fires off the second script to powercycle the relevant USB port.
 You can watch it come alive every 5 minutes with `top(1)`.

 Obviously, you will need to have acquired and built the source of
 `uhubctrl` in advance.

>>> --
>>> 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/owhSpmklNlc/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/3ad78732-5dd1-4d75-94f3-f1a8caef38d0%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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/owhSpmklNlc/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/51dc66c7-d2ca-4e85-bb11-5e44f657fb63%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You 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/CAKOSXUE_UTm2DohZPOjQwsG51P-OT%3DVqLRSiAO7dzw2cZPr6qA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Andrew Milner
I suspect you should not be using the dateTime field in the SDR packet as 
that appears to be a local time and not UTC time - this results in other 
parts of weewx looking for dates in the future - which of course will not 
be found.



On Monday, 15 July 2019 17:17:03 UTC+3, Kike .Asekas wrote:
>
> The problem looks like is in current object in the datetime function I 
> think. Where is the code of current object?
>
>
>

-- 
You 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/0be5e7fb-9289-4d1b-b0b9-65aa900780a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Kike .Asekas
Well, the time in my database is in local time. Why?

El lunes, 15 de julio de 2019, 16:12:44 (UTC+2), Andrew Milner escribió:
>
> The dateTime in the database should be epoch time == UTC time, not local 
> time.
>
>
>
> On Monday, 15 July 2019 17:03:59 UTC+3, Kike .Asekas wrote:
>>
>>
>>
>> I delete the database. I see "cannot find start time" in the templates of 
>> the webpages.
>> The log:
>> Jul 15 15:55:51 raspberrypi weewx[11746]: Starting weewx weather system: 
>> weewx.
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Using configuration 
>> file /etc/weewx/weewx.conf
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Debug is 1
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Initializing engine
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading station type 
>> SDR (user.sdr)
>> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: driver version 
>> is 0.64
>> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: sensor map is 
>> {'windDir': 'wind_dir.*.FOWHx080Packet', 'windSpeed': 
>> 'wind_speed.*.FOWHx080Packet', 'outTemp': 'temperature.*.FOWHx080Packet', 
>> 'outHumidity': 'humidity.*.FOWHx080Packet', 'rain_total': 
>> 'rain_total.*.FOWHx080Packet', 'inTemp': 'temperature.*.FOWHx080Packet', 
>> 'inHumidity': 'humidity.*.FOWHx080Packet'}
>> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: deltas is 
>> {'strikes': 'strikes_total', 'rain': 'rain_total'}
>> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: startup 
>> process 'rtl_433 -q -F json -R 32 -f 868.3M'
>> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: stdout-thread: start async 
>> reader for stdout-thread
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
>> weewx.engine.StdTimeSynch
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading 
>> service weewx.engine.StdTimeSynch
>> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: stderr-thread: start async 
>> reader for stderr-thread
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
>> user.extra_sensors_service.ExtraSensorsService
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading 
>> service user.extra_sensors_service.ExtraSensorsService
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
>> weewx.engine.StdConvert
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: StdConvert target unit 
>> is 0x11
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading 
>> service weewx.engine.StdConvert
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
>> weewx.engine.StdCalibrate
>> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading 
>> service weewx.engine.StdCalibrate
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
>> weewx.engine.StdQC
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Finished loading 
>> service weewx.engine.StdQC
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
>> weewx.wxservices.StdWXCalculate
>> Jul 15 15:55:53 raspberrypi weewx[11768]: wxcalculate: The following 
>> values will be calculated: barometer=prefer_hardware, 
>> windchill=prefer_hardware, dewpoint=prefer_hardware, 
>> appTemp=prefer_hardware, rainRate=prefer_hardware, windrun=prefer_hardware, 
>> heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
>> humidex=prefer_hardware, pressure=prefer_hardware, 
>> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
>> cloudbase=prefer_hardware
>> Jul 15 15:55:53 raspberrypi weewx[11768]: wxcalculate: The following 
>> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Finished loading 
>> service weewx.wxservices.StdWXCalculate
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
>> weewx.engine.StdArchive
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Archive will use data 
>> binding wx_binding
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Record generation will 
>> be attempted in 'software'
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Using archive interval 
>> of 300 seconds (software record generation)
>> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Use LOOP data in hi/low 
>> calculations: 1
>> Jul 15 15:55:53 raspberrypi weewx[11768]: manager: Created and 
>> initialized table 'archive' in database 'weewx.sdb'
>> Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Created daily summary 
>> tables
>> Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Daily summary version 
>> is 2.0
>> Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Using binding 
>> 'wx_binding' to database 'weewx.sdb'
>> Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Starting backfill of 
>> daily summaries
>> Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Finished loading 
>> service weewx.engine.StdArchive
>> Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Loading service 
>> weewx.restx.StdStationRegis

[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Kike .Asekas
The problem looks like is in current object in the datetime function I 
think. Where is the code of current object?


-- 
You 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/e6cab7f9-09cb-454a-996c-3755800abfbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Andrew Milner
The dateTime in the database should be epoch time == UTC time, not local 
time.



On Monday, 15 July 2019 17:03:59 UTC+3, Kike .Asekas wrote:
>
>
>
> I delete the database. I see "cannot find start time" in the templates of 
> the webpages.
> The log:
> Jul 15 15:55:51 raspberrypi weewx[11746]: Starting weewx weather system: 
> weewx.
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Using configuration file 
> /etc/weewx/weewx.conf
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Debug is 1
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Initializing engine
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading station type SDR 
> (user.sdr)
> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: driver version 
> is 0.64
> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: sensor map is 
> {'windDir': 'wind_dir.*.FOWHx080Packet', 'windSpeed': 
> 'wind_speed.*.FOWHx080Packet', 'outTemp': 'temperature.*.FOWHx080Packet', 
> 'outHumidity': 'humidity.*.FOWHx080Packet', 'rain_total': 
> 'rain_total.*.FOWHx080Packet', 'inTemp': 'temperature.*.FOWHx080Packet', 
> 'inHumidity': 'humidity.*.FOWHx080Packet'}
> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: deltas is 
> {'strikes': 'strikes_total', 'rain': 'rain_total'}
> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: startup process 
> 'rtl_433 -q -F json -R 32 -f 868.3M'
> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: stdout-thread: start async 
> reader for stdout-thread
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
> weewx.engine.StdTimeSynch
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
> weewx.engine.StdTimeSynch
> Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: stderr-thread: start async 
> reader for stderr-thread
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
> user.extra_sensors_service.ExtraSensorsService
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
> user.extra_sensors_service.ExtraSensorsService
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
> weewx.engine.StdConvert
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: StdConvert target unit 
> is 0x11
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
> weewx.engine.StdConvert
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
> weewx.engine.StdCalibrate
> Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
> weewx.engine.StdCalibrate
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
> weewx.engine.StdQC
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Finished loading service 
> weewx.engine.StdQC
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
> weewx.wxservices.StdWXCalculate
> Jul 15 15:55:53 raspberrypi weewx[11768]: wxcalculate: The following 
> values will be calculated: barometer=prefer_hardware, 
> windchill=prefer_hardware, dewpoint=prefer_hardware, 
> appTemp=prefer_hardware, rainRate=prefer_hardware, windrun=prefer_hardware, 
> heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
> humidex=prefer_hardware, pressure=prefer_hardware, 
> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
> cloudbase=prefer_hardware
> Jul 15 15:55:53 raspberrypi weewx[11768]: wxcalculate: The following 
> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Finished loading service 
> weewx.wxservices.StdWXCalculate
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
> weewx.engine.StdArchive
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Archive will use data 
> binding wx_binding
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Record generation will 
> be attempted in 'software'
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Using archive interval 
> of 300 seconds (software record generation)
> Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Use LOOP data in hi/low 
> calculations: 1
> Jul 15 15:55:53 raspberrypi weewx[11768]: manager: Created and initialized 
> table 'archive' in database 'weewx.sdb'
> Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Created daily summary 
> tables
> Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Daily summary version 
> is 2.0
> Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Using binding 
> 'wx_binding' to database 'weewx.sdb'
> Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Starting backfill of 
> daily summaries
> Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Finished loading service 
> weewx.engine.StdArchive
> Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Loading service 
> weewx.restx.StdStationRegistry
> Jul 15 15:55:54 raspberrypi weewx[11768]: restx: StationRegistry: 
> Registration not requested.
> Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Finished loading service 
> weewx.restx.StdStationRegistry
> Jul 15 15:55

[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Kike .Asekas


I delete the database. I see "cannot find start time" in the templates of 
the webpages.
The log:
Jul 15 15:55:51 raspberrypi weewx[11746]: Starting weewx weather system: 
weewx.
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Using configuration file 
/etc/weewx/weewx.conf
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Debug is 1
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Initializing engine
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading station type SDR 
(user.sdr)
Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: driver version 
is 0.64
Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: sensor map is 
{'windDir': 'wind_dir.*.FOWHx080Packet', 'windSpeed': 
'wind_speed.*.FOWHx080Packet', 'outTemp': 'temperature.*.FOWHx080Packet', 
'outHumidity': 'humidity.*.FOWHx080Packet', 'rain_total': 
'rain_total.*.FOWHx080Packet', 'inTemp': 'temperature.*.FOWHx080Packet', 
'inHumidity': 'humidity.*.FOWHx080Packet'}
Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: deltas is 
{'strikes': 'strikes_total', 'rain': 'rain_total'}
Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: MainThread: startup process 
'rtl_433 -q -F json -R 32 -f 868.3M'
Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: stdout-thread: start async 
reader for stdout-thread
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
weewx.engine.StdTimeSynch
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.engine.StdTimeSynch
Jul 15 15:55:52 raspberrypi weewx[11768]: sdr: stderr-thread: start async 
reader for stderr-thread
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
user.extra_sensors_service.ExtraSensorsService
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
user.extra_sensors_service.ExtraSensorsService
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
weewx.engine.StdConvert
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: StdConvert target unit is 
0x11
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.engine.StdConvert
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Loading service 
weewx.engine.StdCalibrate
Jul 15 15:55:52 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.engine.StdCalibrate
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
weewx.engine.StdQC
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.engine.StdQC
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
weewx.wxservices.StdWXCalculate
Jul 15 15:55:53 raspberrypi weewx[11768]: wxcalculate: The following values 
will be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
dewpoint=prefer_hardware, appTemp=prefer_hardware, 
rainRate=prefer_hardware, windrun=prefer_hardware, 
heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
humidex=prefer_hardware, pressure=prefer_hardware, 
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware
Jul 15 15:55:53 raspberrypi weewx[11768]: wxcalculate: The following 
algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.wxservices.StdWXCalculate
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Loading service 
weewx.engine.StdArchive
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Archive will use data 
binding wx_binding
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Record generation will be 
attempted in 'software'
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Using archive interval of 
300 seconds (software record generation)
Jul 15 15:55:53 raspberrypi weewx[11768]: engine: Use LOOP data in hi/low 
calculations: 1
Jul 15 15:55:53 raspberrypi weewx[11768]: manager: Created and initialized 
table 'archive' in database 'weewx.sdb'
Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Created daily summary 
tables
Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Daily summary version is 
2.0
Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Jul 15 15:55:54 raspberrypi weewx[11768]: manager: Starting backfill of 
daily summaries
Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.engine.StdArchive
Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Loading service 
weewx.restx.StdStationRegistry
Jul 15 15:55:54 raspberrypi weewx[11768]: restx: StationRegistry: 
Registration not requested.
Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.restx.StdStationRegistry
Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Loading service 
weewx.restx.StdWunderground
Jul 15 15:55:54 raspberrypi weewx[11768]: restx: Wunderground: Posting not 
enabled.
Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Finished loading service 
weewx.restx.StdWunderground
Jul 15 15:55:54 raspberrypi weewx[11768]: engine: Loading s

Re: [weewx-user] Re: WS3080 Lockup - FineOffsetUsb workaround not working.

2019-07-15 Thread 'Johannes Ebner' via weewx-user
I am using it with a USB Hub from Linksys on a Raspberry Pi Zero W.

uhubctl works without issues. I am shutting down the corresponding USB Port 
of the USB Hub.

Am Montag, 15. Juli 2019 15:08:17 UTC+2 schrieb HoracioDos:
>
> Hello Dave.
>
> Did uhubctl work for you? Which raspberry pi model do you have? Are you 
> using a usb hub?
> uhubctl can disable port 2 but it still provide power to the weather 
> station.so it can reset the WS.
>
> Any hint will be welcome.
> Thanks in advance!
>
>
> On Monday, July 15, 2019 at 7:06:46 AM UTC-3, Dave (G1OGY) wrote:
>>
>> Good news, Johannes!
>> I'm pleased it helps.
>>
>>
>> On Mon, 15 Jul 2019, 10:54 'Johannes Ebner' via weewx-user, <
>> weewx...@googlegroups.com> wrote:
>>
>>> Thanks, works perfectly for me!
>>>
>>> Br,
>>> Johannes
>>>
>>> Am Sonntag, 23. Juni 2019 10:06:18 UTC+2 schrieb Dave, G1OGY:



 On Sunday, 23 June 2019 07:30:53 UTC+1, Johannes Ebner wrote:
>
> How is this script working?
>
> Do you run it once and it stays in the background? Or do you run it 
> via crontab?
>
>
>>
 ATM it is running from the command line as I did not want to reboot the 
 Pi:

  /home/weewx/monitorlockup &

 I have also added that command line to /etc/rc.local so that the script 
 will start on reboot.

 The monitoring script sits in the background waiting for a log print.  
 When weewx writes to the log file the script wakes up and checks the new 
 log line(s) for "Errno 110".  If the string is absent the script goes back 
 to waiting for the next log print.  If the print is an error line then it 
 fires off the second script to powercycle the relevant USB port.
 You can watch it come alive every 5 minutes with `top(1)`.

 Obviously, you will need to have acquired and built the source of 
 `uhubctrl` in advance.

>>> -- 
>>> 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/owhSpmklNlc/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> weewx...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/3ad78732-5dd1-4d75-94f3-f1a8caef38d0%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You 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/de121d37-2e14-415d-8e91-d000f3224e93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Kike .Asekas
But in the database the datetime is in UTC timezone or in local timezone?. 
I datetime field in my database reflects the local time. I think sum the +2 
of my timezone later.

El lunes, 15 de julio de 2019, 13:56:37 (UTC+2), Kike .Asekas escribió:
>
> Hello. I have a raspberry pi with raspbian. It have CEST+0200 timezone as 
> reported by date +"%Z %z". If I type 'date' my local time is reported 
> correctly, but in the reports of weewx the time is 2 hours later.  I mean 
> if it's 10:00 the webpages say 12:00.
> In python 
> datetime.datetime.now() gives the current local time correctly
> and 
> datetime.datetime.utcnow()gives 2 hours before correctly too.
> The database have the correct local time too.
>
>

-- 
You 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/485e8e20-9397-4194-9363-e0e90234138e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Incorrect time in reports

2019-07-15 Thread Kike .Asekas
2 hours later.

El lunes, 15 de julio de 2019, 15:22:17 (UTC+2), Andrew Milner escribió:
>
> how is the date being put on the webpages?
>
>
>
> On Monday, 15 July 2019 16:12:30 UTC+3, Kike .Asekas wrote:
>>
>> The current local time correctly.
>>
>> El lunes, 15 de julio de 2019, 15:07:45 (UTC+2), Thomas Keffer escribió:
>>>
>>> What do you get if you try
>>>
>>> python -c "import time; print time.strftime('%x %X')"
>>>
>>> -tk
>>>
>>> On Mon, Jul 15, 2019 at 4:56 AM Kike .Asekas  wrote:
>>>
 Hello. I have a raspberry pi with raspbian. It have CEST+0200 timezone 
 as reported by date +"%Z %z". If I type 'date' my local time is reported 
 correctly, but in the reports of weewx the time is 2 hours later.  I 
 mean if it's 10:00 the webpages say 12:00.
 In python 
 datetime.datetime.now() gives the current local time correctly
 and 
 datetime.datetime.utcnow()gives 2 hours before correctly too.
 The database have the correct local time too.

 -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/649312fb-f97d-484e-9815-7b4f814a9e75%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>

-- 
You 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/56b5fce2-ecc3-439b-95b2-4209833e8e4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Incorrect time in reports

2019-07-15 Thread Thomas Keffer
Well, all weewx does is use strftime. Basically,

time.strftime("%x %X"), time.localtime(v))


We will need to see the log to go any farther. Stop weewx, set debug=1,
restart, post the log through the first reporting cycle.

-tk



On Mon, Jul 15, 2019 at 6:12 AM Kike .Asekas  wrote:

> The current local time correctly.
>
> El lunes, 15 de julio de 2019, 15:07:45 (UTC+2), Thomas Keffer escribió:
>>
>> What do you get if you try
>>
>> python -c "import time; print time.strftime('%x %X')"
>>
>> -tk
>>
>> On Mon, Jul 15, 2019 at 4:56 AM Kike .Asekas  wrote:
>>
>>> Hello. I have a raspberry pi with raspbian. It have CEST+0200 timezone
>>> as reported by date +"%Z %z". If I type 'date' my local time is reported
>>> correctly, but in the reports of weewx the time is 2 hours later.  I
>>> mean if it's 10:00 the webpages say 12:00.
>>> In python
>>> datetime.datetime.now() gives the current local time correctly
>>> and
>>> datetime.datetime.utcnow()gives 2 hours before correctly too.
>>> The database have the correct local time too.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/649312fb-f97d-484e-9815-7b4f814a9e75%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You 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/2973beaf-baee-4682-b370-98b204c4e77e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You 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/CAPq0zED1z9X7vnsQceEQ%2BGCqdwzj5%3DARGjuZL5sZfZhxdngwfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Incorrect time in reports

2019-07-15 Thread Andrew Milner
how is the date being put on the webpages?



On Monday, 15 July 2019 16:12:30 UTC+3, Kike .Asekas wrote:
>
> The current local time correctly.
>
> El lunes, 15 de julio de 2019, 15:07:45 (UTC+2), Thomas Keffer escribió:
>>
>> What do you get if you try
>>
>> python -c "import time; print time.strftime('%x %X')"
>>
>> -tk
>>
>> On Mon, Jul 15, 2019 at 4:56 AM Kike .Asekas  wrote:
>>
>>> Hello. I have a raspberry pi with raspbian. It have CEST+0200 timezone 
>>> as reported by date +"%Z %z". If I type 'date' my local time is reported 
>>> correctly, but in the reports of weewx the time is 2 hours later.  I 
>>> mean if it's 10:00 the webpages say 12:00.
>>> In python 
>>> datetime.datetime.now() gives the current local time correctly
>>> and 
>>> datetime.datetime.utcnow()gives 2 hours before correctly too.
>>> The database have the correct local time too.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/649312fb-f97d-484e-9815-7b4f814a9e75%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You 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/c5cfa949-b4da-4ed5-bc46-ae3a689cb952%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Incorrect time in reports

2019-07-15 Thread Kike .Asekas
The driver I use is SDR. I have debug enabled and I see the packets created 
by sdr and in the field datetime in Unix epoch format it's correct too.


-- 
You 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/bd31dd3b-3bb5-4db7-83c9-56ad7921b883%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Incorrect time in reports

2019-07-15 Thread Kike .Asekas
The current local time correctly.

El lunes, 15 de julio de 2019, 15:07:45 (UTC+2), Thomas Keffer escribió:
>
> What do you get if you try
>
> python -c "import time; print time.strftime('%x %X')"
>
> -tk
>
> On Mon, Jul 15, 2019 at 4:56 AM Kike .Asekas  > wrote:
>
>> Hello. I have a raspberry pi with raspbian. It have CEST+0200 timezone as 
>> reported by date +"%Z %z". If I type 'date' my local time is reported 
>> correctly, but in the reports of weewx the time is 2 hours later.  I 
>> mean if it's 10:00 the webpages say 12:00.
>> In python 
>> datetime.datetime.now() gives the current local time correctly
>> and 
>> datetime.datetime.utcnow()gives 2 hours before correctly too.
>> The database have the correct local time too.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/649312fb-f97d-484e-9815-7b4f814a9e75%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You 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/2973beaf-baee-4682-b370-98b204c4e77e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Re: WS3080 Lockup - FineOffsetUsb workaround not working.

2019-07-15 Thread HoracioDos
Hello Dave.

Did uhubctl work for you? Which raspberry pi model do you have? Are you 
using a usb hub?
uhubctl can disable port 2 but it still provide power to the weather 
station.so it can reset the WS.

Any hint will be welcome.
Thanks in advance!


On Monday, July 15, 2019 at 7:06:46 AM UTC-3, Dave (G1OGY) wrote:
>
> Good news, Johannes!
> I'm pleased it helps.
>
>
> On Mon, 15 Jul 2019, 10:54 'Johannes Ebner' via weewx-user, <
> weewx...@googlegroups.com > wrote:
>
>> Thanks, works perfectly for me!
>>
>> Br,
>> Johannes
>>
>> Am Sonntag, 23. Juni 2019 10:06:18 UTC+2 schrieb Dave, G1OGY:
>>>
>>>
>>>
>>> On Sunday, 23 June 2019 07:30:53 UTC+1, Johannes Ebner wrote:

 How is this script working?

 Do you run it once and it stays in the background? Or do you run it via 
 crontab?


>
>>> ATM it is running from the command line as I did not want to reboot the 
>>> Pi:
>>>
>>>  /home/weewx/monitorlockup &
>>>
>>> I have also added that command line to /etc/rc.local so that the script 
>>> will start on reboot.
>>>
>>> The monitoring script sits in the background waiting for a log print.  
>>> When weewx writes to the log file the script wakes up and checks the new 
>>> log line(s) for "Errno 110".  If the string is absent the script goes back 
>>> to waiting for the next log print.  If the print is an error line then it 
>>> fires off the second script to powercycle the relevant USB port.
>>> You can watch it come alive every 5 minutes with `top(1)`.
>>>
>>> Obviously, you will need to have acquired and built the source of 
>>> `uhubctrl` in advance.
>>>
>> -- 
>> 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/owhSpmklNlc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/3ad78732-5dd1-4d75-94f3-f1a8caef38d0%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You 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/51dc66c7-d2ca-4e85-bb11-5e44f657fb63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Incorrect time in reports

2019-07-15 Thread Thomas Keffer
What do you get if you try

python -c "import time; print time.strftime('%x %X')"

-tk

On Mon, Jul 15, 2019 at 4:56 AM Kike .Asekas  wrote:

> Hello. I have a raspberry pi with raspbian. It have CEST+0200 timezone as
> reported by date +"%Z %z". If I type 'date' my local time is reported
> correctly, but in the reports of weewx the time is 2 hours later.  I mean
> if it's 10:00 the webpages say 12:00.
> In python
> datetime.datetime.now() gives the current local time correctly
> and
> datetime.datetime.utcnow()gives 2 hours before correctly too.
> The database have the correct local time too.
>
> --
> You 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/649312fb-f97d-484e-9815-7b4f814a9e75%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You 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/CAPq0zEA2B66f5_S-_U6gEBYZ5vdLcGmPB%3DiP41Bqw4wEGw0b-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Re: Fresh install of weewx 3.9.1 with WMR300A on RPI, Non-positive value for record field 'interval': 0.0

2019-07-15 Thread Miguel Angel Peña Morales
Hello again.
Finally the result and the ultimate reason of my problem. 


THE RASPI 3 WAS FAULTY!!!


After 3 months of sort of working, it gived up locking up and don't even 
booting. Tried to reinstall raspbian and it failed miserably. Changed the 
sdcard and nothing... Connected a monitor and the screen showed the typical 
image corruption of fauty memory. Now it is working again flawessly on a 
Rpi 4 4GB. You can visit it on http://meteo.logrosan.com. I think it took 
me 30 minutes to install weewx and have it working from apt.

Thanks for everything and suspect some HW problem when it's kind of a 
impossible thing happening.

Regards!

El domingo, 26 de mayo de 2019, 20:14:42 (UTC+2), Miguel Angel Peña Morales 
escribió:
>
>
> Also, are there any other USB devices connected?
> No
> How long is your USB cable that connects to the WMR300?
> Is a standard cable. 1m or so. It worked before with a weather 
> display setup.
> Are you using an official Raspberry Pi power supply or another brand?
> Im using a Samsung brand PS. Shoud be enough to run as no message 
> of not enough juice is showing.
> (Newer RPI's draw up to 2.5amps, so it matters)...
>
> pi@raspberrypi:~ $ dmesg | grep "Machine model"
> [0.00] OF: fdt: Machine model: Raspberry Pi 3 Model B Rev 1.2
>
> pi@raspberrypi:~ $  uname -a
> Linux raspberrypi 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 
> armv7l GNU/Linux
>
> pi@raspberrypi:~ $ cat /etc/os-release
> PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
> 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";
>
> pi@raspberrypi:~ $ cat /proc/cpuinfo
> processor   : 0
> model name  : ARMv7 Processor rev 4 (v7l)
> BogoMIPS: 38.40
> Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
> idivt vfpd32 lpae evtstrm crc32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x0
> CPU part: 0xd03
> CPU revision: 4
>
>
> processor   : 1
> model name  : ARMv7 Processor rev 4 (v7l)
> BogoMIPS: 38.40
> Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
> idivt vfpd32 lpae evtstrm crc32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x0
> CPU part: 0xd03
> CPU revision: 4
>
>
> processor   : 2
> model name  : ARMv7 Processor rev 4 (v7l)
> BogoMIPS: 38.40
> Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
> idivt vfpd32 lpae evtstrm crc32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x0
> CPU part: 0xd03
> CPU revision: 4
>
>
> processor   : 3
> model name  : ARMv7 Processor rev 4 (v7l)
> BogoMIPS: 38.40
> Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
> idivt vfpd32 lpae evtstrm crc32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x0
> CPU part: 0xd03
> CPU revision: 4
>
>
> Hardware: BCM2835
> Revision: a22082
> Serial  : e4f0db99
>
> pi@raspberrypi:~ $ head -3 /proc/meminfo
> MemTotal: 948304 kB
> MemFree:  548404 kB
> MemAvailable: 723760 kB
> pi@raspberrypi:~ $ htop
>
>
>
>   1  [|||   2.9%]   Tasks: 62, 
> 59 thr; 1 running
>   2  [| 0.7%]   Load 
> average: 0.41 0.54 0.50
>   3  [  0.0%]   Uptime: 05
> :46:29
>   4  [  0.0%]
>   Mem[|||  169M/926M]
>   Swp[ 0K/100.0M]
>
>
>   PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
> 1 root   20   0 27136  6132  4880 S  0.0  0.6  0:06.25 /sbin/init
>  1245 root   20   0  108M 69052  8748 S 32.0  7.3  2h23:24 ├─ python /
> usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /e
>  1252 root   20   0  108M 69052  8748 S  0.0  7.3  0:03.03 │  ├─ 
> python /usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid
>  1251 root   20   0  108M 69052  8748 S  0.0  7.3  0:00.05 │  ├─ 
> python /usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid
>  1250 root   20   0  108M 69052  8748 S  0.0  7.3  0:00.00 │  └─ 
> python /usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid
>   794 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.34 ├─ /usr/lib
> /udisks2/udisksd --no-debug
>   802 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.00 │  ├─ /usr/
> lib/udisks2/udisksd --no-debug
>   801 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.00 │  ├─ /usr/
> lib/udisks2/udisksd --no-debug
>   800 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.01 │  ├─ /usr/
> lib/udisks2/udisksd --no-de

[weewx-user] Incorrect time in reports

2019-07-15 Thread Kike .Asekas
Hello. I have a raspberry pi with raspbian. It have CEST+0200 timezone as 
reported by date +"%Z %z". If I type 'date' my local time is reported 
correctly, but in the reports of weewx the time is 2 hours later.  I mean 
if it's 10:00 the webpages say 12:00.
In python 
datetime.datetime.now() gives the current local time correctly
and 
datetime.datetime.utcnow()gives 2 hours before correctly too.
The database have the correct local time too.

-- 
You 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/649312fb-f97d-484e-9815-7b4f814a9e75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Davis... IP Datalogger.

2019-07-15 Thread Ruben Navarro Huedo
Hello friends:
I am trying to run last weewx with Davis and IP Datalogger.
I have other davis using USB Datalogger and all is fine.
IP Datalogger is uploading to weatherlink.com but it hasn't data for weewx 
at the archive interval.
How could i solve it?
I don't want upload to weatherlink... i only need data on weewx.

Thank's a lot.

-- 
You 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/be94f9c9-7ece-4671-9ba2-c1da0e9765ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: Tutorial for installing WeeWX Docker?

2019-07-15 Thread Tom Mitchell
Hi, didn't see this. I am the one who built that Docker support, and have 
been using it for quite a while now for several sites. Happy to help.

On Friday, May 17, 2019 at 2:33:47 PM UTC-4, Roelof Schuiling wrote:
>
> Is there perhaps a tutorial available for installing a Docker image for 
> WeeWX?
>
> I created a container from https://hub.docker.com/r/mitct02/weewx through 
> Portainer (basically just pulling the image and linking a volume). It 's 
> running, I can enter a terminal but I can't locate weewxd.
>
> Is there some explanation available for Docker, perhaps a step by step 
> tutorial?
>
> Thanks in advance!
>

-- 
You 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/e1155995-f996-4e9d-a485-0fe06cf957d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Re: WS3080 Lockup - FineOffsetUsb workaround not working.

2019-07-15 Thread Dave (G1OGY)
Good news, Johannes!
I'm pleased it helps.


On Mon, 15 Jul 2019, 10:54 'Johannes Ebner' via weewx-user, <
weewx-user@googlegroups.com> wrote:

> Thanks, works perfectly for me!
>
> Br,
> Johannes
>
> Am Sonntag, 23. Juni 2019 10:06:18 UTC+2 schrieb Dave, G1OGY:
>>
>>
>>
>> On Sunday, 23 June 2019 07:30:53 UTC+1, Johannes Ebner wrote:
>>>
>>> How is this script working?
>>>
>>> Do you run it once and it stays in the background? Or do you run it via
>>> crontab?
>>>
>>>

>> ATM it is running from the command line as I did not want to reboot the
>> Pi:
>>
>>  /home/weewx/monitorlockup &
>>
>> I have also added that command line to /etc/rc.local so that the script
>> will start on reboot.
>>
>> The monitoring script sits in the background waiting for a log print.
>> When weewx writes to the log file the script wakes up and checks the new
>> log line(s) for "Errno 110".  If the string is absent the script goes back
>> to waiting for the next log print.  If the print is an error line then it
>> fires off the second script to powercycle the relevant USB port.
>> You can watch it come alive every 5 minutes with `top(1)`.
>>
>> Obviously, you will need to have acquired and built the source of
>> `uhubctrl` in advance.
>>
> --
> 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/owhSpmklNlc/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/3ad78732-5dd1-4d75-94f3-f1a8caef38d0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You 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/CAKOSXUFQ540EaABn-_7RnFdsGhmjZy20tYq-XvHo31rLVAcxCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [weewx-user] Re: WS3080 Lockup - FineOffsetUsb workaround not working.

2019-07-15 Thread 'Johannes Ebner' via weewx-user
Thanks, works perfectly for me!

Br,
Johannes

Am Sonntag, 23. Juni 2019 10:06:18 UTC+2 schrieb Dave, G1OGY:
>
>
>
> On Sunday, 23 June 2019 07:30:53 UTC+1, Johannes Ebner wrote:
>>
>> How is this script working?
>>
>> Do you run it once and it stays in the background? Or do you run it via 
>> crontab?
>>
>>
>>>
> ATM it is running from the command line as I did not want to reboot the Pi:
>
>  /home/weewx/monitorlockup &
>
> I have also added that command line to /etc/rc.local so that the script 
> will start on reboot.
>
> The monitoring script sits in the background waiting for a log print.  
> When weewx writes to the log file the script wakes up and checks the new 
> log line(s) for "Errno 110".  If the string is absent the script goes back 
> to waiting for the next log print.  If the print is an error line then it 
> fires off the second script to powercycle the relevant USB port.
> You can watch it come alive every 5 minutes with `top(1)`.
>
> Obviously, you will need to have acquired and built the source of 
> `uhubctrl` in advance.
>

-- 
You 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/3ad78732-5dd1-4d75-94f3-f1a8caef38d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: SteelSeries Gauges and Weather Forecast?

2019-07-15 Thread mwall


On Sunday, July 14, 2019 at 6:00:47 PM UTC-4, Derek Tombrello wrote:
>
> Let me ask you something... the Acurite 01525 has it's own built in 
> weather forecaster. Is it possible for weewx to retrieve this data directly 
> from the PWS rather than calculating it on it's own? I'm guessing no based 
> on http://www.weewx.com/docs/hardware.htm#acurite ?
>

possible: yes

however, the weewx database can contain only numeric values.  so you'd have 
to map the forecast states to some kind of index if you want to store them 
in the weewx database.

or just track them in the 'current' packet, not in the database

and of course you'd want to generalize it so it works with any weather 
station hardware that provides a forecast

some years ago i started doing that in the forecast extension, with the 
intent of collecting forecast states from *any* type of hardware that has 
them.  then use those to compare the quality of hardware-based 
forecasters.  i'm guessing that most use some variant of the zambretti, and 
it would be interesting to log them all with the corresponding 
temperatures, pressures, and other indicators to find out for sure.

m

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/db237c8e-9e73-4526-a3a8-3a8bcca580c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: SteelSeries Gauges and Weather Forecast?

2019-07-15 Thread mwall
On Sunday, July 14, 2019 at 5:49:42 PM UTC-4, Derek Tombrello wrote:
>
> Now I just have to figure out how to change the forecast wording... I'm 
> not sure what "fairly fine, showerly later" means! lol
>

in your weewx configuration file, do this:

[Forecast]
[[Labels]]
[[[Zambretti]]]
A = Settled fine
B = Fine weather
...

for the complete list, look in the comments in forecast.py

this is also how you do translations in forecast for the compass 
directions, weather conditions, tide heights, etc.

m 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/de76df4f-d27f-42ab-8221-47fab19639eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] Re: AS3935 database issue

2019-07-15 Thread dan Forster
Mikael,

When you get some time, it might be nice to document the whole procedure 
you took to get everything working perfectly, in simple steps (which you 
can copy and paste), so new and old can use easily. There is much interest 
in those new inexpensive storm detectors sold on eBay and lots of weewx'ers 
out there...

Take care

Dan

On Friday, 12 July 2019 23:13:11 UTC+1, Mikael Fredriksson wrote:
>
> Gary,
>
> now things looks like I want it to look! I'm sure I hadn't solved this 
> myself so a big thank you for that solution :) 
> This forum is just great for people like me who isn't very good at this 
> stuff. 
> But I know I'm learning a lot when things don't go as I want and I get to 
> read much about it. I think many solutions are in the weewx docs but 
> sometimes it gets to difficult for a beginner!
>
>
> Once again, thank you Gary for helping me!
>
> Mikael
>
>
> Den fredag 12 juli 2019 kl. 23:16:28 UTC+2 skrev gjr80:
>>
>> Mikael, 
>>
>> I had assumed that WeeWX had a default format for ‘count’ fields but it 
>> appears that one does not exist, so we will have to define one. There is no 
>> default label either, though not that one is really required (as hPa is 
>> required for pressure) but we might as well add one. Try adding the 
>> following to the end of extensions.py: 
>>
>> weewx.units.default_unit_format_dict['count'] = '%.0f' 
>> weewx.units.default_unit_label_dict['count'] = '' 
>>
>> Again save and restart WeeWX. 
>>
>> Note that the above format and label can be overridden (as with any other 
>> observation) from skin.conf or the [StdReport] stanza of weewx.conf. 
>>
>> 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/10362092-89bf-4739-acd2-cc9a75d8d27b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.