LQI information

[cdjackson]

This refactors the LQI browser a little, and maintains a flat list of LQI information between each node. This idea is to expand this a little to get min/max/avg out, but I've not finished this yet - it currently just returns the last LQI value.

The idea is to allow a network diagram to be built, showing the link quality.

It might be best not to merge this just yet - I'm creating the PR now so y'all can see and comment on this in case there's a better way to do this.

[cdjackson]

When merged this will also add the initial node descriptor changes. I'll merge this in a couple of days if I don't have any feedback. Closes #44

[presslab-us]

Seems to work pretty well for me. It's great to see the LQI information! For the node information, I only see it for my coordinator. Perhaps none of my devices support this? Or do I need to do something to get it to update?

[cdjackson]

Seems to work pretty well for me.

Good :)

It's great to see the LQI information! For the node information, I only see it for my coordinator.

You mean the node descriptor? In theory, this is mandatory for all nodes, but I’ve got some (not cheap!) Chinese temp/humidity sensors (battery) and they also don’t support it. My Hue does though (and the coordinator).

Perhaps none of my devices support this? Or do I need to do something to get it to update?

This should always happen during discovery - I don’t know if you persist the network (which I’m currently not doing) if it bypasses this?

[presslab-us]

Oh yeah, it was the persistence. I re-joined the device and assumed it would update but now that I think about it, it won't. I can see the node descriptor and power descriptors now, looks good. All my devices (except coordinator) show max buffer of 0, not sure what that means. Do you know what buffer this refers to?

BTW I did get an error running the unit tests but I just skipped them for now.

[cdjackson]

Sam here (re max buffer). It refers to fragmentation...

The maximum buffer size field of the node descriptor is eight bits in length, with a valid range of 0x00-0x7f. This field specifies the maximum size, in octets, of the network sub-layer data unit (NSDU) for this node. This is the maximum size of data or commands passed to or from the application by the application support sub-layer, before any fragmentation or re-assembly.

I guess 0 means fragmentation isn’t allowed...

BTW I did get an error running the unit tests but I just skipped them for now.

Ooops - forgot to check that… I’ll do that tonight or tomorrow - thanks.

[presslab-us]

Thanks for the info.

A problem with the persistence: `ZigBee API starting up...java.lang.RuntimeException: Error serializing network state. at org.bubblecloud.zigbee.network.impl.NetworkStateSerializer.deserialize(NetworkStateSerializer.java:72) at org.bubblecloud.zigbee.ZigBeeApi.deserializeNetworkState(ZigBeeApi.java:311) at org.bubblecloud.zigbee.ZigBeeConsole.start(ZigBeeConsole.java:103) at org.bubblecloud.zigbee.ZigBeeConsoleJavaSE.main(ZigBeeConsoleJavaSE.java:34) Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: Unrecognized field "maximumBufferSize" (Class org.bubblecloud.zigbee.network.ZigBeeNodeDescriptor), not marked as ignorable at [Source: java.io.StringReader@2770cd42; line: 1, column: 359] (through reference chain: org.bubblecloud.zigbee.network.impl.ZigBeeEndpointImpl["node"]->org.bubblecloud.zigbee.network.impl.ZigBeeNodeImpl["nodeDescriptor"]->org.bubblecloud.zigbee.network.ZigBeeNodeDescriptor["maximumBufferSize"])

`

[cdjackson]

I haven’t looked at how the persistence works, but maybe if the definition of classes changes from one ‘execution’ to the next, then it might not read back in properly? Can you try deleting the files to see if that solves it?

[presslab-us]

Yes, if I delete the network.json it will start up. But then the next time I run I get the error, so even after it has saved an updated file it will fail.

I think I see the problem, in the json file it's named maximumBufferSize but in ZigBeeNodeDescriptor it's named maxBufferSize. I'm not sure where it's getting maximumBufferSize from though... The same goes for maximumTransferSize.

[cdjackson]

Ok - thanks. I'll try and look at this tonight if I get a chance (maybe not as I'll be sitting on a plane for a while :( but we'll see).

I would have thought that the serialise/deserialise should use the same classes/names, but...

[cdjackson]

Ok - the issue with this serialisation is that class members, and the getters need to have the "same" names. I had the private member called maxBufferSize but the getter was called getMaximumBufferSize. Changing the private member to maximumBufferSize seems to have fixed it...

I'll push this shortly - if you get a chance to check you side it would be good... Then I'll merge...

[presslab-us]

This is working fine for me. One other thing I noticed is that the console "nodes" command is in a different order than "list". Although it seems to me like the "nodes" info could be put into the "desc" command so it's all in one place.

[cdjackson]

I kept the nodes command separate as it's a different list - the list command lists the endpoints/devices (there may be multiple per node) where the nodes command lists the physical nodes. This is also why they might come up in a different order - you won't for example get the controller in the 'list' command, but you do in the other commands that use the node list rather than the device list (nodes and lqi)

[presslab-us]

Ah yeah the different endpoints. Most devices have one endpoint but sure there could be more than one. I just wonder if there would be a better way to organize the nodes, as there are now multiple commands to get information about the nodes.

One of my devices seems to be tickling a bug with the LQI handling: 06:28:25 983 ERROR Error constructing response packet {} java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) 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:312) at org.bubblecloud.zigbee.network.packet.ZToolPacketStream.parsePacket(ZToolPacketStream.java:174) at org.bubblecloud.zigbee.network.packet.ZToolPacketParser.run(ZToolPacketParser.java:106) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.ArrayIndexOutOfBoundsException: 3 at org.bubblecloud.zigbee.network.packet.zdo.ZDO_MGMT_LQI_RSP.<init>(ZDO_MGMT_LQI_RSP.java:75) ... 9 more

This looks to be an existing problem, not caused by this pull request. I'll try to look at this when I get a chance.

[cdjackson]

I just wonder if there would be a better way to organize the nodes, as there are now multiple commands to get information about the nodes.

Yep - for sure this could be consolidated into a single command (or a couple of commands). A simple 'list' command that listed the devices (pretty much the same as now) and another one that listed devices, and within that list listed the endpoints that each device has (so similar to the node command I added, but adding things like LQI and other stuff).

I didn't originally do that to keep the change set to a minimum, but I agree it is nicer. I'll take a look at this when I get a chance.

[presslab-us]

Fixed the ArrayIndexOutOfBoundsException above: https://github.com/tlaukkan/zigbee4java/commit/ba49ff26916a1cd988ea03a5185787d40260c3f9