Ocelot response timing

Timoh · Post by **Timoh** » Sun Jan 20, 2008 6:21 pm

Hi Scott,
I've found that if a set an output relay on my secu-16 which changes an input fairly quickly (a few ms) on the same secu16, it seems to destabilize some comms with the ocelot.

As far as I can tell, when I set a relay the normal response is 06 00 06. And when there is a change on the input, the Ocelot issues a ff to let you know something has changed.

What is happening is that the ff is being returned before 06 00 06. This results in HB reading ff 06 00 as result of the relay change and saying the relay has not changed, when it fact it has.

Also for reasons unknown, it knocks the inputs out of whack in that they don't respond at all in HB when the input changes in the Ocelot. The odd thing is it will only affect the inputs in HB that changed as a result of the relay change. (The inputs which were not supposed to change as a result of the relay change remain functional in that they report their input state correctly.)

Restarting HB corrects this and all is well again until I trigger the relay which changes the inputs very quickly.

Thanks
Tim

Post by **ScottBot** » Mon Jan 21, 2008 9:53 pm

Nice one. Here's a quick shot at a fix. Can't really test it, since I'll probably never be able to duplicate it.

If I see the 0xff before the "606", I just stuff it back into the serial buffer and treat it as a 606.

Timoh · Post by **Timoh** » Tue Jan 22, 2008 8:42 pm

Nope didn't work...
It stuffed the 0xff back into the buffer as you say, but it seems there are other values floating around. So in the attached trace, we also saw 0x44 before 06 00 06.

I've noticed other values at the beginning of the input state change response from the Ocelot. In the original trace we 0x93 and 0x38.

I'm not sure where these other values are coming from.

Tim

Post by **ScottBot** » Thu Jan 24, 2008 8:08 pm

Try this one. I'm just throwing out the 0xff instead of pushing it back. Seems that pushing it back was causing an issue with processing the real-time data. The 'other values' you were seeing in the trace were the trailing bytes of the real-time data checksum that was not processed because the 0xff was though to be the start of the data.

Timoh · Post by **Timoh** » Fri Jan 25, 2008 10:15 pm

That works.
Thanks
Tim

Timoh · Post by **Timoh** » Sat Jan 26, 2008 11:14 am

Scratch that... It worked a few cycles than crapped out.
Tim

Post by **ScottBot** » Sun Jan 27, 2008 10:25 pm

Try this one. Small fix, and more validation and tracing.

Timoh · Post by **Timoh** » Wed Jan 30, 2008 7:03 pm

We were good for 2 days with this one... Then it looks like an x10 code got thrown into the mix.
Tim

Timoh · Post by **Timoh** » Thu Jan 31, 2008 8:47 pm

Same think happened this morning...
My x10 command that triggers at sunrise - 2 hours, offsets everything from that point on by 3 bytes.

The x10 is triggered from some code in my Ocelot. Not HB.

Tim

Post by **ScottBot** » Fri Feb 01, 2008 9:06 am

There's a little more I can do to help pull the correct real-time data from the buffer, even if there is other data ahead of it. The protocol can be a bit of a challenge to manage when there's a lot going on at the same time.

Timoh · Post by **Timoh** » Fri Feb 01, 2008 9:52 am

OK... Do what you can. I was thinking this last one might be a bit more of a challenge. I can probaby develop a work around if no further progress can be made.

With the recent timer and variable functionality, I can offload some of my relay set commands to the Ocelot using some c-max code and variables.

Tim

Post by **ScottBot** » Fri Feb 01, 2008 4:57 pm

So what do you have running in the Ocelot now that we have added the additional timers/variables/parameters functionality to the Ocelot plugin?

I think this problem would go away if everything was managed by HB.

The last trace you sent shows it receiving 0xfb, which indicates an X10 status update. It then reads two bytes to get the HC/UC or HC/CMD (for global commands). It reads 0x01 0x02, which is B3. Since it's a HC/UC, the plugin is expecting there to be 3 more bytes following it to specify the HC/CMD portion of the X10 command. I realize that it's perfectly legal to send just a HC/UC without the following command, but I was curious as to know if this is what you are doing in the Ocelot. Are you just sending the HC/UC?

Post by **ScottBot** » Fri Feb 01, 2008 5:09 pm

Actually, I also see "fb 01 13" being received shortly after that. That's probably the HC/CMD that it is looking for. Just not sure why it wasn't seen until later.

Timoh · Post by **Timoh** » Fri Feb 01, 2008 6:59 pm

Yes. I'm doing a B3 Off which corresponds to the code received 5 minutes later.

Maybe the 3 bytes you are looking for is coming in, just not as fast as you think. If the buffer is empty, maybe wait 1 second and try again, if still nothing then try again 2 seconds later, and if still nothing try again 4 seconds later. That would give you 7 seconds for the data to come into the buffer.

Maybe we only saw it much later due to the fact we only queried the buffer much later.

Previous logs show that sequence coming in 1 second apart.

Maybe another idea would be instead of 0xfb hc + uc then three bytes, looking for a second 0xfb and two bytes.

I was thinking I could now set a variable in the Ocelot that would close my relay, instead of sending the command from HB to close the relay. But in looking at the protocol, it would still returns a 06 00 06 as a response. So it might not help me much. Due to if there was something unread in the buffer, it would return that and get all out of sync.

Tim

Post by **ScottBot** » Fri Feb 01, 2008 9:03 pm

It was only waiting 1 second after the first X10 reception for the next. I'll increase that to a few seconds to see if that works any better.