Extended X10 Commands (Leviton DHC) [resolved in v3.0.0.38]

[johnhicks]

public void Main(object[] parms)
{
object[] values = {"L1", "Extended", 40, 54, false };
hs.PluginFunction("X10","","ExecX10", values);
}

The code executes without an error, but it doesn't do what I expect. Instead of executing the extended command, it set the extended dim value on L1 to the data value! In other words, the function seems to be ignoring the command byte and sending only the extended dimming command on the specific unit/house code. I cannot tell what role the house/unit could should play, but I think then answer should be "none"; instead, it is the only device impacted.

I found a related thread (http://board.homeseer.com/showthread.php?t=89817) where this was discussed and it seemed to be working in a previous HomeSeer version.

Why can't I send an extended command out the HS3 CM11A X10 interface!

Thanks for whatever help someone can provide!

John

[mfisher]

John,

Here is the definition for the ExecX10() function in the HS3 version of the plugin:

Sub ExecX10(ByVal code As String, ByVal cmd As String, Optional ByVal dimv As Integer = 0, Optional ByVal data2 As Integer = 0, Optional ByVal wait As Boolean = false) As String
	' Parameters for ExecX10:
		' X10 Code As string		' such as "B2"
		' X10 Command As string	' "preset dim"
		' DimVal As Integer (0-100)	' dim % for standard X10 devices
		' Data2 As Integer (0-100)	' dim % for preset dim
		' Wait As Boolean			' always use False

Unfortunately it looks like the HS3 plugin currently treats the X10 Extended command as a Dim command and does alter the extended data values prior to passing them on to the hardware specific code. I will look into how to resolve or circumvent this behavior.

(09Dec2016 - UPDATED TO CORRECT ERRORS IN ORIGINAL POST)

[johnhicks]

Extended X10 Groups (Leviton DHC)

Thank you for the reply, Mark!

Curiously, that definition does not correspond to the public documentation you have published here, where it states that dimval should contain data1.
More importantly, changing to the method signature that you suggest gives me an error:
Error in PluginProc: Parameter count mismatch.

I really hope to get this working, so I hope you have other suggestions.

John

[Uncle Michael]

Curiously, that definition does not correspond to the public documentation you have published here, where it states that dimval should contain data1.

Just a clarification, the docs you reference refer to v2 of Homeseer. The ExecX10 function was changed for v3. The only documentation I'm aware of is here.

Also, FWIW, Mark is not responsible for this confusion. He has volunteered to try to help us all get through it, but his position is completely unofficial.

[johnhicks]

Extended X10 Groups (Leviton DHC)

Thank you, Uncle Michael, for the correction. Mark's answer was relevant enough that I thought he had inside knowledge!

It turns out that the method signature that Mark mentioned exists, but it is the Exec method (not ExecX10) on the CM11A object. That method is exactly what I need, but if there is a way to access the CM11A object from PluginFunction, I can't find it.

It appears that ExecX10 method determines the command type (7), then calls the ControlDevice method on the util object. Unfortunately, that last method assumes dimming logic and is hard-coded for dimming only. It does not pass data values. Contrary to the docs, there is simply no way to send an extended X10 command (other than dim).

I tried to see if there was any means of invoking CM11A.Exec(). I couldn't find one because PluginFunction is limited to its own class (HSPI) and nothing on that class will return a CM11A object. I'm still a little unsure about the limitations of the PluginAccess architecture. Perhaps there is a way to access a class (CM11A) within the project that I haven't discovered.

From my perspective, I see this as a bug in the X10 project code. At least, that's what we call it when the documentation describes behavior that is different than the implementation. The documentation says that it will pass a command and data value; the code has a hard-coded extended dim command.

Are there any workarounds? Is there any way to reference the CM11A object from within a script?

Any help is greatly appreciated! And thanks for the help so far!

John

[mfisher]

John, sorry for the confusion. I looked at the source quickly yesterday in order to help you resolve this issue. As you pointed out in your Bugzilla post (thank you very much for that!) I unfortunately looked at the wrong function and posted erroneous info. I've corrected my post above for future viewers.

As Michael pointed out, when HST said that they were no longer going to support the X10 plugin I volunteered to help resolve issues. In past years I have supported the Ti103 plugin under HS2. At first it was just the "X10" plugin for the CM11A & Ti103 and that expanded to the CM15A plugin as well. As much as I enjoy working on this, my business consumes most of my time which leaves me with precious little bandwidth to devote to this effort.

Understand that in HS2 each X10 interface (CM11a, Ti103, CM15a, etc.) had its own plugin and the idiosyncrasies of each were handled by the plugin. When plugins were being ported from HS2 to HS3, the CM11a and Ti103 code bases were rolled into a new X10 plugin with new code to glue them to the new HS3 architecture. While this works for the most part, there are things that do not work properly and can be rather messy to fix. This extended command issue is a prime example.

I will try to find a way to resolve this as soon as I am able.

[johnhicks]

Extended X10 Groups (Leviton DHC)

Thanks so much for volunteering to help, Mark. I was unaware of the history. I bought HomeSeer because it could combine my hodgepodge of home automation technologies. The Levition DHC scenes mostly work very well and there would be no need to replace them for newer technologies (Z-wave) if I could get them controlled by HomeSeer. They were also pretty expensive.

If you are "volunteering to resolve issues", does that mean that you could submit code changes? I would be willing to write the code to fix this. Rather than change the behavior of the existing method (and possibly break processes that rely on it), I would suggest a 2nd method, "ExecX10Extended", this would only send extended commands. It would be patterned after ExecX10, but much simpler because it only has one command type.

What are the logistics of this? Is that something you can merge with the code base?

I know I could write my own plug-in for this too, but that seems a much bigger investment. And I doubt that both plug-in processes would be able to access the CM11A serial port.

Let me know how I can help resolve this!

John

[mfisher]

John, thanks for the offer to help - I'll keep that in mind.

Yes, I have the source for these plugins and am able to submit changes to the updater once new code has been thoroughly tested and accepted by users.

Creating a new function just for extended commands is certainly a way to go, however doing this for each corner case gets real messy over time. I prefer to get the current interface to work properly when possible and only create new functions when absolutely unavoidable.

Given that, I just posted a new beta version that maintains the same interface, but completely changes the way that ExecX10() handles requests, and it now calls directly into the Exec() function for either the CM11a or Ti103 interface code as was done in HS2. This bypasses all internal plugin processing of commands when calling ExecX10() from a script and I feel this is a better solution since we all expect it to work the way it did in HS2 rather than new "mysterious things" happening in the middle. This does not change the way the plugin works for all other functions, just when calling ExecX10() from a script.

See this thread for the latest beta release: http://board.homeseer.com/showthread.php?t=185551

Please 'install' this beta (as described in the link above), throw as much stuff at it as you can and let me know what happens. I do not have any extended devices so can really only check that the interface is being commanded to send the correct data onto the powerline.

[johnhicks]

[mfisher]

Sorry about that, correct version is now uploaded as .38. Please let me know what happens.

[johnhicks]

Extended X10 Groups (Leviton DHC)

Mark:

The X10 plugin now works for extended commands! As of 3.0.0.38 I am able to send scene commands to my Leviton DHC devices. Thanks for fixing that bug so quickly!

If anyone is trying to figure this out (there is very little information available online anywhere), I should correct some of my original addressing suppositions, which turned out to be wrong:

• The HouseCode is critical. The docs say that the Relative Trigger is in relation to the house code, but then also says it is in relation to 16 S values. I assumed that the 16 S values and 4 G values would give me my 64 scenes. Nope, that's not how it works.
• The S values are some sort of starting offset. I haven't found a rhyme or reason for them (other than S3). The G values count up from the first scene. I just had to experiment with sequential S values (S0, S1, S2) until I found Scene 1. After that you increment G0, then G1, and then S3 for the remaining scenes.

For example, my living room lights happened to be assigned to "L", as was the scene controller. I triggered Scene 1 with data 34 (0010 0010). Why the 2nd bit is true is a mystery to me, but it is constant on all the scenes in this group. Scene 2 incremented the first of the two G bits (0110 0010 = 98), and Scene 3 counts up again (1010 0010) 162. Obviously, Scene 4 is (1110 0010) 226. That give you the first four scenes. Scene 5 resets the two G bits and increments S3 (0010 1010). You re-increment the G bits for Scenes 5 to 8.

When I switch to the master bedroom, with HouseCode "B", I discovered that the Scene 1 address was now (0010 0011) 35. Again, I have no idea why the bottom bits are different. When you set up a HXC&X-1TW remote, you specify a housecode and device number; possibly the lower the S bits correspond to the device number (I'm not bothered enough to investigate). Scenes 2 through 7 are by the same relative increments (35, 99, 163, 227, 43, 107, and 171).

So, the addressing was wrong, but the extended command was right: Type 3, Command six = 54, as I described in my first post.

Invoking the extended command for Scene 1 in my living room is:

public void Main(object[] parms)
{
object[] values = {"L1", "extended", 34, 54, false };
hs.PluginFunction("X10","","ExecX10", values);
}

I hope this helps others who want to understand DHC/Toscana scenes.

I can now trigger every scene in my home!

John

[mfisher]

Thank you for letting me know that the changes are working for you, and for the details on using extended X10 with the Leviton system.

I'll mark this as resolved in BugZilla and here on the board. Please let me know if you encounter any issues!

[Guest]

CM15a Plugin

Hello,

I think I'm experiencing the same issue using the CM15a plugin with Leviton DHC. I'm using a homeseer SEL with the CM15a interface. Any chance on getting this fixed?

Thanks

[mfisher]

Hello,

I think I'm experiencing the same issue using the CM15a plugin with Leviton DHC. I'm using a homeseer SEL with the CM15a interface. Any chance on getting this fixed?

Thanks

Hello and welcome to the HS board!

Unfortunately I do not have the source code for the Linux version of the CM15A plugin. I will make a request to HST for this and look into this when I get a chance.