wmcneil

@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.

Thanks. I had to increase the timeout to 20,000 (I tried a curl at Michael's suggestion, and that was taking 12 seconds, so I increased to 20 to be on the safe side.).

I agree, seems likely. If their customer support was better, I'd make another run at them, but after the "We don't support end users" discussion, I'm done.

I have updated my Eisy to 5.9.1 . Email notifications are no longer working, other features seem to be working ok. In the AC, if I go to Configuration > Emails/Notifications > Settings/Groups and click on Test, several seconds go by and then a window pops up with "Mail server failure" and "[[SMTP_ERRORS--1]]". I am using SMTP server smtp.gmail.com, and my Google App password. I have verified the Google App password is working to send emails with other applications. I have opened a ticket.

I am using the Zmatter dongle. I also have successfully used the gd00z-8 in the past, and am currently using one at my vacation home (with a polisy and zmatter dongle) without issues.....The company who currently owns GoControl have not been very helpful, and I've spent all the time I am going to spend with them. UD told me that others have been having trouble recently with their GoControl garage door controllers.

Update on my issue for those who may also have issues with their gd00z-8: In response to my ticket, UD did a remote session and spent a bunch of time looking at the issue. The final conclusion was that the gd00z-8 was not following correct protocols for inclusion using security. I was able to eventually get nortek/nice to ship me another replacement device, and it is behaving exactly the same way: During the inclusion process, after entering the PIN, and verifying the window that contains the full key, a few seconds later the gd00z-8 beeps three times. The eisy continues with the interview process, and eventually the device is added as only an Entry Control device. With all my prior successful instances of successfully adding this device, it appears as a Barrier device (primary device), with three sub devices: Barrier Alarm, Home Security Alarm, and Tamper Alarm. Zwave interview timeout is set to 1 minute. I have tried exclude followed by a factory reset multiple times, and moving the gd00z-8 a couple feet away from the zmatter antenna, all to no avail. I'm fairly certain the three beeps from the gd00z-8 during the inclusion process is an indication that something is not correct. I have spent a large amount of time on this (and UD spent a good hour on it), Nortek/Nice is difficult to deal with (the last rep I talked to insisted they do not support end users). I will spend no more time on this. I'm going to open a new thread to see what other solutions out there are working for folks.

As described further above: I am using the ticket process, I have updated the ticket several times to bring attention to it, and the ticket has been open 30 days! The process is clearly broken.

To whatever admin changed the title of my thread - I'm trying to understand why the usually excellent support Universal Devices has provided in the past is not currently present for this problem. This is a valid concern, and my title was neither inappropropriate nor inaccurate.

I am having a problem including a new GD00Z-8-GC zwave garage door controller in my eisy zwave network. I opened a ticket (#25957) with ISY 30 days ago. It was ignored for quite some time, then I had one response, now it has gone dark again. Universal Devices - what is going on here?: Your usual stellar support has fallen apart for me on this?! The GD00Z-8-GC is supposed to be a new (replacement) device, but it is not functioning correctly after being added, and is appearing differently than other successfully functioning instances of this device in the past. It's not clear to me if the supposedly new device is defective, or if some other problem is occurring? When the device is included, it is appearing as a Entry Control device only. In the past, successful instances of this device have added as a Barrier device (primary device), with three sub devices: Barrier Alarm, Home Security Alarm, and Tamper Alarm. When the eisy saw the device during the include, it prompted me for the PIN, and had S2 and S0 selected, which I left selected (which is what I have done in the past). I clicked on the verify button when the confirm dialog appeared. I have attached the log. On line 1251, "Interview not complete: total=7 successful=2 attempted=3" is reported. It appears that security is not being established during the include. I have tried many reboots, many excludes and includes, and a factory reset of the GD00Z-8-GC device, all with no change in behavior Thanks in advance for you help with this! ISY-Events-Log.v5.8.4__Fri 2025.01.24 02.10.27 PM.txt

My ticket # is 25957. It was opened 20 days ago, and I requested an update 11 days ago. There has not yet been a response. Can someone from UD please confirm whether the ticket is visible in the system? Thank you.

I opened the ticket below 9 days ago, and there has been no response. Is there something wrong with the ticket system? [Ticket #25957] issue including GD00Z-8-GC garage door controller

Never mind, I figured it out. I had only partially configured the M1XEP - A send all using Elk RP fixed the problem. I had forgotten that the conflict checking in Elk RP does cover all the M1XEP setup. For anyone else reading this, when connected to the M1XEP using Elk RP, click on M1XEP setup, then click on the TRACE button at the bottom of any of the M1XEP tabs, then select Show Setup. This will show you all the settings currently configured in the M1XEP.

I had to replace the M1XEP on my M1EZ8. I have restored the old M1XEP configuration to the new M1XEP. I have reinstalled the Elk nodeserver. I have rebooted my polisy. I am still getting this message in the log: 2024-12-08 19:17:08.944 ELK-4483 elkm1_lib.connection WARNING connection:connect: Could not connect to ElkM1 ([Errno 61] Connect call failed ('192.168.2.235', 2397)). Retrying in 60 seconds The IP address is correct, I can connect to the M1XEP secure port (2601) at that IP with Elk RP and other applications. I have verified that the M1XEP has non-secure port 2397 enabled. I have verified that the user_code I have configured matches one that is configured in the EZ8 control, and have verified that code works with the Elk keypad. I'm stumped. I've attached the log file package ELK_12-8-2024_71701_PM.zip

Thank you, your description has jogged my memory, and I now remember that a similar bug (or maybe this exact bug?) has been around for a while.

In the AC, with the Elk node server "Area 1" selected (which I have renamed to cElkArea1 using the AC), under the Display Message area, the Content pulldown displays only 4 choices, despite the fact that I have 27 email customizations defined. I also see this same limitation in programs which are using the Display Message action. I have tried to reboot the polisy, it had no effect on the problem. I am running IoX v.5.8.4 on a polisy, PG3X version 3.2.27, and elk nodeserver version 3.10.15