If you didn't clear the queue by power cycling as I mentioned above, it will continue to throw those errors until you do. If you powered cycled and the queue messages are back, you missed the window to spot what's causing it. If you are not sure which application causes the queue to become full, then disable all other apps that use websocket, except for Bond integration. If you'd like, you can send me your hub id and will look for clues, but I will likely ask you to disable any custom integrations and then add one by one to narrow down which one is misbehaving.
Now that is something we need!
The chain of events were as follows. I looked at the logs when I got home as to see if something has run amok while on vacation. I had no reason to suspect anything but I do go look for errors every so often to be proactive. That's when I noticed the queue full errors. I intentionally tried sending commands to one of my fans and it changed speeds as instructed. I did not notice anything else in the house that wasn't working. I believe the 404 errors in the above screen shot were thrown when I sent these commands. Since the errors were back after running without them since September, I tried to stop them with refresh, config, etc which didn't work and I didn't expect it to. My thought was if there was some combination to make them disappear, I would create a band aid since my experience has been the errors affect nothing but showing in the logs. I eventually rebooted and they disappeared and did not return prior to switching to the community version.
The last time I tried this Bond experiment was in 2023 and the community version worked without issue from that time until September 2025 when I tried the built in version again to see if things had changed. Unless I look at the logs, there is no outward symptom the errors are occurring. I know you find that highly doubtful but it's the honest truth.
I appreciate the offer but honestly, I've already switched back to the community integration which in my experience, works well on my system. With the insights I've gained about websockets from this thread, I now have a bit more knowledge about something to look for if my websocket apps all start misbehaving at the same time. I learned something so it was a good day!
I am pretty sure is not the Bond integration that is giving you trouble. Is likely something else on your hub that overloads your hub. The community integration uses a different protocol, so you're comparing apples and oranges.
My offer to help you narrow down the cause of the issue is always open—just let me know if you change your mind.
Thanks Bobby. I just have one final question, you stated that queue full errors will shut down all websocket comms. If that's the case, how come I could still send commands to my fan? I just want to make sure I understand what the queue full error actually represents.
It means your hub reached the maximum number of events you can store for that particular queue (protocol). The Bond Integration is trying to record more events, but the queue is full. Reducing the number of events is the only way to prevent filling up the queue.
That's what I thought the queue full error meant. I guess I have one more question then. If the queue was indeed full, how come the commands I sent to the fan through an HE dashboard, through the built in integration, went through to the fan?
That doesn't sound right, nothing should be working. In any case, if you change your mind and want me to take a look, let me know.
I really appreciate the offer but I am unable to disable my custom integrations. If the errors were timely and predictable, It might be a possibility but since I had better than 6 months of clean running this last time, it could take several years before I had everything running again if I had to wait seven months between turning each custom integration back on. I'm not that dedicated and the WAF would tank and the system would be gone long before we even finished. LOL.
Thanks again for the conversation. It has been quite insightful from my perspective.