MWareman

The alexa.amazon.com webapp shows group management for me... I can create a group, add devices to it, and modify existing groups..

The device that hear you say ‘turn on the lights’ will determine which group is used (whatever you called it). The lights in that group respond. That is, unless you’ve used ‘lights’ as a spoken in your account I guess... it would likely prevent it from working.

Odd, I have a shortcut ‘good night’ that triggers just fine as a shortcut. It’s been there for a while now, used pretty much every evening to turn everything off...

Seems you simply don’t assign any spoken at all. ‘Light’ is implied, and will act on all devices in the group of type ‘light’ (ie, not scenes unless you change the type of the scene to ‘light’ in the Portal).

Can you ‘broadcast’ between multiple Google Home devices when they are authenticated with different Google accounts (but on the same WiFi)? If so, I’m going to go the multi account route - and then add my voice training to them all for calendar access...

Possible for Google Home as well? I ran into a similar issue where Home distinguishes between lights and scenes. Since most of my scenes are single or pairs of lights, I’d like to be able to have he Portal optionally report most scenes as the device type of ‘Light’. Thanks!

You probably need to ask in a forum associated with Moen, rather than this forum dedicated to the ISY Home Automation controller. Unless they offer an integration themselves, it’s unlikely that you can.

For me, ‘Hey Google, turn on the lights’ turns on all lights with any spoken assigned, rather than just the two in the room that the Google Home is in. The Home and the two lights are assigned to the same room in the Home app... I wonder if I’ve missed anything...

Link the motion sensor directly to the light, and have it send on commands only (instead of having a program respond to the on). Have your program respond to on only for the purpose of timing the on time and then turning off on the time or condition that you desire.

Sending a network notification is asynchronous. Your program could be completing before its sent. Try adding a wait before the program disables itself to allow the network send to complete.

I have 4 Google Home minis on the way, and I’m going to be messing with this. One is for my Daughters room, and I don’t want her messing with lights all over the house. So, I’ll try multi accounts and see if it can be done. However, one of the main reasons for several is the new ‘broadcast’ command. I wonder if that works based on the WiFi network, or Google account...

I also disabled v2 before linking v3. No issues like those described... so far..

This. Putting your payload into a separate program means there are no triggers that can reset the wait. So, your program will complete, unless specifically triggered again (in which case the wait will abort and the then we start again).

When you turn the scene on (first line of the ‘Then’), the state of the ‘Garage Door Switch’ likely changes, causing the wait to abort, the ‘If’ to re-evaluate and ‘Else’ to execute (with no terms).

UTC does not have daylight savings, so no arbitrary clock shift twice a year. However, you do mental gymnastics each time you look at times in the admin console.... In all reality, ISY should really use UTC internally (so it does not have to mess with any daylight savings change at all) and ‘simply’ render the time to the local timezone for display and triggering events.

Just set the timezone of the ISY to UTC and you too can benefit from no daylight savings....

The unlink and relink seemed to solve the issue for me. At least with an initial test. Thanks!

I am sure... That’s not the issue. I’ve only ever used one of the accounts in my Portal for Google interactions, and that the same account I’m logged in with.

The push update is not working at all for me. Keeps telling me to check I am linked (which I am). The 'Gome' typo also needs fixing..

I suggested changing the magnetic sensor rather than the iolinc connection (sorry if it was not clear). That’s the only way to solve the light status and not have trigger reverse on. Alternatively, drive your light scene from a program that the iolinc triggers, and leave your sensor wired to the NC connector with trigger reverse disabled.

One thing I found the other day which working thru the odd network events my recent foray into using Kibana was that the Google Home HARDCODES its DNS server to the Google DNS (8.8.8.. In doing do, it ignores any DNS process on your router. This sucks for me, as I tried locking down outbound DNS from all lan devices (there is no reason any should be using anything other than my router) and the Google Home stopped working very quickly.

It’s called ‘trigger reverse’ - not ‘sensor reverse’. It only reverses the trigger the iolinc sends - not the query. Dumb SmartLabs decision if you ask me (it’s not an ISY thing). Change the wiring to NC and remove the trigger reverse.

I still only have ‘Unlink’..

PROMs that can be erased with UV light are EPROMs (Erasable Programmable Read Only Memory) PROMs that can be erased electrically (no need for the UV light) are EEPROMs (Electrically Erasable Programmable Read Only Memory) If it was truly a PROM - they are writable only once. There is no window to erase them. Also, 6592.Cool.. I learned my first assembler programming on 6502... and for sure one of my high school electronics projects I built a switching phone system around a 6502..

The RESTful call, what do you have in the Host box for the network resource? If it is 127.0.0.1 there is a known issue that causes ISY to become very unresponsive. If this is the case, change it to the actual lan IP address... Edit: Red herring. I didn’t read properly. However, anyone that uses a network resource to call the ISY itself needs to know this issue exists.