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

ConBee/RaspBee Support #294

Open
saurabh984 opened this issue Apr 26, 2018 · 14 comments
Open

ConBee/RaspBee Support #294

saurabh984 opened this issue Apr 26, 2018 · 14 comments
Labels
CONBEE help wanted pinned Will not be closed, even if stale

Comments

@saurabh984
Copy link

Hi Chris,

The README says more work is required for ConBee and RaspBee. Would you mind creating a list/issue here with details?

I'd like to help!

Thanks
S
@cdjackson
Copy link
Member

Hi @saurabh984 thanks for offering to help. If I remember correctly, it is working ok, but when used for a longer period, or when integrated into other applications, there was an issue where communications stopped. I suspect it is a thread synchronisation issue or something like this. It probably just needs a bit of time, and for someone to pick it up - since I normally use the Ember and do most of my testing with that take time like this I don't see.

I'd suggest if you want to help, then just give it a go - get the console up and running with the ConBee and see what you find. I'm happy to help if you have any questions.

Cheers
Chris

@cdjackson cdjackson mentioned this issue Nov 11, 2018
Merged
@cdjackson cdjackson mentioned this issue Mar 4, 2019
Closed
@curlyel
Copy link

curlyel commented Jun 11, 2019 •
edited

Hi Chris,
since I'm still hoping to make use of my Dresden "RaspBEE"-modules (not the ConBEE), I've started to configure a Pi for trying to get your Zigbee console running on it.

First, I've installed Eclipse IDE (with m2e) and Maven on the Pi. Unfortunately I wasn't able to successfully build the Zigbee packages within the IDE and therefore wasn't able run the Zigbee console from it.

So I've let Maven directly build the project and started the console from the bash command line and gave it a logger config to redirect debug output to the terminal too (see below)
Doing so, I currently get the output of the console as well as the log4j-output. Btw.: passing commands into the Zigbee console is not working yet ...

Please bear with me since I'm neither a Java developer nor familiar with Eclipse IDE - you might remember this ;-), Therefore, before I pursue a complete wrong road, please advise:

Is it a valid approach to gather some debug information about the ConBEE/RaspBEE communication issue or is it complete nonsense trying it outside the IDE?

