oberkc

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.

When SmartHome shut down, and before selling the Insteon business, the hubs became inoperative because the cloud servers were shut down. I recall the reaction from so many that had Insteon hubs and I doubt they would ever again go back. I would consider this a major downside to relying on the Insteon hub and would not do it. Refresh my memory: is there an annual fee to use the hub?

I, too, have assumed that motor noise is a problem. I am also becoming convinced that insteon devices fail gracefully…as they get old, they dont fail copletely, but communication performance is not as robust as when new. It probably does not help that I plugged the opener into the same outlet as the I/O linc. I am midway through the process of moving the IOLincs to another circuit and to new IOLincs. I have also feplaced a couple of older switches with dual band, thinking it might imrpove the comm environment.

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.

True, but I was just responding to your statement that you did not have the secret decoder ring. I tend to ascribe this problem to the load attached to the Insteon device. When off: interference. When on: interference. If possible, temporarily disconnect the load (unscrew the light bulb?) and see if the Insteon devices can now be turned on AND off. I wonder if the program changes were not initially saved.