Hex-Werte in Temperaturen umrechnen?

[Stefan S. (kami)]

Hallo zusammen,

ich habe hier von eine RFlink 433 Mhz Empfänger, der von folgenden 
Sensoren Telegramme empfängt.

https://www.plantcaretools.com/de/onlineshop/drahtloser-bodenfeuchte-sensor-detail

Die Sensoren senden +/- Temperatur und Bodenfeuchtewerte.

Die empfangenen HEX Werte sollen einen MSB und LSB Bereich habe und das 
Erste Bit gibt an ob Positiv oder negativ. Nun suche ich (am besten in 
Perl) eine Funktion, um diese Werte in plausibele Temperaturwerte 
umzurechnen. Hier ist ein Beispieloutput von 3 Sensoren aus meinem 
Garten. Die Aussenlufttemperatur betrug so 22-25 °C. Wie kann man das 
machen?

20;F5;Imagintronix;ID=0003;TEMP=0258;HUM=5c;
20;F9;Imagintronix;ID=0002;TEMP=01e8;HUM=5c;
20;01;Imagintronix;ID=0003;TEMP=0260;HUM=5c;
20;06;Imagintronix;ID=0001;TEMP=0220;HUM=37;
20;08;Imagintronix;ID=0003;TEMP=0260;HUM=5c;
20;0E;Imagintronix;ID=0002;TEMP=01e8;HUM=5c;
20;14;Imagintronix;ID=0002;TEMP=01e8;HUM=5c;
20;1E;Imagintronix;ID=0001;TEMP=0228;HUM=38;
20;28;Imagintronix;ID=0002;TEMP=01e8;HUM=5c;
20;2D;Imagintronix;ID=0001;TEMP=0220;HUM=38;
20;30;Imagintronix;ID=0003;TEMP=0260;HUM=5c;
20;36;Imagintronix;ID=0001;TEMP=0220;HUM=38;
20;38;Imagintronix;ID=0003;TEMP=0258;HUM=5c;
20;3F;Imagintronix;ID=0001;TEMP=0218;HUM=38;
20;46;Imagintronix;ID=0003;TEMP=0250;HUM=5c;
20;47;Imagintronix;ID=0002;TEMP=01e8;HUM=5c;
20;48;Imagintronix;ID=0001;TEMP=0218;HUM=38;
20;51;Imagintronix;ID=0001;TEMP=0210;HUM=38;
20;5B;Imagintronix;ID=0002;TEMP=01e8;HUM=5c;

Danke und Gruß kami

[nicht"Gast" (Gast)]

Is ja fies. Wer hat denn lmgtfy gesperrt?

https://www.google.de/?gws_rd=ssl#q=pearl+hexascii+to+int

[Stefan S. (kami)]

Hi,

also irgendwie stehe ich nun auf dem Schlauch. Ich kann zwar Googlen :) 
Habe ich auch schon gemacht aber ich glaube ich habe noch nicht ganz 
verstanden, was für ein HEX Wert mir da eigentlich vorliegt.

Gruß kami

[Georg (Gast)]

Stefan S. schrieb:
> ich habe noch nicht ganz
> verstanden, was für ein HEX Wert mir da eigentlich vorliegt.

Dafür gibt es z.B. den Rechner von Windows, einfach Ansicht auf 
"Programmierer" und den Wert als HEX eintippen, umstellen auf DEZ.

Das löst aber das Problem nicht, was die Zahlen darstellen sollen. Hex 
258 ist dezimal 600, aber 60 Grad werden es bei dir im Garten wohl nicht 
sein.

Übrigens, egal wie das jetzt kodiert ist, die Genauigkeit ist natürlich 
reine Angabe. Weder wird die Temperatur auf 3 Stellen gemessen noch die 
Feuchtigkeit auf 2.

Georg

[Stefan S. (kami)]

Hallo,

genau da ist ja auch eigentlich das Problem. Also die Feuchtigkeitswerte 
bis 255 klappen super da kriege ich in DEZ 0-100 %. Aber bei den 
Temperaturen sind es ja zwei einzelne Werte. 02 60 zum Beispiel und die 
Werte in dieser Tabelle müssten alle positiv sein. Also wie stelle ich 
die richtig in Dezimal da müssten auch alle Mal 10 sein. Also (DEZ)255 = 
25,5 °C.

Wie kann das also gehen.

Gruß kami

[PG-For (Gast)]

>Wie kann das also gehen.

Mit den mit einem anderen Thermometer gemessenen (verschiedenen)
Temperaturen vergleichen und daraus Schlüsse
ziehen ist zu einfach?

[PG-For (Gast)]

>Aber bei den
>Temperaturen sind es ja zwei einzelne Werte.

Nein, das sind vermutlich 2 Bytes eines Wertes.

>02 60 zum Beispiel und die
>Werte in dieser Tabelle müssten alle positiv sein

rohwert = 0x260, mit gemessenem Wert vergleichen
und Umrechungsfaktor bestimmen?
Und das für mehrere Werte...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stefan S. schrieb:
> was für ein HEX Wert mir da eigentlich vorliegt.
Das was du da gepostet hast, sind ASCII-Zeichen: "TEMP=01e8" ist also 
ein String.

Stefan S. schrieb:
> Also (DEZ)255 = 25,5 °C.
Nehmen wir mal ein paar deiner Werte und zeigen die als Dezimalwerte an 
(ich will da nicht "umrechnen" sagen, weil es ja genu die selbe Zahl 
ist, nur eben anders dargestellt)
hex   dez
01e8  488
0220  544
0260  608

