search

ThomDietrich / miflora-mqtt-daemon

Linux service to collect and transfer Xiaomi Mi Flora plant sensor data via MQTT to your smart home system, with cluster support 🌱🌼🥀🏡🌳
MIT License
607 stars 139 forks source link

🛰️ Future development planning / overview #111

Open ThomDietrich opened 4 years ago

ThomDietrich commented 4 years ago

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:

grafik

Feel free to chime in and discuss. Contributions welcome!

ThomDietrich commented 4 years ago

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

For usability purposes I propose to publish a complete default configuration to MQTT - if no retained configuration for the daemon unique ID exists

CWempe commented 4 years ago

Will support for other Xiaomi sensors at some point be on the road map?

ThomDietrich commented 4 years ago

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.

bangom commented 4 years ago

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:

Details see the attached image below where the draft of the proposed architecture is depicted.

mqtt_daemon distributed_v1

vekexasia commented 4 years ago

Really looking forward to the passive integration as in https://github.com/custom-components/sensor.mitemp_bt

kwesolowski commented 4 years ago

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?

StohanzlMart commented 3 years ago

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!

StohanzlMart commented 3 years ago

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.

tslpre commented 3 years ago

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.

jmservera commented 1 year ago

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 ;)

SR-G commented 4 months ago

Any news on that xiaomi-ble implementation, that would allow better battery life ? I indeed have to change my miflora CR2032 way too often (and wonder how related it may be to miflora-mqtt readings - only with 2 readings a day on my side)