Started with MySensors and about to give up (some feedback)

[alex28]

Hi everybody. I'd like to give some feedback on my experience as a new MySensors user here. As you can guess from the title, it's not going to be very positive. I hope this kind of post is not unwelcome. It's also very long. Please don't take this badly. It's just my own experience with MySensors I'd like to share.

Short info on me. I'm a software developer mainly working on GPU low level code. Although mostly a software guy, I have some experience with the hardware side of embedded systems and I know my way around a soldering iron and a scope. I was looking for a way to improve my home automation setup, mostly made of ZWave and cheap 433Mhz devices, with something open that would give me more control. Basically build my own nodes. MySensors seemed to fit this perfectly.

So came the lockdown and hey, perfect opportunity to get started ! Got myself a couple of Arduino Nanos, a few NRF24L01+ and lots of motivation to get my first GW and test node running. Unfortunately it ended up being an extremely frustrating and time consuming experience. More than once I had to resist the urge to throw everything in the nearest trash bin.

Problem 1. The gateway.
I had an ENC28J60 lying around for some time. The MySensors getting started guide clearly mentions that this is a supported option. So I connected it, got the UIPEthernet libs linked in the guide. Cloned the ntruchsess repo as mentioned in the readme. Hit compile and - incorrect library version. Great start. Cloned the MySensorsArduinoExamples entirely, copied the lib from there. Incorrect library version. OK. Started to hunt around Google, found the original UIPEthernet repo. Cloned that and it compiles. Good.

Started the node, doesn't reply to pings. Searched the MySensors forums, found a topic titled 'Can't ping Ethernet Gateway ENC28J60 + Arduino Nano Clone' from 2017. In that topic some MySensor devs clearly state the ENC28J60 support is broken and that, I quote, 'Not sure anyone has bothered checking with the latest version of the library...'. Uh what ? If you know that this chip won't work since 2017, why is it still a recommended option on the building a GW guide ? Why not make it clear that only the w5x00 chips are supported ?

Problem 2. The Raspberry Pi gateway.
So ordering a w5100 for my GW is not an option right now. It would take a month to arrive due to lockdown. So I decide to use a Pi Zero as a GW. At least the ENC28J60 works with that one. I visit the 'Building a Raspberry Pi gateway' page. It talks about some radio communication bug in the 'latest Jessie'. Raspbian Jessie has been shelved in 2017. So uh, is that bug still an issue in current Raspbian Buster ? Do I still need to get the dev branch or not ? OK, I end up pulling the master branch. The Pi has two independent hardware SPI ports. I connect the ENC to spi0. Works. I connect the NRF24 to spi1. Oh wait, the pinout image in the wiring diagram section of the 'Building a Raspberry Pi gateway' is wrong. SPI1 CS0 is definitely not on pin 36 by default (but on pin 11). Why leave a clearly incorrect pinout diagram on your guide page ?

So I try to compile the GW for using spi1. Doesn't work, radio connection failed. Searching the forums. Found a post titled 'Double SPI Radio Raspberry Pi'. Great, sounds like that guy has figured it out and a MySensor mod commented on it. Sounds like that should work. Followed his quick guide. Doesn't work. Search more. Oh wait, it actually can't possibly work - his cs0_pin assignment in the config is wrong (this setting expects BCM pin numbering, not Pi pin numbering as he used). So that forum topic - which probably pops up for everyone searching how to connect the NRF24 to a Pi spi1 port - won't work because it contains a fundamental error.

Problem 3. NRF24 range is bad. Really bad.
So I finally get the GW and a test node to communicate. Yay ! Smooth sailing from now on. But wait. If I position the node across the room, it starts dropping packets. Searched the forums. Filtering caps on both NRF modules - check. Clean power - check (battery pack for the node, lab power supply for the GW Pi). Range is still bad. Some forum posts seem to indicate that the Nano 3.3V regulator is not good enough to power the radio and you need a separate supply. OK. But why not mention this in your build guides ? All your guides clearly show that the NRF gets directly connected to the 3.3v rail of the Nano. Well I don't have a voltage regulator. Searching more. Lots of conflicting information. Maybe the NRF is counterfeit. Yep it probably is. Order and try another one ? Order and try an external regulator ? Lockdown, week long waits for any oversea deliveries, so nope, not an option. Found lots of topics with people having range issues on that radio. Common solution seems to be switching to the RFM69 on a different frequency band. Would have been nice to know that before. Why not mention this in the guides if it's such common knowledge apparently ?