Wenn ich das jetzt durch 20 teilen würde, käme ich auf
24,4
27,2
30,4
Passt irgendwie nicht zu deinen 22-25°C...  :-(

Stefan S. schrieb:
> Die Aussenlufttemperatur betrug so 22-25 °C
Warum sind die 3 Sensorwerte so unterschiedlich? Sonne-Schatten? Leg die 
Sensoren mal nah aneinander und sieh mal, ob die wenigstens annähernd 
gleiche Werte liefern...

[Marc V. (Firma: Vescomp) (logarithmus)]

Lothar M. schrieb:
> Warum sind die 3 Sensorwerte so unterschiedlich? Sonne-Schatten? Leg die
> Sensoren mal nah aneinander und sieh mal, ob die wenigstens annähernd
> gleiche Werte liefern...

 Und werden die Werte so geliefert wie von dir gepostet oder hast du
 diese in ASCII umgewandelt ?

[Stefan S. (kami)]

Hallo,

also in der Dokumentation steht folgendes:

TEMP=9999       => Temperature (hexadecimal), high bit contains negative 
sign, needs devision by 10
HUM=99          => Humidity (hexadecimal)

Ich habe auch das selbe Probleme, das ich auf keine plausiblen Werte 
kommen. Kennt vielleicht einer eine Umrechnung?

Bei den anderen Werten ist das irgendwie plausibel von Oregon 
Temperatursensoren.

Die Werte sind doch recht vergleichbar, wenn man so guckt oder? Baue die 
sonst nachher nochmal raus.

Gruß kami

[Frank M. (ukw) (Moderator)]

Lothar M. schrieb:
> hex   dez
> 01e8  488
> 0220  544
> 0260  608
>
> Wenn ich das jetzt durch 20 teilen würde, käme ich auf
> 24,4
> 27,2
> 30,4
> Passt irgendwie nicht zu deinen 22-25°C...  :-(

Teile doch mal durch 24 :-)

hex   dez  Temp
01e8  488  20,3
0220  544  22,6
0260  608  25,3

Passt schon besser. Auch die 20,3°C lasse ich bei der vagen Formulierung 
"Die Aussenlufttemperatur betrug so 22-25 °C." noch gelten.

[Frank M. (ukw) (Moderator)]

Stefan S. schrieb:
> also in der Dokumentation steht folgendes:
>
> TEMP=9999       => Temperature (hexadecimal), high bit contains negative
> sign, needs devision by 10

Das scheint aber nicht auf Deine Werte übertragbar zu sein. Da kommt 
unsinniges raus.

> Ich habe auch das selbe Probleme, das ich auf keine plausiblen Werte
> kommen. Kennt vielleicht einer eine Umrechnung?

Du bist doch der TO, oder? Wieso schreibst Du jetzt "auch"?

Mein Tipp: Stelle ein anderes Thermometer daneben und dann poste 
folgende Tabelle:

  Hex-Wert  gemessen
  ------------------
  xxxx        xx°C
  xxxx        xx°C
  ...

Dann kommen wir vielleicht weiter.

[Georg (Gast)]

Frank M. schrieb:
> Passt schon besser.

Ist aber reines raten. Es gibt nur 2 Möglichkeiten:

1. Es taucht eine Beschreibung auf, in der der Aufbau der Daten erklärt 
wird.

2. Die Sensoren kalibrieren - draussen ausbauen und zusammen mit einer 
präzisen Temperaturanzeige auslesen, wenn möglich in einem Wasserbad. 
Fieberthermometer z.B. sind sehr genau. Das ganze möglichst für alle 3 
Sensoren, da sollte das gleiche rauskommen - aber was weiss man schon.

Georg

[Dirk B. (dirkb2)]

Und ein paar Messwerte aus dem Kühlschrank schaden auch nicht.

[Stefan S. (kami)]

Hallo,

kann das Plugin zur Auswertung der Telegramme vielleicht weiterhelfen?

//#######################################################################################################
//##                    This Plugin is only for use with the RFLink software package                   ##
//##                                        Plugin-35 Imagintronix                                     ##
//#######################################################################################################
/*********************************************************************************************\
 * This plugin takes care of decoding Imagintronix sensors
 * 
 * Author             : StuntTeam
 * Support            : http://sourceforge.net/projects/rflink/
 * License            : This code is free for use in any open source project when this header is included.
 *                      Usage of any parts of this code in a commercial application is prohibited!
 *********************************************************************************************
 * Changelog: v1.0 initial release
 *********************************************************************************************
 * Technical information:
 * 
 * ~0.5ms high puls followed by ~1ms pause = high
 * ~1.5ms high puls followed by ~1ms pause = low
 * 
 * Message Format: 
 * 11111111 01010101 00000101 01000101 11111111 10011110
 * FF550545FF9E
 * AABCDDEEFFGG
 *
 * A = Preamble, always FF
 * B = TX type, always 5
 * C = Address (5/6/7) > low 2 bits = 1/2/3
 * D = Soil moisture 05% 
 * E = temperature 
 * F = security code, always F
 * G = Checksum 55+05+45+FF=19E CRC value = 9E
 *
 * Sample:
 * 20;02;DEBUG;Pulses=96;Pulses(uSec)=390,870,420,870,420,870,420,870,420,870,420,870,420,870,420,870,1260,870,420,870,1260,870,420,870, 1230,870,420,870,1260,870,420,870,1260,870,1260,870,1260,870,1230,870,1260,870,420,870,1260,870,420,870,1260,870,420,870,1260,870,1260,870,1260,870,420,870,1260,870,420,870,420,870,420,870,420,870,420,870,420,870,420,870,420,870,420,870,420,870,1230,870,1260,870,420,870,420,870,420,840,420,840,1260,6990;
 * 111111110101010100000101010001011111111110011110
 \*********************************************************************************************/
#define IMAGINTRONIX_PULSECOUNT 96
#define IMAGINTRONIX_PULSEMID   1000/RAWSIGNAL_SAMPLE_RATE
#define IMAGINTRONIX_PULSESHORT 550/RAWSIGNAL_SAMPLE_RATE

#ifdef PLUGIN_035
boolean Plugin_035(byte function, char *string) {
      if (RawSignal.Number != IMAGINTRONIX_PULSECOUNT) return false;
      unsigned int temperature=0;
      unsigned int rc=0;
      
      byte checksum=0;
      byte data[8];
      unsigned long bitstream=0L;
      //==================================================================================
      byte bytecounter=0;                           // used for counting the number of received bytes
      byte bitcounter=0;                            // counts number of received bits (converted from pulses) 
      // get bits
      for(byte x=1;x < IMAGINTRONIX_PULSECOUNT;x=x+2) {
         if (RawSignal.Pulses[x] > IMAGINTRONIX_PULSEMID) {     // long pulse = 0 bit
            if (x < 95) if ((RawSignal.Pulses[x+1] > IMAGINTRONIX_PULSEMID) || (RawSignal.Pulses[x+1] < IMAGINTRONIX_PULSESHORT)) return false;
            data[bytecounter] = (data[bytecounter] << 1);       // 0 bit
            bitcounter++;                           // received a bit
         } else {                                               // Short pulse = 1 bit
            if (RawSignal.Pulses[x] > IMAGINTRONIX_PULSESHORT) return false; // Short pulse too long? 
            if (x < 95) if ((RawSignal.Pulses[x+1] > IMAGINTRONIX_PULSEMID) || (RawSignal.Pulses[x+1] < IMAGINTRONIX_PULSESHORT)) return false;
            data[bytecounter] = (data[bytecounter] << 1) | 0x1; // 1 bit
            bitcounter++;                        // received a bit
         }
         // prepare for next bit/byte
         if (bitcounter==8) {                 // received 8 bits?
            bitcounter=0;                     // reset for next byte
            bytecounter++;                    // byte received, increase counter
            if (bytecounter > 7) return false; // overflow, should not happen
         }
      }
      //==================================================================================
      // Verify packet and calculate checksum
      //==================================================================================
      if (data[0] != 0xff) return false;
      checksum=data[1]+data[2]+data[3]+data[4];
      if (((checksum)&0xff) != data[5]) return false;
      if ( (data[1] >>4) != 0x5) return false;
      if (data[4] != 0xff) return false;
      //==================================================================================
      // Prevent repeating signals from showing up
      //==================================================================================
      if( (SignalHash!=SignalHashPrevious) || (RepeatingTimer+1000<millis()) ) { 
         //SignalCRC=bitstream;                       // not seen the RF packet recently
      } else {
         return true;                               // already seen the RF packet recently
      }
      //==================================================================================
      rc=(data[1])&0x03;
      temperature=(data[3]) << 4; 
      temperature=temperature/2;
      //==================================================================================
      // Output
      // ----------------------------------
      sprintf(pbuffer, "20;%02X;", PKSequenceNumber++); // Node and packet number 
      Serial.print( pbuffer ); 
 
      Serial.print(F("Imagintronix;")); 
              // Label
      sprintf(pbuffer, "ID=%04x;", rc);             // ID    
      Serial.print( pbuffer ); 

      sprintf(pbuffer, "TEMP=%04x;", temperature);     
      Serial.print( pbuffer ); 

      sprintf(pbuffer, "HUM=%02x;", data[2]);     
      Serial.print( pbuffer ); 

      Serial.println();
      //==================================================================================
      RawSignal.Repeats=true;                       // suppress repeats of the same RF packet
      RawSignal.Number=0;
      return true;
}
#endif // PLUGIN_035

Gruß kami

[Frank M. (ukw) (Moderator)]

Georg schrieb:
> Ist aber reines raten.

Ja, natürlich. Mein Beitrag mit "Teile durch 24" sollte dies auch 
suggestiv verdeutlichen. Hat bei Dir auch gewirkt :-)

Denn was soll man mit gerade mal 3 Werten und der Angabe "so 22-25°C" 
denn anfangen?

Genau, gar nichts.

[Georg (Gast)]

Stefan S. schrieb:
> sprintf(pbuffer, "TEMP=%04x;", temperature);

Gibt eben die Temperatur als 4stelligen HEX-Wert aus, bringt also keinen 
Schritt weiter.

Georg

[Stefan S. (kami)]

Hallo,

es ist so, das ich zur Zeit davon ausgehe, das ich nur zu doof bin die 
Hex-Werte richtig umzurechnen. Aus dem Grund dachte ich jemand hat hier 
schon Erfahrungen damit, weil es garantiert eine STANDARD-Umrechnung 
ist.

Diese HEX-Werte müssten Temperaturen um die 20°C wiedergeben und nicht 
Werte die deutlich drüber oder drunterliegen. Das Problem ergibt sich 
eigentlich auch erst bei werden über 25,5 Grad. Bis dahin war meine 
Umrechnung immer plausibel weil 01e8 = 01 positiver Wert und e8 = 232 
entspricht also +23,2 Grad.

Nur halt wenn vorne ne 2 steht dann gibt es Mist.

Gruß kami

[H.Joachim S. (crazyhorse)]

Es gibt die wunderlichsten Codierungen, schön zu sehen z.B. auch in der 
CAN-Matrix diverser Hersteller :-)

Es könnte auch z.B. auch folgendes sein:
das erste Byte gibt ganze 10° aus, das zweite 10/256°

hex   Temp
01 e8  10°+ 9,048°
02 20  20°+ 1,248°
02 60  20°+ 3,744°

[Rufus Τ. F. (rufus)]

Stefan S. schrieb:
> Bis dahin war meine Umrechnung immer plausibel weil 01e8 = 01 positiver
> Wert

Nein. Das oberste Bit hat den Wert 8000, die 01 gehört zum Wert dazu.

Eine negative Temperatur dürfte also Werte größer 8000 liefern.


Der "Standard" zum "umrechnen" von hexwerten ist die Betrachtung als 
Zahl, und was da rauskommt hat Frank schon beschrieben:


 hex dez Temp
