You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since version 7.1.0, more and more issues are popping up regarding missing reports from devices. It is on our radar and we might finally have a solution for once and all. Please don't open any new issues regarding this, as they only cause noise.
A little background
So called unsolicited updates (that weren't requested by zwave-js) are sent by devices via associations - usually the "Lifeline". The Z-Wave specifications do a terrible job at explaining how these should be configured and used, so as a result, most manufacturers got it wrong. Missing updates are usually caused by incorrect associations or devices that send incorrect or ambiguous reports or simply devices that are unnecessarily using endpoints.
There are (what feels like) 20 different ways to configure these associations to the controller, all of them very dependent on the actual device that should be configured. But only a handful of variations can be automatically decided on, so it is more likely that we get it wrong than right.
When a device sent us a report via the root device, we used to guess which endpoint that report was supposed to come from. No matter how we changed the guessing strategy, some use cases were broken. Our plan going forward is to detect when endpoints are unnecessary and should be ignored - as opposed to ignoring the root device when there are any endpoints like we do now.
This should massively reduce our chances to get the associations wrong, remove the need to make these guesses and make the remaining edge cases easier to handle.
Notes to self/thoughts/todo list
New default behavior
If all endpoints have different device classes
ignore the endpoints and work only with the root device
do not set up multi channel associations, set up a node lifeline association on the root device
This needs a compat flag to opt out and restore the current behavior:
"preserveEndpoints": "*", // to preserve all endpoints"preserveEndpoints": [2, 3], // to preserve endpoints 2 and 3, but ignore endpoint 1. There are some thermostats which expose an external sensor with battery through a seemingly unnecessary endpoint, but it needs to be preserved
If some endpoints share a device class
ignore the root device's application CCs (current behavior), opt out possible with preserveRootApplicationCCValueIDs
Try to set up normal lifeline associations on each endpoint separately, fall back to multi channel associations on each endpoint, then fall back to the current behavior of a multi channel association to endpoint 0 on the root device
The lifeline association strategy should be controllable with the multiChannel flag in the association config. New default: "auto", true forces a multi channel association (if possible), false forces a node association (if possible)
This needs a compat flag to define which endpoint the root reports should be mapped to (for devices like the FGS-222, which work half)
Since version 7.1.0, more and more issues are popping up regarding missing reports from devices. It is on our radar and we might finally have a solution for once and all. Please don't open any new issues regarding this, as they only cause noise.
A little background
So called unsolicited updates (that weren't requested by
zwave-js
) are sent by devices via associations - usually the "Lifeline". The Z-Wave specifications do a terrible job at explaining how these should be configured and used, so as a result, most manufacturers got it wrong. Missing updates are usually caused by incorrect associations or devices that send incorrect or ambiguous reports or simply devices that are unnecessarily using endpoints.There are (what feels like) 20 different ways to configure these associations to the controller, all of them very dependent on the actual device that should be configured. But only a handful of variations can be automatically decided on, so it is more likely that we get it wrong than right.
When a device sent us a report via the root device, we used to guess which endpoint that report was supposed to come from. No matter how we changed the guessing strategy, some use cases were broken. Our plan going forward is to detect when endpoints are unnecessary and should be ignored - as opposed to ignoring the root device when there are any endpoints like we do now.
This should massively reduce our chances to get the associations wrong, remove the need to make these guesses and make the remaining edge cases easier to handle.
Notes to self/thoughts/todo list
New default behavior
If all endpoints have different device classes
This needs a compat flag to opt out and restore the current behavior:
If some endpoints share a device class
preserveRootApplicationCCValueIDs
The lifeline association strategy should be controllable with the
multiChannel
flag in the association config. New default:"auto"
,true
forces a multi channel association (if possible),false
forces a node association (if possible)This needs a compat flag to define which endpoint the root reports should be mapped to (for devices like the FGS-222, which work half)
Related: #1989
The text was updated successfully, but these errors were encountered: