zsmartsystems/com.zsmartsystems.zigbee

ZigBee Cluster Library Java framework supporting multiple dongles

com.zsmartsystems.zigbee's Issues

License goal not working

@hsudbrock the change you made to the pom seems to complete stop the license formatter...

Any thoughts on how to resolve this so it works in both scenarios?

Occasional EMBER_NOT_JOINED on startup

When code starts up, sometimes the network does not form and the chip starts returning EMBER_NOT_JOINED on init.

Telegesis dongle doesn't work if OK prompt is disabled

Prompt defaults to ON, but if it is disabled by other software the driver fails. The driver should enable this prompt before doing anything else.

Mesh update exception and Readsync exception at shutdown

2.3.0.201801052345

When stopping the zigbee binding, the "Mesh update exception' occurs every time, but always only five times. Five of my devices are currently powered off (one battery and 4 GE Link bulbs). The 'Readsync exception' occurs right before these, but not every time. After starting again, everything looks good.

010618 readsync exception.zip

Correction... six devices are powered off (one battery and five bulbs).

Failed to update firmware for EMBER EFR32MG

I am receiving 'Received CAN' message while trying to update the firmware of the dongle.

Opening port /dev/ttyS2 at 115200 baud with FLOWCONTROL_OUT_NONE.
Ember bootloader: Serial port opened.
Ember bootloader: Got bootloader prompt.
Dongle firmware status: FIRMWARE_TRANSFER_STARTED.
Ember bootloader: Clearing input stream...
Ember bootloader: Starting transfer.
Ember bootloader: Transfer frame 1, attempt 0.
Ember bootloader: Received CAN.
Ember bootloader: Transfer failed.

Node concurrency issues

ZigBeeNode (and maybe Endpoint?) lists (Neighbours, Routes...) should use concurrent maps.

Network state serialisation should be managed in the network manager

The coordinator should always be the first node added to the network to ensure that it exists when notifications are sent to users when other nodes are added.

Possibly modify the serialisation to ensure this is controlled - but this could be difficult since serialisation is managed outside of the framework. An alternative could be for the serialisation to return the list of deserialised nodes rather than it adding the nodes itself.

Another option is not to send notifications if the coordinator is not known, and then when the coordinator is added, send notifications for all nodes at that time.

Create stand-alone log viewer

Migrate console commands into reusable package

Migrate the console command processors into a separate package - ie separate from the console main application. This would allow the command processors to be used within another console application.

Unable to join Phillips Hue dimmer switch

I'm attempting to get a Phillips Hue dimmer switch to talk to a HUSBZB-1. Obviously a pretty untested setup, but I'd love to get this working, as there are just so few battery-powered switches/dimmers out there. This is less an 'issue' and more just opening a discussion. TLDR on this: It doesn't seem, out of the box, the switch is replying to discovery with it's own sender network ID, but with 0 as the sender. So the stack doesn't see the replies.

Where we seem to be stuck is, we send out an IeeeAddressRequest:
02:51:29.704 DEBUG TX CMD: IeeeAddressRequest [0/0 -> 2858/0, cluster=0001, TID=5C, nwkAddrOfInterest=2858, requestType=1, startIndex=0]

And we do get a response -- with a sender of 0, not 2858. So it never 'sees' the response (as it expects the sender of the response to match the destination of the request).

02:51:29.740 TRACE <-- RX ASH frame: AshFrameData [frmNum=0, ackNum=0, reTx=false, data=5C 90 45 00 00 00 01 80 00 00 40 01 00 00 2C FF 00 00 00 FF FF 0D 00 00 32 6F 19 02 01 88 17 00 2A 0B 00]
02:51:29.742 DEBUG RX CMD: IeeeAddressResponse [0/0 -> 0/0, cluster=8001, TID=NULL, status=SUCCESS, ieeeAddrRemoteDev=0017880102196F32, nwkAddrRemoteDev=2858, numAssocDev=0, startIndex=null, nwkAddrAssocDevList=[]]
02:51:39.707 DEBUG Ieee Address for 2858 returned null

I'm unclear as to why the sender isn't set -- I think it might be possible that the dongle may be intercepting the request (since it knows the 'right answer'? AFAIK it should treat this as any other unicast command, but... it is not) At any rate, I changed this in zdo/command/IeeeAddressRequest.java (I'm not sure this is a good idea for everybody, but for my setup, it doesn't matter for the time being, as it should be correct on anything but a router I think):

// return (((IeeeAddressRequest) request).getDestinationAddress()
// .equals(((IeeeAddressResponse) response).getSourceAddress()));
return (((IeeeAddressRequest) request).getNwkAddrOfInterest()
.equals(((IeeeAddressResponse) response).getNwkAddrRemoteDev()));

Things continued well after that and other messages have the correct response (including sender). I can use the console to query stuff on the device, but the buttons on the switch don't seem to do anything. With that said, the extent of my testing there was pushing a button, seeing nothing in the logs, and deciding it is time for bed.

