stillwater

I tried this and it did not change what version of admin.jnlp was being summoned by the icon at the upper right of eisy.ui. I always use the cloud rather than the lan option from the launcher). I usually use the url that allows the older ISY password to be used, rather than portal., but for this test I used admin console (cloud) from the standard (portal password) url. Not an issue for me personally but i could see that this behavior could be troubling for someone unfamiliar with the old ways. This is on a Windows laptop pc. Eisy-ui is version 1.3.10 and IoX is 6.1.2_8

This is a minor annoyance but it is exacerbated by the use of the portal username (email) and password, which are long. I use the Chrome browser and other unix boxes (for example my unifi router) are happy to sit for long periods of time (days?) without requiring a new login. The admin console is like this also. Of course I don't know if this is something unique to me or something that is some sort of a passing problem.

I am using eisy.ui 1.3.9 and IoX 6.1.2_7. I can access the admin console fine via start.jnlp launcher as always. There is an icon at the upper right hand corner of eisy.ui that downloads something calls admin.jnlp. When this is run the ac tells me that there is a version mismatch -- ac 6.1.1 vs IoX 6.1.2. No problem for me and quite possibly the glitch would go away if I cleared Java cache etc, but it seems a little weird to have this not work when the launcher does.

I see the Event Viewer now (staging repo version current as of today). However I don't see any way to select the logging "level" and it does not appear that the level 3 information is included in this version of event viewer. On the other hand, it is very nicely organized (readable).

When I upgraded from ISY994i (restore from backup) my network resources seemed not to work. They worked if I resaved them. I have quite a few. On a whim I tried exporting them and then restoring them, and after that they all worked. This was just one person one time and it's possible they would have worked after some other keystroke and the export/restore was irrelevant, but it's something that could be tried.

@bpwwer Thanks!!! I looked at it a little and I think you are right that I will be able to maintain it with Rest even if all the interface stuff goes away. In fact the essential things that I do could be done with a state variable and programs instead of a defined node, and using network resources to communicate out instead of the SOAP(?) http server on my auxiliary processor. The only thing I would lose would be the ability to display node status prominently rather than having to decode a state variable. I was contemplating adding other functions but never got around to doing that. If I ever get motivated to do that I may well migrate to python and a more normal PG3 plugin. (My python skills are minimal.) @bmercier I am not looking for any special support but just hoping that backward compatibility with what I have done will be maintained. The only odd thing I have noticed so far (and I am not sure about this) is the failure of a password to carry over on restore from IoX backup. This password is used for basic authentication with the http server on the node server auxiliary processor. I see where the connection properties can be reset via REST. I have tried this and presumably it worked but the password is not reported out in response to a configuration query (reasonably enough, presumably for security reasons), so I can't be sure. (The password does show up in the level 3 logs, which surprised me.) I have now upgraded via the staging repo and appreciate the additional features. My node created by my node server has some info (not as much as admin console) on the node info menu item, and configuration still goes unhelpfully to the plugins page. If this is the end state I don't have a problem with it.

I am reluctant to use the staging repository because 1) there is the warning not to do so unless UDI has instructed you to. 2) It is not clear to me that it is possible to downgrade to earlier versions. (I was unable to downgrade from Beta to the Production instances and even restoring from an old backup did not restore the production versions).

I have a node server that I developed and that is only useful to me. It seems to have survived migration from ISY-994i to eisy (current production repo version). Will this continue to work going forward? Do i have to put my plugin in a local store? The node server (now plugin, I guess) is not complicated -- though I wrote it when node servers were brand new and didn't document it. -- It connects IoX with my climate control computer and a separate auxiliary processor to control a sauna. It defines a node with a few custom states, with the states updated via REST and a scene (involving insteon KPL buttons), and programs that activate network resources to communicate to the climate control computer. There is also a (probably redundant) communication channel between IoX and the auxiliary processor (a raspberry PI programmed in Dyalog APL) that uses the SOAP WSDK (not Java). Update -- I believe that in 6.1.1 when I right clicked on the node it gave me configuration info. But that might be wrong. I might be remembering access via the admin console. I just switched to the beta repo. In eisy-ui when I right click on configuration it sends me to a plugins Dashboard where it gives no information on my plugin other than its name and that it is unmanaged. By contrast the admin console gives access to an X-ray menu that includes "all profiles (JSON)" that appears to provide the definition for the node. I have no idea how to load or edit such info via the admin console or eisy-ui. I have no current need to do so if the node server keeps working. But it does seem that there is something missing in eisy-ui compared to the admin console. Certainly eisy-ui should continue to give full node definition info. I vaguely remember that I uploaded the node definition profile files to ISY using REST. This was probably before the portal or maybe even polyglot existed, certainly before PG2 and PG3. Further Update -- I see the Admin Console has a plugins menu item at the top that lists my node server and also has a configure menu for the various plugin slots. I don't see this anywhere on eisy. Third Update -- It appears that when certain things happen on eisy (package upgrade? plugin refresh? restore from backup), I need to reenter the password for my node server communication through the admin console -- top ribbon menu plugins/configure/choose slot/ Password. This box ends up blank rather than having dots in it. I don't see equivalent functionality in the eisy-ui (beta repository). I don't remember how I originally entered this information (which is for access to a web service on an auxiliary computer)-- there may have been a node server menu item in the admin console or it might have been created in the node server profile files -- but in the eisy it needs to be entered while I never had to do that with changes to the ISY-994i.

It would be nice to have a comprehensive user manual for eisy-ui, and for those of us who are used to the old admin console, a cross-walk document that tells users how to accomplish via eisy-ui all the things that could be done under the admin console. My current question is about how to view level 3 (device communication) events live, as was possible in the AC under tools/diagnostics/Event Viewer. No shame if this isn't available yet -- but I hope it's on the dev list if so.

This is a belated response to some discussions in the forums before Javi's September 8 post. I am not diminishing the concerns of those who want to keep their ISY-994i boxes working forever. At this point, because of issues with Java including on the Mac, it is imperative that there be a full alternative to the admin console. Now that UDI is fully committed and has a timetable, I am confident that the eisy-ui wil have every bit of functionality that the admin console had, and probably some additional useful features as well.

You can use IoX to test for connectivity and only reboot the router when connectivity to the portal been lost. I have done this in the past. It will reboot extra when the portal goes down but this is not common.

I don't know, maybe do a factory reset on the PLM and then try restore PLM again. Before that you could do a count of the links in the PLM (from the tools/show PLM links table box) and see how that compares to the complexity of your insteon system. Something seems to be going wrong in the refresh of the PLM. If your IoX/ISY backup is current you could restore from backup again before doing the PLM restore, just to be sure that the scenes are accurately reflected in the IoX links table that would be transferred to the new PLM by the PLM restore. But this is clearly clutching at straws on my part.

I was just saying that the fact that the scenes run from keypads means nothing about the status of the PLM links table. Not suggesting you actually unplug the PLM. You haven't said whether you can turn the scenes on and off from the Admin Console but I assume based on the diagnostic that the answer is no. This means either that the EISY is not communicating with the PLM (the fact that the diagnostic says specific links not found probably means that this is NOT the case. Also the fact that recreating the scene worked suggests that the connection between EISY and PLM is working. ) OR more likely that the PLM does not have the proper links in it to activate the scenes. I would try rerunning the restore PLM procedure following the instructions exactly. Maybe restore the EISY from backup again first. But again others know more than I about all this.

Again my understanding is that scenes will run from keypads with no PLM plugged in. (Unless they need programs on IoX to run properly.). Of course EISY wouldn't know whether they have run or not or have any idea about changes in device status.

I thought your problem was that Alexa wasn't causing scenes to tun -- so now I don't understand what is working and what isn't. The device table compare shows what links are in the devices but not what is in the PLM's link table. It sounds like that is where the problem lies. Under Tools in the Admin Console there is a show PLM links table but I wouldn't know how to analyze what's there. (There's no "compare" button.) Clarification-- there are 3 types of link tables. The IoX keeps a record of the links that are supposed to be in each device and also the links that are supposed to be in the PLM links table. So you did a compare of the IoX "should be" device table with the actual device table, for particular devices. The restore device re-writes the device link table to reflect what's in IoX. I don't think restore device affects what's in the PLM device table (but it might be intended to--I am not an expert).