Re: nRF5 action!
@janaka_a
@NeverDie
@ncollins
I thought you might be interested about this. I've been recently working on this project, the PCB design was made by another Team member and I worked on the firmware, it's based on Zephyr and running multiple protocols. This was mainly designed for Thread using the openthread stack. The nice thing is that once openthread is up and running you simply get a udp socket on which it's possible to send json that directly talks to an application. Despite the standard networking stack, this Tag has astonishing low power with sleep current of only 3.19 uA. I also tried some experimental custom radio protocols on it like the simple mesh, so if anyone is interested to have MySensors running on it I'd be happy to help.

Project page :
https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/

PCB :
https://github.com/HomeSmartMesh/nrf52_thread_sensortag

Zephyr firmware :
https://github.com/HomeSmartMesh/sdk-hsm-sensortag

The MQTT gateway consists of few lines of python :
https://github.com/HomeSmartMesh/raspi/blob/master/py/thread_tags/thread_tags.py

components :
nRF52840 on a MS88SF2 module.
i²C bus scl P1.13 and sda P1.15
Light sensor VEMLS6030 @0x48
MS8607 with relative humidity @0x40, pressure and temperature @0x76
Reset button P0.18 and user button SW0 P1.09
RGB LED P0. 04 06 08

@NeverDie , indeed OTA is optimal, then at least the default pre-flashed bootloaded is not so bad to be able to update SW without debugger. But for development purposes the USB dongles are much cheaper than the devkit, yet lacking debug connections. I hope this pogo pin adapter can help others, as I use it to flash and even debug with Ozone on that cheap nRF52840 USB dongle.
Link to CAD Model : https://a360.co/3jr91PD
Also on thingiverse although thingiverse connection is not stable
https://www.thingiverse.com/thing:3384693

I also like platformio Arduino and would like to have the nRF52840 USB dongle supported without the softdevices, as they prevent the direct usage of the RF peripheral for custom radio.

Hi @robertjuric ,
as you're particularly interested in MQTT for logging through influx and grafana, that is exactly what I've been doing so this might be of help.
https://hackaday.io/project/20388-home-smart-mesh
My project did not exactly use MySensors, but I'm interested to get MySensors to work on the rest of my raspberry py, database and dashboard environment.
The raspberry pi has a python script running an influx client here : https://github.com/nRFMesh/nRF52_Mesh/tree/master/raspi/influx
That client collects MQTT topics and forward them to the database.
some example dashboards are shared here that show how influx queries are written in grafana, also to make hour averages: https://github.com/nRFMesh/nRF52_Mesh/tree/master/raspi/grafana

I do recommend keeping as many things running on the raspberry pi as possible, e.g. MQTT broquer, scripts, services, as linux is an advanced operating system that makes logging and debugging of errors much easier than running on a microcontroller.

I'm not sure how much what I shared is relevant to you, but in case you're interested or have questions, just let me know.

@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_Mesh

I 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 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/

Re: nRF5 action!
@janaka_a
@NeverDie
@ncollins
I thought you might be interested about this. I've been recently working on this project, the PCB design was made by another Team member and I worked on the firmware, it's based on Zephyr and running multiple protocols. This was mainly designed for Thread using the openthread stack. The nice thing is that once openthread is up and running you simply get a udp socket on which it's possible to send json that directly talks to an application. Despite the standard networking stack, this Tag has astonishing low power with sleep current of only 3.19 uA. I also tried some experimental custom radio protocols on it like the simple mesh, so if anyone is interested to have MySensors running on it I'd be happy to help.

Project page :
https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/

PCB :
https://github.com/HomeSmartMesh/nrf52_thread_sensortag

Zephyr firmware :
https://github.com/HomeSmartMesh/sdk-hsm-sensortag

The MQTT gateway consists of few lines of python :
https://github.com/HomeSmartMesh/raspi/blob/master/py/thread_tags/thread_tags.py

components :
nRF52840 on a MS88SF2 module.
i²C bus scl P1.13 and sda P1.15
Light sensor VEMLS6030 @0x48
MS8607 with relative humidity @0x40, pressure and temperature @0x76
Reset button P0.18 and user button SW0 P1.09
RGB LED P0. 04 06 08

@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/

@NeverDie , you got it right, mine has the advantage of being self holding, which is quite an advantage if you want to debug, I tried, to debug in the past using the keyboard with only one hand, not very efficient

