Defining layout for UI within .items or within .sitemap

Setup, Configuration and Use Beginners
,
1

I’m just wondering, what’s the best way to get a structure within items and sitemaps and all.

Is there a definitive way or a rule of thumb on how to use both variations?
So far, from the examples, I got my home layout within the .sitemap like:

sitemap binder label="Die Binders"
{
	Frame label="Haus" {
		Group item=gOG label="OG" icon="firstfloor"
		Group item=gEG label="EG" icon="groundfloor"
		Group item=gUG label="KG" icon="cellar"	
		Group item=gSensoren label="Sensoren" icon="office"	
		Group item=gGarten label="Garten" icon="garden" 
	}

	Frame label="Wetter" {
		Text item=Weather_Temperature valuecolor=[Weather_LastUpdate=="Uninitialized"="lightgray",Weather_LastUpdate>90="lightgray",>25="orange",>15="green",>5="orange",<=5="blue"] {
			Frame {
				Text item=Weather_Temp_Max valuecolor=[>25="orange",>15="green",>5="orange",<=5="blue"]
				Text item=Weather_Temp_Min valuecolor=[>25="orange",>15="green",>5="orange",<=5="blue"]
				Text item=Weather_Humidity
				Text item=Weather_Visibility
				Text item=Weather_LastUpdate visibility=[Weather_LastUpdate>30] valuecolor=[Weather_LastUpdate>120="orange", Weather_LastUpdate>300="red"]
			}
			Frame {
				Switch item=Weather_Chart_Period label="Chart Period" mappings=[0="Hour", 1="Day", 2="Week"]
				Chart item=Weather_Chart period=h refresh=6000 visibility=[Weather_Chart_Period==0, Weather_Chart_Period=="Uninitialized"]
				Chart item=Weather_Chart period=D refresh=30000 visibility=[Weather_Chart_Period==1]
				Chart item=Weather_Chart period=W refresh=30000 visibility=[Weather_Chart_Period==2]
			}
		}
	}
	Frame label="Datum" {
		Text item=CurrentDate
	} 
	
	Frame label="Lüftungsanlage" {
		Text item=Lueftung_Fan_Level label="Lüftung [MAP(level_de.map):%d]" icon="selfAiring" {
			Frame {
				Switch item=Lueftung_Auto_Mode label="Modus" mappings=[1="Auto", 0="Manuell"]
				Switch item=Lueftung_Fan_Level label="Stufe" mappings=[1="A", 2="1", 3="2", 4="3"]
			}
			Frame {
				Setpoint item=Lueftung_Komfortemperatur step=0.5 minValue=15 maxValue=25
				Text item=Lueftung_Aussentemperatur_Message
				Text item=Lueftung_Innentemperatur_Message
				Text item=Lueftung_Ventilator_Message
				Text item=Lueftung_Bypass
			}
			Frame {
				Text item=Lueftung_Filterlaufzeit_Message
				Text item=Lueftung_Status_Message
				Switch item=Lueftung_Control mappings=[1="App", 0="CCEase"]
			}
		}	
	}
	
}

with this in mind, i then grouped the items in my .items like

/*Hauptgruppen */
Group All
Group gEG 			(All)
Group gOG 			(All)
Group gUG 			(All)
Group gGarten 		(All)
Group gJalousien	(All)
Group gWetter 		(All)
Group gStatus 		(All)
Group gSensoren		(All)

/* Erdgeschoss */
Group EG_WoZi 		"Wohnzimmer" 	<living> 	(gEG)
Group EG_Kueche 	"Küche" 		<kitchen> 	(gEG)
Group EG_WC		 	"WC" 			<batch> 	(gEG)
Group EG_Flur 		"Flur" 			<corridor> 	(gEG)
Group EG_Windfang 	"Windfang"		<corridor> 	(gEG)

