Hey thanks for your work here @Thrilleratplay. This was my gateway drug into using HomeAssistant.
I have noticed that the H5075 sensors keep sending for weeks after it sends battery level 0 and LCD turned off - which is really cool!
Just wrote a post about that at r/Govee.
Damn, I just replaced the batteries in three sensors today because the battery was 0%. I should have noticed the temperature was still being recorded. That is good to know in case I, or anyone else, doesnāt notice the low battery level or LCD is off. Thank you.
ā¦and before anyone comments, yes, Home Assistant alerts for the battery level would also help but I havenāt gotten around to that. Besides, I use my sensors mainly for data collection and do not always look at my HA dashboard.
The -62 or -64 value has been reported as an issue in the bleson package I used but I remember that being a common value before. One thing I did do that is different from the previous version is prune values of 0. The averaged value may been have changed depending on the number of 0 readings were returned. I do not know if this is would be more accurate or not. I think I need to read up on the bluetooth spec to see how that value is calculated.
Funny, Iāve noticed that of the two Govee sensors I have that ran out of battery, both died while still reporting around 34%. Screens went off and they stopped reported. I chalked it up to them probably coming with poor quality/consistency batteries.
Also, despite them not recommending it, Iāve found that the H5074 in my freezers have been working great for the past 4-5 months (reporting 78% despite being at -4F to -14F 24/7). In a plastic ziplock to protect it from condensation, of course. I was thinking I might need another for the refrigerator, but Iāve found that the H5075 with the included alkalines actually seems to be doing fine in the fridge (33F-39F)
The only issue I have these days is that sometimes the values displayed in HA for the H5075 refrigerator sensor will bounce between very high and low ā I think bouncing between the values of other sensors. It seems to happen when the signal from the fridge sensor is obstructed (lots of bottles of liquids etc) and moving the sensor a bit clears it up. Itās just interesting that it seems to pickup the values from other sensors when the real sensorās signal is iffy.
You have a H5075 in your refrigerator? Interesting. I do not think the high and low values are from other sensors as the mac address is embedded in every packet. My guess is the H5075 is built to a price and the sensor varies. The Govee app will pull the history and normalize the data. This component only relies on the data is receives via the broadcast, so the fewer received messages, the more variation there will be.
Yes, in the fridge (in a ziplock). I didnāt expect the battery life to be good because of the cold temperature effect on alkalines, or at least for it to suppress the battery % reading due to the reduced voltageā¦ but it doesnāt seem to have had much negative impact.
Re: the data, yes, that would certainly make sense, but in this case the value alternates between a realistic value and the value of the H5074 in the adjacent freezer (a consistent ~35F difference), never in between or otherwise totally out of whack. Itās possible itās simply a quirk in how HA is displaying the (maybe missing?) data. The next time it happens Iāll take a screenshot and a closer look at what the raw values are.
I have two H5074s in freezers and one H5075 in the fridge, with HA automations for temperature alarms on them. With the Sensirion SHT30 sensors it helps to make sure they stay <80% RH.
Any chance of getting this working with ESPHome? The sensors are detected by name and the address type is public but i cant see a way to get them connected to ESPHome.
No worries, I have been having issues with BT for a long time it turns out the dongle I was using was the issue. I bought that ZEXMTE one and itās working wonderfully now. Now to find a use for the 2 ESP32 boards I bought
I put a feature request on the github page for ESPHome on this. I am interested for two reasons:
I had the integration up and running when I was running HA on a RPi 4 and it worked great. I built some automations to run exhaust fans based on humidity in my bathrooms and all was well. However, I got to the point where I had to move HA off of the RPi 4 to a more capable computer. I now run HassIo on a VirtualBox VM running on an Ubuntu 18.04 host. The āhostā laptop has built in BT but I was not able to get visibility of it in the VM. I purchased a USB BT adapter but I still canāt āsee itā in the VM. The ESPHome route would solve this since I have several available.
I think moving this to a āhubā and off the HA host would be a better solution. I have several ESP32s sitting around, so that was my interest in doing it with ESPHome. Note, the ESP32/ESPHome does āseeā the Goveeās as I can get their mac addresses using the standard BLE integration but not the data. I still have the RPi 4 available and would make it the āhubā if anyone has any ideas.
I have a rather large installation with a number of devices, integrations and entities. (10+ integrations, 50+ devices, 100ās of entities). Reload times for HA Core were getting longer and longer.
I am using multiple add-ons and their performance was starting to bog down. In particular I am using MotionEye to monitor and backup a number of RTSP video streams. (I am currently not using any motion detection, just writing full streams to an SMB server. In the future I would like to start using motion detection but there was no way the Pi was going to be able to handle that load)
I have had several MMC failures even using high end cards.
I had a several year old laptop available, so I shifted HA to it and it has addressed all of the above very well. Others are using NUCs but given that I had the laptop sitting around unused if made sense to just use it. (it is unused since I use RPis for lots of other stuff like my SMB server, Digital Picture frame, etc. and made the laptop un needed)
Impressive. A USB connected SSD may help with the MMC failures and overhead created by IO waits, it is understandable you will want something that will scale for video streams.
@Thrilleratplay, thanks for putting this together. Iām interested in this, but my HA server is hidden away in the basement and I wanted to make a light weight raspberry pi Bluetooth central/observer for things like this. When I look into how youāre doing this, it looks like the temperature/humidity/battery data are all encoded into the BLE advertisement (manufacturer specific portion) rather than specific characteristics inside a BLE service that need to be access via Bluetooth connection. Is that understanding correct?
For example, the packet data that youāre parsing for the H5075 model below is part of the advertisement, not coming from a connection?
I believe the data can also be retrieved through a direct Bluetooth connection, but this component only reads the BLE advertisement. I did a lot of work to abstract parts of this component and allow for easier maintenance. You may be interested in the POC work I did before creating the HA component, it should be easier to follow or rework for your needs.
Additionally, Govee is creating an updated model that may have an improved range that could work with your set up. I purchased one which arrived today but is now saying it is unavailable. Support will be available for it in v0.7 of the HA component.
Esphome esp32 ble tracker would allow you to put them in the basement, or outside or anywhere wifi can reach. It would be awesome if someone could add the govee platform to esp home ble_tracker. The hard part is already done. I donāt have Bluetooth in my greenhouse.
I have two HA instances that just stop reporting temp/humidity values from the sensor. The fix was always been to reboot the computers. Any idea why it would just stop? It works for a straight 8-10 hours, then just randomly quit working. No specific time. Just random time during the day. Both machines are on version 0.7 and the HA version is 114.4 running on Ubuntu 20