I recently bought cheap long range nRF24L01+PA+LNA radios from Aliexpress. I had good success with the other radios I bought but went with a different supplier this time. The units I bought are the YJ-15008+PA units from Keyes (as printed on the PCB).

But then when I tried to use the radios I realized there is something wrong. One peculiar thing was that when you touch the radio's PA it works. After some debugging and reading other forums I found that the CE pin on the radio header is not connected to the nRF24L01 chip. I had to do a wire mod to connect these and the problem disappeared. I guess when touching the radio while the software is waiting for the MAX_RT or TX_DS bits to be asserted during a transmission, you "trigger" the TX enable on the PA chip and the transmission happens.

I have seen quite a few threads in different forums regarding the fake cheap Chinese radios with the same behavior (touching starts the transmission etc.) so I am posting this just in case someone using MySensors is struggling. The usual answer people give is related to filtering the power and eliminating noise etc. I believe these are valid arguments for increasing range but if the software hangs (using a simple RF24 GettingStarted example for instance) this is most probably your problem! Hope this helps someone!

@tekka Thanks tekka, have it sorted now! Any idea why I can't reset my nodes from the MYSController? (!TX).

Ok, so I reverted everything to the previous version of the MYSBootloader and the previous version of the MYSController. First time I tried I could assign firmware and do the OTA update.
I then updated the bootloader to the latest version and OTA still worked. I then opened the latest version of the MYSController and guess what, I can assign firmware.

SO what did I do? I made sure all files int he MYSController directory was read/write enabled. Was this the problem? I have no idea and clearly no-one else either.

OK, OTA works with MYSController 0.1.2.282, it has the assign firmware in the context menu. But the latest version 1.0.0beta no way. Can't figure out how to assign the firmware.

This is probably a stupid question but why can't I assign firmware to my node in MYScontroller?

I use a Pro Mini 16MHz with the MYSBootloaderV13pre.hex burned and MYScontroller_1_0_0beta.

In the context menu of the node I don't get the assign option:

I can see the bootloader is communicating with my gateway (RPI Ethernet gateway) and in the controller.

mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:PNG:SEND,TO=0
mysgw: TSF:CKU:OK
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=1,l=0,sg=0:255
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:PNG:SEND,TO=0
mysgw: TSF:CKU:OK
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=1,l=0,sg=0:255
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:PNG:SEND,TO=0
mysgw: TSF:CKU:OK
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102
mysgw: TSF:MSG:READ,1-1-0,s=255,c=4,t=0,pt=6,l=10,sg=0:FFFFFFFF0800DCEF0102

The controller log looks as follows:

1/23/2017 19:07:58	INFO	BL version=258
1/23/2017 19:07:58	INFO	No FW assigned
1/23/2017 19:08:01	RX	1;255;4;0;0;FFFFFFFF0800DCEF0102
1/23/2017 19:08:01	DEBUG	Undefined firmware/type for node=1
1/23/2017 19:08:01	INFO	BL version=258
1/23/2017 19:08:01	INFO	No FW assigned
1/23/2017 19:08:05	RX	1;255;4;0;0;FFFFFFFF0800DCEF0102
1/23/2017 19:08:05	DEBUG	Undefined firmware/type for node=1
1/23/2017 19:08:05	INFO	BL version=258
1/23/2017 19:08:05	INFO	No FW assigned
1/23/2017 19:08:16	RX	1;255;4;0;0;FFFFFFFF0800DCEF0102
1/23/2017 19:08:16	DEBUG	Undefined firmware/type for node=1
1/23/2017 19:08:16	INFO	BL version=258
1/23/2017 19:08:16	INFO	No FW assigned
1/23/2017 19:08:19	RX	1;255;4;0;0;FFFFFFFF0800DCEF0102
1/23/2017 19:08:19	DEBUG	Undefined firmware/type for node=1
1/23/2017 19:08:19	INFO	BL version=258
1/23/2017 19:08:19	INFO	No FW assigned
1/23/2017 19:08:22	RX	1;255;4;0;0;FFFFFFFF0800DCEF0102
1/23/2017 19:08:22	DEBUG	Undefined firmware/type for node=1
1/23/2017 19:08:22	INFO	BL version=258
1/23/2017 19:08:22	INFO	No FW assigned

Somewhere I am missing something simple. Please help. I see that when I request info on the node it states the firmware updates are not allowed.

What I am aiming for is a Domoticz controller using an MQTT Ethernet gateway running on a RPI with Pro Mini (8MHz and 16Mhz) nodes using nRF24L01 radios. All this I can get running, no problem. The question is how do I deploy OTA firmware updates.

I know Domoticz does not support OTA. MYScontroller does but not via MQTT. MyController does but does it support MQTT and is it a viable alternative to Domoticz?

Currently my thinking is to have a completely separate Ethernet or Serial Arduino Gateway to be used only for OTA. When I need to do firmware updates I will have to disconnect the RPI MQTT Gateway and fire up the dedicated gateway to do the OTA updates with MYScontroller.

Does this makes sense or is there a better way??

@Coffeesnob I had exactly that and it turned out that my radio was faulty. Do you have any spare radio's? The other thing I did to improve the situation was adding an LC filter on the power as well as running the radio's from their own supplies, not from the 3.3v on the mega or Nanos.

I suggest first use external power for the radios. Directly from the supply a 3.3v regulator and large decoupling cap. If you want you can add an LC filter as well for high frequency filtering (25kHz to 50kHz). If that does not fix things stop out the radios. If you have another nano/mini try to replace the mega. I had problems getting my mega to work as well.

@esawyja My opinion, radio directly from psu and 3.3v regulator and yes, decouple the radio with capacitor.

@Mark-Swift Hi Mark,l. No sorry, no link with instructions but should you have these units or the same problem, send me an email address and I can mail you the pictures I took and explain what I did.

I recently bought cheap long range nRF24L01+PA+LNA radios from Aliexpress. I had good success with the other radios I bought but went with a different supplier this time. The units I bought are the YJ-15008+PA units from Keyes (as printed on the PCB).

But then when I tried to use the radios I realized there is something wrong. One peculiar thing was that when you touch the radio's PA it works. After some debugging and reading other forums I found that the CE pin on the radio header is not connected to the nRF24L01 chip. I had to do a wire mod to connect these and the problem disappeared. I guess when touching the radio while the software is waiting for the MAX_RT or TX_DS bits to be asserted during a transmission, you "trigger" the TX enable on the PA chip and the transmission happens.

I have seen quite a few threads in different forums regarding the fake cheap Chinese radios with the same behavior (touching starts the transmission etc.) so I am posting this just in case someone using MySensors is struggling. The usual answer people give is related to filtering the power and eliminating noise etc. I believe these are valid arguments for increasing range but if the software hangs (using a simple RF24 GettingStarted example for instance) this is most probably your problem! Hope this helps someone!