Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[paul53]

@martinp sagte: Wie kann man das "typeof" als Blockly formulieren?

[MartinP]

@paul53

"script.js.Energiezaehler.Gaszaehler: NulKubikWork ist vom Typ string"

Aber merkwürdig - Wieso hat der nicht gesetzte Haken "als String" nicht dazu geführt, dass da eine Float-Zahl aus dem Vis View übertragen wurde?

[paul53]

@martinp sagte: Wieso hat der nicht gesetzte Haken "als String" nicht dazu geführt, dass da eine Float-Zahl aus dem Vis View übertragen wurde?

Vermutung: Komma anstelle Punkt eingegeben?

[Homoran]

@haus-automatisierung sagte in Merkwürdiges Typ-Problem:

Aber "Zeichen nach Komma" klingt ja schon nach String.

reingefallen
ist Zeichen nach Punkt. und nur für die Darstellung

[haus-automatisierung]

@homoran sagte in Merkwürdiges Typ-Problem:

ist Zeichen nach Punkt.

Alleine der Begriff "Zeichen" lässt doch schon einen String vermuten. Oder die Option hat nur eine Wirkung, wenn man auch "als String" anhakt. Fragen über Fragen. Da müsste man wohl das Widget genauer anschauen um das zu verstehen.

[MartinP]

@paul53

@paul53 said in Merkwürdiges Typ-Problem:

@martinp sagte: Wieso hat der nicht gesetzte Haken "als String" nicht dazu geführt, dass da eine Float-Zahl aus dem Vis View übertragen wurde?

Vermutung: Komma anstelle Punkt eingegeben?

Das scheint der Fall zu sein - wenn ich im Datenpunkt den Typ auf "Zahl" ändere, ist das auch nur von kurzer Dauer, dann wird das wieder nach String geändert ...

Vielleicht liegt es am jqui-input control, was unbedingt einen Dezimalpunkt nutzen will ...

[Homoran]

@haus-automatisierung sagte in Merkwürdiges Typ-Problem:

Alleine der Begriff "Zeichen" lässt doch schon einen String vermuten. Oder die Option hat nur eine Wirkung, wenn man auch "als String" anhakt. Fragen über Fragen

da kennst du die Historie und den Entwickler wohl nicht ;-)

[MartinP]

@homoran Das ist eine merkwürdige Geschichte, irgendwie im Dunstkreis des üblichen Punkt/Komma Ärgers ...

dieses Jqui - input Control scheint da bei unverändertem Zurückschreiben des Wertes aus der Maske den Typ auf "Number" zu belassen, und sobald man die letze Nachpunktstelle editiert wird der Typ auf String geändert ...

Editiert man auch den Dezimalpunkt, und ersetzt ihn durch ein Komma, werden alle Nachkommastelle auf Null gesetzt ...

Das Control scheint unbrauchbar oder zumindest "sperrig" bei deutscher Lokalisierung ...

[paul53]

@martinp sagte: Das Control scheint unbrauchbar

Gerade getestet: Das Widget liefert immer einen String - egal ob mit Punkt oder Komma.

[MartinP]

@paul53 Ich habe jetzt erstmal aus der Not an dieser Stelle auf String umgestellt ...

Userdata Variable auf Typ "String" umgestellt, und "als String" im Control angehakt - dann weiß man wenigstens dass nicht in irgendwelchen Situationen doch eine Zahl geschrieben wird ....

Wäre wirklich interessant, ob das bei Vis.2 besser wird ...

[haus-automatisierung]

@martinp sagte in Merkwürdiges Typ-Problem:

irgendwie im Dunstkreis des üblichen Punkt/Komma Ärgers ...

Da gibt es keinen Ärger. Ganz einfache Regel: Immer mit Punkt und der US-Schreibweise arbeiten. Also dem richtigen Datentypen. Und das Frontend (Admin-Adapter, VIS, Grafana, …) formatiert den Wert entsprechend der Locale des Nutzers. Alles andere führt nur zu Problemen und ständigen Typkonvertierungen.

Dann hat man auch keine Probleme mit Scripts, Berechnungen, in JSON, InfluxDB/Datenbanken usw.

[MartinP]

@haus-automatisierung Das wäre schön - und dann gibt es irgendein Widget, das sagt LOCAL=DE, also Dezimalzeichen AUSSCHLIESSLICH Komma... wenn ich einen Punkt sehe, ist das also ein String ....

[MartinP]

Jetzt muss ich erstmal meine Influx-DB "frisieren" und einen Fehlschuss durch die Experimente mit der Kalibrierung der Gaszählermessung entfernen ....