#AsusWRT
1 messages ยท Page 1 of 1 (latest)
@flint jetty @main ivy @subtle jay
heyoooo
I am wondering how they are broken tho, as in, Are they for everyone? I now have an asus router in access point mode and it doesn't fill the values at all
They where "calculated" in the lib aioasuswrt, all was connected to a dreadful "cache" that where 100% broken in all possible ways.
Cache is removed from the lib, and therefor also the possibility for these sensors.
IMO its far better to provide right-now-status and if the user wants to add a acc-sensor its very easy to do so, as explained in the PR.
Instead of building "the same" implementation of an integral-sensor over and over in different subdeps.
But you mentioned they were broken
Yeap
also, what's the difference between aioasuswrt and asusrouter
as in, why do we have 2 dependencies
They where resetted after X time and as that was not taken into account they where at best an indication only
And they where also fetched in a broken manner https://github.com/kennedyshead/aioasuswrt/issues/44
asusrouter is connected through http/https. aioasuswrt is ssh/telnet
Ah, that's also on my list to figure out, why do we offer the user this choice instead of just rolling with it ๐
Using the http/https implementation do not work for me, as it actually sigterms my router (these routers are sensitive and need a lot of care)
lmfao really
But even then we could just try to probe
as in
as a new user I don't really care what method I connect with, and they would probably also try http and find out that their router broke
I had a long break from all HASS code TBH, this is also a reason for the defrag
Well... ssh needs to be enabled, telnet is turned on by default IIRC but also very sketchy. Http/Https is not viable on all routers.
I was not appart of adding http/https
Oh yea I am not blaming you
๐ I would not have taken it personal ๐
just trying to understand the context and ideally we just make sure that the user doesn't have to pick
We are now in contact with Asus, so I think if there's something you need we can ask and maybe we can get more info on certain things
IMO we should default to ssh, and just add the others as "optional". That way the router atleast wont crash
I am also wondering, what way gets the most data
Are there extra benefits in https or http
Like in theory we could just make a think like, if you enable this checkbox we will probe the router, after which you might need to restart the router
Nah, I think I have a good understanding about these routers.
No there is no extra benefits, all that data is available in cli, but the lib is not developed to support all that data
Is there planns to add support for that? But yes, all that is on web can be done in the same manner through CLI. The web is really just a proxy
I have a router with RGB now
I mean, that do not mean that I personally will dig into those things as its in no interest for me. But I sat up pipelines for building and publishing aioasuswrt and am very open to getting help with the package: https://github.com/kennedyshead/aioasuswrt/issues/95
Ah check, yea I added the other codeowners here as well, would love their input on this as well
Sure thing ๐
In any rate, I am pushing for rssi really atm. All data is done in lib.
I could create all the current sensors in http to start with so they do not differ (apart from the acc-(tx/rx), my opinion is that those should be removed and calculated in hass for ppl that want them)
But not in the current package bump though ๐
Also, I am wondering if you can discover the router on your network, I am not able to find it using SSDP or mDNS
And if we do not want dual packages I am in for removing one or the other ๐ Makes no different for me as I have the ssh/telnet through aioasuswrt in a custom_component for testing anyways that I will keep using ๐
But I would argue that there is a good idea to have different options here. These routers are... And they blow up now and then becasuse of FW-updates, but that do not mean that if http blows then ssh also blows or the other way round
I mean, my goal isn't to push everyone to the same protocol, it's more that I would like to see a way where we don't bother users with the choice of what protocol
This can be done! I dont remember atm how I did that though. But its somewhere in my notes IIRC
Well, its. a long road to get to that "auto-pick" state, but everything is doable ofc
fyi, telnet and SSH are off by default
there's a network browser in HA since a few releases
so you'd be able to find them
I must have had a bad memory
I mean, this is a pretty new router, so they could have changed as well
That can actually be found out
With/without the PR?
Well, I have not added alot of the info that is available
to Hass
They are added?
are they not?
That is very strange if they are not?
Ah! That is different yes, but it should see some?! Check if there are disabled entities
there are none
2025-09-30 12:34:25.243 DEBUG (MainThread) [aioasuswrt.asuswrt] Could not parse row: 169.254.0.2 dev eth.ai-10 lladdr a0:ad:9f:0f:03:d9 REACHABLE
That's something that I see in my logs that mihgt sound interesting
oh! I know already what it is! its that .ai-10
I assumed so ๐
Will patch that in the lib ๐
What was your router name?
I mean what is the version of router
๐
I believe its ROG Rapture GT-BE19000AI
TY
Even though Id rather sit here all day and build on the asus integration I really need to run to business-meeting now ๐ bbl
hah
don't worry ๐
That also has to happen
lmfao so I tried agent mode and I hink it messed up the regex somehow
If you give me those DEBUG codes I'll fix them aswell ๐
which ones
Just logs
Aha ๐
I have become the thing I swore to destroy
Agents suck balls 99%
I rather do it myself atm. either it gets overcomplicated/fails or just plain wrong with agents is my experience ๐
Oh I understand
But this sounded like a perfect task for an AI
as in, I was confident it couldn't mess it up, but I think it still did
I mean, I use llm in my dev-setup. But not for creating PR:s and stuff
if this was an issue in the HA repo I could have assigned it to copilot and it would do its magic which is quite cool
its just helping me in neovim sometimes
NEOVIM MENTIONED
Oh, well they have this: https://github.com/home-assistant/core/blob/dev/.github/copilot-instructions.md
yes, but we also get more copilot features ๐
kewl ๐ I am working on my own private focused AI setup for those things @ https://code.botwork.se
Dont like the monopoly of github
sounds cool
Can show you at some point ๐
At the end of next month I will be at the devil's den at Github HQ ๐
Oh! ๐ I think it can be very interesting to see GH behind the scenes
But still, for me. Living in EU I dont see any reasons to send my code over seas if I can do it just as well over here
oh I understand
they have a screen with realtime updates happening on github haha
I am on a de-google de-ms de-apple journey ๐
you're not alone, I also like that movement ๐
I don't participate as hard, but I do like the initiatives
However on that note :S
liquid ass
oh man its great
Yeap! I so wish they where more open so the linux distros could run on these machines though
Hey, guys ๐
Which router do you have, @main ivy , if it does not work properly with HTTP(S)? I have a test RT-AC66U with Merlin 380.70 - FW from 2018, router from 2013 which works just fine
From my pov, HTTP(S) allows being fully agnostic to the exact FW and implementations on the device. While it does not matter a lot when reading from nvram, I would not say the same on writing. API has protection. Writing wrong to nvram directly can cause issues with the device. Plus it gives standardised feedback when running services. All the restarts of demons, reboots, aimesh things can be done manually running commands. But who would check that for each case
Good morning @flint jetty really nice to meet you โค๏ธ
Safety: I cant see the problem here?! We would not do something wrong while writing!? Why would we? And as we have full access in the CLI connection there is a lot more options than in http.
Agnostic: CLI is just as agnostic as the http that can differ from device to device and versions. I would even argue that http changes more than the CLI-interface.
While I do think that both approaches has their drawbacks (I can go into detail if we really need to). I do not want to draw attention from the goal of building something great with argues about that particular topic ๐ IMO its great to have options so that if one fail the other can be used.
The problem for me is:
- The implementation in hass is a bit struggling TBH, it feels very defragmented.
- After/If I get the bumped
aioasuswrtversion merged, I will do a cleanup PR that hopefully will clear things up. - If its decided to not merge, I will open a PR removing the CLI-stuff instead. State before the bump is to sucky to use IMO.
- When dealing with tickets its always a problem when you need to ask what type they use (a small one but still).
Also problem (solved): I got swamped a couple of years with things blocking me from fixing aioasuswrt. Now I have a new situation where I can actually work on the code again (detail here is NEVER agree to any CEO/CTO possitions!!! It will just burn you).
I started meshing, and that made me want to try out some triangulation of ppl through rssi I have a PoC of actually doing this even though device is just connected to 1 end point at a time.
I also started to dig around in more things in aioasuswrt and what we actually use in hass and realized that there is a lot of things just garbaged that could be super useful for me (and probably others).
I also wanted to fix the currently broken things (remove that nasty "cache"), and optimize the code for better memory-usage and less CPU-hog. (I have just done a 50% improvement in exec-time actually, and the memory usage is ~20% less than before).
@sharp moon the fix is in the package! TY so much, will bump the current PR with a minor before merge โค๏ธ
Did anyone try looking at discovery yet?
mDNS reports these two on my network:
+ RT-AC88U-2780._alexa._tcp.local
+ ZenWiFi_CD6R-203C._alexa._tcp.local
My best guess is to use the ._alexa. part
Or map all possible router names... Which is going to suck
What about ssdp?
I'm assuming that this is specific for Alexa so I'm not sure what other brands do discovery via this mDNS name
It looks like finding it, I will test for a bit, already started implement zeroconf now so there will be PR as soon as its stable
Also do note that we're in contact with ASUS ๐
Could you test a search for "urn:schemas-upnp-org:device:WANDevice:1", it should be there
But that is if you actually have upnp turned on though
Found it without upnp
check Home Assistant
we havea network manager now
Network discovery
I don't see mine here
but its in AP mdoe
"ssdp": [
{
"st": "urn:schemas-wifialliance-org:service:WFAWLANConfig:1",
"deviceType": "urn:schemas-wifialliance-org:device:WFADevice:1",
"modelDescription": "ASUS WPS Router"
}
]
But strangely it does not show up when I added to manifest ๐คท
Could be my devsetup though
but can you check via this? This is how HA sees it
as in, no SSDP expert, so might be the same
did you run hassfest after this btw
Nice
If @flint jetty can find time next week to check if the newer router also exposes something, then I can look further into how we can improve discover
Does not work for me. Neither the PR nor the HA is showing routers up in the Network Discovery
How does the discovery tab in HA work at all? Do I need to set something up additionally, or it just shows everything on the network?
Nope it just works
Guessing you turned off WPS and UPnP?
I will add the UPnP search to ๐
Have updated the PR
SSDP and mDNS is just found on the network, dhcp only works when a device gets a new IP
Yeah, I think this is my network issue. My podman container with HA needs full access to the host network for this... Anyway, will solve this in the evening. Also, the HA dev container on Windows cannot do this at all ๐
Meanwhile, with Wireshark monitoring, I can confirm, the newer router does not send anything at all in SSDP, even in router mode.
GT-AX11000 Pro (router, 3.0.0.6.102.x branch) and RT-AX88U (AiMesh node, 3.00.4.388.x branch, Merlin) both send something, so they should be discoverable
Btw, this is how config flow worked with SSDP in my custom integration: https://github.com/Vaskivskyi/ha-asusrouter/blob/0978febf89de175c4f091724894e46cc796c22d4/custom_components/asusrouter/config_flow.py#L618
with serial for unique_id. But some users reported multiple discoveries after setting up, which I did not manage to fix before fully removing SSDP. For me everything worked well ๐ซค๐ฉ
Let me write back to Asus then, because at this moment it seems like we get a lot of different discoveries, or just none at all
We can use UUID under UDN, that should be unique!
what do we currently use as unique identifier?
Looks like SN but that is not unique IIRC
Can be wrong about that though
We will run into a problem using both ssdp:s, the UUID differ, and so does the SN
I think the only thing that I would be interested in is for @flint jetty to check mDNS on his network, fyi btw, you can use an app for that
I just sent an email to asus, I explained that we're looking for a discovery method for both current models and future models that will work
zeroconf for tnew device you mean?
ye, they claim that their new device would do mDNS
But with my router in AP mode I don't see any mDNS
Do you see any ssdp?
TY ASUS ๐ข
There must be a way!
Would be strange if you could not map it some wow
Does it have BT ๐
I mean, DHCP is always an option, but definitely not my preferred one in here
but I think we can steer them a bit here
I guess it answers on router.asus or whatever the address was
but then you're assuming it uses the router for DNS
nope
I do think using SN as unique is not correct though...
I mean in a way its unique
but my concern is that we need to know this for other discovery methods as well
as in
if they now do update your router to add mDNS
and we just picked the UUID as key
and we have no way of knowing the UUID via mDNS
then we can only ever discover the first one
@sharp moon, no mDNS visible from the new router
Why don't you like SN as a unique ID if we filter to only Asus devices? SN visible in UPnP / SSDP is the same as the one in NVRAM and can be read via SSH / Telnet / API. And it is exposed openly, while MAC is not
http://192.168.55.1:49152/wps_device.xml (both routers + nodes)
http://192.168.55.1:38153/rootDesc.xml (routers only)
So, if we see SN discovered, which is already set up in the integration via any other method, we can ignore it. With MAC - this will not work
Also, currently unique ID for config entries is the MAC address
I think that's a fair argument
So, once per 75 min each of 3 devices sends this and only:
Answers
_services._dns-sd._udp.local: type PTR, class IN, _alexa._tcp.local
Name: _services._dns-sd._udp.local
Type: PTR (12) (domain name PoinTeR)
.000 0000 0000 0001 = Class: IN (0x0001)
0... .... .... .... = Cache flush: False
Time to live: 4500 (1 hour, 15 minutes)
Data length: 14
Domain Name: _alexa._tcp.local
as an mDNS. Which is pointless, and I only accidentally saw it since forgot to turn off wireshark. But if you check with zeroconf for everything inside _alexa._tcp.local
you get
Service: GT-AX11000Pro._alexa._tcp.local.
Info: ServiceInfo(type='_alexa._tcp.local.', name='GT-AX11000Pro._alexa._tcp.local.', addresses=[b'\xc0\xa87\x01'], port=80, weight=0, priority=0, server='GT-AX11000Pro.local.', properties={b'skillSetupId': b'8b18386c-1353-4612-9626-714937decf3e', b'version': b'1'}, interface_index=None)
Service: GT-BE19000AI-53A0._alexa._tcp.local.
Info: ServiceInfo(type='_alexa._tcp.local.', name='GT-BE19000AI-53A0._alexa._tcp.local.', addresses=[b'\xc0\xa8M\x01'], port=80, weight=0, priority=0, server='GT-BE19000AI-53A0.local.', properties={b'skillSetupId': b'8b18386c-1353-4612-9626-714937decf3e', b'version': b'1'}, interface_index=None)
Service: RT-AX88U-6D90._alexa._tcp.local.
Info: ServiceInfo(type='_alexa._tcp.local.', name='RT-AX88U-6D90._alexa._tcp.local.', addresses=[b'\xc0\xa87\x02'], port=80, weight=0, priority=0, server='RT-AX88U-6D90.local.', properties={b'skillSetupId': b'8b18386c-1353-4612-9626-714937decf3e', b'version': b'1'}, interface_index=None)
which would show the skill ID corresponding to (probably) AsusRouter skill 8b18386c-1353-4612-9626-714937decf3e for all of them
I think that the mDNS of ._alexa ._tcp.local might be a good choice for discovery
I also think that mac is a bad choice as unique, but SN as far as I understood when looking at it in the ssdp discovery is just not tied to the machine. Could be wrong here but if we took 2 routers that are the same model and version I think the SN will be the same TBH. That is no good if running in mesh, when you are likely to have the same version sometimes.
serial number generally is unique for the device
Like yes, in some fields, serial number is not unique
like idk, barcodes
but in IoT I kinda consider it unique
but like said, we're on contact with ASUS, let's try to push back and see if we can get a better mDNS packet, because now we'd be depending on Alexa
as in, if Alexa changes their discovery method, or Asus stops supporting Alexa or Asus creates routers that doesn't support Alexa, we're cooked
so I rather want to push for a generic discovery method
Well, for the SN in WFADevice its 0000001 for me, and in UPnP its the mac
So I do not think its as unique as we think ๐
The strange thing is that UDN do not match either... ๐คท
okay let me rephrase, if we can get the real serial number reliably, it's a good pick
๐
That i could agree to ๐ Problem is that we dont have it in discovery, so its hard to map to device that way. Ip is actually the only "unique" thing I found so far and its extracted from the location
Yes sorry, IP
but that's unique, but not good for HA
and it can change
I wish I had twin routers so I could compare some things
starts browsing amazon
I have twin routers accessible. Let me check...
All the SNs in rootDesc.xml are the correct device SN for both - same as printed on the label and as in NVRAM
This is probably why some of my users were having issues with SSDP. Are you on stock or on Merlin?
Tested on a pair of ExpertWiFi EBG15 (both with FW 3.0.0.6.102_45537)
Merlin. and stock. The ZenWifi one is stock.
What is the key in NVRAM for SN? Cant find it, which could be the root cause with the router not reporting it.
I think I have a workaround lined up for unique_id where the SN is missing, let me just try it out and I will present it to you guys for feedback.
My suggestion in the meantime is:
- Lets create 1
ssdpdiscovery and filter out all routers where we cant uniquely identify the machine?
(My best bet so far is the UPnP one that seems to be present on at least most systems that have the feature turned on.) - After this we add new discoveries one by one in a relatively ordered fashion, this way we can get a more thouroughly tested discovery service.
There could be a need to handle the setup flow differently for cli/http and this raises the question again if we want to support them both. Even though most things can be automated in the setup-process there could be a relatively long roadmap to even add one discovery service if we want to automate the steps from the get go. And if we dont automate then it could be a cumbersome process to setup a device (its already more of a tech-guy-knowledge setup as it is IMO.).
My router do not respond to the wps_device.xmlunfourtunately
Nvram key serial_no is not present for me, as I suspected. MAC is there though.
Ok tested a little bit and it should work, but there are caveats.
A "vision"-flow for a router setup IMO (the AP one needs to be a bit different as its not reported in ssdp)
- ssdp discovery finds server and extract the IP and MAC (the
upnp:rootdeviceis what we can use asWFADevicedo not report MAC and has SN 000001) - IP can be used to auto populate, and MAC is under
serialNumberso we let that be the identifier for the routers without SN reporting and any other serial_no value for the routers reporting correctly. (not optimal but its our only option here, the option would be to use the USN as fallback for these machines instead of the MAC under SN). - Username / Password is default for setup. But I think we should add a step for creating and uploading ssh-key here with a passphrase so that security is strengthened and/or give instructions to how to add this. (IMO username/password is not enough for security TBH) We should also create a user that is dedicated to hass in this step. A one-time flow to add new user with key via the admin-user prevents possible problems if the user decides to change the username/password later on and will also open the opportunity to limit the access for hass by adding/removing from groups.
- Next step would be a "service-selection", tickboxes with available things. Reason for this is to be transparent with what you actually get access to by adding the integration (I also strongly believe that this will give users less of a "why does this device not show up" feeling by explaining why they are not active by default, maybe even a "map entity to device" functionality?).
Just brainstorming ๐
And my ZenWIFI that is meshed reports upnp:rootdevice but no SN and no manufacturer info at all. It has UDN/USN and reports 0 data about the mesh-setup.
I think that we should use USN/UDN if available as unique tbh, that would create a most generic approach that seems to work on most devices AFAICT
So, for my merlin router I can get the UDN from sspd and then match it to the UPnP service running (this is set once per system but on one of my machines its not saved in nvram?!?!). For the stock router I can match the UDN to nvram uuid.
This means I atleast now know where to start the matching code in the PR ๐
I will start coding for matching in aioasuswrt and update the discovery-PR as soon as I get a moment. After an initial router version, I will focus on fixing the ap discovery. What router are you using @flint jetty
But, I would like to refactor the component a bit first so that it's easier to maintain. Given if we decide on keeping both versions going fwd that is? So that is a blocker for me atm. We really have to decide.
I think we would need to have a discussion on what protocol we want to use and why and what asus sees as official, because if they can provide http docs and ensure that this will stay like this and not break, then I'd go with http
I can only say I agree ๐
Like I don't want to start a battle which method is the best, in the end I think we should collect enough data to make a wise decision
I have 0 issues with that ๐ For me its all about a pragmatic approach to whatever problem that we are facing! You will never get drama from me!
Drama is for kindergarden (and linux-kernel)
lmfao yes
I just stated the obvious problem if I spend time on cleaup PR and then we decide to just do one integration I did all work for nothing ๐
its independent to what solution we pick ๐
And either way i will build aioasuswrt to do the things I think is a good integration and publsih a cc to hacs when I feel its good enough for my wife
This is mainly because I have had problems running http to my routers and dont need the wife nag about that ๐
I dont remember the exact issue on top of my head, but result was a frozen machine
Oh i agree, like, i dont want either of you to spend a massive amount of time on something that's wasted. Maybe the result is that Asus will help us and we find a way to get it to work nicely via HTTPS, or maybe we find that it still doesn't work reliably and we just do a dynamic approach
Sorry, again missed it. Yes, serial_no is the one, but apparently it does not go back too far. An old RT-AC66U also does not have it
The port might be different - that's what I noticed trying the ExpertWiFi EBG15 models. I found it in some of SSDP notify messages
I think creating a new user is a bit of overkill. Is it purely to avoid issues if the user changes their password? With http, we can trigger reauth if the password has changed / credentials are wrong - it's one of the pre-defined statuses
GT-AX11000 Pro (main router) + RT-AX88U (AiMesh node) for the main network + I have access to do tests on some other models (RT-AC66U, EBG15)
I mean if they have your router password you'd be anyhow in trouble
No matter if you have ssh enabled or not
Yeap. Asus tried hard to solve this issue, so you can limit access with up to 4 rules (4 IPs to allow) ๐
Its not only to fix a pwd-change. It can restrict access, but its further down the line anyhow... Many things to break and fix before its on the RM ๐
So, any words from Asus on the matter of supporting http as a standard?
Nope, somebody else got pulled into the conversation
I would not say that the small specialised corps are any better. Here you get many extra people in emails ignoring you, there you are ignored by the only single person
Was thinking about doing a cleanup without touching the defragmented dual-integration parts. There are stuff to improve for sure in the asuswrt integration. But it feels a bit dumb to walk around the "hot plate" like that because the defragmentation is the root cause IMO.
Company run by email ignore, one of the absolute best! ๐คฃ
Lovely
Yes I'm also one to check my mail better
Nah! Havnt opened mine for 3W now
Who needs to see all spam from ppl breaking pipelines and doing "Fex" commits
Currently a quite small one, 20 devs something
But I've done them all
And let me tell you, big-corp stands out
metasolutions.com is where I work atm. (besides running botwork.se as a side gig)
Ah, so another point for non responding people in small corporations
I mean, I am responsive in PR:s and the company slack... That is enough IMO
Then I do a sweep every other week in the mail
For me it's hard to understand your field of communications. I come from research, not from IT, software or nearby. So a subuniverse, where your email is valued more and replied faster if you have Dr. or Prof. infront of your name ๐
Honestly, one of the biggest issues of today is the constant preassure of keeping up with information by force! We need to flip that into us deciding when we are up for receiving the data ๐ humans is best at pull not push data ๐
IT is not the same as other businesses, agree there
Worked in fintech a while, that was only email and PR on BB
Why BB is still beyond me
Ah, sorry, I am actually on the other side of communications - I bother people that something broke, we want it to be fixed today and not in a year ๐ But that's hardware, not software. Scientific SW is always crap, that is by default, it won't change
I think there are as many problems as there are companies at this point ๐
And they mostly start at communication
You know the best SW fix we got? A device (FPGA) for fast high voltage control. Was freezing due to the "too much data" when a position slider changed in the PC software. The fix was to make the slider literally luggy. Now FPGA does jot crash. Just the SW use got even more frustrating ๐
lmfao
And ppl think AI is going to save us when its trained on data from the ppl it is meant to help
GLHF AI and people trusting it ๐
But yea, for asus, maybe its nice if we explain a broader context, as we don't really have secrets, but they want to pre install HA on one of their routers, and for that they want the integration to be nice. They are of course driven by their router, so I assume they don't care as much for older devices. However, we want to take this moment to actually improve the integration as a whole and not just for 1 device. Ideally we come up with a way for older devices and future devices
So I think having more people in the conversation that can explain us about older firmware or firmware for different routers could help us as well
Maybe a split of integration is a good thing here?
One for integrated and one for legacy devices
I mean, the device itself has the same API as before, I can just connect to the device via http and via SSH (apart from that bug we found)
So I don't see a reason to split it
Ok! I was thinking more on the legacy ones and how to manage those when asus do changes to their new linup.
That's something I suggested more than a year ago. Have one with SSH/telnet separately from HTTP/API. Before ollo got his http lib into AsusWRT. I agree, that this will be confusing for users
I think that's also a matter of testing
We can mask it ๐
As in, making sure that we have test fixtures for older models and that we test against it
But for me its only a matter of a yes/no to keep ssh/telnet in the component at this stage. When I know that answer I know where I should put my efforts ๐
I also don't have an answer on that yet, but like said, I want to make a data driven decision on that and not just an opinion contest
And in either case, I would love for you both to stick around as you have a ton of information about these routers, and the more stable we can make it, the better
Not my intention to stress you โค๏ธ
I guess I could complete the discovery one even without knowing that though. It should not be harder than what I described in one of my A4-rants the other day
Just eager to do something fun this weekend ๐
you mean based on alexa?
No, based on SN (that is not really SN in some older models)
ssdp
I know it do not include the AP ones, but for router I think it will include most
If they are not nat:ed and so on, but that is a totally different beast
Let me be frank here. Otherwise it's not fair. I got invited here by Asus to bring my AsusRouter http lib to HA. I am not saying Asus is purely interested in HTTP - they want money and the HA label on their boxes and nothing else. I don't actually mind regardless of whether we will keep one or another connection. I use my custom integration in any case ๐ Anyways, I can help with what I know about the new models and help with testing
Just don't expect that we will get Asus reply / decision fast - they always take time to think about
I see those dots rolling. Really curious at this point @flint jetty but I need to run so I'll catch up later โค๏ธ
I might focus on my other "hacking"-project this weekend though. Integrating Living-AI EMO bot into hass
I am at the conference. Have all the time today. Talks are boring. Some cosmology / high energy things...
I mean, it would be nice if we could get it to a point even you would consider migrating to core ๐
At this point, I don't expect much, but anything we can get is nice
Bug fixes are slow. I know myself ๐
Sure, we only release once a week, and not whenever you want as with HACS, but that also gives a bit of structure and the responsibility is shared
BTW, Merlin got 2 more new Asus routers recently to consider his FW support (from his words on the forum). Asus is getting more active with community projects
Dont mind a slow update cycle! Rather do that and not get flooded by tickets TBH.
I mean everyone has their preference ๐
and sometimes a slow update cycle is the cause of a ticket flood
Yes, but not when things are stable to start with ๐
Hm... Fixing a bug, I found another one... My GT-AX11000 Pro can get to the state where you cannot log in anymore through the WebUI, getting wrong password even though it's correct ๐ซค
But no problem, still works from the HA on HTTP(S) then ๐
Asus have really done some strange things here! Fingers crossed that they will solve these issues.
@flint jetty Pipeline is failing
TY pipline, this is very true... not being home is not the same as being home... Feels like I am talking to AI here ๐คฃ
As the docs say "It happens to all of us" ๐
meh, AI would've wrote this in a 10 line essay
Yes, and in a very neutral tone.
Works now
Why is this one still open? https://github.com/home-assistant/core/issues/31404
It's not on the integration or libraries - this is an FW issue which cannot be fixed anyhow. The devices themself have an overflow in the traffic recorder at 4 GB. But anyway, that's for some old ones. The new overflow above 20 TB (don't ask why I know this)
lmao 2020
What's the device class set to
SensorDeviceClass.DATA_SIZE
SensorStateClass.TOTAL_INCREASING
That should be correct
this ties into the "total transfer"-removal I did in the bump-PR @sharp moon .
By the trx-fix I just implemented in 1.5.y yoy now could do this sensor by just adding an integral-helper for rx/tx and that would actually be accurate, instead of using the FW-broken trx data with reset after 20TB/4GB
That is my main reason for removing that sensor anyhow
That is really the only way to get that sensor accurate! I tried setting a variable in the api object... Could have figured it a bad idea if I hade thought about that for a couple of minutes as it will reset as soon as the class is recreated, but it got into hass. The transfer is not only resetting btw, its highly inn-accurate IIRCC .
This is also related to why I switched to a different aproach to get rx/tx explanation. To my understanding Asus uses the faulty-method for that total transfer value.
Sorry for the pedantic stuff, my OCD is going haywire over here.
Just appologized to @subtle jay and @flint jetty for getting pinged in PR:s. Not much else ๐ You?
@main ivy you can close your own issues by using the bot commands
I remembered that like 3 sec after that comment ๐
Hey, guys. I want to add the update platform to AsusWRT. Any objections?
Do it! 
Making it work is simple. Writing it nicely is boring... And I have not even started with tests yet ๐ซค๐
hehe
I think this is a great step, problem is all the different flavor?! I guess that can be handled but It will be "fun" ๐
Flavor?
Merlin/Stock and on top of that there are deprecated HW and so on. But they might handle updates the same though, did not really think about it to long ๐
@flint jetty hey how did you now find the color things on the router?
Which colour thing? Aura (RGB)?
yes
I just have it between other cards on the main dashboard (the second button in the menu). Same as before. I don't think this card can be (re)moved
Did you just copy the http endpoints from the web app?