[Custom component] AsusRouter integration

Share your Projects! Custom Integrations
157

Wouldn’t it be wiser to use the connected devices sensor then to avoid all those extra events on every reconnect? The connected devices sensor is already being updated. How often is that updated btw?

158

@Quacked, there are pros and cons, as usual

Event

Pros

  • Easier to implement into automation. They are straightforward and only correspond to what they should, so automation will always be triggered when needed
  • Only the device which changed status is processed per automation

Cons

  • Are written to HA database, so do increase the db size a bit

connected devices sensor

Pros

  • No additional db entries

Cons

  • You need to trigger on the attribute change, not the value change (because you can get into the case of one device connected and one disconnected keeping the total number constant)
  • All the devices in the connected list should be checked
  • The device list should be compared to the previous device list to understand which devices connected and which disconnected

Conclusion

I would say, if you would like to use automation, events are preferable. You will perform much fewer operations for logic even though will write something to the database. Also, integration logic will be simpler.

This would become even more noticeable with increasing the number of devices.

From the device point of view, everything is the same - no change in performance. From the integration point of view, devices are anyway processes for the sensor value and attributes and event logic is neglectable - no change in performance.

Free to choose

But for users who don’t need such automation, these events (reconnected, disconnected) are by default off, so they will not be written to the db.

connected devices updates vs events

The sensor is updated based on the device trackers update and consider device at home intervals. The logic is the following:

  • Each update the device list is polled from the router (it contains only connected devices)
  • All the previously tracked (connected) devices are added to the same list
    a) Device is on - it is added to the connected list
    b) Device is off, was connected before, but the time passed is smaller than consider home - the device is kept in the connected state
    c) Device is off, but time is larger than consider home - the device is marked disconnected
  • List is written to the devices attribute of the sensor.

Event reconnected is triggered on step a) if the device was disconnected before. If it was not tracked at all before, it will trigger connected.
Event disconnected is triggered on step c)

@EdwardTFN, thanks! I will add your device to the list.

1 Like
159

Wow, nice explanation.

Look, don’t take me wrong, I’m not against the new events at all. I’m not sure if I will ever use, but I’m really happy to have those available for future (my brain will spend some time to come up with use cases for those) and I definitely like the fact you are implementing this as events, as it is clear to me this would be much easier to manage than playing with a big list of devices from our side.

You are doing a great work with this integration. Thank you very much!!!

By the way, do you know how should be the process to replace the “official” ASUS integration by this one? Maybe you should go that path…

160

You could try, and see what specific questions you would have, and we go from there.
The migration process arguably would be outside of the scope of this integration. And I hope we let Vaskivskyi focus on what he does best.

161

In regards to the ha database I would think that the users who have large numbers of devices would have their recorder optimized to exclude and include specific entities.
I have mine on maríadb in another container.
I only include specific sensors I want to track and purge them every 90 days.
On proxmox I keep an eye on the size easily.

162

Do you mean to suggest AsusRouter instead of AsusWRT for Home Assistant Core?

I doubt, my integration can “replace” the in-built AsusWRT. There are several problems I see:

  • AsusWRT is used by at least 2213 people (via Analytics). Removing it and adding AsusRouter will break something for these 2k+ people.
  • AsusWRT uses different communication protocols - SSH or telnet by the time, so users cannot just ‘move’ automatically, even though the manual switch is easy and straightforward.
  • AsusWRT already has a PR to add support for HTTP protocol usage (link) created by one of the code owners (maintainers) of AsusWRT itself. Hanging there for almost half a year.

On the other hand, another of the two code owners has already mentioned (link), that he has moved on away from HA.

I would like for AsusRouter to be a part of HA Core and I can (or at least I have such a will) add it to the Core, if possible. But I don’t want to try it for nothing (since fulfilling all the requirements is not super easy). As well as don’t want to neglect the work of the AsusWRT authors.

So, in general, if you would like for AsusRouter to become a part of HA Core (become a built-in integration), you can create a thread in the Latest Feature Requests topics - Home Assistant Community (home-assistant.io). If it gets upvoted and the HA team is not against 2 different Asus integration being in Core, I think AsusRouter and AsusWRT could coexist.

If you would like to suggest the replacement of AsusWRT with AsusRouter eventually, the AsusWRT authors and HA team should be not against this. So, I would still suggest creating a ‘feature request’ for HA.

3 Likes
163

Also expected in 0.11.0

Spoiler #3

image

6 Likes
164

It looks like 0.11.0 is the new largest release. It would be hard to fit all the release notes in the HACS update window, so the full feature list will be here:

New entities

  • :girl: Full support for Guest WLANs (either switch or binary_sensor entities depending on your integration configurations).
  • :globe_with_meridians: OpenVPN Server support (switch / binary_sensor entities) with client_list attribute.
  • :point_up: New platform Button is added with 4 entities - Reboot, Restart HTTP Daemon, Restart Firewall and Restart Wireless. Probably, it is easy to guess, what they do.
  • :question: New platform Update is added, which will show whether your device can be updated to a newer firmware version.

Events and services

  • :bookmark_tabs: New service asusrouter_adjust_wlan, which can set settings of usual WLAN and Guest WLAN networks.
  • :exclamation: New events added - asusrouter_device_disconnected and asusrouter_device_reconnected. Their default state is off. Please use the Configure menu if you would like these events to be raised.
  • :vertical_traffic_light: All the events from now on are optional each has a switch in the Configure menu.

Other improvements

  • :open_book: The list of connected devices is now force-updated before it is polled from the device. This way the list will always be accurate (important for some older and some FW-limited devices)
  • :bulb: (Merlin) LED state is now recovered on device reboot and when some services (e.g. restart_wireless) are called from HA. This will prevent LEDs from turning on by themself, keeping the light entity in the wrong state. This problem is related to Merlin using its own way of LED control and ignoring native Asus services.

Deprecation warning

  • :scissors: With the implementation of button.reboot, the previously used service asusrouter.service_reboot is becoming deprecated. Buttons are easier for users to understand (and find) and can be implemented in all the same kinds of automation. If you are using asusrouter.service_reboot in your automations, please replace it with button.reboot. The service will be removed from the integration with version 0.12.0.

AsusRouter achievements

  • AsusRouter does support at least 26 different device models (as reported by users).
  • AsusRouter is used by at least 528 HA installations (as per HA Analytics, so only those who share data). In comparison, in-built AsusWRT is used by at least 2223 users. So, we have ~23.75 % of users in comparison to the integration which you don’t need to search for (and install from HACS). Sounds quite good.

Seems like that is it

:hammer_and_pick: More features are still in progress - I am trying to implement them as soon as possible, but you should consider that this integration is just my free-time project.

Version 0.11.0 of AsusRouter is already available in the HACS.

Release 0.11.0 :gift: More features than can fit in a single release note · Vaskivskyi/ha-asusrouter (github.com)

10 Likes
165

Any idea why the device Hostname won’t show?

ASUS Router Integration - Hostname Unavailable

166

Thank you. Works great.
Actually had to reboot my Asus today and your entity did the trick just perfectly!
Good job👍

167

I’m experience the same issue about event.data.name is always empty. It looks like a bug.
@Vaskivskyi, should we record this as an issue on GitHub or you prefer to concentrate the discussions here at the forum? I’m asking not only about now, but also for when we find issues in the future.

168

By the way, it would be also nice to have the MAC vendor name for new devices event (it won’t add value for reconnections and disconnections). I know this will require Internet connection, but maybe you should just return “unknown” when the request to the external API is not available.
There are public APIs for this: Api V2 Documentation | MAC Address Lookup (this one doesn’t require any authentication).

I’m not 100% sure about this feature request… It would be nice to have, but at the same time it would include external dependencies just to try fixing something that is not trivial in another way on Home Assistant…
Any thoughts?

169

@SpicyLimes, @EdwardTFN,

Anything special about the device(s) with an empty hostname? Wired, wireless? Or does it happen to all the devices connected?

@EdwardTFN,

It does not really matter, whether the discussion will be here or on GitHub.

I also don’t know about MAC lookup right away, but let me think about it.

170

All the devices…
I’ve just replaced my router by a new one, removed the integration and then added it again (now to the new router) and suddenly my automation was triggered for each one for the 70s devices connected… None if those have name.

I’ve also tried to add a device to the manual dhcp list including a hostname. Even in that case, the event returned none for the name. And I can see the proper name on the device list.

171

Just my two cents on the MAC vendor name suggestion:

A quick search found this MAC vendor list: https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd3e4

Wouldn’t it be better to include something like that instead of using external calls? For instance an option in component’s settings to download that list into HA database. The list above is less than 700 kB.

1 Like
172

@EdwardTFN,

Oh, sorry. I know about this, but I don’t know a way to avoid this. When you set up the integration for the first time (so, just add it), all the devices will be new devices and will trigger the event.

I’ll check why this might happen to the device names. I’ve managed to find only one on my network with an empty name in events.

173

I’m fine with that… I believe 99% of people will install the integration before creating the automation based on that integration, so they will never see this… :wink:

174

Seems like the issue is found. The fix will be released later today (CET) in 0.11.1

1 Like
175

:boom: 0.11.1 is already available via HACS

Including a fix for device names as well as a fix for the update entity.

@EdwardTFN, @SpicyLimes, please check whether with the new version all the devices are reported correctly in the events.

Full release log:
Release 0.11.1 :bug: Bug fix and updated translation​:open_book: · Vaskivskyi/ha-asusrouter (github.com)

Update

And the fastest bug fix release is going to 0.11.2. Important mostly for older devices.
Release 0.11.2 :bug: Bug fix · Vaskivskyi/ha-asusrouter (github.com)

Small ad

From time to time (not too regularly), I’ll be reminding, that you can support the development using the Buy Me A Coffee service. :coffee: It’s not obligatory, but adds lots of motivation :croissant:

Thanks a lot to anonymous (not really) and non-anonymous supporters from this thread! :beers:

2 Likes
176

Yes - thank you! The device name is now showing up on “Persistent” Notifications as well as “Notify” Notifications on my iPhone.

ASUS Router Notification

1 Like