# RFC: Heaters/temperature\_\* refactoring **URL:** \ **Category:** Developers\ **Created:** [March 26, 2026, 3:09pm UTC](https://klipper.discourse.group/t/rfc-heaters-temperature-refactoring/25798 "2026-03-26T15:09:50Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![nefelim4ag](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/nefelim4ag/32/2387_2.png) [@nefelim4ag](https://klipper.discourse.group/u/nefelim4ag)\ **Post date:** [March 26, 2026, 3:09pm UTC](https://klipper.discourse.group/t/rfc-heaters-temperature-refactoring/25798/1 "2026-03-26T15:09:50Z")
It looks to me that over the years, many different types of sensors have been used, and composite objects have accumulated in the code. Sometimes, it requires weird duct tape to define them in the config. For example, I have an `extruder` object. It is: stepper + heater + temperature sensor, _and for some reason, a separate fan object._ Where the definition of MAX31865, and the sensor pin, actually, is a CS: ```auto sensor_type:MAX31865 sensor_pin: ebb42:PA4 spi_bus: spi1_PA6_PA7_PA5 rtd_nominal_r: 1000 rtd_reference_r: 4300 rtd_num_of_wires: 2 min_temp: 10 max_temp: 330 smooth_time: 0.3 ``` The same would happen with heaters, temperature fans, temperature probes & etc. It seems to me that the DAG approach to this complexity can simplify all objects and their definitions. So, basically, one can do: ```auto # or just sensor [tempature_sensor _extruder] sensor_type:MAX31865 sensor_pin: ebb42:PA4 spi_bus: spi1_PA6_PA7_PA5 rtd_nominal_r: 1000 rtd_reference_r: 4300 rtd_num_of_wires: 2 min_temp: 10 max_temp: 330 [extruder] # or just sensor temperature_sensor: _extruder smooth_time: 0.3 ``` That is it. All the sensor-specific fields within the compound objects will be deprecated (now we can deprecate config sections). The above example should be compatible with all the previous API and UIs. Basically, one can do the same now with temperature\_combined. Later, it seems to me that it would be possible to fix specific objects like MAX31865, to get rid of the non-existent `sensor_pin`. And to rework the temperature\_combined, so it will use “true” callbacks, to work over the temperature sensors. I understand it is a bit of work, and basically, it is refactoring to simplify the existing config and remove any possible ambiguity. If I try to imagine the complete refactoring of this, it would be the “sensor” object, which loads the appropriate module, which can be a temperature sensor. So, it would fit the not temperature sensors, for example: [Support for SGP40 Sensors](https://klipper.discourse.group/t/support-for-sgp40-sensors/20033) So basically, the separation of the source of data from the consumers of data, to always define a DAG: - SGT40 → sensor\_combined - SHT36 → sensor\_combined - sensor\_combined → chamber\_heater or: - heater\_block → extruder Thanks, -Timofey * * * Separately, I guess, this can somewhat help with a possible toolchanger setup, where nowadays, the thing that we are changing is shifting between the whole toolhead and the pure nozzle. But this is my speculation. Ah, and it fixes the setups where several objects can be controlled from the 1 source, for example, 2 fans to cool down the drivers. Where people often use multi\_pin to accomplish that. Or 2 extruders for one hotend. ---
**Author:** ![ianf](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/ianf/32/13900_2.png) [@ianf](https://klipper.discourse.group/u/ianf)\ **Post date:** [March 27, 2026, 3:44pm UTC](https://klipper.discourse.group/t/rfc-heaters-temperature-refactoring/25798/2 "2026-03-27T15:44:51Z")
I agree that the extruder object is a little weird because while physically the extruder is the motor and gears, the config object combines 1. `stepper` 2. `heater` 3. `temperature_sensor` I like the idea of breaking out the temperature sensor especially if that makes it easier to maintain the individual sensors. Perhaps it’s worth considering dismantling the extruder object entirely and creating a toolhead object that then combines the `stepper`, `heater`, `temperature_sensor` and `fan`. This would probably go a long way to making multiple toolheads simpler because selecting a different tool would automatically select the heater, part fan etc without needing so much gcode macro glue. FWIW, I don’t like `sensor_pin` having overloaded definitions, namely adc\_pin and cs\_pin. I would prefer for the mcu internal ADC to retain `sensor_pin` and external sensor device like the MAX31865 and others to use their connecting bus nomenclature. ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [April 24, 2026, 3:11pm UTC](https://klipper.discourse.group/t/rfc-heaters-temperature-refactoring/25798/3 "2026-04-24T15:11:48Z")
> [@nefelim4ag](#): > > For example, I have an `extruder` object. > It is: stepper + heater + temperature sensor, _and for some reason, a separate fan object._ Yeah, this is something I’ve thought about in the past as well. Other examples include the `[stepper_x]` object, which defines a stepper, an axis, an endstop, and homing details. In some ways it would be nice to have separate config sections. However, I think separating them out could lead to a large number of config sections that cross reference themselves in intricate ways. That could ultimately be confusing for users. Not sure. -Kevin