Nah, nothing to worry about. After the most recent release of that driver I realized a number of Xiaomi/Aqara devices send a certain type of message, once during pairing, that the driver doesn't "expect".
Since the driver code is only executed when 1) a message is received from the device, 2) a driver command is used, or 3) the driver requests to run some part of its own code in future on a scheduled basis, this error doesn't "hurt" anything.
Because the message serves no useful purpose, I just need to add code which ignores it so no error is generated. I am currently (slowly) working on updates across all the drivers and that fix will be included.
Yes, in fact all ZigBee devices should be paired in situ. But don't just take my word on it.
Here's a post in another thread just today about this from Hubitat's head honcho:
Everything you have described is perfectly normal behavior for Aqara Temperature Humidity sensors, based on my experience.
You haven't found it because it doesn't exist. These are inexpensive Chinese market sensor devices, not scientific instruments. Here is the best documentation I have found, located in the GitHub repository of the parent company Lumi United Technology's:
When the temperature and humidity sensor detects temperature changes over 0.5 degrees or more than 6% humidity change, a report will be sent. The atmospheric pressure value will be sent along with the temperature or humidity report. The Temperature and humidity sensor also reports the current temperature, humidity, and atmospheric pressure values during each heartbeat.
Note: when they say "temperature changes over 0.5 degrees" they are talking about changes in degrees Celcius.
Despite what Lumi states above, the reports are not as consistent as expected. I have seen the sensor wait to report on temperature changes in excess of +/- 5° C. Also, temperature changes seem to have priority over humidity changes. So the sensor seems to sometimes wait for a +/- 5°C temperature change before sending a report, even though humidity has changed more than +/-6%.
Also, for those people like yourself who are trying to work with the reported values in a detailed way to generate graphs or look trends, etc., it's important to understand how the driver generates events.
The sensor only sends reports for all readings (temperature and humidity for the Xiaomi model, and temp, humidity, and pressure for the Aqara model). It does not send individual readings. If you don't see readings arriving in groups in the logs, that means there is very likely some issue with the ZigBee mesh connection (i.e., dropped messages).
However, events for then Hubitat Hub are only generated when there is a change. If for example a new temperature reading is the same value as the previous one, no event is generated. This is by design, to avoid spurious redundant repeated values from cluttering the device's events list. It is of course in direct conflict with some people's desire to plot a graph over a specific interval of time, but then the sensor by design doesn't work that way. It reports based one changes, not time intervals - with the exception of the "heartbeat" reports (which I call "check-in" messages).
I will be adding functionality to the next update of the driver to include the temperature, humidity, and atmospheric readings that are sent with each check-in message (occurring approximately every 50-60 minutes). I am thinking about forcing those to generate events regardless of whether the values have changed or not, because I can see that being useful to people who would like to track the values over time for various purposes.
Outside of the sensor reading reports, if you are concerned about whether the devices are remaining connected to the hub, the absolute consistent method for doing this is to look at events for the custom attribute lastCheckin. This feature is not on by default (to keep the events list "cleaner") and needs to be turned on in the preferences for each device:
I would also recommend looking at @bptworld's Device Watchdog app which can generate daily scheduled device activity and battery level reports.
