Is there any documentation regarding the relationship between eisy, IoX, and PG3?

The UDI Wiki is your best source

https://wiki.universal-devices.com/Main_Page#Online_Documentation

If you're looking for something specific then the forum would also be a good choice.

This is exactly what I have suspected-There is NO documentation on how the entire framework ties together. For example PG3 runs partially on the eisy, but is also must have a central database somewhere in order to keep track of licenses and plugin info. Where is all of this because it it too big to reside totally on the eisy (there are other good reasons why PG3 can't totally run on the eisy)?

What I am looking for is a layout of how the entire framework ties together. You can call it the system architecture, but that is exactly what I am looking for. I have asked Michel for this, and he has ignored me. I thought perhaps someone in the forum could enlighten me.

Well we can sort of deduce some things after using it for a while. If you compare the system to a Windows application you create that's running on a Windows PC (a Visual Basic program for example) you'll see that there are many system calls and resources that allow your applications to hook into the operating system. File access, mouse movements and actions, writing on the screen, network events, etc. The eisy runs on unix and multitasking has always existed on unix, long before DOS was even created. There are various methods of interprocess communications built into unix (like when you fork a new process, it inherits all the file descriptors of the parent process) though nowadays interprocess communications is often done through sockets. So an add on like PGx will often access an application programming interface (API) that's defined just like system calls are made available to Windows processes. The various IoX resources are defined as API calls that your program (plugin) can use to exchange information to and from IoX. Defined objects (nodes), programs, and variables would be stored in a database, which allows external applications such as eisy-ui to retrieve them. Editors like admin console (and soon, eisy-ui) can also modify the database.

Just some thoughts.

11 hours ago, Guy Lavoie said:

Well we can sort of deduce some things after using it for a while. If you compare the system to a Windows application you create that's running on a Windows PC (a Visual Basic program for example) you'll see that there are many system calls and resources that allow your applications to hook into the operating system. File access, mouse movements and actions, writing on the screen, network events, etc. The eisy runs on unix and multitasking has always existed on unix, long before DOS was even created. There are various methods of interprocess communications built into unix (like when you fork a new process, it inherits all the file descriptors of the parent process) though nowadays interprocess communications is often done through sockets. So an add on like PGx will often access an application programming interface (API) that's defined just like system calls are made available to Windows processes. The various IoX resources are defined as API calls that your program (plugin) can use to exchange information to and from IoX. Defined objects (nodes), programs, and variables would be stored in a database, which allows external applications such as eisy-ui to retrieve them. Editors like admin console (and soon, eisy-ui) can also modify the database.

Just some thoughts.

Nice try, but I have come to a different conclusion. I just would like it validated. I have been a user since the ISY99, and have come to several conclusions. These are:

1) Whatever firmware UD is using is NOT OS dependent, but a stand-alone app. They MAY have converted it to run under LINUX for the ISY994, but it still is a stand-alone app..

2) In the ISY994, UD didn't want to support both the Elk module and PGx, so they dropped support of the Elk module and left it up to some developer to develop an Elk plugin.

3) The firmware for the ISY99 through the eisy seems to be the same code base, with additions for the new functions (such as PGx, etc.). There seem to be only minor differences between the admin console for the ISY99, and the eisy. However, the firmware for the ISY994 contains code to prevent unauthorized execution of the Elk module.

4) PGx seems to be a small module within the eisy that provides OS and library functions for the plugins, and licensing for the plugins. When it is activated, it makes contact with the server at UD that is accessible at the UD portal. It is this server that stores the plugin licenses and gives the control panel for the PGx. The PGx module in the eisy then gets it's info from the portal server.

LINUX may or may not be used for the UD devices. I don't believe Unix is used at all. The eisy (and the ISY994) boot too quickly to load an OS. Linux (or Unix) is NOTHING like Windows.

5) Somewhere in the eisy there is the portal credentials.

6) I don't know how much snooping UD does with PGx.

I really want decent documentation from UD.

1 hour ago, SJacobson said:

LINUX may or may not be used for the UD devices. I don't believe Unix is used at all. The eisy (and the ISY994) boot too quickly to load an OS. Linux (or Unix) is NOTHING like Windows.

The host OS for eISY is not Linux but another UNIX variant called FreeBSD. This can be confirmed at the command line by running the command: uname -a

Here's the output of 'uname -a' on my eISY:

[admin@eisy ~]$ uname -a

