Your example above will solve the issue when all values/labels are stated in the itemsStateOptions.
I have another case in which lots of individual commands will have to be gathered in the format command = mode in e.g. a map file for MAP transformation.
I figured out that “sourceType: map” is possible.
But how to make the MAP transformation work inside the oh-repeater?
(Maybe I should just use a dummy item for that and go with itemsStateOptions…)
I don’t think you can access transformation services from here.
But a MAP transform isn’t really what you want anyway, you’ve been distracted by the xxx.map file looking like a list.
A MAP transform takes a single value as key and returns a single string to you. There’s no way to examine or iterate the lookup file content.
Example mylist.map
ON=green
OFF=red
BANANA=yellow
You’ve got no way to find out the list is ON,OFF,BANANA which I think is what you’re after?
As @rossko57 said, the map transformation of the oh-repeater doesn’t seem like the right choice here.
But try to describe your scenario a bit more, maybe there are other ways to achieve what you’d like to see.
I’m working on a widget to control my pretty old (2010) Denon AVR via the Denon/Marantz binding. The binding is very useful, since it allows to send commands via telnet.
There are a few basic channels that also work with my AVR as they are - e.g. Power on/off, volume, input source.
Some of the channels are “Read” channels, such as “Surround Program”.
In order to set the correct Surround Program" I can use a special “Write” channel (general#command).
I have around 15 commands to change the surround mode e.g. MSDOLBY DIGITAL=DOLBY DIGITAL.
I created an item linked to the command channel, I can send individual commands successfully, but when I tried to collect all commands in the items metadata, itemStateOptions didn’t work. I guess I will have to try this again tonight, since this should work.
Hence I have:
8 Input sources
15 Surround Programs
Ideally I would like to have an f7-picker to select the correct modes, but f7-picker doesn’t seem to be working in Main UI…
Am I right?
That’s why I would like to distribute buttons to multiple rows… that’s where the MAP transformation could have helped. I understood from @rossko57 and you that this is not possible.
Your suggestion…
in combination with the above from @JustinG is the smartest way to solve the issue = already solved for 8x Input source.
I will need to get the command issue for the surround program with itemsStateOptions working.
Will try this later today…
It is (I think) - but it would be too easy giving you a solution, so I think this is a good challenge for you, if the above variants doesn’t fit your needs.
The map parameter in the oh-repeater is not about the map transformations in your config folders, that’s just a coincidence of terminology.
map is not an accepted value for the ‘sourceType’ parameter:
What map refers to in this case is an expression that can be applied to each value in the repeater’s array (after the filter is applied) that transforms the final element value. My small example widget from above could achieve exactly the same results using the map parameter to do the string building instead of doing it at the level of the label text:
component: f7-card
config: {}
slots:
content:
- component: oh-repeater
config:
for: fish
sourceType: array
in:
- name: Fish 1
color: Red
- name: Fish 2
color: Blue
filter: loop.fish_source.indexOf(loop.fish)>=1
map: loop.fish.name + " = " + loop.fish.color
slots:
default:
- component: Label
config:
text: =loop.fish
Tried to find a way to add a horizontal line as a divider or separator and just found the following which is probably a bit of a tweak rather than a good solution:
- component: f7-card
config:
outline: true
showing up in the UI:
Is there a more elegant way to add horizontal lines?
Can’t say if it’s a bug or a known limitation, but It’s exactly that - expressions does not work inside the oh-repeater array definition. You could open an issue for that on the webui repo on github.
You can use the widget vars object to pass values between different components within a widget. OH components with actions will have the variable option to set a variable value that can then be accessed in expressions throughout the widget. Here’s an example that uses two button created by a repeater to set two different variables to control the visibility of two different labels.
Yes, I am aware of the above described solution.
Thank you.
However, I’m looking for a solution to do this across widgets = on widget level instead of “component within a widget”.
(button in widget “Dashboard” triggers visibility of widget “Dreambox DM8000”)
So if you use a proxy item that is toggled by the first widget (or if you already have some item that is keyed to the event that you want), then the visibility of the secondary widget will be dynamic.
Something Yannick wrote a while back (I don’t remember where) made me think that it might be possible to have a vars object in the page scope, but I’ve never managed to make it work and proxy items work just as well.
I would want to feed a oh-repeater automatically from the semantic model and group/filter the items, whereas the grouping/filtering is the challenge I have.
Example for “Lights” based on “Point_Control_Switch” and “Property_Light”:
This adds all lights to the repeater irrespective of its location.
I’d wish to group the lights based on location. e.g all light in groundfloor or all lights in a certain room.
I thought that I could just add the tag “GroundFloor” to “itemTags”. But this doesn’t work.
I can see there is “itemsInGroup” as well… maybe using “itemsInGroup” could be used an then filter with “itemTags” - but how to apply such a filter …
What would be the best way to group “Lights” by its location?
This direct capability doesn’t exist. There’s just too much complexity (layer’s of hierarchy between higher model locations and points) and variability in the semantic model to make this easy, and the repeater’s collection of objects via itemsInGroup or itemsWithTags depends on the data returned via the api which doesn’t have any semantic filtering.
You can either create your own groups as suggested by hmerk or, if your semantic model is consistent enough, stack repeaters together. If I were to do something like this I would start with one repeater that is a hard coded array of the rooms I’m interested in:
This isn’t too problematic from a maintenance standpoint because the physical structure of the house isn’t likely to change too often. Then inside this repeater a second repeater with sourceType: itemsInGroup and groupItem: =loop.room.name which then filters for the equipment tags you are interested in (Or the other way around: gets the source list by tags and then filters by group membership). This repeater then populates the widget items accessing the actual points via a consistent nomenclature (e.g., loop.childItem.name + '_Switch' or whatever your nomenclature is).
