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.

Sign up for GitHub

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

Jump to bottom

Processing of unsolicited Vendor Specific Messages fails #152

Closed
HaukeRa opened this issue Feb 3, 2019 · 1 comment
Closed

Processing of unsolicited Vendor Specific Messages fails #152

HaukeRa opened this issue Feb 3, 2019 · 1 comment

Comments

@HaukeRa
Copy link

HaukeRa commented Feb 3, 2019

Describe the bug
When receiving a vendor specific message, the 3-byte long opcode branch in DefaultNoOperationMessageState decides upon the cached mMeshMessage what to do with the incomming message.

This only works if we sent a message ourselves previouly that requires a direct answer. So only the first branch for VendorModelMessageAcked seems to work. When we send a VendorModelMessageUnacked we don't expect an answer so this branch is probably never taken.

Unsolicited vendor messages are never received because of this (or only if we coincidentally sent a VendorSpecific message right before we received a VendorSpecific message)

To Reproduce
Steps to reproduce the behavior:

  1. Configure vendor specific node to send unsolicited messages
  2. Make the node send a vendor specific message (e.g. with a button press)
  3. Vendor specific message is never handed to onMeshMessageReceived

Expected behavior
Vendor specific messages should be received, even if we didn't ask for it. Maybe for Vendor Specific messages it is impossible to say if it is acknowledged or not? I think its up to the entity who defined the message to decide upon the opCode if it is an acknowledged message or not.
@roshanrajaratnam
Copy link
Member

@HaukeRa What's the setup here? is the message sent from the app? if it's an unacknowledged message the app will not receive a message at all.

@roshanrajaratnam roshanrajaratnam mentioned this issue Mar 5, 2019
Merged
roshanrajaratnam added a commit that referenced this issue Mar 5, 2019
@roshanrajaratnam
Release v1.2.0 (#172)
f268d38 
* Fixes src and dest was swapped on LightLightness
*  Adds support for controlling groups. Previously this was done in each model configuration view but now model configuration will only allow sending messages to the unicast address itself.
* Fixes a documentation bug after renaming callbacks.
* All addresses now use ints instead of byte arrays.
* Fixes a bug relating to broken parcelable implementations
* Added an additional api to override default 5 second attention timer.
`identifyNode(@nonnull final UUID deviceUuid, final String nodeName, final int attentionTimer)`
* Moved bouncy castle insertion to MeshManagerApi.
* Adds support for multiple provisioning capabilities. This includes No OOB, Static OOB, Output OOB and Input OOB methods. Now the user is prompted to pick supported Authentication Method and Authentication action during the provisioning process.
  - 3 new APIs added 
    - `startProvisioningWithStaticOOB(@nonnull final UnprovisionedMeshNode unprovisionedMeshNode)`
    - `startProvisioningWithOutputOOB(@nonnull final UnprovisionedMeshNode unprovisionedMeshNode, final OutputOOBAction oobAction)`,  
    - `startProvisioningWithInputOOB(@nonnull final UnprovisionedMeshNode unprovisionedMeshNode, @nonnull final InputOOBAction oobAction)` 
  - Adds ConfigModelPublicationGet message
  - Adds support for importing and exporting json strings
  - Fixes a bug relating to vendor models in json serializer/deserializer when importing/exporting mesh networks.
* Fixes #152
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@roshanrajaratnam @HaukeRa