DS18B20 & RPi - keine Sensoren in /sys/bus/w1/devices trotz kommunikation

[Elektrofreak]

Hallo,

ich lese schon seid längerem mich in das Thema FHEM ein und habe nun entschieden, erstmal mit DS18B20 Temperatursensoren einzusteigen, um die Möglichkeiten und Konfigurationen kennen zu lernen.

Ich habe bei eBay ein 10er-Pack an wasserdichten Sensoren gekauft. Ein Sensor ist mit einem 4,7kOhm Pullup-Widerstand zwischen Pin 1 und Pin 7 am Raspberry Pi Model B (1. Rev.) mit den Pins VDD = Pin1 (3,3V), GND = Pin6 und Data = Pin 7 angeschlossen.

Von der Software-Seite her habe ich die Einstellungen aus dem Wiki:

http://www.fhemwiki.de/wiki/Raspberry_Pi_und_1-Wire

übernommen (mit und ohne device-tree, mit identischem Ergebnis; aktuell ohne modprobe und mit device-tree).

Glücklicherweise habe ich einen Logik-Analyzer, sodass ich das Signal auf der Datenleitung messen kann. Ich sehe, dass alle 10 Sekunden für ca. 1 Sekunde Daten transferiert werden. Dabei werden jeweils 65 "Bursts" bzw Datenpakete übertragen, wobei viele laut GUI meines Analyzers ein Reset oder Search-Commands sind. Bit für Bit habe ich die Daten noch nicht analysiert.

Komischerweise wird jedoch im /sys/bus/w1/devices -Verzeichnis kein Gerät (außer dem w1_bus_master1) angelegt. Wenn ich die Buchsenleiste vom RPi nehme kann es vorkommen, dass manchmal ein Gerät mit der ID 00-20000000.... oder ähnlich erzeugt wird. Ich vermute, dass es entweder ein Software-Problem ist oder dass die Temperatursensoren von einer chinesischen Firma stammen und die ID nicht zugeordnet werden kann.

Der Befehl "sudo vcdbg log msg" gibt folgende Ergebnisse :

Code Auswählen Erweitern


...
000931.568: *** Restart logging
000932.970: Read command line from file 'cmdline.txt'
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
000933.175: clock: clock_set_clock:  dst: CLK_UART, source: PLLD_PER, div: 166.666700
000933.820: Loading 'kernel.img' from SD card
001167.683: Kernel trailer DTOK property says yes
001167.796: Loading 'bcm2708-rpi-b.dtb' from SD card
001201.706: dtparam: uart0_clkrate=3000000
001209.036: dtparam: audio=on
001224.305: Loaded overlay 'w1-gpio-pullup'
001262.444: dtparam: cache_line_size=32
001271.968: clock: Set PLLB_VCO to 800000000
001272.080: clock: clock_set_clock:  dst: CLK_ARM, source: PLLB_ARM, div: 1.000000
001272.159: clock: clock_set_clock:  dst: CLK_VPU, source: PLLC_CORE0, div: 4.000000
001272.219: clock: clock_set_clock:  dst: CLK_EMMC, source: PLLC_PER, div: 4.000000
001272.291: clock: Set PLLA_VCO to 2000000000
001272.397: clock: clock_set_clock:  dst: CLK_V3D, source: PLLA_CORE, div: 4.000000
001272.459: clock: clock_set_clock:  dst: CLK_H264, source: PLLA_CORE, div: 4.000000
001272.522: clock: clock_set_clock:  dst: CLK_ISP, source: PLLA_CORE, div: 4.000000
001273.370: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
001273.463: clock: Set PLLB_VCO to 640000000
001273.537: clock: clock_set_clock:  dst: CLK_ARM, source: PLLB_ARM, div: 1.000000
001273.567: clock: Set PLLB_VCO to 800000000
001273.638: clock: clock_set_clock:  dst: CLK_ARM, source: PLLB_ARM, div: 1.000000
001273.675: clock: clock_set_clock:  dst: CLK_ARM, source: XOSC, div: 1.000000
001273.709: clock: clock_set_clock:  dst: CLK_ARM, source: XOSC, div: 0.000000
001273.733: clock: Set PLLB_VCO to 800000000
001273.844: clock: clock_set_clock:  dst: CLK_ARM, source: PLLB_ARM, div: 1.000000
006686.074: vchiq_core: vchiq_init_state: slot_zero = 0x4d880000, is_master = 1
006689.706: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
006693.692: gpioman: gpioman_get_pin_num: pin LEDS_RUNNING not defined
006693.717: gpioman: gpioman_get_pin_num: pin LEDS_NAND_ACTIVITY not defined
006693.738: gpioman: gpioman_get_pin_num: pin LEDS_USB_ACTIVITY not defined
006693.758: gpioman: gpioman_get_pin_num: pin LEDS_FATAL_ERROR not defined
006693.780: gpioman: gpioman_get_pin_num: pin LEDS_APP_OK not defined
006693.804: gpioman: gpioman_get_pin_num: pin LEDS_APP_FAILED not defined
006693.824: gpioman: gpioman_get_pin_num: pin LEDS_HDCP_AUTH not defined
006693.847: gpioman: gpioman_get_pin_num: pin LEDS_HDCP_UNAUTH not defined
006693.869: gpioman: gpioman_get_pin_num: pin LEDS_HDMI_ON not defined
006693.891: gpioman: gpioman_get_pin_num: pin LEDS_DVI_ON not defined
006693.913: gpioman: gpioman_get_pin_num: pin LEDS_HDMI_HPD_UP not defined
006693.935: gpioman: gpioman_get_pin_num: pin LEDS_REMOTE_CONTROL not defined
006693.957: gpioman: gpioman_get_pin_num: pin LEDS_ARM_CONTROLLED not defined


