Lost display of BME680 sensor data in Fluidd plus a puzzling "HTTP 404: Not Found" error

[dilectus]

Basic Information:

Printer Model: Creality CR-10 Smart Pro (modified)
MCU / Printerboard: 2 X Creality CR-FDM-v2.5.S1_100 (one is “mcu”, the other is “auxmcu”) + Raspberry Pi Pico as mcu “pico”
Host / SBC: x86_64 PC 64bit Debian GNU/Linux 11 (bullseye), kernel version Linux 5.10.0-28-amd64
klippy (2).zip (1.7 MB)

Describe your issue:

For more than a year I had BME680 sensor working great (connected to mcu “pico”) and Fluidd nicely displaying temperature, relative humidity, barometric pressure, and sensor resistance (as a proxy to ambient VOC levels). Within the last month the Fluidd started showing only temperature data from the BME680 sensor and every time I load or reload Fluidd webpage (on multiple devices and OS’s) I get “HTTP 404: Not Found” error even though printer seems to be fully functional aside from BME680 sensor data missing (screenshot below)…

I’ve tried the following which had no effect on the issues:

Uninstalled and reinstalled:

1. Klipper
2. Moonraker
3. Fluidd

I believe this happened after an update, but it might be some config change I made and just don’t recall.
I’ve been researching to find a solution for the last 10 days, without success.

Any help would be very appreciated!

[Sineos]

Seems strange. Please provide the moonraker.log

[dilectus]

Thanks for checking this out. Please see the moonraker.log attached.
moonraker (2).log (21.4 KB)

[Sineos]

The log does not contain anything. Did you provoke the error before getting the log?

[dilectus]

Thanks Sineos.

Hmmm… Interesting… Yes, the error was present.

I’ve just now rebooted the host and verified that moonraker.log was updated on startup as well as confirming that the error persists at startup as shown below. Here’s the updated moonraker.log.
moonraker (4).log (53.8 KB)

[Sineos]

Now there is

2025-03-05 11:02:05,245 [data_store.py:_init_sensors()] - Configuring available sensors: ['temperature_sensor Aux_Board_MCU', 'heater_generic Chamber', 'temperature_sensor Ambient_BME680', 'heater_bed', 'temperature_sensor Board_MCU', 'temperature_sensor PC', 'extruder']
2025-03-05 11:02:05,998 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.objects.subscribe, Code: 400, Message: Invalid argument
2025-03-05 11:02:06,137 [application.py:log_request()] - 404 GET /server/database/item?namespace=mainsail&key=presets (127.0.0.1) [_API_KEY_USER_] 5.41ms

Unfortunately, I have no idea what the reason or solution could be. Maybe @Arksine could support.

[dilectus]

Thank you Sineos.

I’m really stumped, too and that is the only error I found as well.
It makes me suspect a Python update caused this, but I could be also completely misinterpreting the logged error…

Appreciate your time and referral to @Arksine!

[Arksine]

It looks like it could be an issue in Fluidd. The strange thing is that the 404 in the log is not coming from Fluidd, its coming from something running on the localhost. Its possible that it is an agent that Fluidd is proxying a request through.

I’m not sure if this is the reason for the loss of BME680 info. I can see that something is attempting to subscribe to a printer object and the request is not properly formatted.

If you enable verbose logging and reproduce I’ll be able to provide better feedback. I’m not sure how familiar you are with SSH and Linux, but you need to modify moonraker.env:

cd ~/printer_data/systemd
nano moonraker.env

Add the following line:

MOONRAKER_VERBOSE_LOGGING="y"

Then save and exit (ctrl-x) and restart moonraker

sudo systemctl restart moonraker

Reproduce the issue and attach the log. Verbose logging will create large logs, so you will want to disable it by either removing the line from moonraker.env or changing the y to n.

[dilectus]

Thank you very much for detailed reply Arksine!

Please see attached updated moonraker.log with verbose logging as per your instructions.
moonraker (5).log (4.0 MB)

Some more findings:

