Basically when the sensor sends the data to the controller you can have it send the same data to the LCD. That would most likely provide a longer battery life than requesting the data from the sensors. Doing it this way only the LCD (and the controller) have to be on all the time.

void incomingMessage(const MyMessage &message) {
  // We only expect one type of message from controller. But we better check anyway.
  if (message.type==V_LIGHT) {} 
}

The attributes are defined in MyMessage.h, "sender" would be the node requesting.

uint8_t last;            	 // 8 bit - Id of last node this message passed
uint8_t sender;          	 // 8 bit - Id of sender node (origin)
uint8_t destination;     	 // 8 bit - Id of destination node
uint8_t version_length;      // 3 bit - Protocol version
			                     // 5 bit - Length of payload
uint8_t command_ack_payload; // 3 bit - Command type
	                             // 1 bit - Request an ack - Indicator that receiver should send an ack back.
								 // 1 bit - Is ack messsage - Indicator that this is the actual ack message.
	                             // 3 bit - Payload data type
uint8_t type;            	 // 8 bit - Type varies depending on command
uint8_t sensor;          	 // 8 bit - Id of sensor that this message concerns.

You can request values directly from another sensors for your LCD sensor node, but it's better to send LCD text data directly from controller to LCD node. Requesting data directly from another nodes is not very good choice, because of this nodes must not use deep sleep (so must not be battery powered).

If you wake-up and push the data from the sensor to the LCD node, it would be no more power-consuming than transmitting to gateway, all messages go through the gateway anyway.

My LCD node contains two 2004 LCD displays and receives text data for every display line from controller. But I'm using my own perl script as controller.