[weewx-development] Re: Week and Month plots not being generated?
d for that time span. The generated plot will be stored using # that name, in whatever directory was specified by option 'HTML_ROOT' # in weewx.conf. # # With one final nesting (four brackets!) is the sql type of each line to # be included within that plot. # # Unless overridden, leaf nodes inherit options from their parent # Default plot parameters plot_type = line aggregate_type = none width = 1 time_length = 86400 # 24 hours x_label_spacing = 1 [[day_images]] x_label_format = %H:%M bottom_label_format = %x %X time_length = 97200 # 27 hours aggregate_interval = 300 # every 5 minutes for day plots show_daynight = true [[[daytempdew]]] outTemp [[[daytempfeel]]] windchill [[[daywind]]] windSpeed windGust [[[dayradiation]]] radiation [[[dayradiationD]]] radiationD [[week_images]] x_label_format = %d bottom_label_format = %x %X time_length = 604800 # 7 days aggregate_type = avg aggregate_interval = 7200 # every 2 hours for week plots show_daynight = true [[[weektempdew]]] outTemp [[[weektempfeel]]] windchill [[[weekwind]]] windSpeed windGust aggregate_type = max [[[weekradiation]]] radiation [[[weekradiationD]]] radiationD [[month_images]] x_label_format = %d bottom_label_format = %x %X time_length = 2592000 # 30 days aggregate_type = avg aggregate_interval = 28800 # every 8 hours for month plots show_daynight = false [[[monthtempdew]]] outTemp [[[monthtempfeel]]] windchill [[[monthwind]]] windSpeed windGust aggregate_type = max [[[monthradiation]]] radiation [[[monthradiationD]]] radiationD [[year_images]] x_label_format = %m/%d bottom_label_format = %x %X time_length = 31536000 # 365 days aggregate_type = avg aggregate_interval = 86400 # once a day for year plots show_daynight = false [[[yeartempdew]]] outTemp [[[yeartempfeel]]] windchill [[[yearwind]]] windSpeed windGust aggregate_type = max [[[yearradiation]]] radiation [[[yearradiationD]]] radiationD # Plot of high/low temperatures [[[yearhilow]]] hi data_type = outTemp aggregate_type = max label = High low data_type = outTemp aggregate_type = min label = Low Temperature On Thursday, September 12, 2019 at 12:54:22 AM UTC+2, gjr80 wrote: > > Hi, > > Are you sure the plots are being generated without data? Under some > circumstances plots can be generated with data points only (ie no > connecting lines between the data points) and to a casual observer they can > look like there is not data being plotted at all (especially if there are > only a few data points). Can you post the plots and the entire > [ImageGenerator] stanza from skin.conf. Is your site publicly accessible > via the internet, if so a link would help. > > Gary > > On Thursday, 12 September 2019 08:44:41 UTC+10, Henry Denston wrote: >> >> >> >> On Thursday, September 12, 2019 at 12:41:55 AM UTC+2, Henry Denston wrote: >>> >>> Hi, >>> >>> I'm playing around with a customized weewx version (adapted to a custom >>> weather-station) and ran the framework for the first time on the final >>> system for testing. >>> Everything working great except I noticed that the weekly and montly >>> plots do not include data. >>> I'm using a modified version of the Seasons skin. >>> The daily and yearly plots seem to work great and no weewx error or >>> warning in the log. >>> Only the week and month plot stay empty (only the timestamp of plot >>> generation at the bottom of the respective plot is updated). >>> >>> Can you think of a reason why this might happen? >>> The system runs for two days already so I think the week plot should >>> contain some data by now (even the year plot incl
[weewx-development] Re: Week and Month plots not being generated?
On Thursday, September 12, 2019 at 12:41:55 AM UTC+2, Henry Denston wrote: > > Hi, > > I'm playing around with a customized weewx version (adapted to a custom > weather-station) and ran the framework for the first time on the final > system for testing. > Everything working great except I noticed that the weekly and montly plots > do not include data. > I'm using a modified version of the Seasons skin. > The daily and yearly plots seem to work great and no weewx error or > warning in the log. > Only the week and month plot stay empty (only the timestamp of plot > generation at the bottom of the respective plot is updated). > > Can you think of a reason why this might happen? > The system runs for two days already so I think the week plot should > contain some data by now (even the year plot includes some already)? > In the skin.conf file this is the configuration for one observation type: > > [[week_images]] > x_label_format = %d > bottom_label_format = %x %X > time_length = 604800 # 7 days > aggregate_type = avg > aggregate_interval = 7200 # generate plot every 2 hours for week > plots > show_daynight = true > > [[[weektempdew]]] > outTemp > > Would appreciate any hint, where to start to look for this issue. > Is it possible I still have to wait longer for these plots to be filled > with data? > > Thank you very much in advance, henry. > -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-development+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/3bfb9626-c944-4650-9d5b-effc1c109421%40googlegroups.com.
[weewx-development] Week and Month plots not being generated?
Hi, I'm playing around with a customized weewx version (adapted to a custom weather-station) and ran the framework for the first time on the final system for testing. Everything working great except I noticed that the weekly and montly plots do not include data. I'm using a modified version of the Seasons skin. The daily and yearly plots seem to work great and no weewx error or warning in the log. Only the day and month plot stay empty (only the timestamp of plot generation at the bottom of the respective plot is updated). Can you think of a reason why this might happen? The system runs for two days already so I think the day plot should contain some data by now (even the year plot includes some already)? In the skin.conf file this is the configuration for one observation type: [[week_images]] x_label_format = %d bottom_label_format = %x %X time_length = 604800 # 7 days aggregate_type = avg aggregate_interval = 7200 # generate plot every 2 hours for week plots show_daynight = true [[[weektempdew]]] outTemp Would appreciate any hint, where to start to look for this issue. Is it possible I still have to wait longer for these plots to be filled with data? Thank you very much in advance, henry. -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-development+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/3fbec3e4-ca34-45b8-8c6b-e68619095c59%40googlegroups.com.
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Tom, can you tell me what WeeWX will do in case it gets a package with the same unix timestamp a package already had before? As dateTime is a unique key I'm curious if WeeWX automatically 'filters' the data/packages or if some kind of exception is thrown (that may have an impact on system operation)? Thank you! On Friday, March 22, 2019 at 3:23:35 PM UTC+1, Tom Keffer wrote: > > That's right. > > On Thu, Mar 21, 2019 at 8:55 PM Henry Denston > wrote: > >> Thank you for the clarification tom. >> So I assume there are not going to be more tables added (e.g. for week, >> month etc) but only the daily hi/lows, right? >> >> Regards, henry. >> >> On Friday, March 22, 2019 at 12:45:41 AM UTC+1, Tom Keffer wrote: >>> >>> The daily summaries hold one row per day. >>> >>> Each row is timestamped with the start of the day, *local time*. In >>> your time zone (CET +1, I presume), they are all in the same day, >>> 3-March-2019. >>> >>> If you have only one row in your daily summaries and WeeWX has been >>> running for more than one day, then there is something wrong and we will >>> need to see the logs. >>> >>> -tk >>> >>> On Thu, Mar 21, 2019 at 4:06 PM Henry Denston wrote: >>> >>>> Sorry, in case I create too much spam, but I'm trying to dig deeper >>>> into WeeWx and while I was checking out the database structure I can not >>>> fully understand how the day tables are managed. >>>> I'm using mysql so I checked the weewx/manager.py (the >>>> DaySummaryManager classs) and all mysql.py files. >>>> >>>> The daily tables look like this (e.g for my temperature): >>>> >>>> [image: pic.png] >>>> >>>> >>>> >>>> >>>> >>>> >>>> I first assumed that every observation type (like radiation, >>>> temperature, rain etc.) gets it's own daily table (and that is right). >>>> Then every daily table contained one row for every day the station was >>>> up and running and every row will have a min and max value of that day >>>> (for >>>> the specific observation type). >>>> I could not test the station over a longer period of time so far but to >>>> me it seems that a daily table will always only hold one single row? >>>> I'm confused as as you can see in my picture posted above, the dateTime >>>> is from the day before (02.03.2019) and the min/max timestamps are from >>>> another day, the day after (03.03.2019). >>>> How will weewx get the hi/lo values for every single day in a month for >>>> example if the daily tables only hold one single row? >>>> >>>> It's been a long day so maybe I'm just being dumb right now but I'm >>>> confused and I don't like being confused ;). >>>> I hope someone will be so kind to clear this up for me. >>>> Thank you very much, henry. >>>> >>>> On Sunday, March 3, 2019 at 3:27:31 AM UTC+1, Henry Denston wrote: >>>>> >>>>> I'm using WeeWX on a RPi but there are also many other systems >>>>> running simultaneously. I'm using a single bash script used by rc.local >>>>> file and crontab that checks and manages all systems. Implementing WeeWx >>>>> into my system like that just is a convenient way for me to not 'break' >>>>> my >>>>> system architecture and keeping things simple. >>>>> >>>>> So far I did not encounter issues, so I'm happy :) >>>>> >>>>> Again Tom, thank you very much for this great project and your efforts! >>>>> >>>>> On Saturday, March 2, 2019 at 10:01:45 PM UTC+1, Tom Keffer wrote: >>>>>> >>>>>> The init.d scripts files do more than just start weewx. They also >>>>>> make sure essential services are up and running before attempting the >>>>>> startup. >>>>>> >>>>>> So, let me flip the question around: is there any reason *not* to >>>>>> use the init.d script? Is there something you need to work around that >>>>>> attracts you to putting the start up in the rc.local file? >>>>>> >>>>>> -tk >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Mar 2, 2019 at 11:40 AM wrote: >>>>>> >>>>>>> On Su
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Thank you for the clarification tom. So I assume there are not going to be more tables added (e.g. for week, month etc) but only the daily hi/lows, right? Regards, henry. On Friday, March 22, 2019 at 12:45:41 AM UTC+1, Tom Keffer wrote: > > The daily summaries hold one row per day. > > Each row is timestamped with the start of the day, *local time*. In your > time zone (CET +1, I presume), they are all in the same day, 3-March-2019. > > If you have only one row in your daily summaries and WeeWX has been > running for more than one day, then there is something wrong and we will > need to see the logs. > > -tk > > On Thu, Mar 21, 2019 at 4:06 PM Henry Denston > wrote: > >> Sorry, in case I create too much spam, but I'm trying to dig deeper into >> WeeWx and while I was checking out the database structure I can not fully >> understand how the day tables are managed. >> I'm using mysql so I checked the weewx/manager.py (the DaySummaryManager >> classs) and all mysql.py files. >> >> The daily tables look like this (e.g for my temperature): >> >> [image: pic.png] >> >> >> >> >> >> >> I first assumed that every observation type (like radiation, temperature, >> rain etc.) gets it's own daily table (and that is right). >> Then every daily table contained one row for every day the station was up >> and running and every row will have a min and max value of that day (for >> the specific observation type). >> I could not test the station over a longer period of time so far but to >> me it seems that a daily table will always only hold one single row? >> I'm confused as as you can see in my picture posted above, the dateTime >> is from the day before (02.03.2019) and the min/max timestamps are from >> another day, the day after (03.03.2019). >> How will weewx get the hi/lo values for every single day in a month for >> example if the daily tables only hold one single row? >> >> It's been a long day so maybe I'm just being dumb right now but I'm >> confused and I don't like being confused ;). >> I hope someone will be so kind to clear this up for me. >> Thank you very much, henry. >> >> On Sunday, March 3, 2019 at 3:27:31 AM UTC+1, Henry Denston wrote: >>> >>> I'm using WeeWX on a RPi but there are also many other systems >>> running simultaneously. I'm using a single bash script used by rc.local >>> file and crontab that checks and manages all systems. Implementing WeeWx >>> into my system like that just is a convenient way for me to not 'break' my >>> system architecture and keeping things simple. >>> >>> So far I did not encounter issues, so I'm happy :) >>> >>> Again Tom, thank you very much for this great project and your efforts! >>> >>> On Saturday, March 2, 2019 at 10:01:45 PM UTC+1, Tom Keffer wrote: >>>> >>>> The init.d scripts files do more than just start weewx. They also make >>>> sure essential services are up and running before attempting the startup. >>>> >>>> So, let me flip the question around: is there any reason *not* to use >>>> the init.d script? Is there something you need to work around that >>>> attracts >>>> you to putting the start up in the rc.local file? >>>> >>>> -tk >>>> >>>> >>>> >>>> On Sat, Mar 2, 2019 at 11:40 AM wrote: >>>> >>>>> On Sunday, February 24, 2019 at 11:42:22 AM UTC-8, Henry Denston wrote: >>>>>> >>>>>> Ok, thanks Tim, good advice! :) >>>>>> >>>>>> So basically there is no need to use the file from >>>>>> util/init.d/weewx.debian like the DOCs advice. >>>>>> So there is no downside by not using the instruction from the >>>>>> documentary and just execute the ./bin/weewxd weewx.conf file with >>>>>> the weewx.conf as first parameter from the /etc/rc.local file? >>>>>> >>>>> >>>>> >>>>> The downside is that if you start/stop weewx via some custom >>>>> mechanism, we will have a difficult time helping you for future >>>>> questionsand you will have a difficult time updating weewx to future >>>>> versions (maybe). >>>>> >>>>> >>>>>- If you are running a systemd-based operating system, start weewx >>>>>with a systemd-based startup file >>>>>- If you are running an init.d-based operating system, start weewx >>>>>with an init.d-based startup file >>>>> >>>>> >>>>> But 'technically' weewx does not care how you start it up. You can >>>>> do it any way you want. >>>>> >>>>> >>>>> >>>>
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Ok, thanks Tim, good advice! :) So basically there is no need to use the file from util/init.d/weewx.debian like the DOCs advice. So there is no downside by not using the instruction from the documentary and just execute the ./bin/weewxd weewx.conf file with the weewx.conf as first parameter from the /etc/rc.local file? Did I get that right? Regards, Henry. On Sunday, February 24, 2019 at 8:35:44 PM UTC+1, Tim Urberg wrote: > > One pro to doing it this way is you can watch the LOOP data as it is > coming in. A good way to debug if nothing else. > > On Sunday, February 24, 2019 at 1:28:33 PM UTC-6, Tim Urberg wrote: >> >> One you could use screen, which allows a totally separate screen to be >> running in the background. >> >> https://linuxize.com/post/how-to-use-linux-screen/ >> >> Here's what I have in /etc/rc.local (on a Raspberry Pi): >> >> screen -S weather_station -d -m sh -c 'weewxd /etc/weewx/weewx.conf; exec >> bash' >> >> Then when you log in run: "sudo screen -r" which will re-attach to the >> screen session. Once finished type Ctrl+A and then D to detach. >> >> That's one way to do it. >> >> On 2/24/2019 1:20 PM, Henry Denston wrote: >> >> Thank you. >> >> Another question that I would like to ask: >> >> Is there any downside just adding (executing) the sudo ./bin/weewxd >> weewx.conf script to the /etc/rc.locatl file? >> So my WeeWx installation gets started everytime on startup of my system. >> >> In the Docs this instruction is given: >> >> cd /home/weewx >> sudo cp util/init.d/weewx.debian /etc/init.d/weewx >> sudo chmod +x /etc/init.d/weewx >> sudo update-rc.d weewx defaults 98 >> sudo /etc/init.d/weewx start >> >> >> >> But is there any disadvantage using the method I described above? >> >> >> Thank you, Henry. >> >> On Friday, February 22, 2019 at 6:04:07 AM UTC+1, gjr80 wrote: >>> >>> python-pil is used by the WeeWX image generator to create/manipulate the >>> image file (ie create the image file, draw points, lines, labels etc). The >>> logic for obtaining the data to be plotted, working out what goes where and >>> what colours are used etc are all contained in various WeeWX .py files >>> (imagegenerator.py, weeplot/genplot.py etc). >>> >>> Gary >>> >> >> >> >> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> >> Virus-free. >> www.avg.com >> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> >> >> <#7407f7e0-e639-4a8c-96c3-80a9c576a2f6@googlegroups.com_a5d4dd4a-9976-a276-ea21-69354bce9e61@urberg.net_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Thank you. Another question that I would like to ask: Is there any downside just adding (executing) the sudo ./bin/weewxd weewx.conf script to the /etc/rc.locatl file? So my WeeWx installation gets started everytime on startup of my system. In the Docs this instruction is given: cd /home/weewx sudo cp util/init.d/weewx.debian /etc/init.d/weewx sudo chmod +x /etc/init.d/weewx sudo update-rc.d weewx defaults 98 sudo /etc/init.d/weewx start But is there any disadvantage using the method I described above? Thank you, Henry. On Friday, February 22, 2019 at 6:04:07 AM UTC+1, gjr80 wrote: > > python-pil is used by the WeeWX image generator to create/manipulate the > image file (ie create the image file, draw points, lines, labels etc). The > logic for obtaining the data to be plotted, working out what goes where and > what colours are used etc are all contained in various WeeWX .py files > (imagegenerator.py, weeplot/genplot.py etc). > > Gary >
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Ok, after hours of trial and error I guess the lable 'aggregate_interval' is responsible for my issue. I set it to 60 (so Images/Plots will get copied when older than a minute everytime a record runs). Sorry for the spam. But can you answer me the question if there are limitations regarding the color formatting in the skin.conf? E.g. I can not set the color '0xD17729' in the ImageGenerator Section for the label 'axis_label_font_color'. E.g. 'white' or 'yellow' works great. When I try for example 'axis_label_font_color = 0xD17729' the axis label font color just appears as blue. So are there limits what color codes I can use? Any thoughts? Thank you, Henry. On Thursday, February 21, 2019 at 7:03:04 PM UTC+1, Henry Denston wrote: > > Thank you very much Tom. > > One thing I can not figure out is: > > In the docs it says that everytime an archive period is over (every time a > new record is done) all the newly generated images (plots) get copied into > the public_html folder. > What I noticed for me is that this is not the case. (actually it seems to > be a lot longer until they are updated). > When triggering a report manually using the wee_reports command the same > behavior can be observed. > However, when I delete the .png images (plots) from the public_html folder > the fresh images get copied into the public_html right away when the next > record is done. > Can you tell me how to change this so the newest plot images are always > copied to the public_html folder everytime a new record is done? > I tried to set copy_always flag in the skin.conf in the copy_generator > section but no change. > Also cannot seem to find anything in the docs that can help me. > > Thank you very much, Henry. > > I have no stale_age or cronjob defined for report generation. > > On Wednesday, February 20, 2019 at 2:56:36 PM UTC+1, Tom Keffer wrote: >> >> When a new record arrives, WeeWX tries to write all the types it can into >> the database. If a type is not in the database schema, it is skipped. >> >> If you're interested, the logic is in function manager._addSingleRecord() >> <https://github.com/weewx/weewx/blob/master/bin/weewx/manager.py#L273>. >> >> -tk >> >> On Tue, Feb 19, 2019 at 11:02 PM Henry Denston wrote: >> >>> Tom, in case I would like to create my own database schema, is it enough >>> to just remove the cloumns from the dictionary in this file: >>> .\weewx\bin\schemas\wview.py'' ? >>> Seems like weewx still tries to write to removed database columns when >>> trying to save a record. >>> >>> Would really appreciate it in case you could name at least some files >>> off the cuff that I have to look into. >>> Thanks :) >>> >>> On Friday, February 15, 2019 at 11:23:00 PM UTC+1, Tom Keffer wrote: >>>> >>>> If you're going to all the trouble of creating a custom database >>>> schema, you can certainly make additional changes to suit your needs. Just >>>> be careful not to drop something you'll need for your reports. >>>> >>>> However, you'll find removing unused observation types does not save as >>>> much space as you think. A major part of the database is the index, which >>>> will still be there. >>>> >>>> As far as what's the best practice? I'd say, do what Google does: save >>>> everything. Storage is cheap. >>>> >>>> -tk >>>> >>>> On Fri, Feb 15, 2019 at 11:50 AM Henry Denston wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> thank you very much for your great reply! :) >>>>> I do not have an existing database yet. >>>>> >>>>> I already read the *Adding a new type to the database >>>>> <http://weewx.com/docs/customizing.htm#add_archive_type> *section in >>>>> the Customizing Guide, however was confused as I thought this only >>>>> applies >>>>> in case one wants to add a new observation type that is not present in >>>>> weewx yet (as in the example electricity). >>>>> I wanted to add additional radiation sources (and there is already the >>>>> radiation observation type implemented in weewx), so I thought by using >>>>> an >>>>> already existing observation type I might not need to adjust the database >>>>> structure. >>>>> Your answer however, clearly shows how to make the required changes, >>>>> thank you very much! (Maybe add this little example to the docs, right >
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Thank you very much Tom. One thing I can not figure out is: In the docs it says that everytime an archive period is over (every time a new record is done) all the newly generated images (plots) get copied into the public_html folder. What I noticed for me is that this is not the case. (actually it seems to be a lot longer until they are updated). When triggering a report manually using the wee_reports command the same behavior can be observed. However, when I delete the .png images (plots) from the public_html folder the fresh images get copied into the public_html right away when the next record is done. Can you tell me how to change this so the newest plot images are always copied to the public_html folder everytime a new record is done? I tried to set copy_always flag in the skin.conf in the copy_generator section but no change. Also cannot seem to find anything in the docs that can help me. Thank you very much, Henry. I have no stale_age or cronjob defined for report generation. On Wednesday, February 20, 2019 at 2:56:36 PM UTC+1, Tom Keffer wrote: > > When a new record arrives, WeeWX tries to write all the types it can into > the database. If a type is not in the database schema, it is skipped. > > If you're interested, the logic is in function manager._addSingleRecord() > <https://github.com/weewx/weewx/blob/master/bin/weewx/manager.py#L273>. > > -tk > > On Tue, Feb 19, 2019 at 11:02 PM Henry Denston > wrote: > >> Tom, in case I would like to create my own database schema, is it enough >> to just remove the cloumns from the dictionary in this file: >> .\weewx\bin\schemas\wview.py'' ? >> Seems like weewx still tries to write to removed database columns when >> trying to save a record. >> >> Would really appreciate it in case you could name at least some files off >> the cuff that I have to look into. >> Thanks :) >> >> On Friday, February 15, 2019 at 11:23:00 PM UTC+1, Tom Keffer wrote: >>> >>> If you're going to all the trouble of creating a custom database schema, >>> you can certainly make additional changes to suit your needs. Just be >>> careful not to drop something you'll need for your reports. >>> >>> However, you'll find removing unused observation types does not save as >>> much space as you think. A major part of the database is the index, which >>> will still be there. >>> >>> As far as what's the best practice? I'd say, do what Google does: save >>> everything. Storage is cheap. >>> >>> -tk >>> >>> On Fri, Feb 15, 2019 at 11:50 AM Henry Denston wrote: >>> >>>> Hi Tom, >>>> >>>> thank you very much for your great reply! :) >>>> I do not have an existing database yet. >>>> >>>> I already read the *Adding a new type to the database >>>> <http://weewx.com/docs/customizing.htm#add_archive_type> *section in >>>> the Customizing Guide, however was confused as I thought this only applies >>>> in case one wants to add a new observation type that is not present in >>>> weewx yet (as in the example electricity). >>>> I wanted to add additional radiation sources (and there is already the >>>> radiation observation type implemented in weewx), so I thought by using an >>>> already existing observation type I might not need to adjust the database >>>> structure. >>>> Your answer however, clearly shows how to make the required changes, >>>> thank you very much! (Maybe add this little example to the docs, right >>>> next >>>> to the electricity eample? :)) >>>> >>>> *Another question:* >>>> By using the file user/extensions.py additional sensors can be added >>>> to weewx as you have presented. >>>> Is it best practice to just append additionally required sensors to >>>> the standard weewx database structure or should I (make some additional >>>> changes to) 'rebuild' the used database structure for my system? >>>> For example in case I intend to use only about 8 sensors/values in my >>>> current system (e.g.: dateTime, usUnits, windSpeed, outTemp, radiation, >>>> radiation1, radiation2, radiation3) I could remove all additional values >>>> in >>>> the database that I will not use (e.g. barometer, pressure, altimeter, >>>> inTemp, etc) ? Would love to hear your opinion on that. >>>> >>>> Thank you very much, Henry. >>>> >>>> >>>> On Friday, February 15, 2019 at 7:51:13 PM UTC
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Tom, in case I would like to create my own database schema, is it enough to
just remove the cloumns from the dictionary in this file:
.\weewx\bin\schemas\wview.py'' ?
Seems like weewx still tries to write to removed database columns when
trying to save a record.
Would really appreciate it in case you could name at least some files off
the cuff that I have to look into.
Thanks :)
On Friday, February 15, 2019 at 11:23:00 PM UTC+1, Tom Keffer wrote:
>
> If you're going to all the trouble of creating a custom database schema,
> you can certainly make additional changes to suit your needs. Just be
> careful not to drop something you'll need for your reports.
>
> However, you'll find removing unused observation types does not save as
> much space as you think. A major part of the database is the index, which
> will still be there.
>
> As far as what's the best practice? I'd say, do what Google does: save
> everything. Storage is cheap.
>
> -tk
>
> On Fri, Feb 15, 2019 at 11:50 AM Henry Denston > wrote:
>
>> Hi Tom,
>>
>> thank you very much for your great reply! :)
>> I do not have an existing database yet.
>>
>> I already read the *Adding a new type to the database
>> <http://weewx.com/docs/customizing.htm#add_archive_type> *section in the
>> Customizing Guide, however was confused as I thought this only applies in
>> case one wants to add a new observation type that is not present in weewx
>> yet (as in the example electricity).
>> I wanted to add additional radiation sources (and there is already the
>> radiation observation type implemented in weewx), so I thought by using an
>> already existing observation type I might not need to adjust the database
>> structure.
>> Your answer however, clearly shows how to make the required changes,
>> thank you very much! (Maybe add this little example to the docs, right next
>> to the electricity eample? :))
>>
>> *Another question:*
>> By using the file user/extensions.py additional sensors can be added to
>> weewx as you have presented.
>> Is it best practice to just append additionally required sensors to
>> the standard weewx database structure or should I (make some additional
>> changes to) 'rebuild' the used database structure for my system?
>> For example in case I intend to use only about 8 sensors/values in my
>> current system (e.g.: dateTime, usUnits, windSpeed, outTemp, radiation,
>> radiation1, radiation2, radiation3) I could remove all additional values in
>> the database that I will not use (e.g. barometer, pressure, altimeter,
>> inTemp, etc) ? Would love to hear your opinion on that.
>>
>> Thank you very much, Henry.
>>
>>
>> On Friday, February 15, 2019 at 7:51:13 PM UTC+1, Tom Keffer wrote:
>>>
>>> Yes, your strategy would work, and your names (radiation1, radiation2,
>>> and radiation3) are sensible names to give the extra sensors.
>>>
>>> You would have to change the database schema to accommodate the extra
>>> sensors.
>>>
>>> Do you have an existing database, to which you want to add the new
>>> observation types? If so, then follow the instructions in the Customizing
>>> Guide, section *Adding a new type to the database
>>> <http://weewx.com/docs/customizing.htm#add_archive_type>*. If there is
>>> something that is confusing about the instructions, let us know what the
>>> problem is so we can clarify and, perhaps, update the documents and make it
>>> clearer.
>>>
>>> If you do not have an existing database, then it is slightly easier. To
>>> the bottom of the file user/extensions.py, add the following:
>>>
>>> import schemas.wview
>>> radiation_schema = schemas.wview.schema + [
>>> ('radiation1'', 'REAL'),
>>> ('radiation2'', 'REAL'),
>>> ('radiation3'', 'REAL'),
>>> ]
>>>
>>> Then go into your weewx.conf and change the [DataBindings] and
>>> [Databases] section so they look like this:
>>>
>>> [DataBindings]
>>>
>>> [[wx_binding]]
>>> # The database must match one of the sections in [Databases].
>>> # This is likely to be the only option you would want to change.
>>> database = archive_sqlite
>>> # The name of the table within the database
>>> table_name = archive
>>> # The manager handles aggregation of data for historical summaries
>>> manager = weewx.wxmanager.WXDaySummaryManager
>>> # The schema defines the str
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Got it, thank you.
I'm testing my driver right now and I noticed some strange behavior.
*My driver works like this:*
It queries an external MySQL database and selects all datasets (rows, and
one row contains a timestamp, the value of sensor1, sensor2 etc.) that have
not been processed by WeeWx yet.
The driver yields data once every 5 minutes. Everytime the driver runs, it
has to yield about 60 packets.
*My question:*
Is this too much for WeeWx to handle?
Yielding about 60 data packets at once in a loop in the *genLoopPackets(self)
*method?
I'm asking because when I run WeeWx (using: sudo ./bin/weewxd weewx.conf),
only about 16 LOOP messages appear in the console window while I'm
expecting about 60.
Hope you can point me into the right direction again, thank you very much!
:)
Kind regards, Henry.
On Friday, February 15, 2019 at 11:23:00 PM UTC+1, Tom Keffer wrote:
>
> If you're going to all the trouble of creating a custom database schema,
> you can certainly make additional changes to suit your needs. Just be
> careful not to drop something you'll need for your reports.
>
> However, you'll find removing unused observation types does not save as
> much space as you think. A major part of the database is the index, which
> will still be there.
>
> As far as what's the best practice? I'd say, do what Google does: save
> everything. Storage is cheap.
>
> -tk
>
> On Fri, Feb 15, 2019 at 11:50 AM Henry Denston > wrote:
>
>> Hi Tom,
>>
>> thank you very much for your great reply! :)
>> I do not have an existing database yet.
>>
>> I already read the *Adding a new type to the database
>> <http://weewx.com/docs/customizing.htm#add_archive_type> *section in the
>> Customizing Guide, however was confused as I thought this only applies in
>> case one wants to add a new observation type that is not present in weewx
>> yet (as in the example electricity).
>> I wanted to add additional radiation sources (and there is already the
>> radiation observation type implemented in weewx), so I thought by using an
>> already existing observation type I might not need to adjust the database
>> structure.
>> Your answer however, clearly shows how to make the required changes,
>> thank you very much! (Maybe add this little example to the docs, right next
>> to the electricity eample? :))
>>
>> *Another question:*
>> By using the file user/extensions.py additional sensors can be added to
>> weewx as you have presented.
>> Is it best practice to just append additionally required sensors to
>> the standard weewx database structure or should I (make some additional
>> changes to) 'rebuild' the used database structure for my system?
>> For example in case I intend to use only about 8 sensors/values in my
>> current system (e.g.: dateTime, usUnits, windSpeed, outTemp, radiation,
>> radiation1, radiation2, radiation3) I could remove all additional values in
>> the database that I will not use (e.g. barometer, pressure, altimeter,
>> inTemp, etc) ? Would love to hear your opinion on that.
>>
>> Thank you very much, Henry.
>>
>>
>> On Friday, February 15, 2019 at 7:51:13 PM UTC+1, Tom Keffer wrote:
>>>
>>> Yes, your strategy would work, and your names (radiation1, radiation2,
>>> and radiation3) are sensible names to give the extra sensors.
>>>
>>> You would have to change the database schema to accommodate the extra
>>> sensors.
>>>
>>> Do you have an existing database, to which you want to add the new
>>> observation types? If so, then follow the instructions in the Customizing
>>> Guide, section *Adding a new type to the database
>>> <http://weewx.com/docs/customizing.htm#add_archive_type>*. If there is
>>> something that is confusing about the instructions, let us know what the
>>> problem is so we can clarify and, perhaps, update the documents and make it
>>> clearer.
>>>
>>> If you do not have an existing database, then it is slightly easier. To
>>> the bottom of the file user/extensions.py, add the following:
>>>
>>> import schemas.wview
>>> radiation_schema = schemas.wview.schema + [
>>> ('radiation1'', 'REAL'),
>>> ('radiation2'', 'REAL'),
>>> ('radiation3'', 'REAL'),
>>> ]
>>>
>>> Then go into your weewx.conf and change the [DataBindings] and
>>> [Databases] section so they look like this:
>>>
>>> [DataBindings]
>>>
>>> [[wx_binding]]
>>> # The database must match o
Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Hi Tom,
thank you very much for your great reply! :)
I do not have an existing database yet.
I already read the *Adding a new type to the database
<http://weewx.com/docs/customizing.htm#add_archive_type> *section in the
Customizing Guide, however was confused as I thought this only applies in
case one wants to add a new observation type that is not present in weewx
yet (as in the example electricity).
I wanted to add additional radiation sources (and there is already the
radiation observation type implemented in weewx), so I thought by using an
already existing observation type I might not need to adjust the database
structure.
Your answer however, clearly shows how to make the required changes, thank
you very much! (Maybe add this little example to the docs, right next to
the electricity eample? :))
*Another question:*
By using the file user/extensions.py additional sensors can be added to
weewx as you have presented.
Is it best practice to just append additionally required sensors to
the standard weewx database structure or should I (make some additional
changes to) 'rebuild' the used database structure for my system?
For example in case I intend to use only about 8 sensors/values in my
current system (e.g.: dateTime, usUnits, windSpeed, outTemp, radiation,
radiation1, radiation2, radiation3) I could remove all additional values in
the database that I will not use (e.g. barometer, pressure, altimeter,
inTemp, etc) ? Would love to hear your opinion on that.
Thank you very much, Henry.
On Friday, February 15, 2019 at 7:51:13 PM UTC+1, Tom Keffer wrote:
>
> Yes, your strategy would work, and your names (radiation1, radiation2,
> and radiation3) are sensible names to give the extra sensors.
>
> You would have to change the database schema to accommodate the extra
> sensors.
>
> Do you have an existing database, to which you want to add the new
> observation types? If so, then follow the instructions in the Customizing
> Guide, section *Adding a new type to the database
> <http://weewx.com/docs/customizing.htm#add_archive_type>*. If there is
> something that is confusing about the instructions, let us know what the
> problem is so we can clarify and, perhaps, update the documents and make it
> clearer.
>
> If you do not have an existing database, then it is slightly easier. To
> the bottom of the file user/extensions.py, add the following:
>
> import schemas.wview
> radiation_schema = schemas.wview.schema + [
> ('radiation1'', 'REAL'),
> ('radiation2'', 'REAL'),
> ('radiation3'', 'REAL'),
> ]
>
> Then go into your weewx.conf and change the [DataBindings] and [Databases]
> section so they look like this:
>
> [DataBindings]
>
> [[wx_binding]]
> # The database must match one of the sections in [Databases].
> # This is likely to be the only option you would want to change.
> database = archive_sqlite
> # The name of the table within the database
> table_name = archive
> # The manager handles aggregation of data for historical summaries
> manager = weewx.wxmanager.WXDaySummaryManager
> # The schema defines the structure of the database.
> # It is *only* used when the database is created.
> schema = user.extensions.radiation_schema
>
> ##
>
> # This section defines various databases.
>
> [Databases]
>
> # A SQLite database is simply a single file
> [[archive_sqlite]]
> database_name = radiation.sdb
> database_type = SQLite
>
> # MySQL
> [[archive_mysql]]
> database_name = weewx
> database_type = MySQL
>
> Restart WeeWX.
>
> WeeWX will now use the new database radiation.sdb, which will have the
> new SQL columns.
>
> -tk
>
>
>
> On Fri, Feb 15, 2019 at 8:51 AM Henry Denston > wrote:
>
>> Hello everyone!
>>
>> I'm currently developing a custom weather station (a microcontroller
>> collecting data from custom sensors and forwarding it to a RaspberryPi).
>> I already read the customization guide multiple times and started to
>> develop a custom weewx-driver for my custom weather station.
>> The customization guide offers some very valuable insights. However, I
>> still have some questions and misunderstandings I guess, so I hope some
>> experienced users/developers can help me out. :)
>>
>> As already stated I started developing my own driver, I also edited the
>> weewx.conf and my custom driver is loaded when I start weewx with: sudo
>> ./bin/weewxd weewx.conf (it yields/prints packets)
>> I checked the sql table structures in the documentat
[weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)
Hello everyone! I'm currently developing a custom weather station (a microcontroller collecting data from custom sensors and forwarding it to a RaspberryPi). I already read the customization guide multiple times and started to develop a custom weewx-driver for my custom weather station. The customization guide offers some very valuable insights. However, I still have some questions and misunderstandings I guess, so I hope some experienced users/developers can help me out. :) As already stated I started developing my own driver, I also edited the weewx.conf and my custom driver is loaded when I start weewx with: sudo ./bin/weewxd weewx.conf (it yields/prints packets) I checked the sql table structures in the documentation and now I'm not sure how to save my custom sensors values. For example: I have a windsensor (measuring windspeed only), a temperature sensor and 4 pyranometer sensors of different kind measuring the sun irradiation. Now in my custon driver I know that I can store/assign the windspeed and temperature like this for example: data = dict() data['dateTime'] = int(data_array[0]) # unix timestamp data['usUnits'] = weewx.METRIC data['windSpeed'] = float(data_array[1]) # Anemometer measuring windspeed only data['outTemp'] = float(data_array[0]) # PT100 measuring temperature outside yield data So this should be straight forward if I understand correctly. But how do I store my irradiation values from the various pyranomerters? It seems that in the expected database structure there is only one column for irradiation available. How can I store it so WeeWx can use it in its reports and archives? I have smth. like this in mind: data['radiation'] = float(dataset_array_sensor[2]) # pyranometer 1 data['radiation1'] = float(dataset_array_sensor[3]) # pyranometer 2 data['radiation2'] = float(dataset_array_sensor[4]) # pyranometer 3 data['radiation3'] = float(dataset_array_sensor[5]) # pyranometer 4 Would this work? Do I have to change the sql database structure for it to work? (I plan to use sqlite for it as its easier to use it out of the box) If so, how would I do it? I did read the customization guide multiple times but I'm really confused regarding this. I hope you can give me a hint into the right direction (I think I'm probably way overthinking this and just missing a small detail) Thank you very much in advance! :) Best regards, Henry.
