oberkc

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.

I am getting a high number of unexpected device activations as well. I can find no programs running at the time of the a uncommanded actions. As near as I can tell, all the unexpected device activations are Instagram Insteon. I don't think any types of devices are affected. I see nothing in the log to suggest any command is causing this. I think I have also ruled out the possibility that it is related to scenes. I have also reset many of the offending devices. My current working theory is that it has something to do with motion sensors or combinations thereof. We have a lot of unusual activity due to some visiting cats. They are triggering a lot of motion sensor detects. I am going to see whether their departure in a couple of days reduces the number of light triggers.

I am on EISY. I was not even sure it would run on Polisy.

Yes, the EISY UI shows current software versions and, apparently, any updates that are available. Interestingly, it shows me on 6.03_3 with no mention of 6.04_x.

And mine shows neither EISY or IoX: At one point, I had two entries for my single system, but something changed along the way (possibly a "package" update) and it is now a single line.

They can be "linked" without the ISY, but "programs" are part of the EISY. It is possible that a device had pre-existing links? Yes. Is it possible that a device had a pre-existing program? No. The process of adding a device to the EISY can remove existing links (an option that one must choose when doing so). Alternatively, factory resetting a device before adding to the EISY would remove existing links.

I believe, unfortunately, the latter. I believe the process of removing them from EISY removes them from programs. Hopefully, I am wrong.

Yes. "ON" levels can be set to zero. That is, when a controller device is telling a responder device to turn ON, and the responder's ON level is zero, the result is that the responder device turns off when the controller device sends an ON command.

Yes, I get similar windows from time to time. I am not sure why these windows have recently started happening, but I assume it is related to some software update. I also see old devices, scenes, and programs that reappear though I thought I had deleted them. While a nuisance, they go away eventually. Often, a reboot of EISY clears up many of these notices.

I have had the Govee outdoor lights installed and has been working with EISY via matter (wifi) for several months. A couple days ago, they stopped working. After desperate attempts at "synchronizing" the network, I have deleted them from the EISY and factory reset the Govee lights. I tried re-adding them back to EISY and it fails. I then tried adding the Govee lights to google home via matter and it worked. I successfully shared them from google with Alexa. When I try to share them from google to EISY, the process appears to get hung up. When I try to share them from Alexa, the process appears to hang up. These particular Govee lights do not seem to sync via the Govee plug-in. As near as I can tell, matter is the only way to control them from the EISY. Has anyone else had this or similar experience? Thoughts?

"Also"? Besides motion sensor, what other type did you try? IIRC, variable MUST be set as a sensor for this to trigger an Alexa routine. I think my variables are all imported to Alexa as motion sensors and they trigger routines quite well. I don't recall if it is critical, but I use values of 0 and 1. You might try this to see if it solves your problem.

UD Mobile has a geofencing capability and can trigger a device or variable when entering/exiting the geofence. This, in turn, can be used to make an announcement from Alexa/Google if you have the portal subscription. I suspect this is the easiest approach. Tasker, on android phones, can also create a geofence and I suspect can trigger an action on EISY. (Mobilinc used to have a tasker plugin, but I assume this has quit working with the latest incarnations of IoX.) There are probably other options.

My mind did not necessarily perceive any logical dissonance, but I suppose that I could find some if I looked hard enough. The inconsistency, in my mind, were I to seek it out, would be that controlling a physical switch from the admin console or via UD Mobile does NOT trigger control conditions, but similarly controlling a virtual switch DOES. Even if true, it does not logically bother me that the control signal is triggered by contacts versus status being driven some other part of the switch. To me, it is just a case of understanding how things work and exploiting capabilities for my benefit. For me, the virtual switch offers a valuable ability to add it to the UDMobile and mimic a physical switch, including status indications and triggering programs. (I also like the virtual switch in place of variables when used for simple binary logic conditions.) Without the virtual switch, one had to go through a bit more cumbersome approach to turning on and displaying scene status. No more trying to figure out when a scene is ON or OFF by use of some percentage or using a canary device within the scene. I would, in fact, be disappointed if the virtual devices did not trigger control conditions or behave like physical devices as scene controllers.

This is not the case at my house. I have programs that are triggered by switched (control) conditions of virtual switches.

Normally, a program having a "status = xxx" is triggered when there is a change in status for that device.

Thanks for the update. I have certainly had my share of tickets, but never had I needed to hook up a monitor and keyboard. I am glad it is working for you.

How do you "check" the EISY? Are you able to log into the admin console? If so, I would be very tempted to reboot it from there. Otherwise, I tend to look for clues (or at least data points). Is the EISY connected to the network? Do I know the IP address? Can the IoX Launcher find it? Can I reach it from UDMobile or from a browser (requires v6.0). I know one can also attempt to log in from a computer terminal app, but I don't do this often enough to remember how to do this. In the end, however, it is a computer. If I run across computers in any form that seem to be stuck in some perpetually unusable state, I reboot them. I believe that this can be done from the button on the front, but I am usually too lazy to look up how to to this with the button, so I simply unplug it, wait a few seconds, and plug it back in.

From the google home app, find the matter device you want to share with another matter hub, such at the EISY. Once found, open the device settings (little gear on top right). In the settings, you should find "Linked Matter apps & services". Select that option and you should find another list, including "Link apps & services", in blue font. Select that and you should see a pairing code.

This has become my favorite approach for when I want to control a scene from UDMobile or the admin panel...create a virtual switch, include it in the scene as controller, then use the virtual switch in UDMobile. It acts as an indicator for the scene status, and can trigger programs when they are part of the condition. I expect that approach would work great here, but the virtual switch would have to be included as a fourth line in your program condition.

What does it mean when all my hue nodes have the little green "write pending" icon? There is no option to "write updates to devices" that one can find with most other nodes. The nodes otherwise seem to respond as normal. I have restarted the plugin (v1.07). Is this a problem? What action should I take in response?

I would consider the possibility that it is not the lock, itself, that is the root cause of your problems. I use one of the Schlage BE469 with zmatter dongle and it works quite well for me. Barring a faulty lock, I believe it is unlikely that your problems are due to some inherent incompatibility between the lock and EISY/Zmatter. I recently experienced some "flaky" zwave performance with some outlets and blinds. With much help from UD I isolated it to one failing zwave device that was causing the communication between other zwave devices to fail. Zwave appears to create communication path between the hub and each device, with specific devices acting as repeaters along that path. When one of those devices along the path fail, communication between the hub and other zwave devices for which the failed device is part of the communication path will also fail. Perhaps, in your case, the communication between the hub (EISY) and lock is compromised for some reason. Range? Other zwave devices? Batteries? I also became a little more comfortable with the function of network healing, neighbors, and the zwave log. You might experiment with watching the log while you exercise the lock from the EISY. Watch for errors to see if there are potential clues. You might try updating the neighbors or rewriting the device links to the lock. Of course, there are no guarantees that this will work, but it might provide some insight into why you are having some problems.