Open FrancYescO opened 3 years ago
So sub-plugin support works by other plugins implementing the required methods and registering with PSUControl.
While not explicitly required I would recommend that sub-plugins be PSUControl specific and have their plugin id prefixed with psucontrol_
and the display name prefixed with PSU Control -
. Doing so simplifies the user experience as well as debugging.
I'm currently looking at creating a sub-plugin that provides TPLink support but only out of interest in the hardware. The plan thus far is to implement simple switching and sensing support, nothing more.
If someone wants to provide a Tuya plug I can take a look at creating a sub-plugin for it.
if you want i can somehow expose to you my octoprint instance with ssh and webui
if you want i can somehow expose to you my octoprint instance with ssh and webui
Appreciate the offer but that isn't really something that will be efficient or sustainable for long term support.
If anything I'm sure someone out there with a plug will write it. All of the heavy lifting gets done by PSUControl so sub-plugin dev is pretty straight forward.
may i ask as simple workaround to add to the sensing select to add "if connected to serial" as actually having the USB power pin isolated, octoprint should consider my printer powered simply when connected to the serial
is there any way to integrate with this plugin with https://github.com/ziirish/OctoPrint-TuyaSmartplug ? (my main objective is to use the poweroff while idle feature)
i've tried to used the GCODE mode as workaround (as also the tuya plugin have this option) but while to poweroff works ok, the poweron/sensing have no way to use as i cannot send the GCODE while printer is powered off (so no serial connection) and sensing plugin shows nothing in the selectbox (and the internal method never reveal the printer turned on unless i click on the icon)