INSTEON Virtual Devices

[upstatemike]

One thing I haven't been able to figure out from reading the "quick start" manuals is how you do virtual devices with INSTEON. I have some keypads that have buttons set to X-10 addresses that are not used by any device. My controller watches for these "virtual device" X-10 codes from the keypads and then triggers some action that has nothing to do with X-10 (turn on the TV, speak a status report, etc.)

Since there are no predefined addresses with INSTEON, I don't see how you would create a virtual device to link an INSTEON keypad button to. How do you watch for keypad presses that are not linked to actual switches or modules?

 

[AccessX10]

Since there are no predefined addresses with INSTEON, I don't see how you would create a virtual device to link an INSTEON keypad button to.

upstatemike,

Actually, all INSTEON devices have a predefined address. It's a six digit alphanumeric on the back or front of the device.

It will look like: 00.AB.5F (or similar)

 

[upstatemike]

So I guess you need to write down that number when you install the switch and have your controller watch for something like 00.AB.5F ON ?

Any way to find out the address after the switch is already installed?

Can I make up a fake address and somehow link an INSTEON keypad button to it?

 

[AccessX10]

So I guess you need to write down that number when you install the switch and have your controller watch for something like 00.AB.5F ON ?

Any way to find out the address after the switch is already installed?

Can I make up a fake address and somehow link an INSTEON keypad button to it?

Yeah, it's a good idea to write them down. Smarthome was intelligent enough to put the SwitchLinc addresses on the front side, so you just have to remove the wall plate to see them.

Are you developing your own software for INSTEON?

Software such as mControl requires that you enter the address when setting up the devices. It’s my understanding that if you are a developer, you could discover the address by manually “linking†to the PowerLinc V2 controller. So you would SET the PLV2 and then tap a switch to obtain its address. INSTEON does this for security purposes.

I’m not sure if the INSTEON KeypadLinc’s will handle this. Although they are supposed to ship today, so we should know more soon.

 

[smee]

Are you developing your own software for INSTEON?

Software such as mControl requires that you enter the address when setting up the devices. It’s my understanding that if you are a developer, you could discover the address by manually “linking†to the PowerLinc V2 controller. So you would SET the PLV2 and then tap a switch to obtain its address. INSTEON does this for security purposes.

I’m not sure if the INSTEON KeypadLinc’s will handle this. Although they are supposed to ship today, so we should know more soon.

I think that in order for your PC-based software to recognize an Insteon signal (such as something that comes from a keypad), you would need to link the PowerLinc and the device (using the method you described). As far as I know, the PowerLinc will pass on incoming signal data for any signal it sees, but it will mask out the first 2 (out of 3) address bytes (they are sent as FF) when it sends the info to the PC. If you haven't linked the devices, the PC won't be able to do anything (or at the very least you will be depending on only the lowest-order byte for your addresses).

I believe this information can also be sent to the PowerLinc from the PC (if your software allows you to type in the address and then sends it itself).

It may be possible to change this behavior by reprogramming the PowerLinc using their salad language.

 

[upstatemike]

Are you developing your own software for INSTEON?

No, I'm not developing anything. I'm just working out the logistics of migrating to INSTEON someday. Until JDS gets the Stargate support in place I am just using them in X-10 mode and having fun with the paddle/lightbar combinations. Let's see, how about a black paddle with a Yellow level bar and Blue standby LED for the kitchen...

 

[AccessX10]

Let's see, how about a black paddle with a Yellow level bar and Blue standby LED for the kitchen...

Hahaha... I did the same thing when mine first arrived. I actually use different light pipes depending on the rooms use. For example, the whites work great as nightlights in the bathroom while the blues work best in the bedrooms due to there ability to mask the LED’s light better. Black paddles with the red light pipes look great in the theater.

Just wait for the KeypadLinc options... it gets better.

 

[jeffx]

Just skimmed through the KepadLinc V2 User Guide. Sounds like "scenes" are now "groups" and per the manual,

When creating groups with more than two buttons, we recommended you use the soon to be released Smarthome Manager V2 software program...

 

