1-Wire-Slave-Baukasten

[RoBue]

Hi Leute,
wie versprochen stelle ich hier mal einige meiner Entwicklungen zum Nachbasteln und Herumexperimentieren ein.

Etwas heikel ist die Entwicklung von eigenen 1-Wire-Slaves. Maxim scheint nicht besonders erpicht darauf zu sein, aber es fehlen leider zu viele Komponenten für ein umfassendes System. Außerdem werden gute und sinnvolle Bauteile (z.B. DS2423, DS2450) abgekündigt. Deswegen finden sich im Internet einige Ansätze, vorhandene Bausteine durch den Einsatz von Mikrocontrollern nachzubauen oder neue zu entwickeln.

Hier einige gute Beispiele:
-> http://www.mikrocontroller.net/topic/241934#new
-> http://www.mikrocontroller.net/topic/44100 (vor allem DS2423)
-> http://www.mikrocontroller.net/topic/271772 (DCF77)
-> http://www.tm3d.de/index.php/1-wire-device-mit-avr (DS18B20, DS2423, Barometer)
-> http://www.mcselec.com/index.php?option=com_content&task=view&id=256&Itemid=57 (DS2450 mit BASCOM)
-> http://www.brain4home.eu/index.php

Aus diesen Vorlagen entschloss ich mich einen einfachen 1-Wire-Slave-Baukasten zu entwickeln, mit dem man unter BASCOM leicht eigene Slaves erstellen kann. Auf diese Weise kann man evtl. abgekündigte Bausteine im begrenzten Umfang nachbilden, aber vor allem andere Sensoren (z.B. analoge oder I²C) in das 1-Wire-System einbinden. Dies ist  z.B. bei dem weit verbreiteten SHT11 durchaus sinnvoll.

Schwierig ist das jedoch, WIE diese neuen Slaves vom Master angesprochen werden sollen, wenn der Master bzw. dessen Steuersoftware diesen Slavetyp überhaupt nicht kennt!
Es gibt zwei Lösungswege:
- Wenn man die Steuersoftware selbst schreiben kann, ist ein eigener Family-Code am einfachsten. Dann kann man darüber den Slave eindeutig identifizieren und ihn seiner Funktion entsprechend auslesen.
- Wenn man auf eine fertige Steuersoftware zurückgreifen will/muss, bleibt einem nichts anderes übrig, als den Slave so zu programmieren, dass er sich analog zu einem vorhandenen Baustein verhält. Die Gefahr, dass es dabei zu Doppelungen in der 64-Bit-ID kommt, ist dabei sicher gering, aber trotzdem möglich.

Meine Lösung:
- In der Slave-Software ist ein DS18B20 als Standard eingestellt (Data &H28 , &H53 , &H48 , &H54 , &H00 , &H00 , &H00 , &H68).
- Um eine andere ID mit evtl. einem anderen Familiy-Code einzustellen, muss man diese in die ersten 8 Bytes des EEPROMs des ATmega schreiben. Dann wird diese automatisch beim Starten als (neue) ID genutzt.
- Der Slave verhält sich ähnlich wie ein DS18B20, d.h. der Befehl "&H44" (Convert Temperature) berechnet alle Werte, schreibt sie in die ersten 8 Bytes eines Arrays und erstellt  daraus eine CRC-Prüsumme, die in das 9.Byte des Arrays geschrieben wird. Der Befehl "&HBE" (Read Scatchpad) gibt  8 Werte und die CRC-Prüfsumme (=9. Wert) aus.
- Diese 8 Werte selbst sind aber nicht mit denen eines DS18B20 kompatibel,  sondern daraus muss man nun, je nach Funktionen des Slaves, seine Werte gewinnen. Das funktioniert also nur mit  Steuerssoftware, die auch das Scatchpad ausgibt und nicht nur fertige Werte anzeigt. Möglich ist das z.B. mit DigiTemp oder den 1-Wire-Kernel-Modulen des RaspberryPi, leider geht es wohl nicht mit owfs oder IPSymcon.
- Wenn man auf eigene Software zurückgreifen kann, dann kann man für den Slave entweder einen eigenen Family-Code wählen (z.B. &HFE) oder über den Befehl "&H10" und "1wread()" einen Wert auslesen. Ist er <> 255/&HFF, dann ist es kein echter DS18B20. Eine eigene 64-Bit-ID(s.o.) kann man sich z.B. bei -> http://www.tm3d.de/index.php/tools berechnen lassen. Das AVR-PC-Control erkennt  Eigenbau-Slaves mit Familiy-Code &HFE und "falsche" DS18B20 über den Befehl "&H10" und gibt die Messwerte im richtigen Format aus.

