LaCrosse WS2300 & WS2350 support

[Devonian]

I seem to remember that others have asked if the Lacrosse WS23xx weather station is supported in Weewx (I know it's currently not).

However, I just came across this python driver here...

http://www.lavrsen.dk/foswiki/bin/view/Open2300/Ws2300Python

Leading me to here...

http://ace-host.stuart.id.au/russell/files/ws2300/

http://ace-host.stuart.id.au/russell/files/ws2300/ws2300.1.html

 

I have a ws2300 and am no programmer by any stretch of the imagination, but could this driver be incorporated/made to work with Weewx without too much trouble?

 

I have used Open2300 and it worked OK on Debian, putting data into a MySQL database, although the install/setup was not 'simple'.

 

I'd love to be able to run Weewx on a Raspberry-Pi with my WS2300 as I've just done the wireless mod to 'trick' the sender to transmit data every 8 seconds (same as if it were cabled).

 

What are the chances?

Anyone willing to help?

 

Regards,

 

Nigel.

 

 

 

 

[Thomas Keffer]

Nigel,

I took a (quick) look at the driver you linked to. Unfortunately, it's very tightly coupled with the main program. The "driver" itself reads only bytes and depends on higher level services to interpret them. Those, in turn, are tightly coupled with the read model, which is centered around "read requests," python structures that encapsulate what's in the WS2300 memory model.

In short, it would take a lot to disentangle the mess and fit it into the much simpler weewx driver model.

If someone wants to take it on, I'm happy to support him/her, but this is way more than an afternoon's project.

-tk

 

 

 

 

--
You received this message because you are subscribed to the Google Groups "Weewx user's group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Tom Keffer

kef...@threefools.org
+1 541-386-8891 (h)
+1 541-490-9507 (c)

Skype: tkeffer

[Nigel Head]

Hi Tom,

 

OK, shame - I did say I'm no programmer didn't I !!

It would be real good to get a ws2300 driver as the WS23xx is still sold and for the money is quite decent.

 

Never mind, I also have a Davis Vantage Pro2, new in the box waiting to be installed.

 

Regds,

 

Nigel.

--
You received this message because you are subscribed to a topic in the Google Groups "Weewx user's group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/Ha_VqoBaySQ/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[pingus]

Funny, the same weather stations as I have :-)

[Devonian]

OK, found this

http://code.google.com/p/wfrog/source/browse/trunk/wfdriver/station/ws23xx.py?r=643

  

Still needs the driver I linked to in my firtst post, but might be a work around ?

 

 

Nigel.

[mwall]

to those of you with lacrosse ws 2300 stations,

i added support for the lacrosse ws 2300 by copying the minimal amount from Russell Stuart's ws2300.py implementation.

the driver will be included in the 2.6 release of weewx.  if you want to play before 2.6 is released, then install weewx 2.5, download the ws23xx.py driver, place ws23xx.py in bin/weewx/drivers

http://sourceforge.net/p/weewx/code/HEAD/tree/trunk/bin/weewx/drivers/ws23xx.py

the minimal configuration in weewx.conf looks like this:

[Station]
    ...
    station_type = WS23xx

[WS23xx]
    port = /dev/ttyUSB0
    driver = weewx.drivers.ws23xx

for the port, /dev/ttyUSB0 is typical for a connection with a USB-serial adapter. use /dev/ttyS0 for a direct serial connection.

not every USB-serial adapter will work.  the ATEN UC-232A USB-serial adapter is known to work.

btw, the wfrog wrapper would not work - at least not in wfrog as of nov 2013 with the latest ws2300.py.

m

[Scott Wyman]

I have been experimenting with the ws23xx driver with a WS2316 station. I'm trying to determine how it handles the wind data, is the value stored in current.windSpeed the wind speed value that was pulled from the station at the time of the archive interval, or is weewx calculating some kind of average?

Also, since the WS2316 does not supply it's own gust value, how does the database field current.windGust get created? Is this an average value calculated by weewx?

Thanks.

[mwall]

On Friday, November 29, 2013 5:34:43 PM UTC-5, Scott Wyman wrote:

I have been experimenting with the ws23xx driver with a WS2316 station. I'm trying to determine how it handles the wind data, is the value stored in current.windSpeed the wind speed value that was pulled from the station at the time of the archive interval, or is weewx calculating some kind of average?

Also, since the WS2316 does not supply it's own gust value, how does the database field current.windGust get created? Is this an average value calculated by weewx?

hi scott,

the driver uses the maximum wind speed as reported by the station for the LOOP value of windGust.

since the ws23xx stations have no notion of gust, it would probably be more correct to use None for windGust and windGustDir.

