X10 CM15Pro not working properly

[bkenobi]

Yes, it would be a very good idea to log this on github as an issue.  There are at least 1 or 2 other x10 related issues currently.  I would like to see a bit more attention on X10 to get these resolved, but I know that Gene has a lot of other things he's working on so it's best to at least get all of these issues on his radar.

https://github.com/genielabs/HomeGenie/issues

[Gene]

Hello I'm replying here instead of github issue tracker because it won't allow me attacching files.
Did run the test as described here

https://github.com/genielabs/HomeGenie/issues/95#issuecomment-69834673

but still was not able to reproduce the issue. Also tried with a combination of 3 units istead of 2. And also tried units with subsequent number (eg. A4,A5 instead of A4, A9).
The only difference I could see by comparing AHP comm with HG comm is that AHP send next command right after receiving the ACK (0x55).
HG instead had a delay of 50ms. So I removed this delay and now both AHP and HG comm i/o are the same.
Perhaps you can try the attached dll with this modification and also the fix about the first command after hg startup not being sent.
Please @bkenobi, try this whenever you can just to ensure not to have any side effect. I'm also running this new XTenLib and didn't notice any issue at the moment (hope the same with CM11 but could not try with it yet).

Cheers,
g.

[Gene]

I noticed in pim555 message this log:

Code: [Select]

[15:46:21.004044] X10 < 04 6A
[15:46:21.508237] X10 > 55
[15:46:21.508514] X10 > COMMAND SUCCESSFUL
[15:46:21.561701] X10 < 06 63
[15:46:22.060267] X10 > 55
[15:46:22.060547] X10 > COMMAND SUCCESSFUL
2014-12-29T15:46:22.1183840+00:00       HomeAutomation.X10      A4      -       Status.Level    0
[15:46:22.860401] X10 > 5A 02 00 6A
[15:46:22.860727] X10 > PLCRX: 5A 02 00 6A
[15:46:22.860948] X10 > FNMAP: 00
[15:46:22.861183] X10 >  DATA: 6A
[15:46:22.861683] X10 >       0) House code = A
[15:46:22.861888] X10 >       0)  Unit code = 4
[15:46:23.668483] X10 > 5A 02 00 6A
[15:46:23.668816] X10 > PLCRX: 5A 02 00 6A
[15:46:23.669039] X10 > FNMAP: 00
[15:46:23.669273] X10 >  DATA: 6A
[15:46:23.669769] X10 >       0) House code = A
[15:46:23.669978] X10 >       0)  Unit code = 4

The odd thing is that the [15:46:22.860727] X10 > PLCRX: 5A 02 00 6A indicates that the CM15 is receiving command from some other controller.
Infact, when sending a command through CM15, you shouldn't see any PLCRX debug line.
Is there any other X10 controller in the house? If so, the odd thing is... why is this reacting when using HG and not reacting with AHP or mochad? =)
Do you have any automation program active in HG that could also send extra unwanted command over X10?
Can you provide full debug transaction of the A1 on, A2 on, A1 off sequence?

Cheers,
g.

[bkenobi]

It looks like the new dll is working just as well as the old version.  I still see an issue with commanding multiple HU codes on at the same time as is documented on github.  I'll continue using this library and see if I find any new issues.

[Gene]

Hi bkenobi,

the new version is 50-100ms faster. I'm attacching here also the fix to the issue #30 for you to test.
@pim555 please keep testing the previous attacched version as this one might contains issues (hope it doesn't).

Cheers,
g.

[pim555]

Thanks Gene, will give this one a try later on today.

How do I install? Just copy these files over the existing ones after stopping the HG service and then re-starting?

[bkenobi]

Yes

Stop HG
move/delete/rename old X10 library files
copy new files
restart HG

just make sure you use sudo on every command since it's a system directory.

[bkenobi]

I attached my test procedure and individual results since they were too long for this forum.


So, it looks like there is an issue with the storage not getting purged.  It appears that the modules turn on in a different order than when sent (I don't know if this is an issue for anyone, but worth noting).  The first time a series of commands was sent, the first UC was not actuated (did not repeat, but did happen once).  Looks like the code is pretty close!

[Gene]

Hi bkenobi,

thanks for the detailed report. So UC storage array has to be reset everytime a Function code is sent. I corrected the behaviour in order to respect that.
I have one concern about one optmization when sending commands from HG.
If you now do a eg. A4 ON, XTenLib will send house code and unit, followed by housecode and function (so 2 X10 commands).
But this only the first time. If you keep sending commands on A4, HG will now send only the house code and function command (so just 1 command and so half the time to perform it). You can see this from the console.
Just wondering if this is an accetable optimization, of if this can create issue. In that case I will disable it.
I'm attacching fixed dll, but still with this optmization so you can test.

Cheers,
g.

[pim555]

My virus scanner goes haywire on the two files provided for testing. Fake alarm or...?

[pim555]

Gene,

I guess it is false alarm but appreciate if you can confirm and maybe have it whitelisted.

http://community.norton.com/en/forums/clarification-wsreputation1-detection

[Gene]

I guess it's false. File was generated in Linux anyway.

g.

[bkenobi]

Yes, that is the correct way to implement (only send UC if the command is for a different set of UC's).  I'll try this out later today.

[Gene]

I'm finally implementing decoding of X10 RF commands in XTenLib.... =) perhaps tomorrow it will be ready.

g.

[bkenobi]

It looks like almost everything is now working.  The only thing I found an issue is that HG missed the first UC on the first test.  This is exactly what happened last time too.  Is HG missing the first UC it sees after startup? 

I performed one more test and believe I have confirmed that HG doesn't accept the first UC and possibly the first X10 string of any kind (don't know how to verify a command works or not).