#Help: Addon Development w/ Docker-Desktop (win) & VS Code

1 messages · Page 1 of 1 (latest)

meager socket
#

Let's make a thread here that we can dump info in, keep it out of the main chat.

#
  1. Open the forked repository from (1), i.e. devcontainer-main in VS Code and re-open the folder inside the container (either prompted or from Command Palette > 'Rebuild and Reopen in Container')
  2. When finished opening, run task (Terminal > Run Task) 'Start Home Assistant'
  3. Proceed with any normal Home Assistant OS instance, using the Local Add-ons repository page to test install and operation of any addons that are added into the devcontainer-main/addons folder of devcontainer-main.
#

It seems, however, that the supervisor aspect of the devcontainer-main (repository from (1)) doesn't run up all its necessary components and so fails to actually get the on-boarding experience happening correctly.

#

For instance, the Home Assistant observer shows the following:

Supervisor: Connected
Supported: Unsupported

  • apparmor
  • contect_trust
  • docker_configuration
  • network_manager
  • cgroup_version
  • systemd
  • systemd_journal
  • systemd_resolved
  • os
    Healthy: Healthy
#

Then, starting the on-boarding process, e.g. setting up a username/password, etc, doesn't get past allowing analytics information. When you are prompted to log in, the webpage 'freezes', as in it doesn't have any further information to provide and just halts with a bounded 'Home Assistant' and the blue startup screen.

meager socket
meager socket
sweet needle
#

Thank you for the thread. That's a good idea.

#

Your definition of the problem is correct. I have done those steps and ended up stuck at on boarding.

#

Some few things I tried around:

  • I tried with a repository I found on the web that provides add-ons through the addon container. KO
  • I tried running it on another machine (win11). KO
  • Ubuntu 22.04. KO
  • change browsers chrome, Firefox. Used an external device (Android chrome that never accessed the home assistant instance). KO
  • Pruning images, volumes and containers from docker. KO

KO: means, on boarding stuck.

#

One important thing that I have to mention. The first time ever I started the container, it worked.
After the second rebuilding, it stopped working. It didn't work on the second device, the first time nor the other times.

sweet needle
#

Thinking about this makes me feel like there is some network issue somewhere with conflicting HA instances on the same network making integrations fail discovery?

Just some random thoughts coming while I think about this problem.

meager socket
# sweet needle Thinking about this makes me feel like there is some network issue somewhere wit...

Interesting that it worked for you the first time. It's never worked for me.

I don't think it's networking because you can get to onboarding. And you can see the results of the observer which says it's connected.
I have had many other hass instances to and running in the same network. I've even had a clone running in a vm (I was transferring from an Intel NUC and converting from docker-compose via portainer to Hass OS), and all the instances have run up fine.

It seems to me that there's an important element (or many) of the devcontainer config/development Dockerfile that's preventing the onboarding from working properly.

meager socket
#

Other things I have tried include selecting a different folder, ie devcontainer-main/addons
I put the devcontainer.json and tasks.json files in place there, but it ran up with the exact same error about the supervisor having elements that were "unsupported".

sweet needle
#

I agree that network shouldn't be a problem.

But as this solution seemed to worked fine for others (and even me for a second), it's weird that now it's broken on any of my computers. Without any breaking release.

So I am trying to think about what is shared between all the setups I tried.

Now maybe you are right, the dev containers may not be up to date and missing something important for on boarding. But still couldn't find any relevant log.

I have seen the unsupported elements too but did not focus on that since it's a dev. In a perfect world you don't get this kind of warning but in reality, in dev env it's common.

celest gulch
#

I'm also having the same issue! I had the devcontainer working for a while, but after deleting the devcontainer and creating a new one, I also got stuck on onboarding.html.

celest gulch
#

/api/onboarding returns:
[{"step":"user","done":true},{"step":"core_config","done":true},{"step":"analytics","done":true},{"step":"integration","done":false}]

So it's somehow failing on the integration step I think...

celest gulch
#

All right, I've got a hacky workaround. Somehow, the frontend is supposed to send a POST request to /api/onboarding/integration but for some reason it doesn't do this...

