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

>> Can device get info on existing other devicesYes, 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.

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.

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...

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:

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)

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 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.

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.

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:

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.

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.

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.

I think I understand what you're saying. At the moment the cm11a device both listens for x10 events (housecode

ON, etc), and translates that into one of Pluto's standard events that the plugins know how to handle (sensor tripped, light at 50%, motion detected, etc).

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

on).

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

on) into something meaningful to Pluto (sensor tripped).

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.

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:

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?

> 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.

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.