statistics: Extend system stats with unixtime

[denis-efimov]

For the moment, it is not possible to make macros based on the host's system time, such as bed leveling once a day or turning things on and off based on real time.

Extending system stats with unixtime, we bring the possibilities of macros to a whole new level.

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[github-actions[bot]]

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[30350n]

Hey! I'm currently looking into creating an air filter (nevermore) timing macro to track the time the filter has been used and this is exactly the functionality I'm looking for. The change seems relatively small and straight forward, could this get reviewed and merged?

[pedrolamas]

I think you would be better adding this as a Jinja2 function (check rawparams implementation, you can add a function on that level) than as part of a status object.

The reason be that a change in a status object will be pushed to Moonraker, and that will trigger a bunch of other stuff that seem unnecessary to me...

[30350n]

But wouldn't the function work similarly to the action_ functions then? Here it states that:

these actions are taken at the time that the macro is evaluated, which may be a significant amount of time before the generated g-code commands are executed

which would be suboptimal for a function which is supposed to get the current time, right?

[Arksine]

The get_status() methods used to update printer status are also called when the macro is evaluated. There would be very little difference between the method outlined in this PR and adding time.time() to the Jinja 2 context. All expressions in a gcode macro are evaluated, then then template is rendered, typically resulting in one or more gcode commands. These commands are then queued for execution. If anything is blocking the gcode queue then the execution of said commands will be delayed.

[30350n]

Thanks, that makes sense. In that case here's a new PR: #6010