-
-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update rate and RuntimeError: Event loop stopped before Future completed. #361
Comments
@pvvx Let me first try to explain how BLE monitor works.
Now back to the problem, the for hci in self._interfaces:
try:
mysocket[hci] = aiobs.create_bt_socket(hci)
except OSError as error:
_LOGGER.error("HCIdump thread: OS error (hci%i): %s", hci, error)
else:
fac[hci] = getattr(self._event_loop, "_create_connection_transport")(
mysocket[hci], aiobs.BLEScanRequester, None, None
)
conn[hci], btctrl[hci] = self._event_loop.run_until_complete(fac[hci])
_LOGGER.debug("HCIdump thread: connected to hci%i", hci)
btctrl[hci].process = self.process_hci_events
try:
self._event_loop.run_until_complete(btctrl[hci].send_scan_request(self._active))
except RuntimeError as error:
_LOGGER.error(
"HCIdump thread: Runtime error while sending scan request on hci%i: %s", hci, error
) This part of the code is stopped and started each period. This code will tell aioblescan to set up a connection to a hci port and (further in the code) make a HCIdump and pass on each BLE advertisement in RAW format. This is done instantly, not at the end of the period at once. But the connection is closed and started over at the end of each period. I think what happens is that if you set the period to 0 seconds, it will start a new connection before it was even able to close the previous connection, causing the mentioned Error. I'm not sure what you exactly try to aim, but I think an "instant" sensor is what you are looking for. For these sensor, the 'period' isn't waited for, messages are updated right away. Are you trying to do this for ATC firmware sensor? Temperature and humidity are measuring sensors, so the won’t update till the end of the period. But we could make an option to update instantly. Actually, the reason that it doesn’t update instantly is because sensor sometimes send weird results, part of these spikes are filtered out already, and averaging filters out the rest. |
Is this averaging for the Xiaomi sensor? :) Special firmware will support instant sensors. In the current version, the custom firmware XiaomiLYWSD03MMC reports several bits of binary switches and a trigger output to the GPIO and programmed to thresholds with histresis in temperature and temperature. Averaging for advertising in encrypted Mi format is done by the thermometer itself according to the user's settings in it. In the ad-beacon of these sensors with various options for software and hardware registration of failures and incorrect data were not found. Correct the package parsing sources. As a result, I started rewriting your 'ble_monitor' to correctly parse structures in BLE advertising packages ... PS: XiaomiLYWSD03MMC and over, Custom firmware Ver 3.2 - Added new encrypted beacon formats, reed switch maintenance. |
First picture, this is a "bug" in the original firmware. In sensors.py there is a check for this increasing humidity behavior. There is a check for the device firmware, that sets a self._jagged flag to fix this behavior. For more info about this bug, see this post #7 (comment) As the firmware attribute is "Xiaomi (Encrypted)" and not "Xiaomi (MiBeacon V4/V5 encrypted)". it won't correct for this behavior. Try to change the firmware to "Xiaomi (MiBeacon V4/V5 encrypted)" # LYWSD03MMC / MHO-C401 "jagged" humidity workaround
if devtype in ('LYWSD03MMC', 'MHO-C401'):
if self._device_firmware == "Xiaomi (MiBeacon)" or self._device_firmware == "Xiaomi (MiBeacon V4/V5 encrypted)":
self._jagged = True
At the moment, you can't. I will have to change that in the code.
I understand, but this is only the case for your optimized ATC firmware. BLE monitor has to deal with a lot more sensors, which turn out to send wrong data once in a while. But I will look into an option to disable averaging in the future.
Ok, but I would propose to implement the updates in BLE monitor here. I'm totally open for improvements 😄
Will look into that as well. |
@pvvx I like the changes you made to the ble_parser, I will implement this as well. But I will have to keep the compatibility with the MiScale and Kegtron sensors of course. This will make it easier to get your changes implemented. |
I haven't figured it all out yet in your ble_monitor. How is it meant to include BT-MESH sensors processing in ble_monitor?
I don't know English well and I don't want to learn it. As a result, it's easier for me to describe everything in code ... |
Different platforms, same sensor, same time: Xiaomi Gateway 3 does not give out a fractional part of the moisture value from the original Xiaomi LYWSD03MMC: |
Yes, that is exactly what this "jagged" option is doing, it removes the decimal part. But this isn't done in your case, as the code in sensor.py checks for firmware = "Xiaomi (MiBeacon)" or "Xiaomi (MiBeacon V4/V5 encrypted)", and your firmware is now called "Xiaomi (Encrypted)". So either rename firmware, or add "Xiaomi (Encrypted)" to the code.
Here you can see the behavior in more detail, it adds 0,1% every step, till 0.9 and than starts over at 0.0 again. |
Support for Encrypted ATC advertisements has been added in 2.7.0-beta. It also includes automatically selecting the advertisements with the highest accuracy, when sensor is set to send in all adv. formats. Binary sensors (opening and switch) are not added yet, but are already in the output of the ble_parser. If you want these two sensors, you only have to add them in const.py. But I don't exactly understand what these two sensors actually report. |
Custom Firmware Xiaomi LYWSD03MMC options allow you to:
|
Have You achieved the opening sensor to work ? |
I need to receive all packages with the maximum data update rate.
![image](https://user-images.githubusercontent.com/12629515/119289304-01985500-bc53-11eb-8aa3-ee3bf27ee70f.png)
But that doesn't work in ble_monitor.
In the working environment of radio broadcasting, BT adapters receive more than several hundred advertising packets per second from dozens of BLE sensors.
Setting the period to "0" in the log, 'ble_monitor' generates many errors (RuntimeError: Event loop stopped before Future completed) per hour ...
Does "Ble_monitor" cause BLE internal buffer overflows due to Python scripting performance or incorrect algorithms?
If, before calling ble_parser (), you enter a packet limit (discard most of it), reducing the number of transmitted packets to a couple per second, then no errors appear.
Tried various hardware platforms. Python3.9.5+, all packages are the latest versions.
Samples (the "line" numbers in the script 'ble_monitor' may be different - edited to clarify the problem.):
All BLE MESH packets on the network are also passed to the 'ble_parser()' procedure. BT-BLE adapters with UART completely fill the 1.5 Megabit connection...
The text was updated successfully, but these errors were encountered: