1wire-USB-Master [SMS-Guard] Installation

[Steve]

Hallo,

ich bekomme absolut nicht meinen Busmaster wie hier beschrieben http://www.sms-guard.org/downloads/1wire-USB-Master/index.htm zum laufen.

[    8.425554] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0


pi@raspberrypi ~ $ /home/pi/1wire-USB /dev/ttyUSB0 /tmp/ -l
start 1wire-USB v1.03
check multiple running
1wire-USB runs not multiple and will be continued
o$??
i
try Baud 115200
o$??
i
no 1wire-USB-Master found on /dev/ttyUSB0

Die Schnittstelle ist aktiv jedoch werden keine Daten in den Ordner "ttyUSB0" geschrieben. Ein Sensor ist angeschlossen.

Kann mir jemand eine verständliche Anleitung geben wie ich auf dem RPI das Ding zum laufen bekomme.

Gekauft habe ich aus dem Grund das mit der Kompatibilität mit FHEM geworben wird und jetzt geht nichts.

Der Hersteller gibt auch keine zufrieden stellende Antwort auf meine Fragen

[Prof. Dr. Peter Henning]

Tut mir ja jetzt etwas leid, aber man verlässt sich bei so etwas auch besser nicht auf die Hersteller, sondern auf die Anleitungen: http://www.fhemwiki.de/wiki/Kategorie:1-Wire

Es handelt sich nämlich NICHT um einen echten 1-Wire Busmaster, sondern um eine proprietäre Lösung auf einem Mikrocontroller.

Mein Tipp: Abschreiben.

LG

pah

P.S.: /dev/ttyUSB0 ist kein Ordner, sondern ein Linux-Device

[Steve]

Abschreiben bedeutet Schublade?...dann drücke ich den Mißt lieber dem Hersteller auf das Auge.

Für die 35€ kann ich auch eine bessere Lösung kaufen. Blos welche?

Über GPIO4 möchte ich es nicht mehr machen da die Meßdaten sehr fehlerhaft sind.

[Frank_Huber]

der von sms-guard war auch mein erster fehlgriff.
hab ihn zurückgeschickt über Fernabsatz.

Hab jetzt den hier mit OWX angebunden:
http://www.ebay.de/itm/171041719472
top zufrieden!

[Wzut]

oder doch zuerst mal mit fhem und dem Modul das ich für das Teil geschrieben habe testen :
http://forum.fhem.de/index.php/topic,28447.0.html

[Prof. Dr. Peter Henning]

Oder so. Trotzdem ärgerlich, dass der Hersteller hier halbwahre Angaben macht...

Ich habe einen Kontakt zu Maxim, mal sehen.

LG

pah

[Steve]

Entfällt mit dem Modul( von Wzut empfohlen) von die Installation lt. Hersteller?

[Wzut]

Auch mit meinen Modulen muß der User unter dem fhem läuft zumindest Zugriff auf /dev/ttyUSBx haben.
Postet doch bitte mal die Ausgabe auf der Konsole von "lsusb" und "ls -l  /dev/tty*"

[Steve]

lsub=

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 005: ID 05dc:a833 Lexar Media, Inc.

lsusb" und "ls -l  /dev/tty*=

crw-rw---- 1 root tty     204, 64 Dec  9 19:40 /dev/ttyAMA0
crw-rw---T 1 root dialout   5,  3 Dec  9 19:40 /dev/ttyprintk
crw-rw---T 1 root dialout 188,  0 Dec  9 19:42 /dev/ttyUSB0

[Prof. Dr. Peter Henning]

chmod 777 /dev/ttyUSB0

[Wzut]

wenn dein fhem unter dem User fhem läuft würde ich auf jeden Fall den User noch in die Gruppe dialout packen :
sudo usermod -a -G dialout fhem

[Steve]

Also wie vorher beschrieben eingestellt , jedoch hat FHEM keinen Zugriff auf ttyUSB0

Can't open /dev/ttyAMA0: Permission denied

[Wzut]

AMA0 ist die serielle Schnitstelle des Raspi auf den GPIO Pins und NICHT das Gleiche wie USB0 !
und schau dir mal in deiner config  das an bzw. nimm es raus :

Code Auswählen Erweitern

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create

[Steve]

