LinuxMCE Forums

Archive => Archive => Pluto Main General Issues => Topic started by: archived on August 05, 2005, 06:20:53 pm

Title: Will Pluto listen to X10 commands?
Post by: archived on August 05, 2005, 06:20:53 pm
I came across the Pluto site yesterday. I have been using X10 stuff (controlled by a Homeseer-running PC) for about 5 years now. Asterisk has been in production for about 6 months.
I can't wait to free-up a machine to test drive Plutohome!

I have a bunch of these:
http://www.smarthome.com/12063W.html
along with a number of X10 RF remotes/occupancy sensors/RF receivers.
They are used to directly control X10 modules but also to start lighting scenarios -controlled by the Homeseer software- based on keypresses or room occupancy.

One question on the X10 part though:
Pluto can control X10 modules through a CM11a (On/Off/Dim) but does it also *listen* to X10 commands issued by X10 keypads/controllers?
I have seen a thread mentioning the development. Did it work out?

Regards,
Erwin
Title: Will Pluto listen to X10 commands?
Post by: archived on August 05, 2005, 06:57:56 pm
Hi Erwin,

I asked the guy who maintains the cm11a, and he said he didn't get to it yet.  Also he's leaving on vacation for 2 weeks starting Monday, so he won't be able to get to it till he gets back.  Sorry.

It's a trivial deal once he gets to it, he's just pretty busy since he also maintains other lighting control modules too.
Title: Will Pluto listen to X10 commands?
Post by: archived on August 05, 2005, 07:07:07 pm
Thanks!
It's vacation time over here also.

Good to hear it's in the pipeline!

Regards,
Erwin
Title: Will Pluto listen to X10 commands?
Post by: archived on August 17, 2005, 08:17:51 pm
Hi,

I'm also interested in this feature (having Pluto listen to X-10 signals).  I was just about to program my own home automation system (using heyu2 or wish to communicate with the CM11A) when I came across Pluto.  I may now wait and see if Pluto will provide this support.

Here are my needs for the listening to X-10 signals:

1) I plan to install magnetic switches on my garage doors.  These magnetic switches will be connected to an X-10 Powerflash unit (http://www.smarthome.com/4060.html), which will then turn on garage and house lights when the garage door is opened (if it's dark outside).

2) I would like to replace my fan switches in my bathrooms (for the showers) with 2-way sending switches so that I could turn on the exhaust fans at the switch when I take a shower and have them automatically turned off (by the CM11A) after a preset time (maybe an hour).  This would make sure the humidity in the bathroom is exhausted without requiring me to remember to go back and turn off the fan.

These functions would require X-10 listening and also "if-then" functionality so X-10 signals could be transmitted as appropriate.

Thanks!
Title: Will Pluto listen to X10 commands?
Post by: archived on August 17, 2005, 09:48:49 pm
I assigned a mantis to our cm11a guy which you can track here: http://plutohome.com/support/mantis/view.php?id=980

He'll be back from vacation next week and is a bit backed up with several other requests for new GSD devices.
Title: Will Pluto listen to X10 commands?
Post by: archived on August 21, 2005, 06:39:33 pm
Probably beating a dead horse here, but X-10 support in Pluto needs to be significantly enhanced to compete with HomeSeer and the like.

Specifically, we need to be able to send ALL X-10 commands, including extended codes (this way we can use, for example, SwitchLinc specific codes for dimming).  We also need, obviously, the ability to see 2-way devices and status-only devices so that we can include them in our events.

Since I'm no Richie Rich, I have an all-X10 installation which is now pretty stable.

It has my vote for high priority enhancement of the month :-)

Once I get Visual Studio 2005 Beta 2 installed on my box, I'll try to aid this and other efforts.

Dan
Title: Will Pluto listen to X10 commands?
Post by: archived on September 05, 2005, 05:07:55 am
another Vote in for X10 listening. I have a wireless alarm system that is X10 compatable that would be great to interface with Pluto :D
Title: Will Pluto listen to X10 commands?
Post by: archived on September 06, 2005, 01:17:02 pm
and another vote again ! everything is X10 at home ... I need it too  :)
Title: Will Pluto listen to X10 commands?
Post by: archived on September 06, 2005, 01:52:37 pm
This task is on my list.
I need some time to finish my current tasks (1-2 days) and then I will need more information about your X10 devices, especially those that are sending commands back to computer like  alarm system.
Title: X10
Post by: archived on September 06, 2005, 04:10:00 pm
Quote from: "torindan"
This task is on my list.
I need some time to finish my current tasks (1-2 days) and then I will need more information about your X10 devices, especially those that are sending commands back to computer like  alarm system.


There are basically three types of X10 device.

1) Receive-only (1-way) devices like el-cheapo switches.

2) Send/Receive (2-way) devices like newer switches.  They both receive an X10 command (e.g., ON) and send their status out when queried.  Some, like the SmartHome SwitchLinc actually echo their commands when manually hit (e.g. they send an ON when physically pressed).

3) Send-only (1-way) devices like dusk/dawn and motion detectors, which only provide status reports when some event happens.

My entire home is outfitted with #2 and #3 type devices.  I have no receive-only devices -- which is why X10 listening is so important.

To be useful, your efforts should support the extended X10 command set.

I presume there will be events in the event system for responding to incoming X10 messages.


Thanks,
Dan
Title: Will Pluto listen to X10 commands?
Post by: archived on September 06, 2005, 04:58:18 pm
I know the type of the devices, but us far as I know you can set on their back which device to trigger.
I only have recieving devices here. So i'm not qiute sure what will happend in this situation :

Motion detector detects motion and sends ON to A1, A2 and so on.

