HTTP Eingang - Befehlserkennung / Hexadezimal aufsplitten möglich?

[Gast]

Hallo Leute,

ich bekomme über einen HTTP-Eingang folgenden Quellcode geliefert.

{"cid":-1,"data":{"value":"0001FC000008FF000002FF000157FF000022FF03"},"code":200}

Hierbei handelt es sich um einen Sensor, welchen ich über einen IO-Link Master ( IFM AL1350 ) auslese.
Es handelt sich aber bei diesem großen Hexadezimalwert um 10 unterschiedliche Werte ( Schwingung, Temperatur, Schaltausgänge, usw... )
Benutze ich value":"\h als Befehlserkennung, gibt er mir natürlich nur den kompletten Wert als normale Zahl zurück.
Ich möchte aber die ersten 4 Zahlen aus Hex extrahieren und dann die nächsten 4 usw.... um letztendlich 10 unterschiedliche Werte zu bekommen
Ist das irgendwie möglich?

Gruß

Andy

[Gerd Clever]

Hallo Andy,

in welcher Form sollen denn diese 10 Werte nach dem Auslesen vorliegen bzw. wie willst Du sie dann in Loxone weiter verwenden?

Ich frage deswegen, weil das Auslesen + Aufbereiten recht aufwändig werden kann und es deswegen im Vorfeld gute wäre zu wissen, was Du genau vorhast.

Gruß Gerd

[Christian Fenzl]

Ich hab grad etwas mit der Befehlserkennung gespielt - das wird ein Horror.

Mit nem kleinen Script am LoxBerry vielleicht?

[Gerd Clever]

Im schlimmsten Fall 40 Befehlserkennungen + Folgeauswertungen. In der Tat ein Horror. Hier vermisst man wieder schmerzlich die Möglichkeit, eigene Bausteine definieren zu können. Hilfreich wäre auch, wenn man \h beispielsweise auf die nächsten 4 Zeichen einschränken könnte.

[romildo]

Man kann schon auch 4 Zeichen einlesen.
In Deinem fall kommt alles als Text bei Loxone an. Die Textzeichen werden als Hex eingelesen und in Dez umgewandelt.
Beispiel:
Befehlserkennung: \4\3\2\1
Ankommender Text: 1234
Ankommende HEX: 31 32 33 34
Ausgabe Dez: 825373492
Für die nächsten 4 Text-Werte müsste dann ein Sprung davor gesetzt werden, Befehlserkennung also \s4\4\3\2\1
Dies nur als Beispiel, wird in Deinem Beispiel vermutlich nichts bringen.

Ich vermute wie Gerd Clever in #3.1 schreibt, dass es darauf hinaus läuft, dass jeder Wert einzeln eingelesen und danach in Loxone bearbeitet werden muss.
Wie Christian Fenzl schon schreibt, könnt dies dann der Horror werden

Wie Gerd Clever in #2 schreibt, müsste man daher schon genauer wissen, was denn erwartet wird.

[Gast]

Hey Leute,

Vielen Dank für eure Rückmeldungen!
In Node-Red ist dieses aufteilen überhaupt kein Problem.
Leider habe ich an diesem Miniserver nicht die Möglichkeit Node-Red einzusetzen.
Es müsste also wirklich über die Befehlserkennung laufen.
Ich werde mal noch ein paar Sachen testen und eventuell frustriert abbrechen 😁

Danke euch!

[Tico]

Das Problem mit Sensordaten und getrennten Eingaben für Abschnitte der Daten ist die Zeitverzögerung zwischen dem Lesen. Virtuelle HTTP-Eingänge haben eine Zeitverzögerung zwischen jedem getrennten Eingang. Ein Sensorwert kann beim Aufbau des Gesamtwertes wilde Fehler aufweisen (d.h. 4 virtuelle Eingaben für einen Sensorwert benötigen eine endliche Zeit, um sich zu aktualisieren).

Sie könnten stattdessen die virtuellen Eingaben auf 10 reduzieren und dann einige Formelblöcke verwenden. Jeder Sensorwert wird als ganze Einheit erfasst.

Wie romildo sagte, ist die Befehlserkennung -

1. Sensor
\s0\4\3\2\1

