basic.print ignoriert "text" Format

[Sipple]

Hi

Ich habe in SHNG zwei items, die einen String enthalten. Definitiv. Wird im Admin Interface auch so dargestellt wie es sein soll.

go_e:
    Status:
        type: dict
        mqtt_topic_in: go-eCharger/013817/status
        on_change:
        - ..fwv = value['fwv']
        - ..sse = value['sse']
    fwv:
        type: str
    sse:
        type: str

In go_e.fwv steht korrekt "040.0"
In go_e.sse steht korrekt "013817"

In der Visu will ich die beiden Werte exakt so darstellen.
basic.print weigert sich jedoch beharrlich das so auszugeben.

FW: {{ basic.print('', 'go_e.fwv', 'text') }}
<br />
SN: {{ basic.print('', 'go_e.sse', 'text') }}

Laut Dokumentation gibt es für das Format den Wert 'text'. Klappt aber nicht, auch keine andere Kombination. basic.print interpretiert das anscheinend immer als eine Zahl.
Was raus kommt ist dann "40" bzw. "13817", es werden also z.B. führende Nullen abgeschnitten.
Hab ich bei basic.print nen Denkfehler oder ist das ein Bug?

SHNG: 1.8.2
smartVISU: 3.1.0

Gruß, Martin

[wvhn]

Hi Martin,

die Ausgabe von Zahlen als Text ist bisher tatsächlich nicht vorgesehen bzw. es ist nie aufgefallen, dass das nicht funktioniert. Leider ist die Änderung nicht leicht zu machen, da das Widget die item-Werte bereits in Zahlenform erhält. Die Wandlung passiert tief im System auf dem Weg vom Websocket in den widget.buffer. Wenn ich den widget.buffer manuell mit Anführungszeichen "012345" beschreibe und ein update triggere, dann stimmt auch die Anzeige in basic.print.

Das Format im widget.buffer lässt sich sicher ändern, aber ich befürchte negative Auswirkungen auf alle Widgets, die sich bisher darauf verlassen, dass das item in Zahlenformat übergeben wird. Da brauche ich einige Zeit, um das sauber abzusichern.

Es gibt aber einen Workaround :
Wenn Du im Backend den beiden Strings jeweils ein " " voranstellst, dann kannst Du mit dem Format "text2br", das den Text als html einfügt, die richtige Anzeige erreichen. Also go_e.fwv = " 040.0".

Gruß
Wolfram

[Sipple]

Alles klar, verstanden. Da muss ich mir dann ein Hilfs-Item bauen, weil die Werte, um die es geht, direkt vom go-e in das item geschrieben werden.
Aber SO wichtig ist das in dem Fall jetzt zum Glück nicht.
Hab da noch andere Baustellen. Das geniale status.toast macht noch Probleme, bzw. irgendwas im Zusammenhang damit. Ich bekomme Toast Meldungen immer wieder doppelt im Abstand von ein paar Sekunden. Aber das beobachte ich noch und mach gegebenenfalls ein neues Thema aus.

[Sipple]

Mit dem   klappt es. Leider bekomme ich es mit einem simplen eval in SHNG nicht hin. Habe ne Logik gebaut, aber das ist mit Kanonen auf Spatzen geschossen.

go_e.fwv:
     type: str
     eval: " " + value

geht jedenfalls nicht. Das + wird angemeckert. Wäre auch zu schön/einfach gewesen

[wvhn]

kann es sein, dass der Typ "string" ignoriert wird? Oder ist das gleichwertig mit "str"? Der eval-Ausdruck ist ja ein gültiger Python-Ausdruck und müsste funktionieren, wenn der Typ des items stimmt.

[Sipple]

Da hab ich mich vertippt oder das war irgendeine Autovervollständigung. Ist schon korrekt "str".
Das ist bestimmt was ganz einfaches, wenn man's weiß. Die Profis wie Msinn lachen da wahrscheinlich drüber.

[wvhn]

Moin Martin Sipple,

im Changelog steht unter "known bugs" immer noch das Problem, dass führende Nullen nicht ausgegeben werden, auch wenn das item vom Typ str ist. Ich hab jetzt mal versucht, die Baustelle endlich zu schließen.

In der ./lib/base/base.js steht heute (sV v3.4.0) in der Funktion widget.set() ab Zeile 1409 (Zeile 1425 in der aktuellen develop-Version v3.4.a)

        else if (value !== undefined) {
            widget.buffer[item] = ( $.isNumeric(value) ? value * 1.0 : value);​

Wenn man das ändert zu

        else if (value !== undefined) {
            if (typeof value == 'string' && value.substring(0,1) == '0')
                widget.buffer[item] = value;
            else
                widget.buffer[item] = ( $.isNumeric(value) ? value * 1.0 : value);​

Dann ignoriert die Visu die führende Null aus dem Text nicht mehr.

Kannst Du das gelegentlich mal testen und v.a. beobachten, ob es negative Nebeneffekte gibt?

Gruß
Wolfram

[Sipple]

Moin Wolfram

Danke, werde ich versuchen. Habe allerdings aktuell viele Baustellen und komme irgendwie zu nichts.
Ich melde mich.

Gruß, Martin

[wvhn]

Es gab tatsächlich noch einen negativen Nebeneffekt. Wenn der Inhalt des items "0" war, wurde dies als String interpretiert, was in einzelnen Widgets zu Problemen führte. Das ist jetzt bereinigt und die Lösung ist im develop branch verfügbar.

Gruß
Wolfram