Die DS18B20 können über einen Index (0 .. n) angesprochen, wobei die 0 dem Sensor mit der niedrigsten Adresse entspricht. Wenn ich das richtig sehe erledigt diese Zuordnung die Dallas Bibliothek. Im Scratchpad gibt es 3 Bytes, die beschreibbar sind.
Nun meine Frage: können diese Scratchpadbytes über den Index angesprochen werden oder nur über die Adresse des Sensors?
Mein Gedanke ist, wenn diese Bytes nicht benötigt werden, könnte man dort die Messpunkte zuordnen (MP1 ... n). Beim Austausch würde wieder der MP in das Scratchpad des neuen Sensors geschrieben werden und damit entfällt das "Gesuche" nach der Reihenfolge der Adressen.
Oder gibt es eine andere Variante???
Hoffe hatten alle einen fleißigen Osterhasen
und Dank für die Tipps.
Die DS18B20 können über einen Index (0 .. n) angesprochen, wobei die 0
dem Sensor mit der niedrigsten Adresse entspricht.
Also diese Sensoren werden über eine Adresse angesprochen. Über sonst gar nichts.
Wenn ich das richtig
sehe erledigt diese Zuordnung die Dallas Bibliothek.
Das ist möglich. Dann hängt alles weitere was du tun kannst oder nicht tun kannst, von dieser Lib und ihrer API ab. Schaue dort bitte nach.
Im Scratchpad gibt
es 3 Bytes, die beschreibbar sind.
Das sind Userdaten die im EEPROM gespeichert werden können.
Nun meine Frage: können diese Scratchpadbytes über den Index
angesprochen werden oder nur über die Adresse des Sensors?
Hängt von der lib ab.
Mein Gedanke ist, wenn diese Bytes nicht benötigt werden, könnte man
dort die Messpunkte zuordnen (MP1 ... n). Beim Austausch würde wieder
der MP in das Scratchpad des neuen Sensors geschrieben werden und damit
entfällt das "Gesuche" nach der Reihenfolge der Adressen.
Oder gibt es eine andere Variante???
Die Userdaten können natürlich für eine Zuordnung verwendet werden. Du kannst einen SCAN durchführen und für alle gefundenen Adressen die Userdaten lesen.
Was sollte dich davon abhalten. DU entwickelst doch die Software.
Wenn ich das richtig
sehe erledigt diese Zuordnung die Dallas Bibliothek.
Hängt von der geheimen Dallas Bibliothek ab, welche Du nimmst.
Es gibt 2 Bytes im EEPROM, die man benutzen kann. Z.B. kann man über die Suchfunktion jedem Sensor einen Index zuweisen und dort abspeichern. Diesen Index kann man dann von einem adressierten Sensor wieder auslesen.
Man kann einen Sensor über seine Adresse, die Suchfunktion oder alle gleichzeitig ansprechen.
Was für ein Käse. Da haben diese ICs schon eine WLTWEIT einmalige 48 Bit
ID, und dann wollen Leute da immer noch was eigenes dazu stricken.
Haha genau, jetzt haben alle Netzwerkgeräte schon eine weltweit einmalige MAC Adresse aber ein paar blöde Leute haben trotzdem die IP-Adresse erfunden.
Eine ID im EEPROM zu vergeben, ist schon recht geschickt. Dann kann man einen defekten Sensor wechseln und ihm die selbe ID verpassen.
Und die Software weiß, ob der Sensor registriert wurde oder neu ist.
Eine ID im EEPROM zu vergeben, ist schon recht geschickt. Dann kann man
einen defekten Sensor wechseln und ihm die selbe ID verpassen.
Und die Software weiß, ob der Sensor registriert wurde oder neu ist.
Manchen talentlosen fällt es schwer, die Unterschiede von physikalischen und logischen Adressen zu verstehen und deren Vor- und Nachteile.
genau das war meine Idee und für 2 Sensoren sind das nur ein paar zeilen code. So kann einen Sensorwechsel meine Frau selbst durchführen, da die Software die Zuordnung der Sensoren selber macht.
Gruss M.
p.s. gibt halt immer Leute, die meinen alles zu verstehen und sinnfreie Beiträge in den Foren schreiben. Und wer nur mit einem Sensot umgeht, hat auch keine Probleme.
p.s. gibt halt immer Leute, die meinen alles zu verstehen und sinnfreie
Beiträge in den Foren schreiben. Und wer nur mit einem Sensot umgeht,
hat auch keine Probleme.
Und das traurige ist, dass die gleichen Leute in ihrem Browser eine URL mit symbolischem Namen verwenden – denn die eindeutige IP-Adresse einer Website lässt sich ja gut merken und ändert sich auch nie … oder auch nicht.
p.s. gibt halt immer Leute, die meinen alles zu verstehen und sinnfreie
Beiträge in den Foren schreiben. Und wer nur mit einem Sensot umgeht,
hat auch keine Probleme.
Und das traurige ist, dass die gleichen Leute in ihrem Browser eine URL
mit symbolischem Namen verwenden – denn die eindeutige IP-Adresse einer
Website lässt sich ja gut merken und ändert sich auch nie … oder auch
nicht.
Du sprichst mir aus dem Herzen, Ralf.
Habe heute festgestellt, dass die Library die UD-Abfrage eines nicht existierenden Sensors nicht abfängt. Ergebnis ist 0, wenn kein Sensor angeschlossen, ist ein Sensor angeschlossen wird die UD dieses Sensors für den nicht vorhanden ausgegeben. Bei mehreren, scheint es die letzte zu sein. Da kann ich mich aber auch irren, habe es nicht mehr notiert. Das erste Faktum genügt mir.
Gruss
Habe heute festgestellt, dass die Library die UD-Abfrage eines nicht
existierenden Sensors nicht abfängt.
Wie wärs, endlich mal den Quelltext der konkreten Lib zu verlinken!
Ich weiß nur, was meine Lib macht.
Auf die Addressierung eines Slaves gibt es kein ACK. Ein nicht
addressierter Slave liefert immer 0xFF.
sry habe imo schlechtes inet im erzgebirge.
bibliothek ist von miles burton (dallas temperature).
in cpp ab zeile 787
// note If address cannot be found no error will be reported.
int16_t DallasTemperature::getUserDataByIndex(uint8_t deviceIndex) {
DeviceAddress deviceAddress;
getAddress(deviceAddress, deviceIndex);
return getUserData((uint8_t*) deviceAddress);
vllt. verstehe ich das aber auch nicht. Gibt es eine Bibliothek, die das Ansprechen eines nicht existierenden sensors mit einem Fehlercode abfängt. Falls ja, bin ich für einen Link dankbar.
oder man sucht in den Libs crc8 crc16 ist öfter zu finden.
danke Dir, habe nun die cpp abgewandelt.
getAddress(deviceAddress, deviceIndex); gibt Flag zurück. mit if else wird entweder index oder 0xFF (else) zurückgegeben, damit ist alles erledigt.