Well that's where I stand right now. What was supposed to be a fun and satisfying experience to build some home made IoT devices ended up being a long and frustrating one leaving me with a feeling of having wasted my time. I wanted to build some fun nodes but after all that time spent trying and searching and ripping my hair out, I still don't even have a stable network running.

And yes, some of this is probably due to bad counterfeit HW and also my own overexpectations. But a lot of the frustration came from the obsolete, outdated, conflicting and sometimes blatantly false information presented both on the official MySensors guides, as well as in the forums. I wasted so much time searching and trial'n'erroring solutions to problems that wouldn't even exist if they were clearly outlined in some up-to-date guides.

At this point I'm unsure about how to proceed. I like the idea behind MySensors and support in Home Assistant (which I use for HA) seems good. I could order an NRF24 PA LNA. Or some RFM69's. And try both. And have a more reliable network - maybe.

But I don't really feel like spending weeks on this just tinkering around and trying to make the basic network behave in a reliable way. Maybe I misinterpreted what the MySensors platform is about. My impression of MySensors was that this is a solid and well tested platform where the basics would just work out of the box without much tinkering around. And where I could spend my time on what actually matters to me - building my custom nodes. Trying out dozens of different radios from different manufacturers, different power supplies, different DIY dipole antennas and whatnot is just not something I'm interested in. Maybe I'll just get a commercial ZWave interface with digital inputs and connect it to the Arduino instead.

Thanks for reading.

[mfalkvidd]

Welcome to the forum @alex28 and thanks for taking time to share your experience. I'll digest it a bit before writing any further, to make sure I subdue my emotional response so we can keep this constructive.

To anyone else reading this feedback; please remember to not shoot the messenger. This is a great chance to make the MySensors project even better.

[mhkid]

@alex28 I think these are fair criticisms. I've spent a ton of time with mysensors and have backed away because of some of these same things. I love the idea and appreciate the effort that's went into the platform. You have to tinker a lot and you spend more time figuring out problems with the platform than you do actually building sensors. Spending time troubleshooting only to find out others have spent time on the same thing or info is outdated takes the fun out of the process for me.

However, having said that I keep coming back because I love the idea of this platform. Lots of really great ideas and great makers contributing here.

[BearWithBeard]

I'm sorry to hear that you had such a disappointing first contact with MySensors.

I can't really comment on the issues you had with the ENC28J60 ethernet module and RPi zero gateway, as I haven't worked with those yet. But from my personal experience as a simple community member, I think problem 1 and 2 are due to your hardware selection not being very popular and therefore might not be as well tested as others and a partially outdated documentation (you hinted at the Raspbian release which is currently two major versions behind, for example) may be the consequence of this. This should clearly be updated, no question. And I can totally understand your frustration if you continue to run from one issue into the next one like this. I think I speak for all of us if I say that I know how annoying and discouraging it feels.

But here's the thing: I don't think the devs and mods are to blame for this. While there is mainly a core team contributing to the project, MySensors is open and community-based. Those who contribute regularly and actively have most likely enough things to do, to also constantly worry about keeping the guides up to date and verify the compatibility of every third party library. As the project grows over the years, adding more and more components, functionality, transports and so on, it's getting harder and harder to keep an eye on everything. I guess that's where we all have to accept responsibility to point out wrong, outdated or ambiguous information to help and improve MySensors.

In this sense, I think it is very helpful to get critical feedback from someone who is just starting out and has a technical background. You have a totally different perspective than someone who is completely new to it and also to the regulars. The former lack the expertise to identify and then express their problems when they hit a roadblock, while the latter may take specific things for granted and just know where they get their information from.

I just had a closer look at the wiring guide - which is part of the third problem you mentioned - and noted that there is indeed room for improvement in some places. Things which I've never noticed before because I didn't feel like I needed more information. But on second thought, yeah, that's because I've been through this before and gained knowledge along the way I now take for granted. For example, while the guide does recommend to use capacitors, it may not be communicated prominently enough - especially considering, that a lot of NRF24 troubleshooting threads in this forum seem to be caused by noisy signals / missing caps. On top of that, a list of (dis-)advantages for every radio type (range, reliability, power consumption, frequency, ...) might be a good addition to give beginners an idea what they should choose, because the radio introduction doesn't elaborate on this topic either. Maybe also a list of NRF24 modules which are known to be less troublesome than the common black one might be helpful.