The workaround is just manually send this request

  • open the inspector in your browser
  • visit http://localhost:7123 (where your ha instance in the devcontainer is running)
  • login
  • search for request to the /auth/token endpoint. You'll need the auth_token provided in this response.
  • craft a new request (if you right click on a request, you can select "edit and resend" <note: this option is only available in firefox; see discussion below for other browsers>)
    • Change the URL to http://localhost:7123/api/onboarding/integration
    • Add a header named Authorization with the value Bearer <your token here>
    • As the body, use {"client_id": "http://localhost:7123/", "redirect_uri": "http://localhost:7123/?auth_callback=1"}
sweet needle
#

It works. Thank you for the workaround !

meager socket
meager socket
#

From what I can tell from some googling, the workaround described above seems to suggest that do the following:
Open chrome developer console >> Network tab, "Fetch/XHR" (default). Then find the request labelled 'token'. In the 'Preview' tab of the token request, there is the 'access_token', which I assume is the Auth token mentioned above.
Once I've found the 'token' request (which points to http://localhost:7123/auth/token, I right click on the 'token' request, and select "Copy as fetch". I paste that into the console and adjust the headers and body, first to add the authorization header, and then to change the body as described.

#

Buuut, that doesn't seem to work. I'm assuming I'm doing everything entirely wrong since I don't even seem to have the same options, such as "Edit and Resend".

willow dove
#

took me some attempts but here is the fetch that worked and got a response 200:
fetch("http://localhost:7123/api/onboarding/integration", {
"headers": {
"accept": "/",
"accept-language": "en-US,en;q=0.9",
"cache-control": "no-cache",
"pragma": "no-cache",
"sec-ch-ua": ""Chromium";v="112", "Google Chrome";v="112", "Not:A-Brand";v="99"",
"sec-ch-ua-mobile": "?0",
"sec-ch-ua-platform": ""Linux"",
"sec-fetch-dest": "empty",
"sec-fetch-site": "same-origin",
"Authorization": "Bearer ey..MYTOKENFROM/auth/tokenENDPOINT"

},
"body": '{"client_id": "http://localhost:7123/", "redirect_uri": "http://localhost:7123/?auth_callback=1"}',
"method": "POST",
});

celest gulch
#

@meager socket i was away for a little while. Have you got it to work yet? Don’t forget to also edit the URL. Copy as fresh sounds correct. I was using Firefox, so it might be called a little different in chrome.

#

It looks like Chrome doesn't have an "edit and resend" feature. Best you can do is use one of the copy options on the request like Muexxl did, and edit the request there.

meager socket
#

Ah, that makes sense, the old Firefox/Chrome mix-up. I haven't been using Firefox because it seems to break a few things for me.

Thanks Timmehhh, I haven't given it another go yet because I got so confused and frustrated, and now I understand what I was missing!

Will give it another go when I get a chance. Thanks for your response.

meager socket
#

I managed to get it working in the end. Muexxl's fetch config wasn't quite right for me (some formatting was incorrect which I suspect is due to copy/pasting it into discord), but I took a fresh copy of the fetch and adjusted it to use the same headers that Muexxl used and made it a POST and that has worked. I can now log in and start my addon dev.

Thank you!

still urchin
#

Is this the sort of thing that will be fixed in a few days, after which I can just start over?

buoyant token
meager socket
#

I doubt it. It's been a problem for about a month, if not longer.

still urchin
buoyant token
#

apologies, this was in VScode for me, but wherever your locally cloned repository is should do. I should also give the info that I believe the page was cached, so I had to re-run the server and wait a minute before it skipped past to the dashboard

#

as the other guys in this thread have detailed, it appears the integration step is failing to load for some reason, I spent a little more time trying to find out why but unfortunately it looks to be to do with the frontend code rather than python and I don't have great experience in debugging front end applications. I trawled the onboarding code but couldn't see anything obvious

still urchin
#

I managed to get things working editing the code from @willow dove to remove pasting artifacts.

