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

Begonnen von Steve, 09 Dezember 2015, 19:46:43

Vorheriges Thema - Nächstes Thema

Steve

Hallo,

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


Zitat
[    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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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*"
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Steve

lsub=

ZitatBus 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*=
Zitat
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


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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Steve

Also wie vorher beschrieben eingestellt , jedoch hat FHEM keinen Zugriff auf ttyUSB0
ZitatCan't open /dev/ttyAMA0: Permission denied

Wzut

#12
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 :
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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

Zitat von: Steve am 14 Dezember 2015, 05:56:28
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

Zitat von: Steve am 15 Dezember 2015, 21:26:56
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"  :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Steve

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

Zitat
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.

Zitat
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

#19
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

Zitat von: eldrik am 17 Dezember 2015, 20:57:56
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 :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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

Zitat von: Steve am 18 Dezember 2015, 12:56:36
Ok, ich werde noch mal das System platt machen.

??? wozu soll das gut sein ?
Wichtig ist :
ZitatOWDEVICES: 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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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?


Zitat2015.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

Zitat von: Steve am 20 Dezember 2015, 20:32:26
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 ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Steve

Zumindest habe ich wieder eine saubere Basis.

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

ZitatInternals:
   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

Zitat von: Steve am 21 Dezember 2015, 17:11:10
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 :
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 ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Steve

Kann dies das Problem sein?

ZitatHinweis: 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:

Zitatstty -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
RaPi3, esp8266, LoRa, Tasmota

Wzut

#30
Zitat von: Steve am 21 Dezember 2015, 20:17:35
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 :
$dev .= "\@115200" if( $dev !~ m/\@/ );
abändern auf :
$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)



Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ManfredC

Zitat von: aficianado am 21 Dezember 2015, 22:30:02
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

ZitatJetzt 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
RaPi3, esp8266, LoRa, Tasmota

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 ;D.

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


Die Lösung war folgende:

ZitatDu 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

Zitat von: Steve am 25 Dezember 2015, 17:55:47
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 !
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Flar64

#35
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 :D
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

#36
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  :-\  :D

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

Gruß Flar64

Omega

#38
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:

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

...
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"

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"

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...

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.
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

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
RaPi3, esp8266, LoRa, Tasmota

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
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

Frank-Synology-DS215J

#41
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

#42
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: Frank-Synology-DS215J am 23 Oktober 2023, 13:58:13kann 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 
temp_neu:temperature.* {(ReadingsNum($name,'temperature',999) >-50 &&  ReadingsNum($name,'temperature',999) <100) ? ReadingsNum($name,'temperature',999) : return }
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Frank-Synology-DS215J