The temperature offset does not work

[MarshMalloW0007]

The problem

In my code, for the first layer, the temperature of the nozzle is 185°C and for the bed 10°C.
For the following layers, the temperature of the nozzle is 180°C and for the bed 5°C.
I put the offset at 40 to obtain 225/50° C for the first layer and 220/45° C for the other layers.

The preheating phase goes well and the temperatures are respected.

During the printing of the first layer, the temperature of the nozzle goes down to that of the gcode, 185° C and goes up again to 220° C starting from the second layer.

The temperature of the bed is not impacted by this "bug".

I tested on two installations of Octopi and the screenshots are made with the virtual printer

Did the issue persist even in safe mode?

Yes, it did persist

If you could not test in safe mode, please state why

No response

Version of OctoPrint

OctoPrint 1.8.6

Operating system running OctoPrint

OctoPi 1.0.0

Printer model & used firmware incl. version

Tevo Tornado 1.1.19 and VIRTUAL Printer of OctoPrint

Browser and version of browser, operating system running browser

No response

Checklist of files to include below

• Systeminfo Bundle (always include!)
• Contents of the JavaScript browser console (always include in cases of issues with the user interface)
• Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

octoprint-systeminfo-20221217175659.zip
ForChoiceFilament-OS185_10-gcode.zip

[cp2004]

Can confirm, it is triggered because you have M109 R185 in your gcode and it doesn't look like OctoPrint's offsets support this gcode. You have both these commands in your start gcode which is unnecessary as they do the same thing for heating up:

M109 S185 
M109 R185

Just using M109 S185 would do the same thing and avoid the issue of the temperature offset not being applied.

[cp2004]

PR #4696 addresses this issue.