[rocco]

I had confused the two originally, thinking "groups" were analogous to X10 scenes. but, "groups" and "scenes" are two different things in Insteon. Insteon "groups" replaces the X10 method of sending multiple addresses followed by a single command, except that the groups need to be predefined in Insteon devices. Insteon "scenes" are very similar to scenes in X10.

 

[jeffx]

I couldn't find where the Insteon switches could do "insteon" scenes, only x-10 scenes. Did I miss something?

 

[PeterW]

I’m not sure if the INSTEON KeypadLinc’s will handle this. Although they are supposed to ship today, so we should know more soon.

I think that in order for your PC-based software to recognize an Insteon signal (such as something that comes from a keypad), you would need to link the PowerLinc and the device (using the method you described). As far as I know, the PowerLinc will pass on incoming signal data for any signal it sees, but it will mask out the first 2 (out of 3) address bytes (they are sent as FF) when it sends the info to the PC. If you haven't linked the devices, the PC won't be able to do anything (or at the very least you will be depending on only the lowest-order byte for your addresses).

It may be possible to change this behavior by reprogramming the PowerLinc using their salad language.

Yes, you must link the device and the PLCv2. But you have to link it in both directions. The switches will only send events to devices that they consider to be 'slaves'.

So, you hold set on the PLCv2 and then set on a switchlincV2. This sets up a PLCv2(master) link to Switchlinc(slave). This stops the masking so you can see information about the switchlincv2. But the switchlinc doesn't know that it has to send messages to the PLCv2 yet.

So, you then hold the set button in the switchlincv2, and then the set button on the PLCv2. THat creates a link from Switchlincv2 (master) -> PLCv2 (slave). When you press the on/off buttons, the switchlincv2 will now attempt to "control" the PLCv2 by sending it on/off/etc commands. I seem to recall reading something about how this doesn't quite work if you do it manually because the switchlincv2 is confused by the PLCv2 only having the 'master' capabilities bit set and not indicating that it can be a slave.

The far easier solution is to type in the ID addresses into your controller software and let it set up the link configuration in both directions without you having to spend 30 minutes of your life holding down 'set' buttons in 10 second increments. It doesn't require SALad language, just a series of upload and download commands to the PLCv2 for its internal database, and some remote upload/downloads to the target switches over Insteon for their side of the database.

Now.. Keypadlincv2's are different. The masking is applied in the Powerlincv2 interface only. The keypadlincv2 can see ALL of the traffic. The traffic on the wire is 'in the clear' and the only thing in the Insteon network that can't see it in the clear is the controller software on the far side of a PLCv2.

Re groups and scenes.. Linking uses groups in a way a bit like X10 scenes. When you link two switches together, it actually creates a sort-of single-switch scene without you really being aware of it. Creating a real scene just means you have to link several slaves to the same master. They all join the same 'group' of the master (ie: scene).

-Peter

 

[rocco]

Re groups and scenes.. Linking uses groups in a way a bit like X10 scenes. When you link two switches together, it actually creates a sort-of single-switch scene without you really being aware of it. Creating a real scene just means you have to link several slaves to the same master. They all join the same 'group' of the master (ie: scene).

Peter, That isn't all there is to Insteon scenes, is it? I brought up the fact (on the HomeSeer board) that groups can only perform the same command at each member (all group members turn off, or all members dim 50%) whereas scenes and UPB links can have some members turn off, while some members dim and other members turn on full. It was pointed out that Insteon "groups" have this limitation, but that Insteon "scenes" do not. Unfortunately, only groups are documented in the white paper. But I was assured that the user had scenes, not groups, working in his environment.

Here is the discussion on the HomeSeer board:
http://board.homeseer.com/showthread.php?p=661966#post661966

 

[PeterW]

rocco: Yes, thats all there is.

Suppose the master is 00.11.22 and the button in question is group 6 (button F).

Suppose, slave #1 is 00.22.11 and slave #2 is 00.22.22. When activating the group/scene, we want slave #1 to go to 50% at a 5 second fade, and slave #2 to go to 30% at 60 second fade.