Perhaps a better solution is when:

RX EZSP: EzspChildJoinHandler [index=0, joining=true, childId=25851, childEui64=0017880102196F32, childType=EMBER_SLEEPY_END_DEVICE]

Is received, start the discovery process on the second step and skip the IEEE address discovery, since we were already told. Unfortunately, the childType is not passed up into the discovery stack, and I think the ieee address discovery step needs to happen for routers.

Telegesis: waiting for TelegesisNetworkLeftEvent results in timeout

The default timeout is 500ms, but this transaction takes longer - just over 1 second in the case below, but maybe longer?

19:28:24.806 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TX Telegesis: TelegesisLeaveNetworkCommand []
19:28:24.807 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TELEGESIS TX: Data 41 54 2B 44 41 53 53 4C 0D 0A
19:28:24.929 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 4F 4B
19:28:25.436 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Error leaving network: No event received

19:28:25.832 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisNetworkLeftEvent []

openhab/org.openhab.binding.zigbee#125

Mesh update node changed check not working

When the mesh update completes, it copies the new data into the node. It then does a check to see if the node has changed, and if so, it then sends the notification to listeners. Since the node is updated already, the check always fails and notifications are not sent.

The update of the node in the mesh update code should be looked at to improve this.

#183

Handling of attributes that may not be of ZCL defined type

As seen in this issue some devices may report an incorrect data type.

Below the device is reporting an unsigned 8 bit int which is inconsistent with the ZCL definition which is boolean...

09:50:12.811 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [On/Off: 7287/1 -> 0/1, cluster=0006, TID=FC, records=[Read Attribute Status Record: attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, status=0, attributeValue=1]]

Maybe we should ignore the device reported type and just use the ZCL defined type.

Karaf NPE: ZigBeeCommandNotifier.java

Zigbee binding 2.3.0.201801042145

In case it is related, I had a bulb that refused to come online, so I reset it and rediscovered. I also had recently updated the binding before I noticed this. I have some debug logs, if you want them.

Exception in thread "pool-3555-thread-2" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.zcl.ZclAttributeNormalizer.normalizeZclData(ZclAttributeNormalizer.java:24)
        at com.zsmartsystems.zigbee.zcl.ZclCluster.handleAttributeStatus(ZclCluster.java:843)
        at com.zsmartsystems.zigbee.ZigBeeEndpoint.commandReceived(ZigBeeEndpoint.java:410)
        at com.zsmartsystems.zigbee.ZigBeeNode.commandReceived(ZigBeeNode.java:680)
        at com.zsmartsystems.zigbee.ZigBeeCommandNotifier$1.run(ZigBeeCommandNotifier.java:65)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Philips Hue Dimmer Off command not working

I've been testing the On/Off switch functionality with a Philips Hue Dimmer. The device pairs and is discovered in OH.

Pressing the 'on' button on the Dimmer works and the OH channel updates to ON correctly but when pressing the 'off' button the library does not translate the zigbee packet into an off command,

From what I've gathered purely from reading the src it looks like there is a mismatch between what the dimmer sends for the commandId (64) and what is expected for an off command (0).

Here's the 'on' button press log:

2018-02-21 22:41:09.981 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 33 44 33 45 2C 30 31 30 34 2C 30 31 2C 30 31 2C 30 30 30 36 2C 30 33 3A 01 14 01 2C 2D 35 31 2C 46 46
2018-02-21 22:41:09.986 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=15678, profileId=260, destinationEp=1, sourceEp=1, clusterId=6, messageData=01 14 01, rssi=-81, lqi=255]
2018-02-21 22:41:09.991 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=15678, profileId=260, destinationEp=1, sourceEp=1, clusterId=6, messageData=01 14 01, rssi=-81, lqi=255]
2018-02-21 22:41:09.995 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=15678/1, destinationAddress=0/1, profile=0104, cluster=6, addressMode=null, radius=0, sequence=0, payload=01 14 01]
2018-02-21 22:41:10.000 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=CLUSTER_SPECIFIC_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=false, manufacturerCode=0, sequenceNumber=20, commandId=1]
2018-02-21 22:41:10.005 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: OnCommand [On/Off: 15678/1 -> 0/1, cluster=0006, TID=14]
2018-02-21 22:41:10.009 [DEBUG] [converter.ZigBeeConverterSwitchOnoff] - 0017880103E47DAF: ZigBee command receiveds OnCommand [On/Off: 15678/1 -> 0/1, cluster=0006, TID=14]
2018-02-21 22:41:10.014 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103E47DAF: Channel zigbee:device:zigbee:0017880103e47daf:0017880103E47DAF_1_switch_onoff updated to ON

Here's the 'off' button press log:

2018-02-21 22:39:42.435 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 33 44 33 45 2C 30 31 30 34 2C 30 31 2C 30 31 2C 30 30 30 36 2C 30 35 3A 01 12 40 00 00 2C 2D 35 31 2C 46 46
2018-02-21 22:39:42.441 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=15678, profileId=260, destinationEp=1, sourceEp=1, clusterId=6, messageData=01 12 40 00 00, rssi=-81, lqi=255]
2018-02-21 22:39:42.448 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=15678, profileId=260, destinationEp=1, sourceEp=1, clusterId=6, messageData=01 12 40 00 00, rssi=-81, lqi=255]
2018-02-21 22:39:42.469 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=15678/1, destinationAddress=0/1, profile=0104, cluster=6, addressMode=null, radius=0, sequence=0, payload=01 12 40 00 00]
2018-02-21 22:39:42.478 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=CLUSTER_SPECIFIC_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=false, manufacturerCode=0, sequenceNumber=18, commandId=64]
2018-02-21 22:39:42.488 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - No command type found for CLUSTER_SPECIFIC_COMMAND, cluster=6, command=64, direction=CLIENT_TO_SERVER
2018-02-21 22:39:42.491 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Incoming message did not translate to command.

Support EZSP version 5 and later.

Attribute reporting class cast exception

java.lang.ClassCastException: com.zsmartsystems.zigbee.zcl.clusters.general.ReportAttributesCommand cannot be cast to com.zsmartsystems.zigbee.zcl.clusters.general.ReadAttributesResponse
        at com.zsmartsystems.zigbee.zcl.ZclCluster.readSync(ZclCluster.java:214) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at com.zsmartsystems.zigbee.zcl.clusters.ZclOnOffCluster.getOnOff(ZclOnOffCluster.java:113) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.converter.ZigBeeConverterSwitchLevel.initializeConverter(ZigBeeConverterSwitchLevel.java:93) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:229) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:171) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:165) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

closes openhab/org.openhab.binding.zigbee#72

Example code

Is there any example code available associated with this repository? I'm looking at getting into the ZigBee market (mainly for Philips HUE at the moment) and I'm looking for a decent Java library that I can utilize.

This looks promising (commits in the last few days) but I would like to see some example code before actually buying any products.

XBee getPanID returns error

This XBee returns a command not supported error when requesting the PAN ID.

2018-03-29 15:07:19.310 [DEBUG] [ongle.xbee.internal.XBeeFrameHandler] - TX XBEE: XBeeGetPanIdCommand [frameId=16]
2018-03-29 15:07:19.310 [DEBUG] [ongle.xbee.internal.XBeeFrameHandler] - TX XBEE Data: 00 04 08 10 4F 49 4F
2018-03-29 15:07:19.432 [DEBUG] [ongle.xbee.internal.XBeeFrameHandler] - RX XBEE Data: 00 05 88 10 4F 49 02 CD
2018-03-29 15:07:19.433 [DEBUG] [ongle.xbee.internal.XBeeEventFactory] - Error creating instance of XBeeResponse
java.lang.ArrayIndexOutOfBoundsException: 8
	at com.zsmartsystems.zigbee.dongle.xbee.internal.protocol.XBeeFrame.deserializeInt16(XBeeFrame.java:93) [367:com.zsmartsystems.zigbee.dongle.xbee:1.0.8.SNAPSHOT]
	at com.zsmartsystems.zigbee.dongle.xbee.internal.protocol.XBeePanIdResponse.deserialize(XBeePanIdResponse.java:79) [367:com.zsmartsystems.zigbee.dongle.xbee:1.0.8.SNAPSHOT]
	at com.zsmartsystems.zigbee.dongle.xbee.internal.XBeeResponseFactory.getXBeeFrame(XBeeResponseFactory.java:111) [367:com.zsmartsystems.zigbee.dongle.xbee:1.0.8.SNAPSHOT]
	at com.zsmartsystems.zigbee.dongle.xbee.internal.XBeeFrameHandler$1.run(XBeeFrameHandler.java:184) [367:com.zsmartsystems.zigbee.dongle.xbee:1.0.8.SNAPSHOT]

First question is why, second is to avoid the exception.

Avoid duplicate nodes when network address changes

When adding nodes, we need to check the IEEE address to ensure the new node isn't an existing node that has rejoined with a new address.

add a public method to send EzspFrameRequest?

Thoughts on adding a new public method to the ZigBeeDongleEzsp class to allow sending of raw EzspFrameRequest messages? I'm currently re implementing the entire class in order to send some basic commands to the stick.. ie, getting the local ieee and network address of the stick. If this method were added I would be able to use the built in class.

public EzspFrameResponse sendFrameRequest(EzspFrameRequest request, Class responseType) {
EzspSingleResponseTransaction transaction = new EzspSingleResponseTransaction(request, responseType);
ashHandler.sendEzspTransaction(transaction);
return transaction.getResponse();
}

send reset when EmberZNet sends error

According to the docs:

When the NCP enters the FAILED state, the NCP sends an ERROR frame containing a reset or error code and will reply to all subsequent frames received, except RST, with an ERROR frame. To reinitialize the ASH protocol, the Host must reset the NCP by either asserting the nRESET pin or sending the RST frame.

