Open aqualx opened 5 years ago
I use these changes since this spring and I had no issues. Could this pull request be merged into the master?
Hey guys! This is a cool but also big PR. I did not yet get around to review it... but if the addition works for you guys, there is no need to wait any further. @aqualx could you please point me to the 1-2 areas of the change that I might be interested to review, as they change existing functionality or might become an issue later? Thanks
@aqualx You might want to update the PR to include the last three commits from your master branch.
Especially the new OUIs (MAC prefixes) are important for users with new devices.
https://github.com/aqualx/miflora-mqtt-daemon/commit/7fe9e787594fae87ba4ba02641722b519098a488
Any update on This?
It would be great is this could be merged so the users of this devices can use this maim project and don't have to use the other fork.
Hey @CWempe and @aqualx, I had big plans to further improve this daemon! Sadly I didn't have much time the last couple of months. I'm definitely willing to apply these changes. @CWempe if I resolved the conflicts in this PR and provided a merge-ready state, would you be able to test with both devices?
I could test the Temp/Humidity device. But my only flower recently died, so I cannot test the flower sensor currently. π
I can help. I have 9 MiFlora and 2 Temp/Hum devices.
Fyi in an attempt to merge this eventually I went ahead and merged smaller unrelated pieces from this PR in #105, aside many further PRs and improvements from my side.
In general my concern with this PR is the bloating (doubling in some areas) of the existing structure, and the threading approach. Before the script is bloated more I would want to refactor the hell out of it. This project grew out of its original hacky scope almost immediately and I never took the time to follow a proper design. Every convention and every sensor deserves its own class, this could be combined with adding a new sensor type - that's where this PR comes into play.
Dear @aqualx, dear @ThomDietrich!
I believe forming this whole project into a "MQTT Thingy Interface" on top of Passive BLE Beacon Monitor will make you both happy π!
What do you think? @onebavarian @CWempe
Gratefully for everything, Martin
btw: I just found this project: https://github.com/zewelor/bt-mqtt-gateway
It does not support as many Xiaomi devices as Passive BLE Beacon Monitor but some senors are supported. https://github.com/zewelor/bt-mqtt-gateway/issues/151
btw: I just found this project: https://github.com/zewelor/bt-mqtt-gateway
They even seem to have the "force update"-feature I'm looking for on Pull since 2019 :P https://github.com/zewelor/bt-mqtt-gateway/pull/48
Still, bt-mqtt-gateway uses miflora-git and such polling and not BLE Bacon broadcast monitor which - to me - seems fundamentally better suited for battery usage:
[...] Unlike the original mitemp_bt integration, which is getting its data by polling the device with a default five-minute interval, this custom component is parsing the Bluetooth Low Energy packets payload that is constantly emitted by the sensor. The packets payload may contain temperature/humidity/battery and other data. Advantage of this integration is that it doesn't affect the battery as much as the built-in integration. [...]
What's new:
Solution tested in Debian Stretch with python 3.5 (stable).
Notes:
config.ini
changed.