wmcneil

@johnjces, with regard to port 8080, it is available as follows, this may be what you were trying to remember: When using local credentials, you can access the REST interface using http at port 8080, for example: http://IoX_Username:IoX_Password@BOX_IP_ADDRESS:8080/RESTcommand When using ISY Portal credentials, you can access the REST interface using http at port 80(which is the default http port, so it does not have to be explicitly specified), for example: http://ISY_portal_username:ISY_Portal_password@BOX_IP_ADDRESS/RESTcommand

@bmercier, I am running 0.7.2 I have opened a ticket and attached the requested files to it.

I have an Elk node server that appears in the admin console as shown in the screen shot below: This is how the tile looks if I use the "Add Tiles" button to add the Elk node server to the eisy-ui home page: So the four buttons at the bottom of the Admin Console Elk node are present, but lets say for example I want the functionality of the Admin Console "Set Armed Status" button and corresponding pulldown selection to be added to the tile. Can this be done, and if so, how?

Some further details that expand on the issue: For me, running Chrome 142.0.7444.60 under windows 11, when I attempt to load eisy-ui using https://LOCAL_IP , chrome warns me (about the self-signed certificate), and then if I tell it to proceed anyway, it does so and then changes the displayed url to https://LOCAL_IP . If I then click on the Admin Console icon, chrome refuses to complete the download of admin.jnlp If I load eisy-ui using http://LOCAL_IP, then click on the Admin Console icon, chrome complete the download of admin.jnlp

@woodchip, After successfully install of IoX 6.0.0 or later: ports 80 and 443 use ISY Portal Credentials, and become available. The only interface which is available only on ports 80 and 443 is eisy-ui, which includes a full PG3x interface fully equivalent to what was available (and still is available) on port 3000 using IoX==local credentials. All other interfaces are available both on ports 80 and 443, as well as continuing to be available on the prior interfaces: ports 8080 and 8443 use IoX==local credentials. All of the interfaces which used these ports prior to IoX version 6.0.0 continue to function using these same ports, and using the same IoX=local credentials that they used prior to IoX version 6.0.0 port 3000 uses IoX==local credentials, and provides a PG3x interface. So after installing IoX 6.0.0 , you can choose to use only ports 80 and 443 for all interfaces going forward, or you can continue to use ports 8080 or 8443, and port 3000. So for example: If you access Admin Console via ports 80 or 443 using ISY Finder/Start, you will enter ISY Portal Credentials If you access Admin Console via ports 8080 or 8443 using ISY Finder/Start, you will need to authenticate using IoX==local credentials I am not aware of any official best practices for port usage being published. The fact that you can choose to consolidate everything around ports 80 and 443 allows for that simplification if you so choose. That is what I am choosing to do.

I specified only https posts in my post above, and neglected to also specify http ports. Here is the complete list: So if 14.3 and 6.0.0 are installed correctly any of these should work https://eisy.local/WEB/sysconfig.txt OR https://polisy.local/WEB/sysconfig.txt OR https://eisy.local:8443/WEB/sysconfig.txt OR https://polisy.local:8443/WEB/sysconfig.txt OR http://eisy.local/WEB/sysconfig.txt OR http://polisy.local/WEB/sysconfig.txt OR http://eisy.local:8080/WEB/sysconfig.txt OR http://polisy.local:8080/WEB/sysconfig.txt If 6.0.0 is not installed correctly, the ports that use IoX==local credentials should still work: https://eisy.local:8443/WEB/sysconfig.txt OR https://polisy.local:8443/WEB/sysconfig.txt OR http://eisy.local:8080/WEB/sysconfig.txt OR http://polisy.local:8080/WEB/sysconfig.txt

port 80 is the default port for http, so if no port is specified, port 80 is used port 443 is the default port for https, so if no port is specified, port 443 is used ports 80 and 443 use ISY_Portal credentials, and are available if running IoX >= 6.0.0 . These ports provide access to eisy-ui ports 8080 and 8443 use IoX==local credentials So if 14.3 and 6.0.0 are installed correctly any of these should work https://eisy.local/WEB/sysconfig.txt OR https://polisy.local/WEB/sysconfig.txt OR https://eisy.local:8443/WEB/sysconfig.txt OR https://polisy.local:8443/WEB/sysconfig.txt If 6.0.0 is not installed correctly, the ports that use IoX==local credentials should still work: https://eisy.local:8443/WEB/sysconfig.txt OR https://polisy.local:8443/WEB/sysconfig.txt

Answering my own question: When I tried out using port 80 and ISY Portal credentials, I neglected to add authorization to the Network Resources entry I created. After correcting that mistake, port 80 is working for rest correctly.

I have successfully installed 14.3/6.0.0 . After the install, it appears that rest get http commands are continuing to work with port 8080 . I tried configuring one in Network Resources for port 80, and when I click on the Test button, I get a error window popup with a "TCP client request failed" message. This is in a AC session that was opened using port 80 and ISY Portal credentials. Is rest going to continue to work only with ports 8080/8443, or will ports 80/443 eventually be supported?

I have installed a zen17, along with a magnetic sensor (this one), and all is working as expected. The zen17 firmware was version 2.00, and I had to download the 2.10 version from zooz, install it, and do an Update with Interview in order for the second (S2) switch input (Door/Window Sensor) device to appear. If you are doing an install of the zen17, note also the hints in the previous two posts.

Thanks! The user manual does not state that a value of 11 (garage door mode with wired sensor) for parameter 2 or 3 requires a subsequent exclude/include (although the "How to Use the ZEN17 Universal Relay as a Garage Door Opener" directions do), so having confirmation the exclude/include is required is helpful. Also, the fact that the default settings for the input trigger parameters (Parameter 10 and 11) is to have triggering enabled is important to know. (So that the triggering can be disabled for the garage door application)

zen16 vs zen17 what's the difference

An advantage to detecting door closed/not closed with a magnetic switch is that there is no battery that has to be replaced. The advantage of a tilt sensor is that it can detect movement, as well as closed, open. Practically speaking, you can write code that will work reliably to control the opener via a relay with either sensor. I should add that I always have installed a video camera in the garage, so that I can double check for sure what the door status is, either while debugging code, or in the very rare event of hardware failure.

I am looking for a ZWave garage door control solution other than the GoControl gd00z-8 (If interested, you can read about why the gd00z-8 will not work for me here.) One solution I see is the Zooz ZEN16 Multirelay in combination with the Ecolink Z-Wave Plus Tilt Sensor. If anyone is happy with that solution, or a different ZWave solution, I'd be interested in your feedback.

I'm getting about 10 msec ping response. So there must some other overhead in the SMTP interaction that is taking significantly longer.