MWareman

Not as far as I know with IOS. Just another reason I prefer Android/Tasker/Autoremote and Autonotification. There is no equivalent feature available under IOS due to the Apple AppStore policies. If you use ISY Portal you could create ‘IFTTT’ rules (these provide inbound webhooks that can be configured to trigger actions on ISY) - and this means it’s a long security token instead of a username and password. Better, but still not perfect.

If you have ISY Portal, look at the IFTTT connectivity. It allows you to create tokenized inbound URLs that map to ISY actions (running programs, turning devices and scenes on and off etc...)

The benefit of the zwave route is if you use Google Home. You can set colors via voice control and the Home app now. No need for network rules for everything. I have both now, but new installs are going zwave.

True. Didn’t actually do the math...

Don’t think you can get them yet. Also, how cheap is ‘cheap’. I want some...

Shows 40 years ago for me....

I have a MyQ as well. However, I’ve not done the Polyglot solution as it won’t work if the Internet is down (cloud dependent). In my case I got an extra remote and wired an Elk output across the push button on the remote. I have an Elk zone on a mag switch on the door and a zwave tilt switch on the back of the door for additional status. I’m not comfortable with Insteon for controlling the garage door - but you could easily wire an iolinc in place of the Elk if you are ok with the lack of security in the Insteon protocol.

Hopefully, the ISY Portal will support this... I wonder what the spokens will be to change the color... https://www.gsmarena.com/google_home_app_teardown_reveals_color_control_for_smart_lights-news-35713.php

You can easily reset the Ring devices - but you do need to be local to them (and in the case of the doorbell need the somewhat special screwdriver to take the security screw out to reach the reset button). Then, you simp,y set the device up as new in a new account. You will have to pay again for the cloud plan if you were using that before though.. as that’s associated to the account.

With Motion sensors, you configure it to only send ‘On’ commands. Then, you put the motion sensor in the scene as a scene controller. That way - the ‘On’ is triggered immediately (no ISY delay). On the ISY, you have a program that triggers from the ‘On’ - then ‘Then’ starts a wait (for however long you want the light to stay on) then sends an ‘Of’ to the light. The advantage is that each time motion triggers it - the timer is reset. If the door sensor does not support ‘On’ only mode, then you are stuck with the fully programmed approach (with the inherent delay that introduces).

Looks like you’ve got to reset that key. You need to keep that random looking bit secret - otherwise anyone will be able to trigger your devices!

[runs off to check] Nope. Cannot see this in my portal account. Is it possible to share a screenshot? Edit: Ahh, you mean under the Alexa spokens config. I’d hazard a guess that it enables you to expose network rules and such to Alexa as an audio device (think asking a network addressable receiver to adjust its volume). I don’t use Alexa, so not sure.

The icons are chosen by Google based on the device type selected in ISY Portal.

No. Spokens are set in the portal itself, along with the room the device is in. The rooms are synced with Google Home - so if you have multiple Google Home devices around your house they can be room aware. Spokens do not need ‘light’ after them - but it can be spoken regardless. Programs can be represented to Google as a light, switch, scene or outlet (changing the icon). On runs ‘Then’ and Off runs ‘Else’.

I wouldn’t be surprised if the api traffic was both TLS encrypted, and has its certificate pinned. Making sniffing payloads impossible.

The reason I used to get this is I had only added ISY Scenes to my Home. The issue here is scenes do not generate status events. Without the ISY Portal pinging Googles servers with status updates for devices on a fairly regular basis the authentication credential expires. Then, when Google tries to execute a command you get the unavailable message (and have to disconnect and reconnect the portal). Best solution to that (if that’s the issue here) is to directly add some devices that will cause status to be sent on a regular basis. In m6 case, I stopped using scenes and started assigning spokens to the master Insteon device (load controlling) and then wrote programs on ISY to keep secondary devices in sync.

That makes sense. I think the Google Assistant fundamentally ignores any ‘light’ in any spoken, and matches on what’s left. I’ve gone thru and taken them all out with no noticeable change. I just call the fan light in my family room the ‘overhead’ light.... whatever feels most natural. Of course, multiple spokens can be registered if our better halves disagree with what we feel is the most natural word..

In my experience, It will also run ‘Then’ or ‘Else’ if you refresh the device status (or when the 3am update all is run) - based on its status.

I generally don’t include ‘light’ in the spoken field. It’s not necessary. You can omit saying it and Google knows what to do as the device is known as a light already. Or you can say it and Google will look for a ‘light’ device matching the spoken. Seems to work very well. I’ve started removing the room names from spokens now - or at least adding secondary spokens without the room. This also is no longer necessary. You can still specify the room the voice command is directed to via any Google Home. For example, I have the primary spoken as ‘kitchen overhead’ and a secondary spoken as ‘overhead’. That way, when Google announces what it’s doing it says ‘kitchen overhead’, but I can ask for ‘overhead’ (if near the Kitchen Smart Display), ‘kitchen overhead’ or ‘kitchen overhead light’ via any Google Home in the house. If I ask for the ‘kitchen lights’ then both the overhead and island lights in the kitchen respond - which makes sense since both are ‘light’ devices assigned to the ‘kitchen’ room. Hope all that makes sense!

“Hey Google, Turn on the overhead light in the kitchen and family room” “OK, turning on two lights” And indeed, the correct two lights came on.... Got to love how Google Assistant can chain commands. I tested “Turn on the kitchen and family room overhead lights” - and it got that right as well..... Standing in my family room (regular Google Home)... “Hey Google, turn off the overhead light” - and off it goes. Kitchen stays on. Move to my kitchen (an LG Smart Display)... “Hey Google, turn off the overhead light” - and off it goes. This is fantastic. I now don’t need convoluted spokens and the whole system becomes far more intuitive. Thanks again for the fast feature!

It works! Thank you so much...

There can be only one.... When you added the ISY Portal, you likely clicked past the screen that said it would disable MobiLinc Connect. As Wes said - UDI Sales can get you sorted out and switch you back (this will disable the ISY Portal). You will have to decide which to keep.

Maybe you have the ‘Reverse Trigger’ setting enabled on the iolinc? This only reverses the trigger sent when the sensor changes state, but not a query. So if you have something that queries your iolinc later the status could flip without the door being operated.

Thank you! Awesome as always...

You are correct. Thanks. Thats what I get for putting this together between other work..