(siehe Anhang / see attachement)

Beispiel für einen 1-Wire-Slave mit ATmega8/168 für SHT11 und LCD-Ausgabe (Source- und Hex-Files):
Aufbau der ID: Familycode: &H28 oder &HFE; Byte 2-4: &H53 &H48 &H54 = "SHT"; Byte 5-7: Nummer; Byte 8: CRC8
Scatchpad: Byte 1+2 = Temperatur x 10, Byte 3+4 = Luftfeuchte x 10, Byte 5+6 ADC oder Counter, Byte 7 = z.Z. unbenutzt, Byte 8 = Fehlerstatus (Byte 9 = CRC)

Folgende Ergänzungen und Erweiterungen sind möglich:

- LED an PORTB0 mit Widerstand gegen GND. Sie zeigt an, wenn der Slave gerade angesprochen wird

- Jumper an PORTD4 (Pin 6)gegen GND. Wenn der Jumper gesteckt ist, dann läuft das Modul im Standalone-Betrieb (Ausgabe alle 15s, kein 1-Wire-Zugriff möglich!!!)

- 16Bit-Counter an PORTD5 (Pin 11)

- ADC-Eingang an PORTC0 (Pin 23) füer analoge Sensoren (Luftgüte, Druck, Licht ...)

(siehe Anhang / see attachement)

Viel Spaß,
RoBue

[erwin]

Hi RoBue,

großartige Sache, die du da ins Spiel bringts!
Ich hab deine Beiträge in der Vergangenheit im Bascom Forum verfolgt und daraus jede Menge gelernt.
Mein Vorschlag zu deinen Überlegungen:

- Der Slave verhält sich ähnlich wie ein DS18B20, d.h. der Befehl "&H44" (Convert Temperature) berechnet alle Werte, schreibt sie in die ersten 8 Bytes eines Arrays und erstellt daraus eine CRC-Prüsumme, die in das 9.Byte des Arrays geschrieben wird. Der Befehl "&HBE" (Read Scatchpad) gibt 8 Werte und die CRC-Prüfsumme (=9. Wert) aus.

...damit die Sache OWFS..usw. "kompatibel" wird:
Wie wär's, entweder ein RAM / ROM (DS192x) zu emulieren, wo OWFS sowohl scratchpad, ... schreiben als auch lesen kann -
Alternativ auch ein DS2450, DS2438 - wenn es was zu "triggern" gibt.....
Was man sich "ersparen" würde, wäre die physische Schittstelle/das Transportprotokoll usw. neu zu erfinden.
Die Interpretation der "Werte" bleibt dann natürlich nach wie vor der Software, die auswertet....das ist in FHEM jedoch retaliv einfach zu implementieren (siehe OWDevice).

Was hälts du davon ?
l.g. erwin

[RoBue]

Hallo erwin,

da bin ich dabei, aber das macht auch eine ganze Menge Arbeit.
DS2450-Anpassung habe ich schon angefangen, aber da sind die ständigen CRCs,
die mich einfach nerven. Darum habe ich mich vorerst für die einfachere Version entschieden.

Die ROMs/RAMs wären fast noch besser,
aber da habe ich gar keine Erfahrung.

Auf jeden Fall habe ich noch ein paar Bilder und die Programme für eine ATtiny45-Version, aber leider noch in der DS18B20-Variante.

(siehe Anhang / see attachement)

(siehe Anhang / see attachement)

Liebe Grüße,
RoBue

[RoBue]

Hi Leute,

hier nun ein Beispiel,
wie man die (neuen) 1-Wire-Slaves am RaspberyPi
mit bash-Scripten und mit Hilfe der 1-Wire-Kernel-Module
ansprechen und auslesen kann:

Installation der Module:

Code: [Auswählen]


modprobe wire
modprobe w1-gpio
modprobe w1-therm


Der Slave wird als DS18B20 erkannt und ein Verzeichnis mit seiner ID unter

     /sys/bus/w1/devices

angelegt.

Nun die Abfrage und Ausgabe (nur 1 Slave angeschlossen !!!):

Code: [Auswählen]


#!/bin/bash

# ID des 1. Sensors auslesen
sensor=`cat /sys/devices/w1_bus_master1/w1_master_slaves | head -1`

while true
do
    clear

    echo -n "Sensor auslesen ..."

    # Scratchpad auslesen
    scratchpad=`cat /sys/bus/w1/devices/$sensor/w1_slave | grep "t=" | tr a-f A-F`

    echo " fertig!"
    echo

    # einzelne Werte isolieren
    temp_low=`echo $scratchpad | cut -d" " -f1`
    temp_high=`echo $scratchpad | cut -d" " -f2`
    hum_low=`echo $scratchpad | cut -d" " -f3`
    hum_high=`echo $scratchpad | cut -d" " -f4`
    wert_low=`echo $scratchpad | cut -d" " -f5`
    wert_high=`echo $scratchpad | cut -d" " -f6`
    error=`echo $scratchpad | cut -d" " -f8`

    # Temperatur berechnen (mit bc)
    temperatur=`echo "ibase=16; ($temp_high * 100) + $temp_low" | bc`
    temperatur=`echo "scale=1; $temperatur / 10" | bc`

    # Luftfeuchte berechnen
    luftfeuchte=`echo "ibase=16; ($hum_high * 100) + $hum_low" | bc`
    luftfeuchte=`echo "scale=1; $luftfeuchte / 10" | bc`

    # 3. Wert (Counter, ADC, ...)
    wert=`echo "ibase=16; ($wert_high * 100) + $wert_low" | bc`

    # Ausgabe
    datum=`date +"%H:%M %d.%m.%Y"`
    echo "Datum      : $datum"
    echo "Sensor-ID  : $sensor"
    echo "Scratchpad : $scratchpad"
    echo "Temperatur : $temperatur °C"
    echo "Luftfeuchte: $luftfeuchte %H"
    echo "3. Wert    : $wert"
    echo "Errorstatus: $error"

    sleep 15

done


Auf dem Bildschirm müsste dann Folgendes zu lesen sein:

Code: [Auswählen]


Sensor auslesen ... fertig!

Datum      : 12:31 16.04.2013
Sensor-ID  : 28-030000544853
Scratchpad : FE 00 99 01 00 00 00 00 74 t=15875
Temperatur : 25.4 °C
Luftfeuchte: 40.9 %H
3. Wert    : 0
Errorstatus: 00


Alles klar?

Falls Fragen sind, bitte melden!

Viel Spaß und liebe Grüße,
RoBue

PS:
Hätte jemand Lust mit mir die Kernel-Module um weitere Sensortypen zu erweitern?
Er oder sie müsste sich in C gut auskennen, da da meine Schwächen liegen.
Aber gemeinsam würden wir das sicher in 1 Tag schaffen, z.B. den DS2450 und den DS2413 auch noch zu integrieren.

PS2:
Welche digitalen (evtl. auch analoge) Sensoren sollte man noch in 1-Wire integrieren?
Macht mal Vorschläge (ich schlag dann zurück!)
Anstelle von SHT-Sensoren, kann man übrigens auch HYT-Sensoren nehmen.

[RoBue]

Hi Leute (und erfahrene FHEM-User),

ich möchte in den nächsten Tagen FHEM installieren
und damit auch meine Slaves testen
und evtl. die Module von FHEM daran anpassen.

Darum 2 Fragen, damit ich nicht gleich am Anfang auf dem Schlauch stehe:

Frage 1:

Wenn ich 1-Wire über eine serielle Schnittstelle betreibe
(mit den entsprechenden Adaptern natürlich),
reicht es wenn ich z.B. Folgendes eingebe:

Code: [Auswählen]


define 1-Wire OWX /dev/ttyUSB0


Muss ich dann noch die anderen Module vom Typ 21_OWxxx irgendwie anmelden oder einbinden?
Muss ich noch weitere Änderungen irgendwo vornehmen?

