Second setup, choosing a radio

[projectMarvin]

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 nRF52832

The 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

[projectMarvin]

Reading more it seems like OTA for these devices is not supported yet.
@NeverDie @scalz Did you ever get OTA working on these boards?

[Sasquatch]

I found that 2.4 GHz is too noisy for stable operation in area, had problems with range and missing packets. Radios worked fine, 80-90 meters in open field, 2 meters indoors across one room !!! but i can see 20+ WIFI networks within reach.
Long story short: check your environment before you buy many radio modules.

I'm currently in finishing stages of ultimate low power node - 5+ years on single AA(LITHIUM) battery with one minute update/report interval, based on RFM69+atmega328p.

If you really need/wand OTA then nrf24 or rfm69/rfm95 is the way to go. Possibly gateway could be nRF52840 and nodes nrf24, not 100% sure, but should be compatible.

[projectMarvin]

@Sasquatch Cool thanks!

I'm really conflicted about what to choose.
The nRF52s run cortex M4s, which I have worked a lot with.
But I want OTA because I don't want to run around and manually upgrade each node. Then I will try to avoid it and end up running a lot of versions of each node.
The rfm95 is a viable option, slightly more expensive but very good range. But as I understood it they are not very suitable for battery powered actuators, not sure why though.

[NeverDie]

@projectMarvin said in Second setup, choosing a radio:

Reading more it seems like OTA for these devices is not supported yet.
@NeverDie @scalz Did you ever get OTA working on these boards?

Nope, not in C, but I did achieve OTA using micropython, uLisp, and Forth, because those 3 are interpreted. However, there may be more information available now on how to do OTA for it in C than there was when I last checked. With C it would require a wireless bootloader. Perhaps one or more of the nRF52 RTOS's would have it by now. It might (?) possibly even be a part of platform.io by now, though I'm doubtful.

[Sasquatch]

@projectMarvin
nrf52 rx current is ~5mA - 480h on 2400mAh battery
rfm69 rx current is 16mA - 150h same battery

Both times rather pathetic, you never run battery powered node in constant rx mode.
If you power down radio as often and for as long as possible you can get 5+ years out of both radios on single AA lithium thionyle battery and keep data flowing every minute or so. I suspect that on Nrf it might need less programming acrobacy.

As for OTA, you should need to update your firmware only when security patches come out for library, once a year maybe?
pulled from nrf52840 datasheet:

The non-volatile memory controller (NVMC) is used for writing and erasing of the internal flash memory
and the UICR (user information configuration registers).
(...)
The CPU must be halted before initiating a NVMC operation from the debug system.

It looks to me that self programming is not possible. BUT i have never worked with tem (or any other M4) so what do i know

[berkseo]

@projectMarvin Most recently, I tried updating mysensors nodes on nrf52840 via nRF Conect (BLE). Incredibly fast.

[NeverDie]

@berkseo said in Second setup, choosing a radio:

@projectMarvin Most recently, I tried updating mysensors nodes on nrf52840 via nRF Conect (BLE). Incredibly fast.

If you have step-by-step instructions on exactly how to do that, it would help just about everybody.

[NeverDie]

It's a timely topic, as Nordic just 1 month ago appears to have published info on how to do OTA using their development kit: https://devzone.nordicsemi.com/nordic/short-range-guides/b/mesh-networks/posts/thread-tutorial-practical-guide-for-device-upgrade-ota

Unfortunately, it seems like a different world entirely from the Sanjeev code, which doesn't utilize the Nordic Bluetooth devkit.

I'm moderately hopeful that Adafruit may one day release a wireless bootloader that's more compatible with the Sanjeev code. However, there's a risk Adafruit would make it for CircuitPython instead.

[NeverDie]

It looks as though ARM MBED has FOTA working for the nRF51822:
https://os.mbed.com/teams/Bluetooth-Low-Energy/wiki/Firmware-Over-the-Air-FOTA-Updates

ARM MBED is the rtos that Arduino chose for its nRF52840 "nano" product offerings.

[berkseo]

@NeverDie This is not a very convenient update process, although it is incredibly fast. You need to download the archive with the firmware to your phone. In the nRF Conect app, you will connect to a mysensors device that has previously been switched to bootloader mode (secure bootloader). Next, you need to choose the archive with the firmware and accept the download. This is a research interest rather than a working option

[projectMarvin]

