oberkc

I have had some luck adding zwave devices when close to the ISY, then moving to the final location. Many of my zwave devices have additional nodes for which I have no known use. I think some can be used to build zwave scenes, but have never had much luck with this. I suggest ignoring them if you can otherwise make your device function as desired.

This is how I do it. despite the warnings, I actually like the mutually exclusive option with keypad buttons. One has to recognize, however, the limitations. It only works if you manually press the affected buttons physically. The relationship is not enforced when you change the state of those buttons via the ISY.

I am not near my system, but recall the mutually exclusive feature to be found from the admin console, selecting the keypad and, along the bottom of the main window, you should find an “option” button (or similar) where ome can configure which butons are part of the mutual exclusive relationship.

One could use the mutually exclusive option built into every keypadlinc but this works only when manually pressing the respective button. It does not work if the buttons are controlled via program or scene or direct commands from the ISY. A scene might be more effective, where one would set up one button as a sea controller, and the other button as a scene responder, having an ON level of zero, or off. EVEN THIS METHOD MIGHT HAVE USED CASES WHERE ONE OF THE BUTTONS IS TURNED ON INDIRECTLY, where the SCENE RELATIONSHIP WOULD NOT BE ENFORCED. A third option would be using a program or programs such as if One button is on Then Turn the other button off A program such as this might be effective in the most number of situations. The approach you take would depend on how you expect to use each of the two keypad buttons.

Thank you all for the references. I have forgotten, or did not realize, that there was a difference between having a portal account and having an active subscription. Ultimately, I feel extremely comitted to the “ISY” system and it is quite imbedded into my house. Though I have every reason and hope in the continued viability of universal devices, I very much want to avoid having to suddenly remove this system should any external resource such as portal accounts (active or otherwise) become disabled or eliminated for any reason, rendering my sytem inoperative.

Thanks for the pointers. That gives me some relief. I am still stuck with the perception that a portal account is required, however. If one does not have a portal account, does the system not work? If one has a portal account but later chooses to cancel it, does the system quit working?

I have been watching, with interest, the discussion on the newest software and UI. I understand that one must use the portal account credentials to login. Is this suggesting that a portal account is now required to use an EISY? Does this suggest that the newest version of iox requires an Internet connection to work ? Am I correct in my understanding that the old Java interface is still available and, if so, is that the only way to access the EISY locally?

I am in the same situation. I assume I must order the EISY and zwave eclosure (planning to move my old zwave board to the new EISY. I did not see the “migrate to zmatter” option. (I guess the reason is that I am not using the zooz dongle, but it makes me concerned that the instructions are not updated or complete.). I must admit that similar transitions in the past did not go smoothly for me and my ambition for future upgrades is waning. Are there any other particular tricks or pitfalls that I should be watching out for?

I still experience an occasional fall on event. I have never spent a lot of time trying to isolate the source but suspect it is associated with one of a few motion or door sensors that I have. Yes, they affect IO lincs connected to garage doors.

The only isnsteon benefit to migrating is the use of the newest (i3?) devices. I understand that the ISY does not support them. I also vaguely recall that the price for the portal subscription is higher, should you use it and that tech support from UD is discontinued for ISY. I do not recall any other immediate benefit to insteon-only users.

Unplug it and plug it back in? I would have to look it up, but I think one can also reboot using a button on the front.

UD has responded to my ticket and provided instructions for modifying some settings that might help with matter and thread on Polisy. The problem apparently has something to do with the way Polisy handles IPV6 addresses. It does involve logging in under a terminal window and sending a series of commands. Given my lack of urgency and the risk of messing something up and causing a bunch of work that I would rather avoid, I will probably not be in any hurry to try it. I will probably wait until I have a rainy or cold day with nothing else to do before proceeding further. Besides, I have a higher priority to see if I can get the YoLink local hub to work. Sorry that I will not be able soon to confirm whether this works.

Will do, if I choose to do so. Based on the response to my ticket, there are "other issues" that may arise if I make the change necessary to make matter work. I will keep you informed.

I just tried it again. UD Mobile has been trying to setup matter device and telling me "that this may take a few minutes." It is now 15 minutes and no sign of ending. No error code. Yes, I am on Polisy. I will open a ticket.

I understand that a Thread Border router is required and I have tried all this. I have a border router in the form of an echo hub and a google hub 2nd generation. My trial device was a nano leaf bulb over thread. I have an android phone, an iPad, and access to an iPhone, all with UDMobile and google home and the Alexa app. I can add the leaf bulb to the echo hub and share it to the google hub and vice versa. At the time, UD mobile required a QR code to add matter devices. (Perhaps this has changed recently?). I forget which hub and which version of the hub app allowed the sharing via QR code, but one did. I tried adding it via UD mobile, and had no success. I stopped trying. I thought I kept up with the latest software versions for IOX and UDMobile. Maybe there are newer versions out now. I have been waiting for the bugs to surface and be corrected before spending any more time on this.

I understand that the UAID and SECRET_KEY in the node server configuration page will be the same as with the old hub. How does one "fill in" the config page withe the local net ID and access token?

I see both YoLinkTest and TSTYolinkLocal.

I have had different experience with nanoleaf bulbs, unfortunately. Fair point. I would assume that this is the same as wifi and would expect it to work.

As I understand, matter devices can communicate via two options: wifi, or a "thread" network. The thread network was developed as part of the matter ecosystem, I believe, and requires a thread border router in order to complete the system. If a particular matter device connects via wifi, then I expect you would be able to add this device to your ISY, though there may not be full functionality. If a particular matter device communicates via the thread network, then I expect that you will have little success trying to add the device to your ISY.

My experience is that one can use matter over wifi, but matter over thread is not ready yet.

So, does one simply add the new hub to the account and replace the existing credentials and secret key in the node server with a new one from the app once the new hub added?

Do we have a level of confidence that the YoLink node server works with the new hub?

I thought that UD Mobile could be used without the portal. If used inside the house, on the same wifi network, I did not think it was any more difficult than adding the internal IP address for the ISY in http: settings. Maybe things have changed?

I get up there a couple of times each year. Unfortunately, I am stupid and do things backwards. I go south in the summer and north in the winter. We like the good snow at Boyne Highlands.

"Control on" is triggered any time on is received, but not triggered on off/dim/bright/etc. If a device (motion sensor in this case) is already on, a control condition will still trigger a program evaluation even though no change in status occurred. An off command will not trigger a program execution. A control condition is true only during that point when the expected condition is received. "Control on" is false at all other times. "Status on" is triggered by ANY change in status, and is true at all times when the status is on. If the device is currently on and it transmits another "on" command, a status condition will not trigger since it is not a change in status. Use of control versus status is based upon the desired logical result.