(the ws2317 anemometer i have for development has not been working, so i've been developing the ws23xx.py driver without any wind data)

suggestions are welcome!

m

[mwall]

On Friday, November 29, 2013 5:34:43 PM UTC-5, Scott Wyman wrote:

I have been experimenting with the ws23xx driver with a WS2316 station. I'm trying to determine how it handles the wind data, is the value stored in current.windSpeed the wind speed value that was pulled from the station at the time of the archive interval, or is weewx calculating some kind of average?

current.windSpeed should display the current wind speed as reported by the station.

the driver polls the station periodically, with a polling interval that depends on the type of connection (wired or wireless).

the ws23xx driver reads the following values every polling interval:

inside temperature
inside humidity
outside temperature
outside humidity
absolute pressure
wind speed
wind speed max
latest wind direction
rain in last hour
rain total
dewpoint
windchill
connection type

you can see where these are located in the memory map:

http://www.lavrsen.dk/foswiki/bin/view/Open2300/OpenWSMemoryMap

[Scott Wyman]

Ah, ok, thank you for the details. Yeah, the max wind speed stored on the station doesn't do me much good since that needs to be reset manually on the station.

Ultimately, I was hoping to be able to store current.windGust as the max speed over the past 10 minutes or something like that. But I assume that calculation would have to be done on the weewx side.

Thanks again.

[Devonian]

@ mwall

Thanks for your contribution.

I am a bit late here, but will try this out on my WS2310 which is modified to use the 2350 style cup anemometer and the 8 second wireless update (same as for cabled version).

There is a critical error in the link you have in your script description referencing the wireless mod (line 75) - read more here:

http://www.wxforum.net/index.php?topic=2196.0

I guess I should set the polling_interval parameter for cabled '0' instead of 'None' (even though it's modified wireless) to force an 8 second update??

Best regards,

Nigel.

[mwall]

On Sunday, December 1, 2013 1:55:49 PM UTC-5, Devonian wrote:

There is a critical error in the link you have in your script description referencing the wireless mod (line 75) - read more here:

http://www.wxforum.net/index.php?topic=2196.0

I guess I should set the polling_interval parameter for cabled '0' instead of 'None' (even though it's modified wireless) to force an 8 second update??

nigel,

thanks for that link about the wireless mod.  i have updated the driver comments.

please leave the polling_interval undefined, at least to start.  when no polling_interval is defined, the ws23xx driver will detect the connection station (wired, wireless, or lost) then use an appropriate polling interval (8, 30, or 60 seconds, respectively).  if the connection type changes, the driver will adjust the polling interval.

if you specify a polling_interval (in seconds) then that is what will be used, regardless of the connection type.

m

[mwall]

On Sunday, December 1, 2013 1:55:49 PM UTC-5, Devonian wrote:

I am a bit late here, but will try this out on my WS2310 which is modified to use the 2350 style cup anemometer and the 8 second wireless update (same as for cabled version).

sorry, i missed the bit about you having done the wireless update mod.  in this case simply specify the polling_interval like this in weewx.conf:

[WS23xx]
    ...
    polling_interval = 8
 

[mwall]

nigel,

please use r1762 (driver version 0.9)

this fixes some type casting issues when the driver retrieves values from weewx.conf

m

[Devonian]

Thanks for the rapid update and all points noted.

It will be a week or two before I get time to install and test it as I am running wview at the moment and I've just started a complete bathroom re-fit.

Regds,

Nigel. 

 

[Scott Wyman]

Hi,

I know the ws32xx driver is still a work in progress, and I've been testing it for a couple of days.  One thing I noticed is that initially everything starts up ok and the looping begins every 10-12 seconds as expected (I am using a cabled connection). However, as soon as it does the first archive interval (I have it set to every 5 minutes), the looping interval slows to about once per minute.  Other than the new driver file and the entries in the weewx.conf file, are there any other updated engine files required?

I currently have version 2.5 installed, I'm thinking I should wait until there is an updated 2.6 alpha or beta to test it out further.  However, I certainly don't mind tinkering a bit to help test out the new driver.

-Scott

[mwall]

On Tuesday, December 3, 2013 1:44:57 AM UTC-5, Scott Wyman wrote:

I know the ws32xx driver is still a work in progress, and I've been testing it for a couple of days.  One thing I noticed is that initially everything starts up ok and the looping begins every 10-12 seconds as expected (I am using a cabled connection). However, as soon as it does the first archive interval (I have it set to every 5 minutes), the looping interval slows to about once per minute.  Other than the new driver file and the entries in the weewx.conf file, are there any other updated engine files required?

I currently have version 2.5 installed, I'm thinking I should wait until there is an updated 2.6 alpha or beta to test it out further.  However, I certainly don't mind tinkering a bit to help test out the new driver.

scott,

unless you set the polling interval, you should see loop data every 10 seconds or so for a wired connection, 30 seconds or so for a wireless connection or 60 seconds or so if connection is lost between console and sensors.  the archive interval will depend on what is set in the station - the factory default is 60 minutes.

it varies from one station type to another, but this highlights a difference between wview and weewx.  wview tends to ignore the station's hardware archive interval - it uses whatever is specified in the wview configuration. weewx respects the hardware setting - if the weewx.conf setting does not match the station setting, weewx will use the station setting. this is probably because weewx tries to implement 'catchup' - reading archive records from the station when it first starts up to fill gaps in the database.  wview does not.

to see what is happening, please try the following:

- ensure that you are using the latest ws23xx.py driver (driver version 0.9)

- set debug=1 in weewx.conf

- watch the log when weewx starts up.  we are interested in the first 30 lines or so, in particular messages about the archive interval and polling interval.

- watch the log for messages about 'connection changed' or 'using X second polling interval for Y connection'.  if you see these after the initial startup, it means your console is losing connection with the sensors.  when this happens, weewx starts polling at a longer interval (60 seconds) until the connection is re-established.  this should affect the loop timing, but not the archive record timing.

you can force weewx to poll the station at a regular interval by setting polling_interval. for example for an 8 second interval:

[WS23xx]
    polling_interval=8

if you are working with weewx directly from the repository, beware that the ws23xx driver in 2.6 might be a bit behind the driver in 2.5 - i have been committing changes to 2.5 then occasionally merging those changes into the 2.6 branch.  i am doing most of the ws23xx testing on a bog standard 2.5.

m

[Scott Wyman]

Ok, thank you, I'm going to play around with it some more tonight. 

I'll watch the log to see if the connection status is changing from 'cabled' to 'lost' for some reason during the first archive action.

--

[Scott Wyman]

Hi,

Ran some more tests with the WS23xx driver, here is the results. When I start up weewx, all appears normal, here the log snippets:

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Initializing weewx version 2.5.0

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Using Python 2.7.3 (default, Sep 26 2013, 20:03:06) #012[GCC 4.6.3               ]

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Using configuration file /home/weewx/weewx.conf

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Loading station type WS23xx (weewx.drivers.ws23xx)

Dec  3 12:48:48 ubuntu-server weewx[8840]: ws23xx: serial port is /dev/ttyS3

Dec  3 12:48:48 ubuntu-server weewx[8840]: ws23xx: pressure offset is None

Dec  3 12:48:48 ubuntu-server weewx[8840]: ws23xx: polling interval is None

Dec  3 12:48:48 ubuntu-server weewx[8840]: ws23xx: windchill will be read from station

Dec  3 12:48:48 ubuntu-server weewx[8840]: ws23xx: dewpoint will be read from station

Dec  3 12:48:48 ubuntu-server weewx[8840]: ws23xx: forcing record_generation to 'software'

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdTimeSynch

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdTimeSynch

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdConvert

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: StdConvert target unit is 0x1

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdConvert

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdCalibrate

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdCalibrate

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdQC

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdQC

Dec  3 12:48:48 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdArchive

Dec  3 12:48:49 ubuntu-server weewx[8840]: ws23xx: station archive interval is 5 minutes

Dec  3 12:48:51 ubuntu-server weewx[8840]: ws23xx: station archive interval is 5 minutes

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Using station hardware archive interval of 300

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Record generation will be attempted in 'software'

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Use LOOP data in hi/low calculations: 1

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Using archive database: archive_sqlite

Dec  3 12:48:51 ubuntu-server weewx[8840]: stats: Schema exists with 16 elements

Dec  3 12:48:51 ubuntu-server weewx[8840]: stats: Backfilling stats database.

Dec  3 12:48:51 ubuntu-server weewx[8840]: stats: stats database up to date.

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Using stats database: stats_sqlite

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdArchive

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdPrint

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdPrint

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdRESTful

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Data will not be posted to Wunderground

Dec  3 12:48:51 ubuntu-server weewx[8840]:     **** required parameter ''station'' is not specified

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Data will not be posted to PWSweather

Dec  3 12:48:51 ubuntu-server weewx[8840]:     **** required parameter ''station'' is not specified

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Data will not be posted to CWOP

Dec  3 12:48:51 ubuntu-server weewx[8840]:     **** required parameter ''station'' is not specified

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Data will not be posted to StationRegistry

Dec  3 12:48:51 ubuntu-server weewx[8840]:     **** required parameter ''register_this_station'' is not specified

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: No RESTful upload sites. No need to start thread.

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdRESTful

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Loading service weewx.wxengine.StdReport

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Finished loading service weewx.wxengine.StdReport

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Starting up weewx version 2.5.0

Dec  3 12:48:51 ubuntu-server weewx[8840]: wxengine: Station does not support reading the time

Dec  3 12:48:51 ubuntu-server weewx[8840]: ws23xx: station archive interval is 5 minutes

Dec  3 12:48:52 ubuntu-server weewx[8840]: ws23xx: using computer clock with latest_ts of 2013-12-03 12:43:52 HST (1386               110632)

Dec  3 12:48:52 ubuntu-server weewx[8840]: ws23xx: count is 163 to satisfy timestamp of 2013-12-02 20:30:00 HST (138605               2200)

Dec  3 12:48:53 ubuntu-server weewx[8840]: ws23xx: downloading 163 records from station

-- it continues to load the saved data from the console then starts the main packet loop--

Dec  3 12:50:28 ubuntu-server weewx[8840]: wxengine: Starting main packet loop.

Dec  3 12:50:31 ubuntu-server weewx[8840]: ws23xx: connection changed from unknown to cable

Dec  3 12:50:31 ubuntu-server weewx[8840]: ws23xx: using 8 second polling interval for cable connection

--As I watch, looping begins and appears normal at 10 - 12 second intervals--

LOOP:   2013-12-03 12:50:31 HST (1386111031) {'barometer': 29.640359353267044, 'windchill': 78.584, 'dew

LOOP:   2013-12-03 12:50:41 HST (1386111041) {'barometer': 29.640359353267044, 'windchill': 77.252000000

LOOP:   2013-12-03 12:50:55 HST (1386111055) {'barometer': 29.637293532067908, 'windchill': 78.926, 'dew 

LOOP:   2013-12-03 12:51:05 HST (1386111065) {'barometer': 29.637293532067908, 'windchill': 76.712, 'dew

etc...

Then it hits the first archive interval at 12:55:

Dec  3 12:55:23 ubuntu-server weewx[8840]: Archive: added archive record 2013-12-03 12:55:00 HST (1386111300)

Dec  3 12:55:23 ubuntu-server weewx[8840]: reportengine: Running reports for latest time in the database.

Dec  3 12:55:23 ubuntu-server weewx[8840]: reportengine: Running report StandardReport

Dec  3 12:55:23 ubuntu-server weewx[8840]: reportengine: Found configuration file /home/weewx/skins/Standard/skin.conf                for report StandardReport

Dec  3 12:55:24 ubuntu-server weewx[8840]: cheetahgenerator: Running StandardReport report for time period SummaryByMon               th

Dec  3 12:55:24 ubuntu-server weewx[8840]: stats: Schema exists with 16 elements

Dec  3 12:55:24 ubuntu-server weewx[8840]: cheetahgenerator: generated 1 'SummaryByMonth' files for StandardReport in 0               .25 seconds

Dec  3 12:55:24 ubuntu-server weewx[8840]: cheetahgenerator: Running StandardReport report for time period SummaryByYea               r

Dec  3 12:55:24 ubuntu-server weewx[8840]: cheetahgenerator: generated 1 'SummaryByYear' files for StandardReport in 0.               63 seconds

Dec  3 12:55:24 ubuntu-server weewx[8840]: cheetahgenerator: Running StandardReport report for time period ToDate

Dec  3 12:55:27 ubuntu-server weewx[8840]: cheetahgenerator: generated 12 'ToDate' files for StandardReport in 2.31 sec               onds

Dec  3 12:55:29 ubuntu-server weewx[8840]: genimages: Generated 33 images for StandardReport in 2.60 seconds

Dec  3 12:55:29 ubuntu-server weewx[8840]: reportengine: copied 9 files to /var/www/weewx/

Dec  3 12:55:29 ubuntu-server weewx[8840]: reportengine: Running report FTP

Dec  3 12:55:29 ubuntu-server weewx[8840]: reportengine: Found configuration file /home/weewx/skins/Ftp/skin.conf for r               eport FTP

Dec  3 12:55:29 ubuntu-server weewx[8840]: reportengine: FTP upload not requested. Skipped.

Dec  3 12:55:29 ubuntu-server weewx[8840]: reportengine: Running report RSYNC

Dec  3 12:55:29 ubuntu-server weewx[8840]: reportengine: Found configuration file /home/weewx/skins/Rsync/skin.conf for                report RSYNC

Dec  3 12:55:29 ubuntu-server weewx[8840]: reportengine: rsync upload not requested. Skipped.

--and looping will suddenly slow to about every 62 seconds--

LOOP:   2013-12-03 12:55:28 HST (1386111328) {'barometer': 29.63348862609117, 'windchill': 77.468, 'dewp

LOOP:   2013-12-03 12:56:30 HST (1386111390) {'barometer': 29.63348862609117, 'windchill': 77.9, 'dewpoi

LOOP:   2013-12-03 12:57:32 HST (1386111452) {'barometer': 29.630422881354356, 'windchill': 78.566, 'dew

LOOP:   2013-12-03 12:58:36 HST (1386111516) {'barometer': 29.627357136617537, 'windchill': 79.88, 'dewp

I don't see anything in the log indicating that the connection status has changed.

Let me know if you have any ideas.

Thanks, appreciate the time you guys put into this!

-Scott

[mwall]

On Tuesday, December 3, 2013 6:46:38 PM UTC-5, Scott Wyman wrote:

Let me know if you have any ideas.

scott,

thank you for your time and patience to track this down.  it was reverting to a 60 second polling interval each time the loop generator was interrupted.  the bug is fixed in the 0.10 version of the driver (r1767)

m
 

[Scott Wyman]

You're the man... will give it a try shortly :)

A couple of other observations/questions when you have the time:

1.  It appears weewx (or the ws23xx driver) is recognizing the logging interval of my WS2317 as 1 minute less than what it is actually set to. In order to have weeiwx perform a 5 minute archive interval, I had to set my station console to 6 minutes. I had originally noticed this when I had it set to 1 minute and the driver would spit out some div by 0 errors because it was pulling the interval as 0.

2.  Is it possible for weewx to completely ignore the station console logger and not pull station history at startup and only store records in the database every 5 minutes based solely on LOOP data? I had thought setting record_generation = software would do that, but it appears it will always grab console history regardless.  I know your previous explanation outlined how weewx works compared to wview, so I understand if that is not possible.

Thanks!

[Scott Wyman]

Just tried version 1.0, looping appears normal. Thanks!

On Tuesday, December 3, 2013 2:17:11 PM UTC-10, mwall wrote:

[mwall]

driver version 0.11 is available (r1769)

On Tuesday, December 3, 2013 7:55:55 PM UTC-5, Scott Wyman wrote:

1.  It appears weewx (or the ws23xx driver) is recognizing the logging interval of my WS2317 as 1 minute less than what it is actually set to. In order to have weeiwx perform a 5 minute archive interval, I had to set my station console to 6 minutes. I had originally noticed this when I had it set to 1 minute and the driver would spit out some div by 0 errors because it was pulling the interval as 0.

i think this is fixed now, but i'm not certain.  please give it a try.  it is at least self-consistent when you use wee_config_ws23xx to set/get the archive interval.

 

2.  Is it possible for weewx to completely ignore the station console logger and not pull station history at startup and only store records in the database every 5 minutes based solely on LOOP data? I had thought setting record_generation = software would do that, but it appears it will always grab console history regardless.  I know your previous explanation outlined how weewx works compared to wview, so I understand if that is not possible.

i assumed that catchup is always desirable...  if you want to disable catchup, do this:

[WS23xx]
    disable_catchup = True

do you have any thoughts about whether this should be implemented across all drivers?

m

[Scott Wyman]

Ok, will give it a try.

That's an interesting point about whether to implement across all drivers.  While I agree it would be desirable to always catchup, I guess I have never trusted the internal logger on my 2316 (I realized I have a 2316, not 2317 as indicated earlier. Probably one and the same).

Even though QC and spike checks in the various software I've used helps a lot, it seems like I tend to get funky data from the internal logger.

Personally, I like the idea of having the option to disable it,

Speaking of the LOOP data, do you know offhand if there will be plans to somehow calculate some type of value for the windGust field either in the driver itself or as part of the weewx engine since the WS23xx does not supply it? I'm thinking perhaps the max wind speed obtained from the LOOP data over the past 10 minutes or something like that.

[mwall]

On Wednesday, December 4, 2013 12:05:45 AM UTC-5, Scott Wyman wrote:

Speaking of the LOOP data, do you know offhand if there will be plans to somehow calculate some type of value for the windGust field either in the driver itself or as part of the weewx engine since the WS23xx does not supply it? I'm thinking perhaps the max wind speed obtained from the LOOP data over the past 10 minutes or something like that.

tom should chime in on this one.

i'm not convinced of the value of 'gust' when the hardware is not capable of recording it.  and i'm a bit leery of fabricating data in a driver - better to keep drivers as close to the raw data as possible.  for example, one could argue that windchill and dewpoint calculations should be done in a separate 'fill in the gaps' service instead of in each driver.  if it were to be done then we should do it consistently, probably as a weeutil/wxformulas calculation analogous to windchill and dewpoint.

weewx already calculates $day.wind.max, $week.wind.max, $month.wind.max, $year.wind.max

you can create an extension to calculate stats over an arbitrary period.  see the 'all time' and 'seven day' xsearch.py example that comes with weewx.

see this thread for tom's take on max vs gust:

https://groups.google.com/d/msg/weewx-user/VhdvEuj7PDs/JExUW-AhL2sJ

[Scott Wyman]

Driver 0.11 looks good so far. Going to run it for a while tomorrow and keep an eye on it.

On Tuesday, December 3, 2013 6:52:52 PM UTC-10, mwall wrote:

[Scott Wyman]

One thing I am noticing as I watch the LOOP data... in some cases the windSpeed value shown in the loops does not match what I'm seeing on the console. Right now we are having very light winds. As the program loops, values of say 1.1,  2.0,  2.2,  or 3.0 mph on the console are correctly shown in the loop data scrolling down my screen. But then as soon as a value of 3.5mph is on the console, and a loop hits at the same time, it will show 2.23 for windSpeed.  And 4.0mph will show as 2.68. Now, I understand that the looping is not guaranteed to grab every single wind speed value from the sensor, but it appears to be pretty consistent how anything 3.5mph and above are showing as a different value in the loop. Is there some type of speed conversion happening, or should I be seeing the values in the same units as my console?

I certainly may be losing my mind.  The wind usually picks up here during late morning, so I'm going to watch it some more tomorrow.

Thanks for all the updates today... have a good night! (or morning, wherever you may be).

On Tuesday, December 3, 2013 6:52:52 PM UTC-10, mwall wrote:

[Scott Wyman]

I watched this some more and here are some more examples of what I am seeing:

14.0 mph on the console is showing as 10.06 in the loop data
10.0 mph is showing as 7.38
6.9 mph is showing as 5.6
5.3 mph is showing as 4.02

Does this sound normal?

[mwall]

On Wednesday, December 4, 2013 6:56:32 PM UTC-5, Scott Wyman wrote:

14.0 mph on the console is showing as 10.06 in the loop data
10.0 mph is showing as 7.38
6.9 mph is showing as 5.6
5.3 mph is showing as 4.02

Does this sound normal?

sounds like we might have a multiplier problem. 

if the loop data have usUnits=1 then the loop data windSpeed is in miles per hour.  if the loop data have usUnits=16 then the loop data windSpeed is in km/h.

i assumed that the station emits wind speed in meters/second, so the driver multiplies by 3.6 to put it in km/h, which is what weewx needs for the set of units defined by weewx.METRIC.  the m/s units is corroborated by wview - it has a multiplier of 2.23693929, which converts m/s to miles/hour, which is what wview uses internally.  except that how i see that the wview implementation first divides the raw value by 10...

i won't have a functioning anemometer until next week sometime, so your help on this is greatly appreciated.

m

[mwall]

On Wednesday, December 4, 2013 7:19:07 PM UTC-5, mwall wrote:

except that how i see that the wview implementation first divides the raw value by 10...

the divide by 10 is necessary.  the station records wind speed in decimeters per second, so divide by 10 to get meters per second.

in the ws23xx.py driver, division by 10 happens in the BcdConversion object.

so that is not the problem...

[Scott Wyman]

Will the wee_config_ws23xx utility show the raw values from the station?  If so, I can try to grab some values using that and compare them to what I see on the console.

[mwall]

On Wednesday, December 4, 2013 7:49:01 PM UTC-5, Scott Wyman wrote:

Will the wee_config_ws23xx utility show the raw values from the station?  If so, I can try to grab some values using that and compare them to what I see on the console.

do this to grab a single loop record:

cd /home/weewx
./bin/wee_config_ws23xx weewx.conf --current

do this to grab a raw wind reading:

cd /home/weewx
PYTHONPATH=bin python bin/weewx/drivers/ws23xx.py --reading=ws

either one understands the --help option so you can see what else is available.  the direct invocation of ws23xx.py avoids all of the weewx overhead (not that there is very much).

m

[Scott Wyman]

I used the config utility to grab some data for a few readings. Looks like when doing it this way, the loop data is showing windSpeed as a little bit higher than what is showing on my console:

5.5 mph on console shows as 6.84 in loop

6.7 shows as 8.64

8.7 shows as 9.72

I couldn't get the second one to work, I get the following:

ws23xx.py: error: --readings option does not take a value

I tried with just the --readings option and it seems to want to use a USB connection, but I'm using /dev/ttyS3

File "bin/weewx/drivers/ws23xx.py", line 734, in __init__

    raise FatalError(self.device, "can't open tty device - %s." % str(e))

__main__.FatalError: can't open tty device - [Errno 2] No such file or directory: '/dev/ttyUSB0'.

[mwall]

On Wednesday, December 4, 2013 8:32:50 PM UTC-5, Scott Wyman wrote:

I couldn't get the second one to work, I get the following:

ws23xx.py: error: --readings option does not take a value

I tried with just the --readings option and it seems to want to use a USB connection, but I'm using /dev/ttyS3

 
it defaults to /dev/ttyUSB0.  try this:

PYTHONPATH=bin python bin/weewx/drivers/ws23xx.py --port=/dev/ttyS3 --readings

or this for just the wind speed:

PYTHONPATH=bin python bin/weewx/drivers/ws23xx.py --port=/dev/ttyS3 --measure=ws

[Scott Wyman]

Ok, here are some readings I documented while invoking the driver directly grabbing the ws values. The first number is the mph reading that is showing on the console, and the second number is the ws value shown by the driver:

1.7 mph = 0.8

2.9 mph = 1.3

3.1 mph = 1.4

4.6 mph = 1.5

5.3 mph = 1.8

7.3 mph = 2.1

8.0 mph = 2.4

8.5 mph = 2.6

11.4 mph = 3.3

14.3 mph = 4.0

It seems up to 3.1 mph, the conversion to m/s is correct but above that, it seems to be off.  That is consistent with what I was seeing when watching the loop data run through the program last night where values above 4.0 mph or so didn't seem to match.

Do you think there might be something wrong with my station giving out bad readings?

[Scott Wyman]

Matthew,

Let me know if there is anything else I can do to help troubleshoot this.  Or do you need to wait until you get your wind sensor to test further?

-Scott

[mwall]

On Saturday, December 7, 2013 12:15:55 AM UTC-5, Scott Wyman wrote:

Let me know if there is anything else I can do to help troubleshoot this.  Or do you need to wait until you get your wind sensor to test further?

as of this morning i have a functioning anemometer.  i see discrepancies as well, but no pattern yet.

could you see if there are discrepancies or a pattern to the 'wind speed' versus the speed component of 'wind vector'?

wind speed only:

PYTHONPATH=bin python bin/weewx/drivers/ws23xx.py --measure=ws

wind speed and direction:

PYTHONPATH=bin python bin/weewx/drivers/ws23xx.py --measure=wv

wind direction only:

PYTHONPATH=bin python bin/weewx/drivers/ws23xx.py --measure=w0

[Scott Wyman]

Ok, will do. Winds are dead calm here today, hopefully they pick up a bit later tonight. 

--
You received this message because you are subscribed to a topic in the Google Groups "Weewx user's group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/Ha_VqoBaySQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[Scott Wyman]

Matthew,

I ran several more tests pulling the 'ws' and 'wv' values, and in all cases the 'ws' value matches the speed component of 'wv'. No discepencies there that I can see.

As far as the multiplier/conversion issue, with the winds being very light, I was able to pinpoint the exact point at which the calculation appears to go astray.  Here is what I have documented:

MPH on Console =  'ws' value from driver

1.3 = 0.6

1.7 = 0.8

3.1 = 1.4

3.3 = 1.5

3.5 = 1.0 <-- *******

3.8 = 1.1

4.2 = 1.3

4.6 = 1.5

5.3 = 1.8

7.3 = 2.1

So it appears at 3.5 mph and above is when the calculation appears to be off.  I'm assuming the 'ws' value is supposed to be m/s. If I'm way off base here and not looking at this correctly, let me know.

Thanks,

-Scott

[Nigel Head]

@ mwall

Hi,

I got 5 minutes to install weewx on an old re-purposed thin client with a 'real' COMM port.

Installed weewx deb and added the latest ws23xx.py driver.

My congig file has this added...

[Station]

station_type = WS23xx

and...

[WS23xx]

port = /dev/ttyS0

driver = weewx.drivers.ws23xx

polling_interval = 8

Here is the output from syslog...

Dec 8 22:40:44 debian5740 weewx[1091]: wxengine: Initializing weewx version 2.5.0

Dec 8 22:40:44 debian5740 weewx[1091]: wxengine: Using Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) #012[GCC 4.4.5]

Dec 8 22:40:44 debian5740 weewx[1091]: wxengine: pid file is /var/run/weewx.pid

Dec 8 22:40:44 debian5740 weewx[1314]: wxengine: Using configuration file /etc/weewx/weewx.conf

Dec 8 22:40:44 debian5740 weewx[1314]: wxengine: Loading station type WS23xx (weewx.drivers.ws23xx)

Dec 8 22:40:44 debian5740 weewx[1314]: ws23xx: driver version is 0.11

Dec 8 22:40:44 debian5740 weewx[1314]: ws23xx: serial port is /dev/ttyS0

Dec 8 22:40:44 debian5740 weewx[1314]: ws23xx: pressure offset is None

Dec 8 22:40:44 debian5740 weewx[1314]: ws23xx: polling interval is 8

Dec 8 22:40:44 debian5740 weewx[1314]: ws23xx: windchill will be read from station

Dec 8 22:40:44 debian5740 weewx[1314]: ws23xx: dewpoint will be read from station

Dec 8 22:40:44 debian5740 weewx[1314]: ws23xx: forcing record_generation to 'software'

Dec 8 22:40:44 debian5740 weewx[1314]: wxengine: StdConvert target unit is 0x1

Dec 8 22:40:45 debian5740 weewx[1314]: wxengine: The archive interval in the configuration file (300) does not match the station hardware interval (3540).

Dec 8 22:40:46 debian5740 weewx[1314]: wxengine: Using station hardware archive interval of 3540

Dec 8 22:40:46 debian5740 weewx[1314]: wxengine: Record generation will be attempted in 'software'

Dec 8 22:40:46 debian5740 weewx[1314]: wxengine: Using archive database: archive_sqlite

Dec 8 22:40:46 debian5740 weewx[1314]: stats: stats database up to date.

Dec 8 22:40:46 debian5740 weewx[1314]: wxengine: Using stats database: stats_sqlite

Dec 8 22:40:46 debian5740 weewx[1314]: wxengine: Starting up weewx version 2.5.0

Dec 8 22:40:46 debian5740 weewx[1314]: wxengine: Starting main packet loop.

Dec 8 22:40:51 debian5740 weewx[1314]: ws23xx: connection changed from unknown to cable

It's late and I'm tired (several 12+ hour days working on my bathroom!). but it seems there is no sensible updated data being displayed on the web page.

It is available to view here...

www.nthead.co.uk/weewx

Also, the wind values appear negative?!

wview was running just fine on the exact same hardware, it's last update is here (30 minutes before I stopped it and installed weewx)

www.nthead.co.uk/weather

Regds,

Nigel.

[Andrew Milner]

It is doing something - but extremely slowly!!  I noticed that the time of the webpage changed from 01:58 to 01:59 in half an hour - and was actually about 1 hr 10 minutes at least behind the current time.  Between the two 'looks' the graphs had acquired some data ... so I suspect you have a log full of errors of some kind that is taking up a lot of time!!

[mwall]

hi nigel,

is all of that work in the bathroom demolition, or have you started the construction already?  are you laying a lot of tile?

there are a few things happening here...

weewx is using an archive interval of 59 minutes (3540 seconds) that it got from the station - if you just let it run you should see updates to the web page every 59 minutes. 

fwiw, wview ignores the station's archive interval and uses whatever you specify in the wview configuration.  also, wview does not do 'catchup' when it starts up.

the ws23xx driver exposes a bug in weewx 2.5.0 in which weewx uses the station's archive interval even when software record generation is specified (the ws23xx driver defaults to overriding the record generation to be 'software').  this bug has been fixed in the trunk.

there are two ways to deal with this:

1) download the latest bin/weewx/wxengine.py and bin/weewx/abstractstation.py, then restart weewx

OR

2) change the archive interval on your station. for example, set a 5 minute interval like this (beware that changing the archive interval will clear the station memory):

wee_config_ws23xx --set-interval=5 --port=/dev/ttyS0

the negative values for wind speed is new to me.  does your station have the cups or the impeller?

i have committed ws23xx.py driver version 0.12 (r1776).  this adds checks for wind speed overflow and validity.  when the anemometer is disconnected it should detect this and use None for windSpeed and windDir.

m

[mwall]

scott and nigel,

there is a discrepancy between the wview/open2300 implementations and the ws2300.py implementation in the manner of reading wind speed and direction.  it looks like wview copied from open2300.  ws2300 uses a different approach.  i'm trying to sort it out...

m

[Nigel Head]

The bathroom is a total re-work, as in back to 4 bare walls, then new plumbing, sewer/waste pipes, wiring, shower enclosure, ventilation, flooring, ceiling, new plastering, tiling, install a suntube because we removed the window etc etc...

This is nearly the end of a year long complete re-vamp of our entire property we bought, which we downsized to ready for our retirement... except the government wants to raise the age we can retire (b*******)

Anyways, back to the WS2300.

I haven't had any spare time today and I'm off to bed in a moment, but the webpage is showing very little.

I await your update and there is no rush on my side ;)

I for one really appreciate the effort you all put in and for no real personal gain.

No errors in syslog, just typically this every 59 minutes or so...

Dec 9 21:38:17 debian5740 weewx[1314]: Archive: added archive record 2013-12-09 20:59:00 GMT (1386622740)

Dec 9 21:38:17 debian5740 weewx[1314]: cheetahgenerator: generated 1 'SummaryByMonth' files for StandardReport in 0.11 seconds

Dec 9 21:38:18 debian5740 weewx[1314]: cheetahgenerator: generated 1 'SummaryByYear' files for StandardReport in 0.45 seconds

Dec 9 21:38:18 debian5740 weewx[1314]: cheetahgenerator: generated 12 'ToDate' files for StandardReport in 0.52 seconds

Dec 9 21:38:21 debian5740 weewx[1314]: genimages: Generated 33 images for StandardReport in 3.20 seconds

Cheers,

Nigel.

--

[mwall]

nigel and scott,

the wind speed is fixed as of driver version 0.14 (r1781 in the trunk).  the ws2300 implementation was decoding using base 10 instead of base 16.

m

[Scott Wyman]

Hi Matthew,

Looks pretty good so far, the speed component of 'wv' appears to be correct when invoking the driver directly.  However the 'ws' values appear to still be off.  Although I am running a full test through weewx and the loop values appear to show the correct mph for windSpeed, so perhaps the 'ws' values are not being used.

I'm going to let it run for a while and see how it goes.

Thanks!

-Scott

[mwall]

On Tuesday, December 10, 2013 2:03:31 AM UTC-5, Scott Wyman wrote:

Looks pretty good so far, the speed component of 'wv' appears to be correct when invoking the driver directly.  However the 'ws' values appear to still be off.  Although I am running a full test through weewx and the loop values appear to show the correct mph for windSpeed, so perhaps the 'ws' values are not being used.

i added a new conversion object (and measure option) for 'wind' that gets speed, direction, and validity all in one invocation.  this avoids the problems that can arise where you ask for the wind speed in one call then ask for the validity in a second call.

loop uses the new 'wind' invocation.  'ws' was still doing a decimal conversion instead of hex.  fixed in driver version 0.15 (r1782)

m

[Scott Wyman]

Ok, I will give version 0.15 a run. 

Been running 0.14 for about 12 hours, all appears good so far. 

--

[Scott Wyman]

Version 0.15 running for about 15 or so hours, all looks good.

[Nigel Head]

OK, my phone company managed to disconnect my line and Internet access for the last 2 days!

I downloaded the latest driver at work and installed it yesterday.

Seems to work fine but updates are still hourly...

www.nthead.co.uk/weewx

How do I make this update at, ideally 8 second intervals or even every minute?

Thanks again Matthew.

Nigel.

On 12 December 2013 00:59, Scott Wyman <sc...@horkboy.com> wrote:

Version 0.15 running for about 15 or so hours, all looks good.

[mwall]

On Thursday, December 12, 2013 3:01:04 PM UTC-5, Devonian wrote:

OK, my phone company managed to disconnect my line and Internet access for the last 2 days!

I downloaded the latest driver at work and installed it yesterday.

Seems to work fine but updates are still hourly...

www.nthead.co.uk/weewx

How do I make this update at, ideally 8 second intervals or even every minute?

nigel,

to get an archive record every minute,

1) set the station archive interval to 1 minute:

wee_config_ws23xx --set-interval=1

2) set record_generation to software and tell weewx to create an archive each minute:

[StdArchive]
    archive_interval = 60
    record_generation = software

3) restart weewx

sudo /etc/init.d/weewx stop
sudo /etc/init.d/weewx start

fwiw, all of this will be easier in 2.5.1 and 2.6...

m

[Devonian]

Is the line  wee_config_ws23xx --set-interval=1 used from a command prompt?

I run it and get the error

sudo: wee_config_ws23xx: command not found

Edited the weewx.conf OK.

Nigel.

[mwall]

On Thursday, December 12, 2013 5:00:10 PM UTC-5, Devonian wrote:

Is the line  wee_config_ws23xx --set-interval=1 used from a command prompt?

I run it and get the error

sudo: wee_config_ws23xx: command not found

if you installed from rpm or deb package, then this is the command:

sudo wee_config_ws23xx --set-interval=1

if you installed to /home/weewx using setup.py, then this is the command:

sudo /home/weewx/bin/wee_config_ws23xx --set-interval=1

[Nigel Head]

I know I'm tired, but it's not panning out for me..

Screenprint from my command line output (tested on wee_config_ws28xx and the file wee_config_ws23xx is in the directory list?!)

root@debian5740:/usr/share/weewx# wee_config_ws28xx
Using configuration file /etc/weewx/weewx.conf
Using ws28xx driver 0.23
Traceback (most recent call last):
  File "/usr/bin/wee_config_ws28xx", line 241, in <module>
    main()
  File "/usr/bin/wee_config_ws28xx", line 76, in main
    **config_dict['WS28xx'])
  File "/usr/share/weewx/weewx/drivers/ws28xx.py", line 1097, in __init__
    self.startUp()
  File "/usr/share/weewx/weewx/drivers/ws28xx.py", line 1157, in startUp
    comm_interval=self.comm_interval)
  File "/usr/share/weewx/weewx/drivers/ws28xx.py", line 3682, in setup
    self.shid.open(vendor_id, product_id, device_id)
  File "/usr/share/weewx/weewx/drivers/ws28xx.py", line 2859, in open
    raise weewx.WeeWxIOError('Unable to find USB device')
weewx.WeeWxIOError: Unable to find USB device
root@debian5740:/usr/share/weewx#
root@debian5740:/usr/share/weewx#
root@debian5740:/usr/share/weewx# wee_config_ws23xx
-bash: wee_config_ws23xx: command not found
root@debian5740:/usr/share/weewx#

My install seems to be in /usr/share/weewx and /etc/weewx

Nigel.

[mwall]

On Thursday, December 12, 2013 6:25:07 PM UTC-5, Devonian wrote:

I know I'm tired, but it's not panning out for me..

sorry, my mistake.  like the ws23xx.py driver, the wee_config_ws23xx utility is not in the weewx 2.5.0 install - you must download it:

https://sourceforge.net/p/weewx/code/HEAD/tree/trunk/bin/wee_config_ws23xx

put wee_config_ws23xx into the same directory as wee_config_ws28xx and wee_config_vantage, in your case /usr/share/weewx

m

[Nigel Head]

I had figured that out yesterday and downloaded the wee_config_ws23xx file and placed it in the same directory as all the others (as you suggested in your post above).

It simply does not run or is not recognised as a command.

I had also rebooted the machine, but still no go.

What now?

Cheers,

Nigel.

--

[Andrew Milner]

More than likely it is permissions.  Is it an executable and are you in the same directory when you give the command?  If the directory is not on the path you may need to use sudo ./wee_config_ws23xx

[Nigel Head]

using the ./ before the command worked.

It warned that changing the interval will clear the station memory and allows a y/n decision before completing the command.

I should now have a 1 minute update interval

Nigel.

[Tom Winkler]

Hi Matthew,

first, merry christmas
second, don't answer today ;)

I got ws_config_ws23XX running. Most of the commands giving back results, like --info, --set-interval, --curent, --clear-memory. No result with history=1 or history-since=2
If I start with

./bin/weewxd weewx.conf

after some minutes I get a trackback back

root@raspberrypi:/home/weewx# ./bin/weewxd weewx.conf

Traceback (most recent call last):

  File "./bin/weewxd", line 68, in <module> weewx.wxengine.main(options, args)
  File "/home/weewx/bin/weewx/wxengine.py", line 889, in main engine.run()
  File "/home/weewx/bin/weewx/wxengine.py", line 142, in run self.dispatchEvent(weewx.Event(weewx.STARTUP))
  File "/home/weewx/bin/weewx/wxengine.py", line 192, in dispatchEvent callback(event)
  File "/home/weewx/bin/weewx/wxengine.py", line 447, in startup self._catchup()
  File "/home/weewx/bin/weewx/wxengine.py", line 563, in _catchup for record in self.engine.console.genArchiveRecords(lastgood_ts):
  File "/home/weewx/bin/weewx/drivers/ws23xx.py", line 487, in genArchiveRecords calc_windchill=True)
  File "/home/weewx/bin/weewx/drivers/ws23xx.py", line 558, in data_to_packet ws,wd,wso,wsv = data['wind']
ValueError: need more than 3 values to unpack

Maybe it's important, that I only have the base station ws2300 connected?
No outdoor sensors are connected actually, cause I have the base station at home for setting up with the Raspberry Pi. The sensors are installed at our flying field, 10km away ;)

