bmercier

Just a clarification here. The Local plugin folder is indeed not backed up. However, the eisy-ui database is backup, which includes the plugin configuration, customparams, nsdata... basically all the data that the plugin sends to PG3/eisy-ui. But the code or data files are not saved. The code is not backed up as this would make the backup much bigger. The code should be stored in a github repository. What could be backed up, but is not today, are the data files. Production plugins backup includes these folders: data, persist, config and sounds. We could argue that for local plugins, those folders should be backed up as well, which is a very valid point. But the challenge is this: file permissions. If the plugin is in let's say /home/admin/dev/my-plugin, the owner would typically be admin, with the group admin. To back this up, it needs public r. And to be able to restore as well, it needs public rw. So in most cases, by default, it will fail. So ideally, local plugins should not store anything on the file system. If it has to store something, it should use nsdata, and that will be backed up.

When PG3 is disabled, the PG3 service itself stays active. Eventually we will have a release that will removes PG3 completely. But for now, we wanted the capability to return to PG3 if something does not work right.

Please test Ring using the Controller node. It has a test button, and a property that will tell you if PG3 remote access is successful. FYI, looking at the Rachio error, I see the call to the webhook url returned a 503. This tells me that you unit might not have been online on portal.

You can't create a plugin "that addresses github". You need to clone your repository on your unit. Then the local plugin needs to point to the path on your unit. You would need a second store entry just for that purpose, it would never be published. But this is not the best solution, which is why I recommend the local plugin approach.

They show under the plugin Overview tab. The dashboard also shows a small chip with the number of notices, if any.

Same thing. You have both methods available. I would recommend the local plugin approach.

@Panda88 There are 2 ways you could test your plugin on your production system. 1. Use a local plugin on your production system. Assuming your development plugin is in a github repository, you can simply clone it on your production unit, install the dependencies, create a local store entry and "install" it. That's the same setup as your development machine. You essentially use github to push the changes from dev, and pull them to your production unit. 2. Use a regular store entry. On one of your units, create a regular production store entry with a purchase option that points to your github repository, but leave the status to "New" or "Inactive". The plugin will be in the store, but only you (and UDI) will be able to see it. To install it, Go to Development, My plugins, and click on your plugin. From the Purchase options tab, you will be able to install your plugin. If you want to preview the purchase options as a user, click on "View In Store".

I see you have Ring. Can you test Ring connectivity? This uses webhook too.

Yes, Reinstall will install the latest release. In the next release (1.4.9+), you will see an update available indicator, and an update button.

The notification controller is installed in PG3 in slot 1. In your PG3 screenshot, The "unmanaged" notification means the plugin exists in IoX, but it does not exists in PG3. This can be either: A) The plugin used to exist in slot 2 in PG3, but it was removed from PG3 only. This can happen if you restore a PG3 backup where the plugin in slot 2 is not there. The plugin will still exist in IoX. B) The plugin has been installed in slot 2 in eisy-ui. In that case, it will show in PG3 as unmanaged (it exists in IoX, but not PG3). So to clarify the situation, login to eisy-ui at https://eisy.local and go to eisy-plugins to see if the plugin is there. I would also recommend to start using eisy-ui and move your PG3 plugins over to eisy-ui. First, make sure you have the latest releases, then in eisy-ui go to eisy Plugins, then click on "Migrate from PG3", You will see your 2 PG3 plugins and the buttons to migrate them to eisy-ui.

In eisy-ui, right-click on the node, select NodeInfo, then Node Definition. This works for all nodes, not just nodes from migrated plugins.

This is not possible for now, but there is a work around. Using the virtual plugin, you can expose variables as nodes, and I think you may be able to make it a thermostat. That you could add in a tile.

It can take minutes. Also make sure to run version >= 1.4.8

eisy-ui 1.4.8 in beta has the fix. This should solve the backup issue.

Just an update on this thread: The issue was that programs needed to be opened and resaved. That should not longer be required with eisy-ui >1.4.6

Do this in eisy-ui, under System | Configuration. The root cause is that the eisy-ui process was not in sync with the system & IoX timezone. With the latest eisy-ui release, changing the timezone changes it everywhere. Just rebooting should also work. The eisy-ui process will be started with the system time, which should already be correct.

A fix is coming. For your understanding, the problem is a timing issue with the zmatter backup & IoX backup. The zmatter backup creates a background process that creates & removes files in the IoX directory. When PG3x is enabled, it is backed up between the zmatter & IoX backup. This gives time for the zmatter background process to complete. When PG3x is disabled, the zwatter backup may not have completed when IoX backup starts. So the fix will be this: The backup process will no longer automatically trigger a zmatter backup. It will have to be done manually in the Protocols / ZWave section, before doing the system backup, just like it was in AC. There will be a clear dialog explaining that when starting a system backup.

This will be in the next eisy-ui release

@wrj0, please change the timezone to something else, save, then change it back.

Great questions! Why? To simplify eisy and provide a better experience, PG3’s capabilities have been integrated into eisy-ui natively. Or Do I have too? You don’t have to now, but eventually yes. PG3 is going away. And what does it do? (Seems redundant?) It is very similar to PG3, it is indeed redundant at this time. What shows up? A dashboard similar to PG3. Essentially the same capabilities. Is it sort of like the PG3 Dashboard? Yes If this is needed to be done or mandatory, shouldn't an update have taken care of this? Plugins are developed by third-party developers (most of them). UDI do not support the plugins and cannot guarantee that they will work. Although every efforts have been made to make this backward compatible with PG3, it is possible a plugin may work in PG3 and not eisy-ui. Therefore, we had to provide both of them side-by-side and allow to migrate easily, and migrate back if it does not work.

@Javi, @bpwwer I think it's indeed a cache problem. Based on the description of the problem, the profile is updated based on the discovery of Roku nodes. When eisy-ui receives the command to install the profile, it uploads the profile files to IoX then calls /rest/ns/${profileNum}/profile/reload. In the eisy-ui log, you will see "Tell IoX to reload the profile in slot ${ profileNum }". So if the query is done prior to that, I'm not sure there is anything happening to invalidate the cache. To confirm this: Reproduce the error Look at /rest/profiles/?family=10&instance=xx If it is properly updated, this means the profile was processed successfully on IoX. Lool at /api/profiles (This returns all families and instances known to eisy-ui) Look at the data, under family 10 and the correct instance. If it is NOT updated (or nothing under the instance), this means the cache was not invalidated.

In the browser, the 401 will come with the WWW-Authenticate header, which tells the browser to prompt for a username/password. Do you get the promt?

That could happen if eisy-ui and plugins are started before IoX is ready. eisy-ui would have received the status, and tried to update the property on the IoX node, but would fail if IoX is still initializing. Will check what I can do about this.

Very interesting. Is this something that is really reproductible. If so, replicate the error and check what error you are getting in the eisy-ui logs. You can also open a ticket and send your log after replicating this error.

Try a hard refresh using Ctrl-Shift-R. If that does not fix it, you need to remove the "Service worker". I'm not sure in this browser, but in Chrome that would be F12, Application tab, Service Workers - delete the service worked. Need to find the equivalent for this browser.