NOTE: Mind the rules. If you have an alternative implementation, please post it in a separate non-marketplace thread or send me a PM to talk about incorporating your changes to the original. Do not post requests for generic help to this thread. It is only for support for the widget in the original post.
A dynamic standalone widget that will present the minimum battery level of all your batteries along with each individual battery’s level as a separate row in a list.
Optionally, batteries above a certain level can be hidden so the only ones you see are those that are low. By default all the batteries are shown.
The level the icon and color changes between green (default 60), orange (default 30), and red can be configured through the optional parameters.
If you include fetchMetadata: widgetOrder in the repeater’s config they will be ordered based on this metadata (“Default Widget Order Index”). I’ve been made aware that there’s a bug in that comparator function so indexes are compared as strings, so it goes like this:
-1 < 0 < 1 < 10 < 11 < 12 < … < 2 < 20 < …
You won’t run a problem until you use indexes < 10 and => 10 at the time.
I get this error trying to install
I’m using Metric and region Sweden, 24h clock
I just Copy/Paste the YAML to a widget, and its working
Thought I let you know…
EDIT: I just noticed that it is on more than this one, so not an error with this widget
should move this to the proper place, sorry
2021-10-30 10:14:08.759 [ERROR] [munity.CommunityUIWidgetAddonHandler] - Unable to parse YAML: Cannot deserialize value of type `java.util.Date` from String "Oct 28, 2021, 10:52:35 AM": not a valid representation (error: Failed to parse Date value 'Oct 28, 2021, 10:52:35 AM': Unparseable date: "Oct 28, 2021, 10:52:35 AM")
at [Source: (StringReader); line: 37, column: 12] (through reference chain: org.openhab.core.ui.components.RootUIComponent["timestamp"])
2021-10-30 10:14:08.764 [ERROR] [munity.CommunityUIWidgetAddonHandler] - Widget from marketplace is invalid: Unable to parse YAML
@ysc Thanks for the hint. But a little bit too much effort for my use case. I thought more or less about a dynamically ordering based on the item state. I am already working on a solution. Give me some days to create a PR.
@nisseDILLIGAF I have the similar problem in my environment. I already opened an issue to track it:
@rlkoshak thx for this widget! For the badge text, you use badge: "=(loop.item.displayState === undefined) ? loop.item.state : loop.item.displayState", but as far as I know displayState is not supported in a loop? Or am I doing something wrong?
In the header text, displayState is working fine.
I couldn’t say except that it works for me. However, there is no displayState if you’ve not populated the Item’s State Description metadata with a pattern.
And in that case that line of code will choose the state instead of the displayState. So even if the displayState were not supported, which wouldn’t make much sense, it should still work and show you the Item’s state. If it’s not working something else must be wrong.
A State Description metadata is indeed needed to use displayState, but displayState seems not usable in a loop. I already noticed this before, but since I saw it in your code, I though there was another way.
In a normal component (eg oh-list-card), the items show me a state and displayState
In a oh-repeater and with the use of a loop, I get name, label and state
For me, this different behavior is not very clear.
In this case I can just add a % in the widget (loop.item.state + ' %' ), but it would be nice if we can use displayState
That that was it Rich. I didn’t even know you could, thanks for the pointer!
One other question, to round the number values to 1 decimal place. I have added a Metadata stateDescription and added %.1f to the Pattern field. But it does not seem to be working? Is there something simple I am missing?
Mine are also coming from MQTT, all my items have a state description ("%s %%"), but none of them are showing in the widget… I actually have this issue with all my widgets where a repeater is included.
Then that thread doesn’t apply. The issue in that thread you linked to is when the binding supplies a state description which sometimes overrides the State Description metadata. The MQTT binding doesn’t do this.
In my case the values from the GPS binding are displaying rounded to a whole number where as the values coming from the iCloud binding are coming through with 15 decimal places, a little more accurate than needed for battery levels.
I might run the raw values through a rule every 10mins and display a proxy item.