Hardware

You have three ways to for the gateway to communicate to Home Assistant (HA), serial, ethernet, and MQTT. It comes to this: A serial gateway will be in very close proximity to the HA Green. It is very simple to set up. ethernet or MQTT can be anywhere there is ethernet or WiFi, but not so simple to set up. The latter two require ethernet connectivity hardware added. This makes the configuration much more complicated and, if going this way, I'd recommend the RPi zero 2W with your radio of choice running Raspberry Pi OS as your gateway. The gateway software runs in the OS (I run this set up). The serial gateway is a wired connection to your HA Green and the HA Green would power it. The location of your HA Green/serial gateway probably take some experimentation. The downside is the range of your radio. Fortunately, with repeater nodes or nodes that also act as repeaters, too, this isn't too bad. I find the range, line-of-sight, no obstructions about 10m. Or, 3m through 1 wall. I am unfamiliar with Sensebender. Googling it I find one from Itead one from OpenHardware. I'm not finding much in the way of documentation. :( I am familiar with the RF-Nano (Arduino Nano compatible with nRF24 built in) and would offer much the same capabilities as the Sensbender. The range on the RF-Nano is a bit less than that of the stand-alone nRF24. The Nano is powered from the computer, though from what I can glean from the docs, the Sensebender would also require a serial-to-USB adapter (use 3V3 pin on adapter for power). This is amazingly simple hardware. The Nano gateway can also have sensors. This is very cool for me because I run HA in a virtual box under Ubuntu on a refurb PC. The serial gateway is a Nano compatible and I use it to "push" buttons on a remote. I'm not using a radio at all. Essentially the Nano and MySensors gateway software gives me I/O ports for my pc. Let us know how your project goes.

You might want to try sensors for volatile organic compounds (VOCs). They can be quite effective at picking up unwanted smoke.

nice! I'm happy that there is another radio to use

As we all know, the nRF24 works pretty well, but there is a lot of device-to-device variation. This would be a nice thing to have when debugging the network. @juliefen will you be creating a github project with schematic, board layout, code, construction tips, theory of operation, calibration and operating manual, examples, etc.?

Can't give you a 100% answer. I've noticed with FETS I sometimes have a low leak Voltage. But I've seen Chinese designs that gave a negative voltage when the FET was turned off haha

I have learned the hard way, many times, "If it's not broken, don't fix it". MySensors fills a niche, very low power, very low cost, sensors (albeit, DIY). The range is about the same as Bluetooth. The data is usually a boolean or an integer. So let us not say, abanddoned but at a development plateau. A mature technology that still has legs.

@monte thank you for that one. Although almost 2.5 times the price it's cheaper than other European options.

Quick update: i wanted to hide and protect the Nano in a housing. Aliexpress supplies very nice enclosures that fits on Din rails. https://fr.aliexpress.com/item/1005005505247992.html They fit in electrical cabinets thanks to standard dimensions. [image: 1771086807073-a.png] [image: 1771086818359-b.png] One 3Dprinted part later (glued inside enclosure) and the Arduino is safely held in place! [image: 1771086835896-c.png] [image: 1771086853317-d.png] [image: 1771086860801-5.png] stl file of adapter : dinRailEnclosureMountForNano-revE.stl

@ben999 Yes I have 3 gateways 1 nfrf and 1 rm for production. And 1 nrf gw for test. The test gw is on a separare PI I might run a 4th gw. Also an rfm on the test machine.

I’ve had similar trouble with the LGT RF Nano — the radio part is a bit picky. What fixed it for me was lowering the data rate in the sketch and giving it a proper capacitor on VCC (even a small 4.7µF helped a lot). Also worth trying a different CE/CSN pin setup; these clones don’t always match the “standard” wiring perfectly. After that mine started talking to the gateway without any drama.

I learned my lessons about bread boards. Slowly replacing my cheap AliExpress ones with good quality ones. I blew up 2 nano's and 1 nrf this week because of a bad breadboard

Hello I still didn't figure it out exactly, what is the issue with LGT8F328P and arduino, but for start, it can work, if you define 4x faster baud rate. So I define MY_BAUD_RATE 76800 and connect terminal with 19200, and it works. LGT is started in 8 MHz by default, and it looks like this is not corrected with mysensors. But this only helped for serial port, because later I had issues with DHT library timings. If I later change speed to 16 MHz and start serial port again, it works as expected: noInterrupts(); CLKPR = 0x80; CLKPR = 0x01; interrupts(); Serial.begin(19200);

as I experienced, MQ sensors are not really gaz sensitive, they are more particle size sensitive when hot enough and when not totally scrap. I would not rely my life on them, if you have an alcool spray use it around and any MQ will to go the sky...

Hi everyone, bumping this thread because I could read some of you were interested in packet loss (@NeverDie and someone else) and my findings could help fix it partially or completely via software. It's certainly a hardware problem, though I can't figure out if it's due to the components physical positioning, the power supply, or both (and/or more issues like wiring, proper PCB traces, etc). Also, even the same modules from the same manufacturer, say EByte E01 PA+LNA modules in my case, have shown different performances, so it might be something bound to the variability of the SMD components used as well. Let's get straight to the point. I am the developer of rf24tunlink, a radio network bridge which uses primarily nRF24 modules. During R&D, I found that around 30% of packets from my modules were dropped due to a couple corrupted bytes, which was constant even in close range. That does indicate a hardware problem already, but the distribution of the bit flips is an even stronger indicator. [image: eb505750-d741-45b2-aba1-57d26913c786] All flips are in the first bytes! You might be getting at least one flip in most packets, resulting in ALL of them being dropped automatically because this invalidates the CRC. In this scenario ShockBurst can fail, or you might get duplicates, might not get ACK payloads or simply get a slow link because the same packet can be sent up to 15 times with a wait between each retry. Not coming here unarmed: how to fix it? Easy in principle, you: Disable CRC -> ShockBurst off, no ACK payloads, essentially your module will be RX only. Implement RS ECC: sacrifice just enough bytes to fix all the corrupted bytes. (in my case, 2/32 was enough!) That's how I turned a 30% packet loss into a 100% flawless reception, see this result: [image: 43bcccb9-9b9d-4ae8-ac4b-c9ed1f8fc320] There is more to it, as the link gets worse, of course this situation also gets worse. Finding out how many errors are in a packet can help you estimate signal quality and potentially take preventive measures. Now, if you only care about sending a specific packet, you either receive it or not at all and that's it. But if you want more like I did, then things get more complicated. In this case I wanted a full duplex link -> a second pair of nRF24 modules was mandatory I also wanted to send network data (iperf, ping, ssh, realtime video, audio, telemetry, control, anything really) -> frames needed to be split into radio packets, sent, corrected and stitched back into a frame. That is a HARQ algorithm. After all of this, I could get a usable network speed of 1.2Mbps (determined via iperf). Used a Pi 4, Pi zero 2 W and 4 nRF24 PA+LNA modules. You could use this same metric to evaluate your components, some modules could do better and some could do worse. Would be cool to fix this hardware for all and get closer to that 2Mbps max speed. Some people declared a speed of 1.7Mbps and I have seen a 1.5Mbps peak during development, so there is definitely room for improvement. [image: 1bd38d37-7a09-49e1-b92b-7d0838d1c436]

@OldSurferDude Thanks! I didn't touch the Arduino IDE for a while and forgot that the MYSBootloader doesn't come included in the Mysensor's library... My bad. Thanks for the link! I should had searched first... I use the OTA feature since 2017... It works well. So well that I forgot how to load the bootloader... Regards!

Check out My Projects to see what can be done. Then decide what you want to do. Come back here for help -OSD

Gawd bless ya @OldSurferDude , that just about answered every question I have to date, I especially thank you for indicating whether the item named is a software or hardware product. On reading into the Cerbo GX capabilities I was very impressed with its sophistication and, just as you said, I will have to break the complicated parts down into bite-sized pieces and build from there. It started with an idea for a project, essentially to take data on battery state of charge (SoC) from the Cerbo GX and use an Arduino Nano or ESP8266 to build a strategy so that I would have sufficient hot water in the morning, consistent with having enough battery power left in the evening. Only on further inspection did it occur that the Node Red software built into the Cerbo GX could do this for me...and thus the possibility that a wireless hot water temperature sensor (transducer) could be fabricated to feed that data into the Cerbo GX; hence my path to here. I've dabbled in programming in C, mainly through the Arduino IDE, and in a previous life part of my work involved programming PLCs for industrial automation, so I am somewhat familiar with 'tech', but I lost interest once most systems seemed to go Windows based. In the intervening years the 'tech' has moved on apace and has left me behind, which is why I've struggled to follow the jargon, akin to trying to fit the second piece in a large jigsaw puzzle. Once the fundamentals are there I'll catch on. So please, kind contributors, be tolerant of the silly questions we newbies ask, we won't always be newbies, and I'll be back for sensors stuff once I've tamed the red-hot node and sorted out my LBQTTs Best wishes....MM