CUNO + 1-wire Anschlussbelegung
Benjamin
ich hatte wie viele von Euch vor einiger Zeit angefangen mich von den
Fähigkeiten des CUL/CUNO begeistern zu lassen.
Letztendlich wurde es ein CUNO V2, gerade wegen der Möglichkeiten mit
integriertem 1-wire Anschluss.
Doch gerade dieser bereitet mir schlaflose Nächte ... ;-)
Ich möchte an das 1-wire-Interface des CUNO Temperatursensoren vom Typ
DS18B20 anschließen, allerdings ist mir hier die entsprechende
Schaltung/der Anschluss alles andere als klar, obwohl ich schon seit
einigen Tagen in diversen Foren, im Mikrocontroller.net und
selbstverständlich auch hier stöbere.
Unter http://busware.de/tiki-index.php?page=CUNO steht im Abschnitt:
Onewire, wie die Anschlussbelegung des Steckers ist, jedoch sind hier
zwei Anschlüsse für OW aufgeführt, ich bin bisher davon ausgegangen,
dass ich nur ein Kabel + GND nutzen muss (parasite mode)?
Die Belegung:
3-yellow (+3.3V fused)
4-green (OW return)
5-red (OW)
6-black (GND)
Ich habe einen Sensor mit der PIN-Belegung hier:
http://ulrich-franzke.de/haustechnik/steuerung/sp1010456_2.jpg
angeschlossen und erhalte kein Signal des Sensors in FHEM.
Konfiguriert ist der CUNO nach folgendem Post:
http://groups.google.com/group/cul-fans/msg/c51921f27012a9a4 mit:
define myCUNO1_init notify myCUNO1:CONNECTED { set %NAME raw En ;; Log
1, "Notify setting %NAME initial values" ;; sleep 1.0 ;; get %NAME raw
En ;; get %NAME raw OHo ;; set %NAME raw OHt60 ;; get %NAME raw c03 }
attr myCUNO1_init comment set time from timeserver, enable 1wire w. 60
sec refresh
somit sollte OW angeschaltet sein.
Ich habe die folgenden beiden Beschaltungen ausprobiert: ohne Erfolg:
1)
CUNO RJ10 DS18B20 (Draufsicht von der Seite mit der Inschrift)
6 -- rechts (mit links verbunden: parasite mode)
5 -- Mitte
2)
CUNO RJ10 DS18B20 (Draufsicht von der Seite mit der Inschrift)
6 -- rechts (mit links verbunden: parasite mode)
4 -- Mitte
Was gibt es sonst noch zu beachten?
Danke für Eure Hilfe :-)
Fiedel
oh je, du machst ja gleich Nägel mit Köpfen...! ;o)
Das Problem kann dein "Init-Script" sein, aber auch der Umstand,
dass der Parasite- Mode in der CULFW möglicherweise gar nicht
implementiert ist.
Gehe doch mal so vor:
Fahre FHEM herunter (bzw. stecke den CUNO direkt an den PC)
und verbinde dich per Hyperterminal o.ä. mit dem CUNO.
Zuvor solltest du probehalber einen Sensor per "Normal Mode"
anschließen (Pin 4 und 5 der Buchse sind intern verbunden und
einer davon ist mit dem "Datenbein" des Sensors zu beschalten).
Dann teste mit "V" ob er erreichbar ist , sende "X21" und danach
"OHo" (muss "On" zurückliefern) und z.B. "OHt10" .
Nun warte mind. 2 Minuten und dann sollte der Sensor alle 10 Sek.
Daten senden.
Wenn das soweit klappt könntest du den CUNO wieder mit FHEM
verbinden (aber dabei nicht die Spannung abstöpseln, sonst muss
"OHo" und "OHt10" neu gesendet werden, da nicht im Flash
gehalten) und würdest per autocreate einen neuen HMS- Sensor
angelegt bekommen.
Du kannst jetzt aber auch direkt mit der "Parasite" - Beschaltung
experimentieren, da du ja nun weißt, dass der CUNO macht was
er soll.
Da muss dann auch noch irgendwie ein 4,7k Wiederstand als
Pullup rein. Ich hab das erst gar nicht probiert, da der 3- Leiter
Betrieb unkomplizierter und stabiler ist.
Auch das Script das du verwendest habe ich erst mal außen vor
gelassen: Wenn der CUNO mal spannungslos war, der Server
jedoch nicht, hilft es dir - falls aber umgekehrt, oder falls der
CUNO nicht stromlos sondern nur "disconnected" war, schaltet
es dir die HMS- Emulation sogar vorsätzlich ab, da das "OHo"
ein "toggle"- Befehl ist.
Du müsstest also auch noch das "On" oder "Off" auswerten, das
der CUNO auf "OHo" zurückmeldet...
Viel Erfolg und viele Grüße
Frank
On 24 Feb., 10:47, Benjamin <benji_b_0...@gmx.de> wrote:
> Hallo CUL-Gemeinde,
>
> ich hatte wie viele von Euch vor einiger Zeit angefangen mich von den
> Fähigkeiten des CUL/CUNO begeistern zu lassen.
>
> Letztendlich wurde es ein CUNO V2, gerade wegen der Möglichkeiten mit
> integriertem 1-wire Anschluss.
>
> Doch gerade dieser bereitet mir schlaflose Nächte ... ;-)
>
> Ich möchte an das 1-wire-Interface des CUNO Temperatursensoren vom Typ
> DS18B20 anschließen, allerdings ist mir hier die entsprechende
> Schaltung/der Anschluss alles andere als klar, obwohl ich schon seit
> einigen Tagen in diversen Foren, im Mikrocontroller.net und
> selbstverständlich auch hier stöbere.
>
Benjamin
danke für Deine ebenso ausführliche Antwort ;-)
Ich habe jetzt mal überprüft, wass Du geschrieben hattest.
Sensor per Parasite oder Normal Mode angeschlossen, beidemale mit dem
gleichen Ergebnis: Es kommen Daten an.
Aber nun der Reihe nach:
1) CUNO per USB an PC (Treiber war vom flashen schon installiert)
2) per Serieller Konsole (PuTTY) an den entsprechenden COM-Anschluss
(USB gemapped) verbunden
3) V liefert wie zu erwarten: 1.44
3,5) X21
4) OHo liefert On
5) OHt10 liefert im 10Sek. Abstand Werte: z.B. HAC2601500800FF, diese
ändern sich auch, wenn man den Sensor mit der Hand erwärmt
4) CUNO mit Netzwerk verbunden
5) FHEM angeschaut --> nichts
6) auf der seriellen Konsole erscheinen weiterhin im 10Sek-Takt Werte
Angeschlossen hatte ich den Sensor (DS18B20):
per parasite:
CUNO -- 18B20
6 -- GND (beide äußere Pins)
4 - DQ (Mitte)
per 3-wire:
CUNO -- 18B20
6 -- GND (linker Pin)
4 -- DQ (Mitte)
3 -- 3.3V (rechter Pin)
Ich hatte verstanden, dass die Sensoren mit 3 - 5.5V sauber arbeiten
(Spec-Seite von Maxim/Dallas) und das der im CUNO verwendete DS2482
bereits einen 4.7k Widerstand integriert hat
Frage:
- Wie kann ich durch den FHEM auf den CUNO zugreifen?
- was sehe ich auf der Konsole bei der Verbindung mit dem PC (HMS
Telegramme?) ?
Viele Grüße,
Ben
Olaf Droegehorn
wie hast Du denn den CUNO in FHEM eingebunden ?
Gru�,
Olaf
Am 26.02.2012 19:09, schrieb Benjamin:
> Hallo Frank,
>
> danke f�r Deine ebenso ausf�hrliche Antwort ;-)
>
> Ich habe jetzt mal �berpr�ft, wass Du geschrieben hattest.
>
> Sensor per Parasite oder Normal Mode angeschlossen, beidemale mit dem
> gleichen Ergebnis: Es kommen Daten an.
> Aber nun der Reihe nach:
> 1) CUNO per USB an PC (Treiber war vom flashen schon installiert)
> 2) per Serieller Konsole (PuTTY) an den entsprechenden COM-Anschluss
> (USB gemapped) verbunden
> 3) V liefert wie zu erwarten: 1.44
> 3,5) X21
> 4) OHo liefert On
> 5) OHt10 liefert im 10Sek. Abstand Werte: z.B. HAC2601500800FF, diese
> �ndern sich auch, wenn man den Sensor mit der Hand erw�rmt
> 4) CUNO mit Netzwerk verbunden
> 5) FHEM angeschaut --> nichts
> 6) auf der seriellen Konsole erscheinen weiterhin im 10Sek-Takt Werte
>
> Angeschlossen hatte ich den Sensor (DS18B20):
> per parasite:
> CUNO -- 18B20
> 6 -- GND (beide �u�ere Pins)
> 4 - DQ (Mitte)
>
> per 3-wire:
> CUNO -- 18B20
> 6 -- GND (linker Pin)
> 4 -- DQ (Mitte)
> 3 -- 3.3V (rechter Pin)
>
> Ich hatte verstanden, dass die Sensoren mit 3 - 5.5V sauber arbeiten
> (Spec-Seite von Maxim/Dallas) und das der im CUNO verwendete DS2482
> bereits einen 4.7k Widerstand integriert hat
>
> Frage:
> - Wie kann ich durch den FHEM auf den CUNO zugreifen?
> - was sehe ich auf der Konsole bei der Verbindung mit dem PC (HMS
> Telegramme?) ?
>
> Viele Gr��e,
> Ben
>
--
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager Tel. : +49-2244-918-4080
DHS - Computertechnik GmbH Fax. : +49-2244-918-4082
Wilhelm-Liebertz-Str. 2c E-Mail: O.Droegehorn@dhs-
computertechnik.de
D-53639 Koenigswinter WEB: www.dhs-computertechnik.de
------------------------------------------------------------------------
Benjamin
ich habe CUNO in mein Netzwerk eingehängt (Ethernet) und per DHCP-
Server eine feste IP vergeben lassen (DNSMasq auf FB 7390).
Anschließend: "define CUNO CUL 192.168.178.4:2323 <CODE>" in fhem.cfg
Miene FS20-Geräte (FHT80b und S300) sehe ich und erhalte auch Daten.
Ich habe gerade noch einmal in die Culfw-FAQ geschaut und verschiedene
Befehle getestet:
ORb --> OK:1 (1 Sensor ist angeschlossen)
Oc --> 1:4B000003A4AC2628 (ID des Sensors)
im 10Sek.-Abstand werden auf der CUNO-Konsole folgende Werte
angezeigt:
...
HAC2601270200FF
HAC2601280200FF
HAC2601280200FF
HAC2601840200FF (Steigerung nach Wärmen des Sensors per Hand)
HAC2601910200FF
...
Ich würde denken, es sind alle Teile für einen erfolgreichen Betrieb
mit fhem zusammen?
Oder Olaf, Fiedel ;-) ??
Danke für Eure Hilfe
Fiedel
alles gut so! Du konntest in FHEM nichts sehen, wenn der CUNO
noch mit der Console verbunden war. Es geht nur eine gleichzeitige
Verbindung.
In der FHEM.cfg muss das z.B. so aussehen:
# CUNO definieren
define meinCUNO CUL 192.168.1.2:2323 0000
# autocreate (sollte standardmäßig so drin sein)
define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog /var/log/fhem/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
Der CUNO muss in FHEM als "Initialized" erscheinen.
Ggf. kannst du dort in die Befehlszeile zur Kontrolle
nochmal "get meinCUNO raw OHo" eingeben.
Falls dann "Off" zurück kommt, einfach den Befehl
nochmal eingeben, sodass "On" kommt.
Dann sollte es gehen.
Viele Grüße
Frank
Benjamin
ich bin gerade erleichtert in Fhem über den Sensor "gestolpert" ;-)
HMS
HMS100T_ac26
T: 22.9 Bat: ok
er wurde automatisch angelegt.
Frage:
- Wie kann ich sichergehen, dass onewire, OHo und OHt60 beim Neustart
des CUNO/FHEM gesetzt ist? Beim in meinem ersten Beitrag zitierten
Post wurde ich von Fiedel darauf hingewiesen, dass OHo ein Toggle-
Schalter ist... ?
Benjamin
ich habe den CUNO gerade neben meinem Rechner liegen, würde ich aber
gerne wieder an seinen Platz im Keller verbauen. Beim absetzen des
Befehls "get CUNO raw OHo" kommt keine Antwort in FHEM an. ebensowenig
bei einer Änderung der Abfragezeiten mittel "get CUNO raw OHt60"
CUNO = mein Cuno
OHt aktuell 10Sek.
Habe Ihr Ideen?
Viele Grüße,
Ben
Olaf Droegehorn
das sind SET Befehle
Gru�,
Olaf
Am 26.02.2012 20:38, schrieb Benjamin:
> Hallo Frank,
>
> ich habe den CUNO gerade neben meinem Rechner liegen, w�rde ich aber
> gerne wieder an seinen Platz im Keller verbauen. Beim absetzen des
> Befehls "get CUNO raw OHo" kommt keine Antwort in FHEM an. ebensowenig
> bei einer �nderung der Abfragezeiten mittel "get CUNO raw OHt60"
>
> CUNO = mein Cuno
> OHt aktuell 10Sek.
>
> Habe Ihr Ideen?
>
Fiedel
die Antwort (auf get CUNO raw OHo) vom CUNO in FHEM bekommst du erst,
wenn er wieder in FHEM an- und in der Konsole abgemeldet ist.
Es geht wie gesagt immer nur eine gleichzeitige Verbindung.
...was Olaf meint: es muss heißen:
get ... raw OHo (weil du ja einen Wert On/Off zurück bekommst); aber
set ... raw OHt60 (weil nur etwas gesetzt wird)
Aber ich habe das auch schon öfter durcheinandergewürfelt. ;o)
Dauert eben ein bissel und kostet auch ein, zwei Nerven, bis das
alles so läuft, wie man es will.
>- Wie kann ich sichergehen, dass onewire, OHo und OHt60 beim Neustart
>des CUNO/FHEM gesetzt ist?
sodass die Befehle "im Flash landen", oder wir müssen noch etwas mehr
Perl lernen, damit wir das zurückkommende "Off" erkennen und "OHo"
noch einmal senden können. Der Rest in dem kleinen Script ist kein
Problem, da die übrigen Befehle nich diese "toggle" Eigenschaft haben.
Bei mir läuft das System seit längerer Zeit durch und ich gebe die
Befehle per Hand ein, falls ich es mal runterfahre. Habe am Anfang
auch
gedacht, ich brauche unbedingt solch ein Script, aber das läuft
mittlerweile unter "Feinschliff" und wird später in Angriff genommen -
wenn
überhaupt... ;o)
Übrigens: Lass ruhig nach der Testphase das "OHt" weg, dann kommen die
Daten (ist so eingebaut) alle 120 Sek. Das reicht aus und das Logfile
dankt
es dir.
Gute Nacht sagt
Frank
Olaf Droegehorn
in einem anderen Thread hat ein User per Notify einen Init-String f�r
CUNO gebaut, der OHo mit einschlie�t. M��t ihr mal die Suchfunktion
bem�hen, ist bereits durch die Group gelaufen.
Und ja, sobald ich mal Zeit habe, baue ich das auch in die Firmware
ein. Es kann mir aber gern einer einen Patch f�r die passenden C-Files
f�r die Firmware schicken, dann teste ich es, und checke es ein.
Gru�,
Olaf
Am 26.02.2012 23:06, schrieb Fiedel:
> Hi Ben,
>
> die Antwort (auf get CUNO raw OHo) vom CUNO in FHEM bekommst du erst,
> wenn er wieder in FHEM an- und in der Konsole abgemeldet ist.
> Es geht wie gesagt immer nur eine gleichzeitige Verbindung.
>
> ...was Olaf meint: es muss hei�en:
>
> get ... raw OHo (weil du ja einen Wert On/Off zur�ck bekommst); aber
> set ... raw OHt60 (weil nur etwas gesetzt wird)
>
> Aber ich habe das auch schon �fter durcheinandergew�rfelt. ;o)
> Dauert eben ein bissel und kostet auch ein, zwei Nerven, bis das
> alles so l�uft, wie man es will.
>
>> - Wie kann ich sichergehen, dass onewire, OHo und OHt60 beim Neustart
>> des CUNO/FHEM gesetzt ist?
>
> Das w��te ich selbst gern. M�glicherweise �ndert es Olaf in der CULFW,
> sodass die Befehle "im Flash landen", oder wir m�ssen noch etwas mehr
> Perl lernen, damit wir das zur�ckkommende "Off" erkennen und "OHo"
> noch einmal senden k�nnen. Der Rest in dem kleinen Script ist kein
> Problem, da die �brigen Befehle nich diese "toggle" Eigenschaft haben.
>
> Bei mir l�uft das System seit l�ngerer Zeit durch und ich gebe die
> Befehle per Hand ein, falls ich es mal runterfahre. Habe am Anfang
> auch
> gedacht, ich brauche unbedingt solch ein Script, aber das l�uft
> mittlerweile unter "Feinschliff" und wird sp�ter in Angriff genommen -
> wenn
> �berhaupt... ;o)
>
> �brigens: Lass ruhig nach der Testphase das "OHt" weg, dann kommen die
> Daten (ist so eingebaut) alle 120 Sek. Das reicht aus und das Logfile
> dankt
> es dir.
>
> Gute Nacht sagt
>
> Frank
>
>
>
> On 26 Feb., 20:38, Benjamin<benji_b_0...@gmx.de> wrote:
>> Hallo Frank,
>>
>> ich habe den CUNO gerade neben meinem Rechner liegen, w�rde ich aber
>> gerne wieder an seinen Platz im Keller verbauen. Beim absetzen des
>> Befehls "get CUNO raw OHo" kommt keine Antwort in FHEM an. ebensowenig
>> bei einer �nderung der Abfragezeiten mittel "get CUNO raw OHt60"
>>
>> CUNO = mein Cuno
>> OHt aktuell 10Sek.
>>
>> Habe Ihr Ideen?
>>
Fiedel
> Und ja, sobald ich mal Zeit habe, baue ich das auch in die Firmware
> ein. Es kann mir aber gern einer einen Patch f r die passenden C-Files
> f r die Firmware schicken, dann teste ich es, und checke es ein.
>
> Gru ,
> Olaf
>
wollte nicht quengeln... ;o) Nur wenn es sich mal ergibt, das ist
völlig o.k.
Programmieren kann ich leider nicht und mache hier gerade meine ersten
Erfahrungen damit. Dafür konnte ich hier bereits mehrfach
Neueinsteigern
mit meinen detaillierten Kenntnissen des OHo- Befehls helfen... ;o)
Viele Grüße
Frank
Benjamin
na dann melde ich ebenfalls mal Bedarf zur Speicherung des OHo im
Eeprom an ;-)
Ich kann leider auch nichts dazu beitragen, da meine C Kenntnisse
schon sehr betagt sind, Perl ist schon eher etwas, was ich verstehe,
aber auch nur ein klein bischen... :-)
@Olaf: bzgl. Notify: Das Script hatte ich im ersten Post bereits
verlinkt, es funktioniert aber ebenfalls nur eingeschränkt, da bei
einem "rereadcfg" oder "shutdown restart" der Status ja wieder
geändert wird (toggle) und somit OHo = off sein wird... hier fehlt wie
Frank schrieb die Abfrage wie OHo gerade steht.
Noch eine Frage: wenn ich wie oben von Euch beschrieben aus dem FHEM-
Webinterface ein "set CUNO raw OHo" (CUNO = define CUNO CUL ...)
sende, erhalte ich kein Ergebnis, wir Frank schreibt sollte da wohl
etwas zurück kommen? Eine Änderung der jeweiligen Einstellung ist auch
nicht zu sehen...?
Dank für Euren Rat ;-)
Fiedel
> Noch eine Frage: wenn ich wie oben von Euch beschrieben aus dem FHEM-
> Webinterface ein "set CUNO raw OHo" (CUNO = define CUNO CUL ...)
> sende, erhalte ich kein Ergebnis, wir Frank schreibt sollte da wohl
> etwas zurück kommen? Eine Änderung der jeweiligen Einstellung ist auch
> nicht zu sehen...?
>
> Dank für Euren Rat ;-)
direkt unter der FHEM- Befehls(Eingabe)zeile sollte dann "On" bzw.
"Off"
erscheinen. Wenn du z.B. dort eingibst:
get CUNO ccconf
dann sollte unter der Zeile erscheinen:
CUNO ccconf =>freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
Das wäre mal ein Test um zu sehen, ob die Anzeige generell klappt.
Bei mir kommt da auch manchmal erst was, wenn ich den Befehl ein
zweites Mal eingebe. Oder es kommen zuerst nur unsinnige Zeichen
und beim 2. Mal dann eine sinnvolle Antwort. Hat mich aber bisher
nicht weiter gestört, da ansonsten alles supi läuft.
Zu der Sache mit dem "Init-Script" ist mir noch was eingefallen:
Wenn man beim Init des CUNO ihm zuerst per notify ein Reset (B00)
sendet und nach erneutem Init (er bootet neu) das Script startet,
steht wegen des Reboot "OHo" immer auf Off. Dann müsste man das
nicht extra auswerten. Man müsste eben nur sicherstellen, dass
nach dem Reboot nicht erneut ein "B00" gesendet wird (Endlosschl.),
dies nach Ablauf des Scripts jedoch wieder freigegeben ist.
Oder man sendet das Script nach dem "B00" mit einer kurzen
Zeitverzögerung automatisch ab, dann fällt sogar diese Verriegelung
weg.
Werd mich bei Gelegenheit mal dran versuchen.
Aber wie gesagt - ist eher Feinschliff und hat Zeit... ;o)
Viele Grüße
Frank
Benjamin
ja, zweimal eingeben bringt tatsächlich manchmal den Erfolg ;-) Es
scheinen hier auch keine set-Befehle zu funktionieren, sondern jeweils
nur get-Befehle ... man lernt ;-)
Ich bin vorhin auch dazu übergegangen, eine feste IP direkt im Eeprom
zu speichern, da der CUNO ständig seine IP (dank DHCP) gewechselt
hatte .. :-(
Jetzt steht der Onewire-Verkabelung, ausser mangelnder Zeit, nicht
mehr im Wege.
Danke an Euch beide, Olaf und Frank, für die Unterstützung.
Eine schöne Woche wünscht,
Benjamin
Benjamin
Befehle: "get CUNO raw ...". Hier scheint es ein Problem mit dem FHEM-
Frontend zu geben. Mir ist gerade aufgefallen, dass, wenn man den
Befehl eingibt und Enter drückt die Befehle wunderbar angenommen
werden, bei Eingabe des Befehls und anschließendem Klick auf Save wird
ein falsches get übertragen:
URL: http://fritz.box:8083/fhem?cmd=save anstatt
z.B. http://fritz.box:8083/fhem?cmd=get+CUNO+raw+c03
LG
Rudolf Koenig
Oder mit der Erwartung des Benutzers. Save ist kein "go".
Benjamin
ich wollte Dir oder irgendjemandem sonst nicht zu nahe treten, Ihr
habt mit FHEM ein wunderbares Projekt aus der Taufe gehoben, dass
ebenso wunderbar funktioniert :-)
Ich hatte nur den Sachverhalt beschrieben, wenn es anders gedacht ist,
dann bin ich natürlich für jede Erklärung offen ;-)
On 29 Feb., 10:09, Rudolf Koenig <inf...@koeniglich.de> wrote:
> > Hier scheint es ein Problem mit dem FHEM-Frontend zu geben.
>
> Oder mit der Erwartung des Benutzers. Save ist kein "go".
Rudolf Koenig
War auch nicht als solches angenommen, und das was ich geschrieben habe, war
auch nicht als Beleidigung gemeint, ich habe nur Deine Formulierung
wiederverwendet.
save ist als Abkuerzung fuer "save<return>" gedacht, unlaengst haben sich viele
Leute beschwert, weil Konfig-Daten verlorengegangen sind, weil sie in der Doku
vor dem save aufgehoert haben zu lesen: Deswegen habe ich diesen Knopf eingebaut.
Auch wenn es neben der Eingabezeile steht, und in anderen Web-Formularen neben
der Eingabezeile das Go/Los Button befindet, dient beim fhem "save" einen
anderen Zweck. Vielleicht haette ich das nicht dahin packen sollen, weil ich
die Gewohnheit unterschaetzt habe.
Benjamin
Ist für mich ok ;-)
Dank Dir für die schnelle Antwort.
Eine Frage habe ich aber noch zu 1-wire:
Ich habe einen DS18B20 angeschlossen, bei Parasite Power dachte ich,
benötige ich keinen zusätzlichen Widerstand, da der DS2482 einen
integriert/in der Nähe hat. Ist dem so? Ich kann den parasite mode
nämlcih so nicht nutzen (85°)... bei Anschluss via 3-Kabel
funktioniert alles wunderbar??
Könnt Ihr mich bitte kurz aufklären
LG, Ben
Fiedel
> nämlcih so nicht nutzen (85°)... bei Anschluss via 3-Kabel
> funktioniert alles wunderbar??
die 85°C deuten auf ein Problem mit der Stromversorgung
der Sensoren hin. Jetzt hilft nur experimentieren! ;o)
Den Widerstand (zw. Datenpin und Masse) kannst du
probehalber einsetzen ohne etwas zu zerstören.
Diese Seite finde ich recht ausführlich und
informativ gemacht:
http://www.wiregate.de/1-wire-bus
Wenn es gar nicht geht, wird es vermutlich wirklich nicht
implementiert sein. Dann eignet sich Telefon- Flachband-
Kabel gut für die Sensorkette. Du kannst den Stecker
gut ancrimpen und hast genug Adern zur Verfügung.
Viel Erfolg!
Frank
Benjamin
mit 3 Kabel Verbindungen kann ich leben, war nur rein
Interessehalber ;-)
Ich hatte jetzt noch einen weiteren Sensor ( gleiche Bauart )
angeklemmt (3Pol) und bekomme nun wieder die 85° Meldungen
angezeigt...
Angeschlossen schient der Sensor richtig zu sein, Anschlussbild Stern,
da hier nicht anders zu lösen (bei bereits verlegten Leitungen),
mittels Telnet(Raw) auf den CUNO kann ich mit einem "get CUNO raw Oc"
auch beide Sensoren sehen ;-)
CUNO raw =>
1:7B000003A4ABD828
2:4B000003A4AC2628
aber in FHEM wird kein zweiter Sensor angezeigt und die Temp des
ersten liegt bei - fehlerträchtigen - 85°
Ideen aus der Community herzlich willkommen ;-)
Danke für Eure Hilfe,
Ben
Benjamin
es funktioniert, jippie ;-)
Fiedel
freue mich, dass es jetzt geht! Bin auch oft zu ungeduldig ;o)
Falls du doch noch Parasite- Erfolge haben solltest, schreib
das mal bitte hier rein! Konnte bisher nichts konkretes dazu
finden. Auch nur interessehalber.
Ansonsten weiterhin viel Spaß beim Messen, Steuern und
Regeln...! ;o)
Viele Grüße
Frank
Benjamin
Die Sensoren liefern nach eine Änderung einer Kabelteilstrecke von
Telefonleitung auf Cat 5e nur noch -0 °C als Temp.-Werte.