MWareman

I caught my Alexa talking to my Google Home last night as well...

I've been running a second ISY with a handful of Insteon and Zwave devices for about a year now - mainly for testing alphas. My two ISYs talk to each other via the network modules, and Fe not had any issues at all.

They are all pre-beta and not feature complete or stable.... Yet. Plenty of brave souls are running it, I choose to keep it to a secondary non-production ISY until it's more stable.

I believe locks are blacklisted by Amazon. You may need to do this with a program instead.

Kumoapps run in the cloud, but actions taken can be made from the tag manager, or from the cloud per your choice. So, it's hybrid.

The Kumoapp example I posted a while ago sends the data from the tag manager to the ISY internal to the network (as long as the tag manager and ISY are on the same network). This does not need a port forward at all, nor does it require the network module or any portal.

Where did you by the 99i from? It's many years past (official) sales stopping.... I *really* wish people would stop reselling them.

That's a different issue. You need to turn off 'Trigger Reverse' on your iolinc. That's what causes this when the 3am query all runs.

4-5 a seconds seems a long time I agree. 1-2 is more usual in my setup when triggering a program to perform an action. One thing to try. Put 'Switch 2' in a scene and have the program turn the scene on. Scenes don't ACK requests unlike direct device control. This may make things faster. Down side is if you have a less than reliable Insteon network it may get missed, but it's worth a try. Main possibility is you Insteon network may just be very busy. Maybe the request out to the light is queued, causing it to get delayed. Have you assessed how busy the communication is? (The log will help here...). Maybe you have a loop somewhere...

After the commands you want to loop, put a 'Repeat 1 time' command. Commands after that won't repeat.

It should do, yes. As mentioned, the original one should also work if disabled. That prevents the If condition causing a cancel and reevaluate while the wait is processing.

I think that the 'lock' spoken may be blacklisted in Alexa.... Don't know for sure though...

Maybe, but probably not. When the temp changes to 99, else will run, turn on the heater and begin the wait. When the temp hits 100, the wait will cancel, the if reevaluate and the else will restart. This will continue until the temp hits 103, when a 5 min wait will start. When 104 hits, the wait will cancel, and the then restart. Etc.... You'll have very hot water!

I think the only option is a second ISY to go with the second PLM, and integrate the two via the networking module on each.

I pull down the admin.jnlp, rename it to admin-4.5.4.jnlp (or whatever version we are at) and put it in a directory with all the other versions. Then I can run whatever version I need to, without worrying about the cache by double-clicking on the desired version. It's been very beneficial while using multiple ISYs at different firmware levels.

Or sync them. Some people use the local spoken field for their connection to Alexa using one of the hub emulators out there.... (Caveat, I'm not one of them!)

You have several options, and your mobile platform plays a part.... You can configure Mobilinc to communicate directly to the ISY - and that does not change with any Portal choice. So, configure your Wife's phone to do this, and Alexa away..... You can also configure Mobilinc to communicate with the ISY Portal service, though you'll need two profiles in Mobilinc. It's a little fussy, because Mobilinc does not natively support ISY Portal, but it works. If on Android, you can switch from Mobilinc to Agave, which has full support for ISY Portal. Easily the cleanest option. You could accept the limitation of a Mobilinc Connect subscription, which has limited Alexa integration (via a skill rather than a connected home integration)

You have to remove the device from any subfolders before the option will appear.

I've had pfSense hold on to old state records when the external IP changes. Very frustrating. I've been away from it for a while and just recently switched back. Hopefully that little bug is squashed in the newest builds... If it happens again, try flushing the state table to see if that helps....

Nope. Not possible. Java apps wouldn't run in an enterprise environment where the users are not administrators if that were the case.

I believe it's documented somewhere.... You need multiple Amazon accounts with each Dot or Echo assigned to their own. Then, subaccounts in ISY Portal, with distinct device assignments and spokens.

Checking that box is why you are getting the User Account Control popup. Try unchecking it.

Why not tell you to ignore? That setting is about having upnp auto-enable port forwarding. It has nothing to do with hooking ISY up to the Portal. I won't tell you to ignore the message, but I will tell you this menu option and the message you are getting have nothing to do with the problem you are having connecting ISY to the portal. Most problems getting ISY to connect are either DNS related, or SSL cipher strength related. Please post the error log and I'm sure something can be gleaned from it to assist.

...and in Powershell.... $isy_user = "ISY Username" $isy_password = "ISY Password" $url = "http://ISYIP:ISYPort/rest/vars/set/2/72/9" $authVal = "Basic " + [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($isy_user + ":" + $isy_password)) $response = Invoke-WebRequest -Uri $url -Headers @{"AUTHORIZATION"=$authVal} $response.Content

That's the expected behaviour. ISY is an event driven system. Any change in the triggering conditions causes the program to abort running an reevaluate (starting again in your case). You need two programs, as described above.