Moonraker: Missing Sensors With Klipper Kinematics: None

Hey there, fellow Klipper and Home Assistant enthusiasts! Ever been in that frustrating spot where you've painstakingly set up your Klipper rig, connected it all up to Moonraker, and then integrated it with Home Assistant, only to find that some of your crucial sensors are completely missing? Specifically, we're talking about that head-scratcher where your Moonraker Home Assistant integration shows missing sensors, especially when your Klipper configuration uses kinematics: none. This isn't just a minor annoyance; it can seriously hinder your ability to monitor and automate your setup. You've got your Pi 3 B+ humming along, a Klipper Expander doing its thing, and you're seeing some entities, like fan temperature sliders or LED output pins, but the actual sensor values for fan speed or temperature? Poof! Gone. This article is all about diving deep into this specific issue, figuring out why it happens, and most importantly, how to get those elusive sensors to pop up in your Home Assistant dashboard. We're going to break down the setup, the bug, and every potential fix we can think of, so stick around and let's get those sensors reporting! It’s a common pitfall for those of us pushing the boundaries of what Klipper can do, especially when moving beyond a standard 3D printer setup into more unique or experimental configurations. Understanding the interaction between Klipper's kinematics: none, Moonraker, and its Home Assistant integration is key to unlocking a fully functional monitoring system. Many users, like you, might be leveraging Klipper for non-traditional purposes, perhaps for an input shaper rig, a bed leveling probe testing station, or even just a complex lighting system, where the full kinematics of a 3D printer aren't needed. When this happens, kinematics: none becomes the go-to setting, and while it should theoretically allow other components like sensors to function independently, the reality, as you’ve experienced, can be quite different. This particular version of the Moonraker integration, 1.11.1, could have its own quirks, or it might be a more fundamental misunderstanding of how the integration expects data when kinematics are absent. We'll explore whether Moonraker, the communication bridge, is properly parsing and exposing the sensor data to Home Assistant, or if the Home Assistant integration itself is specifically looking for kinematics data as a prerequisite for full sensor discovery. The goal here is not just to fix your immediate problem, but to equip you with the knowledge to troubleshoot similar issues in the future, making your Klipper-powered smart home truly smart and reliable. So grab a coffee, and let's unravel this mystery together, ensuring your custom Klipper setup is fully visible and controllable within Home Assistant. This is a journey through configuration files, logs, and a bit of detective work, all aimed at bringing those essential sensor readings back into your digital grasp. We're committed to helping you understand why this happens, and what steps you can take to mitigate or resolve it, turning a frustrating bug into a valuable learning experience for the entire community. It's truly about empowering you, the user, to take control of your unique setup and get the most out of Klipper and Home Assistant.

Understanding the "Sensors Missing with Kinematics: None" Conundrum

Let's really dig into the core issue: Moonraker Home Assistant integration failing to display crucial sensors when Klipper is configured with kinematics: none. You're not alone in encountering this baffling problem, especially when venturing into custom Klipper setups beyond typical 3D printers. Many users, like yourself, employ kinematics: none in Klipper for various reasons, such as setting up a Klipper Expander board as a standalone measurement device, an input shaper rig, or even just a specialized test bench where traditional printer movements aren't required. In these scenarios, kinematics: none tells Klipper that it's not controlling a standard XYZ motion system, allowing it to focus on other defined components. The expectation, naturally, is that other configured elements, like temperature sensors, fans, or output pins, should still be fully discoverable and controllable via Moonraker and, subsequently, Home Assistant.

However, the symptoms you've described are classic for this conundrum: you only see a handful of "basic ones" – typically printer status, power, or possibly a few default heaters – while your custom-defined sensors, like specific fan temperature sensors or fan speed readings, are conspicuously absent. You mentioned getting a list of 46 entities, which is great for showing some communication, but the devil is in the details. The fact that you see a fan temperature slider but not the actual temperature sensor reading is a massive clue. This suggests that the entity itself is partially recognized, or perhaps a control aspect is, but the underlying data stream for the sensor value isn't being correctly parsed or exposed. Similarly, an LED output pin might show up, allowing you to toggle it, but if there were an associated current sensor or a feedback sensor, it too might be missing.

