MWareman

I think querying the relay should be fine. It's querying the sensor that could trigger any program looking for 'status' and cause unexpected results. Separate the sensor and relay - make sure that they are not in the same scene. Change your query to only query the relay - not the relay and sensor. Michael.

Connected Home is still beta. The skill is released. I'm sure instructions for the connected home will be published outside of the beta thread once it's no longer beta.

Thread about adding the Alexa Connected Home (beta) to your Alexa Portal, to allow ISY control (apparently its currently limited to the first 450 users).. http://forum.universal-devices.com/index.php?/topic/17861-Amazon-Echo---Connected-Home-Feature-(Beta)!

Something caused the status of the IOLinc sensor to get updated though. Perhaps before the posted log. Perhaps an event not logged. If not the 'All On Off' program, what? It's not in the log. Something did it though. Either way, putting the IOLinc sensor as a controller of a scene that the IOLinc really is a responder to will likely cause uncommanded openings at some point when you use the IOLinc as a garage door controller. (If this is indeed the case)

AFAIK - preserve simply does not remove them. ISY does not learn existing links in this situation. A scene with two devices actually contains three devices (the two and the PLM) and three links (not one). Each device in a scene has a link to and from each other device in a scene (including the PLM). If you cross-linked them and then added them individually to ISY, the ISY will not know of the pre-existing link directly between the two Switches - and will probably remove it when you save the device - effectively breaking the link between them. Some people use 'preserve' when adding ISY to another pre-existing controller and trying to use multiple controllers to control common devices. I wouldn't recommend that at all - its fraught with danger!

I'm with oberkc - if the IOLinc sensor is in the same scene (as a controller) with the relay (as a responder), then I think we've found the cause. A missed 'close' signal may trigger the relay when the 'Query All' reaches the device, and the sensor changes to the corrected state. This would also explain why you are not able to reproduce it.

Do you use the Mobilinc Portal service (called 'Mobilinc Connect')? It's purchased as a subscription within the Mobilinc app. If not, you won't lose anything by adding the ISY portal and hooking it up to Alexa. You can keep using the Mobilinc application directly to ISY just fine, but you may have faster SSL response times by reconfiguring the Mobilinc app to use the ISY Portal instead of the direct connection. If you do use 'Mobilinc Connect' with the Mobilinc app, then it will stop working when you change to the ISY Portal - since only one Portal can be active on an ISY. You'll have to reconfigure the Mobilinc app to use a new URL - and if you use IOS there are some Mobilinc IOS-only features you will lose (like push notifications). If on Android - there are no features lost by switching to ISY Portal. No other features are impacted - like XBMC integration thru the network module. That will keep on working.

It sounds like you directly cross-linked the switches. This isn't necessary when you have an ISY, and actually causes the ISY to be unaware of the situation. The correct approach is to create a scene in ISY and add both SwitchLinc dimmers as 'controllers' (not 'responders') of the scene. The ISY will then create the necessary links for everything to work as you want. That way - they will both track each others dim level, and the correct dim level will be represented in ISY. You may want to 'restore' the devices in the ISY Console first though to remove the errant direct cross-linking (if that's what you did). Michael.

You could try splitting apart the times of the 3am query and the 2:57 program - put an hour between them so you can identify which is causing it next time it happens. Maybe change the query to 4am. I suspect some device in your 2:57 program has another program triggering on status change of one of the member devices (which your 2:57am program will trigger), and the opening time will likely stay with the program rather than move with the query. Other than 'All On', I've never seen any reports of iolincs spontaneously operating. Even though I am NOT a proponent of using an iolinc for garage door control, I strongly suspect there is a logic error somewhere buried in the programs that is/was the root cause. It's not going to be easy to identify without being able to reproduce it.

You'll have to open the Admin Console, open up the log and select level 3, then leave the Console open while you reproduce the issue. It's pretty verbose - but that's what is needed. Capture the event then filter it for the timeframe before posting it. We're you able to reproduce the issue with manually running the scene and/or program you suspect?

The Insteon protocol does not allow for KPL buttons to be directly controlled (other than button A - the load), so there are no valid commands for Alexa to execute. You need to assign the spoken name to your scenes that the buttons control instead.

From the log, it certainly looks like something in the 'all off' program opened the door - and the sensor sent a status update after the door opened - all before the 'query all' ran. However, a level 3 log of the incident would have revealed more detail.

If you manually run the 'Query All' - does your door open? If so - capture and post a level 3 log of the event. If not, then its probably not the query doing it.

This is a multi channel device - it doesn't work yet with ISY. I know, because I have one awaiting installation.

Other than trigger reverse and an odd program there really is nothing electrically that could operate the door other than a failing IOLinc or bad GDO itself. What makes you think it was ISY that commanded the opening? Unless someone nearby managed to send a wireless Insteon signal that opened the door. It's not impossible because there is no security in the Insteon protocol.

Fundamentally, if you have 'Trigger Reverse' set on, a query will always cause the sensor to reverse state - potentially causing havoc with any programs that trigger on a door state change. 'Trigger Reverse' only reverses the on/off triggers - it does not reverse the state when queried. Let's say I have a program that triggers when the door opens, and closes the door after 30 mins. With trigger reverse enabled, at 3am (or whenever the query runs) the status will change to 'open' even though the door is still closed. The program will trigger and 30 mins later a 'close' signal will be sent - but this will actually open the door. Now a real 'open' trigger is sent, restarting the program and 30 minutes later the door will close. Best practice is to never use trigger reverse. If you need to reverse the input state on an IOLinc, change out the door sensor for a 3 wire one and wire it show it shows the correct state without having to use trigger reverse. Then when the query runs, there will be no state change.

ISY Portal has both a 'skill' ("Tell Izzy to...") and a 'Connected Home' ("Alexa, bedroom lights 80%") feature thru the portal (in beta currently). No need for Smart things to get that level of integration. The connected home method is far better than the skill for control of lighting and programs.

Create a program to arm your Elk (in the 'Then' branch, nothing in the 'If' - program can be disabled to prevent inadvertantly triggering), and give it a spoken name on the portal. Ask Alexa to turn 'on' the program, and 'Then' will execute, arming your alarm. I do this with my 'goodnight' program - it works every night. Michael.

The 3am query is there to resync what ISY thinks is the level of devices in case it missed a scene message. You can also do a resync on boot, but 3am is considered a time when there is not much activity to interfere. The only issue I've heard of before is an errant garage door notification (usually caused by trigger reverse being on), never heard of the door opening - unless you have a program somehow tied to the sensor - and have trigger reverse enabled.

I really would caution against assigning a spoken name to a lock. Someone outside the door could tell at Alexa and have the door opened for them. Same for a garage door opener.

2 seconds for email activation is pretty impressive. When I tried email the delay was more like 5-8 seconds. I'm now using the network module and using the Pushover API (for human targeted notifications) and Autoremote (for Tasker parsed notifications). Both result in delivery times less than 1 second generally.

There is also the SOAP API, which has create and delete support of most objects I believe. No networking module needed just like the REST API.

I use my Android phone with Tasker, and ISY's networking module to send Autoremote messages. One example is when my doorbell is pushed, it sends a doorbell event to my phone with plays a doorbell sound (thru the phones Alarm audio channel so it makes the sound even in quiet mode). Another, when the garage door is left open ISY sends a door left open trigger, and the phone (via Tasker) uses text to speech to announce that the door was left open. It's very flexible - and works well for me.

It just shows up, just like an Insteon thermostat. There really is no config required in Mobilinc.

This is the thermostat I have : http://www.amazon.com/Trane-TZEMT400BB3-Remote-Management-Thermostat/dp/B0052MHPP4 If you need the hardware zwave module for the ISY, its available as an option from UDI (https://www.universal-devices.com/sales/) as the 'Z-Wave Assembly Kit'. Michael.