Consider a database

[astrobokonon]

I could do the temperature statistics way better and just have an async process in another container that just grabs the temperatures, all the time, and stores them in a time windowed database. It would then be a better match with the developments that have occured with Mr. Freeze, and not that much overhead considering everything can just still run on the Pi.

I'm almost tempted to say that it might be better to consider another database, but influx makes this so easy it's probably not worth that extra effort.

[astrobokonon]

The current implementation of the temperature statistics just plain sucks, so I'm going to do this. It's worth the effort and it'll give a pathway for Mr. Freeze upgrades and enhancements.

[astrobokonon]

Going to do the separate/async route in a separate code and tear out the crappy implementation in printzini and the printer module. Printzini will have to query the database for the statistics that he needs, but that is the only foolproof way to avoid capturing the warm-up/cool-down in the temp stats anyways.

[astrobokonon]

Done as of ca300d1a77bd1d5e36e973cfd1e10eb0ce401d13 and it works great. Still working on Printzini side of things but this is now 90% done.

[astrobokonon]

If I do this right, I can also figure out the structural changes needed to fix the old issue in NightWatch relating to database queries that come up empty (see NightWatch#37). So I'm going to try to do that.

[astrobokonon]

Hooray, I found this buried in the Ultimaker griffin code (griffin/printer/drivers/marlin/applicationLayer.py)

    ENCODE_JOBSTATE_AS_NUMBER_TABLE = {
        PrintJobStateProperty.NO_JOB: 10,
        PrintJobStateProperty.PRINTING: 0,
        PrintJobStateProperty.PAUSING: 11,
        PrintJobStateProperty.PAUSED: 12,
        PrintJobStateProperty.RESUMING: 13,
        PrintJobStateProperty.PRE_PRINT: 14,
        PrintJobStateProperty.POST_PRINT: 15,
        PrintJobStateProperty.WAIT_CLEANUP: 16,
        PrintJobStateProperty.WAIT_USER_ACTION: 17

That should allow me to translate between "active_hotend_or_state" stuffed into the TemperatureFlow API endpoint.

[astrobokonon]

Next step: move the db off the pi. It's bogging down with this much data and querying, so I'll spin up a db on the VM and just use that one. Debatable whether I should move the tesseract page to that as well, I probably should and just use the pi as a collector.

[astrobokonon]

Just realized that I don't have to query the temperatureFlow endpoint, the 'state' parameter is in the print_job endpoint. Duh!

{
  "datetime_cleaned": "",
  "datetime_finished": "2020-02-05T01:36:17",
  "datetime_started": "2020-02-03T20:28:24",
  "name": "UM3E_FOG_Cover_S_metric_right_top",
  "pause_source": "",
  "progress": 1,
  "reprint_original_uuid": "",
  "result": "",
  "source": "WEB_API",
  "source_application": "Cura connect",
  "source_user": "",
  "state": "wait_cleanup",
  "time_elapsed": 104035,
  "time_total": 104033,
  "uuid": "6dd8d59f-388d-458f-8ba2-a0cec761045a"
}

[astrobokonon]

Now just working on the database query, and using the select key to only grab points stored since the print began and where "active_hotend_or_state" == 0 (which indicates active printing).

[astrobokonon]

As of pull request #7 the title is complete. I have considered a database and used it.

Now I just need to finish the details.

[astrobokonon]

Note: This is still open because I had to move on to other stuff. The db query between some intervals code was completed for the Mesa cryotiger monitors, but I haven't had a chance to move that over into this.