cantsin / imls-pi-stack Goto Github PK

Can we count on this to happen before we run? Does this happen in the playbook/service unit space? Does it ever "undo" itself? If so, should session-counter be doing this work instead of the unit files?

Or, should we have a unit file that just makes sure we're in monitoring mode?

The duration stamp is normally written "inside" the duration bar.

When writing short durations (>10m), the duration overlaps with the timestamp of the start, because there is not enough room to write the stamp in the image.

We should write it to the right of the duration bar in those cases.

Our initial build did not reboot reliably. As a result, some sessions spanned many, many days.

The tool in imls-data-convert does the following:

• for each session in the data
  • for event in the session
    • Remap mfg id, patron id
    • set session_id to the day

The problem is that some sessions will start and stop on the same day. The result is a broken merge of sessions.

More thought is needed. The reason for going session-by-session is because the mfg id and patron ids change from one session to the next. Perhaps clearing the mapping table, but not the counter... I think that would work.

We want to leave a clear breadcrumb trail for users.

If there are no durations in range when it comes time to write an image, we should leave an empty image behind (or, something) when we encounter the situation where everything is filtered out (or no wifi devices were ever found).

The installation process here:

https://github.com/cantsin/imls-pi-stack/wiki/SoftwareInstallation#installing-the-os

walks through what the shim does. Should the setup be that they copy-paste a github shortened URL?

bash <(curl -s -L ...short url...)

When entering wordpairs, we should have a restart option, in case a typo is made or a pair is skipped.

We should probably also... just finish when we hit 40 characters read in. There should be no reason to type done.

Instead of a counter in the DB, it might be better to just ask what DISTINCT session IDs are in the durations table (at startup), and then increment by one.

If we do this every time we startup, and simply track the session ID in RAM as we execute, we'll always have a correct session ID, and we can eliminate a piece of state.

(I think. That bears more thinking/discussion. But I wouldn't mind removing an explicit piece of state when it already exists somewhere else, and the possibility of it getting out-of-sync is real.)