This is awesome
Will the relativeTime
of day.js
also result in auto updating the values on screen? For e.g., implementing a clock widget displaying the current hour and minute
AFAIK the refresh gets triggered only on (re)load the page / the parent component currently. That at least is the mechanic that I have observed.
I can imagine that this has something to do with the load this would cause, besides all the other components.
And yes, even without the automatic update, this library is a blessing.
Okay, it’s pretty obvious, I didn’t think about this case before… the current implementation of the repeater defines a new scope for the variables, similarly to personal widgets, so that variables defined for that scope don’t “spill” or “bubble up” to the parents in the tree. In your case this is what you were expecting and, by design, is not happening - you were expecting your variable to be accessible to the whole widget but the repeater blocked it. Since the individual variables are passed by reference and forwarded to the more specialized scope, it’s “only” a matter of either:
- providing a way to initialize variables at a higher level, so they’re defined ahead of the oh-repeater and simply forwarded along;
- moving the repeater’s iteration variables outside the
vars
object, and making sure those are properly propagated to the child components and widgets; - something else…?
Hi ysc, thanks for the detailed explanation.
Indeed it makes sense how you implemented this function, so we can ensure that the variable is only available for the single repeater instance, which makes sense e.g. for normal table processing.
But I think we should also have the possibility to access other variables. In my usecase I have a json string which is loaded when i select a day. Then I modify this in each repeater object or add new objects if needed. The repeater function is modifying the variable i filled by selecting the day. Once all operations are done I can update the json with one single “save” button. If I use your approach i would need to add a save button on each repeater object to ensure that the values are saved.
Maybe it makes sense to somehow change the logic how the repeater uses a vars object. Either using another type of object like repeater.myVar
which i would prefere to ensure that we can seperate this object types. Or using some nested vars for this. e.g. the repeater runs with a for loop and my for has the name minutes
then I could call it by vars.repeater.minutes
.
What do you think about this?
Yes it makes sense to move those iteration variables out of the vars
object and into their own, provided it’s properly propagated to all descendants including popups and so on.
Hello, is it possible to use dayjs in rules/scripts and JS transformation files (in /etc/openhab/transform)? I suppose it’s loaded only in context of the widgets. But any workarounds?
The JS transformation is powered by Nashorn so maybe you can load("{the dayjs library}")
and use it, you’ll have to try.
Don’t rely on Nashorn as a long term solution, it’s been deprecated since.
Thank you! that was super simple.
dayjs_transform.js:
(function(i) {
load('https://cdn.jsdelivr.net/npm/dayjs@1.9.5/dayjs.min.js');
load('https://cdn.jsdelivr.net/npm/dayjs@1.9.5/plugin/calendar.js');
var date_string = dayjs().format();
// plugins need to be extended like this
dayjs.extend(dayjs_plugin_calendar);
var date_string_calendar = dayjs().calendar();
return date_string+" ("+date_string_calendar+")";
})(input)
Same for rules and scripts (without the function and input statements ofcourse)
there is definitely a performance hit. Execution takes anywhere between 500 to 2000+ ms as compared to <100ms with simple JS files. Thats because of loading the scripts in every run.
Hi guys,
I have a coupple of simple questions (or requests) on oh-repeater:
- As far as I understand it is possible to use oh-repater only or with ItemsinGroup or ItemsWithTags.
Is it possible also to use both together? I mean, can I filter only items in a group which have some tags? - Is it possible also to retrive the icons (i.e. items.category) in the future?
- Or in general, Is it possible to filter the results by item.state or tag or label (or label part) ?
- Is it also possible count the number of those items?
These functions will increase the widget possibility and reduce their developing time
Thanks for your answer
Lorenzo
Heads up for those using oh-repeater: I just moved the iteration variables from the vars
object in the context to loop
.
So to access your repeater variables, when before you’d find them in:
vars.{name}
now it’s:
loop.{name}
I know it’s a breaking change but better now than later once we’re made the release.
@Foxejoe you have a map
and a filter
config property that allows to filter the result.
It works like this:
source => apply filter => apply map => final array
source and map are expressions but shouldn’t use the = prefix (as stated in the description).
So it’s possible to use e.g. the itemsInGroup source type and then add filter: loop.item.tags.indexOf('mytag') >= 0
Or the other way around: use itemsWithTags source type and then add filter: loop.item.groupNames.indexOf('mygroup') >= 0
.
If you get an array of items you can retrieve the category.
To count them, you can use {name}_source.length
where {name}
is your iteration variable (the for
parameter).
Oh, good to know - will this be part of the RC1 release today?
Yes - https://github.com/openhab/openhab-webui/pull/639
It solves the problem above of variables set inside the repeater not propagating up the tree.
It also adds itemStateOptions
and itemCommandOptions
as a source type for the array.
component: f7-card
config:
title: =vars.sleep
slots:
default:
- component: f7-card-content
slots:
default:
- component: oh-repeater
config:
for: option
sourceType: itemCommandOptions
itemOptions: MusicCastSalon_Sleep
containerClasses:
- display-flex
- flex-direction-column
slots:
default:
- component: oh-link
config:
text: =loop.option.label
action: variable
actionVariable: sleep
actionVariableValue: =loop.option.label
Hi, I used the OH-repater in a custom widget that I open with a modal action.
While the modal sheet is open, the items state are not updated, I have other widget with items create not with oh-repeater and they are normally updated also in a modal action.
I just notice today, I am on Build 2111.
Is it my failure or this is how it works?
Regards
Lorenzo
Just wondering. How can i go about inplementing this to an item. and then run a rule to turn items on or off?
Do I understand it right that if i want to fill widget with data automatically, like autofilling a widget with temperature, humidity and all other properties, the only way this could be done is a run of oh-repeater with itemsInGroup: roomgroup
and then run another oh-repeater under this repeater with itemsWithTags
or run oh-repeater with itemsInGroup
and filter: loop.item.tags.includes('Temperature', 'Measurement')
multiple times? Is there another way to fill a room widget, not related with naming schemes (it would be a pain to proceed hundreds of items already created and used in dozens of rules)?