I would say, the efficiency should be quite similar for the same result. The only difference - you need a template to check all the devices in the connected devices sensor - so one more loop, but else is the same
Meanwhile, a small announcement 
Any suggestions/ideas?
P.S. @Quacked, @yonny24 (since you are liking the posts), if you want, I can add an asusrouter_device_reconnected event for your use case - to notify when any device is connecting to the local network. But it will be disabled by default with a possibility to enable it in configs.
2 Likes
That would be awesome. Yes Iād need it disabled as I have almost 80 devices around the house. Smart switches etc.
To be able to choose from my known devices could prove to be useful for some as long as there is not too much overhead in terms of memory, cpu, network traffic and storage
Thanks
Not sure if this slow ram leakage on the router is due to this new integration yet. Will keep a close eye on it
Looks like it released some just moments ago:
How can I reduce the thumbprint on this?
Rebooting HA takes longer as this integration really slows it down. I only use about 5 of the entities.
If I remove them (even though they are disabled) from the entity list will this help the start up?
I really need to improve the start-up time.
Update: after disabling several entities not needed like tasmota devices that it was tracking had no issues rebooting. Assume some were slowing it down
Hey,
This is not a RAM leak in the āleakā meaning - it will be released when needed. Also, this is not even from the integration side. This happens with any operations via Web UI or Asus App. As soon as usage reaches something around 80% (depending on the device model and FW), it will start freeing up some memory (a snapshot as a piece of evidence).
But, of course, if your device does not free up memory eventually or reaches a state in which it is not responsive, please open a bug report in the AsusRouter GitHub with data about your device and other details.
As per the second part. By rebooting which part do you mean - turning HA off or turning HA on? Can you please go to Settings - System - Repairs - Menu (3 dots on the top right) - Integration startup time and make a snapshot with AsusRouter and other integrations. An example is attached.
1 Like
Yes, please. But when you said āthat would spam too much in HAā, does that mean an event like that would take a lot of resources or did you mean it would spam too much if I set up a notification every time a device reconnects? Like I mentioned, Iām only gonna get notifications when a device not in whitelist connects.
I just started listening to * in developer-tools/event and see that I have like 100 events within 1 minute and Iām not even home. Iām guessing an event each time a device reconnects wonāt make much of a difference.
Agreed. The new event will be added in the next release.
I meant HA events in general. Each event is written to HA database, so more events - more resources are used. Of course, I donāt expect AsusRouter to overtake all the other events by frequency, but a bit here, a bit there and HA is slowing down with time.
1 Like
Was just a one-off I believe. Super fast now when starting HA. I did disable those tasmota devices it was trying to track that were not disabled by default. Not sure if it was related with those tbh.
Question: What happens if I remove the entities not wanted instead of just disabling them?
Will they reappear after the next reboot?
Thanks
It should not matter, whether you have device_tracker entities enabled or disabled or only some of them - devices are anyway tracked the same way just for the connected_devices sensor. So from the integration point of view, nothing changes.
More than probably you wonāt even be able to remove entities - they can be removed only when integration does not provide them anymore. But as soon as integration knows of their existence, entities will be created again.
Fantastic, thanks!
1 Like
Was notified 2 times today successfully. My sister in law came around. Also when I spun up a new vm in hyperv!
Great 
1 Like
Spoilers for version 0.11.0
Spoiler #1
Spoiler #2
4 Likes
@Vaskivskyi, what will be the cons about enabling the 3 events.
I know some devices (like an iPhone) will disconnect and reconnect all the time, generating thousands (or at least hundreds) of events per day, but what is the problem with this?
I believe as you are investing time into the ability of disabling events by type your are probably anticipating some ācostā from those events, right?
As a user, I prefer the possibility of having control over what is going on. And as a developer, I think users should have such a possibility.
For now, events are more of an āadvance featureā (their settings are also present only in the Reconfigure UI, not during the initial setup). The snapshot is showing the default values - for all the userās new devices will be enabled, on the opposite - reconnections and disconnections - are disabled.
Yes, as I have mentioned before, performance might be one of the issues, which I will not be able to control or fix for users. Some devices do like to āblinkā online/offline too regularly. So if there is a user with 100 devices on their local network, it could happen that their HA will slow down a bit, because of the events raised. Even if not, each event is written into the HA database - it likes to grow by itself, letās not help it 
Those are the only cons I see. From the device performance, nothing changes at all.
My tests
We donāt have that many WiFi devices at home. Out of what I can test - Broadlink RM4 mini is the one that might send 20 events per night (~7 hours) without any reason. Samsung Galaxy Watch (when not connected to a phone) might send 1-2. Simultaneously, there are no problems with Samsung phones, iPad Air, Epson projector, Roomba and 6 ESP8266 devices flashed with Tasmota.
But my integration settings allow up to 9 seconds for a device to be offline before actually changing its status and sending an event. If the user will select to update devices each second and put the consider home setting to 1 second as well, there might be more events.
Conclusion
So, as a general thought, I think users will need to test whether events work well for them and with their settings of the integration.
2 Likes
Thanks!!
A different topic nowā¦ Itās not on the list of the supported devices, but Iām using an Asus Rt-AC88U Wireless AC3100 Dual Band Gigabit Router since a while and everything looks to be working smoothly with this integrationā¦ Perhaps you want to add this model to the supported devices list.
Iām using the original ASUS firmware.
1 Like
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?
@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
updatethe 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 thanconsider home- the device is kept in the connected state
c) Device is off, but time is larger thanconsider home- the device is marked disconnected - List is written to the
devicesattribute 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
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ā¦
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.