pi@RaspBEE-TEST:~/com.zsmartsystems.zigbee/com.zsmartsystems.zigbee.console.main/target $ java -jar com.zsmartsystems.zigbee.console.main-1.2.0-SNAPSHOT.jar -dongle CONBEE -port /dev/ttyS0 -baud 38400 -flow software -reset
Initialising ZigBee console...
13:29:17.275  DEBUG  Default: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=2, interTransactionDelay=50, maxRetries=2]
13:29:17.279  DEBUG  Broadcast: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=3, interTransactionDelay=1200, maxRetries=0]
13:29:17.280  DEBUG  Multicast: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=3, interTransactionDelay=1200, maxRetries=0]
13:29:17.297  ERROR  Error creating network database folder database/CONBEE
13:29:17.330  DEBUG  Adding supported cluster 1280
13:29:17.346  DEBUG  ClusterMatcher starting
13:29:17.348  DEBUG  ClusterMatcher adding cluster 1280
13:29:17.357  DEBUG  Adding supported cluster 25
13:29:17.358  DEBUG  ClusterMatcher adding cluster 25
13:29:17.680  DEBUG  Network state is updated to INITIALISING
13:29:17.680  DEBUG  ConBee transport initialize
ZigBee network state updated to INITIALISING
13:29:17.683  DEBUG  Ignoring invalid transport state transition in ZigBeeNetworkState.INITIALISING by ZigBeeTransportState.UNINITIALISED
13:29:17.685  DEBUG  Opening port /dev/ttyS0 at 38400 baud with FLOWCONTROL_OUT_XONOFF.
13:29:18.031  DEBUG  ConBeeReceiveHandler thread started
13:29:18.055  DEBUG  TX CONBEE queue: 1
13:29:18.058  DEBUG  TX CONBEE queue: 1 sync
13:29:18.059  DEBUG  TX CONBEE queue: 1 send
13:29:18.060  DEBUG  CONBEE TX: DeviceStateRequest [sequence=1]
13:29:18.097  DEBUG  CONBEE TX: 07 01 00 08 00 00 00 00 F0 FF
13:29:18.099  DEBUG  TX CONBEE queue: 1 exit
13:29:18.113  DEBUG  CONBEE RX: Data 07 01 00 08 00 A2 00 1C 32 FF
13:29:18.124  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=1, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.126  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.126  DEBUG  ConBeeDeviceState-sync
13:29:18.127  DEBUG  ConBeeDeviceState out before
13:29:18.128  DEBUG  ConBeeDeviceState out QueryVersionRequest [sequence=0]
13:29:18.128  DEBUG  CONBEE TX: QueryVersionRequest [sequence=2]
13:29:18.135  DEBUG  CONBEE TX: 0D 02 00 09 00 00 00 00 00 E8 FF
13:29:18.135  DEBUG  ConBeeDeviceState out after
13:29:18.136  DEBUG  ConBeeDeviceState-done
13:29:18.147  DEBUG  CONBEE RX: Data 0D 02 00 09 00 00 05 33 26 8A FF
13:29:18.151  DEBUG  CONBEE RX Frame: QueryVersionResponse [sequence=2, version=640877824]
13:29:18.153  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.154  DEBUG  ConBeeDeviceState-sync
13:29:18.155  DEBUG  ConBeeDeviceState-done
13:29:18.161  DEBUG  TX CONBEE queue: 1
13:29:18.162  DEBUG  TX CONBEE queue: 1 sync
13:29:18.164  DEBUG  TX CONBEE queue: 1 send
13:29:18.174  DEBUG  CONBEE TX: DeviceStateRequest [sequence=3]
13:29:18.178  DEBUG  CONBEE TX: 07 03 00 08 00 00 00 00 EE FF
13:29:18.180  DEBUG  TX CONBEE queue: 1 exit
13:29:18.187  DEBUG  CONBEE RX: Data 07 03 00 08 00 A2 00 33 19 FF
13:29:18.189  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=3, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.190  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.191  DEBUG  ConBeeDeviceState-sync
13:29:18.192  DEBUG  ConBeeDeviceState out before
13:29:18.193  DEBUG  ConBeeDeviceState out ReadParameterRequest [sequence=0, parameter=DEVICE_TYPE]
13:29:18.195  DEBUG  CONBEE TX: ReadParameterRequest [sequence=4, parameter=DEVICE_TYPE]
13:29:18.204  DEBUG  CONBEE TX: 0A 04 00 08 00 01 00 09 E0 FF
13:29:18.205  DEBUG  ConBeeDeviceState out after
13:29:18.206  DEBUG  ConBeeDeviceState-done
13:29:18.212  DEBUG  CONBEE RX: Data 0A 04 00 09 00 02 00 09 01 DD FF
13:29:18.217  DEBUG  CONBEE RX Frame: ReadParameterResponse [sequence=4, status=SUCCESS, parameter=DEVICE_TYPE, value=01]
13:29:18.220  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.223  DEBUG  ConBeeDeviceState-sync
13:29:18.223  DEBUG  TX CONBEE queue: 1
13:29:18.234  DEBUG  ConBeeDeviceState-done
13:29:18.235  DEBUG  TX CONBEE queue: 1 sync
13:29:18.237  DEBUG  TX CONBEE queue: 1 send
13:29:18.240  DEBUG  CONBEE TX: DeviceStateRequest [sequence=5]
13:29:18.253  DEBUG  CONBEE TX: 07 05 00 08 00 00 00 00 EC FF
13:29:18.255  DEBUG  TX CONBEE queue: 1 exit
13:29:18.269  DEBUG  CONBEE RX: Data 07 05 00 08 00 A2 00 09 41 FF
13:29:18.271  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=5, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.272  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.272  DEBUG  ConBeeDeviceState-sync
13:29:18.273  DEBUG  ConBeeDeviceState out before
13:29:18.274  DEBUG  ConBeeDeviceState out ReadParameterRequest [sequence=0, parameter=MAC_ADDRESS]
13:29:18.275  DEBUG  CONBEE TX: ReadParameterRequest [sequence=6, parameter=MAC_ADDRESS]
13:29:18.278  DEBUG  CONBEE TX: 0A 06 00 08 00 01 00 01 E6 FF
13:29:18.278  DEBUG  ConBeeDeviceState out after
13:29:18.279  DEBUG  ConBeeDeviceState-done
13:29:18.299  DEBUG  CONBEE RX: Data 0A 06 00 10 00 09 00 01 59 89 00 FF FF 2E 21 00 A7 FC
13:29:18.302  DEBUG  CONBEE RX Frame: ReadParameterResponse [sequence=6, status=SUCCESS, parameter=MAC_ADDRESS, value=59 89 00 FF FF 2E 21 00]
13:29:18.304  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.305  DEBUG  ConBeeDeviceState-sync
13:29:18.305  DEBUG  ConBeeDeviceState-done
13:29:18.308  DEBUG  TX CONBEE queue: 1
13:29:18.309  DEBUG  TX CONBEE queue: 1 sync
13:29:18.310  DEBUG  TX CONBEE queue: 1 send
13:29:18.311  DEBUG  CONBEE TX: DeviceStateRequest [sequence=7]
13:29:18.314  DEBUG  CONBEE TX: 07 07 00 08 00 00 00 00 EA FF
13:29:18.315  DEBUG  TX CONBEE queue: 1 exit
13:29:18.329  DEBUG  CONBEE RX: Data 07 07 00 08 00 A2 00 01 47 FF
13:29:18.330  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=7, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.330  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.335  DEBUG  ConBeeDeviceState-sync
13:29:18.337  DEBUG  ConBeeDeviceState out before
13:29:18.338  DEBUG  ConBeeDeviceState out ReadParameterRequest [sequence=0, parameter=NWK_PANID]
13:29:18.339  DEBUG  CONBEE TX: ReadParameterRequest [sequence=8, parameter=NWK_PANID]
13:29:18.342  DEBUG  CONBEE TX: 0A 08 00 08 00 01 00 05 E0 FF
13:29:18.343  DEBUG  ConBeeDeviceState out after
13:29:18.344  DEBUG  ConBeeDeviceState-done
13:29:18.350  DEBUG  CONBEE RX: Data 0A 08 00 0A 00 03 00 05 24 D8 E0 FE
13:29:18.352  DEBUG  CONBEE RX Frame: ReadParameterResponse [sequence=8, status=SUCCESS, parameter=NWK_PANID, value=24 D8]
13:29:18.352  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.353  DEBUG  ConBeeDeviceState-sync
13:29:18.353  DEBUG  ConBeeDeviceState-done
13:29:18.354  DEBUG  TX CONBEE queue: 1
13:29:18.354  DEBUG  TX CONBEE queue: 1 sync
13:29:18.355  DEBUG  TX CONBEE queue: 1 send
13:29:18.355  DEBUG  CONBEE TX: DeviceStateRequest [sequence=9]
13:29:18.357  DEBUG  CONBEE TX: 07 09 00 08 00 00 00 00 E8 FF
13:29:18.358  DEBUG  TX CONBEE queue: 1 exit
13:29:18.365  DEBUG  CONBEE RX: Data 07 09 00 08 00 A2 00 05 41 FF
13:29:18.366  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=9, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.366  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.366  DEBUG  ConBeeDeviceState-sync
13:29:18.369  DEBUG  ConBeeDeviceState out before
13:29:18.370  DEBUG  ConBeeDeviceState out ReadParameterRequest [sequence=0, parameter=APS_EXTENDED_PANID]
13:29:18.371  DEBUG  CONBEE TX: ReadParameterRequest [sequence=10, parameter=APS_EXTENDED_PANID]
13:29:18.373  DEBUG  CONBEE TX: 0A 0A 00 08 00 01 00 0B D8 FF
13:29:18.374  DEBUG  ConBeeDeviceState out after
13:29:18.374  DEBUG  ConBeeDeviceState-done
13:29:18.394  DEBUG  CONBEE RX: Data 0A 0A 00 10 00 09 00 0B 00 00 00 00 00 00 00 00 C8 FF
13:29:18.397  DEBUG  CONBEE RX Frame: ReadParameterResponse [sequence=10, status=SUCCESS, parameter=APS_EXTENDED_PANID, value=00 00 00 00 00 00 00 00]
13:29:18.399  DEBUG  TX CONBEE queue: 1
13:29:18.400  DEBUG  TX CONBEE queue: 1 sync
13:29:18.401  DEBUG  TX CONBEE queue: 1 send
13:29:18.402  DEBUG  CONBEE TX: DeviceStateRequest [sequence=11]
13:29:18.406  DEBUG  CONBEE TX: 07 0B 00 08 00 00 00 00 E6 FF
13:29:18.407  DEBUG  TX CONBEE queue: 1 exit
13:29:18.408  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.409  DEBUG  ConBeeDeviceState-sync
13:29:18.410  DEBUG  ConBeeDeviceState sendFrame!=null
13:29:18.420  DEBUG  CONBEE RX: Data 07 0B 00 08 00 A2 00 0B 39 FF
13:29:18.421  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=11, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.422  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.424  DEBUG  ConBeeDeviceState-sync
13:29:18.425  DEBUG  ConBeeDeviceState out before
13:29:18.426  DEBUG  ConBeeDeviceState out ReadParameterRequest [sequence=0, parameter=NWK_ADDRESS]
13:29:18.427  DEBUG  CONBEE TX: ReadParameterRequest [sequence=12, parameter=NWK_ADDRESS]
13:29:18.437  DEBUG  CONBEE TX: 0A 0C 00 08 00 01 00 07 DA FF
13:29:18.438  DEBUG  ConBeeDeviceState out after
13:29:18.438  DEBUG  ConBeeDeviceState-done
13:29:18.456  DEBUG  CONBEE RX: Data 0A 0C 00 0A 00 03 00 07 00 00 D6 FF
13:29:18.461  DEBUG  CONBEE RX Frame: ReadParameterResponse [sequence=12, status=SUCCESS, parameter=NWK_ADDRESS, value=00 00]
13:29:18.464  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.464  DEBUG  TX CONBEE queue: 1
13:29:18.466  DEBUG  ConBeeDeviceState-sync
13:29:18.467  DEBUG  ConBeeDeviceState-done
13:29:18.469  DEBUG  TX CONBEE queue: 1 sync
13:29:18.470  DEBUG  TX CONBEE queue: 1 send
13:29:18.472  DEBUG  CONBEE TX: DeviceStateRequest [sequence=13]
13:29:18.488  DEBUG  CONBEE TX: 07 0D 00 08 00 00 00 00 E4 FF
13:29:18.491  DEBUG  TX CONBEE queue: 1 exit
13:29:18.507  DEBUG  CONBEE RX: Data 07 0D 00 08 00 A2 00 07 3B FF
13:29:18.508  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=13, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.509  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.510  DEBUG  ConBeeDeviceState-sync
13:29:18.511  DEBUG  ConBeeDeviceState out before
13:29:18.512  DEBUG  ConBeeDeviceState out ReadParameterRequest [sequence=0, parameter=NWK_EXTENDED_PANID]
13:29:18.512  DEBUG  CONBEE TX: ReadParameterRequest [sequence=14, parameter=NWK_EXTENDED_PANID]
13:29:18.526  DEBUG  CONBEE TX: 0A 0E 00 08 00 01 00 08 D7 FF
13:29:18.527  DEBUG  ConBeeDeviceState out after
13:29:18.528  DEBUG  ConBeeDeviceState-done
13:29:18.546  DEBUG  CONBEE RX: Data 0A 0E 00 10 00 09 00 08 59 89 00 FF FF 2E 21 00 98 FC
13:29:18.549  DEBUG  CONBEE RX Frame: ReadParameterResponse [sequence=14, status=SUCCESS, parameter=NWK_EXTENDED_PANID, value=59 89 00 FF FF 2E 21 00]
13:29:18.555  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.557  DEBUG  TX CONBEE queue: 1
13:29:18.571  DEBUG  TX CONBEE queue: 1 sync
13:29:18.573  DEBUG  TX CONBEE queue: 1 send
13:29:18.574  DEBUG  CONBEE TX: DeviceStateRequest [sequence=15]
13:29:18.578  DEBUG  CONBEE TX: 07 0F 00 08 00 00 00 00 E2 FF
13:29:18.579  DEBUG  TX CONBEE queue: 1 exit
13:29:18.581  DEBUG  ConBeeDeviceState-sync
13:29:18.581  DEBUG  ConBeeDeviceState sendFrame!=null
13:29:18.590  DEBUG  CONBEE RX: Data 07 0F 00 08 00 A2 00 08 38 FF
13:29:18.604  DEBUG  CONBEE RX Frame: DeviceStateResponse [sequence=15, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:29:18.605  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:29:18.606  DEBUG  ConBeeDeviceState-sync
13:29:18.607  DEBUG  ConBeeDeviceState out before
13:29:18.608  DEBUG  ConBeeDeviceState out ReadParameterRequest [sequence=0, parameter=CURRENT_CHANNEL]
13:29:18.612  DEBUG  CONBEE TX: ReadParameterRequest [sequence=16, parameter=CURRENT_CHANNEL]
13:29:18.626  DEBUG  CONBEE TX: 0A 10 00 08 00 01 00 1C C1 FF
13:29:18.628  DEBUG  ConBeeDeviceState out after
13:29:18.632  DEBUG  ConBeeDeviceState-done
13:29:18.641  DEBUG  CONBEE RX: Data 0A 10 00 09 00 02 00 1C 19 A6 FF
13:29:18.645  DEBUG  CONBEE RX Frame: ReadParameterResponse [sequence=16, status=SUCCESS, parameter=CURRENT_CHANNEL, value=19]
13:29:18.651  DEBUG  TX CONBEE queue: 1
13:29:18.652  DEBUG  TX CONBEE queue: 1 sync
13:29:18.665  DEBUG  TX CONBEE queue: 1 send
13:29:18.667  DEBUG  CONBEE TX: DeviceStateRequest [sequence=17]
13:29:18.677  DEBUG  CONBEE TX: 07 11 00 08 00 00 00 00 E0 FF
13:29:18.679  DEBUG  TX CONBEE queue: 1 exit
13:29:18.680  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_OFFLINE, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:29:18.682  DEBUG  ConBeeDeviceState-sync
13:29:18.684  DEBUG  ConBeeDeviceState sendFrame!=null
13:29:18.704  DEBUG  CONBEE RX: Data 07 00 08 00 A2 00 1C 22 FF

EDIT: 20minutes after start I've logged CONBEE RX Frame has inconsistent sequece: RX1 // TX17. Added for completeness:

13:29:18.704  DEBUG  CONBEE RX: Data 07 00 08 00 A2 00 1C 22 FF
13:50:20.831  DEBUG  CONBEE RX: Data 0A 52 61 73 70 42 65 65 20 42 6F 6F 74 6C 6F 61 64 65 72 20 70 72 65 6D 69 75 6D 0A 56 65 72 73 2E 20 31 2E 30 32 0A 62 75 69 6C 64 20 32 30 31 33 2F 30 38 2F 30 31 0A 53 54 41 52 54 49 4E 47 20 41 50 50 0A
13:50:20.833  DEBUG  CONBEE RX: Data 0E 01 00 07 00 81 00 69 FF
13:50:20.834  DEBUG  CONBEE RX Frame: DeviceStateChanged [sequence=1, status=SUCCESS, state=DeviceState [networkState=NET_JOINING, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]]
13:50:20.835  DEBUG  CONBEE RX Frame has inconsistent sequece: RX1 // TX17
13:50:20.836  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_JOINING, dataConfirm=false, dataIndication=false, dataRequest=false, configChanged=false]
13:50:20.836  DEBUG  ConBeeDeviceState-sync
13:50:20.837  DEBUG  ConBeeDeviceState sendFrame!=null
13:50:21.344  DEBUG  CONBEE RX: Data 0E 02 00 07 00 A2 00 47 FF
13:50:21.345  DEBUG  CONBEE RX Frame: DeviceStateChanged [sequence=2, status=SUCCESS, state=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]]
13:50:21.346  DEBUG  CONBEE RX Frame has inconsistent sequece: RX2 // TX17
13:50:21.346  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
13:50:21.347  DEBUG  ConBeeDeviceState-sync
13:50:21.347  DEBUG  ConBeeDeviceState sendFrame!=null

