I have employed that exact same circuit with an an nRF24 radio in four places to turn on pumps. I power the Nano's through the USB with very cheap USB power adapter (less than 250mA@5V). When I had problems like you describe, it was the relay that had failed. These have been running for three years, in enclosures, outdoors.
The most common failure comes from switching too high of a current and the contacts fuse together. Again from too much current, the arcing caused a carbon build up on the contacts making the contact unreliable.
Because of your reference, I assume that you are using the relay board and that is what has failed.
The Nano will not drive the coil of a relay directly. I agree with @iguaan. That is why one uses the module: all the transistors, etc. are already built up for you.
Signaling the Nano with nRF24 radios is another rabbit hole. The radios being too close (<10cm) to each other could be the problem and reducing the antenna power may help.
I found that how you configure the software is very important. What I ended up doing was having a master control the flow of communication. That is, the master would send out a message to only one device and wait for the device to respond. Often the node would not respond (node did not receive message or master did not receive response) requiring the master to resend the message. The libraries should handle this, but seem to be insufficient. This is @electrik 's question. As an experiment, connect an LED in place of the relay.
Yes, I have had other problems, but they were usually the connector coming off the relay board or incorrect wiring. The only time the Nano was defective was after I had shorted the +5V to GND. (oops)
Keep at it, you'll get it to work.
To provide a large enough pulse to drive the ceramic transducer , you need a lot of energy, so they pump up the 5v with an inductor/transformer to provide a high voltage pulse. This is 60v or more…
The more Energy you produce the farther the pulse will travel….
Everything thing else on the board run at 3.3 to 5V.
Add a large Capacitor of 100 µF are so between the 5v and ground on the device, this may clean up your problem.. Some CPU modules just can’t supply enough current quick enough that’s needed when the pulse is triggered.
These are very inexpensive device, we’re luck to see them work at 1/2 the spec range.
Based on the quite useful reverse engineered schematic at https://hackaday.io/project/174308-tradfri-pir-motion-sensor-hacking the measurements were somewhat sabotaged by the 2N7002 (see Connors comment "enables voltage dividers only when triggered").
the transistor is controlled by the Elmos E931.96 PIR motion controller IC.
The latter is programmable by the IKEA TRÅDFRI ICC-1 module's EFR32MG1P132F256GM32 MCU.
2. Blind Time
Ignores motion after the interrupt output is switched back to 0
Range: 0.5s... 8s.
The blind time is [Register Value] *0.5s
3. Programmable pulse counter
1... 4 pulses with sign change in between
Amount of pulses = [Register Value] + 1
4. Window time
For noisy environments
2s... 8s window
Window time = [Register Value] * 2s + 2s
https://github.com/basilfx/TRADFRI-Hacking gives a good overview on that.
What is the issue with tose 60s?
I'm not really familiar with FHEM, but as far as the MySensors side, you still need the gateway software running. However, this code can run directly on a Raspberry Pi, at least with a radio network for the MySensors transport. I haven't ever used RS485 myself, but I would think it would be similar.
At least the code itself has sections for dealing with running on Linux, which is what is used when running it on the RPi, so I think you're good. https://github.com/mysensors/MySensors/blob/master/hal/transport/RS485/MyTransportRS485.cpp
The gateway code runs as a systemctl service, so it can easily run in parallel with most things, so probably wouldn't conflict with FHEM on the same device.
Oh yeah, and in case you haven't found it, there's this page: https://www.mysensors.org/build/rs485