Debug app code

[Gruijter]

I also cannot use breakpoints with HP2023. I get some message on an unbound breakpoint cannot be set. I tried both --remote and docker.

With HP2016 it does work however. But there I get a message about 32bit not supporting async stuff.

[DaneedeKruyff]

At the moment I’m working on updating the Ring app to SDK3, I’m doing that on an older Homey so to not run into differences between the old and new Homey so I haven’t tried these settings yet on my new Homey.

[RonnyW]

@DaneedeKruyff

"remoteRoot": "/app/"

Breakpoints are working for me on HP23 after setting the remote folder like ind Danees example:

"remoteRoot": "/app/"

[Peter_Hendrix]

Almost there I think. But the app won’t really run and I cannot sent breakpoints and get: “Starting inspector on 0.0.0.0:9225 failed: address already in use”

So still miles away

[RonnyW]

@Peter_Hendrix

“Starting inspector on 0.0.0.0:9225 failed: address already in use”

Do you have some morte details so we can help?

• HP19 or HP23?
• If HP23, is the app running on Homey (homey app run --remote) or in Docker (homey app run)?

Your error message says that there is already a debugger process running on this port.
If you have more than on app running in debug mode, make sure you are using unique ports for every app.
If you are trying to start the debugger on HP23 Docker, it won’t work because the process is already started. You must connect to this process instead.

[Adrian_Rockall]

If you are running on an HP 2023 use “homey app run --remote” else it will run in Docker which already has inspector running.

You could also try a different port instead of 9225 just in case another app is using it.

[RonnyW]

@Peter_Hendrix
Here is example code that tries first to connect (docker) or starts debugger (Homey).

Debug app code

Another hint…if you want to debug on Homey and Docker, you can add this code to your app.js: if (process.env.DEBUG === '1'){ try{ require('inspector').waitForDebugger(); } catch(error){ require('inspector').open(9225, '0.0.0.0', true); } } It first tries to connect to an existing debugger prozess (needed for docker) and opens a new one if not found (needed for Homey19 or Homey23 remote). In lauch.json you can provide different profiles for Homey remote or docker…

[Peter_Hendrix]

Fiddled around a bit and got it working… thanks.
This speeds up development quite a lot.

[Joolee]

You’re a genius!
The waitForDebugger line is probably needed when debugging SDKv3 apps because the execution order for the onInit methods has been changed.
I ran onto the problem of non-binding breakpoints while trying to update my app to SDKv3 and setting a break-point early on in the app execution, running on a 2016 Homey.

[grant_violetultra]

Hi all. Has anyone got this working with a Typescript app instead of JS? I’ve got as far as being able to attach the debugger, but can’t set breakpoints (they’re shown as a grey circle). The diagnostics shows the following:

I’m assuming that the tsconfig.json file will have no effect on homey app run. Another option is to pass --sourcemap to the typescript compiler, but how is that possible when it is compiled by homey app run ?

I’m also getting the “Warning: Async stack traces in debugger are not available on 32bit platforms” warning, but would that prevent breakpoints from being set?

Thanks in advance for any assistance.

[robertklep]

@grant_violetultra

I’m assuming that the tsconfig.json file will have no effect on homey app run.

Instead of assuming, have you tried?

[grant_violetultra]

Hi @robertklep yes, I have. It looks like tsconfig.json is used to provide compiler options for when compiling within VSCode. I don’t think the Homey build/run process will be aware of it.

[robertklep]

If you had tried, you’d have found that adding "sourceMap": true to the compiler options in tsconfig.json causes source map files to be created in the .homeybuild folders, just as the hint suggests…

$ la .homeybuild/
total 28
drwxrwxr-x 12 robert wheel  384 Oct 19 13:15 ./
drwxrwxr-x 16 robert wheel  512 Oct 19 13:35 ../
-rw-rw-r--  1 robert wheel   43 Oct 19 13:15 README.md
-rw-rw-r--  1 robert wheel   34 Oct 19 13:15 README.txt
-rw-rw-r--  1 robert wheel  510 Oct 19 13:15 app.js
-rw-rw-r--  1 robert wheel  271 Oct 19 13:15 app.js.map

[grant_violetultra]

Ok, thanks, I saw those but hadn’t realised that they weren’t present before I had added it.

I’ve now seen another error message after stopping the debugger - “Could not read source map for file:///app.js: ENOENT: no such file or directory, open ‘/Users/grant/violet/HomeyApp/com.violet-ultra.smartswitch/app.js.map’”
So, it’s looking for the map files in the root dir (the same one as the .ts source files), not the .homeybuild dir. So that’s a step forward.

[grant_violetultra]

I’ve got it working by updating "localRoot" in launch.json to be
"localRoot": "${workspaceFolder}/.homeybuild",

Thanks for the help @robertklep

[Sharkys]

So from all your comments, for someone unexperienced like me…

How to debug in VSCode

1. create launch.json - VSCode

• choose RUN AND DEBUG and select settings.
  

{
"version": "0.2.0",
     "configurations": [{
             "name": "Launch app",
             "type": "node",
             "request": "launch",
             "cwd": "${workspaceFolder}",
             "runtimeExecutable": "homey",
             "args": ["app", "run", "--remote"],
             "outputCapture": "std",
             "env": {
                "DEBUG": "1"
            },
             "serverReadyAction": {
                 "pattern": "Debugger listening on",
                 "action": "startDebugging",
                 "name": "Attach to Homey"
             }
         },
         {
             "name": "Attach to Homey",
             "type": "node",
             "request": "attach",
             "address": "myhomeyip",
             "port": 9222,
             "localRoot": "${workspaceFolder}",
             "remoteRoot": "/app/"
         }
     ]
 }

(or variations for Cloud, different Homeys like above)

2. Aplication app.js oninit update with (optional?) :

		if (process.env.DEBUG === '1') {
			require('inspector').open(9222, '0.0.0.0', true);
		}

(or variations for Cloud, different Homeys like above)

3. configure Chrome chrome://inspect/# to listen on myhomeyip:9222

4. run Launch APP in VSCODE via RUN - START DEBUGGING…
   
   (or start manually LAUNCH APP & Attach to Homey)

5. in Chrome launch /app//assets/app/bootstrap.mjs INSPECT - you shall see “Debugger attached” in VSCode as confirmation it’s connected

Inspector from my perspective just provide another view of what available already in VSCode but I’m sure someone more clever then me will comment on this.

And you must set Breakpoints to actually see anything and debug, also CALL STACK must be active on ATTACH TO HOMEY…

If I missed anything or misunderstood anything, feel free to comment, I will then edit this post.

Note

"localRoot": "${workspaceFolder}",

• seems it’s not required to be changed to "localRoot": "${workspaceFolder}/.homeybuild", unless you run the code from .homeybuild (which I guess you should not)

[Baschte]

I had the problem that the debugger worked on my Homey Pro 2023 but the breakpoints didn’t work. The important note was above. I have to start everything in my VSCode via shell with homey app run myself and can then access this instance via the debugger on address 127.0.0.1 (not the homey ip). After that, everything works great. So I can’t start and use the Launch App command in the debugger. Thanks everyone for the help in this thread.

[RonnyW]

homey app run starts the app in Docker container (on your PC).
If you want to run it on Homey directly, start is with homey app run --remote and use Homey-IP to connect the Debugger.

[robertklep]

@RonnyW

homey app run starts the app in Docker container (on your PC).

I only asked more than a year ago to fix the documentation so it explains to add --remote to run the app code on Homey itself

[Sharkys]

Is there actually any benefit of running it on the docker instead of Homey itself?