stillwater

rebooting eisy did not fix mine either.

THis is odd but by no means an urgent issue. Two machines both using wired ethernet on same LAN, both using Chrome browser. Mac works fine with eisy.local and numerical ip address. On PC eisy.local login fails --gets to password screen then redirects to eisy.clocal:3000 and eisy refuses to connect (according to chrome). Can log in on PC using ip address but on the system upgrade screen only three packages are listed-- eisy-ui, IoX, and UDX. This is with staging repo-- 1.4.3_1, 6.1.2_10, 5.0.0_7, PG3x 3.4.26, and mosquitto 2.0.18 . Rebooting eisy and restarting Chrome did not affect this behavior. CORRECTION -- The part about the PC only displaying 3 packages is only partially correct. If I zoom out using the Chrome scren % tool, both the pc and the mac show seven packages. I had thought earlier there was a mechanism for scrolling but there isn't currently, or at least not that I can find. So the only difference between the PC and the MAC is that the PC can't access via eisy.local. the page needs a scroll bar for the packages or a format that shows all at once. the eisy.local access problem seems likely to be solved by clearing a cache in chrome or by creating an equivalence in c:\Windowas\System32\drivers\etc\Hosts -- but it's not really something that needs fixing.

I just checked my eisy... with eisy-ui show PLM links reports "no records found" -- But it also says system busy and event viewer shows eisy receiving something like 870 lines, presumably from the PLM. In fact if I open the admin console it shows the PLM links table scrolling on the screen in response to the eisy-ui initiated process. Clearly something is amiss with eisy-ui display. Otherwise system is behaving normally. This is with eisy-ui 1.4.3_1 and IoX 6.1.2_10.

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.