The HE hub provides a means to view/retrieve the complete stream of incoming Zigbee messages (as seen by the hub). You can see these directly on the hub admin interface at http://<hub ip>/hub/zigbeeLogs. It's possible to leave that browser tab open (and visible) and let it soak up logs for a while and copy/paste that into ChatGPT/Claude/Gemini. Ask a simple question as @neonturbo suggested above, with a summary description of the issue you are observing.
However what is rendered on that page is not as detailed as what the hub actually outputs on the websocket. To capture the full details, you need special tools, as a websocket connection is different from a web page. It is a little bit more technically involved; probably the easiest way is to use the developer console (F12) on the http://<hub ip>/hub/zigbeeLogs page, reload, and let it soak for a while.
Here is an example using Chrome:
The red arrows show where to navigate to. The green arrow points to the "export" button which lets you save the full capture to a ".har" file. You can upload that file directly to Claude/ChatGPT/Gemini.
Each log line has details about the Zigbee message received, including the full payload. AI tools are good at parsing these logs and figuring out what devices are doing and can even identify problems (e.g. Excessive OTA requests from Thirdreality devices).
I uploaded the above capture to Gemini with the simple prompt "tell me what is going on with my Zigbee network". This is what it came up with:
Gemini analysis of zigbee websocket capture
Based on the live log WebSocket capture (zigbeeLogsocket.har), your Zigbee network is active and running, but it reveals a very clear reason why you might be noticing latency, lag, or poor automation responsiveness.
Here is the analysis of what is happening under the hood:
1. The Core Issue: Severe Log Spamming (Traffic Congestion)
The single biggest takeaway from your log is that your Moes ES1 presence sensor is flooding the network with rapid, consecutive messages.
Specifically, look at this chunk of data:
21:40:02.103: Moes ES1 sends a time cluster (000A) message.
21:40:02.108: Moes ES1 sends the exact same message again (5ms later).
21:40:02.111: Moes ES1 sends it again (3ms later).
21:40:02.114: Moes ES1 sends it again (3ms later).
21:40:02.117: Moes ES1 sends it again (3ms later).
It is firing off 5 to 6 redundant updates in a span of 14 milliseconds. Outside of these bursts, it is continuously reporting illuminance, distance, and custom engineering attributes every 2 seconds. This level of hyper-chattering can saturate a Zigbee channel, causing a massive backlog on your hub (Hubitat, judging by the path structure) and leading to delayed or dropped events from your other devices.
2. Device Overview & Health Check
Moes ES1 (Device ID: 50): * Signal Strength: Perfect (LQI: 255, RSSI: -35). This indicates it has an excellent physical connection or is positioned right next to a router/hub.
Behavior: Highly problematic due to the data repeating bursts noted above.
- TR Presence Multi-Sensor R3 (Device ID: 213):
Signal Strength: Perfect (LQI: 255, RSSI: -35).
-
Behavior: Healthy. It reports fine-grained radar/presence metrics steadily and updates binary motion attributes (
0006) perfectly fine without hammering the network. -
Aqara FP300 (Device ID: 120):
Signal Strength: Good (LQI: 192 to 200, RSSI: -52).
- Behavior: Normal. It check-ins appropriately every minute or so with routine telemetry.
Recommended Next Steps to Fix the Network
To stop the network chatter and clear up bandwidth for your other devices, you should adjust the settings on the Moes ES1 sensor:
Increase the Reporting Interval / Minimum Change: Go into your hub's device details page for the Moes ES1. Look for driver configuration variables related to parameters like "Illuminance reporting threshold" or "Minimum reporting interval". Increasing these limits prevents the sensor from trying to broadcast minuscule lux changes instantly.
Switch/Update the Driver: The rapid-fire bursts on the Time Cluster (000A) point to either a bug in the device's firmware or an unoptimized custom device driver handling the device profile. Check to see if there is an alternative community driver available, or hit "Configure" in your hub UI to force it to rewrite its reporting table rules to the device.
Power Cycle: If configuration changes don't take, physically power cycle the Moes ES1 to clear its internal hardware buffer.