Thermostat Device

[ericvic]

I've just started playing around with HouseBot and it looks pretty good. I've been a long time HomeSeer user but have never been completely satisfied with it.



I want to make a device for a RCS TX15B thermostat and I'm confused about a few things. I have read some of the documentation and look over the sample code but not very well. I understand how tasks and software remotes can change properties to have the device send X-10 to the thermostat. What I don't understand is how the device will get incoming X-10 so that it can update its properties.



I hope that was understandable.



Thanks,

Eric

[ScottBot]

Eric,



A HouseBot X10 Device will automatically update its Power State Property to On or Off when it receives an incoming X10 command on the Power Line. You don't have to do anything extra with Tasks just to get the Device to show the new state. If the Property Value is associated to a control on a Theme/SW Remote, it will automatically be updated on the remote as well.



If you want to act on the new value, you will need to create a Task that uses the Property Value in a condition statement.



Hope that helps. If you want help on a specific example, let me know.

[ericvic]

Scott,



Thanks for the quick reply but that didn't completely answer my question.



For the thermostat device I'm going to have properties like mode (heat, cool, off, auto), setpoint (some temp), fan (off, on), etc... Those actually map to different preset dims and the thermostat device, unlike most other X-10 devices, uses an entire housecode. So I need some way for the device to receive all incoming X-10 commands for its housecode so that I can decode them and set the correct properties.



Thanks,

Eric

[ScottBot]

Eric,



It depends on how, exactly, you are going to 'implement' the Device.



If you going to write your own Device using the Plugin SDK, you can subscribe to certain events that are sent from the X10 Hardware Interface (I can give you more specifics later). Once subscribed, you will get notifications when X10 commands are received from the interface and you can then parse the commands and update your mode, setpoint, etc. properties as needed.



You may also be able to just take a NULL Device and add the appropriate Properties that you need. Then Create an X10 Controller Device. The X10 Controller will receive all of the incoming X10 changes and display them in a Property Value. You can then use a Task and VBScript to manage the Properties in your NULL Device. It's more of a hack, but you could do it without writing a new plugin.



I've considered writing a plugin for thermostats, but never got around to it. I think you could do some cool things with the configuration. For example, the user could configure all of the on-off times/temps in a graphical UI that the Device manages and controls. Just the ability to easly set the programming on the thermostat would be worth the price of the thermostat for me.

[ericvic]

Scott,



Sorry I didn't say it before. I plan on writing a new device using the SDK and VC++.



After I posted I look at the device class a bit more and noticed the SubscribeToNotificationList() and SubscriptionNotification() methods which I'm going to play around with a bit when I get a chance (hopefully by the weekend). Do you have any sample code that uses these methods?



Also I noticed that you launch a seperate thread for each device. It looks like a neat design but does it not load the system down too much if there are many devices?



You mention having the on/off times in the device itself. How would you see a device doing time sensitive operations without using a task. It seems like a device mainly sits in the DeviceRun() method and waits for property changes. Sorry if this is an easy one but remember that I haven't played around with the software very much yet.



Thanks,

Eric

[ScottBot]

Eric,



