Eric Callahan

As a heads up there has been a change that is likely to affect users that reported this issue. A new option has been introduced to the `[machine]` section named...

Right, as mentioned lmdb-tools provides a facility for transferring databases between architectures with mdb_save and mdb_load. The pylmdb package also provides one that I have not tested. Moving to another...

@ReXT3D This is likely the correct behavior. The `last printed` field is offered in the file metadata. That is, it applies to the *exact* file, if the file is modified...

Indeed, this should be resolved with the move to sqlite. FWIW, when Moonraker performs the conversion it does not remove the lmdb database, so a user can revert if something...

As long as the dependency is a pure python module and does not block I don't have an issue adding it. The biggest issue we run into is building wheels...

I do not think that `power.py` should be extended to report sensors on a switch, that is what `sensor.py` is for. The power module is exclusively for switch implementations and...

The [documentation](https://moonraker.readthedocs.io/en/latest/configuration/#toggling-device-state-from-klipper) regarding this functionality has recently been updated with further details. It is now possible to add `force=True` when calling the `set_device_power` remote method from Klipper, allowing the request...

It is possible, but not necessary as it can be accomplished by overriding `SDCARD_PRINT_FILE`. The majority of printer builds don't separate logic from peripherals, in such cases it is not...

I'm moving the discussion from the PolicyKit thread to here, since that issue isn't the proper venue for debating new features, removing features, or changing Moonraker's method of installation. I'm...

> Your point is absolutely fair, however, this approach works only for existing users of Klipper/Moonraker. To be fair, I think most users are ok with installing Moonraker in containers...