#AsusWRT

1 messages ยท Page 1 of 1 (latest)

sharp moon
#

asuswrt

#

@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

main ivy
#

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.

sharp moon
#

But you mentioned they were broken

main ivy
#

Yeap

sharp moon
#

also, what's the difference between aioasuswrt and asusrouter

#

as in, why do we have 2 dependencies

main ivy
#

They where resetted after X time and as that was not taken into account they where at best an indication only

#

asusrouter is connected through http/https. aioasuswrt is ssh/telnet

sharp moon
#

Ah, that's also on my list to figure out, why do we offer the user this choice instead of just rolling with it ๐Ÿ™‚

main ivy
#

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)

sharp moon
#

lmfao really

main ivy
#

๐Ÿ˜„

#

Well, asus is "great"

sharp moon
#

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

main ivy
#

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

sharp moon
#

Oh yea I am not blaming you

main ivy
#

๐Ÿ˜„ I would not have taken it personal ๐Ÿ˜‰

sharp moon
#

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

main ivy
#

IMO we should default to ssh, and just add the others as "optional". That way the router atleast wont crash

sharp moon
#

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

main ivy
#

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

sharp moon
#

maybe that also isn'y great either

#

also stuff like RGB and whatnot?

main ivy
#

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

sharp moon
main ivy
#

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

GitHub

Hi! If you are a happy and fun person and have an urge for getting aioasuswrt to elevate from OK to GREAT please put a comment here and we can discuss if we can add you as a collaborator. Prerequis...

sharp moon
#

Ah check, yea I added the other codeowners here as well, would love their input on this as well

main ivy
#

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 ๐Ÿ˜„

sharp moon
#

Also, I am wondering if you can discover the router on your network, I am not able to find it using SSDP or mDNS

main ivy
#

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

sharp moon
#

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

main ivy
main ivy
sharp moon
#

fyi, telnet and SSH are off by default

sharp moon
#

so you'd be able to find them

main ivy
sharp moon
#

I mean, this is a pretty new router, so they could have changed as well

main ivy
#

It can be that the old ones only supported telnet until som hack

#

๐Ÿคทโ€โ™‚๏ธ

sharp moon
main ivy
#

That can actually be found out

sharp moon
#

this is now the only thing I Get

#

I now tried via SSH

main ivy
#

With/without the PR?

sharp moon
#

without

#

this is 2025.10 beta

#

I would have expected device trackers

main ivy
#

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?

sharp moon
#

they don't seem to be

#

note that I am in access point mode

main ivy
#

Ah! That is different yes, but it should see some?! Check if there are disabled entities

sharp moon
#

there are none

main ivy
#

Hm...

#

interesting!

#

Do you have access to a python interpreter in your setup?

sharp moon
#

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

main ivy
#

TY

#

Will start analysing that one ๐Ÿ˜„

sharp moon
#

That's something that I see in my logs that mihgt sound interesting

main ivy
#

oh! I know already what it is! its that .ai-10

sharp moon
#

I assumed so ๐Ÿ˜›

main ivy
#

Will patch that in the lib ๐Ÿ™‚

#

What was your router name?

#

I mean what is the version of router

#

๐Ÿ˜„

sharp moon
#

I believe its ROG Rapture GT-BE19000AI

main ivy
#

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

sharp moon
#

hah

#

don't worry ๐Ÿ˜›

#

That also has to happen

#

lmfao so I tried agent mode and I hink it messed up the regex somehow

main ivy
#

If you give me those DEBUG codes I'll fix them aswell ๐Ÿ˜‰

sharp moon
#

which ones

main ivy
#

That are failing in agent-mode

#

Or wte problems you see

sharp moon
#

I'm missing what you need ๐Ÿ™‚

#

I saw that you created an issue

main ivy
#

Just logs

sharp moon
#

so I just clicked agent mode and asked AI to fix it

#

๐Ÿ˜‚

main ivy
#

Aha ๐Ÿ˜„

sharp moon
#

I have become the thing I swore to destroy

main ivy
#

Agents suck balls 99%

sharp moon
#

I mean, assigning an issue to copilot generally works

main ivy
#

I rather do it myself atm. either it gets overcomplicated/fails or just plain wrong with agents is my experience ๐Ÿ˜›

sharp moon
#

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

main ivy
#

I mean, I use llm in my dev-setup. But not for creating PR:s and stuff

sharp moon
#

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

main ivy
#

its just helping me in neovim sometimes

sharp moon
#

NEOVIM MENTIONED

main ivy
sharp moon
#

yes, but we also get more copilot features ๐Ÿ˜„

main ivy
#

