-
-
Notifications
You must be signed in to change notification settings - Fork 413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different strings passed to JS state transform depending on UI where Number:Time Item is being rendered #4101
Comments
So MainUI is using the displayState from the SSE event stream, whereas sitemaps have their own event stream. The displayState for Main UI is created here: Line 105 in e628f75
The sitemap event stream state is created here: Line 211 in b64e972
Now it is needed to further track down where and how the transformation service is called. Which means this is in fact a core issue and no UI issue. |
@florian-h05 thanks for the insight. Could you please move the issue to openhab-core as I don't have rights to do that? TIA |
Unfortunately I also don't have the rights at the core repo. |
For sitemap UIs, I believe the item state is formatted at this place before applying the transformation: As you can see, "state.format(value)" is used where value is "%s" extracted from "[[JS(24g-uptime.js):%s]". It explains why a date time format is passed to the transformation. Main UI is using "state.toString()" instead. |
It makes sense to me to consider the pattern like it is done in sitemap UIs, it allows controlling the format of value passed to the transformation. I mean you could use something else than %s if you want a specific format passed to the transformation. Apparently Main UI is ignoring this pattern. |
As a workaround, replacing "%s" by "%d s" should allow having the same value passed to the transformation in both cases. |
While true, I don't like the state description pattern being used both internally with some logic, and for representation. It tends to create conflict and confusion down the line. |
@andrewfg @florian-h05 @mherwege : if you are ok, I update the class SseItemStatesEventBuilder to align the behaviours. |
When using %s as pattern, there will be no difference in behaviour, correct? |
Is there still a difference if #4169 would be applied? I still think the format() method for Quantity Time produces the wrong result today, leading to this difference. It should not generate by default something that looks like a date/time, it should be a duration. There is specific handling for that and I think it is wrong. |
Normally, when there is no transformation and %s is set as pattern, yes, options should have higher priority. But I will verify. |
It looks like a different problem. |
@mherwege : I believe this is the place where you would like to change format for QuantityType ? |
That’s indeed what I did there, in the code you link to. |
So with the change I propose to implement + your change, Main UI and Basic UI will pass the same value to the transformation (my change that will call |
Yes, that is my understanding, whereby the unit in the value can be different depending on the unit set for the item. |
The change is not as easy as I have imagined. |
In fact, the problem is in class My previous suggestion to use "%d s" as final pattern should not work due to the way it is currently implemented. As a fast fix, I could duplicate the method |
The idea here is to use state.format(format) instead of String.format(format, state.toString()) Related to openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) Related to openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) Related to openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) Related to openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) Related to openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) As a consequence, the input value passed to the transformation is the same in all UIs (Main UI and sitemap UIs). Fix openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) As a consequence, the input value passed to the transformation is the same in all UIs (Main UI and sitemap UIs). Fix openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) As a consequence, the input value passed to the transformation is the same in all UIs (Main UI and sitemap UIs). Fix openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) As a consequence, the input value passed to the transformation is the same in all UIs (Main UI and sitemap UIs). Also make sure to call transformation even for NULL and UNDEF states but without applying format to the input value. Fix openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
The idea here is to use state.format(format) instead of String.format(format, state.toString()) As a consequence, the input value passed to the transformation is the same in all UIs (Main UI and sitemap UIs). Also make sure to call transformation even for NULL and UNDEF states but without applying format to the input value. Fix openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Use item state formatter to format input of transformation, meaning using state.format(format) instead of String.format(format, state.toString()) This was already the case in sitemap API but not in other APIs used by Main UI. Make sure to call transformation even for NULL and UNDEF states. It was not the case in one API used by Main UI. When calling transformation and state is NULL or UNDEF, do not apply format to the input value and do not replace by "-". That leans the transformation will be called with "NULL" or "UNDEF". Sitemap API was calling the transformation using a pattern containing "-". Fix openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Use item state formatter to format input of transformation, meaning using state.format(format) instead of String.format(format, state.toString()) This was already the case in sitemap API but not in other APIs used by Main UI. Make sure to call transformation even for NULL and UNDEF states. It was not the case in one API used by Main UI. When calling transformation and state is NULL or UNDEF, do not apply format to the input value and do not replace by "-". That leans the transformation will be called with "NULL" or "UNDEF". Sitemap API was calling the transformation using a pattern containing "-". Fix openhab#4101 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Use item state formatter to format input of transformation, meaning using state.format(format) instead of String.format(format, state.toString()) This was already the case in sitemap API but not in other APIs used by Main UI. Make sure to call transformation even for NULL and UNDEF states. It was not the case in one API used by Main UI. When calling transformation and state is NULL or UNDEF, do not apply format to the input value and do not replace by "-". That leans the transformation will be called with "NULL" or "UNDEF". Sitemap API was calling the transformation using a pattern containing "-". Fix openhab#4101 Also related to discussion in openhab/openhab-addons#13777 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Use item state formatter to format input of transformation, meaning using state.format(format) instead of String.format(format, state.toString()) This was already the case in sitemap API but not in other APIs used by Main UI. Make sure to call transformation even for NULL and UNDEF states. It was not the case in one API used by Main UI. When calling transformation and state is NULL or UNDEF, do not apply format to the input value and do not replace by "-". That means the transformation will be called with "NULL" or "UNDEF". Sitemap API was calling the transformation using a pattern containing "-". Fix openhab#4101 Also related to discussion in openhab/openhab-addons#13777 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Use item state formatter to format input of transformation, meaning using state.format(format) instead of String.format(format, state.toString()) This was already the case in sitemap API but not in other APIs used by Main UI. Make sure to call transformation even for NULL and UNDEF states. It was not the case in one API used by Main UI. When calling transformation and state is NULL or UNDEF, do not apply format to the input value and do not replace by "-". That means the transformation will be called with "NULL" or "UNDEF". Sitemap API was calling the transformation using a pattern containing "-". Fix openhab#4101 Also related to discussion in openhab/openhab-addons#13777 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Use item state formatter to format input of transformation, meaning using state.format(format) instead of String.format(format, state.toString()) This was already the case in sitemap API but not in other APIs used by Main UI. Make sure to call transformation even for NULL and UNDEF states. It was not the case in one API used by Main UI. When calling transformation and state is NULL or UNDEF, do not apply format to the input value and do not replace by "-". That means the transformation will be called with "NULL" or "UNDEF". Sitemap API was calling the transformation using a pattern containing "-". Fix openhab#4101 Also related to discussion in openhab/openhab-addons#13777 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/oh4-number-of-type-java-lang-string-is-not-supported/156599/3 |
Applies to
Actual Behaviour
OH passes DIFFERENT strings, (either a QuantityType compatible string, or ii) a DateTimeType string), to a JavaScript transform for rendering a Number:Time Item state depending on whether the item is being displayed via Main UI or via a Basic UI sitemap Text element.
Expected Behaviour
OH should pass the SAME string to the JavaScript transform for rendering an Item state REGARDLESS of whether the item is being displayed via Main UI or via a Basic UI sitemap Text element.
Precondition
An Item is defined using a JavaScript transform to format its state description.
Test Cases
81612 s
" to the JS transform.1970-01-01T22:40:12Z
" to the JS transform.Reference
See forum thread
The text was updated successfully, but these errors were encountered: