stillwater

What does it say on the display on the Configuration tab under the System option. This displays the GMT offset of your system and a time that may be the system time (My eisy is in my local time zone so I am guessing about this).

presumably in this case the red x just means there was nothing to back up.

I just looked at a backup file on my PC and it appears that the backup file is a zipped archive. Within one of mine I find FILES > CONF > D2D and within that a series of .PGM files that appear to be fairly readable XML representations of each program. So you could look through these in notepad or in an xml viewer and get an idea of what the program was. There might even be a way to import a particular program once you found it but you might have to rename it to fit in an empty slot or something like that. I wouldn't try anything like that without making a current backup first.

@Javi You are right, it's very different. There is an external web service that is consumed as a client by IoX. Configured (host name = ip address and user/ password/Port) via AC>Plugins>Plugin Configuration. I am pretty sure these parameters can be entered via REST also.

@Javi My non-standard undocumented node server built in 2016 is a cllent of an eternal web server on a raspberry pi. I believe this is working as of now, based on http return codes I have looked at. If this is going away I can probably substitute REST commands and network resources but it would be good to know. It's a nice feature to have.

I did it sometime around 2016 so I am hazy on the process. The good thing is that it has survived upgrade after upgrade including shiftover to eisy. The code was saved as part of the ISY/IoX backups. The only tricky thing on changeover to eisy was I had to export and reimport network resources and add back a password fo the webserver client that is part of my redundant loop. This was before even the early versions of polyglot (now PG3). I recall the methods were described in a document about version 5 of isy -- it was the basis of moving away from insteon to be able to create any kind of node. I am pretty sure this is the document I used: https://docs.universal-devices.com/developers/wsdk/5.0.4/docs/ISY-WS-SDK-Node-Server.pdf What I used this for was to create a node that could display in the admin console (and now in a tile on the eisy-ui home page) that allowed a Sauna that is actually controlled as a heating zone in my climate control system to be turned on and off by insteon keypad buttons and then have its status (OFF - ON -- Warming -- Ready -- Ready/Reheat ) reflected in keypad button backlights. There's no reason it couldn't be used to create a node that shadows an insteon sensor or has has status set by a program that takes input from a variety of sensors. The actual node definition is very simple but there is a fair amount of arcane names and syntax involved given how simple it actually is. I think this is because UDI was trying to be as comprehensive as possible in what could be represented in a node and displayed. The above document says that the node definition profile files are normally installed via the admin console (hopefully this has been or will be carried over to eisy.ui) but that it's also possible to install them by REST -- see section 4.2 on page 10. Since I haven't touched this since about 2016 I can't vouch of whether the installation process still works as specified. There is also this V5 API documentation that may be a little more recent than the document above but still predates polyglot. https://wiki.universal-devices.com/ISY_Developers:API:V5:Node_Server Note you can have a custom node definition without a separate node server. the node status can be updated within IoX. (at least this is my recollection). Finally I recognize that this is all ancient stuff and that the current approach encapsulates the node definition in a "plugin" that is managed via a new page within the eisy. Probably there is a way to upload the node definition files to somewhere in the eisy and then install via the plugin interface but I have not looked into how this is done yet.

it's possible to create a custom node definition that would display "open" and "closed" rather than "on" and "off." This can be done via the REST interface and uploading configuration definitions But that's probably not the answer that @RVandergriff01 was looking for.

In eisy-ui 1.3.11-1 (current beta and staging) and IoX 6.1.2_8 (staging) on my EISY, if I right click on a node there is an options called "add to group" -- choose this and there is a menu called "scene selector" that allows me to choose a scene to add the node to.

@Bumbershoot Hadn't thought of that. This is a great idea.

Thanks. I want to be clear about this. I use the launcher method (start.jnlp) with the local password option and the cloud admin console option. (:8443 option and cloud choice on drop down). What I was talking about was admin.jnlp found and invoked by the (new to me) icon at the upper right corner of the eisy.ui screen. This icon was new to me and I was seeing what it did. So in my mind UDI is inviting users to access the admin console via this method. I was just trying to be helpful to UDI and others in flagging this. Based on what you say if UDI wants to leave the icon on the screen it should invoke a compatible launcher via the cloud if accessible rather than whatever admin.jnlp happens to be on the local machine. Or if it's going away the icon should be eliminated rather than inducing frustration for more naive users. Or it can be left as it is as it may work for people who have never upgraded or under some other obscure circumstances. Obviously it is likely to go away when the ac is no longer supported. @Guy Lavoie 's suggestion that running the launcher with the cloud option would reset the admin.jnlp that would then be invoked by the eisy.ui icon did not pan out on my machine. I was just trying to be helpful in flagging this. I don't care what UDI decides to do about this. Using the launcher versus the icon does not complicate my life --it is what I did before I noticed the icon.

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. Update: I should have said I have current with the beta repository and then the staging repo the last few days but it may have also been true at the 6.1.1 and whatever the coresponding eisy-ui level was. Currently IoX 6.1.2_8 and eisy-ui 1.3.10. Windows laptop PC with Chrome browser on flat local network. (no vlans or fancy stuff.). Eisy has a staic ip assignment in the router.

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