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.