-
Notifications
You must be signed in to change notification settings - Fork 38
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
Matter/Chip libraries in Maven #211
Comments
Hi Jon, Thanks for your interest and engagement with the sample! We're not planning to update We don’t want to incorporate the build process into the sample offering because supporting potential SDK build issues in different user environments is out of scope for this project. Here is one possible strategy to build new library versions in case it's helpful to you; you might incorporate a similar script into your project’s build process. Note the below was executed with Edit these to suit your environment # Input
chipvers=<Desired SDK hash>
destdir=<The /libs directory of your library in you android app project> Find a build container git clone https://github.com/project-chip/connectedhomeip.git
cd connectedhomeip
git checkout $chipvers
buildimage=$(cat .github/workflows/full-android.yaml | grep chip-build-android | head -n 1 | awk '{print $2}')
echo "Using $buildimage"
# Run the build container
docker run -it --rm \
--mount source=$(pwd),target=/workspace,type=bind \
--workdir="/workspace" \
$buildimage /bin/bash Within the container: # Execute build
chown -R $(whoami) /workspace
git submodule update -f --init --recursive
source ./scripts/bootstrap.sh
./scripts/build/build_examples.py \
--target android-arm-chip-tool \
--target android-arm64-chip-tool \
--target android-x86-chip-tool \
--target android-x64-chip-tool \
build
# Strip for size
ndkpath="$ANDROID_HOME/.."
ndktgt=$(ls -la $ndkpath | awk '{print $NF}' | sort -r | grep ndk | head -n 1)
ndkfq="$ndkpath/$ndktgt/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-strip"
builddir="/workspace/examples/android/CHIPTool/app/libs/"
echo "Using ndk at $ndkfq to strip .so"
find $builddir -name "*.so" | xargs $ndkfq Exit the container and copy libs to project tree srcdir="connectedhomeip/examples/android/CHIPTool/app/libs/"
cp -R $srcdir $destdir Then in your android lib’s Gradle config, you can simply reference the blobs like this sourceSets {
main {
jniLibs.srcDirs = ['libs/jniLibs']
}
} The topic of an official release exceeds the scope of this sample app project, but we will work to ensure your feedback is noted where relevant. |
@aBozowski We are trying to read our own MEI attributes and seems like we would need to regenerate the Matter lib, and we followed this guide. Do we still need to create the docker like quoted in order to generate
|
Using docker makes the build more reproducible but it is not required. It is also not required to rebuild the library in order to read MEI clusters. I use reporting to reading the devices. The custom attributes will get reported like normal attributes (AttributeState), but they don't get decoded. Example of manually decoding....
This is the same thing as writing XML for the cluster and then recompiling CHIP lib. I just did it manually to avoid maintaining a modified CHIP library. Same process works for writing attributes. It would really be useful to have a small tool which uses an IDL description of the cluster to generate the appropriate snippet of Kotlin or C++ but that tool does not exist as a standalone tool. Instead, just look at what ZAP does in the zzz directories and then build your version of it by hand. Once you write this code it rarely changes. |
It would be useful if this sample included an example of manually decoding a cluster. Note that you can manually decode the standard clusters too. AttributeState.tlv is there for every cluster you read. You can also access AttributeState.json to read/write in JSON format. |
@jonsmirl We are trying to implement Here's our attempt:
|
Look in the chip directory, there is subscribeToAttribute() and SubscriptionHelper() those can subscribe to any cluster MEI included. This will subscribe to everything:
|
We are successful implement onReport and onError based on readAttribute but NodeState getEndpointState() value is null , Do you have any ideas about what might be the cause of the problem? |
The source code to the Java/Kotlin libraries is in the CHIP tree. You can look at the source to see what is happening. |
It appears that the our custom cluster returns null while other default ones (like |
You need to decode the TLV on the AttributeState
|
@jonsmirl It appears that when I try to Whereas if I read an The problem is that since I get null for |
Look in your Android log and make sure your device is really reporting it. The reports are printed in detail in the logs. |
If I use wildcard then the log will not print out, if I define the clusterId of my custom cluster then I will see the CHIPTOOL JSON. We can confirm that the device is reporting it since we tested with CHIPTOOL and it is also printing the CHIPTOOL json in the log as well. |
The logs print all report messages from the devices. Search for where it reports the other clusters on that endpoint. You could have an error in the TLV. If there is an error it won't report in Android. But there will be a log message. |
Note I am using SubscriptionHelper and you are using something different. |
TLV encodes the data types in its headers. |
So this is not the JSON payload that prints out from chiptool but from your TLV decoder function? |
Somewhere down inside the Android library it is printing that. I don't know where. It is getting printed when the library decodes the TLV. |
@jonsmirl We are still having trouble reading the custom cluster ID, where did you put the subscribe or read attribute function in the Sample app? |
Note that each reportCallback is unique do you have to track one for each device.
|
https://central.sonatype.com/artifact/com.google.matter/matter-android-demo-sdk/versions
Is there a script to make this? I would find it more useful to have multiple versions of the artifact: Matter 1.0, Matter 1.1, Matter 1.2 and Matter Head. Can you see if the Google Matter developers will put up official build releases in Maven?
The text was updated successfully, but these errors were encountered: