Goose66

I have seen this question before in other contexts. I guess I don't see why it needs to be any more complicated than put in 5 years worth of halloween dates and then revisit it in 5 years. This is what I do for my Holiday_Lighting state variable that drives nightime lighting and program execution for Christmas dates and my programs for irrigation. Nothing in my setup tends to last more than a couple of years without changes, anyway.

I am interested, as well. I would most like to see it have a framework for developers of Nodeservers that provide custom intefacing of the ISY 994i to 3rd Party devices and services. Nodeserver development includes XML that defines the interface (driver values and commands) of the ISY to devices (nodes) supported by the nodeserver. If there was a way a developer could define a tile for their devices (nodes) that works with these driver values and commands (in addition to tiles for the ISY's natively supported devices), that would be great!

Also, it appears that the Tesla Polyglot nodeserver is keeping my car awake! Car info is now instantly available every time I bring up the Tesla app on my phone. Did Benoit look at the effect of this on battery drain?!?

Posted this over in the ISY Portal forum but got no answers. I installed Benoit's Tesla Polyglot nodeserver through the portal (my first one) and it loads OK and connects to my account. However, it appears that there is no profile information loaded - at least none of the labels are appearing for the driver values and buttons. Is there a "profile.zip" loading step in the configuration that's not documented? How does that step work in PGC?

I find it easiest to tie Alexa routines to programs in the ISY, and just leave all the logic there with my other logic. Otherwise, I am maintaining some things in Alexa app, and others in the ISY, etc. Also, I can use an Alexa command to start the routine program, but I can also tie it to a keypad button or run it from the Mobilinc Dashboard as well.

I installed Benoit's Tesla Polyglot nodeserver through the portal (my first one) and it loads OK and connects to my account. However, it appears that there is no profile information loaded - at least none of the labels are appearing for the driver values and buttons. Is there a "profile.zip" loading step in the configuration that's not documented? How does that step work in PGC?

Perhaps "shortcoming" was a little passive-aggressive. But I do think after hanging around these forums for the last twelve or so years that the current model has caused some consistent confusion with new users because it's not entirely intuitive what events will cause the programs to run, nor is it intuitive what events will cause the program to be preempted and start again when it is already running. Thus the confusion around programs with WAITs and REPEATs seemingly not "finishing" is caused not by the WAIT or REPEAT not finishing but the program has been preempted by an occurrence of an event during the WAIT or REPEAT (and probably dropped into the Else branch) without the initial run of the program ever completing. But it's just a difference of opinion on approach, and I think the two program Trigger / Action model bridges the gap. I seem to recall that this was Chris Jahn's invention originally, wasn't it?

I am comparing it with a traditional scripting model. For example, if I am programming client-side GUI interaction of a web page in Javascript, I write a function (equated to a Program on the ISY) which may contain evaluation of many parameters from the DOM. But the browser will not automatically execute that function anytime the value of any one of those parameters in the DOM changes, right? I have to specifically tie the function to a DOM event to get the function to execute. So if I have a condition that checks the value of a text box, then I have to tie the function to the text_box_change event for that text box to get the function to run. If the ISY was a similar event-driven model, I would write the Program with all of the conditions I wanted to evaluate in the If statement, but then I would tie the Program to the events that I was interested in having the program run. This may create some Programs that had no If conditions (e.g., tied to an event of 'Device' is switched On with no conditions in If) and others with seemingly redundant information (e.g. If 'Device' Status is Off condition with the program having to be tied to the 'Device' Status_Change event), but the circumstances under which a program is executed would be clearer. This would help users, especially new users, with the inevitable confusion caused when a Program's Else branch is inexplicably run or where a Program containing a WAIT or REPEAT never seems to finish. This is why I tend to recommend the two program Trigger / Action approach, again especially in the case of a new user or non-programmer user.

Status of 'Basement / Light' Changes - Event 'Basement / Motion' Sends an On Command - Event CLIMD of 'Basement / Thermostat' Changes - Event Time is "3:54:00 PM" - Event etc. If 'Basement / Light' Status is Off - Condition If Time is between Sunset and Sunrise - Condition If 'Basement / Thermostat' TEMP_C is less than 54 - Condition etc. The ISY takes the conditions from the If statement of a program and infers the events upon which to execute the program. It is this inference that has caused some confusion in the past - e.g., Tom's question above regarding the program being triggered when the status of a device changes or continuously when the device is Off. By using the two program Trigger / Action model, the user can specify which conditions should be used as events to trigger the program and those that should not be used as events to trigger the program.

By “conditional” model, I mean you specify the conditions and the ISY decides what events trigger the program based on the conditions. In an event-driven programming model, you would specify the events that would trigger the program yourself. Think old school C++ Windows event loop or Visual C#. But, of course, we’ve certainly had this discussion before. So going back to Tom’s problem, it make no sense to run the program when the status of the Logitech activities change, because the program would always fall into the Else branch. So put those conditions in the disabled Action program, and the program will only trigger when the Motion detector sends an Off command (which is I believe the intention).

The Action program is disabled so that the events of the Logitech activities changing status don't trigger the program. For example, you've been sitting still for longer than ten minutes and then switch from TV to PS4. If the program were initiated, it would go into the else because the motion-sensor was not switched off, so why bother triggering the program at all? The purpose of the two program (Trigger / Action) approach is to address shortcomings in the ISY's programming model - the programming model is a conditional one, where it should be an event-driven model. To overcome this limitation, in the two program approach, the events that you want to trigger the program go in the first, "Trigger" program's If statement, and the conditions you want to check before executing the steps in the Then or Else branches go in the second, "Action" program's If statement. The Trigger program is enabled, but the Action program is disabled so that the conditions in the If statement also don't serve as event triggers. You don't always need two programs (such as simple schedule triggers), but if you consistently use the two program approach, it makes for a very neat and tidy model. It is also, IMO, the only model in which the Else branch ever makes sense. There is a lot of discussion of this approach and supporting arguments for it (along with a lot of counterarguments) in these forums, such as: .

Turn Off Basement Lights - Trigger: If 'Basement / Motion--Sensor' is switched Off Then Run Program 'Turn Off Basement Lights - Action' (If) Else - No Actions - (To add one, press 'Action') Turn Off Basement Lights - Action (Disabled): If 'Basement / Logitech XBox Activity' Status is Off And 'Basement / Logitech PS4 Activity' Status is Off And 'Basement / Logitech TV Activity' Status is Off Then Set 'Basement / Lights' Off Else - No Actions - (To add one, press 'Action')

Are nested conditions not supposed to create triggers for the program? If they still do, you need to use the two program Trigger/Action approach. Also, seems to me you want ANDs between the Logitech Hub activity status, not ORs.

I would like ISY portal support in Mobilinc as well.

I sent them many messages over several years to get access to the API for the hub as a developer without ever getting so much as a confirmation email. Steve may be a great guy, but he doesn't own Insteon or SmartLabs, right?

I guess it is a little reassuring to see a guy in an Insteon shirt at a show. But no information in the article or the interview on what may be coming, other than "it will be better ... down the road at some time." And I don't buy for a minute that this guy has traveled all over the World installing Insteon. I mean, does it even work in 50Hz electrical systems?

There are posts in the "Press" section of the Insteon.com website as new as January of 2018, but it appears there has been no new products since the Motion Detector v2, which is over two years old now. Are Insteon products still be developed? Is there an end date for these products that has been announced?

It seems to me this would basically remove the ISY from the equation. I see the point of the Alexa portal to be a voice interface to the ISY with the ISY containing the smarts of the system. This seems to me to be a way for the ISY to act as a device bridge or hub with the Alexa device containing the smarts. If this is the goal, why not buy sensors and switches that work directly with Alexa and remove the ISY from the equation altogether? EDIT: Well, except for these: You can ask Alexa if a door or window is open before arming the home security system A front door contact sensor can activate Alexa to announce that the front door is open

I would love to do my AV mapping through the ISY Portal instead of using whatever 3rd-party skills go with my individual AV devices and remotes. That's what we are going for with the ISY, right - the central controller?

I suspect the greatest danger is the same here as everywhere else on the Internet: people using the same or similar credentials for the UDI portal and forums as for other, more easily compromised sites, like your Domino's Pizza account or your online gaming account. We can talk about UDI implementing 2FA for the portal and newer security suites on the ISY, but I would bet 60% of the users will continue to use a single password for all of their vulnerable web accounts.

So this may be a situation where the hint says, e.g., it is a motion detector, but it has driver values to support both. A front end developer would then display it with the motion detector interface of the front end GUI, but display the temperature driver value as an "extra" value. Later, if the front end developer decide she wants to support that node "natively," and implement a specific GUI for it, she could recognize it by the nodedef id attribute, perhaps. There's no point in making a list that includes every possible combination a developer could come up with. That's how you devolve into the nonsense that Michel was concerned about. @Jimbo But I agree with you - to make the nodes most compatible with a generic front-end interface, like Alexa, you would want motion to be one sensor node and temperature to be another sensor node.

Oh, I thought this was for Alexa based on the topic. So the Unlock by code is for Google Home only? Also, I was asking if there was similar functionality in the API (for Alexa) for "Open" and "Close" as there was for "Lock" and "Unlock."

Is there any way in the API to implement that functionality for door open?

Magnetic contact sensor - you mean like a float switch? I will look for something along those lines, although the water doesn't really pool anywhere where a float switch could be used. I was thinking more of a damp or water contact type sensor.

I have a couple of spare I/O Lincs that I would like to hook up to a water sensor to inform me of roof leaks while we troubleshoot a roofing problem. Unfortunately I leave to go out of town on Sunday for two weeks, so it is something I need to throw together right away. Anybody know of something I can buy at Lowes or Home Depot tomorrow to use as a water sensor that can be quickly interfaced with an I/O Linc? EDIT: I just got the Z-wave module as well, so a Z-wave solution would work, as long as it is available commercially at a Lowes, Home Depot or Best Buy.