MQTT Support / Home Assistant Integration

[PH89]

Summary

• Adds a full-featured MQTT client to JetKVM with Home Assistant Auto-Discovery support
• Publishes device state (video signal, USB, cloud connection, active sessions, network info, system metrics, virtual media) as retained MQTT messages
• Supports TLS connections with validation against rootcerts and optional insecure mode
• Implements controllable entities via MQTT: mouse jiggler (switch), DC power (switch), ATX buttons, device reboot, firmware update, and virtual media selection
• Adds EnableActions config toggle — when disabled, controllable entities are replaced with read-only sensors/binary sensors while keeping full monitoring capability. The firmware update entity remains visible but without install command.
• Firmware update entity reports real-time in_progress status and update_percentage during OTA updates
• Virtual media select entity dynamically updates its options list, supports storage-based and HTTP-mounted images, and exposes a source attribute (storage/url/none)
• System metrics sensors: CPU load (with state_class: measurement for graphs), SoC temperature, memory usage, storage used/free
• Extension-aware discovery: ATX and DC entities are published/removed based on the active extension
• Proper cleanup: discovery entries and state topics are cleared when MQTT or HA Discovery is disabled
• Adds MQTT settings page to the UI with full configuration (broker, port, TLS, credentials, base topic, HA Discovery toggle, actions toggle)
• Includes English and German localization for all MQTT settings

Related Issues:

• Make "voltage", "current", "power" from DC power extension available as parameters (e. g. in HomeAssistant)? #1059
• Home Assistant integration #1156

Test plan

• Enable MQTT and verify connection to broker (with and without TLS)
• Verify HA Auto-Discovery creates all expected entities
• Toggle EnableActions off → confirm switches become binary sensors, buttons disappear, select becomes sensor, update entity loses install button
• Toggle EnableActions on → confirm controllable entities reappear
• Trigger firmware update via HA → confirm progress bar and percentage are displayed and update is applied in the background.
• Mount a local disk image via the virtual media select → confirm state updates
• Mount an HTTP image externally → confirm select shows extracted filename and source attribute is url
• Switch active extension (ATX ↔ DC ↔ Serial ↔ none) → confirm discovery updates accordingly
• Disable HA Discovery → confirm all discovery entries are removed from the broker (homeassistant topic)
• Disable MQTT entirely → confirm all topics and discovery entries are cleaned up
• Verify system metrics sensors (CPU load, temperature, memory, storage) update periodically and support HA graphs

Preview

[Igglybuff]

@PH89 I've tested this on my JetKVM device and it seems to work well - I'll play around with it next week to see if I spot any issues.

I wonder if there's a simple way to add a debounce delay for certain things like ATX HDD LED which can flick on and off repeatedly/quickly for long read/write sessions (if I'm using my NAS, this spams my broker and Home Assistant 😅).

[PH89]

I will check this out. Normally it should be possible. But should be configurable. For MQTT server it should not be a problem to handle such change frequency. On the Home Assistant site it could cause a quick pollution of the history log. So maybe it is better to disable logging for these entities.

[CLAassistant]

All committers have signed the CLA.

[PH89]

@Igglybuff Integrated debounce delay for ATX HDD Led.

[Igglybuff]

@Igglybuff Integrated debounce delay for ATX HDD Led.

I've just tested your branch and played around with the debounce setting, but I'm not sure it's behaving as expected. No matter what value I set it to (500, 1000, 0), the ATX HDD LED sensor is stuck disabled:

Though this could be because I need to start fresh and re-register with my broker? Not sure.

Were there any other features you were thinking of adding? I would be curious to hear what the JetKVM maintainers think of this PR - maybe they don't look at drafts 😄

[Igglybuff]

Actually I think the debounce is working now (PEBKAC error) - I had it disabled from a couple weeks ago, but for some reason it took a few attempts for Home Assistant to enable it again and for the entity state to start populating.

This shouldn't be a problem when setting it up for the first time I don't think.

[aaronbolton]

I've been testing this, and all seems to work great. The only issue I've noticed on reboot of the jetkvm it doesn't reconnect to MQTT and requires the save & connect to be selected

[PH89]

Thanks for the feedback. I will check on this. I guess I will finalise the PR this weekend and mark it as ready for review.

[PH89]

Ready for review.

[aaronbolton]

I've been testing this for around a month now with each new iteration, and the current implementation appears solid, with absolutely no issues to report.

The only area I haven't tested is the TLS connection

[aaronbolton]

I've been testing this for around a month now with each new iteration, and the current implementation appears solid, with absolutely no issues to report.

The only area I haven't tested is the TLS connection

just to follow up, ive tested TLS connections with and without verification and it appears to work fine

[Brianr1028]

Apologies if this is staring right at me, but has this been added to Home Assistant yet? Also, instructions for setting it up?Thank you.

[PH89]

Apologies if this is starting right at me, but has this been added to Home Assistant yet? Also, instructions for setting it up?Thank you.

This is not needed since we are using the Home Assistant MQTT integration.

Just set up MQTT according to documentation in Home Assistant. After that you can add it.

[Brianr1028]

I already have MQTT setup for getting info for Rasperry Pi's. Can I assume the following:

• Name would be IP address?
• Type of entity, does it matter what I select? Tried a couple different ones from sensor, switch. Assume I want sensor?
• If I select sensor, then it wants be to define state topic. Not sure what I need to specify

[PH89]

@Brianr1028 What you describe is adding a manual MQTT Entity. This is not needed since I implemented auto discovery. You only need to enter the MQTT configuration in the JetKVM settings. After that it should be discovered automatically by HA, as long you have auto discovery in your HA mqtt options enabled.

If you are interested how this technically works I advise you the documentation of the MQTT integration of HA (https://www.home-assistant.io/integrations/mqtt/)

[Brianr1028]

@PH89 Got this working - thank you. In addition to reporting JetKVM is up to date can we pull in the current version so it shows on a HA card or if its not up to date will it show the current version? I do know clicking on up to date does show version which is all fine.

Beyond that very nice and certainly easier than other MQTT's I have setup with my limited knowledge of topic.

[PH89]

@Brianr1028

In addition to reporting JetKVM is up to date can we pull in the current version so it shows on a HA card or if it's not up to date will it show the current version?

Yes this is possible already with the state_content attribute on the HA card

Like this:

state_content:

• state
• installed_version
• latest_version

Hope it helps.

[Brianr1028]

@PH89 I have a lovelace card I am trying to use. In particular I would like to graph out the CPU load. Is it possible in the next release to add unit-of-measurement attribute? I realize this can be defined in configuation.yaml, but I noticed storage free and storage used had that already defined. Sorry don't mean to be a pest. thank you

[PH89]

@Brianr1028

Just to clarify — the CPU load sensor reports the Unix load average, which is not the same as CPU usage in percent. The load average represents the average number of processes waiting in the run queue over a period of time (typically 1 minute). So a value of 1.0 means on average one process was waiting, 2.0 means two, and so on. It's a dimensionless number with no unit.

For context: a load of 1.0 on a single-core system means it's fully saturated, while the same value on a quad-core system means it's only at 25% capacity. That's also why attaching a unit like "%" would actually be misleading here.

I am not sure what kind of graph card you are using maybe you can provide me more information.
I used the standard graph-card in my test and this should provide a history-graph for the cpu load.

Hope that helps! And no worries, you're not being a pest at all — good questions are always welcome.

type: grid
cards:
  - type: history-graph
    entities:
      - entity: sensor.jetkvm_cpu_load
        name: Load
    hours_to_show: 24