Class: Weather

[Dean Roddey]

General Description

This thread is for discussion of the Weather device class. This class defines a basic set of fields that any weather source should be able to provide, not a local weather station but an online weather source.  It includes current condition information, plus forecast information for at least a small number of days (which a local station wouldn't provide.)

Any given source might conceivably support many more data values, but this device class must stick to what is likely to be widely supported, so that it can be used generically.

Fields Provided
The fields provided by this device class have pre-determined names, and these MUST be implemented as indicated here. They are all prefixed by the device class prefix in the form:

WEATH#fieldname

where WEATH# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. There will never be multi-unit considerations for this type of device class.

Most such sources will either allow the user to indicate standard vs. metric units for any units that have those options, or will inherently support one or the other based on non-CQC configuration options. It is assumed below that all such values are displayed in the user's selected units.

The WEATH# prefix is left off of the field names below for brevity. For the forecast day fields, they will be replicated at least three times (for three days of forecast information), though there may be more available.

• CurAsOf. This field MUST be of Time type and indicate that time at which the currently available field information was originally obtained. Most sources will only update the information so often, and this field can be used to determine how old the displayed data is.
  
• CurBaro. This field MUST be of Float type, and it indicates the current barometric pressure.
  
• CurCondText. This field MUST be of String type and contains a text string that indicates the current weather conditions. It MUST be marked with the CurWeather semantic type.
  
• CurHumidity. This field MUST be of semantic type Current External Humidity and conform to the definition of that semantic type.
  
• CurIcon. This field MUST be of Card type and will contain a code that reflects the current weather conditions. The valid values and their meanings are listed below. It MUST have a Range limit of 0 to 48.
  
• CurPrecip. This field MUST be of Float type, read only, and should reflect the current day precipitation, rendered in either inches or millimeters, depending on the standard/metric setting of the driver. If the source cannot provide this, it MUST be set to zero.
  
• CurTemp. This field MUST be of semantic type Current External Temp and conform to the definition of that semantic type. It reflects the current external temperature in the user's selected scale.
  
• DayXCondText. This field MUST be of String type and contains a short description of the forecasted weather conditions for day X.
  
• DayXHigh. This field MUST be of Int type and reflects the forecasted high for day X. It MAY have a range limit.
  
• DayXIcon. This field MUST be of Card type and contains the same icon type code as CurIcon, but forecast day X. It MUST have a Range limit of 0 to 48.
  
• DayXLow. This field MUST be of Int type and reflects the forecasted low for day X. It MAY have a range limit.
  
• DayXPrecipProb. This field MUST be of Card type, and have percentage limits (0 to 100) and reflect the likelihood of precipitation on forecast day X. If the source cannot provide this, it MUST be set to zero.
  
• DayXStamp. This field MUST be of Time type and should contain a time stamp for midnight of forecast day X.
  
• FCCurrent. This field MUST be of String type and should be filled with text that describes, briefly, the current forecast, i.e. for the next 12 hours or so. Forecasts for further out MAY be provided but are not required, and MUST NOT use the device class prefix as they are beyond the scope of this class. If no forecast information is available, the driver should set this field to "Unavailable".
  
• FCDayCount. The number of forecast days available. It must be at least three as per this device class' requirements, but can be more. This is to support tools like the auto-generation system.
  
• LocName. Drivers that implement this device class MUST either allow the user to provide a name for the location that the weather is being reported for (Home, Spain, Dad's House, etc...), or get such a name from the weather source. This field MUST be of String type, read only, and filled in with this location name.
  

Multi-Unit Considerations

This device class does not expect there to ever be multiple weather sources within one controllable device, server, etc... at least not any that are considered to be of a piece.

Weather Condition Codes

Some user interface widgets assume that the icon fields of drivers that implement this class will have specific values, so that they can display predefined representations of the weather conditions. Some weather sources may have more and some may have less that this device class supports, but all must be mapped to this set of condition codes:

• Unknown : 48
  
• Chance of Flurries : 15
  
• Chance of Rain : 40
  
• Chance of Sleet : 11
  
• Chance of Snow : 16
  
• Chance of T-storms : 35
  
• Clear : 32
  
• Cloudy : 26
  
• Flurries : 15
  
• Fog : 20
  
• Hazy : 21
  
• Mostly Cloudy : 28
  
• Mostly Sunny : 34
  
• Partly Cloudy : 30
  
• Partly Sunny : 34
  
• Sleet : 11
  
• Rain : 12
  
• Snow : 14
  
• Sunny : 32
  
• T-Storms : 35
  

[Dean Roddey]

(Reserved 1)

[Dean Roddey]

(Reserved 2)

[Dean Roddey]

A first whack at a Weather device class, which is essentially a subset of the Weather Underground driver, which is stuff that would have worked with the older Weather Channel driver as well, so hopefully it's generic enough that it'll work with other sources in the future.

I updated the WU and weather device simulator to support this, as well as the original V1 version of the WU driver as well. The only difference is the field prefix on those fields that fall within the device class. The fields and their attributes and meanings are all still the same.

This will let me move forward on weather in the new auto-gen stuff.

[dgage]

Awesome Dean. This was a big one for me as my wife is constantly paying attention to the weather, primarily for kids going to school. I also have my RadioRa2 temperature controls coming in this week. I received my Irrigation Caddy last week. So I think I'm about ready to make my first interface in CQC about a year and a half after purchasing. I've been using it for automating the lighting as opposed to any interfaces.

[Dean Roddey]

I added current and forecast precipitation fields to the device class, since they are so important for things like irrigation control. If the source doesn't provide them, the driver sets them to zero, but it allows them to be there where available.

I also, for the V2 version, corrected the old spelling mistake, i.e. PrecipProb instead of PercipProb. The V1 version was left alone for backwards compatibility. If anyone has been using the V2 driver, and the precip fields, this will be breaking change, but this is a beta thing so sometimes this happens. It needs to be updated now before it goes out officially. Just update to use the new (correctly spelled and class prefixed) version of the field.

[Dean Roddey]

I updated this class to support a 'FCDayCount' field. Different sources provide different numbers of days of forecast data. A minimum of three is required, but there can be more. Tools like the auto-gen system need to know how many to generate support for. Since this is an addition, it should be totally backwards compatible; but, AFAIK, I'm the only one who has ever done a V2 compliant weather driver, and I will update those drivers to match.