MWareman

Your ISY would need the zwave add on module - but once you have that you can directly add zwave devices to ISY.

Why not connect the zwave contact switch to the ISY - then you could implement the logic....

I have a Ring - but to integrate with ISY I have the Ring driving a DPDT Relay - with one pole of the relay driving the old school doorbell and the second pole of the relay driving a non alarm zone on my Elk. This keeps the ISY integration fully local and was pretty easy to wire up.

Well, since Elk is able to be integrated it makes some kind of sense to do this. I’m just not sure how wise integrating a security device with voice command is....

If it’s the newer zwave module, then you cannot run v4 on the ISY.

The other thing to look for is a little ‘leaf’ symbol on the screen. That means the stat is in set back mode. I gave up on mine after SmartHome replaced it twice because it randomly went into that mode.... and moved to a zwave stat. It’s been stable since.

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!