Neue 1-Wire-Module für Raspberry Pi u.a.

[Martin]

Super Danke für die schnelle Hilfe hat auch geklappt .
ich hatte aber noch mal gesucht im Netz nach  stateFormat es wird leider nicht erklärt.
Auch nicht auf den Fhem Seiten schade eigentlich für Anfänger wie mich.



Gruß
Martin

[eppi]

Hallo
Ich habe diesen Beitrag mit dem iButton Schlüsselbrett gelesen, welches ich gerne umsetzen möchte.
Frage dazu: Werden die iButton (DS1990A) von OWServer und OWDevice unterstützt?

Danke!
Gruss Dani

[Dr. Boris Neubert]

ich hatte aber noch mal gesucht im Netz nach  stateFormat es wird leider nicht erklärt.
Auch nicht auf den Fhem Seiten schade

Es ist erklärt und Du hast es nicht gefunden.
In der commandref, der zentralen Doku, ist es erklärt, siehe hier: http://fhem.de/commandref.html#attr.

Viele Grüße
Boris

[Dr. Boris Neubert]

Frage dazu: Werden die iButton (DS1990A) von OWServer und OWDevice unterstützt?

OWDevice ist ein generisches Modul und unterstützt alle Geräte, die OWFS unterstützt. Zur Erkennung ist nur eine kleine Ergänzung im Modul nötig. Ob OWFS die iButtons unterstützt, liest Du auf deren Webseite nach.

Viele Grüße
Boris

[eppi]

Hallo Boris

Ob OWFS die iButtons unterstützt, liest Du auf deren Webseite nach

gesucht, gefunden :=)
Dann werde ich mal die Bestellung absetzen.

Danke und Gruss Dani

[UweH]

Hallo 1wire-Mitstreiter,

durch tatkräftige Unterstützung von fladdy ist es gelungen, auch meinen widerspenstigen Raspi dazu zu bringen, über i2c mit den angeschlossenen Sensoren/Devices zu kommunizieren.
Nachdem auch ein komplett neues Image und Update und und und den gleichen Erfolg brachte (nämlich nix), hatte fladdy dann offenbar eine Eingebung.

Ich fasse den Mailverkehr hier Ausschnittweise zusammen, damit andere nicht auch verzweifeln...


pi@raspberrypi ~ $ sudo i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Aber, wenn ich statt der 0 die 1 übergebe:

pi@raspberrypi ~ $ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Es existieren zwei Devices auf einem Raspberry für I2C:

pi@raspberrypi ~ $ ls /dev/i2*
/dev/i2c-0 /dev/i2c-1

Jetzt musst Du aber noch Deine owfs.conf anpassen und aus

server: device = /dev/i2c-1 # i2c port: DS2482-100

server: device = /dev/i2c-0 # i2c port: DS2482-100

machen.

Grund für zwei Devices:

You may have noticed the driver registers two I2C busses. One is the the BSC0 bus that has pins on the GPIO connector, the other is BSC1 which has pins on the camera connector.

Warum die jetzt vertasucht sind? Keine Ahnung - vielleicht liedt es an der Version der Kernel-Treiber oder am der Raspberry Hardware-Revision (256MB erste/zweite Generation bzw. 512MB).

Und hier die Lösung:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=20146

Damit funktioniert es nun.
Weiterer positiver Effekt: Ich konnte mein i2c-Interface testen und auch das läuft. Damit kann man den i2c-Bus ohne COC nutzen.
Details dazu bald in der Bastelecke (neben den anderen lustigen kleinen Basteleien von mir, die da schon zu sehen sind ;-) ).

[MarkusN]

Wäre jemand so nett folgende Ergänzung in die 11_owdevice.pm einzupflegen?