2. Sensor
\s4\4\3\2\1

3. Sensor
\s8\4\3\2\1

usw.

Es folgt das Beispiel des eingehenden Textes 1234.

[svethi]

Manchmal braucht es halt nen anderen Blickwinkel ;-)

[Christian Fenzl]

Das ist aber nur eine halbe Lösung für EINEN von 10 Werten 😜
Da fehlt noch das Zusammenfassen und Umrechnen von Hex auf DEC in einen Wert.
Und dann das ganze mal 10.
Doch ein Horror 🙂

[Gerd Clever]

Naja, ich gehe davon aus, dass nicht wirklich alle 10 Werte benötigt werden. Wenn's einem wirklich wichtig ist, ist das auf diese Weise immerhin machbar. Man kann schließlich den gesamten Block für einen Wert fertigstellen und dann 9 mal kopieren. Allerdings kann man dann nur hoffen, dass die Lösung die nächsten 50 Jahre ohne Wartung läuft ...

[svethi]

Hmm, kannst Du den (kompletten) Wert auch in einen virtuellen Texteingang pushen? Dann könnte man vielleicht eher was mit PicoC machen

[Tico]

Christian Fenzl put the challenge out there....I thought I would oblige.

Here's version 2. I've used the hex value in the first post of sensor number 10 (FF03) -



Note that using the final decimal value might not be applicable for all sensors. A sensor could instead represent a bitfield.

ie. hex 0101 might reflect the switching status of 4 relays - 2 relays on, 2 relays off. The decimal value that will pop out will be 257. That has no relevance to the sensor.

Hopefully not too horrible .

[Christian Fenzl]

Tico Didn't know this is a challenge, but "Challenge accepted"

LoxBerry XL

#!/usr/bin/env php
<?php
// Start 16:07
require_once "loxberry_XL.php";
$rawdata = '{"cid":-1,"data":{"value":"0001FC000008FF000002FF000157FF0 00022FF03"},"code":200}';
// $rawdata = file_get_contents("http://my.url/to/data.json");
$data=json_decode($rawdata);
$toms = str_split( $data->data->value, 4 );
foreach( $toms as $index => &$val ) {
    $val = hexdec( $val );
    $mqtt->retain( "iolink/$index", $val);
}
// Finished 16:17 ;-)

Result:

[Tico]

Hallo Gast Ich wollte gerne wissen, ob Sie Erfolg bei der Datenbeschaffung hatten?

Entschuldigung für die späte Rückmeldung!
Ich habe dein Beispiel nachgebaut und es funktioniert hervorragend!
Vielen Dank für deine Hilfe!!!
Auch an den Rest vielen herzlichen Dank für eure Tipps!
Ich wünsche ein schönes Weihnachtsfest und einen guten Rutsch ins neue Jahr!

[Steiny]

Hallo Zusammen,

danke für diesen Eintrag - ich habe beinahe das gleiche Szenario wie Andreas S. ursprünglich geschildert hat, nur kommt bei mir erschwerend dazu, dass im HEX-Wert von in Summe 5 Werten, 3 als 32-Bit Fließkommazahl nach IEEE754 Standard übermittelt werden.

Konkretes Beispiel: {"cid":-1,"data":{"value":"44174C3C48D2F78F3E9F0D2E008B01"},"code":200}
Die färblich markierten Stellen sind die 3 besagten 32-Bit Fließkommazahlen nach IEEE754.

Gibt es irgendwie eine Möglichkeit, dass mit Loxone-Bordmittel auf die tatsächlichen Dezimalwerte umzurechnen ?

Vielen Dank!

MFG

[Tico]

Ja, es sollte möglich sein, mit den Standardressourcen von Loxone in Dezimalzahlen zu konvertieren.

Hier ist ein Link zu einem Wiki-Artikel, der das Verfahren beschreibt -

https://loxwiki.atlassian.net/wiki/spaces/LOXEN/pages/1371996216/Convert+hexadecimal+string+to+a+number+Part+2

Wenn Sie die Lektüre des Wikis beendet haben, fahren Sie fort: ....

Beachten Sie, dass Sie für Ihre Anwendung 8 Hex-Zeichen für jeden Wert eingeben müssen. Loxone unterstützt maximal 6 Hex-Zeichen für jeden virtuellen Eingang.