kewl ๐Ÿ˜„ I am working on my own private focused AI setup for those things @ https://code.botwork.se

#

Dont like the monopoly of github

sharp moon
#

sounds cool

main ivy
#

Can show you at some point ๐Ÿ™‚

sharp moon
#

At the end of next month I will be at the devil's den at Github HQ ๐Ÿ˜›

main ivy
#

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

sharp moon
#

oh I understand

sharp moon
main ivy
#

I am on a de-google de-ms de-apple journey ๐Ÿ˜„

sharp moon
#

you're not alone, I also like that movement ๐Ÿ˜„

#

I don't participate as hard, but I do like the initiatives

main ivy
#

However on that note :S

sharp moon
#

liquid ass

main ivy
#

i guess no more work for me today

#

I do like apple-silicone... Cant help my self

sharp moon
#

oh man its great

main ivy
#

Yeap! I so wish they where more open so the linux distros could run on these machines though

flint jetty
#

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

main ivy
#

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:

  1. The implementation in hass is a bit struggling TBH, it feels very defragmented.
  • After/If I get the bumped aioasuswrt version 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.
  1. 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).

main ivy
#

@sharp moon the fix is in the package! TY so much, will bump the current PR with a minor before merge โค๏ธ

sharp moon
#

Did anyone try looking at discovery yet?

main ivy
#

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

sharp moon
#

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

main ivy
#

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

sharp moon
#

Also do note that we're in contact with ASUS ๐Ÿ™‚

main ivy
#

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

sharp moon
#

we havea network manager now

#

Network discovery

#

I don't see mine here

#

but its in AP mdoe

main ivy
#
  "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

sharp moon
# sharp moon

but can you check via this? This is how HA sees it

#

as in, no SSDP expert, so might be the same

main ivy
sharp moon
main ivy
#

Oh!... sec

#

Success

sharp moon
#

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

main ivy
#

Both my routers where discovere

#

+d

flint jetty
#

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?

main ivy
#

Nope it just works

main ivy
#

I will add the UPnP search to ๐Ÿ™‚

main ivy
#

Have updated the PR

sharp moon
flint jetty
#

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 ๐Ÿซค๐Ÿ˜ฉ

GitHub

Monitor and control your AsusWRT-powered router from Home Assistant - Vaskivskyi/ha-asusrouter

sharp moon
#

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

main ivy
#

We can use UUID under UDN, that should be unique!

sharp moon
#

what do we currently use as unique identifier?

main ivy
#

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

sharp moon
#

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

main ivy
#

zeroconf for tnew device you mean?

sharp moon
#

ye, they claim that their new device would do mDNS

main ivy
#

For my a bit older they say nada for mDNS

#

Ah!

#

Thank you ASUS โค๏ธ

sharp moon
#

But with my router in AP mode I don't see any mDNS

main ivy
#

Do you see any ssdp?

sharp moon
#

So I also asked if that is expected

#

Nope

#

AP mode is just nothing

main ivy
#

TY ASUS ๐Ÿ˜ข

#

There must be a way!

#

Would be strange if you could not map it some wow

#

Does it have BT ๐Ÿ˜„

sharp moon
#

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

main ivy
#

I guess it answers on router.asus or whatever the address was

sharp moon
#

but then you're assuming it uses the router for DNS

main ivy
#

Correct, and will not work in AP mode

#

most likely

sharp moon
#

nope

main ivy
#

I do think using SN as unique is not correct though...

sharp moon
#

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

flint jetty
#

@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

sharp moon
#

I think that's a fair argument

flint jetty
#

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

main ivy
#

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.

sharp moon
#

Like yes, in some fields, serial number is not unique

#

like idk, barcodes

#

but in IoT I kinda consider it unique

sharp moon
#

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

main ivy
#

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... ๐Ÿคท

sharp moon
#

okay let me rephrase, if we can get the real serial number reliably, it's a good pick

#

๐Ÿ˜‚

main ivy
#

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

sharp moon
#

Ip?

#

IP?

main ivy
#

Yes sorry, IP

sharp moon
#

but that's unique, but not good for HA

main ivy
#

and it can change

#

I wish I had twin routers so I could compare some things

#

starts browsing amazon

sharp moon
#

I mean me and Vask have the same router

#

but it doesn't work via SSDP

flint jetty
#

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

flint jetty
flint jetty
main ivy
main ivy
#

My suggestion in the meantime is:

  • Lets create 1 ssdp discovery 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.).

main ivy
main ivy
#

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:rootdevice is what we can use as WFADevice do not report MAC and has SN 000001)
  • IP can be used to auto populate, and MAC is under serialNumber so 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 ๐Ÿ˜„

