DS18B20 auf HM-CC-RT-DN abbilden (Wer hat HM-Temp-Fühler mit RT in Betrieb?)

[martinp876]

schwer zu sagen... mit dem VD klappt es auch noch nicht reibungslos...

[Thorsten Pferdekaemper]

Sag Bescheid, wenn Du noch mehr Daten brauchst. Ich kann auch mal versuchen, das Teil zu quälen, wenn das was bringen sollte (Sensor in den Kühlschrank oder Backofen oder zu weit weg oder...)

[martinp876]

Hi Thorsten,

Aktuell ist es sehr einfach: Es gibt eine Formel von homegear, die zu einem Timing des VD passen soll. Wie die Jungs darauf gekommen sind ist unklar - sie könnten es etwas einfacher machen, was darauf hindeuted, dass es nicht aus dem sourcecode von HM ist.
Diese Formel passt nicht zum Timing des Temp-Fühlers.
Die Formel ist relativ komplex, daher kann ich sie nicht anpassen.
Ein Test mit dem RT steht noch aus...

Gruss Martin

[Thorsten Pferdekaemper]

Die Formel ist relativ komplex, daher kann ich sie nicht anpassen.

Liegt's an fehlenden mathematischen Fähigkeiten oder an was anderem? Schick die Formel mal rüber, vielleicht kann ich da helfen.

[martinp876]

Die Formel ist:
#    int32_t result = (((_address << | messageCounter) * 1103515245 + 12345) >> 16;
#   return (result & 0xFF) + 480;

Das Resultat sind die Anzahl der 250ms steps

zu beachten: es ist c-code, 32bit integer. Runden beachten. Perl schaltet gerne nach float, was die Berechnung unbrauchbar macht.
vom Ergebnis sind schlussendlich nur bit 16 bis 23 relevant. Damit kann man erst einmal
_address &= 0xffff
rechnen
Der Wert 12996205 = C64E6D ist auch uebertrieben und kann auf 24bit gestutzt werden, ohne das Ergebnis zu aendern. Also statt 1103515245 = 0x41c64e6d kann mit 12996205 = C64E6D gerechnet werden.

Das Prinzip waere, dass dem Empfaender das naechste aufwachen mitgeilt wird mittels messageNo und Sender-addresse (HMId). Der Empfaender sollte dann zu diesem Zeitpunkt aufwachen - leider kann man dies nicht sehen - man koennte es nur in Empfaenger messen.

Rechne ich dies noch fuer eine TC/VD beziehung stimmt es. Rechne ich es fuer eine TH/RT beziehung (sample von oben) stimmen die Werte nicht.

[Thorsten Pferdekaemper]

Hi,
ich glaube, mir fehlen da ein paar Grundlagen...
Erst einmal: Das  ist wahrscheinlich ein "8 )"
Ansonsten: Für was stehen die Variablen und wo findet man die Werte?
_address ist die ID des Device? Also 1F4CB9 bzw. 21FBB2 ?
Wo finde ich den messageCounter?
Gruß,
  Thorsten

[martinp876]

Hi Thorsten

der message-counter ist das byte vor der sende-ID
Die Adresse ist die sende-ID

und ja, shift-left acht

Gruss Martin

[Thorsten Pferdekaemper]

Hi,
ok, in diesem Beispiel:

Code Auswählen Erweitern

2014.01.05 12:42:30.163 0: HMLAN_Parse: HMLAN1 R:E1F4CB9   stat:0000 t:5080E694 d:FF r:FFCD     m:C4 8670 1F4CB9 000000 00D431
...ist der message-Counter "C4" und die sende-ID ist "8670" richtig?
Gruß,
    Thorsten

[CQuadrat]

Das würde mich auch mal etwas näher interessieren.
Ist irgendwo die Bedeutung der ganzen Logparameter dokumentiert?

[martinp876]

2014.01.05 12:42:30.163 0: HMLAN_Parse: HMLAN1 R:E1F4CB9   stat:0000 t:5080E694 d:FF r:FFCD     m:C4 8670 1F4CB9 000000 00D431

2014.01.05 12:42:30.163 log zeitstempel
0: verbose level des logs
HMLAN_Parse: vergebener Name - meist ds Modul indetifizierend
# von hier Parameter wie es der Entwickler einstellt
HMLAN1 R:E1F4CB9   stat:0000 t:5080E694 d:FF r:FFCD     m:C4 8670 1F4CB9 000000 00D431

