Visu & PHP: Implizite und explizite Typumwandlung

[toggle]

gaert
Hallo Christian,

mir ist aufgefallen, dass in einem Visu-Element die dynamischen Designs nicht funktionieren wollten, obwohl sie identisch zu anderen Visu-Seiten erstellt wurden. Nun habe ich herausgefunden, dass es darauf zurückzuführen ist, dass 0 != 0 ist. D.h. es kommt ein String "0" an und wird in der Live-Anzeige des Logikeditors als 0 angezeigt. Der Wertebereich im dynamischen Design steht auf "0 bis 0", wird aber nicht getroffen, weil vermutlich das "Format" nicht passt. Die meisten Standardbausteine wandeln den String wohl implizit um, nur die Visu scheinbar nicht. Grundsätzlich werden Zahlen in String-Form (u.a. Fließkommazahlen) in den Archiven sauber abgelegt und können problemlos in den Diagrammen dargestellt werden.

Prinzipiell könnte ich einen Konverter in die KO-Kette setzen. Aber es erscheint mir nicht sehr elegant.

Handelt es sich um ein Feature oder ein "Feature"?

Gruß
Peter

[wintermute]

Das ist PHP was die Umwandlung vornimmt, nicht Edomi oder irgendwelche Bausteine.
Guckstdu: http://de.php.net/manual/de/language...e-juggling.php

[toggle]

Dass PHP das so macht, ist mir bekannt. Da Edomi in PHP geschrieben ist, wird dieses implizite Verhalten geerbt. Es sei denn, man konvertiert die Daten explizit. Daher würde ich gerne wissen, ob es einen Grund gibt, dass die Visu eine solche Konvertierung nicht durchführt. Mir erscheint es etwas inkonsistent, dass die meisten Edomi-Komponenten mit verschiedenen Inputtypen zurecht kommen (weil sie bzw. PHP diese implizit umwandeln), aber die Visu eben nicht.

[gaert]

Ein paar mehr Details würde helfen - welches DPT hat das KO, etc.?

Der Vergleich hat nämlich durchaus mit dem Datentyp zu tun (String oder Integer oder Float). Mit PHP übrigens weniger, eher mit SQL

[toggle]

Es handelt sich primär um keine KOs sondern um Ausgänge eines LBS, der über UDP empfangene Strings filtert und entsprechend dem hinterlegten Mapping weiterleitet.

function LB_LBSID($id) {
    if ($args = getLogicEingangDataAll($id))
    {
        $input = $args[11]['value'];
        $param = explode(":", $input, 2);
        for($i = 1; $i < 11; $i++)
        {
            if($param[0] === $args[$i]['value'])
            {
                setLogicLinkAusgang($id, $i, $param[1]);
                break;
            }
        }
    }
} 

Alle ausgegebenen Werte sind ebenfalls Strings. Die meisten Ausgaben werden über Ausgangsbox-LBS in Datenarchive geschrieben. Einige werden über interne KOs (Variant) für die Visualisierung verwendet, was leider nicht zum gewünschten Ergebnis führte, wie oben geschildert. stringValues.PNG



PS: Ich wollte meinen LBS generisch halten, weil nicht alle Werte numerisch sind.

[gaert]

KO-Werte landen ohnehin als varchar() in der Datenbank - eine Unterscheidung zwischen String und "Zahl" findet daher in diesem Kontext nicht statt.

Was mir noch nicht ganz klar ist: Wo genau liegt Dein Problem? Wenn Du im dyn. Design einen Wertebereich von 0..0 angibst und der KO-Wert "0" ist, sollte das Design "zünden"...

[timberland]

Hätte jetzt getippt er hat vielleicht eine Ausgangsbox ungleich 0, dann würde diese ja nicht ankommen. Aber das ist im Screen ja nicht der Fall. Oder liege ich da Falsch?

[toggle]

Genau das passiert eben nicht. Ich habe 4 dynamische Designs für 4 Werte definiert (0-0, 1-1, 2-2, 3-3). Zum Testen benutze ich netcat

echo "thz.fanStage:0" | nc -uw 1 192.168.1.10 54676
echo "thz.fanStage:1" | nc -uw 1 192.168.1.10 54676
echo "thz.fanStage:2" | nc -uw 1 192.168.1.10 54676
echo "thz.fanStage:3" | nc -uw 1 192.168.1.10 54676

Wenn ich im Logikeditor nach dem Empfang eines neuen Strings sehe, dass sich der Wert am Eingang der Ausgangsbox entsprechend geändert hat, passiert in der Visu nichts - das Basis-Design bleibt aktiv. Setze ich den Eingangswert der Ausgangsbox im Logikeditor manuell, dann schaltet die Visu das dynamische Design wie erwartet ein. Injiziere ich nun wieder einen String via UDP, wird dieser im Logikeditor korrekt dargestellt, aber die Visu schaltet auf Basis-Design.

[gaert]

Vermutlich wird noch ein CR/LF/Leerzeichen/etc. angehängt via nc?!

[toggle]

Mit nc habe ich erst angefangen zu testen, als es mit der eigentlichen Quelle nicht ging. Und die habe ich mit Wireshark verifiziert - kein CR/LF. Alle anderen Werte werden ja sauber in die DB geschrieben und in vielen Diagrammen dargestellt.

[gaert]

Verstehe ich nicht... Welchen Wert hat denn das KO nun tatsächlich (wie auch immer es gesetzt wird)?! Vergiss' mal "String" - ein KO-Wert ist immer ein String, oder eben ein String aus Ziffern bestehend (=Zahl).

[toggle]

Ich habe aufgehört nach der Ursache zu suchen, nachdem das Problem in einer neuen Konfiguration (KO, Logik und Visuseite) nicht mehr aufgetreten ist.

Wie kann ich den "uninterpretierten" KO-Wert abfragen?