Merkwürdiges Typ-Problem

[Homoran]

@haus-automatisierung und genau das konnte ich nicht genau entziffern, aber ich glaube es geht anscheinend um die Stelle im Blockly, die den Wert aus einem DP Typ Number nimmt und dort hineinschreibt.
Dann müsste der geschriebene Wert doch gar nicht gewandelt werden

auch EDIT:
ja, das ist es

[haus-automatisierung]

@homoran sagte in Merkwürdiges Typ-Problem:

Dann müsste der geschriebene Wert doch gar nicht gewandelt werden

Na das kommt drauf an, was wirklich in dem State steht. Nur weil der definierte Typ auf dem Objekt number ist, heißt es ja nicht, dass da auch wirklich mal ein numerischer State gespeichert worden ist.

Eventuell wurde ja mal ein String gespeichert (auch mit einer Warnung) und jetzt wird der String da zurückgeliefert...

Nur weil man den Typ auf dem Objekt umstellt, findet AFAIK kein automatischer Cast des State-Wertes auf den neuen Typ statt.

[MartinP]

@haus-automatisierung

Ich lese den Gaszähler mit einem induktiven Näherungssensor aus (1 Puls pro 10 Liter Gas), und der schickt manchmal überzählige Pulse.

Um diese zu korrigieren habe ich einen Vis 1.x View provisorisch gebastelt, bei dem man durch Eintippen des realen Zählerstandes eine Korrektur auslösen kann...

Womöglich kommt da durch die "kalte Küche" ein String in den "Zahl" Userdata - Punkt...

Wäre aber merkwürdig... Widget ist vom Typ "jqui - input"

[haus-automatisierung]

@martinp sagte in Merkwürdiges Typ-Problem:

Womöglich kommt da durch die "kalte Küche" ein String in den "Zahl" Userdata - Punkt...

Könnte man jetzt raten, oder man schaut einfach in dem State nach

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

[MartinP]

@haus-automatisierung Wie kann man das "typeof" als Blockly formulieren? - stehe da gerade auf dem Schlauch...

EDIT

Habe nach "T" gesucht, nicht nach "O"

[haus-automatisierung]

@martinp sagte in Merkwürdiges Typ-Problem:

Wie kann man das "typeof" als Blockly formulieren?

Nimm doch einfach kurz ein neues JavaScript. Der Block von Dir nimmt type des Objektes (und nicht den "echten" Datentyp des verknüpften States).

Den kennst Du ja schon. Da kommt state raus.

[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 ....