HMLAN1 name des IO device
R:E1F4CB9   kann ich nicht deuten
stat:0000  status info. Eintrag von HMLAN addiert für HMLAN<-> zentrale protokol. u.a. zur Fehler-erkennung
t:5080E694  zeitstempel des HMLAN
d:FF AES key zuordnung (ff: kein AES)
r:FFCD     RSSI am HMLAN
m:C4 8670 1F4CB9 000000 00D431 message

C4 sequenz nummer (zur msg zuordnung)
86 message-flags (broadcast/needack/burst,...)
70 msgTyp
1F4CB9 msg src ID
000000 msg destination id (000000 bei broadcast)
00D431 message-typ spezifische daten/nettoinfo

[CQuadrat]

Vielen Dank !!

[Thorsten Pferdekaemper]

Hi,
ich würde nochmal gerne auf die Sache mit der Formel zurückkommen. Soweit ich verstanden habe, ist das der Knackpunkt um nicht-HM Geräte als Temperatursensor einzubinden.

#    int32_t result = (((_address << 8 ) | messageCounter) * 1103515245 + 12345) >> 16;
#   return (result & 0xFF) + 480;

Ich habe immer noch nicht kapiert, was man als _address bzw. messageCounter einsetzen muss. Du schreibst:

der message-counter ist das byte vor der sende-ID
Die Adresse ist die sende-ID

Tja, aber welches ist die sende-ID?
Könntest Du mal an dem Beispiel hier sagen, was _address ist und was messageCounter?

Code Auswählen Erweitern

2014.01.05 12:42:30.163 0: HMLAN_Parse: HMLAN1 R:E1F4CB9   stat:0000 t:5080E694 d:FF r:FFCD     m:C4 8670 1F4CB9 000000 00D431

Gruß,
   Thorsten

[martinp876]

Tja, aber welches ist die sende-ID?

sorry, dachte es ist klar. src = source = quelle = sender

1F4CB9 msg src ID

[jab]

Abend,

ich habe mir das Problem mal näher angesehen. Mit etwas Statistik und ein paar mehr Daten bin ich da auch schon etwas weiter gekommen. Es sieht aus als wenn es eine Serie von 71 Schritten gibt die immer gleich sind im Timing. Grob sieht das Timing wie im Anhang aus. Eine Sequenz dauert ca 3,5 Std. Die Zeilen sind immer die Abstände zwischen zwei Nachrichten. Wo der Beginn der Sequenz ist müsste man dann mal rausfinden indem man einen Sensor neu peert und das dann mitschneidet.

Leider hatte ich nur Daten mit Genauigkeit von 1s. Ich schreibe aktuell mal die Raw Messages mit und werte das dann in ein paar Tagen aus damit das genauer wird.
Sequenz.txt = 2 Sequenzen die recht gut matchen
Sequenz_Full.txt = Die Sequenzen über 2 Tage. Da gibt es ein paar kurze Lücken. Die kommen von der Zeit wenn mein HMUSB neustartet. An sich sieht das aber durchgehend einheitlich aus.

Die Frage ist jetzt ob die Sequenz von der HMID abhängt oder bei allen Geräten gleich ist. Nur ein Gedanke. Ich habe leider keinen zweiten Tempsensor.


Gruß,
Jan

[jab]

So ich habe das mal weiter angeschaut. Es scheint genau die Formel zu sein:

Code Auswählen Erweitern


function length($addr, $cnt)
{
        $min = 480;
        $res = ((($addr<<8)|$cnt) * 1103515245 + 12345) >> 16;
        return (($res & 0xFF) + $min)/4;
}

$addr = 0x1F4C66;

for ($cnt = 0x0; $cnt < 0x68; $cnt++) {
        echo length($addr, $cnt). "\n";
}

Das erzeugt genau das gleiche Timing wie ich in der Sequenz sehe. Vermutlich ist die Länge Zufall.

Anhängend:
real.txt - Die gemessenen Timings
predict.txt - Das Timing nach Formel

Abweichung über 104 Messwerte: 1s. Ich denke das sollte ok sein.


Gruß,
Jan