I don't see the pin-to-pin wiring diagrams between Arduino and radio as a problem though. I always perceived MySensors as a beginner friendly platform and as such I understand why it is shown like that. It's the basics. You don't need more to get started, but of course, when you dig deeper and your expectation rise (or are high from the beginning), there's much more to it and you start wondering where to go from there, how to improve the signal quality, etc. Maybe there's room for an "advanced follow-up" to the basic guide, which goes into more detail.

As a personal consequence, I'm happy to take a closer look at any guide I'm familiar with and try to figure out if and how they can be improved. But I honestly don't expect to find a ton - without the intention to downplay your personal experience, I don't think it is representative for the majority of users - because the guides are generally in a good state already.

Let's not forget that MySensors has hugely lowered the entry barrier to IoT and home automation for countless people, which wouldn't be possible without the extensive contributions from the devs and every community member, who is actively helping. I invite you to participate and help to improve the project as a whole. Your input is very welcome.

---

Another general idea I just had is to add some kind of "I just made this and it worked / I tried to make it and it didn't work [because,... (optional questionaire)]" on every guide / article to get a feedback about its current state.

[bjacobse]

@alex28 As your critics reads for me as constructive feedback, then I will suggest for you to enable you to get a positive experience (I have been around Mysensors since May 2015) I use it with Domoticz as this is what I like ;-)
Anyway start with simple things, I have my Domoticz on a RPI attached to the serial gateway, it's simple and reliable and "easy" to debug

Make sure the gateway is working on your home automation, and then proceed to make 1 simple windows sensor
https://www.mysensors.org/build/binary

And then you can make additional sensors to your network. Please note that Domoticz is the controller, and hence it's Domoticz that will allow a sensor/node to be "added" to your network. The serial gateway is not having anything to do with "adding" nodes to your network, it's just a "dum" gateway moving data from the sensors to your homeautomations

Any other Homeautomation than Domoticz is equally good, if they have Mysensors support :-)

To make your start easy:

• Don't use ENC28J60 to make a gateway
• Make a serial gateway
  https://www.mysensors.org/build/serial_gateway
• Don't spend too much time on NRF24L01+ as MANY of those are counterfeit China-shit, and you can debug for hours not understanding why your setup isn't working. Replace NRF24L01+ immediately if it ain't working
• Verify that your NRF24L01+ are in good working condition, before using them (if possible). Do you have a friend that have a some known good working NRF24L01+, then borrow a few pieces
• ALWAYS use a capacitor as close as possible to your NRF24L01+ radio modules voltage supply/GND
  https://www.mysensors.org/build/connect_radio#connecting-a-decoupling-capacitor

And then I'm quite sure the Mysensors-community would like if you can support to update the documentation to become better for the next new persons that would like to start using Mysensors, so the frustration that have been around your start can be reduced for the future

[mhkid]

@BearWithBeard I think the frustration is more that the information is out of date in many areas or leaves it open to people repeating the same thing that others have already solved. The antenna is always a problem. Maybe a prominent guide/recommendation on how to avoid buying counterfeits. A better FAQ on the common errors with communication messages and top solutions. Much of the information is there, I think it could be curated better. However it's hard to find sometimes in the forum because information is conflicting because people have different experiences because of different setup.

A one recommended path for beginners would be much more helpful. Meaning use specific hardware: gateway, antennae, nodes and whatever else and you're likely to have success. Part of the frustration is using something you have on hand only to find out after you built things out it has some other known problem or limitation that if known up front you would have avoided. The battery nodes for some reason took me a while to figure out. Then I bought 3.3v pro minis to only realize as I built some of the simpler sensors out they needed to be 5v (like motion) and they either run on more batteries or had to be plugged in, which defeated my purpose for a remote sensor. I'm sure you'll say but all that info is there. It is in some cases but you spend hours trying to find it in the forum.

I too have a software engineering background so I'm not a technical novice. I enjoy this as a hobby but because of ease of use I've started to not use the platform. If there were a known path to success that was documented that way I'd come back in a minute. I have no doubt there is a setup and hardware config (including where to buy from) that works nearly all the time it just isn't clear to me what that is.

