TLDR: What trigger should I use to turn off a smart plug in the event of a possible hardware failure causing heating issues? Is it just as simple as PrintFailed?
Firstly, thanks everyone for all of the amazing help and articles I've been able to find in getting mostly everything set up for my printer. I've got event handling done due to some great guides and plugins, almost everything is running exactly as I want it to.
But I am in the middle of some prototyping, and it's going to involve some 20+ hour prints that I won't be able to monitor in full. While I realize that I should probably be fine, it would put my mind at ease knowing that I could automatically cut power if something starts to behave improperly in my absence.
So what event, gcode, etc. could I use to detect a possible hardware failure that is causing a loss of control of the temperature? It looks to me like maybe PrintFailed, but I don't want to make any assumptions. What would PrintFailed catch?
You could first check if your printer firmware has some form of protection. Marlin based printers should have that enabled but some manufacturers don't bother or disable it. I know Prusa I3 MK3 has it in firmware and will cut power to bed/nozzle if either the temperature sensor is faulty or the reading is not plausible such as reading no temperature increase despite powering nozzle or bed.
I knew I had seen videos on the issue, I have just found them in case your printer IS Marlin based how you can enable thermal protection if it is not enabled by default.
I have flashed a firmware to my ender 3 that enables thermal runaway protection, but i've read that a common cause of the failure is a mosfet failing closed and the software being incapable of turning that off. If it's something I have to live with, then I can suck it up. But it would be preferable to cut power to the unit itself if octoprint already has an associated event for me to use.
Uh nasty ! Off the top of my head I would probably do this as a shell script running in the background calling the API to get the target temperature and the actual temperature, compare that and react to that. You could try issue the following on the command line and check if you can somehow work with that:
I'm sure there are several approaches to get this done, but just to make sure the functionality isn't already there: what triggers the print failed event?
If the thermal runaway in the firmware is thrown, I would imagine it tries to kill the print and might cause the print failed to trigger. If that's the case, I can webhook that event and take it from there.
Instead of PrintFailed (which does get triggered on firmware errors too but without information about the error attached) I'd suggest to take a look at the Error event instead, which does contain the error message from the firmware.
Thermal runaways in particular aren't (and due to their nature cannot be) detected by OctoPrint - only the firmware knows whether it's currently pushing full power to a heater but not seeing any response in the attached temperature probe. Just monitoring the temperatures reported by the firmware will not be safe, they could be false due to a probe that's fallen out and it's not possible to say whether that's the case or the heater is just slow.
So just to confirm, because the Error event is listed in the documentation to specifically reference communication errors. This should also catch various errors like thermal runaway?
If I have the "Error" event trigger a webhook to shut down the smart plug (powering the printer) and send me the error message, that should conceivably offer me an additional layer of protection in the event that the firmware itself can't cut off power from the heating elements? Are there any other considerations I should make?
I apologize for the naivety and appreciate the assistance.
It will catch anything that the firmware sends that starts with Error: or !! and which OctoPrint can't handle. That includes (usually) Thermal Runaways, but also other fatal errors.
Looks like I'll need to adjust the docs here slightly, the way it's phrased now is misleading since recoverable errors in printer communcation (e.g. line number mismatch) are in fact not triggering this event.