@NeverDie How about this?
https://github.com/adafruit/Adafruit_nRF52_Bootloader
based on nrf5 sdk v11 though, current version is 17.

I had almost given up on mysensors and was considering the nrf52840 with openthread and mqtt-sn since nordic has working examples for that all the way from a mostly sleeping nrf52840 to an mqtt-sn - mqtt bridge.
I really like the nrf52840 and I want OTA since I know I will never leave my nodes alone and stop updating their codes
LoRa is problematic since I want something that is legal in both Sweden and China.

But mbed os shows promise and if the nano ble runs mbed on an nrf52840 then that should open a lot of doors.
Maybe this project will finally push me to adopt an RTOS

This sounds promising.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.0%2Fexamples_bootloader.html&cp=7_1_4_4

[NeverDie]

@projectMarvin said in Second setup, choosing a radio:

Looking at:

https://github.com/adafruit/Adafruit_nRF52_Bootloader

it does look as though there is a possible OTA mechanism:

DFU = LOW and FRST = LOW: Enter bootloader with OTA, to upgrade with a mobile application such as Nordic nrfConnect/Toolbox

but if it requies a mobile phone application... it sounds a bit inconvenient, similar to what berkseo was alluding to. Nordic's software efforts always seem to assume Bluetooth, which is frustrating, because the hardware itself obviously doesn't have to rely on Bluetooth per se.

However, at the bottom it does seem to give you the option of crafting your own bootloader, and so that might be a way to do it right:

How to compile and build

You should only continue if you are looking to develop bootloader for your own. You must have have a J-Link available to "unbrick" your device.

I get the impression amazon's FreeRTOS may (?) also offer a way to FOTA update an nRF52840.

I haven't looked into Thread, but the nRF52840 supposedly supports Thread, and maybe (?) by now Thread is mature enough to have FOTA.

[NeverDie]

From what I gather Particle had a FOTA for their nrf52840 modules, but they ruined it by making it a monthly paid subscription service. Too bad.

[projectMarvin]

@NeverDie Here is a nordic fota over thread example.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.1.0%2Fthread_example_dfu.html&cp=7_3_2_10_4_0
They also support using a dongle or DK with a raspberry as a border router.

Nordics documentation is fairly extensive and quite easy to search, I like it
The nrf52840 DK is kind of the standard example hardware for openthread so they have plenty of examples.

[projectMarvin]

@NeverDie I read something about that Particle discontinued their BLE mesh boards

[NeverDie]

@projectMarvin said in Second setup, choosing a radio:

@NeverDie I read something about that Particle discontinued their BLE mesh boards

At least in part. Hackaday says Particle discontinued their Xenons.

[projectMarvin]

@NeverDie said in Second setup, choosing a radio:

@projectMarvin said in Second setup, choosing a radio:

@NeverDie I read something about that Particle discontinued their BLE mesh boards

At least in part. Hackaday says Particle discontinued their Xenons.

https://blog.particle.io/mesh-deprecation/

[scalz]

@projectMarvin
indeed nrf52 + mysensors fota is not officially supported.
When I tried fota, I used nordic/Adafruit (secure) bootloader and derived it (because we used adafruit core + mysensors).
That was a while ago.. but actually I prefer and need subghz.
Unfortunately I'm working on others fun projects so I don't have time to work on nrf5 for the moment.

Sure using mobile app for fota is not convenient. better code a server-side app, micro service, for this task.

[projectMarvin]

So after spending some time reading on the forum I have kind of shifted toward rfm69 with a sensebender ethernet mqtt gateway.
However this comes with new concerns.
The only rfm69 frequency I can use is 433 MHz, which means huge antennas. Even coiled they are pretty big.
Searching Taobao (chinese aliexpress) the rfm69 modules are quite uncommon and so I'm worried that they are already a bit aged.
Also the majority of the ones listed are the C version with a different pinout than the version used by sensebender.
The sensebender gateway is aging, it 5 years old with the last update 3 years ago.
This is not negative, I'm just wondering if it's still a good gw for a new system or will it soon be considered old and lacking?

I'm not sure what the development plan is for mysensors, will we keep using nrf24 and rfm forever or is there any plan to shift towards something newer?

[scalz]

@projectMarvin
why can't you use other freq than 433?

• Even if rfm69 is not very new, there are lot of choices on aliexpress for cheap with different variants( freq and footprints). RFM69 works great for longer range vs nrf24/52.

