For those who are curious, yes, another video will be coming, with all the errata, addendums, etc, that I had bumped into while developing the Weather Plugin.

I can't record it yet, because I have not had an opportunity to do so. My wife is in mother mode, and has permanently camped herself in the living room, which is adjacent to the kitchen, which is adjacent to the den, where I work; there are no doors in between, so everything bleeds through. I do not have a studio, like I once had to do the voiceovers, so I am having to wait until the house is quiet enough, and there isn't a risk of a baby waking up, so I can do the next video.

Until then, the Weather Plugin has been checked into the repository, the events it intercepts are considered frozen, as are the various variable names it expects, so this can be used by others to create a weather device to populate the weather plugin.

You can see an example of how to use MessageSend to emit the appropriate events inside the source tree:

If somebody wants to take a stab at implementing the Weather c++ device, then go for it.

-Thom

p.s. yes, the Value parameters are full integers. I see NO point in decimal points for weather values, none. If someone can convince me of a valid reason to use floating point values, I will change this.

p.p.s. in the weather-test.sh, yes the event passed is event 91, which is a outside temperature change. This should be changed on each line for each relevant piece of data, (temperature for temperature events, humidity for humidity events etc..) this works because (1) the weather events ALL use the same parameters, and (2) all of the weather data goes into the same map, but for the sake of properly intercepting events, please use the correct PK_Event numbers.

p.s. yes, the Value parameters are full integers. I see NO point in decimal points for weather values, none. If someone can convince me of a valid reason to use floating point values, I will change this.

Thom,

I've been mulling this over for a bit. Something to consider is that some other sources of weather/temperature data return floating point data (WeatherBug, Environment Canada, Davis/Oregon weather stations, thermostat API's, 1-Wire, etc). To take the weather plugin to the next level, we'll need to do something with that data. That usually means doing comparisons...

If $outside_temp < $inside_temp and $outside_temp > 0 then Disable A/C unit enable external air baffle and whole house fanEnd

So, if the weather plugin uses integers, all other drivers will have to do type conversions. Fahrenheit to Celcius conversions (and vice versa) would also need to be rounded to the nearest integer. So, that may complicate all the drivers that have to interact with the weather plugin.

The Weather Plugin does not know or understand that there are weather devices out there, nor that it even cares.

I saw no reason whatsoever to futz over a point degree difference, when it comes to the outside weather, because depending on where you are outside, this can fluctuate a lot. It simply does not matter.

The different weather APIs return textual data as strings. WE HAVE TO DO A TYPE CONVERSION, ANYWAY as part of the parsing process. (This is something that all you guys who write scripting languages all day, don't have to deal with, with your language magically converting everything).

The REASON that the integer values are here anyway, is precisely for the case you outline below, it's so that you can match things in event criteria. The weather plugin expects BOTH the integer values and the textual values to be returned as part of the event.

As for F to C conversions, this is something that is being decided, e.g. to put the F/C in device data, and have the weather devices read this (The weather plugin does not care, it's just a cubby hole), it's up to the weather devices to do the necessary conversions.

The different weather APIs return textual data as strings. WE HAVE TO DO A TYPE CONVERSION, ANYWAY as part of the parsing process. (This is something that all you guys who write scripting languages all day, don't have to deal with, with your language magically converting everything).

The REASON that the integer values are here anyway, is precisely for the case you outline below, it's so that you can match things in event criteria. The weather plugin expects BOTH the integer values and the textual values to be returned as part of the event.

As for F to C conversions, this is something that is being decided, e.g. to put the F/C in device data, and have the weather devices read this (The weather plugin does not care, it's just a cubby hole), it's up to the weather devices to do the necessary conversions.

Fair enough... I'll kick the tires on it when I get the ISY driver out in the wild. My plans are to get the CT-80 driver out in the next couple of weeks, the first cut ISY driver out in late September/early October, and then upgrade to 12.04 to work on a bunch of things, including integrating with the weather plugin for the ISY driver and the CT-80.

Thanks for the excellent summary on how the plugin works. It'll give me a lot to think about over the next little while.

Portions of the weather plugin were missing from the binary releases up until about 8 weeks ago. Some changes may have occurred during that addition. All missing graphics should now be available and all items *should* update based on Thom's initial test script.

I couldn't get your test script to work at all.could I get your help making one for weather.com based

This is not my script but I did try it out and made some improvements to it as it did not work for me as listed. First, if you aren't running the script from /var/www/lmce-admin directory, you will need to change the required file path to find the included file. Also, if your city name has a space in it, like my city does and many others (i.e. San Antonoio, Las Vegas, etc.) you will need to urlencode the city name returned from the database query or the script fails.