×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

INDI::Weather class

I am planning to standardize weather devices & services in INDI, and would appreciate your input before I embark on the actual development. Basically the idea is to design a class that encapsulates most weather parameters of interest to astronomers along with their range & units. For each parameter that is supported by the device, the user should be able to pick a "maximum" and/or "minimum" range which the value must fall within for it deemed "acceptable". Once the value is exceeded for a certain time threshold (also configurable), then the status of the overall "Weather Parameter" property is ALERT and this should cause the observatory to interrupt any operations and go into "panic mode".

All parameters shall have:

1. Actual value + unit if any
2. Current % of Maximum Range?
3. Minimum/Maximum "Acceptable" range?

This could even apply to rain (descriptive and mm). If we define rain conditions as RAIN_DRY, RAIN_LIGHT, RAIN_HEAVY (just an example, the actual enumeration range can be more complex) then we have just 3 values (0, 1, 2). The % would be 0%, 50% and 100%. The minimum/maximum acceptable range could be 0%/0%. If the rain is measured in mm, the same principle applies.

There will be a primary LIGHT property which holds the state of the various parameters. Green OK, Yellow Warning (10% within range, if applicable), and Red for Alert.

Weather: [X] Rain [X] Wind [X] Clouds

If Rain is ALERT, then the whole Weather property is ALERT, and the observatory can go into safe mode. As it stands now, it is either OK (continue observing), or full panic mode (stop observation, close dome shutter, park..etc). We can have a "Medium" risk mode which we would have to define someway. Perhaps something like, if Warning state last more than 5 minutes, or only if parameters X, Y, Z are all warning then the overall state becomes warning, otherwise, it is OK...etc.. For the "Medium" risk, it can cause the observatory to cease operations, until the weather improves, but it doesn't need to go into panic mode.

This might seem complex, but remember we are trying to create a generic weather interface for _any_ devices or service, with any number of parameters, descriptive or physical in nature. Furthermore, we need to formalize what is the overall state of the weather device, and how it can affect the observatory. Is OK/Alert enough? or OK/Warning/Alert? Or perhaps something else completely?

Any thoughts appreciated!
Last edit: 8 years 7 months ago by Jasem Mutlaq.
8 years 7 months ago #4805

Please Log in or Create an account to join the conversation.

  • Posts: 72
  • Thank you received: 21

Replied by Philippe on topic INDI::Weather class

Hi Jasem.

Look fine and really good idea to have an INDI::Weather class.
I've to think about your question. I used a library for some Weather condition calculation like DewPoint, relative humidity and degree of saturation get from an Arduino with meteo's sensors. Even if all values calulate by this lib aren't necessary for astronomy, few of them, as the relative humidiy and dew point could give an estimation for when we reach condensig condition. Other value could be just as information.

My first idea would be to have a graphic object in INDI's library to draft the trend along the night of these values...

The libray could be find here and the licensing is subject to the GNU General Public License.

Best regards Philippe
Philippe Besson
Skywatcher HEQ5, Televue 101-IS, Takahashi FS-60CB
Focus Boss II with OptecInc TCF-S focuser and Starlight Instruments HSM20 handy stepper motor
Guiding camera ZWO ASI120MM
Filterwheel OptecInc IFW
Camera not set yet
Switzerland
8 years 7 months ago #4811

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic INDI::Weather class

Whatever the parameters may be, we need a way to represent those critical to decision making across all weather stations drivers. For now I think the driver should represent its overall state as either:

1. Ok: Observatory operations can run in full capacity.
2. Warning/Bad: Observatory operations should run in reduced capacity (stop capturing stuff!)
3. Alert: Cease observatory operations completely and go into safe mode.

I'm still building my home observatory, so I'm not really sure how folks with observatories handle this. This is of course assuming unattended and/or remote operation.
Last edit: 8 years 7 months ago by Jasem Mutlaq.
8 years 7 months ago #4839

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic INDI::Weather class

Ok everyone, you'll see the new weather driver "WunderGround", though you'll need to get an API key (free) from www.wunderground.com, and just put your API key there then "Save" options so that it gets loaded next time. Would appreciate feedback on the weather driver.
8 years 6 months ago #4980

Please Log in or Create an account to join the conversation.

  • Posts: 20
  • Thank you received: 3

Replied by S. Alonso on topic INDI::Weather class

Dear everyone

I've read this thread carefully as I'm very interested in the Weather class. In fact, I have some ideas from it from writing the AAG CloudWatcher driver. This post is going to be long, because I will try to expose all my ideas regarding weather devices

We assume that Weather devices are mainly RO devices that show some parameters regarding weather conditions (air temperature, humidity, wind speed...). However, the main discussion (in my opinion) is if we should add new properties which allow to establish when one of those parameters falls within an acceptable range (f.e. low wind), a "caution" range (f.e. "moderate wind") or dangerous range (f.e. "strong wind") or even "unknown" if the reading is outside reasonable ranges (some sensors sometimes give bad readings). In fact, in my AAG CW driver I explicitly did that. My main reason for doing that is that I wanted to emulate the CW software (for Windows) which did more or less that. However, this approach:

- Increases a lot the number of properties: Not only you should send the raw readings, but a new one to show which "range" it is and another property to define the ranges for any of those states.

- It "breaks" the recommendation of making the drivers as minimal as possible. I think that this kind of functionality is more a problem of the clients (to decide what is "strong wind", etc).

- It makes difficult to mix the inputs from several different weather devices if present: for example, one may have a thermometer in one device and a wind sensor in another one. If you pretend to mix both measurements to take any kind of autonomous decision (close the observatory because the weather is not safe enough), this MUST be done in the client, not in the device level.

Please take into account that I'm thrown stones on my own roof, because that reasons contradict what I've done in the CW driver. However, as I think that if a better approach is defined in INDI for Weather devices I will gladly update that driver.

So, what I propose:

+ The Weather class MUST give the RAW readings from the device. These RAW readings may differ from device to device even if they are used for the same phisical magnitude. For example, to measure "Wind Speed", some devices may give it in km/h and another ones in ticks per second [as the sensor is spinbing] that should then be converted to a more meaningful measure.

+ The Weather class should be prepared to ease conversion of known units. For example, we should stablish standard temperature measures to be provided in ºC. Internally, it should have some kind of property that allows to express temperature readings in Kelvin or even Fahrenheit. The same for wind speeds: by default in km/h but it should naturally allow the conversion to miles/hours and so on.

+ We should avoid the above mentioned "limit" properties with different states . This functionality should be delegated to clients.

+ However, the drivers must give some information about acceptable ranges to ease the construction of generic clients. There are several magnitudes as temperature or wind that are easily understandable and that a regular user could set by "common sense". However, other magnitudes as humidity or light sensors might not be so obvious. So, the drivers must give in some format RECOMMENDATIONS about how the raw readings could be interpreted.

+ The Weather class should implement a number property in which the rate of updates could be adjusted. For example, one reading every 10 seconds or every minute and so on.

+ We should define standard properties that a lot of weather devices might use: "Ambient Temperature", "Wind Speed", "Humidity", "Rain Presence", and so on.

+ I think that readings of values should NEVER use the Property States (IDLE, OK, ALERT, BUSY) to note that a particular reading is extreme and possibly dangerous. Again, interpreting data is a CLIENT problem.

And I think this is all from my part at this moment. Any comments and / or criticism about them is greatly welcome.

Zerjillo
8 years 6 months ago #5004

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic INDI::Weather class

Thanks a lot for the very informative reply!

I think it is a normal side effect of having a generic weather driver.

It is always a balance between the workload in the driver vs. the client. Yes, ideally, the driver should be a dumb raw device, but we experienced instances where it makes more sense to do the work in the driver itself than the client (for example mount alignment and dome slaving). I don't expect clients to become weather-processing machines, since we're dealing with astronomical clients mostly.

