search

ioBroker / ioBroker.vis-2

Next generation visualisation for ioBroker platform.
Other
26 stars 3 forks source link

Widget "jqui-input" saves numbers as strings - see also issue #372 #30

Closed WillyIoBrok closed 5 months ago

WillyIoBrok commented 10 months ago

Issue: the "jqui-input" widget will save an entered value as string even though the checkbox "As string" is not selected.

Steps to reproduce:

create a new state of type "number"
create a new vis view containing 1 jqui-input widget that is linked to the new state. save the view.
Make sure, that in the configuration of this widget the switch "as string:" is untagged/switched off.
-> by this, I would expect, that numbers entered by hand are written into the DP as number

open the view and enter a number in that input field (ex: 100).

look into the log - you will see a warning like this, telling you, that a string has been written into the DP
<html><body>
web.0 2023-07-23 10:25:15.752 info State value to set for "new state" has to be type "number" but received type "string"

Expected behavior
if "As string:" is untagged, I would expect, that a number will be sent to the linked DPs, not a string

Additional context
this issue seems to be very old (at least since 2017) and has been raised by many people, but there seems to be no change on this behaviour. It has been issued in 2017 as issue ioBroker/ioBroker.vis#372

As long as you don't rely on the fact, that you have a number type, everything seems to work perfect (except the warning in the log). But if to do mathematical calculations on the data, the result of these calculations on strings will be nonsense. If you do those calculations only under certain cases, you get very hard to find errors.

Feuer-sturm commented 10 months ago

@WillyIoBrok Which vis Version do you use?

WillyIoBrok commented 10 months ago

as sent already by email:

the newest vis Version I know - 1.4.16

the widget version is also the newest available for me : vis-jqui-mfd jQuery-UI-Stil Widgets 1.0.12

WillyIoBrok commented 10 months ago

hmmmm .... do you mean I shall recheck with vis2? sorry, but I don't have a clue, how to do that nor where to get that vis2 ... I'm only a plain user of the iobroker system and can only use the sw, which is offered by the system.

Feuer-sturm commented 10 months ago

@WillyIoBrok If you do not have the possibilty to check it with VIS2 it is not a problem. I can try to reproduce it with vis1 and check if i see the same error occurs with vis2 as well.

Feuer-sturm commented 10 months ago

With vis2 (version 2.1.4) I receive the same warning in the log if I reproduce your issue.

web.0
    2023-07-24 14:17:29.467 info    State value to set for "0_userdata.0.Temp.issue748" has to be type "number" but received type "string"

grafik

foxriver76 commented 6 months ago

still happening @Feuer-sturm?

For me it works, setting numbers correctly

grafik

foxriver76 commented 6 months ago

Or is it another widget? Mayne you can provide an export @Feuer-sturm

WillyIoBrok commented 5 months ago

Hello, I tested it once more (with vis1). The situation remains unchanged (see initial topic). Everything seems to work, but there is still a string sent to the DP instead of a number which creates at least a warning in the log.

foxriver76 commented 5 months ago

The question is: is the State value previously a String or a number. Maybe someone can provide an Export of the Widget.

Feuer-sturm commented 5 months ago

@Feuer-sturm I can't reproduce the behavior any more. From my point of view it is fine now tested widget: Gestylt Eingabe vis-2: 2.9.6 datapoint is from type number which is linked with the widget.

@WillyIoBrok Do you have the problem with vis-2 as well? vis-1 is not in focus here.

WillyIoBrok commented 5 months ago

as mentioned above I don't use vis-2 (yet). In vis-1 I reproduced the erroneous behaviour some minutes ago.

Feuer-sturm commented 5 months ago

@WillyIoBrok vis-1 is not in focus of this repository. Here we track only issues for vis-2 :-)

WillyIoBrok commented 5 months ago

ok, no problem. I don't have a real problem any more since I know the behaviour and have workarounds in place ...