kck

Got my Echo working with ISY via a RPi with the Hue emulator. Works well if a bit awkward. By the way - one thing to be sure of when setting it up is that capitalization counts. The "offUrl" is exactly that and not offURL as one might have expected (being an acronym after all). Spell it wrong and the actual offUrl gets set to null which results in a device not found back from Alexa. My biggest issues setting it up was pulling in my 20 year old Unix knowledge from some lost part of my aging brain. Been a long time since I banged on Unix stuff but it does come back to you when you play with it. My main problem now is that my RPi doesn't want to successfully boot with only the WiFi adapter in it so I have it hanging on enet which isn't ideal. Have to debug that one when I get a chance.

I saw something that sounds similar with a KPL of mine. It controlled the LED vanity lights in my bathroom and it would go into an almost buzz like fast flickering when pressed on while the other keys worked ok. The default for the lights from that switch was a partial power setting like 50% or so. I factory reset the switch, cleared scenes associated with the KPL and reloaded it from the ISY and it would work for a while but then the problem returned. Ultimately I swapped it with another KPL elsewhere in the house and both have been fine since. All I can think is that in my case the "flickering" was some sort of marginality in the actual KPL electronics that was getting triggered by controlling an LED as less than full power. I don't recall where I swapped the failing unit now but I think it may be controlling an incandescent lamp or may be in a spot with no connected load. In any case, all evidence for me suggested a bad Insteon unit.

Are you using the floor heat for room heat or just to take the chill off the floor. If the latter there is usually a sensor put in the floor that is remoted to a thermostat. For my bathroom with that set up I just use an old style non-electronic thermostat that is set to the max temp that I'd like the floor at and in series with that I put an Insteon on/off in line switch. I do not try to control the temp of the floor since for this application the only real purpose of the thermostat is to avoid overheating. But I don't want to always be heating the floor so this way I have a "prep bath" button on our bedstand keypads that turns on the floor heat as well as doing other bathroom setup for lights, hot water recirc, towel heater, etc. in case they are not yet set. I then have a program to turn the heat off after a set time (or alternately turn it off via a dedicated keypad button).

It's not an IR controller - it's an RF so IR won't work. (I have one - not connected to the ISY.) There is a hardwired switch that is an alternate to the remote that has 3 positions (on, off, remote). I suspect that you could wire into that with a low voltage switch to cut power to the unit by essentially putting it into "hardwired off" mode. The ignition system for these units are all low voltage driven either by a wall wart or by 4 AA batteries.

Interesting - I would have expected a slightly different behavior. Since in other place it has been stated that the program triggers at the from and to times and since the condition is false in this case I would have expected that the program would trigger but the condition would be false and hence the else would run. This is yet more evidence for the need to clarify triggers versus conditionals from the other thread that is running.

I actually saw similar behavior a while back at my house. During a remodel I had temporarily put an Insteon on/off toggle in a spare bathroom to control the lights. There was also in the same bathroom a conventional switch that controlled an exhaust fan. Quite often if you turned off the fan with the conventional switch the room light would go off and then turn right back on. Since this was a temporary setup (that has since been returned to both conventional switches) I didn't try to do any further diagnosis on it. But it does sound like the same sort of behavior.

I seem to recall that you also have to remove the old device from any folder while you do the replace - i.e., get it to top level. Otherwise I don't think you will see the replace option listed.

Not sure if this will work for your case but a simple wait can handle some cases. if cond1 or cond2 or cond3 then wait 5 min do something if the conditions can trigger multiple times or in varying orders then the wait will trap the multiple events in that if another one occurs during the wait it will just restart the wait. The problem with this approach is that it doesn't bound the debounce period in that if you have a condition triggering every 4 minutes you will never get the action done. Still for some cases I've had it does handle things and is simpler that the explicit approach of multiple programs to create the debounce window. By the way - a simple example of when this works is if the if simply has a number of state variables in the if all of which may change in a very short interval due to other programs running and you simply want to collapse any change into a single execution of the action.

There may well be a better way but of late I have taken to generating lots of "state" variables that reflect the state of my house and can be used in tests like your if and also can trigger programs when they change. You simplest bet might be to have a variable that represents the state of the sprinkler system and set it anyplace that you disable the sprinkler program. A bit risky since you might not get it everywhere. So using my approach of late I wouldn't disable the sprinkler program - I'd use that state variable in the program to have it not execute. That way the state of the sprinkler system would be fully represented by that one variable.

You can get the effect you want with the magnetic switch you have but it requires a program and a scene. Create a scene in which the responders are the KPL button(s) that you want to reflect the door status. Then create a program like: If Status "GD Opener-Sensor" is not On Then Set Scene 'GD Status' On Else Set Scene 'GD Status' Off I have some corner cases in my setup where things could get out of sync so I actually run this program every 15 minutes from another program just to make sure the indicators are correct for those cases but I don't think I actually would have to. In any case, using a program and a KPL scene you can make things work as you'd like with the supplied switch.

