Original question:
Linux: CC2652 : Zigbee Linux Sensor to Cloud Setup 1.0.0 failed on ubuntu-18.04.1-desktop-amd64
Tool/software: Linux
Relating this thread:
I kindly ask what is the OS used into the RPI3 model B (stretch?).
Thank!
Ok I've did a little step, the ZNP now is working properly, I've to change the serial port ttyACM0 directly inside the configuration file that is into the folder:
/home/source/ERROR__out/Precompiled/servers
so for my RPI3B+ stretch the correct port is ttyACM0 and not ttyUSB0 as shown into the forum (may be the installation was not for stretch?).
Then the log now is the following:
root@raspberrypi:/home/source/Projects/node# sudo ./start_local.sh Starting the Linux Zigbee Gateway Platform type selected automatically as bbb. To override this selection, please stop this script, and then run it again, specifying the desired platform type at the command line: ./zigbeeHAgw [help | bbb | x86 ] running ./zigbeeHAgw on an ARM done processing arguments, board type bbb, target arm NPI is 'NPI_lnx_arm_server' Zstack linux server is 'ZLSZNP_arm' gateway server is 'GATEWAY_SRVR_arm' network manager is 'NWKMGR_SRVR_arm' OTA server is 'OTA_SRVR_arm' Starting the ZigBee gateway subsystem making sure there are no lingering servers... there are 0 NPI servers there are 0 ZLS servers there are 0 GATEWAY servers there are 0 NWKMGR servers there are 0 OTA servers (total 0) done Executing reset from external scripts =================================================== starting NPI, cmd ' ./NPI_lnx_arm_server NPI_Gateway.cfg -v 0x0000010E ' on Thu 4 Jul 10:09:46 CEST 2019 [10:09:46.937,114] [NPISRVR/MAIN] UNMSKBL: [10:09:46.937,560] [NPISRVR/MAIN] UNMSKBL: ************************************************ [10:09:46.937,593] [NPISRVR/MAIN] UNMSKBL: * NPI Server v1.0.2d * [10:09:46.937,620] [NPISRVR/MAIN] UNMSKBL: ************************************************ [10:09:46.937,645] [NPISRVR/MAIN] UNMSKBL: Startup phase 1 completed successfully, server started (NPI_PID=10210) on Thu 4 Jul 10:09:46 CEST 2019 =================================================== starting ZLSZNP, cmd ' ./ZLSZNP_arm 127.0.0.1:2533 config.ini -v 0x0000460E ' on Thu 4 Jul 10:09:46 CEST 2019 ./ZLSZNP_arm: error while loading shared libraries: libprotobuf-c.so.0: cannot open shared object file: No such file or directory Startup phase 2 failed
Inside the /usr/lib the lib file is till present:
To be sure about library path the file /etc/ld.so.conf.d/libc.conf was edited as below (added the /usr/lib path):
# libc default configuration
/usr/local/lib
/usr/lib
may be this issue related the release version of the libprotobuf-c.so.0 that in my version is instead libprotobuf-c.so.1 ?
Actually the protobuf-c-compiler installed release was the following one:
root@raspberrypi:/home/source/Projects/node# dpkg -s protobuf-c-compiler Package: protobuf-c-compiler Status: install ok installed Priority: optional Section: devel Installed-Size: 189 Maintainer: Robert Edmonds <edmonds@debian.org> Architecture: armhf Multi-Arch: foreign Source: protobuf-c Version: 1.2.1-2 Depends: libc6 (>= 2.4), libgcc1 (>= 1:3.5), libprotobuf10, libprotoc10, libstdc++6 (>= 5.2) Description: Protocol Buffers C compiler (protobuf-c) Protocol Buffers are a flexible, efficient, automated mechanism for serializing structured data - similar to XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format. . This is the "protobuf-c" implementation of Protocol Buffers in C. . This package contains the "protoc-c" code generator that creates C stubs from Protocol Buffers .proto files. These stubs must be compiled and linked against the libprotobuf-c support library. Homepage: https://github.com/protobuf-c/protobuf-c
Thank.
Hi @YK Chen,
the step I've used is the same as my test with the zc_switch design, the log from Wireshark seems correct and is here attached.
Just some note about the Log, at the packet 1069 the ligh bulb send the Association Request, at packet 1085 the ZC send to the bulb the Transport Key, then on 1200 the ZC ask for the Active Endpoint Request and in 1204 the Light Bulb send the related responce, on 1206 there is the Simple Descriptor Request and related response from the Ligh Bulb is at 1210 so I think that all the protocol is managed properly.
The difference, I think, is that inside my initial experiment with the zc_switch example ( e2e.ti.com/.../3016844 ) I made the binding only by looking if the On/Off input cluster (0x0006) was discovered. Now, with this application (the Linux Gateway), I think that the system try to know what type of device is joining the network by looking at the Device Type regarding the cluster type that may be into the device itself (and of course this is the correct way to indentify a device), hence if this Device Type is not recognized the light bulb is not managed because considered as a invalid device regarding the presence or not of the On/Off cluster.
To solve I think that we have to find a way to expand the supported device type in order to let also this type of devices, classified as "Color temperature light (0x0220)" being managed from the system when we did this we will also able to manage other device and then expand the range of the supported device.
Following this idea I've did a text search through the source files with the string "Device Type Not Recognized", this bring me on this source file:
C:\ti\Zigbee_3_0_Linux_Gateway_1_0_1\source\Projects\node\nodejs_zb_gateway\devices\device.js
opening it the interesting function is the "function createDevType(nwkmgr, ieee, simpleDesc)" that is responsible for properly understanding the device type, the strange things is that either the simpleDesc.profileId and the simpleDesc.deviceId was properly identified, in fact into the "Device Type Not Recognized" message we have the correct profileId and deviceId so I don't understand why the check fail and the device is not properly recognised...
To check if the execution is correct I've did a simple console.log just inside the two if section into the function createDevType(nwkmgr, ieee, simpleDesc) function:
...
}
//ZLL profile
else if(simpleDesc.profileId === ZBL.ZB_PROFILE_ID.LIGHT_LINK)
{
console.log("ZLL profile found...");
//ZLL Dimmalbe Light
if(simpleDesc.deviceId === ZBL.ZLL_DEVICE_ID.DIMMABLE_LIGHT)
{
return new LightDevice(nwkmgr, ieee, simpleDesc.endpointId, "DimmableLight");
}
//ZLL Color Light
if(simpleDesc.deviceId === ZBL.ZLL_DEVICE_ID.COLOR_LIGHT)
{
return new LightDevice(nwkmgr, ieee, simpleDesc.endpointId, "ColorLight");
}
//ZLL Extended Color Light
if(simpleDesc.deviceId === ZBL.ZLL_DEVICE_ID.EXTENDED_COLOR_LIGHT)
{
return new LightDevice(nwkmgr, ieee, simpleDesc.endpointId, "ColorLight");
}
...
and into the output log I can see effectively the ZLL profile found... message so the execution is correct until this point... and seems trhat I've to add another definition because the only that was managed are the following ones:
DIMMABLE_LIGHT: 0x0100
COLOR_LIGHT: 0x0200
EXTENDED_COLOR_LIGHT: 0x0210
and I need also to add the COLOR_TEMPERATURE_LIGHT: 0x0220 extension...
making this code adding at the /Projects/node/nodejs_zb_gateway/devices/devices.js file:
I'm able to correctly recognise the device and drive it from the web page:
So next step is see how integrate other not really supported ZED devices like smart power outlet...
P.S.
About the *_arm compilation issue I think that the problem was mainly somethings wrong inside the RPi (may be the gcc compiler release or other stuff that will be investigated) but for sure cross compilation has an undeniable advantage of the compilation speed, just some seconds to perform the compilation instead long time directly inside the RPi.
Thank.
