tlaukkan / zigbee4java Goto Github PK
View Code? Open in Web Editor NEWZigbee API for Java provides simple Java interface to ZigBee network.
License: Apache License 2.0
Zigbee API for Java provides simple Java interface to ZigBee network.
License: Apache License 2.0
Hello :)
i tried to run zig4java console with eclipse in windows 10 but the application crash even if all the other configurations are well ( dongle, firmware, args ).
the crash occur when the step of creation of zigbee network is begin ! the reason is : sendSynchrouns(hwDriver, request, RESEND_TIMEOUT) = null
whereas when i run the same program in eclipse using a ubuttu machines the program run well and the console of the application is running . the value of sendSynchrouns(hwDriver, request, RESEND_TIMEOUT) in this case is :
sendSynchrouns(hwDriver, request, RESEND_TIMEOUT) = ZB_WRITE_CONFIGURATION_RSP{Status=SUCCESS(0)}
hope that helps someone :)
I notice that with the refactored console, the COM port speed is now running at 38400 where it was previously running at 115k2. I've noticed a lot of errors in the past day or so - I initially put this down to the new firmware (I updated to the latest stack) but I'm not wondering if it's related to the speed. If I run my application (which runs at 115) it works ok until I start the console - then bad stuff starts (timeouts, various network addressing errors, failure to reset the stick). I've only tried this a couple of times, but it seems if I change the console to 115200 again, this goes away.
@chris-hatton - I'm guessing that you refactored this (but I've not checked). Was this a conscious change or did it 'creep' in?
This might not be the cause of my problem, but for sure the console speed has changed - just not sure if it's right?
Cheers
Chris
Is there any way to detect and pair with this light, without first knowing its MAC address?
I can put the device in pairing mode (it blinks to indicate) but issuing 'listen' on the zigbee4java console never produces a result.
Do I need to re-flash the CC2531 with Packet Sniffing firmware and use Ti RF Studio software to packet sniff and first retrieve the MAC Address of my light devices (I have several)?
Even if so, is there another way?
How would this work on a large scale ZigBee installation - it seems unwieldy if all MAC addresses need to be known ahead of time. If possible, shouldn't some deeper scanning and pairing functionality be included in zigbee4java?
Thanks, I have been unable to do any testing until now because of my lack of knowledge on the above. I have ordered a second CC2531 as advised by the documentation.
https://github.com/tlaukkan/zigbee4java/blob/master/settings.gradle#L16 should not include ':zigbee-console-android' as it would be included on line 28 if the "zigbee4javaProfiles" contain "android".
I'm interested in discussing splitting out the COM port from the library to allow other coordinators to be used. I see @chris-hatton is doing something similar in his fork.
Is this something that is of interest? I think it makes sense to define an interface, and then (somehow) pass this as an argument into the API initialisation. The question is what is the most appropriate place to put this interface such that it will work with 'any' coordinator.
I'm not familiar enough (yet!) with ZigBee to know what other interfaces are available, and therefore where is best to define such an interface. I'm guessing it's at a higher level than the COM port level.
I know ZB4O has a similar concept with their OSGi interfaces, so maybe the interface can easily be defined at the same level
I think this would be a good route for the library but I'm interested in your thoughts. Since there's only a few people working on this it would be good to try and maintain a common codebase if possible so we can benefit from each others bug fixes.
I'm trying to build the project, and yes I did look at the faq, maybe I missing something, I don't know..
:zigbee-console-common:classes
:zigbee-console-common:jar
:zigbee-serial-android:compileLint
:zigbee-serial-android:copyReleaseLint UP-TO-DATE
:zigbee-serial-android:mergeReleaseProguardFiles UP-TO-DATE
:zigbee-serial-android:preBuild UP-TO-DATE
:zigbee-serial-android:preReleaseBuild UP-TO-DATE
:zigbee-serial-android:checkReleaseManifest
:zigbee-serial-android:prepareReleaseDependencies
:zigbee-serial-android:compileReleaseAidl
:zigbee-serial-android:compileReleaseRenderscript
:zigbee-serial-android:generateReleaseBuildConfig
:zigbee-serial-android:generateReleaseAssets UP-TO-DATE
:zigbee-serial-android:mergeReleaseAssets
:zigbee-serial-android:generateReleaseResValues UP-TO-DATE
:zigbee-serial-android:generateReleaseResources
:zigbee-serial-android:packageReleaseResources
:zigbee-serial-android:processReleaseManifest
:zigbee-serial-android:processReleaseResources FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':zigbee-serial-android:processReleaseResources'.
> A problem occurred starting process 'command '/home/developer/opt/android-sdk-linux/build-tools/21.1.2/aapt''
* Try:
Run with --info or --debug option to get more log output.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':zigbee-serial-android:processReleaseResources'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:305)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:23)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:88)
at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:29)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at org.gradle.execution.DefaultBuildExecuter.access$200(DefaultBuildExecuter.java:23)
at org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:68)
at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:55)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:149)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:106)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:80)
at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:36)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:171)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:237)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:210)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:206)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:30)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:56)
Caused by: org.gradle.process.internal.ExecException: A problem occurred starting process 'command '/home/developer/opt/android-sdk-linux/build-tools/21.1.2/aapt''
at org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:196)
at org.gradle.process.internal.DefaultExecHandle.failed(DefaultExecHandle.java:325)
at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:83)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
Caused by: net.rubygrapefruit.platform.NativeException: Could not start '/home/developer/opt/android-sdk-linux/build-tools/21.1.2/aapt'
at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:27)
at net.rubygrapefruit.platform.internal.WrapperProcessLauncher.start(WrapperProcessLauncher.java:36)
at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:65)
... 1 more
Caused by: java.io.IOException: Cannot run program "/home/developer/opt/android-sdk-linux/build-tools/21.1.2/aapt" (in directory "/home/developer/workspace/zigbee4java/zigbee-serial-android"): error=2, No such file or directory
at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
... 3 more
Caused by: java.io.IOException: error=2, No such file or directory
... 4 more
BUILD FAILED
If binding or subscribing is already done or device is broadcasting then it should be possible to add only report listener to attribute.
Which would be good USB connected ZigBee controller devices to integrate to zigbee4java?
What are software design options to support multiple devices with completely different serial interfaces or another integration technology altogether considering current implementation approach?
This is an example of the timeouts I'm currently seeing. This isn't the only error, but it's one I captured in the console and will try and investigate -:
on 0
17:41:46 291 DEBUG Sending EmptyPayloadCommand command to 00:17:88:01:00:DC:88:0B/11 (#19281).
17:41:46 291 DEBUG Skipped to registered 00:17:88:01:00:DC:88:0B/11 as org.bubblecloud.zigbee.network.ApplicationFrameworkMessageListener
17:41:46 292 DEBUG -> AF_DATA_REQUEST (Packet: length = 13, apiId = 0x24 0x01, full data = 0xfe 0x0d 0x24 0x01 0x51 0x4b 0x0b 0x01 0x06 0x00 0x07 0x00 0x00 0x03 0x01 0x06 0x01 0x3c, checksum = 0x3c, error = false, errorMessage = null)
17:41:46 303 DEBUG <- AF_DATA_SRSP (AF_DATA_SRSP{Status=SUCCESS(0)})
17:41:46 309 DEBUG <-- AF_DATA_CONFIRM (AF_DATA_CONFIRM{Endpoint=1, Status=SUCCESS(0), TransID=158})
17:41:46 326 DEBUG <-- AF_INCOMING_MSG (Packet: length = 25, apiId = 0x44 0x81, full data = 0xfe 0x19 0x44 0x81 0x00 0x00 0x06 0x00 0x51 0x4b 0x0b 0x01 0x00 0x17 0x00 0xfd 0xa9 0xa6 0x00 0x00 0x05 0x18 0x06 0x0b 0x01 0x00 0x51 0x4b 0x1d 0x39, checksum = 0x39, error = false, errorMessage = null)
17:41:46 326 DEBUG Received AF_INCOMING_MSG from 19281 and cluster 6 to end point 1. Data: Packet: length = 25, apiId = 0x44 0x81, full data = 0xfe 0x19 0x44 0x81 0x00 0x00 0x06 0x00 0x51 0x4b 0x0b 0x01 0x00 0x17 0x00 0xfd 0xa9 0xa6 0x00 0x00 0x05 0x18 0x06 0x0b 0x01 0x00 0x51 0x4b 0x1d 0x39, checksum = 0x39, error = false, errorMessage = null
17:41:46 326 DEBUG AF_INCOMING_MSG arrived for 00:17:88:01:00:DC:88:0B/11 message is Packet: length = 25, apiId = 0x44 0x81, full data = 0xfe 0x19 0x44 0x81 0x00 0x00 0x06 0x00 0x51 0x4b 0x0b 0x01 0x00 0x17 0x00 0xfd 0xa9 0xa6 0x00 0x00 0x05 0x18 0x06 0x0b 0x01 0x00 0x51 0x4b 0x1d 0x39, checksum = 0x39, error = false, errorMessage = null
17:41:46 327 DEBUG Skipped unregistration of 00:17:88:01:00:DC:88:0B/11 as org.bubblecloud.zigbee.network.ApplicationFrameworkMessageListener
17:41:46 328 DEBUG Received response [ ZCL Header: 0x18 0x06 0x0b, ZCL Payload: 0x01 0x00] to request [ ZCL Header: 0x01 0x06 0x01, ZCL Payload: ]
I think this is the end of the transaction - the interesting thing (I think) is that it skipped the unregistration of the message listener - why?
Next it does what I assume is a routine network inspection - I don't think this is relevant, but I've left it in to complete the log...
> 17:41:47 024 DEBUG Network browsing completed, waiting until 1428943307011
17:41:47 024 DEBUG Inspecting ZigBee network for new nodes.
17:41:47 025 DEBUG -> ZDO_IEEE_ADDR_REQ (Packet: length = 4, apiId = 0x25 0x01, full data = 0xfe 0x04 0x25 0x01 0x00 0x00 0x00 0x00 0x20, checksum = 0x20, error = false, errorMessage = null)
17:41:47 031 DEBUG <- ZDO_IEEE_ADDR_REQ_SRSP (ZDO_IEEE_ADDR_REQ_SRSP{Status=SUCCESS(0)})
17:41:47 040 DEBUG <-- ZDO_IEEE_ADDR_RSP (ZDO_IEEE_ADDR_RSP{AssocDevList=[], assocDevList=[], IEEEAddr=0x00 0x12 0x4b 0x00 0x02 0xf1 0xdb 0x5b, nwkAddr=0x00 0x00, NumAssocDev=0, SrcAddress=null, SrcAddrMode=0, StartIndex=0, Status=SUCCESS(0)})
17:41:47 040 DEBUG ZDO_IEEE_ADDR_RSP from 0x00 0x12 0x4b 0x00 0x02 0xf1 0xdb 0x5b with 0 associated
17:41:47 040 DEBUG -> ZB_GET_DEVICE_INFO (Packet: length = 1, apiId = 0x26 0x06, full data = 0xfe 0x01 0x26 0x06 0x06 0x27, checksum = 0x27, error = false, errorMessage = null)
17:41:47 044 DEBUG <- ZB_GET_DEVICE_INFO_RSP (Packet: length = 9, apiId = 0x66 0x06, full data = 0xfe 0x09 0x66 0x06 0x06 0x01 0x00 0x01 0x80 0x00 0xeb 0x00 0x00 0x04, checksum = 0x04, error = false, errorMessage = null)
17:41:47 044 DEBUG ZDO_MGMT_LQI_REQ to 0 from index 0
17:41:47 044 DEBUG Inspecting device 00:12:4B:00:02:F1:DB:5B.
17:41:47 044 DEBUG Endpoint inspection completed, next inspection slot in 0
17:41:47 045 DEBUG -> ZDO_MGMT_LQI_REQ (Packet: length = 3, apiId = 0x25 0x31, full data = 0xfe 0x03 0x25 0x31 0x00 0x00 0x00 0x17, checksum = 0x17, error = false, errorMessage = null)
17:41:47 051 DEBUG <- ZDO_MGMT_LQI_REQ_SRSP (ZDO_MGMT_LQI_REQ_SRSP{Status=SUCCESS(0)})
17:41:47 059 DEBUG <-- ZDO_MGMT_LQI_RSP (ZDO_MGMT_LQI_RSP{NeighborLQICount=1, NeighborLQIEntries=1, NeighborLqiList=[org.bubblecloud.zigbee.network.packet.zdo.ZDO_MGMT_LQI_RSP$NeighborLqiListItemClass@7f861456], SrcAddress=0x00 0x00, StartIndex=0, Status=SUCCESS(0)})
17:41:47 059 DEBUG Found 1 neighbors on node 0
17:41:47 059 DEBUG Node #19281 visible from node #0 with LQI value 24
17:41:47 059 DEBUG -> ZDO_IEEE_ADDR_REQ (Packet: length = 4, apiId = 0x25 0x01, full data = 0xfe 0x04 0x25 0x01 0x51 0x4b 0x00 0x00 0x3a, checksum = 0x3a, error = false, errorMessage = null)
17:41:47 069 DEBUG <- ZDO_IEEE_ADDR_REQ_SRSP (ZDO_IEEE_ADDR_REQ_SRSP{Status=SUCCESS(0)})
17:41:47 104 DEBUG <-- ZDO_IEEE_ADDR_RSP (ZDO_IEEE_ADDR_RSP{AssocDevList=[], assocDevList=[], IEEEAddr=0x00 0x17 0x88 0x01 0x00 0xdc 0x88 0x0b, nwkAddr=0x4b 0x51, NumAssocDev=0, SrcAddress=null, SrcAddrMode=0, StartIndex=0, Status=SUCCESS(0)})
17:41:47 104 DEBUG ZDO_IEEE_ADDR_RSP from 0x00 0x17 0x88 0x01 0x00 0xdc 0x88 0x0b with 0 associated
17:41:47 106 DEBUG -> ZB_GET_DEVICE_INFO (Packet: length = 1, apiId = 0x26 0x06, full data = 0xfe 0x01 0x26 0x06 0x06 0x27, checksum = 0x27, error = false, errorMessage = null)
17:41:47 109 DEBUG <- ZB_GET_DEVICE_INFO_RSP (Packet: length = 9, apiId = 0x66 0x06, full data = 0xfe 0x09 0x66 0x06 0x06 0x01 0x00 0x00 0x00 0x00 0x80 0x00 0x2b 0xc5, checksum = 0xc5, error = false, errorMessage = null)
17:41:47 109 DEBUG Node #19281 is 00:17:88:01:00:DC:88:0B
17:41:47 109 DEBUG Inspecting device 00:17:88:01:00:DC:88:0B.
17:41:47 109 DEBUG ZDO_MGMT_LQI_REQ to 19281 from index 0
17:41:47 110 DEBUG Endpoint inspection completed, next inspection slot in 0
17:41:47 110 DEBUG -> ZDO_MGMT_LQI_REQ (Packet: length = 3, apiId = 0x25 0x31, full data = 0xfe 0x03 0x25 0x31 0x51 0x4b 0x00 0x0d, checksum = 0x0d, error = false, errorMessage = null)
17:41:47 120 DEBUG <- ZDO_MGMT_LQI_REQ_SRSP (ZDO_MGMT_LQI_REQ_SRSP{Status=SUCCESS(0)})
17:41:47 152 DEBUG <-- ZDO_MGMT_LQI_RSP (ZDO_MGMT_LQI_RSP{NeighborLQICount=1, NeighborLQIEntries=2, NeighborLqiList=[org.bubblecloud.zigbee.network.packet.zdo.ZDO_MGMT_LQI_RSP$NeighborLqiListItemClass@4c0147e3], SrcAddress=0x4b 0x51, StartIndex=0, Status=SUCCESS(0)})
17:41:47 153 DEBUG Found 1 neighbors on node 19281
17:41:47 153 DEBUG Node #0 visible from node #19281 with LQI value 247
17:41:47 154 DEBUG -> ZDO_IEEE_ADDR_REQ (Packet: length = 4, apiId = 0x25 0x01, full data = 0xfe 0x04 0x25 0x01 0x00 0x00 0x00 0x00 0x20, checksum = 0x20, error = false, errorMessage = null)
17:41:47 160 DEBUG <- ZDO_IEEE_ADDR_REQ_SRSP (ZDO_IEEE_ADDR_REQ_SRSP{Status=SUCCESS(0)})
17:41:47 168 DEBUG <-- ZDO_IEEE_ADDR_RSP (ZDO_IEEE_ADDR_RSP{AssocDevList=[], assocDevList=[], IEEEAddr=0x00 0x12 0x4b 0x00 0x02 0xf1 0xdb 0x5b, nwkAddr=0x00 0x00, NumAssocDev=0, SrcAddress=null, SrcAddrMode=0, StartIndex=0, Status=SUCCESS(0)})
17:41:47 168 DEBUG ZDO_IEEE_ADDR_RSP from 0x00 0x12 0x4b 0x00 0x02 0xf1 0xdb 0x5b with 0 associated
17:41:47 168 DEBUG -> ZB_GET_DEVICE_INFO (Packet: length = 1, apiId = 0x26 0x06, full data = 0xfe 0x01 0x26 0x06 0x06 0x27, checksum = 0x27, error = false, errorMessage = null)
17:41:47 171 DEBUG <- ZB_GET_DEVICE_INFO_RSP (Packet: length = 9, apiId = 0x66 0x06, full data = 0xfe 0x09 0x66 0x06 0x06 0x01 0x00 0x01 0x80 0x00 0xef 0x00 0x00 0x00, checksum = 0x00, error = false, errorMessage = null)
17:41:47 172 DEBUG Node #0 is 00:12:4B:00:02:F1:DB:5B
17:41:47 172 DEBUG Node 0 inspected few seconds ago, request delayed
And then I turn the light off...
off 0
17:41:54 421 DEBUG Sending EmptyPayloadCommand command to 00:17:88:01:00:DC:88:0B/11 (#19281).
17:41:54 421 DEBUG Skipped to registered 00:17:88:01:00:DC:88:0B/11 as org.bubblecloud.zigbee.network.ApplicationFrameworkMessageListener
17:41:54 423 DEBUG -> AF_DATA_REQUEST (Packet: length = 13, apiId = 0x24 0x01, full data = 0xfe 0x0d 0x24 0x01 0x51 0x4b 0x0b 0x01 0x06 0x00 0x08 0x00 0x00 0x03 0x01 0x07 0x00 0x33, checksum = 0x33, error = false, errorMessage = null)
17:41:54 434 DEBUG <- AF_DATA_SRSP (AF_DATA_SRSP{Status=SUCCESS(0)})
17:41:54 442 DEBUG <-- AF_DATA_CONFIRM (AF_DATA_CONFIRM{Endpoint=1, Status=SUCCESS(0), TransID=167})
17:41:54 458 DEBUG <-- AF_INCOMING_MSG (Packet: length = 25, apiId = 0x44 0x81, full data = 0xfe 0x19 0x44 0x81 0x00 0x00 0x06 0x00 0x51 0x4b 0x0b 0x01 0x00 0x17 0x00 0x42 0x0d 0xa7 0x00 0x00 0x05 0x18 0x07 0x0b 0x00 0x00 0x51 0x4b 0x1d 0x23, checksum = 0x23, error = false, errorMessage = null)
17:41:54 458 DEBUG Received AF_INCOMING_MSG from 19281 and cluster 6 to end point 1. Data: Packet: length = 25, apiId = 0x44 0x81, full data = 0xfe 0x19 0x44 0x81 0x00 0x00 0x06 0x00 0x51 0x4b 0x0b 0x01 0x00 0x17 0x00 0x42 0x0d 0xa7 0x00 0x00 0x05 0x18 0x07 0x0b 0x00 0x00 0x51 0x4b 0x1d 0x23, checksum = 0x23, error = false, errorMessage = null
17:41:54 460 DEBUG AF_INCOMING_MSG arrived for 00:17:88:01:00:DC:88:0B/11 message is Packet: length = 25, apiId = 0x44 0x81, full data = 0xfe 0x19 0x44 0x81 0x00 0x00 0x06 0x00 0x51 0x4b 0x0b 0x01 0x00 0x17 0x00 0x42 0x0d 0xa7 0x00 0x00 0x05 0x18 0x07 0x0b 0x00 0x00 0x51 0x4b 0x1d 0x23, checksum = 0x23, error = false, errorMessage = null
17:41:59 445 DEBUG Unregistered 00:17:88:01:00:DC:88:0B/11 as org.bubblecloud.zigbee.network.ApplicationFrameworkMessageListener
> org.bubblecloud.zigbee.api.ZigBeeDeviceException: org.bubblecloud.zigbee.api.cluster.impl.api.core.ZigBeeClusterException: org.bubblecloud.zigbee.network.impl.ZigBeeBasedriverTimeOutException: Timeout expired before receiving any data
at org.bubblecloud.zigbee.api.cluster.impl.OnOffImpl.off(OnOffImpl.java:82)
at org.bubblecloud.zigbee.ZigBeeConsole$OffCommand.process(ZigBeeConsole.java:777)
at org.bubblecloud.zigbee.ZigBeeConsole.executeCommand(ZigBeeConsole.java:215)
at org.bubblecloud.zigbee.ZigBeeConsole.processInputLine(ZigBeeConsole.java:190)
at org.bubblecloud.zigbee.ZigBeeConsole.start(ZigBeeConsole.java:166)
at org.bubblecloud.zigbee.ZigBeeConsoleJavaSE.main(ZigBeeConsoleJavaSE.java:34)
Caused by: org.bubblecloud.zigbee.api.cluster.impl.api.core.ZigBeeClusterException: org.bubblecloud.zigbee.network.impl.ZigBeeBasedriverTimeOutException: Timeout expired before receiving any data
at org.bubblecloud.zigbee.api.cluster.impl.core.ZCLClusterBase.invoke(ZCLClusterBase.java:119)
at org.bubblecloud.zigbee.api.cluster.impl.core.ZCLClusterBase.invoke(ZCLClusterBase.java:96)
at org.bubblecloud.zigbee.api.cluster.impl.general.OnOffCluster.off(OnOffCluster.java:94)
at org.bubblecloud.zigbee.api.cluster.impl.OnOffImpl.off(OnOffImpl.java:78)
... 5 more
Caused by: org.bubblecloud.zigbee.network.impl.ZigBeeBasedriverTimeOutException: Timeout expired before receiving any data
at org.bubblecloud.zigbee.network.impl.ZigBeeEndpointImpl.invoke(ZigBeeEndpointImpl.java:379)
at org.bubblecloud.zigbee.api.cluster.impl.core.ZCLClusterBase.invoke(ZCLClusterBase.java:114)
... 8 more
Here I get a timeout, even though the response is received ok (apparently). I suspect that this is because there are now two message listeners since the first one wasn't unregistered. One of the two listeners is receiving the response (presumably the first one that wasn't unregistered), and the other (presumably the second) times out!
Endpoint in org.bubblecloud.zigbee.network.impl.ZigBeeEndpointImpl is defined as a byte. My Hue bulb reports two endpoints (which I'm yet to work out) - one is currently showing as -14, which presumably should show 242?
I'll likely change this to short - just logging it here so I don't forget.
Anyone know how to reverse this?
While this doesn't appear to happen with all battery devices, I have a Develco occupancy sensor - I can communicate with this fine initially, but if I do a request after it stops listening, I get a timeout (expected) and subsequently I get the NO ROUTE error - even when I put the sensor back into identify mode...
Any thoughts appreciated...
The "read" method is blocking in the thread "ZToolPacketParser". Thus, "parserThread.join()" might be blocked during closing of "ZToolPacketParser".
Tested on the current head version eaf7129.
org.bubblecloud.zigbee.api.cluster.general
contains clusters that belong to other ctegories, for example the IlluminanceLevelSensing
cluster belongs to the Measurement and Sensing
category.
A refactor is going to break the current API (see also #70)
Hi there.
A couple of days ago, I started to play with this great project and a netvox zigbee device.
I found what seems to be a little bug in the bindTo method of the ZigBeeEndpointImpl class.
When you are building the ZDO_BIND_REQ packet, the last parameter is declared as BindDstEP , but you are sending is endpoint.getDeviceTypeId().
I think this is a bug, as it should be sending endpoint.getEndPointAddress().
I will try to send a patch for your consideration.
Thanks you very much for your time and work.
Regards!!!!
I'm occasionally seeing errors when the binding starts where it can't initialise the dongle. I've not looked into this in detail yet but it seems that the dongle doesn't respond to the reset request within the 5 seconds.
I'll look at this further, but just raising an issue in case anyone else has this problem...
It seems that the library often (nearly always?) hangs on closing at the following point -:
/**
* Requests parser thread to shutdown.
*/
public void close() {
this.close = true;
try {
parserThread.interrupt();
parserThread.join();
} catch (InterruptedException e) {
logger.warn("Interrupted in packet parser thread shutdown join.");
}
}
Presumably the parserThread doesn't quit and it locks at the join
.
@chris-hatton, @cdjackson, @presslab-us
Cool stuff for winners. Would be nice to have some participants in the challenge with zigbee4java used in android device for example. I am trying to figure some nice idea myself. 3D printer would be handy household device to have at home ,):
Will this API work with XBee device like http://www.adafruit.com/products/967?
The deviceUpdated callback is called after every inspection of a node, even if the node hasn't been 'updated' (unless it's a new node).
In my mind, it shouldn't call deviceUpdated unless something has changed. Currently the stack checks to see if the address has changed, and if it has it does a re-inspection of the endpoints - this is when I think it should call deviceUpdated.
Do others agree? I'll make a PR for this and you can decide :)
ApplicationFrameworkLayer.createDefaultSendingEndPoint() registers 3 endpoints, apparently without any real reason.
The code is weird too because it iterates over a set of 34 clusters and registers as many endpoints as needed (i.e. 3 endpoints) each with 16 clusters as inputs and outputs (the third only contains 2 clusters).
Also, each endpoint is registered specifying a device ID=0 in the Home Automation Profile which is the On/Off Switch in the HA specification.
I believe this default registration should not be hardcoded in the ApplicationFrameworkLayer and delegated to the application (e.g. the ZigBeeConsole).
Hint: the HA Combined Interface described in the HA spec could be a better choice.
Ciao,
Cristiano
I have seen serial port error today which suddenly manifested today on my windows 10 development workstation. Several reconnects of the dongle and reboot did not resolve this repeating issue on zigbee4java startup. It seemed to appear by chance and finally disappear similarly after a dongle reconnect. If anyone else is seeing this with genuine TI dongle then please report it here. There has been some changes in USB serial port implementation with windows 10 and this may require fixes with our serial port implementation.
C:\Users\tlaukkan\Development\projects\zigbee4java\zigbee-console-javase>java -jar target/zigbee-console-javase-2.0.3-SNAPSHOT.jar COM5 11 4951 false
ZigBee API starting up...10:01:23 442 INFO Initialized ZigBee network with existing network state.
java.io.IOException: This port appears to have been shutdown or disconnected.10:01:23 495 ERROR Exception inputStream reader parserThread
java.io.IOException: This port appears to have been shutdown or disconnected.
at j.extensions.comm.SerialComm$SerialCommInputStream.read(SerialComm.java:512)
at org.bubblecloud.zigbee.util.MarkableInputStream.read(MarkableInputStream.java:113)
at org.bubblecloud.zigbee.network.packet.ZToolPacketParser.run(ZToolPacketParser.java:102)
at java.lang.Thread.run(Unknown Source)
at j.extensions.comm.SerialComm$SerialCommOutputStream.write(SerialComm.java:564)
Looks like it has been marked as "@deprecated" since the 1st revision on github.
I think it might be necessary if we want to launch zigbee4java as a customized device (e.g. IAS CIE) besides the ZigBee controller.
Any thoughts are appreciated.
I've created a javadoc for the API - it's available here
Hi
I am observing with master HEAD that although ZDO_MGMT_PERMIT_JOIN_REQ passes successfully an error is reported related to it both at startup and when running join command from console. I wonder if there is some problem with handling of the commands directed to the zigbee dongle or error handling on console level? These commands do not access anything over network so their status is returned synchronously via ZDO_MGMT_PERMIT_JOIN_REQ_SRSP. It also looks like the ZDO_MGMT_PERMIT_JOIN_REQ is sent twice.
Despite this I was able to join philips hue bulb to the network and command it.
Br,
Tommi
ZigBee API starting up...20:20:21 735 INFO Initialized ZigBee network with existing network state.
20:20:21 799 INFO Registered default sending endpoint 1 with clusters: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 15, 10, 12, 21, 1794, 256]
20:20:21 823 INFO Registered default sending endpoint 2 with clusters: [257, 258, 512, 513, 514, 516, 768, 1027, 1024, 1025, 1026, 1028, 1029, 1030, 2820, 1280]
20:20:21 842 INFO Registered default sending endpoint 3 with clusters: [1281, 1282]
20:20:29 890 ERROR Error sending ZDO_MGMT_PERMIT_JOIN_REQ
ZigBee API starting up ... [OK]
There are 1 known devices in the network.
ZigBee console ready.
join enable
20:17:09 450 DEBUG Sending permit join with data: -1
20:17:09 451 DEBUG -> ZDO_MGMT_PERMIT_JOIN_REQ (Packet: length = 5, apiId = 0x25 0x36, full data = 0xfe 0x05 0x25 0x36 0x0f 0xfc 0xff 0xff 0x01 0xe4, checksum = 0xe4, error = false, errorMessage = null)
20:17:09 468 DEBUG <- ZDO_MGMT_PERMIT_JOIN_REQ_SRSP (ZDO_MGMT_PERMIT_JOIN_REQ_SRSP{Status=SUCCESS(0)})
20:17:09 470 DEBUG -> ZDO_MGMT_PERMIT_JOIN_REQ (Packet: length = 5, apiId = 0x25 0x36, full data = 0xfe 0x05 0x25 0x36 0x02 0x00 0x00 0xff 0x01 0xea, checksum = 0xea, error = false, errorMessage = null)
20:17:09 488 DEBUG <- ZDO_MGMT_PERMIT_JOIN_REQ_SRSP (ZDO_MGMT_PERMIT_JOIN_REQ_SRSP{Status=SUCCESS(0)})
20:17:17 489 ERROR Error sending ZDO_MGMT_PERMIT_JOIN_REQ
ZigBee API permit join enable ... [FAIL]
The permit join defaults to on, allowing any device to join the network at any time. This should default to off, and only turned on when the user allows permit join, and only for a limited period of time.
Hi,
Your mentioned hardware support only TI
I would like to know the support for digi zigbee modules
http://www.digi.com/products/xbee-rf-solutions/modules
What needs to be done to if it is not supported ?
Thanks,
Kiran.
To better support battery operated devices we need to be able to persist netwrok state. if software is restarted while a battery operated device is sleeping then the device is not discovered. It should be possible to load battery operated device information from storage instead.
CC2531 Dongle becomes unresponsive if restart occurs right after SYS_RESET. In other words if application is restarted during the initial startup phase of zigbee4java.
This behavior seems to be systematic. Whether this is a problem in the dongle side or if we should execute some other maneuver after trying SYS_RESET and magic byte to bring the dongle back to communicative state.
Currently only working procedure to fix the dongle is to plug it out physically.
I finally got around to chasing down why I get a random device being discovered each time the stack starts for my Hue. My Hue bulbs show an endpoint 242 - it's always been there, and it's a little frustrating in that every time the stack starts it gives this endpoint a different device type - I want to stop this! :)
There are really two issues here - firstly, the random selection of device type. This is just plane bad news - in the case of the Hue, where the device isn't known anyway, it doesn't matter, however it means even if the device is known, if it somehow happens to come up with the same score when the factory is evaluating a match, then next time it might evaluate to a different device if it matches two devices with the same score. In my case, the reason for the randomness is that this device doesn't come up with any score from the factor 'hasMatch'. So, the first class in the factory is the winner and the order isn't defined, so we end up with a random selection each time. This issue is easily solved by using a map that has a defined order - I've made this modification and will generate a PR soon.
The other issue is that returning any device type when the score is 0 is wrong - it hasn't matched any clusters, so we can't really say that this is the device (well, not one that we know!). So, to resolve this I propose to return null from getBestDeviceProxyFactory which stops the device being constructed.
PR to follow.
@presslab-us it looks like your changes in 3972948 might have broken something. I'm now getting the following error getting the ZDO_SIMPLE_DESC_RSP
during startup (at least when the network isn't restored off disk) -:
00:02:28 445 DEBUG Inspecting node #0 (00:12:4B:00:02:F1:DB:5B) / end point 1.
00:02:28 446 DEBUG -> ZDO_SIMPLE_DESC_REQ (Packet: length = 5, apiId = 0x25 0x04, full data = 0xfe 0x05 0x25 0x04 0x00 0x00 0x00 0x00 0x01 0x25, checksum = 0x25, error = false, errorMessage = null)
00:02:28 452 DEBUG <- ZDO_SIMPLE_DESC_REQ_SRSP (ZDO_SIMPLE_DESC_REQ_SRSP{Status=SUCCESS(0)})
00:02:34 463 DEBUG Inspecting ZigBee EndPoint <0,1> failed during it 1-th attempts. Waiting for 1000ms before retrying
00:02:34 464 DEBUG Inspecting node #0 (00:12:4B:00:02:F1:DB:5B) / end point 1.
00:02:34 464 DEBUG -> ZDO_SIMPLE_DESC_REQ (Packet: length = 5, apiId = 0x25 0x04, full data = 0xfe 0x05 0x25 0x04 0x00 0x00 0x00 0x00 0x01 0x25, checksum = 0x25, error = false, errorMessage = null)
00:02:34 469 DEBUG <- ZDO_SIMPLE_DESC_REQ_SRSP (ZDO_SIMPLE_DESC_REQ_SRSP{Status=SUCCESS(0)})
It seems if I revert back to the previous master on the 21st June (your fix of the not implemented exception) that this works ok again, so it seems to be the change on the 24th to add the HA meter clusters that has caused this...
Are you also seeing this?
Cheers
Chris
Hi
Here is an example of interfacing with ZigBeeConsole via JSON RPC API. You can hook this Slack Bot to your team and use direct chat with bot to interact with the ZigBeeConsole.
https://github.com/tlaukkan/zig
-Tommi
Hi,
I'm a newbie in IoT and in Zigbee, so sorry if I ask too obvious questions.
I'm trying to use zigbee4java based on this sample : https://github.com/jpizarrom/kura-greenhouse-demo-zigbee
I use this hardware : http://www.embit.eu/products/wireless-modules/emb-z2530pa/
So far I don't think It works and I have strange error message :
ERROR o.b.z.n.p.ZigBeeNetworkManagerImpl - Unable to reset dongle
Not sure what It means but I don't think my zigbee device is about to work properly.
Does anybody can tell me what's going wrong ?
Thanks in advance.
Here is a more complete log :
2007-01-01 01:29:51,428 [pool-14-thread-1] TRACE o.b.z.n.p.ZToolPacketParser - Creating ZToolPacketParser
2007-01-01 01:29:51,431 [pool-14-thread-1] TRACE o.b.z.n.p.ZToolPacketParser - Provided InputStream class com.smarthome.gateway.zigbee.LoggingInputStream doesn't provide the mark()/reset() feature, wrapping it up as BufferedInputStream
2007-01-01 01:29:51,441 [pool-14-thread-1] TRACE o.b.z.n.p.ZigBeeNetworkManagerImpl$WaitForCommand - Waiting for asynchronous response message 16768.
2007-01-01 01:29:51,444 [ZToolPacketParser] TRACE o.b.z.n.p.ZToolPacketParser - ZToolPacketParser parserThread started
2007-01-01 01:29:51,473 [pool-14-thread-1] DEBUG o.b.z.n.p.ZigBeeInterface - -> SYS_RESET (Packet: length = 1, apiId = 0x41 0x00, full data = 0xfe 0x01 0x41 0x00 0x01 0x41, checksum = 0x41, error = false, errorMessage = null)
2007-01-01 01:29:51,477 [pool-14-thread-1] INFO c.s.g.z.Wire - >> "[0xfe]"
2007-01-01 01:29:51,480 [pool-14-thread-1] INFO c.s.g.z.Wire - >> "[0x1]"
2007-01-01 01:29:51,482 [pool-14-thread-1] INFO c.s.g.z.Wire - >> "A"
2007-01-01 01:29:51,484 [pool-14-thread-1] INFO c.s.g.z.Wire - >> "[0x0]"
2007-01-01 01:29:51,487 [pool-14-thread-1] INFO c.s.g.z.Wire - >> "[0x1]"
2007-01-01 01:29:51,489 [pool-14-thread-1] INFO c.s.g.z.Wire - >> "A"
2007-01-01 01:29:56,493 [pool-14-thread-1] TRACE o.b.z.n.p.ZigBeeNetworkManagerImpl$WaitForCommand - Timeout 5000 expired and no packet with 16768 received
2007-01-01 01:29:56,496 [pool-14-thread-1] ERROR o.b.z.n.p.ZigBeeNetworkManagerImpl - Unable to reset dongle
2007-01-01 01:29:56,504 [pool-14-thread-1] TRACE o.b.z.n.p.ZigBeeNetworkManagerImpl - HARDWARE_INITIALIZING -> CLOSED
2007-01-01 01:29:56,507 [pool-14-thread-1] INFO c.s.g.z.ZigBeeDemo - post initializeHardware false
2007-01-01 01:29:56,510 [pool-14-thread-1] INFO o.b.z.n.p.ZigBeeNetworkManagerImpl - Failed to reach the NETWORK_READY level: getCurrentChannel() failed
2007-01-01 01:29:56,512 [pool-14-thread-1] INFO o.b.z.n.p.ZigBeeNetworkManagerImpl - Failed to reach the NETWORK_READY level: getCurrentPanId() failed
2007-01-01 01:29:56,515 [pool-14-thread-1] INFO c.s.g.z.ZigBeeDemo - ZigBee current pan=-1, channel=-1. Network will be reset.
I believe the discovery process is too chatty. In the log below (a network only composed by the dongle) look for occurrences of Waiting for other request to complete.
It looks like too many requests are issued concurrently and some are probably not needed.
Among the others:
At 11:09:39 698. ZDO_IEEE_ADDR_REQ is issued to get the IEEE address of the node and the nwk address of the associated nodes. This is actually not needed because, if the discovery starts from the coordinator, we already know its IEEE address (from ZB_GET_DEVICE_INFO_RSP). The list of associated nodes (with their IEEE addresses) can be derived from ZDO_MGMT_LQI_RSP.
So I don't see the need for ZDO_IEEE_ADDR_REQ.
What do you think?
11:09:39 697 DEBUG Inspecting ZigBee network for new nodes.
11:09:39 698 DEBUG -> ZDO_IEEE_ADDR_REQ (Packet: length = 4, apiId = 0x25 0x01, full data = 0xfe 0x04 0x25 0x01 0x00 0x00 0x01 0x00 0x21, checksum = 0x21, error = false, errorMessage = null)
11:09:39 699 DEBUG Inspecting ZigBee network for new nodes.
ZigBee API starting up ... [OK]
11:09:39 703 DEBUG Inspection queue: New queue size: 0. Failed queue size: 0
There are 0 known devices in the network.
ZigBee console ready.
> 11:09:39 706 DEBUG <- ZDO_IEEE_ADDR_REQ_SRSP (ZDO_IEEE_ADDR_REQ_SRSP{Status=SUCCESS(0)})
11:09:39 717 DEBUG <-- ZDO_IEEE_ADDR_RSP (ZDO_IEEE_ADDR_RSP{AssocDevList=[], assocDevList=[], IEEEAddr=0x00 0x12 0x4b 0x00 0x01 0x48 0xf1 0x20, nwkAddr=0x00 0x00, NumAssocDev=0, SrcAddress=null, SrcAddrMode=0, StartIndex=0, Status=SUCCESS(0)})
11:09:39 718 DEBUG -> ZDO_IEEE_ADDR_REQ (Packet: length = 4, apiId = 0x25 0x01, full data = 0xfe 0x04 0x25 0x01 0x00 0x00 0x00 0x00 0x20, checksum = 0x20, error = false, errorMessage = null)
11:09:39 719 DEBUG Waiting for other request to complete
11:09:39 725 DEBUG <- ZDO_IEEE_ADDR_REQ_SRSP (ZDO_IEEE_ADDR_REQ_SRSP{Status=SUCCESS(0)})
11:09:39 726 DEBUG -> ZB_GET_DEVICE_INFO (Packet: length = 1, apiId = 0x26 0x06, full data = 0xfe 0x01 0x26 0x06 0x06 0x27, checksum = 0x27, error = false, errorMessage = null)
11:09:39 734 DEBUG <-- ZDO_IEEE_ADDR_RSP (ZDO_IEEE_ADDR_RSP{AssocDevList=[], assocDevList=[], IEEEAddr=0x00 0x12 0x4b 0x00 0x01 0x48 0xf1 0x20, nwkAddr=0x00 0x00, NumAssocDev=0, SrcAddress=null, SrcAddrMode=0, StartIndex=0, Status=SUCCESS(0)})
11:09:39 735 DEBUG ZDO_IEEE_ADDR_RSP from 0x00 0x12 0x4b 0x00 0x01 0x48 0xf1 0x20 with 0 associated
11:09:39 735 DEBUG Waiting for other request to complete
11:09:39 736 DEBUG <- ZB_GET_DEVICE_INFO_RSP (Packet: length = 9, apiId = 0x66 0x06, full data = 0xfe 0x09 0x66 0x06 0x06 0x34 0x12 0x00 0xff 0xfd 0x00 0x00 0x03 0x48, checksum = 0x48, error = false, errorMessage = null)
11:09:39 736 DEBUG -> ZB_GET_DEVICE_INFO (Packet: length = 1, apiId = 0x26 0x06, full data = 0xfe 0x01 0x26 0x06 0x06 0x27, checksum = 0x27, error = false, errorMessage = null)
11:09:39 739 DEBUG Network browsing completed, waiting until 1442913879697
11:09:39 739 DEBUG Inspecting device 00:12:4B:00:01:48:F1:20.
11:09:39 739 DEBUG Waiting for other request to complete
11:09:39 741 DEBUG <- ZB_GET_DEVICE_INFO_RSP (Packet: length = 9, apiId = 0x66 0x06, full data = 0xfe 0x09 0x66 0x06 0x06 0x34 0x12 0x00 0xff 0xfd 0x00 0x00 0x03 0x48, checksum = 0x48, error = false, errorMessage = null)
11:09:39 741 DEBUG -> ZB_GET_DEVICE_INFO (Packet: length = 1, apiId = 0x26 0x06, full data = 0xfe 0x01 0x26 0x06 0x06 0x27, checksum = 0x27, error = false, errorMessage = null)
11:09:39 741 DEBUG ZDO_MGMT_LQI_REQ to 0 from index 0
11:09:39 741 DEBUG Waiting for other request to complete
11:09:39 745 DEBUG <- ZB_GET_DEVICE_INFO_RSP (Packet: length = 9, apiId = 0x66 0x06, full data = 0xfe 0x09 0x66 0x06 0x06 0x34 0x12 0x00 0xff 0xfd 0x00 0x00 0x03 0x48, checksum = 0x48, error = false, errorMessage = null)
11:09:39 746 DEBUG -> ZDO_MGMT_LQI_REQ (Packet: length = 3, apiId = 0x25 0x31, full data = 0xfe 0x03 0x25 0x31 0x00 0x00 0x00 0x17, checksum = 0x17, error = false, errorMessage = null)
11:09:39 746 DEBUG Adding node #0 (00:12:4B:00:01:48:F1:20) to the network
Node added: 00:12:4B:00:01:48:F1:20 (#0)
11:09:39 746 DEBUG Created node object for #0 (00:12:4B:00:01:48:F1:20) that was not available on the network
11:09:39 746 DEBUG Inspecting new node #0 (00:12:4B:00:01:48:F1:20)
11:09:39 747 DEBUG Waiting for other request to complete
11:09:39 756 DEBUG <- ZDO_MGMT_LQI_REQ_SRSP (ZDO_MGMT_LQI_REQ_SRSP{Status=SUCCESS(0)})
11:09:39 756 DEBUG -> ZDO_NODE_DESC_REQ (Packet: length = 4, apiId = 0x25 0x02, full data = 0xfe 0x04 0x25 0x02 0x00 0x00 0x00 0x00 0x23, checksum = 0x23, error = false, errorMessage = null)
11:09:39 760 DEBUG <-- ZDO_MGMT_LQI_RSP (ZDO_MGMT_LQI_RSP{NeighborLQICount=0, NeighborLQIEntries=0, NeighborLqiList=[], SrcAddress=0x00 0x00, StartIndex=0, Status=SUCCESS(0)})
11:09:39 760 DEBUG Found 0 neighbors on node #0
The ZNP firmware (Z-Stack 2.6) that comes with the TI Z-Stack Linux Gateway doesn't work with zigbee4java. I see some mention of supporting this in ZB4O. http://zb4o.aaloa.org/redmine/issues/274
I think supporting this would make it much easier for new users to get up to speed as they won't need to compile the firmware themselves and can instead use the HEX from the Gateway download. Also there are possibly bug fixes in this newer version.
Gradle support is now greatly improved from the first attempt and, in my judgement, ready to be merged from gradleSupport branch to master. As a temporary feature branch, gradleSupport will be deleted, following the merge.
The current changes from master have been merged into gradleSupport, so there should be no conflict when merging back.
I do not have a suitable testing ZigBee environment at the moment, and while there is no reason why the addition of new build support should have broken anything internal to the library, it may be a good idea for someone (particularly @tlaukkan, @cdjackson or @presslab-us) to find a moment to compile and run ZigBeeConsole etc. from this branch and perform some kind of sanity check.
As a brief intro: Gradle builds both desktop and android related artifacts by default.
See this by executing the following line from the zigbee4java folder:
./gradlew build
Which profiles are built can be controlled in the file gradle.properties. It is not currently possible to override this property with -P on the Gradle command line. Enabling property override behaviour seems to be a subject of some discussion within the Gradle community.
I've also modified the Maven POMs to match the new module layout and build scheme, with modules grouped by 'desktop' and 'android' profiles; both of which are enabled by default.
One major difference between the Maven and Gradle outputs, currently, is that Maven does not produce a final Android APK file from the ZigBeeConsole App project, whereas Gradle does. This seems a low priority fix however as Gradle is the clear recommended system for Android builds these days. The Maven Android compile at least serves to confirms to Maven-based zigbee4java contributors that the Android target hasn't been broken by their ongoing changes.
The zigbee-console-android project is a placeholder at the moment, producing an empty Android App, but now with the correct dependencies in place to build from zigbee-console-common and construct an Android console to demo ZigBee functionality from the mobile platform... this will be my next endeavour.
> .22:44:21 857 ERROR Error constructing response packet {}
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.bubblecloud.zigbee.network.packet.zdo.ZDO_MSG_CB_INCOMING.translate(ZDO_MSG_CB_INCOMING.java:145)
at org.bubblecloud.zigbee.network.packet.ZToolPacketStream.parsePayload(ZToolPacketStream.java:309)
at org.bubblecloud.zigbee.network.packet.ZToolPacketStream.parsePacket(ZToolPacketStream.java:171)
at org.bubblecloud.zigbee.network.packet.ZToolPacketParser.run(ZToolPacketParser.java:107)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 6
at org.bubblecloud.zigbee.network.packet.zdo.ZDO_SIMPLE_DESC_RSP.<init>(ZDO_SIMPLE_DESC_RSP.java:96)```
The frame is too small for the parser. Any ideas what can cause it so I can start fixing it?
Thanks
I'd like to modify the console to support standard gnu/posix options like in the below example.
In order to support this I need to slightly modify the ZigBeeConsole, ZigBeeApi and ZigBeeNetworkManagerImpl to allow for more parameters to be passed to the constructors.
In order to avoid constructors with so many parameters I was thinking to the Builder pattern.
Do you think this is worthwhile to add?
Cheers,
Cristiano
usage: java -jar zigbee4java-serialPort.jar [OPTION]... DEVICE
-c,--channel <channel> add the specified channel (11-26)
to the list of channels scanned on
establishing the network. The
default channel list is 11, 14,
15, 19, 20, 24, 25. This option
may be repeated multiple times.
-d,--distribute-network-key distribute the network key in
clear to devices joining the
network. If not specified the
default behaviour is to not
distribute the network key.
-e,--epid <epid> the extended PAN ID (EPID) in
hexadecimal format
(0-0xfffffffffffffffe). The
default value is 0 which means
that stack will set the EPID to
the value of the IEEE address.
-k,--network-key <network-key> the network key in hexadecimal
format (1-0xfffffffffffffffe). If
not set the dongle will use a
preconfigured value.
-m,--discovery-mode <discovery-mode> the method used to discover
devices. Valid values are
`announce', `addressing', `lqi'
and `all' as a shortcut for the
first tree. This option can be
repeated multiple times.
-p,--panid <panid> the PAN ID in hexadecimal format
(0-0xffff). The default PAN ID is
0xffff which means that stack will
generate a random, nonconflicting
PAN ID.
-r,--reset-network start with a clean network state
and configuration. If not
specified the network will resume
using the last state and
configuration.
-s,--no-security disable security.
I'm facing a timeout problem when I run zigbee-console-javase
both with the CC2531ZNP-Pro-Secure_Standard.hex
and the CC2531ZNP-Pro-Secure_LinkKeyJoin.hex
firmware (note that I'm starting the network clearing the state):
java -jar target/zigbee-console-javase-2.0.3-SNAPSHOT.jar /dev/ttyACM0 11 4952 true
ZigBee API starting up...19:23:28 455 DEBUG Opening portIdentifier '/dev/ttyACM0'.
19:23:28 463 DEBUG -> SYS_RESET (Packet: length = 1, apiId = 0x41 0x00, full data = 0xfe 0x01 0x41 0x00 0x01 0x41, checksum = 0x41, error = false, errorMessage = null)
19:23:30 049 DEBUG <-- SYS_RESET_RESPONSE (Packet: length = 6, apiId = 0x41 0x80, full data = 0xfe 0x06 0x41 0x80 0x00 0x02 0x00 0x02 0x06 0x03 0xc2, checksum = 0xc2, error = false, errorMessage = null)
19:23:30 049 DEBUG Resetting network stack.
19:23:30 050 INFO Setting clean state.
19:23:30 051 DEBUG -> ZB_WRITE_CONFIGURATION (Packet: length = 3, apiId = 0x26 0x05, full data = 0xfe 0x03 0x26 0x05 0x03 0x01 0x03 0x21, checksum = 0x21, error = false, errorMessage = null)
19:23:31 051 WARN ZB_WRITE_CONFIGURATION executed and timed out while waiting for response.
19:23:31 061 WARN Couldn't set ZCD_NV_STARTUP_OPTION mask 00000003
19:23:31 061 ERROR Unable to set clean state for dongle
19:23:31 061 DEBUG Serial portIdentifier '/dev/ttyACM0' closed.
19:23:31 499 WARN Discarded stream: expected start byte but received this 0x00
19:23:31 499 DEBUG ZToolPacketParser parserThread exited.
ZigBee API starting up ... [FAIL]
It happens when the application is started while the led on the CC2531 is on, i.e. within the first 60 seconds after it has been plugged.
If I run the above command a second time just after the timeout or I wait more than 60 seconds after the dongle has been plugged (the led goes off) the network always starts successfully.
I've tried to increase the RESEND_TIMEOUT_DEFAULT
to 10000 and this seems to fix the problem.
Can anyone confirm this behavior?
I often see timeouts on end devices, which are battery powered. These devices spend most of the time sleeping, and only occasionally wake up and poll their nearest router to see if any requests are waiting.
The poll time for most end devices I have here is 5 seconds. The HA spec is as follows: In their normal operating state, ZigBee end devices shall poll no more frequently than once every 7.5 seconds...
Unfortunately the default timeout in zigbee4java is 5 seconds. So often any read operation will timeout to an end device.
What would be the best way to address this? In the short term I think raising the timeout to 10 seconds would work for my devices here. But according to the HA spec it could be much longer than 7.5 seconds. Maybe there should be a separate large timeout (30 seconds?) for end devices, and the usual timeout for routers. Or the timeout could be exposed in the API, but then it's left up to the host application which seems unnecessary.
@chris-hatton @cdjackson @presslab-us
The URL to the FAQ: https://groups.google.com/d/forum/zigbee4java
Any idea what error 25 is -:
20:25:31 206 DEBUG <--!!!= 0xfe 0x03 0x44 0x80 0x19 0x01 0x1e 0xc1
20:25:31 206 WARN Unknown status value: 25
I added the DEBUG printout here... Error 25 isn't in the manual :(
These are the imports of ZigBeeConsole
:
import org.apache.commons.io.FileUtils;
import org.bubblecloud.zigbee.api.Device;
import org.bubblecloud.zigbee.api.DeviceListener;
import org.bubblecloud.zigbee.api.ZigBeeApiConstants;
import org.bubblecloud.zigbee.api.ZigBeeDeviceException;
import org.bubblecloud.zigbee.api.cluster.Cluster;
import org.bubblecloud.zigbee.api.cluster.general.LevelControl;
import org.bubblecloud.zigbee.api.cluster.general.OnOff;
import org.bubblecloud.zigbee.api.cluster.impl.api.core.Attribute;
import org.bubblecloud.zigbee.api.cluster.impl.api.core.ReportListener;
import org.bubblecloud.zigbee.api.cluster.impl.api.core.Reporter;
import org.bubblecloud.zigbee.api.cluster.impl.api.core.ZigBeeClusterException;
import org.bubblecloud.zigbee.api.cluster.general.ColorControl;
import org.bubblecloud.zigbee.network.NodeListener;
import org.bubblecloud.zigbee.network.ZigBeeNode;
import org.bubblecloud.zigbee.network.ZigBeeNodeDescriptor;
import org.bubblecloud.zigbee.network.ZigBeeNodePowerDescriptor;
import org.bubblecloud.zigbee.network.discovery.LinkQualityIndicatorNetworkBrowser.NetworkNeighbourLinks;
import org.bubblecloud.zigbee.network.discovery.ZigBeeDiscoveryManager;
import org.bubblecloud.zigbee.network.impl.ZigBeeNetworkManagerException;
import org.bubblecloud.zigbee.network.impl.ZigBeeNodeImpl;
import org.bubblecloud.zigbee.network.port.ZigBeePort;
import org.bubblecloud.zigbee.network.model.DiscoveryMode;
import org.bubblecloud.zigbee.util.Cie;
ZigBeeConsole
needs to use many impl
packages. What is the name convention here? Should we consider impl
packages the same as internal (which should maybe preferred), something the application should try to avoid?
Pragmatically, the question arises from trying to OSGi-fy (see #62) the API with the maven-bundle-plugin
.
By default this plugin will not export packages containing impl
or internal
.
Also, I think that some of the classes imported above should be move in non impl
packages, for example org.bubblecloud.zigbee.api.cluster.impl.api.core.Attribute
it's just an interface and it's clearly part of the API.
Another example are Exceptions: org.bubblecloud.zigbee.api.cluster.impl.api.core.ZigBeeClusterException
and org.bubblecloud.zigbee.network.impl.ZigBeeNetworkManagerException
.
Also, I don't quite understand the overall name convention:
There are many other examples. We can improve a little bit the situation but that would mean breaking the current "API".
I guess we will have a similar discussion as we had with the SerialPort, but I would suggest to remove the serialisation from the main library and put it in the gateway server as an example for others.
The problem is it has a very large dependancy and IMHO this serialisation should be left to the main software and not covered in the library. In my project, the framework already provides libraries for serialising this sort of data, and for embedded systems adding dependancies like this isn't so nice...
What do you think? Is there a better way to handle this? Some sort of callback, or just let the framework populate the devices itself...
Edit: Migrated to https://github.com/zsmartsystems/com.zsmartsystems.zigbee
This is probably well known.
Ciao,
Cristiano
ZigBee API starting up...java.lang.RuntimeException: Error serializing network state.
at org.bubblecloud.zigbee.network.impl.NetworkStateSerializer.deserialize(NetworkStateSerializer.java:77)
at org.bubblecloud.zigbee.ZigBeeApi.deserializeNetworkState(ZigBeeApi.java:353)
at org.bubblecloud.zigbee.ZigBeeConsole.start(ZigBeeConsole.java:110)
at org.bubblecloud.zigbee.ZigBeeConsoleJavaSE.main(ZigBeeConsoleJavaSE.java:34)
Caused by: org.codehaus.jackson.map.JsonMappingException: No suitable constructor found for type [simple type, class org.bubblecloud.zigbee.network.ZigBeeNodeDescriptor]: can not instantiate from JSON object (need to add/enable type information?)
at [Source: java.io.StringReader@26eb6935; line: 1, column: 289] (through reference chain: org.bubblecloud.zigbee.network.impl.ZigBeeEndpointImpl["node"]->org.bubblecloud.zigbee.network.impl.ZigBeeNodeImpl["nodeDescriptor"])
at org.codehaus.jackson.map.JsonMappingException.from(JsonMappingException.java:163)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObjectUsingNonDefault(BeanDeserializer.java:740)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:683)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:87)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromObject(AsArrayTypeDeserializer.java:55)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeWithType(BeanDeserializer.java:664)
at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:297)
at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:414)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:697)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:87)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromAny(AsArrayTypeDeserializer.java:69)
at org.codehaus.jackson.map.deser.AbstractDeserializer.deserializeWithType(AbstractDeserializer.java:77)
at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:297)
at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:414)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:697)
at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:87)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromAny(AsArrayTypeDeserializer.java:69)
at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserializeWithType(UntypedObjectDeserializer.java:106)
at org.codehaus.jackson.map.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:219)
at org.codehaus.jackson.map.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:194)
at org.codehaus.jackson.map.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:30)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:87)
at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromArray(AsArrayTypeDeserializer.java:45)
at org.codehaus.jackson.map.deser.std.CollectionDeserializer.deserializeWithType(CollectionDeserializer.java:232)
at org.codehaus.jackson.map.deser.StdDeserializerProvider$WrappedDeserializer.deserialize(StdDeserializerProvider.java:494)
at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2723)
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1854)
at org.bubblecloud.zigbee.network.impl.NetworkStateSerializer.deserialize(NetworkStateSerializer.java:75)
... 3 more
The callback from the reporter interface only provides the attribute information - not the device or cluster. This means that it's difficult to set up a single reporter callback method to receive information from different clusters (or devices).
Have I missed something here? To me it seems preferable to have the additional information available in the reporter callback so the client doesn't have to (somehow) manage this itself (with multiple callbacks I guess).
1 ZDO_SIMPLE_DESC_REQ would get 2 ZDO_SIMPLE_DESC_RSP. (I don't see why/where the 2nd ZDO_SIMPLE_DESC_RSP is sent. Any ideas?)
If a node has 2 endpoints, the result would be unexpected.
See example below. The coordinator has 2 endpoints. Inspecting endpoint 1 would take the 2nd result of inspection of endpoint 2 as its result, which is incorrect.
It could be resolved by updating the WaitForCommand by adding an extra parameter "endpoint". If the asynchronous response is ZDO_SIMPLE_DESC_RSP, checking the value of "Endpoint" field of the response to determine whether the response is dedicated to current waiter.
Any suggestion?
13:19:00 940 DEBUG Found 2 end points on #0.
13:19:00 941 DEBUG <-- ZDO_ACTIVE_EP_RSP (ZDO_ACTIVE_EP_RSP{ActiveEndpointCount=2, ActiveEndpointList=[2, 1], nwkAddr=0x00 0x00, SrcAddress=0x00 0x00, Status=SUCCESS(0)})
13:19:00 943 DEBUG Inspecting node #0 (00:12:4B:00:01:4E:93:2C) / end point 2.
13:19:00 945 DEBUG <- ZDO_MGMT_LQI_REQ_SRSP (ZDO_MGMT_LQI_REQ_SRSP{Status=SUCCESS(0)})
13:19:00 945 DEBUG -> ZDO_SIMPLE_DESC_REQ (Packet: length = 5, apiId = 0x25 0x04, full data = 0xfe 0x05 0x25 0x04 0x00 0x00 0x00 0x00 0x02 0x26, checksum = 0x26, error = false, errorMessage = null)
13:19:00 954 DEBUG <-- ZDO_MGMT_LQI_RSP (ZDO_MGMT_LQI_RSP{NeighborLQICount=1, NeighborLQIEntries=1, NeighborLqiList=[org.bubblecloud.zigbee.network.packet.zdo.ZDO_MGMT_LQI_RSP$NeighborLqiListItemClass@53c88e], SrcAddress=0x00 0x00, StartIndex=0, Status=SUCCESS(0)})
13:19:00 954 DEBUG Received expected response: ZDO_MGMT_LQI_RSP
13:19:00 954 DEBUG Found 1 neighbors on node #0
13:19:00 954 DEBUG Node #40442 visible from node #0 with LQI value 170
13:19:00 955 DEBUG <-- ZDO_MGMT_LQI_RSP (ZDO_MGMT_LQI_RSP{NeighborLQICount=1, NeighborLQIEntries=1, NeighborLqiList=[org.bubblecloud.zigbee.network.packet.zdo.ZDO_MGMT_LQI_RSP$NeighborLqiListItemClass@f78a5], SrcAddress=0x00 0x00, StartIndex=0, Status=SUCCESS(0)})
13:19:00 959 DEBUG <- ZDO_SIMPLE_DESC_REQ_SRSP (ZDO_SIMPLE_DESC_REQ_SRSP{Status=SUCCESS(0)})
13:19:00 959 DEBUG Waiting for ZDO Simple Description Response
13:19:00 959 DEBUG -> ZDO_IEEE_ADDR_REQ (Packet: length = 4, apiId = 0x25 0x01, full data = 0xfe 0x04 0x25 0x01 0xfa 0x9d 0x00 0x00 0x47, checksum = 0x47, error = false, errorMessage = null)
13:19:00 968 DEBUG <-- ZDO_SIMPLE_DESC_RSP (ZDO_SIMPLE_DESC_RSP{DevID=0x0000, DevVer=0, InClusterCount=0, InClusterList=[], OutClusterCount=13, OutClusterList=[0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000f, 0x000a, 0x0502], ProfID=0x0104, Endpoint=2, nwkAddr=0x00 0x00, SrcAddress=0x00 0x00, Status=SUCCESS(0), len=34, inputs=null, outputs=null})
13:19:00 968 DEBUG Received expected response: ZDO_SIMPLE_DESC_RSP
13:19:00 968 DEBUG ZDO Simple Description Response ZDO_SIMPLE_DESC_RSP{DevID=0x0000, DevVer=0, InClusterCount=0, InClusterList=[], OutClusterCount=13, OutClusterList=[0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000f, 0x000a, 0x0502], ProfID=0x0104, Endpoint=2, nwkAddr=0x00 0x00, SrcAddress=0x00 0x00, Status=SUCCESS(0), len=34, inputs=null, outputs=null}
13:19:00 969 DEBUG Sender end point 00:12:4B:00:01:4E:93:2C/2 found with profile PROFILE_ID_HOME_AUTOMATION: 260
13:19:00 969 DEBUG networkAddr: 0, inputClusters: 0
13:19:00 969 DEBUG Inspecting node #0 (00:12:4B:00:01:4E:93:2C) / end point 1.
13:19:00 971 DEBUG <-- ZDO_SIMPLE_DESC_RSP (ZDO_SIMPLE_DESC_RSP{DevID=0x0000, DevVer=0, InClusterCount=0, InClusterList=[], OutClusterCount=13, OutClusterList=[0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000f, 0x000a, 0x0502], ProfID=0x0104, Endpoint=2, nwkAddr=0x00 0x00, SrcAddress=0x00 0x00, Status=SUCCESS(0), len=34, inputs=null, outputs=null})
13:19:00 975 DEBUG Received expected response: ZDO_SIMPLE_DESC_RSP
13:19:00 976 DEBUG <- ZDO_IEEE_ADDR_REQ_SRSP (ZDO_IEEE_ADDR_REQ_SRSP{Status=SUCCESS(0)})
13:19:00 977 DEBUG -> ZDO_SIMPLE_DESC_REQ (Packet: length = 5, apiId = 0x25 0x04, full data = 0xfe 0x05 0x25 0x04 0x00 0x00 0x00 0x00 0x01 0x25, checksum = 0x25, error = false, errorMessage = null)
13:19:00 985 DEBUG <- ZDO_SIMPLE_DESC_REQ_SRSP (ZDO_SIMPLE_DESC_REQ_SRSP{Status=SUCCESS(0)})
13:19:00 985 DEBUG Waiting for ZDO Simple Description Response
13:19:00 985 DEBUG ZDO Simple Description Response ZDO_SIMPLE_DESC_RSP{DevID=0x0000, DevVer=0, InClusterCount=0, InClusterList=[], OutClusterCount=13, OutClusterList=[0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000f, 0x000a, 0x0502], ProfID=0x0104, Endpoint=2, nwkAddr=0x00 0x00, SrcAddress=0x00 0x00, Status=SUCCESS(0), len=34, inputs=null, outputs=null}
13:19:00 985 DEBUG Sender end point 00:12:4B:00:01:4E:93:2C/1 found with profile PROFILE_ID_HOME_AUTOMATION: 260
13:19:00 985 DEBUG 13 Adding <profileId,clusterId> <260,0> to sender2EndPoint hashtable
13:19:00 985 DEBUG 13 Adding <profileId,clusterId> <260,1> to sender2EndPoint hashtable
13:19:00 985 DEBUG 13 Adding <profileId,clusterId> <260,2> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,3> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,4> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,5> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,6> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,7> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,8> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,9> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,10> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,15> to sender2EndPoint hashtable
13:19:00 986 DEBUG 13 Adding <profileId,clusterId> <260,1282> to sender2EndPoint hashtable
13:19:00 987 DEBUG networkAddr: 0, inputClusters: 0
Node discovered: 00:12:4B:00:01:4E:93:2C (#0)
13:19:00 987 DEBUG Endpoint inspection completed, next inspection slot in 0
13:19:00 987 DEBUG Inspection queue: New queue size: 2. Failed queue size: 0
13:19:00 987 DEBUG Inspecting device 00:12:4B:00:01:4E:93:2C.
13:19:00 987 DEBUG Inspecting existing node #0 (00:12:4B:00:01:4E:93:2C)
13:19:00 987 DEBUG Endpoint inspection completed, next inspection slot in 100
13:19:00 994 DEBUG <-- ZDO_SIMPLE_DESC_RSP (ZDO_SIMPLE_DESC_RSP{DevID=0x0400, DevVer=0, InClusterCount=3, InClusterList=[0x0501, 0x0003, 0x0001], OutClusterCount=3, OutClusterList=[0x0502, 0x0500, 0x0003], ProfID=0x0104, Endpoint=1, nwkAddr=0x00 0x00, SrcAddress=0x00 0x00, Status=SUCCESS(0), len=20, inputs=null, outputs=null})
13:19:00 995 DEBUG <-- ZDO_SIMPLE_DESC_RSP (ZDO_SIMPLE_DESC_RSP{DevID=0x0400, DevVer=0, InClusterCount=3, InClusterList=[0x0501, 0x0003, 0x0001], OutClusterCount=3, OutClusterList=[0x0502, 0x0500, 0x0003], ProfID=0x0104, Endpoint=1, nwkAddr=0x00 0x00, SrcAddress=0x00 0x00, Status=SUCCESS(0), len=20, inputs=null, outputs=null})
13:19:01 087 DEBUG Inspection queue: New queue size: 1. Failed queue size: 0
13:19:01 087 DEBUG Inspecting device 00:12:4B:00:01:4E:93:2C.
13:19:01 087 DEBUG Inspecting existing node #0 (00:12:4B:00:01:4E:93:2C)
13:19:01 088 WARN The device #0 (00:12:4B:00:01:4E:93:2C) has been found again with a new network address #40442
Node updated: 00:12:4B:00:01:4E:93:2C (#40442)
13:19:01 088 DEBUG Endpoint inspection completed, next inspection slot in 99
13:19:01 187 DEBUG Inspection queue: New queue size: 0. Failed queue size: 0
There are 0 known devices in the network.
ZigBee console ready.
Hey,
I noticed something strange, if I listen for cluster messages, process them and invoking command in response I get timeout issues. If I invoke the response on the main thread instead of the ClusterListener thread its working fine. Debugging the issue I saw that zigbee4java got the response.. its just some threading issue. Am I missing something? Anyone have an Idea how to fix the issue?
The CC2531 stores which devices have joined the network. I could not find a way to remove any of those from the dongle by using the java SE console app. Is there one? If not, can it be added?
I am looking at refactoring the NetworkManager class to make it more abstract. Currently, it is heavily linked to specific layers and methods in the TI interface (eg the ZDO). I think in many (hopefully most!) cases this is not necessary and this should be left to the implementation, not the abstract class.
So, I plan to look at removing all links to things like ZDO if I can - for example -:
networkManager.sendZDOBind()
takes a ZDO_BIND_REQ
class as parameter - I'd remove this and simply pass in the required parameters and move the instantiation of the ZDO_BIND_REQ
to the implication class.
I think his should make it easier to implement other sticks that support higher level interfaces (eg Telegesis / Ember / XBee.....)
Any thoughts appreciated :)
Hey Tommi. It's been a few months since I looked over this and you've moved up to V3 which is cool ;).
Just looking at the split between the Dongle and API projects and there seems to be a lot of stuff in the dongle project that's not dongle related (eg the cluster libraries seem to be there).
Shouldn't there be a cleaner split between the zigbee layers, so that the API and implementation of the cluster library is in one project, and the definition of the dongle, and implementation of the dongle are in separate projects?
Currently, it doesn't appear to me that it's possible to implement a different dongle without reuse of the 2531 project.
Maybe I misunderstand how it's now meant to work - any guidance?
Cheers
Chris
Edit: Migrated to https://github.com/zsmartsystems/com.zsmartsystems.zigbee
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.