Please take as constructive. I'd love to see MySensors adopted by even more people because I think it really is a platform that could be good for way more people.

[alex28]

Hi, thanks a lot for all your replies. I really appreciate that my post wasn't just taken as a rant from a disgruntled new user, but as constructive criticism from a different perspective.

I'd like to address some points made. Please keep in mind that all this is from my own personal experience. I can't claim that it's universal, but just some subjective observations from one guy who tried MySensors. That said -

@BearWithBeard I have to respectfully disagree about the guides being generally fine. Yes, they are nicely written and well presented. They're very inviting for new users. That's important and sets MySensors apart from many other open projects which often look very unwelcoming to new users with very steep learning curves. Having been involved in a few FOSS projects, god knows I have been guilty of that myself. The problem with the guides is the information contained in them. It's outdated and misleading.

From what I could gather on the forums and also from replies here (as the one from bjacobse), is that there are a number of best practices to follow with a MySensors project. And you have to follow them closely. If you don't, you will inevitably run into problems. Don't use the ENC28J60 network chip, it won't work. Don't use the NRF24L01+ if you want a reliable connection. Use external voltage regulators. OK that's all fair. But while these practices seem to be very well known by the community, even taken for granted, they are not documented for new users. In fact, the very guides written to draw new users to the platform will actively encourage bad practices - by presenting them as perfectly valid options.

Yes the information is out there somewhere. But it's often hard to find, spread out and riddled with confusing and conflicting (and sometimes plain wrong) info, sidetracking you.

I'm also not that sure if my choice of hardware is so unusual. Maybe people selecting such HW will simply never show up on your radar, because they give up early on due to all the problems they run into.