I'm in the camp where I believe all "popular" weather parameters should have standardized units, just like the rest of all units in INDI. This doesn't prevent the driver from presenting "raw" values, but it is required to present INDI-compliant properties. A mount driver can display its raw encoder values, but it also MUST present the EQUATORIAL_EOD_COORD values we well.

Already implemented in INDI::Weather

I'm also in the camp that it should remain as simple as possible. The weather status indicator from the weather device can a "recommendation". The client does not have to act on it, and may resort to interpreting the raw values and making decisions based on those.

Thanks for the feedback!!
8 years 6 months ago #5005

Please Log in or Create an account to join the conversation.

  • Posts: 20
  • Thank you received: 3

Replied by S. Alonso on topic INDI::Weather class


Ok, lets say that we create that "limit" properties to say that a particular measure is in a "safe" range, "caution" range and "danger" range. I would:

- Define a min and max for every one of those three states.
- Define a proper name for each one of those states (Calm, Moderate Wind and Strong Wind) in the case of "wind speed"
- Add a "unknown" state if the reading does not fall in any of those ranges.

Additionally I would NOT make a "general state" that aggregates all those conditions. I REALLY think that should be implemented in the Client (for example if you want to mix readings from different weather stations, which is not so strange). So decisions like "If moderate Wind AND cloudy -> Close the observatory should be made al client level, not with a special property in the device.

Ok, totally agree. INDI-complaint properties should use standarized units. Therefore, conversions to other units I would left it for clients. However, I would say as a recommendation to present RAW readings (in a "RAW Readings" group).

Best regards.

Zerjillo
8 years 6 months ago #5006

Please Log in or Create an account to join the conversation.

  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic INDI::Weather class

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.
Last edit: 8 years 6 months ago by Gerry Rozema.
8 years 6 months ago #5009

Please Log in or Create an account to join the conversation.

  • Posts: 2247
  • Thank you received: 223

Replied by Gonzothegreat on topic INDI::Weather class

I think everyone should have a wether box attached to their observatory, should be mandatory.
Or at leat something that can check for rain and wind as a strict minimum.

I have the Meteostation , which is a great little tool however this runs as a standalone.
If I connect via Indi to it, somehow it kills the meteostation scripts (no idea why), hence I used it 100% standalone.

