wmcneil

UD asked me to upgrade packages and try again. I did so and then tested with three users defined (user 2 and 1, as well as the default user 0 which is reserved for manual turns of the deadbolt) Everything seems to be working correctly now. These are the updates that were applied: IoX 6.0.3_3 -> 6.0.4_1 UDX 4.2.0 -> 4.2.0_2 PG3x 3.4.6 -> 3.4.9

I have opened a ticket. Michel responded and reported that myself and another user reported the problem. UD is investigating root cause.

Yes, the update to 6.0.3 happens on any reboot, without having pressed the update button. More info about that here: https://forum.universal-devices.com/topic/46113-reboot-automagically-causes-update-to-iox-603_3/#findComment-400793 There are additional upgrades available(to UDX 4.2.0, PG3x 3.4.6, and easyui 0.8.5), I have applied them, and the problem with my kwikset deadbolt user number reporting remains.

Thanks, yes, I have now fixed the version number in my post.

I have an eisy running IoX 6.0.3_3, and the zmatter dongle. I have a kwikset zwave 620 deadbolt. The deadbolt has been in my zwave network for over 1 year. The following behavior has started recently: When the deadbolt is unlocked by a human entering any valid user code on the keypad, the User Number reported in the Access Control Alarm entry in the AC is a 10-digit number. It is a constant value, regardless of which user code is entered. Previously, the User Number would be the correct user number corresponding to the code that was entered. Since the 620 supports only 250 users, a 10-digit number should not be possible. Before I start trying to chase this further, I thought I would see If anyone else has seen this behavior. If so, please post. Thanks.

@mmb, I also had the same problem with Firefox. Completely clearing the cache solved the problem for me.

@bmercier, since your statement above that "There are no cases where updates would be done automatically" is not correct (per Michel's response above), if possible, please remove the Solution tag from your post further above.

Explanation from Michel in response to the ticket I opened as to why 6.0.3 installs automatically upon reboot (without update button having been pressed): "...the reason is that 6.0.0 had an issue with libxml-2 library. So, once the packages were upgraded, it would no longer start and thus would not even give you the ability to login to the Admin Console to do the upgrade. Since we removed the capability for upgrade using the front power button (it had its own issues), our only choice was to reinstall it upon reboot. "

I have opened a ticket. Will post back with update once it is resolved.

It seems likely that the update to 6.0.3 is happening "automagically" on reboot without the update button having been pressed. If anyone else has experienced this, please post and let me know, so I can be absolutely certain before I open a ticket.

Hmmm, this happened on two different boxes, an eisy, and a polisy. In both cases, prior to the reboot, they were running IoX 6.0.0_4 . I could see that maybe I accidentally clicked on update on one of the boxes without realizing it, but seems less likely that it happened on two different boxes. The only package that actually "automagically" updated was IoX, so if your theory is correct, I would have had to accidentally done the update on both boxes before about 12/1, otherwise other packages would have updated too....Anyway, thanks for the pointer, good to know.

Rebooting either an eisy or a polisy (yes, I have both) that is running IOX 6.0.0_4 causes an update to 6.0.3_3 , WITHOUT any update being requested. Why is the update occurring when no update was requested? After the reboot and automagic update to IOX 6.0.3_3, eisy-ui / settings / system shows the following additional updates now available: UDX available update from 4.0.4 to 4.2.0 PG3X available update from 3.3.23 to 3.4.6 eisy-ui available update from 0.7.2 to 0.8.5 There is no release announcement for IOX 6.0.3 . Will there no longer be release announcements?, or was the one for 6.0.3 an accidental "miss"?

I was able to update my polisy to IoX 6 without any issue. It does take a while for the update to complete, maybe 15ish minutes.

So if I change local connection settings to use port 8080 and the "IoX" credentials (instead of the ISY Portal credentials), the problem goes away. @Javi , I assume UD Mobile will eventually fix this and support ISY Portal credentials on port 80, since not doing so would make UD Mobile inconsistent with all the other interfaces?

In UD Mobile (android, version 1.4.6) when I attempt to access Settings / Plugins I am getting this error message: "could not get pg3 auth Invalid Credential. Please check username and password. 401" This is an eisy running IoX 6.0.0_4 and eisyui 0.7.2 UD Mobile Local Connection Settings: Local IP Address: http://Numeric_IP_address Local Port: 80 Local Username: ISY Portal Username Local Password: ISY Portal Password

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