For the network chip, yeah, it's not widely used on Arduino. Yet the ENC28J60 is not uncommon for giving RPi Zeros an ethernet port. Like most of these cheap Chinese modules they're usually sold in packs, so probably more than one newcomer to MySensors will have such a module lying around in a drawer somewhere. Especially if he comes from the RPi community. Your starting guides make it sound like this module is a perfectly fine choice. You just have to install these libs that MySensors specifically modified for it (but they were never updated and don't work with the new AVR stuff anymore), and you're good to go ! Well no. And then later on, after hours of frustration, you find a forum thread where mods openly say that the ENC is unstable, untested and should be avoided, then reading the guide sounds almost cynical to me. If something is known not to work for years, then remove it as an option from the newbie guides. Having only one single network chip class supported (the w5x00 line) is perfectly fine. Just don't mislead people into using unsupported HW.

The NRF24 situation is similar. I understand that historically this was the only supported radio. I also understand that it is again unwritten community knowledge that mostly due to the market being submerged by barely functional Chinese clones, there's a good chance the performance with this module will be abysmal. And also that the RFM69(HW) is a much better and more stable choice for many use cases. Yet, this is not mentioned anywhere in the newbie guides. The NRF24 is still presented as the primary and default choice of a radio. With an image of a cheapo Chinese clone module right next to it. I think your idea of adding the pros and cons of each radio would be tremendously helpful when starting out. Had I known the issues with the NRF clones, I would have either ordered a better nRF based module (like the one from Sparkfun) or something RFM69 based, before even starting. And this would have saved me from a big disappointment later on.

Also, please don't underestimate the number of users coming to MySensors from the RPi communities. A lot of DYI home automation people use controllers like Domoticz, Home Assistant or similar running on a Pi. I'm sure that many of your own established community members also do. It only makes sense for many to install the MySensors gateway directly on their Pi. And that's where people will inevitably run into issues like I mentioned in my OP. If you browse the forums from these communities, when people ask about creating their own IoT devices, they will more often than not be pointed to the ESP8266 / NodeCMU stuff running on Wifi. With the result that all their DIY IoT devices are directly connected to a public IP network, with all the fun and not so fun consequences this can have. MySensors would be a perfect and safe alternative here. But I can't stress this enough from my personal experience, having the newbie guides be up to date, working and promoting best practices is absolutely primordial here. They're the first contact people will have with MySensors. And not everybody will have the persistence to keep going through the rough to try to make it work. Many will probably just give up and turn to things like the ESP.

@bjacobse, I appreciate your comments and advise. I have a running ethernet GW at this point, albeit with very unreliable radio link. A serial GW was not an option due to the way my current HA infrastructure is laid out, which is an entirely Ethernet based internal IoT subnet. Your comments about best practices with the ENC and the NRF are spot on and should be made more clear to newcomers.

Again, please don't see this as a direct attack on the MySensors project. I think it's a great idea and a lot of awesome work has been put into it. But communication is really important for new users. And please also think about the type of user who is 'only' looking for a working and stable base platform he can build sensors on. For these type of users a known stable setup, both HW and SW wise, should be recommended in my opinion. Along with best practices and pros and cons for HW with valid options (like the radios).

[Sergio Rius]

@alex28 In my opinion you are presenting fair points.

[GaryStofer]

@alex28 Hi Alex, sorry for your frustration.

I think documentation, either incomplete or outdated, is the crux of most open source projects.

I can not speak to the Hardware you used to try to get a network up as I have stuck to the more simple approach of using the simple Arduino ( ATmel328P) nodes for both sensors, repeaters and gateways, while using a RPI as the network controller with something like Domoticz running on it. I started years ago , even before the RFM069 was an option and made PCBs that incorporate the NRF24 and the ATMEL 328P along with the necessary voltage regulators etc. Maybe it was easier to get started then because there where less options and less misleading documentation was available, but I don't recall running into any problems worthwhile of mentioning or having the level of frustrations you have encountered.

I have two sites running with 8 and 12 nodes each. All sensors running on batteries. The range of the NRF24 is limited in that I only get through one or two sheet rock walls inside the house, but using the NRF24 module with the built in PA/LNA on the gateway and one repeater opened up the range considerably. I'm fairly positive that all the NRF modules I have a re clones....

I use the serial gateway on the Atmel328p and connect that directly to the serial port of the Rpi Zero-W, without USB adapters then run Domoticz on the PI to get onto the internet .

If you look on OSH - PCB you will find many good PCBs that you can make MYsensors nodes with using the more simple Arduino platform.

Most of my frustrations stemmed from the Linux configuration for the RPI so that it doesn't clobber the SD card on surprise power failure.

Cheers -- Gary

[pptacek]

I'm an experienced embedded developer and I spent weeks tinkering with various things around MySensors. Here are my 2 cents to anybody who wants to start quickly and painlessly.

1. Do not bother with anything but Arduino, nano is especially simple to use due to the built-in USB. I personally prefer pro minis due to the form factor. Do NOT bother with Raspberry Pi, it is too much work to get something done unless you have pre-build images you can just dd on your SD card.
2. Please, if you are starting with Arduino and stuff, USE some shield for your radio module. Order some Nano RF24 shield like this one https://www.amazon.com/Emakefun-Terminal-Expansion-ATMEGA328P-Interface/dp/B07N8PLFVC to avoid self-wiring. nRF24 4x2 header is idiotic and it is easy to make frustrating mistakes, have loose wires, miss a capacitor, have a weak voltage regulator, etc.
3. A serial gateway with a nano on a shield can be put together in 5 minutes. You just stack things up, make sure you CE and CS pins are right and upload a sketch. You are done.
4. nRF24 is a radio on 2.4GHz. Let it sink for a bit. Almost everything wireless (and microwaves) in your house runs on that frequency. Do yourself a favor, run a simple wifi scan on your phone and see which part of the band is messed up and which is available. It is simple to do today with free Android and Apple apps.
5. Watch your signal strength! What do you do when you start dropping packets? Put both modules closer and bump signal UP right? WRONG! That will make it worse and you will go down the spiral trying to figure out why your nRF24 radio is total crap. Closer you get, weaker signal you need. Seriously. If you will be operating the same room, set a signal to LOW. When you will go over one wall, set it to HIGH. I'm using nrf24l01+pa+lna modules (one with antenna) between house and garden, three walls in between, 50 yards, and on LOW I have 100% reliable connection, no dropped packets.

As of now, I'm using these battery-powered stacks (nrf24l01+pa+lna & jModule2 & pro mini 3.3V) around the backyard and I'm happy camper:

[mbj]

I started with a small MySensors project more than 4 years ago and life was easy then :-) The choices were few and I felt they were well documented.

I began with an Ethernet gateway but moved to MQTT (ESP8266 because of WiFi) once it was available. The choice of radio was easy and even if there were problems most could be solved. I still run 10 - 15 items using NRF over MQTT to OpenHab and also have quite a few Z-wave items connected to this system.

