Crazy product request: Phantom devices.

[Illusion]

I think this may sound crazy, but I have run into a situation several times with the ISY.

 

Sometimes I wish I had another of some device just so I could use it to take the programming of an existing device before switch out.

 

As an example:

 

I have 2 SyncroLincs. One we will call Amp sense and one we will call DVD sense. I notice an anomaly in the DVD syncorlinc. I suspect it gets a little buggy because of the low power settings of the DVD player. I want to switch the purpose of these two modules for testing reasons. I have lots and lots of programs that reference these. If I use find/replace, that works great for switching one, but now I cannot switch the other using find/replace.

 

I was able to use an unused IOLinc sensor as a temporary place holder and make it work in this case but it got me thinking. I have experienced this conundrum several times in my Insteon travels. It is especially frustrating when a device is part of lots of scenes.

 

Could the ISY create a phantom device that mimics any existing Insteon device? Say create phantom device, select device type from the drop down menu, and the ISY creates some fictitious address and creates links, or just remembers what they should be like when it stores device writes. Then we could use this phantom device to take the programming of another switch, and then replace a third switch and pull the info from this phantom device.

[apostolakisl]

I agree with you.

 

I had a situation where I wanted to swap two switches. Fortunately I had a couple extra unused switches to dump all the settings into as "place holders".

 

It would be nice if you could keep all the settings saved but not assigned to any switch.

[Michel Kohanim]

Illusion,

 

I must say: very interesting and something we had never thought about. We have to do more investigation but, at the moment, I really do not see it happening any time soon.

 

Thanks so very much for your feedback.

 

With kind regards,

Michel

[Illusion]

Illusion,

 

We have to do more investigation but, at the moment, I really do not see it happening any time soon.

 

Thanks so very much for your feedback.

 

With kind regards,

Michel

 

As I expected, but I thought I would put it out there. Maybe someday in the distant future if it is even technically feasible. I did not expect quick positive results, but I figured if I never say anything then for sure it will not happen.

[Michel Kohanim]

Hi Illusion,

 

Duly noted!

 

With kind regards,

Michel

[Nuttycomputer]

Hey I came across this and wanted to also recommend this feature however not for the use specified. A Phantom or Dummy device would be extremely useful for those of us that haven't quite outfitted our entire device or want to run programs based on scenes.

 

For example right now I have a series of programs I would like to run when home changes from ownerhome/owneraway. The default way to do this seems to be linking a button on a keypad specifically to cycle this mode, or tying it into the alarm system state. Currently I have neither but would love if I could simply trigger it via a dummy switch accessible via the iPhone. This will also help prevent any young kids inadvertently switching the system as the idea is only the adults have iPhones.

[Michel Kohanim]

Hello Nuttycomputer,

 

You can already do this by running a program (away/home) from either the AJAX interface or your mobile device.

 

With kind regards,

Michel

[Nuttycomputer]

Hello Nuttycomputer,

 

You can already do this by running a program (away/home) from either the AJAX interface or your mobile device.

 

With kind regards,

Michel

 

Michel, thanks for quick reply. Support for your product has been amazing which is why I'm glad I chose it even when frustrated. Did realize you could run programs from mobilinc now that I have purchased full version.

[Michel Kohanim]

Hello Nuttycomputer,

 

Thanks so very much for your vote of confidence. It means a lot to us all at UDI!

 

With kind regards,

Michel

[Nuttycomputer]

Hello Nuttycomputer,

 

You can already do this by running a program (away/home) from either the AJAX interface or your mobile device.

 

With kind regards,

Michel

 

Hey Michel, while I have been running programs with successs it's complex to train users they need to choose Run (then) from the options available. I believe a phantom or virtual device would provide the simple end user functionality and could serve for others as a nice virtual bridge between scenes and programs.

 

Should eventually be getting a few more KPLs that I could link some of these programs to as others use in the forum

[Michel Kohanim]

Hello Nuttycomputer,

 

Yes, agreed ... I will have to talk to Nick (ISY/AJAX guru) to see if we can have favorites. The question is what does the button do? Does it Run Then/Else/If?

 

With kind regards,

Michel

[Nuttycomputer]

Hello Nuttycomputer,

 

Yes, agreed ... I will have to talk to Nick (ISY/AJAX guru) to see if we can have favorites. The question is what does the button do? Does it Run Then/Else/If?

 

With kind regards,

Michel

 