Code Auswählen Erweitern

     } elsif($family eq "20") {
        # 2450 - 1-Wire Quad A/D Converter
        # added by markus niemann
        unshift @getters, qw(volt.A volt.B volt.C volt.D);
        unshift @setters, qw();
        unshift @polls, qw(volt.A volt.B volt.C volt.D);
        #$interface= "state";

volt.A - volt.C sind die für mich interessanten Daten (Strom-/Spannungsdaten eines 1-Wire Hub von eservice-online), ggf lohnt es sich aber weitere auszulesen:

Code Auswählen Erweitern

/20.9E5810000000/8bit
/20.9E5810000000/CO2
/20.9E5810000000/PIO.ALL
/20.9E5810000000/PIO.A
/20.9E5810000000/PIO.B
/20.9E5810000000/PIO.C
/20.9E5810000000/PIO.D
/20.9E5810000000/address
/20.9E5810000000/alarm
/20.9E5810000000/alias
/20.9E5810000000/crc8
/20.9E5810000000/family
/20.9E5810000000/id
/20.9E5810000000/locator
/20.9E5810000000/memory
/20.9E5810000000/pages
/20.9E5810000000/power
/20.9E5810000000/r_address
/20.9E5810000000/r_id
/20.9E5810000000/r_locator
/20.9E5810000000/set_alarm
/20.9E5810000000/type
/20.9E5810000000/volt.ALL
/20.9E5810000000/volt.A
/20.9E5810000000/volt.B
/20.9E5810000000/volt.C
/20.9E5810000000/volt.D
/20.9E5810000000/volt2.ALL
/20.9E5810000000/volt2.A
/20.9E5810000000/volt2.B
/20.9E5810000000/volt2.C
/20.9E5810000000/volt2.D


[Martin Fischer]

hallo markus,

Wäre jemand so nett folgende Ergänzung in die 11_owdevice.pm einzupflegen?

Code Auswählen Erweitern

     } elsif($family eq "20") {
        # 2450 - 1-Wire Quad A/D Converter
        # added by markus niemann
        unshift @getters, qw(volt.A volt.B volt.C volt.D);
        unshift @setters, qw();
        unshift @polls, qw(volt.A volt.B volt.C volt.D);
        #$interface= "state";

ich war vor einer woche schon kurz davor das einzuchecken aber hatte dann nochmal mit boris gesprochen.

das design von OWDevice ist (aus meiner sicht) noch nicht ganz rund. hintergrund ist nämlich:

Code Auswählen Erweitern

  PIO.A ... PIO.D PIO.ALL
       read-write, yes-no
       Pins used for digital control. 1 turns the switch on (conducting). 0 turns the switch off (non-conducting).
       Control is specifically enabled. Reading volt will turn off this control.
entscheidend dabei ist der letzte satz. bei volt bzw. volt2 ist es umgekehrt:

Code Auswählen Erweitern

volt.A ... volt.D volt.ALL
   8bit/volt.A ... 8bit/volt.D 8bit/volt.ALL
       read-only, floating point
       Voltage read, 16 bit resolution (or 8 bit for the 8bit directory). Range 0 - 5.10V.
       Output ( PIO ) is specifically disabled.
da jede abfrage des busses aber auch gleichzeitig mit einer last verbunden ist, sollte das erst im modul geregelt werden.

wenn nämlich alle readings in @gettes und @polls aufgenommen werden, dann erfolgen auch überflüssige abfragen. es gibt noch ein paar weitere devices, die sich so verhalten.

ich wollte da nun nicht in boris' codebasis eingreifen, aber boris wollte sich gedanken dazu machen. es gilt ebenso noch eine saubere lösung umzusetzen, wie ein auslesen von "unterverzeichnissen" also z.b. "HIH3600/humidity" sauber in den readings dargestellt werden soll.

gruß martin

[Dr. Boris Neubert]

Ich fasse den Mailverkehr hier Ausschnittweise zusammen, damit andere nicht auch verzweifeln...

Das steht in Kurzform auch in dem Link im Ursprungsposting dieses Threads.

War das zu versteckt?

Grüße
Boris

[Dr. Boris Neubert]

wenn nämlich alle readings in @gettes und @polls aufgenommen werden, dann erfolgen auch überflüssige abfragen. es gibt noch ein paar weitere devices, die sich so verhalten.

Ich bin der Meinung, daß der aktuelle Stand das alles berücksichtigt:

Die @getters definieren die Readings, die man Abfragen kann. Tatsächlich abgefragt wird ein Reading aber nur mit [code]get myDevice theReading[/code Dabei wird nur genau das Reading abgefragt und kein anderes.

Die @polls sind diejenigen Readings, die automatisch alle x Sekunden abgefragt werden, wenn man ein Polling-Intervall beim define angibt.

Auf Deine Anmerkung hin hatte ich noch das Attribut polls eingeführt, über das der Anwender angeben kann, welche Readings er pollen möchte, wenn er mit der Vorgabe nicht zufrieden ist.

Aus meiner Sicht müßte damit alles laufen, sogar Readings der Form "foo/bar", also aus Unterverzeichnissen von OWFS, wobei ich diesen letzten Punkt noch nicht getestet habe. Du hattest mir den Tip gegeben, es mit den FAKE-Devices zu tun.

Viele Grüße
Boris

[Dr. Boris Neubert]

wäre es möglich ein model-Attribut innerhalb von OWDevice automatisch zu setzen (z.B. DS18B20)?

Ja. Baue ich gelegentlich mal ein.

Erledigt und morgen verfügbar. Beim define wird es aus dem Reading type gesetzt.

Grüße
Boris

[Martin Fischer]

Auf Deine Anmerkung hin hatte ich noch das Attribut polls eingeführt, über das der Anwender angeben kann, welche Readings er pollen möchte, wenn er mit der Vorgabe nicht zufrieden ist.

Aus meiner Sicht müßte damit alles laufen, sogar Readings der Form "foo/bar", also aus Unterverzeichnissen von OWFS, wobei ich diesen letzten Punkt noch nicht getestet habe. Du hattest mir den Tip gegeben, es mit den FAKE-Devices zu tun.

ah, ich erinnere mich... muss bei mir irgendwie untergegangen sein..

gruss martin

[UweH]

Offenbar nicht, ich habe auch eben nochmal gesucht und bin nicht fündig geworden.
Es gibt diesen Link http://neubert-volmar.de/Hausautomation/RaspberryPi/index.html und diesen http://wiki.temperatur.nu/index.php/OWFS_with_i2c_support_on_Raspberry_Pi_%28English_version%29.
Was übersehe ich?

[fladdy]

Danke!

Die Tatsache, dass man bei RevA-Raspberrys /dev/i2c-0 statt /dev/i2c-1 nehmen muss, habe ich auch nicht in Deiner Anleitung gefunden. Vielleicht kannst Du das ja noch aufnehmen/hervorheben.

wäre es möglich ein model-Attribut innerhalb von OWDevice automatisch zu setzen (z.B. DS18B20)?

Ja. Baue ich gelegentlich mal ein.

Erledigt und morgen verfügbar. Beim define wird es aus dem Reading type gesetzt.

Grüße
Boris

[Dr. Boris Neubert]

Die Tatsache, dass man bei RevA-Raspberrys /dev/i2c-0 statt /dev/i2c-1 nehmen muss, habe ich auch nicht in Deiner Anleitung gefunden. Vielleicht kannst Du das ja noch aufnehmen/hervorheben.

Hab's aufgenommen in der Anleitung

Grüße
Boris