Re: [weewx-user] Re: Setting log level for syslog.syslog() style logging for older addons and modules
That's fine. I can fix what's needed for me where upstream has ceased working on it. Until then I can suggest adding syslog filters on their system. I'm not sure there are still repos where I can commit, tho. However, with all due respect, you don't maintain WeeWx for devs but for the general audience so the "whiney" comment is a bit out of the line, I think. Users will "whine" while not contributing a single line. And that's perfectly fine. Even if "whining" don't lead to anywhere. I can do all the fixes I need without barking around on these forums but I think if this has a viable user side solution for other folks with a similar problem, we can all benefit from seeing the solution here. I'm maintaining a driver now that also will get the v4 treatment. And that's also perfectly OK, since that's my job. On Thursday, May 21, 2020 at 2:33:04 PM UTC+2, Tom Keffer wrote: > > For the record, Gary is one of the core developers. > > For a variety of reasons, one of the goals of V4 was to not depend on > syslog. Yes, you've found a regression, but not a very major one. It can't > be fixed without breaking that goal. > > We have tried hard to get 3rd parties to "catch up", to the point of > submitting PRs for them. I personally have submitted a dozen or so. > > ...if I ever get to thoroughly know the insights of the logging mechanisms >> inside core WeeWx code, I will happily contribute a fix. However, until >> then, please don't sound like that's the only way to fix regressions. > > > I'd also say, "No whining if you don't contribute." > > -tk > > > > > On Thu, May 21, 2020 at 2:06 AM kobuki > > wrote: > >> Certainly, if I ever get to thoroughly know the insights of the logging >> mechanisms inside core WeeWx code, I will happily contribute a fix. >> However, until then, please don't sound like that's the only way to fix >> regressions. That aside, what I'd like to hear is some opinion or statement >> from core devs if they consider it a regression at all, or it was expected >> from the get go with all the breaking changes for 3rd party devs to catch >> up. I will respect their stance in that case and let it go. >> >> On Thursday, May 21, 2020 at 10:56:03 AM UTC+2, gjr80 wrote: >>> >>> Yes, you maybe right. As Tom says, PRs are always welcome. >>> >>> Gary >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "weewx-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to weewx...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/9515f5d6-35c6-4806-b0a6-6f86a58b64c6%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/9515f5d6-35c6-4806-b0a6-6f86a58b64c6%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/e749e174-e83d-4125-8e48-95e177260850%40googlegroups.com.
[weewx-user] Re: Setting log level for syslog.syslog() style logging for older addons and modules
Certainly, if I ever get to thoroughly know the insights of the logging mechanisms inside core WeeWx code, I will happily contribute a fix. However, until then, please don't sound like that's the only way to fix regressions. That aside, what I'd like to hear is some opinion or statement from core devs if they consider it a regression at all, or it was expected from the get go with all the breaking changes for 3rd party devs to catch up. I will respect their stance in that case and let it go. On Thursday, May 21, 2020 at 10:56:03 AM UTC+2, gjr80 wrote: > > Yes, you maybe right. As Tom says, PRs are always welcome. > > Gary > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9515f5d6-35c6-4806-b0a6-6f86a58b64c6%40googlegroups.com.
[weewx-user] Re: Setting log level for syslog.syslog() style logging for older addons and modules
Thanks for your comment. No, it's not "harsh", logging IS all over the place, since it's in the designated weewx.log, syslog and also in the systemd journal under several different tags. I'm also aware of secondary instances' tagging scheme in the log. It's just that it's another source of misc. tagging, making it harder to organize and filter the log. Possibly it's caused by various modules using the old syslog module with assumptions about process names. I now constrained them using rsyslog filters, but it's more like inconsistent behavior or regression than anything else. What's not going to magically happen is all old module devs taking prior notice and fix all the old code to comply. At least the basic level of compatibility should have been kept, allowing the old debug flag work. There are also old modules that work very fine while being basically abandoned, but now have botched logging. And no, sadly not all of them are accessible nor willing to touch their legacy code. On Thursday, May 21, 2020 at 2:24:00 AM UTC+2, gjr80 wrote: > > On Thursday, 21 May 2020 07:44:24 UTC+10, kobuki wrote: >> >> I've upgraded my 3.9.3 to 4.0.0 on a Debian 10. Unfortunately logging now >> is all over the place. >> > > Sounds a little harsh. > > Program name for rsyslog filters is either 'weewx' or 'weewxd' or on a >> second weewx instance, 'weewx-name'. >> > > I am running V4 under Debian 10 and see no 'weewxd' in the logs, but then > again I only run setup.py installs and not package installs. 'weewx-name' > for a second WeeWX instance is (and always has been) expected behaviour; if > you are logging to a single file different program names for each WeeWX > instance makes debugging far easier, also makes it far easier to log each > instance to separate files. > > But then it ignores 'debug = 0' in weewx.conf when a module uses >> syslog.syslog() calls instead of the new Python logger. Modules put out >> debug messages in the log. The old "central" debug setting used to take >> care of them. Can I set the syslog logging level somehow in config for all >> modules that still use the facility? >> > > I doubt whether there will be any magic button you can press in a config > file since V4 now uses the python logging module in lieu of the syslog > module and consequently the old syslog setup code was removed in V4. There > may well be some magic syslog incantation that someone will provide, but I > suspect you will be best served by contacting the 3rd party extension > authors and asking them to update their extension to work (properly) with > V4. > > Gary > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/52241058-2ea2-457b-886b-2d1054f22f65%40googlegroups.com.
[weewx-user] Setting log level for syslog.syslog() style logging for older addons and modules
I've upgraded my 3.9.3 to 4.0.0 on a Debian 10. Unfortunately logging now is all over the place. Program name for rsyslog filters is either 'weewx' or 'weewxd' or on a second weewx instance, 'weewx-name'. That's the lesser of the issues, I can work around that. But then it ignores 'debug = 0' in weewx.conf when a module uses syslog.syslog() calls instead of the new Python logger. Modules put out debug messages in the log. The old "central" debug setting used to take care of them. Can I set the syslog logging level somehow in config for all modules that still use the facility? -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a533a242-2442-4693-af7c-a44ffe392809%40googlegroups.com.
[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2
I need to correct myself. The cabled serial output should be available on the RJ11 connector if an ADM3483 TTL-RS422 converter chip is installed on the wireless ISS. See this thread on wxforum: http://www.wxforum.net/index.php?topic=18656 (see also: http://www.wxforum.net/index.php?topic=28530.0) However, you only need the 3.3V serial output from the MCU on the board (no need for the converter chip), which is apparently routed to pin 4 of the converter chip pads for easy soldered access. So you can just get normal TTL serial data out of there and forward it to your decoding appliance/code/weewx driver/whatever remotely. This approach is also interesting when trying to use a SIM board not made for a certain region. A smart little hack and we have a wifi/lora transmitter... OK, there are a few assumptions since I've never tried this, and the OP in the above forum thread never left feedback on success or failure. But I think it's worth a try. On Tuesday, May 28, 2019 at 11:02:44 AM UTC+2, kobuki wrote: > > That might provide a working solution, if the console port indeed dumps > the data packets (I remembered it does, but right now I'm not entirely > sure). If it does, it should RS422 signaling. I'm not sure if it can be > used to wake up your module without losing the first few data bytes of the > 10 for a packet, but if it has uA power modes where it can listen on a > serial port, it might be a viable approach. The data packets are identical > to the ones used by the radio protocol, and there are interpreters for that > in several languages, including C++ for Arduino, python, etc. Maybe the > simplest is to relay the packets to the remote station and let it process > them. > > On Tuesday, May 28, 2019 at 2:45:10 AM UTC+2, John wrote: >> >> Maybe hook up to the console connector then. That would upgrade both my >> active station and perhaps salvage the old one as well. Does the console >> connector provide a buffer for the data stream so that I could just have >> the ULP wake up the ESP32, read out the data buffer, write to the SD, >> transmit, and go back to sleep? >> > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/2707c599-b255-4a17-a485-c714956e911b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2
That might provide a working solution, if the console port indeed dumps the data packets (I remembered it does, but right now I'm not entirely sure). If it does, it should RS422 signaling. I'm not sure if it can be used to wake up your module without losing the first few data bytes of the 10 for a packet, but if it has uA power modes where it can listen on a serial port, it might be a viable approach. The data packets are identical to the ones used by the radio protocol, and there are interpreters for that in several languages, including C++ for Arduino, python, etc. Maybe the simplest is to relay the packets to the remote station and let it process them. On Tuesday, May 28, 2019 at 2:45:10 AM UTC+2, John wrote: > > Maybe hook up to the console connector then. That would upgrade both my > active station and perhaps salvage the old one as well. Does the console > connector provide a buffer for the data stream so that I could just have > the ULP wake up the ESP32, read out the data buffer, write to the SD, > transmit, and go back to sleep? > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8f34e162-c2d3-4cfc-86c5-0c9b5af98729%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2
That's also doable, but a LOT of work. Plus the T/H sensor has a proprietary protocol, so you might need to replace that sensor. Then you still need to write handlers for rain, wind, solar/UV sensors (if installed) as they're not interfaced digitally, and light sensors are analog, require a special pulsing of voltage for operation, etc. If you do it and open source it, that might be useful for others. But then again, a SIM board is $128 if you live in the US... On Tuesday, May 28, 2019 at 1:38:25 AM UTC+2, John wrote: > > I'm kinda assumed the whole ISS board was dead but I didn't really dive > into it at the time. I was thinking along the lines of just hooking up each > of the sensors to the esp32 and use the ULP to aggressively sleep the > wifi/bt between LoRa transmissions. The modules I have came with a SD card > connector so maybe log everything to SD and occasionally wake up the WiFi > via a LoRa command for a drive by download. > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/7149d782-9f20-4f96-9cfe-5522fdc8f38c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2
That's an interesting idea. You might be able to use the console connector present on every SIM board to capture the same packets that are sent out on radio - *if* it's only the original radio that's dead. The only issue is the power consumption of the ESP32. Whatever ULP mode it has, WiFi will always consume orders of magnitude higher than an RFM module. On Sunday, May 26, 2019 at 7:20:36 PM UTC+2, John wrote: > > Thanks for the pointer to the RFM69 discussions. >>> >> > Now I am thinking of a change in strategy and just putting one of the > ESP32+RFM95W dev boards into the ISS and send the data out directly, > alternating between moderate range LoRa <-> LoRa peers and occasionally to > a distant LoRaWAN gateway. The ESP32/LoRa module looks to have a very low > power mode (ULP) suitable for battery / solar operation. I have an dead ISS > that I thought was only good for parts that I may be able to bring back to > life with a new cpu/radio and deploy to the ranch cabin. > > > https://github.com/LilyGO/TTGO-LORA32-V2.0 > > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/00d635fd-742f-4fac-b542-3dc61c5f2c59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2
The radio should be capable on paper, but the RFM9x series is only used for LoRa in the wild. The main problem is that there's no suitable driver for these modules for FSK mode. The RFM69 is cheaper for FSK and there are several FSK/OOK libs to choose from, plus it already has several working implementations for the Davis radio protocol. There's nothing keeping you from writing an implementation and a driver, but I'm not sure it's worth the effort. On Sunday, May 26, 2019 at 1:47:40 AM UTC+2, John wrote: > > I have recently picked up a couple inexpensive ESP32 / LoRa dev boards > with an integrated RFM95W rf module in the 902-928 MHz range. I haven't > delved into the radio capabilities outside of the LoRa modes but perusing > the specs it seems like these might be a candidate for talking to the Davis > Vantage Pro 2 ISS. > > A search for RFM95W in the forum was empty. Has anyone else evaluated > these i2c modules as a way to read the ISS directly with a raspberry pi ? > > The ESP32 core on these dev boards has integrated Wifi and Bluetooth > radios, making them a candidate for bridging the ISS directly to the lan > and wan, or even to a distant LoRaWAN gateway using the RFM95W module. > > > > https://www.digikey.com/en/datasheets/rf-solutions/rf-solutions-rfm95_96_97_98w > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/84e02d11-3d5d-4e2d-9133-ca0d9cc72a7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Suggestions for solar irradiance calculator on arbitrary tilted surface
Thanks for the insight. I've already found pvlib-python, good to know it can be advised to use by professionals, too. I'd be fine using the theoretical max. irradiance, one of my aims is actually pre-drawing an enveloping curve representing the possible max. power output. For real time curves I can use the solar sensor (horizontal irradiance) of my weather station for some additional insight. On Saturday, April 27, 2019 at 4:26:03 AM UTC+2, sam...@gmail.com wrote: > > I work in the PV industry, though I don't have much experience with weewx > yet, and limited experience with python. That said, the calculation you are > looking for is called a "transposition", and you are transposing from GHI > (Global Horizontal Irradiance) from your horizontal sensor to what is > called POA (Plane of Array) irradiance. That may help a bit with your > searching. > > Sandia's PV Array Performance Model is a set of equations that can > describe nearly every part of a PV system's behavior: > https://pvpmc.sandia.gov/modeling-steps/1-weather-design-inputs/plane-of-array-poa-irradiance/ > > It is partially (completely?) implemented in Python in the pvlib library: > https://pvlib-python.readthedocs.io/en/stable/ > > I haven't used the library, though I do use a lot of tools that include > calculations from the Sandia PVAPM. > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Suggestions for solar irradiance calculator on arbitrary tilted surface
Yes, on hot summer days I also see the sensor overshooting the prediction. It could of course be that the sensor drifted from its initial calibration, though the current weather might indicate it's not the case, but rather as you noted, it's some atmospheric effect in certain months/seasons. In WeeWx, you need to add a new observation type, maxSolarRad which you need to append to the database columns and use in the skin config. On Sunday, April 21, 2019 at 7:33:50 PM UTC+2, Greg Troxel wrote: > > kobuki > writes: > > > Yeah, thanks for the insight. I'm aware of the various atmospheric > models. > > I want to find something that has been a) proven useful for solar power > > predictions; b) has a working open source python implementation. While > the > > scientific background is very interesting in itself, I don't intend to > > re-invent the wheel. I do have a fairly good solar and UV sensor for my > VP2 > > weather station. An interesting fact, this spring the solar sensor W/m2 > > curve almost completely overlaps with the built-in solar model > prediction > > (theoretical max. irradiation) in WeeWx, and we do have unobstructed > clear > > sky and sunshine these days. So I'm hoping to do something similar with > my > > solar power system. > > I wasn't aware there was a solar model in weewx. I have on my todo > list to compute the irradiance with a clear sky, and to graph measured > irradiance vs theoretical max. > > I have seen irradiance values higher than what I believe theoretical max > is. On a completely clear day, no, but on days with some clouds. My > assumption -- with no good basis -- is that there is some sort of > lensing as the sun passes the cloud edge and there is a temporary > beyond-max excursion. This is part of why I want to graph the > fraction-of-max. > > > I've found 2 worthy contenders in the subject so far: > > > > https://github.com/pvlib/pvlib-python/ > > https://pypi.org/project/solprimer/ > > > > I need to indulge myself in them a bit to see which might fit my needs > the > > best. I think the first one might be better suited and it's also > actively > > developed, but I just don't know yet. > > Thanks for the links. > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Suggestions for solar irradiance calculator on arbitrary tilted surface
Yeah, thanks for the insight. I'm aware of the various atmospheric models. I want to find something that has been a) proven useful for solar power predictions; b) has a working open source python implementation. While the scientific background is very interesting in itself, I don't intend to re-invent the wheel. I do have a fairly good solar and UV sensor for my VP2 weather station. An interesting fact, this spring the solar sensor W/m2 curve almost completely overlaps with the built-in solar model prediction (theoretical max. irradiation) in WeeWx, and we do have unobstructed clear sky and sunshine these days. So I'm hoping to do something similar with my solar power system. I've found 2 worthy contenders in the subject so far: https://github.com/pvlib/pvlib-python/ https://pypi.org/project/solprimer/ I need to indulge myself in them a bit to see which might fit my needs the best. I think the first one might be better suited and it's also actively developed, but I just don't know yet. On Sunday, April 21, 2019 at 4:56:51 PM UTC+2, Leon Shaner wrote: > > Kobuki, > > My other half (who is an avid physics/astronomy type) points out that > there are two non-obvious factors here, one being "atmospheric extinction" > and the other being "transparency." > > Atmospheric extinction has to do with the fact that the sun's radiation > has to go through more atmosphere at lower inclinations than when it is > directly overhead. A solar radiation detector will already be subject to > atmospheric extinction, in that it will simply read lower when the sun is > closer to the horizon, even on a completely clear day. As an aside, I'd > have to wonder how accurate solar radiation sensors are that don't have > mechanical tracking to keep directly pointed at the sun. :-/ > Seems like that much of this discussion should be "on topic" for this > group. =D > > Transparency, on the other hand is something that acts more like a filter, > and as transparency varies, it has more pronounced effects on certain > wavelengths vs. others. Because solar panels do not react to the entire > visible spectrum, transparency can have an even more dramatic effect on a > panel's efficiency, than just how bright/clear it seems to the human eye. > :-/ > > From that, my takeaway is you probably need to factor in a UV sensor to > account for transparency. > > That forum I quoted would probably be a great place to get more input. > Plenty of PhD types over there. =D > > Good luck! =D > > Regards, > Leon > -- > Leon Shaner :: Dearborn, Michigan (iPad Pro) > > On Apr 21, 2019, at 10:37 AM, Leon Shaner > > wrote: > > Kobuki, > > Ok. Do you already have a solar radiation detector? If you know the solar > radiation, and your fixed geo-location, the position of the sun can be > calculated and the math I mentioned can be used to calculate the efficiency > of your panel across the range of the sun's motion. > Seems like you should be looking for Astronomy-oriented projects which can > track the sun's position from your geo-location. Then the rest of the math > is just the angle of incidence calculations that I mentioned. Sorry I > don't know of any projects that tie this together. > > Here's an interesting lead: > > > https://www.researchgate.net/post/How_can_we_compute_solar_position_at_a_given_place_on_a_given_day_and_time > > Regards, > Leon > -- > Leon Shaner :: Dearborn, Michigan (iPad Pro) > On Apr 21, 2019, at 10:00 AM, kobuki > > wrote: > > Thanks for the quick heads up. To make it clear, I'm not looking for the > math theory behind it, I'm trying to find an existing Python library or > source code that I can integrate or use for writing the service. I want to > track the energy production, we have a fixed setup. I'm not interested in > sun tracking calculation now. > > On Sunday, April 21, 2019 at 3:56:52 PM UTC+2, Leon Shaner wrote: >> >> You can google for "solar panel angle of incidence" and you'll find some >> good articles which explain the math. >> Suffice it to say, it works out that tracking the sun yields about 30% >> more power than the same panel in a fixed position, assuming consistent sun >> throughout the day. >> HTH >> >> Regards, >> Leon >> -- >> Leon Shaner :: Dearborn, Michigan (iPhone) >> >> On Apr 21, 2019, at 9:47 AM, kobuki wrote: >> >> Sorry if it might seem a bit off topic, but since I want to integrate >> this service in WeeWx, too, I thought it's the appropriate place after all. >> I'd like to add a solar
Re: [weewx-user] Suggestions for solar irradiance calculator on arbitrary tilted surface
Thanks for the quick heads up. To make it clear, I'm not looking for the math theory behind it, I'm trying to find an existing Python library or source code that I can integrate or use for writing the service. I want to track the energy production, we have a fixed setup. I'm not interested in sun tracking calculation now. On Sunday, April 21, 2019 at 3:56:52 PM UTC+2, Leon Shaner wrote: > > You can google for "solar panel angle of incidence" and you'll find some > good articles which explain the math. > Suffice it to say, it works out that tracking the sun yields about 30% > more power than the same panel in a fixed position, assuming consistent sun > throughout the day. > HTH > > Regards, > Leon > -- > Leon Shaner :: Dearborn, Michigan (iPhone) > > On Apr 21, 2019, at 9:47 AM, kobuki > > wrote: > > Sorry if it might seem a bit off topic, but since I want to integrate this > service in WeeWx, too, I thought it's the appropriate place after all. I'd > like to add a solar power tracker that gives me the theoretical maximum > output of irradiation on a surface in W/m2 that has an arbitrary tilt and > rotation wrt south/north (depending on the hemisphere). I'm sure this has a > Python solution already, I'm just not familiar enough with the subject to > find it. Ultimately I want to estimate the theoretical max. output of our > solar power system on the roof. For starters, I'd be content with > calculation methods that ignore the inherent losses in the system (cables, > inverter, panel temperature coefficients, etc). > > Does anyone have pointers to start with? > > -- > You received this message because you are subscribed to the Google Groups > "weewx-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to weewx...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Suggestions for solar irradiance calculator on arbitrary tilted surface
Sorry if it might seem a bit off topic, but since I want to integrate this service in WeeWx, too, I thought it's the appropriate place after all. I'd like to add a solar power tracker that gives me the theoretical maximum output of irradiation on a surface in W/m2 that has an arbitrary tilt and rotation wrt south/north (depending on the hemisphere). I'm sure this has a Python solution already, I'm just not familiar enough with the subject to find it. Ultimately I want to estimate the theoretical max. output of our solar power system on the roof. For starters, I'd be content with calculation methods that ignore the inherent losses in the system (cables, inverter, panel temperature coefficients, etc). Does anyone have pointers to start with? -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle Update
Right, but the point is, another driver most likely won't fix it. If it does, please do tell me which. Until then, it's possible to try using a fixed offset to correct the reading and see if it can fix it long term. Such an offset is not unusual with this chip. On Friday, April 19, 2019 at 8:37:33 PM UTC+2, Luc Heijst wrote: > > On Friday, 19 April 2019 15:09:03 UTC-3, kobuki wrote: >> >> Most cheap modules use chips of unknown origin and I've seen variance >> between samples in the past >> > > My Adafruit BMP280 chip wasn't cheap:12.95 euro. I have seen other > 'BMP280' chips priced as low as 3.75 Euro > > Luc > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Receiving Davis Vantage weather data with a RTL-SDR dongle Update
It's most likely not the driver but the sensor itself. The BMP280/BME280 chips are protocol compatible WRT their common command set, there is practically no room for error when reading out values between the 2. Your chip is probably off. Most cheap modules use chips of unknown origin and I've seen variance between samples in the past. I've built literally many dozens of devices using them so I know first hand... They're cheap but you get what you pay for. Mostly they're OK, though. Try a simple offset in weewx.conf, it should be alright. If it's crawling away after a few days providing the offset and with various pressure levels, it has a linearity error -> wastebin. On Friday, April 19, 2019 at 7:35:30 PM UTC+2, Luc Heijst wrote: > > On Tuesday, 16 April 2019 23:21:13 UTC-3, rich T wrote: >> >> Drivers I'm currently using are: >> bme280wx https://gitlab.com/wjcarpenter/bme280wx >> >> Rich, > > I followed the instructions for my BMP280 sensor in your link because > WJCarpenter wrote in the release notes of bme280wx: "This interface seems > to work correctly for a BMP280 as well" > > I did gave it a try and I think WJCarpenter is wrong. The pressure > readings I get from my BMP280 sensor are way higher than my other preasure > readings, see table below. > > Vantage Pro console:1009.23794422608 > Meteostick: 1009.266 > Weather365 Wetterbox: 1010.935 > Rtldavis with BME280wx: 1013.28862385024 > > BTW. The BMP280 module has I2C address 0x77, so I had to change that in > the BME280 setting. > > So, work to do to find a better BMP280 driver. > > Luc > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: US frequencies for rtldavis
Luc wrote: "I told him recently several times: the frequencies in your RFM69 file don't work in rtldavis. They simply are all (very) different from the set I use. *** There is also no constant difference between the two frequency sets as he mentions. *** Note: The original US set in rtldavis is probably derived from the RFM69 set because the differences between these two sets are relatively constant. So far nobody could explain why these RFM69 frequencies don't work here." First, unless I misunderstood something, the statements above marked with *** are contradicting each other. There are ONE and only ONE set of frequencies. The DO work for RFM69-based receivers. If the frequencies there don't work in rtldavis, the error is in the rtldavis code or in the receiver equipment, its offset, etc. The original author didn't verify his code using real transmitters? That's possible, but then we're dealing with a huge uncertainty from the get go. Please see the https://docs.google.com/spreadsheets/d/1SyNKF-ynoYvKEiOfr7CcZSvaKDU49rJLbNvfN0avzbQ/ sheet about the (almost) constant difference between rtldavis and the RFM69 frequencies (rtldavis xxx columns). I think the presence of this relatively constant offset is the offset error in someone's SDR stick (as things look, it might not even be the author's...) If you can, please try to do the visual test in SDR# as I mentioned in the other thread to see if your EU or US transmitters are in the ballpark at all or not. This is in my opinion very important, to at least eyeball a basic confirmation or mistake somewhere. Other notes. Around 90+% pctgod is very good for such a long time! I wouldn't even expect anything more from the SDR solution for a lot of reasons. What is the dimension of your freq. correction graph? Hz of kHz? If it's Hz, then it's basically spot on. However, that -1600 offset is horrendous. Something is going on, indeed. If you need to correct/scan the frequencies and such huge errors are present in reception, it must lie with something else, possibly in the demodulator code. I still stand by the statements about the correct frequencies in the RFM69 code. On Saturday, March 16, 2019 at 9:17:15 PM UTC+1, Luc Heijst wrote: > Hi Rich and Paul, > > Thanks for testing. > > When you look at my answer to kobuki, ALL IN CAPITALS, you must have > thought "qxqxwtr!" > > I know kobuki for a long time and he assisted me with the wind correction > formulas in the weewx-meteostick driver. > > I told him recently several times: the frequencies in your RFM69 file > don't work in rtldavis. They simply are all (very) different from the set I > use. > There is also no constant difference between the two frequency sets as he > mentions. > Note: The original US set in rtldavis is probably derived from the RFM69 > set because the differences between these two sets are relatively constant. > So far nobody could explain why these RFM69 frequencies don't work here. > > I'm used to do my own research and more than once the formulas of the > 'DeKays' and 'Kobukis' appeared not to be correct as I have learned with > the decoding of the raw Davis messages. > > The original rtldavis program had an automatic frequency correction per > channel mechanism build in and also a random start channel. > With these two features the program could 'find' more or less its own > frequency table. > > The problem is, that is only working for one transmitter. I tried to use > the mechanism for three transmitters simultanious and it did more harm than > good, so I have removed completely the correction mechanisme. > The problem the original author had, is that he didn't own any Davis > weather equipment and could not test the program himself. > > So, how now further? I think we are still on the right way with our > practical approach. > > Below the found hop frequencies so far. The yellow marked frequencies are > based upon Rich' test and the blue frequencies on Pauls test. > The white ones in between I have calculated on some assumptions and may be > totally wrong. > > The two graphs below show the pctGood percentage of the three stations > read by rtldavis and the 5-minute frequency errors of the 5 EU channels. > The rtldavis program was used with parameter -fc -1600 (new!) which is an > overal frequency correction for all (5 or 51) channels. > > > > The above graph show the pctGood percentage of the three stations read by > rtldavis. > rtld_totaloveral value > ISS-1my first ISS > WINDmy anemometer station included my solar sensor > LEAF-SOILmy leaf-soil station with 4 sensors (1 soil-temp, 2 > soil
Re: [weewx-user] Complete i18n of reporting templates
Alright, thanks for the answer. This is the current state - is it possible that in the future this might change and we can use custom template variables for i18n for centralized configuration? Changind each and every template by hand is tedious. Though automation is possible... On Saturday, March 16, 2019 at 8:07:51 PM UTC+1, Thomas Keffer wrote: > > See the section *Localization > <http://weewx.com/docs/customizing.htm#localization>* in the Customizing > Guide. > > To answer your specific question, any label that does not use a tag will > have to be changed in the template. Other labels that do use a tag, such as > $obs.label.barometer, are changed in weewx.conf. > > -tk > > On Sat, Mar 16, 2019 at 10:34 AM kobuki > > wrote: > >> I've just upgraded to WeeWx 3.9.1 from 3.7.1. No problems at all, it >> picked up the old config and went on running without a hitch. The new >> default skin is a bit better than the old one, though I'm not using it yet, >> for reasons outlined below. >> >> So, I was happy to see that many labels and metrics are templated and can >> be defined in weewx.conf, but unfortunately not all. I would still need to >> edit the templates by hand to fully translate them to my own language. What >> is the recommended method for that? Is it possible to just add new labels >> and their translations and refer to them like the rest of them available in >> the weewx.conf sample? Like $obs.label.barometer, $obs.label.rain, etc. The >> section headers on the left side of the web page or the Almanac, for >> instance, still need translation. What is the current recommended way to >> translate them? Is it planned to allow a user to define them, or even >> arbitrary labels for use in templates, inside weewx.conf? It would be great >> to have something like $custom.label.xxx at least for a centralized >> definition. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "weewx-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to weewx-user+...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Complete i18n of reporting templates
I've just upgraded to WeeWx 3.9.1 from 3.7.1. No problems at all, it picked up the old config and went on running without a hitch. The new default skin is a bit better than the old one, though I'm not using it yet, for reasons outlined below. So, I was happy to see that many labels and metrics are templated and can be defined in weewx.conf, but unfortunately not all. I would still need to edit the templates by hand to fully translate them to my own language. What is the recommended method for that? Is it possible to just add new labels and their translations and refer to them like the rest of them available in the weewx.conf sample? Like $obs.label.barometer, $obs.label.rain, etc. The section headers on the left side of the web page or the Almanac, for instance, still need translation. What is the current recommended way to translate them? Is it planned to allow a user to define them, or even arbitrary labels for use in templates, inside weewx.conf? It would be great to have something like $custom.label.xxx at least for a centralized definition. -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Cannot add maxSolarRad to schema
That's it! Thanks for the pointer. Installed pyephem via pip and values started to appear in the DB. Also the extended almanach is appearing now on my weewx home page. Thanks again. On Monday, October 29, 2018 at 12:40:52 PM UTC+1, gjr80 wrote: > > Have you installed pyephem <http://weewx.com/docs/setup.htm>? > Irrespective of which algorithm is used weeWX needs to know here the Sun is > to calculate maxSolarRad and for that weeWX needs pyephem. > > Gary > > On Monday, 29 October 2018 21:32:11 UTC+10, kobuki wrote: >> >> I've run it now that we have sunlight (a nice sunny day fwiw): >> >> REC:2018-10-29 12:27:00 CET (1540812420) altimeter: 29.7888279777, >> appTemp: 71.73557034, barometer: 29.7797912689, cloudbase: 2931.0243356, >> dateTime: 1540812420.0, dewpoint: 61.7885389671, ET: 0.000201022314202, >> heatindex: 72.0, humidex: 80.9574895993, inDewpoint: 58.9109361372, >> inHumidity: 65.2041778279, inTemp: 71.204, interval: 1, *maxSolarRad: >> None*, outHumidity: 70.3, outTemp: 72.0, pressure: 29.1458023626, rain: >> 0.0, rainRate: 0.0, txBatteryStatus: 0.0, usUnits: 1, UV: 1.82, >> windBatteryStatus: 0.0, windchill: 72.0, windDir: 132.438871386, windGust: >> 10.0, windGustDir: 165.347826087, windrun: 41.0369442587, windSpeed: 7.5 >> >> It's all none. It's present in all LOOP messages too, all None there too. >> Another calculated field, cloudbase seems to have normal values. One thing >> to note is that I'm not running the latest WeeWx, but I didn't think it's >> important since maxSolarRad has been introduced quite a long time ago. I >> can update it hiwever if needed. >> >> On Monday, October 29, 2018 at 1:45:14 AM UTC+1, Thomas Keffer wrote: >>> >>> The daily summaries are used for the stats --- things like >>> $week.maxSolarRad.max. They are not used for the plots. >>> >>> Did you run weewx from the command line? What values did it show for >>> maxSolarRad? >>> >>> -tk >>> >>> >>> >>> On Sun, Oct 28, 2018 at 10:24 AM kobuki wrote: >>> >>>> Tom, it's exactly what I did. I'm quite well versed with mysql, so >>>> adding the column is not a problem. I've even shown the extract for the >>>> column in my first post! >>>> >>>> So, to sum up: 1. I've added the field to the python schema and also >>>> set its group; 2. added the filed to the software-generated list of >>>> fields; >>>> 3. added the maxSolarRad field to the archive table in mysql (it's >>>> actually >>>> MariaDB, but that's not important now). Yet it still filled my db with >>>> nulls even in daylight. I can't test it any more as it's already too dark. >>>> I will rebuild the daily records when the values start appear in the db. >>>> Unless it's a requirement for it to work at all, in that case I'll do it >>>> right away. >>>> >>>> On Sunday, October 28, 2018 at 6:02:37 PM UTC+1, Thomas Keffer wrote: >>>>> >>>>> Replicating is necessary for sqlite --- it has no mechanism for adding >>>>> a column to a database table. >>>>> >>>>> However, if you are using MySQL, then you can just add a column. Here >>>>> are the instructions <http://www.mysqltutorial.org/mysql-add-column/>. >>>>> >>>>> But, you must still rebuild the daily summaries, because they will not >>>>> be aware of the new type. Use the wee_database tool with the >>>>> --rebuild-daily >>>>> <http://weewx.com/docs/utilities.htm#Action_--rebuild-daily> option >>>>> to do this. >>>>> >>>>> -tk >>>>> >>>>> On Sun, Oct 28, 2018 at 9:45 AM kobuki wrote: >>>>> >>>>>> Thanks for the explanation. I did see the instructions for >>>>>> wee_database but I'm perfectly fine with the current database. I see no >>>>>> point in replicating it - what is the exact reasoning behind it? Isn't >>>>>> it >>>>>> possible to tell WeeWx to use the current db with the modified archive >>>>>> table? The new one should be completely identical to the old one after >>>>>> adding the extra column, after all. It has a lot of data, too. >>>>>> >>>>>> On Sunday, October 28, 2018 at 4:07:02 PM UTC+1, Thoma
Re: [weewx-user] Cannot add maxSolarRad to schema
I've run it now that we have sunlight (a nice sunny day fwiw): REC:2018-10-29 12:27:00 CET (1540812420) altimeter: 29.7888279777, appTemp: 71.73557034, barometer: 29.7797912689, cloudbase: 2931.0243356, dateTime: 1540812420.0, dewpoint: 61.7885389671, ET: 0.000201022314202, heatindex: 72.0, humidex: 80.9574895993, inDewpoint: 58.9109361372, inHumidity: 65.2041778279, inTemp: 71.204, interval: 1, *maxSolarRad: None*, outHumidity: 70.3, outTemp: 72.0, pressure: 29.1458023626, rain: 0.0, rainRate: 0.0, txBatteryStatus: 0.0, usUnits: 1, UV: 1.82, windBatteryStatus: 0.0, windchill: 72.0, windDir: 132.438871386, windGust: 10.0, windGustDir: 165.347826087, windrun: 41.0369442587, windSpeed: 7.5 It's all none. It's present in all LOOP messages too, all None there too. Another calculated field, cloudbase seems to have normal values. One thing to note is that I'm not running the latest WeeWx, but I didn't think it's important since maxSolarRad has been introduced quite a long time ago. I can update it hiwever if needed. On Monday, October 29, 2018 at 1:45:14 AM UTC+1, Thomas Keffer wrote: > > The daily summaries are used for the stats --- things like > $week.maxSolarRad.max. They are not used for the plots. > > Did you run weewx from the command line? What values did it show for > maxSolarRad? > > -tk > > > > On Sun, Oct 28, 2018 at 10:24 AM kobuki > > wrote: > >> Tom, it's exactly what I did. I'm quite well versed with mysql, so adding >> the column is not a problem. I've even shown the extract for the column in >> my first post! >> >> So, to sum up: 1. I've added the field to the python schema and also set >> its group; 2. added the filed to the software-generated list of fields; 3. >> added the maxSolarRad field to the archive table in mysql (it's actually >> MariaDB, but that's not important now). Yet it still filled my db with >> nulls even in daylight. I can't test it any more as it's already too dark. >> I will rebuild the daily records when the values start appear in the db. >> Unless it's a requirement for it to work at all, in that case I'll do it >> right away. >> >> On Sunday, October 28, 2018 at 6:02:37 PM UTC+1, Thomas Keffer wrote: >>> >>> Replicating is necessary for sqlite --- it has no mechanism for adding a >>> column to a database table. >>> >>> However, if you are using MySQL, then you can just add a column. Here >>> are the instructions <http://www.mysqltutorial.org/mysql-add-column/>. >>> >>> But, you must still rebuild the daily summaries, because they will not >>> be aware of the new type. Use the wee_database tool with the >>> --rebuild-daily >>> <http://weewx.com/docs/utilities.htm#Action_--rebuild-daily> option to >>> do this. >>> >>> -tk >>> >>> On Sun, Oct 28, 2018 at 9:45 AM kobuki wrote: >>> >>>> Thanks for the explanation. I did see the instructions for wee_database >>>> but I'm perfectly fine with the current database. I see no point in >>>> replicating it - what is the exact reasoning behind it? Isn't it possible >>>> to tell WeeWx to use the current db with the modified archive table? The >>>> new one should be completely identical to the old one after adding the >>>> extra column, after all. It has a lot of data, too. >>>> >>>> On Sunday, October 28, 2018 at 4:07:02 PM UTC+1, Thomas Keffer wrote: >>>>> >>>>> There are several things that could be going wrong. >>>>> >>>>> First, the schema is used only when the database is first being >>>>> created. After that, the schema is read from the database --- it's not >>>>> enough to just add a new type to schemas.wview.schema. You have to >>>>> rebuild the database with the new type. The utility wee_database can >>>>> do this. It will create a new database with the new schema, then populate >>>>> it with data from the old database. See the section *Add a new type >>>>> to the archive database >>>>> <http://weewx.com/docs/customizing.htm#add_archive_type>* in the >>>>> Customizing Guide. >>>>> >>>>> When you're done, double check that the new database, in fact, >>>>> includes the new type. This can be done by running the mysql utility >>>>> with the command >>>>> >>>>> *describe weewx.archive* >>>>> >&g
Re: [weewx-user] Cannot add maxSolarRad to schema
Tom, it's exactly what I did. I'm quite well versed with mysql, so adding
the column is not a problem. I've even shown the extract for the column in
my first post!
So, to sum up: 1. I've added the field to the python schema and also set
its group; 2. added the filed to the software-generated list of fields; 3.
added the maxSolarRad field to the archive table in mysql (it's actually
MariaDB, but that's not important now). Yet it still filled my db with
nulls even in daylight. I can't test it any more as it's already too dark.
I will rebuild the daily records when the values start appear in the db.
Unless it's a requirement for it to work at all, in that case I'll do it
right away.
On Sunday, October 28, 2018 at 6:02:37 PM UTC+1, Thomas Keffer wrote:
>
> Replicating is necessary for sqlite --- it has no mechanism for adding a
> column to a database table.
>
> However, if you are using MySQL, then you can just add a column. Here are
> the instructions <http://www.mysqltutorial.org/mysql-add-column/>.
>
> But, you must still rebuild the daily summaries, because they will not be
> aware of the new type. Use the wee_database tool with the --rebuild-daily
> <http://weewx.com/docs/utilities.htm#Action_--rebuild-daily> option to do
> this.
>
> -tk
>
> On Sun, Oct 28, 2018 at 9:45 AM kobuki >
> wrote:
>
>> Thanks for the explanation. I did see the instructions for wee_database
>> but I'm perfectly fine with the current database. I see no point in
>> replicating it - what is the exact reasoning behind it? Isn't it possible
>> to tell WeeWx to use the current db with the modified archive table? The
>> new one should be completely identical to the old one after adding the
>> extra column, after all. It has a lot of data, too.
>>
>> On Sunday, October 28, 2018 at 4:07:02 PM UTC+1, Thomas Keffer wrote:
>>>
>>> There are several things that could be going wrong.
>>>
>>> First, the schema is used only when the database is first being created.
>>> After that, the schema is read from the database --- it's not enough to
>>> just add a new type to schemas.wview.schema. You have to rebuild the
>>> database with the new type. The utility wee_database can do this. It
>>> will create a new database with the new schema, then populate it with data
>>> from the old database. See the section *Add a new type to the archive
>>> database <http://weewx.com/docs/customizing.htm#add_archive_type>* in
>>> the Customizing Guide.
>>>
>>> When you're done, double check that the new database, in fact, includes
>>> the new type. This can be done by running the mysql utility with the
>>> command
>>>
>>> *describe weewx.archive*
>>>
>>> Finally, make sure that values of maxSolarRad are non-NULL. You can do
>>> this by running weewxd directly from the command line
>>> <http://weewx.com/docs/usersguide.htm#Running_directly>. Watch the
>>> values as they go by and see if they are None.
>>>
>>> -tk
>>>
>>>
>>> On Sun, Oct 28, 2018 at 5:41 AM kobuki wrote:
>>>
>>>> Hi,
>>>>
>>>> I've added maxSolarRad to my WeeWx in the following way. First, I
>>>> added these lines to the /usr/share/weewx/user/extensions.py file:
>>>>
>>>> import weewx.units
>>>> import schemas.wview
>>>>
>>>> extended_schema = schemas.wview.schema + [('maxSolarRad', 'REAL')]
>>>> weewx.units.obs_group_dict['maxSolarRad'] = 'group_radiation'
>>>>
>>>> Then made changes to /etc/weewx/weewx.conf:
>>>>
>>>> [DataBindings]
>>>> [[wx_binding]]
>>>> database = archive_mysql
>>>> table_name = archive
>>>> manager = weewx.wxmanager.WXDaySummaryManager
>>>> # schema = schemas.wview.schema
>>>> schema = user.extensions.extended_schema
>>>>
>>>> ...
>>>>
>>>> [StdWXCalculate]
>>>> [[Calculations]]
>>>> ...
>>>> maxSolarRad = software
>>>>
>>>> Naturally, I added a new column to the archive table in my weewx mysql
>>>> schema:
>>>>
>>>> `maxSolarRad` double DEFAULT NULL,
>>>>
>>>> Then restarted WeeWx, I see in the logs that maxSolarRad is being
>>>> handled with a certain algorithm, but the maxS
Re: [weewx-user] Cannot add maxSolarRad to schema
Thanks for the explanation. I did see the instructions for wee_database but
I'm perfectly fine with the current database. I see no point in replicating
it - what is the exact reasoning behind it? Isn't it possible to tell WeeWx
to use the current db with the modified archive table? The new one should
be completely identical to the old one after adding the extra column, after
all. It has a lot of data, too.
On Sunday, October 28, 2018 at 4:07:02 PM UTC+1, Thomas Keffer wrote:
>
> There are several things that could be going wrong.
>
> First, the schema is used only when the database is first being created.
> After that, the schema is read from the database --- it's not enough to
> just add a new type to schemas.wview.schema. You have to rebuild the
> database with the new type. The utility wee_database can do this. It will
> create a new database with the new schema, then populate it with data from
> the old database. See the section *Add a new type to the archive database
> <http://weewx.com/docs/customizing.htm#add_archive_type>* in the
> Customizing Guide.
>
> When you're done, double check that the new database, in fact, includes
> the new type. This can be done by running the mysql utility with the
> command
>
> *describe weewx.archive*
>
> Finally, make sure that values of maxSolarRad are non-NULL. You can do
> this by running weewxd directly from the command line
> <http://weewx.com/docs/usersguide.htm#Running_directly>. Watch the values
> as they go by and see if they are None.
>
> -tk
>
>
> On Sun, Oct 28, 2018 at 5:41 AM kobuki >
> wrote:
>
>> Hi,
>>
>> I've added maxSolarRad to my WeeWx in the following way. First, I added
>> these lines to the /usr/share/weewx/user/extensions.py file:
>>
>> import weewx.units
>> import schemas.wview
>>
>> extended_schema = schemas.wview.schema + [('maxSolarRad', 'REAL')]
>> weewx.units.obs_group_dict['maxSolarRad'] = 'group_radiation'
>>
>> Then made changes to /etc/weewx/weewx.conf:
>>
>> [DataBindings]
>> [[wx_binding]]
>> database = archive_mysql
>> table_name = archive
>> manager = weewx.wxmanager.WXDaySummaryManager
>> # schema = schemas.wview.schema
>> schema = user.extensions.extended_schema
>>
>> ...
>>
>> [StdWXCalculate]
>> [[Calculations]]
>> ...
>> maxSolarRad = software
>>
>> Naturally, I added a new column to the archive table in my weewx mysql
>> schema:
>>
>> `maxSolarRad` double DEFAULT NULL,
>>
>> Then restarted WeeWx, I see in the logs that maxSolarRad is being
>> handled with a certain algorithm, but the maxSolarRad column is filled
>> with NULL values in the database.
>>
>> Could anyone explain what I'm missing from the above procedure to make it
>> work? Thanks in advance...
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-user+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Cannot add maxSolarRad to schema
Hi,
I've added maxSolarRad to my WeeWx in the following way. First, I added
these lines to the /usr/share/weewx/user/extensions.py file:
import weewx.units
import schemas.wview
extended_schema = schemas.wview.schema + [('maxSolarRad', 'REAL')]
weewx.units.obs_group_dict['maxSolarRad'] = 'group_radiation'
Then made changes to /etc/weewx/weewx.conf:
[DataBindings]
[[wx_binding]]
database = archive_mysql
table_name = archive
manager = weewx.wxmanager.WXDaySummaryManager
# schema = schemas.wview.schema
schema = user.extensions.extended_schema
...
[StdWXCalculate]
[[Calculations]]
...
maxSolarRad = software
Naturally, I added a new column to the archive table in my weewx mysql
schema:
`maxSolarRad` double DEFAULT NULL,
Then restarted WeeWx, I see in the logs that maxSolarRad is being handled
with a certain algorithm, but the maxSolarRad column is filled with NULL
values in the database.
Could anyone explain what I'm missing from the above procedure to make it
work? Thanks in advance...
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
