[SOLVED] Sitemap: un switchable items

Setup, Configuration and Use Items & Sitemaps
1
  • Platform information:
    • Hardware: QNAP TS-253A (Intel N3160)
    • OS: QTS 4.4.1 (64-bit)
    • Java Runtime Environment: QJDK8_1.8.201_x86_64 from Qnapclub
    • openHAB version: 2.5.1

I’ve used Network binding to create an entry for one TV, just to know when it 's powered on/off and act as a trigger for some rules. I have this info both in Paper UI and Basic UI. In Paper UI I’m not able to change the switch (and this is correct), but in Basic UI I can. Of course it has no effect and some time after it assumes the correct state. But this is confusing to non-techie users (such as my wife). How can this be avoided ?

Here is my items entry

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

Thanks a lot.

2

Text item= instead of Switch item=

2 Likes
3

Why does that matter? The Paper UI is not used for everyday control anyway. It is only for openHAB administration.

4

Never liked comments like that - if someone finds utility in it, then let them use it. I personally use it as my main way of controlling everything. I find it much nicer than sitemaps and does exactly what I need it to do…

5

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.

6

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
7

@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).

8

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.

9

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

10

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…

11

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

12

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
13

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

1 Like
14

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.

15

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

2 Likes
16

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
17

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

2 Likes
18

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

19

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:

20

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