Originally posted by: <email address deleted>
Inzwischen liegen mir diverse Erfahrungen mit den verschiedenen
Anschlussvarianten des 1-Wire Bus vor:
- direkter USB-Anschluss bzw. USB-to-Serial Konverter mit nachgeschaltetem
Serial-to-1 Wire Konverter:
-- keine Instabilitäten, läuft astrein über Monate hinweg. Übrigens auch an
einem Raspberry Pi, wenn man dort das Problem der USB-to-Serial Konverter
richtig löst.
- Anschluss an CUNO
-- problematisch, weil bei hoher Funklast der CUNO offenbar öfter mit sich
selbst beschäftigt ist und den 1-Wire Bus mit Verzögerung bedient.
Insbesondere bei einen shutdown+restart kann der CUNO nicht schnell genug
initialisiert werden. Nach einem halben Tag hat sich das in der Regel dann
gegeben - aber ärgerlich ist es trotzdem.
- Anschluss an COC auf dem Raspberry Pi
-- problematisch, weil der COC in unregelmäßigen Abständen aus der
Kommunikation aussteigt. Zu erkennen ist das an COC-Fehlermeldungen im Log
- und die werden definitiv nicht von OWX produziert. Dabei liegt der Fehler
offenbar im Kernel des Raspberry Pi (meint übrigens auch Dirk Tostmann).
Doppelt problematisch, weil auch der Raspberry Pi in unregelmäßigen
Abständen komplett ins Nirwana verschwindet. Das kann man zwar durch einen
watchdog abfangen, der dann automatisch rebootet - das führt dann aber
dazu, dass eventuell der CUNO mal wieder beschäftigt ist etc.
Diese drei Varianten: direkt, CUNO und COC laufen derzeit bei mir
gleichzeitig auf einem RPi. Und richtig glücklich bin ich nur mit dem
direkten Anschluss...
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Zusatz (Hoffe es hilft Fehler einzugrenzen)...
Folgende Hardware Konstellation:
Betriebs-System:
FritzBox 7390 mit fhem und CUL als FS20 Interface
CUNO-1 im rfmode HomeMatic als HM Interface und 1-Wire-Bus mit 2 Temp
Sensoren und einem Switch
CUNO-2 abgesetzt in der Garage als FS20 Interface und 1-Wire-Bus mit 3 Temp
Sensoren und einem Switch
Verhalten: der CUNO-1 im rf Mode Homematic hat eine enorme Funklast, da er
11 HM-CC-TCs und 12 VDs bedienen/abfragen muss. Läuft einigermaßen stabil.
Je nach Tagesform kommt der CUNO nach einem Shutdown-Restart nicht mehr
hoch, und man muss die Sequenz fhem Shutdown - CUNO Power Cycle - fhem
start durchführen.
Interessanterweise taucht dieses Problem (bei mir) öfters auf, wenn ich
Änderungen an der fhem.cfg im web-frontend vornehme und speichere.
Der CUNO-2 in der Garage hat "nur" 3x 1-Wire Temp Sensoren & 1 Switch, und
auch wenn die Funklast in der Nacht gleich null ist, leidet der unter
regelmässigen Neustarts.
Test-System:
RPi mit CUL (FS20), COC (HM) und busware kernel, Watchdog, 1-Wire mit 1x
DS18S20
RPi nicht übertaktet
RPi mit 2,2A Netzeil (seit ich das in Verwendung habe, ist mir mein RPi
ohne 1Wire bislang nicht wieder abgestürzt)
RPi mit fhem das nur dem Betrieb-System (oben) zuhört und selber keine
Aktion auslöst.
Verhalten: häufiger Ausstieg des COC bis hin zum teilweisen einfrieren des
RPi selber, was aber seltsamerweise NICHT den Watchdog auf den Plan ruft.
Vermutung; (und ich meine eine entsprechende Bemerkung auch von Dirk
gelesen zu haben) ist, das bei Betrieb des 1-Wire Interfaces es zu
Problemen in der culfw kommt.
Möglicherweise "rettet" sich ein CUNO mit einem Reset, aber ein COC hängt
sich weg.
Wie gesagt: dies nur meine Beobachtungen, die hoffentlich dazu beitragen,
etwaige Fehler einzugrenzen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com