Is anything sent to computer? (it doesn't have a code assigned to it, so I only hope that I will be informed via X10 protocol)

Can you search your CM11 logs (in /var/log/pluto/) for string "CM11A wants to notify us of Something"
Title: Will Pluto listen to X10 commands?
Post by: archived on September 06, 2005, 06:40:37 pm
Quote from: "torindan"
I know the type of the devices, but us far as I know you can set on their back which device to trigger.
I only have recieving devices here. So i'm not qiute sure what will happend in this situation :

Motion detector detects motion and sends ON to A1, A2 and so on.

Is anything sent to computer? (it doesn't have a code assigned to it, so I only hope that I will be informed via X10 protocol)

Can you search your CM11 logs (in /var/log/pluto/) for string "CM11A wants to notify us of Something"


You're thinking about it wrong.  X10 can certainly be set up that way, but that is NOT the way it's done when there's a computer involved.

I have a motion detector, M1, near the mudroom door on my porch.  I have exterior lights, interior lights, etc., all with their own housecode/unitcode.

When M1 goes off, it wirelessly sends M1 ON to my W800RF, which goes into the computer.  If this were a wired device, it would send it to the CM11A.

The point is, you don't set the motion detector to "turn on a device" -- it IS the device.  When it says ON, the computer decides what to do based on user-controlled "programming".

For example, here's a typical rule:

WHEN M1 changes from OFF to ON
   AND M1 has not been triggered previously in the last 30 seconds
   AND homeowner is AWAY

THEN turn E10, E11, and E12
   AND trigger the Speak Package Instructions script using FRONT PORCH SPEAKER.


I see "CM11A wants to notify us of Something" in my logs all over the place.

P.S. In accordance with the laws of nature, my server died this weekend.  I have to rebuild it over the next week or two :(
Title: Will Pluto listen to X10 commands?
Post by: archived on September 07, 2005, 08:45:17 am
Ok then, good news is that pluto is notified.

I wasn't sure because a few months ago we got a reguest for bidirectional X10, but the person reported that he never saw that string in his logs, so I didn't know if motion detector sends anything to computer and how it really works.

Bad news is that in the code which receives messages from CM11 doesn't trigger events.
I don't know too much about all X10 devices (there are to many of them) so please post your suggestions here about what device could trigger what.

For example if motion detector is triggered than we should send an alert to security plugin.

If some other device then we must notify this and this. and so on.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 07, 2005, 01:49:44 pm
Quote from: "torindan"

Bad news is that in the code which receives messages from CM11 doesn't trigger events.
I don't know too much about all X10 devices (there are to many of them) so please post your suggestions here about what device could trigger what.

For example if motion detector is triggered than we should send an alert to security plugin.

If some other device then we must notify this and this. and so on.


I suggest that you do NOT try to do that at first.  I would simply adhere to generic X10 devices rather than specific.  I would create events that look like this:

- When an X10 device changes from OFF to ON
- When an X10 device changes from ON to OFF
- When an X10 device changes state
- When an X10 device is ON for x seconds
- When an X10 device is OFF for x seconds
- When an X10 device is set to value (=,<,>,<=,>=,!=) x
etc.

Don't try to understand what the X10 device really is -- it's too high level and most X10 devices can be treated as black boxes with an address and a command set they support.

We'll also need the extended command set for both sending and receiving X10 commands.

And lastly, I think the person you were talking to was probably complaining that his motion detector wasn't being recognized by Pluto because it wasn't!  The motion detectors are typically wireless and frequently go through something like a W800RF rather than a CM11A.  The W800RF receives all 256 codes and sends them directly to the computer.  HomeSeer has a driver for this device.

Dan
Title: Will Pluto listen to X10 commands?
Post by: archived on September 07, 2005, 04:31:48 pm
I have to disagree with you...

If a motion detector is triggered, I want pluto to know this, because beside of X10 devices there are a lot of other devices which integrates with pluto for example survailance cameras.

Right now you have a posibility to be called on your mobile phone if there is a security event in your home (motion detected by survailance camera or, in near future, by X10 motion detector) so you probably won't care what kind of device detected the motion, you want to be notified. If you also want to light some X10 lights it's ok, but you probably will want the behavoir to be consistent no matter what kind of device was triggered.

Another example: the "follow me" command right now based on bluetooth devices, which detects in which room are you (actually your mobile phone). The same behavior probably can be done with motion detectors.
Follow me doesn't only work with lights, but also with media (like playing music or video) which follows you in each room.

So we should start thinking right now what we really want to do when a X10 event arrives, not just send back X10 commands and postpone solving the real thing.

This probably will take some time to implement so if you desperately need X10 reaction right here, right now, you can try to communicate with your devices via Generic_Serial_Device. Which permits you to send/receive commands to/from device by writing small chunks of Ruby code.
To find out more read http://plutohome.com/support/phpbb2/viewtopic.php?p=1243
Title: Will Pluto listen to X10 commands?
Post by: archived on September 07, 2005, 05:06:01 pm
Quote from: "torindan"
I have to disagree with you...

If a motion detector is triggered, I want pluto to know this, because beside of X10 devices there are a lot of other devices which integrates with pluto for example survailance cameras.


For what it's worth, I agree and understand that, in the end, Pluto should have full integration with a bunch of nice features like follow-me.

I'll leave the scheduling to you.  If it were ME, I'd do the BASICS first and THEN I would integrate that into my product more tightly.  You're going to have to do a lot of testing and debugging and I don't really see the point of working towards the end result first prior to getting the basic homework done.

I tend to do the core work first (which other people can then use to create their own scenarios) and then integrate with nice features afterwards.  But that's just me.

Dan
Title: Will Pluto listen to X10 commands?
Post by: archived on September 07, 2005, 10:53:17 pm
Hi,

I agree with Dan.  I believe that the majority of the people will be initially served best by having the ability to have Pluto listen for X10 events and then give us the ability to choose which X10 commands to send out.  I'm sure we all want the more advanced features, but the basics will serve a lot of people and provide more functions for more people.

As he mentioned.  It's not really important which device created the event or what that device does. It's not important to have "static links" between devices.  Initially, the important thing is for Pluto to be able to listen for X10 events and allow us to decide what devices to trigger from those events.

This allows people the flexibility to make their house perform whatever tasks they wish.  Some people have mentioned that they have an X10 door sensor, that when triggered, turns on lights (if it's dark outside).  Some people want lightswitches to turn on fans for a specific period of time.  Some people want curtains to open from an X10 switch.  Some people want alarm systems to trigger lights in the house.  Most all of these tasks can be served with a basic X10 if-then event system.

If there was a simple method where we could do some basic "programming", it would be great.  Dan gave a good example of the type of "programming" most of us would use.
He said:
----------------------
WHEN M1 changes from OFF to ON
AND M1 has not been triggered previously in the last 30 seconds
AND homeowner is AWAY

THEN turn E10, E11, and E12
AND trigger the Speak Package Instructions script using FRONT PORCH SPEAKER.
---------------------
Basically, we need some if-then logic and some "and-or" logic and some type of timer and the ability to look at the clock/time.  For example, when I open my garage door with the remote control, I have an X10 event that fires (let's say it's "A1 ON").  If it's dark outside (night), I want it to turn on the light inside the garage and the outside driveway lights.  I need the computer/Pluto to allow me to program something like this:

IF A1 FIRES ON AND TIME >18:00 AND TIME <05:00 THEN FIRE A2 ON AND FIRE A3 ON.  SLEEP 240.  FIRE A2 OFF AND FIRE A3 OFF.

or, another example.  If I have an X10 switch hooked to my bathroom fan (which exhausts the humidity from the shower), I would like it to automatically turn off after an hour.

IF B1 FIRES ON THEN FIRE B3 ON.  SLEEP 3600.  FIRE B3 OFF.

 If you can give us the basic ability to listen for X10 state changes and then choose which X10 signals to send out, it will really serve a lot of people.   Turning a light on or off from the Orbitor is cool, but home automation, as far as X10 is concerned, really requires the ability described above.

-Lance
Title: Will Pluto listen to X10 commands?
Post by: archived on September 08, 2005, 01:13:37 am
Quote from: "lance_powers"
Hi,

Basically, we need some if-then logic and some "and-or" logic and some type of timer and the ability to look at the clock/time.  For example, when I open my garage door with the remote control, I have an X10 event that fires (let's say it's "A1 ON").  If it's dark outside (night), I want it to turn on the light inside the garage and the outside driveway lights.  I need the computer/Pluto to allow me to program something like this:

IF A1 FIRES ON AND TIME >18:00 AND TIME <05:00 THEN FIRE A2 ON AND FIRE A3 ON.  SLEEP 240.  FIRE A2 OFF AND FIRE A3 OFF.


I wonder if there's a way to open the entire API to scripting languages such as Perl.  I know you were able to wrap Ruby... this would be going the other way around.

Then, rather than you coming up with all this stuff initially, a huge number of developers can show you what's important by way of example.

This might be a quickstart way to get the X10 system tested and working, too.

Just my $0.02.  Value may be more or less in your part of the woods.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 08, 2005, 06:23:02 pm
Quote
I wonder if there's a way to open the entire API to scripting languages such as Perl. I know you were able to wrap Ruby... this would be going the other way around.


I'll 2nd this request.  I do most of my web/Internet programming in perl and I'd love to have the ability to control my X10 modules via perl.

If Pluto was able to listen for X10 events and allow us to interact with them in a perl environment, it would be wonderful.  This would allow all kinds of options.  I'm sure some many of us would be more than willing to share our perl code/modules and, in the end, would probably save the Pluto team many, many hours of programming time trying to fulfill all the X10 type requests.

This may also create an easy way for people to interface Pluto with MisterHouse and other popular Perl X10 programs.

-Lance
Title: Will Pluto listen to X10 commands?
Post by: archived on September 10, 2005, 11:37:42 am
what you're describing doesn't require any programming.  We have a database driven criteria evaluator, so you can say that when an event is triggered evaluate this:

Use the criteria builder which is just pull-downs and 'pick from a list':

[Room] = [Living Room]  [AND]
[Time of Day] = [Daytime] [AND]
[House Mode] = [Armed Away]

however since we are trying to target a mainstream audience, we knew that not only would programming be too difficult, but even a free-form criteria builder would be too difficult.  So we created the "canned events" which are defined in the canned events table.  In this case we give the canned events a description, like "watching media in a room" and put in the database what parameters we think a user would likely want to provide.  In this case I believe we add it 2 criteria fields, room and time of day, where time of day can be daytime or nighttime, which is calculated automatically based on the longitude and latitude of your city.  So the intent is that a total bonehead can just choose from the list and have the event be done.

so to accomplish what you're describing and there are four possibilities:

 1) if the scenario you're describing is something thatis general and broad enough to appeal to the mainstream audience, we can add a canned event that lets the userpick from some predefined criteria.  This is obviously the easiest and the least flexible.

2) you can build the criteria from the database yourself, rather than using the canned events.  This is a lot more flexible, but still relatively simple.  Note that it does not seem we have yet a web-based page to manually do this.  We only have the canned events page so far.  However it is easy enough to add this page and were going to do that anyway for the reasonably technically literate.

3) hopefully in about a month or so we will be extending our existing Pluto to Ruby interface to allow Ruby snippets that are used during the evaluation.  This would of course give your total flexibility to do virtually anything, but it only works for people who know Ruby.

4) write a new interface in Perl.  The good news is we can use the existing model that we used for our ruby/GSD interface.  And if the ruby to C++ SDK is similar to the Perl to C++ SDK, it's quite possible that much of the code could be shared.  The reason we opted for ruby instead of Perl is that unlike Mr. House which is totally geared towards techies, all of Pluto are paid staff so our focus is a totally mainstream audience that we can sell the product to.  We know of these four choices, a mainstream end-user will only be able to handle number one.  Some trained dealers will be able to handle number two.  although none of our dealers will have programming skills, some of them are fairly technically literate, so we wanted a GSD they could use to define the protocol to communicate with basic devices such as televisions and receivers with RS-232 interfaces.  They will not know programming at all, neither Ruby nor Perl nor C++.  The syntax of Ruby seems to be the most natural and non-technical so that somebody who has no programming skills good look at a GSD devicefor a Sony receiver, and try to copy and paste and adapted to a Panasonic, for example.  Ruby just seemed more simple and more natural than Perl for nonprogrammer.

we would really like to have a Perl interface, because even though we couldn't really sell it to our dealers, it would certainly help us get more open source users, and facilitate interoperability with Mr. House.  However our resources are pretty stretched as it is since we now have dealers shipping products and a lot of demands from them we have to meet.  So we just don't have the manpower in the house to add the Perl module.  particularly since we don't have any programmers on staff who know Perl very well, and not one who knows it well enough to do a integration like this.  So perhaps someone from the open-source community who knows Perl would be interested in working on this?
Title: Will Pluto listen to X10 commands?
Post by: archived on September 10, 2005, 07:49:10 pm
I think there's a subtle point being missed here.  I'm talking about the lowest level of a stack -- not the full stack.  Let me explain.

You guys are concentrating on a full stack -- that is, components and features that your nontechnical end users can appreciate and use in a simple fashion so that it makes their life easier.  Let's call this the High Level Interface.  This is what Pluto tries to put forth in its GUI.

However, underneath all of that is application code, written in C++.  Let's call this the Application Level Interface.  At this level, Pluto has written code (open source) that facilitates and drives most of the High Level Features, and on the flip side provides integration with the stacks below it.

Underneath the Application Level Interface is the Operating System Interface.  Here, you guys have built on Linux and created an easy-to-install, self-updating service which allows the Application Level Interface to run.

Each layer of the stack has integration points between each other.

What I am talking about developing is well below the High Level Interface -- probably at the Application level, maybe even lower.

So let's say we develop a bunch of lower-level services to handle X10 events, etc.  Maybe it's Perl, maybe it's Ruby, whatever.

Open source community -- being technical -- jumps on this and begins to create useful scripts, applications, etc.