01e8 488 20,3
0220 544 22,6
0260 608 25,3

Die Information, daß der Wert den Faktor 10 enthielte, ist 
offensichtlich falsch, aber Franks Faktor 24 erscheint bei den Werten 
plausibel.

Und wenn Du mehr rausfinden willst: Pack den Sensor in den Kühlschrank 
und sieh Dir an, was da für Werte rauskommen. Als nächstes packst Du das 
Ding in die Tiefkühltruhe und siehst Dir die Werte an, die dort 
'rauskommen.

Poste die Werte hier, dann kann man durch gemeinsames Draufsehen was 
vermuten.

Nach Franks Hypothese sollten Werte in dieser Größenordnung rauskommen:

10° 00F0
5°  0078
-5° FF88
-10° FF10
-18° FF50

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stefan S. schrieb:
> weil 01e8 = 01 positiver Wert und e8 = 232
Das ist aber eine sehr verwunderliche Interpretation der Spec:
>> TEMP=9999 => Temperature (hexadecimal),
>> high bit contains negative sign,
>> needs devision by 10

Georg schrieb:
> Gibt eben die Temperatur als 4stelligen HEX-Wert aus, bringt also keinen
> Schritt weiter.
Der Trick liegt in der Protokollbeschreibung:

Message Format:
* FF5505  45  FF9E
* AABCDD  EE  FFGG
*
* A = Preamble, always FF
* B = TX type, always 5
* C = Address (5/6/7) > low 2 bits = 1/2/3
* D = Soil moisture 05%
* E = temperature
* F = security code, always F
* G = Checksum 55+05+45+FF=19E CRC value = 9E

Also sind im Beispiel die (von mir freigestellten) 0x45 die Temperatur.

Dieser Wert steht im data[3] und wird von dort ein wenig kurios weiter 
verrechnet:

temperature=(data[3]) << 4;  // mal 16
temperature=temperature/2;   // geteilt durch 2

Und gleich danach kommt die Ausgabe

sprintf(pbuffer, "TEMP=%04x;", temperature); Serial.print( pbuffer );

Letztlich kann aber durch diese Operationen hier NIEMALS das höchste Bit 
gesetzt werden, und es wird auch niemals anderweitig gesetzt. Insofern 
ist die Protokollbeschreibung offenbar unbrauchbarer Schrott...

BTW:
Bitte Quelltexte mit den C-Token umrahmen. Das steht über jeder 
Eingabebox:

Wichtige Regeln - erst lesen, dann posten!

    .....
    Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

    [c]C-Code[/c]

[Stefan S. (kami)]

Hi,

okay das ja ganz aufschlussreich. Dann werde ich mal schauen, was die 
bei Raumtemperatur und im Kühlschrank liefern.

Gruß kami

P.S.: Nächste mal nutze ich C-Code

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stefan S. schrieb:
> P.S.: Nächste mal nutze ich C-Code
Der Trick ist der Teil mit den eckigen Klammern. Dort wo C-Code steht, 
kommt dein C-Code rein. Einfach mal vor dem "Absenden" auf "Vorschau" 
drücken...

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan S. schrieb:
> kann das Plugin zur Auswertung der Telegramme vielleicht weiterhelfen?

 Nein, aber empfangenes Telegramm schon.

 Ausserdem:

      temperature=(data[3]) << 4;
      temperature=temperature/2;

 Nach dieser komischen Umrechnung ist data[3] für:
 0x260 = 0x4C oder 76
 0x218 = 0x43 oder 67
 0x1E8 = 0x3D oder 61

 Bei 3 Grad Unterschied und (76-61) / 3 sollte es sein:
 22°C == 61
 23°C == 66
 24°C == 71
 25°C == 76

 Angenommen, es ist tatsächlich 0.2°C Auflosung, dann könnte es
 sein, dass du folgendes gemessen hast:
 0x1E8 = t
 0x218 = t + 1.2°C
 0x260 = t + 3°C

 Oder auch nicht...

 Ohne Telegramm wird es aber wahrscheinlich nichts, ausserdem liefert
 dein Sensor1 Werte die ziemlich stark voneinander abweichen.

[Peter M. (r2d3)]

Stefan S. schrieb:
> TEMP=9999       => Temperature (hexadecimal), high bit contains negative
> sign, needs devision by 10

Stefan, steht doch fast alles da, Du solltest halt nur gleich von Anfang 
an die vollständige Doku liefern, nicht erst mehrere Beiträge später! 
:)

Da steht, dass das oberste Bit das negative Vorzeichen liefert.
Wir ignorieren die immer gleichen Hexwerte von "20" einfach!*


Du musst einfach nur wissen, dass es zwei Arten gibt, Ganzzahlen mit 
Vorzeichen zu speichern, vorzeichenbehaftete und Zahlen im 
Zweierkomplement.

Gucken wir uns drei 8-Bit-Zahlen:
Zahl  Darstellung vorzeichenbehaftet  Zweierkomplement / dez

-2     1 000 0010    1 111 1110 ||254
-1     1 000 0001    1 111 1111 ||255
0      0 000 0000    0 000 0000 ||0
+1     0 000 0001    0 000 0001 ||1
+2     0 000 0010    0 000 0010 ||2
+3     0 000 0011    0 000 0011 ||3

Du kannst also in einem Byte positve Zahlen von 0-255 kodieren.
Du kannst aber auch sagen, Du reservierst das oberste Bit als 
Vorzeichen.

Dann kannst Du Zahlen von -127 bis +127 darstellen.
Für die Null gibt es gleich zwei Darstellungen, nämlich +0 und -0...

Es gibt aber auch das Zweierkomplement.
Bei der Darstellung kannst Du negative Zahlen auch am gesetzten obersten 
Bit erkennen. Hier sind Werte von -128 bis +127 möglich.

Die Werte F5, F9 und 01 legen nahe, dass es sich um 
Zweierkomplementdarstellung handelt, ansonsten würden die Temperaturen 
zu sehr springen!

Wenn Du immer dann den Messwert von 256 abziehst, wenn das oberste Bit 
gesetzt ist (Dezimalwert>=128) hast Du den Wert als Wert im 
Dezimalsystem mit negativem Vorzeichen:  -(256-245)=-11

"F5" dezimal von( 0-255): 245 umgerechnet  -(256-245)=-11
"F9" dezimal von( 0-255): 249 umgerechnet  -(256-249)=-7
"01" dezimal von( 0-255):   1 umgerechnet  =1
...
"5B" dezimal von( 0-255):   1 umgerechnet  =91

Diesen Wert beziehen sich vermutlich auf einen Nullpunkt und sind 
skaliert.

"F5" dezimal von( 0-255): 245 umgerechnet  -(256-245)=-11
"F9" dezimal von( 0-255): 249 umgerechnet  -(256-249)=-7
"01" dezimal von( 0-255):   1 umgerechnet  =1
...
"5B" dezimal von( 0-255):  91 umgerechnet  =91

Jetzt skalieren wir nach Vorschrift des Herstellers und dividieren durch 
10, also ergibt sich -1,1  -0,7  0,1  9,1


Mein simpler Reichelt-Temperatursensor KTY81-110 hat 1000Ohm bei 25 
Grad.
Deine Messwerte könnten die positiven oder negativen Abweichungen von 
einem Referenzwert darstellen!

Also noch mal geschätzt 25 Grad dazuzählen:

23,9  24,3  25,1  34,1

Das wäre dann die Temperatur in Grad.

Schreibt der Hersteller irgendwas zum Offset?
Dann müssen wir den Offset nicht mehr raten...

Miss mal zwei Punkte die schön auseinander liegen, also morgen früh mal 
und morgen nachmittag und schreibe Dir die Referenztemperaturen auf.
Dann finden wir den Offset auch ohne Herstellerangaben.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter M. schrieb:
> Also noch mal geschätzt 25 Grad dazuzählen:
Das ist aber schon eine sehr gewagte Strategie: sich zwar auf die 
angegebenen "geteilt durch 10" aus dem Datenblatt verlassen, dann aber 
einfach ein Byte ignorieren und einen beliebigen Offset draufaddieren... 
:-o

Mich wundern nach wie vor die sehr unterschiedlichen Temperaturwerte und 
ich frage mich, ob das wirklich die Sensortemperatur war. Denn ein 
schwarzes Gehäuse heizt sich auch bei 25°C Lufttemperatur locker auf 
34°C auf. Und damit läge meine allererste Antwort wieder gut im 
Rennen...

[Peter M. (r2d3)]

Lothar M. schrieb:
> Peter M. schrieb:
>> Also noch mal geschätzt 25 Grad dazuzählen:
> Das ist aber schon eine sehr gewagte Strategie: sich zwar auf die
> angegebenen "geteilt durch 10" aus dem Datenblatt verlassen, dann aber
> einfach ein Byte ignorieren und einen beliebigen Offset draufaddieren...
> :-o

Der Grund für meine verwegene Schätzung ist ein ganz einfacher:

Nehmen wir an, dass "20" das höherwertigere Byte darstellt!

Dann handelt es sich bei allen Werten um positve Werte, weil ja das 
oberste Bit nicht gesetzt ist.

Der Sprung von F9 und 01 entspräche dann roh 248 Werten, bzw. skaliert 
24,8 Grad Differenz.
Der Sensor lag vorher aber wohl nicht im Kühlschrank.
Dieser extreme Anstieg ist unwahrscheinlich!

Folgerung: Bei diesem Sprung handelt es sich offensichtlich um einen 
Nulldurchgang, denn dann enspricht der Anstieg nur 8 Werten, bzw 0,8 
Grad skaliert.

Weil ich bei meinen Anfängerexperimenten mit Spannungsnormalen auch mit 
Temperatursensoren herumspiele weiß ich, dass die Temperatursensoren ja 
Referenzpunkte haben, zum Beispiel Null Grad Celsius für R=100,1000 oder 
10000 Ohm bei den PT-Widerständen oder 25 Grad Celsius beim KTY81-100.

Schaltungstechnisch ist wahrscheinlich die Auswertung mit einem Teiler 
gegenüber einem Referenzteiler am einfachsten.
Dann kommen halt positve und negative Spannungen heraus bezogen auf die 
Nullspannung bei Referenztemperatur.
Und diese Zahlen müssen dann wieder binär kodiert werden.

Das waren so meine Gedanken...
Ich lass' mich auch gerne falsifizieren. Ich würde schon gerne das 
Rätsel entschlüsseln. Dafür muss Stefan aber zwei oder drei einigermaßen 
genaue Messwerte liefern, damit man das dekodieren kann.

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter M. schrieb:
> Die Werte F5, F9 und 01 legen nahe, dass es sich um
> Zweierkomplementdarstellung handelt, ansonsten würden die Temperaturen
> zu sehr springen!

 Für mich ist das ganz einfach ein 8-bit Zähler, der bei 0xFF
 überläuft und wieder bei Null anfängt. Ob er Telegramme oder Zeit
 zählt ist unwichtig.
 Du kannst das natürlich als Zweierkomplementdarstellung sehen...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter M. schrieb:
> Dann handelt es sich bei allen Werten um positve Werte, weil ja das
> oberste Bit nicht gesetzt ist.
Das oberste Bit wird niemals gesetzt, weil die zugrundeliegende 
Berechnung das gar nicht hergibt...

> muss Stefan aber zwei oder drei einigermaßen genaue Messwerte liefern
Genau und zuverlässig wäre gut. Am besten Werte von allen 3 Sensoren 
nebeneinander im Schatten bei einem anderen Thermometer... ;-)

[Marc V. (Firma: Vescomp) (logarithmus)]

EDIT ging nicht mehr, also:
 Im Telegramm steht in data[3] der von Sensor gesendete Temperaturwert.
 Es ist ein 8 bit Wert, wird erst vom Plugin (auf etwas ungewöhnliche
 Weise) in einen 16 bit umgewandelt.
 Die Ursprungswerte für data[3] im Telegramm gehen von etwa 61 bis 75.
 Das ergibt eine Differenz von 15 für 3 Grad Unterschied, demzufolge
 hat der Sensor eine Auflösung von etwa 0.2C - immer vorausgesetzt,
 die angegebene Temperatur von 22-25C stimmt.
 Aber auch nach dieser Rechnung kann 0C nicht angezeigt werden, also
 ist das Ganze ohne Telegramm und eingermassen genaue Temperatur
 sinnlos.

[Peter M. (r2d3)]

Noch ein Nachtrag:

* Message Format: 
 * 11111111 01010101 00000101 01000101 11111111 10011110
 * FF550545FF9E
 * AABCDDEEFFGG
 *
 * A = Preamble, always FF
 * B = TX type, always 5
 * C = Address (5/6/7) > low 2 bits = 1/2/3
 * D = Soil moisture 05% 
 * E = temperature 
 * F = security code, always F
 * G = Checksum 55+05+45+FF=19E CRC value = 9E

Leute, guckt mal, im Protokoll sind nur zwei Nibbles, also ein Byte für 
die Temperatur vorgesehen.

Ich kann kaum C, aber hier werden wohl die obersten 4 Bit der Temperatur 
weggeschmissen:

 temperature=(data[3]) << 4; 
      temperature=temperature/2;

Das macht keinen Sinn!
Wir kommen hier nicht weiter, weil uns der obige Code nicht die Rohdaten 
liefert.
Stefan, liefer mal die Rohdaten der Temperatur!
Ersetze:

sprintf(pbuffer, "TEMP=%04x;", temperature);

sprintf(pbuffer, "TEMP=%02x;", data[3]);

Und dann fangen wir noch einmal von vorne an!
Was ich versucht habe auszuwerten, ist die Sequence-Nummer, aber nicht 
das rohe Temperaturdatum.
Was bis jetzt hinter "TEMP=" stand, verwirrt nur...

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter M. schrieb:
> Ich kann kaum C, aber hier werden wohl die obersten 4 Bit der Temperatur
> weggeschmissen: temperature=(data[3]) << 4;
>       temperature=temperature/2;
> Das macht keinen Sinn!

 Da wird gar nichts weggeschmissen, Temperatur ist mit Null deklariert.
 Und data[3] wird einfach ins Temperatur ubernommen, mit 16
 multipliziert und  gleich danach mit 2 geteilt.
 Das man ein Byte nur selten ohne Überlauf mit 16 multiplizieren kann
 ist klar, aber warum nicht gleich mit 8 multiplizieren ist mir immer
 noch nicht klar...

[Frank M. (ukw) (Moderator)]

Peter M. schrieb:
> Ich kann kaum C, aber hier werden wohl die obersten 4 Bit der Temperatur
> weggeschmissen:

Stimmt nicht, denn:

  unsigned int temperature=0;

Ich nehme mal an, dass ein int hier mindestens 16 bit hat.

Marc V. schrieb:
> warum nicht gleich mit 8 multiplizieren ist mir immer
>  noch nicht klar...

Eben, kommt mir auch spanisch vor.

Aber:

Wenn das Byte mit 8 multipliziert wird und jeder Schritt 1/3 Grad 
bedeutet, dann ist meine (gewagte) Hypothese (s.o.), einfach den Wert 
durch 24 zu teilen, absolut richtig :-))))

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter M. schrieb:
> Was ich versucht habe auszuwerten, ist die Sequence-Nummer, aber nicht
> das rohe Temperaturdatum.
 Aha.
 Deswegen wohl:
> Die Werte F5, F9 und 01 legen nahe, dass es sich um
> Zweierkomplementdarstellung handelt, ansonsten würden die Temperaturen
> zu sehr springen!
> Der Sprung von F9 und 01 entspräche dann roh 248 Werten, bzw. skaliert
> 24,8 Grad Differenz.

[Marc V. (Firma: Vescomp) (logarithmus)]

Frank M. schrieb:
> Wenn das Byte mit 8 multipliziert wird und jeder Schritt 1/3 Grad
> bedeutet, dann ist meine (gewagte) Hypothese (s.o.), einfach den Wert
> durch 24 zu teilen, absolut richtig :-))))

 Ich habe auch zuerst mit 3 gerechnet,aber dann erschien mir die
 Auflösung von 0,33C zu grob.
 Diese Rechnung könnte hinhauen, aber nur wenn man 20.3C als untersten
 Wert betrachtet.
 Dann ist 20.3 * 3 = 61 was in etwa stimmen kann.
 Und auch 25C * 3 = 75 was auch stimmen kann.

 Ohne genaue Temperaturmessung ist das alles nur stochern im Nebel.

[Peter M. (r2d3)]

Marc V. schrieb:
> Peter M. schrieb:
>> Ich kann kaum C, aber hier werden wohl die obersten 4 Bit der Temperatur
>> weggeschmissen: temperature=(data[3]) << 4;
>>       temperature=temperature/2;
>> Das macht keinen Sinn!
>
>  Da wird gar nichts weggeschmissen, Temperatur ist mit Null deklariert.
>  Und data[3] wird einfach mit 16 multipliziert und gleich danach mit
>  2 geteilt - warum nicht gleich mit 8 multiplizieren ist mir immer
>  noch nicht klar...

