On Monday, March 20, 2017 at 11:12:55 AM UTC-4, Wysiwyg wrote:
>
> also during the weekend I noticed that at reboot, as weewx start before my
> ethernet connexion is fully setup, it seems I get a crash (the driver is
> not able to connect).
>
> Is it possible to use this weewx.WeeWxIOError during
bill,
thanks for posting this.
we probably should refactor the platform stuff in wee_debug. instead of
checking for a specific *platform*, it should check for specific *features*.
for example, it can easily spit out standard platform stuff:
platform.python_version()
platform.platform()
platfo
On Sunday, March 12, 2017 at 6:49:17 AM UTC-4, Wysiwyg wrote:
>
> This has no meaning and I guess it would be better to filter.
> also it may happens that some mqtt topics may be not for weewx but for
> other personnal use.
>
> I would like to check if a key is existing in weewx schema before put
On Wednesday, March 15, 2017 at 5:24:23 PM UTC-4, Ian Boag wrote:
>
> I think I have it .
>
> In simulator.py . getLoopPackets
>
> for obs_type in self.observations:
> _packet[obs_type]=self.observations ... blah .. blah
>
> Hijacking this looks like it should work . ?
>
just use
On Saturday, March 11, 2017 at 10:08:44 PM UTC-5, Darryn Capes-Davis wrote:
>
> Yes, specifically it is Wunderground code. Introduce in Nov for caching
> rapid fire values. I suppose this code would have well helped for
> developing, but too verbose in my opinion for debug=1.
>
fixed at commit 6
darryn,
could you be more specific about which log messages?
for restful services, doing debug=2 should show the url/data before
actually uploading, so that you can debug network issues from the client
point of view.
there is also log_failure and log_success that should apply to each restful
On Saturday, March 11, 2017 at 6:30:47 PM UTC-5, Thom Rogers wrote:
>
> Hi Matt,
>
> I found the usb repo, but not sure what I need to download from there (and
> where to put it ) in order to use with my wh23xx driver.
>
thom,
the usb branch includes the wh23xx driver. the lower-level code is
On Thursday, March 9, 2017 at 8:01:26 PM UTC-5, Clay Jackson wrote:
>
> I just picked up an Acurite 275M outdoor temp/humidity sensor that has an
> external probe – I want to set up at least one, and maybe 2 or 3 for Soil
> Temp recorders. RTL_433 will read them and produce this – all I need
On Tuesday, March 7, 2017 at 11:36:53 PM UTC-5, Ian Boag wrote:
>
> Not sure where to start - the obvious place is the fousb.py driver and
> have it go to a file with the downloaded query in it (instead of talking to
> the station). I can read the numbers etc. I assume that fousb.py just
> retur
On Saturday, February 25, 2017 at 1:50:23 PM UTC-5, crich...@gmail.com
wrote:
>
> Thanks. I'll get to cleaning up the code later, but on the time thing...
> here's the code and values that are part of rec_time being sent in.
> It sure looks to me that int(time.time()+0.5) gives local time. Of t
On Saturday, February 25, 2017 at 11:07:01 AM UTC-5, crich...@gmail.com
wrote:
>
> I tried this again with more messaging enabled, and I think the problem is
> that the times in the records have to be local times, not something from
> the past, and not actually UTC. Both those cases result in t
On Thursday, February 23, 2017 at 7:59:13 AM UTC-5, Bill Morrow wrote:
>
> I discovered a possible problem with this approach working well with other
> parts of weewx. Last night I was attempting to get the Realtime Gauge-Data (
> https://github.com/gjr80/weewx-realtime_gauge-data) extension goi
On Wednesday, February 22, 2017 at 12:42:59 PM UTC-5, Bill Morrow wrote:
>
> I understand your points about wind, Frederic. There's an interesting
> discussion underway in another thread in the user group:
> https://groups.google.com/d/msg/weewx-user/x2RYkjwyNjc/Ilcqr3-7BgAJ.
> "tempus" makes
On Tuesday, February 21, 2017 at 10:49:35 AM UTC-5, Thom Rogers wrote:
>
> I'm confused as to why you are talking about an acurite driver. I'm
> interfacing to an Excelvan WH2310 which I believe is a Fine Offset station,
> not Acurite.
>
i mistyped. i meant the fine offset wh23xx.
bill,
you might want a separate thread in the wxMesh driver - one thread that
receives mqtt data and puts it on a queue, then the main thread that runs
genLoopPackets and picks data off the queue as soon as they arrive.
see the ws3000 driver for a pretty simple example implementation. it has
On Sunday, February 12, 2017 at 10:26:35 PM UTC-5, vk3...@gmail.com wrote:
>
> Just noticed that the beta of V3.7.0 is available.
> In the release notes from Tom he noted that any missing 'windGustDir' is
> to be determined by Weewx with this version.
> Please note that the last version of my driv
On Monday, February 20, 2017 at 9:45:55 PM UTC-5, vk3...@gmail.com wrote:
>
> I think I'm nearly ready to release this but I'd still like a comment on
> hwo to best handle the new version (V3.7.0)
>
susan,
you should not have to do anything special for weewx 3.7.0 - there are no
changes in 3.7
On Monday, February 20, 2017 at 8:27:07 PM UTC-5, crich...@gmail.com wrote:
>
> Here's the comment from the top of the file: Derived (shamelessly stolen)
> from Matthew Wall's Observer driver by Chris Richmond.
> Meaning the basic structure is still there, just the additions to deal
> with my dat
On Monday, February 20, 2017 at 2:27:55 PM UTC-5, crich...@gmail.com wrote:
>
> I'm making progress with my driver, and I'm making LOOPs in weewk now, but
> the archive's and generated files aren't happening.
> There aren't any errors anywhere, just no DB updates, pictures, or web
> pages. The t
On Sunday, February 19, 2017 at 1:35:20 AM UTC-5, Thom Rogers wrote:
>
>
> Any advice on how to overcome the "No backend available" error?
>
thom,
you have to install a usb 'backend' that is supported by pyusb. three
examples are libusb, libusb1, or openusb. libusb1 is probably your best
bet.
On Saturday, February 18, 2017 at 9:18:07 PM UTC-5, Inoukb wrote:
>
> Hello, Inouk from Foobot here. Available to help if necessary.
>
> Not sure why you guys don't use our API though:
> http://api.foobot.io/apidoc/index.html
>
hello inouk!
is it possible to configure the foobot to send to a loc
On Monday, January 9, 2017 at 5:22:35 PM UTC-5, kd0...@gmail.com wrote:
>
> Is there a driver for the La Crosse WS-2816CH-IT weather station? Thanks.
>
did you try the interceptor driver?
https://github.com/matthewwall/weewx-interceptor
m
On Friday, February 17, 2017 at 2:22:44 PM UTC-5, Thom Rogers wrote:
>
> Not sure what this tells us, but here's the output of those commands:
>
trying to figure out whether you have multiple python installations
did you set PYTHONPATH?
what happens when you run with no PYTHONPATH set?
On Friday, February 17, 2017 at 8:24:19 AM UTC-5, Thom Rogers wrote:
>
> No. No luck on that either
>
>
> >>> import configobj
>
> Traceback (most recent call last):
>
> File "", line 1, in
>
> ImportError: No module named configobj
>
>>
>>
which python do you get when you invoke the shell? tr
On Thursday, February 16, 2017 at 9:50:28 PM UTC-5, Thom Rogers wrote:
>
> Even though I've successfully installed configobj via the pip install
> configobj command, when I try to start weewx it errors with "No module
> named configobj"
>
can you import configobj at a python prompt?
On Thursday, February 16, 2017 at 10:36:10 PM UTC-5, crich...@gmail.com
wrote:
>
> OK, I think I've got it. One more thing. Is there a point to including
> pairs where the value is zero, or is that assumed when the data gets rolled
> up for archive or plotting?
> Thx, Chris
>>
>>
>>>
chris,
On Monday, February 13, 2017 at 9:28:05 PM UTC-5, susan wrote:
>
> Thanks for the feedback. I'll plead 'guilty' to not bumping the version
> number, but I've just downloaded and expanded the file I attached above and
> the line in the 'install.py' file that I think drives all this is:
>
>
On Thursday, February 9, 2017 at 1:00:08 AM UTC-5, Clay Jackson wrote:
>
> I've got an Acurite 5n1 that I'm reading using the SDR radio driver.
> Since that doesn't provide a barometer, I'm reading an APRS formatted
> stream from another station I have, and grabbing the barometer from there
the wiki has an example of how to do option 2 using file parsing:
https://github.com/weewx/weewx/wiki/add-sensor
the wiki also has an example of how to do option 2 using a separate thread:
https://github.com/weewx/weewx/wiki/multi-threaded-service
On Monday, January 30, 2017 at 9:56:05 AM UTC-5, Pat O'Brien wrote:
>
> Hey Matthew, your GitHub link 404s. Do you have an updated link for it?
>
https://github.com/matthewwall/weewx-observer
pat,
please take a look at this weewx wiki page:
https://github.com/weewx/weewx/wiki/observer
the interceptor approach is pretty much the only option for the fine offset
bridges, but there is a direct-connect approach for the fine offset wifi
consoles that requires zero configuration (no scrap
On Sunday, January 29, 2017 at 12:31:28 PM UTC-5, Tom Keffer wrote:
>
> So, I would propose including #errorCatcher on the top of all the
> included files.
>
done at commit 352c5dc on the newskin branch
i also add a 'map' widget - if you specify a google map apikey in skin.conf
Extras, then you
here is another update to the new Standard replacement candidate:
http://lancet.mit.edu/mwall/projects/weewx-newskin/
changes include:
- separate page for celestial details
- consolidate and simplify css
- a new 'sensor status' section
- modified simulator to emit battery status
fixed in 0.18rc2.py
m
#!/usr/bin/env python
# Copyright 2015 Matthew Wall
# See the file LICENSE.txt for your rights.
#
# Credits:
# Thanks to Benji for the identification and decoding of 7 packet types
#
# Thanks to Eric G for posting USB captures and providing hardware for testing
# https://g
On Monday, January 23, 2017 at 10:25:27 AM UTC-5, Agusti Rifer wrote:
>
> I have placed the added file wmr300-0.18rc1, i have downloaded the
> generation time to 2 minutes, but the problem persists.
> Every 15 minutes makes a correct barometer and the rest all N/A.
>
you must replace wmr300.py i
On Monday, January 23, 2017 at 3:24:46 AM UTC-5, Agusti Rifer wrote:
>
> I have an Oregon WMR300 I find a problem, if the file generation interval
> is set to 900 (15mins) everything works correctly, but if it is set to 5
> minutes, the barometer is only recorded every 3 records and on the weewx
On Sunday, January 22, 2017 at 6:53:25 PM UTC-5, Vince Skahan wrote:
>
> On Sunday, January 22, 2017 at 2:19:26 PM UTC-8, mwall wrote:
>>
>> another update to the newskin candidate:
>>
>> http://lancet.mit.edu/mwall/projects/weewx-newskin/
>>
>
> should
another update to the newskin candidate:
http://lancet.mit.edu/mwall/projects/weewx-newskin/
changes include:
- lightened up the graphic design and layout
- rudimentary color scheme elements
- using a much-less-ugly font (currently uses google font server, but i'm
evaluating fonts to in
On Friday, January 20, 2017 at 12:40:51 AM UTC-5, dr__bob wrote:
>
> So a try, except bracketing the sendto would help. With a configurable
> delay? With a configurable number of retries? But I've really got to
> figure out why my cable modem apparently periodically restarts.
>
weewx is des
finally, and most importantly,...
very nicely done!
here is a bit more unsolicited advice:
- split the code into two classes: HP1000Driver and HP1000Station. the
station class should do all the work - that is where the network stuff
happens, and that is where the decoding happens. then you can derive a
TESTStation from HP1000Station to put al
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
perhaps most important items as you make your work available to others:
- add a copyright line to the top of readme, install.py, and the driver .py
itself:
Copyright 2017 Susan
email address is optional.
- if you want to distribute under a license, then include a file called
'license' with
On Wednesday, January 18, 2017 at 9:12:58 PM UTC-5, vk3...@gmail.com wrote:
>
> I have attached the tar.gz file that I *think* will work as an extension
> but I've only managed to test it on my iMac with Weewx installed via the
> 'setup.py' method.
> Can some mind soul(s) please try this out (in
On Monday, January 16, 2017 at 1:46:17 PM UTC-5, blown46pwr wrote:
>
> I also noticed the barometer reading that is reported by weewx is a little
> high. Is that the observerip driver or a weewx setting?
>
it might be a pressure/barometer/altimeter issue:
https://github.com/weewx/weewx/wiki/Baro
so it looks like there are 4 approaches to getting data:
1) get the livedata.htm page then parse it for values
2) use raw udp/tcp sockets to find the station then query it for data
3) sniff network traffic (requires the station to be sending to
wunderground)
4) listen for network traffic (requ
On Monday, January 16, 2017 at 12:24:42 PM UTC-5, blown46pwr wrote:
>
> Does this help?
> https://www.dropbox.com/s/bawuan2dfdqs5az/Alma%2C%20MI%20Current%20Weather%20Conditions.htm?dl=0
>
that is the page generated by weewx.
we need the page that you get when you connect to the observer.
htt
On Thursday, January 12, 2017 at 10:36:54 PM UTC-5, blown46pwr wrote:
>
> Only thing left to figure out is the wind direction.
>
please connect to your weather station with a web browser using this url:
http://XXX/weather.htm
where XXX is the ip address of the weather station. then save the fil
On Wednesday, January 11, 2017 at 10:01:58 PM UTC-5, vk3...@gmail.com wrote:
>
> At present the code includes 'testing code' that I've used to confirm that
> the various unit transformations all work, and this is controlled by a
> single class boolean variable. Is it better to leave this code in
susan,
just to be clear, your driver works with the wifi console, not the bridge,
right?
be sure to package your driver as a weewx extension. that will make it
much easier for people to install. see the customization guide for details
about how to package an extension, and see the fileparse
On Wednesday, January 11, 2017 at 7:45:38 PM UTC-5, Tom Keffer wrote:
>
> Gack! That's been in there since the original translation from Pascal, now
> 4 years ago!
>
there is a fair amount of unused code in uwxutils - apparently none of the
functions that use uwxutils.CToF are actually used:
St
On Monday, January 9, 2017 at 10:13:31 PM UTC-5, blown46pwr wrote:
>
> The web page is still loading as simulator.
>
> Appreciate the help. Have to go to bed. Will tackle more tomorrow. Thanks!
>
please try pulling the latest from github (driver version 0.6), then try
again.
m
On Monday, January 9, 2017 at 10:13:31 PM UTC-5, blown46pwr wrote:
>
> The web page is still loading as simulator.
>
you need to remove the 'break' line too.
better yet, do some captures of the web page and post them, then i can
ensure that the driver works with them.
the code could be consolid
On Monday, January 9, 2017 at 9:52:15 PM UTC-5, blown46pwr wrote:
>
> Thanks for helping.
>
> Which file am I supposed to edit? I do not see "logdbg" in the config file
> and it only goes to line 506?
>>
>>
>>
modify the driver file user/observerip.py. and i mistyped. it should be
this:
On Monday, January 9, 2017 at 9:29:55 PM UTC-5, blown46pwr wrote:
>
> Now the only questionable message I get is this: observerip: packet
> missing UV but it is running. However the index.html file is still loading
> the simulator information.
>
apparently the web page on your station does not c
On Monday, January 9, 2017 at 9:15:19 PM UTC-5, blown46pwr wrote:
>
> I edited the weewx.conf file and remarked out sensors that my WS-0900-IP
> does not have, like solar. It then choked telling me it was expecting a
> value of "0" (zero) but it found a 2. So I edited the weewx.conf file again
>
On Monday, January 9, 2017 at 8:44:53 PM UTC-5, blown46pwr wrote:
>
> Hoping someone can help me with the observerIP driver. I followed the
> directions in this thread and it seemed to install fine. When I start weewx
> and watch the messages at tail -f /var/log/syslog, it reports in one of the
On Saturday, October 15, 2016 at 6:49:15 PM UTC-4, Tom Keffer wrote:
>
>
> Shall we put the Windows branch into the main Git repo while playing with
>> this? Can I create a pull request for that?
>>
>
> If you wish. But, let me ask you, are you willing to be the support
> point-of-contact for a
On Sunday, January 8, 2017 at 8:42:48 AM UTC-5, Tom Keffer wrote:
>
> Alternatively, make a "loop report engine," analogous to the present
> archive report engine. Or, adapt the existing report engine so it can work
> on loop data.
>
> This would be the more general solution.
>
agreed. a loop
darryn,
as you design this json interface, i hope that we can avoid the mess that
is customraw.txt and realtime.txt
those two files are output by weather-display and cumulus, respectively.
those are the primary mechanism for getting data from those applications to
their non-native displays, s
darryn,
beware that there is no single json to rule them all.
you might do:
$current.json
that emits archive records (or loop data) in json format, only to find that
the json you output is not recognized by the plotting library you want to
use.
in this respect, a jsongenerator might make mor
chris,
angular (1 or 2) has way too much overhead
react is more heavyweight than i would like as well
i lean toward riot:
http://riotjs.com/
if you're going to do dashboards right, you either need a dashboard
framework that can do everything, or you need a bunch of components that
play well
sandor,
around line 70 of idokep.py, change this:
site_dict.setdefault('station_type', 'WS23XX')
site_dict.setdefault('database_dict', config_dict['Databases'
][config_dict['StdArchive']['archive_database']])
to this:
site_dict.setdefault('station_type', engine.stn_i
On Tuesday, December 27, 2016 at 6:41:52 PM UTC-5, Sándor Makány wrote:
>
> Kedves Lóránt!
>
> Próbálom beüzemelni a modulod, azonban az alábbi hibába futok bele:
> File "/usr/share/weewx/user/idokep.py", line 63, in __init__
> Dec 27 23:37:45 raspberrypi weewx[4830]: site_dict =
>
On Thursday, August 25, 2016 at 10:25:23 AM UTC-4, moof wrote:
>
> Good morning,
>
> I am looking to add support for the Rainwise IP-100. The device provides a
> XML feed via the devices ip/status.xml updated every 2 second.
>
> I am new to Python, so some examples could help. What is the best dr
On Thursday, December 22, 2016 at 11:41:46 AM UTC-5, Moreno Simonetti wrote:
>
> hello . can help me.?
>
Dec 22 17:23:07 raspberrypi weewx[1255]: wmr300: e.errno=None
e.strerror=None e.message=could not detach kernel driver from interface 0:
Nessun dato disponibile repr=USBError('could not detac
susan,
thank you for reporting this.
according to redhat, you're not supposed to modify anything in
/usr/lib/systemd/system:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html
perhaps wee
bill,
i'm not sure what you mean by 'port', but i'm pretty sure there is a weewx
port (i.e., package) for freebsd:
https://reviews.freebsd.org/D6324
the cmon extension has to deal with many platform-specific operations. at
first i wrote it using /sys and /proc, but then i discovered the pytho
On Wednesday, December 7, 2016 at 11:30:51 AM UTC-5, albes wrote:
>
> Hi Guys, sometimes my weewx reads strange data and generate peaks in the
> outtemp history values. How can I avoid these peaks ?
> I cannot understand why this is happening and I'm not sure it is related
> to hardware...
> The
the candidate skin has been updated based on feedback received thus far.
you can try it yourself in the newskin branch, or see a snapshot here:
http://lancet.mit.edu/mwall/projects/weewx-newskin-161104/
- there are two possible stats pages, statistics-a.inc and
statistics-b.inc, only one of
thanks for the feedback thus far! try the latest iteration on the new
Standard skin in the newskin branch, or look at a snapshot here:
http://lancet.mit.edu/mwall/projects/weewx-newskin-161104/
a few things to note:
- celestial now includes daylight hours. tested for extreme polar
locations
thanks for the feedback thus far! try the latest iteration on the new
Standard skin in the newskin branch, or look at a snapshot here:
http://lancet.mit.edu/mwall/projects/weewx-newskin-161104/
a few things to note:
- celestial now includes daylight hours. tested for extreme polar
locations
thanks for the feedback thus far! try the latest iteration on the new
Standard skin in the newskin branch, or look at a snapshot here:
http://lancet.mit.edu/mwall/projects/weewx-newskin-161104/
a few things to note:
- celestial now includes daylight hours. tested for extreme polar
locations
On Thursday, November 24, 2016 at 8:58:01 PM UTC-5, vk3...@gmail.com wrote:
>
> I'll check a few things out when I get home but I had not realised that I
> needed to provide the 'delta' rain value for each loop packet. I was
> passing back the 'daily rain so far' value so I'll look into changing
On Saturday, November 19, 2016 at 8:53:45 AM UTC-5, Hartmut Schweidler
wrote:
>
> Hallo
> In the "skin mg" not "user.json.JSON"
>
hartmut,
the 'mg' skin should not have been included in the newskin branch, and i
have removed it. it is a very experimental skin i have been using to test
variou
darryn,
thanks for the feedback!
there is nothing wrong with javascript, cookies, jquery, or bootstrap. but
imho jquery and bootstrap do not belong in the weewx standard skin.
- weewx must have minimal dependencies, but using jquery/bootstrap is a
massive dependency
- using jquery makes cheet
On Monday, November 14, 2016 at 6:36:48 PM UTC-5, Vince Skahan wrote:
>
> On Monday, November 14, 2016 at 3:31:16 PM UTC-8, mwall wrote:
>>
>> thanks glenn. i have added a link to weewx.com. also added a satellite
>> link, analogous to the radar link.
>>
>
&
thanks glenn. i have added a link to weewx.com. also added a satellite
link, analogous to the radar link.
including a forecast.inc is exactly my intent. same for a
javascripty-plots.inc or heatmap.inc or anticipated-spray-days.inc or
tides.inc or a nullschool.inc
you should be able to just
thank you for the feedback!
what features/functionality do you consider must-have for the standard skin?
what other attributes should the new standard skin have, e.g., "easy for
new users to understand", "easy to extend", "show all sensor data",
"illustrate core weewx capabilities"
change up t
On Saturday, November 12, 2016 at 9:34:46 PM UTC-5, Tom Keffer wrote:
>
> Not sure what sort of feedback you're looking for. I assume this is a
> work-in-progress?
>
my intent is to replace Standard with something more modern, more
functional (wrt sensors and out-of-box experience), and with les
forgot the .inc files in setup.py manifest
fixed at 2cdea68
you'll have to re-install, or copy the .inc files manually
thanks to chris for his work on 'Standard Skin Version 2', as well as the
feedback from glenn, alan, vince, steve, and others in that thread.
hopefully we can get the momentum to make it happen this time...
't want to install and try it yourself, you can see the
refactored skins here:
http://lancet.mit.edu/mwall/projects/weewx-newskin
known issues:
- day/week/month/year are not obviously click/touch-able
- timestamp for each max/min is a hover; should be click/touch-able
- grey is a boring color
m
On Tuesday, October 18, 2016 at 3:29:48 PM UTC-4, Vince Skahan wrote:
>
> I've been on the other end of unpredictable ethernet naming, where some
> kernel updates changed which nic was eth0 vs. eth1 in an embedded system
> that I couldn't mess with. Something about PCI bus ordering changed, if I
On Tuesday, October 18, 2016 at 1:25:14 PM UTC-4, Eelco F wrote:
>
> Since then, CPU_temp is no longer read out, and also neteth0rbytes and
> tbytes are now longer written to the graphs. I think the latter must be due
> to ubuntu which calls eth0 enp0s25 now. This is due to systemd.
>
why must t
On Saturday, October 1, 2016 at 10:01:37 AM UTC-4, kobuki wrote:
> -- "... rainRate should not be in the driver at all. the hardware reports
> a value that is arbitrary, and the rainRate calculation is yet a different
> arbitrary calculation ..." - well, the rf packets provide a raw value,
>
this is regarding the commits for meteostick driver 0.45, which included
removal of the use of weewx.units.Converter() for unit conversions and the
change to weewx.METRICWX from weewx.US for the unit system of LOOP packets
emitted by the meteostick driver.
there have been many exchanges via ema
On Thursday, September 29, 2016 at 22:44:13 PM UTC-4, Sam Roza wrote:
>
> Yeah, you're right about switches, of course. Well, I guess it's time to
> break down and buy a Pi...
>
> A Pi3, and some bridge work, and I should be up and running.
>
> Matt, would you suggest the DNS methods over the oth
On Wednesday, September 28, 2016 at 5:09:13 PM UTC-4, Sam Roza wrote:
>
> Hi Matt,
>
> I have an LW-301 here, and I have loaded the interceptor driver, but it
> seems that the interceptor basically requires putting a piece of hardware
> in between the router and the OS Internet Gateway if you don
On Saturday, September 17, 2016 at 10:31:41 PM UTC-4, Darryn Capes-Davis
wrote:
>
> Thanks all for the feedback. Now have
> https://github.com/dcapslock/Weewx-OpsGenie with first release
> https://github.com/dcapslock/Weewx-OpsGenie/releases/download/v0.1/Weewx-OpsGenie.tar.gz.
>
> Will write
On Saturday, September 17, 2016 at 5:07:03 AM UTC-4, Darryn Capes-Davis
wrote:
>
> IMPORTANT: If you wish to give it a go you need the latest restx.py which
> was committed today. This is why I am sharing just in development group for
> now.
>
> Some questions:
>
> 1. Does the extension cut the
On Wednesday, September 14, 2016 at 10:56:56 AM UTC-4, jmltech wrote:
>
> What would be a good example to follow for creating a new driver and
> service?
joe,
first of all, you should decide whether to do a driver or a service. a
driver is the primary source of data when you run weewx. a ser
radar,
thanks for posting the sensor outputs. these have been incorporated into
the interceptor driver as of v0.10rc2. it *should* automatically detect
whether the acurite bridge has older firmware that emits chaney's format or
the newer firmware that puts out the wu-ish format.
m
hello Björn,
you have many options. basically you install a weewx uploader extension on
the pi that feeds data to your server. here are a few:
MQTT - very low bandwidth, easy to integrate with many other systems
InfluxDB - easy integration with grafana and other plotting tools, but not
so mu
On Sunday, August 21, 2016 at 9:25:58 AM UTC-4, Radar wrote:
>
> acurite update to the firmware to 224
>
>
radar, thank you for posting this, especially the output for the tower,
room monitor, and extra sensors. thanks to hardware from george
nincehelser, i've been working on an update to the in
On Thursday, August 25, 2016 at 10:25:23 AM UTC-4, moof wrote:
>
> Good morning,
>
> I am looking to add support for the Rainwise IP-100. The device provides a
> XML feed via the devices ip/status.xml updated every 2 second.
>
> I am new to Python, so some examples could help. What is the best
On Wednesday, August 17, 2016 at 7:58:29 AM UTC-4, stefano siega wrote:
>
> Now i want to use this data in the reports. But if I use the tag
> "$lightning_strikes" or "$day.lightning_strikes.raw" I receive an error:
>
> log:
>
> Aug 17 13:55:23 raspberrypi weewx[7005]: cheetahgenerator: Igno
ead of
archive:
[AS3835]
binding = loop
give it a try and let us know what you get.
m
# $Id: as3935.py 1494 2016-08-12 23:42:27Z mwall $
# Copyright 2015 Matthew Wall
"""
A service for weewx that reads the AS3935 lightning sensor range. This service
will add two fields
On Friday, August 12, 2016 at 7:43:57 PM UTC-4, Steve Sykes wrote:
>
> Hi Ian,
> I just installed your MOD-1016 board, into my Raspberry Pi2 weather
> station. It was recognized right away, but integrating it into weewx is not
> so easy. Right now there is an issue with the python driver.
> I h
On Wednesday, August 10, 2016 at 2:51:01 PM UTC-4, Vince Skahan wrote:
>
> On Wednesday, August 10, 2016 at 10:20:25 AM UTC-7, mwall wrote:
>>
>> stuff on the wiki is 'officially' released and should work with the
>> latest version of weewx. stuff in my g
101 - 200 of 203 matches
Mail list logo
