MWareman

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.

You need the zwave module (hardware upgrade) but yes. Works fine with Mobilinc as well.

Neither was I. I went zwave (a Trane unit). It's worked flawlessly for me.

Benoit, It's still hanging for me at the same place. So that you know, this is just Chrome on Android - nothing exotic. Michael.

Benoit, Success at attaching a debug session (didn't know you could do that!). However, there are no javascript errors... After I click 'Login' I see a 'POST' from XMLHttpRequest to /api/login containing my username and password as form data. The ISY responds simply with a '200 OK' response. Then XMLHttpRequest makes a GET to /api/domains with a basic Authorization header (my encoded username and password). I get back '304 Not Modified'. Next - the browser (from within portal.css) issues a GET to /images/refresh_white.png. Portal responds with '304 Not Modified'. Then there is a request by XMLHttpRequest to /api/isys?domain=xxxx&subaccounts=false (again with a basic authorization header with my username and password). The Portal never responds.. It just shows 'Pending'. The browser just 'spins' and the processor get's warm.. I've attached a screen image. Michael.

Apologies, I didn't get time to setup the debug session today. I'll try again tonight at home. Michael.

Benoit, What Android version are you using to test? I'm on a Nexus 9, 6.0.1. I'll setup the remote debugger when I get to the office (traveling now...) Also, a poster above reported an access issue with his iPad mini - don't know if its the same issue though. (Edit: Just tried Safari and Chrome on my iPad 9.0.2 and it worked fine in both). Michael.

The 5050 RGBWW is what I have, and I find I need to 'cool' the warm white a little with a dim blue color mix. The warm white is just too yellow otherwise. In my case though I have pulled wires down to my basement and the power brick is down there - keeps the kitchen clean. Did it the same time I tiled the back splash in my kitchen.

On 2, many do not seem to be 'initiated' by the PLM, but the collision occurs and the devices themselves see a corrupted packet that they interpret as an 'ALL-ON'. The PLM has no knowledge this occurred, even though a signal it sent was the cause. This may be why the ISY never sees it. Given that the ISY is never aware of this (according to overwelming evidence), programs will not trigger. This is good. Finally, if you are going to hook control up to the Elk, why wouldn't you hook the sensor up to Elk as well on a zone (point 6) - and benefit from the garage door triggering the Entry 2 entry delay (which can be longer that your front door entry delay). That way, anyone using the hook 'trick' (or other forced entry) to open your garage door by releasing the emergency lever will still trigger the alarm? In my case, my night arm scenes will trigger immediately, no entry delay at all.