Wrong Z position when using relative movements

[asciipip]

When a print's gcode includes relative movements, those relative movements are written to InfluxDB as if they were absolute values.

Here's the specific behavior I'm seeing:

I'm using OctoLapse to record timelapses of my prints. I have OctoLapse set to Z-hop the hotend up 0.4 mm before moving it out of the way for each photo, to prevent the nozzle from dragging across existing lines. OctoLapse does this by inserting relative movements into the gcode stream. In my case, that means sending G91, G1 Z0.400, moving to the snapshot location, moving back, and sending G1 Z-0.400, G90 (the last because my prints otherwise use absolute positioning).

That shows up in the InfluxDB database like this:

> SELECT current_z FROM progress WHERE time > '2024-10-18T14:03:20Z' and time < '2024-10-18T14:03:26Z'
name: progress
time                        current_z
----                        ---------
2024-10-18T14:03:20.40794Z  6
2024-10-18T14:03:20.631068Z 6
2024-10-18T14:03:22.798683Z 0.4
2024-10-18T14:03:22.842193Z 0.4
2024-10-18T14:03:23.929142Z 0.4
2024-10-18T14:03:24.002798Z 0.4
2024-10-18T14:03:25.157071Z -0.4
2024-10-18T14:03:25.200298Z -0.4

During this time window, I should instead be seeing sequential Z values of 6.0, 6.4, and 6.0, because that's where the hotend was actually positioned.

[agrif]

This is surprising to me, as the plugin simply reads the currentZ field.

Doing some digging, it looks like this is an old relic in OctoPrint, and right now OctoPrint avoids tracking the location for some pretty compelling reasons. I used to think I should add a state tracker to this plugin for info like this, but having read that FAQ, I think I agree that's the wrong solution.

It might make sense to query the printer periodically for this info to send to Influx. This would be a somewhat big change, since right now all the plugin does is shuffle data from OctoPrint to Influx without any active querying.