This is what happens:
1: program #1 to 50% on level and 5 second fade using the 'set' button. Test the on/off paddle to make sure it is right.

2: Put button F into link mode (as master).

3: Put #1 into link mode. It broadcasts 'set button pressed'.

4: The keypadlincV2 sends to #1: "please join my group 6 on my id 00.11.22".

5: #1 copies 00.11.22, group 6 and the CURRENT **local** on level and fade rate into its database and confirms to the keypadlincV2. All linking activity stops. Note that the keypadlincV2 never mentions the ON level. All the levels come from the target/slave switch.

6: #1 now restores the OLD on level and fade rate. They are not permanent unless you wait for 4 minutes. The assumption is that if you change it and then link, then you want to set the values specific for that link mode.

7: Now program #2 to 30% on level and 60 second fade, just like we did with #1

8: Put button F into link mode again (as master)

9: put #2 in link mode. It broadcass "set button pressed".

10: keypadlincv2 says to #2: "please join my group 6 on my id 00.11.22"

11: #2 copies its current on level and fade rate into the record for '00.11.22 group 6'. Linking is over.

12: #2 restores old on level and fade rate.


Then what happens when you press the 'F' button to turn it on:

1: keypadlincV2 broadcasts: "00.11.22 group 6 ON" (the on "level" is a NOP).

2: the devices look at their database and see an entry for 00.11.22 group 6.

3: #1 starts going to 50% at 5 second fade

4: #2 starts going to 30% at 60 second fade

5: keypadlinkV2 now directly commands #1 with a 'group cleanup' message. "00.11.22 cleanup ON group 6"

6: #1 acks the message, and it was already in progress. If it missed the broadcast, it would now initate the fade if needed.

7: keypadlincv2 now directly commands #2 with the same group cleanup message.

8: #2 acks and checks that it is in progress too.


Now, if #1 was at 100% already when it receives the "00.11.22 group 6 on" command, it will reduce the level to 50% as its database says to do.

However, it does not seem to be possible to set the 'on level' to 0% for the scene. I could make it work at an on level of 3%, but not 0%. (It may be possible for HA software to edit the databases to set an 'on' level of 0%, but I haven't tried this yet.)

Anyway, the flip side command is 'group 6 off' in which ALL devices turn off.

This is quite different to UPB. In UPB, when you set up a scene or link manually, you go into setup mode, adjust the levels to what you want, then they collectively take a 'snapshot' of the selected devices when creating the link with the controller. Regardless of whether the devices are on, off, whatever. UPStart allows even finer grain control by allowing you to specify the fade rates etc.

In UPB, the target devices store the on/fade rates in the target devices too. Except they're not limited to an on/fade level. They can be off, blinking, whatever. Links can activate LEDs too.

UPB doesn't have a concept of group cleanup though. It simply assumes that all the devices heard the broadcast.... Generally this is a safe assumption because UPB devices don't absorb their own signals like X10 and Insteon devices do.

Anyway, that is what Insteon's "scenes" (aka: multilink) work. Multilink mode is just a special way of putting the controller into a permanent master linking mode so it doesn't exit after each new device is introduced. It doesn't change the way it works otherwise. Multilink mode is just there to save you from running to/from the keypad controller for each device. ie: at the original step #2, we could have put it in multilink mode (go into link mode, then hold 'set' for 3 seconds), and then skipped step #8.

Anyway, sorry about the painful level of detail.

 

[rocco]

Anyway, sorry about the painful level of detail.

Peter, much thanks for the pain; It was worth it. I now understand.

The white paper did not make this clear, and I interpreted ON to be on for every group member, OFF to be off, and DIM 75% to be dim 75% for each member. It's now clear that only ON and OFF are useful, and the dim level for each ON is stored in each device, on a per group basis.

In a way, a "Group" is similar to a UPB "Link", with the Insteon "ON" being analogous to the UPB "ACTIVATE", and OFF to DEACTIVATE. How they are defined is certainly very different.