What I'd like to see in the Weather class:
Astronomy forecast for the next 5 nights, maybe someone could hook up with clearoutside.com/ (I use this website a lot and the app, it's quite good I must say).
Input from must-have sensors (rain, wind, humidity etc...)

If forecast says 'clear night', then check sensors for confirmation only if found 'OK' then you can start your session.

I would like to also be able to have an emergency shutdown, ie; rain sensor has detected rain then everything must close as in stop imaging session, park scope, close dome(or roll on roof).
8 years 6 months ago #5011

Please Log in or Create an account to join the conversation.

  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic INDI::Weather class

Ok, been thinking a bit more on this.

After having another coffee, and thinking on verbiage etc, I've homed in a little better on what I meant in the above ramble regarding weather.

The final configuration we will have, two (possibly 3 if a small one fits between the two big ones) telescopes on mounts under a roll off. For each telescope, there will be a dedicated computing device with an indi server handling the mount and cameras. A third computing device will be there specifically for controlling the roof. A fourth will be in another location about 25 meters distant, hooked up to the all sky and the weather station. The 'obseratory manager' device will be running on the roof handler, and likely the failsafe park devices will bring the inputs to the roof manager as well. The oservatory is physically located 400 feet from the house, and the conduits for power and optical fiber are now in the ground, expect power and data out to the location early next week. I will have gigabit ethernet running between the house and the observatory, with a gigabit drop at the all-sky camera location too.

In our setup, the plan is, we will have one client (on computers here in the house) for each telescope. That client will monitor one property in what I now call the 'observatory manager', which is a binary 'safe / unsafe' output. The client should not attempt to take the telescope out of the parked position until that property shows safe. It will show safe only when the roof is open. Once the telescope is out of the parked position, it continues to monitor that property, and if it goes to the unsafe condition, the client manipulating the telescope and cameras needs to immediately send the telescope into the parked position.

After thinking this thru, it would be much simpler for clients if that 'safe / unsafe' property is available on the same indi server where the mount and cameras are located. In reality, I plan to have the logic all sitting on the roof controller, but, I think I'll write a shim driver of some type which just reads the property from the roof controller, and exports a single binary 'safe / unsafe' on the server hosting the telescope. IMHO, this is the most important detail to standardize up front, what property a client should be honoring for safe / unsafe operation, and it should be an optional property, ie, client does not have to honor it if it doesn't exist, but, if it does exist, client MUST honor it.

In our case, roof controller is where the overall logic needs to reside. The roof controller is exporting 'safe / unsafe' to any and all clients that use it. Roof controller will take input from multiple sources, in binary true/false form. If any of them reaches 'false' as in unsafe, it will export unsafe to all the clients. The expectation then is, telescopes will soon reach the parked condition. When all telescopes are parked, the roof can be closed. In the case of a dome, this step could be skipped, and shutter closed as soon as any conditions reach false, no need to wait for telescopes to reach parked positions.

Within the roof controller, the first input will be a simple 'human settable' true / false condition. Any time that one is set to false, then the roof controller will keep the roof closed, and the rest dont matter. It's essentially an on/off switch for the observatory as a whole. Other inputs will / should be coming from other places, and as an example, I will have a weather station. My thought now is, when I have programs set up to monitor weather, they can register with the roof controller as an input. The roof controller is a simple 'or' function of all inputs, and when all inputs are 'safe', it will open the roof and export safe to the clients. The closing functions need a little more logic. If any of the inputs to roof go to false, be it from a human clicked a button, or possibly a weather analysis program triggers an unsafe condition for weather, the output goes false, and clients should start parking. Roof controller then needs to monitor feedback on parked positions and they all have to reach true before it activates the roof.

I go a step farther in thinking thru the abstraction now, and, from that comes the concept of 'observatory manager' device, where essentially all observatory safety things come together, and get boiled down to a single binary true/false output. On my indi server controlling the roof, it breaks down to two things running there. One of them is a purpose built indi device driver that controls my roof installation, the other is the general purpose observatory manager, which should be common across all observatories, because that's what clients monitor. It provides a means for purpose built stuff to communicate with general case abstractions, and provides us with one standardized property for all clients to monitor in the case of an automated observatory. Reality is, for an imaging client, it has no need to have any knowledge of the sensors or logic that came to the unsafe condition, it just needs to know conditions are unsafe, and it should park the mount. Everything else is done elsewhere by other programs.

As far as thoughts on making things mandatory, I strongly disagree. When we first start with our system, I wont leave anything to full automation until I've had some time to develop confidence in things overall, and lots of folks have an observatory where they are quite happy with manual control and have no interest in fully automating. We will initially make our 'open/close' decisions by simply looking outside or at the all sky camera display, and I expect it will take a year of work on programs before I have enough confidence to let them make fully automated decisions while I'm sound asleep. If we are running it all manually, there is no need to enforce any kind of sensors be attached.

But in the end, where this all leads (imho), is the need for one standardized property initially, which exports safe / unsafe conditions for clients, and clients need to be aware of that property. Much of the other stuff becomes location specific. Once our structure is built, I would like to be able to use ekos manually 'right out of the box' to start, and I'm leery of using anything that wont at least check the roof is indeed open before it slews a telescope. As time goes on, we'll develop more and more toward fully automated, and having clients that honor the unsafe flag is all we need to work on the rest of the process.

For me at least, the standardizing up front of a safe / unsafe flag will open the door to let folks work on the intricacies of all the rest, it is the place to start, and over time we'll gain lots of experience in figuring out ways to 'make it better' in terms of how various clients manage data from various sensors to make intelligent decisions. But, that all becomes kind of moot if the clients running the mount are not already set up to join the party.
8 years 6 months ago #5012

Please Log in or Create an account to join the conversation.

  • Posts: 2247
  • Thank you received: 223

Replied by Gonzothegreat on topic INDI::Weather class

Most of astrophotographers out there, are close to (shed in the garden, controlling it from their home comfort) or in their observatories. Mine is located 750Km away from my house...
A weather box is an absolute must have for me, I couldn't run my observatory without it. In fact, when I wanted to go live in August, well I couldn't as I did forget the 'al-sky-camera / weather box' power supply at home (I have had to take the telescope back home with me too). That was a real blow.

I agree that a standard need to be introduced, words should be easy to understand an meaningful. "safe / unsafe flag" is good. Rain/Dry, Windy/Calm, Open/Close.

Scenario using the Ekos scheduler:
weather forecast says: clear night.
sensors checks (rain/wind) : Dry/Calm
roof opens checks sensors: Open
deploy scope and run with the schedule.

While the above runs, a constant sensors check must apply, sudden rain shower from unforeseen clouds or burst of wind in excess of a threshold should send the observatory into an unsafe mode and shutdown the system.
8 years 6 months ago #5014

Please Log in or Create an account to join the conversation.

  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic INDI::Weather class

Ok, so folks got me thinking more on the subject :)

