Goose66

2-3 years is not very long, especially without a replaceable battery. Also, I am noticing it is essentially an "online" UPS, where the ISY (or whatever) is 100% fed by the battery, and the battery is periodically recharged by the supplied charger. I don't what the low and high thresholds are for charging, but they are close enough that it switched on and off at least once (red light/green light) while I was installing a second outlet and mounting it in my utility closet. If it is going to go through charging cycles like this several times a day, especially if it's charging to 95% or 100%, then I can see why the life would be limited. Li+ batteries need limited charging cycles and should be kept between 20% and 80% charged for longest life.

Should I be using the 9V output for my ISY or one of the 12V outputs?

It seems to me that this is a problem with authentication to the ISY. Since NodeLink is now running, go to System Config and ensure your ISY credentials are correct, then restart NodeLink from the web interface.

@Teken Don't know how one tests and validates long term impact on anything Insteon given the lack of diagnostic tools and the fact that Insteon is so flaky, varying in performance from day-to-day.

Does it avoid the need to use a FilterLinc to protect Insteon? That would reduce the total price. Also, I was comparing VA to mAH, which obviously (to me now) is not comparable. I moved my ISY to the utility closet with my electrical panels recently and was just searching for UPSes for it this morning! EDIT: For anybody finding this post in the future, the 700VA UPS I was considering in the same price range has a 108Wh battery compared to a 98Wh battery for this unit. I am sure there are additional losses in all the conversion from AC-DC-AC-DC and 120V to 12V to 120V to 12V so this is a pretty good solution cost-per-Wh wise.

Just out curiosity, why would one want this device over a more traditional line interactive UPS that had 25x the backup capacity for the same price or less?

You can use one of the dimmer switches for the light, but probably best to get an On/Off switch for the fan, or get a FanLinc and link with the two switches for control of the light and fan.

I have had Insteon thermostats for may years now. But I just installed a Venstar ColorTouch 7900 in my basement and wrote a Polyglot Nodeserver for it. One of the primary reasons I was excited to try something different is I was having Insteon problems (another dying PLM, as it turns out) and communication with the Insteon thermostats was one of the first to go. I really like the Venstar ColorTouch 7900 and the mobile app (Skyport) that works with it. The Wi-fi connection seems very reliable. There's also native Alexa support without going through the ISY (although I haven't played with it). The Polyglot nodeserver also let's me control all the same aspects of the Venstar thermostat as I was on my Insteon thermostats, primarily changing setpoints for vacation mode. But the nodeserver has to poll the Venstar (every 10 seconds or so) and doesn't get the instantaneous updates on state and temps from the thermostat like the Insteon thermostat does. Also, I don't believe the Venstar thermostats (or any nodeserver-supported thermostats) are supported with a thermostat-friendly interface in Mobilinc or Agave.

This use case begs for an occupancy sensor. Is there a thought process here or is it just a cost issue? The money you save in electricity from having occupancy sensors in the home will pay back their cost over a few years, IMO.

@madcodger I forget that another place where Nodeservers cans be hosted is Polyglot Cloud, or "PGC." PGC is available through my.isy.io if you have a ISY Portal subscription. The nodeservers available on PCG are primarily those requiring an interface to cloud services (e.g., Tesla, Ring, etc.) instead of local APIs that run internally on your home network. Any PGC nodeservers that you configure will also count towards the 25 nodeserver limit on your ISY.

Each nodeserver can reside on a different host. Therefore you can have multiple RPis running Polyglot or Nodelink or hosting native nodeservers all hooked to the same ISY, as long as the total number of individual nodeservers doesn't exceed the ISY limit. For example, I have three instances of Polyglot connected to my ISY: one running on an older, RPi 2 which has reached EOL, my development instance running on a newly imaged RPi 3, and my "production" instance running on my Polisy. Conversely, a single RPi can only run one instance of Polyglot, and that instance of Polyglot can only connect to one ISY.

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.

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?