As mentioned by @cdaoust above. You can assume that Tindie and most other international online marketplaces as well as many global stores will aim to block all Russian sellers and keep blocking them in protest until the currently ongoing Russian invasion of Ukraine has been resolved → Russian invasion of Ukraine - Wikipedia (political discussion about reasons why will probably too off-topic here).
I have ~48 of the miflora sensors, I think in the last 4+ years I have had exactly one of them die. I use a custom esp32 ble component to forward the ble beacon information to Home Assistant.
I own 1 spruce soil sensor. The only advantage that this sensor has is that it doesn’t get hoovered up by the lawn mower when my wife mows the lawn.
The miflora are the superior sensors. They are a bit more accurate for soil moisture level and they can give you a good estimate for applying fertilizer ( the Plant Lovelace doesn’t a basic job of highlighting the plants needs ). Before you accept the answer about fertilizer level, you should have a basic understanding of how the measurement works ( i.e. if you are using it for a potted plant, there has to be enough soil for the measurement to work, and the soil needs to not be dry as well ).
So far the version 5 of the miflora sensors appears have the same accuracy as the version 4; the version 5 does beacon its battery report.
The miflora devices are water resistant. The spruce device? I have found moisture around the battery the two times I have opened it.
I am amazed how Mi Flora sensor is water-resistant, I have three outside monitoring two potted citrus trees and one tomato plant in rainy Northern Ireland. I also had a Zigbee water valve from Lidl, and it died in early autumn due to water leak. Not even one MiFlora stopped working. The only thing that bothers me is battery life, and this is why I would like to see a Zigbee version as good as that one with long battery life similar to aqara range.
I am a bit surprised how the market is so saturated with other products (i.e. motion, window, temp sensors) but not so many plant sensors, specifically with Zigbee. Oh, the Zigbee…
The Miflora sensors have reasonable battery life if you just read data from them via passive BLE, no active scans or reads. I am on the latest firmware for all green/white models, which no longer provides battery information in the beacon.
Passing reading the state from the sensor will significantly extend the life of the battery. Don’t even open up the “Flower Care” app unless you need to update firmware. The “Flower Care” app burns through the battery pretty quickly.
Battery life for me is > 1 year, and maybe 2 years in a couple of cases. ( Events which wake the sensors drain the batteries, but some events “are what they are”.)
With regards to reading battery state, I have a custom ESP32 component based on the excellent, and much appreciated, work done by the Github user myhomeiot. My modification to his work changes how the disconnect from the device works ( I believe there is a problem with leaked resources around an error state in the code used for BLE reads… I also suspect from Espressif documentation that the closing of devices when you are reading from more then three devices has to be managed in a different way ). My latest changes have been running on ESP for the last few weeks without any issues, so I believe they should be stable.
I often wonder if reading the battery’s state is worth the return in the end. If the device stops beaconing data then it is normally time to replace the battery ( sometimes the devices needs to be reset, aka pop the battery out and put it back in… I think there is a bug the devices hit from time to time as they store their local state information; I base this comment on having used the devices built in history in the past ).
About half of my Miflora devices are missing their orange gasket; they just keep working. I have had Miflora devices that have survived being accidentally submerged in water which had fertilizer levels that were harmful to plant life.
The one thing I have noticed about their design, as compared to some other sensors I have looked at, is the water will drain from the device if they become wet. The Spruce devices have a nice gasket, but once water gets in one, it has no place to go.
I designed my own sensors a decade ago, one of the bigger problems they had was corrosion build up.
There was a French company that made “Flower power” devices which would also rust and die after a couple of years. I feel like they were the first company to make devices which could help with determining fertilizer level for plants ( at a reasonable cost ).
Hi, I prepared a CC2652 version with light(BH1750), soil moisutre, env temp and humidity(SHT30) and EC(soil fertilization)
preparing firmware for CC2652 is not an easy task because a lot of bugs in TI SDK and RF matching(IC against module for smaller dimensions)
With CR2032 battery - 2 months and still 100%, with my calculations it should work for at least 2 years.
I’m testing a lot of time, soldering by myself, but the chip shortage is huge
What is the currently best working solution that is available for purchase?
I checked the thread and the Russian manufacturer is blocked. Other than that I can’t find any good solution.
While it does not feature Zigbee support, maybe also keep an eye on “b-parasite” or future derivate forks from it as that is another open-source hardware project for a soil-moisture and ambient temperature/humidity/light sensor that could potentially be redesigned to support Zigbee (and Thread).
That is. “b-parasite” today only comes with BLE (Bluetooth Low Energy) firmware which is I guess so if based around Ebyte E73-2G4M04S1B radio module as that only has Nordic Semiconductor nrf52832 SoC and that specific chip is a Bluetooth-only part, however, if that radio module was replaced with Ebyte E73-2G4M08S1C radio module (or alternatively RFstar radio modules like RF-BM-ND05 or RF-BM-ND05I) which instead are based on Nordic Semiconductor nRF52840 SoC then that is a chip with multi-protocol support so could optionally be made to support Bluetooth, Thread, and Zigbee wireless protocols via different firmware images.
I am not an electrical engineer or a firmware developer, however, believe that would not be too much work to replace an nrf52832 based radio module with a nrf52840 based radio module since they both are based on Nordic Semi’s nRF52 series which is part of the same family? I think that the nrf52832 and nrf52840 SoCs are even pin-compatible but pin-compatibility might not hold true for the Ebyte (and RF-Star) radio modules?
it’s currently it’s as part of redesign and I’m not sure about licensing(I’m not the only one owner of project), I’m also not sure how many ppl are interested due to a lot of time to cleanup and update code to latest SDK version and publish to public repo PCB, firmware and Z2M converter
It is also huge problem to buy CC2652R chip at normal price, can anyone advise to wait or rewrite code to NRF or similar(at a price of less than 6$)? And what about NRF power consumption
Alternatively could use a battery holder/battery retainers that stack two (2) CR2032 cells on top of each other in order to at least get twice the total battery capacity while still using the common CR2032? There are “2CEL” battery holders that can hold two CR2032 batteries and stacking two CR2032 would add relatively very little extra cost and would not a huge size difference to the product.
Still, it would be better to instead use CR2450 or CR2477 batteries on these types of sensors.
All modern Zigbee (multi-protocol) SoCs have similar power consumption, however as I understand and I am sure you are already aware, a lot of power consumption depends on code optimization, as in how much time it sleeps versus how much time it is awake + how often it checks sensors + how often it actually transmits state updates. As while it might be OK to wake it up relatively often to check some of the sensors it might not need to transmit state updates until values change significantly. These types of wireless sensor nodes should be designed as Zigbee end devices which never need to listen to incoming RF packets, and only send out short packages very rarely.
I was wrong, apparently “b-parasite” is designed to use nRF52840 based Ebyte E73-2G4M08S1C radio module, so that means that it could be flashed with Zigbee and/or Thread firmware instead.
and RF matching(IC against module for smaller dimensions)
