Validate current value when changing state type?

[Supermicha81]

Would it be possible to validate and convert the current value of a state when changing its type?

Currently, it is possible to change the type of a state (e.g., from string to number) even if the current value is not a valid number. This can lead to confusing log warnings and unexpected behavior.

For example:

• A state is initially created with type string.
• A numerical value (e.g., "25") is stored in the state as a string.
• The state type is changed to number, but the stored value remains a string ("25" instead of 25).
• When trying to use this state in a script, ioBroker throws a warning:
  "You are assigning a string to the state 'xyz' which expects a number."

This happens even though the state type is already number. It seems that ioBroker does not automatically convert the stored value when the type is changed.

Possible improvements:
Automatically convert the stored value to the new type if possible (e.g., "25" → 25).
Show an error or warning when the stored value cannot be converted (e.g., "hello" → number).
Provide a tool or function to validate and correct all existing states after a type change.

This issue can cause hard-to-debug problems, as scripts rely on the state type but the underlying value may still be incorrect.

[Apollon77]

Hm ... would it not be more clear to delete the state value when such a thing happens (which BTW is a very unusual case anyway and one could also argue that the user that changes the datatype of a state should himself know best what that means for the value and how to best convert that.

Or what's the use case? Who changes the value type why?

[Supermicha81]

You're right, changing the datatype of an existing state is probably not something that happens frequently.
But it does happen in practice, and it can lead to hard-to-debug issues — especially now that ioBroker enforces stricter types (which is a really good thing!).

You said: 'the user should know what changing the type means' — but that's exactly the point:
If a user explicitly changes the type of a state, they usually do know what type is expected — and will rightfully expect that the current value is now treated accordingly.

Here are some real-world examples:

• When experimenting or developing new scripts and adjusting logic.
• When converting Blockly to JavaScript and refactoring code.
• When initially creating a state as string (e.g., via Blockly or the admin UI) and later realizing it should be a number.
• When working with older ioBroker installations — many user-defined states were created before strict typing was enforced.
• When importing/exporting state definitions from other adapters or scripts.

Possible solutions:

• Automatically convert the current value if it can be safely converted (e.g., "25" → 25).
• Delete the value if it's incompatible, forcing the user to re-set it.
• Deleting the value anyway, forcing the user to re-set it.
• Show a warning in the admin UI when changing the type, e.g.:
  "The current value does not match the new type. Please update the value manually."
• Or at least add a log/info message suggesting to manually re-save the value.

TL;DR:
The current behavior is technically correct, but from a usability standpoint, it's confusing and potentially error-prone — especially for users migrating from older setups. A simple validation or hint could go a long way to improve clarity.

[Apollon77]

I still would not start trying to convert types. I would be ok with "if the current value matches the new type then the value can stay, else it get removed and then the user can write the value again in the right datatype."
So if it is a string and should be a number and someone already had written a number into the state then this would stay.

All other cases can only end in strange data n the state and lead to even more confusion

[mcm1957]

I also could live with an implementation which always null's the value when changing a state type. But of course ist also ok th eleave the value if its matching the type.

I do not think that any effort to convert should be invested. Changing the type should occure ruther seldom

[mcm1957]

Besides - as long as writing a value by setState does not ensure a matching type ther could be nonsense store anyway.

[Supermicha81]

Thanks for your replies.

"All other cases can only end in strange data"

You're right, trying to convert array to number or something else makes so sense.
The only sensible case would be a numeric string to a number or a string like "true" to bool, but maybe it would be a great effort for such a small usecase.

"... it get removed and then the user can write the value again in the right datatype."

I think this should be the best solution, nulling the value could be the easiest and maybe the best way.

Thanks for taking the time to discuss this and consider possible improvements — really appreciate the open exchange!