Regards
Tom

[mwall]

On Wednesday, December 25, 2013 12:56:01 PM UTC-5, Tom Winkler wrote:

Maybe it's important, that I only have the base station ws2300 connected?
No outdoor sensors are connected actually, cause I have the base station at home for setting up with the Raspberry Pi. The sensors are installed at our flying field, 10km away ;)

hi tom,

try driver 0.17 at r1810.  be sure to grab wee_config_ws23xx as well as the driver ws23xx.py.

m

[Tom Winkler]

Thx M ;)

everything 's running now.
Perfect, great job. Many thanks!!!

[Devonian]

Well, after someone hacked my online Linux box with weewx on it, I decided it was too risky to leave it running and brought it down and will completely format it, re-install Linux and then weewx.

All my own fault for opening the SSH port on my router and running as root with a not too difficult password.

Question:  When will weewx 2.6 be released?

If it is soon, I will wait as everything will be inside the one package.

Nigel.

[Thomas Keffer]

Hi, Nigel

Probably around late January?

-tk

--
You received this message because you are subscribed to the Google Groups "Weewx user's group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[Devonian]

Hi Tom,

OK, many thanks.

Maybe I'll wait as I have a(nother) low(er) power ex thin client on it's way to play with (9W at full throttle ;) ).

Just depends if I can hack a SATA SSD on to it...

