[SOLVED] Sitemap: un switchable items

If it works for you, fine.
Development on it basically ceased when the enterprise employed developer abandoned it and no other developer here was familiar with it.

Those statements tend to occur when it doesn’t work just fine for some user and they want to customize this or change how that appears or the like. So the answer is always going to be “you can’t do that, PaperUI wasn’t made to let you do that, that isn’t it’s purpose.”

1 Like

@rlkoshak

Fully agree with you - what I was disagreeing with is the statement “It is only for openHAB administration”. That’s simply untrue - yes the level of customization is very low with paperui but it’s not simply used for administration. Beyond providing tangible user benefits, I find it invaluable as a binding writer as well (and I ensure my bindings act/look good for paperui as well).

Personally, I would never give PaperUI to guests or a family as their interface to the home automation. There is too much power to accidentally mess things up and the vast majority of the interface is irrelevant to anyone except for the OH administrator.

Development of bindings falls into the same category as administration. It’s not something one presents or asks their six-year-old to figure out and use.

For day-to-day use by people other than the openHAB developer/administrator, PaperUI is not suitable as a UI.

That is why it has already been removed from OH3, I believe.

Wow - you two are totally missing the point. Didn’t say it was suitable for everyone (nor even a majority) - what I was saying is that to make a statement like “It is only for openHAB administration.” is incorrect as there are people that use it as a UI (like me and quite a few others in the sony forum).

As for the removal - the reason it’s being removed is because it’s being replaced by paper-ng (which I look forward to - anything better to get rid of sitemaps!). Personally - I’d like to see habpanel become the default as it’s so much more friendly that any other ui right now…

I took a quick look and could not wrap my head around configuring it. That is more friendly??

Should have said “friendly to the end user” :slight_smile:

However, there are so many widgets available to it now - I’d even argue its pretty easy to configure now (install widget, add/move widget, use widget).

EDIT: btw - the one real virtue of paper-ui is the lack of configuration (and it’s one big downside as you two have mentioned). I love how I can instantly be productive without having to come up with editing/installing files and know syntax of the file for that UIi…

1 Like

<ahem> Have you accomplished the difficult task of making your switches into display-only in the UI? Please mark the solution.

1 Like

Thanks. But does not work in my case. Here is my sitemap

sitemap aveiro label="Casa Aveiro" {
   
	Frame label="Parâmetros" icon="groundfloor" {
		Switch item=GlobalSetting mappings=[OFF=Ausente,ONW=Inverno,ONS=Verao]
        Text label="Climatização" icon="snow" {
            Default item=GF_LivingDining_AirCon label="Sala"
            Default item=GF_LivingDining_Stove label="Sala"
            Default item=GF_Kitchen_AirCon label="Cozinha"
            Default item=FF_MasterBedroom_AirCon label="Suite"
        }
        Text label="Temperatura" icon="temperature" {
            Default item=GF_LivingDining_Temperature label="Sala"
            Default item=GF_LivingDining_Stove_Temperature label="Lareira"
            Default item=GF_Kitchen_Temperature label="Cozinha"
            Default item=FF_MasterBedroom_Temperature label="Suite"
            Default item=GF_Terrace_Temperature label="Quintal"
            Default item=FF_Outside_Temperature label="Rua"
        }
        Text label="Tomadas" icon="poweroutlet" {
            Default item=GF_LivingDining_Power label="TV & Rádio"
            Default item=FF_MasterBedroom_Power label="Toalheiro Suite"
        }
    }

	Frame label="Rés do chão" icon="groundfloor" {
        Group item=GF_Kitchen
        Group item=GF_LivingDining
    }

    Frame label="Primeiro andar" icon="firstfloor" {
        Group item=FF_MasterBedroom
    }
}

This TV is in the GF_Kitchen group. It displays together with other items that I have in the kitchen. Some of them can be switched on/off by OH but the TV can’t. So having a switch symbol that can be actioned is confusing. As said in my original post the correct state is displayed in the next refresh cycle of the network binding.

My wife has no access to Paper UI. Only myself, and only for administration. Paper UI shows my TV power as switch that’s why I’ve created a switch item. My problem is that Basic UI allows you modify the switch value, and I think that this should be forbidden given the fact that this should be considered more as a contact and not a real switch.

You can’t achieve your goal with groups.
You need to define your items individually.

2 Likes

Thanks. I will create a 2nd item for the same TV and will not display it in the sitemap. And will create a new rule that whenever the first item is changed it will revert automatically to the value of the 2nd item, without having to wait for the refresh.

It would be “cleaner” if Basic UI ignored the value change request instead of having to develop a rule…

Items

Switch GF_Kitchen_TV "Televisão" <smarttv> (GF_Kitchen) ["Switch"] {channel="network:pingdevice:10_100_10_192:online"}
Switch GF_Kitchen_TV2 {channel="network:pingdevice:10_100_10_192:online"}

Rule

rule "Ignore power command to kitchen TV"
when
    Item GF_Kitchen_TV changed
then
	GF_Kitchen_TV.sendCommand(GF_Kitchen_TV2.state)
end

Displaying your items without groups would be a far better option as you have better control.

2 Likes

Probably yes, but then what’s the purpose of groups ? For sending commands only ?

If you don’t intend on a special order of your items on your sitemap you can use groups for displaying, too.
Otherwise you will find group use cases in the docs:

From the fine manual :wink:

The Group item is commonly used to define hierarchies of Items from different perspectives. For example:

  • Location-oriented or physical perspective:
    • Floors in your house → Rooms on that floor → An appliance in that room…
  • Functional or logical perspective:
    • Maintenance Group → All battery states → Individual battery states in percentage
    • Further examples: all lights, all room temperatures, combined power consumption

These relationships can be exploited in Sitemaps or in automation rules to navigate through the hierarchically organized Items or to perform computations and updates on subsets of similar Items

Thanks.

I also have “read-only” switches (e.g. smoke detectors).
To see them in BasicUI as readonly I used 2 things:

  1. Used mappings to be able to map ON/OFF state to string
    Switch KitchenSmokeDetected "Smoke detected (Kitchen) [MAP(SwitchPresence.map):%s]" <fire> (gEmergencyDetectors,gSmokeDetectors) {channel="mihome:smoke:158d0002b0b1c6:alarm"}

Content of conf/transform/SwitchPresence.map is

ON=Yes
OFF=No
NULL=Not set
UNDEF=(not defined)
-=?
  1. Using Text type in sitemap
Text item=KitchenSmokeDetected

And it looks like this:

1 Like

When you use the Group widget for display in sitemap, you are stuck with default displays for everything. No mappings, visibility, colour options; no choice of item ordering.
It’s a quick fix to get you started and most people soon abandon the use - for display

It often seems little understood that you can get the same “one line” display that is clickable to expand to a new page sub-items like this:

Text item=myGroup {
   Switch item=switchA mappings=[ON="fred",OFF="mary"]
   Text item=switchB icon="bell"
}

More tedious (once), more flexible, more precise.

3 Likes

I’m at a very early stage in what concerns OH use, my first goal is to have everything working, so for the time being I will continue with group display, but soon I will optimize and your suggestion will be very usefull.