Goose66

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?

I want to make a point in this thread for future readers: While it would likely just burn out your millivolt valve, hooking the 5 volt output of the I/O Linc through the relay to the valve COULD work. However this would be VERY DANGEROUS because in these systems the fact that the pilot light heats the thermocouple to produce the electricity to open the valve is a safety feature. If you were to supply external power to open the valve when the pilot was not lit, that could release gas into the house and asphyxiate the occupants.

The two wires that went from the fireplace to the switch now go from the fireplace to the NO (normally open) and common terminals on the I/O Linc. This gives you ISY control of the fireplace.

My fireplace is controlled by a millivolt gas valve. The small flame (pilot) heats a thermocouple that produces the voltage required to operate the valve. No external power is required. I had a standard decora wall switch that simply connected to two small gauge wires to control the fireplace. I ran a 4 conductor thermostat wire (18 ga) from the switchbox to an outlet on the wall below. I use one pair of the four conductor wire to hook the NO and common on the I/O Linc to control wires to the fireplace. I replaced the switch with a Leviton decora momentary contact switch ($27) and I use the other pair of the four conductor to hook the momentary contact switch to sensor and ground on the I/O Linc. On the I/O Linc, run through the procedure to link the sensor to the relay output. In this way you have both Insteon and local switch control of the fireplace.

I would love to get confirmation from Michel on this because it would explain a lot. I just assumed that the PLM handled scenes the same way as the other Insteon devices, but it makes complete sense that would be up to the ISY and not the PLM (because it is not the same as a PLC or Insteon Hub). It would be possible, under those circumstances as well, for a program's invocation of a scene to be different from a user's invocation of the scene through the Admin Console (although I don't see that listed in Mike's comment).

And delete and re-add to the ISY with "Remove existing lincs." Make sure the plug they are in when you do the re-adding and putting them in scenes has really good communication with the ISY, and then you can move them to there final operational location afterwards. I will say I have trouble with my On/Off modules and ApplianceLincs pulled out for Christmas lights every year, and it also seems they cause problems with the other Insteon devices. I have tried to migrate them all to the latest dual-band modules, but there are still 4 or 5 legacy modules in the mix.

I have a very similar problem. I have a scene that includes a dozen or so On/Off modules that control my indoor Christmas lights. The scene also has a KPL button as a controller. A program turns the scene On and Off at 7:00 AM and 11:00 PM, respectively. Activating the scene through the ISY turns them all on or off. Using the KPL button turns them all on or off, but it seems like 1 out of 3 mornings at 7:00 am, one or two of them does not turn on. If I walk to the KPL and turn the scene off and then back on, I can get them all to come on, even if I do it at 7:02 am. Now, while I would expect the KPL button to be more reliable, there appears to be nothing about programs that would make them less reliably than other methods of turning on the scene through the ISY (Admin Console, Alexa, Mobilinc, etc.), and the fact that the program runs at 7:00 and 11:00 instead of sunset/sunrise suggests that it's not a problem with colliding with other programs. What I think it all comes down to is that Insteon communication to these On/Off modules is just not that reliable. And the mathematics of the situation makes it more noticeable in the scheduled program run because it runs every day while troubleshooting attempts such as activating the scene through the Admin Console are only done occasionally. In fact, I have precisely the same problem with another scene with outdoor ApplianceLincs that controls my outdoor Christmas lights between sunset - 30 min and 12:00 am. By comparison, my program that turns on and off my outdoor lighting scene containing all KeypadLincs at sunset and sunrise works flawlessly every night, as far as I can tell.

Thanks for the response. I'm leaning in the direction of not causing problems, so I only want to cleanup what is old, not remove something that is still integral.

Admin console. Just wanting to clean up as much as possible before going to 5.0.11A.

I have a disabled program QueryAll in my program list. It runs at 3:00 am and has Set "ISY" Query in the Then clause. It is disabled. Is this still required or is this legacy and can be deleted? I am running 5.0.10.