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

[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