Goose66

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.

No convention - just the presence of the light(s) and the echo device in the group. Ensure that Boys Light does in fact appear to be a light to the Echo. In the group, it should appear with a light bulb. Sent from my iPhone using Tapatalk

I would think the REST interface would be the easiest to use, but it doesn't have two way communication like the Web Services, AFAIK. Here's where you need to start: http://www.universal-devices.com/isy-developers/

I would like to revisit this in light of the v3 Smart Home skill and node servers. What are people doing with garage doors? I have garage doors supported through a node server so adding the devices directly to Alexa is not an option. If I write a program and add them as a "Scene," it will not support "Open" or "Close" commands. If I add the program as a "Switch" it gets really wonky. For example, for a single named device, I can say "Alexa, turn on the third garage" and the door opens, and "Alexa, close the third garage" will close it. But if I add anything else with the word "garage" in the name, or I add a program to close all the garage doors, then all bets are off. I alternatively get "garage doors doesn't support that" or "you have several devices with that name" or "I don't know how to help you with that," etc. with no apparent consistency. Ultimately, all I really want is "Alexa, close the garage doors" and "Alexa, close the garage bays" to run a program that closes all the garages (for security reasons). Maybe I should be looking at routines. What has everybody else come up with?

Doors and locks are not allowed in Scenes in the Alexa service. If your Scene can contain doors or locks, then your Smart Home skill will not pass certification, so I imagine the ISY and probably SmartThings won't return scenes with doors and locks in the discovery payload to Alexa. That said, programs that actuate locks should work fine.

They were already coding, testing, and deploying the implicit targeting feature, they had to go through all the semantics on how to interpret requests when the Echo device is in a group with other devices, the Alexa clearly understands that the request is a thermostat request and there are multiple thermostats - even you can see that a single if statement to check the group for a thermostat before issuing the “You have more than one thermostat” error is all that would have been required and it would have been implemented in code they were already changing. Regardless, what’s embarrasing is that they would roll out the implicit targeting feature without considering this additional device types - especially something as ubiquitous as a thermostat. It says if you have your Echo in a Smart Home group, it can intelligently respond to your request. Do you think asking for what thermostat you mean when it is in the group with your Echo device is intelligent?

Not that it really should require any explanation, but it means so easy that it’s embarrasing that they did not include it.

I just added thermostats last night and also confirm that the "implicit targeting" does not seem to work for thermostats. That's just ridiculous - I can't imagine implementing the functionality and only making it work for "LIGHTS." It would have been embarrassingly easy to extend it to THERMOSTATS. EDIT: Alexa support is clueless on the issue. All the documentation and announcements have language that makes it sound like it should work for more types of devices than lights, but the only example given anywhere is "Alexa, turn off the lights." I will put in a feature request, but that will likely take many months.

I would be interested in switching from MobiLinc if I could get support for all my devices in one app. But that would mean rather a lengthy list of devices to accommodate me and everybody else. I suggested to Michel and Chris that a generic list of "Device Types" would be useful, that could be used, along with the nodedefs for the natively supported devices and those for the ones supported through node servers, to allow for user interface developers to develop for the the defined list of device types instead of individual devices. Device types such as: COLOR_LIGHT, DIMMER, APPLIANCE, THERMOSTAT, GARAGE_DOOR, LOCK, ALARM_ZONE, ALARM_PETITION, etc. I don't know if it will get rolled into the 5.0 architecture, but the ISY would be the right place to do the translation, keeping the UI as device agnostic as possible.

Do you see the future development continuing to be device type specific, or will you move to device type agnostic support from nodedefs once ISY 5.0.X is supported?

Nice! Sent from my iPhone using Tapatalk

I am curious what the use cases are here? Maybe no vaccuming when people in house (via geofence)?

As far as the Alexa service (Echo devices), I am not aware of any API that would allow you to send requests to the Echo to play music. Neither the Alexa Skills Kit (ASK) API or the Alexa Voice Service (AVS) API provides functionality to control playback on an Echo device by anything other than local voice control. You could put an RPi with a speaker next to the Echo and send it a network request that uses text-to-speech to request the music from the Echo. Or, you could control a third-party music player than plays music through your Echo device's Bluetooth connection.

Two for control of the fireplace valve and two for hooking a switch to the I/O Linc.

Problem with the three-way switch configuration is that the ISY or voice commands can’t turn the fireplace on or off. All you could hope for was to try both commands (on and off) and one of them would toggle the current state. With the momentary switch hooked to the sensor port, the momentary switch toggles the current state from on to off or off to on, but the ISY commands (or voice commands through the portal) will work as expected. If I have time tomorrow, I will make a video of my setup and post it. Mine is exactly like yours.

So if you look closely at the pilot light there is a thermopile in the flame. This thermopile generates a tiny bit of power that is switched on by the wall switch to the millivolt valve. There are probably other switches in the circuit as well, such as microswitch on the flue damper that prevents the fireplace from lighting when you turn on the wall switch. Instead of running 120 V to the fireplace, just run a 4 conductor 18 ga. cable from the wall switch to an outlet where you can plug in the I/O Linc. Hook up the two wires that are now connected to the switch to the Normally Open and Common terminals (no particular order) on the I/O Linc. You can also replace the switch with a momentary contact and use the other conductors in the four conductor cable to hook the momentay switch to the sensor and ground terminals (in no particular order) of the I/O Linc to retain local switch control. EDIT: So the momentary contact switch may not work because there is no setting for the I/O Linc for toggle on sensor input. My momentary switch is still sitting in the box on the shelf below the switch. I am looking into ways to use the regular on/off switch instead with the sensor inputs. Right now the on/off switch is installed parallel to the I/O Linc which means I can control the fireplace with either the switch OR the I/O Linc, but not both, e.g., I can't turn it on with the I/O Linc but turn it off with the switch.

That looks like a pilot flame to me. Very similar to my setup. What does the switch look like?