🛰️ Future development planning / overview
ThomDietrich opened this issue · 11 comments
Hey all,
after shorter discussion with @bangom and others I thought about the future of this daemon. While thinking about all potential functions and processes a map felt useful. Here we go:
Feel free to chime in and discuss. Contributions welcome!
1.1
This function heavily depends on the miflora library but should be implemented async and in proper object oriented manner. Linked to #107
Success rate: A function already available but not very visible. Should be published to all conventions. Linked to #106
Availability: Currently missing and important for smart home system integration. A sensor should go "offline" after x failed polling attempts.
1.2
Passive listening for btle broadcasts by the sensors should be part of the miflora library development and integrated with 1.1
1.3
Not available through the gatttool integration, scanning is now available through bluepy. Should be added as a function and results published to MQTT
1.5
Wherever possible, the daemon should be configured via MQTT. Propose to reduce required file/env based configuration to
- MQTT connection parameters
- daemon unique ID (with a fallback to a suited host identifier)
- (every other configuration aspect is still supported for classic deployment)
For usability purposes I propose to publish a complete default configuration to MQTT - if no retained configuration for the daemon unique ID exists
Will support for other Xiaomi sensors at some point be on the road map?
Yes! I forgot to highlight that but the new structure in #107 should support that. I envision an architecture in which a device is pretty much self-contained, dealing with it's configuration, btle sensor reading, and MQTT communication independently of all other sensors. We can discuss this in #107 if you like.
1.1
This function heavily depends on the miflora library but should be implemented async and in proper object oriented manner. Linked to #107
Success rate: A function already available but not very visible. Should be published to all conventions. Linked to #106
Shouldn't be a big problem to publish it as another plant sensor/entity (in HA for example sensor.plant01_btle_stability)
Availability: Currently missing and important for smart home system integration. A sensor should go "offline" after x failed polling attempts.
Could be useful. Again perhaps another sensor (in HA for example sensor.plant01_btle_state = online/offline).
1.2
Passive listening for btle broadcasts by the sensors should be part of the miflora library development and integrated with 1.1
1.3
Not available through the gatttool integration, scanning is now available through bluepy. Should be added as a function and results published to MQTT
This is a nice idea which can make discovering and adding new sensor more user friendly.
1.5
Wherever possible, the daemon should be configured via MQTT. Propose to reduce required file/env based configuration to
- MQTT connection parameters
- daemon unique ID (with a fallback to a suited host identifier)
- (every other configuration aspect is still supported for classic deployment)
For usability purposes I propose to publish a complete default configuration to MQTT - if no retained configuration for the daemon unique ID exists
I'm not sure about daemon-config&management residing in Smart Home System (controller) - there are more kinds of controller right now (HA, OpenHab, ...). Maintaining more versions could be hard...
My idea was rather master-slaves architecture. Key points:
- You keep sensor configuration only on master daemon which distributes sensor list to all slaves daemons via MQTT on master daemon start/restart.
- Defining sensor-slave ownership with "@" part in sensor name (sensor location isn't used in HA anyway :-)
- Purpose of a slave is "set it and forget it" - slave daemons rebuild automatically theirs sensor list from MQTT subscribed topic, publishes local sensor data and publishes nearby sensors so they can be added to the master daemon (notification on master: "new nearby miflora sensor found with MAC / RSSI" ... ).
- Purpose of master daemon - single entity for management, discovery, notification monitoring.
Details see the attached image below where the draft of the proposed architecture is depicted.
Really looking forward to the passive integration as in https://github.com/custom-components/sensor.mitemp_bt
I was actually looking for removing "sensors config" in a slave, and doing mapping MAC->actual plant later, so i don't need to touch slave if sensor or plant gets moved. That would also allow to get all sensor reading through all slaves and then filter/downsample after a broker?
Well, let's break down this daunting task into smaller, more ignoreable chunks:
For a start, subdividing the sleep (1) and checking for a "magic string" mqtt message in between (2) to skip wait (read: sleep; 3), thus triggering a whole script rerun would be nice!
Maybe https://pypi.org/project/schedule/ can help for a hot-feature-patch?
Regarding future development you could probably set up the projects tab? I'm not sure, if you/we are looking for an update to this repo or a totally "new" MiBLE2MQTT daemon, on top of (as @vekexasia mentioned) Xiaomi Mijia BLE MiBeacon Monitor Git?
Thus, @CWempe would get his otter sensors.
1.2 would be very useful in increasing battery life. However, as the battery level is not advertised anymore in the latest firmware, it would make sense to implement an hybrid approach where one could get all the passive BLE information while retaining the possibility to poll specific values at defined timeframes.
So for example, ones could poll the battery once or twice a day, and gather all the other information passively. Or, if someone as a particular need for a specific value at a specific interval, it can still be done while the other info will come in passively.
Hi, Home Assistant moved to a passive BLE approach that also polls to get more info when needed: https://www.home-assistant.io/integrations/xiaomi_ble/, using this library: https://github.com/Bluetooth-Devices/xiaomi-ble. This has greatly improved battery life. Is there any plan for 1.2? If not I may try to do it myself, but I don't want to duplicate work ;)