@cdjackson
Copy link
Member

cdjackson commented Jun 11, 2019 via email

@curlyel
Copy link

curlyel commented Jun 12, 2019

Hi Chris,
Thanks for the guidance, it encouraged me still trying to get the IDE up ;-)

But: I gave up on doing it on the RaspberryPi directly, since the Eclipse version available for Raspbian-arm32 is probably to old (version 3.8). If I got it right, it does not support Java 1.8. So I guess, I had no chance...

2nd try:
I decided to install the IDE on an Windows system and connected the RaspBEE sitting on the Pi's TTL UART via ser2net to a Windows virtual COM-port. This setup works - So I can run the console from within the IDE now :-) And of course: Commands are now working too ;-)

e.g.

11:19:15.938  DEBUG  CONBEE TX: QuerySendDataRequest [sequence=185]
11:19:15.939  DEBUG  CONBEE TX: 04 B9 00 07 00 00 00 3C FF
11:19:15.939  DEBUG  ConBeeDeviceState-done
11:19:15.998  DEBUG  CONBEE RX: Data 04 B9 00 13 00 0C 00 22 74 02 00 00 00 00 00 00 00 00 00 8C FE
11:19:15.998  DEBUG  CONBEE RX Frame: QuerySendDataResponse [sequence=185, networkState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false], destinationAddress=(NWK=0/0), requestId=116]
11:19:15.998  DEBUG  ConBeeDeviceState=DeviceState [networkState=NET_CONNECTED, dataConfirm=false, dataIndication=false, dataRequest=true, configChanged=false]
11:19:15.998  DEBUG  ConBeeDeviceState-sync
11:19:15.998  DEBUG  ConBeeDeviceState-done
nodes
Network  Addr  IEEE Address       Logical Type   EP   Profile                    Device Type      Manufacturer     Model          
      0  0000  00212EFFFF008959   COORDINATOR   
  36044  8CCC  8418260000D98CCF   ROUTER       

