Profile transformation into other types then String

[Mamut (Peter Prochazka)]

@rlkoshak

So, if we assume that it can be possible some times to transform whatever is coming from a device into a String that is suitable to populate any one of the Item types, you should support them all.

String is easy any thing is convertible to string - but string les usable later
Number are easy too because thay not have formating except decimal separator in some local use comma (like mine) and other use dot (like english). You may converty any string to decimal number freely with aditional formating information

Date is hard because each locales and techlogy may have diffrent format (dd.MM.YYYY or YYYY-MM-dd, 12/24 hours). with additional information it can be easy formated.

For Switch and contact you need just hint what mean on or closed any other string values are oposite state.

For color you need to now thre is 3 number how separted ? and what they means HSB or RGB ? are they in decimal format or hexadecimal ? …

and so one

This why I think about formating hint for “type convertor”.

Easy way is put into formating also requeste Target type and formating without any “automatic detection” of target item.

This featury I can provide in couple of hours for all transforamtion and we may have it soon as posible if the commit is accepted.

Or we may spend more time a prepare super duper generic without “formating hint”,but automatic solution, but we may have it 3.0.0 because it requeres changes in core classes.

[rlkoshak] do you know somebody from OH team (older developers) who can decide what is better for OH?

[rlkoshak (Rich Koshak)]

@Mamut

This why I think about formating hint for “type convertor”.

But all of this is already handled by the transformation. You are proposing an additional transformation on top of the already existing transformations.

I’m saying, from a usability perspective, don’t. Don’t recreate the wheel. There is already code in place to handle all of these parsing complications. I can right now send “2020-01-16T12:21:00Z” to a DateTime and it will be parsed and populate the Item.

It’s not your job to parse the String returned by the transformation. Just pass it to the existing code that parses it already and if it doesn’t work, report an error.

Don’t invent new “acceptable” formats for every type. Just let the existing formats exist. It is the user’s job in the transformation to convert whatever is coming in into a format that is suitable for the Item type being used.

@Mamut

Number are easy too because thay not have formating except decimal separator in some local use comma (like mine) and other use dot (like english). You may converty any string to decimal number freely with aditional formating information

Numbers are not so easy when you have to deal with Units of Measurement. But it’s not your job to worry about commas or points as separators. The transformation must return a String using whatever OH requires. If it doesn’t it’s an error and the transformation needs to be adjusted. Don’t provide yet another, different, and unique within the openHAB ecosystem way to transform the value. That leads to confusion, frustration, and inconsistency.

@Mamut

Date is hard because each locales and techlogy may have diffrent format (dd.MM.YYYY or YYYY-MM-dd, 12/24 hours). with additional information it can be easy formated.

Date isn’t hard. OH currently supports ISO 8601. The String returned by the transformation must be in ISO 8601 format. If it is not, the transformation needs to be adjusted.

@Mamut

For Switch and contact you need just hint what mean on or closed any other string values are oposite state.

That’s what the Map transformation is for. No hint required.

@Mamut

For color you need to now thre is 3 number how separted ? and what they means HSB or RGB ? are they in decimal format or hexadecimal ? …

OH only supports H,S,V format using integers. If the value isn’t in that format, the transformation needs to convert it into that format.

@Mamut

This why I think about formating hint for “type convertor”.

That’s not your job. You are duplicating something already built into this profile. At most, your job might be to do some preliminary checks that the String you get from the transformation is suitable for the Item type. But if it isn’t, than it’s an error. It’s not your job to provide an additional way to transform the data.

@Mamut

This featury I can provide in couple of hours for all transforamtion and we may have it soon as posible if the commit is accepted.

I strongly disagree with this approach. Its duplicative, confusing, inconsistent, and it doesn’t solve the original problem of being able to take the output of the transformation profile and apply it to any Item type. You are solving a problem that has already been solved, and not solving the original problem.

@Mamut

[rlkoshak] do you know somebody from OH team (older developers) who can decide what is better for OH?

I’m not a maintainer but I strongly recommend you open an issue before spending too much time coding something. They are the ones who will need to approve a PR.

[Mamut (Peter Prochazka)]

