Humidex instead of Heat Index

[Ron Gibson]

Hi Folks,

Does anyone have a fix /mod so I can display the Canadian version of Humidex instead if the US Heat Index?

Thanks,

Ron

VE3CGR

[gjr80]

Hi Ron,

When you refer to 'the Canadian version of humidex' I presume you just mean 'humidex', I was not aware of any other versions of humidex.

In terms of displaying humidex, what you need do really depends on what you want to do (display the current value or aggregates on a web page, plot historical data or display on the SteelSeries Gauges) and what type of station you have. Provided your station provides both outTemp and outHumidity in the same loop packet or archive record, a default weeWX install will calculate and include a humidex field in the loop packet and archive record. In such cases the current humidex value can be displayed in a weeWX generated web page. In a default weeWX install humidex may well be calculated but it is not stored in the weeWX database. To include humidex aggregate data in a web page or to plot humidex data, humidex must be saved to the weeWX database. On the off chance you are referring to the SteelSeries Gauges, as long as you have the gauges installed and working and your station provides both outTemp and outHumidity in the same loop packet or archive record it should simply be a case of selecting the humidex radio button on the combined gauge to display humidex.

You can see if weeWX is calculating humidex for loop packets and archive records by running weeWX directly (http://weewx.com/docs/usersguide.htm#Running_directly). When you run weeWX directly you will see loop packets and archive records displayed on screen. Lines starting with LOOP are the loop packets and lines starting with REC are the archive records. If weeWX is calculating humidex you should see a field 'humidex' in each packet/record.

Provided weeWX calculates humidex you can display the current humidex on a web page using the $current.humidex tag. If for example you want to display humidex in place of heat index on the 'main' weeWX generated web page, index.html, then you need to edit the skins/Standard/index.html.tmpl file. Locate the heat index tag, $current.heatindex, and replace it with $current.humidex. You will also probably want to change the corresponding label, just find the text 'Heat Index' on the line above and replace with 'Humidex'. Save the file and index.html should update on the next report cycle.

The process is a little more complex if you want to display humidex aggregates or plot humidex. In this case you will need to have weeWX store humidex to database. The procedure is straight forward but involves manipulating some files, what you need to do is add a field 'humidex' to the database using the procedure in the 'Add a new type to the archive database' section of the Customization Guide (http://weewx.com/docs/customizing.htm#add_archive_type). Once weeWX is storing humidex to database you can then use tags such as $month.humidex.max to display the max humidex value for the month to date. In terms of modifying the existing weeWX generated pages to display humidex in place of heat index just modify index.html.tmpl, week.html.tmpl, month.html.tmpl and year.html.tmpl (in directory skins/Standard) replacing $xxxx.heatindex.yyyy tags with $xxxx.humidex.yyyy. You will also need to replace the corresponding labels.

To plot humidex in place of heat index you need to edit skins/Standard/skin.conf, locate the [ImageGenerator] stanza and replace any occurrences of [[[[heatindex]]]] with [[[[humidex]]]] (you might also want to remove the correspondingly [[[[windchill]]]] entries - plotting wind chill and heat index on the same plot makes sense but plotting humidex and wind chill on the same plot may appear a bit odd). Once finished save skin.conf and the current day plots should update on the next report cycle. The other plots may take longer to regenerate, you can force them to be generated by deleting image files in public_html.

Gary

[Ron Gibson]

Hi Gary,

Many thanks! I had no idea that both the heatindex and humidex were in the LOOP data until you explained how to see the data flow. I now have the Humidex displayed on the main page and will proceed to work on the plots.

Ron

[Ron Gibson]

I will say that the 'Add a new type to the archive database' section is quite confusing for me. 

[Andrew Milner]

can you be more specific as to where it becomes confusing?

[Ron Gibson]

Hi Andrew,
The instructions are not clear to me. I need a bit of help adding the humidex type to the database.
Thanks,
Ron

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/W_Eg07xAfPI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Milner]

I just took a look and have to agree it is totally unclear how you just add an entry to an existing schema.  Which file do you put the include into for example??  I could not get beyond step 1 for trying to include humidex!!  It seemed to read and make more sense when the source was another source entirely eg electricity.

But like you, I am also baffled and not sure how you do it!!!!!

[Ron Gibson]

Thanks Andrew, I don't feel as bad now. Hopefully someone with better in-depth weewx knowledge will chime in.

[Andrew Milner]

I hope so

Hopefully Tom, Gary, Vince or Matthew will chime in …… unless we're both just being particularly dense of course!!!!!!

[gjr80]

Ron,

Those instructions are very specific to the case where the user is adding a separate module to create a new field rather than your case where you just want to extend the schema, my apologies, I should have read them in their entirety first. You should be fine following those instructions but using the file user/extensions.py rather than user/electricity.py. user/extensions.py should already exist and probably only has some comments and code to set the locale, just add the additional code at the end.

There is certainly more info in various post sources in the forums but I think this case is something that should be better covered in the guides. I will add it to the list.

Gary

[Ron Gibson]

Hi Gary,
Can you give a hint as to what the additional should be? Will this
extent the DB?
Ron

[vince]

On Monday, July 2, 2018 at 2:09:46 PM UTC-7, Ron Gibson wrote:

Hi Gary,
Can you give a hint as to what the additional should be? Will this
extent the DB?
Ron

It's been several years since I did this, but given that humidex is in the LOOP stuff, I *think* you just need to add it to the archive schema. as mentioned in http://weewx.com/docs/customizing.htm#add_archive_type

DISCLAIMER - THIS IS TOTALLY 'UN'-TESTED.....

Create a new file myschema.py that adds to the schema:

import schemas.wview

schema_with_humidex = schemas.wview.schema + [('humidex', 'REAL')]

Update wx_binding re: the same section in the doc, so weewx uses the new modified schema:

[DataBindings]

   [[wx_binding]]

       database = archive_sqlite

       table_name = archive

       manager = weewx.wxmanager.WXDaySummaryManager

       schema = user.myschema.schema_with_himidex

Update your new db to use the new schema using wee_database (in the link above), and rebuild your daily summaries per the customizing.html guide.

That said, I never extend the weewx schema as of v3 supporting multiple databases.   I've found that putting stuff in a separate db, even if it's just an archive with entries that are dateTime and humdex, makes me somehow feel better that I won't mess up the whole thing.  So to me extending the weewx db schema is kind of superseded by 'adding a new custom db' for anything I've done since v3 came out.   But the stuff above matches my very hazy recollection of how to add stuff to the weewx db schema.

(again - totally untested, but I hope the example helps you wade through the docs easier)

FWIW, I'd strongly suggest you try this in a standalone VM or something running the Simulator rather than on a system with data you care about.   I have vagrant files on my github page (link) for how to spin up weewx in a VirtualBox VM very easily if you wanted to try that rather than risking your production system while experimenting...

[vince]

On Monday, July 2, 2018 at 2:42:37 PM UTC-7, vince wrote:

It's been several years since I did this, but given that humidex is in the LOOP stuff, I *think* you just need to ...

 

update - procedure I posted tested ok - it 'did' add humidex to my database and create the summary tables etc. for the newly created field...

• I put the new 'myschema.py' file in bin/user
  
• I stopped weewx before messing with the database of course, then restarted after rebuilding daily at the end of the process
• lastly, I had a typo on the schema line, it would be "schema = user.myschema.schema_with_humidex"

[gjr80]

On Tuesday, 3 July 2018 07:42:37 UTC+10, vince wrote:

That said, I never extend the weewx schema as of v3 supporting multiple databases.   I've found that putting stuff in a separate db, even if it's just an archive with entries that are dateTime and humdex, makes me somehow feel better that I won't mess up the whole thing.  So to me extending the weewx db schema is kind of superseded by 'adding a new custom db' for anything I've done since v3 came out.   But the stuff above matches my very hazy recollection of how to add stuff to the weewx db schema.

I too use separate databases but only because I have multiple other fields that I wish to store and it was a small step to add the necessary code to support a 2nd and 3rd database. I still think there is a place for extending the stock database and simply adding humidex is a good use case. The additional data (humidex) is already available, extending the database (as opposed to re-using an existing field) does not break any database compatibility and the additional lines of code added to extensions.py are weeWX upgrade proof. On top of that we are talking about 2 lines of code compared with significantly more to implement a StdArchive like service to support an additional database. One thing I have learnt (many times) since contributing to weeWX is that the simple is usually preferred to the complex.

Not disagreeing with anything you said Vince, but just want to point out I think there are valid cases where extending the database is appropriate.

Gary

[Andrew Milner]

…. I would even go so far as to say that

"If it is in the LOOP data packet then it should automatically be included in the database" - or at least there should be a simple option or true/false or yes/no somewhere in weewx for defining which LOOP and REC fields should be incorporated into the database schema.  (Unless humidex is the only one missing!!)

[gjr80]

Starts to get a bit messy when different drivers emit different 'things' in loop packets, somewhere you will need to define a schema based on what is emitted in packets/records and then you need manipulate a database. To do that with a single yes/no config option is going to be complex, to do it with one config option per field, well you might as well add a few lines to extensions.py.... The decision was made when weeWX was first written to maintain a database (well archive table) that was identical to that used by wview, and I guess that has been the crux of keeping the archive table as it is. One might argue that adding an existing packet/record obs is as simple as 2 lines of code plus a few wee_database incantations, and you can forget about the wee_database incantations if you are starting with a new database.

Gary

[Andrew Milner]

good point I guess - it was just a thought, though I still feel that if the driver outputs the field the database should, by default, handle it.  How this is achieved is another matter entirely, and wview compatability should, in 2018, be a by-product of weewx's flexibility rather than the driving force.

Anyways - am not arguing, just suggesting.....

Have a nice day.

[Ron Gibson]

Thanks Vince,
I put the 'myschema.py' in '/usr/bin', stopped weewx and backed up the DB, changed the schema line in weewx.conf.

When I run 'wee_database /etc/weewx/weewx.conf --reconfigure' it errors 'ImportError: No module named myschema'.

Ron

[Andrew Milner]

mysxchema.py should be in /bin/user of weewx and not /usr/bin which you said you used

[Ron Gibson]

Ok, I created a /bin/user and moved the file there. Same error.

[Ron Gibson]

Yep, clear as mud. The correct location turned out to be '/usr/share/weewx/user'.

Now on to the plots.....

On 7/3/2018 8:57 AM, Andrew Milner wrote:

[vince]

On Tuesday, July 3, 2018 at 8:27:23 AM UTC-7, Ron Gibson wrote:

Yep, clear as mud. The correct location turned out to be '/usr/share/weewx/user'.

The location differs based on whether you used setup.py or the pre-packaged version of weewx.

Documented in http://www.weewx.com/docs/usersguide.htm#Where_to_find_things for many years....

 

[mwall]

On Tuesday, July 3, 2018 at 3:31:23 AM UTC-4, Andrew Milner wrote:

good point I guess - it was just a thought, though I still feel that if the driver outputs the field the database should, by default, handle it.  How this is achieved is another matter entirely, and wview compatability should, in 2018, be a by-product of weewx's flexibility rather than the driving force.

fwiw, there is a weewx branch that is our prototype for dealing with this.  the intent is to introduce a new 'wview-extended' schema, which is a backwards-compatible extension of the 'wview' schema.  the new schema has many more fields that cover most of the observations available in a wider range of hardware, not just the davis hardware.

see the branch for details:

https://github.com/weewx/weewx/tree/schema

the wview-extended schema file is the only difference:

https://github.com/weewx/weewx/blob/schema/bin/schemas/wview-extended.py

but to make this part of weewx we would have to add some documentation and test the expected use cases (upgrades, importing from wview, etc)

m 

[David Beach]

With the weather reports and forecasts using Humidex here in Canada, it is nice to have the weeWX 'local server' page report Humidex rather than Heat Index. However, I'm pretty much a 'know nothing' generally about Linux/Raspian and Python. I followed the instructions from Gary and it works great! And now the local page (I use nginx on my RPi) has Humidex instead of Heat Index. If you're in Canada, consider giving this a shot. Not too hard at all.

Thanks for the 'how to.'

David

On Monday, 2 July 2018 01:57:18 UTC-4, gjr80 wrote: