Author Topic: Will Pluto listen to X10 commands?  (Read 29003 times)

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #15 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

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #16 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

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #17 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.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #18 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

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #19 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?

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #20 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

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #21 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.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #22 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

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
X10 device state
« Reply #23 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

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #24 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.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #25 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.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #26 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]

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #27 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.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Will Pluto listen to X10 commands?
« Reply #28 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.