Sun Thing from Astro Binding provides surise/sunset times as DateTime. I can’t imagine the situation when date part is needed for such Channels, and weather widget of course prints the whole DateTime which is quite ugly. I tried to add regex profile with \d±\d±\d+\s(\d+:\d+) regex but it still prints the date. I tried different regex patterns with no success. How can I eventually strip the date part?
The same with day duration that is returned in seconds. I created fake Item bound by Blockly Rule that transform seconds into HH:MM. This is way too complicated for such a trivial transformation and I can’t understand why Channel does not return value in immediately usable form. Or did I do something wrong again?
@kanyck I’m using the Type start and Type end channels in my textual configurations, and then can just assign these to DateTime Items with the following value format as an example
"Evenings [%1$tH:%1$tM]"
easily giving me
without much fuss, with such value formatting working on all DateTime types.
With day duration or any other durations in seconds or minutes I use some javaScripts
the channel delivers a data type and if it’s DateTime it simply delivers it. Same with your seconds exmaple. So data type is fully correct, machine readable but I agree - per default ugly to read
Binding developers can define a default state description which converts e.g. x seconds into a UI readable 9h 21m 23s
You as a user can override this state description. Perhaps you want it in german with 9 Std 21 Min 23 Sek
So in UI search your item and open it. Click on Add Metadata and select State Description.
In the pattern add the wanted conversion.
Like in the picture below Unit is seconds and is converted into hour and minutes with
Thanks a lot! It worked and seems nearly as simple as it’s expected to be!
However I still can not comprehend the info under the link you provided – it describes textual .item so I can’t map it to MainUI manipulations. Thus it seems irrelevant
What I also can’t understand is “Evenings [%1$tH:%1$tM]” notion @Hans_Lree mentioned. Is it of any use in my case (building stuff with MainUI). Hans also provided a link, but it says HH:mm[:ss[.SSS]]not %1$tH:%1$tM. I’m completely lost in what should I use and trying to RTFM only adds up to the confusion.
I have a serious issue with the OH docs: it’s still so much oriented on textual configuration that I can’t really map it to MainUI usage. So trying to RTFM only adds up to the confusion… which means that there will be more my posts asking stupid questions. Please be patient… and thanks again!
My main reason for the link was in its first sentence
DateTimeType objects are parsed using Java’s DateTimeFormatter
which can be looked up. And yes, I do use it with purely textual definitions, but the formatting is the same, as you saw, be it for Items for sitemaps or MainUI, hence
@Hans_Lree mentioned. Is it of any use in my case (building stuff with MainUI)
of course it is
Search for Java DateTimeFormatter and now that you know the syntax, with all the different letters’ meaning you can format any DateTime Items exactly as you want, for BasicUI Sitemaps or MainUI alike.
History
openHAB has the legacy build upon text files. I really don’t like them!
My unfortunately not so small system was a mess of textual plus UI configured items, things, persistence, .... Hard to maintain!
End of last year I decided to build it up from scratch. Besides rules and some custom transformations I’ve no text config anymore.
Is it irrelevant?
My personal answer: No!
The description and content is correct. But I can understand as beginner it’s hard to translate the textual config stuff into UI config as you said.
The Evenings [%1$tH:%1$tM] contains already the pattern %1$tH:%1$tM which I posted too.
And HH:mm[:ss[.SSS]] is the standard display you mentioned if no state description is added. You described as ugly, I agree
I understand. I just can explain what’s mentioned but sure I don’t see it from beginners perspective.
My advise: use AI search
If you know the bingo word which is here state description you’ll get a comprehensive answer combined from openhab docs and community posts. Also the UI config is mentioned!
I think I shall put it on my wall. Yet I’m afraid I don’t have enough wall surface for everything I’ll need to have in sight
It’s definitely a part of the problem. MainUI is poorly documented.
Here I used icorrect phrasing. Of course it is but is not seem so from my perspective. That’s what I was trying to say.
That’s another part of the problem. The devs and people who have been using OH for a long time have grown with it gradually and just don’t see the gaps that scares the beginners. For instance, I could not find definitions (or, better, explanations) on lots of notions used in the docs.
I have already. The only issue is that it lies now and then. But it definitely helps nevertheless, thank you!