Pluto simply takes this work and builds a High Level Interface (actually you'll likely find the open source community will do this for you) to make it easier for your users to work with it.

Here's a more detailed example.

1) You open up so that a larger group of developers can create scripts.  One developer creates an entire X10 Alarm System handling component, complete with events and so on.  But it's all driven by a config file and so on.

2) Pluto integrates the Perl codebase into its OS layer so that upgrades to Perl are done and the needed CPAN modules are loaded.

3) Pluto integrates the scripts into its GUI so that when you go to the Events system you see the events created for the X10 Alarm System, but they've been renamed/reworked to be less "developer like".

4) Pluto creates a new GUI layer for the alarm system for its Orbiters so that the end user can make modifications to the config file without knowing it's a config file and without knowing it's Perl and without knowing anything other than "Hey, this is easy and exactly what I needed".

The point is that we're talking about enabling low-level functionality that doesn't exist.  Your value-add is being able to take that low-level functionality and create a higher level of abstraction / interface so that your end users can use it.  Meanwhile, all of the technical folks get a chance to start enabling things and don't necessarily care about the GUI.  Or maybe they do.  Who knows.

So when we're talking about this stuff, remember we're just talking at a low-level -- we're not suggesting your end users should be exposed to this stuff directly.


Dan
Title: Will Pluto listen to X10 commands?
Post by: archived on September 10, 2005, 11:16:22 pm
just to be sure we're in sync...  you know that all Pluto devices communicate over a socket, so although our DCE library is in C++, any device could be written in any language so long as it uses the same protocol.  All the logic of Pluto is handled by devices which are exchangeable/hot-swappable.  DCE router is nothing but a message router--it has absolutely zero logic in it other than passing a message from one device to another.  so DCERouter imposes no restrictions--any device that all can register and start processing messages like commands and events.  DCERouter also supports a message interceptor mechanism.  This is where a device can pass in a criteria and say I want to be notified of all messages that meet this criteria.

for example, the media plug-in device registers that it once to receive all messages of command=abort ripping or event=ripping progress, because it always wants to know what ripping jobs are going on and have been completed, since it maintains all the attributes for media and needs to update the database.  This means any time any device, such as an orbiter, sends an 'abort ripping' command to the disk drive device, which handles ripping, media plug-in will be notified and get a copy of that message.

all the logic of handling and responding to events is handled by the event plug-in device, which registers a message interceptor of all messages where the type=Event (ie any event).  event plug-in looks in the Pluto main database in the table EventHandler to see if the user registered a handler for that type of event.  If it finds one, then it evaluates the criteria in the table Criteria to see if it's a match.  If it does, it executes the commands in the given command group.  so it's a very primitive and simple event handler that does not allow for complex calculations because the intention was a point-and-click for mainstream users.

when I talked about adding a ruby based event handler, this would just be another device that also intercepted all messages of type event, but instead of a valuating them by comparison to a database table, it would execute a snippet of Ruby code.  this would be very trivial to do because we already got the C++/ruby interaction working for our GSD, and it already hands-off incoming messages to ruby snippets.  so all we would need to do is creating another GSD that did the same thing for events instead of commands.  It would be a fairly trivial thing.

you could do the exact same thing in Perl right now with no changes to the framework.  You would not even need the C++ interaction.  If you open a socket connection to DCE router on port 3450, send a properly formed message interceptor message, then DCE router will give you all of the messages you want to intercept, such as events, and you can do whatever you want with them, including firing commands based on criteria from configuration files, databases, what ever.

so on to your specific example:

>>1) You open up so that a larger group of developers can create scripts
I understand about a developer creating an X10 alarm system, but what specifically would you need us to "open up"?  I'm not sure I understood what you meant by that, or if we have done anything closed to that would prevent a developer from doing what he wanted.

>>2) Pluto integrates the Perl codebase into its OS layer...
I'm a bit fuzzy on what you mean by the OS layer.  Pluto does not really have any hooks into the OS other than just standard socket code.  For example, I run Pluto on Windows just because I am more comfortable in the Visual Studio development environment.  All of Pluto's code runs just fine.  of course the media players (Xine/Myth) are Linux specific.  so I have a Linux media directorthat I change the ip address in the pluto.conf to points to my Windows-based core.  so when you say "integrates the Perl codebase into its OS layer", can you clarify what you mean?  to my knowledge all you would need to do is add Perl.  our dependencies are also database driven.  In your Pluto admin site if you choose a device templates, you'll see there is a pulldown for the package.  And in advanced, packages you see the package definitions including all the dependencies dependencies.  all of Pluto's packages are built automatically by an unattended build system.  So you could create a device template for a Perl device,add a package for your device in advance, packages, specify under the file listing what files you want included, and add under the dependencies section Perl.  Perl is still included in our mirror--it's just that nothing depends on it.  But if you added such a device, without changing anything, Perl would get installed on your device would run.  In fact our startup scripts don't care what language the devices written in, your Perl device would get started just like all the other devices.  So I'm not clear what we would need to do for this point.

>>3) Pluto integrates the scripts into its GUI
Our GUI (Orbiter) actually has no scripts.  In fact there is virtually no logic in the GUI for specific applications.  For example there is absolutely nothing in orbiter relating to lighting, events, security, telecom, etc..  The look and feel andfunctionality of the telecom screenis defined in the database: DesignObj tables.  we use a Windows C# program called Designer to build the screens and specify what commands are attached to the buttons.  But none of this requires any code whatsoever in the GUI Orbiter.  so I don't think any changes to orbiter would be needed.  You could create new screens in the database using Designer that did something you wanted for X10.  There's a table DeviceTemplate_DesignObj which provides the link that says what's devices use what screens.  It is completely free-form and unrestricted.  I could create a screen (ie DesignObj) for a new device template (Jandy pool control) that had buttons for maintaining a swimming pool.  without touching the code, that new screen would appear on all the media directors, PDAs, mobile phones, etc. whenever you wanted to control your swimming pool.

>>4) Pluto creates a new GUI layer for the alarm system
our designer program (ie what the developer uses to build the database records defining the gui/look/feel) does suck.  however, it is usable and not terribly complicated--the only thing is you need Windows.  since the user interfaces database driven, our sqlCVS utility will automatically synchronize.  So if you ran designer, and created a new screen, and then in Pluto admin did a Advanced, sqlCVS, checkin, and checked in the "designer" repository, your new screen would be synchronized with our main server.  you will be given a batch number by sqlCVS.  all sqlCVS commits (even infrared codes) go into a quarantine state so we can review it before it hits the release.  but if you send us an e-mail and say "please approve batch 89775", for example, our tester would go into his local machine, enter a command to merge that batch into his test machine, confirmed that it was okay and didn't break anything, and then approve it and it would be part of our next release.  so the developers are not really tied to Pluto for the GUI.

does that help?  we don't have any Perl programmers, but I know Pluto's framework very well.  So if there is a Perl programmer who wants to take this on, we could also do a phone call for brainstorming how best to do it.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 11, 2005, 04:21:27 am
Damn, that was one hell of a response, Aaron!! :-)

All good information, and I think we're in sync.   I'm still coming to grips with how Pluto's integration pieces work, but your explanations are helping tremendously.

When I was referring to the "OS Layer" I was referring to the Quick Install CD and the Debian-based system it installs for you -- basically the "end user system that the end user never sees".

It's all good.

Dan
Title: X10 device state
Post by: archived on September 11, 2005, 10:59:06 am
Hi,

Is it possible to query the state of an X10 device ie what state a CM12 is in or what levela dimmable switch is at etc? If you could then one use would be to resend a command that had failed and another would be to get the state of all X10 controllable devices in a given room or area of the house.

Cheers

Andrew

Quote from: "torindan"
I have to disagree with you...

If a motion detector is triggered, I want pluto to know this, because beside of X10 devices there are a lot of other devices which integrates with pluto for example survailance cameras.

Right now you have a posibility to be called on your mobile phone if there is a security event in your home (motion detected by survailance camera or, in near future, by X10 motion detector) so you probably won't care what kind of device detected the motion, you want to be notified. If you also want to light some X10 lights it's ok, but you probably will want the behavoir to be consistent no matter what kind of device was triggered.

Another example: the "follow me" command right now based on bluetooth devices, which detects in which room are you (actually your mobile phone). The same behavior probably can be done with motion detectors.
Follow me doesn't only work with lights, but also with media (like playing music or video) which follows you in each room.

So we should start thinking right now what we really want to do when a X10 event arrives, not just send back X10 commands and postpone solving the real thing.

This probably will take some time to implement so if you desperately need X10 reaction right here, right now, you can try to communicate with your devices via Generic_Serial_Device. Which permits you to send/receive commands to/from device by writing small chunks of Ruby code.
To find out more read http://plutohome.com/support/phpbb2/viewtopic.php?p=1243
Title: Will Pluto listen to X10 commands?
Post by: archived on September 11, 2005, 12:27:25 pm
Quote from: "aaron.b"



.... snip .....


when I talked about adding a ruby based event handler, this would just be another device that also intercepted all messages of type event, but instead of a valuating them by comparison to a database table, it would execute a snippet of Ruby code.  this would be very trivial to do because we already got the C++/ruby interaction working for our GSD, and it already hands-off incoming messages to ruby snippets.  so all we would need to do is creating another GSD that did the same thing for events instead of commands.  It would be a fairly trivial thing.

you could do the exact same thing in Perl right now with no changes to the framework.  You would not even need the C++ interaction.  If you open a socket connection to DCE router on port 3450, send a properly formed message interceptor message, then DCE router will give you all of the messages you want to intercept, such as events, and you can do whatever you want with them, including firing commands based on criteria from configuration files, databases, what ever.

.... snip .....

does that help?  we don't have any Perl programmers, but I know Pluto's framework very well.  So if there is a Perl programmer who wants to take this on, we could also do a phone call for brainstorming how best to do it.


Hi,

