Probably not.
By convention in OH if a light has a color channel then that channel is represented as an HSB measurement or control. HSB stands for Hue Saturation Brightness so a color channel also allows you to control Brightness. And indeed On/Off which maps to Brightness being zero or some positive value. So according to this OH convention if there is a Color channel it is necessary neither to also include an additional Brightness channel, nor to also include an additional On/Off channel. And therefore in support of this OH convention it considers the Color HSB channel to be one light in the summary card, but if you also include such superfluous extra Brightness channel then the summary card will show two lights.
The solution is either a) don’t attach a Brightness item to the superfluous extra Brightness channel, or b) remove the tag from that superfluous extra Brightness channel Item.
Thanks for the feedback. What exactly is “superfluous extra” here?
I use the switch to turn the light on and off, and I use the slider to adjust the brightness as needed. I don’t want to have to fiddle around when turning it on until I find the right brightness level, and besides, I’d have to remember that setting for each light.
I also want both to be sorted accordingly in the generated tiles, so that I can see all the brightness sliders in one place and all the light switches in the other.
This solution isn’t a solution for me.
You link three Items to the same HSB color channel as follows:
So if you still want to use three different channels then remove the tags from one of more of your Items.
I’m afraid I don’t understand what you’re trying to tell me.
I only have a brightness slider and a toggle switch. I don’t have any colors. Maybe you’re confusing them with the roller blind sliders?
As soon as I remove a tag, the item no longer appears in the “Brightness” or “Light” summary, where I want to have all items of the same type.
Apologies, I misunderstood your original post. But let us try to address you issue more generically..
General Summary of Tags
Tags are instructions that tell the system how Items or equipment (Things) shall be amalgamated or summarised. If you feel that your amalgamation or summary has items or equipment in the wrong place or double counting them, then the only solution is to change those instructions by changing your respective tags. The system can only do what you tell it to do.
Location Card Specific use of Tags
The Location Card has a certain logic that tries to include all entities that “look like lights”. Its purpose is to summarise lamps on the almost infinite variety of different user’s systems that each have their own special tagging scheme. I agree that as such it does indeed tend to be over- rather than under- inclusive; that was a conscious choice of the designers. Nevertheless the essence is that to specifically exclude “something” from that amalgamation logic, one must change tags or remove the tags on whichever “something” is causing it to be wrongly included.
As far as I recall the Location Card looks for Things with an EQUIPMENT == “light” type tag, and/or Items with POINT == Control/Switch/Status plus PROPERTY == “light” type tag. So I suggest you try tweaking the EQUIPMENT tags on your things and/or the POINT+PROPERTY tags on your Items.
e.g. change Switch+Light => Switch+Power (say) or Control+Brightness => Control+Illuminance (say) .. just to throw in some possible ideas..
If you want to understand the Location Card logic the following links might help (read it in conjunction with the OH tagging schema).
One point here:
The tags are always applied to items. Things may have default tags coming from the binding channel definitions, but that only applies that tag to the item when it is created in the UI. There is no obligation to keep it there.
An equipment tag would normally be found on a group item, containing one or multipe child items. A thing has a very specific meaning and it gets confusing when we mix terminology.
The logic of the location cards indeed tries its best to identify the lights, but it follows some generic logic that is not always applicable. However, it should not double count if you have point items as part of the equipment group item (i.e. it will not count both point and equipment). What it will do is count multiple light type points items inside the same equiment. You should only tag one point item if it represents the same light. An equipment is allowed to contain multiple “lights”, e.g. this is often the case for central control systems, where the control unit is the thing and gets created as an equipment and the individual lights are all channels on that thing, mapped to point items.
The important part remains: only tag a single light once in your system.
Many thanks Mark
thank you both, @AndrewFG and @Mherwege fir the detailed answers.
I’m trying to make sense of the information; at worst, I’ll just accept that two lamps are counted—I’ll just have to remember to divide that number by two in my head.
When it comes to sorting, it’s important to me that “Brightness” and “Lights” are grouped together, and that everything is displayed under “Location” so I have room-specific access.
I would have expected (as the AI said 
) that only one piece of equipment is counted per location.
I’ll take another look at this over the weekend when I have more time. Thanks!
If you want to share your Item definitions (Item > Edit > Code) we can probably make some suggestions. Say for the lights in “Kind 1”
I’d be happy to accept the offer 
version: 1
items:
Kind1:
type: Group
label: Kind 1
icon: bedroom_orange
groups:
- Obergeschoss
tags:
- Bedroom
version: 1
items:
KNX_OG_Dimmaktor_1_Licht_Kind_1_Dimmer:
type: Dimmer
label: Licht Kind 1
icon: light
groups:
- alleLichterOG
- Kind1
tags:
- Brightness
- Control
(Funny, I just noticed that “Light Child 1” (the light switch) is also in the group for Child 2. But it doesn’t show up there…)
version: 1
items:
KNX_OG_Dimmaktor_1_Licht_Kind_1:
type: Dimmer
label: Licht Kind 1
icon: light
groups:
- alleLichter
- Kind2
- Kind1
tags:
- Light
- Switch
Finally, here’s a screenshot of the Properties homepage I mentioned. Both items are currently listed there.
I just noticed in the “Home Page” definition that I also specified an expression for the blinds there.
Here, I can simply split the lights into two parts in the “Locations” where I have sliders and switches.
Kind1:
- component: oh-location-card
config:
backgroundImage: /static/backgroundImages/Kind1.JPG
backgroundImageStyle:
filter: brightness(60%)
badges:
blinds:
expression: Number.parseInt(state) > 0
But I am afraid, that this is not working:
light:
expression: "=Number.parseInt(state) / 2" // doesn't work
light:
expression: Number.parseInt(state) / 2 // doesn't work
I think this is the important part: “it tries its best”. I had started the discussion a while ago with the same question @anli had just raised. The semantic model and the construction of the location cards need to follow a pre-defined process. The team put a lot of effort implementing the heuristic which tries to resemble a consistent and broadly accepted user experience.
However, it is and cannot be a 100% fit for all. I do have similarly organized my items into the model as @anli which generates the same (for me unwanted) effects.
One option to mitigate could be an additional config parameter (e.g. custom metadata) to give a factor how many times this item should count as that property (here Light). With that @anli and I could set that property to 0 (zero) for a light switch to prevent double counting if a secondary light item is also included to the same location. It would also allow to set to >1 if a single control manages multiple lights (e.g. a row of ceiling lights). Sure, that this could also be seen differently, but in my opinion 10 ceiling spots could also count as 10 lights rather than 1 just because they are controlled by the same device. I appreciate that this could be seen as a strange logic, but hey…
I also do have similar concerns with the strict semantic model - e.g. a point could only belong to one location or another equipment, but not both. As of now this only generates warnings which I can easily ignore. But if in future the model is enforced, I am stuck. Reason is, that I create equipments for all channels of each physical device. However, I do only want to expose certain items in the location cards instead of the full equipment group. In addition I do have grouped all equipments of one physical building under a main generic “Devices” equipment grouped by types (e.g. Lights, Thermostats, HAVAC, Media, Blinds, Switches, etc). This is also inconsistent to the model. I have done that to group them under the building. If I just use groups, they get cluttered below the model and are no longer grouped. But this could be due to my lack of knowledge of the way openHAB works. I thought “Show non-semantic” would help me with that, but I do not see any difference at all. I’d appreciate if someone could help me with that. Maybe creating a virtual group would help to collect all those items…
Again: this is my personal way of thinking and organizing and definitely not the one and only.
Cudos to the developers. They have done and are doing a great job to develop and maintain this great system. Knowing that each design decision will have its pros and cons, I am happy that overall a good one well balanced approach has been chosen. MANY THANKS FOR THAT!
Cheers
Michael
The basic rule remains, only one item with semantic point tags per light. The UI visualization is a different topic. What leads to the confusion is the default widget being applied, and therefore the tought you always need multiple items. Maybe you can try setting a default widget for that item inspired on: Location Cards seem to include semantic property `Brightness` into count of Lights (badges) · Issue #3661 · openhab/openhab-webui · GitHub
Now that’sa nice approach indeed. I was also ever since struggling with the same problem (multiple lights shown on location card where there is only one physical light in the room) but this seems like nice way to resolve the issue. Thanks for sharing that!
Hi, is the enhanced List item Widget working for you? I only See the toggle when Applied to a brightness Channel but don’t get the caret to expand to the slider…
Any hints would be appreciated
Michael
Actually I haven’t tried the linked widget. I still got the custom widget on my to-do list but haven’t done anything yet.
Hi all, I still don’t get the suggested light_control_list_item working correctly.
When I set in Developer Tools → Widget the property to a brightness item he preview looks correct and seems to be working correctly:
However, set as default widget it does not show the triangle to expand to the dimmer item - there is only the switch:
Any idea to debug or provide more information?
Many thanks for your input
Regards,
Michael
If you show your widget code this should be easy to fix. The problem is almost certainly a missing accordionList property, but there are other possibilities.
Hi @JustinG, I have taken the widget from the market place as provided. It seems to be working fine in the Widget editor when I manually assign a brightness item in “Set Props”. But when shown in the location badge, it only shows the switch.
version: 1
widgets:
light-control-list-item:
tags:
- color
- list-item
- marketplace:167937
- toggle
- dimmer
- light control
props:
parameters:
- context: item
description: Dimmer or Color Item to control
label: Item
name: item
required: true
type: TEXT
groupName: widgetSettings
- description: Title of the <code>oh-list-item</code>
label: Title
name: title
required: false
type: TEXT
groupName: widgetSettings
- description: Footer of the <code>oh-list-item</code>
label: Footer
name: footer
required: false
type: TEXT
groupName: widgetSettings
- description: Icon name (e.g. <code>oh:light</code>)
label: Icon
name: icon
required: false
type: TEXT
groupName: widgetSettings
- description: Use the state of the Item to get a dynamic icon (for openHAB icons only)
label: Icon Use State
name: iconUseState
required: false
type: TEXT
groupName: widgetSettings
parameterGroups:
- name: widgetSettings
label: Widget settings
description: When using as "Default List Item Widget", leave all properties empty; Main UI will populate them automatically.
component: oh-list-item
config:
title: =props.title || props.item
item: =props.item
icon: =props.icon
iconUseState: =props.iconUseState
footer: =props.footer
accordionItem: true
slots:
after:
- component: div
config:
style:
display: flex
gap: 0.5rem
slots:
default:
- component: oh-colorpicker
config:
item: =props.item
openIn: auto
visible: "=items[props.item].type === 'HSB' ? true : false"
- component: oh-toggle
config:
item: =props.item
accordion:
- component: oh-list
config:
style:
margin-left: calc(2*var(--f7-list-item-padding-horizontal) + 3*var(--f7-typography-padding))
margin-right: calc(var(--f7-list-item-padding-horizontal) + var(--f7-typography-padding))
slots:
default:
- component: oh-slider
config:
item: =props.item
min: 0
max: 100
step: 1
label: true
scale: true
scaleSteps: 5
scaleSubSteps: 5
unit: "%"
style:
height: 80px
overflow: visible