Nigel.

[James Jones]

I am not sure whether anyone can help. I have a WS2300 -11 which is working fine however I cannot get it to down load data to my computer Dell optiplex 780 which has a serial port. Windows 7 professional is the operating system on the computer. It has worked previously. I think it is something to do with the com ports (1 to 4 on the WS2300 but I cannot find any of these ports on my computer.
Can anyone hep ?

Regards
Stuart

On Wednesday, June 12, 2013 6:41:30 PM UTC+1, Devonian wrote:

I seem to remember that others have asked if the Lacrosse WS23xx weather station is supported in Weewx (I know it's currently not).

However, I just came across this python driver here...

http://www.lavrsen.dk/foswiki/bin/view/Open2300/Ws2300Python

Leading me to here...

http://ace-host.stuart.id.au/russell/files/ws2300/

http://ace-host.stuart.id.au/russell/files/ws2300/ws2300.1.html

 

I have a ws2300 and am no programmer by any stretch of the imagination, but could this driver be incorporated/made to work with Weewx without too much trouble?

 

I have used Open2300 and it worked OK on Debian, putting data into a MySQL database, although the install/setup was not 'simple'.

 

I'd love to be able to run Weewx on a Raspberry-Pi with my WS2300 as I've just done the wireless mod to 'trick' the sender to transmit data every 8 seconds (same as if it were cabled).

 

What are the chances?

Anyone willing to help?

 

Regards,

 

Nigel.

 

 

 

 

[Devonian]

Stuart,

I believe your PC has a 'genuine' serial port - this is probably COM 1 ?

What is listed in the Control Panel -> Device Manager -> Ports (COM & LPT) ??

The COM port should be listed here and without it, nothing is going to work.

HTH

Nigel.

[Devonian]

I have defined polling_interval = 8 in my weewx.conf file, but get this, where it defaults back to 60 seconds:

Feb 24 22:24:55 ubuntu weewx[2974]: wxengine: Record generation will be attempted in 'software'
Feb 24 22:24:55 ubuntu weewx[2974]: wxengine: The archive interval in the configuration file (8) does not match the station hardware interval (60).
Feb 24 22:24:56 ubuntu weewx[2974]: wxengine: Using archive interval of 60 seconds
Feb 24 22:24:56 ubuntu weewx[2974]: wxengine: Using archive database: archive_MySQL

I have set wee_config_ws23xx --set-interval=1
as that is the lowest I understand it can be set to (1 minute)

How can I set it to 8 seconds?

Otherwise, it works fine ;)

Nigel.
 

[meteo....@free.fr]

Dear all,
I had since 2007 a Lacrosse WS2350 station and until now all data was managing with the original SW (heavy weather) and Graphweather. all of them are installing on a 'server' PC. since the beginning, this one is only powered between 22h20 and 23h59 (for consumption reason).
The station store the weather data every 15min and each 30s the current weather is only send on my main web page (meteo.eybens.free.fr) when the PC is ON. The graphweather SW is used to generate all the graphs and also the statics pages.
Since a week ago I have installed weewx (py) on a rasberry as explain on the weewx web site. The station is configurated in Metric
I noticed since I use weewx, a lot a spikes are generated on the graphs (see meteo.eybens.free.fr/weather). The spikes are randomly.
As I am a electronic engineer, I try to find the issue but my SW experience is low. I add some log line in the driver WS23xx (called now WS2350) to show the data come from the serial line. What I noticed :
- some time the data come from serial port are not the right ones. example come from the personal logs with  consecutive data (It seems that the outside temp data is shifting of one byte) :

Nov 23 21:23:32 (none) weewx[2423]: ws23xx: create Ws2300
Nov 23 21:23:53 (none) weewx[2423]: ws23xx: Data raw : [(0, 0, 5, 5), (2, 5), (0, 0, 2, 0), (7, 8), (9, 4, 8, 9, 0), (0, 0, 0, 0, 0, 5, 5, 5, 5, 5, 5, 0), (0, 0, 0, 0, 0, 0), (1, 9, 4, 4, 6, 0), (9, 0, 8, 3), (0, 2, 0, 4), (15,)]
Nov 23 21:23:53 (none) weewx[2423]: ws23xx: Data dict : {'rt': 644.91, 'wc': 10.2, 'cn': 15, 'oh': 87.0, 'it': 25.0, 'ih': 52.0, 'pa': 984.9, 'dp': 8.09, 'ot': -28.0, 'rh': 0.0, 'wind': (0.0, 112.5, 0, 0)}
Nov 23 21:23:53 (none) weewx[2423]: ws23xx: Data station : {'rt': 644.91, 'wc': 10.2, 'cn': 15, 'oh': 87.0, 'it': 25.0, 'ih': 52.0, 'pa': 984.9, 'dp': 8.09, 'ot': -28.0, 'rh': 0.0, 'wind': (0.0, 112.5, 0, 0)}
Nov 23 21:23:53 (none) weewx[2423]: ws23xx: Data packet : {'barometer': 1020.5388046802619, 'windchill': 10.2, 'dewpoint': 8.09, 'pressure': 984.9, 'outHumidity': 87.0, 'altimeter': 1014.9135383866834, 'heatindex': -28.0, 'rain': 0.0, 'dateTime': 1416774233, 'windDir': None, 'outTemp': -28.0, 'windSpeed': 0.0, 'inHumidity': 52.0, 'inTemp': 25.0, 'windGust': None, 'rainTotal': 64.491, 'rainRate': 0.0, 'usUnits': 16, 'windGustDir': None}
Nov 23 21:23:53 (none) weewx[2423]: wxengine: ignoring rain value of 0.0, limits are (0.1, 10.0)
Nov 23 21:24:23 (none) weewx[2423]: ws23xx: close LinuxSerialPort
Nov 23 21:24:23 (none) weewx[2423]: ws23xx: create LinuxSerialPort
Nov 23 21:24:23 (none) weewx[2423]: ws23xx: create Ws2300
Nov 23 21:24:37 (none) weewx[2423]: ws23xx: Data raw : [(0, 0, 5, 5), (2, 5), (0, 2, 0, 4), (7, 8), (9, 4, 8, 9, 0), (0, 0, 0, 0, 0, 5, 5, 5, 5, 5, 5, 0), (0, 0, 0, 0, 0, 0), (1, 9, 4, 4, 6, 0), (9, 0, 8, 3), (0, 2, 0, 4), (15,)]
Nov 23 21:24:37 (none) weewx[2423]: ws23xx: Data dict : {'rt': 644.91, 'wc': 10.2, 'cn': 15, 'oh': 87.0, 'it': 25.0, 'ih': 52.0, 'pa': 984.9, 'dp': 8.09, 'ot': 10.2, 'rh': 0.0, 'wind': (0.0, 112.5, 0, 0)}
Nov 23 21:24:37 (none) weewx[2423]: ws23xx: Data station : {'rt': 644.91, 'wc': 10.2, 'cn': 15, 'oh': 87.0, 'it': 25.0, 'ih': 52.0, 'pa': 984.9, 'dp': 8.09, 'ot': 10.2, 'rh': 0.0, 'wind': (0.0, 112.5, 0, 0)}
Nov 23 21:24:37 (none) weewx[2423]: ws23xx: Data packet : {'barometer': 1015.6599383487659, 'windchill': 10.2, 'dewpoint': 8.09, 'pressure': 984.9, 'outHumidity': 87.0, 'altimeter': 1014.9135383866834, 'heatindex': 10.2, 'rain': 0.0, 'dateTime': 1416774278, 'windDir': None, 'outTemp': 10.2, 'windSpeed': 0.0, 'inHumidity': 52.0, 'inTemp': 25.0, 'windGust': None, 'rainTotal': 64.491, 'rainRate': 0.0, 'usUnits': 16, 'windGustDir': None}
Nov 23 21:24:37 (none) weewx[2423]: wxengine: ignoring rain value of 0.0, limits are (0.1, 10.0)
Nov 23 21:25:07 (none) weewx[2423]: ws23xx: close LinuxSerialPort


- and some time the results of calculation are not the right one. In the weewx.sdb the data are Ok but in the graphs there spikes. I don't have any log. And when I take the station value and to the calculation using the weewx formulas by hand or excel the result are ok.

In parallel, I check with the graphweather SW the same period and there are no spikes.

How can we solve these issues ?
If it necessary, I can do test or anything else to help. I just can do the test after 22h00 FR time.
regards
Lio

[mwall]

lio,

there are a few possibilities here:

1) archive (aggregated) vs loop (live) data.  heavyweather reads only archive records, and since archive records are an aggregation of loop data, spikes will be filtered by the aggregation algorithm in the station firmware.  by default, weewx will use loop data for the stats (record_generation=software).

