simplextech

The ISY doesn't have a "user interface". There's an "admin console" for administration but otherwise it's a automation system. There has been a market for mobile access and Mobilinc, Agave, ekPro have filled that niche and I'm sure there will be others. When a large enough demand for a web UI emerges I'm sure someone will fill that niche as well. Until there's either a personal drive or monetary drive for development or enhancement I don't think it will happen. I've said it before that I'm happy I don't see UDI wasting resources on making a UI pretty (I want string support and dynamic updating rather than restarting and having to re-upload/process profiles). Otherwise I don't care as long as it's reliable and functional over pretty.

Sounds like it might be dead... replace it.

Not necessary when just doing firmware upgrades. I've upgraded several ISY's a few times with Z-wave. Just make a z-wave backup first just in case.

Ok. It's odd that node remnant are still in the right panel but not in the node list. You could try running a synchronize. This will take a while with as many z-wave devices as you have but it will interrogate each node in the z-wave module db and isy and compare and synchronize them. Admin Console Z-Wave menu -> Tools -> Synchronize Nodes -> All

Actually I don't care so much for what the whiteout is covering. I'm more concerned about helping you enter the modern age of taking screenshots from your computer and being able to edit them without having to use your phone, email them to yourself, etc etc... Whatever you may be hiding under the whiteout is your concern... if that is whiteout?

I have to ask... why does it look like whiteout on your screen? And it looks like you're taking a picture of your screen with your phone? or other camera? Why?

The motion sensor works fine. I have several deployed in daily use. This is a "motion sensor" NOT a multi-sensor so the temp, lux, etc are NOT meant to work outside of the device even though they are "visible" to and presented by the ISY. So do not run around in circles about these items. The MSII has a couple product defects. 1. the internal motion sense timer doesn't reset properly so using the MSII for controlling lighting and using the auto off/reset of the lights doesn't work. This is a device problem not ISY and nothing UDI can do to fix this. There's also a device problem with LED not being able to be turned off when on battery. Again device problem not ISY. Outside of setting expectations correctly and the two issues above. Yes the MSII works great. I use the on-only mode for scenarios where I want very fast lighting response and that gives me great flexibility using ISY programs to determine when to turn things off based on things besides motion.

For what it's worth I also have half a dozen 2421 sensors and no false opens on them. I do have random long delays of reporting "on" from them but no false reporting.

Been very busy bee's with the documentation.... good job.

The physical wiring is the same. Regardless of using an ISY or Insteon Hub or No hub/controller at all. Follow the wiring instructions but you can ignore the "configuration" instructions as they are intended for use with the Insteon Hub or direct linking. For a 3 way you will not wire the second switch with a traveler like a normal 3-way switch. You will wire the first switch controlling the load just like any normal switch with a load. The second switch will be wired with power/neutral but without a load. Cap off the red wire and any remaining wire in the box. (generally the traveller). Verify the first switch is physically controlling the load correctly. Then you can link the switches either via ISY or direct that is all up to you but I recommend using the ISY as it just makes it easier.

If you're ISY is default (DHCP) and the Google Wifi does not have a DHCP reservation defined for the ISY then how in the world have you kept the same IP address forever? Suppose it is possible if you've never had the ISY disconnected from the network for any period of time. Amazing actually. I think you'll have to wait for UDI and see if they can do a remote session to debug this but it all smells of a network issue.

Was the IP address the same or different from before the re-install? May have been asked already but is your ISY configured with a static IP address or DHCP?

No DHCP reservation.... so the IP address of the ISY could have changed during your testing and rebooting and such. Have you cleared your java cache and downloaded and installed the ISY finder during any of this?

I've been giving this a lot of thought recently..... I looked into Home Assistant again and their native and hacs component for ISY. Neither are even loading or working if Nodeservers are present so this is a non starter. I looked into OpenHAB and their binding. It's deprecated and not maintained. Probably wouldn't work correctly so I didn't continue looking. If someone else runs OpenHAB with the ISY binding please let me know how well it works and particularly with Nodeservers. Currently none of the mobile apps (eKeyPadPro, Agave, Mobilinc X) support nodeservers. I've heard from all of them they are "looking into it". At what time frame is unknown and which developers they are working with to test/validate nodeservers? I think HAD or a variation of it is still viable and could be continued. However at what level of interest from people and at what cost? (development time).

As mentioned earlier all of this is pointing towards some network issue. I went back in the thread and you said you don't have a "Port" reservation. But do you have a DHCP or Host Reservation within the Google Wifi router? I know nothing about the Google Wifi or how/what they may call it but it should not be "Port". Does the AC still work only sometimes? after a ISY reboot it works and then stops working?

It sounds like there's a lot of issues and a lot of changes before, after, during this whole debacle. Have you contacted UDI support? Can they look at your system and try to get things working? From the Portal and AC side I think UDI should look to verify the portal registration is good.

Doing the linking from the ISY gives you the best of the technology. Without the ISY managing the switches you can't use them in a program. The devices are still inked and still work without the ISY being online just like they would with direct linking. So you lose nothing but gain the ability to use them with ISY programs.

Polyglot running local has zero connection to the ISY Portal. In any kind of troubleshooting exercise only do one thing at a time and check results before continuing as when you do 3 things how do you decide what fixed things or caused the problem?

You're very welcome. I grabbed pieces from the ISY-Inventory polyglot and edited to work outside of the nodeserver. Here's the link to my public repositories. Might find some ideas or useful tidbits. https://github.com/simplextech?tab=repositories

Give this a try. I left comments inline and print statements for debug #!/usr/bin/env python3 import xml.etree.ElementTree as ET import requests from requests.auth import HTTPBasicAuth def get_request(url, user, password): try: r = requests.get(url, auth=HTTPBasicAuth(user, password)) if r.status_code == requests.codes.ok: return r.content else: print("get_request Error: " + r.content) return None except requests.exceptions.RequestException as e: print("Error: " + str(e)) my_switch = 0 isy_ip = "192.168.1.69" user = "admin" password = "admin" svars_url = "http://" + isy_ip + "/rest/vars/get/2/1" svars_resp = get_request(svars_url, user, password) # print(svars_resp) if svars_resp is not None: svars_root = ET.fromstring(svars_resp) # print(svars_root.tag, svars_root.attrib) for svar in svars_root.iter('var'): # print(svar.find('val').text) my_switch = svar.find('val').text print("My Switch Value is: " + my_switch) Change the (isy_ip, user, password) to match yours.

If those are the only changes then remove them and see if the problems clear up. Then add one at a time to see if a problem returns.

I suppose that's one way to check. Normally one would check the process table and see if the process is found, if it's been running for a while or not. Does a "start" the script checks if it's running but doesn't provide much information. Do you have anything in your logs that may point to why it's not displaying in the UI?

Have you logged into the box to see if the udx process was still running? Did it crash for some reason? Look at the logs?

In your python r is the requests object. You can access the contents via literally the objects contents. change the print statement like this. print(r.content) That will print the content you receive from the requests.get which is contained in the 'r' variable (object).

Not sure about the slowness in programs but 5.0.16A did fix the slowness of a right-click on a z-wave device from the main screen. Hoping it's still fixed in this release.