Für das erste Hexadezimal-Beispiel, 44174C3C, benötigen Sie einen virtuellen Eingang, der die ersten 6 Hexadezimal-Zeichen abruft (44174C). Verwenden Sie dazu den Formel-Block '6 x UPPER' aus dem Wiki-Download.

Ein zweiter virtueller Eingang wird die letzten beiden Hex-Zeichen (3C) abrufen. Verwenden Sie den Formel-Block '2 x UPPER' aus dem Wiki-Download.

Der "6 x UPPER"-Formelblock wird einen Wert ausgeben. Dieser muss mit 256 multipliziert und dann zur Ausgabe des Formblocks "2 x UPPER" addiert werden.

Um 44174C3C zu konvertieren, sieht die Seite also wie folgt aus -



Das nächste Beispiel, 48D2F78F, würde zwei virtuelle Eingänge mit Befehlserkennung erfordern -

\ivalue":"\i\s8\6\5\4\3\2\1
\ivalue":"\i\s14\2\1

Das nächste Beispiel, 3E9F0D2E, würde eine Befehlserkennung erfordern -

\ivalue":"\i\s16\6\5\4\3\2\1
\ivalue":"\i\s22\2\1

Schließlich werden Sie ein leichtes Flackern in den Werten haben, wenn die beiden virtuellen Eingänge zu jeder Formel ausgeführt werden. Wir können dies später beheben, um das zeitliche Problem zwischen den Wertaktualisierungen zu beseitigen.

[Steiny]

Vorweg, danke für die Prompte Info!
Das Einleisen der 8 Stellen HEX-Wert ist mir damit klar, aber wie wird dann der tatsächliche Dezimalwert errechnet ? Wie gesagt handelt es sich hierbei um eine 32-Bit Fließkommazahlen nach IEEE754. Die "einfache" Umrechnung von HEX auf Dezimal reicht hier nicht aus bzw. liefert keinen validen Wert.

Siehe: https://de.wikipedia.org/wiki/IEEE_754

Danke!

MFG

[Tico]

Ahh, ich habe den IEEE 754-Teil überlesen. Ich hoffe, Sie wollen die Daten wirklich, denn in Loxone-Blöcken wird es teuer...!

Die oben abgeleitete Dezimalzahl muss wieder in Bits zerlegt werden. Wir verwenden die Decimal to Binary Decoder Blöcke.



Die Mantisse, der Exponent und das Vorzeichen können dann gebildet werden.

Mantisse (23 Bits)
Exponent (8 Bits)
Vorzeichen (1 Bit)

Hier ist ein Link zu einem Thread mit herunterladbaren Loxone-Dateien -

https://www.loxforum.com/forum/german/software-konfiguration-programm-und-visualisierung/242537-abb-wechselrichter-mit-rs485#post246707

https://www.loxforum.com/forum/german/software-konfiguration-programm-und-visualisierung/242537-abb-wechselrichter-mit-rs485#post247136

Die wichtigste Einschränkung von Loxone besteht darin, dass das Wertefeld zum Abruf in Teile zerlegt und dann wieder zusammengesetzt werden muss. Loxone Virtual Inputs werden in Serie ausgeführt. Der zeitliche Schluckauf verursacht eine kurze Datenfluktuation. Die obige Methode führt zu einer Überverarbeitung der Daten, hat aber den Vorteil, dass nur zwei Virtuelle Eingänge (mit nur einem Schluckauf beim Aufbau der Daten) benötigt werden. Einer dieser virtuellen Eingänge enthält die gesamte Mantisse (plus ein Bit des Exponenten).

Eine Alternative ist die Verwendung von vier Virtual Inputs, um die 4 Bytes zu erfassen. Diese vier virtuellen Eingänge werden dann direkt in die Binär-Dezimal-Decoder-Blöcke gesteckt. Der Vorteil ist, dass weniger Überarbeitungen anfallen. Der Nachteil ist, dass drei Schluckaufs auftreten, wenn die Daten aufgebaut werden.

[Steiny]

Vielen, vielen Dank! Das hilft mir schon um einiges weiter.
Ich werde das gleich mal testen. :-)

MFG