Now, let's hypothesize why this might be happening. One strong possibility is that the Moonraker Home Assistant integration, version 1.11.1 in your case, might have an internal logic that expects some form of kinematics definition to fully initialize or discover all associated components. It's almost as if a prerequisite check for a [printer] section with defined kinematics is implicitly tied to a broader sensor discovery routine. If this check fails because kinematics: none is present, it might prematurely stop the discovery process for certain sensor types, or it might misinterpret the available data, leading to the partial entity listing you're seeing. Another theory is that while kinematics: none is perfectly valid for Klipper, Moonraker itself might not be fully exposing the sensor data in a way the Home Assistant integration expects. Moonraker acts as a sophisticated API layer for Klipper, and if its internal schema for reporting objects changes or is limited when kinematics are absent, the Home Assistant integration would only reflect what Moonraker tells it.

Your specific setup, a Pi 3 B+ hooked up to a Klipper Expander, is a fantastic example of where kinematics: none shines. It allows you to extend Klipper's capabilities to more than just a 3D printer. The Expander acts as an additional microcontroller, letting you add more sensors, fans, and output pins, managed by your main Klipper instance. The problem arises when this flexibility isn't fully reflected in the Home Assistant interface. This discrepancy between Klipper's robust functionality and the Home Assistant integration's interpretation is precisely what we need to unravel. It’s critical to remember that while Klipper is incredibly flexible, the integrations built upon it sometimes make assumptions about typical usage. When we deviate from these assumptions, even with a perfectly valid Klipper configuration, we can run into these integration-level quirks. We’re essentially pushing the limits of the integration, and that often means doing a bit of detective work to ensure everything communicates as it should. The Moonraker logs you provided will be instrumental in pinpointing any errors or warnings related to sensor discovery, helping us to see exactly where the communication breaks down between Klipper, Moonraker, and finally, Home Assistant. So, understanding this intricate dance between configurations and integrations is the first step to a complete and functional smart home monitoring system.

Diving Deep into Your Klipper Expander & Moonraker Setup

Alright, guys, let's zoom in on your specific setup: a trusty Pi 3 B+ paired with a Klipper Expander. This combination is awesome for adding more I/O to your Klipper ecosystem, extending its reach far beyond just your printer's main board. The Expander essentially acts as a satellite microcontroller, managed by your main Klipper instance running on the Pi. It’s perfect for integrating additional sensors, fans, LEDs, and more, allowing you to create a truly bespoke monitoring and control system. Moonraker’s role here is absolutely pivotal; it's the intelligent bridge that translates Klipper's low-level hardware commands and status updates into a digestible, web-friendly API. Without Moonraker, Home Assistant wouldn't have a way to talk to Klipper, making it the unsung hero of your smart home integration.

Now, why are sensors so incredibly crucial for monitoring and automation? Think about it: without accurate temperature readings, you can't properly control cooling for a critical component. Without fan speed feedback, you don't know if your ventilation is actually working. These aren't just numbers on a screen; they're the eyes and ears of your automated system, enabling intelligent responses and preventing potential issues. The absence of these sensor values, especially when the control entities (like the fan temperature slider or LED output pin) do show up, is particularly perplexing. It suggests that the communication path for sending commands is working, but the path for receiving real-time data from the sensor itself might be blocked or misinterpreted.

Let's get into some troubleshooting basics. First and foremost, double-check your Klipper's printer.cfg (and any included .cfg files for your Expander). I cannot stress this enough, folks – a tiny typo, an incorrectly formatted line, or a forgotten [temperature_sensor <name>] or [fan_generic <name>] section can completely derail sensor reporting. Ensure that every single sensor you expect to see in Home Assistant is explicitly and correctly defined in your Klipper configuration. Pay close attention to the pin: assignments for your Expander, making sure they match the physical connections and the microcontroller's pinout. Also, confirm that these sections are not commented out – sometimes a ;# or # can slip in accidentally during edits. Klipper is very particular about its configuration syntax, and any deviation, no matter how small, can lead to components not being initialized or reported.

Next, consider Moonraker's configuration. While Moonraker is generally good at discovering Klipper objects automatically, are there any specific settings in moonraker.conf that might influence how custom sensors or Expander-attached devices are exposed? For most standard setups, default Moonraker configuration is sufficient, but in unique scenarios like kinematics: none, there might be an edge case. Review its documentation for any sections related to sensor discovery or specific Expander configurations.

Finally, think about the Home Assistant integration itself. How does the Moonraker integration discover entities? Typically, it queries Moonraker's API for available printer objects. Is there a way to enable a debug mode for the Moonraker integration within Home Assistant? This would provide verbose logging, showing exactly what data the integration is receiving from Moonraker and where it might be failing to parse or create entities. Understanding this data flow is paramount. The fact that some entities appear tells us that the basic connection is working, but a deeper issue prevents full discovery. This often boils down to how the integration interprets the data structure provided by Moonraker, especially when that structure deviates from the norm, as it might with a kinematics: none setup. It's like Moonraker is speaking a slightly different dialect, and the Home Assistant integration is struggling to fully understand all the nuances, leading to only partial comprehension of your extensive sensor array. This intricate interplay needs careful examination, ensuring that every layer of your system is configured to communicate effectively, from the Klipper Expander to your Home Assistant dashboard. We need to bridge this communication gap to bring all your essential sensor data to light.

Unpacking the Moonraker Home Assistant Integration (Version 1.11.1)

Let's meticulously unpack the specific version you're running: Moonraker Home Assistant integration 1.11.1. This version number is crucial, as integrations evolve, and sometimes bugs or unexpected behaviors are introduced or fixed between releases. Could there be known issues with this specific version related to sensor discovery, especially in non-standard kinematics: none setups? It's definitely worth checking the integration's GitHub repository, bug trackers, or community forums for similar reports. Often, you'll find other folks who've hit the same wall, and their discussions or workarounds can be a goldmine.

Now, how exactly does this integration parse Klipper's data via Moonraker? At its core, the Home Assistant Moonraker integration queries Moonraker's API (usually endpoints like /printer/objects/query?webhooks or /printer/objects/query?gcode_macros) to retrieve a JSON object representing the current state and configuration of your Klipper instance. This JSON blob contains all the defined sections in your printer.cfg, including [temperature_sensor], [fan_generic], [output_pin], and so on. The integration then sifts through this data, mapping known Klipper components to Home Assistant entities. The challenge arises when this expected data structure is altered, perhaps subtly, by a kinematics: none configuration. If the integration is hard-coded to look for certain kinematics objects before fully processing other sensor types, it could explain the partial discovery.

Consider the "basic ones" that do show up. These typically include things like printer.state, printer.paused, or perhaps a default extruder or heater_bed temperature sensor if they are implicitly defined by Klipper even without full kinematics. The fact that these basic entities appear confirms that the fundamental connection between Home Assistant, Moonraker, and Klipper is established. The issue isn't a complete communication breakdown, but rather a selective failure in entity discovery. This distinction is critical for narrowing down our troubleshooting efforts. It tells us that the initial handshake is successful, but the subsequent detailed data exchange for all configured components is where the problem lies.

The presence of custom entities like a fan temperature slider or an LED output pin, but not their actual sensor values, is particularly insightful. This suggests that the control aspects of these components are being discovered and rendered correctly. You can likely interact with the slider to set a fan speed or toggle the LED. However, the associated sensor entity that reports the fan's actual measured temperature or the LED's current state (if it had a feedback loop) is missing. This strongly implies that the integration is successfully identifying the controllable attributes of your defined Klipper objects (like a fan_generic or output_pin), but it's failing to extract or create entities for their read-only sensor values. This could be due to a parsing error specifically for sensor data types when the kinematics context is absent, or perhaps a filtering mechanism within the integration that inadvertently excludes these sensors under such conditions. It’s like the integration sees the car's steering wheel and pedals, but can't read the speedometer or fuel gauge because it thinks the engine isn't fully assembled.

Finally, let's talk about the Moonraker Logs you provided (e.g., home-assistant_moonraker_2025-12-06T18-37-04.373Z.log). This log file is your ultimate diagnostic tool, folks! You need to meticulously comb through it for any ERROR or WARNING messages related to entity discovery, sensor parsing, or communication failures with Klipper. Look for lines that mention