Today there are heaps of choices and the development continues but my feeling is that MySensors is still mainly driven by a small community of enthusiasts working on this on their very limited free time. As more and more functions/variations are added the complexity grows and the need for correct documentation increases exponentially but the resources are not at all growing in same pace.

I have some experience with using much larger projects (OpenHab, ArduPilot, PX4 etc.) and and also here documentation often is a mixture of updated and outdated info. Many times the forums are where the correct answers can be found but very often there are many erroneous answers per one correct one.

For a project like MySensors I am convinced that the only way to go is to select an entry level configuration with few well working choices which are always kept alive and up to date.

As users become more and more experienced they will have come across a lot of useful info as well as have learnt how to find more. Hopefully some find documentation so important that they are willing to contribute also.

For the advanced stuff of course there should be an ambition to document it well and keep it actual but why not accept this as playground for the advanced users who know enough to find the answers as well as are able to assist others.

Last but not least. We always get what we pay for, don't we :-) To keep a full blown MySensors activity well documented will cost a fortune and require very up scaled resources.

Cheers
Mats

[mhkid]

@alex28 I agree exactly with what you've said. I've spent hours with MySensors and the website and community kept me here for a long time. Would love to just see the quickest path to success. I would have never messed around with a rpi to do this if I would have known the troubles I would run into.

[Jens Jensen]

FWIW,
on a more specific tweak, one of the things I struggled with for a while was why the mysensors defaults for RF24 transport use tx power level RF24_PA_HIGH (-6 dBm) by default instead of RF24_PA_MAX (0 dBm)

I wound up setting:
#define MY_RF24_PA_LEVEL (RF24_PA_MAX)
in all my sketches, as it seems to make the difference for those several walls and/or extra few meters of range.

(Not sure why the -6 dBm setting was chosen?)

[mickecarlsson]

I started with MySensors, Pro Mini and NRF24. I had tons of problems. I borrowed from work our WiFi scanner equipment and checked the 2.4 GHz. It was a total mess. Our DECT-phone almost killed the channel that was used for MySensors. And I discovered, as many has, the NRF24 was all counterfeit.
So, i trashed all NRF24 and moved to RFM69. That was nearly three years ago. My gateway is a Raspberry Pi.
My controller is Domoticz.
Conclusion, and a note to all MySensors users out there. Move away from NRF24 and go with RFM69, you will never look back.

[sundberg84]

Or you can do both (RFM/NRF), which is another positive thing about Mysensors. I have also noticed how dependent NRF is on other traffic. I sometimes lose some nodes during high peak wifi hours, but only the nodes that are on "the edge" of their coverage range. So - its quite easy and cheap to build another RFM gateway, dont have to throw the NRF gateway since I have alot of indoor nodes working with that one. The garden nodes and some basement nodes are running RFM protocol - and that is a big upside with MySensors in my world.

How i see this thread is that MySensors team or any other interested and dedicated person needs to make this clearer and maybe in some newbie guide or on the main homepage start this discussion/ state this information. In this way we can avoid all these things... For example changing the chapter "Radio" in https://www.mysensors.org/about/components so it not only shows the NRF module but also other options, and also have this "common issues" stated.

[BearWithBeard]

I agree with @sundberg84. Let's just make clear that none of this implies that MySensors is fundamentally flawed. My understanding is that the criticism / objection is solely directed at the documentation and how it is presented for new users. If I may try to summarize the consensus in this topic so far:

• Having a proper documentation is very important.
• MySensors used to be simple and straight forward to setup, because options were few.
• The ever-increasing feature set makes it harder for new users to find out which components might be the best choice for their use case ...
• ... and some of the options or their documentations are currently outdated, deprecated or insufficiently tested. They should at least be labeled as such.
• If you are new to a project and follow an introductory guide, the expectation is that you can succeed without seeking information in additional sources ...
• ... or else new users who run into problems may quit in silence and one may never find out, if there is an issue with the documentation.
• There is a desire for a simple step-by-step guide with a "core" set of hardware (and software), both for beginners and people who are simply looking for a stable, reliable setup without hours of fiddling, debugging, searching and swapping components.
• NRF24 might be widely adopted in other Arduino-related projects and the "go-to" radio in MySensors for historical reasons, but many are seemingly frustrated by its comparatively poor range and stability, so RFM69 may be pushed more ...
• ... and there is a lack of explanation, which transport method new users should pick up. A list of pros and cons may be helpful.

