Merkwürdiges Typ-Problem
-
@martinp kannst du bitte das log als Text in code-tags posten.
-
@homoran Mache ich gleich oben in Eröffnungspost ... finde aber dass das was man als Text bekommt, wenn man aus dem "Protokolle" Fenster im Browser koplert manchmal etwas komisch formatiernn
-
@martinp sagte in Merkwürdiges Typ-Problem:
Fenster im Browser koplert
nöö! das sollst du ja auch nicht
das entsprechende log über den Button herunterladen und dort heraus kopieren -
@martinp sagte in Merkwürdiges Typ-Problem:
Merkwürdigerweise ist aber NullKubikWork gar kein String ...
Es wird sich ja auch über den Typ von
'0_userdata.0.Adjustments.Gaszaehler.LastKubikmeter'und'0_userdata.0.Adjustments.Gaszaehler.VerbrauchTotal'beschwert.
You are assigning a string to the state "0_userdata.0.Adjustments.Gaszaehler.LastKubikmeter"
You are assigning a string to the state "0_userdata.0.Adjustments.Gaszaehler.VerbrauchTotal"Nicht von
'0_userdata.0.Adjustments.Gaszaehler.NullKubikmeter'Edit: Ach Du kopierst da States hin und her. Verstehe das Script nicht so richtig. Was gibt denn ein
console.log(typeof getState('0_userdata.0.Adjustments.Gaszaehler.NulKubikWork').val); -
@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 werdenauch EDIT:
ja, das ist es -
@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
numberist, 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.
-
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"
-
@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.
-
@haus-automatisierung Wie kann man das "typeof" als Blockly formulieren? - stehe da gerade auf dem Schlauch...
EDIT
Habe nach "T" gesucht, nicht nach "O"
-
@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
typedes Objektes (und nicht den "echten" Datentyp des verknüpften States).Den kennst Du ja schon. Da kommt
stateraus. -
@martinp sagte: Wie kann man das "typeof" als Blockly formulieren?
-
"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?
-
@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?
-
@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 -
@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.
-
@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 ...
-
@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
-
@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 ...
-
@martinp sagte: Das Control scheint unbrauchbar
Gerade getestet: Das Widget liefert immer einen String - egal ob mit Punkt oder Komma.
-
@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 ...
