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).
Suggestion
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.
Reasoning
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
Authentication
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
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
Usage of the native API and HTTP(S) protocol allows support of as many of the features available for the device
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.
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
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
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.
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.
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.
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.
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.
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.
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
upvote - the current native integration really doesnāt give any information on my device (ASUS GT-AX6000) , Yours is much more complete with alot more integrated buttons and switches taking out the guess-work.
Link to the corresponding PR
Merging HTTP(S), SSH and Telnet into a single integration will create problems for new users:
Like the idea - vote for it
We have reached 100 votes!
The end