Ich kann kaum C. :(
Wenn das Shiften auf 16Bit läuft, hast Du Recht.
Wenn das auf 8Bit liefe, dann ist es gleichbedeutend mit Multiplikation 
mit 8 und Löschung des höchsten Bits (Vorzeichen?).

[Anja (Gast)]

Frank M. schrieb:
> Wenn das Byte mit 8 multipliziert wird und jeder Schritt 1/3 Grad
> bedeutet, dann ist meine (gewagte) Hypothese (s.o.), einfach den Wert
> durch 24 zu teilen, absolut richtig :-))))

Widerspricht aber der Anleitung.
Frage: meint der Hersteller tatsächlich Grad Celsius oder Grad 
Fahrenheit? (oder sonst noch was).

Gruß Anja

[Frank M. (ukw) (Moderator)]

Anja schrieb:
> Widerspricht aber der Anleitung.

Korrekt, wurde oben aber auch schon festgestellt.

> Frage: meint der Hersteller tatsächlich Grad Celsius oder Grad
> Fahrenheit? (oder sonst noch was).

Das ist ein sehr interessanter Anzatz! Könnte man ja mal umrechnen:

hex   dez  dez/8   Temp (°F)   Temp (°C)
01e8  488  61       61          16,1
0220  544  68       68          20,0
0260  608  76       76          24,4

Ich habe hier mal mit Achtel-Werten gerechnet, weil lt. C-Programm eine 
Multiplikation mit 8 stattfindet. Der Temperaturbereich von 16°C bis 
24°C ist hier etwas zu groß - vor allen Dingen nach unten. Bei 
Zehntel-Werten (nach Dokumentation) kommen hier aber noch unsinnigere 
Temperaturen raus.

Es bleibt dabei: Messreihe mit möglichst vielen Werten und dann rechnen 
ist immer noch das Mittel der Wahl.

[Stefan S. (kami)]

Hallo zusammen,

erstmal vielen Dank für die wahnsinnig vielen Rückmeldungen auf meine 
Anfrage. Echt klasse.

Ich habe nun auch mal ein paar Messungen gemacht und hier die 
Ergebnisse.

Also in meinem Haus zeigen bei einer Innenraumtemperatur von ca. 25,6 °C 
die Sensoren folgendes  an:

20;AD;Imagintronix;ID=0001;TEMP=0210;HUM=05;
20;B9;Imagintronix;ID=0001;TEMP=0210;HUM=05;

20;1C;Imagintronix;ID=0002;TEMP=0218;HUM=05;
20;25;Imagintronix;ID=0002;TEMP=0218;HUM=05;
20;2F;Imagintronix;ID=0002;TEMP=0218;HUM=05;

20;64;Imagintronix;ID=0003;TEMP=0218;HUM=05;
20;6B;Imagintronix;ID=0003;TEMP=0218;HUM=05;

Die Werte bleiben konstant bei 0210 und 0218


Einen Sensor habe ich mal in den Gefrierschrank -18°C gepackt und dann 
rausgenommen und auf Innenraumtemperatur auf heizen lassen. Zeitabstand 
so alle 3 min ein Wert.

Hier das Ergebnis:


20;23;Imagintronix;ID=0003;TEMP=00d8;HUM=05;
20;35;Imagintronix;ID=0003;TEMP=00d0;HUM=05;
20;50;Imagintronix;ID=0003;TEMP=00c8;HUM=05;
20;5A;Imagintronix;ID=0003;TEMP=00c8;HUM=05;
20;80;Imagintronix;ID=0003;TEMP=00b8;HUM=05;
20;88;Imagintronix;ID=0003;TEMP=00b8;HUM=05;
20;91;Imagintronix;ID=0003;TEMP=00b8;HUM=05;
20;9C;Imagintronix;ID=0003;TEMP=00b8;HUM=05;
20;BC;Imagintronix;ID=0003;TEMP=0130;HUM=05;
20;C6;Imagintronix;ID=0003;TEMP=0150;HUM=05;
20;CE;Imagintronix;ID=0003;TEMP=0168;HUM=05;
20;D8;Imagintronix;ID=0003;TEMP=0180;HUM=05;
20;E2;Imagintronix;ID=0003;TEMP=0188;HUM=05;
20;F4;Imagintronix;ID=0003;TEMP=01a0;HUM=05;
20;0B;Imagintronix;ID=0003;TEMP=01b8;HUM=05;

Gruß kami

[Wolfgang (Gast)]

Stefan S. schrieb:
> Hier das Ergebnis:

Davon sehe ich in den Daten nichts oder hast du dem Sensor bei -18°C im 
nicht genug Zeit gegeben?

Stefan S. schrieb:
> ... und das Erste Bit gibt an ob Positiv oder negativ

[Peter M. (r2d3)]

Deine Messungen legen nahe, dass die Temperatur in Celsius sich aus der 
Formel

celsius=temp/8 -40

ergibt.

[Peter M. (r2d3)]

Wolfgang schrieb:
> Stefan S. schrieb:
>> Hier das Ergebnis:
>
> Davon sehe ich in den Daten nichts oder hast du dem Sensor bei -18°C im
> nicht genug Zeit gegeben?

Hier stagniert der Wert nach Tiefkühleinlage des Sensors:

20;9C;Imagintronix;ID=0003;TEMP=00b8;HUM=05;

[c-hater (Gast)]

Stefan S. schrieb:

> Ich habe nun auch mal ein paar Messungen gemacht und hier die
> Ergebnisse.

Was da rauskommt, ist ziemlicher Bullshit. Es sind zwar Tendenzen 
erkennbar, die in Teilbereichen halbwegs plausibel sind, aber die Werte 
zeigen, dass da irgendwas grundsätzlich im Argen liegen muss. Denn die 
Kurve insgesamt ist weit weg vom erwartbaren Verlauf für die von dir 
beschriebene Messung.

Vermutlich (höchstwahrscheinlich) ist schon die Spezifikation der 
Struktur der Rohdaten in dem Plugin falsch, dementsprechend liefert das 
Plugin seinerseits dann auch bloss noch Datenmüll.

Dem Problem kommt man also nur auf eine Weise auf die Schliche: 
Denselben Versuch noch einmal, aber nicht den Schwachsinn posten, den 
das Plugin produziert, sondern statt dessen die vollständigen 
Rohdatensätze als Hexdumps.

Sehr wahrscheinlich stecken irgendwo darin noch andere Bits, die zur 
Temperatur gehören.

[c-hater (Gast)]

Peter M. schrieb:
> Deine Messungen legen nahe, dass die Temperatur in Celsius sich aus der
> Formel
>
> celsius=temp/8 -40
>
> ergibt.

Nein, sicher nicht.

Hast du dir mal den Verlauf der Kurve angesehen? Der sollte 
(wenigstens in etwa) einer Exponentialfunktion entsprechen, ist aber 
weit weg davon.

Es gibt nicht nur einen deutlichen Sprung der absoluten Werte, sondern 
auch der Zeitkonstanten der erwartbaren Exponantialfunktion. Sprich: Das 
ist ziemlicher Bitmüll.

[Peter M. (r2d3)]

Stefan S. schrieb:

Wendet man die Formel auf den Ursprungsdatensatz an und sortiert nach 
Sensornummern ergibt sich:

Sensor 1 zeigt Werte von 26-29 Grad.
Sensor 2 zeigt konstante 21 Grad.
Sensor 3 zeigt Werte von 34-36 Grad.

[Peter M. (r2d3)]

c-hater schrieb:

> Hast du dir mal den Verlauf der Kurve angesehen? Der sollte
> (wenigstens in etwa) einer Exponentialfunktion entsprechen, ist aber
> weit weg davon.

Nein. Ich betrachte nur die beiden Fixpunkte.
Ich halte es nicht für sehr sinnvoll, auf irgendwelche Verlaufsdaten 
einzugehen, denn deren Entstehungsgeschichte ist nicht verwertbar.

Man könnte so etwas auswerten, wenn Stefan eine zweispaltige Tabelle 
liefern würde mit Zeitstempel und Temperaturwert.

Was Du analysierst, ist aufgrund der vorliegenden Datenqualität 
Kaffesatzleserei. Ziel war ein Zwei- oder Mehrpunktmessung.

Ich dachte übrigens anfangs auch, man müsse die Nachricht dekodieren, 
aber da die bytebasierten Temperaturdaten in einem Zwei-Byte-Wert 
geshiftet werden, gehen auch keine Daten verloren.

Hier habe ich wohl Unrecht:

Peter M. schrieb:
> Ich kann kaum C, aber hier werden wohl die obersten 4 Bit der Temperatur
> weggeschmissen: temperature=(data[3]) << 4;
>       temperature=temperature/2;

[c-hater (Gast)]

Peter M. schrieb:

