Is it possible to make the registration at the gateway non blocking, so the node can start processing other things and send messages when the gateway is reachable.
Use case:
A node that switches lights and is mounted behind a switch in the wall. For emergency situations it should always be possible to switch on the lights even when the gateway fails.
When the switch is pressed, the node notifies the gateway the lights are switched on or off. The lights can also be switched on or off via the gateway.

Hi Yveaux. To my opinion it is not necesarry for the library to do the buffering.
I'm looking for an option where the node enters void loop() even if there is no gateway when the node boots, so it can do things locally.
Because there is no gateway, it is not possible to send or receive messages. It is no problem if they get lost.
For the node a user can create a buffer for messages that should be reported when the nodes detects a gateway is available.
The function isTransportOK() can for instance be use to discover if a gateway is available.
So I think it is only necesarry to implement an option to enter void(loop) when no gateway is detected and periodically try to register to the gateway.

I have Z-wave modules (Fibaro) installed. The switches can be used without gateway.
When the gateway boots (I use Razzberry) it start detecting the nodes. I assume it it is up to the nodes to send the current state.
I agree that buffering messages is useless in most cases. A periodic update (initiated by the user program) is in my opinion the correct solution.

I tested my node with the "#define MY_TRANSPORT_WAIT_READY_MS 1" feature.
It seems to work fine!
Tnx for the work.

I tested my node with the "#define MY_TRANSPORT_WAIT_READY_MS 1" feature.
It seems to work fine!
Tnx for the work.

Great this option is available!
Is it possible to let the node use the last used parent, instead of configuring the parent?

I have Z-wave modules (Fibaro) installed. The switches can be used without gateway.
When the gateway boots (I use Razzberry) it start detecting the nodes. I assume it it is up to the nodes to send the current state.
I agree that buffering messages is useless in most cases. A periodic update (initiated by the user program) is in my opinion the correct solution.

Hi Yveaux. To my opinion it is not necesarry for the library to do the buffering.
I'm looking for an option where the node enters void loop() even if there is no gateway when the node boots, so it can do things locally.
Because there is no gateway, it is not possible to send or receive messages. It is no problem if they get lost.
For the node a user can create a buffer for messages that should be reported when the nodes detects a gateway is available.
The function isTransportOK() can for instance be use to discover if a gateway is available.
So I think it is only necesarry to implement an option to enter void(loop) when no gateway is detected and periodically try to register to the gateway.

Is it possible to make the registration at the gateway non blocking, so the node can start processing other things and send messages when the gateway is reachable.
Use case:
A node that switches lights and is mounted behind a switch in the wall. For emergency situations it should always be possible to switch on the lights even when the gateway fails.
When the switch is pressed, the node notifies the gateway the lights are switched on or off. The lights can also be switched on or off via the gateway.

I think the purpose of the V_VAR is interpreted in different ways. So it's sometimes hard to use V_VAR as configuration parameters.

E.g. In Domoticz V_VAR is used to store and restore node variables. They are stored in the Domoticz database when send by the node. The node can retrieve a previous stored value from the database. There is no easy way to set the variables. So V_VAR kan be used as remote permanent memory.

It would be nice if there was an implicit specification for configuration parameters.
A possible option could be:

• Extra message types for parameters:
  Type: set_parameter, Number: 5, Comment: Set configuration parameter.
  Type: req_parameter, Number: 6, Comment: Request configuration parameter.
• Extra subtypes for parameters:
  Type: P_SEND_RETRIEVE, Value:0, Comment: Trigger the node to send or retrieve all configuration parameters. 0=Retrieve, 1=Send.
  Type: P_PAR<number>, Value: <number>, Comment: Configuration parameter <number>
  The values of the parameters can be any type, like stefaanv suggests.
• Add functions:
  request_parameter, to handle retrieving parameters: void request_parameter (uint8_t childSensorId, uint8_t configParam, uint8_t destination);
  send_parameter, to handle sending paramters: bool send_parameter (MyMessage &msg, bool ack);

The idea behind P_SEND_RETRIEVE:
If a node receives a P_SEND_RETRIEVE message from the gateway with value 0, a routine can be triggered to request all configuration parameters one by one, using function request_parameter.
If a node receives a P_SEND_RETRIEVE message from the gateway with value 1, a routine can be triggered to send all configuration parameters one by one, using function send_parameter.