Hi, It seems that you are using ID 255 for your temp node, but ID's 0 and 255 are reserved for gateway id and broadcast. Also, if not using any controller, you should manually assingn ID to sensor nodes in a sketch, like that:

#define MY_NODE_ID 10

@karl261 said:

I am totally sick of these NRFs that all perform differently.

Same here! So I radically solved my problems with connectivity by moving to rfm69 radios. It took some time and effort to make 'adaptor' pcbs to connect rfm's to my existing nodes, especially for 5v nodes, as rfm's are not 5v tolerant and require voltage level converter. I don't have comprehensive statistics for now (finished switching only a few days ago), but even first tests gave stable communication range far beyond that I ever saw with nrf's

I observed similar problem with nodes communication, only in opposite direction, the gateway was fine but two of my nodes required MY_DEBUG enabled to function properly. One of them was completely unreachable without MY_DEBUG or a delay(10) in the loop(), and other node had big problems receiving data (a lot of fail's). I couldn't figure out where the problem was, my assumption is that it is some kind of timing problem, maybe the radio being polled to fast or something... and debug prints certainly add some time to code execution and that kinda solves the problem. But thats only my assumption, I may be completely wrong

Hi, It seems that you are using ID 255 for your temp node, but ID's 0 and 255 are reserved for gateway id and broadcast. Also, if not using any controller, you should manually assingn ID to sensor nodes in a sketch, like that:

#define MY_NODE_ID 10

@TimO I have 3 nodes (incl. gateway) with this level shifters running and don't see any problems so far. I recently switched all of my nodes from nrf's to rfm69's and had to make 'adaptor' pcb's to connect rfm's, for 3v nodes this 'adaptor' is trivial and for 5v nodes it uses 4ch level shifter from aliexpress. MISO, MOSI, SCK and NSS goes through shifter and D2(IRQ) pin connected directly

I observed similar problem with nodes communication, only in opposite direction, the gateway was fine but two of my nodes required MY_DEBUG enabled to function properly. One of them was completely unreachable without MY_DEBUG or a delay(10) in the loop(), and other node had big problems receiving data (a lot of fail's). I couldn't figure out where the problem was, my assumption is that it is some kind of timing problem, maybe the radio being polled to fast or something... and debug prints certainly add some time to code execution and that kinda solves the problem. But thats only my assumption, I may be completely wrong

@karl261 said:

I am totally sick of these NRFs that all perform differently.

Same here! So I radically solved my problems with connectivity by moving to rfm69 radios. It took some time and effort to make 'adaptor' pcbs to connect rfm's to my existing nodes, especially for 5v nodes, as rfm's are not 5v tolerant and require voltage level converter. I don't have comprehensive statistics for now (finished switching only a few days ago), but even first tests gave stable communication range far beyond that I ever saw with nrf's

@kk02067 it will work fine without presentation

I understand that. But is it possible to request data from another random node without doing any programming in the node thats being requested?

No, the node must have some code to catch incoming request and respond properly

And is it enough to keep the requesting node awake just the time to get the response?

Yes, it should be enough

I guess you can use this sensor_api_20#requesting-data to do what you want