I suppose Ocelot driver has bug

[bisoft_m]

Here is my problem:

When I use remote control to switch on/off x10 devices directly, HB updates status of x10 devices. But when ocelot switch on/off x10 devices HB doesn't update any status.

At first I thought that Ocelot doesn't send to HB any info when it controls x10 devices itself. I used COM port monitor to check exchange between PC (HB) and Ocelot. I could see that Ocelot sends info when it switches x10 devices but HD doesn't react to it.
According to my observation HD updates status when it received 0xFE HC KC but when HD receive 0xFB HC KC it doest update.
So are you sure that your Ocelot driver handles both x10 Ocelot responses?


Also after several period (5-10 minutes) HD stops to control Ocelot, some kind of COM port buffer problem, but maybe it caused by previous problem. Here is my log
Sep 27 2007,01:30:01PM,Ocelot,Error,"Error reading COM port. Error = Insufficient data in read buffer"
Sep 27 2007,01:30:14PM,Ocelot,Error,"Error reading COM port. Error = Insufficient data in read buffer"
Sep 27 2007,01:30:27PM,Ocelot,Error,"Error reading COM port. Error = Insufficient data in read buffer"
Sep 27 2007,01:30:38PM,Ocelot,Error,"Error reading COM port. Error = Insufficient data in read buffer"
Sep 27 2007,01:30:49PM,Ocelot,Error,"Error reading COM port. Error = Insufficient data in read buffer"
Sep 27 2007,01:31:00PM,Ocelot,Error,"Error reading COM port. Error = Insufficient data in read buffer"
Sep 27 2007,01:31:11PM,Ocelot,Error,"Error reading COM port. Error = Insufficient data in read buffer"
Sep 27 2007,01:31:13PM,!! Exception encountered !!

Sometimes I have in log the following
Sep 26 2007,12:29:30PM,Ocelot,Error,"Purging Comm Port."


I really suffer from these problems because I can't use Ocelot and as result I can't control house equipments.

Andrey A.

[bisoft_m]

Anybody could help me? I really need support.
Scott where are you?

[ScottBot]

So when you say "But when ocelot switch on/off x10 devices HB doesn't update any status" do you mean that you are running a CMax program in the Ocelot and that is what is controlling the light? Because if you control the light using HouseBot through the Ocelot the status will update due to the fact that it was changed from HB.

If you are running a program/CMax from Ocelot, this could be the problem. I've run the Ocelot for years at my own home, but never with a CMax program (since that's what HouseBot is for).

[bisoft_m]

Yes Scott, I run C-max program.
I don't think it's good idea to use Ocelot as transceiver only.

You wrote in help
> While it is possible to have the Ocelot internal program running
> concurrently with HouseBot, bit complicates the HouseBot IR
> configuration.

So my idea is to use Ocelot for critical tasks only because it could work without PC and as result without HB. I would like to combine the stability of controller (Ocelot) and functionality of HB.

I think my problem could be fixed.
1. When any x10 equipments send x10 command Ocelot sends to HB 3 bytes: 0xFE XX XX
2. When Ocelot sends x10 command itself (from C-max) it also sends to HB 3 bytes but in this case: 0xFB XX XX
and HB doesn't react to these 3 bytes. As I told it seems Ocelot driver doesn't handle '0xFB XX XX' bytes.

I really need new Ocelot driver, maybe you could provide me sources to fix myself or you could do it yourself...
But we should find the solution for this issue.

Looking forward to your reply.

[ScottBot]

In looking at the code for the Ocelot, it does actually handle the 0xFB response (or it should). It would probably be more helpful if you run an interface trace for the Ocelot to see more information on what is received and what is handled by the plugin.

Information on running a hardware interface trace can be found here.

[bisoft_m]

In looking at the code for the Ocelot, it does actually handle the 0xFB response (or it should). It would probably be more helpful if you run an interface trace for the Ocelot to see more information on what is received and what is handled by the plugin.

Scott, I did it.

Session1 ---------------------------
In this session I use simple C_Max program for Ocelot:

When Ocelot receive E1-ON it sends A1-ON
When Ocelot receive E1-OFF it sends A1-OFF

I don't know why but Ocelot driver received E5 instead of E1 (Sometimes it happens).
I also have COM port monitoring log and according to it Ocelot sent to HB
correct 0xFB 0x04 0x00 bytes but in Ocelot driver's log we could see 0xFB 0x04 0x04 it's very strange.
(I enclosed COM port log, it contains all communication interaction between Ocelot and HB. You need ‘LGComSpy++’ program to open it, if you don’t have program I can send it too)

This session indicates:
1. Sometimes something is going wrong and driver receives wrong bytes. Or in other words it looks like driver receives wrong bytes but in fact it may receive correct bytes.
2. Driver handles 0xFB block but it doesn’t update status of HB x-10 devices.


Session2 ---------------------------
In this session I use another more complicated C_Max program for Ocelot:

When Ocelot receives Secu16-Input#0 (Button is pressed) it starts timer and send x10 commands based on this timer.
(Let’s say it switches off every x10 devices step by step with 1-3 secs interval)

In this log you could see “Ocelot,Error, Purging Comm Port.”
(I also enclosed interface trace log and COM port log)

This session indicates:
1. Something is going wrong with driver when it receives 0xFF byte (remote i/o status changed) and try to send request for I/O statuses.


