So I was thinking, what if...?

[joeslat]

What if you could have the ACRF processor read the incoming RF signal of a PalmPad, look up whether you want that X10 to pass to HS as an X10 command or have that surpressed, so that you could instead assign that RF command to launch an event. ?Then you could use palmpads to fire events without wasting an X10 house/unit code. Should work. Right?

Joe

[Rupp]

Sure but are you running out of X10 codes?

[Oman]

You can do this now. You can set the plug-in so that X10 is not "emulated". This means that you can have an RF house code (say 'D') transmit from the palmpad but not control 'D' X10 devices. See the doc file.

Jon

Sure but are you running out of X10 codes?

[joeslat]

Rupp, yes, I'm close to running out of X10 codes. 2 thermostats, 20+ motion detectors (with the elusive 2nd X10 code taken by the day/night thing, although I have sort of solved that), and lots of other stuff.

Thanks,

Joe

[joeslat]

Jon, I don't think it will do what I'm suggesting. Let's say C1 is a light switch in my bathroom, and I have a palmpad set to HC C and I want to use it out at the pool to turn up and down the temperature, etc. (which are not X10 devices). Let's say C1 On fires an event that raises the temp by 1 degree and C1 Off fires an event that lowers the temp by 1 degree.

If I surpress X10, I presume the palmpad will do what I want it to do, trigger those events but not resending the X10 so it doesn't alter my bathroom light.

However, every time I turn the light on or off in my bathroom, which is a 2-way switch, it will also fire those temp up/down events.

So, maybe what I'm proposing is that it can be used to shadow events as well, then I would have those temp up/down events by trigger=manual and the ACRF activates the event directly. That way, the bathroom switch would have no impact.

Joe

[rirvine]

Joe,

Use the "shadow" device functionality.
With this, you can map an RF code to a HomeSeer device.
So create a homeseer virtual device, shadow C1 to that device, then create events which send your "temp up by 1, down by one" based on value changes for this new virtual device. Since you are triggering on this virtual device and not the X10 code, you can have your two way switch send X10 codes and it won't trigger the temp changes.
This is all theory but it should work.

Ross.

[joeslat]

Thanks, Ross, that's right. What I left out was that I'd like "infinite" capability, and shadowing has limited use.

I may not have the best design, but I've done my X10 install based on priority (lights we use a lot) versus location. As a result, the housecodes do not represent a logical location (like a room or floor). There are not enough unit codes in one housecode to do a whole floore, and there are not enough housecodes for me to waste one on every room, not to mention there are closets and things...

So, if I could have 16 palmpads, all set to different housecodes, all surpressing X10 retransmission, and I had 16 rooms, I could have a different event for every HC/UC on/off commands, and that would allow me to make a PalmPad do anything I want. There simply aren't enough lines available in shadowing to do this, and this would open up huge possibilities.

The issue is more than surpressing X10 codes - it is releasing the power of having a potential of over 1,000 commands (16 hc x 16 dc x 4 commands (on/off/dim/bright) that can be used as event triggers in homeseer, via palmpad and ACRF.

The ACRF can identify discrete RF codes from DS10's, so why can't it identify discrete RF codes from palmpads? The answer is of course it can, it has just been taught to consider these X10 commands and do specific things with them. But if I thought of this in terms of a DS10, I could set up a device called "PalmPad C1" and link the RF command directly to that device, then have events trigger on changes in that device rather than having to use X10 or shadowing. Just imagine the DS10 utility of ACRF and think about the PalmPad as an RF transmitter of many discrete codes and forget that those codes correspond to X10 commands.

Joe

[bdickhaus]

If I understand what you want to do, I am doing this today (with motion sensors, but it is the same idea). What you want to do is use the "unit offset" feature in the plug-in. This puts the device codes up into the "virtual" space.

For example, set a palmpad to unit C, set the unit offset to 16. When you press 1 on the palmpad, HS sees it as C17. You can also remap house codes. So I have motion sensors on house code D on the RF side, I remap them to B with an offset of 16. So D1 on the RF side becomes B17 in HS. I could (although I don't for sanity's sake) have an X10 device as D1 and it would work independently of the D1 on the RF side of things (which is B17 as far as HS is concerned).

Bill

[joeslat]

This is great, and close enough to what I want to work. Thanks for putting up with me.

What I was hoping to avoid is setting up a device, albeit NOT X10, by putting the "triggerevent" concept into the ACRF, rather than doing device actions which then trigger events. To me, that would save a bunch of steps and unnecessary devices. I already have a device for "pool pump" - now I'll need another one called "pool pump palmpad control" or something like that. And if I have 5 palmpads that all work from different rooms but I want each of them to control the pool pump, I have to set up basically the same device, as well as two events for each (on and off), so now we're talking 5 extraneous devices and 10 extraneous events. I understand I'm introducing a whole new concept here, just seems to me we'd get infinite flexibility with PalmPads if we were allowed to redefine the RF codes normally related to X10 commands as being "universal" that we could do anything with (like DS10a's). The hardest thing is to "forget" that those codes actually mean something in the X10 protocol.

Joe

[Oman]

The problem is that HomeSeer is setup around devices. You connect events and triggers to devices, and you control devices. With the old version of HomeSeer you could just reference a device even if it did not exist. For instance you could have have the ACRF plug-in control z1 and set event triggers for z1 ON even if z1 did not exist. This has become harder or impossible in HS 2.

Jon

This is great, and close enough to what I want to work. Thanks for putting up with me.

What I was hoping to avoid is setting up a device, albeit NOT X10, by putting the "triggerevent" concept into the ACRF, rather than doing device actions which then trigger events. To me, that would save a bunch of steps and unnecessary devices. I already have a device for "pool pump" - now I'll need another one called "pool pump palmpad control" or something like that. And if I have 5 palmpads that all work from different rooms but I want each of them to control the pool pump, I have to set up basically the same device, as well as two events for each (on and off), so now we're talking 5 extraneous devices and 10 extraneous events. I understand I'm introducing a whole new concept here, just seems to me we'd get infinite flexibility with PalmPads if we were allowed to redefine the RF codes normally related to X10 commands as being "universal" that we could do anything with (like DS10a's). The hardest thing is to "forget" that those codes actually mean something in the X10 protocol.

Joe