Thanks constructive
Need more time to think how to enhance the profiles and follow “the right way”.

This why I open this set of questions .

[rpwong (Russ)]

Hi @Mamut! I’m an OH user with basic coding skills (one of many), and I mostly learn by doing and following examples. I appreciate that you’re trying to simplify something for future users, but I’m inclined to agree with @rlkoshak that having multiple approaches to transformation is not desirable.

My perspective is that there are a lot of things that are easy to figure out in OH, and a lot of things that are hard to understand. Many new OH users with my level of expertise don’t realize that they need to do those easy things first so that they can progress to the hard things (translation: walk before you run). So, while your profile approach might be helpful early on to get people set up and working, I feel like they’d be missing an important lesson that will help them progress to bigger challenges with items that can’t be handled by profiles.

This is largely because I think that OH needs to define tiers into which users can slot themselves based on their needs and expertise, and enable users to graduate up as they get deeper into the system. I see item-type transformation as an ideal teaching point for people who have their system running and are exploring what they can do with rules.

I also think it’s confusing for new users when there are multiple ways to do things. We can already see this in the confusion that comes from having to do some things in PaperUI and some things in configuration files. People start out with PaperUI and then get frustrated when they can’t get something to work, only to be told that they should have done it in config files or sitemaps (or Habmin). OH would be easier for newbies to grasp if PaperUI had very specific responsibilities/limitations, and I hope that’s where we’re going with OH3.

Saying all that, I’m only representative of users who want to understand how OH works and learn so that I can do more creative things with it. People who just want it to work might feel differently, but if that’s the case I probably wouldn’t recommend they get into OH in the first place.

[rlkoshak (Rich Koshak)]

@rpwong

OH would be easier for newbies to grasp if PaperUI had very specific responsibilities/limitations, and I hope that’s where we’re going with OH3.

The goal is that the replacement to PaperUI will replace PaperUI, BasicUI, ClassicUI, Habmin, and HABot. HABPanel is kind of it’s own thing and probably will remain it’s own thing. It will have user authentication with roles meaning accounts are given roles and what you can see and do depends on the role you log in as. At least that is how I understand the current plans based on the opened issues.

The end goal may not be done by OH 3.0 of course.

[Mamut (Peter Prochazka)]

Hi @rlkoshak @rpwong,
Thanks for your opinions.

I think finnaly we need this:

#1 - Fix profiles to ignore types and learn them to use proper types based on Item type

Number outdoorTemp  {channel=datasource [ profiles .....

This must be done by “standard behavior” => For example suported dateTime format is only ISO

#2 - For my point of view create new transforamtion addon let’s call it “theWheel” or “SwissKnife” with preprogramed function like to normalize common case output to OH standard.

1. unixtime2DateTime()
2. localTime2DateTime(“formatingstring”)
3. RGB2HSB
   and so one

as tool library to not invent wheel again and again by each user of OH for common cases. We need to find proper set of function. This litle bit decrease new user confusion to use rule for input in “common life” cases and also bring to advance user simplification of their configuration and rule set also faster deployment.

#3 - Look like we want chaining of profiles like @rossko57 mention in this and other threads. To allow combination for exampe XPATH->JAVASCRIPT … or JSONPATH -> theWheel because typically JSONPAT,XPATH are good in finding information, but you get in “raw” which may not compatible if OH data types and formats (best example is unixtime).

This what I extract from our previous discustions and my experience with OH as user.

[rlkoshak (Rich Koshak)]

I definitely agree with 1 and 3 as stated. I’m cautious about 2 because essentially what you are proposing is the creation of a brand new text parsing language. Usually when someone says the answer is the invention of a brand new language, that’s the wrong answer.

Normalizing input is a common problem. I’m certain there are already “languages” like what you are proposing already in existence. It would be better to find and adopt that than to invent a new one. Maybe all you need is the String Formatter approach that OH already uses (see label formatting using %s and the like).

But I do completely agree, this would be a separate transformation add-on and not something that you would implement as part of the profile.

I think you will find that on it’s own, a transformation like you are proposing isn’t all that useful, but I could see it becoming more useful with chaining.