2. Frage:

Wenn ich am RPi die 1-Wire-Kernel-Module nutze,
ist dann der Eintrag:

Code: [Auswählen]


define 1-Wire GPIO4 BUSMASTER


(vgl. http://forum.fhem.de/index.php?t=msg&goto=67059&rid=0)?

Muss ich da weitere Kernel-Module o.ä. aktivieren?

Danke schon im Voraus,
RoBue

[RoBue]

Hi Leute,

ich führe in diesem Thread wohl nur noch Selbstgespräche.

Habe mir das doch etwas anders vorgestellt.

Anscheinend besteht nicht so sehr viel Interesse. Schade.

Aber ich habe mich doch nochmal aufgerafft, etwas zu schreiben:
Ich habe das 58_GPI04-Modul für den RPi (Dank an Peter Flathmann!) soweit modifiziert,
dass es meine 1-Wire-Clones erkennen und ausgeben kann.
Sie haben die einheitliche ID: 0x28 0x53 0x48 0x54 xx xx xx

Hier die Ausgabe des "Clones":

(siehe Anhang / see attachement)

Und hier die Ausgabe eines "normalen" DS1820:

(siehe Anhang / see attachement)

Besteht Interesse am Code?

Kann mir dann jemand einen Tipp geben,
wie man aus den Werten eine Grafik zaubern kann?

Liebe Grüße,
RoBue

[Tobias]

HI Robue,
damit es nicht ganz zum Selbstgespräch wird ;)
Auf jeden Fall interessant. Aber für mehr als die DS2423 Emulation wie sie auch im Thread von dougie durchgenommen wird, wird wohl kein großes Interesse da sein. Dafür ist die Inbetriebnahme der originalen Dallas 1wire Bausteinen zu einfach und der Aufwand mit der Emulation zu hoch.
Besonders die Kluft bei der Temperaturmessung wie hier im Thread ist besonders hoch. Da ist ein DS18B20 einfacher anzuschließen. Und falls mit Luftfeuchte, ist der DS2438 und ein Honeywell HIH5040 ebenfalls einfacher.....
Ich weiß auch das die Emulation mit dem DS18B20 nur ein TEst ist und ein wirklicher BusinessCase wird erst mit  der Emulation des DS2423 und des 2450 erreicht

[dougie]

...mal ne andere Frage: ist der SourceCode oder sind die Kommandos eigentlich bekannt/public domain, die Lewis Slevin für das 1W LCD verwendet hat?

Würde mir gefallen, wenn es da auch was open-source mässiges gäbe, oder nachgebaut werden könnte.

VG
Ralf

[RoBue]

Hallo dougie,

meinst Du diese?

-> http://www.louisswart.co.za/1-Wire_Online_Order.html

Mit meinem "Baukasten" eigentlich kein Problem.
LCD-Rotinen sind schon drin,
werden aber z.Z. nicht über 1-Wire genutzt,
sondern nur intern die Messwerte ausgegeben,
wenn der Befehl "Convert" gesendet wird.

Die Frage ist nur, WIE die LCD angesprochen werden soll,
also was sie alles können soll
und wie sie Befehle aussehen sollen.
ich versuche mal in den nächsten Tagen ein Beispiel.

Wer schreibt dann die Routinen zur Einbindung in FHEM?

Gruß RoBue

[RoBue]

Hallo Tobias,

letztlich hat auch eine DS2450-Emulation ihre Schwächen,
z.B. die Rechenzeit und Messzeit für die Sensoren,
die evtl. länger ist als die der AD-Wandler des DS2450.
Außerdem fehlen diese Bausteine bei den GPIO-Kernel-Modulen des RPi und in DigiTemp.

Letztlich muss man wohl mehrere Versionen anbieten.
Am liebsten wäre mir doch eine eigener Family-Code.

Der Vorteil meiner Lösung besteht darin,
dass auch dig. Sensoren eingebunden werden können
und damit das lästige Kalibrieren der analogen Sensoren entfällt.

Liebe Grüße,
RoBue

[ritchie]

Hallo Zusammen,

hat sich jemand mal Gedanken dazu gemacht, ob man einen Atmel auch als aktiven 1-wire HUB verwenden kann.

Gruss R.