Determine what parts of "Facility Summary" we need to display and what format we should use to display it.

[astrobokonon]

@dyerlytle I suggest starting with the information that the IGRINS proxy displays and going from there in terms of additions/deletions. The vast majority of it is already in the TCS LOIS packet coming in at 1 hz, and the light path information topic as well. Parsers are in amqparse.py:parserLPI and amqparse.py:parserFlatPacket respectively, though the former actually uses an XML schema for validation found in ligmos/schemas.

Unsure whether it's better to hook into the broker directly, or to pull the information from my database periodically. It ultimately needs to be tested to see which is both more stable and less stressful on everything, my gut says the latter but it's hard to tell.

One interesting option is to try out an in-memory database such as Redis. That's something I've been thinking about for instruments to hook into to get the last value of something without having to cache broker topics themselves, but we'd need to have a relay of some sort to shuffle the information into Redis. There are automated solutions for that (Apache Camel comes to mind), but a more hand-crafted approach might be better to make sure things don't turn into another confusing jungle.

[Teznie]

I find that for this kind of application the FacSum has too much information on it, but that most of what we might want is there. So @astrobokonon's suggestion of starting there is a good one. Heidi (@hlars-freehub) had a good suggestion the other night but I don't recall it. I will get her to check in.

[hlars-freehub]

Astronomers ask for the sunset/rise & twilight times fairly often, so that would be useful. Other definite things are UT time, LST, HA, light path (fold mirror, M1 cover, instrument cover, filters), focus, and moon proximity. I think the idea about having pop-up warnings, perhaps with an audible pip, is a good idea for wrap & keyhole limits, dome occultation when they are near (starting with 30, 20, 10, 5, minute warnings).

[dyerlytle]

Displaying Facility Summary Information

We can use Bokeh again to make an updating text box to display facility summery data. The image below shows a web browser with a bokeh plot running that is updating every second. There are various styling attributes that can be used: font, font size, font color, background color for each text string, background color for box, border color, etc.

[dyerlytle]

The list Ryan and I came up with yesterday: Facility Summary:

• UTC
• right ascension (current and demand)
• declination (current and demand)
• air mass
• target name
• guide mode
• mirror cover
• dome shutter
• instrument cover
• fold mirror status
• moon distance
• (warnings, what we have now, add others when they become available.)

[astrobokonon]

@dyerlytle and based on @hlars-freehub comment above, sunrise and sunset times should be in that list too and they'll be in the initial prototype that goes up.

We were ambivalent about LST & HA, so they might not make the initial version but can easily appear in the next since they're possible to get from the TCS (LOIS) status packet too.

[astrobokonon]

Initial testing version(s) now done. For this one I didn't include sunrise/sunset times or LST/HA but they can go in pretty easily. Focus is missing but I can add in totalFocusOffset easily as well as the relative/absolute ones.

I decided to break it down into two distinct tables; one for TCS type information, and another that breaks down the various light path information components. Again - this is just to get everything actually functional and in place.

TCS information:

"cRA" is current RA and "dRA" is demand RA - Dec & Epoch follow suit. Presentation definitely needs work.

LPI information:

There are checks for stale data being done, but the results are being ignored for now.

[astrobokonon]

Closing this for now since we have a plausible framework; see https://github.com/LowellObservatory/NightWatch/tree/master/_proto/influxdb_grabber for the toy model.

The .conf templates are out-of-date, but since it's just a toy I'm leaving them to focus instead on the integrated version that will run with the rest of the webstack.

The rest of the details are really implementation considerations (style, coloring, etc.), which can be handled in a new issue after we get the alpha version up and running.