oberkc

I had no trouble on IE10 when I last had it. One of the common pieces of advice is to clear your java cache. Have you tried this?

Yes, I am pretty enthusiastic about the ISY. I don't consider using apps to be a stop-gap or workaround. I DO consider logging on to a web page, whether via a PC or mobile device, (to the admin panel) to remotely control my system to be unnecessarily complex. I consider control right on the home page of my mobile device (via widget or icon) to be the superior approach. I don't believe adding a virtual device, alone, allows for this. What other apps/devices allow the capability of the ISY (without relying on a PC to execute programs and events) that have the virtual device capability? I would love to check this out. So you have said. I admire the enthusiasm you hold for such an opinion. Based on the response given by UDI to your original post, it appeared they shared your opinion. I wonder if this has changed in the intervening years. Clearly you perceive it has value. Yes, there may be others who have similar perceptions. Yes, mobilinc is an additional cost. Is it more complex than what I perceive you are suggesting?...perhaps in setup, but not so in operation. Have you tried the ISY dashboard?" Thank you for your time and explanation. I truly did not understand

.I would expect it to be blank right after cycling power. If, however, you have successfully restored the device (no writes waiting), you see no commands in the event viewer of some (but not all) keypad buttons, and you see no status (blank), I suspect faulty device. You can try moving closer to an access point or other RF device, but I don't expect this to help. I have never pasted an image, but to save a snapshot of your desktop, or part of your desktop, I like the "snipping" tool that comes with windows (I think).

My firmware is 4.05 My UI is 3.3.8. It works on windows 8, using IE 11. I suspect it works on other browsers, but I cannot say that I have tried it.

keep in mind, too, that the remotelinc buttons do not actually have a STATUS. Any status shown in the admin panel is, as I understand, nothing more than the last command received. Perhaps a better method of fault isolating is simply to press the buttons on your remotelinc while watching the event viewer. Do you see the commands when the button is pressed? If some buttons work, and others don't, I cannot help but suspect a faulty remote. When you restored your device from the ISY, did you save those changes to the remotelinc? Make sure there are no red marks or warnings besides the device in the admin panel.

I am using windows 8. I have java update 7 update 45.

Yes, you did explain your use cases. The problem that I am having is that I am (or would be were I interested) able to do every example you cite, without virtual devices, so I don't see the need for having another device (real or imagined) in my ISY admin panel. I can do this via an actual insteon device or via my android phone, or via ipad. If I have internet connection, I can do this anywhere in the world. Doing so using iOS would be equally possible. I have two android tablets throughout my house and can control lighting this way, or via android phone. This can be done via iOS devices, as well. I have a remotelinc at a couple of strategic places, as well. My two tablets are also used for TV remote control. I can integrate this with my insteon system as well. It takes additional hardware, but I don't believe having a virtual device would make this any easier from a hardware standpoint. No, of course not. I use a combination of tasker and mobilinc for this. I don't use the admin UI for anything except MANAGING my insteon system. I often go months without opening the admin panel. But I can easily turn on or off anything insteon via android/iOS device. I admit that doing so via PC is not something that has interested me, so I have not much looked into the options there. OK, I will take your word for this. I have no idea whether having a virtual device makes it easier to create apps. Of the two apps I have seen, they can display status for existing devices, so I am happy to assume that it would be no different than showing status of a virtual device. I can use tasker/mobilinc to create home-screen widgets that can do anything that insteon can control. Using mobilinc directly, one can see status of any device and control any scene. The only complaint I have with this method is inability to create a specific user interface that I would like, which would mostly be an emulation of a keypad. Having a virtual device may help make this a reality, but only if controlling it remotely would result in behavior like a direct (manual) control of a real device.

Am unsure what you mean when you say you have your ISY connected with smartlinc. I have not experienced the problems you are describing, but wonder if it is related to trying to maintain some relationship with smartlinc.

As one who deals with requirements versus solutions for a living, it sounds to me as if you are pushing for a specific solution without defining your requirement. I will admit to being unfamiliar with the rest of the home automation world and programming, in general, and that your requirement may be self evident to those who have this familiarity, but I am having trouble understanding (but still curious) what it is that you are trying to achieve. Is it a desire for a better human-machine interface to allow more intuitive and tailorable interface for control of your system from a web page on your PC...to display this virtual device from the admin panel? Do you want the ISY firmware to include the ability to create this configurable interface? Is it the ability to write apps that interface to the ISY? On what hardware do you want to display this virtual device? (Your mention of "apps" makes me think you are intending this for android or iOS tablets. ) I have no personal interest in controlling my lighting from the PC (or at least providing a wife/guest_friendly means to do so). Perhaps that is what I am missing here. My interfaces are all through tablets or actual insteon devices and I find barely reasonable (room for improvement, however) methods to create that user interface. I must admit, however, that I would definitely like the ability of an android tablet to act as a virtual keypad device, looking like a keypad, showing status for each button. So far, I have not found a solution for this. I do use android tablets and phones to control my system, however. My approach falls short of a "virtual" device in that it does NOT show status for scenes or devices. I have understood this as a limitation of android (multiple icons based on conditions) rather than a limitation of the ISY and don't believe having a virtual device within the ISY as a solution to this problem. I appreciate your patience with me.

And how is this different than using a variable, or another program, to respresent some "virtual" status? So, you are not arguing for a new capability, but, rather, easier use and better integration with the rest of the world. OK

Turning on and off a folder does not sound outside the realm of what can be done now. What device do you wish to use (tablet, cell phone, something else) so you wish to be able to control this virtual device? If you were to describe your intentions, perhaps someone could come up with a solution. Perhaps I just don't understand the meaning of a "virtual device".