Session3 ---------------------------
This session is same as first one. I sent first command E1 but again driver showed that it received E5 instead of E1. Later driver showed ‘Error’ it received wrong Unit Code in 0xFB block. And in the end we got “Ocelot, Error, Error reading COM port. Error = Insufficient data in read buffer"

(Sorry, I don’t have COM port log for this session, interface trace log only)

This session indicates:
1. Very often Ocelot driver has problem with third (last) byte of 0xFE and 0xFB blocks.

That's all Scott, I'm waiting for new guidelines.

[ScottBot]

...
I don't know why but Ocelot driver received E5 instead of E1 (Sometimes it happens).
I also have COM port monitoring log and according to it Ocelot sent to HB
correct 0xFB 0x04 0x00 bytes but in Ocelot driver's log we could see 0xFB 0x04 0x04 it's very strange.

That is very strange. I wasn't able to look at your com trace, but I could clearly see the E5 in the plugin trace. I can only suggest, as a test, that you try controlling something like F1 and see if it comes in as F6. Might be a clue to some buffer problem, but I can't see where.

The 'Error' and comm port purge was due to the plugin being very intolerant of any problems with the data stream. I made a minor change that should remove the purge and error message. Hopefully that won't cause other issues.

I've enhanced the 0xfb handling. Hopefully it will send the A1 notification messages now. I've not tested this, so let me know how it works.

You can download the new plugin here. Just unzip and copy it into your \HouseBot\Plugins\Interface directory over the old DLL. You should backup the old one first.

[bisoft_m]

Thanks, I will test new driver.

...
I don't know why but Ocelot driver received E5 instead of E1 (Sometimes it happens).
I also have COM port monitoring log and according to it Ocelot sent to HB
correct 0xFB 0x04 0x00 bytes but in Ocelot driver's log we could see 0xFB 0x04 0x04 it's very strange.

That is very strange. I wasn't able to look at your com trace, but I could clearly see the E5 in the plugin trace. I can only suggest, as a test, that you try controlling something like F1 and see if it comes in as F6. Might be a clue to some buffer problem, but I can't see where.

I enclosed LGComSpy++ program. It will be very useful for this case (and for you) because it shows data transfer and all COM port service info (speed, CTS etc). Just install it and open my COM port logs.

I didn’t see driver sources but one thing I noted, see below logs

Log (Session1)
Oct 06 2007,11:20:03AM,Ocelot,Debug,"Read [1] bytes [fe]"
Oct 06 2007,11:20:03AM,Ocelot,Debug,"Read [2] bytes [04 04]"
Oct 06 2007,11:20:03AM,Ocelot,Debug,"Read [3] bytes [fe 04 12]"
Oct 06 2007,11:20:03AM,Ocelot,Debug,"X-10 Command Received. HC = [E], UC = [5], CMD = [On]"

Log (Session3)
Oct 06 2007,04:01:40PM,Ocelot,Debug,"Read [1] bytes [fb]"
Oct 06 2007,04:01:40PM,Ocelot,Debug,"Read [2] bytes [00 07]"
Oct 06 2007,04:01:41PM,Ocelot,Debug,"Auto X10 response received (xfb). Data HC = [A], UC = [8]"
Oct 06 2007,04:01:41PM,Ocelot,Debug,"Read [1] bytes [fb]"
Oct 06 2007,04:01:41PM,Ocelot,Debug,"Read [2] bytes [00 fb]"
Oct 06 2007,04:01:41PM,Ocelot,Debug,"Auto X10 response received (xfb). Data HC = [A], UC = [Error]"

In both cases there is problem with third byte:
1. In 0xFE block driver shows third byte like second one (0x04).
2. In 0xFB block driver shows third byte like first one (0xFB).

Maybe it’s just coincidence! Also I noted (from COM port log) that you handle bytes in 0xFE and 0xFB blocks one by one. You didn’t receive these three bytes at once, maybe there is problem in this cycle (buffer queue)?

Of course I will try to change E1 address and play again to help localize problem.

[bisoft_m]

And last part of program.

[bisoft_m]

I made additional tests for current Ocelot driver.

Session4 ---------------------------------
I changed C-max program, now I send F1 instead of E1
As you could see driver shows 0xFE 0x05 0x05 instead of 0xFE 0x05 0x00


Session5 ---------------------------------
I changed C-max program again, now I send L1
And driver shows 0xFE 0x0B 0x0B instead of 0xFE 0x0B 0x00

After these sessions (4, 5) we could say that sometimes third byte in 0xFE block contains value of second byte.


Session6 ---------------------------------
And I checked new Ocelot driver but… I’ve got exception after first x10 command.

[ScottBot]

I changed C-max program, now I send F1 instead of E1
As you could see driver shows 0xFE 0x05 0x05 instead of 0xFE 0x05 0x00

I thought that it seemed suspicious that both of the values were identical. Thanks for verifying the buffer issue. After looking very very closely for the possibility of this problem, I did notice a very small window where the buffer could be out of sync and cause this. I've made a fix to the plugin that you can try here.

I was not able to reproduce the crash with the new plugin that you were seeing. If you continue to see a crash with this latest plugin, please send me (at [email protected]) the latest dump file (found in your \HouseBot\dump directory).

[bisoft_m]

I was not able to reproduce the crash with the new plugin that you were seeing. If you continue to see a crash with this latest plugin, please send me (at [email protected]) the latest dump file (found in your \HouseBot\dump directory).

Still getting exception. I have sent all files to your mail box.