Add `AsusRouter` integration to HA Core

:octopus: Link to the corresponding PR


Home Assistant has ASUSWRT core integration, which supports SSH and telnet connections to the Asus routers. Unfortunately, this integration (or to be exact this kind of connection) does not work well with the devices on the newer firmware (versions 386.x released in 2020 and versions 388.x released in 2022).

For the last year I am developing custom AsusRouter integration which got reasonably popular. It supports HTTP(S) connection to the device and uses native router API - the same way router Web UI works or the official “ASUS Router” application for Android and iOS. The integration works well with any firmware starting with versions 380.x from the year 2018).


I suggest merging AsusRouter as a separate integration to the HA Core as opposed to the already existing ASUSWRT. In this case, users of ASUSWRT who are happy with it can stay with it and users with newer devices can switch to AsusRouter.


Current state of ASUSWRT

  • I know that one of the ASUSWRT maintainers is already trying to add HTTP(S) protocol support to the integration. There are PRs #71899 and #84152.
  • The other ASUSWRT maintainer (also the author of the SSH/Telnet library used by ASUSWRT) has already “moved on from hass” and asked to be removed from code owners. Link. And this maintainer is the author of the SSH/Telnet communication library used by the integration.

Why I think it is better to have separate integrations


  • :green_heart: AsusRouter uses the native authentication way for Asus devices - just username and password for the Web UI:
    • This way of authentication is enabled by default and is easy for new users
    • It uses the same credentials which users need to access their device
    • Having this as the only auth method makes setting the integration up as easy as possible
  • :heart: Merging HTTP(S), SSH and Telnet into a single integration will create problems for new users:
    • Which method to choose?
    • SSH / Telnet need to be enabled manually in the device’s Web UI
    • Which credentials to choose? SSH and Telnet credentials are different from HTTP(S) and are set up separately

Feature support

  • :green_heart: Usage of the native API and HTTP(S) protocol allows support of as many of the features available for the device
  • :heart: Merging all the protocols in the same integration will create a headache for the user:
    • Why some sensors or features are not available?
    • Why some features are working differently? SSH/Telnet allows monitoring of network traffic through network interfaces (e.g. eth0). HTTP(S) API allows monitoring of traffic over router-defined network interfaces (e.g. WAN, USB and of WiFi networks) regardless of the device model and features.

and other…

From my point of view, having a new integration with new native features is preferable to creating Frankenstein’s monster of different parts.

Currently, AsusRouter is used by 667 HA installations as per HA Analytics. Even though, it is a custom integration and needs to be installed from HACS.

ASUSWRT is used by 2351 installations which are sharing data with HA Analytics.

:star: Like the idea - vote for it

If enough users like the idea of adding AsusRouter as a standalone integration into HA Core, I would be glad to gradually make it a part of Core and fulfil all the Core integration requirements.

I am also open to collaboration with other developers, including ASUSWRT maintainers, to make AsusRouter even better for HA users.

I totally support this. I’ve migrated from the official integration to AsusRouter a while ago and have no regrets. The integration is very stable, complete, full of functionalities giving power to HA to control even more advanced functionalities in the router and now in the AiMesh nodes.


I like the idea of it, however keep in mind that you won’t be able to iterate versions of the integration as quickly as you are with it being standalone

1 Like

Yes, I know that limitation of being in Core.

I don’t think this will be a problem. Of course, in case of a bug, the user will need to wait longer for the fix, but since features will be implemented gradually (to fulfil all the requirements of the HA Core development), I don’t expect lots of things to break

1 Like

Definitely support this. Moved over to this from the official integration and it fits my needs much better.

I would understand that it might be overkill for other users so keeping the other integration and this one as different choices seems like the way to go.

1 Like

P.S. I am sorry in advance for tagging people to ask them stupid questions.

I would kindly ask two of the moderators I see the most regularly answering questions of Community (@petro, @tom_l) to help with my question:

  • Can you please suggest, which of the HA Core developers present on the Community Forum is the most suitable person to address the question of whether there could be 2 different integrations for the same kind of devices present in HA Core working in a different way? (the details are in the feature request first message)

