I upgraded from UI4 to UI5 the night before last and was able to get my DSC Alarm Panel functioning again by deleting the old one and creating a new one using the plugin. Then last night, a newer version of UI5 was available, so I upgraded.
After the upgrade, my DSC Alarm Panel was no longer working, so I deleted it and created a new one. Now, there is no communication with the panel, and there are a lot of fields missing from the device on the Advanced tab, notably the protocol field. Even after having let it site overnight, there is still no communication with the alarm panel. I can connect to it using PuTTY as a raw TCP session on port 5000 and see the timestamp every minute or two. I have attached some screenshots.
I have verified that all the files are there. The only difference is that there are now two of S_AlarmPartition2.xml.
Has anyone else experienced this, and have you been able to fix it? I guess that, as a last resort, I could revert to UI4 and load one of my backups and try the upgrade to UI5 again.
@OtisPreslsy, my guess is that it isn’t your upgrade was successful. I think the problem is that UI5 handles some things differently that UI4 and there are some changes that need to be made to most plugins to make them compatible.
From what I gather we are all seeing the same problems. It actually looks like some of the changes make life easier on us plugin developers (at least I hope so!), but it will probably be a few days before all the bugs get shook out.
I keep getting “remote arm is not enabled” And I know i have it set to “disarm” in the advanced tab. I also keep seeing “DSCAlarmPanel: Clearing…” and “DSCAlarmPanel: Keybus Fault Restored” I tried to delete the plugin and do a fresh install and i wasn’t able to even get and zones listed… I had to downgrade to UI4 and it all works again.
Yep, I saw the same exact thing, which is why I tried to delete it and start over. I was able to get it working on the original release of UI5 but not this last one.
I can confirm 1.5.233 broke the DSC plugin. I would not be surprised if it broke other things as well. Going back to 1.5.201. Looking at the logs, it looks like it is not even trying to communicate over the network with my wiznet board.
Mine worked on 1.5.201, but I had to delete it and then add a new one using the plugin. I just reverted back to UI4: 1362 with a FW reset and restored from a backup. I verified that all was working correctly. Then, I upgraded to 1.5.233 and see the same thing. The timestamp no longer ipdates, and it always displays: DSCAlarmPanel : Clearing…
When you try to arm it, it says that Remote Arm is not enabled. When leaving the device there from UI4 and then installing the plugin, the new device it creates is still missing all the variables and never establishes communication with the panel. I am going to try going back to 1.5.201, because I had it working there.
[quote=“garrettwp, post:8, topic:169759”]I can confirm 1.5.233 broke the DSC plugin. I would not be surprised if it broke other things as well. Going back to 1.5.201. Looking at the logs, it looks like it is not even trying to communicate over the network with my wiznet board.
They modified a number of the plugins prior to putting them into the app store, and we don’t yet have a full list of what those exact changes were. The unmodified versions from UI4 won’t work correctly as UI5 requires a number of changes to be made (to the JSON, for example)
We’re chasing them to see what those changes were.
When I upgraded from UI4 to 1.5.233 this last time, I left the alarm panel from UI4 installed and then installed the plugin, which created the new one that did not work.
I reverted back to 1.5.201, preserving my configuration and settings, and it started communicating with the alarm panel on both plugins. I then deleted the new alarm panel, which deleted the plugin but left the original alarm panel from UI4 there because it is not associated with the plugin. This apparently allowed it to still use the new files and is working again.
Yes, when doing an upgrade to UI5. The plugins will get updated and replace the old plugin files. So your older plugin setup is using the UI5 version of the files. There were some changes made in firmware 1.5.228 that caused the plugins to work with 1.5.201 to not function under 1.5.233. I am digging, but I do not know the plugin structure well.
I doubt that anything changed in the files for this plugin, but I could be wrong. I looked through all the XML files and see that the missing variables from the Advanced tab, for instance, are still defined in the XML files. It still reports version 1.0 in the market, so I am guessing that some changes that were made between 201 and 233 affected some plugin functionality in general, as you stated.
[quote=“garrettwp, post:13, topic:169759”]Yes, when doing an upgrade to UI5. The plugins will get updated and replace the old plugin files. So your older plugin setup is using the UI5 version of the files. There were some changes made in firmware 1.5.228 that caused the plugins to work with 1.5.201 to not function under 1.5.233. I am digging, but I do not know the plugin structure well.
Can you tell us what needs to be changed to update the plugins. Thank you for fixing the issue, but this can help us when converting other plugins over or when new ones are created.
Were these the only changes was the eventlist2 area? It looked like the plugin was not even communicating with the panel. I will update back to 1.5.233 to see if the plugin works. But that will have to wait until later in the day.
I upgraded my unit to 1.5.233 and downloaded version 1.1 of the DSC Alarm Panels plugin. It still does not communicate with the alarm panel using the IT-100 and Wiznet Ethernet module, and all of the variables are still missing from the Advanced tab on the parent control pad.
Edit: The new 1.1 version of the plugin does still work with 1.5.201; I have rolled back to that version.
Florin’s wording is misleading. We have never knowingly broken any compatibility with UI4, except with the EventList tag which we normalized, and, when it happened, we made a change on our side to allow the Ui4 and Ui5 plugins to share the same file (renamed EventList2 to EventList).
What Florin is referring to here with the DSC is not that we changed anything in the engine that broke the plugins. Rather, in the past, users were typically uploading their plugin files by hand through the UI, so they weren’t compressed. That means the ‘require’ lua command in an Implementation XML would work fine to import uncompressed .lua files. Now with UI5, we have an online, hosted development environment so it’s easier for developers to commit and publish files without all the manual uploading, and it stores the files compressed. So, the ‘require’ doesn’t work on a compressed file. But, if you continued to upload it manually, like everybody did on Ui4, it would still work. To get around this we added a new feature, which Florin documented, so that when an implementation file needs a lua file, it can be included with a simple xml tag . Previously, for UI5, Florin had created a hack in the plugin to copy the files to a temporary directory and decompress them before including. Now with the new feature, Florin went through all the publicly published plugins and removed the hack, and he was supposed to simultaneously add the new Files tag. But in this case, the hack was removed, but the Files tag wasn’t added.
So it was human error, and not that something in the engine changed to break compatibility. To my knowledge, all the UI4 plugins work the same on Ui5 as they did on Ui4 and I haven’t so far seen any confirmed differences. We’ve received lots of complaints, but, I believe that it’s always ended up being something else, and that compatibility is in tact at the engine level. In the Ui / html, the only change was the normalized EventList2.