Comfort Status/Refresh responses.

[Ingo]

Hi,

With helping Julian testing the ComfortClient I noticed that sometimes I get a \'NA\' response back from Comfort. I\'ve only ever seen this on a slow Internet/VPN link into my system, it never happens on a fast LAN connection.

On initial startup the Client does a complete refresh to sync the system. The following commands are sent and the feedack below is what I get back.

[12:40:05] > M?
[12:40:05] > K?
[12:40:05] > Z?
[12:40:05] > z?
[12:40:05] > Y?
[12:40:05] > y?
[12:40:05] > SR01
[12:40:05] > S?
[12:40:05]  < M?0000
[12:40:06]  < KL00020200
[12:40:06]  < Z?E85F
[12:40:06]  < z?00
[12:40:06]  < Y?0000
[12:40:06]  < y?00
[12:40:06]  < OK
[12:40:06]  < S?01
 
[12:40:10] > M?
[12:40:10] > K?
[12:40:10] > Z?
[12:40:10] > z?
[12:40:10] > Y?
[12:40:10] > y?
[12:40:10] > SR01
[12:40:10] > S?
[12:40:10]  < M?0000
[12:40:10]  < KL00020200
[12:40:11]  < NA
[12:40:11]  < Y?0000

When I receive the 'NA' response back all subsequent return values also goes missing. From the output above it can be seen that the first refresh is 100% successful but the second one gave a 'NA' response and then some of the return values are gone.

Is there some sort of buffer that might be filling up or should the requests rather be sent in sync mode than async?

Regards,
Ingo
Comfort II, 8-Zone(5.172), UCM05/Ethernet(5.202)

[admin]

Do all commands get NA reply?
If so it looks like the UCM (or Comfort)  may have been reset, so it rejects all commands since it is not logged in.
Someone may also have sent LI command which logs the UCM out

[Ingo]

No, I initially thought it was a specific command that does it but sending all the commands one by one does not give the error. Only when all the commands are sent does the NA response, sometimes, return.

The UCM is not reset and I am the only one connected. I tested this on two systems, my 64-zone production system and my 8-zone test system.

[admin]

I suspect the characters do not arrive in the corrrect sequence from the network to the UCM when you send too many at once, hence it does not recognise the jumbled commands

[Ingo]

I suspect the same thing. What is the best way for sending all the queries then? Should it be sent one at a time and only send the next command once a response has been received from the previous command?

[admin]

Yes, best to wait for a reply before the next command

[juwi_uk]

Personally I\'d be amazed if the characters dont arrive at the UCM in the correct sequence as surely that is what the TCP layer is meant to do;  reconstruct the packet sequence in the correct order at the receiving end.

Also I\'m sending minimal bytes here so if they dont all fit in a single packet then I\'d be surprised.

It\'s not a setting in the Tibbo (DS-MANAGER) side is it; ie in the Network-serial conversion logic?

Sending a single command and waiting for a response is problematic surely as you cant guarantee that the next received value is for the command just sent as other state changes in Comfort can send out values on the bus.

I have asked in the past if we could \"tag\" commands sent to the UCM so that in code we code then check for the same \"tag\" on received values and match sender to receiver.  Maybe that can still be considered as an E.R. for future firmware?  Ideally I\'d want the tag to be a GUID but guess that might be too costly in bytes!  Then you could send a command and not send the next until the first comes back,  performance hit excepted!

Ingo,  perhaps we can capture a trace with a packet analyser (sniffer) and see what\'s going where?

Julian

p.s if the buffer does overrun on the UCM side then maybe send out a information packet on the bus so this can be trapped?

 

[Ingo]

Good suggestion Julian, let me see if I can put something together.

Ingo

[Ingo]

Here we go, two sniffer traces. Now we just need someone to decode this as I have no idea what data is expected on the wire and what is not. According to my knowledge the TCP handshaking looks good so the problem might not be there.

Following the TCP stream I can see the one that is not working is a couple of bytes less than the working one.

I used Wireshark to capture the data over a 3G/HSDPA link with VPN tunnel into my local 512kb/s WiMAx connected system.

Ingo

[admin]

We are still looking into this, but have not found the cause of the problem yet