On Thursday, January 19, 2017 at 11:54:26 PM UTC-5, vk3...@gmail.com wrote: > > Thanks for all of the feedback - brilliant! > Mike - I was a bit wary of claiming too much 'copyright' as I must admit > I've "borrowed" quite a bit from your "pmon" extension. > I noticed that using the "wee_extension" install method only put into the > config file the lines in 'config' section of the 'install.py' file. However > the driver itself has the 'confeditor_loader' function that I must have got > be run sometime in the past (just putting the code in the directory and > using the 'wee_config' reconfigure to switch to the new driver perhaps???) > and that has commented lines which I think is much better. >
as you noticed, wee_extension will insert the config parameters specified in install.py but wee_config will insert the (commented) parameters from the confeditor (if there is one). this also lets you prompt the user for any required options for which there are no defaults. you can figure out sane defaults for everything for this driver. for the network mask, you can default to a generic broadcast. then users can specify something more specific if they have a special network configuration (e.g., to span a vpn or router). > I'll also change the name. the XC0422 was the only clone that I had access > to and I didn't want to make claims that I could not back up by calling it > anything else. However it would seem that it does work on other 'clones' > and so using the original name woudl be netter. > Dr Bob (name taken from the old Muppet sketch per chance???), I can put in > a delay (with the delay length driven by an optional parameter with a > default of 5 seconds). I must admit that the network traffic didn't bother > me on my home local network (especially when you look at the garbage my > Apple TV puts onto the network) but this is a good idea. > the typical approach is to define a poll_interval, with a default value set to the shortest sensor update interval. then just time.sleep(self.poll_interval) in the while loop in genLoopPackets > Also I'll add in the suggestion for the systemctl file. In the 'readme' I > mention that you should put in references to make sure the network is up > and running so the Weewx daemon will not cause problems on startup. > it would be better if you do not. instead of applying that band-aid, make the driver more robust. you should retry the network connections, and if the retries fail more than max_tries times, then you raise a weewx.WeeWxIOError exception. then weewx handles it as it does for any other driver. remember that not everyone uses systemd (*bsd, windows and macos do not even have systemd) > Gary - Thanks for the suggestions. I'll read to read up on 'markdown' and > give that a go. > Back with another go shortly. Also thinking about using the 'HISTORY' data > to see if there are gaps in the Weewx databse that can be filled in by the > console, but that will be V2. > Any thoughts about sampling the SDETUP packet more often to detect console > unit changes or is just telling people to restart Weewx OK? > Susan > there is no reason to restart weewx. the station is already sending you the unit system in each packet. so just make the driver deal with the changes on the fly. you can either change usUnits, or do conversions on each observation (you'll probably want to do the latter). you should use snake_case for every function too (except for the ones you *must* do camelCase, such as genLoopPackets). at some point you should refactor so that all of the test code goes into the __main__ section. isolating the test code will become especially important when you try to do additional features such as history data. m
