bmercier

This is nor 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.

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?

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.

Here's some clarifications regarding plugins & backup. "PG3 backup" includes the exact same backup as when you were doing a backup of PG3x. This includes the PG3 database, and the plugin folders (that includes the plugin code & data files if any). Some plugins may write data to files. Some will persist their data into "nsdata", which is essentially stored in the PG3 database. Now eisy plugins work differently. Because this is integrated with eisy-ui, the eisy-ui backup already includes all the data that the plugins saves to a database (such as nsdata). Regarding the files, eisy-ui took a different approach than PG3. The vast majority of files in the plugin folder are the code and libraries that the plugin use. Most plugin don't save anything to the file system. Backing this up increases the backup size a lot, for no good reason. Instead, only data files located in these folders are backed up: data, config, persist & sounds. Plugins are expected to use one of these folders when saving data to the file system (If not using nsdata or other "customs"). When restoring a backup, eisy-ui restore will recoved the database. Then the plugin code is installed from the store - we don't need the files from the backup for this. Then the plugin data files are restored. So, "plugin data files" simply refers to these 4 folders. If you don't have any eisy-ui plugin to back up, it will show an x, which means that this is not included in the backup.

What is the log level on these plugins?

Can you reinstall the plugin in PG3 and retry the migration? With the latest update from today, this should work.