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?

16 hours ago, bpwwer said:

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.

@bpwwer PG3 and PG3x will continue to work with IoX, so they still can be used for development purposes. PG3 was already no longer maintained (except by yourself). Now, the change is that PG3x will also no longer be maintained.

So for those older plugin that just needs to be maintained, they can stay in PG3 or PG3x.

16 hours ago, bpwwer said:

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.

To debug production installations on eisy-ui, you can do things similarly. Install the production plugin in eisy-ui (There is no need for a local store for this), and using sudo, you can access files and logs. The installation location is /var/eisyui/ns/*and it follows a similar stricture as PG3/PG3x.

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

@awysocki Great question! I should have addressed that in my original post.

In addition to what @bpwwer was saying, having it integrated brings these benefits;

• Management of plugins will be available through eisy-ui remotely on my.isy.io. With PG3x, that was not possible. The only way to manage plugins remotely was with the use of UD Mobile.

• This makes the whole solution more robust, especially when it comes to authentication. Although we were able to unify the login experience, this was still 2 products under the cover, and we had to go through hoops to make this work.

• PG3x was an older product that was an evolution from Polyglot -> PG2 -> PG3 -> PG3x. The codebase needed to be refreshed and re-thinked. There were "features" that were no longer necessary and could be confusing. For example:

  • Support for multiple IoX, when most if not all users are just using it to connect to IoX.

  • The local store had an optional developer mode that became needed (or let's say more convenient) when we introduced stricter permissions with PG3x. For development purposes, there is no need for a local store that is not in developer mode.

  • A beta store, with plugins that may or may not share the same nsid with the production store. That made licensing harder to understand for users.

• This opens doors for a better plugin configuration UI.

  • At this time, plugins can only be configured through "custom params" and "custom typed params". You have to go to the plugin configuration page.

  • With this integration, we will be able to do things like right-click on a node and show plugin-specific configuration. We will be able to add more elaborate configuration UI that goes beyond a list of parameters.

  • The current release does not have this yet, but this lays the foundation for more elaborate configuration, integrated with the rest of the UI.

12 hours ago, bpwwer said:

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

@bpwwer If you find bugs or issues, it's best to open a ticket. If the audience is UDI and likely to trigger a conversation to troubleshooting, a ticket is more appropriate.

If on the other hand you have something to say that is likely to benefit other users, then feel free to post here. If I see issues posted here, I will definitely look into it, but they may be overlooked as well as we don't continually monitor the forum. Issues posted here are not tracked either.

@bmercier ,

Thought this would be useful to the wider audience.

For the transition period how is the production store and the new plugin(beta) store sync'd (or not).

I see the new one is populated with what was in the production store. As I have added to the new one I see it doesn't push back to the old production store. Does anything from now on in the old store get sync'd to the new store?

Does this mean for the next while that we have old and new, we developers need to update both stores?

Not a problem for any of the above I am just trying to figure out the rules of the sandbox between them.

Follow up: (too late to edit for some reason)

If we added the beta type sales option to the old production store then we could make changes in only one of the two places. Adding two sales options to a plugin, if they do sync

Edited Monday at 02:32 PM3 days by sjenkins

9 minutes ago, sjenkins said:

@bmercier ,

Thought this would be useful to the wider audience.

For the transition period how is the production store and the new plugin(beta) store sync'd (or not).

I see the new one is populated with what was in the production store. As I have added to the new one I see it doesn't push back to the old production store. Does anything from now on in the old store get sync'd to the new store?

Does this mean for the next while that we have old and new, we developers need to update both stores?

Not a problem for any of the above I am just trying to figure out the rules of the sandbox between them.

Great question.

The short answer:

Both PG3x & eisy-ui use the same "production store". Updates to the store should be done using eisy-ui.

Details:

In PG3x:

• Developers: Store updates are sent to a cloud database.

• Users: PG3x updates a copy of the production store locally every 8 hours. You can click on a button to sync immediately when needed.

In eisy-ui:

• Developers: Store updates are sent to my.isy.io AND the PG3x cloud database.

• eisy-ui users: When looking at the plugins store, the data comes in real-time from my.isy.io. The is no local copy of the production store. Therefore, updates to the store are immediate (When developers updated from eisy-ui)

• PG3x users: Same as before. If the plugin was updated using eisy-ui, the same sync from the cloud database is needed.

• NOTE: The my.isy.io copy of the production store is synched from the PG3x cloud database once per hour.

Therefore, it's best to update from eisy-ui as updates will be immediate for eisy-ui users, and it still updates the PG3x cloud database.

Also, plugins should be updated from eisy-ui or PG3x - not both. If updating from PG3x, then updating from eisy-ui within an hour, you may be be overwriting your PG3x update.

35 minutes ago, sjenkins said:

Follow up: (too late to edit for some reason)

If we added the beta type to the old production store then we could make changes in only one of the two places, if they do sync

If you are referring to the beta edition, you are correct, this exists only in eisy-ui. That edition does not exists in PG3x and is removed.

Quick question. I have the IoX Matter plugin and have been using it for several Matter devices. The plugin has been "beta" for some time and looks like it won't migrate. Will it still work the same on the PG3 side?

P.S., Work the same on PG3 side even if all other plugins are migrated?

18 hours ago, SHM said:

Quick question. I have the IoX Matter plugin and have been using it for several Matter devices. The plugin has been "beta" for some time and looks like it won't migrate. Will it still work the same on the PG3 side?

P.S., Work the same on PG3 side even if all other plugins are migrated?

Yes. You can have plugins in eisy-ui and in PG3 in parallel. That's supported.

iox-matter will have to be published to the production store.

Thanks. Did the migration. I did not try to migrate Matter but 2 plugins (Push, IFTTT) failed to migrate. Screenshot reason attached.

Did a brief survey of nodes and programs. It appears that Yolink door sensor and HomeKit thermostat nodes are not working. Here is a screenshot of the Yolink message. Same for the HomeKit thermostat node.