EMBER - reinitialize fails

networkManager.startup(true) is failing because of supplying invalid network key. Following is the log:-

08-13 18:01:03.511 5963-6033/ D/c.z.z.d.e.i.a.AshFrameHandler: [pool-6-thread-1     ] TX EZSP: EzspSetInitialSecurityStateRequest [state=EmberInitialSecurityState [bitmask=[EMBER_HAVE_NETWORK_KEY, EMBER_TRUST_CENTER_GLOBAL_LINK_KEY, EMBER_REQUIRE_ENCRYPTED_KEY, EMBER_NO_FRAME_COUNTER_RESET, EMBER_HAVE_PRECONFIGURED_KEY], preconfiguredKey=EmberKeyData [contents={00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}], networkKey=EmberKeyData [contents={3E 11 25 BC 43 FC 14 31 48 D1 3C 00 CA 3D 00 FF}], networkKeySequenceNumber=0, preconfiguredTrustCenterEui64=0000000000000000]]
08-13 18:01:03.516 5963-6033/ D/c.z.z.d.e.i.a.AshFrameHandler: [pool-6-thread-1     ] --> TX ASH frame: AshFrameData [frmNum=2, ackNum=3, reTx=false, data=4B 00 FF 00 68 04 1B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 11 25 BC 43 FC 14 31 48 D1 3C 00 CA 3D 00 FF 00 00 00 00 00 00 00 00 00]
08-13 18:01:03.532 5963-6032/ D/c.z.z.d.e.i.a.AshFrameHandler: [AshFrameHandler     ] <-- RX ASH frame: AshFrameData [frmNum=3, ackNum=3, reTx=false, data=4B 80 FF 00 68 B2]
08-13 18:01:03.536 5963-6032/ D/c.z.z.d.e.i.a.AshFrameHandler: [AshFrameHandler     ] ASH: Frame acked and removed AshFrameData [frmNum=2, ackNum=3, reTx=false, data=4B 00 FF 00 68 04 1B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 11 25 BC 43 FC 14 31 48 D1 3C 00 CA 3D 00 FF 00 00 00 00 00 00 00 00 00]
08-13 18:01:03.538 5963-6032/ D/c.z.z.d.e.i.a.AshFrameHandler: [AshFrameHandler     ] RX EZSP: EzspSetInitialSecurityStateResponse [status=EMBER_KEY_INVALID]
08-13 18:01:03.539 5963-6032/ D/c.z.z.d.e.i.a.AshFrameHandler: [AshFrameHandler     ] --> TX ASH frame: AshFrameAck [ackNum=4, notRdy=false]
08-13 18:01:03.540 5963-6015/ D/c.z.z.d.e.i.EmberNetworkInitialisation: [pool-1-thread-1     ] EzspSetInitialSecurityStateResponse [status=EMBER_KEY_INVALID]

We have tried:-

1. networkKey = ZigBeeKey.createRandom();
2. networkKey = zigBeeDongleEzsp.getZigBeeNetworkKey();
   In both the above cases, we are getting EMBER_KEY_INVALID.

It worked in 1.0.12. This error is in 1.0.15-SNAPSHOT.

Discovery optimisation

Thoughts to improve discovery -:

• Send a notification when the node is first discovered, so that even if the discovery fails, the application knows that the device was found.
• Don't perform discovery steps if data already known - eg don't ask for IEEE address if we already have it, don't ask for node descriptor if we know it...

add ezsp command setConcentrator

Please add network frame "setConcentrator" to the ezsp command list. frame id: 0x10

From the EZSP Reference Guide:

Name: setConcentrator
ID: 0x10
Description: Enable/disable concentrator support.

[EMBER] Frequent drop offs of devices

Since updating to 1.0.14, all of my GE Link bulbs have been frequently jumping off the network. Sometimes jump back onto it too. After a restart, things usually look good, but within a day there will be a handful that are not responding. The bulbs were much better about staying on the network with 1.0.13. I know when they fall off the network, because they will turn themselves on. But I have also frequently seen lights turning on through automation, like walking into a room, but them some of the bulbs not turning off or dimming properly. By rolling back just the zsmartsystems libraries to 1.0.13, the bulbs stop dropping off as frequently.

The response from the bulbs during pairing looks different too, in that the bulbs flash differently. They usually flash three times. Now, they flash once and then flicker for a while and either drop off the network or start behaving. When I see one flicker out of the blue, I start discovery and this will usually get it back on the network. I left debug on for a day, so I have nearly 1GB of logs(!). I haven't spotted anything that stood out to me, but I do have a lot of these...