Sorry, da hab ich nicht richtig gelesen.

Also ttyUSB0 wird abgefragt und es gibt keine Störmeldung.

Jedoch sind im ttyUSB0 keine Daten die übertragen werden können.

Hab auch noch mal mit Filezilla nachgeschaut.

Eine Sensor habe ich am USB-Master angeschlossen und auch noch einmal getauscht.

[eldrik]

Sorry, da hab ich nicht richtig gelesen.

Also ttyUSB0 wird abgefragt und es gibt keine Störmeldung.

Jedoch sind im ttyUSB0 keine Daten die übertragen werden können.

Hab auch noch mal mit Filezilla nachgeschaut.

Eine Sensor habe ich am USB-Master angeschlossen und auch noch einmal getauscht.

Was sollte dort auch ausser dem "Busmaster" zu finden sein 

Wzut hat bereits einen Hinweis, auf das von ihm, für diesen "Busmaster", geschriebene Modul gegeben und passend verlinkt, dort ist knackig erklärt was auf Seiten Fhem gemacht werden muss um den Busmaster und die Sensoren einzubinden (ein allgemeiner Umgang mit Fhem Modulen und das manuelle kopieren der Modul Dateien, in die richtigen FHEM Unterordner, wird jedoch vorausgesetzt).

http://forum.fhem.de/index.php/topic,28447.msg215143.html#msg215143

Greetz
Eldrik

[Prof. Dr. Peter Henning]

Außerdem eine minimale Kenntnis über Devices - und warum es absoluter Käse ist, sie mit filezilla ansehen zu wollen...

http://www.cyberciti.biz/faq/understanding-unix-linux-bsd-device-files/

LG

pah

[Steve]

Ich arbeite schon Jahre mit Fhem und hab so ziemlich Alles was ich wollte zum laufen gebracht (auch mit Hilfe des Forums)

Wenn hier einige hauptberuflich mit Linux zu tun haben ist das ja super... ich nicht.

Deshalb habe ich mich im Forum an Euch gewand um eine Hilfestellung zu bekommen und nicht um belehrt zu werden.

Es tut mir sehr Leid das ich das Niveau von Einzelnen unterschreite.

[Wzut]

an Euch gewand um eine Hilfestellung zu bekommen und nicht um belehrt zu werden.

Doch , doch du willst etwas dazu lernen und die die lehren würde unheimlich gerne von dir den Satz lesen : "ok alles klar läuft , danke" 

[Steve]

Ich hab die Module eingefügt und auch in der cfg aktiviert.

Clients :USBSLAVE:
DEF:   /dev/ttyUSB0
DeviceName:  /dev/ttyUSB0@115200
FD: 4
INTERVAL: 10
NAME: SMSguard
NR: 21
OWDEVICES: 0
PARTIAL
STATE: Initialized
TYPE: USBMASTER

Jedoch liegt das Problem warscheinlich an der Installation des BusMasters.

pi@raspberrypi ~ $ sudo killall 1wire-USB
1wire-USB: no process found
pi@raspberrypi ~ $ sudo /home/pi/1wire-USB /dev/ttyUSB0 /tmp -l
start 1wire-USB v1.03
check multiple running
1wire-USB runs not multiple and will be continued
o$??
i
try Baud 115200
o$??
i
no 1wire-USB-Master found on /dev/ttyUSB0

es wird kein Busmaster in ttyUSB0 gefunden.

Wie schon geschrieben sehe ich das Problem nicht in der Umsetzung in FHEM sondern eher in der Installation des Busmasters.

Mit dem Befehl "sudo killall 1wire-USB" kommt wie oben im Zitat stehend die Fehlermeldung.

[eldrik]

das Problem ist wohl vielmehr, dass an den Busmaster mögliche Sensoren (welche? USBSLAVE unterstützt ja Wzut nach nur ds18b20) einfach falsch angeschlossen wurden... oder wurden vielleicht schon über autocreate USBSLAVE Geräte in Fhem angelegt und einfach nur übersehen?

und warum und wozu man 1wire-USB (scheinbar ein Programm vom Hersteller wenn man kein Fhem nutzt?) noch starten will wenn fhem bereits über das Modul USBMASTER das Device /dev/ttyUSB0 belegt und erfolgreich "Initialized" hat...

Greetz
Eldrik

[Wzut]

und warum und wozu man 1wire-USB (scheinbar ein Programm vom Hersteller wenn man kein Fhem nutzt?) noch starten will wenn fhem bereits über das Modul USBMASTER das Device /dev/ttyUSB0 belegt und erfolgreich "Initialized" hat...

sehe ich auch so
@Steve . schon mal den Film Highlander gesehen ?
Stichwort : "Es kann nur Einen geben"
D.h. kümmer dich nicht um irgendwelche externen Programm, Stick einstecken, Gerät in fhem anlegen , fertig

[Steve]

Ok, ich werde noch mal das System platt machen.

Ich bin natürlich die Installation lt. SMS-Guard durch gegangen und hab da bestimmt Dinnge eingestellt die dann nachträglich zu Problemen führen.

Auf die Information habe ich gewartet das der Stick nur eingesteckt wird und dann mit FHEM ausgelesen werden kann.

Ich werde berichten....

[Wzut]

Ok, ich werde noch mal das System platt machen.

wozu soll das gut sein ?
Wichtig ist :

OWDEVICES: 0
STATE: Initialized

STATE: Initialized -> für fhem alles prima , alles gut
OWDEVICES: 0  -> kein OW Gerät am Bus gefunden, hier würde ich weitermachen und zumindest mal einen Sensor anschliessen oder wenn 1W jetzt nicht so wichtig ist die Pins der beiden Zähler mal auf Masse legen und schauen wie A und B hochzählen

[Steve]

Habe jetzt RPI neu aufgesetzt.

- FHEM 5.7 installiert
- BusMaster eingesteckt
-"chmod 777 /dev/ttyUSB0"
- "USBMASTER" und "USBSLAVE" in opt/fhem/FHEM eingefügt
- in cfg "define Test USBMASTER /dev/ttyUSB0" eingegeben

Es wird weiterhin kein Device erkannt. Die Sensoren (DS18B20) mehrmals gewechselt und auch die S0 Eingänge betätigt.

In den Readings und im Logfile wird nichts angezeigt.(außer das ttyUSB erreichbar ist)

Habe ich noch etwas vergessen oder ist der BusMaster defekt?

2015.12.20 20:08:40 1: /dev/ttyUSB0 disconnected, waiting to reappear (Test)
2015.12.20 20:10:35 3: Setting Test serial parameters to 115200,8,N,1
2015.12.20 20:10:35 1: /dev/ttyUSB0 reappeared (Test)
2015.12.20 20:14:01 1: /dev/ttyUSB0 disconnected, waiting to reappear (Test)
2015.12.20 20:14:11 3: Setting Test serial parameters to 115200,8,N,1
2015.12.20 20:14:11 1: /dev/ttyUSB0 reappeared (Test)

[Wzut]

Habe jetzt RPI neu aufgesetzt.

- FHEM 5.7 installiert

schade, die Zeit hättest du sinnvoller verbringen können .... jetzt kannst auch hier wieder auf Seite 1 anfangen und die wichtigen Infos liefern :
Ausgabe von "ls -l  /dev/tty*" ?
Ausgabe von list Test ?

[Steve]

Zumindest habe ich wieder eine saubere Basis.

crwxrwxrwx 1 root dialout 188,  0 Dec 21 17:05 /dev/ttyUSB0

Internals:
   Clients    :USBSLAVE:
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0@115200
   FD         11
   INTERVAL   10
   NAME       Test
   NR         21
   OWDEVICES  0
   PARTIAL    9�
   STATE      Initialized
   TYPE       USBMASTER
   Matchlist:
     1:USBSLAVE T.*$
   Readings:
     2015-12-20 21:18:28   state           Initialized

[Wzut]

PARTIAL    9�
   STATE      Initialized

Da stimmt etwas nicht , nach 10 Sekunden sollten die beiden Zähler gelesen sein und STATE nicht mehr auf Initialized stehen, das Partial mit den zwei Zeichen zeigt auch an das etwas von /dev/ttyUSB0 gelesen wurde aber eben nicht richtig.

so sollte das eigentlich aussehen wenn noch keine OW Devices angeschlossen sind :

Code Auswählen Erweitern