node 36044
IEEE Address     : 8418260000D98CCF
Network Address  : 36044
Node Descriptor  : NodeDescriptor [apsFlags=0, bufferSize=64, complexDescriptorAvailable=false, manufacturerCode=48042, logicalType=ROUTER, serverCapabilities=[], incomingTransferSize=0, outgoingTransferSize=0, userDescriptorAvailable=false, frequencyBands=[FREQ_2400_MHZ], macCapabilities=[MAINS_POWER, RECEIVER_ON_WHEN_IDLE, FULL_FUNCTION_DEVICE], extendedEndpointListAvailable=true, extendedSimpleDescriptorListAvailable=true, stackCompliance=0]
Power Descriptor : RECEIVER_ON_IDLE, [MAINS, RECHARGABLE_BATTERY, DISPOSABLE_BATTERY], MAINS, FULL
Associations     : []
Endpoints        : 
Neighbors:
Routes:

I have to admit, that I was not able to form a new zigbee network through the console so far and bring it to "join enable" to discover an Osram bulb ("join enable" command worked, but did not brought the bulb to join after resetting it of course ;-)) .
Therefore I used DeCONZ to do the join and copied over the PAN and Nwkey to the ZigbeeConsole for the first steps. Is this likely the reason, why no endpoint for the bulb have been discovered?