> Man könnte so etwas auswerten, wenn Stefan eine zweispaltige Tabelle
> liefern würde mit Zeitstempel und Temperaturwert.

Er hat die Datensätze geliefert und gesagt, das die temporal äquidistant 
gewonnen wurden (nämlich ca. alle drei Minuten). Das genügt.

Jedenfalls wenn man geneigt ist, zumindest grundsätzlich den Angaben der 
TO zu trauen. Wenn man das aber nicht tut, ist deine Analyse mindestens 
genauso Kaffeesatzleserei wie meine...

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan S. schrieb:
> Die Werte bleiben konstant bei 0210 und 0218
>
> Einen Sensor habe ich mal in den Gefrierschrank -18°C gepackt und dann
> rausgenommen und auf Innenraumtemperatur auf heizen lassen. Zeitabstand
> so alle 3 min ein Wert.

 Meiner Meinung nach sind die Sensoren nicht übermässig präzise und
 Plugin ist schlecht, um nicht absoluter Mist zu sagen.
 Es kann aber folgendermassen hinhauen:

 -18C = 0xB8
 25.6C = 0x218

 Dann könnte die angehängte Tabelle in etwa stimmen...

[c-hater (Gast)]

Marc V. schrieb:

>  Dann könnte die angehängte Tabelle in etwa stimmen...

Gewagt, sehr gewagt...

Wenn der TO auch nur näherungsweise die Wahrheit darüber gesagt hat, wie 
er die Messwerte gewonnen hat, dann stimmt deine Tabelle nicht. Sie ist 
dann bestenfalls eine halbwegs brauchbare Interpretation der bei der 
Verwurstung durch das Plugin verbliebenen Bits der tatsächlichen Daten.

Oder anders ausgedrückt: So katastrophal mies ist wohl kein kommerziell 
vertriebener Sensor, nichtmal einer, der nur zur Messung der 
Eigenschaften von Gartenerde gedacht ist...

[Marc V. (Firma: Vescomp) (logarithmus)]

-hater schrieb:
> Wenn der TO auch nur näherungsweise die Wahrheit darüber gesagt hat, wie
> er die Messwerte gewonnen hat, dann stimmt deine Tabelle nicht. Sie ist
> dann bestenfalls eine halbwegs brauchbare Interpretation der bei der
> Verwurstung durch das Plugin verbliebenen Bits der tatsächlichen Daten.

 Stimmt.
 Ich habe ihm schon am 3.5. geschrieben:
Marc V. schrieb:
> Ohne Telegramm wird es aber wahrscheinlich nichts, ausserdem liefert
>  dein Sensor1 Werte die ziemlich stark voneinander abweichen.
Marc V. schrieb:
> Ohne genaue Temperaturmessung ist das alles nur stochern im Nebel.


 Also, Sensor und Thermometer daneben, evtl. mit Haartrockner
 nachhelfen.

[c-hater (Gast)]

Marc V. schrieb:

>  Also, Sensor und Thermometer daneben, evtl. mit Haartrockner
>  nachhelfen.

Und Rohdaten posten. Das scheint mir viel wichtiger zu sein. Dass das 
Plugin Schrott ist, dürfte ja wohl schon so ziemlich feststehen.

Entweder macht es Mist schon bei der Decodierung der Bits (und der TO 
ignoriert das "false" des Funktionsergebnisses) oder die vom Plugin 
angenommene Datenstruktur des Senders ist nicht korrekt.

Viel mehr Möglichkeiten sehe ich hier nicht.

[Stefan S. (kami)]

Hallo zusammen,

also ich habe die Firmware modifiziert und werde sie demnächst 
einspielen.

Bin zur Zeit leider viel unterwegs und schaffe es nicht so schnell wie 
ich gerne würde neue Daten zu liefern.

Aber kommt alles.

Vielen Dank schonmal.

Gruß kami

[Niemand (Gast)]

In

https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/46_TRX_WEATHER.pm

findet man

 ((($bytes->[$off] & 0x80) ? -1 : 1) *
    (($bytes->[$off] & 0x7f)*256 + $bytes->[$off+1]))/10;

Erinnert an DHT11/DHT22. Aber das funktioniert so mit den Daten des TO 
nicht.


Merator: Tags korrigiert

[Stefan S. (kami)]

Hallo zusammen,

ich habe mal das Plugin auf data[3] geswitcht. Hier die ersten Werte von 
2 Sensoren die beide in einem Raum mit 27,9°C liegen:

20;1E;Imagintronix;ID=0002;TEMP=0044;HUM=05;

20;23;Imagintronix;ID=0001;TEMP=0044;HUM=05;

20;2B;Imagintronix;ID=0001;TEMP=0044;HUM=05;

20;3C;Imagintronix;ID=0001;TEMP=0044;HUM=05;

20;40;Imagintronix;ID=0002;TEMP=0045;HUM=05;

20;44;Imagintronix;ID=0001;TEMP=0044;HUM=05;

Ich mache gleich mal einen Abkühlversuch.

Gruß kami

[Christian H. (netzwanze)]

Stefan S. schrieb:
> ich habe mal das Plugin auf data[3] geswitcht.

Bitte keine Prosa, sondern Quellcode.

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan S. schrieb:
> ich habe mal das Plugin auf data[3] geswitcht. Hier die ersten Werte von
> 2 Sensoren die beide in einem Raum mit 27,9°C liegen:

 LOL.
 Wenn die TEMP in HEX ist, dann stimmt meine Tabelle doch.

[Christian H. (netzwanze)]

Ist das Plugin überhaupt für den verwendeten Sensor gedacht?

Nur mal auf die Schnelle "Imagintronix protocol" gegoogelt:

https://www.pitt-pladdy.com/blog/_20131228-233456_0000_Imagintronix_Temperature_Humidity_Sensor_Protocol_WH15B_for_WH1400_/

[Peter M. (r2d3)]

Marc V. schrieb:
> Stefan S. schrieb:
>> ich habe mal das Plugin auf data[3] geswitcht. Hier die ersten Werte von
>> 2 Sensoren die beide in einem Raum mit 27,9°C liegen:
>
>  LOL.
>  Wenn die TEMP in HEX ist, dann stimmt meine Tabelle doch.

Bitte beim nächsten Mal meine primitive Formel richtig abtippen, mein 
Offset beträgt 40 und nicht 41...

:)

[Peter M. (r2d3)]

Christian H. schrieb:
> Ist das Plugin überhaupt für den verwendeten Sensor gedacht?
>
> Nur mal auf die Schnelle "Imagintronix protocol" gegoogelt:
>
> 
https://www.pitt-pladdy.com/blog/_20131228-233456_0000_Imagintronix_Temperature_Humidity_Sensor_Protocol_WH15B_for_WH1400_/

Aus dem Link:

> 2-bits of Channel data. This is the Channel - 1 so Channel 3 devices
> would be encoded as 0x2.
> 12-bits of 2's Compliment Temperature in 1/10'ths of a °C

Das passt nicht zum Text von Stefan:

Stefan S. schrieb:
> * Message Format:
>  * 11111111 01010101 00000101 01000101 11111111 10011110
>  * FF550545FF9E
>  * AABCDDEEFFGG
>  *
>  * A = Preamble, always FF
>  * B = TX type, always 5
>  * C = Address (5/6/7) > low 2 bits = 1/2/3
>  * D = Soil moisture 05%
>  * E = temperature
>  * F = security code, always F
>  * G = Checksum 55+05+45+FF=19E CRC value = 9E

Hier steht nichts davon, wo die fehlenden 4 Bit einer 12-Bit-Zahl 
liegen.
Hier werden nur 8 Bits reserviert (2 Nibble mit Buchstaben EE).

Der Code passt nicht zum Datenformat! Hier ist was falsch.
Meine Formel bzw. die Tabelle von Marc passt am ehesten.
Stefan braucht einen anderen Sensor oder passenden Code.

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter M. schrieb:
> Bitte beim nächsten Mal meine primitive Formel richtig abtippen, mein
> Offset beträgt 40 und nicht 41...

 Du hast immer noch genau nix verstanden.
 Von was fur einem Offset ist die Rede ?
 Wo siehst du bei mir ein Offset ?

 Und von welchen Formeln redest du uberhaupt ?
 Diese hier ?
Peter M. schrieb:
> Der Sprung von F9 und 01 entspräche dann roh 248 Werten, bzw. skaliert
> 24,8 Grad Differenz.

 Oder diese ?
Peter M. schrieb:
> Ich kann kaum C, aber hier werden wohl die obersten 4 Bit der Temperatur
> weggeschmissen: temperature=(data[3]) << 4;
>       temperature=temperature/2;

 Oder diese ?