1. Even though the BME680 and 404 issues occurred at the same time, removing the BME680 from the config does not affect the 404 error - it still persists.

2. I’ve added another sensor. This is AHT10 I had connected (also via Pi Pico) before I switched it for the BME680 a while ago. The AHT10 is capable of only temperature and relative humidity measurement and when I had it connected previously, it would show up in Fluidd with temperature reading in larger font and relative humidity below it in a smaller font. However, now this AHT10 behaves just like the BME680 does in Fluidd with its missing data and only temperature is shown (screenshot below).

I’m super puzzled… Wonder if the Pi Pico somehow went bad, but wouldn’t that kind of failure be more explicitly shown in error logs instead of this odd behavior?

[dilectus]

UPDATE:

Flashed Klipper onto a fresh Pi Pico. This one is Pi Pico W but still RP2040. Swapped the original Pico with new Pico W and booted up.
NO CHANGE.
Still only seeing temperatures from both BME680 and AHT10.
The 404 error persists.

Even more stumped now…

[nefelim4ag]

FWIW, you have macros to query sensors.
So, you can easily check if Klipper has got information from them.
Klipper can’t pull only temperature and nothing else.
So, most probably reflashing and replacing boards to fix the client side issue is worthless.

You can, in fact, open the browser’s built-in console and try to collect info, where and how fluidd receive 404 if that matters.

Hope it helps.

---

jfyi, I have somewhat similar issue, Fluidd right now shows only BME680 data, not SHT3X.

So, fluid receive updates from moonracker about bme680.

You can check in the browser console for websocket messages from moonraker to fluidd to get similar data.

But fluidd do not display them.

[Arksine]

Looking at the log, I’m fairly certain that the 404 is a response from a prioxied request from Fluidd to Spoolman:

2025-03-05 15:38:28,175 [common.py:_log_request()] - TransportType.WEBSOCKET Received::{"id":53463,"method":"server.spoolman.proxy","jsonrpc":"2.0","params":{"request_method":"GET","path":"/v1/setting/currency","use_v2_response":true}}
2025-03-05 15:38:28,182 [common.py:_log_response()] - TransportType.WEBSOCKET Response::{"jsonrpc":"2.0","result":{"response":null,"error":{"status_code":404,"message":"HTTP 404: Not Found"}},"id":53463}

It appears the path /v1/setting/currency doesn’t exist. Probably need to get with the Fluidd devs or Spoolman dev to determine what is going wrong there.

With regard to the main issue I can see a subscription request to the BME680 that successfully returns. I don’t know why the data is being displayed, but I think if a Fluidd dev looks into the 404 issue they can provide feedback there.

There is a failed subscription request in the log, however I’m not sure its coming from Fluidd. It doesn’t include the BME, but its possible that the failure is causing the frontend to suppress some data. The specific request is below:

2025-03-05 15:39:06,246 [common.py:_log_request()] - TransportType.WEBSOCKET Received::{"jsonrpc":"2.0","method":"printer.objects.subscribe","id":59833,"params":{"objects":{"print_stats":["state","message","filename","info"],"webhooks":["state","state_message"],"gcode_move":["speed_factor","extrude_factor"],"gcode_macro _OBICO_LAYER_CHANGE":null,"fan":"speed"}}}

Klipper is rejecting it because the "fan":"speed" argument is invalid, it needs to be "fan":["speed"]

[dilectus]

Thank you nefelim4ag.

I did add macros to query sensors only AFTER I encountered this issue and indeed sensors are reporting OK via gcode macro query.

I do get an error if I try to query BME680 with sensor.gas object for some reason. However, I can successfully query sensor.temperature, sensor.pressure, and sensor.humidity via gcode macro:

[gcode_macro QUERY_BME280]
gcode:
{% set sensor = printer[“bme280 Ambient_BME680”] %}
{action_respond_info(
“Temperature: %.2f C\n”
“Pressure: %.2f hPa\n”
“Humidity: %.2f%%\n” % (
sensor.temperature,
sensor.pressure,
sensor.humidity))}