For sure, I need more time to understand the right sequence when playing with the console ;-)

So I have two questions for now:
Can I split/separate/redirect the (extensive ;-)) logging output in the console window from the console input/output?
What is the intended sequence to bring up an Zigbee-PAN, bring it to accept joins and discover clusters supported by the endpoints?

@cdjackson
Copy link
Member

cdjackson commented Jun 12, 2019 •
edited

Is this likely the reason, why no endpoint for the bulb have been discovered?

No - the framework will try to discover endpoints if they are unknown at startup. You will have to tell the system that the device exists, or maybe it will occur automatically simply by power cycling the bulb if the device sends an ANNOUNCE message (which it should).

Can I split/separate/redirect the (extensive ;-)) logging output in the console window from the console input/output?

Yes, you can adjust the logging in the log4j.xml file and set up different files etc if you prefer.

What is the intended sequence to bring up an Zigbee-PAN,

From the command line, set the PAN / EPAN etc, and use the reset parameter to initialise the network. There are other ways, but this is the easiest.

bring it to accept joins

Use the join command

discover clusters supported by the endpoints?

This is automatic.

@curlyel
Copy link

curlyel commented Jun 12, 2019

Chris,
after some minutes, the ZigbeeConsole stalles with a couple of threads waiting for Thread [pool-2-thread-3]

I've suspended this thread and took the screenshot below. I started digging into the variables/objects - but don't know where to look after ;-)

image

@curlyel
Copy link

curlyel commented Jun 12, 2019

No - the framework will try to discover endpoints if they are unknown at startup. You will have to tell the system that the device exists, or maybe it will occur automatically simply by power cycling the bulb if the device sends an ANNOUNCE message (which it should).

Ok. did this (a couple of times). Thought it was more complicated ;-) I'm going to try another device...
And, thanks for the logging hint too...

@cdjackson
Copy link
Member

after some minutes, the ZigbeeConsole stalles

This is the problem that we need to resolve. You need to spend some time to work out why this is happening...

@curlyel
Copy link

curlyel commented Jun 12, 2019