As you can see, the one in the left side, is holding by itself, it does not has the cables soldered though, the one on the right is my first iteration, but the side holders are weak and broke with time.
It is true that the fact of picking the two side points, it makes it self aligning.
The blue versions are the newer ones, where you can slide it in with the pogo pins stretched out, and then you press it in and lock the open space in the bottom with that small blue little thingie that we see unused and free in the middle version. So no rubber band required, all is static mechanics.
Both middle and left versions are available, the middle version requires glue to fix the pogo pins in the printed shell after being inserted the first time but makes soldering the wires on top easier. The left one has a roof holding the pogo pins but they're harder to access for soldering the debug wires in them and also printing is with slightly more debris given the complex bridging.
One way or the other, this managed to get me a self-standing pogo pin adapter of an already existing board. Indeed if you design your own, you can think of those you linked, but if you're short of space, you can also fallback on such custom 3d printed solutions.
This nRF52840 usb dongle is an amazingly powerful board and so cheap, that I'm confused why Nordic did not made the debug for it simpler, feels like they prefer to sell the dev kit for prototyping, but they don't know how hobbyist like to prototype on the final cheap product. I could afford 5 of them to experiment with some mesh protocols.

So if you have access to 3d printing and would like to give it a try, I'll stay around and help if needed, also if you have improvement suggestions, I struggle with fusion360 till I get things done.

@NeverDie , indeed OTA is optimal, then at least the default pre-flashed bootloaded is not so bad to be able to update SW without debugger. But for development purposes the USB dongles are much cheaper than the devkit, yet lacking debug connections. I hope this pogo pin adapter can help others, as I use it to flash and even debug with Ozone on that cheap nRF52840 USB dongle.
Link to CAD Model : https://a360.co/3jr91PD
Also on thingiverse although thingiverse connection is not stable
https://www.thingiverse.com/thing:3384693

I also like platformio Arduino and would like to have the nRF52840 USB dongle supported without the softdevices, as they prevent the direct usage of the RF peripheral for custom radio.

@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_Mesh

I 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.

Hi @robertjuric ,
as you're particularly interested in MQTT for logging through influx and grafana, that is exactly what I've been doing so this might be of help.
https://hackaday.io/project/20388-home-smart-mesh
My project did not exactly use MySensors, but I'm interested to get MySensors to work on the rest of my raspberry py, database and dashboard environment.
The raspberry pi has a python script running an influx client here : https://github.com/nRFMesh/nRF52_Mesh/tree/master/raspi/influx
That client collects MQTT topics and forward them to the database.
some example dashboards are shared here that show how influx queries are written in grafana, also to make hour averages: https://github.com/nRFMesh/nRF52_Mesh/tree/master/raspi/grafana

I do recommend keeping as many things running on the raspberry pi as possible, e.g. MQTT broquer, scripts, services, as linux is an advanced operating system that makes logging and debugging of errors much easier than running on a microcontroller.

I'm not sure how much what I shared is relevant to you, but in case you're interested or have questions, just let me know.

@neverdie Bluetooth and zigbee have different scopes and different business models. Zigbee is targeting automation networks such as devices that are permanently available and collecting in a server, while Bluetooth is only user centric in its pairing mechanism (it's funning those bluetooth devices that collect a certain amount of data locally for download with the user's phone, they are not scalable for big systems). Zigbee is evolving towards more structured networks capabilities and I predict that the Thread is sooner or later going to replace Zigbee without users loosing functional products as the alliance is already preparing a common zigbee and Thread top layer (dot dot) that would provide a smooth transition. Thread will provide a standardised routing between the sensors local network and the internet, and that is very competitive compared to any Bluetooth or zigbee solution where every one has to reinvent the wheel for a different way of mapping the local network to global, vendor specific or custom gateways would finally tend to disappear. Even if you do not want your sensor to be shared with the world, the smooth transition from low power wireless network to ethernet (and the raspr) is something I would apreciate. Now add to that the MQTT-SN that is designed for low power wireless networks, and you get an out of the box MQTT layer for your low power wireless sensor. I do not know, but if I would bet, I'd bet on that to gain interest in the future.
And by the way, I do not think that these fancy standards compete with MySesnors, because the SW that is simple and you know is 100 times more practicle to work with, port and adapt to corner cases than a huge stack such as BT or zigbee.

@rozpruwacz yeah nRF52840 is here with reasonably priced boards. I got one from ali shop holyiot 18010 now for around 6.5 €, and as mentioned @hugob the nRF52-Dongle, which is by the way available at mouser for 9 € only. And you can follow his link for further nRF52840 discussion.
I would not know how to help with the sw, in the projects I worked on, I simply used a similar environment to the Nordik SDK framework simply with makefiles. I do have a segger j-link debugger that allows using ozone, and I flash with the command line flashing utilities, even adding some fancy python scripts for user id based customisation.

What about the nRF52840 ? Newer, better, bigger and back to the 250Kbps.
And if you get the j-link edu for example you can use some nice debug tools such as the Ozone, I wasted my time enough before running after $2 st-links.