If I try to query all the measurements of the BME680 including “gas” or resistance of the sensor as per below gcode macro I get a config error for the following gcode macro:

[gcode_macro QUERY_BME680]
gcode:
{% set sensor = printer[“BME280 Ambient_BME680”] %}
{action_respond_info(
“Temperature: %.2f C\n”
“Pressure: %.2f hPa\n”
“Humidity: %.2f%%\n”
“Resistance: %.0f Ohm” (
sensor.temperature,
sensor.pressure,
sensor.humidity,
sensor.gas))}

Perhaps I have a syntax error in the second gcode macro?

Otherwise, this might imply that this BME680 has failed in some fashion, but after connecting an AHT10 and seeing the same behavior in Fluidd (anything except sensor’s temperature data is missing) as well as swapping out another Pi Pico with no change, I no longer believe a hardware failure is a culprit…

And that weird 404 error remains…

Thanks again.

I understand that you have a similar issue with sensor data missing in Fluidd.

But have you previously had this data displayed properly?

Like this (not my printer screenshot, just example I found that shows the data I’m now missing in yellow bullet points):

[dilectus]

Just realized…
Although the above screenshot (not of my printer, just an example I found) is very representative of the the sensor data I’m now missing, the numbers shown without any units in the screenshot seem to be raw ADC values from a gas sensor…
In my case, without any additional code, just with standard BME680 config per Klipper documentation, I had INTIGER numbers followed by Ohm symbol (Greek letter Omega) displayed instead.

This is just a random screenshot I found that closely resembles the Fluidd display I used to have and the particular sensor model used to generate this example screenshot is unknown to me. So that apparent raw ADC value vs resistance value in Ohms (as I had) might be just due to a different sensor (not BME680) used in this example and its default Klipper configuration and/or reporting capability.

Just thought I’d clarify… I’m puzzled enough myself lol…

Thanks to everyone who replied!

[dilectus]

Thank you very much Arksine.

It may take me a minute to fully parse all your much appreciated input.

Spoolman as a culprit is certainly a new avenue.
I’ll investigate to the best of my ability.

Would you be so kind as to point me in the right direction as far as making the Fluidd and Spoolman devs aware of this thread?

Thanks again.

[dilectus]

Thank you @Sineos, @Arksine, and @nefelim4ag for all your help.

“HTTP 404: Not Found” error in Fluidd

Commenting-out/removing Spoolman from the config solved the 404 error in Fluidd.

Verified Solution:
Re-installing Spoolman and adding Spooman back into moonracker.cfg fixed the 404 error in Fluidd.

Loss of sensor data display in Fluidd when sensor is capable of other measurements in addition to temperature

Updated Fluidd today from v1.32.5 to v1.32.6 - issue persisted.

A few hours ago a new bug and workaround was discovered and reported to Fluidd devs: GitHub · Where software is built

Verified solution:
The workaround (for now) is to NOT use any capital letters in the name of the sensor. For example, in the config file rename sensor
“[temperature_sensor ambient_BME680]”
to
“[temperature_sensor ambient_bme680]”
and proper display of all sensor measurements will be restored in Fluidd.

Thanks to all of you again.

[pedrolamas]

First of all, thank you @Arksine for pointing me to this topic!

On the topic of the 404, as you now know that was from the Spoolman proxy and I have a feeling that this is the change in Fluidd that surfaced it:

feat(Spoolman): show currency for price field

That endpoint probably only exists on more recent Spoolman version, so the fix is by updating Spoolman.

From Fluidd side, I will see if there is any way for us to check the version of Spoolman before doing these calls…

As for the missing humidity, pressure, etc., my apologies for that, it was a bug on Fluidd that I have now fixed and will be available on the next release:

fix(Thermals): show extra sensor data

[dilectus]

Thank you @pedrolamas!

[pedrolamas]

I’ve now pushed a fix for the Spoolman 404 error, and will merge it later today.

fix(Spoolman): add version check

---

On a side note, I would ask that any bug that seems related to Fluidd (as was the case here) to please be reported directly on our GitHub repo.

Thank you!