well I'm lousy Perl programmer, but do know internals of Misterhouse quite well, so maybe this would be a good start. I will connect from Misterhouse and then we can proceed from there (main problem would be to parse messages and establish all datas about devices, ...)...

Can you give us pointers to more info or how does "properly formed message interceptor message" looks like.... Is connection to 3450 TCP or UDP ?

Thanks in advance,

regards,

Rob.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 11, 2005, 03:14:09 pm
>>  how does "properly formed message interceptor message" looks like..

this may not be so easy at present.  the logic is entirely in DCE/Message.cpp.  It uses our own SerializeClass/SerializeClass.cpp library.  it was written for peak efficiency with C++ applications, so DCE router can process as many messages as possible, and it can run on low-power devices like PDAs.  SerializeClass works across all operating systems (Linux/Windows/Symbian/Smartphone/etc)., that may not be friendly across languages like Perl.  An integer is just past out as the 4 bytes.  ie, like int myInt=28818128;  Send((void *)&myInt,4);.  in C++ this works and is very efficient, and since a single common class is used throughout the entire program there is no risk of errors.

if Perl uses a completely different way of representing integers internally, you probably will not be able to do it the same way.  of course we could change Message to use a more portable format--since that one class is the only one used, it wouldn't be difficult.  However if we use a different format, say XML, ie Send("<device id from>28818128</device id from>"); that would make it easier for you Perl guys, however I suspect it would drastically reduce DCERouter's efficiency and the speed at which it can parse and process messages.  this is important since there is a huge volume of messages.  For example if you set your media player to report Time code every second, that message gets broadcast every second, media plug-in needs to see what orbiter's and VFD displays are currently controlling that media and bound to remote controls, and send them all messages to update the time code.  Picture a big home with media playing in 10 rooms, five people on the phone, etc., you can see why DCE router needs to be very efficient and parsing XML would slow it down.

On to DCE Messages the way they work now...  First, the basic wrappers are in plain text so it is easy to follow in the logs.  There are a few special text messages, such as RELOAD, etc., but the only one that really matters for sending messages is MESSAGE.  Basically you just send MESSAGE xxx

Where xxx is the size in bytes of the binary data that will follow.  The binary data  contains the actual message.  All messages contain a from device and a to device, type and an ID.  The most common type is 1, which means command.  In that case the ID is the command's number.  The second most common type is 2, which is the event, and the ID the events number.  Each message also has an optional number of parameters.

What the commands and events are is defined in the database--DCERouter doesn't care.  It just sends a message to the destination.  In your Pluto admin web site, if you click advanced, DCE, you can see a list of all the commands and events and the parameters they take.  Our utility DCEGen uses this database to build a pregenerated C++ program that encapsulates everything.  So for example the command “MH Move Media” is ID 241.  It expects 2 parameters: “PK_EntertainArea” is parameter ID 45, and “StreamID” is parameter ID 41.

Media_Plugin is a DCEDevice that implements that command.  So DCEGen builds a base class for media plug-in that listens for incoming messages on a socket, automatically parses them and deserializes them, and then passes them to a switch block which will include a case 241, that will then extract the parameters, and call a virtual function called: “MH_Move_Media(string sPK_EntertainArea,int iStreamID)”.

So for C++ it's really simple, the programmer has nothing to do.  It he wants to send the command he just types in DCE:: and then auto complete gives them a list of all the commands, and when he chooses the move media command, auto complete gives all the parameters, and when he calls SendCommand(), the command goes through and in media plug-in the MH_Move_Media() function gets called automatically.

We don't have a formal document showing the binary structure of the message, but if you look at the source in Message.cpp, you can see it's just a bunch of serialized values.  

Here is a sample binary file containing the move media command going from device 123 to device for 83, with the stream ID of 382 and an entertainment area of “abc”.  

http://plutohome.com/download/mh_move_media

If you do: DCE::MH_MoveMedia(...), and then call SendCommand(); the resulting binary data is what's in that file.  If you cat that to a socket the message goes through.

I am assuming we only need to implement the same message serialization in Perl.  Of course the other possibility is to do like we did in Ruby.  there is a C++ to Ruby Gateway, so Ruby does never parse actual binary data, that's all done in the same C++ code.  to the advantage to this technique is that all the logic is in one place, however I'm not certain if the same Perl to C++ interaction is available.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 13, 2005, 08:21:08 pm
Quote
you could do the exact same thing in Perl right now with no changes to the framework. You would not even need the C++ interaction. If you open a socket connection to DCE router on port 3450, send a properly formed message interceptor message, then DCE router will give you all of the messages you want to intercept, such as events, and you can do whatever you want with them, including firing commands based on criteria from configuration files, databases, what ever.


So, to restate, you're saying that we could write a perl program that could register with the DCE router (by sending a properly formatted request to TCP port 3450) to request all messages from the CM11A.  Each time the CM11A received an event (because somebody turned on a two-way X10 light switch or some event happened that triggered an X10 command on the line), the DCE router would send that data to the perl program?  Based on the event sent to us by the DCE router, we could fire an X10 module by sending an event (X10 command) back to the CM11A via the DCE router?

If so, that sounds perfect.  We could write our own program that could do whatever we want.

How would the DCE router pass these messages/events  to our "listening" program?  Is it via a TCP port?  How is that port address determined.

To this point I haven't actually loaded Pluto onto a server because I was unsure I would be able to get full functionality with my X10 system, but it now seems like it's a very real possibility.

Thanks,

Lance

[/quote]
Title: Will Pluto listen to X10 commands?
Post by: archived on September 13, 2005, 08:56:33 pm
Your device connects to DCERouter on port 3450 twice--one socket you send HELLO xxx (where xxx your device ID), and on the other you send REQUEST HANDLER xxx.  The first socket will be used for messages from the router to your program (we call it the command socket).  The second socket you will use to send messages to the router (we call it the event socket).  The message syntax is the same--the 2 sockets are used to allow simultaneously sending/receiving messages.

On the Event Socket you could send a message to DCERouter to register the interceptor (ie give me all commands going to lights, give me all messages to or from the cm11a, give me events of type 'sensor triggered')...  Whatever you want.  Then on the Command Socket you will get whatever messages you asked to intercept.  On the command socket you will also get any messages sent directly to you.  And on the event socket you can send any messages you want--such as commands to other devices, events, etc.

I guess that if we bit the bullet and made a re-useable Perl message class that handled all the low level guts, any Perl programmer could use it to do anything they wanted.  Even really advanced stuff--intercept the sunrise event, and upon receipt, check the weather station to see if it's raining and if not, open the blinds, otherwise let you sleep.  Or intercept the 'watching media' event and if it's [whatever complicated criteria] do something...

BTW, this is the kind of stuff you'll be able to do with our embedded Ruby event processor when it's done.  The advantage of the system we're doing is it's not freeform--it's database driven.  ie the structure and organization is handled for you.  You'll have a web page that organizes all your events, let's you name them and categorize them to quickly maintain individual snippets on the web form.  Each snippet will be stored in a separate record in the database.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 13, 2005, 09:45:26 pm
Quote from: "aaron.b"
....

On the Event Socket you could send a message to DCERouter to register the interceptor (ie give me all commands going to lights, give me all messages to or from the cm11a, give me events of type 'sensor triggered')...  Whatever you want.  Then on the Command Socket you will get whatever messages you asked to intercept.  On the command socket you will also get any messages sent directly to you.  And on the event socket you can send any messages you want--such as commands to other devices, events, etc.

...

Can I intercept everything from Pluto ?  How exactly does registering interceptor takes place - what are exact messages for those :
give me all commands going to lights, give me all messages to or from the cm11a, give me events of type 'sensor triggered'...

Are there docs on this ?

Can device get info on existing other devices, their type and ID (I'm asking this cause I'll try to write something for Misterhouse) - so it can create its own counter part objects ?

Thanks in advance,

Rob.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 14, 2005, 09:42:05 am
See: http://plutohome.com/support/index.php?section=document&docID=285

and http://plutohome.com/support/index.php?section=document&docID=199
and http://plutohome.com/support/index.php?section=document&docID=24
Title: Will Pluto listen to X10 commands?
Post by: archived on September 14, 2005, 10:24:46 am
>> Can device get info on existing other devices
Yes, it's automatic.  When you send a CONFIG message, the router gives you back all your device information, as well as basic information about every other device in the home.  The C++ DCE library does this automatically.  It might be tricky to do this in Perl right now because the binary data returned from the CONFIG message has a lot of c++ structures.  However, everything is contained in teh pluto_main database.  You could also query the database directly.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 15, 2005, 07:57:09 am
I just made a quick change...  Now you send/receive messages in plain text.  When you register your command handler, send "PLAINTEXT" and all your messages will come in plain text.  With the .30 release I'll include some documentation with a sample you can use with just telnet and some messages to copy/paste showing how to send/receive messages.

I should have done this from the beginning...  There was already a Message constructor to build a message from plain text, the only part missing was a method to convert the message back into text.  It took half an hour, and now the Perl/Java programmers can write a DCE Device without any problems.

I also sent Paul from xAP an email and will look into adding a xAP gateway to Pluto as well.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 15, 2005, 08:59:03 am
Quote from: "aaron.b"
I just made a quick change...  Now you send/receive messages in plain text.  When you register your command handler, send "PLAINTEXT" and all your messages will come in plain text.  With the .30 release I'll include some documentation with a sample you can use with just telnet and some messages to copy/paste showing how to send/receive messages.

I should have done this from the beginning...  There was already a Message constructor to build a message from plain text, the only part missing was a method to convert the message back into text.  It took half an hour, and now the Perl/Java programmers can write a DCE Device without any problems.

Hi,

marvelous. I think Misterhouse will now get Pluto plugin or vice versa.....
Quote from: "aaron.b"

I also sent Paul from xAP an email and will look into adding a xAP gateway to Pluto as well.

Since Misterhouse and a lot of other programs already support xAP, that would be even better way to do it....