2) filtering.  it is possible that heavyweather does explicit filtering of bad values.  you can use StdQC in weewx to filter values that are obviously out of range.

3) reading data from the station.  it is possible that the station never sends 'bad' data, but that weewx sees 'bad' data only because the ws23xx driver is reading incorrectly.  for example, if the driver reads from station memory while the firmware is updating that memory there could be problems.  the byte shift you see might be an indicator of this.  apparently wview had this problem as well, and the implementation there is to query the station 3 times then only accept the read if the values are close to each other.

what should you do?

a) set StdQC to prevent obviously bad values from getting into the database
b) try setting loop_hilo=False in [StdArchive].  this will prevent any anomalous values in loop data from getting into the stats.
c) see if there is a pattern to the anomalous data.  does it happen every day?  a few times a week?
d) instrument the driver code to record byte shifts.  see if there is a pattern.
e) figure out if there is a better way to implement Ws2300.read_batch

m

[meteo....@free.fr]

m,
Ok,
a) I changed yesterday(Wednesday evening) the record_generation to software. It seems to be better. but not 100%
Since  the beginning I had range for the external. I had noticed that for humidity, rain and wind, weewx doesn't like the value close to 0 or egal to 0. The most impacted by that it's the rain; weewx is able to calculate some rain <1mm if the value is 0.0. need to be understand why?
[[MinMax]]
        barometer = 900, 1100, hPa
        outTemp = -30, 50, degree_C
        inTemp = -5, 50, degree_C
        outHumidity = 5, 100
        inHumidity = 5, 100
        rain = 1, 100, mm
        windSpeed = 1, 100, km_per_hour

b) I set yesterday(Wednesday evening) the loop_hilo to False. It seems to be better. but not 100%

c)d) The spikes are fully randomly in term of hours/days/values and also the data.

e) Implemented a better batch it's a good idea but I don't have any experience in SW to do that. I tried to loggout the data come from TTYUSB0 in the driver but it doesn't work; I had python errors.I will try to find a TTY sniffer to record data and compare them with the data raw that I get.

For more information :
Today there had 2 spikes. The must import is this one (data come from weewx.sdb) :
date time   usunits   interval   baro   press   altim   ITemp  OT  IHumi  OH  WindS   WD    WG   WGD    RainR   Rain   DP   WindCh    HeatI
"1417077000"    "16"    "15"    "1001.5582669982"    "971.394444444444"    "1001.07182890586"    "23.0111111111111"    "7.27647058823529"    "49.0"    "94.0"    ""    ""    ""    ""    "0.0"    ""    "6.35777777777778"    "7.27777777777778"    "26.8255713462631"

The heat index is @ 26.82° while the out temp is at 7.27°c and the out humidity @94.0. From different web weather below around 26.7°c or 40%, the heatindex is similar to the out temp. I added a condition in the calcul heatindexC(T_C, R) to return the out temp for data below 26.7°c or 40%. It doesn't do the conversion C<-->F) and then calculation, if not necessary. I will see check the result in the next hours/days.

I also see :
date time   usunits   interval   baro   press   altim   ITemp  OT  IHumi  OH  WindS   WD    WG   WGD    RainR   Rain   DP   WindCh    HeatI
"1416893400"    "16"    "15"    "1013.42188970812"    "982.427777777778"    "1012.37984899088"    "20.6"    "7.96470588235294"    "52.0"    "91.0"    "0.0"    ""    "0.0"    ""    "0.0"    ""    "11.5866666666667"    "7.96666666666667"    "5.74444444444445"
Here the dewpoint 11.5866 is above the out temperature 7.96 avec 91% of out humidity.... normally we the Dp should be 6.62.....

see for next result.........
Lio

[meteo....@free.fr]

Hi m,
I have spend a couple of hours to log the data come from the serial port :
response = self.read_data(address + start_pos, bytes) in WS23xx.py (from my side I call it WS2350.py)

I didn't find the solution. Could you tell me how to do it ?
I also notice there is a Debug_Serial to log the data in a buffer, how to save this log in a file to analyse the data ?

I had updated the heatindex and dewpoint formulas. This solve almost all the spikes.
rds

[mwall]

On Sunday, November 30, 2014 11:53:50 AM UTC-5, meteo....@free.fr wrote:

Hi m,
I have spend a couple of hours to log the data come from the serial port :
response = self.read_data(address + start_pos, bytes) in WS23xx.py (from my side I call it WS2350.py)

I didn't find the solution. Could you tell me how to do it ?
I also notice there is a Debug_Serial to log the data in a buffer, how to save this log in a file to analyse the data ?

if you set DEBUG_SERIAL=True then Ws2300 class will capture the data from serial communications.  to display the capture you must print the captured data.

for example, this construct would capture data from getting inside temperature and humidity, then print it out after the serial connection is complete:

with WS23xx(port) as s:
    data = s.get_raw_data(['it','ih'])
    print data
    if s.ws.log_buffer:
        for line in s.ws.log_buffer:
            print line

sorry about all the layers in the code.  WS23xxDriver is the weewx driver, WS23xx is a wrapper around Ws2300, Ws2300 is the station abstraction.  it was written this way to minimize modifications to the original ws2300 code (by russell stuart).

m

[lionel...@free.fr]

Hello m,
I finally find how to have all the data come from the serial port (result = self.serial_port.read_byte(timeout) in the def read_byte(self, timeout=1.0) of class Ws2300. I did it yesterday night.
Since I did that, the graphs don't show any more spikes (now it's almost 17h00 of working). I will check the logs this evening and let running for a couple of days. If it will be confirmed, It will be necessary to add a sleep time during the reading byte. At each step of taking data and convert data, I added a syslog.syslog command and this is adding timing in the SW.

On an other way, I am writing a python script to convert the data come from Heawyweather to weewx CSV format. The gaol is to integrate my 6 years old of data.
Is weewx able to generate graphs for each days for each month of each year and keep them on the web sevrer ?
It's what I have actually, something similar to this :
http://meteo.eybens.free.fr/meteostatistique/MyGWStats.php

Rds
lio

[mwall]

On Thursday, December 4, 2014 11:12:06 AM UTC-5, lionel...@free.fr wrote:

Hello m,
I finally find how to have all the data come from the serial port (result = self.serial_port.read_byte(timeout) in the def read_byte(self, timeout=1.0) of class Ws2300. I did it yesterday night.
Since I did that, the graphs don't show any more spikes (now it's almost 17h00 of working). I will check the logs this evening and let running for a couple of days. If it will be confirmed, It will be necessary to add a sleep time during the reading byte. At each step of taking data and convert data, I added a syslog.syslog command and this is adding timing in the SW.

please let us know whether this works.


 

On an other way, I am writing a python script to convert the data come from Heawyweather to weewx CSV format. The gaol is to integrate my 6 years old of data.
Is weewx able to generate graphs for each days for each month of each year and keep them on the web sevrer ?

just import the data into the table called 'archive' in weewx.sdb (for sqlite)

m

[Andrew Milner]

Sounds to me as though your serial port is not handshaking correctly through sw or hw (CTS/RTS or whatever) and what you have possibly effectively done is just slow everything down such that waiting for the handshake is not necessary.

[meteo....@free.fr]

Hello,
After several of working, I confirm that all traces I have added in the WS23xx.py, resolve the spikes.
I also identify in with part is come from the issue :
it's in
class Ws2300(object):
==> class Ws2300Exception(StandardError):
=====>    def read_byte(self, timeout=1.0):
        if self.log_mode != 'r':
            self.log_mode = 'r'
            self.log(':')
        result = self.serial_port.read_byte(timeout)
        if result == None:
            self.log("--")
            #toto = "Read_byte result : --" # LSA
        else:
            self.log("%02x" % ord(result))
            #toto = "Read_byte result : %02x" % ord(result) # LSA
        #syslog.syslog(toto) # LSA
        return result

When I comment the LSA lines, this is generate bad reading randomly. else none.
See an error exemple below.In red, here the Outtemp ('ot') is at 60.9°C. The date read is data (0, 9, 0, 9) while the previous and the following was data (0, 9, 4, 3) for Outtemp of 4.9°C. The values of the data are (hundredth,tenth,unit, decade + 3).
Remark, I always noticed the issue is come from the reading the outtemp. none of the other one.....

