X10 still not quite right

[bkenobi]

I noticed the other day that HG doesn't interpret X10 commands quite right.  I have 4 lights in my back yard that I turn on with a SC503 Maxi Controller.  This device has buttons for each of the 16 unit codes and each command.  To turn a light on with this device, you would press the unit code and then the ON command.  If you want to turn multiple lights on at the same time (with the same house code), you press each unit code and then the command.

So, if I press:
A2, A3, A4, A ON

All lights turn on correctly.  But, HG does not seem to understand this sequence.

Mono log:

Code: [Select]

[08:03:13.291712] X10 > 5A 02 00 6E
[08:03:13.295153] X10 > PLCRX: 5A 02 00 6E
[08:03:13.298003] X10 > FNMAP: 00
[08:03:13.300828] X10 >  DATA: 6E
[08:03:13.303811] X10 >       0) House code = A
[08:03:13.306583] X10 >       0)  Unit code = 2
[08:03:13.712743] X10 > 5A 02 00 62
[08:03:13.716326] X10 > PLCRX: 5A 02 00 62
[08:03:13.719174] X10 > FNMAP: 00
[08:03:13.722003] X10 >  DATA: 62
[08:03:13.725001] X10 >       0) House code = A
[08:03:13.727874] X10 >       0)  Unit code = 3
[08:03:14.126374] X10 > 5A 02 00 6A
[08:03:14.129762] X10 > PLCRX: 5A 02 00 6A
[08:03:14.132598] X10 > FNMAP: 00
[08:03:14.135484] X10 >  DATA: 6A
[08:03:14.138527] X10 >       0) House code = A
[08:03:14.141299] X10 >       0)  Unit code = 4
2014-09-21T08:03:14.2149900-07:00       HomeAutomation.HomeGenie.Automation     35      Automation Program      Program.Status  Running
2014-09-21T08:03:14.3036150-07:00       HomeAutomation.HomeGenie.Automation     35      Automation Program      Program.Status  Idle
[08:03:15.042949] X10 > 5A 02 01 62
[08:03:15.046602] X10 > PLCRX: 5A 02 01 62
[08:03:15.049493] X10 > FNMAP: 01
[08:03:15.052298] X10 >  DATA: 62
[08:03:15.055368] X10 >       0) House code = A
[08:03:15.058311] X10 >       0)    Command = ON
2014-09-21T08:03:15.0617620-07:00       HomeAutomation.X10      A4      -       Status.Level    1

Attachments:

• Lights before sending the command.  All lights are off.
  
• Lights after sending the command.  Only the last UC (A4) was processed which is what the mono log indicated.
• The HG web log indicates only A4 was processed as well.

[Gene]

Ok I'll look into this.

Also please file a issue on github so we won't forget.

g.

[bkenobi]

Issue submitted.

[bkenobi]

I just realized this issue causes more problems.  If HG does not know that a light is on, it will not fire the event in the event scheduler.  So, if the lights in the back yard are turned on to put the dogs in the kennel and HG only sees the last light, it doesn't know that the others are turned on.  When the sun rises and the sunrise event fires, the one module that HG knows is on will be turned off, but all others will remain on until manually turned off.  This means that I'm burning ~600W for 10+ hours a day for no reason.  One time is not a big problem, but this is going to happen every day until spring and that's going to add up on my electricity bill.

The current work around is to either:  turn the lights on one at a time (my wife probably won't do this); turn the lights on from a different controller (wife will likely grumble about "stupid automation"); or try to make sure lights are turned off when it's still dark (defeats purpose of leaving them on for the dogs).

[bkenobi]

I was thinking about X10 and scheduled events last night and now believe that the scheduler needs to be modified.  The way I believe Event Scheduler is set up is that when an event is seen (dusk, dawn, 12:34pm, etc) HG will look at the module(s) that have this event set.  If the module is on and it has an off event that corresponds, it will switch the module off.  If the module is off and it has an on event that corresponds, it will switch the module on.  BUT, this requires that HG know the current state of the module and that state be synced correctly to the actual module state.  With X10, there are many instances when this is a bad assumption:

• HG didn't see the command on PLC (like the bug I posted here)
• The command to turn on/off the module was issued locally (most X10 modules don't send PLC with local commands)
• HG was not functioning at the time of the command (controller issue, system restart, etc)

Either way, HG can't status most modules so it has no way to synchronize the state.  I would prefer that the event be fired even if the module is already in the event state.  In other words, I want HG to send the OFF command for all of my lights in the back yard even if HG thinks they are already off.  This won't hurt the module and HG will just add the event to it's log but it may fix synchronization of states.  No down side, only benefit!

[bkenobi]

I have modified the Energy Management->Scheduled ON/OFF module to eliminate the dependance on what state the module is currently in.  I assume any updates to HG will likely overwrite this, so I suspect I'll have to duplicate the built in code and move it to my personal scripts folder and then disable the original.

[bkenobi]

I decided that I wanted to provide an update that could fully replace the original Scheduler module.  I hope this code will help someone.  It now offers the capability to force a command to be sent for specific modules.  I also made sure to update the UpdateTime, LastUpdateTime, and LastValue fields.  I'm hoping that this will be sufficient for inclusion into the next release such that I don't have to keep my own Scheduler script.  Thanks!

[codedmind]

I will try it tomorrow!

Great work

[Gene]

I'll try this too.. didn't notice of it before.

Cheers,
g.

[carlosmaug]

Hi

After expending some time looking to the code.. I wonder if there is a reason why homegenie implements all x10 protocol by it self instead of using an external program like mochad.

I say this because mochad does it great with x10, and is very easy to communicate with it (it is a daemon listening on port 1099) It will be nice to dedicate our efforts to do "magic" things instead of reimplementing what is already done and works fine.

¿What's the general opinion about it?

Bye :-)   

[bkenobi]

I played with Mochad briefly and found that it worked fairly well.  But, I don't know about how long things would take to run with HG vs Mochad.  I think it's something to consider since it's already implemented.

[pim555]

I had exactly the same thought when I started looking at the Xtenlib code. Seems to be quite a lot of low level functionality to maintain and optimize. I was triggered by this thought after experiencing some issues with X10 control via HG in my home. Not sure how I can run mochad on RPI yet but if I would like to give it a try to see if my issues with X10 are gone when using mochad. If that is the case, I definitely would vote for implementing a mochad driver within HG.

CHeers
Pim.

[bkenobi]

I did some basic testing with raspi based HG versus mocha and found that mocha was slightly fasted.  But, that was not linking it to HG.  If someone knows how to work with mocha and were to build an interface, I'm sure it would get some interest!

[pim555]

As explained in my other post...I do get correct behavior when using Mochad on RPI to control my X10 devices via CM15Pro. When using HG, behavior is not as expected.

For me it would make sense to integrate Mochad into HG but I don't have sufficient Linux knowledge to do so. Not for the issues I am having, as I assume these can also be solved in the XTenlib, but more as Mochad is considered as pretty stable, cross platform, X10 control.

Regards
Pim.