I don't think the button needs to specify. If it reported the same stats to the ISY as any other device: On, FastOn, Off, FastOff then whatever program you are trying to control could utilize the status of the device or control button pressed in its IF Statement

 

In essence I think what we would be looking for is a simulated or virtual Insteon Device. Obviously virtual sensors would be useless so I think one would only need to add Virtual KPL and Switchlinc style devices. That way it could be added as a controller to any scene, used in programs, or a combination of both.

 

The other benefit I think this has is it would be 3rd party friendly. No other device interface really needs to know it is virtual except the ISY which would need to process and respond to insteon signals destined for the virtual device.

[Michel Kohanim]

Hello Nuttycomputer,

 

I guess I didn't understand your suggestions correctly. What I was suggesting was that instead of a Virtual device, you could have shortcuts to programs in the favorites. The outcome is the same; the implementation is different.

 

The reason I am suggesting the above is expediency: supporting virtual nodes is not trivial and will require major regression testing as it would impact all parts of the framework (both on ISY as well as UIs). Whereas simply adding a short cut to programs is UI only development and much less intrusive (and perhaps even trivial).

 

With kind regards,

Michel

[Nuttycomputer]

Hello Nuttycomputer,

 

I guess I didn't understand your suggestions correctly. What I was suggesting was that instead of a Virtual device, you could have shortcuts to programs in the favorites. The outcome is the same; the implementation is different.

 

The reason I am suggesting the above is expediency: supporting virtual nodes is not trivial and will require major regression testing as it would impact all parts of the framework (both on ISY as well as UIs). Whereas simply adding a short cut to programs is UI only development and much less intrusive (and perhaps even trivial).

 

With kind regards,

Michel

 

Hey Michel the outcome is the same in this case but a virtual node would add much more functionality. Primarily what I'm struggling to do is bridge the gap that the Insteon Architecture has between the real and the virtual. How Scenes, Controllers, and Responders function works very well when you are physically pressing buttons in the house. Seamlessly in fact. The problem is when you bring that into the virtual using the ISY all of a sudden you have access to turn on responders directly, turn on scenes directly, etc.

 

So far ISY has done a fantastic job in my opinion of making up for some of these limitations through programs and state variables. However understanding these concepts is difficult for an end user. A GUI change to turn a program on/off (run then, run else) would go a ways in fixing that for programs. However a virtual node would bridge not only programs but scenes.

 

Imagine if I could have my primary end users go to scenes on their virtual device and turn on the Away Scene. This is linked with a virtual "Away Switch" whose status can not only be tracked and trigger programs but also responders linked to that scene through the traditional manner. What functionality! Not only does it make things simpler for the end user but the administrators, read me , don't have to come up with crazy programs. (For example right now I'm creating several programs to get around the limitation of the fanlinc being a responder only even though I can turn it on/off directly from my phone)

 

I do however respect that the ROI may be low. I admit perhaps I was thinking the implementation would have been easier than what you have indicated. Unfortunately I have no formal background in programming and you guys that do achieve amazing things. My background is in networking and when I see a device that already receives/triggers commands I immediately assume it would be simple to have it send/receive commands for virtual versions. That is a fault of mine and the luxury of dealing with an almost purely virtual world on a daily basis.

 

P.S. It would also solve the OPs original request.

 

Edit: Even if the ultimate decision is no, not worth it sorry, I do appreciate the ability to bring it up. You don't know how much of a relief it is to have such a responsive developer. In my daily job I work with multiple vendors/developers whose software is far more expensive and far less functional than yours. Yet we have to push/struggle to get basic issues fixed. So I hope I don't come off as anything but appreciative of the work you guys do. I understand from your viewpoint I'm the new kid on the block with the crazy ideas (heck read my other posts) I just hope my word of mouth will drum up some extra sales for you guys. Given the support I've received already, I think I paid way too little for the ISY I bought

 

Also to be fair you work within the limitations given you by the manufacturers. I think the primary problem is with the devices themselves. Since Home Automation is entering the virtual more and more with the ISY, Smartlinc, etc. there is no reason, in my opinion, to have responder only devices. Every device should be a controller whether it has a physical switch or not.

[Michel Kohanim]

Hello Nuttycomputer,

 

First of all, we do very much value feedback and suggestions. Secondly, as I mentioned before, this is already one of the requirements we track but since there are multiple other ways of accomplishing the same, the priority keeps getting decreased in the favor of something more pressing. So, in short, the answer is not a NO. The answer is: what can we do in the meantime and quickly?

 