If the HA Core team is not against my suggestion (adding AsusRouter as separate integration along with the already present ASUSWRT), I would like to start working on it. But it would be a bit of a waste of time to do if HA developers are against it and PRs won’t be approved anyway.

In general, I just would like to know either yes, it is allowed or no, this is not allowed.


No idea, sorry.

1 Like

Then I will try my luck asking the person behind the whole HA idea. I am again sorry for tagging.

@balloob, I would like to ask you whether the suggested here is possible and whether the HA Core team will agree with the proposal:

  • add one more integration (AsusRouter, already successfully used by many users as custom integration) to the Core to control routers along with the already existing ASUSWRT which is already more of a legacy, but still suitable for the oldest of the Asus routers (from before the times when Asus implemented modern API).

Thanks in advance for your reply!

P.S. I think, the activity of voting for this feature request shows user interest. At the same time, I would prefer to know the opinion of the HA team on the topic before actually starting with PRs to the Core so I don’t go “against the vision” of the project.

1 Like

Please stop tagging people. It’s allowed. E.g. There’s multiple Yamaha integrations. Usually, the second integration is named after the API that the company touts. If it’s using the same API, you’d use the same integration. Or you overwrite the previous integration if all routers will use the new one. Regardless, you probably won’t get an answer here on the forums. Discord or Github will be where you want to address these concerns.

If you put in the work for a new integration and state your cases in the PRs, the chances of it getting rejected are low. All this hoopla about ‘dev’s rejecting things’ that you see on the forums is mostly BS or the new functionality (in core, not an integration) will break core behavior. As an aside, usually adding integrations does not affect core behavior.

Works really good. Thank you for all your hard work



I see this thread just now, looks from your side that this is a race, but from my point of view is not.
I just worked implementing the HTTP protocols in native integration months ago because as maintainer of that integration I think that should be updated to support most possible version of routers, but considering that there are many version of Asus Router with so different firmware version, should be better to have an integration able to work also with old routers and firmwares that not work with http.
In any case is not up to me the final decision and my PRs will remain alive waiting patient for a possible review.
I take a look to your custom integration, just let me suggest a couple of things if your goal is to add your integration as new native one (and of course you can just ignore them):

  • think about avoid unrequired polling: seems that your library poll the router for every possible information also if not really required. It is normally better to just poll for active sensors and not stress the router that normally have more important things to do.
  • implement your custom integration using custom integration blueprint, this will allow you to implement your code using appropriate devenv and devcontainer and you will be able to create unit tests that are really important part for HA integration (and generally speaking good practice in code development). I also suggest you to add additional tasks to ensure good code formatting (black, isort, etc). Feel free also to use my custom integrations repositories as example.

This will prepare your integration to be more “ready” to be accepted as native.

Good work.


Hey, @ollo69, thanks for your comments and suggestions!

I know, that my library is not the most optimal one and there are many spots to improve. That is currently my goal. The same is for the AsusRouter as custom integration. As you have mentioned, there is a huge variety of devices and firmware versions which I was trying to support as much as possible, from time to time ignoring optimization.

When I will be trying to create PRs for a new in-built component, I am going to come from the stability point of view, since the responsibility is a bit higher. And yes, testing was also a part which I avoided for a long time, but now there is no way not to make everything properly.


1 Like

Update on the status

The first PR to the HA Core with some base features:


:horse_racing: We have reached 100 votes!



:hammer_and_wrench: The end

I just now understood, that I didn’t post anything here as an update.

So, in short, AsusRouter is not expected to be added to Core anymore, since this will cause confusion to users if having 2 integrations and having only AsusRotuer will cause issues to users of 15+ y.o. devices which did not support API yet.

In any case, the core AsusWRT added HTTP(S) API support a bit more than a month ago (link).

So, maybe at some point, it will start working properly for the users


AsusRouter will still be available as a custom integration for all those voting for a feature-full experience

You can also use the backend library for your projects

Meanwhile, this feature request is one of the largest (top-36) in this community forum