UI4 UI5 Migration
Our newest Ui5 does some things differently than Ui4. This page explains the changes in Ui5 that may not be obvious to Ui4 users.
Contents |
Single user interface
With UI4 there were several different user interfaces, such as the dashboard, the wizard, the cp.mios.com portal, etc. To view the current status of a device you went to the dashboard. To view the history of a device you went to cp.mios.com. Now there's just one UI and everything is one place. As always some of the features are handled locally by Vera, and others are handled by a server. But rather than having to check 2 UI's, they are all together. If you are viewing a popup or a tab that requires features handled by the server, such as a history of your notifications, you will see that you are prompted to login with your mios.com username when you try to choose those tabs or features. Also, if you do login to mios.com, but do not yet have a Vera, you will be notified of this when you select features that are handled by Vera locally, such as controlling devices.
Scenes
Scenes have been changes substantially. In Ui4 there were up to 4 different ways to specify "turn on light #3". On the dashboard there were on and off buttons, and in the wizard similar buttons. When adding light #3 to a scene, on and off were pull-downs. And you had the option of adding it both as a 'normal' scene and as an 'advanced' scene, and as part of a delay (ie turn off light #3 and 30 seconds later turn it on).
With Ui5 the goal is to make sure that the same action is always done exactly the same way. So if you want to turn on light #3 in the dashboard, you click the 'on' button for the light. If you're creating a scene and want it to turn on light #3, you still see the same control like on the dashboard and still click 'on' the same way.
So now when you create or edit a scene you'll see that you essentially get your dashboard. Devices that are grayed out are not involved in the scene (ie unchanged). Click one of the controls in the device to add it to the scene. Clicking 'on', like you would on the dashboard, means turn the light on. The delays are handled now by a the "Add commands to be run X seconds after the scene". So if previously in UI4 you had light #3 turn on and turn off after 30 seconds, and light #4 turn on and turn off after 45 seconds, then when you migrate to UI5 you'll have a pull-down that has "Immediate" which shows light #3 and #4 on, and also a "after 30 seconds" which has light #3 off, and also an "after 45 seconds" which has light #4 off. You can now add as many delays as you want, like, immediately do nothing to light #3, turn it on after 30 seconds, dim it to 50% after 60 seconds, and turn it off after 5 minutes.
Also in UI4 you had 'advanced' command (on the advanced tab) vs. 'normal' commands (on the command tab). And it was impossible to see all your commands in one place. In Ui5 there's no longer the concept of normal vs. advanced commands. There is still an Advanced tab, but this is only an advanced "view" of the same commands. The same commands are shown on the devices tabs as on the advanced tab. The advanced tab just presents it in a table view with all the commands in the scene. Whereas the devices tab let's you build a scene more like a macro recorder, by just clicking on the devices the same way you would on the dashboard.
Timers
They are now called "Schedules", but they work exactly the same way. It's a tab in the scene editor.
Events
They are now called "Triggers", but they work exactly the same way. It's a tab in the scene editor.
Developer changes
eventList
The eventList in the D_...json is now normalized. The format from UI4 was a mistake all along, treating arrays as objects. So this:
"eventList": {
"event_1": {
"label": "Incoming call from",
"serviceId": "urn:upnp-ap15e-com:serviceId:FCM1",
"norepeat": "0",
"argumentList": {
"argument_1": {
"dataType": "string",
"name": "CallSource",
"comparisson": "=",
"prefix": "Phone number",
"suffix": ""
}
}
},
"event_2": {
"label": "Outgoing call to",
"serviceId": "urn:upnp-ap15e-com:serviceId:FCM1",
"norepeat": "0",
"argumentList": {
"argument_1": {
"dataType": "string",
"name": "CallDestination",
"comparisson": "=",
"prefix": "Phone number",
"suffix": ""
}
}
}
},
now needs to be like this, where eventList and argumentList are now arrays containing an element id that has the id, rather than putting the id in the tag name (i.e. event_1 becomes "id": 1):
"eventList": [
{
"id": 1,
"label": "Incoming call from",
"serviceId": "urn:upnp-ap15e-com:serviceId:FCM1",
"norepeat": "0",
"argumentList": [
{
"id": 1,
"dataType": "string",
"name": "CallSource",
"comparisson": "=",
"prefix": "Phone number",
"suffix": ""
}
]
},
{
"id": 2,
"label": "Outgoing call to",
"serviceId": "urn:upnp-ap15e-com:serviceId:FCM1",
"norepeat": "0",
"argumentList": [
{
"id": 1,
"dataType": "string",
"name": "CallDestination",
"comparisson": "=",
"prefix": "Phone number",
"suffix": ""
}
]
}
],
sceneList
The sceneList tag is obsolete. In UI5 the commands available for scenes are the same commands that can be given to a device from the dashboard controls. So if we have a device with 4 buttons in the Control Panel, but only 2 of them on the dashboard, only these 2 can be used in the scene.
New device tags
The device is the top level container. It has the following tags:
- inScene*: If this tag is present and has the value "1", the device will be shown in the scene editor.
- x, y: These represent the device box dimensions, x and y being the width and the height respectively. 1x = 80 pixels, 1y = 25 pixels. These are used to tell the UI how much space you need to draw all the controls (excluding the header and the icon). A button has x = 1 and y = 1, an horizontal slider has x = 2 and y = 1 and a vertical slider has x = 0.5 and y = 2.
The device can have 0 or more SceneGroups.
* These tags are mandatory. They don't have a default value so if they're missing, the behavior is unknown.
SceneGroup
SceneGroup is a new type of container, similar to a ControlGroup, but with some key differences: it is customizable (by setting its position and dimensions) and it defines the behavior of the buttons assigned to the same state variable. If two buttons in the same SceneGroup are assigned to the same variable, only one of them can be activated in the scene editor (radio buttons behavior). If two buttons assigned to the same variable are in different SceneGroups, both can be activated at the same time in the scene editor (checkboxes behavior).
It has the following tags:
- id: A numeric value (positive integer numbers).
- top: The offset from the device header. It uses the same units as x and y.
- left: The offset from the device icon. It uses the same units as x and y.
- x, y: the dimensions of the SceneGroup. e.g If I have two horizontally aligned buttons in the SceneGroup, x will be 2 and y will be 1.
A SceneGroup can contain one or more ControlGroups.
New ControlGroup tags
In UI5, the ControlGroup is an intermediary container between the controls and the SceneGroups. You can't place a control on the dashboard unless you place it in a ControlGroup, which in turn must be placed in a SceneGroup.
- scenegroup: This tells the UI in which SceneGroup this ControlGroup will be placed.
- isSingle: Since controls cannot be grouped in drop-down lists anymore, this tag has a different role in UI5. When isSingle is "1", the buttons in the ControlGroup will have a background (e.g. the BinaryLight buttons). If isSingle is missing, the buttons won't have a background (e.g. the Thermostat buttons).
Note: type is not used anymore.
New control tags
Controls can be positioned relative to the SceneGroup in which they're placed with the following tags:
- top
- left
Note: ControlPair and ControlHeader are not used anymore.
image_player
This is a skinnable button. The image for the skin is specified with the image_src tag.
e.g. Here is the Up button from the camera:
{
"ControlType": "image_player",
"Label": {
"lang_tag": "cmd_up",
"text": "Up"
},
"Display": {
"Top": 49,
"Left": 466,
"Width": 75,
"Height": 20
},
"Command": {
"Service": "urn:micasaverde-com:serviceId:PanTiltZoom1",
"Action": "MoveUp",
"Parameters": [
]
},
"image_src": "images/player/image_control_up.png"
},
luupx and Lua files
In UI4, loading a module from a Lua file was done like this:
if (package.path:find ("/etc/cmh-ludl/?.lua;/etc/cmh-lu/?.lua", 1, true) == nil) then
package.path = package.path .. ";/etc/cmh-ludl/?.lua;/etc/cmh-lu/?.lua"
end
package.loaded.L_HomeCare = nil
hc_plugin = require ("L_HomeCare")
This worked only for manually uploaded Lua files because the uploading script didn't lzo compress these files. Installing a plugin with Lua files lzo compressed them, so the above code would've become a lot more complicated. luupx is a luup module extension which at the moment contains only one function - loadModule. This function accepts one parameter - the module name. It uncompresses the Lua file to /usr/lua_files and returns the required module.
So, in UI5, loading an external module is done like this:
luupx = require ("luupx")
hc_plugin = luupx.loadModule ("L_HomeCare")