There are also a lot of other xAP aware apps that could cooperate with Pluto...


http://wiki.xapautomation.org/tiki-index.php?page=XapApplications-List&PHPSESSID=5e4a48787e7363beffd2caaa2b52300b

xAP desktop is my favourite :
http://www.mi4.biz/modules.php?name=News&file=article&sid=45

Thanks for these efforts. xAP would be excellent addition for Pluto....

Regards,

Rob.
Title: Will Pluto listen to X10 commands?
Post by: archived on September 15, 2005, 07:23:56 pm
I uploaded a tutorial explaining how the plain text messages for perl/java works, and tested it today against our daily builds.  If anybody has comments please let me know so I can make changes before the .30 release and before people start using it:

http://plutohome.com/support/index.php?section=document&docID=286
Title: Will Pluto listen to X10 commands?
Post by: archived on September 20, 2005, 01:27:30 pm
Can somebody with bidirectional X10 device enable remote access and send PM with installation number and password.
Maybe more interaction will be needed (such as request for triggering the sensor or something similar) so please send a way to contact you in realtime (yahoo messenger, skype, phone)
Title: cm11a doesn't receive yet
Post by: archived on October 28, 2005, 02:23:58 am
It appears that the cm11a doesn't receive events from the powerline. I set up a few lights and was able to control them via pluto. My other automation system was able to see pluto's commands. When I attempt to control the light from the other automation system, pluto doesn't see anything or at least the log file doesn't report any activity. In my case my security system supports X-10 and if pluto could receive, it would be one way (though certainly not the best) for them to communicate. It would let some of your installers use X-10 as a way to tie systems together until a better solution comes out.

What is far more useful is to support the W800RF32 from http://www.wgldesigns.com/w800.html (protocol spec at http://www.wgldesigns.com/protocols/w800rf32_protocol.txt). As has already been mentioned on this thread, this lets pluto access a ton of inexpensive wireless devices.

What is necessary is that pluto be able to receive an X-10 house/unit code and be able to lookup the device based on that code. Once that lookup is available others could contribute to supporting the W800RF32.

I understand that pluto wants to know the device type so that the proper action can be maintained. This should be user selectable for any of the house/unit code devices as only the user knows what has been wired up and what house/unit code is selected. The security devices (mentioned in the protocol spec) have unique codes so you can determine what they are without the user.

A few examples that I currently do but could do more with pluto:

Wireless X-10 motion sensor turns on light when it senses motion and turns off the light when motion ceases and a timeout expires. The X-10 motion sensors can be setup to do this by themselves.

Wireless X-10 magnetic contact sensors cause a picture to be taken when it activates. With all the support in pluto, it could also send that picture somewhere.

Being able to receive X-10 within the pluto core would be very useful. I would be willing to provide access to my system or provide some W800RF32 decoding C code that I wrote if that would help.
Title: Will Pluto listen to X10 commands?
Post by: archived on October 28, 2005, 02:36:09 am
Pluto does now receive X10 commands, but the CM11 is not a transceiver. The CM11 it only a transmitter. If you were to get a module that support Bi-directional communication, then you might be able to do what your after.

Regards,
Cordel
Title: CM11A update
Post by: archived on October 28, 2005, 08:30:45 am
I modified the CM11A app to receive the X-10 commands that are on the powerline. The code was mostly there but it wasn't checking/polling the CM11A device but only looking for incoming messages when it had data to send. Now the log file shows the incoming data but it doesn't look like the state of the devices is changed. I see code that attempts to update the state but it doesn't look like it is called. Here is an entry from the log:

Quote

10      10/28/05 1:16:23.483            Got response: 5a from CM11A.
10      10/28/05 1:16:23.511            Reading 3 bytes of DATA...
10      10/28/05 1:16:23.511            Data read successfully <02 61 62 >
10      10/28/05 1:16:23.511            Probably need to send EVENT that A5 is ON
10      10/28/05 1:16:23.511            Data decoded into [A5 ON]


Who do I send the patch to?

This was only tested on Linux. As I use a function that doesn't appear to be implemented under Win32, I am not sure if this will work there or not.
Title: Will Pluto listen to X10 commands?
Post by: archived on October 28, 2005, 10:31:24 am
Please send the patch to dan.t _a_t_ plutohome.com.

I'm also working on W800 receiver and it's mostly done.

But I had a problem with some strange sensors (DS10A as i remember)which sends bad W800 commands (not compliment pairs of bytes)
The person which had the system said that that sensor doesn't have a code like A1, B5 whatever, but only a number ... like "3".

So if you have such devices or some expirience how to decode such messages, please post here or PM me.
Title: Will Pluto listen to X10 commands?
Post by: archived on October 28, 2005, 10:32:23 am
You can email the patch to dan.t at plutohome.com.  RE: "As I use a function that doesn't appear to be implemented under Win32"...  which function is that?  I don't know the cm11a code, but i think it's all just rs232 commands, so it should be completely cross-platform.

As far as getting the states to update, there are 2 issues here.  The first is that when Daniel's CM11A receives a house code, he needs to look up what device uses that house code and fire a logical event.  For example, if he gets a 'house code A8 on', he needs to look up that the device with code A8 is a motion detector, and in response send a 'sensor tripped' event.  This way cm11a motion detectors will fire the same events as other motion detectors, and the security plugin, which is responsible for all the logic in the home security system, and which intercepts all 'sensor tripped' events, will correctly implement the logic.  CM11A, like all the interface devices, has no logic in it--it just implements commands and fires events.  All the logic is in plugins which are generic and not specific to any type of interface.  That's why you can mix sensors from X10 and Lutron, and they're all treated like 1 big alarm system.

The 2nd issue is ensuring that the logic is correct and does what's expected (this is in my code in Security Plugin).  At the moment it works like this: when security plugin sees that a sensor is tripped it checks what cameras are associated with the sensor as per the page Wizard, Security, Video Links.  It snaps photos from all those cameras and archives them under a 'security event'.  It checks what the sensor is supposed to do (nothing, make announcement, security breach, etc.) as per Wizard, Security, Active Sensors.  If there's an announcement, it plays a text-to-speach message indicating the sensor is tripped.  If there's a breach, it fires the alarm and attempts to contact the homeowner as wer Wizard, Security, Cellphone notifications.

So if there's an issue with cm11a not firing the sensor tripped event, that goes to daniel.  If there's an issue with it not being handled properly, that goes to me.
Title: Will Pluto listen to X10 commands?
Post by: archived on October 28, 2005, 02:34:44 pm
This goes back to what I was talking about earlier.

Rather than tying the X10 address event directly to your motion detector events (or anything else for that matter), I would recommend a 2-release plan.

Release 1 - for X10 developers and techie folks only
Release 2 - tie the work from Release 1 into Pluto's end-user functionality

First, create events that are X10 only: Device ON, Device OFF, Device DIM, All Units On, All Units Off, Preset DIM, etc.

At the end of this release, you still don't have much in the way of end-user functionality.  But for X10 developers, they can now begin developing new and unique solutions immediately.

Then you begin the second release, which is tying the X10 event system to your already-established, device-type-specific events -- so when an A8 event fires, you have an X10 (phase 1) listener that picks it up and re-fires it as a Motion Detector Tripped event (phase 2) so that end-user functionality is maintained.

I guess what I'm saying, in short, is don't tie the CM11A directly to the rest of Pluto.  Make an intermediate layer.  Doing so opens it up to X10 developers to work with events and gives you maximum flexibility / isolation.

My $0.02.  And if I've missed the point (again), my apologies up front.

Dan
Title: Will Pluto listen to X10 commands?
Post by: archived on October 28, 2005, 03:29:46 pm
I think I understand what you're saying.  At the moment the cm11a device both listens for x10 events (housecode

So I think what you're describing is breaking this into 2 devices:

1) a CM11A which fires only 'proprietary' events that are unique to X10 (ie housecode

2) a device that does nothing but translate X10's proprietary events (housecode

This is no problem.  In the definition for the CM11A you can say in the table 'DeviceTemplate_DeviceTemplate_Related' that if there are any device:cm11's in the house, there must also be a device:X10 translator.  The device cm11a fires only proprietary x10, and the device:x10 translator registers an interceptor with the router asking for all proprietary x10 events.  Thus device:x10 will get a copy of those events and can translate them accordingly, and fire pluto events.

This does have the advantage that you can create dozens of device templates for all the x10 interfaces (ie CM11a, Powerlinc USB, WiSh, etc.) and there is 1 common device 'x10 translator' that does all the translation.

However, let's go over what this would accomplish....   This 'sharing' of 1 common translation code is a great idea since there are so many x10 interfaces.  But it could also be accomplished by creating a shared c++ class 'TranslateX10' that any x10 interface devices inherit from.  Also, although I don't know of any reason why developers would want the 'raw' 'raw' proprietary x10 events to be broadcast through dcerouter, even if they did, you don't need to create 2 devices to accomplish this:  the CM11a could simply fire *both* a proprietary x10 event and a standardized pluto event.

There is only 1 reason I can think of why you would want to separate this into 2 devices.  That's because if you wanted to create an x10 interface device using GSD (ie the simple embedded wizard) rather than C++, you wouldn't be able to share a common class 'TranslateX10'.  GSD is designed to be quite simple and fast for non-programmers, so there's no concept of oo-programming, just a 'check off the commands and events, then fill in the blanks'.  So if you created 5 different GSD device templates for 5 different types of x10 interfaces, you would need to repeat in each one the same translation logic.

However imho an even better approach is not to create 5 GSD device templates for all the various interfaces, but 1 super 'x10' device template--that is expand CM11a so that it recognizes other types of x10 interfaces.  That way for the unwitting end-user they just pick an interface of 'x10' and it works, without introducing the error that they pick the wrong one.  However, this assumes most x10 interfaces share the same functionality so that there could be only 1 device for all the different models.

