Hi @Terdious, this morning I noticed that my NetAtmo thermostat was no longer reporting data to Gladys.
In the configuration the service was no longer connected. I then clicked Save and connect and re-authorized on the NetAtmo page that opens.
Unfortunately the data still isn’t coming through.
I tried removing the thermostat and adding it back but without success.
In the logs I get the error below:
025-03-22T13:22:08+0100 \u003cinfo\u003e netatmo.loadDevices.js:146 (NetatmoHandler.loadDevices) Netatmo devices not supported : 0
2025-03-22T13:22:08+0100 \u003cinfo\u003e netatmo.discoverDevices.js:23 (NetatmoHandler.discoverDevices) 2 Netatmo devices found
2025-03-22T13:22:08+0100 \u003cinfo\u003e netatmo.convertDeviceEnergy.js:108 (NetatmoHandler.convertDeviceEnergy) Netatmo Energy device \"undefined, NAPlug\" converted
2025-03-22T13:22:08+0100 \u003cinfo\u003e netatmo.convertDeviceEnergy.js:108 (NetatmoHandler.convertDeviceEnergy) Netatmo Energy device \"Thermostat, NATherm1\" converted
2025-03-22T13:22:11+0100 \u003cerror\u003e netatmo.loadDeviceDetails.js:101 (NetatmoHandler.loadDeviceDetails) Error getting devices details - error: AxiosError: Request failed with status code 400
at settle (/src/server/services/netatmo/node_modules/axios/lib/core/settle.js:19:12)
at IncomingMessage.handleStreamEnd (/src/server/services/netatmo/node_modules/axios/lib/adapters/http.js:585:11)
at IncomingMessage.emit (node:events:530:35)
at endReadableNT (node:internal/streams/readable:1698:12)
at processTicksAndRejections (node:internal/process/task_queues:90:21) {
code: 'ERR_BAD_REQUEST',
config: {
transitional: {
silentJSONParsing: true,
forcedJSONParsing: true,
clarifyTimeoutError: false
},
I didn’t include the full logs because there is personal information in them, but if needed I can send them to you privately.
Another point, on the NetAtmo discovery page it therefore does not find my thermostat and Gladys is frozen. No buttons work anymore.
Are you having any issues on your end?
PS: my thermostat is properly connected in the NetAtMo app and I can control it from my phone app without any problem.
Hi @_Will_71,
So indeed, I had the same issue. I had to go to the dev.netatmo page to « unban ». Apparently Gladys made too many requests and the API banned the application…
Following an update??
However I have lots of missing data nonetheless, I need to take a look this week to see if something changed on the API side or on Gladys’ side after an update…
Ok, thanks for getting back to me. I can’t confirm exactly whether this happened before or after the last update.
To try, I recreated an app in NetAtmo and tried to reconfigure the service but nothing works anymore — Gladys no longer detects my thermostat and the configuration page freezes.
OK! I’ll try to debug tomorrow and will let you know if I need your logs
1 Like
I reactivated Netatmo in Node-RED and I confirm that it doesn’t work either.
When I generate a token it works for 5 minutes and then stops.
1 Like
Here is the returned data with Node-RED
So that confirms that it only works for a certain amount of time after recreating a token at Netatmo.
So there is indeed a problem on their side, or they changed something.
1 Like
Ta-da! Following Axios’ update:
…
Except no, nothing else!! And ChatGPT’s response is a deal-breaker for Axios… It’s crazy!!
1 Like
The tests were long … Sorry
It should be fine @pierre-gilles !
1 Like
Thanks!!
Question: I use it in the tests, which is why I installed it globally in addition to the service. Should I do it differently? Reinstall it in the tests?
Hi @pierre-gilles,
Thanks for the review and your thoroughness. For my part, it’s a mess… I can’t find the right information.
Anyway… I fixed according to what you gave me.
However, the last test failed on my latest push which was only textual, on something other than the PR:
2815 passing (2m)
1 failing
1) house.arm
should arm a house:
expected emit to be called 4 times but was called twice
emit(websocket.send-all, { payload: { house: "test-house" }, type: "alarm.arming" }) => null at House.arm (/home/runner/work/Gladys/Gladys/server/lib/house/house.arm.js:11:35)
emit(trigger.check, { house: "test-house", type: "alarm.arming" }) => null at House.arm (/home/runner/work/Gladys/Gladys/server/lib/house/house.arm.js:12:36)
AssertError: expected emit to be called 4 times but was called twice
emit(websocket.send-all, { payload: { house: "test-house" }, type: "alarm.arming" }) => null at House.arm (lib/house/house.arm.js:11:35)
emit(trigger.check, { house: "test-house", type: "alarm.arming" }) => null at House.arm (lib/house/house.arm.js:12:36)
at Object.fail (node_modules/sinon/lib/sinon/assert.js:107:21)
at failAssertion (node_modules/sinon/lib/sinon/assert.js:66:16)
at Object.assertCallCount [as callCount] (node_modules/sinon/lib/sinon/assert.js:148:13)
at Context.<anonymous> (test/lib/house/house.arm.test.js:33:12)
We still can’t re-run these when they fail. The problem is that I now have the same error locally… I don’t understand!
I’m sorry, but I need help — if this happens locally as well, there must be a reason, which may have existed before but was… masked? Could you help me understand and how to look for the issue?
EDIT: The worst part is that if I run this test alone, it still fails???
Well this is crazy, I don’t understand why it happened all of a sudden, if I run just the tests in server/test/lib/house/house.arm.test.js 10 times it now fails consistently locally on origin :
it('should arm a house', async () => {
await house.arm('test-house');
await Promise.delay(5);
assert.callCount(event.emit, 4);
If I change the delay to 8, it fails 1 time out of 8 :
it('should arm a house', async () => {
await house.arm('test-house');
await Promise.delay(8);
assert.callCount(event.emit, 4);
And if I change the delay to 10, it no longer fails :
it('should arm a house', async () => {
await house.arm('test-house');
await Promise.delay(10);
assert.callCount(event.emit, 4);
I can’t determine what my changes are modifying in the behavior of this particular test…
I ran a command to run the tests on the Netatmo service + lib/house with the delay set to 8, no problems 3 times in a row… but still about 1 time out of 2 with a delay of 5…
Edit: I pushed a change: added spaces in some error texts and the tests pass. But could we still look together at why we have random failures like this (and apparently not so random locally…)
