Assume that the Generic Level State is 0 and the following Generic Level Set message is received by a node.
Level: 0x7FFF
Tid: 1
Delay: 0xFF (1275 ms)
Transition time: 0x00
That is, set the Generic Level State to 0x7FFF after a delay of 1275 ms without a linear transition.
A reasonable response from the node would be
Present Level: 0
Target Level: 0x7FFF
Remaining time: 0x00
The current SDK For Mesh 4.2.0 doesn't allow sending such messages as it does the following in generic_level_server.c
static uint32_t status_send(generic_level_server_t * p_server,
const access_message_rx_t * p_message,
const generic_level_status_params_t * p_params)
{
generic_level_status_msg_pkt_t msg_pkt;
msg_pkt.present_level = p_params->present_level;
if (p_params->remaining_time_ms > 0)
{
msg_pkt.target_level = p_params->target_level;
msg_pkt.remaining_time = model_transition_time_encode(p_params->remaining_time_ms);
}
access_message_tx_t reply =
{
.opcode = ACCESS_OPCODE_SIG(GENERIC_LEVEL_OPCODE_STATUS),
.p_buffer = (const uint8_t *) &msg_pkt,
.length = p_params->remaining_time_ms > 0 ? GENERIC_LEVEL_STATUS_MAXLEN : GENERIC_LEVEL_STATUS_MINLEN,
.force_segmented = p_server->settings.force_segmented,
.transmic_size = p_server->settings.transmic_size
};
Note line 18 where the length of the message depends on remaining_time_ms > 0 and thus the message will only include the Present Level field which is 0 and indicate to the caller that there is not transition in progress which is not true. This same type of code is present in other status sending functions as well.
At first glance a more reasonable check would be to compare the present_level and target_level fields to determine what to include in the status message. However, that is not without issue either as can be seen by the following example.
Again, assume that the Generic OnOff State is 1 and its state is bound to the Generic Power Actual according to the rules in 3.1.5.1.2 of the Mesh Specification, the Generic Power Default state is > 0 and different from the Generic Power Actual state. When the following Generic OnOff Set message is received by a node
OnOff: 1
Tid: 2
Delay: 0xFF (1275 ms)
Transition time: 0x00
That is, set the Generic OnOff State to 1 after a delay of 1275 ms without a linear transition. This message will cause the Generic Power Actual state to transition from it's current state to the value given by Generic Power Default state instantly after the delay.
A reasonable Generic OnOff Status message in response from the node would be
Present OnOff: 1
Target OnOff: 1
Remaining time: 0x00
While it might be enough to compare the present and target fields for Generic Level Status message, it's not enough for the Generic OnOff Status message.
The reason I picked Generic OnOff Server as an example is due to the following text in Generic Level State behaviour that doesn't exist in Generic OnOff State behaviour.
From 3.3.2.2.2 Receiving Generic Level Set / Generic Level Set Unacknowledged messages
"If the target state is equal to the current state, the transition shall not be started and is considered complete."
On the other hand in 3.3.1.2.3 Sending a Generic OnOff Status message specifies when to include the Target OnOff and Remaining Time fields
"... If the Generic OnOff Server is in the process of changing the Generic OnOff state, ...
This opens for the discussion if the Generic OnOff State is considered "changing" when it's set to the same value causing bound states to change.
If the state is not considered changing in this example, a response to a Generic Power Actual Get message during the 1275 ms delay would indicate that a transition is indeed ongoing but the response to the Generic OnOff Set indicate that it's not, giving conflicting answers. Perhaps that is fine by the specification.
What would be the expected behaviour?
Thanks.