main ivy
#

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.

sharp moon
main ivy
#

I can only say I agree ๐Ÿ™‚

sharp moon
#

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

main ivy
#

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)

sharp moon
#

lmfao yes

main ivy
#

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

sharp moon
#

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

flint jetty
flint jetty
#

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)

sharp moon
#

No matter if you have ssh enabled or not

flint jetty
#

Yeap. Asus tried hard to solve this issue, so you can limit access with up to 4 rules (4 IPs to allow) ๐Ÿ™ƒ

main ivy
#

So, any words from Asus on the matter of supporting http as a standard?

sharp moon
main ivy
#

I so love big-corp

flint jetty
#

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

main ivy
#

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.

main ivy
sharp moon
#

Yes I'm also one to check my mail better

main ivy
#

Nah! Havnt opened mine for 3W now

sharp moon
#

Lmao

#

So are you big or small corp

main ivy
#

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

sharp moon
#

Ah, so another point for non responding people in small corporations

main ivy
#

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

flint jetty
#

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 ๐Ÿ˜†

main ivy
#

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

sharp moon
#

BB?

#

Bitbucket?

main ivy
#

Spot on

#

The suckiest of them all

flint jetty
#

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

main ivy
#

I think there are as many problems as there are companies at this point ๐Ÿ˜„

#

And they mostly start at communication

flint jetty
#

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 ๐Ÿ‘

sharp moon
#

lmfao

main ivy
#

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 ๐Ÿ˜›

sharp moon
#

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

main ivy
#

One for integrated and one for legacy devices

sharp moon
#

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

main ivy
#

Ok! I was thinking more on the legacy ones and how to manage those when asus do changes to their new linup.

flint jetty
sharp moon
main ivy
#

We can mask it ๐Ÿ˜‰

sharp moon
#

As in, making sure that we have test fixtures for older models and that we test against it

main ivy
#

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 ๐Ÿ™‚

sharp moon
#

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

main ivy
#

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 ๐Ÿ˜›

sharp moon
#

you mean based on alexa?

main ivy
#

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

flint jetty
#

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

main ivy
#

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

flint jetty
#

I am at the conference. Have all the time today. Talks are boring. Some cosmology / high energy things...

sharp moon
#

At this point, I don't expect much, but anything we can get is nice

flint jetty
sharp moon
#

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

flint jetty
#

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

main ivy
#

Dont mind a slow update cycle! Rather do that and not get flooded by tickets TBH.

sharp moon
#

I mean everyone has their preference ๐Ÿ™‚

#

and sometimes a slow update cycle is the cause of a ticket flood

main ivy
#

Yes, but not when things are stable to start with ๐Ÿ˜„

flint jetty
#

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 ๐Ÿ˜‰

main ivy
main ivy
#

@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 ๐Ÿคฃ

flint jetty
#

Yeah, I saw, will fix as soon as I make my dev container run tests...

#

๐Ÿซค

main ivy
#

As the docs say "It happens to all of us" ๐Ÿ™‚

sharp moon
main ivy
flint jetty
#

Works now

flint jetty
#

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)

GitHub

The problem I have latest Hassio running in docker on RPi 3B+. I added AsusWRT integration but when I streaming/downloading the amount of transferred data can show maximum of 4GB and then it starts...

sharp moon
#

What's the device class set to

flint jetty
#

SensorDeviceClass.DATA_SIZE

sharp moon
#

sorry

#

state class

flint jetty
#

SensorStateClass.TOTAL_INCREASING

sharp moon
#

That should be correct

main ivy
#

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.

main ivy
#

Sorry for the pedantic stuff, my OCD is going haywire over here.

main ivy
#

Just appologized to @subtle jay and @flint jetty for getting pinged in PR:s. Not much else ๐Ÿ˜„ You?

sharp moon
#

@main ivy you can close your own issues by using the bot commands

main ivy
#

I remembered that like 3 sec after that comment ๐Ÿ˜„

flint jetty
#

Hey, guys. I want to add the update platform to AsusWRT. Any objections?

sharp moon
#

Do it! BongoCatEyes

flint jetty
#

Making it work is simple. Writing it nicely is boring... And I have not even started with tests yet ๐Ÿซค๐Ÿ™ƒ

sharp moon
#

hehe

main ivy
main ivy
#

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 ๐Ÿ˜„

sharp moon
#

@flint jetty hey how did you now find the color things on the router?

flint jetty
#

Which colour thing? Aura (RGB)?

sharp moon
#

yes

flint jetty
#

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

sharp moon
#

Did you just copy the http endpoints from the web app?