When setting my sensors up I always used hcitool lescan to test the range. Since I have 2 of my Miflora sensors in my green house i had to do some testing before i found a good position for both sensors and receiving Pi3. So if lescan can find your sensor address then you’re good.
Otherwise, reposition.
I have about 30 m to my greenhouse but there are only windows in the way. It’s also a good idea to know where the antenna for Bluetooth is on your Pi3.
Also, since you have added a median to your sensor it will take 3 readings before a value is displayed in HA (FYI).
Another tip is to make sure the sensor is updated. You can do that with the Xiaomi plant app, but before any data can be read by HA it must be unpaired from the app.
Figured I’d chime in here, as I’ve got the same issue a lot of people are reporting: Updating miflora sensor took longer than the scheduled update interval 0:00:30
Last time I checked, I had 782 entries in my current log file, which is absurd IMO.
Found this awesome project called OpenMQTTGateway, which can be used for connecting lots of sensors to MQTT, via an ESP8266. I should mention, it also supports BT presence detection, 933mhz sensors, IR, and a plethora of other devices. It’s a great project, and the credit should go to the devs of said project.
Then I found this issue. Which (at the time of this writing) was committed 17 days later. Here’s a post by the dev, explaining how he implemented the Mi Flora sensor into the OpenMQTTGateway.
Long story short, the OpenMQTTGateway can now read the values from the Mi Flora sensors, and rebroadcast them via MQTT, which can then be pulled into HA; all running on an arduino platform (ESP8266).
For anyone who takes this route, please keep in mind, you’ll probably need to be familiar with programming and electronics; I wouldn’t recommend trying to implement this as your first Arduino project. Also, the firmware on the HM10/11 needs to be updated to at least v601 (This had me scratching my head for a bit). Instructions for this can be found here.
Hopefully this is a good alternative for a few of you (like myself) suffering from enormous, unnecessary log file entries caused by the above “sensor took longer than …” messages.
Has someone been able to pinpoint where to problem lies in this case? Is it that everyone is using raspbi with integrated bluetooth chipset, which breaks it? Or is the problem somewhere in homeassistant / some library used to communicate with these devices?
I looked at, and like the PlantGateway, but when you look at what it’s actually doing, it is overkill to run it on a dedicated machine, even a Pi. This OpenMQTTGateway is capable of pulling in data from all kinds of radios, and rebroadcast it via MQTT, all running on an ESP8266 @ roughly $8.
Using a ESP32 might be an option, for the onboard BT, though (I haven’t looked closely at the ESP32), you might loose the ability to attach an external BT antenna, which helps with range dramatically. Also, without looking at the code, I’m not sure if the OpenMQTTGateway would run on the EPS32, at least without heavy modification. Might be worth a shot though…
I’ve set up two Mi Flora sensors using a Pi Zero and Plantgateway.
The sensors are updating as expected, but I’ve also set up the two plants using the “Plant” component. What I see is that the status of these two are updated on what seems like a rather erratic schedule. It can take several hours/days until all sensors within each “Plant” is populated, even though the the separate MQTT sensors are reporting fine.
Right now one of my plants say the lux value is >2600, but that was maybe 6 hours ago. The correct value is 249. Which is shown when I click on the icon within the plant. See these images:
@aherbjornsen/@Molodax , I think there might be a few different things going on here.
Firstly, the brightness value on the card is the “max_brightness” value recorded over the course of the last few days since start-up and not the real time situation (i.e. defaults to max value seen over last 3 days). This was a new feature added by the Plant component author and lets you evaluate whether the light environment for the plant is overall too low. So when I added the Plant Card, I decided to show the max_brightness value. But it might be more intuitive to change it to be real-time and let the “red” colour coding flag that there is a problem. Appreciate any thoughts on improving that card.
Secondly, as you mention, setting “force_update” on the mqtt sensor will cause the card to update even if the underlying sensor’s value hasn’t changed which can help keep things consistent. It also makes the more-info graph more accurate reflection of history.
But recently I’ve noticed the card does not always populate all values at start-up (e.g. looks like your battery on the second card above has not been populated). If I go to the RPi and run the plantgateway program manually then the plant card will fill in as the new mqtt messages are received. What should be happening at start-up is that the mqtt sensor gets initialised based on the last message retained by the mqtt broker and that gets propagated onto the Plant component. But, on occasion, some messages seem never to arrive at the plant entity. I am trying to find out what causes this as I have only been noticing it since going to release 0.63 and changing my mqtt broker server. I am curious if you or others are regularly seeing this at start-up?
Thanks for the detailed answer. I figured out the “max_brightness” thing myself after looking in the code. The current solution is IMHO not good, and what you suggest (showing real-time value indicating with red if a past value exceed “max_brightness”) is much better.
I’ve also noticed the problems with auto populate at startup. Last time i restarted, one of my plants was fully populated, the other one has only conductivity filled in. It’s not a very big deal, but if you’re able to fix it that would be great.
I can support @aherbjornsen in opinion that it’s not the best choice to show “max brightness”, it was very confusing for me (I didn’t look into the code). Moreover, in my case it is not informative at all since the weather is very shifting here, so 15 minutes of sun shine do not reflect the overall light environment. Real-time data is much better.
Might migrate from Hassbian soon…