• RFM69HCW variant is footprint compatible with RFM95W.

• MySensors new driver is RFM69<->RFM95 communication compatible

• RFM95 is more expensive, a bit more power efficient (especially in RX mode, but so far there is no listenmode in MySensors, so that's not a big detail)

About the sensebender gw, I have one but actually I use my own gw designs (because I can). But I don't think SAMD mcu is "obsolete" for a good gw

Personally I prefer an external gw (Serial or ethernet), than radio module directly connected to rpi.

For the moment, afaik, MySensors plan is still the same, and might remain the same for quite a while I think: arduino, nrf24, rfm69/95.
We (me especially) wanted to add others newer soc for subghz (like TI's) but it's not worth the effort, I'm too busy for supporting this.
So it's easier for the team to support what we use.

[NeverDie]

@scalz said in Second setup, choosing a radio:

MySensors new driver is RFM69<->RFM95 communication compatible

Good to hear! That potentially gives us the best of both worlds.

On the cost front, the STM32WLE5 is the first single chip solution that has both an MCU and LoRa integrated onto a single die. What's interesting is that it appears to be priced lower than Semtech's standalone LoRa chips.

So much depends on price. The Fanstel top-end nRF52840 modules have range that's comparable to an RFM69, but at better data rates. They're pricier than what most people want to pay though, so that has all but ruined the uptake rate.

If Expressif were to offer a Wi-Fi 6 chip with WiFi-NOW capabilities, and which could sleep at ultra low power, then the promise of its gigabit speeds would be a game changer. Unfortunately, I'm not aware of any announced plans for them to do that.

[scalz]

@NeverDie
There are others soc with LORA integrated, often with tiny footprints.

I agree about nrf and bitrate. I have bt840xe on one of my gw, not sure if I would use one on a coincell node
I mean nrf52840+external frontend is almost same rf power output as rfm69 at 13dB which would be a lot for a coincell, but rfm69 has better penetration and no potential coexistence problem with other protocol if using mysensors. Well, we are talking about differents beasts, depends on the usecase, there are pros&cons in both I think.

Here, I'm quite happy with my cheap rfm69 modules, I get a very nice range, I don't need any repeater (a bit more than 2acres area, with nodes in different buildings and thick rock walls, metals obstacles etc).

[NeverDie]

@scalz said in Second setup, choosing a radio:

There are others soc with LORA integrated, often with tiny footprints.

Who? I've tried googling this, and all I find is STMicroelectronics. The rest are all SiP rather than SOC as far as I can tell.

[scalz]

@NeverDie you're right it was probably SiP.

[CarloMagno]

@scalz said in Second setup, choosing a radio:

MySensors new driver is RFM69<->RFM95 communication compatible

Indeed this is very interesting!
Do you have any pointer to instructions on how to use this feature?
I am also currently working on my sencond MySensors setup and going the RFM95 route. My first setup was a RFM69, so if I can combine nodes from both without having two different gateways would be very convenient... it could also help in choosing the best hardware for each use case.
After some searching, the only thing I could find was this pull request in MySensors development branch, but I couldn't find any hint about how to make use of it:
https://github.com/mysensors/MySensors/pull/1414

[projectMarvin]

@scalz said in Second setup, choosing a radio:

@projectMarvin
why can't you use other freq than 433?

I'm currently in China, 915 and 868 are not legal here

• Even if rfm69 is not very new, there are lot of choices on aliexpress for cheap with different variants( freq and footprints). RFM69 works great for longer range vs nrf24/52.

Yes there are some, but even on aliexpress when you look at the sales numbers you will see that basically no one are buying the rfm69w/hw and quite few are selling them.

• RFM69HCW variant is footprint compatible with RFM95W.

Really? How does this work? Do you reprogram them?
Considering they are different size, different number of pins and have the pins in different positions.

• MySensors new driver is RFM69<->RFM95 communication compatible

Does is also work with rfm69 <-> rfm96 & rfm98? (96/98 are 433 MHz )
If so this would be really interesting solution.

• RFM95 is more expensive, a bit more power efficient (especially in RX mode, but so far there is no listenmode in MySensors, so that's not a big detail)

About the sensebender gw, I have one but actually I use my own gw designs (because I can). But I don't think SAMD mcu is "obsolete" for a good gw

Ok cool, might go for one then if I choose nrf24 or rfm69.

Personally I prefer an external gw (Serial or ethernet), than radio module directly connected to rpi.

Yes I agree, I want the gw to be independent preferably over ethernet.

For the moment, afaik, MySensors plan is still the same, and might remain the same for quite a while I think: arduino, nrf24, rfm69/95.
We (me especially) wanted to add others newer soc for subghz (like TI's) but it's not worth the effort, I'm too busy for supporting this.
So it's easier for the team to support what we use.

Ok this makes sense, thank you for your answers

@NeverDie said in Second setup, choosing a radio:

If Expressif were to offer a Wi-Fi 6 chip with WiFi-NOW capabilities, and which could sleep at ultra low power

Then I would immediately buy a wifi6 ap, this would be amazing!
Even though I prefer a standalone solution like mysensors this would be to convenient to ignore

[scalz]

@projectMarvin said in Second setup, choosing a radio:

I'm currently in China, 915 and 868 are not legal here

oki!

Yes there are some, but even on aliexpress when you look at the sales numbers you will see that basically no one are buying the rfm69w/hw and quite few are selling them.

Still it's available for ordering. I prefer using HCW and CW because they have a more compact footprint. but I ordered HW/W in the past on aliexpress too, no problem. works the same, only the pinout changes.

Really? How does this work? Do you reprogram them?
Considering they are different size, different number of pins and have the pins in different positions.

Nope. RFM69HCW and RFM95 have same size and mapping, you can take a look in datasheets. Note: only HCW variant is compatible.

Does is also work with rfm69 <-> rfm96 & rfm98? (96/98 are 433 MHz )
If so this would be really interesting solution.

Unfortunately, we test what we have in stock and use, so I've no idea about those 433mhz modules..maybe yes in theory, but I've never tried this setup.

[BearWithBeard]

@projectMarvin said in Second setup, choosing a radio:

Really? How does this work? Do you reprogram them?
Considering they are different size, different number of pins and have the pins in different positions.

RFM69HCW and RFM9x are indeed pin-compatible. I've drawn a bunch of RFM modules with their pinouts a while back, because I couldn't find a good, clear comparison diagram including the pinout online. If there's interest in the original SVG files (i.e. to add them to the radio guide) or drawings of other modules, just let me know.

[scalz]

@BearWithBeard nice pic, could be added to the radio guide, sure

well, the thing to remember when you don't have any pic, is H (High power version) require more IC for RF because of the power amplifier whereas non-H (low power version) only has passives parts (res, capa etc).
And on non-C version (HW and W), there are pads close to the crystal.

[BearWithBeard]

@scalz Yupp!

C - Compatible, fits RFM12B (69CW) and RFM22 (69HCW) footprints
W - Supposedly "Worldwide" / certified variants (I'm not certain on that)
H - High power, with amplifier (+20dBm, as opposed to +13)

I just find it weird if the pinout is printed on the "backside" of a PCB so that you have to turn it around to look at it (breadboard prototyping). With these drawing, I have both the components and the pinout visible. I think visually, so I like having visual references at hand.

[NeverDie]

I suppose the pinouts may matter for legacy upgrades, but for new designs I presume you'd be better off using a LoRa module that comes with built-in metal shielding: better SNR and FCC (or equivalent) compliance. Also, the better LoRa modules come with TCXO's, which would be added benefit. None of the HopeRF's shown above have TCXO's or metal shielding. That's not to say they wouldn't work, but if it were me, I'd move on from those to something better, or at least more compliant.

[scalz]

@NeverDie
lora modules are more expensive. You can find rfm69 for 1.8€ shipping included which work great and they are widely available compared to some lora modules.
I think it depends on projects goals.
But I agree with your points of course

[NeverDie]

Here I'm sharing something I just learned which maybe most people aren't aware of: It used to be that the RFM69 was much faster than LoRa, but with Semtech's SX1280 chip, LoRa can sustain a datarate of up to 254kbps, which is close to the 300kbps maximum of an RFM69. And, I suspect that with LoRa's greater receive sensitivity, it might be able to attain its highest datarate more than the RFM69, under similar conditions. But the cherry on top is that also Included in the SX1280 chip is an FLRC modem which can get up to 1.3mbps.

In addition, the FSK modem that comes with the SX1280 has a top datarate of 2Mbps.

Now, granted, the SX1280 operates at 2.4Ghz, not the sub-1Ghz of previous LoRa or RFM69, but Semtech is claiming the SX1280 has extremely high immunity to both Wi-Fi and Bluetooth interference, well, at least in LoRa mode that is.

The SX1280 also has range finding built into it for asset tracking, so, at least to me, it sounds like an interesting chip. If the environment happens to support high speed communications, then you can use that, but if not, you can always fall back onto LoRa to get your packets through.

I've checked, and EByte has some SX1280 modules available on Aliexpress.

[BearWithBeard]

@NeverDie Agreed. But at the same time I think it's easy to underestimate which impact projects like MySensors or Low Power Lab (Moteinos) have with the selection of hardware they provide or advertise. If they focus on unshielded HopeRF modules for SX12xx transceivers, then that's what most people are going to buy, because they think that's what they must buy to stay compatible. They're well known, widely supported / documented / endorsed and, of course, relatively cheap. That's exactly why those black NRF24 modules are still so popular.

Different "standard" or go-to hardware is difficult to establish. But if one knows exactly what parts are needed, how to get them working and the design is specifically for a personal project, sure - pick better parts with shielding, etc.

I bought some HopeRF modules to simply test sub-GHz RF and was suprised how well they worked, so I kept using them. They dropped only 1 in about 5000 messages (0.02%) on average over the past two month. I built a Dual-RF GW and am super happy with it (aside from an ATC issue with 2.4.0). I might get different transceiver in the future, but for now, they're doing a great job.

Here's a quick sketch of the coverage in our house (pumice stone walls and reinforced concrete floors), comparing NRF24 and the HopeRF RFM69 transceivers. I can reach every corner of our property with a RFM69HCW on the GW and a non-amplified RFM69CW on the node. LoRa would be totally overkill for me if they have no significant benefits other than increased range. (Maybe lower power consumption?)

[NeverDie]

@BearWithBeard Yes, you're right: there are many advantages to sticking with "known good" hardware--vetted by a larger community--as well as not fixing something if it isn't broken.

On the other hand, if you want to try range-finding asset-tracking, then you maybe (?) have to consider something new in addition to (not as a replacement for) what you already have. What are the alternatives? I guess maybe Bluetooth, or something that beeps when you press a button like a key finder. Perhaps those are good enough. Not sure.

[projectMarvin]

@scalz Sorry, I didn't notice you were comparing 69 to 95.

@BearWithBeard Nice drawings! What did you use to draw those?

[BearWithBeard]

@NeverDie Yeah, different use cases and demands may require to use alternative hardware. I deliberately chose to represent the standpoint of a beginner to provide another perspective as to why people are still buying "mediocre" hardware. I didn't mean to contradict you. You are highly experienced and show that with your contributions. I often learn something new when I read your posts (latest example: the SX1280 above). I hope it stays that way!

@projectMarvin Thanks. In an attempt to step away from Adobe products, I'm using Affinity Designer for a while now and I'm very happy with it for vector graphics and interface design.

[NeverDie]

@BearWithBeard I liked the RFM69, but I quickly gave it up over concerns such as: https://hackaday.com/2017/12/20/fcc-fines-drone-fpv-maker-for-using-radio-spectrum/
The way I read the US regulations, it seems much easier for a LoRa device to conform and yet still have rock solid connectivity, whereas the rules effectively handicap narrowband by imposing cripling tx power limitations and non-generous duty cycles. And each ISM band has unique requirements as to what is allowed and what isn't. If you live somewhere else, then obviously the rules may be different.

So, rather than being overkill, I see the receive sensitivity of LoRa as a real gift, allowing the Tx power to be dialed down to truly insignificant levels that can't possibly bother anyone or anything.

[scalz]

@NeverDie
I agree too. I don't think a Lora module is overkill, it has interesting features. it just depends on project criteria, there are also commercial products using rfm69.

A nice setup is using rfm95/Lora module on gw, then you can use rfm69 and rfm95/Lora modules for nodes depending on requirements.

I don't need to mention antenna tuning etc for diy nodes, but it's good to remember, software needs to be compliant too with regulations.
MySensors lets that freedom to users, so nothing prevents them to use too high power levels, or flood a rf band, break duty cycle, and become an outlaw..

Still, there are basic mechanisms in MySensors, available only for rfm69/95, like:

• listen before send, for free channel
• automatic power control for better battery lifetime, and greener communication which dials down TX power to very low levels. But it requires to use new rfm69/95 driver.

[NeverDie]

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.

[wassfila]

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

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

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