oberkc

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.

Out of curiosity, I checked the wiki. Unfortunately, it appears out of date. Regardless, it seems to say that one must use the method I suggested. I also have a vague recollection that using the generic "start linking" process did NOT work for me. I look forward to a report from @PapaBear

Well, I was not so sure that this is the case for the MSII. I had a recollection that for this device, it needed to be done a specific way. Perhaps I am wrong about this, but it certainly does not hurt to try.

I continue to wonder if you are not doing it correctly. When I attempt to do so, the pop-up windows look differently than the ones you have. Here is how I believe it needs to be done: Choose "link Management" and navigate to Motion Sensor II, as shown below: You should get a pop-up that looks a little differently than the one you showed. The pop up is not "auto discover" but should have the device type prepopulated with the motion sensor II. Manually add your address in the top box. Choose "OK". Hopefully, it should find it.

I also recall that some have experienced communication problems when an Insteon device is protected by certain types or brands of GFCI outlets. Hopefully, that won't be the case here.

If I recall correctly, you must add some sensors a little differently. Rather than "start linking" option and pressing the set button (and hoping that the ISY can hear it), you must go to the drop-down menu and add the MSII by selecting it from the menu and manually entering the requested data.

I have understood that "matter" is in the early stages for UD and, as such, documentation and user manuals is not something we should expect. I have had some luck with matter devices over wifi, but matter devices over thread have not worked consistently for me. In fairness, the thread devices (nano leaf bulbs) I have tried also do not consistently work with echo or google, either, and am willing to consider the possibility that the problems might be with the nano leaf bulb, rather than with the EISY. I keep looking for other thread devices to try, but I don't see many around.