Welche Tips könnt Ihr mir geben? Was kann ich probieren?

Vielen Dank für eure Hilfe!

[Wzut]

mal ganz ohne den externen Widerstand probiert ?
Ich hatte bisher noch keine OW Sensoren am Rpi mit dem neuen Kernel, daher ist für mich im Wiki der folgenden Abschnitt auch neu :

# activating 1-wire with pullup
dtoverlay=w1-gpio-pullup

liest sich aber als wenn da ab jetzt der interne Pullup auf der Datenleitung benutzt wird.

[Prof. Dr. Peter Henning]

Ich habe mit den chinesischen Sensoren keinerlei negative Erfahrungen gemacht.

Tipp: ordentlichen Busmaster verwenden.

LG

pah

[Elektrofreak]

Das mit dem Busmaster habe ich auch schon gelesen. Ich habe gedacht, dass der Raspberry Pi die Aufgabe des Busmasters übernimmt, da ich keinerlei weitere Informationen bzgl. des Busmasters auf der entsprechenden Wiki-Seite gelesen habe. In FHEM ist er jedenfalls als

Code Auswählen Erweitern

define RPi GPIO4 BUSMASTER
definiert. Im Webinterface bekomme ich folgende Informationen:

Code Auswählen Erweitern


Internals
DEF BUSMASTER
NAME RPi
NR 73
NTFY_ORDER 50-RPi
SLAVES not found.
STATE Initialized
TYPE GPIO4
Readings
failures 8 2016-02-15 21:02:56


Den Widerstand habe ich testweise mal entfernt. Es scheint trotzdem (zumindest mit angehängtem Logik-Analyzer) Kommunikation stattzufinden. Keine Ahnung, ob der RPi dann einen internen Pullup aktiviert oder ob es nur eine entsprechende Konfigurationsanweisung ist, die die externe Beschaltung mitteilt. Der Sensor wird aber trotzdem nicht erkannt...

[Wzut]

dass der Raspberry Pi die Aufgabe des Busmasters übernimmt, da ich keinerlei weitere Informationen bzgl. des Busmasters auf der entsprechenden Wiki-Seite gelesen

