code:observatory_weather_blocking
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
code:observatory_weather_blocking [2008/08/30 16:46] – pkubanek | code:observatory_weather_blocking [2009/12/14 21:22] – pkubanek | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== State ====== | ||
+ | |||
+ | Implemented and running fine. | ||
+ | |||
====== Introduction ====== | ====== Introduction ====== | ||
- | Currently all weather checks are carried inside RTS2 dome component. The nice think is that there is single instrument to fail to prevent | + | Currently all weather checks are carried inside |
- | - it is hard to share weather | + | - it is hard to share weather |
- | - it is hard to see which device | + | - it is hard to see which device |
- | - it is hard (requires | + | - it is non trivial |
This drawbacks should be resolved by following code changes: | This drawbacks should be resolved by following code changes: | ||
+ | |||
+ | // In short: Single devices provide their opinion about whether to open or not over normal RTS2 channels. Some may be setup as mandatory in the system configuration. Multiple-instance connections, | ||
====== Multiple central server ====== | ====== Multiple central server ====== | ||
- | Single device needs easily | + | Single device needs to connect |
+ | |||
+ | To do this, the following must be assured: | ||
+ | |||
+ | * a single device having two Rts2CentralConn instances (no major changes expected) | ||
+ | * proper device IDs obtained from multiple centralds (shall be in CentralConn, | ||
+ | * proper logging (to both centrald) - some changes expected | ||
+ | * what to do in case of centrald failure (hook in device class, fill it as needed) | ||
====== Switching ====== | ====== Switching ====== | ||
Line 20: | Line 33: | ||
requests to switch state and will generate warning email. | requests to switch state and will generate warning email. | ||
- | Before system | + | Before system |
- | can list that device block switching to standby or on. If such bit is set at | + | Devices state can list that device block switching to standby or on. If such a bit is set at |
least on one device, centrald will reject mode switching and will record that | least on one device, centrald will reject mode switching and will record that | ||
- | mode switching was rejected. If all devices agree, centrald switch state and | + | mode switching was rejected. If all devices agree, centrald |
- | distribute message about switched state to all connected | + | distribute message about switched state to all clients |
- | If during request for state of the devices any connection | + | If during request for state of the devices any connection |
- | change state, the request will be canceled, and new request (if needed) will be | + | change state, the request will be canceled, and a new request (if needed) will be |
issued. | issued. | ||
- | Centrald | + | Centrald |
actual state (e.g. it ask switching from off to standby and on, and from | actual state (e.g. it ask switching from off to standby and on, and from | ||
standby to on). It does not ask any confirmation if request is to lower or same | standby to on). It does not ask any confirmation if request is to lower or same | ||
Line 37: | Line 50: | ||
When centrald starts, it has two options: | When centrald starts, it has two options: | ||
- | - if uptime of the whole system, as deterined by sysinfo call, is bellow | + | - if uptime of the whole system, as deterined by sysinfo call, is below a value specified in observatory / wait_after_reboot seconds, it will switch immediately to off if reboot_on is false and to on if reboot_on is true |
- | - otherwise, system state will be set by reboot_on config entry (on if reboot_on is true, off it is false). System then enter grace period and will wait for others | + | - otherwise, system state will be set by reboot_on config entry (on if reboot_on is true, off it is false). System |
- | This procedure is implemented in order to do not close dome roof on RTS2 | + | This procedure is implemented in order to not to close dome roof on RTS2 |
restart. | restart. | ||
+ | |||
+ | ====== Solution ====== | ||
+ | |||
+ | Following solution was implemented and runs successfully on all systems: | ||
+ | |||
+ | - **weather state** each device have weather state. It can be either good or bad. This way any device may signal if weather is acceptable for observation or no. | ||
+ | - **central server required device list** so central server know which devices must be presents in order to turn central weather to good. If some devices are missing, central weather state is set to off. | ||
+ | - **list of failed devices** in central server, so user knows from monitor why central server is in bad weather state. | ||
+ | - **mootd**, which allows to connect two or more central server, and signals to all central server off states. If at least one central server is in hard off, mootd signals bad weather on all connected central servers. | ||
+ |
code/observatory_weather_blocking.txt · Last modified: 2009/12/14 00:00 (external edit)