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.
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.
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.
Breakpoints are working for me on HP23 after setting the remote folder like ind Danees example:
"remoteRoot": "/app/"
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
Do you have some morte details so we can help?
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.
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.
@Peter_Hendrix
Here is example code that tries first to connect (docker) or starts debugger (Homey).
Fiddled around a bit and got it working… thanks.
This speeds up development quite a lot.
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.
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.
Instead of assuming, have you tried?
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.
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
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.
I’ve got it working by updating "localRoot"
in launch.json
to be
"localRoot": "${workspaceFolder}/.homeybuild",
Thanks for the help @robertklep
So from all your comments, for someone unexperienced like me…
How to debug in VSCode
{
"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)
if (process.env.DEBUG === '1') {
require('inspector').open(9222, '0.0.0.0', true);
}
(or variations for Cloud, different Homeys like above)
configure Chrome chrome://inspect/# to listen on myhomeyip:9222
run Launch APP in VSCODE via RUN - START DEBUGGING…
(or start manually LAUNCH APP & Attach to Homey)
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}",
"localRoot": "${workspaceFolder}/.homeybuild"
, unless you run the code from .homeybuild (which I guess you should not)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.
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.
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
Is there actually any benefit of running it on the docker instead of Homey itself?