For my unit the sticker in the thermostat says it is V1.6 5212 and the ISY Admin Console reports it as V.0D on the top of page header. If there is some other way to query firmware version let me know and I'll get it. Kevin

I can set the other modes but not Program Auto. I just tried all of them from the admin console. For off you send CLIMD 0 and then if I query I get back CLIMD 0. Likewise for Heat (CLIMD 1), Cool (CLIMD 2), and Auto (CLIMD 3). If I set Program Auto you seem to send a CLIMD 5 but when I then query I see back a CLIMD 3 and, of course, the GUI then reflects the Auto as the status. It sort of looks like the Thermostat is the issue but seeing such consistent behavior across a number of units (Jeff's 2 and my one) makes it seem like there is intent in this behavior rather than some random error.

Did anyone else ever see this or find an answer? I just installed this thermostat and see this same behavior. I'd like to have the program mode running much of the time but override it when away and some other times. I'd like my programming to be able to turn program mode back on but don't see a way. Thanks Kevin

Yes. All I have asked for is that a control event allow program activation when that control event originates in the ISY. I agree that there is no consistent notion of "status" for a scene - thought I had said that earlier but maybe not clearly. However if a user program could be activated by any of the ISY scene control actions then the user can invent his own notion of what scene status is in any individual case by setting his own defined state vars. Perhaps it would be clearer is I said that I'd like to be able to have programs track any control events that might impact a "scene". I can do that now for all the physical switch events so if I could also do that for the ISY events I think that covers everything. That was all I meant when I referred to clicking on the "on" button on the ISY scene page. I do not expect that the result of clicking an ISY scene button is the same as touching some particular physical switch - I just want to know it was clicked (even if it causes no change to the scene responders). And I fully understand if something like this is low priority and thanks for engaging in the discussion. Kevin

True but status and control aren't quite the same. In particular I can't distinguish between on and fast on because I can only react to the final state of the device. Also, if the device is already on I can't see an additional control operation with status. Now as I said, I would tend to extend the model for consistency but that probably comes in part from 35+ years and a computer and systems architect which generally tells me that more generic and simpler models are better in the long term. My real point continues to be that the virtual switch that exists in the form of the ISY software (whether instigated by the ISY GUI or a mobile GUI) should be treated in the same manner as the real switches. Having said that, for the cases I am thinking about I'd take just doing that with the virtual switches that control scenes but would be surprised if it would be much harder to do it for all the virtual switches than for just the scene ones. By the way - just for reference some of the things I'd like to do use the fast on and fast off on a toggle to do some additional work since these commands are otherwise unused for the most part. There are some places where a KPL is overkill but you'd still like to be able to turn on or off some other stuff in certain cases. I can do these things from toggles now (and am) but I'd like to be able to tell my wife that the fast command always does what she expects whether she issues it from the toggle switch or from her iPad.

If I go to the "scene" page in the ISY GUI and click "On" (or any of the other actions) this is the equivalent of activating a physical switch that is linked as the controller of that scene. In the latter case I could have a program defined to also run in response to the activation of the physical switch but in the former case I can't. Likewise, if I am running a mobile client that uses ISY to activate a scene by remotely issuing the "on" or "off". From what I can tell, ISY is essentially registered as a controller for every scene. For the physical switches I can say "if control myswitch is switched fast on" and cause a program activation. I think what I'd like is to be able to equally say "if control ISY-scene is switched fast on" and have a program activate for that. That way, if I want to do something when the user activates a scene I have to attach a program condition for each of the (2) ways that the scene can be activated (or fast on'd or off'd etc.). Since mobile apps seem to be extensions of ISY in this regard, if say MobiLinc does an "on" for a scene and there is a program that will trigger on that ISY doing an "on" for that scene, it gets run. I think the model I have in mind is really simple (though I may be missing a subtle point since I am still new to this) in that is asks to simply treat all the ISY controller "buttons" the same way as you treat the real switches and it doesn't rely on any defined concept of "scene" beyond what you already have in ISY. (And for consistency I'd probably extend this to ISY activations of devices as well since at the moment there is a different between doing an "on" at the switch and doing an "on" of the same switch in ISY.) From what I can tell you can't do these things at the moment but I'm not sure what the issue you are worried about regarding the definition of the operations is (as distinct from whether you have the time/priority to actually implement this idea if it were deemed worthy). So can you explain why what I am asking for causes "everything to fall apart"?

