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.
That's unfortunate, the only difference would be that the gcode hooks will be handled only from printing from octoprint local files and the collection action for the queue will happen prior to the actual gcode operation on the printer, so timing could be a concern.
You might consider looking at event mixin for print complete, print started kind of stuff.
As for creating the plugin, I highly recommend the plugin tutorial on the docs site and there are one or two videos in the code and chat series by Gina that create a plugin start to finish.
I can live with execution from local octoprint print files only. Timing compared to execution on the printer is not critical. I would imagine GCODE only results from embedded commands executed as the "after print" routines, but before the "unload" filament, or: from a "button" press in case of an emergency.
I already started with the tutorials
what does not help, is that the functionality of OctoPlugout is already quite nice without any additional plugin features. so this is not a great trigger for getting something done
Not sure if this will be useful to anyone, but I just wrote a quick script that I use with the OctoPrint plugin PSU Control to turn my eWeLink smart plug on and off. This is the link if anyone is interested: https://github.com/jasonappah/ewelink-plug
Solved: objective covered. I integrated mqtt in octoplugout and with your octoprint mqtt plugin octoprint can talk to the plug and request a shutdown, which then will be done when it is safe. I also implemented configuration from a wifi AP, or from a portal page (once wifi credentials are provided), so I can plugin a plug "everywhere" and then configure wifi, API string, octopi IP address, mqtt server and credential and it will run.... OTA upgrades was already done, so now it has all I want. With the mqtt plugin I could create a pulldown in octoprint for safe shutdown/poweroff.
With this new functionality it is open to a much larger public. If you have tried it: consider upgrading, if not: have a go. Latest source is still at https://github.com/ruedli/OctoPlugout