What do you think?
Title: X10
Post by: archived on October 28, 2005, 09:09:38 pm
There is a lot going on with how to describe X-10 and it is easy to only focus on part of it and not others, especially when it is being considered in a larger context like the design of pluto.

X-10 has multiple media formats, powerline and wireless.

X-10 has multiple device types, motion sensors, light switches and dimmers, contact closures, relays, etc.

X-10 has limited range based on media formats (though this can be fixed it is part of the X-10 design constraints).

Right now, pluto only sends X-10 commands based on some event. It would be nice if X-10 could generate events from all its different media formats and device types. Some folks on the thread have asked for lower level access to the X-10 events, this may or may not be necessary depending on how the X-10 event is handled, either going in or out of the pluto message router.

We are close to getting the CM11A to accept the powerline X-10 data. From there it can generate a pluto event via DCE. I am not sure we need an X-10 translator device. However in the CM11A there will be some sort of mapping from X-10 to pluto message necessary. I think a translator device may be overkill in that most of X-10 is on/off/dim or safe/alarm in terms of states. More below.

There is also the issue of multiplicity and locality. For larger X-10 installations it is useful to have support for multiple CM11A or W800RF32 devices. If they could be connected to MDs, even better. Each CM11A and W800RF32 then has all house/unit codes available. So the mapping from X-10 device to pluto event is best done through its parent CM11A/W800RF32 controller running on whatever CPU.

The templates need to provide for an X-10 type device for motion sensor, lights, etc. or there needs to be a special X-10 section that provides a list of all devices. Because X-10 can have a module plugged into any appliance, it is hard for pluto to know what a user will plug in. This is why people want a lower level access but then this complicates the pluto model.

I agree there needs to be an abstraction here that is unique for X-10. Most of the X-10 systems out there focus on the device/state pair which is what I think people are interested in. For example, when device A-1 is ON turn on device B-1. Because X-10 is more then a lighting system or security system, folks want more flexibility.

Pluto already supports lighting and motion sensors. What about contact closures? If an X-10 installer wants to create a device "coffee pot" and use an X-10 module to control it, can we create a template for that type of device? If someone wants to use a palmpad to create a button called "her wakeup routine" that sends an X-10 A-1 ON, can pluto translate that into a scenerio to turn on radio, lights and the coffee pot? What about hooking up an X-10 contact closure that sends an X-10 D-5 ON when a light beam is crossed? The wireless motion sensors are basically the same as the last example.

All these examples work for receiving on/off and dim/bright states. It gets more complicated for devices that support extended codes and preset dims but lets put that aside for now.

The code that translates X-10 commands received from the wireless or powerline interfaces into DCE messages needs to know the following:

1) house/unit code
2) controller (CM11A or W800)
3) machine it is running on
4) device type (light, motion, contact closure, misc. device)
5) function (on, off, dim, bright)

So if a wireless motion trips or someone pushes a plam pad button, an X-10 ON will be received somewhere and it can be transated into a pluto device and that device's state can be updated.

I think that a seperate class could be created for the X-10 function handling for the case DCE->X-10 and X-10->DCE so that could be reused between all the different X-10 controllers.

I think people want access to the lower level X-10 so they can have better control over the actions. If users could create their own misc. devices would this alleviate the need to get the X-10 directly?
Title: Will Pluto listen to X10 commands?
Post by: archived on October 29, 2005, 11:32:07 am
Hello, I think all those issues are easily addressable:

> For larger X-10 installations it is useful to have support for multiple CM11A

That's already done.  On Wizard, Devices, Interfaces just add multiple CM11A's.  Call 1 'Living room cm11a' and the other 'Bedroom cm11a'.  Then on your wizard, devices, lighting (or climate, or security, etc), add all the devices you want, and for the 'controlled via' just choose the correct cm11a, and put the house code in there.  That's what 'controlled via' is for--it means this [light/sensors/etc.] is controlled by this [cm11a/lutron/etc.], so all commands for that [light] go to the controlled via interface.  So this one we already do.

> The templates need to provide for an X-10 type device for motion sensor, lights....

We have about 12 or so generic devices that can be controlled via cm11a: dimmable lights, on/off lights, drapes, generic relays (for coffee pot, etc.), motion detector, glass break, door sensor, window sensors, etc.  If an end-user wants to add new templates (like a 'garage door'), he can.  No coding is required.  Add a 'garage door', pick a floorplan icon for it, and it will appear on the floorplan and in scenarios and you can send it on/off.  The only time new code is required is if you want to translate incoming events from that new device template.  For example, maybe when a 'garage door' fires an x10 state changed event, you want to fire a pluto event 'garage door opened/closed'.  However that's only a couple extra lines of code--just some lines in a switch block.  Of course, we could also totally separate this from code and have a conf file, or maybe a device data for cm11a that stores this in a pre-designated format: when devicetemplate=X fires x10 event=y, fire Pluto event=z.  Then it could be done completely without touching the code.  We use this approach already for LIRC and could do the same for x10.

> What about contact closures? ... can we create a template for that type of device?

Yes, there's a generic relay.  But remember you can add 'any' device template you want.   Then add an instance of the device, make it controlled via the cm11a, and it will work.

> If someone wants to use a palmpad to create a button called "her wakeup routine" that sends an X-10 A-1 ON, can pluto translate that into a scenerio to turn on radio, lights and the coffee pot?

Yes, we don't have a gui for PalmOS.  However any device that can connect on a socket can send a message, so you could also just add an icon to palm-pilot called 'wakeup' that runs a batch file that sends a message over a socket.  In Wizard, Scenarios, choose the sub-category for this scenario: (Lighting, climate, etc.).  Usually lighting.  Add the commands you want: generic relay on A1 ON, light on B5 50%, etc.  Give the scenario a name: 'wakeup'.  Now on all Pluto gui's a 'wakeup' button appears.  If she wants to do this her PalmOS or other device that we don't have a gui for, create a script that connects to DCERouter on port 3450 and sends a message of type: 'Execute Command Group' (CommandGroup=Scenario) with the id of the new wakeup scenario.

> hooking up an X-10 contact closure that sends an X-10 D-5 ON when a light beam is crossed?

there are 2 ways: 1) add the 'x10 contact closure' as one of our built-in security sensors (glass break, motion, door, window, etc.).  Those our CM11a already knows to translate into a 'sensor tripped' event.  Go to wizard, events, respond to events, add "A sensor is tripped", choose the contact closure, and then state what actions you want to be done: 'turn the light on'.  2) add the 'x10 contact closure' as a 'generic relay' or other unknown device template that our cm11a module doesn't know how to translate.  In that case (I think) the cm11a will just fire a generic event (device on/off/state change, etc).  Daniel T will know what events he fires from unknown device template.  Then when you go to wizard, events, respond to events, choose 'advanced' and add an event handler for that particular event.

>  If users could create their own misc. devices...

I think everything the users want is already do-able, Daniel T may have some debugging for cm11a/w800, but the framework does everything already.  However, the main issue I thought was at the table was translating x10 events into meaningful events.  X10 may only fire a 'state changed' event.  But for a non-techie user to create an event handler for 'a5 goes to state 2' is too complicated.  So we want a translation mechanism that says "if the device on a5 is a coffee maker, translate that into a 'Coffee is ready' event".  Then for an end user creating an event handler it's much easier to pick "cofee is ready" -> "turn kitchen light on", then it is to pick "device A5 state = 2" -> "set device B6 = on".

So the choices for doing this are:
1) a generic C++ 'translate x10' class that has hardcoded logic: if device template = coffee maker, event = 'Coffee is ready'.  This is the most efficient and least amount of work for a non-techie end user.  But the least flexible (code must be changed for each new device template, all x10 devices must be c++).
2) a new device called an x10 translator.  All x10 interfaces fire proprietary x10 events, which this device intercepts and translates.  There is still the same issue with needing to change code, but the advantage is the x10 interface devices (cm11a, w800, etc.), can be C++ or GSD since translation occurs separately.  But it's not efficient (2 devices relaying messages through dcerouter, rather than 1).
3) Re-write cm11a so that instead of using a hard-coded translation table, it gets the translation from a device data parameter, like LIRC does.  Advantage is a user can change the translation without changing the code.  But this introduces less "standardization".  One user may create his own event 'coffee ready', and another user his own event 'coffee prepared'.  Assuming both users check the box to 'share their codes', both new events will make it into our distro (unless our auditors catch it and filter the duplicate).  Then you can end up with a mess where different people do the same things differently making support more difficult, as well as documentation.  Pluto targets the non-techie consumer market so we try to make everything point-and-click simple.

Personally I'm not fond of #2 just because it seems inefficient.  I prefer #1 because it forces a standardization.  If you as a user add a new device and want a new 'coffee ready' event, you can email our cm11a maintainer (dan.t), have him add the translation to the c++ code, and it will be in the next release.  He can even give you a package from our daily builder the next day if you don't want to wait--or you can compile it yourself.  However, if the community is set on every user being able to do his own custom message translation all the time without coding, then #3 would be best.
Title: Will Pluto listen to X10 commands?
Post by: archived on October 29, 2005, 11:49:45 pm
>That's already done. On Wizard, Devices, Interfaces just add multiple CM11A's.

Could CM11A or other usb/serial devices run off an MD or GC100?

>We have about 12 or so generic devices that can be controlled via cm11a: dimmable lights, on/off lights, drapes, generic relays (for coffee pot, etc.), motion detector, glass break, door sensor, window sensors, etc.

Maybe if we had an X-10 category that could show the available templates that can be used via CM11A (or W800), that would help those getting started with Pluto? Right now they are scattered around the different categories. Part of this is getting over how Pluto does things differently then the other X-10 based systems.

Anything that can be controlled via CM11A (or other X-10 controller) should have a house code/unit code field in its template data. Finding them amongst the (soon to be) hundreds of devices will be challenging especially if the user can create their own templates.