I must admit to being curious what it is that you cannot do with existing programming capability.

This sounds like a problem with the keypad, itself. Have you attempted to remove power for 20 seconds or so, then restore? Does the ISY show any device status for the failed buttons? What happens when when you restore the device from the ISY?

The program seems simple enough that I would look for other reasons this is not working. Choose one of these programs from the program listing, right click, run then. Does it send a message? If it does, then look for clues that the ISY is not seeing the status of the devices.

I don't believe a uery will ever yield a false value. Instead, it would result in a comm error and unknown state. On the other hand, it is possible for the ISY-assumed state of a given device to be false hen commands are sent and devices fail to respond. What my be happening with you is that a device status becomes out of sync with reality sometime during the day. The 3am query corrects this condition resulting in the ISY perceiving a status change. Programs triggered by status are, subsequently, triggered causing some of your lights to come on. I don't believe a query alone will cause lights to come on. I also understand you can disable the daily.query without the world coming to an end, it this may increase the possibility that ISY status for any given device mismatches true status. How important this is would be dependent on which devices these are and what programs you have that depend on said status.

The difference with using a pogrm versus scene I based on the desire to have the kpl button indication be off=closed. Using the now-standard sensor, installing the sensor to be in contact when the door is closed would result in a ON indication with the door closed. Using a scene in this case would result in the button being ON=CLOSED. Using the other sensor, installed as before, you have the option to choose (by wiring methods) whwhether ON or OFF= CLOSED.

I have not rechecked, but I recall that there is an option to get caught up with programs and schedules that one can select or deselect. I think it is under the configuration tab. Perhaps yours is selected and you are seeing the result of this?

The solution is likely predicated on what you WANT the lights to do after you incorporate them into the insteon world. Solutions include using a keypad at the existing switch location and use micro modules (or inlinelincs) at each fixture location. If you desire manual control of only one fixture, you could skip the keypad and install a single switch. Make sure you have a neutral at the switch box location that is on the same circuit as the hot that feeds the existing switch.

and... when you set the responder levels, make sure you set these for the scene level AND for the KPL controller button. You have to set these in two places for this to work.

While the button grouping is a viable option, it can start to break down if you control it from the ISY or an app on a mobile device. Groupings only work when the keypad is controlled by direct push of the buttons. It sounds to me like you may have missed a step from the other post. Yes, set each button as non-toggle on. Add the fanlinc appropriate speed to the button (for example, add the fanlinc medium speed to the button assigned to trigger medium speed). Finally, add the other three buttons as responders. When you do that, make sure each of those responders is set to an ON level of ZERO! I think you will like this approach better in the long term.

You are correct...It would not matter. I was responding to the original suggestions that one could create some scenes manually, and create other scenes via the ISY. A more accurate statement would be that the ISY should be aware of all links and scenes, however created originally. Having links outside the ISY is more difficult to manage, in my mind.

I find scenes to have a couple of benefits over programs. First, response is quicker. A device responding to a scene command from another device generally reacts faster than a device responding to a program which was triggered by another device. Second, I find the growth path easier to manage with scenes. As my number of devices grows (incrementally for me), I find that I don't have to worry much about how this affects my programs. All I have to worry about is putting the device into the correct scenes. I find it easier and managing scene construct than programming. This benefit, however, may be dependent on the kinds of things one does with programs. To elaborate on the second point, I have an ALL HOUSE INTERIOR scene. Any new device that I add to the inside of my house goes here. The various programs that control when my house goes to sleep will work properly without any changes. I have a HOLIDAY scene. Any new devices that are for holiday decorations go into this scene. I have a couple of programs that call on this holiday scene. Making one change to a single scene is easier, for me, than making changes to multiple programs. I simply find this the easier way to manage my growing insteon system.

In my mind, a simple program such as: if control 'switch-A' is on << then do something else nothing will NEVER be false, unless triggered externally, such as being called from another program, or if triggered by additional conditions within the program, such as: if control 'switch-A" is on << and time is between 0700 - 1000 << Then... Else... Such a program will trigger itself at 0700 and at 1000, and upon receipt of an ON command from switch A. Such a program will be TRUE only if receipt of an ON command occurs between 0700 and 1000. It will stay true until 1000, at which point this program will turn false and stay false until receipt of another ON command between 0700 and 1000. aweber1nj, it seems to me from your posts that you are understanding it just fine. Just to be sure, I offer the following examples: if control switch-A is turned on <<< if control switch-A is turned off <<< if status switch-A is ON <<< if status switch-A is OFF << if status switch-A is NOT switched OFF << The other thing about the ISY that seems to trip folks up who have experience with other programming languages are WAITs and REPEATs. If a program is triggered while in a waiting period, the execution will halt and start executing a new path, based on results of the evaluation. For example: If control switch A is turned on and control switch A is NOT turned off then wait a few minutes do something else do something else In the program above, if switch A is turned ON, it triggers an evaluation and the evaluation for the entire condition is TRUE. Then path will run. If, in less than a few minutes, the switch is again turned ON, the program will halt the existing wait period and start a new wait period. If, in less than a few minutes, the switch is turned OFF, it will halt the existing wait period and execute the ELSE path. Beyond triggers and wait/repeat, I think you will find the programming quite intuitive and consistent with your experience. Hopefully, this helps.

You are not the first to express the opinion that there is something not quite right. However, I have always found that it works completely predictably once you understand it: that is, what triggers a program to be evaluated. Once evaluated, the "pure logic of the expression" does, indeed, govern the execution. Understand program "triggers", and I think you will find the ISY to be quite logical.

Yes. Under this condition (still assuming the simple case that this is the only program condition) the else path is not run.