bmercier

Approval won't work if ISY is not online, that will give you "Bad Request". You may want to try to reboot your ISY. It should normally connect to portal. If it does not, it may be caused by a problem with dns resolution, parental control on your router, or local network routing issues.

The line showing https://eisy.local/desc should show the type and version. The fact that it does not tells me there is a problem. Can you try the url in a browser? Does it respond at all? Could you also try https://192.168.0.106/desc in admin console and browser? It it works, but https://eisy.local/desc does not, it could be explained by a dns resolution problem.

Yes. I understand it was working before. The difference is that you now have eisy-ui installed. Explanation: When eisy-ui is installed, it takes care of the connectivity to portal. IoX no longer does. eisy-ui also takes care of the "portal approval" as it is tied to the portal connectivity. The approval process involves an exchange of tokens with portal through the proxy connection which IoX can no longer do. So, when you are using AC and connect to IoX directly (8080 or 8443), the Portal tab won't work. If you use AC and connect to eisy-ui (no port specified), then the Portal tab will work just like before. Note that you can also manage the portal approval using eisy-ui's web interface. That is not normal. Can you try the URL in a browser? That should give you an xml doc. You may have to accept the self-signed certificate. You should also be able to navigate to https://eisy.local

Is the "other issue" the "Bad Request" on the Portal tab? That is normal if you are using AC over port 8443 or 8080.

This is not a display issue. This just means that IoX is not sending these events through MQTT because they have not changed. Will look into it with Chris.

I located your uuid based on your email address and checked the logs. I see that it's currently online, but there had been an issue (and maybe still there) where there were more than one instance of eisy-ui running. That stems from a bug in an alpha release. A reboot should solve it. Alternatively, you can do this: Stop the service: sudo service eisyui stop Check if you have any eisyui process running, and if so, kill it. You may have it if you installed 0.5.5. Run this: ps aux | grep eisyui Check if you have any process running as eisyui. If so: Take note of the process id (pid) Run this: sudo kill <pid> Restart the service: sudo service eisyui start

If you are referring to my.isy.io, it is up and working, it has redundant connectivity, redundant systems and is monitored. It seems that your unit is probably not connected to portal, and there may be several reasons. Please open a ticket and we we will help you get it to work.

Thank you very much for the feedback. There's no specific timeout set. Will need to investigate further as I have never myself let it up overnight. I suspect the websocket connection dies somehow. Will look into it. Is there a way to get a screenshot? Never seen that happen to me. It might be good to look at the browser console to see what's happening.

That could be explained this way: If IoX is having intermittent troubles, that would kill the subscription, and thus, force you to restart AC. But getting the subscription from eisy-ui, this means eisy-ui has been up all the time without errors. It gets the events from MQTT. Even if IoX restarted, or even if MQTT restarted, eisy-ui reconnects in the background and continues to feed the active subscriptions. No, what @apostolakisl describes is a design choice to hace all folders expanded by default. The only change coming regarding this will be buttons to collapse all/expand all.

This means that IoX is somehow having trouble. That is not related to eisy-ui. The "loading nodes" error you see in eisy-ui means that it is requesting /rest/nodes from IoX, and it is not responding. Are you still having trouble? If so, you need to open a ticket. If you were able to load the admin console, that tells me that IoX is actually working (even if you connected through port 80 or 443).

Just to be more specific; When logging in: If uuid is not in the account, eisy-ui will offer you to add it to the accunt. Also, if uuid is in the account but not "approved" in the admin console, it will auto-approve. There was however a bug related to that logic, and it is now fixed. It is intended to be both a user interface (The home page), and an admin interface (the other stuff). Next big piece under development is Programs. One of the goals is to get rid of the admin console.

Some will prefer "All Expanded" to start with. Eventually I will add Expand All/Collapse All buttons at the top. In addition, I would say that instead of drilling down your folders, the search function is probably best to quickly get to the node you want.

This would be a good start eisy-ui documentation: https://wiki.universal-devices.com/Eisy:User_Guide#eisy-ui

My apologies, I'm pretty sure the update is not going through due to a missing dependency. We are releasing a major upgrade next week which includes an upgrade to the OS. That will fix the installation of eisy-ui using "Upgrade Packages". In the mean time, if you are familiar with ssh, you can upgrade this way: sudo pkg install eisyui sudo service isy restart After the above, you may have to manually start eisy-ui if the install did not start it automatically: sudo service eisyui start

> I assume that I don’t try to backup these node servers and install on the eisy. Correct. That can't be restored on PG3. > Once ISY is migrated, I then install new PG3 node servers (Plug-Ins?) on the eisy? Correct > When installing new Node Server/Plug-In, do I use the slot I used for PG2 previously shown in my ISY? If same plugin, yes. > Will I have to re-point my network resources in my eisy programs for the newly installed Notification node server on PG3? I'm personnally not that familiar with the Notifications plugin, but my understanding is that you are using an older way of doing notifications. I would look into doing it using the current notifications plugin.