Sorry Chris,
I'm afraid, I'm not really in the position yet to work out something... :-(

Yes, the console is talking (RX and TX) from/to the ConBEE but I think we do not get any packets back from the Zigbee network. The zigbee library tries to discover the endpoints etc. as you said, but all the discoveries end up with timeout:
-dongle CONBEE -port COM9 -baud 38400 -flow software -channel 25 -pan 0xd824 -epan 1 -nwkkey 0xcccccccccccccccccccccccccccccccc -linkkey 0x<deleted> -reset

15:21:53.859  DEBUG  8418260000D98CCF: Node SVC Discovery: ActiveEndpointsResponse returned CommandResult [TIMEOUT]
15:21:53.859  DEBUG  8418260000D98CCF: Node SVC Discovery: request ACTIVE_ENDPOINTS failed. Retry 2, wait 2329ms before retry.
15:21:54.784  DEBUG  00212EFFFF008959: Node SVC Discovery: ManagementRoutingRequest returned CommandResult [TIMEOUT]
15:21:54.784  DEBUG  00212EFFFF008959: Node SVC Discovery: request ROUTES failed. Retry 2, wait 4450ms before retry.
15:21:54.877  DEBUG  001788011051E209: Node SVC Discovery: ActiveEndpointsResponse returned CommandResult [TIMEOUT]
15:21:54.877  DEBUG  001788011051E209: Node SVC Discovery: request ACTIVE_ENDPOINTS failed. Retry 11, wait 9280ms before retry.
....
15:21:56.190  DEBUG  8418260000D98CCF: Node SVC Discovery: running ACTIVE_ENDPOINTS
15:21:56.190  DEBUG  8418260000D98CCF: Added transaction to queue, len=2, transaction=ZigBeeTransaction [queueTime=0, state=WAITING, se
15:22:12.853  DEBUG  8418260000D98CCF: Node SVC Discovery: running ACTIVE_ENDPOINTS
15:22:26.448  DEBUG  DISCOVERY Extension: Starting mesh update
15:22:26.448  DEBUG  DISCOVERY Extension: Starting mesh update for 001788011051E209
15:22:26.448  DEBUG  001788011051E209: Node SVC Discovery: Update mesh
15:22:26.448  DEBUG  001788011051E209: Node SVC Discovery: has no tasks to perform
15:22:26.448  DEBUG  DISCOVERY Extension: Starting mesh update for 8418260000D98CCF
15:22:26.448  DEBUG  8418260000D98CCF: Node SVC Discovery: Update mesh
15:22:26.448  DEBUG  8418260000D98CCF: Node SVC Discovery: already scheduled or running
15:22:26.448  DEBUG  8418260000D98CCF: Node SVC Discovery: scheduled [ACTIVE_ENDPOINTS, NWK_ADDRESS, NEIGHBORS, ROUTES]
15:22:26.448  DEBUG  DISCOVERY Extension: Starting mesh update for 00212EFFFF008959
15:22:26.448  DEBUG  00212EFFFF008959: Node SVC Discovery: Update mesh
15:22:26.448  DEBUG  00212EFFFF008959: Node SVC Discovery: already scheduled or running
15:22:26.448  DEBUG  00212EFFFF008959: Node SVC Discovery: scheduled [ROUTES, NEIGHBORS]
15:22:26.764  DEBUG  8418260000D98CCF: Node SVC Discovery: running ACTIVE_ENDPOINTS
15:22:28.595  DEBUG  00212EFFFF008959: Node SVC Discovery: running ROUTES

To check if it is dongle dependend, I digged out some CC2531 and started the console against it (directly plugged into the Windows PC not the Pi):

-dongle CC2531 -port COM3 -baud 9600 -flow software -pan 0x1234 -epan 987654321 -reset

nodes
Network  Addr  IEEE Address       Logical Type   EP   Profile                    Device Type      Manufacturer     Model          
      0  0000  00124B0009EB11FC   UNKNOWN       

> 15:43:50.933  DEBUG  Transaction complete: ZigBeeTransaction [queueTime=10052, state=FAILED, sendCnt=1, command=PowerDescriptorRequest [0/0 -> 0/0, cluster=0003, TID=1F, nwkAddrOfInterest=0]]
15:43:50.933  DEBUG  transactionListenerRemoved: 0 outstanding
15:43:50.933  DEBUG  00124B0009EB11FC: transactionComplete FAILED 0
15:43:50.933  DEBUG  00124B0009EB11FC: Added transaction to queue, len=1, transaction=ZigBeeTransaction [queueTime=10052, state=WAITING, sendCnt=1, command=PowerDescriptorRequest [0/0 -> 0/0, cluster=0003, TID=1F, nwkAddrOfInterest=0]]
15:43:52.892  DEBUG  00124B0009EB11FC: Node SVC Discovery: PowerDescriptorResponse returned null
15:43:52.892  DEBUG  00124B0009EB11FC: Node SVC Discovery: request POWER_DESCRIPTOR failed after 13 attempts.
15:43:52.893  DEBUG  00124B0009EB11FC: Node SVC Discovery: complete
15:43:52.893  DEBUG  00124B0009EB11FC: Node 0 update
15:43:52.895  DEBUG  00124B0009EB11FC: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=1, interTransactionDelay=50, maxRetries=2]
... <restart>...
15:50:50.972  DEBUG  CC2531 transport initialize
15:50:50.972  DEBUG  Opening port COM3 at 9600 baud with FLOWCONTROL_OUT_XONOFF.
15:50:50.996  DEBUG  ->  SYS_RESET (Packet: subsystem=null, length=1, apiId=41 00, data=FE 01 41 00 01 41, checksum=41, error=false) 
15:50:53.340  DEBUG  <-- SYS_RESET_RESPONSE (FE 06 41 80 00 02 00 02 06 03 C2)
15:50:53.340  DEBUG  Received Async Cmd: Packet: subsystem=null, length=6, apiId=41 80, data=FE 06 41 80 00 02 00 02 06 03 C2, checksum=C2, error=false
15:50:53.342  DEBUG  ->  SYS_VERSION (Packet: subsystem=null, length=0, apiId=21 02, data=FE 00 21 02 23, checksum=23, error=false) 
15:50:53.347  DEBUG  <-  SYS_VERSION_RESPONSE (FE 05 61 02 02 00 02 06 03 63)
15:50:53.347  DEBUG  CC2531 version is Software=2.6 Product=0 Hardware=3 Transport=2
15:50:53.348  DEBUG  ->  ZB_GET_DEVICE_INFO (Packet: subsystem=null, length=1, apiId=26 06, data=FE 01 26 06 01 20, checksum=20, error=false) 
15:50:53.351  DEBUG  <-  ZB_GET_DEVICE_INFO_RSP (FE 09 66 06 01 FC 11 EB 09 00 4B 12 00 3E)
networkManager.initialize returned SUCCESS
15:50:53.352  DEBUG  ->  ZB_GET_DEVICE_INFO (Packet: subsystem=null, length=1, apiId=26 06, data=FE 01 26 06 06 27, checksum=27, error=false) 
15:50:53.356  DEBUG  <-  ZB_GET_DEVICE_INFO_RSP (FE 09 66 06 06 00 20 EB 09 00 4B 12 00 F4)
PAN ID          = 8192
15:50:53.356  DEBUG  ->  ZB_GET_DEVICE_INFO (Packet: subsystem=null, length=1, apiId=26 06, data=FE 01 26 06 07 26, checksum=26, error=false) 
15:50:53.359  DEBUG  <-  ZB_GET_DEVICE_INFO_RSP (FE 09 66 06 07 21 43 65 87 09 00 00 00 E7)
Extended PAN ID = 0000000987654321
15:50:53.360  DEBUG  ->  ZB_GET_DEVICE_INFO (Packet: subsystem=null, length=1, apiId=26 06, data=FE 01 26 06 05 24, checksum=24, error=false) 
15:50:53.364  DEBUG  <-  ZB_GET_DEVICE_INFO_RSP (FE 09 66 06 05 0B 43 65 87 09 00 00 00 CF)
Channel         = CHANNEL_11
*** Resetting network
  * Channel                = 11
  * PAN ID                 = 4660
  * Extended PAN ID        = 0000000987654321
  * Link Key               = 5A6967426565416C6C69616E63653039
  * Network Key            = 26986B784C67F47F2561479A245E8096
15:50:53.367  DEBUG  ->  ZB_WRITE_CONFIGURATION (Packet: subsystem=null, length=6, apiId=26 05, data=FE 06 26 05 84 04 00 08 00 00 AD, checksum=AD, error=false) 
15:50:53.377  DEBUG  <-  ZB_WRITE_CONFIGURATION_RSP (FE 01 66 05 00 62)
15:50:53.377  DEBUG  ->  ZB_WRITE_CONFIGURATION (Packet: subsystem=null, length=4, apiId=26 05, data=FE 04 26 05 83 02 34 12 80, checksum=80, error=false) 
15:50:53.387  DEBUG  <-  ZB_WRITE_CONFIGURATION_RSP (FE 01 66 05 00 62)
15:50:53.387  DEBUG  ->  ZB_WRITE_CONFIGURATION (Packet: subsystem=null, length=10, apiId=26 05, data=FE 0A 26 05 2D 08 21 43 65 87 09 00 00 00 85, checksum=85, error=false) 
15:50:53.396  DEBUG  <-  ZB_WRITE_CONFIGURATION_RSP (FE 01 66 05 00 62)
15:50:53.397  DEBUG  ->  ZB_WRITE_CONFIGURATION (Packet: subsystem=null, length=18, apiId=26 05, data=FE 12 26 05 62 10 26 98 6B 78 4C 67 F4 7F 25 61 47 9A 24 5E 80 96 BB, checksum=BB, error=false) 
15:50:53.410  DEBUG  <-  ZB_WRITE_CONFIGURATION_RSP (FE 01 66 05 00 62)
15:50:53.410  DEBUG  ->  SYS_SET_TX_POWER (Packet: subsystem=null, length=1, apiId=21 14, data=FE 01 21 14 03 37, checksum=37, error=false) 
15:50:53.413  DEBUG  <-  ZToolPacket (FE 01 61 14 03 77)
15:50:53.414  DEBUG  Unsupported configuration option "TRUST_CENTRE_LINK_KEY" in CC2531 dongle
15:50:53.414  DEBUG  CC2531 transport startup

Even with the CC2531 I'm not able to join resetted bulbs from Osram and Philips.
Honestly, I feel a bit lost :-(

Meanwhile I tried the master branch as well as the release-1.10.
Firmware on the RaspBEE is version 26330500.

Since both dongles are not working as expected, I'd assume some flaw on my side. Any hints how to proceed?

@cdjackson
Copy link
Member

Even with the CC2531 I'm not able to join resetted bulbs from Osram and Philips.

Both the ConBee and the CC2531 drivers work. The ConBee is not reliable due to the issue you identify above, and that is what needs to be resolved. The CC2531 is perfectly reliable and used extensively - both by users of openHAB, and some customers running under Android and also Java.

Since both dongles are not working as expected, I'd assume some flaw on my side

Yes, this is likely the case. Unfortunately I'm not really sure what to suggest. I test with the 2531 quite often and it should work fine. I don't really see anything wrong with the log above either.

@curlyel
Copy link

curlyel commented Jun 12, 2019 •
edited

The CC2531 is perfectly reliable and used extensively - ... by users of openHAB

Yes, I know. I am one of them. I do have CC2531 running in two openHAB instances too.
For that I'm very grateful to you, Chris!

don't really see anything wrong with the log above either.

Shouldn't we see some reply packets as response to the discoveries (endpoint, routes etc.)?

Once I start the Dresden software, I can immediately let join bulbs and control them. The CC2531 was in use on openHAB too. Therefore I assume the hardware is working fine in both cases.

The Zigbee console is "talking" to the dongles. But somehow, my Zigbee PAN created with it, seems odd. Could you please have a last look on my command line parameters?
Did I made some wrong initialization?

-dongle CONBEE -port COM9 -baud 38400 -flow software -channel 25 -pan 0xd824 -epan 1 -nwkkey 0xcccccccccccccccccccccccccccccccc -linkkey 0x<deleted> -reset

and for the CC2531

-dongle CC2531 -port COM3 -baud 9600 -flow software -pan 0x1234 -epan 987654321 -reset

Thanks for your patience and sorry for not being a big help here ;-)

@cdjackson
Copy link
Member

I know. I am one of them.

Why are you looking at the ConBee then as a matter of interest? Is it just that you are looking for a solution to work "neatly" with the RPi? If so, I may soon be able to supply an Ember solution using the latest Ember Chipset (the EFR32) if that's of interest?

Shouldn't we see some reply packets as response to the discoveries (endpoint, routes etc.)?

Well, there are no packets being sent. The log doesn't provide that information. The first log doesn't have that, and the second log looks like it's part of the startup, and is only doing the initialisation.

Even if frames are sent, the fact that there are no responses doesn't make it an error with the software. Of course we expect replies in this case, but not receiving a reply is also valid and it's hard to know what happens without a lot more information (eg sniffer logs).

But somehow, my Zigbee PAN created with it, seems odd.

What looks odd? I don't immediately see anything wrong...

Did I made some wrong initialization?

No - it looks ok. Normally the 2351 uses 38400 baud rate I think, but as it is communicating, it probably doesn't matter as it's a direct USB link.

@curlyel
Copy link

curlyel commented Jun 13, 2019

Is it just that you are looking for a solution to work "neatly" with the RPi?

Yes and no. ;-)
I do have the RaspBEE modules here and would give them a try due to the expectation, that they have better reception sensitivity and more transmit power - and yes - will fit into Rpi.