"""
Dec  6 11:29:17 (none) weewx[2427]: response None
Dec  6 11:29:19 (none) weewx[2427]: response None
Dec  6 11:29:19 (none) weewx[2427]: response None
Dec  6 11:29:20 (none) weewx[2427]: response None
Dec  6 11:29:21 (none) weewx[2427]: Read_data answer : 30
Dec  6 11:29:21 (none) weewx[2427]: Read_data answer : 53
Dec  6 11:29:21 (none) weewx[2427]: response (0, 3, 3, 5)
Dec  6 11:29:21 (none) weewx[2427]: data (0, 3, 3, 5)
Dec  6 11:29:21 (none) weewx[2427]: result [(0, 3, 3, 5)]
Dec  6 11:29:22 (none) weewx[2427]: response None
Dec  6 11:29:23 (none) weewx[2427]: response None
Dec  6 11:29:24 (none) weewx[2427]: response None
Dec  6 11:29:24 (none) weewx[2427]: response None
Dec  6 11:29:24 (none) weewx[2427]: Read_data answer : 90
Dec  6 11:29:24 (none) weewx[2427]: Read_data answer : 90
Dec  6 11:29:24 (none) weewx[2427]: response (0, 9, 0, 9)
Dec  6 11:29:24 (none) weewx[2427]: data (0, 9, 0, 9)
Dec  6 11:29:24 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9)]
Dec  6 11:29:24 (none) weewx[2427]: Read_data answer : 90
Dec  6 11:29:24 (none) weewx[2427]: Read_data answer : 34
Dec  6 11:29:24 (none) weewx[2427]: response (0, 9, 4, 3)
Dec  6 11:29:24 (none) weewx[2427]: data (0, 9, 4, 3)
Dec  6 11:29:24 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3)]
Dec  6 11:29:25 (none) weewx[2427]: Read_data answer : 72
Dec  6 11:29:25 (none) weewx[2427]: Read_data answer : 32
Dec  6 11:29:25 (none) weewx[2427]: response (2, 7, 2, 3)
Dec  6 11:29:25 (none) weewx[2427]: data (2, 7, 2, 3)
Dec  6 11:29:25 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3)]
Dec  6 11:29:26 (none) weewx[2427]: response None
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 40
Dec  6 11:29:26 (none) weewx[2427]: response (0, 4)
Dec  6 11:29:26 (none) weewx[2427]: data (0, 4)
Dec  6 11:29:26 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4)]
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 86
Dec  6 11:29:26 (none) weewx[2427]: response (6, 8)
Dec  6 11:29:26 (none) weewx[2427]: data (6, 8)
Dec  6 11:29:26 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4), (6, 8)]
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 00
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 00
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 00
Dec  6 11:29:26 (none) weewx[2427]: response (0, 0, 0, 0, 0, 0)
Dec  6 11:29:26 (none) weewx[2427]: data (0, 0, 0, 0, 0, 0)
Dec  6 11:29:26 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4), (6, 8), (0, 0, 0, 0, 0, 0)]
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 37
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 58
Dec  6 11:29:26 (none) weewx[2427]: Read_data answer : 06
Dec  6 11:29:26 (none) weewx[2427]: response (7, 3, 8, 5, 6, 0)
Dec  6 11:29:26 (none) weewx[2427]: data (7, 3, 8, 5, 6, 0)
Dec  6 11:29:26 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4), (6, 8), (0, 0, 0, 0, 0, 0), (7, 3, 8, 5, 6, 0)]
Dec  6 11:29:27 (none) weewx[2427]: Read_data answer : 00
Dec  6 11:29:27 (none) weewx[2427]: Read_data answer : 0c
Dec  6 11:29:27 (none) weewx[2427]: Read_data answer : 10
Dec  6 11:29:27 (none) weewx[2427]: Read_data answer : e1
Dec  6 11:29:27 (none) weewx[2427]: Read_data answer : d4
Dec  6 11:29:27 (none) weewx[2427]: Read_data answer : 02
Dec  6 11:29:27 (none) weewx[2427]: response (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0)
Dec  6 11:29:27 (none) weewx[2427]: data (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0)
Dec  6 11:29:27 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4), (6, 8), (0, 0, 0, 0, 0, 0), (7, 3, 8, 5, 6, 0), (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0)]
Dec  6 11:29:28 (none) weewx[2427]: response None
Dec  6 11:29:28 (none) weewx[2427]: Read_data answer : 0f
Dec  6 11:29:28 (none) weewx[2427]: response (15,)
Dec  6 11:29:28 (none) weewx[2427]: data (15,)
Dec  6 11:29:28 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4), (6, 8), (0, 0, 0, 0, 0, 0), (7, 3, 8, 5, 6, 0), (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0), (15,)]
Dec  6 11:29:28 (none) weewx[2427]: Read_data answer : 09
Dec  6 11:29:28 (none) weewx[2427]: Read_data answer : 98
Dec  6 11:29:28 (none) weewx[2427]: Read_data answer : 60
Dec  6 11:29:28 (none) weewx[2427]: response (9, 0, 8, 9, 0)
Dec  6 11:29:28 (none) weewx[2427]: data (9, 0, 8, 9, 0)
Dec  6 11:29:28 (none) weewx[2427]: result [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4), (6, 8), (0, 0, 0, 0, 0, 0), (7, 3, 8, 5, 6, 0), (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0), (15,), (9, 0, 8, 9, 0)]
Dec  6 11:29:28 (none) weewx[2427]: ws23xx: Data nybbles : [(0, 3, 3, 5), (0, 9, 0, 9), (0, 9, 4, 3), (2, 7, 2, 3), (0, 4), (6, 8), (0, 0, 0, 0, 0, 0), (7, 3, 8, 5, 6, 0), (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0), (15,), (9, 0, 8, 9, 0)]
Dec  6 11:29:28 (none) weewx[2427]: ws23xx: Data raw : [(0, 3, 3, 5), (0, 4), (0, 9, 0, 9), (6, 8), (9, 0, 8, 9, 0), (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0), (0, 0, 0, 0, 0, 0), (7, 3, 8, 5, 6, 0), (2, 7, 2, 3), (0, 9, 4, 3), (15,)]
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (0, 3, 3, 5) ---- GRData bin2val : 23.3
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (0, 4) ---- GRData bin2val : 40.0
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (0, 9, 0, 9) ---- GRData bin2val : 60.9
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (6, 8) ---- GRData bin2val : 86.0
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (9, 0, 8, 9, 0) ---- GRData bin2val : 980.9
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (0, 0, 12, 0, 0, 1, 1, 14, 4, 13, 2, 0) ---- GRData bin2val : (1.2, 22.5, 0, 0)
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (0, 0, 0, 0, 0, 0) ---- GRData bin2val : 0.0
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (7, 3, 8, 5, 6, 0) ---- GRData bin2val : 658.37
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (2, 7, 2, 3) ---- GRData bin2val : 2.72
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (0, 9, 4, 3) ---- GRData bin2val : 4.9
Dec  6 11:29:28 (none) weewx[2427]:  ----  GRData d : (15,) ---- GRData bin2val : 15
Dec  6 11:29:28 (none) weewx[2427]: Data dict : {'rt': 658.37, 'wc': 4.9, 'cn': 15, 'oh': 86.0, 'it': 23.3, 'ih': 40.0, 'pa': 980.9, 'dp': 2.72, 'ot': 60.9, 'rh': 0.0, 'wind': (1.2, 22.5, 0, 0)}
Dec  6 11:29:28 (none) weewx[2427]: ws23xx: Data station : {'rt': 658.37, 'wc': 4.9, 'cn': 15, 'oh': 86.0, 'it': 23.3, 'ih': 40.0, 'pa': 980.9, 'dp': 2.72, 'ot': 60.9, 'rh': 0.0, 'wind': (1.2, 22.5, 0, 0)}
Dec  6 11:29:28 (none) weewx[2427]: ws23xx: Data packet : {'barometer': 1006.82576, 'windchill': 4.9, 'dewpoint': 2.72, 'pressure': 980.9, 'outHumidity': 86.0, 'altimeter': 1010.8140710421635, 'heatindex': 65.29111, 'rain': 0.0, 'dateTime': 1417861768, 'windDir': 22.5, 'outTemp': 60.9, 'windSpeed': 4.32, 'inHumidity': 40.0, 'inTemp': 23.3, 'windGust': None, 'rainTotal': 65.837, 'rainRate': 0.0, 'usUnits': 16, 'windGustDir': None}
Dec  6 11:29:28 (none) weewx[2427]: wxengine: ignoring rain value of 0.0, limits are (0.0001, 10.0)
Dec  6 11:29:28 (none) weewx[2427]: wxengine: ignoring outTemp value of 58.9, limits are (-30.0, 50.0)
"""

Actually I commented the LSA line and I added a time.sleep(0.01) just before returning the result. after 1h30 of testing seems to be OK. I will check tomorrow, the graphs and traces result.

Andrew,
To use the RTS/CTS, is a good idea.but :
I'm not sure that the WS2350 support the CTS/RST signals. There only 4 wires on the cables
With an USB to RS232 converter, I don't know how to configure/use the CTS/RTS signal with pyhon. On another system always with raspberry, I used the pyserial interface and each time I read the data, there is first a sleep of 1s and then do a 'while' while the serial port is in waiting. and taking back the data during this loop. And I never had bad reading.
Probably we can do that with the linux serial port ?

rds

[lionel...@free.fr]

Hello,
Some news since my last report.
Since I have added a sleep in :

class Ws2300(object):
==> class Ws2300Exception(StandardError):

=====>    def read_byte(self, timeout=1.0):

I never have any more spikes (~7days running). Then I will remove all my traces and let the raspberry running like that. Is this "patch" could be added in the weewx distribution?

During my test I notice when the weewx SW is stopping for more than the archive_interval delay, and restarting the weewx SW, the dewpoint values are seting to the minimum value (> -50°C). The numbers of wrong value is a modulo of archive_interval. In my case archive_interval = 900 and when restarting after for example 3000s, there is 3 bad recorded values for dewpoint. Have you already seen that before?

For importing my old data, I finalise a python script which convert data from heavy weather to weewx. I integrate the 2014 data in the weewx.sdb. weewx have seen them but the graph and the NOAA data are still empty. Do you have an idea for that ?

rds.

[Andrew Milner]

The easiest way to force re-generation of all the NOAA data is to delete all the NOAA files and restart weewx - it will re-generate the files as required.  Which graphs are 'empty'?  Some of the graphs (yearly) are only generated once per day - so you may have to wait until tomorrow to see the extra data!!  The monthly graphs only go back 30 days anyway - so your imported data is probably older than that window and so will not show.

--
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/Ha_VqoBaySQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[lionel...@free.fr]

Hello,
Thx, the regeneration for the graphs and NOAA files are working. I also used 'wee_reports weewx.conf' to force it.

The WX23xx is working now fine on my side.
Now I just need to integrate my data from 2008 to 2013.

rds

[filippo]

Hello
I'm trying to connect my Lacrosse 2350 to weewx. I suppose all is fine because of when I digit weew.conf the data appear in my terminal. The problem is I'm not able to visualize the data in the html page; this page is fixed to the same time. I synch the time by using ntpd but it seems not work.

[mwall]

On Friday, January 23, 2015 at 10:13:25 AM UTC-5, filippo wrote:

Hello
I'm trying to connect my Lacrosse 2350 to weewx. I suppose all is fine because of when I digit weew.conf the data appear in my terminal. The problem is I'm not able to visualize the data in the html page; this page is fixed to the same time. I synch the time by using ntpd but it seems not work.

what does the log say?

if you are still having problems, please start a new discussion thread 

m