Just to save future confusion, LoRa is not technically the same as LoRaWAN. You can use LoRa to communicate directly between devices using your own protocols (haven't done this myself, but look at the Ping Pong example).
LoRaWAN defines a protocol over the top of LoRa that involves a gateway, a network server, an application server, and an application "in the cloud".
I am pretty sure you are using LoRaWAN based your references to the EndNode example and to device classes.
Class A devices only receive data during one of two RX windows following a TX. So, a node transmits, and 2 seconds later will listen for a downlink. If none is received, it will listen again one second later.
Class B nodes have scheduled receive windows associated based on a beacon signal.
Class C nodes are in listen mode when not actually transmitting. These have the highest power use.
Assuming you have two class A nodes, the latency will be long:
1. Node X sends button press uplink to gateway
2. Gateway sends it to Network server -> Application Server -> your application code.
3. Your application code queues a downlink message to Node Y.
4. At some time, Node Y sends an uplink and, a couple of seconds later, the Rx window opens and the queued downlink message arrives. LED turns on.
This is not a complete nor totally accurate view of what happens, but the point is that you have really no control over the latency with Class A nodes - this is actually the point as they are intended to be ultra low power and do things in their own sweet time.
Class B supposedly requires the gateway has a GPS time source.
Class C is the simplest but highest power as it doesn't sleep.
You still have round trip latency via the LoRaWAN software suite and whatever application logic you are running.
If your intention is to communicate directly between the boards, then LoRaWAN is not the solution you want and you need to dig into LoRa directly - again, see the Ping Pong example code.