Honestly, I think one of the greatest features of MySensors is the fact, that you have tons of options to build your network with. Whether you decide to use Arduinos or other beginner friendy dev boards and premade modules, bare AVRs, ESPs, ARM or NRF5x chips and design your own boards, 2.4 GHz, sub-GHz or wired, lots of controllers to choose from... but I see how this variety can cause problems if they're not well documented, because every component has a different set of quirks and requirements.

Propably the best way so far to get issues related to the guides fixed right away, would be to comment on a guide directly, for example Building a Raspberry Pi Gateway, and mention the problem in there. Suggestions to improve the overall guide could also be discussed in there and a staff member could update it in a timely manner.

But I agree that the process for new users could be more streamlined. Maybe we should collect some ideas how this situation could be improved?

Short term:

• Compile a list of guides which contain outdated or otherwise flawed information. Mark the respective sections as such with a note in a colored box for the time being, if they can't be fixed / reviewed right away.
• Colored boxes may be used in general for asides / cross-references, to emphasize important bits or refer to related information.
• Explain the differences and (dis-)advantages of every available transport method in a separate article: "How to choose the right transport method"
• Add a "Build your first MySensors network step by step" guide in the Getting Started section, which focuses on a single set of hard- and software. The user may learn how to configure and connect to a controller, sending and receiving messages, using two Arduinos with USB interface (Uno, Nano) and NRF24 radios - one Arduino as a serial gateway, attached to a computer running Home Assistant and the other one as a node with a simple button and a relay attached to it. (The selected hardware should just serve as an example here.)

Mid / long term:

• Review all guides. Best practices need to be added and / or mentioned more prominently. Test if the components are still supported; fix or remove them.
• Add feedback buttons to every page like "I made this" and "Didn't work for me". Clicking the latter could open a modal and ask for the users input (without registration). It could also serve as a public popularity indicator (besides analytics, I guess).
• Users currently have to choose between each a bunch of 1) controllers, 2) gateway hardware options, 3) ways to connect to the controller, 4) ways to connect nodes and 5) microcontrollers for the nodes and we may want to find a way to suggest different paths which are known to work well together, for users with different levels of expertise or different needs. Possibly by adding additional step-by-step walkthroughs as mentioned above. One that focuses on simplicity, one on flexiblity, or range, low cost, fully wired,...
• Or implement some sort of configurator where the user can select components or features they want to use and the system suggests which hardware / software would be a good fit by internally weighing them.
• Maybe turn the currently solely staff-curated pages into some kind of Wiki format or GitHub repo, where everyone can participate and submit changes (moderated, of course).

Thoughts? Other ideas?

Of course, I don't expect the devs and mods to do all the work. Everyone who has the time and expertise to contribute is invited to help out if any of this is welcome.

---

