Cura OctoPrint Connection plugin

Are you running version 0.3.5 of the TasmotaMQTT plugin? I'm going to do some testing later tonight, but that's the version necessary for the Cura plugin to work.

I sure am. Updated it today and definately running 0.3.5.

So just did a test and I think the issue might be not having a relay number entered. Try turning on SetOption26 on your Tasmota device and then add the number 1 to your relay number field. Restart OctoPrint once you've changed these settings so the subscriptions get re-initiated correctly. Then you should see the option in Cura.

@fieldOfView, there does seem to be something weird with the MQTT plugin that I haven't debugged yet, but I've attached the log for your reference. It doesn't seem to be triggering the power on at all. And the autostart of the ufp uploaded file (if the UFP plugin is enabled in OctoPrint) doesn't seem to autostart. Disabling the UFP plugin and restarting Cura seems to work when just a gcode is transferred to OctoPrint. I assume it's related to the file getting extracted into a gcode and the Cura plugin doesn't account for that.

cura.log (205.7 KB)

Did some additional testing and the API endpoint is definitely functional. The below jQuery ajax call does work to power on the tasmota device with the MQTT plugin.

$.ajax({
                url: API_BASEURL + "plugin/tasmota_mqtt",
                type: "POST",
                dataType: "json",
                data: JSON.stringify({
                    command: "turnOn",
                    topic: "sonoff",
                    relayN: "1"
                }),
                contentType: "application/json; charset=UTF-8"
            });

The cura.log seems to indicate that it is sending the command to the correct endpoint but doesn't show the data being submitted. Are you submitting with post or get in your api call? Because if I change my ajax call to the below it doesn't work either so that's my assumption the reason it's not working.

$.ajax({
                url: API_BASEURL + "plugin/tasmota_mqtt",
                type: "GET",
                dataType: "json",
                data: JSON.stringify({
                    command: "turnOn",
                    topic: "sonoff",
                    relayN: "1"
                }),
                contentType: "application/json; charset=UTF-8"
            });

I'm about to start testing the regular Tasmota web based plugin now and might get to testing Wemo and Domoticz tomorrow.

With the regular Tasmota plugin there aren't enough variables being passed to the command based on the current logic. The below is a functioning jQuery call.

$.ajax({
                url: API_BASEURL + "plugin/tasmota",
                type: "POST",
                dataType: "json",
                data: JSON.stringify({
                    command: "turnOn",
                    ip: "192.168.0.126",
                    idx: "1",
                    username: "admin",
                    password: "",
                    backlog_delay: 0
                }),
                contentType: "application/json; charset=UTF-8"
            });

The Tasmota (non-MQTT) plugin will work without username/password being sent and the device isn't configured to require a password, but the backlog_delay does have to be sent as it's not getting tested for in my plugin. I would either have to refactor my code to work more like tplink and loop through the configured plugs and find those values based on ip/idx versus the Tasmota plugin sending those parameters from the web interface side, or make it a truly optional parameter the same as username/password (which I'm doing now for speed).

Edit: Looks like this is going to take some major refactoring in code making it more in line with the TPLink plugin logic. Running system commands and connecting to printer after power on is still being done from the javascript side instead of the python side, so the auto-connect option doesn't get triggered. I'll add that to my todo list. After making the backlog_delay parameter optional the Cura plugin was triggering the on command, however I still think the username/password fields need to be incorporated into the Cura plugin long-term.

The Domoticz plugin works the same way with username/password as optional parameters. Haven't yet tested it's functionality from the Cura plugin.

The Wemo switch plugin just requires the ip. I'm not even sure if those devices have the option to set a username/password, haven't messed with the one I have much. Cura plugin integration functionality for it is fully functional.

Thanks for trying the development snapshots. I don't have most of the smart plugs, so I rely on your feedback. I also sometimes make assumptions that might not be correct.

One of the aforementioned assumptions for the Tasmota MQTT is that both the topic and the relay number need to be not empty. If they are, I assume that the plugin is not yet configured, and it does not show up in the interface. Please correct me if this assumption is wrong (eg if it should be possible to use the plugin without a relay number, or without an MQTT topic).

For most of the other smart plug plugins I make a similar assumption that the IP and label fields have to be entered. Again, please correct me if this is not correct.

This has been an issue with UFP file support from the start; The plugin sent the .ufp file to OctoPrint with the option to "select" and "print" the file after uploading. But the .ufp file cannot be selected, let alone be printed directly; instead the extracted .ufp.gcode file needs to be selected and printed.

I have fixed this (this week) here and a new development snapshot also fixes some other issues.

For the sake of keeping this thread more "accessible", shall we continue the discussion on the different power plug plugins on github? Eg here: https://github.com/fieldOfView/Cura-OctoPrintPlugin/issues/141