oberkc

When you ask Alexa to turn it on, is it turning on the scene, or an individual device within the scene? If the latter, this could explain one way your devices are getting out of sync.

If the problem appears global and random, I usually suspect comms problems or failing PLM. Perhaps a failing Insteon device has the ability to flood the communication paths, but I am not sure how to troubleshoot such an issue besides trial-and-error. Unfortunately, I am not much help with regards to error messages.

If turned on/off by the keypad, or by the switch/module, the keypad button would reflect this status because of the scene. Is it possible that there is a program that is turning on the switch/module, or that the switch/module is a member of another scene?

In my mind, the variable adds unnecessary complication UNLESS you are trying to track current state (I am currently at home, I am currently away) versus just tracking when one crosses the geofence boundary. Having said this, if one is trying to keep track of a presence (or any other binary-value variable) I suggest considering virtual switches, rather than a variable, to keep track of presence. Using a variable switch adds some convenience to manually changing the presence status should that become necessary (such as when the geofence doesn't fire for some reason). Clearly, though, there is some use in knowing current state of presence. For example, one might have a program to turn on some lights at sunset, but only if home.

The first thing you do is disable the program so that it does not self-initiate. The second thing you do is to add a command after the wait statement to turn the lights off. The third thing you do is change the trigger in your geofence. Tell the geofence to "run if".

Does it call for "Run If", "Run Then", or "Run Else"? Given this, the lights will come on at sunset and turn off as sunrise, regardless of any geofence activity. I do not believe that the presence of one phone inside the geofence would cause the second phone to fail triggering the enter command. Why do you have a "wait 10 minute" action at the end of the THEN clause? Next time you enter the geofence, soon check the admin console (or log) and see when this program last ran. Hopefully, there will be a record of the program running at the time you entered the geofence.

That program appears to be set up correctly to me. (The two yellow programs below it have something wrong, but this should not matter.). I would right-click on you "cleat and hearth" program, then choose "run then" to confirm that this is the program that is not working. If you follow @Geddy advice and find that turning the scene off directly from the admin panel does not work, then you might restore the affected devices. Failing that, you might consider a new communication problem that may have arisen.

Yes, hue emulator has same IP adress as EISY. It just seems likely in my mind that changing the port number will break something. I fear that my experimenting with 20 different node servers and separate hubs for hue, casetta, yolink, harmony, and others, and integration with alexa and google nest, I have this sytem that breaks any time I make a change.

Summary: What are the consequences of changing the IoX HTTP port to something other than 8080? Background: I have a renewed interest in trying to get a brilliant smart switch connected to the EISY via the Hue Emulator. I recall that the brilliant switch looks for a hue hub on port 8080, which creates some sort of conflict if the emulator port is the same as IoX. If I change IoX port to 808X and the hue emulator to 8080, what are the unintended consequences? Will the finder not be able to connect? Will the EISY-UI not work? Will I brick my system?

I must admit that I was quite disappointed to learn that the "failure" of a single z-wave device can cause such broad consequences to the other z-wave devices.

Strange. This is how I do it and it works every time.

I had a period of time when a handful of zwave devices would not respond and others would respond inconsistently. It turns out that I had a single device that had become non-responsive and this device was part of the communication path to several others (a neighbor?). Replacing the faulty z-wave device solved all the problems with my other devices. I did not expect failure of a single device to cascade into general comm problems for the remaining z-wave devices, but, there it was. Perhaps you are having a similar problem. Another thing that I failed to recognize at the time is that there is a specific "capture log" for z-wave. Start the capture log and trigger some of your troublesome devices. The log can reveal those devices that are not communicating and this may help you isolate your problem to a specific device.

I am probably not going to be able to offer much specific help, but I doubt that this is related to any particular "Insteon communication issue" as the title might suggest. Also, I suspect that the way forward will depend upon whether you are using the portal for remote access or whether you have set this up for direct access through one of your router external ports. The first thing that I would do would be to open the settings option>>controllers>>my home and see if UDMobile thinks your ISY is online.

I believe you can run UDMobile without a subscription, but requires some port forwarding and may introduce some security vulnerabilities unless you are skilled enough to avoid them. I believe you could also run it via VPN without subscription, but that may entail some other trade-offs. The subscription portal (IIRC) was originally created to provide integration with Alexa and Google Home (and still does). They incorporated easier access to UDMobile in later versions.

He did, but forgot to proofread after autocorrect. That is a good catch.