Unfortunately the sample app in the SDK doesn't use the subscription stuff. I guess it could. Maybe I'll add that to the 2.0 SDK. If you are running the 2.0 beta, you may want to start using the 2.0 SDK (which isn't posted yet). Let me know if you want me to send you a copy before the release.



The subscription stuff is fairly simple, although a sample would be nice. Are you planning on using one of the existing X10 Hardware Interfaces supported by HouseBot? If so, I can give you the name of the subscription lists that they broadcast so you can catch the events.



As you mentioned, each Device runs in its own thread. Most of the time Devices simply wait on a 'WaitForMultipleObjects()' call. Most of them simply wait for a Property change request to trigger a semaphore to unblock the wait. In Win32, this call essentially takes the thread out of the thread switching management, so they consume virtually no CPU.



The nice thing about having your own thread is that you can do whatever you want in them. For example, the SleepTimer Device does a WaitForMultipleObjects() using a timeout value of the timer. When the timer expires, WaitFor....() falls through and the Device can do its work. You can do the same thing with a thermostat scheduler. Simply set the timeout of the WaitFor...() to the number of seconds before the next temperature change. It's a bit more involved than that since you have to reschedule things if they change the setpoints, but it's very possible to do in the Device.



I'll be happy to help you get started on this, as it's something I'm somewhat interested in myself (as I mentioned before).



I suggest getting familiar with the sample app that comes with the Device SDK. Once you get the feel for how that works, I think you'll see that there's not really much to it.

[ericvic]

Scott,



I am using the 2.0 beta so the newest SDK would be nice.



I will be starting with the CM11A hardware device but if HouseBot works out for me then I will be creating a new hardware device to support the LynX-10 PLC device. I you could give me any info I should know about the CM11A hardware device that would be good because I would want the LynX-10 PLC device to work the same as much as possible.



I was thinking more about how to implementing the scheduling process in the thermostat device and had basically the same thoughts as you about having the WaitForMultipleObjects() have a timeout.



I would welcome any ideas you have on the thermostat device. I'm going to start simple but would like to add a bunch of functionality as time permits.



One last thing. Is anyone working on a device to support 1-wire devices? I have a weather station and a few other 1-wire devices that I would like to use with HouseBot. That is one nice thing about HomeSeer, it has really good support for 1-wire devices.



Thanks for your help.



Eric

[ScottBot]

I've updated the samples in the 2.0 SDK's to use the notifications. It's a fairly crude example, since these things usually are dependent on the usage, but it at least shows the general idea.



If you build and install the hardware interface sample (from the hardware interface SDK) and the MessageBox Device (from the Device SDK), you can send a notification to the MessageBox Device from the interface by pressing a button in the interface property screen.



You can download the 2.0 SDKs from the links below. Make sure you are running beta 3 of version 2.

Device SDK 2.00

Interface SDK 2.00



The CM11a sends out two different notifications.

• X10 Reception - Use filter of "H=%d;U=%d" where %d values are for the house code and unit code the device is interested in. Data pack contains Command.
• X10 Reception (ALL) - Use no filter. Will send All X10 activity. Data pack contains data HouseCode, UnitCode, Command.

Some of this might not make much sense until you dig into it a bit, but I wanted to list it here so when you come to it you'll have some of the specifics.



With the CM11a your device will get notified of the X10 commands. If you create an X10 Controller Device, you can see pretty much what is sent by the CM11a in its Composite Property value.



When you start looking at a Lynx-10 PLC plugin, we can get into that. If you plan on sharing the plugin with the community, I'll send you the source for the CM11a plugin as an example.



I've heard talk of others wanting support for 1-wire devices, but haven't heard of any plugins. I don't know much about them.

[ericvic]

Scott,



I'll get the SDK later today and check it out.



If I use the X10 Reception notification do I have to pass both the house code and unit code? My device will need all X10 for an entire house code. If not I will just use X10 Reception (ALL) and filter out what I don't need.



If and when I do the LynX-10 PLC plug-in I will share it with the community. No need to be stingy especially since you have shared all the hard word you have done to create HouseBot.



I'll leave thinking about the 1-wire plug-in until later.



Thanks,

Eric

[ScottBot]

Eric,



I would just use the X10 Reception (All) and filter it (as you suggested). The alternative would be to subscribe to the X10 Reception list multiple times with different filters.

[ericvic]

Scott,



Will do.



I'll let you know how it turns out.



Eric

[Automate]

There is a way to get 1-wire values into HouseBot. You can use henriksen's 1-wire free wserver software. The software includes a DDE server. Then you can use a HouseBot DDE client plug-in written by member pzand to get the values into HouseBot. Its a long thread but you can read more about it here:

http://www.housebot.com/phpbb2/viewtopi ... ight=1wire



pzand sent me a copy of the DDE client plug-in and a weather plug-in. At one time Scott offered to post a copy of the plug-in on the HouseBot site but I doubt pzand saw the post.

[ericvic]

Scott,



I would like to say that there is a bit of an initial learning curve to writing a new device (but that is to be expected), but that you have written some pretty nice software.



Another easy question. I have the beginning of my thermostat device created and it has all its properties but now how do I send out X-10 commands?



Thanks,

Eric

[ScottBot]

I would like to say that there is a bit of an initial learning curve to writing a new device (but that is to be expected), but that you have written some pretty nice software.

It sounds like I could enhance the sample by giving an example of how to create your own Properties and values.

Another easy question. I have the beginning of my thermostat device created and it has all its properties but now how do I send out X-10 commands?

Actually, thats a hard question Generally if you write a Device Plugin you have written the Hardware Interface plugin too, so you know the interface API between the two. Since you're using an existing X10 Interface, I'll need to give you the details of the API.



The CM11a supports three separate Interfaces (functions). You can see these if you click on the top item in the CM11a Property List. I'll give you the info for the SendX10() function. If you need the others, let me know.



First, your DeviceInfo struct needs to contain the signature of all of the interfaces that your Device needs. This will limit/include which Hardware Interfaces the New Device Wizard will display when setting up the Device. Make sure you specify the SendX10() function. Here's a snippet from one of the HouseBot X10 Devices. The signature is very specific, so enter it exactly as specified below.

Code: Select all

DeviceInfo	CX10DevicesApp::m_X10TransmitterDeviceInfo = {
   0,
   "X10 Transmitter",
   dtHardware,
   "SendX10( HouseCode, UnitCode, Command, RepeatCount )",
...

Now when the Device actually needs to send the command to the Interface, you need to create an InterfaceArgumentPack and send it along. Here's a snippet that should get you most of the way there.

Code: Select all

HARDWARE_RC CX10Device::SendToX10Interface( 
    const char * szHC, 
    const char* szUC, 
    const char* szCMD, 
    int nRepeatCountOrDimLevel )
{
  //
  // Construct the Interface Argument Pack
  InterfaceArgumentPack   Pack;

  //
  // Setup the Pack
  Pack.m_nArgumentPackVersion = INTERFACE_PACK_VERSION;
  Pack.m_szInterfaceSignature = "SendX10( HouseCode, UnitCode, Command, RepeatCount )";
  Pack.m_nNumberOfArguments = 4;
  Pack.m_aArguments = new InterfaceArgument[ 4 ];

  //
  // Assign the arguments.
  Pack.m_aArguments[ 0 ].m_atType = atStringValue;
  Pack.m_aArguments[ 0 ].m_szStringValue = szHC;

  Pack.m_aArguments[ 1 ].m_atType = atStringValue;
  Pack.m_aArguments[ 1 ].m_szStringValue = szUC;

  Pack.m_aArguments[ 2 ].m_atType = atStringValue;
  Pack.m_aArguments[ 2 ].m_szStringValue = szCMD;
  
  Pack.m_aArguments[ 3 ].m_atType = atIntValue;
  Pack.m_aArguments[ 3 ].m_nIntValue = nRepeatCountOrDimLevel;

  //
  // Now send it off.
  HARDWARE_RC Rc = SendInterfacePackToInterface( &Pack );

  delete [] Pack.m_aArguments;

  return( Rc );
}

Hope this helps.

[ericvic]

Scott,



Thanks, that will get me going again. I will have to use SendPresetDim as well but it should be easy to figure out from the example you gave me.



Eric