Was pah meint ist ein "echter" Busmaster, wenn du hier im 1Wire Forum etwas stöberst wirst du genug Hinweise auf die Dinger finden
( lies mal http://www.fhemwiki.de/wiki/USB-Interface_f%C3%BCr_1-Wire und auch http://www.fhemwiki.de/wiki/Kategorie:1-Wire)
Ich selbst habe mit der Rpi GPIO Lösung keine guten Erfahrungen auf Dauer gemacht und würde dir auch raten (gerade bei mehr als einem Sensor ) noch ein paar Euro mehr zu investieren. Deine gesparte Zeit und geschonten Nerven werden es dir danken
 

[crusader]

mal ganz ohne den externen Widerstand probiert ?
Ich hatte bisher noch keine OW Sensoren am Rpi mit dem neuen Kernel, daher ist für mich im Wiki der folgenden Abschnitt auch neu :liest sich aber als wenn da ab jetzt der interne Pullup auf der Datenleitung benutzt wird.

Nee, das ist eine im Netz herumgeisternde Fehlinformation.
Das korrekte Overlay für den 'Normalbetrieb' lautet:

Code Auswählen Erweitern

dtoverlay=w1-gpio
und läuft per default mit GPIO4.

Das w1-gpio-pullup Overlay ist für parasitären Betrieb (mit GPIO5 als externem Pullup-Pin).
Kann aber nicht die Ursache für Elektrofreaks Problem sein, denn die Sensoren laufen auch mit dem falschen Overlay.

Wenn da trotz aktivem Signal keine slaves angelegt werden, sind möglicherweise nicht alle Kernel-Module geladen.
Am besten mit lsmod mal nachschauen, ob diese Module

wire
w1_gpio
w1_therm

vorhanden sind und bei Bedarf nachladen.
OS auf aktuellen Stand bringen, kann auch nicht schaden. Das Kernel-Modul hatte wohl ursprünglich einen Bug.

Dann klappts auch ohne HW-Busmaster.

[Elektrofreak]

Ich habe den Befehl angepasst. Per lsmod kam heraus, dass das w1_therm Modul nicht geladen ist. Die anderen beiden schon.

Auch nachdem Laden des Moduls per modprobe wurden keine Sensoren erkannt...

Kann ich die Arbeit des Busmasters irgendwie debuggen? (Nicht auf bit-Ebene per Logik-Analyzer)

[crusader]

Ich habe den Befehl angepasst. Per lsmod kam heraus, dass das w1_therm Modul nicht geladen ist. Die anderen beiden schon.

Auch nachdem Laden des Moduls per modprobe wurden keine Sensoren erkannt...

Kann ich die Arbeit des Busmasters irgendwie debuggen? (Nicht auf bit-Ebene per Logik-Analyzer)

Wenn die w1-therm gar nicht geladen wurde,  dann erkennt der w1-gpio entweder überhaupt keine Slaves oder er identifiziert sie nicht als DS20.
Da wird Dir der Analyzer wohl keine große Hilfe sein.

Was steht denn in .../w1_bus_master1/w1_master_slave_count bzw. w1_master_slaves ?
Und was ergibt 'dmesg' zum Thema 1wire ?

[Elektrofreak]

Code Auswählen Erweitern


dmesg | grep w1
[   24.062056] w1-gpio onewire@0: gpio pin 4, external pullup pin -1, parasitic power 0
[   24.062247] w1_add_master_device: set_pullup requires write_byte or touch_bit, disabling
[   26.444067] w1_master_driver w1_bus_master1: w1_search: max_slave_count 64 reached, will continue next search.


Code Auswählen Erweitern


cat /sys/bus/w1/devices/w1_bus_master1/w1_master_slave_count
0
cat /sys/bus/w1/devices/w1_bus_master1/w1_master_slaves
not found.


Kommt mir irgendwie komisch vor, dass er max_slave_count erreicht...

[crusader]

Scheinst jedenfalls nicht der einzige zu sein:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=106041&p=731724

Sicher, dass Raspbian aktuell ist ?

[Elektrofreak]

Ja und den Fehler habe ich gefunden... (Verifizierung ausstehend)

Ich habe die minimale cpu-Frequenz auf 100Mhz gestellt und einen dynamischen governor aktiviert. Nach dem entfernen der entsprechenden Zeilen in der /Boot/config.txt (und dem aus kommentieren des Sounds, den muss ich wieder aktivieren zur Verifizierung) wurde der Sensor gefunden.

Vielen Dank bis hierher

[crusader]

Dann viel Spass beim Temperatur-Messen !