I'm not entirely sure what version this "bug" started to present itself, but as of Cura 2.3.1 it is definitely an issue. I never store material temperatures in my GCODE. Partially because I like to change materials a lot, and mainly because even among PLA or ABS suppliers, filament varies and I often find that 5-10°C differences in my material printing temperatures are needed depending on filament brand. My general workflow is to design a part, export it as an STL, slice that STL in Cura, and then store the GCODE file inside of OctoPrint for future reprints of that part, without needing to re-slice in the future. For that reason alone, storing a material temperature in the GCODE itself makes little sense. Cura's process of selecting the model, printer, material and preset really only makes sense if you're physically printing from Cura, which I would guess is not the norm given how many people are using non-Ultimaker printers, and printing from solutions like OctoPrint.
The way Cura behaves in this regard is a little odd. If you don't add a printing temperature to your preset, Cura will add a “M109 S0” to the start of your GCODE during slicing. Effectively telling your printer to set it's temperature to zero. You've now preheated your printer to the correct temperature for your material, hit print, and nothing happens since your printer is now waiting for the temperature to be set to zero.
I've been reliably using OctoPrint on a Pine64 since I wrote the original two parts (Part 1, Part 2) of this series back in January. I was a bit behind on OctoPrint updates (running 1.3.2), and took the opportunity this weekend to upgrade to the latest stable version (1.3.4), and add in the custom action I've been meaning to create for remotely powering up my 3D printer.
I've been using a Ubiquiti Networks mPower-Mini to control power to my 3D printer since day one. In addition to providing remote on/off capabilities, these devices also allow you to track and trend power consumption and other metrics. Ubiquiti has unfortunately ended development of the mFi controller, but these devices are still manufactured for users willing to script their own interface to them. I've been working my way off of my existing mFi controller for this reason, and figured it was time to connect my mFi switch to an action inside of OctoPrint. This allows OctoPrint to issue the on/off commands directly to the outlet, without needing to login to the mFi controller, portal, or mobile app.
I had a couple Pine64 boards sitting in a drawer, and decided it was finally time to replace that old Raspberry Pi running OctoPrint (err, OctoPi) for my 3D printer. The Raspberry Pi has served admirably, but it was definitely time for an upgrade, and a chance to improve a lot of my overall printing workflow.