Goose66

Nodes from nodeservers now add in Alexa as well. Can't test voice functionality until Tuesday, but just about all of mine are currently in scenes or programs, so it would only be for testing purposes that I add one directly.

+1 for this problem for Alexa as well. It is possible it has never worked since v3 Smart Home Skill and/or the Category selection option.

You could choose the two program option as well: One Trigger program that has the motion detector being switched on in the If statement and is enabled, and One Conditional program that has the other conditions (time range and status of overhead lights) in the If that is disabled. Same structure as using the folder as suggested above but extensively discussed here in these forums and in the Wiki. May be a more conventional approach than the folder.

If the sensor is sending multiple Ons and he just removes the Wait timer, then he is going to get a bad counter value and multiple notifications with each sump pump cycle.

The SynchroLinc threshold power usage depends on the order of calibration of the levels - high energy level first, then the threshold is 25% of the delta less than the high energy level, but low energy level first, then the threshold is 25% of the delta above the low energy level, which would be more effective for determining On vs. Off, IMO. I cannot verify that disabling a program halts its execution without testing - but that seems to go against my understanding of how programs work. Regardless, it seems that multiple Ons and Offs was/is the issue, so you can break your program into two programs: a Trigger Program: Sump On (enabled) If 'Sump' is switched On Then Run 'Sump Notify' (Then Path) Else - No Actions - (To add one, press 'Action') and a conditional program that is disabled: Sump Notify (disabled) If Status 'Sump' is On (Not evaluated or necessary) Then Disable Program 'Sump On' Send Notification to 'Russ' content 'Sump On' $DailySumpCycles += 1 Wait 1 minute Enable Program 'Sump On' Else - No Actions - (To add one, press 'Action')

Depending on how your SynchroLinc was calibrated, it may very well be sending multiple Ons and Offs while the pump runs. I would suggest calibrating the SynchroLinc with the Off state first (hopefully 0W) and then the On state. That way the trigger point will be closer to the low energy state. Also, if you change your program to "If 'Sump' is switched On," you will have fewer program invocations. After performing both of these steps, you may be able to remove the Disable/Enable and Wait from the program.

Sounds like your sensor for the sump pump running is "bouncing," i.e., sending multiple Ons and Offs during a single run. Each time the status of the "Sump" device changes, the program is run anew and any running copies, e.g., sitting in Waits, are cancelled. So that's why the variable is never incremented. Can you tell us what type of device "Sump" is? One thing to try is something like this: If Status 'Sump' is 100% Then Disable Program 'Sump ON' Send Notification to 'Russ' content 'Sump On' $DailySumpCycles += 1 Wait 1 minute Enable Program 'Sump ON' Else - No Actions - (To add one, press 'Action')to move the

I assume the wait is to only update the counter if the sump stays at 100% (On?) for more than a minute. So I suspect that this is the issue. It is hard for me to imagine a sump pump running for more than 4 or 5 seconds, much less a minute. But I don't know what your installation looks like.

If security of remote access is the issue, might I suggest a VPN into your LAN, and then simple http access to the ISY from the Admin Console. Alternatively, use RDP or Go2MyPC or equivalent to access a PC on your LAN and run the Admin Console there.

That doesn't really explain why it would be so much slower over https, though. My machine is not that fast (core i5-2500K @ 3.60 GHz) and it has no problem running the Admin Console in Java.

I had these errors in some programs after going to 5.0. Just editing and saving the programs fixed it. I think there are/were bugs in the program conversion process, and they show up as "Out of Memory" errors in the UI.

It is worth noting that if the ISY turns a Scene on or off, e.g., by way of a Program, there is no Insteon Scene Clean-up Sequence such as would occur if the Scene was triggered directly from a controller Insteon device. Therefore, it should make no difference to putting a Wait between scene commands because there is just a single command put on the Insteon network to turn the scene off with no followup cleanup commands.

Have the program turn off the scene containing the three buttons in the Else statement (that is what runs when you ask Alexa to turn off a program). As far as the If statement in the program AND the enabling of the program at the end of the Then branch, what are you trying to accomplish there?

You don’t have an “Alexa Category” pulldown in the dialog that comes up when click the Add Program tab? Sent from my iPad using Tapatalk