The majority of X-10 devices will be lights and input/output relays. If we can handle them with the existing templates (which you are saying we can)  then we are pretty far along once the X-10 state can set the template/database state.

Right now the CM11A doesn't send any events based on the reception of X-10. What class(es) are needed to iterate over the children of the CM11A looking for matching house code/unit code (or house codes for All On and All Off) and send them events to update their state?

In the case of dimming, can events be setup based on the dim value?

There are going to be more complicate devices like the RCS thermostats that will require a new template and better (smarter) mapping from X-10.

A palmpad is a wireless X-10 remote control. It is the most common user interface for X-10. Basically it lets you set a house code and then has buttons which set unit codes on/off. It is just another switch.

I recommend getting the CM11A working two-way. This lets us implement many of the functions of X-10 and map them into how pluto is currently setup. I hate to say what should be changed when I don't understand what is already there. It seems right now I can do most of what my current X-10 system can do. We probably need an X-10 tutorial.

When the W800 is ready, it will provide the wireless events and the ability to map between, powerline, wireless and the rest of the pluto events. I believe that will give us enough information and user feedback to decide what to do next, especially once you want to implement a third (USB?) X-10 interface.

These are the X-10 function codes that ultimately need handling but some devices use them differently so that will have to be taken into account.

Code: [Select]

        Function                        Binary Value    Hex Value
        All Units Off                   0000            0
        All Lights On                   0001            1
        On                              0010            2
        Off                             0011            3
        Dim                             0100            4
        Bright                          0101            5
        All Lights Off                  0110            6
        Extended Code                   0111            7
        Hail Request                    1000            8
        Hail Acknowledge                1001            9
        Pre-set Dim (1)                 1010            A
        Pre-set Dim (2)                 1011            B
        Extended Data Transfer          1100            C
        Status On                       1101            D
        Status Off                      1110            E
        Status Request                  1111            F


The status request is a way to query the current state of an X-10 device. Is there a mechanism to do this in the current framework?
Title: Will Pluto listen to X10 commands?
Post by: archived on October 30, 2005, 10:14:00 am
>Could CM11A or other usb/serial devices run off an MD or GC100?

Yes, when you add the cm11a, choose the MD instead of the Core as the controlled via.  For an interface, 'Controlled Via' is whatever pc you want to run the software at--then choose the correct com port from the pull-down.  It automatically shows all com ports on that pc.  Note that the gc100's com ports show up as though they're on the core.  you'll see com ports with the gc100's device number_port number.  FYI, some serial devices don't work well when attached to a gc100 since some aspects of serial com aren't implemented.  But I believe the cm11a works fine.

> Maybe if we had an X-10 category...

That would defeat the purpose of making all devices interchangeable and platform neutral.  Then instead of adding a 'light switch' you would have to add a 'Lutron light switch', and a 'x10 light switch', and a 'Vantage light switch', and you would introduce a lot of possible errors if the user didn't choose the right type for their interface.  The way it works is *any* device can be controlled via a cm11a.  Normally by convention all 'environment' devices (environment/lighting, climate, security, etc.) are controlled by a device within the 'interface' category.  All environment devices should have a device data "Port/Channel Number" (ie #12).  We have standardized that this is the data parameter where you put in the ID that the interface device will use to identify you.  So, if you add a 'light switch' and make it controlled via a cm11a, put in this field the house code: B5.  If it's controlled via EIB, put in the EIB code: 1/5/2.  If it's controlled via a gc100, put in the gc100's module/relay, like: 5:3.

All interface devices (cm11a,eib,gc100) will scan their children and see what 'Port/Channel Number' they have, and implement the commands 'on' and 'off', and if the device supports levels, the 'set level' command.

I know our approach is quite different than the others, but look at a real world example:

Right now a totally novice end-user with no computer skills can add a new device category: environment/household appliances.  And add a new device template: coffee maker.  In his house maybe he has X10, a few gc100's, an EIB system and a Lutron system.  Every one of those devices supports basic on/off relays.  Right now, even though no programmer ever wrote code for a 'coffee maker', the end user can pick any of those interfaces as his controlled via, put in the port/channel number, and his coffee maker will work.  He can control it with a scenario, or with a floorplan.

We just did an installation in a high-end home cinema which has motorized velvet drapes and black felt borders to frame the screen.  Each of the 4 felt borders and the drapes works by 'setting a level', just like with a light.  0% is the outermost position, 100% is the innermost position.  ie: top border at 20%, bottom border at 15%, drapes at 30% correctly frames a 16:9 movie.  Without touching a line of code, the installer just added a new device template for 'motorized screen borders', added 4 of them, put the controlled via as eib, and within 10 minutes had scenarios for '16:9 DVD movie', '35mm film', 'HDTV', etc. that correctly framed the screen.  Of course when the EIB interface device gets a 'set level' command to a 'screen border' device it doesn't know what a 'screen border' is.  However it sees that it has a device data 'port/channel number' and that it contains a valid EIB address, so it uses it.

If we created a specific category for 'x10 devices' and hardcoded that the cm11a only worked with certain devices, then you would lose that flexibility.  There would an 'x10 coffee maker' a 'gc100 coffee maker' a 'EIB coffee maker', etc.  The end-user couldn't just say 'i have a coffee maker and i want to control it with x10', he'd have to pick the correct interface and the correct corresponding coffee maker.  And if we didn't standardize that all devices which can be controlled via an interface must have a "Port/Channel Number", then you'd have to write code to specifically deal with a coffee maker device (and the thousands of others).

This is the code in cm11a.  Note the framework automatically passes any messages your device receives destined to a child device to the member function: ReceivedCommandForChild.  In other words, if you have a cm11a which has a child device #123 'coffee maker', then when someone sends an 'on' command to the coffee maker, the framework will call ReceivedCommandForChild:

The code looks like this:  Note the function ReceivedCommandForChild is automatically generated by the class builder DCEGen--the programmer only needs to implement inside the function.

void CM11A::ReceivedCommandForChild(DeviceData_Impl *pDeviceData_Impl,string &sCMD_Result,Message *pMessage)
{
   g_pPlutoLogger->Write(LV_STATUS, "Command %d received for child.", pMessage->m_dwID);

   string sChannel = pDeviceData_Impl->mapParameters_Find(DEVICEDATA_PortChannel_Number_CONST);

   g_pPlutoLogger->Write(LV_STATUS, "Child device %d has channel %s.", pMessage->m_dwPK_Device_To, sChannel.c_str());
   
   switch(pMessage->m_dwID) {
      case COMMAND_Generic_On_CONST:
 (send on)
         break;
      case COMMAND_Generic_Off_CONST:
 (send off)
         break;
      case COMMAND_Set_Level_CONST:
......
Title: x10
Post by: archived on October 30, 2005, 10:25:24 pm
I don't think I explained myself very well about having another category for X-10. I wasn't suggesting making X-10 templates different from the other devices. I was hoping to add a navagation aid to help making X-10 standout and be together as a group. Maybe add a manufacturing group for X-10 and list all the templates/devices that are supported there. Part of the issue for people who are used to X-10 is trying to figure out how to do things the way they are used to. Finding the X-10 compatible devices among the multitude of all the supported devices is a challange.

I appreciate the niceness of device abstraction. It makes things easy until you want something specific from the underlying protocol. For example X-10 supports stacking commands and the use All Lights On/Off for a given house code. Stacking works like stating mutiple addresses followed by one function as in, A1, A2, A3, A ON. This gets the devices with the first three addresses to pay attention for the function which is to turn on. This saves time on the powerline which is really slow. All Lights On/Off is a function that takes a house code. All Lights Off A will have all the devices on house code A turn off if they are a light switch type device.

These are optimizations that we can add later but understanding the design points helps us figure it out. For now we want to be able to turn on and off devices and if something else turns on or off the device, we want pluto's state to reflect that as well.

Thanks for the code example. It looks like this is the code that handles the incoming DCE message (from the CM11A perspective). So if the user or other event wants to send an X-10 command, it uses this path to do so.

What I am trying to understand is the other direction. When the CM11A sees an incoming X-10 command to turn on the device at A1, how do we determine if A1 is a child of the CM11A and to update its state to on?

In this way incoming X-10 commands can trigger other things inside pluto, including other X-10 devices. I have modified the CM11A to receive the X-10 commands. I just need to know how to pass them up to the router.
Title: x10
Post by: archived on October 31, 2005, 06:34:02 am
I figured out a few more things about C++ maps and dynamic data structures. Apparently the child devices of the CM11A dim/on/off states are maintained by the CM11A process and weren't being initialized at process startup. I was expecting something more complicated using mysql. Thanks for pointing me to the ReceivedCommandForChild method as it helped clear up some of the cobwebs. So DCE events received by CM11A for its children will update the local device state (on/off/dim) and now incoming X-10 commands will also update the same device state (but only for devices that are in the CM11A's list).

So how do we propagate the incoming X-10 status into the rest of the system so other events are triggered?

I did try playing with events to see if I could get the setting of one X-10 device to trigger another one using the events wizard but I couldn't get it to work. I tried using it via scenerios and the send command from the device page.
Title: Will Pluto listen to X10 commands?
Post by: archived on October 31, 2005, 08:32:44 am
FYI, it seems there was a bug in the .31 that the child devices data parameters weren't populated correctly.  That was fixed, and the new code snippet I gave you will be included in .32.  Also, I just talked to dan.t and he will try to wrap up integrating all cm11a issues this week so we get a 100% functional cm11a in the .32 release.

> So how do we propagate the incoming X-10 status

It seems the current cm11a doesn't do this (ie doesn't yet address incoming status changes).  However this is implemented in a lot of other devices.  To do this you need to create a separate thread that will fire the events.  The main thread is created automatically by the DCE framework, and is woken up to call the appropriate functions for handling incoming messages: ie ReceivedCommandForChild, or one of the CMD_ functions for commands sent directly to your device.  The rest of the time that thread is blocked on a select() waiting for incoming messages.  NOTE: DCE connects to the router twice, 1 socket is for incoming messages, the other for outgoing.  See http://plutohome.com/support/right.php?section=documents/documentDisplay&docID=286 for a tutorial showing how messages work.