Internals:
   CFGFN
   Clients    :USBSLAVE:
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0@115200
   FD         8
   INTERVAL   10
   NAME       USBMASTER
   NR         20
   OWDEVICES  0
   PARTIAL
   STATE      A:2000 - B: 0
   TYPE       USBMASTER
   Matchlist:
     1:USBSLAVE T.*$
   Readings:
     2015-12-21 18:59:11   A               2000
     2015-12-21 18:59:11   B               0
     2015-12-21 18:59:11   state           A:2000 - B: 0

Hast du die Möglichkeit den Stick an einem anderen PC / System anzuschliessen ?

[Steve]

Kann dies das Problem sein?

Hinweis: Seit idem 25. Aug 2015 (Firmware u1-01c) beträgt die Baudrate beträgt 38400 anstelle 115200. Die Baudrate lässt sich aber per Lötbrücke auf 115200 gemäß Bild dauerhaft setzen.

[Steve]

noch eine kleine Info:

stty -F /dev/ttyUSB0 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany
-imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl
echoke

Baudrate steht auf 115200.

An einem anderen PC habe ich den Stick angesteckt jedoch wird er nicht erkannt-> nächste Baustelle

[aficianado]

ich glaube, hier liegen einige Missverständnisse vor, vielleicht kann ich ja helfen:
- dieser 1wire-USB-Master hat einen eigenen Treiber für den RaPi, der die 1wire-Sensoren in Textfiles schreibt. Die Anbindung an FHEM ist beschrieben unter http://www.sms-guard.org/downloads/1wire-USB-Master-fhem/index.htm
- für eine Inbetriebnahme verhält sich der 1wire-USB-Master am USB wie eine serielle Schnittstelle. Dazu aus der Doku:
der 1wire-USB-Master kann recht einfach mit einem seriellen Terminal minicom/HyperTerminal geprüft werden:
a) serielle Schnittstelle einstellen auf 115200 (ab 25.8.15 u1-01c 38400 )8-N-1 kein Handshake RTS/CTS, kein On/Off
Protokoll und darauf achten, dass der Adapter auch wirklich an ,,/dev/ttyUSB2" o.ä. hängt und kein anderer Prozess diese
Schnittstelle nutzt.
LED-Befehl eingeben, damit die rote LED jeden gültigen Befehl anzeigt: $L+<CR>
b) Startbefehl eingeben, damit wird auch die Wandlung im Sensor ausgelöst: $?<CR>
c) mit angeschlossenen 1wire-Sensoren werden die gefundenen IDs gelistet: $0;o;1080974B020800BA;
das ,,o" steht für ,,ok" und die Checksumme der ID wurde geprüft und ist ok
d) danach gibt der 1wire-USB-Master die beiden S0-Zählerstände zurück: $S0;0;0;
e) die Werte der 1-wire Sensoren können nach 1s abgefragt werden mit: $0<CR> ... $63<CR>
f) danach gibt der 1wire-USB-Master die Daten des Sensors zurück: $0;o;31;00;4B;46;FF;FF;07;10;8D;64;
das ,,o" steht für ,,ok" und die Checksumme (9.Byte) der 8 Datenbytes wurde geprüft und ist ok (,,n" wäre ,,nicht ok")
die Beschreibung der 8 Datenbytes in Hex ist dem Sensordatenblatt zu entnehmen
das 10.Byte ist eine Checksumme für die serielle Ü bertragung (Byte1-9 aufaddiert).
g) die S0-Zählerstände können auf 0 gesetzt werden mit: $rez<CR>
h) wird das Terminalprogramm beendet und die Schnittstelle frei gegeben, so kann mit der ,,1wire-USB-rrd-sh" (cron) das
automatische Einlesen des Adapters vollzogen werden und die Sensordaten werden in Textfiles geschrieben

Kannst Du das bitte bestätigen?

Beste Grüße

[Wzut]

Kann dies das Problem sein?

Nicht nur kann , das ist es

Du kannst nun :
a. ändere den Aufruf in fhem von define Test USBMASTER /dev/ttyUSB0 in define Test USBMASTER /dev/ttyUSB0@38400
nach 10 Sekunden sollten dann die beiden Zähler erscheinen
oder
b. die Datei 00_USBMASTER.pm in Zeile 57 ändern :

