[homematic] Remove state description step size handling #12192
Conversation
The RPC protocol doesn't provide this value, so it always was made up more or less arbitrarily. Since the UI now uses this value for validation purposes, there are cases where valid values can not be entered due to this step size (particularly for datapoints with more than 1 decimal digit). Fixes openhab#12183 Signed-off-by: Danny Baumann <dannybaumann@web.de>
| @@ -361,8 +354,6 @@ public ParameterOption createOption(String value, String description) { | |||
| } | |||
| builder.withMinimum(MetadataUtils.createBigDecimal(dp.getMinValue())); | |||
| builder.withMaximum(MetadataUtils.createBigDecimal(maxValue)); | |||
| builder.withStepSize(MetadataUtils | |||
| .createBigDecimal(dp.isFloatType() ? Float.valueOf(0.1f) : Long.valueOf(1L))); | |||
| builder.withUnitLabel(MetadataUtils.getUnit(dp)); | |||
There was a problem hiding this comment.
One thing came to my mind: maybe we should keep step=1 for integer types.
There was a problem hiding this comment.
I guess the UI knows integers have no fraction, so it should be fine to omit it.
|
Will be merged this evening if no veto. |
|
I am using now Build 2744 and i think that the change made it even worse, because i did not get any configuration |
Anything relevant in the logs? |
|
FWIW, I just tried locally with my push button devices which have a similar data point, whose config description is now this one: ... so step is gone as expected. It's still present in UI though, but I created this in my dev environment from scratch, so maybe deleting and re-adding the thing is worth a try? In any case, this PR was only half of the solution it seems:
... because MainUI employs a similar arbitrary default step size. |
|
Deleteting and Readding didnt solve the problem. Without deleting the thing i got the old messages, after deleting and readding the thing the configuration is gone. until now i had no time to look into the logs |
You're right it's arbitrary but based on what seemed to be (admittedly, empirically) the most common step size for a decimal when it's not provided. |
Wouldn't the most logical choice be 'do not enforce any step size at all in that case'? |
|
Sure, in this case it's probably the best choice. https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/step
That would be setting the HTML input element's step attribute to "any" if the config description doesn't specify a stepsize. I remember considering that and then backtracking... but I don't remember the reason for the backtrack right now 😓 |
|
@maniac103 @ghys So do i understand it right that this is an issue in the UI, so should we open an issues? |
|
@TBail There is an issue left in the UI, but that's aside from your 'option isn't shown at all' issue (which I can not reproduce). |
|
Now i updated homegear deleted the thing an redicovered them, but still the following error
|
|
As far as i can see from the log the problem ist not within the Homematic binding. a Trace shows that the thing receives values. So it seems that this is still an ui problem. I will try to find some hints on that. |
|
Now i got the trace from the validation process. It seems to me that the validation does not match the entry indexes. |
|
And now i tried to set vaild parameters and i got the standard eroor
|
That one is the one I mentioned here. For the other one I agree this is clearly a UI, not binding, issue, because indices were saved as option value instead of the actual value. |
|
So at the end the problem is that we need a step size that covers most of the option. So i would suggest to set a value of 1*10E-6. With this value the ui sould be satisfied and it is up to the user to decide if the value is usefull for the channel. @ghys Isn't that an option? |
|
I think he already shared what should be done here ;-) |
|
Since the update from 3.2.0 stable to 3.3.0 M1/M2 I have problems with 6 of my actors (things). Now with M2 I get the following additinal information: Is this regarding to this issue/change? |
|
You're not the only one (see here), but it's a different issue, likely in the UI. |
|
OK. If I can test something, please don't hesitate to contact me ;) Until this I will have to stay at the final version... P.S. Interesting: I have 3 "HmIPW-DRBL4". One is still working and 2 have this problem. All the same FW-Versions. |
|
If you have some working and some broken ones, it may be worth a try to check whether
That way, one could probably tell if the problem is caused by some condition in the past (first case) or in present code (second case). Edit: This code block should update configuration settings whenever the thing handler is initialized (that is, when starting OH or when disabling/re-enabling a thing). It would probably be nice to see a startup log of OH with enabled TRACE logging for HM binding, to check whether anything changed in the output format of the CCU. What also would be interesting is whether deleting and recreating (one of, for now) the affected things helps. |
|
Also ich habe auf TRACE gestellt und neu gestartet. Dann war vieles nicht INITILIZED (weil zu langsam, denke ich). Ich mache jetzt mal folgendes: |
Disable/Enable ist nicht das gleiche wie Löschen/Hinzufügen. Die von der CCU geladenen Datenpunkte werden nach Disable/Enable nicht neu geladen. |
|
OK. Ich habe also 3 der betroffenen Devices entfernt,
TRACE eingeschaltet und DISCOVER gestartet. Ich habe das mehrfach wiederholt. Während TRACE an ist, werden nicht alle Devices sofort gefunden (TIMEOUT?). Aber das ist ja jetzt nicht das Problem ;) Das Log von dem einen Vorgang anbei: 3_2_0_Release.zip Jetzt habe ich auf das akt. Milestone aktualisiert und wieder sind von den 3 Devices 2 nicht in Ordnung: Habe die obige Prozedur wiederholt und das Problem bleibt bestehen. Hier das Log dazu: 3_3_0_M2.zip Ich hoffe, ihr könnt mit den gesammelten Informationen etwas anfangen ;) Elle EDIT: Sorry for switching to german. That was not my intention.... |
The RPC protocol doesn't provide this value, so it always was made up more or less arbitrarily. Since the UI now uses this value for validation purposes, there are cases where valid values can not be entered due to this step size (particularly for datapoints with more than 1 decimal digit). Fixes openhab#12183 Signed-off-by: Danny Baumann <dannybaumann@web.de> Signed-off-by: Nick Waterton <n.waterton@outlook.com>
The RPC protocol doesn't provide this value, so it always was made up more or less arbitrarily. Since the UI now uses this value for validation purposes, there are cases where valid values can not be entered due to this step size (particularly for datapoints with more than 1 decimal digit). Fixes openhab#12183 Signed-off-by: Danny Baumann <dannybaumann@web.de>
The RPC protocol doesn't provide this value, so it always was made up more or less arbitrarily. Since the UI now uses this value for validation purposes, there are cases where valid values can not be entered due to this step size (particularly for datapoints with more than 1 decimal digit). Fixes openhab#12183 Signed-off-by: Danny Baumann <dannybaumann@web.de>
The RPC protocol doesn't provide this value, so it always was made up more or less arbitrarily. Since the UI now uses this value for validation purposes, there are cases where valid values can not be entered due to this step size (particularly for datapoints with more than 1 decimal digit). Fixes openhab#12183 Signed-off-by: Danny Baumann <dannybaumann@web.de> Signed-off-by: Andras Uhrin <andras.uhrin@gmail.com>
The RPC protocol doesn't provide this value, so it always was made up more or less arbitrarily. Since the UI now uses this value for validation purposes, there are cases where valid values can not be entered due to this step size (particularly for datapoints with more than 1 decimal digit). Fixes openhab#12183 Signed-off-by: Danny Baumann <dannybaumann@web.de>
The RPC protocol doesn't provide this value, so it always was made up
more or less arbitrarily. Since the UI now uses this value for
validation purposes, there are cases where valid values can not be
entered due to this step size (particularly for datapoints with more
than 1 decimal digit).
See #12183 for a concrete breakage example.
Fixes #12183