/* Obergeschoss */
Group FF_Bad 		"Bad" 			<batch> 	(gOG)
Group FF_Schlafen 	"Schlafzimmer" 	<bedroom> 	(gOG)
Group FF_KiZiWest	"David" 		<boy1> 		(gOG)
Group FF_KiZiOst	"Sarah" 		<child1> 	(gOG)
Group FF_Flur 		"Flur" 			<corridor>	(gOG)

/* Keller */
Group UG_Flur		"Flur"			<corridor>	(gUG)
Group UG_Technik	"Technikraum"	<energy>	(gUG)
Group UG_Heizung	"Heizungsraum"	<inverter>	(gUG)
Group UG_Waschen	"Waschraum"		<softener>	(gUG)
Group UG_Party		"Partyraum"		<video>		(gUG)

/* Garten */
Group Garten_N		"Garten Nord"	<garden>	(gGarten)

(...)
Dimmer Light_EG_WoZi_LG1 			"Fernseher [%d %%]"	<selfSlider>	(EG_WoZi, Lights)	{ knx="1/1/0+<1/1/3, 1/1/1, 1/1/2+<1/1/4" }
 (...)

I could, however use the sitemap for the grouping until room-level, also, couldn’t I? So what’s the “best” way to do this?

Thanks for a little help,
Thomas.

1 Like
2

I used .items grouping as in demo to define my sitemap, however I found some problem with dimmer-like or number items - they are always rendered as sliders and numbers, but sometimes I would like to have them as setpoints - and this is not possible to do by items file.

1 Like
3

Assuming that all you want is the default way for the Item to be rendered (e.g. toggle for Switch, Slider for Dimmer, Setpoint for Number, etc.) and you do not plan on using any advanced features like color coding or visibility, Groups is an OK way to go. But if you want to control how they appear on your sitemap you need to define them each separately on the sitemap.

Groups are incredibly useful for a lot of things. But in my opinion, not terribly useful for building sitemaps.

1 Like
4

I try to use groups as much as possible, just because it is simple and things appear without touching the sitemap files once the items or things are there. As mentioned by both @rlkoshak and @Artyom_Syomushkin though, thermostats are examples of things that just don’t make good use of groups, and so, my sitemaps are a mix of mostly groups, but also some non-grouped controls.