Code Auswählen Erweitern

$dev .= "\@115200" if( $dev !~ m/\@/ );
abändern auf :

Code Auswählen Erweitern

$dev .= "\@38400" if( $dev !~ m/\@/ );
und danach in FHEM neu starten, oder
c. du tauschst deine 00_USBMASTER gegen die angehängte Version.
(fhem auch neustarten)

[ManfredC]

ich glaube, hier liegen einige Missverständnisse vor, vielleicht kann ich ja helfen:
- dieser 1wire-USB-Master hat einen eigenen Treiber für den RaPi, der die 1wire-Sensoren in Textfiles schreibt. Die Anbindung an FHEM ist beschrieben unter http://www.sms-guard.org/downloads/1wire-USB-Master-fhem/index.htm

Jetzt bring ihn nicht noch mehr durcheinander. Wenn er das Modul von Wzut verwendet, braucht er den ganzen sms-guard Kram nicht!

-Manfred

[aficianado]

Jetzt bring ihn nicht noch mehr durcheinander. Wenn er das Modul von Wzut verwendet, braucht er den ganzen sms-guard Kram nicht!

entschuldige, ich möchte bestimmt niemand verunsichern, sondern Licht in die Angelegenheit bringen. Leider habe ich den Thread erst jetzt gesehen. Bei mir läuft dieser 1wire-USB-Master an einem Raspberry mit DS18S20-Sensoren und FHEM so wie in der Anleitung des Herstellers beschrieben.

Das Missverständnis liegt wohl darin, dass owfs etc. einen Busmaster-Chip erwartet, wie DS2482, etc. und geläufige 1wire-Treiber in FHEM ebenso. Jedoch der 1wire-USB-Master von sms-guard macht dies über einen ATmega und die Anbindung an einem Raspberry erfolgt über einen "Treiber" namens "1wire-USB", der die 1wire-Daten vom Adapter holt und in Text-Files schreibt, die dann in FHEM eingelesen werden können.

Sicherlich kann man den Adapter auch über USB-seriell direkt von FHEM einlesen lassen, wie von Wzut beschrieben. Aber das habe ich noch nicht probiert.

Frohe Festtage und Grüße

[Steve]

Hallo Leute,

vielen Dank für die Hilfe und Geduld die ihr mit mit habt.

Ich habe einen Erfolg zu verkünden.

Das Modul von Wzut funktioniert .

Es lag tatsächlich an der Bautrate. Die wurde im September vom Hersteller geändert von 115200 auf 38400.


Die Lösung war folgende:

Du kannst nun :
a. ändere den Aufruf in fhem von define Test USBMASTER /dev/ttyUSB0 in define Test USBMASTER /dev/ttyUSB0@38400
nach 10 Sekunden sollten dann die beiden Zähler erscheinen

[Wzut]

Ich habe einen Erfolg zu verkünden.

Ach Steve , das ist ja wie Weihnachten ....
Ich werde die Info über die neue Baudrate gleich mal im eigentlichen Modul Threat hinzufügen !

[Flar64]

Hallo zusammen,
ich bin mit meinen DS1820 Sensoren vom GPIO-Betrieb auf den 1wire-USB-Master umgestiegen und benutze die Module von Wzut, gute Arbeit übrigens.

Nun meine Frage:
ich bekomme mit dem Modul von Wzut eine andere Sensor-ID ausgegeben als wie bei dem vorherigen Betrieb über die GPIO.
Wie kann ich meine Sensoren nun einfach identifizieren ohne jeden einzeln abklemmen zu müssen  und wieder neu anzuschließen oder mit einem Föhn durch die Gegend zu rennen?
Es sind 14 Stück schön verteilt was einen gewissen Aufwand mit sich bringt.
Ein Versuch mit umrechnen in binär<->hex brachte mir kein erkennbares Schema.
Beispiel: ID über GPIO 14 stellig 28-564c98cff
     ID mit OW2S0Slave 16 stellig 28FF8CC96415017E

Vielleicht gibt es ja einen Weg die vorhandenen Sensoren den alten IDs zuzuordnen.


Problem gelöst !!!

