We have published a new release of eisy-ui, version 1.3.4 in Beta.

This new releases introduces 2 major features:

• Integrated plugins

• Insteon / Z-Wave / Zigbee / Matter UI.

 This post details the new features related to integrated plugins.

For a while, eisy-ui had PG3 integrated into the UI. But under the surface, if was still using the former PG3 as a separate service.

With version 1.3.4, you can now run your plugins directly in eisy-ui, without PG3. In a way, this is a complete rewrite of PG3. All the existing plugins should work without a change as eisy-ui is backward compatible with PG3.

 

Differences with PG3

Production vs beta store.

In eisy-ui, there is only one plugin store: the ”production” store. Most plugins that are in the beta store also exists in the production store. If you are using a plugin from the beta store that does not exist yet in the production store, the developer will have to publish to the production store.

Plugin developers that want to publish a beta version of their plugin can do so using the “Beta” edition. In PG3, plugins could have the “Free”, “Standard” and “Professional” editions. The addition of the “Beta” edition will allow developers to publish beta releases of their plugins. Beta releases will have an expiration date that is tied to the version. This will allow them to publish additional beta releases as new version comes out, allowing users to restart a beta trial on the new release – something that was not possible in PG3.

Local store

For developers: The local store in eisy-ui is implicitly in developer mode. This works virtually the same way as PG3, but it’s a bit easier to use as the store entry features only the relevant fields.

 

Understanding plugins in PG3 vs eisy-ui

Plugins in eisy-ui, just like plugins in PG3, are installed into IoX “slots”.

With 1.3.4, you have access to plugins in eisy-ui and PG3. But a plugin in a given IoX slot can only live in PG3 or in eisy-ui.

If a plugin is installed in PG3, then you need to go to the PG3 Dashboard to see the plugin. Conversely, if the plugin is in eisy-ui, you need to use the “Plugins (Beta)” option to see the plugin.

Migrating plugins from PG3 to eisy-ui

Migrating your plugins is easy. Go to Plugins (Beta), then “Migrate from PG3”. You will see your PG3 plugins and will be provided with buttons to either migrate them individually, or all at once. This will stop the plugin in PG3, install the plugin in eisy-ui using the same IoX slot, and migrate the configuration. This way, your programs should continue to work with the same nodes, but now managed by the plugin in eisy-ui.

If something goes wrong, you can always migrate back to PG3.

When you migrate from PG3 to eisy-ui, the plugin stays in PG3 as-is, but is marked as “migrated”. If you have to revert, it can be restarted with the exact same configuration.

Beta plugins can’t be migrated.

Plugins in developer mode can’t be migrated either. Developers have to recreate the store entry and “install” from there. It can use the same plugin folder though.

Backups

eisy-ui backup & restore will backup and restore your plugins. Make sure to take a backup after migrating.

Once the plugins are removed from PG3 (or PG3 is disabled), you may notice that the backup size will be significantly lower.

When backing up PG3, all the plugin folders were saved, including the plugin code & dependencies. That is not necessary.

eisy-ui backs up only the  data; The database, and some of the known data folders. When restoring a backup, the plugin gets installed, and the data from the backup is restored.

Having a smaller backup footprint will allow us to introduce automated backups in the future.

Known issues

This is still very new, which is why this is released as beta code only.

We are aware that the 4 node.js plugins (ST-Inventory, ST-Sonos, ST-Nuheat, ST-Ecowitt) are currently not working.

There is no “reinstall all plugins”. This will be added in an upcoming update.

1 hour ago, bmercier said:

Plugins in developer mode can’t be migrated either. Developers have to recreate the store entry and “install” from there. It can use the same plugin folder though.

I'm not sure I understand what this means, at least to me.

I've never used "developer mode", my primary development environment was running a local version of pg3 under my account so I had access to everything. In that environment I have 24 plugins listed in my local store. I have two development/test environments, one on a Polisy and one on an eisy. I also have plugins in local stores associated with the production installations of PG3x. When I have to debug plugins running on a production installation of PG3x, I just use sudo to access the files and logs. Never had a need for "developer mode".

It sounds like none of this will be usable with eisy-ui and that I'll have to potentially re-create 50+ local store entries if I want to continue developing, debugging and maintaining my plugins.

I don't understand the goal of this? PG3 was a way to add features to eisy. I don't fully understand other than calling it something different PLUGINS vs PG3 what its buying us.

1 hour ago, bmercier said:

For a while, eisy-ui had PG3 integrated into the UI. But under the surface, if was still using the former PG3 as a separate service.

With version 1.3.4, you can now run your plugins directly in eisy-ui, without PG3. In a way, this is a complete rewrite of PG3. All the existing plugins should work without a change as eisy-ui is backward compatible with PG3.

I guess I just need more explanation what this means. When you say "for a while..." hasn't this always been the case even with PG2. That's a long while.

So you are saying the plugins now run in the eisy-ui app/container/service...? Where before they ran in the PG3 app/container/service... which connected to eisy-ui?

So you are removing a layer of code? We don't call them PG3 nodes anymore, we call them plugins? Just looking for a better road map of what is the goal and what should I be aware of.

Thanks
Andy

2 hours ago, awysocki said:

I don't understand the goal of this? PG3 was a way to add features to eisy. I don't fully understand other than calling it something different PLUGINS vs PG3 what its buying us.

I guess I just need more explanation what this means. When you say "for a while..." hasn't this always been the case even with PG2. That's a long while.

So you are saying the plugins now run in the eisy-ui app/container/service...? Where before they ran in the PG3 app/container/service... which connected to eisy-ui?

So you are removing a layer of code? We don't call them PG3 nodes anymore, we call them plugins? Just looking for a better road map of what is the goal and what should I be aware of.

Thanks
Andy

PG3 (and PG2) are standalone web apps. Prior to this new beta release if eisy-ui, eisy-ui simply integrated the PG3 main menu into it's menu structure and made calls to the PG3 web app to manage the plugin (formally node servers).

PG3 did plugin management (install/remove, start, stop, configure) by making calls to IoX. eisy-ui also makes calls to IoX for integrated nodes (insteon, z-wave, zmatter, etc.), programs, variables and such. So this beta is basically just combining them so it's one common layer that communicates with IoX instead of two.

The PG3 look and feel will change to match eisy-ui but the functionality will be mostly the same.

Way back when we were developing PG3 we talked about the eventual goal being a combined PG3/Admin console web app. It's great to see that finally happening.

@bmercier Is this the right place to report issues with the integrated plugins feature?