Sadly I don’t have a soloution for you. But as it seems, it’s only affecting variable-actions. I tried to send your command to an item and this works fine:
So, you could create a dummy item, which acts as a variable until @ysc makes us smarter
btw - some good news from my side (as I’m not working with variables in my widget):
I reduced the code from ~1.000 lines of code to 400 and additionaly it’s much more flexible in regard of adjustments.
@RGroll thanks for the information, then I need to use a dummy item at the moment.
I’m very interested how I can reduce my code I think my sonos widget can be written in less than the half size. My heating control was finished yesterday. Now I have to redesign this for oh-repeater as well. Currently it uses 2200 rows, lets see how many i can remove with oh-repeater
If we’re on this topic anyway, theres a strange behaviour in my horizontal swiper - on the 2nd attempt to load/initialize the swiper it gets loaded on the last swiper-element. (despite that I’ve defined an ‘observer’ (to re-initialize on every show/hide) and ‘initalSlide: 0’ as a swiper parameter)
Everything works fine on the first initialization and wasn’t a problem before (before implementing oh-repeater, so there might be a context)
//edit
It seems that the *.gif file upload here is still broken on large images (>3MB)…
I noticed another strange behavior with the f7-swiper. On the swiper we can define how many elements should be loaded per view. But if you use an oh-repeater inside a swiper, all elements in the oh-repeat will be noticed as the first element inside the f7-swiper. So it will not limit the items to load because the swiper is only recognizing one element (in this case the oh-repeater) and not serval.
Maybe this is because the swiper only knows the div below and the repeater elements are nested in this div.
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
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;
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.
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?
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).
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.
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.
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)?