zigbee.log.20180801143036:2018-08-01 14:22:35.268 [DEBUG] [s.zigbee.dongle.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspIncomingRouteErrorHandler [status=EMBER_SOURCE_ROUTE_FAILURE, target=46220]
zigbee.log.20180801143036:2018-08-01 14:22:35.268 [DEBUG] [zsmartsystems.zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteErrorHandler [status=EMBER_SOURCE_ROUTE_FAILURE, target=46220]
zigbee.log.20180801143036:2018-08-01 14:22:35.268 [DEBUG] [zsmartsystems.zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteErrorHandler [status=EMBER_SOURCE_ROUTE_FAILURE, target=46220]
zigbee.log.20180801143036:2018-08-01 14:22:46.220 [DEBUG] [com.zsmartsystems.zigbee.zcl.ZclCluster           ] - 15077/1: Error reading attribute 772 in cluster 2820 - UNSUPPORTED_ATTRIBUTE

Let me know if you want more logs... I got plenty of 'em...
zigbee.log.zip

Implement Green Power Commissioning Tool capability

Goal
Implement green power device : GP Commissioning Tool (0x0064)

Need

• Implement missing ezsp frame
• Open a discussion of the best way to do this and support with other dongle

Request

• create a new branch to develop this functionalities
• add on this branch ezsp frame (information from UG100: EZSP Reference Guide Rev. 3.2) :
  -- gpProxyTableProcessGpPairing (0xC9)
  -- dGpSend (0xC6)
  -- dGpSentHandler (0xC7)
  -- gpepIncomingMessageHandler (0xC5)
  -- gpProxyTableGetEntry (0xC8)
  -- gpProxyTableLookup (0xC0)

Provide timeout handling for Ember dongle

The current implementation for the Ember dongle doesn't recognize when the controller has stopped communicating. The implementation of such a feature is under progress for the Telegesis dongle. Please, provided it also for the Ember dongle.

ConBee/RaspBee Support

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

Test in SpiFrameHandlerTest failing

Version 1.0.13

The test mentioned above fails very often during the build.

12:44:33 testSendEzspFrame(com.zsmartsystems.zigbee.dongle.ember.internal.spi.SpiFrameHandlerTest) Time elapsed: 0.024 sec <<< FAILURE! 12:44:33 java.lang.AssertionError: expected:<7> but was:<9> 12:44:33 at org.junit.Assert.fail(Assert.java:88) 12:44:33 at org.junit.Assert.failNotEquals(Assert.java:743) 12:44:33 at org.junit.Assert.assertEquals(Assert.java:118) 12:44:33 at org.junit.Assert.assertEquals(Assert.java:555) 12:44:33 at org.junit.Assert.assertEquals(Assert.java:542) 12:44:33 at com.zsmartsystems.zigbee.dongle.ember.internal.spi.SpiFrameHandlerTest.testSendEzspFrame(SpiFrameHandlerTest.java:279) 12:44:33 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 12:44:33 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 12:44:33 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 12:44:33 at java.lang.reflect.Method.invoke(Method.java:498)

Dedicated loggers for transmit/receive logs

Currently, the framework logs information about what commands are transmitted to / received from the ZigBee chips using the logger of the class that handles the transmission / reception. The log level is TRACE for the single RX/TX bytes in the SpiFrameHandler as well as for the RX bytes in the AshFrameHandler; it is DEBUG for the other logs (e.g., the complete RX/TX frames in the SpiFrameHandler and the AshFrameHandler, and for the logging of more high-level frame information like in the ZigBeeDongleEZSP, ZigBeeDongleXBee, and the like).

I propose to use dedicated loggers for the transmit/receive log statements, instead of using the logger of the class that handles transmission/reception, for the following reason: While these log messages are sometimes really useful, it is sometimes helpful to disable those log messages, so that they do not flood the log. Of course, one can disable them by setting the log level to INFO - but this will also suppress the other DEBUG-level log messages of the classes (which are a lot rarer, and do not flood the log easily). With dedicates loggers for transmit/receive log statements, one can disable those without disabling the logging for the complete class.

I would like to introduce such loggers for different protocol layers; at the example of Ember chips, there could be one logger for SPI frames (used in the SpiFrameHandler), one for ASH frames (use in the AshFrameHandler), and one for EZSP commands (used in the ZigBeeDongleEzsp). (One could also think about using two loggers for each, one for RX and one for TX, but I think that the simpler solution with one logger for RX and TX is sufficient.)

Regarding the naming of these loggers, my suggestion would be to use the namespace of the module producing the log statements, plus protocol name, plus wire, as these loggers log the data that actually goes over the wire to the ZigBee chip. Example: com.zsmartsystems.zigbee.dongle.ember.ash.wire.

I'd be happy to add a PR for such loggers, but would first like to discuss here about if and how this could be added to the library, and whether this would entail other changes (e.g., in the ZigBee Log Viewer).

Missing content of ember autocode module

I stumbled upon the module com.zsmartsystems.zigbee.dongle.ember.autocode not containing any code, when looking for how the autogenerated classes in com.zsmartsystems.zigbee.dongle.ember are actually generated.

Do you already know then this code will be added to the project?

New attributes not added to cluster follow deserialisation

If a new attribute is added to the cluster library, then it is not added to the cluster if the cluster is deserialised from storage.

Ember chip is sending XON and AshFrameHandler is not handling it.

On first startup, often the ember chip will send back a couple XON bytes (0x11) AshFrameHandler does not exclude these and adds them to the input buffer, resulting in a bad packet. ie:

ERROR com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler - <-- RX ASH frame: BAD PACKET 11 11 52 7B A1 E9 54 26 20

From the ASH protocol documentation, it specifies that certain bytes are reserved. Including:
0x11 XON: Resume transmission
Used in XON/XOFF flow control. Always ignored if received by the NCP.
0x13 XOFF: Stop transmission
Used in XON/XOFF flow control. Always ignored if received by the NCP.

Add network layer incoming packet interface

It would be good to implement a standard network layer interface to allow notifications from dongles into the framework.

Specific notifications I want to see implemented -:

• Ack/Nak responses - these should cut short the internal timeout on transactions if the stick has already given up on a transaction (I've started to implement this, but want a standard interface if possible).
• Incoming route notifications.
• Trust centre notifications.
• ...

Comments/thoughts appreciated...

Ember cannot be initialized

For our project we're using com.zsmartsystems.zigbee in combination with org.openhab.binding.zigbee and trying to create a bridge for the Ember-Controller. The bridge itself is created but it's never set in status ONLINE. We stepped with a debugger through the code and the summary of our investigation is that the ZigBee initialization apparently gets stuck because the AshFrameHandler never receives a com.zsmartsystems.zigbee.dongle.ember.ash.AshFrame.FrameType.RSTACK an therefore can't be completed. So the bridge stays in status Status=INITIALIZING.

Below you see the key points which describe how the ZigBee initialization gets stuck and does therefore not complete. The description starts in com.zsmartsystems.zigbee.dongle.ember.ZigBeeDongleEzsp.initialize(). Since the process is thread-driven some things can happen in a slightly different order or simultaneously. But finally it ends up in the same situation.

In com.zsmartsystems.zigbee.dongle.ember.ZigBeeDongleEzsp.initialize()

• The statement if (!serialPort.open()) returns true.
• The statement ashHandler.start(serialPort) starts the thread to read packets from a stream. Initially there is no data available and the thread goes into wait state at org.openhab.binding.zigbee.internal.ZigBeeSerialPort.read(int)
• The statement ashHandler.connect() sends a reset frame. See below what happens in com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler.outputFrame(AshFrame).

In com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler.outputFrame(AshFrame)

• the for-loop
  • com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameRst.getOutputBuffer() returns [26, 192, 56, 188, 126]. So these values represent the reset frame, right? Is 126 <=> ASH_FLAG_BYTE (end of a frame)?
  • port.write writes the content of the buffer byte by byte into the output stream gnu.io.RXTXPort$SerialOutputStream
  • the invocation of port.write leads to at least one invocation of org.openhab.binding.zigbee.internal.ZigBeeSerialPort.serialEvent(SerialPortEvent) depending on whether it is already in execution. It can happen up to five times since port.write is invoked five times.

In org.openhab.binding.zigbee.internal.ZigBeeSerialPort.serialEvent(SerialPortEvent)

• When serialEvent(SerialPortEvent) is called gnu.io.RXTXPort$SerialInputStream.read() delivers the values 3, 0, 167 five times in total.
• All the occurrences of 3, 0, 167 are stored in a buffer of type int[]. This results in buffer = [3, 0, 167, 3, 0, 167, 3, 0, 167, 3, 0, 167, 3, 0, 167, 0...]
• When all the available data is processed this.notify() is invoked which wakes up the thread that is waiting in org.openhab.binding.zigbee.internal.ZigBeeSerialPort.read(int). Each a byte will be read out there and returned to com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler.getPacket()

In com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler.getPacket()

• port.read() returns a byte from the buffer populated in org.openhab.binding.zigbee.internal.ZigBeeSerialPort.serialEvent(SerialPortEvent) and waits for ASH_FLAG_BYTE in order to return the collected data.
• Since buffer doesn't contain ASH_FLAG_BYTE the thread gets stuck in the loop and will never return to the caller.
• So the caller (thread "AshFrameHandler") will never receive com.zsmartsystems.zigbee.dongle.ember.ash.AshFrame.FrameType.RSTACK and consequently not proceed with the initialization process and set "stateConnected" to true. So no further communication is possible since it depends on this variable being set to true.

Ember console uses classes from internal Ember dongle packages

Classes from the module com.zsmartsystems.zigbee.console.ember use classes from internal packages from the module com.zsmartsystems.zigbee.dongle.ember (viz. the package com.zsmartsystems.zigbee.dongle.ember.internal.ezsp and sub-packages).

This leads to problems (in particular in the context of this issue) when using these modules as OSGi bundles, because the internal packages are not declared as exported in the manifest file that is generated by the maven build (as the maven build adds export statements for all bundles, unless bundles that contain internal or impl - cf. the maven plugin docs).

The simplest approach for solving this would be to simply configure the maven build to make the generated manifest export all bundles for the ember dongle module. This could by done by adding the following to the pom file of that module:

<build>
   <plugins>
    <plugin>
        <groupId>org.apache.felix</groupId>
         <artifactId>maven-bundle-plugin</artifactId>
         <configuration>
           <instructions>
             <Export-Package>com.zsmartsystems.zigbee.dongle.ember.*</Export-Package>
           </instructions>
         </configuration>
    </plugin>
   </plugins>
 </build>

Exporting only packages without internal/impl except the affected packages appears to be more difficult to me.

Another option would be to rewrite the ember console / the ember dongle modules such that imports of internal classes are no longer needed - this option also seems not so easy.

Adding direct access to ezsp dongle

Goal :

• be able to use mfglib frame :
  -- to create a 802.15.4 sniffer
  -- to pass radio certification process of a final product

Need :

• split initialization function in individual function (mfglib start shall be done just after a protocl version request)
• add a function to call ezsp frame
• add ezspFrameHandler listener
• managed a null zigbeeTransportReceive handler

Request :
create a new branch to develop this new functionnalities

Frequent logging when command is not supported

openHAB forum

Removed nodes are not removed from list of discovered nodes

The class ZigBeeNetworkManager puts all nodes for which discovery has completed into the set nodeDiscoveryComplete. This set is used to select between doing a nodeAdded and a nodeUpdated callback in the updateNode method.

When a node is removed, it is not removed from the nodeDiscoveryComplete set, resulting in a different callback behavior when a node is added for the first time (where nodeAdded is called twice, once when the node is added, and once when node discovery is complete), and when a node is added again after it has been removed before (where nodeAdded is called once, and after complete discovery nodeUpdated is called).

CC2531 doesn't pass ZDO MatchDescriptor requests

This requires custom code in the driver.

Raspbee + deConz + OpenHAB-Binding

Hello,

right now we are trying to get the Raspbee-Gateway working. We set up DeConz on the Raspbee and the Openhab-Server but we ran into an issue using the Zigbee-Binding.
If we go to the OpenHab-Site and go to "Choose Binding" there are only three options and Raspbee/Conbee is not included.
Now we are trying to use the console to get the Zigbee Module working.
To us it just isnt clear how to use the console.
As stated in the "console application" paragraph there is a command to start the console so the framework is ready to go. Do we have to copy it to the shell? To us its also not rly clear how the syntax of the command has to look like. Can someone give an example?

Your help would be greatly appreciated.
Tim

Maven Clean Install failed on com.zsmartsystems.zigbee.test

Using Maven 3.5.3 on Debian Stretch.
[ERROR] Failed to execute goal com.gavinmogan:codacy-maven-plugin:1.0.3:coverage (codacy-upload-coverage) on project com.zsmartsystems.zigbee.test: The parameters 'apiToken', 'projectToken' for goal com.gavinmogan:codacy-maven-plugin:1.0.3:coverage are missing or invalid

Supported attributes list error

Currently we add the number of table entries to each subsequent request when building the supported attributes list (and maybe also the commands list). This is probably wrong - it should simply start from the last attribute received.

java.lang.IllegalArgumentException: Invalid type '{com.zsmartsystems.zigbee.ZigBeeChannel}' of configuration value!

OH 1348
Zigbee snapshot 2.4.0.201809041558
Zigbee libraries 1.1.1

I'm seeing this on startup, but everything appears to be functioning...

2018-09-04 18:50:49.702 [WARN ] [org.eclipse.smarthome.core.internal.common.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.IllegalArgumentException: Invalid type '{com.zsmartsystems.zigbee.ZigBeeChannel}' of configuration value!
        at org.eclipse.smarthome.config.core.ConfigUtil.normalizeType(ConfigUtil.java:80) ~[?:?]
        at org.eclipse.smarthome.config.core.Configuration.put(Configuration.java:86) ~[?:?]
        at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.initialiseZigBee(ZigBeeCoordinatorHandler.java:412) ~[?:?]
        at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.lambda$1(ZigBeeCoordinatorHandler.java:437) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]


2018-09-04 18:50:49.702 [DEBUG] [com.zsmartsystems.zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP dongle startup done.
2018-09-04 18:50:49.702 [DEBUG] [org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler] - ZigBee Initialise done. channel=CHANNEL_25, PanId=19740  EPanId=3DAB5D4A2336BFDE

Ember no longer controlling devices after 30-50 minutes

I have reported this previously in the forum. My Ember stick (nortel) will no longer control any devices after running for less than an hour. It will still register changes on the network. The following log shows me commanding brightness on a lamp to zero at 11:13:33. In Paper UI, the brightness updates to 0, however, the lamp itself does not react. Meanwhile, you can see a motion sensor updating, which is acted upon correctly by openhab.

Properties of the zigbee thing I tried to control:

zigbee_logicaltype	ROUTER
zigbee_powerlevel	FULL
modelId	LCT010
zigbee_networkaddress	27819
zigbee_powersource	MAINS
zigbee_stkversion	1
zigbee_datecode	20160906
zigbee_zclversion	1
zigbee_routes	[]
zigbee_lastupdate
vendor	Philips
zigbee_appversion	2
zigbee_permitjoining	false
zigbee_powermode	RECEIVER_ON_IDLE
zigbee_powersources	[MAINS, RECHARGABLE_BATTERY, DISPOSABLE_BATTERY]
hardwareVersion	1
zigbee_neighbors	[]
firmwareVersion	01000B0E
zigbee_devices	[]

Log when things don't work:
New Text Document.txt
Next is how a functioning command turns up in the log. All the TX commands seem to missing from above posted log.
Neues Textdokument.txt

Maven build fails when run in submodules

The maven build fails when run in a submodule (e.g., when running mvn clean install in the subfolder com.zsmartsystems.zigbee.console). The problem is that the license-maven-plugin cannot read the file /src/main/header.txt, which is defined in the parent module.

I don't think that this is a severe issue, but it can be a little annoying when one has to build all modules all the time.

There are several ways to resolve this (cf. mathieucarbou/license-maven-plugin#36 (comment)).

My suggestion is to disable the license-maven-plugin in the submodules as suggested in the discussion linked above, i.e., by setting the inherited property of the plugin configuration to false, and setting its configuration property aggregate to true (so that the plugin will check the source files in all submodules). I will add this small change as a PR, so one can see this written down.

NPE in Karaf console (ZigBeeNetworkMeshMonitor.java)

Originally posted here

This NPE comes up in the Karaf console running OH2.1 release and the Zigbee binding (2.2.0.201707042200). I am using an HUSBZB-1 (EmberZNet Pro 5.4).

openhab> Exception in thread "pool-35-thread-1" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-2" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-4" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-3" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-6" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-5" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-7" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-8" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-10" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-11" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-12" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-13" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-9" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
        at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Exception in thread "pool-35-thread-15" java.lang.NullPointerException
Exception in thread "pool-35-thread-16" java.lang.NullPointerException
Exception in thread "pool-35-thread-14" java.lang.NullPointerException
Exception in thread "pool-35-thread-18" java.lang.NullPointerException
Exception in thread "pool-35-thread-17" java.lang.NullPointerException
Exception in thread "pool-35-thread-19" java.lang.NullPointerException
Exception in thread "pool-35-thread-21" java.lang.NullPointerException
Exception in thread "pool-35-thread-20" java.lang.NullPointerException
Exception in thread "pool-35-thread-22" java.lang.NullPointerException
Exception in thread "pool-35-thread-24" java.lang.NullPointerException
Exception in thread "pool-35-thread-25" java.lang.NullPointerException
Exception in thread "pool-35-thread-26" java.lang.NullPointerException
Exception in thread "pool-35-thread-27" java.lang.NullPointerException
Exception in thread "pool-35-thread-28" java.lang.NullPointerException
Exception in thread "pool-35-thread-29" java.lang.NullPointerException
Exception in thread "pool-35-thread-23" java.lang.NullPointerException
Exception in thread "pool-35-thread-31" java.lang.NullPointerException
Exception in thread "pool-35-thread-30" java.lang.NullPointerException
Exception in thread "pool-35-thread-32" java.lang.NullPointerException
Exception in thread "pool-35-thread-34" java.lang.NullPointerException
Exception in thread "pool-35-thread-35" java.lang.NullPointerException
Exception in thread "pool-35-thread-33" java.lang.NullPointerException

Provide default values for cluster if Values are not properly formated

I'm getting the following exception every few seconds,

        at com.zsmartsystems.zigbee.zcl.clusters.ZclBasicCluster.getHwVersion(ZclBasicCluster.java:327) [193:com.zsmartsystems.zigbee:1.0.11]
        at org.openhab.binding.zigbee.discovery.ZigBeeNodePropertyDiscoverer.getProperties(ZigBeeNodePropertyDiscoverer.java:138) [247:org.openhab.binding.zigbee:2.4.0.201807010828]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:254) [247:org.openhab.binding.zigbee:2.4.0.201807010828]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:158) [247:org.openhab.binding.zigbee:2.4.0.201807010828]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:152) [247:org.openhab.binding.zigbee:2.4.0.201807010828]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [247:org.openhab.binding.zigbee:2.4.0.201807010828]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

looks like its expecting an Integer for the hardware version, but the device returns a string, since the hardware version is not critical for device operation how about we surround querying those parameters in a try/catch and provide default values in case there is an exception?

AshFrameHandlerTest#testAshFrameData fails continuously

With the latest version (1.0.14), the AshFrameHandlerTest#testAshFrameData continuously fails as follows:

testAshFrameData(com.zsmartsystems.zigbee.dongle.ember.internal.ash.AshFrameHandlerTest) Time elapsed: 0.008 sec <<< FAILURE!

Similar to #333, the test case works locally stable but continuously fails on slow CI machines.