Scenes and programs (although perhaps I've simpler path)

[kck]

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.

[LeeG]

Trigger Reverse should function but is not a good choice with the ISY because Trigger Reverse only reverses the commands issued by the I/O Linc Sensor. Any Query, such as the 3AM Query will get things out of sync because Query returns the true state of the Sensor, not the command reversed version. The best solution is to change to a NO magnetic contact which provides desired KPL button state without the use of a Program/Scene.

 

As far as Trigger Reverse, what level ISY is being used?

 

What does Help | About show for Firmware line and UI line?

 

I don't use MobiLinc but is there not an option to hide items such as hiding a Scene.

[kck]

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.

[LeeG]

You could look at the I/O Linc Sensor node status to know if the door is open or closed. MobiLinc does allow the Status word to be changed so the MobiLinc can show Closed when the I/O Linc Sensor is On.

 

You are correct about the older garage kit. It did come with a magnetic switch that had both NO and NC built into the same switch. That magnetic switch is still available as a separate item or a NO only magnetic switch can be installed.

[kck]

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.

[LeeG]

Sorry about the no Scene Status comment. It was accidently copied from a Word page not meant for that post.

[oberkc]

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.

 

I agree...I want the button lit when the door is open. There may be another way to achieve your goal, even with the "new-and-improved" sensor. Perhaps there is a way you could re-mount your sensor such that it is in contact when the door is OPEN? This may be a little more complicated, but I would think doable.

 

The only downside to this in my mind is that I prefer confirmation that the door is FULLY closed, rather than FULLY opened. Mounting the sensor that engages when the door is open would result in a CLOSED status when the door is only partially closed, for whatever reasons.

[LeeG]

Here is a picture of how I mounted a magnetic switch to detect door is open. I have magnetic switches that cover both fully open and full closed positions on two doors. Use 4 Inputs on EZIO2X4. The open position magnetic switch is mounted on a piece of aluminum flashing that is flexible enough to allow the magnet and switch to come in contact well before the door is fully open. That way the minor variation in door stop position when open does not adversely affect switch closure.

 

I DO NOT recommend the open door position check unless the fully closed position is also monitored. The primary point of door monitoring is to insure door is fully closed. As oberkc has already noted mounting the NC switch now supplied with the I/O Linc garage kit to check the open position does not provide that function.

[blademan]

I'd like to second kck's suggestion. If you could simply add the ability to define a state variable value whenever a scene is activated, this could provide great utility in triggering other programs that you might want to also run if other criteria are met

[Michel Kohanim]

blademan,

 

Unfortunately the case for the scene is vague. What do you mean by "scene is activated"? Is it activated by ISY? Is it activated by one of the controllers in the scene? And, if so, what's the purpose of a state variable? In the case of the latter (i.e. activated by one of the controllers in the scene), you can always use regular ISY programs to either check for Control or Status for the controllers in the scene. In the case of former, we just have to have Control switched on/off/fast on/fast off for the scene. Regardless, I am pretty scared of opening up this discussion again since we never arrive at a conclusion that makes everyone happy.

 

With kind regards,

Michel

[kck]

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

[Michel Kohanim]

Hi Kevin,

 

Thanks you for clarification. We have been trying to avoid confusion simply because, historically, no one could agree on what a scene status meant. If all you require is scene activation by ISY, then that's definitely something we can entertain/implement as long as it's not going to include other things such as the status of the scene based or whether or not the scene was activated by something else other than ISY.

 

With kind regards,

Michel

[kck]

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 Kohanim]

Hi Kevin,

 

 

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.

So far we agree!

 

However if one can reliably get program activation whenever an activation event occurs whether at a physical device

This is where everything falls apart. What does this mean and how is it different than what we already have?

 

By the way - my initial experiences using your product has been excellent - nice job with it.

THANK YOU. It does mean a lot to us.

 

Kevin

[kck]

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"?

[LeeG]

kck

 

Some of what you discuss can be done today.

 

"(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"

 

Although whether a device is turned On locally or turned On remotely can be differentiated if so desired a simple

 

If Status 'devicex' is On

 

triggers the Program when the device is turned On, whether the device is turned On locally, or turned On remotely.

 

There are times when knowing the local activation of the device has taken place. This is done with

 

If Control ‘devicex’ is switched On

[kck]

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.

[Michel Kohanim]

Hi Kevin,

 

Thanks so very much for the feedback. It will take more than 7 years of support issues, calls, endless discussions to be able to reply to your subtle and well stated philosophical points of what should or should not be.

 

From a practical perspective - and as I mentioned before - if you limit your requirement to only having Control (NOT status) events available for ISY scenes in programs, then we have something to work on. Statements like the following are things that make everything fall apart:

"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."

 

This is not true and that's why we have an ISY scene. The outcome of activating an ISY scene is NOT necessarily equivalent to activating a controller in a scene (physically). You can have 10 different controllers in the scene each one of which does something different and then ISY scene can do something totally differently which includes turning everything OFF.

 

So, without getting into philosophical discussions, would having a control event for ISY scenes suffice?

 

With kind regards,

Michel

[kck]

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

[Michel Kohanim]

Hi Kevin,

 

Perfect. Thank you ... at least we have something to work on which is well defined and can be implemented.

 

I have added it to our Mantis #96.

 

With kind regards,

Michel