@Jens-Jensen The other wireless transports aren't configured for max TX power either. I guess they are set a little bit conservative to work with a wider variety of hardware and power sources out of the box. I don't have actual numbers for common NRF24 modules at hand right now, but there are modules like the CDEbyte E01-2G4M27D which can draw up to half an amp with RF24_PA_MAX. RFM69 radios draw about 30 mA during TX with the default +10 dBm setting, about 45 mA with +13 dBm (max. for modules without PA) and > 130 mA at +20 dBm (PA). I think this approach is fine, but I agree that this setting could be documented better (Is it even? Can't find it outside of example sketches and apidocs right now).

About NRF24 range in general: I have a gateway and a repeater with PA-LNA modules with RF24_PA_MAX in our house (reinforced pumice stone walls and concrete ceilings) and cover all four floors and even some places in the garden with them. None of my sensor nodes need to go above RF24_PA_HIGH, many work fine with RF24_PA_LOW, increasing the battery life, which is especially nice for nodes running off CR2032 coin cells. But I understand that RFM69 might be the better choice for a sensor network and it should be considered to push it more or even make it the default / recommended radio for MySensors in the future, even though they might be harder to use for beginners.

[rejoe2]

Starting with MySensors in the 2.0.0-beta days with nRF24 (and no technical or IT educational background), I completely agree with a lot of the things already mentionned here.
It was a lot easier then and most of the transceivers (even the most likely couterfeied ones) worked with some caps added. But I saw a lot of people struggling when trying out themselfes, be it counterfied chips, struggling with what the controller sw (FHEM in my case) does or (often) - using the Arduino framework to get combined nodes.
So I started doing some wiki work with focus on FHEM (MySensors Starter Guide), collecting also the experience from some other users there.

As atm some new users became interested especially in wired solutions, I was very happy to see the PJON integration making good progress. Imo this is a very good and easy approach, as no additional hardware is required. This makes this transport layer imo the best choice to get into the basics on MySensors and it's interaction with the controller sw as well. Choice for controller in most cases might already been done when joining the community here, so imo this could really help to "join this train here" more easy, as testing doesn't need much wiring or additional hardware.

The only disadvantage is the lack of RF. So starting with PJON as "learning level transport layer" and adding then RFMxx als wireless option might be considered as primary recommendation for the first steps towards wireless then?

[scalz]

Hi there,

so far the main "culprits" I identified are:

• add a picture of a genuine nrf24 module (eg cdebyte) near the cheapo nrf24, and why not a rfm69/95 module too, in the Getting Started/Component/Radio
• add a comparison of pros/cons of nrf24 vs rfm69 in Build/Connect radio, before the wirings
• remove en28j60 from doc, and keeps only w5x00. Let the community handle en28j60 if this is really needed. I don't think anyone in the team is using en28j60 for gw. The fact it's not uncommon in rpi community, doesn't mean it's common in mysensors community (more based on arduino than rpi)
• update store links and try to remove cheapo nrf24 clones
• rpi section

else I don't see so many outdated infos.

Regarding howto connect a controller to mysensors, I've no idea if this should be on mainsite. As controller choice is very subjective. For example, I've already tried Openhab and others, even HomeAssistant for months too (imho having to configure yaml etc is not noob friendly, I couldn't recommend that to noobs and non-computer people, same for nodered as automations tool ) and I still prefer Jeedom..

Other notes:

• it's hard for the team to support and guarantee what we do not use.. regarding all the options available in MySensors (gw, hw platforms..). Example: I'm not sure, but I think rpi as gw is not widely used in the team for example.
• a reproducible howto get started, with 100% success, would be nice sure.
  Still it's important to remember that will always need to learn new skills in mid-longterm. Not because you're a dev, that you know electronics, rf recommendations, the framework etc
  It's hard to follow and compile all forums infos in one place, with limited resources. This would need a book!
• I'm also in favor of subghz but I can understand it's maybe less plug&play for noobs. I also think when you want to get started, it's easier to get success with Serial GW.

[Sergio Rius]

@scalz After the "cleaning" there should be an example on each supported endpoint platform. I mean, if rj45+mqtt is supported, rfm should have a working example with all the components (level adjusters, etc...)

The big problem with rf24, said that it's so dependant on the environment, is that different countries have different regulations. And could be that what seems perfectly ok for some or all developers, doesn't work for other people in their houses.

Documentation doesn't say anything about checking country's wireless regulations as it's neglected.

[scalz]

@Sergio-Rius
sure these are good points. especially country regulations :+1:
That said this needs some research, personally I don't know rules for all countries & frequencies.
In that case, we should also mention that anyone making&selling his board/device with a rf module is maybe out of the rules without fcc/ce certifications. So many things to say on regulations, you're right.

The trickier point is docs for all possible usecases. There are so many different combo. I don't know if educating and covering "all" electronics possibilities, arduino coding, handling third parties libs etc, is the goal of a software framework here, I don't know exactly the original goals.

"If I was in charge and alone for all this work" (personal point of view), I would remove from howtos all things that I don't use, and would let this stuff live in the community hands, on the forum for example.
Like I said, supporting/maintaining/documenting stuff that you don't use, for free, in spare time, is pita.
Franlky, there are many platforms+mysensors that we don't even use. It has been added to the framework, mostly because it's fun to learn/discover new platforms etc, not because of an urgent need at home.

The problem is the more you show&provide, the more users may want and expect, whereas we hope it will be community driven.
It's like you provide for free young plants to someone, and he expects you'll always feed&water it :)

Unfortunately, regarding documenting the stuff I don't use, I've no time for the moment..busy on other projects, hobby in my spare time must be fun.

I hope we'll find a way to improve docs so it's 100% success each time someone new get started. Hopefully I think there are lot of people who already got success with MySensors and helping on the forum