fetch("http://localhost:7123/api/onboarding/integration", {
  "headers": {
    "accept": "/",
    "accept-language": "en-US,en;q=0.9",
    "cache-control": "no-cache",
    "pragma": "no-cache",
    "sec-ch-ua": '"Chromium";v="112", "Google Chrome";v="112", "Not:A-Brand";v="99"',
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": '"Linux"',
    "sec-fetch-dest": "empty",
    "sec-fetch-site": "same-origin",
    "Authorization": "Bearer {ACCESS_TOKEN}"
  },
  "body": '{"client_id": "http://localhost:7123/", "redirect_uri": "http://localhost:7123/?auth_callback=1"}',
  "method": "POST",
});

Paste the above into the console. Replace {ACCESS_TOKEN} with the value of access_token from the preview for the request to token in the Network tab of Chrome developer tools. Press enter to send the fetch. You should see a Promise response (whatever that means). Then refresh the browser page - you may be asked to login again - do so. You should get into Home Assistant.

buoyant token
#

ah so you don't actually have any HA core code locally? the file is the one on the github link I sent above - I'm not familiar with addon development tbf so not sure how you'd edit the container code sorry

#

my example I am running the core repo and it includes the file above

icy mauve
#

I have the same issue, but I couldn't manage to pass the onboarding page. I tried your workarounds in Chrome, Firefox and Brave without success

meager socket
icy mauve
#

I managed to find the access token, then over the onboarding request->copy->copy as fetch. modified the url adding /integration, added "Authorization": "Bearer {my access token here}", body and method to POST.

I get a 401 (Unauthorized) error

this is my fetch request in Chrome or Brave browser: (I've cut some values in this message where you see [...]
fetch("http://localhost:7123/api/onboarding/integration", {
"headers": {
"sec-ch-ua": ""Chromium";v="112", "Brave";v="112", "Not:A-Brand";v="99"",
"sec-ch-ua-mobile": "?0",
"sec-ch-ua-platform": ""Windows"",
"Authorization": "Bearer {eyJ [...] jY}"
},
"referrer": "http://localhost:7123/onboarding.html?auth_callback=1&code=2a45 [...] 3b9b6&state=eyJo [...] D",
"referrerPolicy": "strict-origin-when-cross-origin",
"body": '{"client_id": "http://localhost:7123/", "redirect_uri": "http://localhost:7123/?auth_callback=1"}',
"method": "POST",
"mode": "cors",
"credentials": "omit"
});

meager socket
icy mauve
#

I tried with this, should be correct but still same 401 Unauthorized reply.

fetch("http://localhost:7123/api/onboarding/integration", {
"headers": {
"accept": "/",
"accept-language": "en-US,en;q=0.9",
"cache-control": "no-cache",
"pragma": "no-cache",
"sec-ch-ua": ""Chromium";v="112", "Brave";v="112", "Not:A-Brand";v="99"",
"sec-ch-ua-mobile": "?0",
"sec-ch-ua-platform": ""Windows"",
"sec-fetch-dest": "empty",
"sec-fetch-site": "same-origin",
"Authorization": "Bearer {ey [...] jY}"
},
"body": '{"client_id": "http://localhost:7123/", "redirect_uri": "http://localhost:7123/?auth_callback=1"}',
"method": "POST"
});

meager socket
meager socket
icy mauve
still urchin
buoyant token
#

I agree, I've been trying to find the right place to raise this for a few days, no-one with much experience seems to be taking any notice, and unfortunately I don't know the product enough to know where

#

I've got the feeling it should be raised in the frontend repo, and I'm not sure if this is a devcontainers specific issue

buoyant token
sweet needle
#

I should have shared the minimal "save HA onboarding" request I made to bypass this problem:
Headers:

Accept: */*
User-Agent: Thunder Client (https://www.thunderclient.com)
Authorization: Bearer <access_token>

I suspect the user agent to not be usefull
Body:

{
  "client_id":"http://localhost:7123/", 
  "redirect_uri": "http://localhost:7123/?auth_callback=1"
}

url: http://localhost:7123/api/onboarding/integration

celest gulch