Had to reorder message processing a bit in order to be able to
properly handle further resends in timeout situations.
Has the added benefit that "ok" now gets processed very early
and now extra state based processing is needed anymore.
Should prevent slicing result to contain bed temperature settings even if
printer has a heated bed configured unless slicing profile also contains a
temperature.
Fixes#1268
In case of trying to switch to state printing with no selected file that
scenario is now caught by setting an internal manualStreaming flag.
That will stop the M105 polling until M29 is sent (through whatever
means).
Note that printing is not disabled... this is merely for testing stuff and
not encouraged to be used for actually streaming files to the printer,
use the built-in functionality for that!
Use this carefully. An error reported by your firmware usually hints
at something being off about your printer (e.g. thermistor troubles)
or the firmware not being fully compatible to OctoPrint since
it doesn't recognize a lot of commands.
If you print with this option enabled, it will still fail if you firmware goes
into lockdown, but now it will keep trying to send data to your printer.
That might cause issues. So best not use that option, only if you absolutely
have no other way to get some misbehaving printer to work with
OctoPrint.
Also make sure that if we have a pkg_resources version that returns
tuples we not only remove any intermediary version parts if the base
version is requested, but we also append "*final" to the tuple afterwards,
otherwise the compatibility check will fail.
There was a problem with software update checks configurations stored in
config.yaml for which the providing plugin was then removed, since those
check definitions then lacked their default values to be merged on whatever
was stored in config.yaml, causing incomplete check configurations as a
consequence over which the plugin tripped.
This patch fixes that in that it tracks which check config keys are provided
by plugins and only returns those as the active check configurations that
belong to plugins that are still in the system.
TODO: This is only half of the solution. Check configurations of plugins
that are being uninstalled should be removed from the config if the
user decides to remove any settings by the plugin too. We need some
adjustments in the lifecycle tracking in order to make this possible
however, so for now this must suffice to at least prevent any errors from
occuring when incomplete configs are encountered.
(cherry picked from commit 8af8b8f)
Caused a KeyError so far, update definitions that are broken like that
will now just be ignored instead.
Closes#1057
(cherry picked from commit 2efc5c4)
* Allow configuration of checkout folder and version tracking type
via Plugin Configuration
* Display message to use if checkout folder is not configured or a
non-release version is running and version tracking against releases
is enabled
* Clear version cache when a change in the check configuration is
detected
* Mark check configurations for which an update is not possible with
a little exclamation mark
(cherry picked from commit 8666a28)
Also migrate for any config version < 4 (incl. None) and make sure
the other migrations may happen on top of that if necessary. Added
some comments to explain necessary migrations.
(cherry picked from commit f1075f6)
