cdjackson / habmin Goto Github PK

Only certain items are applicable (I think!) with some widgets. eg. for setpoint, only NumberType are allowed.
This would make it easier to find the item as the list would be smaller.

https://groups.google.com/forum/#!topic/openhab/lsCy8yZ_N5o

This seems to be an issue with openHAB. If a frame doesn't have a child, then the rendering of the sitemap gets screwed up.

Selecting only one will cause a misformed item label. This check probably should be in REST interface as well as HABmin.

My proposal is that Widgets panel become more like a toolbox panel, i.e. a lot thinner and only icons. On hover, show bubble with widget name. Then place the Properties panel below the Sitemap tree panel and place the Widgets panel (toolbox) in left of both. I made a simple sketch of this idea:

I think this approach will both save some space for bigger Sitemap Configuration panel and it's more logical, because it mimics most of the IDEs.

This can allow the REST interface to detect that recent data is requested and use the existing "get since" type call in the standard openHAB persistence extensions

This is mostly 2.5 seconds at the moment, but it might be a bit long for some people. Consider having 2 config settings - one for ok, and one for error.

It would be nice HABmin to be architect in a "framework way" that could be extended by 3-rd party extensions (provided by openHAB bindings or standalone). There should be some "hooks" provided for adding a new tab button on top or new menu item in the content (presuming there will be some king of standardized structure). This would allow HABmin to be extended by 3-rd party devs. For example if I want to build a visual sitemaps editor for HABmin or to integrate GUI editor for 3-rd party UI like SmartVisu.

Having an item with multple bindings does not show this in the properties correctly .
Here is my examlpe from my items file :
{ nh="192.168.0.xxx", exec="OFF:ssh [email protected] shutdown -P now", wol="192.168.0.255#00:00:00:00:00:00" }

Habmin tells me that all the three bindings are of type "wol".

It would be nice if there is a dropdown with human readable options for number formatting. So, instead of typing values like "%.1f", user should select options like "integer, decimal, floating point with 3 digits after decimal point, etc"

Add as an attribute. This allows multiple PIDs to be accounted for in a single file (eg a general configuration file).
For the same reason, the PID should be returned in the JSON from openHAB.

If I can work out what they all do myself! The documentation is a little shy so the xtext file is the best reference for the options, but not what they actually do!

Same as is done in the item configuration, the label and format parts should be split into separate properties.

Especially useful for group/frame where there might be a lot of children.

Add type, name and icon to model definition.

Issues with relayout within ExtJS when the grid is shown mean that changing the tab from graph to grid can be very slow with largish data sets.
Use a paging array store, or overload store members to only load the data that's necessary.

Add XML file to config file in OpenHAB to support.
If no xml file then just list directory.

This is currently still from dataMine and needs to be converted from Vera to OpenHAB (or removed if deemed not necessary).

Some suggestions:

• Rename "Persistence" to "Statistics" and maybe place it after "Automation".
• Make a checkbox for every item to enable/disable gathering statistics for this item. When enabled, show additional fields under the checkbox for persistence properties.
• Show item label instead of item name, when label available.

Show if the sitemap has been modified and needs saving

Adding the model name allows the item to be written out to the same file.
Additionally, when adding new items, the model name can be asked.

https://github.com/harrydeluxe/extjs-ux

Change item type to combobox
Add icon into store

Modify history REST return to only return items tjat have persistence enablef.

When no data is returned from the server to a binding config request, an error is thrown in configBindingStore load listener.

If you start to type into the item name box, and then want to remove the text, the box ends up with "null" showing. It should be possible to remove the item since this is necessary for group/frame type widgets that can be items, or can just be a label field.

Currently hardcoded with MAP - support all services.

Demo sitemap isn't saved correctly
Selection item=Scene_General label="Scene Selection" mappings="[]"

Save graphs with the following information for each item -:
ItemName, Axis, LineType, Color, GraphType, Markers

For each axis
Min, Max, Position (left/right)

Try and make it simpler for the user!

If you select a sitemap, then change to show an item, when you return to sitemaps you can't select the same sitemap as it's already selected. This probably just needs to use a different event rather than selectionchange

Change the item icon in the sitemap properties, then click update and the "iconCls" seems to change in the tree rather than the widgets icon.

It would be nice if the item dropdown in Sitemap properties allows typing to filter options.

P.S. Here is a nice tutorial how to be done: http://atechiediary.blogspot.in/2013/06/first-page-extjs-containslike-search-in.html

Here is a jsFiddle example: http://jsfiddle.net/ATechieDiary/Q79Zf/

P.S.2 - Just remember to add "forceSelection: true", so you are sure that a valid item is always selected.

I'm thinking of implementing the following to support "derived items". These are items that are derived through a rule - things like "Maximum value in the last 6 hours", or "Difference in the last day", or calculate the power being used by lights (multiply a power setting by a dimmer value).

It would work something like this (all TBD as I haven't thought it through fully yet).

In the Item Properties page, you would be able to add new derived items. So, if you have an item "Weather_Temperature", then you would have a list of derivations possible, and you can select this, select the parameters (eg duration), specify the derived item name, and click ok. HABmin would then do the following -:

• Create the new item - no bindings or anything. The item name (by default) would be the original item name with an extension (eg Weather_Temperature_DailyMin)
• Create a new rule that updates the item as required. Probably all rules would be stored in a single file that gets generated each time either the rules or the items change.

The rule templates will be in an XML file for starters - maybe in the longer term the rules can be edited visually in HABmin. The XML file will contain the following for each rule -:

• Rule name
• Rule description
• Item name extension (to be added to the end of the item name to create the new item). This may also be used as a global ID, so may need to be unique.
• Rule applicability (ie the item type that this rule is available to)
• Type of rule (to allow filtering - eg. Derived items, or actions...)
• List of variables used in the rule that get updated by HABmin. The rules can be added to the item configuration so they look like existing openHAB item config. This could (for example) be used to configure a power (watts) value that gets updated by the rule depending on dimmer value.
• Trigger conditions
• Actions

The items would then be editable just as any other item is - you can enable persistence, set the label etc.

The "link" to the original Item would be maintained in the background within HABmin, and this link info may be used to access the data in an easier way within the charting.