As a result, pretty much everything is saturated: disk I/O, CPU, RAM… The Gladys interface is, of course, responding very slowly and I can no longer access the integrations…
The hardware hasn’t changed (PINE A64-LTS - PINE64), and has been working perfectly since I started using Gladys. Docker runs a few other containers whose overall load is very modest.
The test performed was simple: start one container after another. And it’s Gladys that suddenly causes the machine to crash…
Sorry if I’m repeating myself, but the only change made is an OS upgrade (Armbian from Bullseye to Bookworm).
How can I provide more information in order to determine the cause of this strange behavior?
Ok, and how many devices do you have? Lots of cameras? Lots of scenes?
Gladys itself doesn’t use anything at idle, it all depends on what you run on it! If you have lots of cameras and you’re reading 5 video streams in parallel, then it’s normal for it to struggle Especially on such lightweight hardware.
You can also check Gladys’ logs to maybe understand what’s going on (docker logs gladys)
25 Zigbee devices (now that we can use them ) and 5 Tasmota.
Many cameras
None in Gladys.
Many scenes
Only about twenty
look at Gladys logs
They contain quite a few anomalies related to missing devices :
2024-06-05T21:34:43+0200 index.js:16 (process.) NotFoundError: DeviceFeature tasmota:Tasmota05:POWER not found
at DeviceManager.newStateEvent (/src/server/lib/device/device.newStateEvent.js:17:11)
at EventEmitter.emit (node:events:517:28)
at Event.emit (/src/server/lib/event/index.js:18:16)
2024-06-05T21:34:43+0200 index.js:15 (process.) unhandledRejection catched: Promise {
NotFoundError: DeviceFeature tasmota:Tasmota03:POWER not found
at DeviceManager.newStateEvent (/src/server/lib/device/device.newStateEvent.js:17:11)
at EventEmitter.emit (node:events:517:28)
at Event.emit (/src/server/lib/event/index.js:18:16)
}
2024-06-05T21:34:43+0200 index.js:16 (process.) NotFoundError: DeviceFeature tasmota:Tasmota03:POWER not found
at DeviceManager.newStateEvent (/src/server/lib/device/device.newStateEvent.js:17:11)
at EventEmitter.emit (node:events:517:28)
at Event.emit (/src/server/lib/event/index.js:18:16)
2024-06-05T21:34:43+0200 index.js:15 (process.) unhandledRejection catched: Promise {
NotFoundError: DeviceFeature tasmota:Tasmota01:POWER not found
at DeviceManager.newStateEvent (/src/server/lib/device/device.newStateEvent.js:17:11)
at EventEmitter.emit (node:events:517:28)
at Event.emit (/src/server/lib/event/index.js:18:16)
}
2024-06-05T21:34:43+0200 index.js:16 (process.) NotFoundError: DeviceFeature tasmota:Tasmota01:POWER not found
at DeviceManager.newStateEvent (/src/server/lib/device/device.newStateEvent.js:17:11)
at EventEmitter.emit (node:events:517:28)
at Event.emit (/src/server/lib/event/index.js:18:16)
2024-06-05T21:34:44+0200 handleMqttMessage.js:113 (Zigbee2mqttManager.handleMqttMessage) Zigbee2mqtt device zb_pir_entree not configured in Gladys.
2024-06-05T21:34:44+0200 handleMqttMessage.js:113 (Zigbee2mqttManager.handleMqttMessage) Zigbee2mqtt device zb_pir_salle-a-manger not configured in Gladys.
It all depends on how much space you want to give it ^^
For info, mine is 32GB and runs on a nice little mini PC recommended by @pierre-gilles, and so far no particular lag issues. The only problem is removing a feature or a device because deleting the state history becomes very problematic. But the upcoming arrival of DuckDB may solve this… we’ll see
I’m going to migrate Gladys this weekend to another platform (ROCK64 - PINE64) that I will dedicate to Gladys, and see how it all works. In the meantime, Gladys is on holiday, and that’s really when you see how handy this thing is in daily life! Anyway, wait’n see