Now, it's time for me to dissect your comments!

Imagine if I could have my primary end users go to scenes on their virtual device and turn on the Away Scene.

This I really do not understand ... what is a scene here and what is a virtual device and where do the users actually go? Can you put this in the context of the Admin Console ?

 

This is linked with a virtual "Away Switch" whose status can not only be tracked and trigger programs but also responders linked to that scene through the traditional manner.

What does this refer to? Scene? Virtual Device?

 

What functionality! Not only does it make things simpler for the end user but the administrators, read me , don't have to come up with crazy programs. (For example right now I'm creating several programs to get around the limitation of the fanlinc being a responder only even though I can turn it on/off directly from my phone)

I understand only partly. In short, you want to have scenes that are not really INSTEON scenes but a collection of "things" that can control one another in some manner/shape or form. This said, your comment above does not make this case. You can simply turn on/off the ISY Scene in which the FanLinc is a member and hide the FanLinc switch altogether.

 

With kind regards,

Michel

[Nuttycomputer]

Michel before moving forward it's important I forget not to confuse myself and others by differentiating between end users and administrators. The common understanding with standard end users is that Scenes = Settings. (ie. Romantic, Movie Time, Awake, Away,etc) Scenes control multiple devices. Devices are simply that to an end user.

 

To administrators, like us, a Scene is something that connects a controller to one or more responders. (Sometimes that responder being itself for programming purposes) However, training an end user on this is difficult and confusing (especially as more devices are added) How does a user know if they need to go to scenes to control an individual device or devices. We can hide the offending devices of course but the user is jumping around the UI confused. This is a built in gap of the Insteon system that I feel will exist (especially as long as we have responder only devices) probably indefinitely.

 

In setups where the user only controls the system via keypads and button presses this gap is transparent since the user only interacts with controllers 100% of the time. However the ISY allow end users to control the system remotely and directly which makes this gap extremely apparent (and sometimes difficult to manage)

 

The workaround is complex programs.

 

I'll respond to your comments below but to be extremely clear. Under the administrative side the definition of a scene/device will not change. We will manage scenes/devices/programs the same way. All that I'm proposing is being able to add a virtual device. For example a virtual switchlinc that does not exist in the real world. The ISY then becomes the manager for that virtual device. Providing it a random address not already in use and responding/transmitting commands for it. As I said before, I'm in networking, so far as I'm aware the ISY already receives and takes action when Insteon Commands come in. However there may be something fundamental on the programming aspect that makes this difficult.

 

Imagine if I could have my primary end users go to scenes on their virtual device and turn on the Away Scene.

This I really do not understand ... what is a scene here and what is a virtual device and where do the users actually go? Can you put this in the context of the Admin Console ?

This is linked with a virtual "Away Switch" whose status can not only be tracked and trigger programs but also responders linked to that scene through the traditional manner.

What does this refer to? Scene? Virtual Device?

 

A scene here is the same as setup in the ISY. I confused my readers by using virtual device here. I meant a device that interacts with the virtual world. In this case an iPhone. Here is the context of what the end user would do and what would go on behind the scenes at the admin console:

 

End User (Utilizing Mobilinc for sake of Example) goes to the scenes tab on the iphone and turns on the Away Scene. In the Admin Console the ISY has the Away Scene. The Away scene includes:

 

- Virtual Switchlinc (Controller)

- Living Room Light (Responder)

- Thermostat (Responder)

 

The ISY then has a program folder setup with (Away) with an If Condition of:

- If status Virtual Switchlinc is On

- Then allow the programs in this folder to run.

 

As you can see not only does the user not need to add a dedicated switch/kpl button to control this scene the on/off status of the scene can be instantly tracked and used in programs. Something not currently available because, from what I understand, a limitation of Insteon and not the ISY. Limitation immediately bypassed. How Scenes, Controllers/Responders, and Programs all function does not change on the administrative side. What does change is the addition of a switch that the ISY directly responds/sends commands for.

 

What functionality! Not only does it make things simpler for the end user but the administrators, read me , don't have to come up with crazy programs. (For example right now I'm creating several programs to get around the limitation of the fanlinc being a responder only even though I can turn it on/off directly from my phone)

I understand only partly. In short, you want to have scenes that are not really INSTEON scenes but a collection of "things" that can control one another in some manner/shape or form. This said, your comment above does not make this case. You can simply turn on/off the ISY Scene in which the FanLinc is a member and hide the FanLinc switch altogether.

 

