oberkc

I believe one needs to be on the same network to use the Java interface to IoX. That question strikes me as apples and oranges, especially since you originally said you were "implementing a new ISY-994i" (and not, interestingly, a new EISY). UD Mobile is a remote android/iOS app to the ISY-994 (no longer produced), the Polisy, and the EISY. I don't believe it provides the full spectrum of capabilities available from the Java interface to the ISY/Polisy/EISY.

Can be mixed, but light will behave only based upon to which switch it is connected. Responder levels for each responder in a scene can be unique to each controller device, and to the scene, itself (basically think of it as the EISY/PLM being the controller device).

I believe I have tried this in the past, with the same lack of success, but perhaps I will try again. The use of the "basic association" nodes was in response to the post from peterathans who apparently had success using these nodes.

It is possible that I am doing things wrong, or it is possible that these particular devices don't support it. I have added four zwave devices into a scene. For each device, I have only added the nodes "Basic Scene Ctl 2" and "Basic Assoc 2". There are two of each type of node and no other nodes in this scene, for a total of four nodes. Each device is added as "controller". I believe a couple of those are zooz devices, one being an outlet, and one being a dimmer switch. Two devices are likely other brands. I could find no combination of controller device that would allow selection of a "native", including trying to link the two zooz devices natively.

I have tried, but not as hard as you. One of the things I recall may be required is that the link type must be Z-wave and that not all z-wave devices have this capability (I was able to achieve it only with one device I own...a motion sensor). I have given up on trying to make this happen. Hopefully, someone else has had better luck and can help.

