Timed Delay Before Action

[wesley1226]

I'd like to start off by saying, I absolutely love this integration. It has performed flawlessly since I have installed it. One feature i'd like to suggest is a delay option. For example, I'm using a wyze plug to turn on/off main power to my printer. Upon client open, turn power onto printer, print complete, turns off the power. I'm not sure how feasible it would be to have an option such as after print complete, if no jobs have been started in the past 15 minutes or just a simple timed delay, turn off power to the printer. I'm new to printing so it may be unnecessary but I like to have the cooling fans run until complete cool down of all the parts or if i will be starting a new print soon not have a power cycle. Thank you in advance for any consideration into this request.

[eshapiro42]

This is a great suggestion! But you're right that there needs to be some way to cancel the delayed event if necessary. I'll look into this and see how feasible it would be.

[eshapiro42]

I've added the functionality you asked for in v0.2.0. You will need to either uninstall and reinstall the plugin or run pip install --upgrade OctoPrint-Wyze within OctoPrint's Python environment. After installing the new version, you will also need to restart your OctoPrint server since the database schema has changed. For the same reason, you will need to re-register any event handlers you had registered in the previous version as they will be wiped by this update.

Note that delays are specified in minutes (up to two decimal places are supported if short delays are needed).

The following is now included in the OctoPrint-Wyze tab, but I will paste it here because it is especially important for your use case:

If you are using the delay functionality, you will need to be proactive about manually cancelling any pending event handlers that you do not want to run.

For instance, if your printer is powered via a Wyze Plug which is registered to turn off 15 minutes after a print has finished, starting a new print will not cancel the pending event handler and your printer will be shut off during the print.

To cancel a pending event handler, simply unregister its corresponding entry in the table. It is safe to re-register it immediately afterward.

Please let me know if you have success with the update and if the changes are satisfactory!

[wesley1226]

Okay, I have been using this new update since release and it has worked flawlessly! The delay functionality integrated with both my plug as well as camera in all tested applications. The only issue I could find with the update was that of the event handler not canceling pending events due to new print job ect, that I will point out is clearly mentioned in both the response to the feature request as well as in the main information under the plugin page of OctoPrint. That being said, I still forgot about the delay I had set up which caused the printer to turn off unexpectedly. You must be very pro-active about the delays you have set up. As for V0.2.0, it is exactly what I had in mind and works exactly as expected.

For future updates, one more suggestion to help alleviate similar issues of forgetting about scheduled delays is to add an option such as "Cancel all delay events unless client is closed" or similar programmability. In no way do I wish to ask you to program and code a plugin for just my own use-case. I am very pleased with the plug-in as is and thank you for such as quick response as well as the update!

[eshapiro42]

These are all valid points. I'm sorry your printer shut off unexpectedly (that's the worst), and I sort of had a feeling this was going to be a side effect of the manual cancellation policy that currently exists. Some sort of "cancellation automation" is definitely necessary, but the precise design of that automation is not easy to pin down. As it stands, this feature is really only half-implemented until it is user-friendly enough not to ruin somebody's day.

Your suggestion is an interesting one, and one that I had not thought of. I think what might be just as useful, and would be more customizable for other people's use cases, would be to add a dropdown in each row of the table that allows you to specify which events will cancel a pending event handler from that row. For instance, in your case, you would open the "Cancel On" dropdown menu for the "Wyze Plug - Off" column, and select "PrintStarted" (as well as any other desired events). That way any time a new print started, any pending event handlers that would turn off that particular plug are cancelled.

Does this seem like a decent solution to you? It is the best and most customizable way that I could think of to handle this somewhat delicate situation. I could of course add your solution as an option too if you'd like that as well.

[wesley1226]

Luckily there were no active jobs and certainly no long prints in the works. That's what testing is for! I knew it would happen eventually as autonomous tasks aren't meant to be monitored but rather forgotten. It's one of those things you only do a few times during the learning curve. I believe with time, it would become habit to clear the policy if you were printing things consecutively.

As for your suggestion, I love the simplicity as it stands. I was able to install your plugin and customize it fully without any need for instructions. I believe adding drop down menus, event handlers and tasks to the interface could cause some confusion and require a guide on how to use your plugin. Not to mention the influx of issues that will be caused by people programing their own infinite loop and other strange results from people playing with options. I personally don't know much about the background operations of OctoPrint and even less about python. With a drop down programmability for each and every device on the account, plus the amount of events per device per on/off schedule, plus a delay function for each sounds like a very long if else tree. With drop down menus, I would ask for a reset all option somewhere and for extreme cases, a script to run via terminal to reset settings. The reset may be handled by uninstall/install but if somehow it is able to crash the server itself? Again, I'm not well versed in the operating system that is OctoPrint or how many people use it.

[eshapiro42]

I thought about it a lot and decided to add little "X" symbols instead of dropdown menus, but the functionality is essentially as I described. I do not believe infinite loops are a concern since the check-boxes and Xs only react to OctoPrint events and cannot be the cause of them. I've released v0.2.1 with this change.

You are free to ignore the Xs if you don't want to use them, but I myself find them to be a useful addition :)

Please let me know your thoughts and whether you think we're able to close this issue now.

[wesley1226]

Absolutely! I believe the X is the perfect balance between customization without over complicating the interface! I would absolutely say this feature request is fully implemented. Again, thank you for the quick responses and updates.