FreeBSD eisy 14.3-RELEASE-p5 FreeBSD 14.3-RELEASE-p5 #5 releng/14.3-n271450-382f54740ee4-dirty: Tue Oct 28 19:30:07 PDT 2025     root@bsdev143.isy.io:/usr/obj/usr/src/amd64.amd64/sys/eisy amd64

IIRC, the reason Linux was not chosen by UDI when they were first porting the ISY software to the Polisy device had to do with licensing restrictions/problems with software licensed under the GPL (Gnu Public License), which is the license that Linux is published under. The FreeBSD license, in contrast, is considered to be a more permissive license, which I believe UDI found better suited to their needs: https://docs.freebsd.org/en/articles/license-guide/

Edited Tuesday at 04:40 PM5 days by Bumbershoot

The operating system is well known: it's FreeBSD. It's unix. Other than possibly license mangement of plugins, PGx is essentially stand alone on the eisy. When you create your own plugins, they operate locally. The PGx dashboard is running locally, accessed through a local port.

The new login method with port credentials does need to cache the information locally, to allow seamless access between IoX, PGx and the portal.

7 hours ago, SJacobson said:

Nice try, but I have come to a different conclusion. I just would like it validated. I have been a user since the ISY99, and have come to several conclusions. These are:

1) Whatever firmware UD is using is NOT OS dependent, but a stand-alone app. They MAY have converted it to run under LINUX for the ISY994, but it still is a stand-alone app..

2) In the ISY994, UD didn't want to support both the Elk module and PGx, so they dropped support of the Elk module and left it up to some developer to develop an Elk plugin.

3) The firmware for the ISY99 through the eisy seems to be the same code base, with additions for the new functions (such as PGx, etc.). There seem to be only minor differences between the admin console for the ISY99, and the eisy. However, the firmware for the ISY994 contains code to prevent unauthorized execution of the Elk module.

4) PGx seems to be a small module within the eisy that provides OS and library functions for the plugins, and licensing for the plugins. When it is activated, it makes contact with the server at UD that is accessible at the UD portal. It is this server that stores the plugin licenses and gives the control panel for the PGx. The PGx module in the eisy then gets it's info from the portal server.

LINUX may or may not be used for the UD devices. I don't believe Unix is used at all. The eisy (and the ISY994) boot too quickly to load an OS. Linux (or Unix) is NOTHING like Windows.

5) Somewhere in the eisy there is the portal credentials.

6) I don't know how much snooping UD does with PGx.

I really want decent documentation from UD.

Hi,

I'm not sure what's really on your mind, but I sense from your posts that you're very concerned about something. Although it's unclear what that is.

A few of the architectural conclusions in your post don’t match how the current platforms actually work.

On Eisy, the controller does not run bare-metal firmware.

Eisy runs FreeBSD as a full host operating system. IoX and PG3x are user-space services started by the OS at boot, just like any other daemon. This is why you can SSH into Eisy and see standard BSD processes, services, filesystem, and package manager.

On older hardware like the ISY99 and ISY994, the controller was much closer to firmware-style embedded software. That’s likely where your impression comes from.

Elk module vs PGx, this was mostly a historical product strategy shift rather than a technical limitation. The Elk module was compiled directly into the 994 firmware. Polyglot came later as a way to externalize integrations instead of baking them into firmware, which is what eventually led to node servers replacing modules.

Conceptually, it's reasonable to say the same IoX lineage runs from ISY99 through Eisy. But today IoX is a process running on top of FreeBSD rather than being the entire device image as it was on the earlier controllers. That's why IoX can be restarted independently of the box and why PG3x continues running when IoX is restarted. That separation didn't exist on the ISY99 and ISY994.

PG3x is not a small helper module inside IoX. It's a separate service running alongside IoX on the operating system. Its roles are to host and run node servers as separate processes, provide the store, install, and update interface, handle licensing checks with UD’s portal, and translate node server data into nodes that IoX can consume through its API.

PG3x communicates with IoX over local APIs and sockets. IoX itself is blind to whether a node originated from Insteon, Z-Wave, or a node server.

Licensing does involve communication with UD’s portal, but the node servers and PG3x runtime operate fully locally. Portal credentials are stored locally so the Eisy can authenticate to UD’s portal for remote access and license validation for paid node servers. There's no indication that PG3x streams device data to UD. Node servers run locally and communicate locally with IoX.

So.... what's troubling you?