I will add some thoughts, based on what I plan to implement here, and some experience from many many years as an end consumer of detailed weather data in the aviation industry. Warning, long ramble to come, many of my thoughts are not solidified yet, but I think they give a reasonable idea of the direction we will head.
Sensors should produce what amounts to 'raw reading' data in some way, and they should also have numbers that are 'real world' type of numbers. I think the wind speed is a good example, it should produce a number that is a calibrated value, be it in knots (standard world wide for aviation weather), km/h or meters/sec (standard used for most engineering applications).
Another VERY important point, it should show a min/max range that the sensor is capable of measuring. Again, using the wind example, if the max value the sensor can measure is 80 knots, then a reading of 80 really means '80 or above'.
Another thought, there should be standardized fields for typical measurements that all 'off the shelf' weather station kits can produce, ie wind, rain, humidity, temperature, barometric pressure, etc. But we should also think forward a bit, and make sure it can cover the data that comes from a more high end weather station. An automated weather station for aviation use also produces data for cloud cover, cloud hight, and visibility. I can see a strait forward driver implementation that pulls data from the nearest aviation weather station and reports it, no hardware required, just interpret the METAR which is a standard form of output, and there are stations all over the world emitting METAR reports hourly, all of which are available in real time online.
As far as any interpretation of the data, that should be left ENTIRELY to clients imho. My reasoning for that, different areas have different types of climate, and, much of the interpretation of the data is climate zone specific, and can/will often involve some local knowledge. Again, using my own location as an example, sky has 10% cloud cover, everything looks good, but wind is from the southeast at 10 knots and rising. I KNOW from experience, that's a pacific system moving in, and if we reach 15 knots on the wind from the southeast, then the rest doesn't matter, because we have seriously bad weather approaching fast.
For my project here, we are building a roll off to house two telescopes next summer, so this winter a big part of the plan is to start working up software to head in the direction of full automation. The implementation I'm planning works like this, and is based on the assumption that weather sensors will provide various inputs to a decision process, which ultimately ends up with a 'go/no-go' decision to open the roof, and later, decisions to shut down and close the roof.
The implementation I plan to use is fairly strait forward, and I'm going to create one 'safety device' for lack of a better terminology. It will contain a couple of properties that boil down to true/false booleans. All of my client programs will monitor these properties. One of them will be 'safe to open', and the other will 'must close'. The logic I plan to implement is along this line.
All client programs will monitor roof status, and, will not attempt to move a telescope out of the parked position unless the roof is in the open state. Once they have moved telescopes and start doing whatever, they will constantly watch the 'must close' status, and if it becomes true, they stop whatever they are doing and park the telescopes. The process for a shutdown and close of the roof will begin when the 'must close' varable goes true, then the client driving the roof will monitor all of the scopes to ensure they reach a parked position before it triggers the close action.
Right now this is all a bunch of thoughts in my mind, and I haven't written much code yet, but I have all winter to do so. I do know this, when I implement my 'safety device' initially, it will be entirely manually driven. A person sits down at the computer, clicks a button, and the state will change to 'safe to open'. My initial work then will all be around 'is it safe to stay open'. I'm also pondering ways and means of putting cross checks in place so that I have some form of positive return that tells me telescopes are indeed in the physical park position, and roof will not hit them if it closes. This will likely end up implemented as some sort of beam detect that reflects off of a reflective material on the scope tube, so the beam closes only when the telescope is physically parked.
Other thoughts that I have in mind, the all-sky camera will be running this winter, and I plan to have it run all winter, working toward full automation these days for that. I've started to work up code for analyzing all sky data in real time, and by the end of the winter I hope to have outputs from a client program that produce
a) sky darkness
b) cloud cover
c) sky clarity
The first item is fairly strait forward to analzye. I've standardized on 10 second exposures here using the oculus all sky camera. With 10 second exposure, I can take the center section of the frame, calculate mean and standard deviation for that small patch of sky, and from that I can get a hard number telling me how dark it is. Cloud cover is a little more difficult, but, I've got all winter to figure that out.
When we think of weather devices in astronomical terms, ultimately they are used to provide input to go / no-go decisions for an obseratory to start up and/or stop operation. BUT, those are complex decisions and I think it's wrong for a weather device to output binary 'go/nogo' type information. That should be a totally separate set of properties, exposed at the indi server, but, driven by some sort of flexible client which takes input from many sources and boils it all down to the binary outputs. That device ends up being a state machine that has a few states.
a) Everything parked and closed.
b) Safe to open - roof / shutter and telescopes still parked.
c) Roof / shutter in operation - state is safe
d) State becomes unsafe, - roof / shutter still operating, waiting now on safe to close
e) Telescopes parked, now safe to close
f) Roof close operation complete - transition to state a)
Many parts of this process become observatory specific. Examples. A dome doesn't need to wait on telescopes to park before closing shutter and parking the dome. But a roll off needs to wait on telescopes parked before starting the close operation, and, most cases just one, but in some cases more than one telescope needs to be parked. In those cases, it needs to wait for 'all telescopes parked'.
My initial design thoughts on the 'safety' object for my own use, when we transition out of roof closed, each telescope will inform the safety device that they are coming out of the park position, and it will keep a count of 'unparked telescopes'. When the state transitions to 'must close', it will wait till all telescope clients have reported back 'parked', so if two of them unpark once we get going, it wont transition into 'safe to close' until both of them report parked. I'm not completely sure how it'll all glue together, but, since I ultimately want to include failsafe devices that report 'absolute parked position' as a binary return, it may well not bother with listening to telescope clients, and ONLY monitor the absolute position device.
When we first start using the system, the plan is this. The safety objects will ONLY be driven by human input, ie, there will be no magic involved. Over time, I will start adding magic by taking input from various devices into a client program, and that client will generate the 'must close' condition, but it will still have an absolute override where a person can click on something on the screen, and send the whole observatory into shut down and close up mode.
End result of my ramble, weather is but ONE set of inputs to make decisions for operating the observatory, and should be treated as such. Decisions for automating the process of start up and shut down, should be delegated to another device, call it what you will, we need a good name, and I abhor the 'safety device' name, but it seems to be what folks call it these days. That device should also be a 'dumb device' that just generates states, based on input from client programs. Then the correct direction to move once those devices are 'figgered out', is a VERY flexible client that can be configured for observatory specific parameters. The excecption to that, if we have something reporting absolute telescope park positions, then the 'safety device' should probably be capable of snooping those, and use the 'absolute park' property as a hard override in the case of a roll off, ie, it will not permit roof close action as long as the telescope(s) are not in the verified park position.
The big thing here is, device level stuff should not be making complex decisions based on a large number of measured inputs. No matter how you twist it, if those kind of decisions end up in device level stuff, it'll be wrong for some locations.