...das war heute schon etwas umfangreicher.
Bin nach zwei Wochen Parallelbetrieb endlich weg von den OW Modulen mit Grossbuchstaben, hin zu OWServer und OWDevice.
Hab ich mich sehr drauf gefreut, aber mitten in der Heizperiode, sollte da nichts schief gehen.
Also habe ich lange getestet und einen 2m 1W-Bus auf meinem Schreibtisch aufgebaut, und eine handvoll Sensoren an das COC auf meinem RPi angeschlossen. Soweit alles ok!
Heute dann also das ganze in Ernst! Neues Kabel runter in den Keller mit 4x 0,8mm² Telefonkabel anstatt menies Billig-Kabels, an dem bislang alles hing.
Und? Nüscht! Kein Sensor wird erkannt, sobald auch nur das leer laufende Kabel dran hängt. Also Kabel wieder ab. Alles auf dem Schribteisch wieder erkannt.
Hum.... komisch.
Nehmen wir doch mal den anderen RPi mit dem Polen USB Interface.... BINGO! Alles da. Auch mit neuem Kabel runter in den Keller. Alles gar kein Problem.
Also wieder zurück zum ersten RPi mit COC. NIX! Keine Chance. Hab alles probiert, inkl. verschiedener PullUps und alle anderen Kombinationen - aber bekomme keine Antworten vom Bus, so lange das lange Kabel dran ist.
Nachdem alles versagte, hab ich mein COC vergewaltigt und einen Level-Shifter direkt an Pin 2 vom DS2482 gelötet. Und siehe da: alles funktioniert sofort!
Also entweder ist der MAX3394 auf meinem COC defekt (was ich nicht glaube, weil dann würde er die Devices am kurzen Bus nicht erkennen), oder es gibt hier einen Design-Bug.
Frage: hat schon jemand den OW-Bus vom COC mit Leitungslängen > 5m erfolgreich im Betrieb?
Aber das Gute: endlich vernünftige OW Module. Meine Freude kennt gerade kaum Grenzen.
Vielen Dank den Beteiligten, für diese herausragende Leistung!
VG
Ralf
Das COC wurde für einfachen Anschluss für Sensoren im Nahbereich ausgelegt und wird auch so gestestet. Da einige jedoch über Probleme im "Feld" klagen - hier die Lösung von
"cassy"ZitatAh, da ist es ja. AN147 von Maxim: <<Guidelines for Reliable Long Line 1-Wire® Networks>>, die Bibel des 1-Wire!
Was steht da: Appendix B (auf meinem alten noch als App D) <<R-C Filter Helps DS2480B Interfaces on Short to Medium Networks>>
Genau, das war's, der RC-Filter, wie bei meinem Etherrape, nachgeschaut, C=4700 pF und R=100 Ohm!
-----
Der Rest ist Geschichte. Ich habe mir ein Interfacekabel RJ11-Stecker mit 10cm Kabel auf ein Stück Lötraster gebaut,
die drei Bauteile drauf, 1K-Pullup nach +5V, den C nach Masse und die 150 Ohm als Ausgang auf eine RJ12-Buchse gelegt.
Bei heute ausgelieferten COC ist der 1k Pullup bereits bestückt, somit müßte man nur den simplen RC Filter aufbauen.
Danke Dirk, das war genau der passende Hinweis!
Ich hab das jetzt bei mir angepasst und etwas mit den Werten jongliert.
Da ich ja eh schon direkt am DS2482 angeschlossen war, und das nicht mehr rückgängig machen wollte, hab ich die Bauteile am Level-Konverter eingebaut.
Mein Bus ist aktuell vielleicht 20m lang, da hab ich auch nicht die ganzen 4,7nF genommen, sondern etwas weniger.
Bei mir sieht das jetzt so aus:
(siehe Anhang / see attachement)
R1 ist der Pull-Up Widerstand für die 3,3V Seite und R2 der für die 5V Seite. Bei mir läuft es ab 1,3k stabil, darüber nicht! Dann werden einzelne Devices nicht mehr erkannt.
R3 und C3 sind das Filter-Netzwerk, und wenn ich die AN richtig deute, soll R3 direkt an den BusMaster.
Wenn der 1k PullUp bei dir schon bestückt ist, liegt er dann nicht auf der "falschen" Seite von R3? Mein Bauchgefühl sagt mir aber, das das nicht so viel aus macht.
VG
Ralf
...sorry! Fehler im Schaltplan! Das muss so aussehen!
(siehe Anhang / see attachement)
...ist mir jetzt total peinlich, aber das was IMMER NOCH falsch.
Vielleicht kann ein Moderator hier mal eben aufräumen? :-)
(siehe Anhang / see attachement)
Hallo zusammen,
ich denke ich habe das gleiche Problem mit meinem COC und 1-Wire. Bei kurzem Kabel werden die Sensoren erkannt, bei langem Kabel nicht mehr.
Allerdings habe ich zusätzlich noch das Problem, nicht allzuviel Ahnung von Elektronik zu haben und kann leider weder aus dem Schaltbild, noch aus der Beschreibung von cassy rauslesen, was ich denn nun tun müsste, damit auch mein COC mit längeren 1-Wire Installationen umgehen kann.
Mein COC wurde Ende letzten Novembers geliefert. Ob darauf der 1k Pullup bestückt ist, kann ich jetzt spontan allerdings auch nicht sagen.
Wie würde denn cassy's Lösung als Schaltbild aussehen?
Schöne Grüße,
Simon
Hi Simon,
ich glaube Cassy und Dirk meinen das hier:
(siehe Anhang / see attachement)
Von links kommen die Leitungen vom COC und rechts geht es zu deinen Devices.
der R4/1k ist der Pull-Up und R5/C3 ist das Filter Netzwerk.
Ich hab bei mir viel hin und her probiert und es hängt von der eigenen Topologie und Leitungslänge ab, aber diese Kombination funktioniert bei mir.
Zuvor waren mal die AD/Wandler nicht sichtbar, mal das LCD. Dann hab ich begonnen verschiedene Werte für C3 einzusetzen. Von 220pF bis rauf auf 2,2nF (=2200pF).
Hoffe das hilft dir weiter?
VG
Ralf
Hallo,
ich habe meinen COC für den RPi im Oktober gekauft und habe genau das gleiche Problem, wenn ich viele (>4) DS1820 oder eine lange Kabelstrecke habe.
Woran kann ich denn erkennen, ob mein COC schon den Strong Pull-Up hat?
Viele Grüße,
Tucka
Der Strong Pull-Up hilft dir nicht, weil er von der Firmware unterstützt werden muss. Dies ist meines Wissens nach (noch) nicht der Fall.
Bei mir läuft der 1-Wire Bus inzwischen mit relativ langer Leitung und zahlreichen Devices. Ich habe das von Dirk erwähnte und von Dallas empfohlene Anpassungsnetzwerk eingebaut, musste aber etwas hin und her probieren, bis ich die richtige Kombination hatte.
Hilft das weiter?
VG
Ralf
Danke Ralf,
also nur um es richtig zu verstehen: Du hast also auch einen RPi mit COC und hast Dir die Schaltung mit dem Kondensator + 2 Widerständen gebaut und dann läuft es?
Danke!!
Tucka
Hi Tucka, ja, genau so. Läuft fehlerfrei seit meinem Post vom 21.01.
VG
Ralf
Hi,
Ich habe bei meinem cuno v2 ahnliche Probleme..... Kann dieser fix bei mir auch funktionieren?
W
Hallo Will,
nach einem Blick in das PDFs des Schaltplanes des CUNO V2 stellt es sich für mich so dar: Auch hier ist das zusätzliche Filternetzwerk nötig, damit bei mittleren und größeren Installationen dies fehlerfrei funktioniert. Der CUNO ist zwar prinzipiell nicht mit dem COC vergleichbar, beide haben jedoch die gleiche "Kurzsichtigkeit".
Also flugs das Filter ergänzt, und auch der CUNO wird laufen.
Aber bei meinem (cassy) Entwurf sitzt der Pull-Up direkt am COC (resp. CUNO), der 150 Widerstand geht dann zur Ausgangsbuchse des 1-Wire.
( s. Bild)
cassy
(siehe Anhang / see attachement)
Hallo Cassie,
Nur mal sicherheitshalber zur Nachfrage (bin kein Elektroniker :-) )
Ich musste die komplette Schaltung im Bild hinter den cuno hängen, korrekt?
Ich Frage deshalb, weil im cuno laut schaltplan ein 100 ohm widerstand am 1w Ausgang, haengt....
Danke für kurze Bestätigung.
W
Hallo Will,
kurz: Ja! Die gesamte Schaltung (hehee, drei Bauteile)
Du hast Recht, auf dem CUNO ist bereits ein 100 Ω-Widerstand verbaut ...
... aber der "nützt" uns hier nichts, da er zusammen mit dem Kondensator der Erweiterung die Schwingung des 1-Wire-Buses dämpft. Und das kann er nur, wenn er direkt am Bus hängt, und nicht dahinter.
Chris <cassy>
Hi,
also ich wollte die Diskussion hier noch mal aufmachen, da in an meinem COC mit 1-Wire immer noch nicht ein "langes Kabel (~20m)" zum Laufen bekomme.
Ich habe mittlerweile mal auf OWserver umgestellt. Das läuft prima mit mehreren "lokalen" Sensoren, die direkt hinter dem COC hängen. Sobald ich aber das lange Kabel anschließe geht nichts mehr. Keiner der DS1820 wird erkannt.
Dann habe ich Schaltung von Dougie/Ralf gebaut. Ergebnis: Immer noch alles so wie vorher. Also keine Besserung.
Jetzt lese ich hier von einigen Usern, dass man mit dem Kondensator "rumgespielt" hat, also verschiedene Werte mal getestet hat. Könnte es daran liegen?
Also mal ehrlich, warum steht dann auf der Webseite von Busware nicht klar drauf, dass der COC nur für den "Nahbereich" gedacht ist.... ?
Danke für eure Hilfe!!!
Tucka
Also ich habe mir jetzt den USB Adapter DS9490R gekauft. Er läuft wunderbar über OWserver am RPI und vor allen Dingen mit LANGEN Kabeln !!!
Den COC kann ich also nicht empfehlen, wenn man 1-Wire wirklich "in Produktion" einsetzen will und mehr als 20m Kabel dran hängen hat....
So long---
Tucka
genau so! Wenn Du in den alten Postings zumThema COC und 1wire suchst findest Du, dass Du mit der Erkenntnis nicht allein dastehst. FS20 macht der COC aber prima und ist was günstiger als ein CUL. Dafür ist er räumlich an den RPI gebunden. Ich habe meinen COC unter Fehlinvestition abgeschrieben und nutze seine stabile 5V Buchse zur Stromversorgung meines Bastel RPI.
Hallo tucka,
hört sich gut an! Ich habe mir auch ein RPi zugelegt und einen Ds9490R#. Jetzt musste ich lesen, dass dieser Adapter über das OWX noch nicht verwaltet werden kann.
Kannst du mir bitte etwas Beispielcode für die config geben, wie man den Adapter einbindet und wie das mit dem OWserver anstatt des OWX funktioniert.
Zur Zeit habe ich auf einer FritzBox noch einen seriellen Adapter für den Onewirebus im Einsatz und das funktioniert mit OWX und OWTHERM gut.
Danke
Klaus
hallo Klaus,
wo steht, dass der DS9490 unter OWX nicht läuft? Bei mir tut er es auf jeden Fall ohne Probleme am RPI. Ich möchte behaupten, die Auseinandersetzung zwischen der OWX und der OWServer Fraktion ist eher eine Form von Glaubenskrieg als technisch relevant, d.h. es gibt oft die gleichen Schwierigkeiten egal mit welchen Modulen die 1 wire Devices angebunden sind. Ich habe seit mehreren Wochen auf zwei langen 1wire Leitungen übr OWX und o.g. Adapter, sowie einem Eigenbau keinen einzigen Ausfall mehr gehabt. Einen DS2406 habe ich ersetzt, der oft Fehler ins Log produziert hatte, seitdem gehts perfekt mit ca. 25 Devices aufgeteilt auf 2 Adapter.
super... nur wie hast du das angestellt? Wenn ich die Schnittstelle zu 1wire definiere z.B
define 1wire OWX /dev/ttyUSB0
attr 1wire buspower real
wie bei der FrizBox,
wird über autocreate kein Sensor erkannt.
Fehlt ein Treiber?
Muss eine andere Definition erfolgen?
Danke
Klaus
Hallo Klaus,
sieht bei mir auf dem RPI so aus:
define CUL_0 CUL /dev/ttyACM0@9600 1034
define TRX1 TRX /dev/ttyUSB2@38400
define 1wire_0 OWX /dev/ttyUSB1
define 1wire_1 OWX /dev/ttyUSB0
Das buspower real kannst Du weglassen, hat unangenehme Nebenwirkungen (siehe Forensuche). Wenn es keinen Sensor erkennt, kann das an der Stromversorgung liegen - schließ den Stick mal über einen aktiven USB Hub an den RPI an.
im offiziellen WIKI wird nach wie vor gesagt, das der Adapter DS9490R (noch) nicht funktioniere!?
Ich möchte nur sicher sein, dass wir den gleichen Adapter meinen - hellblau, transparent mit 8-poliger Western-Buchse und direkt von Dallas.
Verwendest du das Original-Betriebssystem von Rpi oder das von busware?
Ich habe jetzt beide Versionen ohne Erfolg bezüglich des Adapters getestet. Wahrscheinlich muss ich mir einen anderen Adapter oder gleich das COC kaufen.
Hast du noch eine andere Idee?
Gruß
Klaus
hallo Klaus,
ich habe diesen Sensor:
http://www.pcsensor.com/index.php?_a=product&product_id=33 (//www.pcsensor.com/index.php?_a=product&product_id=33)
kam recht schnell mit der Post als Einschreiben und funktioniert uneingeschränkt prima, was ich von den 1wire Eigenschaften des COC nicht behaupten möchte.
Ui, da redet ihr wohl über unterschiedliche Adapter.
Der DS9097 basiert auf einem FT232 (wie auch meiner: Link (http://forum.fhem.de/index.php?topic=10060.0)), dafür sind die Treiber vorhanden und damit wird er von FHEM, OWX usw. problemlos erkannt. Der DS9490R beruht auf dem DS2490S und das funktioniert leider nicht mit FHEM. Die treibertechnischen Hintergründe kann sicher jemand mit Fachwissen erläutern (pah...?).
offensichtlich kann man nicht genug lesen. Fatal ist auch, dass man es wahrscheinlich schon gelesen hat und nach ein paar Wochen, ist es weg.
Jedenfalls vielen Dank für die Aufklärung und den Link.
Ich hab mir gleich so ein Teil bestellt.
Den Original-Dallas-Adapter DS9490R kann ich leider noch nicht verwenden.
Gruß
also ich habe seit monaten einen DS9490R ohne probleme mit owfs und fhem am laufen. zuerst an einer synology diskstation und seit einer ganzen weile an einem rasperry pi.
gruss
andre
Hallo Andre,
kannst du mir ein paar Zeilen für die Config senden, wie z.B. der Server zum laufen kommt usw. Die Sensoren kann man ja wieder OWTHERM definieren.
Eventuell was sonst noch zu beachten ist bei dieser Variante. Muss Linux einen speziellen Treiber haben?
Besten Dank.
Gruß
Klaus
Zitatalso ich habe seit monaten einen DS9490R ohne probleme mit owfs und fhem am laufen
Da ist mir offenbar was entgangen. Mein Wissenstand ist, dass der DS9490R bisher nicht unter Linux läuft. Ich will ihn zwar nicht am Raspi benutzen, aber wissen will ich es trotzdem ;-)
es funktioniert einfach und ohne irgendwelchen besonderen tricks...
owfs installieren: sudo apt-get install owfs
in /etc/owfs.conf ein kommentar zeichen weg machen: server: usb = all
eventuell die ports anpassen und zugriff von aussen erlauben.
in fhem einfach OWServer mit ip und port anlegen.
ansonsten ist hier http://owfs.org/index.php?page=usb-ds9490r (//owfs.org/index.php?page=usb-ds9490r) ein eventuelles problem unter linux bschrieben. das trifft aber weder auf die diskstation noch den raspberry pi zu.
gruss
andre
Zitatin fhem einfach OWServer mit ip und port anlegen.
Braucht man noch nicht mal. Funktioniert mit localhost. Danke für den Tipp. Wieder schlauer...
ZitatFunktioniert mit localhost
aber nur wenn owfs und fhem auf dem gleichen rechner laufen. deshalb das eventuell...
hab ich alles gemacht
1. im Terminal sudo apt-get install owfs
2. Editiert server: usb = all
dann der Aufruf in Fhem: define DS9490R OWFS localhost:4304 DS1420
Antwort: Cannot load module OWFS
Was könnte fehlen?
Übrigens- den Server OWFS erreiche ich mit dem browser auf port 2121
Gruß Klaus
um 1-wire per owfs anzusprechen nicht OWFS sondern OWServer verwenden.
define DS9490R OWServer localhost:4304
gruss
andre
Danke für den Hinweis. Nach Eingabe zeigt sich in fhem der OWserver.
Aber ich muss doch noch den Adapter definieren!?
Wenn ich das tue mit: define DS9490R OWFS localhost:4304 DS1420
kommt die Fehlermeldung : Cannot load module OWFS
im Log steht:
2013.05.16 16:14:44 0: Can't locate OW.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/20_OWFS.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/20_OWFS.pm line 30.
Irgendwas mache ich noch falsch!?
Gruß
was meinst du mit adapter?
du brauchst OWFS nicht. du definierst ein OWServer device. darüber kommuniziert fhem mit owfs. mit get DS9490R devices kannst du dann die 1-wire devices am bus auflisten und z.b. mit define <device> OWDevice <address> dann das zugehörioge fhem device anlegen.
gruss
andre
Du definierst den Adapter:
define myOWServer OWServer localhost:4304
und meinetwegen einen Temperatursensor:
define Temp.Sensor OWDevice 10.xxxxxxx 120
Das war's schon.
Die ID des Sensors bzw. anderer Devices kriegst Du raus, in dem Du in der Kommandozeile
get myOWServer devices eingibst.
Und ich sehe gerade, dass Andre mir zuvorgekommen ist... ;-)
geht!
Vielen Dank euch beiden.
Wenn ich allerdings einen Tempsensor definiere, zeigt der keine Temperatur an sondern nur ???
Der 2 Sensor wird mit ID und Temperatur angezeigt
auch der DS9490R wird mit ID angezeigt
Ohne Definition eines Teilnehmers zeigt fhem nichts.
Ich habe das zunächst in die fhem.cfg geschrieben, weil autocreate hierbei nichts in der cfg hinterlässt.
Gruß
ich bin mir nicht ganz sicher was du genau sagen willst...
- schau mal ob das get devices alle sensoren am bus auflistet.
- schau ob du beim anlegen der einzelnen devices in fhem den timeout zum pollen mit angegeben hast (der default ist nicht zu pollen und dann gibt es keine werte)
- da autocreate scheint tatsächlich manchmal nicht zu funktionieren bei den 1-wire devices
gruss
andre
Ich hoffe mal, hier liest noch jemand weiter.
Habe einen DS9490R mit 18B20 Sensoren.
Habe es jetzt geschafft, einen Sensor in Fhem anzulegen.
Er erscheint auch (siehe Bild).
Leider ist das LogFile leer.
Somit ist eine grafische Temperaturübersicht nicht möglich bzw.
zeigt der Plot keine Temperatur-Kurve an.
Folgende Zeilen habe ich abgewandelt, von einem 18B20 der über GPIO angeschlossen war, verwendet:
define DS9490R OWServer localhost:4304
define Temp.Sensor OWDevice 28-1FF263040000
attr Temp.Sensor model DS18B20
attr Temp.Sensor room GPIO4
define FileLog_Temp.Sensor FileLog ./log/Temp.Sensor-%Y.log Temp.Sensor
attr FileLog_Temp.Sensor logtype temp4:Temp,text
attr FileLog_Temp.Sensor room GPIO4
define weblink_Temp.Sensor weblink fileplot FileLog_Temp.Sensor:temp4:CURRENT
Danach dann noch ein set interval 1 gemacht, dass der Sensor abgefragt wird (weiß nicht, ob der Wert stimmt)
Ist doch alle Minute, denke ich.
(siehe Anhang / see attachement)
Hi,
also das Intervall wird in Sekunden angegeben. Mit "1" müllst Du Dir den Log zu ;-)
Ich habe es auf mindestens 60 gesetzt.
Für den Log probiere mal folgendes aus:
define FileLog_Temp.Sensor FileLog ./log/Temp.Sensor-%Y.log Temp.Sensor:temperature:.*
attr FileLog_Temp.Sensor logtype text
Das sollte schon mal die Temperatur loggen.
Funktioniert das?
Viele Grüße,
Tucka
du solltest das intervall im define mit setzen. wenn du es nur mit set änderst ist es glaube ich nur temprär bist zu einem neustart.
gruss
andre
Also das mit dem Logfile klappt.
Das mit dem set stimmt, klappt nur temporär.
Habe einfach define <sensorname> OWDevice <sensorID> 60 eingeben
und siehe da es klappt.
Hallo cassy,
vermutlich etwas "off topic", aber ich frage trotzdem:
Ich möchte mal probehalber an meinem CUNO V2 1-wire Sensoren dranhängen, aber diesen dann so präparieren, dass ich ggf. auch längere Leitungslängen bedienen könnte.
Hier mal die Ausgangsbeschaltung von busware:
(siehe Anhang / see attachement)
Wenn ich Deine Schaltung richtig interpretiere, muss ich vor R1 einen Kondensator 4,7 nF nach Masse einlöten bzw. einen Pullup von 1 k nach 5 V (aus dem USB Stecker).
- Der Pullup dient vermutlich dazu, bei Betrieb mit nur zwei Leitungen die Spannungsversorgung (//www.maximintegrated.com/app-notes/index.mvp/id/4255) (bzw. Infos über Busmaster hier (//www.maximintegrated.com/app-notes/index.mvp/id/4206) bzw. hier (//www.fuchs-shop.com/download/AN244.pdf)) sicherzustellen?
- Brauche ich dann noch einen Pegelwandler für das 1-wire Signal (ist ja nur 3,3 V, da der DS2482 mit 3,3 V gespeist wird; ich meine, ich hätte im Beitrag weiter oben einen Pegelwandler auch für das 1-wire Signal gesehen)?
- Wenn ich die unzähigen Beiträge über 1-wire richtig gelesen habe, dient die 5 V Leitung zur Abschirmung für lange Leitungen, würden da auch die 3,3 V, die aus dem CUNO V2 Stecker kommen, auch reichen?
Danke + Gruß
PeMue
Hallo PeMue,
den CUNO habe ich nicht im Einsatz, somit kann ich hier nicht wirklich hilfreich sein.
<Hypothese Modus EIN>
Gesetzt den Fall, ich hätte einen und würde auf Probleme stoßen, könnte ich mir zwei Szenarien als Lösungsansatz vorstellen:
1.: CUNO mit 3,3 Volt und dem Filter
2.: CUNO mit Levelshifter und 5V
Zu 1.: 1-Wire mit 3,3V ist spezifiziert und funktioniert, allerdings ist der Störabstand geringer, somit bei längeren Leitungen die Gefahr der Fehlinterpretation der Signale höher. den RC-Filter (s.u.) würde ich persönlich ergänzen, der Pull-UP ist nicht nötig (beim CUNO), der bezog sich auf einen Designfehler bei den ersten COC mit Levelshifter MAX3394. Also mein erster Testansatz wäre: C=4700PF von PIN 2,3 nach Masse PIN 4, und dann den (Haus-)Bus nochmals via 100 Ohm nach PIN 2,3 ankoppeln.
Zu 2.: Levelshifter: als zweiten Lösungsansatz kann man auch den Levelshifter nachrüsten, wie in http://www.fhemwiki.de/wiki/CUNO_und_1-wire (//www.fhemwiki.de/wiki/CUNO_und_1-wire) beschrieben. Auch hier würde ich den 4700pF und 100Ohm ergänzen, der Pull-UP entfällt auch hier, ist bereits als R3 im Levelshifter vorhanden.
<Hypothese Modus AUS>
Der RC-Filter:
Diesen hatte ich schon 2008 beim etherrape im Einsatz, lange vor Raspberry und Co.
Der RC-Filter ist übrigens keine Erfindung von mir, der steht so in den AN148 von Maxim: <<Guidelines for Reliable Long Line 1-Wire® Networks>>, Seite 10 (unten), die Bibel des 1-Wire! Dieses Dokument ist zwar stellenweise zäh zu lesen, ich empfehle es jedoch allen als "Gute-Nacht-Lektüre" _BEVOR_ sie sich ins Abenteuer 1-Wire stürzen. Das fängt mit den Leitungen an, im AN148 mit CAT5-TP beschrieben, d.h. jedoch _NICHT_, dass diese Pflicht ist, die Ergebnisse in diesem Dokument beziehen sich auf diese Testanordnung! Ich benutze seit über sechs Jahren eine einfachste Verkabelung mit 4-adrigem Telefonflachkabel [sic!], keine Schirmung, kein Twisted-Pair, aber mit getrennter Leitungsführung innerhalb des Hauses, weit weg von stromführenden Leitungen. Hier muss jeder selbst entscheiden und versuchen, wie er zum Ziel kommt, your mileage may vary.
Chris <cassy>
Hallo Chris,
danke für die Infos, ich werde mir mal die AN148 anschauen.
Zitat... als zweiten Lösungsansatz kann man auch den Levelshifter nachrüsten.
So wie ich den Wiki Artikel gelesen habe, braucht man den Levelshifter nur für CUNOs <Ver. 2.4. Ich messe einfach mal die Pegel nach und berichte.
Trotzdem werde ich nicht verstehen, warum Dirk auf 3,3 V heruntergeht (wenn 5 V vorhanden sind), und danach wieder einen Levelshifter einbaut. Ich hätte den 1-wire Teil mit 5 V aufgebaut und dann wäre Ruhe (vorausgesetzt der 1-wire Busmaster "versteht" die 3,3 V Pegel vom Mikroprozessor).
Gruß PeMue
Moin,
ich steige da nicht so ganz durch. Ich habe diesen OWServer installiert und kann auch auf der Website die Werte abrufen. Allerdings springen die von 22.xx plötzlich mal auf 70 dann wieder auf 40 usw.
Ich habe den DS18S20 und über GPIO angeschlossen. Wenn ich den so abfrage über /sys/bus/w1/devices/10...... und mir das mit cat anzeigen lasse, bekomme ich immer den richtigen Wert.
Zudem will ich das Ganze über einen Nagios Check (nachher im Icinga2) abfragen. Da steht drin:
use OW;
da scheint er ein Problem mit zu haben -> ähnlich wie das, was hier beschrieben ist
Can't locate OW.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/20_OWFS.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/20_OWFS.pm line 30.
Ich weiß nicht in welchen Dateien ich was definieren muss?! Kann mir da jemand weiterhelfen?
Vielen Dank schon mal.