Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete notification_types_node when there are no supported notification types #25

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

monikasoni
Copy link

Change

When the notification frame of the command class contains more than two bit masks, the SUPPORTED_NOTIFICATION_TYPES node stays undefined. Consequently, the ZPC (Z-Wave Protocol Controller) makes repeated attempts to retrieve the supported notification type from the device. This continuous loop causes the device to remain in an "Online interviewing" state for an extended period.

zwave frame

71 08 03 00 00 40

attribute store

(350) Supported Notification Types ........................ <undefined> (<>)

Logs

2023-Nov-28 13:25:19.410614 [attribute_resolver] Attribute ID 83 needs a Get
2023-Nov-28 13:25:19.411275 [attribute_resolver] Retransmitting Get command for Attribute ID 83 (attempt 4 out of 5)

2023-Nov-28 13:25:22.265804 [zwave_command_handler_callbacks] Dispatching incoming command (encapsulation 3) from NodeID 5:0 - [ 71 08 03 00 00 40 ]
2023-Nov-28 13:25:22.266390 [zwave_command_class_notification] Supported notification types Bit Masks length is wrong

2023-Nov-28 13:25:30.952589 [attribute_resolver] Attribute ID 83 needs a Get
2023-Nov-28 13:25:30.953289 [attribute_resolver] Retransmitting Get command for Attribute ID 83 (attempt 5 out of 5)

2023-Nov-28 13:25:33.824015 [zwave_command_handler_callbacks] Dispatching incoming command (encapsulation 3) from NodeID 5:0 - [ 71 08 03 00 00 40 ]
2023-Nov-28 13:25:33.824700 [zwave_command_class_notification] Supported notification types Bit Masks length is wrong

Checklist

@@ -354,6 +354,23 @@ static sl_status_t
= attribute_store_get_first_child_by_type(
ep_node,
ATTRIBUTE(SUPPORTED_NOTIFICATION_TYPES));
// Delete notification_types_node when there are no supported notification types.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious, wouldnt it be possible to avoid creation of node instead of remove it ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Node is created away ahead in the inclusion process. I am not sure if it is feasible to avoid creation.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue was more that the variable length bitmask was not processed correctly, and therefore the supported type was not populated correctly.
It was fixed in 1.5.0.

Note that this solution does not feel right, you are "removing the device functionality" by erasing the supported types... and there is still a risk that this SUPPORTED_NOTIFICATION_TYPES attribute get re-spawned at each system restart by zwave_command_class_notification_on_version_attribute_update()

I'd suggest to close this PR.

@rzr
Copy link
Collaborator

rzr commented Jan 15, 2024

Please rebase on main to make sure it's building

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants