General Discussion

@dbemowsk The serial API (=communication between controller and GW) doesn't distinguish between different transport technologies used in a specific GW. So it's not important if a GW is using nRF, RS485, RFM69, none or whatever else as a transceiver.

@pumpkinpi welcome to the forum! The flowcharts at https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help/ can probably be useful. You are correct that the radio wiring is ok since initialization works. You are incorrect that a few people has had to use a capacitor. Everyone has to. If not, problems will arise. Maybe not right away, sometimes people are just lucky and get the nodes partially working initially. But the nrf24 radios will fail sooner or later without a capacitor. I understand that the instructions on the radio wiring page weren't clear on this so I have adjusted them.

@smilvert Got it working: https://www.openhardware.io/view/510/Multi-Sensor-TempHumidityPIR-LeakMagnetLightAccel#tabs-source I cited you in the credits at the beginning of the sketch.

@NeverDie It looks to be what can be expected after googlin' a bit; e.g. https://openawg.github.io/2016/04/19/first-test-chamber-constructed.html Opening the freezer's door will further disturb things (did it stay closed in both charts?) Were both measurements aquired using the exact same si7021 sensor?

see here : https://www.eevblog.com/forum/eda/oshpark-plated-slots/

My thoughts were to do as follows..... In the garage have a sensor>pro-mini>lora to send signal long distance. Then more locally have lora>pro-mini>serial data out to sedond pro-mini2. Then from second pro-mini2 serial data in>pro-mini2>nrf24l01+>gateway. So 2 x pro-mini with a serial connection back-to-back as a relay. But now you have described the application in much more detail I would be tempted to just add a lora gw as it's less bother.

@madscientist The only limitation that I see is on the avatar, and that limitation is not in pixel size, but file size. [image: 0_1510899002155_upload-a2a4aa28-6092-407c-9d1e-eb23d093bacd] For the cover picture, I don't see any limitation.

Yes, as mentioned earlier in the thread. I think you're right, though, it would be easier and more practical. Then the problem reduces to mostly just a detection issue.

@Boots33 said in Experiences, problems and questions: @Nca78 have you got a link to the PA/LNA module from CDEByte , they sound interesting. This one : https://www.aliexpress.com/item/E01-ML01DP5-Ebyte-2-4GHz-20dBm-2100m-nRF24L01-SPI-Wireless-transceiver-module/32638720689.html I have one with IPX antenna too, and it works very well with a IPX=>SMA adapter and a SMA antenna outside of the enclosure https://www.aliexpress.com/item/2-4GHz-rf-Wireless-uhf-Module-Power-Amplifier-E01-ML01SP4-Original-SENET-1-8km-2-4g/32806320077.html

@Nelson-Nico my reply was not properly formatted, I fixed it. Read again, then get a bit deeper with the links given by @scalz ;)

Just for anyone following in the future. Looks like it might have been a dodgy USB cable. All is working well now. Thanks for looking.

This might not be a perfect answer, but: You may first try to analyse the Power Meter Pulse Sensor. It's quite easy to understand, what it does - despite it uses an interrupt service routine you may not need. This may be helpful to understand how communication between node and controller is organized and timing of data sending for non-sleeping modes can be achieved. You may then just put your code into this basis - just add your parts wrt. measuring and delete the not needed parts (or make them comment first). Some further remarks: There is the rather complex Rain Gauge sketch with a lot of options that may be confusing at first sight. This may already be prepared to do most things you may want to do. In Most cases, it's easier to do the statistics part on controller side and just let the nodes report small "snapshots". So resetting the counter and use an RTC is not necessary... I don't have the link at the moment, but there also exists a small example, how to combine sonsors. I also found this helpful to understand how to convert standard arduino code with MySensors functionality.

Thank you all for taking the time to reply. I will take a look at the documentation, but then realised I could just have one controller at a time running to test at first (doh!)... ;) - Still, this really is all about an end product that works for my needs with learning new stuff into the bargain. :) I'll let you know if I do need to try it - nice to know it's an option!

I was able to locate documentation from others who decoded the devices already. In truth, they are very simple as they only send 1 or 2 packets. Your thermostat presumably sends all kinds of info out and each packet could contain very different data. I may go back to my old code first and give it one more run since it really just needs ESP8266 and RFM69 compatibility added to it. That should be easier than porting the decode algorithm to either MySensors or another project. My original goal was to simply use OpenMQTTGateway with my added protocols and decoders. That didn't work well, so I've made no real progress.

@Yveaux Thanks, it helped me.