Normally in such cases you would create something like a map<string,DeviceData_Impl *> m_mapX10HouseCodes which will map X10 house codes back to devices.  You don't need this for sending x10 commands--in such cases you already get a pointer to the device in 'ReceivedCommandForChild' and that has the x10 house code.  But for the reverse, when you get a state change from x10 you will want a fast way to find out what device corresponds to a house code without having to iterate through all your child devices each time looking for it.  So in the GetConfig() function, which is called automatically when the device starts up and is where you should put initialization functions, you would put an iterator that goes through all child devices, gets the house code, and stores this in that map for a reverse lookup.

So you need another thread that, depending on how the cm11a works, will either poll it for incoming events, or will block waiting for incoming data on a serial port/socket, etc.  When you get incoming data and have an event you want to fire, lookup the device with that house code as explained above, and send an event message *From* that device.  You can create a message and send it to the router:

Message *pMessage_Event = new Message(PK_Device_X10,DEVICEID_EVENTMANAGER,PRIORITY_NORMAL,MESSAGETYPE_EVENT,EVENT_New_PNP_Device_Detected_CONST,
1,EVENTPARAMETER_PK_Device_CONST,StringUtils::itos(PK_Device).c_str());
QueueMessageToRouter(pMessage_Event);

The above sends a message of type event, with the event id "New PNP device detected", and 1 parameter "PK_Device".  Note that for a message of type event, the id is the primary key in the pluto_main table Event, and for command the table Command.  If it's an event, the parameters are from table EventParameter, if it's a command, from table CommandParameter.  The sql2cpp utility automatically creates header files that have #define's with all the constants.  So whenever you see a [TABLE_NAME]_[Description]_CONST, like EVENTPARAMETER_PK_Device_CONST, that is defined the file: #include "pluto_main/Define_EventParameter.h"

Also, DCE automatically creates helper functions to automatically form commands and events.  If you have a compiler with auto-complete (I use VisualStudio.net), type DCE:: and then it will give you a list of all the commands pluto knows, and auto-complete will automatically give you a constructor that takes all the command parameters, telling you the names and types.  Use 'SendCommand' to send a command created this way, like this:

DCE::CMD_Set_Text CMD_Set_Text(m_dwPK_Device,pMessage->m_dwPK_Device_From,"",pLastApplication->m_sName,TEXT_STATUS_CONST);
SendCommand(CMD_Set_Text);

DCEGen also automatically creates helper functions to send events.  In the device template for your device add whatever events your device will fire.  Then when you re-run DCEGen, it will add member functions to your base classe to automatically fire events, like so:

//<-dceag-h-b->
   /*
            AUTO-GENERATED SECTION
            Do not change the declarations
   */
....
         *****DATA***** accessors inherited from base class
   string DATA_Get_Path();
   int DATA_Get_PK_Users();

....

         *****EVENT***** accessors inherited from base class
   void EVENT_Touch_or_click(int iX_Position,int iY_Position);
...

So if you want to fire a sensor triggered event, you can either create the message manually (ie new Message( ...  EVENT_Sensor_Triggered_CONST )...) and send it with QueueMessageToRouter, or in the device template page in the pluto admin site add the 'sensor triggered' event, and then call the helper function to automatically create the event message and send it:
EVENT_Sensor_Triggered();  Using the pre-built event functions sends the events from yourself (ie cm11a) so for devices like this where you send the events from another device (ie your child sensor) you will send the message using QueueMessageToRouter so you can specify the from device.

With that being done, your device will send events.  There are 2 ways these events can be processed.  Firstly, another device may intercept them.  Security_Plugin is responsible for all the logic of implementing a home security system.  Note this:
bool Security_Plugin::Register()
....
    RegisterMsgInterceptor((MessageInterceptorFn)(&Security_Plugin::SensorTrippedEvent) ,0,0,0,0,MESSAGETYPE_EVENT,EVENT_Sensor_Tripped_CONST);

That means any time anybody sends a sensor tripped event, the member function SensorTrippedEvent() event will be called and passed a copy of the message.  Security_Plugin has all the logic of determining whether the sensor that fired the event is part of the alarm system, whether the sensor is active/bypassed, and when it's time to sound the alarm.  That plain text dce link above also includes an example of registering a message interceptor by hand using a socket.

The second way of responding to events is to create an event handler in pluto admin in wizard, events, respond to events.  Here is how an end-user says 'when x event comes in, do y'.  Pick 'Sensor is tripped' from the pull-down, choose the sensor device, and pick the commands.  Then whenever that sensor is tripped, those commands will get executed.

You could also easily add your own events: In the device template choose 'add new event' and create an event 'Coffee Ready'.  Then in your cm11a, wherever is the code that handles incoming messages, you would lookup the device that fired the event in m_mapX10HouseCodes and then check the device template.  If it's your new 'Coffee Ready' device, send the 'Coffee Ready' event instead of the general purpose 'Sensor Tripped'.  Then the user can go in pluto admin to 'respond to events' and pick 'coffee ready' and say what they want to happen in such a case.

Since the device templates are shared across all devices, this is why it may be a good idea to put that 'translation logic' in a separate c++ class that all interfaces devices share.  This class could have a 'TranslateIncomingEvent' function that does a:

if( devicetemplate==coffeemaker )
  event==coffee ready

And then all interface devices, cm11a, Lutron, gc100, etc., could call that common function and you wouldn't need to build that logic into each one.  I will talk to daniel t about doing that so one person one time adds a new 'coffe maker' device and an entry in the translation class, and then every automation interface will know what event to fire when a device 'coffee maker' changes state.
Title: x10
Post by: archived on October 31, 2005, 06:31:30 pm
I left a copy of my recent changes (via svn diff) at the url I sent to dan.t. Hopefully you got them and they make sense. My latest changes parse all the X-10 protocol and prepare for sending the EXTENDED function.

The CM11A already has a thread that dequeues the incoming DCE message for the child device and sends it to the CM11A. I added code that checked for incoming data from the serial port and process it. The serial port isReadEmpty method was the one I was referring to as not having win32 support.

Currently lsof shows CM11A having three sockets to the DCERouter. They all must be created by the framework as I don't see any explicit socket opens anywhere.

Caching X-10 house/unit codes to device names makes sense. Does the CM11A get a notification message when a new child for it is created or removed?

Should we send an Event_On or Event_Off instead?

Most devices that are connected via the X-10 protocol only have on/off or off/dimmed with values from 0-100. Some of the smarter light switches have preset values or scenes. I am not sure why you would want another devicetemplate for a device that only supports on/off. Wouldn't you only want a new device template to hold local device data that is unique to that device? I can see that for the RCS X-10 thermostats where saving different temperature values in the template would translate into different X-10 commands being sent/received.

For the vast majority of X-10 transactions, 0-100 will be enough. I probably need to reread your post a few more times and play with sending some messages. What other wrappers are good examples to look at in this regard?
Title: Will Pluto listen to X10 commands?
Post by: archived on October 31, 2005, 07:56:16 pm
> Currently lsof shows CM11A having three sockets to the DCERouter.

Correct, the framework does that.  It actually creates 2 outgoing sockets (you can have as many outgoing sockets as you want, and only 1 incoming).  The 2nd outgoing socket has used for other special messages.

> Does the CM11A get a notification message when a new child for it is created

No, we've had a lot of debate about this...  You get all your devices when you startup, and dcerouter also loads them at startup.  If the user adds/removes devices in pluto admin nobody is notified of this.  It is up to the user to do a 'quick reload router', which causes the router to reload (basically a clean restart), and all devices in the whole house do so also and they all get their list of children clean.  We thought about having an 'on the fly' notification, but since there are hundreds of devices written by different people, if the framework started deleting pointers to devices previously created, and the author of the module wasn't careful with his mutex's, it could cause the devices to crash.  So for simplicity, you can assume the cm11a's list of child devices is fixed and if the user wants to change them, the cm11a will be stopped and restarted by the framework.

> Should we send an Event_On or Event_Off instead?

There is a generic on/off event.  However the cm11a should do some logical translation.  For example, sensors should fire 'sensor tripped' and not on/off, because that's the event security plugin looks for.

> I am not sure why you would want another devicetemplate for a device that only supports on/off.

It's not required.  We have a device template 'generic i/o' that's a catch all.  (going back to my coffee maker example) If you add a 'coffee maker' you don't need to add a new device template.  You could use 'generic i/o' or even 'light switch' for that matter.  The reason for creating one is just to make it easier for the user.  A 'coffee maker' device template can have a default floorplan icon of a 'coffee maker', and it's easier for the user to keep track of what's what that way.  Plus it allows other interface devices that maybe do something more special to add more functionality.  While x10 may only support on/off, maybe Lutron has a specific command for turning the coffee maker on that takes as a parameter the user who turned it on so it can use his brew settings.  By having a specific device template 'coffee maker' instead of everybody using a 'generic i/o', it allows for future expansion.

> For the vast majority of X-10 transactions, 0-100

The Set level command is defined as taking a parameter between 0-100.  So if the user wants the light at 50%, you will always get a set level of 50.  Some devices use 0-255.  So that interface device is expected to multiply/divide by 2.55.  This ensures that all interfaces across the board are compatible and a 'set level 50' will do the same thing on all lights.

> What other wrappers are good examples to look at in this regard?

I know we use the EIB for automation a lot.  I didn't write it though.  I did write Tira and IRTrans which aren't automation per se, but in both cases the respond to Pluto commands and in turn send commands to the devices, and in both cases they wait for incoming events and in turn fire pluto events and commands.