Open dgtal1 opened 5 years ago
Hi, battery status were added into lywsd02 with this PR https://github.com/h4/lywsd02/pull/1, so I just don't have time to implement it into this integration. I'm going to do it in next version, where data will be split into separate sensor or something like this (needs to throw away template sensor).
About battery. I'm not sure that battery info is shown correctly, because I can't validate it using MiHome app (it doesn't provide such info). But I use my lywsd02 with HA since May and don't have to change battery for this period.
Hi there, thanks for coming back. Yes, true that MiHome doesn't show the battery. But assuming your library deciphers the infromation correctly, then the battery drain is really big. I wonder how you managed to have it working since may. Is it constantly being read every 30 seconds by your HA instance? Anyway, it turned out that ESPhome guys implemented support in their newest release 1.14, so I switched to that integration rather than having HA reading the clock via bluetooth. They used another approach, which I think is much better for the battery. They track broadcasts from the clock rather than explicitly polling its values. This saves battery as the clock decides when to broadcast a new value. It works pretty well. Do you think you could change the approach in your integration and also track broadcasts instead od polling the clock? I'm not sure if it's possible within HA, but I think it would be great for the battery.
I thought about using BLE Broadcasting, but it requires superuser permissions on Linux, so it does not looks like good decision. ESPHome runs on microcontroller, so it is easier to deal with BLE.
Yes, since may I use my clock in HA and it still works. I'm going to update my HA library and track battery drain.
About battery. I'm not sure that battery info is shown correctly, because I can't validate it using MiHome app (it doesn't provide such info). But I use my lywsd02 with HA since May and don't have to change battery for this period.
Maybe this will help you a bit... from 100% to battery warning... if you prefer, I can leave it to die .. the battery lasts about 90 days.
from 100% to battery warning. 100% equals 27% on chart and warning was triggered at 14%, is it correct?
it only took three months, quite fast. My clocks live longer.
from 100% to battery warning. 100% equals 27% on chart and warning was triggered at 14%, is it correct?
it only took three months, quite fast. My clocks live longer.
If you need... have all the data in influx DB... hooked up on grafana... just let me know.
NOT AN ISSUE - A QUESTION Hello, I love your work and the fact that you did this integration. I've got a question though: is it a coincidence that the integration does not expose battery level? It is supported by the lywsd02 library. I'm asking as I did add it to my own version of the integration you created and with polling interval of 2 minutes (4 times less often than in your case) the battery went down 10% in only 3 hours. So really a lot. Is this a reason why you didn't expose the battery? How it goes in your case? What is the pace of the battery drain when you let it run in HA? Perhaps instead of polling the library needs to somehow listed to BLE messages from this sensor? I don't know BLE communication, so not sure how it works.
I did my own platform as I prefer to have separate sensors in HA for all the different magnitudes. Also it's possible to setup multiple clocks in 1 HA setup this way. I used your work and based the code on modified HA mitemp_bt integration. So it's a lot more like mitemp_bt.
You can have a look and let me know what you think. This is my 1st HA integration. I'm Python beginner, so this may not be ideal but perhaps you'll make use of it somehow. https://github.com/grzeg8102/mieclock_bt