Tree like data application structure creating a complex application using a consistent GUI and configuration

[Juno]

I must admit I have not downloaded 2 yet, and also not successfully setup 1.7.
I must admit I am a little frustrated in configuring 1.7 using the GUI/text files, therefore wrote down the idea described below. Hopefully some will merge into Openhab2. If not maybe someone like the idea to create a new domotica application (rather not there are already a lot to choose from ), or use the idea for another application.

As a mechanical/software/electrical engineer I like working from a tree like data structure where each node has properties and commands. This is similar to the linux file system.
Using this tree a (simple) GUI can be created browsing this tree, and for the selected node show its properties and its commands. The properties can be values or parameters of various types. Displayed as static text which are kept in sync with the current value, or parameters. Parameters can be text or numbers with edit boxes, or booleans represented by check boxes. Commands can be viewed as buttons.

When above is implemented it would be relative easy to create a configuration/GUI friendly interface:
On the root of tree a plugin manager node is added which creates commands for all present plugins (I know it is a long list). After pressing the button in the GUI the plugin is enabled and loaded, and a (sub)node is added to the plugin manager node allowing configuring this plugin using various parameters, and maybe commands. For example the ZWave plugin interfacing commands to reset its interface or to detect new devices, and parameters to set the comm port address, or (text)parameters to show the master status, or number of nodes. For ZWave each zwave device will become a subnode of the zwave plugin node. And each new device is a new node dynamically added. This sub node should have the properties of the binded zwave module, so showing its status or having commands to perform triggers, or checkboxes editable or readonly (boolean parameters) for performing or showing toggling functions. Also the node should have properties (values) showing the node status like light is on/off, temperaturs, etc.
Above would allow me to test and see statuses of my zwave devices in a (simple) GUI, without defining items or other (GUI) setup.
To store the plugin configuration the plugin manager has to store its enabled plugins, and the parameters of each plugin. or each plugin can store its own configuration.
Also it can be an idea to allow one plugin to be instantiated multiple time: e.g. to use two zwave networks connected to a system.

After setup and test/verified the plugins, the items can be defined these are maintained by an item manager which creates a binding to the plugin item (I must admit I like the dot separator): e.g. OutdoorLampPower -> .Plugins.Zwave1.ZwaveLightmodule.PowerConsumption.
In my opinion each item is a subnode of the item manager allowing also functionality like a toggle to a switch binding. or a value to a temperature.

Now these items can be viewed in a userfriendly GUI dashboard.

The scriptmanager also will become a node in the tree showing the scripts in individual nodes, To create a new script the manager has an ‘Add Script’ command. This creates a subnode which has a script property showing a special GUI widget for setup the script using item names, or could even address the plugin devices directly using the property address (e.g. .Plugins.Zwave1.ZwaveLightmodule.Switch).
A script node can have a boolean property to dis/enable the script by using the GUI.
An alternative script node (without a script, but with fixed functionality) can be a switch node, in which a property is present to define an input item (or other property address), and a command to add sub nodes to this script. Each subnode contains the address/item of the device which must be controlled. This allows controlling multiple lights using one switch.

A storemanager can instantiate a store system like the plugin manager. Now a storage can add storageitems which are binded to item/address of values to be monitored/stored. A dedicated store view should be added to show the data in a time diagram.

Above would allow implementing a complex system, which can be configured and used by a relative simple GUI which is consistent for the full application.

[rlkoshak (Rich Koshak)]

@juno_kampstra

Hopefully some will merge into Openhab2.

The primary focus of OH2 is to make the initial configuration of OH easier. It will support automatic discovery of Items and vastly reduce the amount of manual configuration required. However its a work in progress right now and not yet ready for production use so we are stuck with manual configuration until it is ready. Perhaps they are already implementing something like this.

@juno_kampstra

Using this tree a (simple) GUI can be created browsing this tree,

Using Groups you can build up a Tree structure of your items should you desire that approach. Then you just need to add your Group to the sitemap and your GUI builds itself. Also, look at Habmin which presents all the information you describe in a GUI, though not in a tree structure. It too is a work in progress though.

@juno_kampstra

Above would allow me to test and see statuses of my zwave devices in a (simple) GUI, without defining items or other (GUI) setup.

You can do this now for zwave devices in Habmin.

@juno_kampstra

In my opinion each item is a subnode of the item manager allowing also functionality like a toggle to a switch binding. or a value to a temperature.

Now these items can be viewed in a userfriendly GUI dashboard.

A user friendly UI for the developer perhaps but not for the end user. The end user doesn’t and shouldn’t have to know that the lamp in bedroom is controlled by a zwave switch and the blinds are controlled by a Souliss device. They should have a UI that has all the things in the bedroom together in the UI. Or perhaps they may prefer all the lighting controls being together instead of having it organized by room. But the point is, the Sitemap is designed to be the user interface for the user, not the developer, and this is why it doesn’t automatically build itself as organization by binding type is the least user friendly way I can think of… For admin and developer type stuff we have Habmin where I think a lot of your ideas would apply and/or are already implemented. But even in administration and development, organization by binding type is often not ideal.

@juno_kampstra

To create a new script the manager has an ‘Add Script’ command. This creates a subnode which has a script property showing a special GUI widget for setup the script

Again, this is something that does exist in Habmin (I should be specific, I’m referring to Habmin2). I think he borrows from Scratch to allow building rules graphically (similar to programming Lego Mindstorms).

@juno_kampstra

This allows controlling multiple lights using one switch.

You do this now using Groups. There is no need to write a script for this capability.

@juno_kampstra

Above would allow implementing a complex system, which can be configured and used by a relative simple GUI which is consistent for the full application.

I agree though I think you make some assumptions which makes this (or any approach for that manner) less clean resulting in a system that is less capable (e.g. pretty much all the commercially available HA offerings) or one with all the same difficulty for setting up and configuring still there. In fact your approach isn’t too far from that used by HomeGenie, and it is one of the major reasons I left it for OH.

For example, how would you handle plug-in bindings where discovery of items is not possible and you have to manually create and configure each item (e.g. MQTT binding)? Is it really easier to have to use a UI to define yoru items in this case?

How do you handle complex systems where it makes more sense to organize everything some other way than by plug-in binding type (e.g. an alarm system that is made up of different sensors which each require a different protocol).

When first starting with OH, I found that I focused really heavily on the plugins and even organized my Items and Rules that way.Essentially I reproduced the organization you describe. However, one of the massively powerful things about OH is that once you get the bindings set up all of that is abstracted and you don’t have to worry about it anymore. For example, if I’m setting up an alarm system even as the developer I don’t have to worry or care that some of the sensors are zwave while others report to OH over MQTT. All I have to worry about is that they are Contact items and I treat them the same way in my rules and my sitemap. And I can swap the devices out for a different type and not have to touch my rules or my sitemap.

If I lost that ability I for one would probably abandon OH entirely as it is one of the only things that makes managing my complex system manageable.

There are some good ideas here and perhaps @chris, developer of Habmin, might have some further ideas or thoughts.