Nach dem editieren des obigen Textes ist es mir aufgefalen
Die Sensor-ID ist verdreht.
Erst kommen die 8Bit was den Familytyp angibt in meinem Fall die 28 für den DS18b20, soweit ok aber dann geht es paarweise von hinten nach vorn und am Schluss noch ein neues Paar.
Da es sich laut Dokumentation des Sensorherstellers um eine 64Bit-Kennung handeln soll (also 16stellig in Hex), gehe ich davon aus das die mit dem GPIO-Modul ausgelesene ID nicht vollständig ist. Warum da jetzt zwischen den beiden ausgelesenen IDs ein Dreher drin ist, weis ich allerdings nicht.

[Prof. Dr. Peter Henning]

Aber ja doch. 28 ist die Family ID, die eigentliche ID besteht aus 6 Byte. Also:

Bitte von FF 8C C9 64 15 01 7E das letzte Byte (=CRC-Code) weglassen und  rückwärts lesen:

01 15 64 C9 8C FF

Die GPIO-ID ist einfach verdreht, und es fehlen 3 Nibbles

LG

pah

Sorry, da hat sich mein Post mit dem Edit um wenige Sekunden überschnitten.

[Flar64]

So ist das halt manchmal, man sieht den Wald vor lauter Bäumen nicht   

Auch wenn ich schon von selbst dahinter gekommen war, trotzdem vielen Dank   

Gruß Flar64

[Omega]

Hallo,
ich hänge mich hier mal an mit meinem Problem.

Mein Stick bleibt leider im Status ,,Initialized" stehen. FHEM läuft in einer VM unter Debian 8.6.

Ein list vom Device:

Code Auswählen Erweitern


Internals:
   Clients    :OW2S0SLAVE:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702PEEN-if00-port0@115200
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702PEEN-if00-port0@115200
   FD         42
   INTERVAL   10
   NAME       1Wire2S0
   NR         179
   OWDEVICES  0
   PARTIAL
   STATE      Initialized
   TYPE       OW2S0SMSGUARD
   Matchlist:
     1:OW2S0SLAVE T.*$
   Readings:
     2016-11-02 14:23:28   A               0
     2016-11-02 14:23:28   B               0
     2016-11-02 14:27:56   state           Initialized
Attributes:
   room       OneWire


Die Schnittstellengeschwindigkeit stimmt, auf einem Cubietruck läuft der Adapter.

Ein ,,ls -l  /dev/tty*" zeigt

Code Auswählen Erweitern


...
crw-rw---- 1 root dialout   4, 66 Nov  2 14:27 /dev/ttyS2
crw-rw---- 1 root dialout   4, 67 Nov  2 14:27 /dev/ttyS3
crw-rw---- 1 root dialout 188,  0 Nov  2 14:31 /dev/ttyUSB0
crw-rw---- 1 root dialout 188,  1 Nov  2 14:31 /dev/ttyUSB1


"lsusb"

Code Auswählen Erweitern


Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


und ein "ls -l /dev/serial/by-id"

Code Auswählen Erweitern


lrwxrwxrwx 1 root root 13 Nov  2 14:27 usb-FTDI_FT232R_USB_UART_A702PEEN-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Nov  2 14:27 usb-FTDI_FT232R_USB_UART_A902YK84-if00-port0 -> ../../ttyUSB0


ttyUSB0 ist ein Vitocrossal Optolink Adapter
ttyUSB1 ist der 2xS0+1wire-Adapter

Leider ist Linux für mich noch eine große Baustelle...

LG
Holger

Nachtrag:
Eben habe ich im Log noch folgendes gefunden...

Code Auswählen Erweitern


2016.11.02 14:57:43 1: PERL WARNING: Use of uninitialized value $linearr[1] in string ne at ./FHEM/00_OW2S0SMSGUARD.pm line 296.
2016.11.02 14:57:43 3: 1Wire2S0 NOK message: ??aL%!RRRRRRRR?a?aR?aRR?

Programmversion ist die, bei der die S0-Zähler resettet werden können.

[aficianado]

Hallo Holger,
leider kenn ich die *SMSGUARD*.pm nicht, aber wenn Du prüfen möchtest ob der Stick läuft, in der Doku von dem Stick

http://www.sms-guard.org/downloads/1wire-USB-Master.pdf