Peter M. schrieb:
> Deine Messungen legen nahe, dass die Temperatur in Celsius sich aus der
> Formel
>
> celsius=temp/8 -40

 Leider ist deine letzte Formel falsch und kam auch erst als ich
 folgendes gepostet hat:
Marc V. schrieb:
> Das man ein Byte nur selten ohne Überlauf mit 16 multiplizieren kann
>  ist klar, aber warum nicht gleich mit 8 multiplizieren ist mir immer
>  noch nicht klar...

 Also, blamiere dich bitte nicht weiter mit (unwahren) Aussagen und
 falsch abgeschriebenen Formeln ...

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter M. schrieb:
> Hier steht nichts davon, wo die fehlenden 4 Bit einer 12-Bit-Zahl
> liegen.
> Hier werden nur 8 Bits reserviert (2 Nibble mit Buchstaben EE).

 Da die Temperatur in 8-er Sprung angezeigt wird, werden es wohl
 eher 3 bit sein die fehlen und das fehlende 4-te bit ist wohl
 fur +/- gedacht.

Peter M. schrieb:
> Der Code passt nicht zum Datenformat! Hier ist was falsch.

 Ja.

[Peter M. (r2d3)]

Marc V. schrieb:
> Peter M. schrieb:
>> Bitte beim nächsten Mal meine primitive Formel richtig abtippen, mein
>> Offset beträgt 40 und nicht 41...
>
>  Du hast immer noch genau nix verstanden.
>  Von was fur einem Offset ist die Rede ?
>  Wo siehst du bei mir ein Offset ?

Allgemeine Form der Geradengleichung:

y=mx+c

m =Steigung
c =Achsenabschnitt, (Offset!)

Oder auch wie beim Justieren eines Multimeters mit Software:
"scale" und "offset".

Bei mir: m=1/8  c=40
Bei Dir: m=1/8  c=41

Deine Tabelle beschreibt die Punkte einer Geraden, notfalls einfach in 
ein Diagramm zeichnen!.

Man guckt dann welchen Wert die Gerade an der Stelle 0 annimmt, das ist 
der Offset c.

Auf Rechteckpapier gezeichnet mit Maßstab "1 entspricht 1 cm"
sieht man dann "16 Kästchen nach rechts, 2 nach oben"
=> m= 2/16=1/8


>
>  Und von welchen Formeln redest du uberhaupt ?

>> celsius=temp/8 -40

Genau von dieser Formel sprach ich, mein letzter Stand der Erkenntnis, 
nachdem Stefan zwei definierte Messungen durchführte und das Byte-Format 
der Nachrichten lieferte und ich nach Lektüre von anderen Beiträgen 
sehen musste, dass der Aufwärtsshift nicht auf Byte- sondern auf 
Wortbreite durchgeführt wurde.

>
>  Leider ist deine letzte Formel falsch und kam auch erst als ich
>  folgendes gepostet hat:

Ist die Formel falsch, weil mein Achsenabschnitt 40 statt 41 beträgt?
:)

> Marc V. schrieb:
>> Das man ein Byte nur selten ohne Überlauf mit 16 multiplizieren kann
>>  ist klar, aber warum nicht gleich mit 8 multiplizieren ist mir immer
>>  noch nicht klar...

siehe oben.
Aus dem Log geht aber hervor, dass oben beim Shiften nichts herausfällt, 
weil die Zielwerte "temp=" größer als ein Byte sind!

weitere Erklärung:
Der Code macht nur dann ein bisschen Sinn, wenn die Temperatur in den 
unteren 13 Bits eines Words drin steckt. In den oberen 3 Bits steht 
irgendetwas anderes. Viermal aufwärtsschieben schickt diese obere 3 Bits 
ins Nirvana inklusive des Vorzeichenbits der unteren 13 Bits.
Die anschließende Division macht den letzten Shift rückgängig und setzt 
das oberste Bit auf Null.
Das macht nur Sinn, wenn es sich um eine vorzeichenbehaftete Zahl 
handelt und man zusätzlich das Vorzeichen noch irgendwo speichert.
Wenn die Zahl im Zweierkomplement dargestellt ist, kann man so den 
Absolutbetrag der Zahl nicht ermitteln.

Sinnvoll wäre es gewesen mit einer UND-Maske die obersten drei Bits 
auszublenden und dann das Ergebnis als vorzeichenbehaftete Zahl oder als 
Zahl im Zweierkomplement weiter zu bearbeiten.

>
>  Also, blamiere dich bitte nicht weiter mit (unwahren) Aussagen und
>  falsch abgeschriebenen Formeln ...

Ich blamiere mich gerne. Falsch abgeschriebene Formeln?!
Ich habe einfach eine Gerade durch die beiden Messpunkte von Stefan 
gezogen und dann überlegt, ob die damit ausgerechneten Temperaturen der 
anfangs gelieferten Werte von Stefan zu seiner Beschreibung passen.
Das ist das simpelste und naheliegendste, was man meiner Meinung nach 
tun kann. Eine Zweierkomplementdarstellung wäre dann auch schnell 
"aufgeflogen".

[Peter M. (r2d3)]

Marc V. schrieb:
> Da die Temperatur in 8-er Sprung angezeigt wird, werden es wohl
>  eher 3 bit sein die fehlen und das fehlende 4-te bit ist wohl
>  fur +/- gedacht.

Nein, da fehlen keine Bits. Wenn Du eine Zahl mit 8 multiplizierst, 
gehen die niedrigwertigsten Bits nicht verloren.

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter M. schrieb:
> Nein, da fehlen keine Bits. Wenn Du eine Zahl mit 8 multiplizierst,
> gehen die niedrigwertigsten Bits nicht verloren.

 Manoman.
 Nicht einmal, sondern dreimal LOL.
 Immer noch nicht begriffen, von welchen bits ich rede ?

 Aber OK, du hast Recht, Diskussion beendet, in Ordnung ?

[Peter M. (r2d3)]

Marc V. schrieb:

>  Da die Temperatur in 8-er Sprung angezeigt wird, werden es wohl
>  eher 3 bit sein die fehlen

Wenn Du hier die nicht die untersten drei Bits meinst, brauche ich wohl 
für Deine Texte einen Hellseher. :)

Ja welche Bits fehlen denn hier wohl, so daß es nur ganzzahlige 
Vielfache von 8 gibt?!

[Stefan S. (kami)]

Hallo zusammen,

so hier meine nächsten Messergebnisse. Diesmal mit Zeitstempel. Ich habe 
den Sensor in den Tiefkühlschrank (-18°C kann auch kälter sein) 
geschmissen und habe ihn runterkühlen gelassen. Danach habe ich ihn bei 
Zimmertemperatur wieder aufheizen lassen (26-27°C)

