sensor arrays

[sonologic]

We updated it with some sensors; since you asked for a spec here is what we used:

• humidity (array of strings) - strings indexed by a mnemonic identifier, the string value representing the percentage humidity should match the regular expression ^(([0]?.\d)|1(.0+)?|0)$
• barometer (array of strings) - strings indexed by a mnemonic identifier, the string value should match the regular expression ^[0-9]*.?[0-9]+(hPa|Pa|bar)$
• wind (array of strings) - strings indexed by a mnemonic identifier, the string value should match the regular expression ^[0-9].?[0-9]+(m\/s|km\/h|beaufort|knots|apc\/mfortnight) (([0-9].?[0-9]+(m\/s|km\/h|beaufort|knots|apc\/mfortnight) gust))? (N(N?W|N?E)?|E((N|S)E)?|S(S?W|S?E)?|W((N|S)W)?)$
• wifi (array of strings) - positive integers indexed by a mnemonic identifier or SSID, the integer should represent the number of currently connected devices to the WIFI

I've tried to use the same format you used for temp; though I have a suggestion for future revisions of the specification: maybe disassociate the value of the measurement from its units (such as, say, {'temp': {'outside': [23.7, 'C'] } }

IMHO this would make sense since this is an API and should be easily machine-readable; making the values floats, integers, etc. and specifying the units separately would make it a whole lot easier for consumers of the API to use this data (for instance in charting) without reparsing the strings into its components.

[lhw]

I guess this was proposed by Eike Frost who is also a member in the same hackspace as I am. We deprecated this approach in favor of the specs laid out in issue #6

[slopjong]

Can somebody add enums with allowed values for the units? The specs file is here.

[slopjong]

The new specs define a whole bunch of sensor types with a straightforwarded structure. The interests of all the hackerspaces should be met with those.