Thanks. Yes I completely understand that you aren't in any position to define an abstract notion of scene status given that the "scene" might come into existence by activating its parts rather than a single switch and it might go away by being activated and then having parts of it changed and none of these things are "well-defined" regarding the concept of the scene. However if one can reliably get program activation whenever an activation event occurs whether at a physical device or via ISY's virtual device then users can answer for themselves what they think a "scene" is and how to reflect their own defined state variables to keep that state if they wish. That way you guys only deal with events which are well defined things. By the way - my initial experiences using your product has been excellent - nice job with it. Kevin

Michel, I agree that if the scene is activated from a device one can attach a program to the control action of the device. However, unless I am missing something (which could well be) if the scene is activated from the ISY (or some program using the ISY like MobiLinc is) then there seems to be no way to attach a program to that activation. This seems asymetric in an odd way. I would be fine if the "control" action in program if statements could include the ISY scene activation (assuming this also includes external programs that access through you). This would make ISY "like" any other controller - which in fact it is except for things like this inability to respond to its control actions. It just seems that the way things are you can only react to "real" controllers (i.e., Insteon devices) but not to "virtual" ones (ISY itself). Kevin

Yup - understand that Insteon has no Scene status concept. However, in the programming/control model of ISY one could certainly define a notion of virtual device that acted in some predefined ways that would allow you to create links between what happens in a scene and other control actions. That is why I mentioned the idea of an ISY defined virtual device that would accept scene commands and would "output" commands or hold status (i.e., state variable). The issue would seem to be that ISY would need to be up to see the commands issued even though other scene activities can occur purely among the Insteon devices. However, from what I see here I think most folks actually assume that the ISY is up and running all the time so in practice this would not be a major issue. One could always define run at startup codes to set the virtual devices as needed but in the normal course they would capture that Scene status that the underlying Insteon system doesn't record or have.

Thanks - Strangely I was running 3.3.10 firmware but an older UI. Since this was a new unit I guess something went wrong when I was installing. I cleared my java cache and redownloaded the UI and now have 3.3.10 UI as well. That explains the Trigger Reverse problem I was having. I can now set that although the issue you raise suggests that isn't really the right solution. The issue with MobiLinc isn't that you can't hide things but that I need to not hide the sensor scene or I can't see the state of the door. However, I think I have discovered that it is possible to remove the "buttons" for that scene on the MobiLinc by renaming them to blank. That seems to eliminate the danger of accidently changing the scene. So I guess that will handle my problems for the moment. On the other hand, it seems that it would be nice to be able to trigger a program based on a state change in a scene - a "virtual" responder device in the scene that could be listed in the condition part of a program. An alternate way of doing it would be if ISY allowed a state variable to be changed by the scene, or for that matter simply treat the scene status as a state variable. So far I like the ISY but it seems that they could unify a few of the programming concepts and get a cleaner all around set of tools. Back to my original problem though: All the documentation for the use of the garage door kit seems based on an older (?) magnetic reed switch that I guess SmartHome used to ship that allow you to choose to connect as NO or NC. The one that came with my unit doesn't seem to have that capability so the advice in the How To here seems out of date for getting a KPL to be lit when the door is open. That would seem to be a common need for using the kit since having the button lit for the door being closed seems counterintuitive from a human factors perspectives - you want to see an unexpected light to remind you that something is odd. It would seem pretty tricky to accomplish that now other than the way I have with a separate follower scene and program which seems like overkill for what is probably a fairly common desire.

New to ISY and Insteon but a long time computer expert and have been generally figuring things out as I go with my installation. However I have one problem that no amount of searching has turned up an answer for - sorry if I just missed it. I installed the current garage door opener kit and want to reflect door status on a KPL with light on if the door is open. The current kit does not give the option of reversing the sensing at the magnetic reed switch which is seems the normal approach suggested. Also, setting reverse triggering for the sensor seems to do nothing for me. In fact, the check mark is gone the next time I look at that dialog box. So I decided to solve the problem with a scene that has the kpl led as a responder and then set that scene on/off with a program that responds to the GD sensor correctly. That all works fine. Now the problem. I also use MobiLinc from my iPhone and displayu the status scene there so I can see if the door is open from elsewhere. Unfortunately, ML is quite happy to allow me to turn the scene on/off from my iPhone which then renders the indication of door open/closed in valid until my program next runs which happens when the sensor status next changes. So I can only a reliable indication if I force the status program to run which I can do but is rather inelegant. For the moment I have a program that forces the query of the door status every few minutes which gets things back to correct in case you inadverently touch the wrong spot on the MobiLink screen. What I'd rather do would be make it impossible to change that scene from ML but that doesn't seem possible, or trigger a program on the ISY whenever that scene changes state (then I could make sure the state change is legit) but it doesn't seem possible to have a scene cause a program to run. I think I am missing a simpler approach here. Any thoughts? Thanks from a newbie.