xAP Weather Schema Schema add change request

Quote:

---

Originally Posted by kev_t

KH

I guess you are referring to the fact that the rain= key does not specify the units

We already have at least two implentations which just report rain=

Pete says his Cumulus is reporting in mm
My WD is reporting in inches

---

Yes exactly my point - allowing people to use their own parameters has introduced an inconsistency within a schema that itself defined well the measurement units.

Also there is no indication of teh period of measurement - per hour - per day etc..

It's these sort of things we must avoid or people should use another schema of their own.

Quote:

---

A discussion on fixing this schema took place in 2008 and was not resolved and has been raised on a number of different support forum since, we should progress this now and update the wiki so we don't have to revisit
kevint

---

Agreed - but we need a champion who understands the schema and can make reasoned and complete changes. Are humidity and rain all we need ?

K

On the Cumulus side most (many) folks are utilizing the Fine Offset or Davis weather instruments. I personally utilize the humidity / rain for a functional multizoned watering device (xAP) which calculates ET (evapotranspiration) based on this data. (internal weather instruments versus internet weather stations). I am into weather though and my Home automation screens plot data from the weather stations. (three today; 1-wire, Fine Offset and Davis).

I also send my data to WeatherUnderground. Here are some links of my stuff:

http://www.wunderground.com/weathers...p?ID=KILLOCKP1

http://www.wunderground.com/weathers...p?ID=KILLOCKP7

http://www.wunderground.com/weathers...p?ID=KILLOCKP8

http://lockport.golffan.us/

http://lockport2.golffan.us/

http://lockport3.golffan.us/

So I can't speak for others using the Cumulus weather station.

On a concurrent endeavor though I am "pushing" to add xAP data to a Linux based application called "WeatherView" which is kind of similiar to Cumulus but a Linux program which I do have running and configured to talk to my Davis Weather Station and it is working fine. It would be beneficial here to use the documented xAP schema (weather report) which included both humidity and rain aside from the rest of the already included data.

Rain:-

On the period for reporting, I have always understood that rainfall is reset at midnight

Clearly you are proposing that there be two 'rains'

one for metric say rainSI, eng units would be mm

one for imperial say rainI, the eng units would be inches

as with all other keys, these would be optional

Of course this makes the current implementations not meet the newly redefined schema, but if that is what it takes to make progress then so be it

Humidity:-

the key for this would be humidity

The eng units would be given to be %

this key is optional

I don't know what if any other optional keys we might need, these are the ones we are discussing now

I would reiterate:-
"In any case any receiving application should gracefully ignore, ie not break, if it gets keys it does not recognise"

Is this acceptable to all?

kevint

Quote:

---

one for metric say rainSI, eng units would be mm

one for imperial say rainI, the eng units would be inches

---

What the the "S" in "rainSI" stand for?

Thinking maybe simplier like:

RainM
RainI

and globally/internationall isn't humidity usually referred to relative humidity?

So the definitions would say:

RainI=(Value of rain in inches)
-- optional

RainM=(Value of rain in millimeter)
-- optional

Humidity=(Relative Humidity Percentage)
-- optional

Quote:

---

Originally Posted by kev_t

Rain:-

On the period for reporting, I have always understood that rainfall is reset at midnight

---

Fine.. if that is the norm / what people want then so shall it be..

Quote:

---

Clearly you are proposing that there be two 'rains'

one for metric say rainSI, eng units would be mm

one for imperial say rainI, the eng units would be inches

as with all other keys, these would be optional

---

The very first post in this thread shows the existing schema and it is self evident that it reports the same sensor data using multiple measurement units defined in the paramater name - I think any extension to this schema should be inkeeping with that. I am not sure SI is inline with other parameter names ... however right it might be.

Quote:

---

Of course this makes the current implementations not meet the newly redefined schema, but if that is what it takes to make progress then so be it

---

It's no good getting grouchy about it - if those developers chose to extend an existing schema without concensus or documenting it then that is what will happen. The cause is the very issue you're advocating - adding your own parameters and why people like SandaySoft are right when they say they don't just want to extend without concensus.

Quote:

---

Humidity:-

the key for this would be humidity

The eng units would be given to be %

this key is optional

---

Sounds fine

Quote:

---

I don't know what if any other optional keys we might need, these are the ones we are discussing now