ist auf Seite 3 unter Fehlersuche beschrieben, wie der Stick mit einem seriellen Terminal angesprochen werden kann.

Außerdem ist unter

http://www.sms-guard.org/downloads/1wire-USB-Master-fhem.pdf

beschrieben, wie die Sensordaten nach FHEM als dummy gelangen und grafisch dargestellt werden.
Also bei mir funktioniert das prima im Dauerbetrieb.

Viele Grüße

[Omega]

Danke für die Unterstützung.

Ich glaube mittlerweile, dass meine Probleme vom ESXi ausgelöst werden. Auf einem anderen ESXi habe ich noch eine VM aufgebaut (diesmal eine ältere Debian-Version).  Dort hat der Adapter ein bisschen funktioniert. Eine Vermutung ist dass die Übertragungsrate mit 115200 zu hoch ist. Soweit ich allerdings weiß, ist diese Geschwindigkeit fest vorgegeben. Und einen Grund wird es wohl haben, dass der Hersteller ab 08/2015 hw-seitig den Stick nur noch mit 38400 ausliefert.

Ich habe mir jetzt einen anderen Adapter bestellt – mal sehen, ob es damit besser funktioniert.

LG
Holger

[Frank-Synology-DS215J]

Ich benutze zwei Module des 1wire-USB-Master [SMS-Guard] schon seit langem und habe alle Sensoren meiner Heizungssteuerung mit 1wire ausgestattet.
Mittlerweile sind es über 60 Sensoren.

Ich habe dazu mal zwei Fragen.
1. Ich finde die Datei "14_OW2S0SLAVE.pm" nach der Neuinstallation nicht mehr. Ist scheinbar auch nicht im SVN repository zu finden. Wo finde ich diese zum download ? oder wird diese Datei aus der Datei 00_OW2S0SMSGUARD.pm generiert ?
2. Ich habe öfter Ausreißer in den Messungen bzw Fehlmessungen, kann man da noch einen Plausibilitätscheck einfügen ? Ich habe mir über userReadings was geschrieben findes aber nervig das bei jedem Sensor von Hand zu machen.

mein userReading sieht so aus:

temperature.neu { ReadingsVal($name,"temperature",0)},
temperature.old { OldReadingsNum($name,"temperature.neu",0) },
temperature.plausibilitaet1 {if (ReadingsVal($name,"temperature.neu",'' ) < 100){ReadingsVal($name,"temperature.neu","")} else {ReadingsVal($name,"temperature.old","")}},
temperature.plausibilitaet2 {if (ReadingsVal($name,"temperature.plausibilitaet1",'' ) > -50){ReadingsVal($name,"temperature.plausibilitaet1","")} else {ReadingsVal($name,"temperature.old","")}},
temperature.oldreading { OldReadingsVal($name,"temperature.plausibilitaet2",0) }

Dazu gehört noch ein oldreading temperature.neu,temperature.old,temperature.plausibilitaet2

geht bestimmt auch einfacher ?

LG Frank

[Wzut]

Der Thread zum Modul ist hier -> https://forum.fhem.de/index.php?topic=28447.0
die Version vom 13.3.21 macht einige Logik Prüfungen der Werte und verwalten auch die Sub Devices,
d.h. 14_OW2S0SLAVE.pm ist seit Jahren überflüssig und daher auch nicht mehr im svn vorhanden.

[Wzut]

kann man da noch einen Plausibilitätscheck einfügen ? Ich habe mir über userReadings was geschrieben

Die DS18xxx Sensoren haben wohl einen gültigen Messbereich von -55 bis +125 °C. 
Fehlerhafte Werte sollten eigentlich breits durch die CRC Prüfung fallen.
Deine userReadings verstehe ich allerdings nicht so ganz. Warum so ein Aufwand und viele Readings und nicht einfach mit einer Zeile auf -50 bis 100 prüfen und Ende (für ungültige Werte willst du doch eh keinen Event)  ?
Bsp 

Code Auswählen Erweitern

temp_neu:temperature.* {(ReadingsNum($name,'temperature',999) >-50 &&  ReadingsNum($name,'temperature',999) <100) ? ReadingsNum($name,'temperature',999) : return }

[Frank-Synology-DS215J]

  Top ! Vielen lieben Dank Dir