Jump to content
View in the app

A better way to browse. Learn more.

Universal Devices Forum

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Any documentation regarding the eisy relationship

Featured Replies

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

  • Author

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.

  • Author
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 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.

Create an account or sign in to comment

Account

Navigation

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.