Yep, but I’m not having the problem as I’m running on a HP2023 anyway. I can’t actually debug/try anything myself which is… frustrating.
The log in the topic start is from @Peter_Kawa and he also updated everything as far as I know.
Oh so you can’t debug it yourself? I don’t really know the differences in app development between Pro2023 and Pro2019 since I only have a Pro 2019 myself. What happens when you try to run homey app run --remote on your Homey Pro 2023?
On my system+hp2023 everything is working perfectly.
This whole thing started when some people mentioned it didn’t install on their hp2019. I sent Peter the sourcecode se he can mess/try with it. We haven’t been able to locate the culprit though… hence this topic.
Is this the app URL?
Because this app installs just fine on my Pro 2019 (FW 12.7.1)
Yes it is.
… and it installs fine? Well… great, I guess. 
Really not sure where to go from here. I’ll try to get everything in a git repo asap so people can try for themselves.
Might be related to my firmware version though (pre-12.9.0). Fetch was included by default in 12.9.0 so I think you should try to remove node-fetch. It’s built in to Node anyway on Homey 12.9.0 or later.
Hmmm both my 2019’s currently run fw v13.2.1 (and I can’t revert to previous fw versions with this model).
So, fw v12.7.1 is still pre “app only” node.js v22 @bramtops
(changelog doesn’t specify nodejs was only for apps updated to v22)
So this error made / makes sense now
[incompatible_app_runtime_nodejs]
But if it works on an older version, an app usually also works on newer Node versions. But like I suggested, the only change that would impact this app is that fetch was recently built in to NodeJS, so node-fetch is no longer needed
Not sure what you all are on about…
HP2023 + FW 13.2.1 = Okay (=mine)
HP2019 + FW 12.7.1 = Okay (=@smarthomesven)
HP2019 + FW 13.2.1 = Not okay (=@Peter_Kawa)
All on the same codebase…
Anyway, i managed to get everything on GitHub - BramTops/Homey-EnphaseController: Homey app for monitoring and controlling Enphase PV systems. · GitHub
No, Pro 2019 runs different code. Energy tab, hidden devices, device firmware updates, zone ordering, device grouping, Python apps SDK, Matter, RF cloning, Zigbee traffic statistics, camera streaming, Satellite mode for Bridges, Energy Dongle, sustained values (in Flows), local API keys, local users/login and many other features are unavailable on the older models. Dashboards, Moods and Advanced Flow are locked behind a one-time purchase on the Pro 2019
I will check it out and see if I can find the culprit. But I think it’s related to fetch
Well, i meant the same code of the app. But damn, that’s a massive feature disparity between the homey’s. Never imagined it’d be that much. I entered the homey eco-system with the 2023 model.
Thanks, but if it’s working for you already then it would be equally hard to debug.
Anyway, thanks for looking!
Hi Bram,
So I downloaded the git source.
I decided to log all commands and returned info (yes I’m learning 
)
I got it run on my HP2019 + FW 13.2.1;
This seems to be the fix:
- Renaming (or deleting) the package-lock.json file,
- Removing
"runtime": "nodejs",from .homeycompose/app.json
Summarized steps from the full log below:
I renamed the file package-lock.json to package-lock.json.off
$ nvm install 24
$ npm i -g homey
$ npm install
$ npm audit fix
I changed the following in .homeycompose/app.json:
from:
"compatibility": ">=10.0.0",
into:
"compatibility": ">=12.9.0",
But it seemed not to affect anything
I removed the following in .homeycompose/app.json:
"runtime": "nodejs",
>>> click here to view the full log <<<
I renamed the file package-lock.json to package-lock.json.off
$ nvm install 24
v24.16.0 is already installed.
Now using node v24.16.0 (npm v11.13.0)
$ npm i -g homey
$ homey app run
... ... ...
✖ Command failed: npm ls --parseable --all --only=prod
npm warn config only Use `--omit=dev` to omit dev dependencies from the install.
npm error code ELSPROBLEMS
npm error missing: node-fetch@^2.7.0, required by nl.creitive.enlighten@1.2.1
npm error A complete log of this run can be found in: /home/pedw/.npm/_logs/2026-06-04T22_45_12_297Z-debug-0.log
✖ Error: This error may be fixed by running `npm install` in your app.
$ npm install
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated @humanwhocodes/config-array@0.5.0: Use @eslint/config-array instead
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated glob@7.2.3: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated @humanwhocodes/object-schema@1.2.1: Use @eslint/object-schema instead
npm warn deprecated eslint@7.32.0: This version is no longer supported. Please see https://eslint.org/version-support for other options.
added 292 packages, and audited 293 packages in 2m
6 high severity vulnerabilities
To address all issues, run:
npm audit fix
$ npm audit fix
up to date, audited 293 packages in 5s
113 packages are looking for funding
run `npm fund` for details
# npm audit report
minimatch 9.0.0 - 9.0.6
Severity: high
minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern - https://github.com/advisories/GHSA-3ppc-4f35-3m26
minimatch has ReDoS: matchOne() combinatorial backtracking via multiple non-adjacent GLOBSTAR segments - https://github.com/advisories/GHSA-7r86-cg39-jmmj
minimatch ReDoS: nested *() extglobs generate catastrophically backtracking regular expressions - https://github.com/advisories/GHSA-23c5-xmqv-rm74
fix available via `npm audit fix`
node_modules/@typescript-eslint/typescript-estree/node_modules/minimatch
@typescript-eslint/typescript-estree 6.16.0 - 7.5.0
Depends on vulnerable versions of minimatch
node_modules/@typescript-eslint/typescript-estree
@typescript-eslint/parser 6.16.0 - 7.5.0
Depends on vulnerable versions of @typescript-eslint/typescript-estree
node_modules/@typescript-eslint/parser
@typescript-eslint/type-utils 6.16.0 - 7.5.0
Depends on vulnerable versions of @typescript-eslint/typescript-estree
Depends on vulnerable versions of @typescript-eslint/utils
node_modules/@typescript-eslint/type-utils
@typescript-eslint/eslint-plugin 6.16.0 - 7.5.0
Depends on vulnerable versions of @typescript-eslint/type-utils
Depends on vulnerable versions of @typescript-eslint/utils
node_modules/@typescript-eslint/eslint-plugin
@typescript-eslint/utils 6.16.0 - 7.5.0
Depends on vulnerable versions of @typescript-eslint/typescript-estree
node_modules/@typescript-eslint/utils
6 high severity vulnerabilities
To address all issues, run:
npm audit fix
$ homey app run
... ... ...
✖ An unknown error has occurred [incompatible_app_runtime_nodejs]
I removed the following from package.json:
"dependencies": {
"node-fetch": "^2.7.0"
},
That did not make a change:
$ homey app run
... ... ...
✖ An unknown error has occurred [incompatible_app_runtime_nodejs]
I changed the following in .homeycompose/app.json:
from:
"compatibility": ">=10.0.0",
into:
"compatibility": ">=12.9.0",
But it seemed not to affect anything
Only that caused the install script to take way much longer before throwing the same error again:
✖ An unknown error has occurred [incompatible_app_runtime_nodejs]
I removed the following in .homeycompose/app.json:
"runtime": "nodejs",
SUCCES, the app runs fine.
I reverted the change in package.json;
I added the following again:
“dependencies”: {
“node-fetch”: “^2.7.0”
},
SUCCESS, the app runs fine.
When you’re interested in the full npm log from step 4.) I’ll be glad to DM it (2207 lines!)
This shouldn’t have any affect (I was wrong with my earlier post about this one). The package-lock.json is not part of the actual app. Are you really sure this is also a required step?
Wut…
I’ll let someone with a lot more knowledge of the Homey internals take a stab at this 
Thanks a lot for trying/testing once again!
Reproducible:
✖ Er is een onbekende fout opgetreden [incompatible_app_runtime_nodejs]
For any app that you try to run (and probably install) on older Homey’s, if you add the runtime key to app.json.
I’ve posted a question about it on Slack.
Define… older?
Because:
Is runtime optional; and removing it will work on all Homeys?? If we can sidestep this whole problem by omitting it then yay I guess.
Riiiight… bug introduced for older homey’s in newer FW. I get it now. Guess we’ll just wait then.
No clue, I just renamed it as a precaution, to get less “noise”, and because a new one will be generated when installing npm if I’m correct);
I’ll have to test again with the file included, Bram, but the nodejs bug now seems the Nº1 suspect, and for Athom to fix (thanks for reporting, Robert!).
That was quick
Installing fw update now…
@bramtops
Yeah, this fix by Athom solves it.
After installing v13.2.2:
The app now installs correctly using the app store version 
