hmm, so, with the challenge being that the PI is most likely to determine that it's connection to the Printer is port 2, is a possible solution, bluffing it into thinking that there is something else (not of consequence) in port 2, so that then the printer connection (and webcam) move into the ports 3/4/5 space, and are then individually switchable - I was thing of plugging a old USB memory stick (finally, a use for the old 256Mb sticks) in, the hope that it "picks up" the port 2 assignment, freeing everything else to be separately controllable? Any thoughts/ideas/references as to what/where/how the Pi Port prioritization happens... Heck, even plugging in an arduino that does nothing more than asserting a high priority level, might be a solution....
Uh, no. It doesn't work like this for the Raspberry Pi 3B.
- Port 1 is the power for both wi-fi and network adapaters
- Port 2 is the power for all four of the USB Type A connectors
You would think that it would work in a more intuitive way but that's just not how they did it at the Raspberry Pi Foundation. They put two USB (ganged) buses internally and connected them to what I've suggested above. There is no individual switching as a feature.
In theory, one could connect a smart external hub and then switch on/off the individual ports of same.
Note that the Raspberry Pi 3B+ is expected to behave slightly better; I will know when mine arrives.
I need another pi (like 5 already isn't enough) - might put in an order on a 3B+ on spec, anyway... Even if it doesn't do this as hoped, I can find another use for it...
I also purchased a Raspberry Pi 3A+ for testing. Unfortunately it has no smart hubs inside. So this one can't be compatible.
I connected both my pi and the printer to a meross smart plug. I can turn either on and off from anywhere. Amazon sells them for about 15 dollars each.
Hi there - I'm completely new here but have a question about using @jneilliii Wemo plugin. Is it possible to trigger the switch if the printer sends an Emergency Stop command? Specifically what I'm looking to do is turn off power to the printer completely (trigger Wemo Off) if there is a thermal fault detected by the printer.
Thanks!
My plugin can't do it currently. I have feature requests to add that functionality, just haven't had the time to work on it.
Oh - Awesome! Thanks.
And thanks for the quick reply!
Here is what I do. I have a TP-smart plug plugged into mains. It has an extension cord with 5 outlets on it. My optopi pi is plugged into that and my printer is alwo plugged into it.
I have node-red installed on the pi running octoprint. This node-red has a flow that is listening for a suttdown command. When it gets that is issues a shutdown of the Pi.
I have another pi (a pi zero w running mqtt and node-red) This node-red can shutdown everything one of two ways: Manually or automatically. The automatic mode works by listening for an end of print message (remember this is the pi zero w) from octoprint and then it waits 20 minutes for any more activity. If there is more, it goes back to listening for an end of print message. If it doesn't hear anything for 20 minutes, it sends the shutdown message to NR runing on the octopi.
It then waits a minute and then sends a poweroff command to the TP-smart plug which turns off power to the Pi and the printer.
The manual method does the same thing. I go to the NR dashboard of the pi zero w and press the poweroff button and it sends the ssshutdown commane then the power off command. Works great.
If anyone wants the two flows just let me know.
That's cool.
I currently use the TP-Link HS style of smart outlets myself. I was just mentioning on here that they now have an individually-controllable power strip which you might be interested in.
I'm working on adapting control of the strip into the TPLink-Smartplug plugin this weekend.
Thanks to the wonderful assistance and debugging from @ridencww I just released a new version of TPLinkSmartplug that supports the strip. For the ip address enter in the ip of the strip connected to wifi followed by a slash and the 0 based index of the socket itself on the strip. For example 192.168.0.2/0 would be the first socket in the strip, 192.168.0.2/1 would be the second, etc.
I just installed the latest update of the plug-in and see that the Thermal Runaway Monitoring is there now. AWESOME!! Thanks so much for working on it! Been loving the plug-in as it was so far. Will let you know if there's any issues with this version. Do you have any recommendations for max temps? I set them to 20C above stated max temps from the MFG. Any thoughts?
Not really. I'm still working on updating that 0.9.16 version after finding some bugs and making a couple of more improvements to the graphing for energy monitoring and some TouchUI compatibility related changes.
I'm also new to printing and am using your wemo plugin. I'm having a problem where the I lose the serial connection to the printer as soon as I hit the print button. No problems in safe mode, I eventually narrowed it down to your plugin. NOTE: I'm still running the stock firmware that arrived with my cr 10s. I have a feeling this might be causing it, since I see a thermal runaway protection warning. Upgrading to Marlin is my next step either way, but after seeing this post figured I'd just ask the author. Do you have some kind of protection in your plugin that checks if the printers firmware has a TRP feature, like the stock Creality firmwares seem to lack.
Anything show up in the logs? Very basic TRP is in the plugin, but a failed thermistor wouldn't work. It's really just monitoring I'd the reported temp is over a threshold.
I was able to play around more with this. Here's the log from today. The only thing I did was change the hotend temperature while the RPi was connected to the Printer board via Serial. Octopi immediately disconnected as soon as I pressed the 'Set' Temperature button.
octoprint (1).log (20.2 KB)
And it doesn't do that while the plugin is disabled? There's nothing really in the log indicating an issue.
So I've been able to get the printer to start when I disable TR Monitoring or if I just disable the plugin altogether. I have to think it's the stock firmware causing the issue, I'll try and get that done and report back.
Actually if you enable debug logging, restart octoprint, and then cause the error to happen, grab the plugin_wemoswitch_debug.log and looks for errors in that.