Differences

This shows you the differences between two versions of the page.

--- code:observatory_weather_blocking [2008/08/30 16:45] – created pkubanek
+++ code:observatory_weather_blocking [Unknown date] (current) – external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Introduction ======
+====== State ======
-Currently all weather checks are carried inside RTS2 dome component. The nice think is that there is single instrument to fail to prevent roof from closing. And this single component can be easily tested and is know to run well (operating on [[howto:FRAM]] for ages..). But it has following drawbacks:
+Implemented and running fine.
-  - it is hard to share weather informations on two RTS2 setups. And we have this encountered at [[howto:bootes:bootes 1]].
+====== Introduction ======
-  - it is hard to see which device block observatory
+Currently all weather checks are carried inside the RTS2 dome component. The nice thing about that is that there is a single instrument to fail and prevent the dome from closing. Also this single component can be easily tested and is known to run well. (Operating on [[howto:FRAM]] for ages...) But it has the following drawbacks:
-  - it is hard (requires some coding) to attach new weather sensor to observatory
+  - it is hard to share weather information between more RTS2 setups. We have encountered this at [[howto:bootes:BOOTES 1]].
+  - it is hard to see which device blocks the observatory
+  - it is non trivial (requires C-source editing) to attach a new weather sensor to the observatory.
 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, originally rather theoretical, should be tested and habilitated. //
 ====== Multiple central server ======
-Single device needs easily to connect to multiple instance of RTS2 running (e.g. cloud sensor need to connect to two RTS2 instances to provide informations to both).
+Single device needs to connect easily to multiple running instances of //RTS2// (e.g. cloud sensor needs to connect with two RTS2 instances to provide information to both).
+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, does not look like a big issue)
+  * 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 ======
@@ Line 22: / Line 33: @@
 requests to switch state and will generate warning email.
-Before system switch to higher state, it will ask all devices for an update. Devices state
+Before system switches to a higher state, it will ask all devices for an update.
-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
-mode switching was rejected. If all devices agree, centrald switch state and
+mode switching was rejected. If all devices agree, centrald will switch state and
-distribute message about switched state to all connected clients.
+distribute message about switched state to all clients connected.
-If during request for state of the devices any connection send command to
+If during request for state of the devices any connection sends a command to
-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.
-Centrald ask for state switching confirmation only if state is higher then the
+Centrald asks for state switching confirmation only if state is higher then the
 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
@@ Line 39: / Line 50: @@
 When centrald starts, it has two options:
-   - if uptime of the whole system, as deterined by sysinfo call, is bellow 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
+   - 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 will then enter grace period and wait for other devices to connect. After this period expires, it will check the list of connected devices. If any required device is missing, it will switch to off and write a message to the log file.
-   - 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 devices to connect. After this period expires, it will check list of connected devices. If any required device is missing, it will switch to off and write message to log file
+This procedure is implemented in order to not to close dome roof on RTS2
-This procedure is implemented in order to do not close dome roof on RTS2
 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.