You can choose how the program/device/whatever is presented to the Alexa skill in the portal. Ultimately, you are going to want the network resources to be called in programs if you are going to implement a sensor to control the open/close aspect. Go ahead and create the programs in the ISY and then categorize them to the Alexa skill as "device/light" or "device/switch". Now you can put them in Alexa groups and routines.

I just put the date ranges for three or four years in an if statement. Nothing in my home automation systems stays consistent that long anyway, and if it were I would just have a very simple change to make every four years.

You can put the the KPL buttons in the scene that implements your virtual multiway circuits as controllers and responders (in other words, the KPL button is just another switch in the virtual multiway circuit). If a KPL button is actually associated with multiple, different virtual multiway circuits, then you have to create a new scene that has the KPL button and all of the switches from each of the different multiway circuits to control the on and off. You then have to have a program that syncs the status of the KPL button light with the state of the switches controlling the load(s) in each of the virtual multiway circuits, e.g., turn the KPL button On if the status of any one of the switches is on, otherwise turn the KPL button off (or vice-versa, depending on how you want it to work).

Anybody with an extensive Insteon installation ever user a power line networking solution, like TP-Link AV600? I am needing to get wired network connection to an outbuilding and hopping it over multiple wi-fi extenders is just not working well. I was going to try the TP-Link devices but I don't want it to bring down my Insteon network.

The thing about the portal subscription is that UDI has recurring costs for renting the server time (as well as ongoing maintenance and enhancement of the Alexa and Google Home skills). It sort of makes sense that the portal be a subscription, right? Sent from my iPhone using Tapatalk

I think the Open thing may be a security feature. I know that your Smarthome Skill can't allow garage or other doors to be opened on an "Open" command in order to pass certification. But the weirdness and inconsistency in the responses is what's interesting Would be interested in knowing if it’s coming from a return code from the Skill or from the Alexa side. Perhaps Brian Mercier can shed some light on that question.

Alexa does some wacky things with Open and Close, but I don't know if it is the ISY Skill or the Alexa logic. It also seems to do different things based on the name and/or Alexa category of the device/scene in the portal. Here are some examples (note that "Alexa, turn on ..." and "Alexa, turn off .." for these all work flawlessly): Device Name Alexa Category Backyard lights Scene - "Alexa, open back yard lights" - "Sorry, cameras don't work on this device" (no cameras in my system) - "Alexa, close back yard lights" - "Ok" and lights turn off Front Entry Lights Device/Light - "Alexa, open entry lights" - "Ok" but lights do not turn on - "Alexa, close entry lights" - "Ok" and lights turn off Pool Sheers Device/Switch - "Alexa, open pool sheers" - "Sorry, I don't know that" - "Alexa, close pool sheers" - Alexa goes bee-bum Small Garage Scene - "Alexa, open small garage" - "Sorry, I don't know that" - "Alexa, close small garage" - "Ok" and garage door closes Doesn't appear to be a lot of consistency here.

Make sure you are forgetting all devices AND scenes

Just to clarify, the implicit targeting feature doesn't allow for any duplication in device or scene names. The implicit targeting feature works on the category of items in the group, not their names. For now, it appears to work only on devices and scenes that are categorized as lights (you categorize your scenes and devices in the ISY Portal). Perhaps name your scenes specific to each bedroom, but put all of the light devices in the group with your echo, and at least a quick "lights on" will get you scene high for that room and "lights off" will turn them all off.

+1 for a scene. Just put all the swiches in there as responders (not controllers). I don't use Agave, but in Mobilinc I have more scenes on my dashboard than individual devices (switches).

Just to add my 2 cents, in order to have the program turn on or off a KPL button light, the KPL button has to be in a scene as a responder, then you have your program turn on or off the scene. If the KPL button light is already on (e.g., because the KPL button was used to trigger the program), then no harm done. Also, note that the KPL button has to be configured in "Toggle Mode" for the light to be turned on and off, I believe. So that begs the question: what will the program do. Does it make any sense for the button light to reflect the execution of the program. In other words, do you want to execute the program every time the button is pressed, or execute one program when the button is turned on but another program (or nothing) when the button is turned off.