I’m experiencing an issue in my HA asusrouter integration logging a lot of the same error:
Logger: asusrouter.util.parsers
Source: custom_components/asusrouter/bridge.py:230
Integration: AsusRouter (documentation, issues)
First occurred: 09:00:07 (189 occurrences)
Last logged: 09:31:07
Failed parsing value ‘isGN’. Please report this issue. Exception summary: (“Wrong value 3 of type <class ‘str’>”, None)
Failed parsing value ‘isGN’. Please report this issue. Exception summary: (“Wrong value 2 of type <class ‘str’>”, None)
My running configuration is:
Asus Router model RT-AX88U - (acting as wireless router) Merlin FW 388.1
HA Integration Vaskivskyi/ha-asusrouter 0.14.2
Home Assistant 2022.12.5 - Supervisor 2022.11.2 - Operating System 9.4 - Frontend 20221213.0 - latest
Does anybody is experiencing the same issue and can help me to solve it?
Unfortunately, I will be able to check anything only after Saturday, since I currently do not have access to the testing environment. But since I have exactly the same RT-AX88U, the problem should not be hard to find and solve.
It seems like the backend library is receiving unexpected values. Can you let me know, which Guest WLAN networks you are using? 2.4 GHz or 5 GHz and the number of the network(s) in use - 1, 2 or 3?
Hi Yevhenii, thanks for your reply, but take some time to solve it I’m not in a hurry, indeed thanks to you for spending your time to produce this component. Here what you need (I think). Guest 1 not used.
Updating to this version might disable your current temperature sensors and create new ones. In this case, please remove the old entities, enable the new ones and assign them entity_id’s as before.
Requirements
Minimum Home Assistant version bumped to 2022.11.0
New features
New guest_id integer attribute added to the device identities (and device_tracker entities), which shows the number of guest WLAN (e.g. 1, 2 or 3 when connected or 0 when not connected to a guest network)
Added support for the temperature of 5 GHz-2 and 6 GHz wireless modules (device and firmware dependant)
Bug fixes
guest binary attribute of device_tracker entities fixed (reports #C294, #384)
Breaking
Deprecated in 0.13.0entity_id, mac and name parameters of asusrouter.device_internet_access service are removed
Migration from versions 0.5.1 and lower is removed - consider the new migration FAQ if you need to update from an older version
I just updated to v.0.15.0 and noticed that the original temperature sensor entities are now unavailable, but new sensors (currently disabled by default) are available. Screenshot attached below shows the unavailable entities in yellow, and the new entities in blue.
Am I to delete the old entities and activate the new ones to use in their place?
Yes, seems that such a problem might happen on the update. Unfortunately, you would need to remove the old entities and enable new ones. In case you are using them in automations / frontend, you can assign the same entity_id’s as before as soon as the unavailable entities are removed.
Seems like now there will be 3 integrations for Asus routers:
AsusRouter custom integration (<-- you are here).
AsusWRT built into HA Core (the stock integration).
AsusWRT custom by one of the stock integration maintainers, which just got added to HA brands. Apparently, this means, it is heading to be added to the HACS default integrations list. Before it was “just for testing purposes”. The difference with the stock - is the added HTTP API support (the one which is used by AsusRouter) for which PR to the HA core is stale for many months.
Apparently, AsusRouter is doing something right
since the library behind the “new” custom integration just borrowed our temperature sensor parsers and regular expressions - the ones needed to support different values templates between FW versions 374.x, 380.x, 386.x and 388.x
AsusRouter is staying with you and becoming even better
Regardless of the success of the stock and the new custom integrations, AsusRouter is going to stay with you as a feature-full and customizable integration.
Do you like AsusRouter? Let the word about it get to other users of Asus devices. Maybe, they don’t yet know about the better alternative to AsusWRT core integration.
This release is not bringing many new features and some of the changes will not be visible to the end users. But it is here to improve both - your experience of using AsusRouter (keeping all the settings as consistent inside the integration as possible) and my work on the new features and bug fixes.
Features
Improved hiding of protected values from the entities attributes
Security-protected attributes are hidden from the binary_sensor entities
Move all the control/no-control features from the library to the integration
The confirmation step is removed from the options flow as obsolete - there is no need anymore to manually reload the integration after changing its settings
Bug fixes
Fixed Device is connected in no-control mode. Sending commands is blocked when in no-control mode, raised by the update entity.
Fixed bug with missing timemaps in parental control rules (report #369)
Breaking
Services asusrouter.adjust_wlan and asusrouter.device_internet_access are available only in control mode of the integration - which would be the correct expected behaviour.
Thinking of buying a new Asus router to use with AsusRouter integration? Check the compatibility list in our Docs. If you will use any of the Amazon Associate links, I might get a small (1-3%) bonus from Amazon (usage of the associate links does not change the price of the items for you)
Thank you so much for this. My phone gps isn’t reliable so use this as a primary tracker.
Recently (maybe since the latest merlin update?) my phone isn’t updating as Away (always Home). I noticed in the attributes the last Activity is updating even though I have been away from home WiFi for an hour. I confirmed the MAC is correct.
Definitely enjoy the holiday vs thinking about this though!
I wouldn’t rely on the gps integration in ha, as it seems to “fallback” to the “phone operators” basic info… showing me “permanently” more than 200km south of my “Home” , i have no problems with the GPS on the phone, if f.ex. driving my car after a google or other “route” maps … AsusRouter are the first instance to discover my phone , halfway up my driveway ( on a good day )
EDIT: to ha-gps defense i should maybe mention that i live on the countryside, surrounded by high trees, and a “spot” (consumer/revenue) neglected by most phone-companies here.
Yeah, this is a lifesaver for automation sanity. My GPS is just bad no matter what (defective is the best way to describe it) as even in Maps it shows me off the road.
I really wish HA zones could be configured to accept ssids as criteria also. Off topic I know
Just checked again on the attributes and my phone ‘last activity’ is still updating though I am 100 miles away.
Actually it almost “killed” me, after initially using trackers created by default-ha integrations ( latest ASUSWRT ) and switching to AsusRouter ( well actually after when i got my Asus-Router-Hardware, last December ) , my heart jumped when suddenly my courtyard was lighted up before i entered
Portuguese (Brazil) and 
Slovak correspondingly.
Czech
English
French
Spanish
Ukrainian
The fix will be available with the next release. Sorry for this bug
More temperatures and fixes
Known issues
Requirements
New features
Bug fixes
Breaking
Documentation
Dependencies
Github / HACS
Other changes
Achievements
Work on the AiMesh support has officially started! 
Dutch translation
Dutch translation (author: 
More Asus integrations in this town
Apparently, AsusRouter is doing something right
Support AsusRouter
