Hi @gohan and others,
Thanks for your comments, here is further clarification on my particular config / needs...
Firstly, I appreciate the reminder about the new BlueTooth modules, I'd forgotten about them to be honest. However, at the current price of AUD$69 per node vs AUD$6 for an ESP, the ESP wins, unless its battery powered and the task requires so much on-air time that a battery powered ESP device is impractical, then the $69 price could be justified. In time I;m sure the price will come down, but I think BlueTooth will always be more expensive that WiFi.
I wrote my own 'controller' (an extension of my older custom security system) and decided to go with MySensors because its data strings / protocol are very flexible and efficient, and saw no sense having the nodes and the controller convert an efficient protocol to and from MQTT for transmission, so the controller parses and generates MySensors formatted data.
In the beginning, I had a dozen nodes transmitting via RF to an Ethernet gateway, but after the ESP devices came onto the market, I've been wanting to use them, but if you have to add a radio to each one, I may as well use and Arduino. The problem being, MySensors 'sensor nodes' can only communicate via RS232 or RF in its 'native' data format. To communicate over Ethernet, the data must be in MQTT packets, then you have to setup an MQTT server somewhere etc, and data has to be converted back and forth between the 'native' format and MQTT. Add to that, the MQTT 'bits' are another source of potential problems, degrading the reliability of the MySensors network, which is otherwise very reliable. If I'm going to add another piece of hardware/software to the process, it should offer some benefits, rather than just being a 'necessary evil', which is how I see MQTT when applied to a MySensors network. This has been a critical shortcoming of MySensors for a while now...
A Very Typical Example:
*I want a MySensors node in my car that automatically arms and disarms my security system (and switches lights etc) when I leave and return. I tried to do it, but RF24 and BlueTooth were unreliable due to the distance and metal in the car, whereas, I have great WiFi access where its parked.
To achieve my goal, I'll need a battery powered, weatherproof repeater node outside, or at best, an ESP in the car, with a matching 'ESP with RF24', in the house and write custom code for them to communicate with each other, then the inside ESP will transmit a message to the MySensors network. Like so many other things, its 'possible', but a painless and totally unnecessary 'kludge'. Why shouldn't I be able to simply flash an ESP NodeMCU with code for a 'switch node' and stick it in my car - job done - it then talks direct to my MySensors gateway? Yes, I know, an MQTT node, plus a Raspberry Pi, plus Mosquito, blah blah... This isn't the eighty's, that's the sort of thing I had to do back then.*
Gateways use an Ethernet transport, so the code is all there, but its setup as a 'gateway transport' and not a 'node transport'. It seems such a waste for nodes to communicate on any transport other than RF, the really good MySensors protocol / packet structure has to be translated into a much less efficient protocol, and back again. Why shouldn't nodes be able to at least talk to the gateway over Ethernet? And, when you consider part of the brilliant design of MySensors is that each node can act as a forwarder, an 'Ethernet node transport' would allow inter node traffic, greatly improving the range.
Suddenly, a small groups of nodes in one location could interact with nodes in another location anywhere (over a secure TCP/IP link). My home controller could then receive notifications from sensors at the office monitoring vital equipment. Likewise, when I 'arm' my home system by clicking the 'Off To The Office' button on my controller, the office MySensors network would turn on power to the coffee machine, so my hot morning cuppa is ready when I get there. Yes this 'is possible' now, but it's not 'native' to MySensors and requires custom work-arounds, often different for each person, depending on their particular setup.
The whole purpose of MySensors / Home Automation is to make life easier, my home system is pretty helpful now, thanks to the very reliable MySensors project. For example, I tap a 'Bath' button on my controller (or phone) and the bathroom towel warmer is turned on, and depending on the current temp, the room heater may be turned on as well, and finally, the water heater thermostat is given a 10 min nudge to bring the water to 'piping hot', rather than normal 'hot' for routine hand washing etc. (that little water heater 'smart' saves me enough each year on my power bill, to pay for all my home automation equipment costs).
Reading through the forum from the beginning, I've see many users stumble over why they have have to add an MQTT client, then setup something called a pie with mosquitoes? Likewise, users keep asking why they have to add a radio to an ESP, when the ESP and the gateway both already 'talk' Ethernet? It's just such an obvious 'hole' in the MySensors transport.
I feel the lack of Ethernet on nodes is truly crippling MySensors, adding an Ethernet 'node transport' would open up so many possibilities, that currently require each individual to kludge together their own solution, you just select MY_RADIO_WIFI and presto! Those that don't like exposing their HA to WiFi, simply don't have to, but I'm willing to bet it would become very popular if enabled, particular with newcomers.
My apologies for the length of this post, but I feel strongly about this and hope I've explained why.