07.06.2016 19:57:12 - 20;10;Imagintronix;ID=0003;TEMP=0043;HUM=05;
07.06.2016 19:58:44 - 20;19;Imagintronix;ID=0003;TEMP=0043;HUM=05;
07.06.2016 20:00:15 - 20;21;Imagintronix;ID=0003;TEMP=0043;HUM=05;
07.06.2016 20:03:19 - 20;33;Imagintronix;ID=0003;TEMP=003f;HUM=05;
07.06.2016 20:06:24 - 20;42;Imagintronix;ID=0003;TEMP=0034;HUM=05;
07.06.2016 20:11:03 - 20;5E;Imagintronix;ID=0003;TEMP=002b;HUM=05;
07.06.2016 20:14:10 - 20;6D;Imagintronix;ID=0003;TEMP=0028;HUM=05;
07.06.2016 20:18:51 - 20;89;Imagintronix;ID=0003;TEMP=0023;HUM=05;
07.06.2016 20:21:58 - 20;9A;Imagintronix;ID=0003;TEMP=0020;HUM=05;
07.06.2016 20:23:32 - 20;A2;Imagintronix;ID=0003;TEMP=001f;HUM=05;
07.06.2016 20:25:06 - 20;AB;Imagintronix;ID=0003;TEMP=001e;HUM=05;
07.06.2016 20:26:39 - 20;B1;Imagintronix;ID=0003;TEMP=001d;HUM=05;
07.06.2016 20:29:47 - 20;C2;Imagintronix;ID=0003;TEMP=001b;HUM=05;
07.06.2016 20:31:21 - 20;CC;Imagintronix;ID=0003;TEMP=001b;HUM=05;
07.06.2016 20:32:55 - 20;D4;Imagintronix;ID=0003;TEMP=001a;HUM=05;
07.06.2016 20:34:29 - 20;DE;Imagintronix;ID=0003;TEMP=001a;HUM=05;
07.06.2016 20:36:03 - 20;E9;Imagintronix;ID=0003;TEMP=0019;HUM=05;
07.06.2016 20:37:37 - 20;F4;Imagintronix;ID=0003;TEMP=0019;HUM=05;
07.06.2016 20:39:11 - 20;FC;Imagintronix;ID=0003;TEMP=0019;HUM=05;
07.06.2016 20:45:27 - 20;20;Imagintronix;ID=0003;TEMP=0017;HUM=05;
07.06.2016 20:47:01 - 20;29;Imagintronix;ID=0003;TEMP=0017;HUM=05;
07.06.2016 20:50:09 - 20;3B;Imagintronix;ID=0003;TEMP=0017;HUM=05;
07.06.2016 20:51:43 - 20;44;Imagintronix;ID=0003;TEMP=0017;HUM=05;
07.06.2016 20:54:51 - 20;56;Imagintronix;ID=0003;TEMP=0016;HUM=05;
07.06.2016 20:56:25 - 20;5F;Imagintronix;ID=0003;TEMP=0016;HUM=05;
07.06.2016 21:08:57 - 20;A0;Imagintronix;ID=0003;TEMP=0015;HUM=05;
07.06.2016 21:10:31 - 20;AB;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:16:48 - 20;CB;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:19:56 - 20;DE;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:21:30 - 20;E7;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:23:04 - 20;F0;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:24:38 - 20;FA;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:26:12 - 20;04;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:27:46 - 20;0F;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:30:54 - 20;20;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:41:53 - 20;57;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:43:27 - 20;5F;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:48:09 - 20;7B;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:51:18 - 20;8C;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:52:52 - 20;95;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:54:26 - 20;9F;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:56:00 - 20;A8;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:57:34 - 20;B1;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 21:59:08 - 20;BB;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 22:00:42 - 20;C5;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 22:02:16 - 20;CF;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 22:05:24 - 20;E0;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 22:11:41 - 20;01;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 22:13:15 - 20;09;Imagintronix;ID=0003;TEMP=0014;HUM=05;
07.06.2016 22:16:23 - 20;17;Imagintronix;ID=0003;TEMP=0013;HUM=05;
07.06.2016 22:17:57 - 20;22;Imagintronix;ID=0003;TEMP=0013;HUM=05;
07.06.2016 22:19:31 - 20;2D;Imagintronix;ID=0003;TEMP=0013;HUM=05;
07.06.2016 22:24:13 - 20;46;Imagintronix;ID=0003;TEMP=0026;HUM=05;
07.06.2016 22:25:46 - 20;50;Imagintronix;ID=0003;TEMP=002a;HUM=05;
07.06.2016 22:33:31 - 20;76;Imagintronix;ID=0003;TEMP=0033;HUM=05;
07.06.2016 22:36:37 - 20;8A;Imagintronix;ID=0003;TEMP=0035;HUM=05;
07.06.2016 22:39:42 - 20;9B;Imagintronix;ID=0003;TEMP=0037;HUM=05;
07.06.2016 22:41:15 - 20;A0;Imagintronix;ID=0003;TEMP=0038;HUM=05;
07.06.2016 22:45:52 - 20;BC;Imagintronix;ID=0003;TEMP=0039;HUM=05;
07.06.2016 22:48:57 - 20;CC;Imagintronix;ID=0003;TEMP=003a;HUM=05;
07.06.2016 22:50:29 - 20;D5;Imagintronix;ID=0003;TEMP=003b;HUM=05;
07.06.2016 22:55:06 - 20;ED;Imagintronix;ID=0003;TEMP=003c;HUM=05;
07.06.2016 22:56:38 - 20;F7;Imagintronix;ID=0003;TEMP=003c;HUM=05;
07.06.2016 22:58:11 - 20;00;Imagintronix;ID=0003;TEMP=003c;HUM=05;
07.06.2016 22:59:43 - 20;09;Imagintronix;ID=0003;TEMP=003c;HUM=05;
07.06.2016 23:01:18 - 20;13;Imagintronix;ID=0003;TEMP=003d;HUM=05;
07.06.2016 23:07:24 - 20;33;Imagintronix;ID=0003;TEMP=003e;HUM=05;
07.06.2016 23:08:56 - 20;3C;Imagintronix;ID=0003;TEMP=003e;HUM=05;
07.06.2016 23:12:00 - 20;4E;Imagintronix;ID=0003;TEMP=003f;HUM=05;
07.06.2016 23:16:36 - 20;63;Imagintronix;ID=0003;TEMP=003f;HUM=05;
07.06.2016 23:18:08 - 20;6E;Imagintronix;ID=0003;TEMP=003f;HUM=05;
07.06.2016 23:19:40 - 20;77;Imagintronix;ID=0003;TEMP=003f;HUM=05;
07.06.2016 23:21:12 - 20;7F;Imagintronix;ID=0003;TEMP=0040;HUM=05;
07.06.2016 23:22:44 - 20;88;Imagintronix;ID=0003;TEMP=0040;HUM=05;
07.06.2016 23:24:16 - 20;93;Imagintronix;ID=0003;TEMP=0040;HUM=05;
07.06.2016 23:25:48 - 20;9D;Imagintronix;ID=0003;TEMP=0040;HUM=05;
07.06.2016 23:30:24 - 20;AF;Imagintronix;ID=0003;TEMP=0040;HUM=05;
07.06.2016 23:31:56 - 20;B7;Imagintronix;ID=0003;TEMP=0040;HUM=05;
07.06.2016 23:33:28 - 20;C0;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:35:00 - 20;CA;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:36:32 - 20;D2;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:38:04 - 20;DC;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:39:35 - 20;E5;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:41:07 - 20;EE;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:42:39 - 20;F7;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:44:11 - 20;FF;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:45:43 - 20;06;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:48:47 - 20;17;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:51:51 - 20;28;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:53:23 - 20;32;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:54:54 - 20;3B;Imagintronix;ID=0003;TEMP=0041;HUM=05;
07.06.2016 23:57:58 - 20;4D;Imagintronix;ID=0003;TEMP=0041;HUM=05;
08.06.2016 00:05:38 - 20;78;Imagintronix;ID=0003;TEMP=0042;HUM=05;
08.06.2016 00:07:10 - 20;80;Imagintronix;ID=0003;TEMP=0042;HUM=05;
08.06.2016 00:08:41 - 20;8A;Imagintronix;ID=0003;TEMP=0042;HUM=05;
08.06.2016 00:10:13 - 20;94;Imagintronix;ID=0003;TEMP=0042;HUM=05;
08.06.2016 00:11:45 - 20;9D;Imagintronix;ID=0003;TEMP=0042;HUM=05;
08.06.2016 00:14:49 - 20;AE;Imagintronix;ID=0003;TEMP=0042;HUM=05;

Hier noch die Quellcodeanpassung :

 sprintf(pbuffer, "TEMP=%04x;", data[3]);     
      Serial.print( pbuffer );

Gruß kami

[Frank M. (ukw) (Moderator)]

Stefan S. schrieb:
> so hier meine nächsten Messergebnisse. Diesmal mit Zeitstempel. Ich habe
> den Sensor in den Tiefkühlschrank (-18°C kann auch kälter sein)
> geschmissen und habe ihn runterkühlen gelassen. Danach habe ich ihn bei
> Zimmertemperatur wieder aufheizen lassen (26-27°C)

Wo sind die mit einem Vergleichsthermometer gemessenen Temperaturen? 
Oder sollen wir uns da jetzt Werte ausdenken?

Aber wir haben ja immerhin einen Min- und einen Max-Wert.

0x13 = 19 = -18°C
0x43 = 67 = 27°C

Die Differenz ist: 67 - 19 = 48. Wir messen also 48 Schritte.
Die Temperatur-Differenz ist: 27°C - (-18°C) = 46 Schritte.

Also gehe ich davon aus, dass 1 Schritt = 1 Kelvin.

Wenn Du also schreibst:

  sprintf(pbuffer, "TEMP=%d;", (int) data[3] - 40);     // beachte %d !
  Serial.print( pbuffer );

dann sollte da annähernd die Temperatur rauskommen.

Denn:

  67 - 40 = 27°      <-- 26°-27°
  19 - 40 = -21°C    <-- -18° - kann auch kälter sein


Genaueres kann man nicht sagen, weil die Vergleichsmessung mit einem 
zweiten Thermometer fehlt. Auch Deine Angaben "26-27°C" und "-18°C kann 
auch kälter sein" sind da einfach zu ungenau. Solange Du das so 
schwammig formulierst, bekommst Du auch nur schwammige Ergebnisse bzw. 
Antworten.

Hast Du kein Thermometer zur Vergleichsmessung? Wenn nicht, leih Dir 
eins vom Nachbarn aus.

[Stefan S. (kami)]

Nee gute Sache mache ich nachher nochmal. Sorry habe ich vergessen.

Gruß kami