Thank you so much for your support

@jaydenlord Probably you do. If you leave the EN floating, electrical noise could cause it to enable or disable randomly. Some enable pin require a HIGH, some LOW. Connect it to VCC to see if it works more consistently. If it doesn't detect, connect it to GND. If one of these works, then the part wasn't designed to be in a default state of enable. Let us know your results (I found this video OSD

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]

Are you still able to use the same analog phone plugged into the back of your modem? If so then it has to still use the same protocol, and I don't understand why the analog beacon wouldn't still work. It would just have to be on that same wire, not on the internet side of the modem. The modem is doing all of the translation in that case. Or am I missing something? Did you have to get a new phone to use the new service?

Welcome - I hope you find it inspiring, educational and practical. There is lots to learn and more to achieve.

@mfalkvidd I got what you mean. Yes, I am using the tcp connection using the mySensors serial API, not the USB<>UART serial interface ;-) I am running a gateway with the nRF24 at 1Mpbs for the fast & furious sensors (mainly energy meters); another at 250kbps for the battery supplied nodes (temp/hum and door sensors); another one at 1Mbps dedicated to the actuators / mission critical. 60 nodes running Another on is a BLE<>Mysensors bridge between the Mopeka Tank Pro (2) and the TPMS (4) Another one is a fauxmo<>Mysensors bridge. A few esp32 based displays (round oled, 3.5", 7") :-)

@Eme Thank you for coming back to report how you solved your problem! Your comments will help other people. I am a big fan of Frugal Tech and I think MySensors is great for that. Alas, MySensors is not well supported anymore. Right now I'm having problems linking to the home page :( It's people like you and me that will keep MySensors going. Thanks for your help. OSD

@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

I don't have a good answer for you @mimaret :( When I get to the point where I'm getting strange error messages, I bite the bullet and start from ground zero. Fortunately, with the RPi you just need a new SD card. Start with a fresh copy of the Raspberry Pi OS. If you enable SSH (and WiFI) when you create the image, you can do everything headless (without keyboard-mouse-video) by running raspi-config via a remote terminal ( PuTTY ) If you enable VNC with raspi-config you can have access to the GUI. Double check your radio wiring. Don't have anything unnecessary plugged in. Carefully follow the instructions I've done this tedious process many times. My RPi's are 3B+ and Zero 2 W. Here's what I've encountered: bad power supply bad SD card bad wiring corrupt download and, of course, more user errors than I care to think about! I have not come across bad RPi ... no, not true! I had a Zero 2 W with a bad WiFi chip (common problem). Overcame that with a USB WiFi dongle. Good luck! Let us know what you discover. -OSD

@zookazim so sorry I haven't been on here in years. I actually left the IoT nodes for a while. I was running into so many issues. To answer your question... not sure if it's still required or even relevant.

hey, sorry for late reply. PR for mysensors is ready to be merged: https://github.com/mysensors/MySensors/pull/1570 next step is create PR in mysensors integration for home assistant. Best regards Mariusz

@Tmaster I think it writes better code than a lot of code I've seen, and the documentation is a lot better. The latter, of course, is because most coders don't document. :( some key elements: good statement of work -- Purpose of the Code is key (did you write that? Good job!). This will guide the AI to write what you want. descriptive variables good documentation code is independent of reading sensors up-to-down/down-to-up I spent a couple hours analyzing, researching and writing and re-writing this and all I can say is that the AI didn't catch is, as far as I can see, if your sensors are too far apart or your magnet is too weak, you could get false readings. You, being the author of AI directive, are responsible for for the code. The AI is just a tool. I started my coding with assembly language, though at that time we still had to enter the binary on some machines (set 16 switches, then press commit). ForTran and COBOL were the first real high level languages and subsequent languages, pascal, c, java, etc. were improvements. AI is a quantum step. It's still coding, but you have to learn how to talk to the AI to get what you want. Good project! Let us know how it turns out and if you had to tweak the code. -OSD

https://github.com/mysensors/MySensors/pull/1562 switches to using libgpiod instead of the earlier interface. I have not tested it myself but it looks good.

I think the comments you make are good. I do have a question about the removing the regulator. I assume you mean the 5V to 3.3V regulator. I connect to the 5V and I see lot of variation in moisture readings due to the variation in the output of the power supply (solar panel/stepdown). I have a calibration routine for that. The voltage can go as high as 4.2V, which I believe may be bad if I connect the power supply to 3.3V. Of course, this is not a concern if using two 1.5V batteries. With batteries, the moisture reading would be more consistent over a day. Lot of advantages there. I just don't like changing batteries and I really hate it when they leak. I have every reason to believe that my power supply will last 10 years and I am fortunate to live in a place with consistent sunshine :) . Someone replicating my project will have to take this into consideration. My design easily accommodates a different power supply. And my power supply could be used in other projects. Resistive vs Capacitive sensor. I'm glad you report good results. This gives people options. Water moisture: I've had good experience with "spraying" the Arduino with clear electronic coating and sealing the enclosure with liquid tape. -OSD

@mvader Turn the time delay adjustment preset on your PIR module to the minimum.. Now try it.. You will not get a continuous output..Also, prepare the circuit using a long wire from the back to the sensor of your module.

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

@nagelc said in New Setup for Home Environment Monitoring – Using NRF24L01+, Arduino Pro Mini, and BME280: bme280 I read somewhere that the temperature sensor on the BME280 is sort of an afterthought. I did a few experiments comparing them to the DHT11/12/22 and found them only a little better. (Take this with a grain of salt, maybe you'll want to do you're own experiments.) I did do a lot of experiments with the DHT's and they really suck. +/-2°C Which turns out to mean +/-2°C offset (component variation) and +/-2°C measurement: +/-4°C from what the temperature actually is. My experience, yours may be better. Please post your experience with OTA. I haven't tried it on Arduino's but it's awesome on ESP8266. I hesitate with Arduino's because I had some erratic behaviour running Arduino's when pushing the memory limit. I, too, use the MQTT data transport to Home Assistant (HA) and I find that excellent. Getting data from HA is a bit tricky, but do-able. I have a flow meter and use HA to store the last read; meaning, if there is a power failure, HA sends the last read on Arduino boot. I don't use the EEPROM because that has a spec of 100,000 writes which the meter would do in about a year, thus, necessitating a new Arduino. I truly appreciate you sharing. Thanks! -OSD