I've been trying to read all the topics related to powering off the printer and raspberry through a command, using relays or similar. In my case, raspberry is fed from the printers PSU and a sonoff switch powers the printer (and hence the raspberry)
I can do all I want manually and remotely, by using e.g. Printoid to shutdown the Pi and the sonoff interface to shutdown.
now, if I flash the Sonoff, I can from the Pi issue a (Sonoff) poweroff.
I see two problems with this:
when issuing the (Sonoff) poweroff, the Pi kills its own power before it can shutdown.
power down with a hot extruder is not recommended, as the extruder cooling fan will also stop.
So my questions are:
Is there a solution for operating a modified switch as discussed here that also cuts of power to the pi?
Do the shutdown procedures discussed here consider the extruder temperature in a safe manner?
Sorry if I missed possible answers on this in the forum, but I couldn't find any: my bad...
Maybe this one is a step into your direction. Instead of controling an ATX PS, you also can use relays to control regual PS.
There is also a plugin that shuts down the RasPi at the desired nozzle temperature.
Thanks for looking into it and for your answers. I am also happy that there wasn't a quick solution that I had overlooked...
That looks indeed like one step. In fact, given the fact that a Sonoff switch is programmable and we flash it we could change the Arduino code and include this timer function. Maybe it is even there already, as the Sonoff in its natural form supports scheduled switch off. So you can program it to switch off in like a minute later...
Unfortunately, the ATX provides me another problem, as my printer is a Prusa MK3/MMU it runs on 24V.
The plugin for the temperature controlled shutdown, targets a TPLink device, might need to get that one, though I like seeing how much kWh my printer consumes, the Sonoff I currently use does that. Note that however it does not prevent shutdown when temperature is too high, but at least it schedules it.
Coming to think of it, I think it needs a script that ideally:
Registers a desired shutdown, either by a button, or from a remotely operated script.
Ensure that temperature is going down, by aborting an active print
Schedule a temperature 0 (in case no print was active, but it was e.g. preheating)
Wait till the temperature is lower then 50 C
Schedule a timed power off to the external relay device
shutdown the rpi
The plugin that you pointed out is pretty close and has most building blocks in it, be it there are still pieces missing as far as I can see.
If I take them step by step, in bold the problematic ones:
register shutdown: a button connected to a GPIO.
Script: you can run a python script to make the software believe a GPIO is triggered. - Schedule shutdown: can we abort an octoprint job from the command line? We could abort the whole octoprint, but then we cannot easily monitor the temperture... So it needs to specifically stop streaming print commands.
Schedule the temperature 0: send one Gcode for doing that. - Wait till temperature lower then 50C: the plugin could do that. - Schedule timed out power off to an external relay: your hardwareseems to do exactly that, but it would need to drive a relay.
shutdown rpi: piece of cake, sudo shutdown now
Maybe there is even something closer out there living in the unknown?
This one is tricky because you are powering the pi from the printer's board. I accounted for this in my TPLinkSmartplug plugin by utilizing it's built-in scheduling/timer/countdown functions. I might be able to do the same for a sonoff flashed with Tasmota, assuming Tasmota has that functionality, I'd have to investigate.
That plugin will actually work with a wide variety of devices, as long as their is an API available to use. It's worked with my Tasmota, Domoticz, and TPLinkSmartplug plugins. It was a plugin developed to add additional functionality to the ones I had programmed and then expanded to include generic api/web calls, etc. There's better documentation on the repository's page.
From what I can see in the Tasmota.ino, there is support for a feature called "PULSETIMER", however that allows for switching the relay off after a configured time of switching in on. This might allow for a switch that is regularly on, to send it another "switch on" with pulsed switch off, but I'm guessing here.
Some Tasmota issues request implementation of scheduling, but they are rejected, and are recommended to do from a server.
Other entries suggests there is scheduling functionality now, but I could not find it on their wiki. In the Tasmota.ini there is an interpretation for calender date and time, which indicates some functionality, but that could also be related to MQTT support..
Well... to make a long story short: I found a forgotten Raspberry Pi powered USB-HUB with UPS. It has a 3.7Ah Lipo battery (which was dead now, so I hope it still works). I'll stick the Pi to that hat and then can power off the printer and then take all the time I need to shutdown the Pi...
Indeed, these rules look very promising, more options now then I can implement in a short time. That would then the only thing I now need: a few buckets of time...
Why are you powering your pi from the printer PSU? That is the issue. Move it to it's own quality supply and then you can control everything how you want with relays.
This then is combined with the KASA App and/or the Alexa skill (Echo Dot next to printer) to turn on/off the TP-Link device with voice control.
In turning it off, there's a separate Alexa skill for "shutdown the printer completely" (shutdown OctoPrint) followed by "turn off the 3D printer" to toggle the power.
I participated in this dialog before, and did not want to go the Tasmota route for my Sonoff plugs. Instead of going down that road, I directly implemented *all activities in the plug itself. The plug even shows messages on the LCD, to better understand what (will) happen(s). You find the sketch here: https://github.com/ruedli/OctoPlugout There are also detailed instructions / steps to follow. It will work for any ESP8266 / ESP32 relay, as long as you configure the pins that are used. As provided it supports Sonoff devices.
Thnx for looking into this! I reviewed the links you provided, but have trouble envisioning how to exploit this. In principle I can GET information from the API and also POST data (for shutdown and sending M117 gcode) but I was looking for a way to communicate to my plugin, through gcode.
Currently the plug can be in two modes, “Always on” or “waiting for a started printjob, waiting for it to finish, and waiting for the extruder to be cool down enough”, after which shutdown and delayed poweroff is executed.
I always start in the automated waiting for save shutdown mode.
I would prefer to react to a custom gcode in the printjob, to set the state of the plug in one of these two modes. This allows for better control, I could e.g. then trigger shutdown (only) at the end of the gcode file, or even force a shutdown, even while the printjob is active (hanging mmu at final unload, forcing cool off and shutdown). Does the suggested webhook provide this? Does this require anything in octoprint, or is the webhook sufficient? Let me know more on how you see this implemented.
You choose what happens on the arduino side based on the post data to the rest api. So I would think it would allow you to do what you wanted. You will have to have some form of octoprint plugin to process gcode commands in order to send the post message. That side is trivial for me (ie in tasmota plugin for example) but the arduino side is not. If you can get the arduino side working I can easily put together a plugin for you.
Hi Jim, what you suggest seems to be different from what I had to mind to accomplish. The followed links allow to call an API (that could access a REST API in the plug) and provide information. This is different from the interface I had in mind.
What I had in mind was this:
A "special GCODE can be embedded by the user. It has one parameter (PlugMode).
This GCODE is detected by Octoprint (the plugin? Or use the existing system command plugin??
This results in a state in the Octoprint REST, which is "set".
The plug (my arduino program running in the plug) does a GET of this state and POSTS that it has been read, which resets it in the Octoprint REST API.
The plug (its arduino program) processes the state, thus implementting what was requested in the GCODE by the user.
I can do 4 and 5, provided that I know where this state is and how it can be read and reset. (This should be defined).
I do no know how to do 1 and 2. Problems:
I do not know which part of the octoprint API can be used for this type of communication. Where in the name space / data space should this be hung up?
I do not know the most suitable way to embed this GCODE command. I see three ways, but there might be better ways:
a. A M117 command with a "special" message format.
b. A "comment" that holds the message with its interpretable payload (PlugMode)..
c. An embedded system command, with a script that runs and sets the part in the octoprint API.
Or something else?
These parts "1" and "2" needs some design thinking and implementation either in existing functionality, or in a new plugin? This was what I was seeking help on.
Ok, I get you now. It's more of a fetching of data that is queued inside a plugin on the octoprint side that is monitoring the gcode. So more of a pull client rather than a push client. You can use the SimpleApiPlugin mixin and then monitor for queued data to send using the gcode phase hooks, or gcode received hook and utilize an M118 my_command method to send a trigger back from printer to octoprint. This is good for near real-time to printer operation (accounts for buffer and allows for support of printing from SD I think). So then whichever collection approach you use, the payload you want to utilize on the arduino side can be buffered up and then when your esp device requests your created api call to the server you provide the data and flush the queue.
Edit: You'd end up using on_api_get in the plugin for the fetching part, and then on_api_command for the "I've got the data, clear the queue" part.
Yes, you understood my objective well! The complexity is not in the implementation (nor python, done that extensively as well before), but in learning how to write a plugin and fit it in the Octoprint framework. The mixin with the SimpleAPIPlugin is very illustrative, need to study that and proceed from there. I "just" wanted confirmation that my efforts for diving in the plugin world is not for nothing, in the sense that everything could be done with an existing set of plugins. I fully trust your assessment on this, so I can proceed with comfort. No doubt my questions on the interface will be sorted out as I proceed, so thanks for your analyses!
PS: I found out the the M118 (which I liked better than M117) is not supported on my firmware (Prusa MK3S /. MMU2S, it sends back an "unknown M code") So I'll probably rely on M117.