BUT: I'm not in need to get it work, since I already have a reliable solution with the CC2531's already (as you know). Again: I'm a happy user of your Zigbee as well as of the ZWave binding ;-)

The main reason for digging out this issue was my thought it would be a chance giving something back to the community. Since I'm not a Java developer, I cannot contribute with coding etc ...
But I have plenty of zigbee hardware and a rough understanding how it should work together - So I was hoping I could drive some long-run tests to help isolating the cause ;-)

What looks odd?

I meant: I wasn't able to join any device to my Zigbee networks created with the Zigbee console so I assumed that I have created some oddity in my test Zigbee networks ;-)

@cdjackson
Copy link
Member

I do have the RaspBEE modules here and would give them a try due to the expectation, that they have better reception sensitivity and more transmit power - and yes - will fit into Rpi.

I would treat this with some level of doubt. The problem with sensitivity specifications is it needs to be against a specific BER or PER. I'm not sure what this is for Atmel - I know what it is for the Silabs chips as they quote with a 1% PER which is very good (this means only 1 packet in 100 is lost). Others may quote at 20% PER - I'm not sure about Atmel. I also note that the numbers quoted in the ConBee spec are considerably better than quoted by Atmel, which seems strange given that the ConBee/RaspBee is simply this single Atmel chip.

So, please be a little careful about just looking at the numbers. It's also worth noting that RF power is generally limited by law (eg CE requirements).

So I was hoping I could drive some long-run tests to help isolating the cause ;-)

That's great that you want to help. Unfortunately it also needs someone with coding skills to look into this I think as it's a low level problem that probably won't be solved just by looking at logs. I do have these devices and wrote the initial driver for it, but nearly all commercial customers use the Silabs chipset, and some are using the TI (although TI told me recently they are not planning any further updates to their stack so I would not recommend that in future).

I meant: I wasn't able to join any device to my Zigbee networks created with the Zigbee console so I assumed that I have created some oddity in my test Zigbee networks ;-)

Ok, agreed - it doesn't work, but my point is there is nothing abnormal in the logs you provided. The logs don't show any joining attempts, or even the general operation of the stack as it is still in the initialisation phase. So, while it's not working, there's nothing actually wrong anywhere - based on the logs I see at least.

@cdjackson cdjackson added the pinned Will not be closed, even if stale label Oct 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CONBEE help wanted pinned Will not be closed, even if stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cdjackson @saurabh984 @curlyel