---

That was why I asked for completeness- anyone have any more whilst we're at it ?

Quote:

---

I would reiterate:-
"In any case any receiving application should gracefully ignore, ie not break, if it gets keys it does not recognise"

---

... yes... I did respond to this before .. However it is the reason why we now have an ambiguous rain= value as no units were defined and also we could potentially invalidate the existing rain= usage if for example we defined it as always inches or having a measurement value appended to the value e.g. rain=12mm. It doesn't break persay but it does mean that if we used that parameter in a formal definition we may present data in an incompatible form to the existing usage.

How long is a max size message currently - does anyone know ?

K

Quote:

---

Originally Posted by pete_c

What the the "S" in "rainSI" stand for?

---

http://en.wikipedia.org/wiki/SI_derived_unit

K

Ah, OK that makes sense Kevin; apologies.

Quote:

---

How long is a max size message currently - does anyone know ?

---

No.

Here are two Cumulus generated xAP messages.

Code:

---

xap-header
{
v=12
hop=1
uid=FF437500
class=weather.report
source=sanday.cumulus.ICS-HST
}
weather.report
{
UTC=16:39
DATE=20120209
WindM=10.0
WindK=16.1
WindGustsM=17.0
WindGustsK=27.4
WindDirD=197
WindDirC=S
TempC=-1.4
TempF=29.4
DewC=-5.3
DewF=22.5
AirPressure=1026.0
Rain=0.0
}

---

Code:

---

xap-header
{
v=12
hop=1
uid=FF437500
class=weather.report
source=sanday.cumulus.ICS-STORAGE-2
}
weather.report
{
UTC=16:42
DATE=20120209
WindM=2.2
WindK=3.6
WindGustsM=5.4
WindGustsK=8.6
WindDirD=360
WindDirC=N
TempC=2.7
TempF=36.9
DewC=-6.2
DewF=20.9
AirPressure=1028.0
Rain=0.0
}

---

Which brings us to

weather.report
{
UTC=(Time of report in hh:mm format using utc time zone)
-- mandatory
DATE=(Date of report in YYYYMMDD format)
-- mandatory
WindM=(Value of wind in mph or "Gusty" if gusty)
-- optional
WindK=(Value of wind in kph or "Gusty" if gusty)
-- optional
WindGustsM=(Value of wind gusts in mph)
-- optional
WindGustsK=(Value of wind gusts in kph)
-- optional
WindDirC=(Compas heading of wind N|NE|E|SE|S|SW|W|NW)
-- optional
WindDirD=(Compas heading of wind in degrees)
-- optional
TempC=(Temperature in centigrade)
-- optional
TempF=(Temperature in fahrenheit)
-- optional
DewC=(Dew point in fahrenheit)
-- optional
DewF=(Dew point in fahrenheit)
-- optional
RainM=(Rainfall since midnight in mm)
-- optional
RainI=(Rainfall since midnight in inches)
-- optional
Humidity=(Relative Humidity as %)
-- optional
AirPressure=(Air pressure in hPa)
-- optional
Cloud=(Overal cloud cover currently only "Clear Skies")
-- optional
CloudM.X=(Cloud type and height in miles ie "Overcast at 5.4M. X increments on each cloud layer)
-- optional
CloudK.X=(Cloud type and heightin kilometers ie "Overcast at 5.4Km. X increments on each cloud layer)
-- optional
Icon=(The name of the picture to use, icon names from kweather www.kde.org. File names below)
-- optional
Error=(Download errors either "NoData" if last connection failed or "StationNotFound" if ICAO code isn't valid)
-- optional
}

If we agree on this I will update the wiki

kevint

I have received one email from someone who can't post to AH forum (for some reason) re WindChill - any thoughts - is this an important one Pete, and have you others ?

Also I don't really like RainM (for mm) because CloudM is miles - however it's already messed up in the existing schema with WindDirC for 'compass' and TempC for centigrade so I think we scuppered that earlier. RainM it is, even though it's wet in the Pennines I've never seen it measured in miles.

In hindsight I think a metric and/or imperial body would have been better, or appending units to values (and maybe 'period' blocks eg hourly, daily ). Definite scope here for a new schema.

K

PS Do people want to include indoor humidity and temperature in a weather schema - I know a lot of weather stations have this built in ?