Second setup, choosing a radio
-
The joke is that "CE" stands for "Chinese Exemption," since Chinese companies and make and sell whatever they want into the US and European markets with with no repercussions whatsoever.
-
Hello everyone :)
I'm about to start my second MySensors setup. First one was a few years ago but I put it on hold and decided to focus on getting a stable setup in OpenHAB with some commercial sensors.
Now I'm back looking to expand on the sensor front and I think MySensors is the best option.But what radio is the best choice today?
I don't have anything left of my old setup so I'm starting fresh.
After digging through the forum I have come up with the following setup and would really appreciate some feedback.MQTT GW: Amplified nRF52840
Nodes: nRF52840 or nRF52832The plan is to mostly have battery powered nodes.
Are these good selections or are there any better options that I have missed?My plan is to initially use a dev kit and a usb dongle to get started and then make custom sensor boards connecting to and powering the nRF52s.
Any and all input is highly appreciated :smile:
@projectMarvin
As you're really interested in Nordic nRF52840 and nRF52832, I can't prevent myself from suggesting you to have a look at this project where I used a mesh of low power sensors with two types of dongles UART and native USB.
https://github.com/nRFMesh/nRF52_MeshI do not place this project as alternative to MySensors as it does not have the same goal at all (no community, not many sensors), it's very custom, but the advantage is flexibility in case someone wants to be closer to the official nRF SDK, as that's my sole dependency and it is not using softdevices so leaves freedom to use priviledges and inetrrupts as needed.
I've been actively looking for standardised method to fulfill low power sensors, mesh network with OTA update. And the way there seems clear but very slow. only nRF52840 supports zigbee, and you need a custom zigbee to MQTT for each network. I have hopes that Thread (OpenThread) will resolve this, but thread is too experimental at the moment and 0 commercial sensors compare to all zigbee sensors available on the market.
So I guess, the radio choice for you will depend if you target a commercially supported project which has a development budget or a DIY plan, also how much effort is intended to be spent on custom sensors creation compared to using low cost existing ones. I realised that I can't make DIY sensors cheaper than the existing zigbee one, which breakes the goal of the DIY model unless you do it for learning purpose or for fun.
I'm checked the micro python / circuit python, but that's also a slow evolving path where it's not the HW supplier that's worried about porting the drivers but a third party have them limited to some peripherals.
Nordic has OTA examples since the very first SDK of nRF5xxx, but it's way challenging to bring it to a seemless user product, just configuring nRF compile flags is quite complicated.
I'll keep watching this forum closely and be happ to see a working solution with nRF52xxx, I do have x5 of those nRF52840 usb dongles. -
@projectMarvin
As you're really interested in Nordic nRF52840 and nRF52832, I can't prevent myself from suggesting you to have a look at this project where I used a mesh of low power sensors with two types of dongles UART and native USB.
https://github.com/nRFMesh/nRF52_MeshI do not place this project as alternative to MySensors as it does not have the same goal at all (no community, not many sensors), it's very custom, but the advantage is flexibility in case someone wants to be closer to the official nRF SDK, as that's my sole dependency and it is not using softdevices so leaves freedom to use priviledges and inetrrupts as needed.
I've been actively looking for standardised method to fulfill low power sensors, mesh network with OTA update. And the way there seems clear but very slow. only nRF52840 supports zigbee, and you need a custom zigbee to MQTT for each network. I have hopes that Thread (OpenThread) will resolve this, but thread is too experimental at the moment and 0 commercial sensors compare to all zigbee sensors available on the market.
So I guess, the radio choice for you will depend if you target a commercially supported project which has a development budget or a DIY plan, also how much effort is intended to be spent on custom sensors creation compared to using low cost existing ones. I realised that I can't make DIY sensors cheaper than the existing zigbee one, which breakes the goal of the DIY model unless you do it for learning purpose or for fun.
I'm checked the micro python / circuit python, but that's also a slow evolving path where it's not the HW supplier that's worried about porting the drivers but a third party have them limited to some peripherals.
Nordic has OTA examples since the very first SDK of nRF5xxx, but it's way challenging to bring it to a seemless user product, just configuring nRF compile flags is quite complicated.
I'll keep watching this forum closely and be happ to see a working solution with nRF52xxx, I do have x5 of those nRF52840 usb dongles.@wassfila Your project looks very cool and I considered it earlier. Thanks for sharing :)
I excluded it because I was concerned that you might stop developing it and that would kill the project.
I want to focus on developing sensor-nodes and using the data in openHAB.
I really think some kind of self-healing mesh solution is the way to go, especially since I want to be able to expand freely and just drop in more nodes at will without disturbing the others.My current plan was to use MQTT-SN over openthread and then use the homie standard to get everything auto-discovered in openHAB.
But now when you say openthread is somewhat experimental I'm no longer sure.
To me openthread seemed quite well documented and I like that Nordic provide so many examples.
In your experience, is thread unstable?I want to go for the DIY approach mainly because.
- I want to be able to choose my own sensors and know that I get quality pcbs that last.
- Commercial multi-sensor nodes are generally fairly expensive. Making one custom doesn't pay off, but 30+ does.
- My end-goal is to make energy harvesting nodes, both indoor and outdoor, that once installed will be able to do their job until their components break.
The more I type in this response, while looking at your github and hackaday I feel like maybe I should give nrf52 Mesh a try.
Do you have any OTA working for your setup? I'm not looking for a fancy gui, just a python script on the border router or similar. -
@wassfila Your project looks very cool and I considered it earlier. Thanks for sharing :)
I excluded it because I was concerned that you might stop developing it and that would kill the project.
I want to focus on developing sensor-nodes and using the data in openHAB.
I really think some kind of self-healing mesh solution is the way to go, especially since I want to be able to expand freely and just drop in more nodes at will without disturbing the others.My current plan was to use MQTT-SN over openthread and then use the homie standard to get everything auto-discovered in openHAB.
But now when you say openthread is somewhat experimental I'm no longer sure.
To me openthread seemed quite well documented and I like that Nordic provide so many examples.
In your experience, is thread unstable?I want to go for the DIY approach mainly because.
- I want to be able to choose my own sensors and know that I get quality pcbs that last.
- Commercial multi-sensor nodes are generally fairly expensive. Making one custom doesn't pay off, but 30+ does.
- My end-goal is to make energy harvesting nodes, both indoor and outdoor, that once installed will be able to do their job until their components break.
The more I type in this response, while looking at your github and hackaday I feel like maybe I should give nrf52 Mesh a try.
Do you have any OTA working for your setup? I'm not looking for a fancy gui, just a python script on the border router or similar.@projectMarvin here's the next gen project that is actually a HW sensorTag but also mainly an nRF52840 firmware compatible with openthread and my previous gen simple mesh framework. The openthread is quite simple as you no longer have to worry about app layer when using directly json from the uC
https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/
