HTTP 404: Not Found when trying to enable/change heater temperature

[jgrn307]

Hi there! I'm new to this game, but I successfully got my old pentair easytouch system wired in with an Elfin. The dash UI is showing the proper pool temperature and status, but when clicking the Set Point or the Heater Status I get an HTTP 404: Not Found (see below)

I think my pool is set up with a Jandy heater, but the controller is not controlling the heater directly, its just using the water temperature to turn the heater on/off (the heater itself is set permanently to 104 degrees). I noticed when the heater is on (via my remote) it shows the following:

Note the Virtual Circuits.

Any ideas? I'm running both nodejs and the dashpanel as dockers in synology.

[tagyoureit]

Can you send me a replay capture? I can't see what the error is from the screenshot. I'll also be able to tell your heater config from that which I can't see from the screenshots, either.

[dpfrommer-gateway-ct]

I get the same as well, regardless of using the FQDN or IP address

[tagyoureit]

See my response above. Please submit a replay capture so I can diagnose.

[dpfrommer-gateway-ct]

@tagyoureit I will submit a replay capture and also take a look at the source to determine if I can find the cause

[dpfrommer-gateway-ct]

@tagyoureit I have the replay.zip. What is the best way to provide it to you?

[tagyoureit]

Upload it to this issue. (Note: you have to do it through the web, Github doesn't accept attachments through email.)

[dpfrommer-gateway-ct]

@tagyoureit here it is

replay.zip

[tagyoureit]

Investigation Summary

I loaded the replay data and attempted to reproduce this issue but was unable to trigger the 404. Here's what the investigation found:

What we verified from the replay:

• The njsPC console log shows the request reaches the server: GET /v2/config/body/1/heatModes
• The route is defined in web/services/config/Config.ts at your commit (b375dfec / v10.0.0)
• No error is logged after the request, which means Express's default 404 handler is responding (the route isn't matching despite being defined in source)
• The handler should return valid heat modes for your config (solar + heatpump heaters, body=0)

Testing the endpoint:

When I load the replay locally and hit the same endpoint, it returns HTTP 200 with the expected data:

[{"val":1,"name":"off","desc":"Off"},{"val":3,"name":"solar","desc":"Solar Only"},{"val":4,"name":"solarpref","desc":"Solar Preferred"},{"val":9,"name":"heatpump","desc":"Heatpump Only"},{"val":25,"name":"heatpumppref","desc":"Heat Pump Preferred"}]

Most likely hypotheses:

1. Stale compiled code in Docker container — If your Docker setup volume-mounts the source directory (rather than using the multi-stage Dockerfile build), an older dist/ directory compiled before the v2 route was added would be missing this endpoint. The Dockerfile's npm run build step always compiles fresh, but a volume mount bypasses this.

2. Synology reverse proxy rewriting the path — If you have a DSM reverse proxy in front of njsPC (common on Synology), it could be stripping or modifying the /v2/ prefix.

3. Docker image from a pre-9.0.0 build — The /v2/config/body/:body/heatModes endpoint was first added in what became v9.0.0. If your njsPC Docker image was built from an older source but somehow reports v10.0.0 (e.g., git metadata from a mounted volume), the compiled code wouldn't have the route.

How to diagnose if it happens again:

If you can reproduce this, please open your browser's Developer Tools > Network tab, then click Set Point/Heater Status and capture:

1. The full URL the browser is requesting (look for heatModes)
2. The HTTP response status code and response body
3. The Response Headers (specifically X-Powered-By and Server headers — this tells us if the 404 is from njsPC/Express or from a reverse proxy like nginx)

Also check:

• Are you using Docker Hub images or building locally?
• Do you have a Synology DSM reverse proxy configured for either njsPC or the dashboard?
• Is your Docker setup using volume mounts to the source directory, or is the code baked into the image?

[tagyoureit]

Investigation Summary

I loaded the replay data and attempted to reproduce this issue but was unable to trigger the 404. Here's what the investigation found:

What we verified from the replay:

• The njsPC console log shows the request reaches the server: GET /v2/config/body/1/heatModes
• The route is defined in web/services/config/Config.ts at your commit (b375dfec / v10.0.0)
• No error is logged after the request, which means Express's default 404 handler is responding (the route isn't matching despite being defined in source)
• The handler should return valid heat modes for your config (solar + heatpump heaters, body=0)

Testing the endpoint:

When I load the replay locally and hit the same endpoint, it returns HTTP 200 with the expected data:

[{"val":1,"name":"off","desc":"Off"},{"val":3,"name":"solar","desc":"Solar Only"},{"val":4,"name":"solarpref","desc":"Solar Preferred"},{"val":9,"name":"heatpump","desc":"Heatpump Only"},{"val":25,"name":"heatpumppref","desc":"Heat Pump Preferred"}]

Most likely hypotheses:

1. Stale compiled code in Docker container — If your Docker setup volume-mounts the source directory (rather than using the multi-stage Dockerfile build), an older dist/ directory compiled before the v2 route was added would be missing this endpoint. The Dockerfile's npm run build step always compiles fresh, but a volume mount bypasses this.

2. Synology reverse proxy rewriting the path — If you have a DSM reverse proxy in front of njsPC (common on Synology), it could be stripping or modifying the /v2/ prefix.

3. Docker image from a pre-9.0.0 build — The /v2/config/body/:body/heatModes endpoint was first added in what became v9.0.0. If your njsPC Docker image was built from an older source but somehow reports v10.0.0 (e.g., git metadata from a mounted volume), the compiled code wouldn't have the route.

How to diagnose if it happens again:

If you can reproduce this, please open your browser's Developer Tools > Network tab, then click Set Point/Heater Status and capture:

1. The full URL the browser is requesting (look for heatModes)
2. The HTTP response status code and response body
3. The Response Headers (specifically X-Powered-By and Server headers — this tells us if the 404 is from njsPC/Express or from a reverse proxy like nginx)

Also check:

• Are you using Docker Hub images or building locally?
• Do you have a Synology DSM reverse proxy configured for either njsPC or the dashboard?
• Is your Docker setup using volume mounts to the source directory, or is the code baked into the image?