Typkovertierungsproblem

IP-Symcon Skripte, PHP, SQL (Fragen)
1

Ich hänge mal wieder n einem Typkonvertierungsproblem mit meinem Deye Wechselrichter und die PHP Funktionen machen mich kirre im Kopf. Vielleicht liegts auch an der bescheuerten Datendarstellung, die die Chinesen da eingebaut haben.

Ich muss einen String „0253“ den ich habe und der für 2:53 Uhr steht in einen zwei Zeichen langen String umwandeln, dessen erstes Zeichen 0x02 und das zweite Zeichen 0x53 also ein Hex-Wert, der aber genau den Zahlen im Ausgangsstring entspricht. Mit den Funktionen aus dem PHP Handbuch komme ich irgendwie nicht weiter.

Deye
Deye814×79 2.71 KB

2

Da sollte dir erstmal

helfen. Damit kannst du die ersten zwei Stellen nehmen oder die letzten zwei oder … :wink:

Warum hex Wert?

3

hex2bin
dann wird der Input String als Hex Darstellung angenommen und raus kommt ein String mit 2 Bytes für 0x02 und 0x53

$Data ='0253';
$raw = hex2bin($Data);
var_dump($raw);
var_dump(ord($raw[0]));
var_dump(ord($raw[1]));
var_dump(dechex(ord($raw[0])));
var_dump(dechex(ord($raw[1])));

string(2) "S"
int(2)
int(83)
string(1) "2"
string(2) "53"

Michael

4

OK, da hab ich mich vielleicht etwas undeutlich ausgedrückt.
Der Deye hat immer einen 16 Bit Wert in einem Register und der kommt beim Lesen als zwei Zeichen String. Normalerweise sind das ganz normale vorzeichenlose Short-Integerwerte. Es wäre schön, wenn die Funktion SendDataToParent da Integerwerte akzeptieren würde, aber ich muss das ja als JSON String codieren. Mit „pack“ ist das bei normalen Integern kein Problem.
Die Zeitangaben sind aber im anders codiert. Da stehen im ersten Byte die Stunden und im zweiten die Minuten und zwar so, dass man es direkt lesen kann. von 0 bis 9 ist das kein Thema, aber die 10 muss halt eben dann auch eine 0x10 sein. 0x0A bis 0x0F gibt es nicht. Noch schlimmer wird es bei den Minuten. Da hat man das gleiche Spiel auch bei 0x29 gefolgt von 0x30, da es 0x2A bis 0x2F nicht gibt. Es ist also eher ein kastriertes Hex, wenn man das so definieren kann.

Alles natürlich unter der Voraussetzung, das ich diese verdammte aus dem chinesischen übersetzte Beschreibung richtig deute.

5

Also ich blick langsam nicht mehr durch, was der Wechselrichter von mir will. Jetzt habe ich den Wert fix auf ‚0000‘ gesetzt, was ja auch 0x00,0x00 für die beiden Zeichen im zu sendenden String macht. Die Daten kommen auch beim Wechselrichter an, aber der zeigt mir im Display 03:35 Uhr!! Da wird man echt blöd im Kopf.

6

So, ich hab den Spieß mal rum gedreht und geschaut, was der Deye Wechselrichter an Werten überhaupt ausgibt.
Wenn im Deye eine Uhrzeit von 1:00 eingestellt ist, dann kommt 0x0064 zurück (entspricht 100 dezimal und passt daher zu 1:00Uhr). Es ist also doch dezimal Codiert.
Stelle ich am Wechselrichter 1:05Uhr ein, dann liefert er 0x0069, was auch passt.
Jetzt muss ich nur den UnixTimestampTime genau in dieses Format bringen. Da scheitere ich schon daran, dass mit IPS zum Beispiel beim Einstellen einer Zeit von 00:00 im Webfront an die Funktion ein Wert von -3600 zurück gegeben wird. Da hätte ich ja eine 0 erwartet.

7

Der TimeStamp ist UTC, die Anzeigen in der Console und WebFront sind lokale Zeit.
Somit musst du die Differenz der Zeitzone des Server beachten.

8

Ja das weiß ich, und ich setze auch mit der php-Funktion „date_default_timezone_set“ auf CET. Wäre jetzt nur die Frage, ob diese Funktion dann nur im Modul wirkt oder ob die dann mein ganzes IPS System umstellt und es hier zu Verwerfungen kommt.

9

Ich würde die aktuelle zeitzone auslese und dann die Differenz einfach hinzurechnen.
Michael

10

Hat funktioniert, date(‚Z‘) liefert ja die Differenz.
Was mich jedoch am Webfront stört ist, dass eine Zeit von 1:00 Uhr nicht dargestellt wird, wenn an der Variable das Profil ~UnixTimestampTime ausgewählt ist. Da erscheint dann nur ein „-“.