Feature Request: Add a set of functions that return errors rather than exit

Description

The current set of data reading functions block a for long time trying to talk to the WS2300. If after this period they have not been able to contact the device they print an error message on stderr and exit the program. This works well for the programs supplied with the package that are designed to be run periodically via cron. However if you wish to create a long running daemon that gathers data from the device and then performs some kind of processing on the data, then the program exit on error (or at times the long timeout) does not work well.

I have created a (sub) set of functions (along with a new version of reset_06 with shorter retries/timeouts) that operates this way. However I'm not sure what would be the best way to submit these changes. Currently they are in the rw2300 file (using a different set of function names), however it may be better to extract these functions and place them in a different file. I have not attempted to refactor the existing code to use these new functions (though obviously it would be possible to do this). I thought that posting here would be a good way of getting feedback on the best way forward. If you think that refactoring (so that the current functions call the new error returning versions thus keeping all of the data decode logic in one place), is the best way forward then I'd be happy to make those changes. If you would rather keep things as they are I'm happy to move my changes out of the rw2300.c file and to maintain/publish them along with the other code I am creating.

-- AndyShaw - 30 Dec 2005

Follow up

Interesting idea.

You should make a patch topic and post your proposals. As you will see on many of the Motion patch topics a patch can evolve for some time while people test it and propose improvements. That is one of the advantages of using a wiki for these things.

The WS23XX weather stations have a lousy computer interface. The minute the station is busy with something it ignores the serial interface. During the night when the European models are syncronizing time from the DCF77 time reference radio station it ignores the serial line for minutes.

This is why the current retry scheme is in place.

I see many ways to implement your proposal.

• Have an additional environmental variable which can be set in the individual programs. I am not sure this is so elegant.
• Have unique functions with shorter retry schemes in rw2300 and let the programs call one or the other. I think the API and ease of understanding the code suffers from this method.
• Extend the API to the calls so that you can adjust how often you want to retry.

There is an additional detail. Because the wind sensor interface sucks and often shows 25.5 m/s (FF) I have an additional retry scheme for wind speed which retries if it gets the FF or 1FF response. How should be handle this?

-- KennethLavrsen - 31 Dec 2005

Comments