Partial example below:

	Frame  {
		Group label="First Floor Devices" 	item=ff
		Group label="Second Floor Devices" 	item=sf
		Group label="Basement Devices" 		item=bs          
		Group label="Outside Lights" 		item=outLights
		Group label="Outlets"			    item=outlet
		Group label="Outside Devices"       item=Outside
	}

	Frame {
	      Group item=Motion
	      Group item=battery
	      Group item=detached 

              Text label="House HVAC [%.1f °F]" item=zwave_device_152e7642b11_node5_sensor_temperature icon="temperature" {
              Setpoint  item=zwave_device_152e7642b11_node5_thermostat_setpoint_heating label="Heat set-point [%.1f F]" icon="temperature" minValue=0 maxValue=90
              Setpoint  item=zwave_device_152e7642b11_node5_thermostat_setpoint_cooling label="Cool set-point [%.1f F]" icon="temperature" minValue=0 maxValue=90
              Selection item=zwave_device_152e7642b11_node5_thermostat_mode label="HVAC mode" icon="temperature" mappings=[0="Off",1="Heating",2="Cooling",3="Auto",4="",5="Resume"] valuecolor=[0="gray",1="red",2="blue",3="green"]
              Text      item=zwave_device_152e7642b11_node5_sensor_temperature
              Text      item=zwave_device_152e7642b11_node5_sensor_relhumidity2
              Selection item=zwave_device_152e7642b11_node5_thermostat_fanmode label="HVAC fan mode" mappings=[0="auto",1="on",2="auto high",3="on high"] valuecolor=[0="gray",1="green",2="green"]
              Text      item=zwave_device_152e7642b11_node5_thermostat_state valuecolor=[ 0="gray",1="red",2="blue" ]
              Text      item=zwave_device_152e7642b11_node5_battery_level
              Chart     item=zwave_device_152e7642b11_node5_sensor_temperature label="House Temp" period=D
         }
1 Like
5

Maybe you can have another point of view:
use the groups to group your items where they belong to:
e.g. the lights in your living room on the ground floor can be set to the group

  • lights_groundfloor
  • livingroom

If you get your groups in such a hierarchical structure, you can put your “top level” group to your sitemap with one row on the main page and you have ALL your items at one/two/three/four fingertips (for a quick check for items you normally do not need on first sight).

My opinion is the same as @rlkoshak said:

I would like to have different views for the sitemap:

  • the “room”-view: all items in the current room to see what’s going on in this room
  • the “items”-view: all lights in the house / on the floor or all temperatures
  • the “expert”-view: all Information which is possible for a device (e.g. zwave theremostat with actual temperature, set point, battery level, last update, …)

If you plan such things with your sitemaps then you would not rely on the order within your items-files to get the order within your sitemap.

Andreas

1 Like
6

Hi Andreas,
THAT’S the sound, you hear, when some major understanding of all the different configuration-Parts come together at one - and you’re realising, that’s an awful lot of work to do - but would also result in a perfect WAF! :joy:
I mean, you could then just have an reduced “daily” room view, just to use the items you use daily, but also the “expert” room view, if you’d like to change some items like heating-temperature.

7

And just to elaborate on this approach, you can create separate sitemaps for each view or you can use subframes and hide everything behind a single element. Since my wife almost never uses the sitemap at all (the highest WAF I can achieve is to not require the sitemap at all) I mostly use subframes in my sitemap. But I have only one case where I don’t want to do something special about how the Item goes on the sitemap (e.g. interject a chart, show a Switch as Text, hide items or change their color) that using Groups to do this is simply not an option.

1 Like
8

It would be nice to add parameter to item, which defines it’s default appearance in sitemap. E.g number could be text, or setpoint. Or dimmer would be a slider or switch.

9

One has to weight this sort of convenience against the problems that it might cause.

Whether we like it or not configuring a home automation system with OH (and probably any other HA system) is programming. A lot is done to hide this fact from the user as much as is feasible but the fact remains, we are programming a system when we configure OH.

That being said, over the decades developers have discovered that code is easier to manage, maintain, and update if there is a clear separation between the user interface (i.e. sitemap in our case) and the rest of the code (Items and Rules). In OH there is already a little bit of overlap because one can define the label in the .items file and set up Groups to populate whole portions of the sitemap. But even this little bit of overlap comes at a cost. How many of us have spent time trying to figure out why their label doesn’t look right only to remember we had overridden the label in the sitemap file? Based on this forum I’d say it happens more than you might think and people have lost hours and days fighting this sort of problem. If there were a clearer separation between the UI and Items no time at all would have been lost.

Then we have the consideration that BasicUI and ClassicUI are the only two of the six (I think I remembered them all) UIs that even use sitemaps. Does it make sense to move a bunch of stuff into the Items (where I posit they do not belong) to support a minority of UIs?

Let’s say that we did make it so one could define all the visual aspects of an Item in the .items file. Have we really saved any work? All the same data that used to be encoded in the sitemap will still have to be put into the .items files so you really are not saving much work. And now that everything is in the sitemap the structure of the sitemap is somewhat lost in the random arrangement of Groups and Items that are placed in the .items files. In other words, now you can look at a .sitemap and have a pretty good idea what the UI will look like but if everything were placed in the .items file you could not, particularly if you used an All Group with subgroups and all you put on your sitemap was All.

How do you handle the case where you have one Item you want to represent two different ways on the sitemap? Take your Dimmer Item for instance? You may want it to appear on your sitemap as both a Switch and a Slider. You can only encode one way in the .items file so do we go back to needing to override it in the .sitemap? Now we are right back where we started.

All this being said, there is a certain logic to putting this encoding information in the .items files. Frankly the fact that we already have labels and icons there and having this ability would make Groups just a little more useful.

But overall I think the negatives outweigh the benefits or at best do not justify what I suspect would be a massive amount of work to the core OH/ESH infrastructure.