Interested too! I hope we find something
Slightly off topic, but i had a number of xioami flower care devices that i stopped using because of the range.
One day i decided to try using esphome on an esp32poe device (ie no wifi). Interesting, i know get over 15m range out of them!
I have a single esp32poe centrally located on my 1200sqm block and the flower cars are spread all over the front yard / front half of the block.
That is very off-topic here, so please start a new thread for Buetooth diacussion, thanks!
I am ready to buy dozens of them. Maybe even one hundred to monitor our garden because it would return me how much water each flower consumes and set valves accordingly. You will find market for them, donât worry. BT is a real problem, zigbee solves it
I came to this post due to the common problem that I think most of us share. I always have huge problems for finding a device with the characteristics I want.
I have a small house in the country side where I am impleting a multi purpose zigbee network. I though it would be interesting soild monitoring but no way to find a zigbee solution.
I have been profesisonal electronic designer for something more than 10 years developing from medical to consumer electronics. For that reason most of the time I end up developing my custom solutions.
I have already designed a PCB and ordered it for the soil monitoring but I would like to ask you a question. Do you think it is a nice idea to professionalize it and start selling every kind of custom zigbee devices? I mean, for low and mid scale batches.
I think zigbee is quite promissing for tasks like monitoring and automatization.
3 Likes
Regarding the idea of professionalizing it. It has worked for others, like Itead with the Sonoff WiFi range. It should work for Zigbee as usage grows, god knows, a lot of us are trying to cobble stuff together from vendors whoâs products frustratingly really donât quite fit into an open network.
Speaking for myself about these sensors, Iâd like to reduce overall costs and value-add some labor (and control quality) than buy turn-key units at a higher cost. My choice if I had one would be to buy a small number of either loaded PCBâs, or the PCBâs and component parts kits to complete them. Iâm happy to select a battery holder type to suit me if the PCB can accept more than one size. I can make my own 3D printed covers for the component end of the PCB, or use a recycled small plastic bottles (Yukult ones come immediately to mind).
Unit cost is important to me for a couple of reasons. One is the possibility of more wastage if the system turns out not to be what I need or proves too much trouble to maintain (how many of us have a junk box full of expensive home automation gadgets that turned out to be a waste of time or moneyâŚ).
The other is the cost when it may well be that I need more than a just a few of them. At a certain point it becomes more cost effective to just over-water instead of buying hundreds of dollars of sensorsâŚ
Everybody will have a different perspective on what itâs worth to try to get moisture sensing into their HA environment.
Yes! IMHO you + others should definitely do so as believe the market is large enough for such devices.
Would love to see a competing Zigbee alternative priced similar to Xiaomi Mi Flora Plant Monitor.
However, if you will be designing hardware for a new commercial product today then you should most definitely also consider basing it on a newer modern 802.15.4 radio SoC chip that supports multiprotocol to allow support for both Zigbee 3.0 and Thread (OpenThread), as well as BLE (Bluetooth Low Energy).
Silicon Labs, Texas Instruments, and Nordic Semi all have multiprotocol SoCs now, but it is very important that SoC models can warry a lot when it comes with Flash Storage Size and RAM Memory size, which is a factor that could make or break future-proofing and avoid e-waste if it will not possible to perform OTA (Over-The-Air) updates in the future due to the firmware image build getting larger and too big as the multiple SDKs and protocol stacks grow over time with upstream bug-fixes and new features from the manufacturers.
The reason to design hardware with multiprotocol support is so that you can either sell separate variants of the same hardware flashed with different protocol stacks or better yet choose a SoC model with very large flash storage (as well as a lot of RAM) so that you can build a single unified product running a multi-protocol firmware image, (either a multi-protocol firmware image that supports concurrently running several radio protocols simultaneously or a simpler multi-protocol firmware image that at least allows the user to select one of the supported protocols upon the initial commissioning process, e.g. set Zigbee or Thread as the default protocol but also enable commissioning and configuring via Bluetooth LE so that users can change from Zigbee to Thread or vice versa).
That way you make your product or at least its hardware more or less future-proof to allow support for both Zigbee 3.0 as well as the new Matter 1.0 standard over Thread via upcoming compatible OTBR (OpenThread Border Router) of which many are scheduled to start being released from later this year, and still be backwards compatible with everyone that just have a Zigbee 3.0 compatible hub/gateway.
But note that it will probably take years for the new Matter 1.0 standard over Thread to become the new default and therefore I believe it is still important for new hardware designs to also support Zigbee. And I expect that most new home automation hubs/gateways/bridges will support both Zigbee and Thread radios in order to be able to handle this transition period which could last a decade or more.
Thank you both for answering. When I say professionalize is not due to a pure profit reason. I do it for fun and I think it can be useful for others. If I get few bucks back is always welcome but it is not the real reason.
Related to the chip I have to say that I conside CC2530 really outdated compared with new chips. If you compare current consumption with new chips from multiple manufacturers you can see that CC2530 consumes around 3x. It was probably a best in class when it was released but nowadays it cannot compite.
In my opinion the main reason why 99% of the chinese zigbee products are CC2530 is because it can be 1/3 of the price of the rest of the chips and because most of them are just copies other products.
I did a brief research of the market and I finally ended up chosing STM32WB55RG. These are the protocols that support
RF transceiver supporting BluetoothÂŽ 5.3 specification, IEEE 802.15.4-2011 PHY and MAC, supporting Thread and ZigbeeÂŽ 3.0.
It has a dedicated cortex-M0+ for the stack and an M4 for the user app. An M4 might sound as an overkill for the very low needed operations like geting the value from a sensor and giving it to the M0+ to be transmitted but it is a common fallacy to think that a M4 consumens a lot. A properly configured M4 can compete with the 8081 from CC2530. In any case, current consumption from the MCU is nothing compared with the consumption of the radio.
Already tested in evalboard.
STM32 claim to support matter in their STM32WB chips but I am not planning to play with that. I do not even know the real development status.
My sensor is intended for outdoor monitoring. Outdoor means sun. Just for research I have added the positibility to add a small solar panel with a secondary battery (fancy name to say rechargable).
The main reason why I have chosen STM32 is the ecosystem. TI sucks in my opinion. They force you to use paid Keil most of the time, the dont have statandarization among all their MCUs so everytime you change is a nightmare and documentation could be better.
But I have to say that TI is excelent in many areas and for many of them the best nanufacturer, but not in MCUs field.
STM32 in the other hand has a really good free IDE, if you learn how to program 1 MCU you can program their entire huge portfolio and I have never found any flaw in their documentation.
But in the end all of this is personal preference.
Lets see how it works.
A lot of us are probably already familiar with flashing firmware to STM32 based stuff (the DFU boot loader etc if I am on the right track) so sounds great to me.
Happy to test early boards if you need that, doesnât sound like it though.
I guess the main downside with an STM32 SoC could be that probably hard to find other people in the DIY home automation communities that are using STM32 SoCs for Zigbee, so you might be first there?
I know STM32 microcontrollers are extremely popular among other DIY communities, however Silicon Labs, Texas Instruments, and Nordic Semi have dominated the DIY and commercial Zigbee markets.
That can be true but I am not looking for DIY communities for developing hardware/firmware.
Maybe I am missing something but what would be the added value to find other people in DIY communities? Developing these kind of prototypes are really easy from the point of view of basic programming. It took me around 30 minutes to transmit temperature measurements with 0 background on this chip using the evaluation board.
If I want to make a product of this, the real problem comes in optimizing code, hardware design, verification, pivotal studies, manufacturing, documentation and commercialization.
I mean, I do not see the advantage of targeting a low level hardware/firmware design community. In the other hand I see as a very good idea targeting a system level diy community where home assistant, nodered⌠enters in the game.
In any case I have not found a lot of DIY hardware projects apart from clones of soil humidity sensors using cc2530. In my opinion the big part of the community is taking the sensor, doesnât mind if it uses TI, ST or renesas and integrate it in home assistant to make an automatic irrigation system for example. I see that most of the people is interested in what they can do with the device, not really how they are deisgned.
Before I forget, in the verification step there is something that most of these soild humidity sensor manufacturers skip. I want a sensor that actually works (even more if I plan to sell it to someone). I will need to borrow a professional soil moisture and demostrate that results are comparable. Maybe I will need to do calibrations or modifications.
I say that I feel that most of manufacturers skip is because as I have read in this forum they give different results for the same conditions.
Slight off topic but has anybody thought to run BT xiaomi sensors in the Bluetooth mesh architecture? That would solve the problem to have flower sensors on zigbee, if it is possible
Iâm using the ESP/Bluetooth proxy to get data from Xiaomi Sensors. That works perfectly 
I have seen that BLE Mesh exist but I have never seen implemented this technology. I do not know if it is only theory or it really exists.
As that is off-topic please do create a separate new separate thread about Bluetooth sensors and Bluetooth Mesh technology.
Though I can tell you right way that Bluetooth Mesh is not possible to use with eny existibg Xiaomi Mi Flora products because they are not based on a SoC radio chip and SDK that has Bluetooth Mesh support, as you need to understand that in order to use Bluetooth Mesh technology the hardware and firmware needs to be specifically built for it, which none of the existing Xiaomi Mi Flora models are.
Please respect that is discussing using Xiaomi Mi Flora BLE sensors and Bluetooth Mesh is very off-topic in this thead.
Again respectfully request that you start a seperate thread as this Zigbee thread is not the right place to discuss deeper about Bluetooth Mesh technology or BLE sensors which hardware do not have multiprotocol support that includes Zigbee.
Jeez really? I did not hijack this thread. The point why we all look for zigbee sensor for flowers is the inability to have them spread across garden using bluetooth.
1 Like
Some developers are working on BLE mesh architecture for Home Assistant but is still in early stages of development.
BLE Sig Mesh Gateway - Hardware - Home Assistant Community (home-assistant.io)
Sorry to @Hedda but we (you including) are looking for solutions to the problem how to have plenty of sensors for home automation and BLE mesh is technology to address it without the need to develop new hardware. This is a solution if the zigbee sensor is not available.
1 Like
Did you not? You did according to Urban Dictionary definition â Urban Dictionary: Thread Hijacking
This thread is about cats and you want to discuss dogs, âŚer. I mean; this thread is about Zigbee flower sensors products and you want to discuss Bluetooth-based solutions instead, and that is off-topic.
Please just start a separate dedicated thread specifically about Bluetooth flower and plant senses if they are not based on hardware that support multiprotocol including Zigbee.
No, discussing details about setting up and configuring up Bluetooth-based solutions that do also not support multiprotocol including Zigbee is not a solution for those that are specifically looking for Zigbee sensors.
I was specifically looking to discuss Zigbee flower and plant sensors which is why I created this thread with a clear subject description and very clearly described in my original post as looking for that and even clarified that I am not looking for Bluetooth products. Sure you can get inspiration from such hardware but discussing how to use such Bluetooth is deffinitly off-topic.
I really do not wish for this thread to derail too much, which it will if people start to go into detail about different Bluetooth solutions instead. I am OK with discussing multi-protocol hardware if can run also run Zigbee but definitely feel that threadjacking is discussing Bluetooth solutions that have nothing to do with Zigbee whatsoever at any level.
I do not think it is too much to ask when requesting you start a need thread about using BLE sensors and Bluetooth Mesh technology on hardware products that do not also support Zigbee.
Can we now please get back on-topic, thank you!
1 Like
Hedda, you mention the bluetooth versions in the main post. What do you expect? If you want this to be about zigbee, donât post links and expect people to gloss over that information.
2 Likes