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

Custom XNCP protocol commands #57

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

Conversation

puddly
Copy link
Collaborator

@puddly puddly commented May 3, 2024

  • EmberZNet filters traffic for multicast groups the coordinator is not explicitly a member of. This PR implements a packet filter to bypass this limitation.
  • Manually specifying source routes is not possible with EmberZNet. The firmware is customized to allow this.
  • Override the board and manufacturer names (with a custom command).
  • Support arbitrary version suffix strings.

To facilitate future firmware extensions and to allow applications communicating with the firmware to query these firmware extensions, I've implemented a simple protocol using EZSP's customFrame command.

@puddly puddly changed the title Multicast packet filter and custom XNCP protocol Custom XNCP protocol: wildcard multicast groups and manual source routing May 28, 2024
@puddly puddly force-pushed the puddly/packet-filter-multicast-extension branch from b3d2ef2 to e1e4123 Compare May 28, 2024 19:25
@MattWestb
Copy link

One PM: manually setting one source router is making problems if the rout is being broken and the network cant healing therefor its normally automatic or no source routing being used.

@puddly
Copy link
Collaborator Author

puddly commented May 28, 2024

Right now, sendUnicast in EmberZNet doesn't let you specify a source route when sending a packet, unlike Z-Stack and deCONZ. For Z-Stack with zigpy-znp, I use source routing as one of the retrying methods in case normal routing fails. I would like to use it the same with with bellows so that this logic can be moved into zigpy.

For zigpy's source routing, we assume symmetry and just use the last-taken route from a device as the source route when sending to the device. This can definitely be improved (speculative routing, randomization, better discovery, etc.).

@puddly
Copy link
Collaborator Author

puddly commented May 29, 2024

New feature for firmware builders: overriding the board name. This uses a custom XNCP command so it will require support in bellows but it will allow you to override the firmware name that is displayed within Home Assistant:

c_defines:
  XNCP_BOARD_NAME: '"My Board v1.0"'
  XNCP_MANUF_NAME: '"Some Manufacturer"'

Currently, the board and device name are stored in USERDATA as manufacturing tokens and cannot be easily rewritten.

@puddly puddly changed the title Custom XNCP protocol: wildcard multicast groups and manual source routing Custom XNCP protocol commands May 29, 2024
@puddly puddly force-pushed the puddly/packet-filter-multicast-extension branch from 625af16 to 0d19db4 Compare August 16, 2024 18:46
@puddly puddly marked this pull request as ready for review August 16, 2024 18:52
@puddly
Copy link
Collaborator Author

puddly commented Aug 16, 2024

The bellows side of this is done, just needs unit tests (zigpy/bellows#611).

@evelant
Copy link

evelant commented Aug 26, 2024

@puddly Is there an easy way to build this for the sonoff-e dongle as well? I'm wondering if it might help with the group command issues in home-assistant/core#86411 edit: sorry I meant zbdongle-e, I always get them mixed up

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