MWareman
-
Posts
4959 -
Joined
-
Last visited
Posts posted by MWareman
-
-
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.I've given each of those buttons a spoken name (visible and verified in the ISY portal).
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.Could my "all off" program have opened the door even though the io link is not part of the program? It is set to run at 2:57am and ran 1 second before the door opened.
-
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.Not sure if this is available yet or open api for ISY control. Have to look into this more, but here is the Fibaro. What strips go with it? I would be willing to try it out.
-
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.
-
Apparently I should proceed with the approach recommended in the Link your provided. What I want to avoid is any extra verbiage such as required in the Amazon Skill Sets requiring you to say "Alexa, tell ISY to tell . . ." I did that with Echo talking to CQC and found that Alexa has trouble understanding that many additional words.
I'm using the Insteon Hub with 3 bedroom lamps and the minimal verbiage required gives me almost 100% reliability. All I have to say is "Alexia, bedroom lights 80%" and it works every time. No need for adding "turn on the". Simplicity with Echo is the key to reliability, IMO.
.
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.this is fantastic! only issue so far is I am having trouble getting it to execute my programs that will arm my elk m1 into "stay" or "away" mode. what is the trick?
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 also use Tasker and Pushover app for android. When I have a motion sensor turn on, it sends an email to pushover then tasker recognizes the message "motion" from pushover then tasker plays an mp3 of the motion tracker on the movie aliens. I have the same idea for doors and when there is water in the basement it plays a sonar ping. This happens within 2 seconds of the sensor being activated.
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.Is the zwave compatible with the ISY? How about Mobilinc?
Sent from my iPad using Tapatalk
-
I'm not too thrilled with the INSTEON 2441TH.
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,
I tested with an Android 5.x (I don't have it with me at the moment, I believe it was 5.3.1). I have seen report of problems with version 5.0.1 up to 6.0.1) in this thread.
Benoit.
Michael.
-
Benoit,Hello,
I'm trying to reproduce the problem, without much success.
I'm trying on Android native browser, chrome on android, chrome on ios, safari on iOS. All worked.
I need help reproducing the problem. I think there must be a javascript error on the browser console.
Can someone with the problem try the following:
- Connect a mobile device to the PC using a USB cable
- Start chrome on the mobile device
- On the PC, start chrome as well, and go to: chrome://inspect (this will start the remote debugger)
- Still on the PC, when connected to the mobile device, go to the console tab.
- On the mobile device, go to my.isy.login, and login
- Assuming you still have the problem, please look at console (on the PC), and please PM me a screen shot of the error(s).
Thanks,
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.I saw these too which could work for some just not sure the power brick will fit for my needs, looks too big.
http://www.ebay.com/ulk/itm/262226150854
Supernight RGBW RGBWW LED Strip Lighting Kit 5M 5050 300leds Non-waterproof
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.Ok, let me try to recap:
1. All-On events don't seem to "involve" the ISY, meaning that programs and scenes are not triggered by an All On event.
2. All-On events seem to be confined to Insteon devices, and may involve the PLM in sending an All-On signal to all devices. (I have replaced my failing PLM and have not yet had any more All-On events).
3. Therefore, an Insteon action triggered (exclusively) by a scene or program should not be triggered by an All-On event.
4. To insulate a garage door from All-On risk, remove the IO Linc as a garage door controller. If there is no Insteon device to trigger the door, it should be safe.
5. Instead, use an output on the Elk board (output 3 directly or any other output triggering an external Elk 912 relay board), to open or close the door. This would be wired to the same device as was the IO Linc (in my case, a wireless remote door opener).
6. Use any sensor, including an IO Linc-connected sensor, to sense whether the door is open or closed. (The ISY can be used to sense the door state, just not to control it).
7. The Elk output can be triggered by any ISY scene or program, without any risk of getting triggered by an All-On event.
Please let me know if there are any corrections/revisions to this.
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.
Garage door opened at 2:57am by itself! Help
in ISY994
Posted
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.