I have suddenly been curious about matter and reading up on a lot of terms…border routers, edge routers, matter controllers, matter bridges, thread, mesh. I percieve, for example, that (at this point) alexa border router/controller does not automatically link to a google router, but an alexa border router can share individual matter devices with a google matter router. Thread and wifi are, of course, different. From what I have read about the ISY, my,perception is that matter (wifi) devices will iintegrate natively with IoX. Matter (thread) devices will integrate only via a nest hub (gen2j or apple home. Interestin to me is that they did not mention any thread enable routers from amazon. I am also assuming that, at this point, IoX is not exposing nodes to other matter controllers via a matter interface. For now, I am assuming that this will still require a portal account. Maybe this will change in the future. Maybe my assumptions and perceptions are all wrong.

Based upon what I have seen, matter is not ready for prime time. I would not assume that we know much about how it will work, whether thermostats are supported, or whether it will stay linked for more than a few days. (Though, in fairness, I base my skepticism on thread, specifically, rather than matter as a whole.)

Shot in the dark....unlikely, I suspect...but is it possible that you have installed the Hue "Emulator" rather than the Hue

It has been my experience that, with Insteon switches, a "control" condition will trigger a program when the expected condition (on, off, etc...) is received from (and only from) manual control of the Insteon device. "Status" conditions will trigger a program any time an Insteon device changes state, regardless of what initiates the state change. If you are seeing behavior different than this, you may be having other difficulties, such as communication between devices.

Adding to this thought, I have several z-wave switches and none would trigger programs from a "control" (switched on) condition. A few would not even trigger status conditions. I start to wonder if, in the IoX world, the control condition is unique to Insteon devices. Perhaps Lutron switches also fail to trigger programs from a control condition? I second the motion to try "status" instead.

This is what I suspect is your problem.

Yes, it appeared to sign in correctly and show "linked".

This is what happened to me, as well. I can tell you that I do not have multiple gmail accounts and have only had a single gmail account ever.

In the google home app, navigate your way (under settings, I think) to "works with google". Scroll to "universal devices". If your account is not linked, it should ask you to sign in again. I did not have to remove and add devices in the portal, but I ended up deleting non-responsive devices from the google home app and scanning for new devices. This added back the same devices, but now responsive. What I did not try, but perhaps you could if your devices remain unresponsive, would be to scan for new devices before deleting them from google home.

I am on Polisy

google home not working for me My google devices were showing as offline. When I tried to relink the "works with google" account with the portal, it showed as successful but the existing devices continued to show offline. (Perhaps I should have searched for new devices?). I unlinked the account and relinked, which appeared to be successful, but it lost all the devices and broke the related automations and I had to re-add and recreate. This appears to be working.

I would approach the problem differently. I don't think this requires anything fancy such as virtual switches or variables or such. Why not: - create a scene with button C as controller and the fan as responder. - create a program such as if status button c is on then wait 30 minutes turn of newly-created scene else nothing

I would still like to get this working, but I have continued to get stuck when, after finding my thermostat and selecting it (still no "enable future devices" option as shown in the instructions) from azure website. Because of this post, I decided to try again and, after four attempts, I received a response with user id. I was finally able to configure the nodeserver and, suddenly, mine is working. We will see for how long, but thanks for the motivation.

yes

Yes, I suspect this is a factor. I have a garage door sensor that the ISY and Polisy would sometimes become out of sync with reality (communication problem). Then during queries and other events, it would sync back up and trigger things unexpectedly. My life seemed to improve as I continued to replace more of the older (power line only) switches with dual-band. Until you have established solid communication, things can happen unexpectedly... I have trouble believing that moving back to the ISY will solve communication problems and find it hard to imagine that the EISY has some sort of programming bug that is missing from the ISY. But...I suppose anything is possible. I helped a friend install a few HomeKit items in their house. In no more than a few months, it stopped working reliably. Then it stopped working altogether. Then apple decided to remove the option of having an iPad as a home hub. Even when I could manually control devices from the HomeKit app, the scheduled automations did not work reliably, or at all. Some of the problems were solved with software updates to the various devices, but that experience made ISY problems seem simple by comparison. I liked the simplicity of the HomeKit experience, but I did not find it to be something that I would choose to rely on. Yes, like you, the reliance on the cloud is further reason I would avoid it. If I could offer any encouragement, it would be to give it a rest from time-to-time and don't wear yourself out. Life can still be good without blinds that open themselves, so a few days or weeks with manual operation is not something over which to lose sleep and, sometimes, the solutions will reveal themselves after taking a break. It sounds as if your thought process and analytical mind are strong and you will figure it out. I wish I could help more, but the inability to dig into and visualize your programs in real time is proving to be a hinderance that I am having trouble overcoming.

Unfortunately, I have not tried to keep up with all the different programs you have in play here, other than I understand that you have a lot of them and that some of them have wait statements. I remain suspicious that you have a lot of interactions among the various programs that are, ultimately, the root cause of your problems. I can tell you that I have never knowingly had a program that randomly chose to run or not to run or to stop running. Any program that I have had not work as intended was because of programming errors. If I had a program that stopped running unexpectedly, I would be checking the condition (true/false) of the last run to determine if it got interrupted by a change in status while it was running. If I had a program with a wait statement that I absolutely did not want to be interrupted, I would create a construct such as: if something happens then run second program (then path) Second program (disabled): if nothing then do something wait do something else With such a construct, the second program could never run false and could be interrupted only by the first program triggering the second program during a wait statement (at which point the second program would run again and continue until the end). Barring a failure in the ISY software, the second program would always run to the end.

This is accurate, but the trigger mechanism is slightly different. "Switched off" is triggered only by an "off" event (not by "on") and is triggered regardless of existing status, and is only triggered by someone "controlling" the actual device. "Status off" is triggered by, and only by, any change in status (off to on, on to off, dim to bright, etc...) and no matter how that change is accomplished, whether by direct control of the device, or in response to other forces such as responses to scene commands.

Unless one has ADD

One of the things I understand about the IoX and Insteon is that direct commands to devices (as opposed to scene commands) involve the command followed by some type of acknowledgement from the responding device. The command is repeated a few times if no acknowledgement is received. These types of commands tend to be more reliable, in my experience. Scene commands, on the other hand, do not have the acknowledgement and IoX simply assumes the responder device reacted accordingly. I find large scenes can be less reliable in response. I have devices that respond to queries and direct commands near 100% but respond to scene commands less reliably. I have a couple of devices at my house that are particularly prone to this problem. Communication problem? Yes. I have also found that replacing the suspect device (some of mine are probably starting to push 15 years old) usually solves the problem which makes me think that Insteon communication performance can fade over time without completely failing. Of course, the devices of the electrical system in my house have evolved over that same time and I am sure that the electrical environment (noise, attenuation) has evolved along with it. The only reason I bring this up is that I it is not uncommon at my house to find status mismatches between IoX and various devices but without showing "unable to communicate".

I think you will find that a single scene, with both as controllers, will work fine. Controllers are, by definition, also responders. Remotelincs, if I recall, have certain limitations due to being battery devices. I do not believe that they are constantly listening for signals (to save battery life) and may not respond to scene commands.