As demonstrated above Scenes do not change. They will still be Insteon Scenes. Regarding the fanlinc, despite the disconnect of asking an end user to go to scenes to control a devices (explained above), you can't simply turn on/of the ISY Scene in which the FanLinc is a member. Scenes are not mutually exclusive. If I turn the Fan Low Scene ON, I can still turn the Fan MED scene on, which compounds the confusion for the end user since they now have two scenes that can't exist at the same time stating ON. Unfortunately since the Fanlinc is a responder only I can't simply add it's 3 speeds as controllers to the scenes and resolve the issue.

 

The workaround/solution in this case is clever programing. I have 4 programs that track the state of the fan and change a state variable accordingly. The states are then used in several more programs to determine whether a KPL button should be on/off. I haven't finished programming but when I'm finished the end result will probably be around a dozen programs simply to keep the single Fanlinc, KPL, and iPhones in sync regarding the fan status. Whereas with the solution I'm proposing I would simply define 3 virtual on/off switches. (Fan Low, Fan Med, Fan High) and add them to the Scenes as controllers and present only those devices, utilizing the hide functions, to the end user. All of a sudden my Fanlinc, KPL, iPhones, tablets, etc. are all synced. More than that my user isn't confused by going to scenes to control an end device.

 

The fanlinc is only a small example of the above. I imagine many users would also benefit from being able to track the state of a scene and apply programs. Or as the OP requested the device could also be used in the "Replace with" function to temporarily store programing of another device.

 

I hope that clears up the confusion. To re-iterate how the ISY processes Scenes/Devices/Programs does not change. The request here is just to add a virtual node, as you put it.

[Michel Kohanim]

Hi Nuttycomputer, thanks so very much for the detailed explanation. I think I understand but just need to make sure!

 

Let's go to implementation side. Based on what you are suggesting, what ISY needs to do is basically trigger a program (perhaps invisible to the user) such that whenever that virtual device is changed, the corresponding program is activated and is run. Is this correct?

 

Our gap is perhaps because of not thinking and talking about the same concepts. Controller/Responder have very strict meaning in all home automation profiles. This said, I am not sure how the virtual node will help with the FanLinc issue especially when the customer changes the state of the FanLinc from an ISY client such as MobiLinc. In this case, how does the FanLinc become a controller?

 

With kind regards,

Michel

[Nuttycomputer]

Let's go to implementation side. Based on what you are suggesting, what ISY needs to do is basically trigger a program (perhaps invisible to the user) such that whenever that virtual device is changed, the corresponding program is activated and is run. Is this correct?

 

Hmm... I don't know whether it needs to trigger a program. Not in the program definition that ISY uses. All the ISY needs to do is stand in for the virtual device. That is send/receive insteon signals (through the PLM) on it's behalf since it doesn't exist to do it itself. My understanding of how the ISY works is that it already does a lot of this. It's already capable of initiating/sending Insteon Signals and taking action based on this signal (such as updating the status of devices). It already stores device link information (doesn't it?) The only addition, I think, would need to be added is having it respond with ACK signals for the virtual nodes it controls. You'll have to excuse my ignorance at this point. I'm not aware of all the Insteon Protocol signals the various devices use or which ones the ISY already sends out.

 

Our gap is perhaps because of not thinking and talking about the same concepts. Controller/Responder have very strict meaning in all home automation profiles. This said, I am not sure how the virtual node will help with the FanLinc issue especially when the customer changes the state of the FanLinc from an ISY client such as MobiLinc. In this case, how does the FanLinc become a controller?

 

I think the strict meaning of Controller/Responder would still apply for virtual nodes as addressed above. Unless there is a stricter definition that a controller must be a physical device.

 

In the Fanlinc example I would not give the end user control over the fanlinc directly. They would have access to the virtual switch with the scene setup in this manner:

 

Bedroom Fan Low (Scene) (Flagged Hidden for Mobilinc)

- Virtual Bedroom Fan Low Switch (Controller)

- Bedroom KPL Fan Low Button (Controller)

- Fan Motor (Responder Only) (Flagged Hidden for Mobilinc)

 

When the end user then turned on the motor to the low setting using either the Bedroom KPL Button or the Virtual Fan Low Switch the fan would turn on and more importantly the iphone and the KPL will be synced (since all controllers of a scene are also responders) Without the need for clunky programs or UI Changes. Since to the Isy UI and Mobilinc it's still appears as any other switchlinc device.

[Michel Kohanim]

Hi Nuttycomputer!

 

 

 

Hmm... I don't know whether it needs to trigger a program. Not in the program definition that ISY uses. All the ISY needs to do is stand in for the virtual device. That is send/receive insteon signals (through the PLM) on it's behalf since it doesn't exist to do it itself.

There lies our disconnect. What you are describing is called a scene in INSTEON and it must be tied to a physical device with an address. That's precisely what ISY's Scene node does: it acts, as a controller, to all the members of the scene. The problem is that this scene is tied to the physical address of the PLM and it has a group number (1 to 254). And, thus, the reason behind my statement that ISY has to run a program.

 

My understanding of how the ISY works is that it already does a lot of this. It's already capable of initiating/sending Insteon Signals and taking action based on this signal (such as updating the status of devices). It already stores device link information (doesn't it?) The only addition, I think, would need to be added is having it respond with ACK signals for the virtual nodes it controls.

This is not possible with INSTEON. All devices MUST have links to one another based on actual physical address. This would be much easier with X10 but not INSTEON.

 

So, basically, we are left with Virtual nodes that run program snippets (so that you do not have to go to Program's tab) ... this said, still, we are going to have issues with the FanLinc being controlled from an ISY client: without an event handler (i.e. program), it would be really impossible to make the FanLinc act as anything else but a responder.

 

All this said, I still do think there's a great value in having virtual nodes but perhaps not in the terms you were envisioning it.

 

With kind regards,

Michel

[Illusion]

. The problem is that this scene is tied to the physical address of the PLM and it has a group number (1 to 254). And, thus, the reason behind my statement that ISY has to run a program.

 

With kind regards,

Michel

 

 

Are you saying I can have a maximum of 255 scenes?

 

 

Sent from my iPhone using Tapatalk

[LeeG]

Actually 254. Group 255 is used for All On/All Off.

[Nuttycomputer]

I think I'm starting to understand why simply emulating a physical device can't be done. Let me just check my understanding. When I go to a device directly (not a scene) in the ISY and issue an ON Command what are the steps the ISY takes in relationship to the PLM? If I'm understanding you correctly the PLM actually sends a group on command with the PLM as the source? When I turn on the device (if it isn't a controller for any scene) it actually is sending a group on command to the PLM? If this is the case then one would actually need to start from scratch and invent/connect a stand alone device that connects directly to the insteon network that could emulate switches. (New product idea?) Otherwise the ISY would have to run invisible/snippet programs as you suggested. That would be very difficult though to come up with the logic on that. I'm struggling myself with just one fanlinc and one kpl.

 

Really it comes back to Insteon and I sent them an email before even commenting on this thread that all devices should be controllers. Responder only devices are causing pains in the mobile world.

[Nuttycomputer]

Are you saying I can have a maximum of 255 scenes?

 

254 and Devices if I'm understanding Michel correctly.

[LeeG]

“When I go to a device directly (not a scene) in the ISY and issue an ON Command what are the steps the ISY takes in relationship to the PLM?â€

 

An Insteon Direct command is issued. No Scenes are involved when using an Insteon Direct command. The Direct command has the Insteon address of the device receiving the command.

 

“If I'm understanding you correctly the PLM actually sends a group on command with the PLM as the source?â€

 

No. An Insteon Direct command is used. Group/Scene commands are only used when a Scene is involved.

 

“When I turn on the device (if it isn't a controller for any scene) it actually is sending a group on command to the PLM?â€

 

When a device is controlled On or Off a Direct command is used. It makes no difference if the device is a Controller/Responder or Responder Only. A Controller Only device such as a ControLinc, RemoteLinc, RemoteLinc2 and others cannot be turned On/Off. It makes no difference whether the device is in a Scene.

 

Insteon Direct device commands do not require and do not use Scenes (link records).

 

Although old there is an insteondetails.pdf document at insteon.net that covers Direct and Group commands. This aspect of the document is accurate as this area has never changed.

[Nuttycomputer]

Hey Lee,

 

Thanks for weighing in. I'm reading the whitepaper now. I guess the fundamental question though is when the PLM receives an Insteon Message does the PLM process it or simply pass it to the ISY. Going the other way? I'll look into that paper though I think it's coming more and more down to just understanding the fundamental relationship between the ISY and the PLM.