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.
