CQC Problems with v3.10D Omni Firmware

[ano]

I installed v3.10D firmware on my Omni Pro II and i love all the improved support for Zigbee. Overall the firmware is working great EXCEPT for one thing, now CQC can't connect to the panel through TCP/IP anymore.

So, my question for HAI is, what changes to the TCP/IP interface were made between v3.10A and v3.10D that might be causing problems? I've checked for information on what has changed in these FW versions, but i don't think that HAI has published anything.

Thanks.

 

[Dean Roddey]

I haven't had time to look at it yet, but it would appear perhaps that the data format was changed in some way, since the driver now seems to be now looking in the wrong places in the incoming messages, so it's getting data that makes no sense to it. If it's a purposeful change then of course we'll have to try to deal with it by looking at the current firmware version or something. If it's not purposeful, then they may want to go back and fix it. So it would be good to hear officially what the deal is.

 

[HAI_fjh]

I am not sure how CQC parses messages, but there was a data structure change. An additional 2 bytes were added to the extended status message to hold the ZigBee power values. The length byte in the message was also changed but if CQC is not actually looking at the length byte and assuming the message is a certain length this could be the problem.

As I initially stated I don't know how CQC parses messages but if this is the problem they would not be the first ones to make this simple mistake.

We don't change the meaning of existing data bytes in a message but we have to have a way to add additional data for new features. The solution is a length byte and to always add new data fields at the end. This way existing programs can look at the beginning of the data, which as not changed, and ignore the extra new data.

 

[Dean Roddey]

OK that's probably it. I didn't realise that this could happen. And I also use the (assumed) max size to figure out how many consequtive values I can request at once (to fit into the max packet size.) Given that there's no way to know ahead of time how the per-item chunks might end up being, it means you'd have to be pretty conservative about that since it could change after the fact and you'd end up overruning the packet size if a newer firmware extended the size of one of them. If you are asking for 32 of something, and they are all now 2 bytes longer, that's 64 bytes of new data that could push you over the max packet size.

 

[HAI_fjh]

One solution is to ask for a single extended status during startup to get the message length, then use that length to calculate max that will fit in a packet for all subsequent requests. Also you may find that you get better performance by not getting max packet length messages. I think around 64 bytes is the fastest. There are a number of factors that come into play but you might want to do some testing.

 

[Dean Roddey]

OK, I've fixed this and sent a test driver to a user to test out. If it's happy, we'll get it into the next drop.