I'll add to my long rambles above, some of the design thoughts we have for the observatory overall, and how the weather inputs play into it.

Our observatory will be 400 feet from the house, with power and gigabit data. I'm striving to build a complete 'failsafe' system, so one of the things we are doing with respect to power will work like this. The power that comes out from the house will be used only to charge an 8D deep cycle battery. I will be using one of the newer RV style power supplies to do that, it's a slick system that is essentially a huge uninterruptible power supply, takes 110v from an external source, and uses it to feed the 110v plugs, but it also has an inverter built in, and a charger. It will keep the battery topped up, and it will power the 110v plugs via the inverter if the external power source goes away. The newer more modern ones also have the ability to give battery condition and power status over an ethernet plug, which we will use.

My goal is, everything in the observatory in the end will be self sufficient and any type of failures put the observatory as a whole into a safe mode, so even in the event of a power outage, the observatory will not be left in an unsafe condition with the roof open. So as an example, one of my 'observatory manager' inputs, will be battery power levels. If the battery is not at at least 50% of charge, the roof will not be opened. This way, it will always have enough reserver power to close the roof in the event of a power outage. Battery dropping below 50% will generate one of my unsafe conditions that trigger the overall shutdown process.

My weather sensors will be remote from the observatory, and managed by a completely different computer. The plan is to build a 'fail to safe mode' operational mode for that, and it works like this. My weather client will be monitoring weather data, and running on a computer here in the house taking data from the sensors over the network. It will provide updates to the observatory managery on some frequency, probably about once a minute or so. On the other end, the observatory manager will default the weather input to 'unsafe', and every time it gets a weather safe indication, it also starts a timer on that. If it goes 5 minutes with no weather updates, the weather input will fail into the unsafe condition. This is a fail safe for the observatory as a whole, if we are operating in fully automated modes of operation, it's not accepable to keep the roof open with no weather data, so lack of weather data will trigger the sequence of events that ends with a roof closing.

I'll be looking carefully at our mount code too, and am pondering how this will be handled, but, the conditions I want to end up with, if there is no client driving the mount for whatever reason, it will after some period determine the inactive state and just go to the parked position.

Inactive states on clients can come from any number of various conditions. Maybe there is a problem on the data link between observatory and house, so we lose connectivity. Maybe there is a power outage, which drops the network on the house end. Maybe it's as simple as somebody closed the client program on a computer in the house, and didn't park the mount before they did that. There's all sorts of conditions that can end up with a mount tracking, but nothing left talking to it. I want to detect those conditions, and send the mount(s) to the park position when they happen.

Ok, think I have probably rambled more than enough for today, and I do have to do some 'real work' yet before the day is done.
8 years 6 months ago #5015

Please Log in or Create an account to join the conversation.

Time to create page: 2.038 seconds