Home Assistant Integration for Arista EOS Enterprise Switches

When most people think of Home Assistant, they think of smart bulbs, thermostats, and Zigbee sensors.

I spend my days working with enterprise infrastructure, so naturally, I wanted my network switches in Home Assistant too.

The problem? Arista EOS has no official integration and very little community support. The usual recommendation is to glue together a handful of REST sensors or command-line scripts. That works… until you want discovery, device information, diagnostics, entities that update together, and something you’re comfortable sharing with other people.

So I built a proper Home Assistant integration for Arista EOS.

Table of Contents

Why bother?

Enterprise switches expose a surprising amount of operational data that becomes genuinely useful once it’s part of your smart home.

The integration doesn’t just tell me whether the switch is online. It exposes the things I’d actually look at while troubleshooting:

Per-switch CPU utilization
Memory usage
System uptime
Power supply status and redundancy
Fan health and speed
Temperature sensors
Environmental alarms
Interface statistics
Port status and negotiated speeds
SFP transceiver information
PoE status (where applicable)
Software version and hardware inventory

Instead of opening the switch CLI or logging into CloudVision just to answer “is something overheating?” or “did a power supply fail?”, the information is already available inside Home Assistant.

That also means I can build automations around it.

If a power supply fails, notify me.

If a switch temperature exceeds a threshold, send an alert.

If an uplink drops, flash a light in my office.

Home Assistant suddenly becomes another operations dashboard.

Building a real integration

The easy version of this project would have been a dozen REST sensors.

The hard part—and the part that makes the integration worth maintaining—was everything else.

I wanted it to behave like users expect a modern Home Assistant integration to behave.

That meant:

A proper config flow instead of editing YAML.
Automatic DHCP discovery.
Reauthentication when credentials change.
Reconfiguration without deleting and recreating the integration.
A shared DataUpdateCoordinator so dozens of entities are updated from a single API call.
Redacted diagnostics for bug reports.
Strict typing throughout the codebase.
53 automated tests covering 98.9% of the project.

None of those features make the screenshots more exciting, but every one of them makes the integration better to use and easier to maintain.

The bug that made no sense

The biggest debugging rabbit hole wasn’t parsing EOS output.

It was TLS.

Home Assistant simply reported:

cannot_connect

That was it.

Everything else worked.

curl connected successfully.
A standalone Python script authenticated successfully.
The switch was reachable.
Credentials were correct.

The actual error only appeared in Home Assistant’s system log:

SSLV3_ALERT_HANDSHAKE_FAILURE

The culprit turned out to be the switch firmware.

Older EOS releases only support legacy TLS cipher suites. Modern OpenSSL rejects those ciphers at its default security level before certificate validation even begins.

That means turning off SSL verification doesn’t help.

The solution wasn’t verify_ssl=False.

It was creating a dedicated SSL context with DEFAULT@SECLEVEL=1 and a minimum TLS version of 1.0, building that context off the event loop, and using it only for requests to the switch.

It’s one of those bugs that looks like a certificate problem but isn’t one at all.

Small details that matter

A few other surprises ended up making the integration considerably more robust.

The newer EOS environment commands have deprecated the older show environment temperature and show environment cooling commands. Supporting both—with modern commands first and automatic fallback—lets the integration work across a much wider range of hardware and software versions.

Another subtle one was fan speed.

The API reports both actualSpeed and maxSpeed. At first glance, they look like RPM values.

They’re not.

actualSpeed is a percentage of the maximum speed.

Treat it as RPM, and your dashboard confidently reports that your fans are spinning at “30 RPM.”

Those are the kinds of implementation details that never make it into vendor documentation but save the next developer hours of confusion.

Try it yourself

The integration is available on GitHub:

https://github.com/Jonah-May-OSS/ha-arista-eos

Installation instructions, supported platforms, and configuration examples are all included in the README.

If you find a bug or have an EOS platform you’d like to see supported, issues and pull requests are always welcome.

Final thoughts

This started because I wanted better visibility into a couple of network switches.

It ended up becoming a lesson in building maintainable Home Assistant integrations, debugging legacy enterprise TLS, and discovering that enterprise infrastructure has a place in a home automation platform after all.

Hopefully, it also makes life easier for the next person who searches for “Arista Home Assistant” and finds there wasn’t an answer—until now.