Originally posted by: <email address deleted>
Ich kämpfe, wie andere auch, mit dem Problem des immer noch instabilen
Raspberry Pi. Ich denke, dass eine kurze Zusammenfassung in einem neuen
Thread sinnvoll ist.
Erstens gibt es noch Ungereimtheiten bei der Hardware:
Ich betreibe einen COC mit Firmware 1.47, der COC behauptet, den
"Boot"-Befehl B nicht zu kennen - andere Forumsteilnehmer melden die
gleiche Firmware, aber einen funktionierenden B-Befehl.
Zweitens verschwndet der COC ab und zu ins Nirwana, meldet "Unknown
messages" direkt aus der Firmware. Es wäre schön, wenn der "B"-Befehl
funktionieren würde - dann könnte man den COC bei diesem Vorkommis auf
einfache Weise zurücksetzen. Derzeit keine Lösung in Sicht.
Drittens: Der Raspberry Pi hat selbst Probleme.
A:Offenbar hat der USB-Protokollstack irgendwelche Probleme. Und zwar
insbesondere dann, wenn man die neuesten Linux-Releases für den RPi
verwendet :-(( Nicht etwa, dass er dann ganz abstürzt - nein, nur das
Netzwerk stirbt. Sehr seltsame Nebenwirkung, das Problem ist aber bekannt
und wird in den entsprechenden Foren auch diskutiert. Ein workaround ist,
in die Datei /boot/cmdline.txt den Bootparameter
dwc_otg.fiq_fix_enable=0
einzufügen. Bei mir hat das jedenfalls die gelegentlichen Abstürze des
Ethernet-Interface verhindert, das läuft also stabil.
B: Mein Betriebssystem befindet sich auf einer SD-Karte, die FHEM-Logfiles
lasse ich aber auf einen Mikro-USB-Stick schreiben. Diese Trennung hat sich
bewährt, weil beim Schreiben ab und zu Dateisystemfehler entstehen. Auf
FAT-Dateisystemen lassen diese sich in der Regel nur mit Datenverlust
beheben. Zu empfehlen ist deshalb, den Mikro-USB-Stick mit einem
ext4-Filesystem zu formatieren, bevor man ihn mountet. Das sorgt dafür,
dass Fehler sehr viel sicherer und meist ohne Datenverlust behoben werden
können.
C: Natürlich muss man auf dem RPi auch den Hardware-Watchdog laufen lassen,
damit die Kiste von selbst rebootet, wenn sie ganz hängt.
Insgesamt ergibt sich damit ein zufriedenstellendes Bild: Am RPi habe ich
derzeit laufen
- COC, daran fest 2 1-Wire devices
- USB-1-Wire Interface (ca. 10 m USB-Kabel) mit derzeit 4 1-Wire devices
- USB-Seriell Interface an Fotovoltaikanlage
- CUL mit abgesetzter Antenne
- CUNO via Netzwerk, daran variabel bis zu 8 1-Wire devices.
Alle paar Tage mal ein automatischer Reboot - aber sonst bestens und ohne
Aussetzer.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 10.11.2012 um 16:14 schrieb Prof. Dr. Peter A. Henning:
> Erstens gibt es noch Ungereimtheiten bei der Hardware:
> Ich betreibe einen COC mit Firmware 1.47, der COC behauptet, den "Boot"-Befehl B nicht zu kennen - andere Forumsteilnehmer melden die gleiche Firmware, aber einen funktionierenden B-Befehl.
... diese lässt sich einfach erklären. B wurde im aktuellen HEAD Ende September entfernt, da COC per GPIO-Lines in den Bootloadermodus gebracht werden soll nicht per B - siehe Commit:
http://culfw.svn.sourceforge.net/viewvc/culfw?revision=316&view=revision
Da immer noch HEAD == 1.47 und COCs bei Auslieferung mit HEAD geflashed werden ist das unterschiedliche Verhalten möglich. Ein:
hexdump -C /sys/bus/i2c/devices/0-0050/eeprom
gibt auch den Tag des Flashens aus. Liegt das vor dem 26Nov gibt's halt noch ein "B" aber selbst das funktioniert nicht, daher wurde es entfernt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 10.11.2012 um 16:14 schrieb Prof. Dr. Peter A. Henning:
> Zweitens verschwndet der COC ab und zu ins Nirwana, meldet "Unknown messages" direkt aus der Firmware. Es wäre schön, wenn der "B"-Befehl funktionieren würde - dann könnte man den COC bei diesem Vorkommis auf einfache Weise zurücksetzen. Derzeit keine Lösung in Sicht.
Kleiner Nachtrag:
Ein Reboot des COC wird, wie auf der Wiki-Seite beschrieben, durch:
echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
erreicht. Das kann man noch Kürzen, aber so ist es am Sichersten!
Das "Unknown messages" Problem ließe sich zudem direkt in FHEM lösen, da culfw alle Nachrichten mit LF abschliesst (im Gegensatz zu FHZ-Devices) kann man einfach in einem solchen Falle bis LF den Puffer leer lesen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Gut, erledigt - der Kollege hat also nicht die aktuelle FW.
Danke
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Äh, mein Fehler, sorry. Ich habe mich ungenau ausgedrückt: Natürlich
funktioniert diese Art des Bootens, so wie schon in einem anderen Thread
beschrieben. Schöner wäre es, den COC direkt booten zu können.
Und "keine Lösung in Sicht" bezog sich nicht auf das Booten, auch das war
missverständlich ausgedrückt. Sondern auf das Verschwinden im Nirwana.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 10.11.2012 um 16:14 schrieb Prof. Dr. Peter A. Henning:
> nein, nur das Netzwerk stirbt
TuxRadios nutzen auch den LN9512 Chip für Ethernet/USB - dort hat sich das Erhöhen von:
vm.min_free_kbytes = 16384
in /etc/sysctl.conf sehr bewährt - beim RPi steht da noch die 8192 ...
Zum Anderen fände ich es beim Pi sinnvoll den Swap in eine separate Partition zu legen ...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Swap geht schon in eine separate Partition. Das mit den 16384 werd ich mal
ausprobieren - war in den ganzen RPi-Foren nirgendwo zu finden.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 10.11.2012 um 17:48 schrieb Prof. Dr. Peter A. Henning:
> Swap geht schon in eine separate Partition
Aber nicht per Default, da wird dphys-swapfile verwendet, der im eigentlichen Root-fs liegt ... => /var/swap
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Das ist sicher richtig, aber ich habe es auf eine separate Partition gelegt.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo die Herren,
schön zu lesen, dass die Fehlersuche auf dem Weg zu einem stabilen RasPi mit COC und vieleicht auch letztendlich einer funktionierenden 1-wire Funktion des COC voll im Gange ist.
Mein RasPi lief im fhem2fhem Modus und alle FS20, FHT und KS300 Sachen mitloggend zuletzt 7 Tage ohne reboot, mit einem DS1820 am COC - bis ich den DS1820 testweise durch einen DS2406 ersetzt habe - mit Aktualisierungszeit von 10 anstatt 300. Das ging vieleicht 2-3 h gut, dann ging 1-wire PRESENT 0 und FS20 Geräte ließen sich über Webinterface FHEM auf RasPi auch nicht mehr schalten.
Zu den Tips oben im Post - über die Änderung der swap Einstellung liest man im Netz nichts wirkich Gutes - z.B. hier: http://raspberrypi.stackexchange.com/questions/70/how-to-set-up-swap-space
Was ist davon zu halten - bzw. gibt es eine Empfehlung (Hardware Swap Speichermedium und Kurzanleitung)?
Die anderen Sachen werde ich jetzt mal umsetzen und weitertesten.
lg det.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nur 10 Sekunden Abfrageintervall setzen den COC echt unter Stress - und den
mag er offenbar nicht.
Für mich stellt sich allmählich die Frage, ob der Prozessor auf dem COC
nicht etwas überfordert ist. Auch beim CUNO klappt es noch nicht sehr gut
mit vielen 1-Wire Devices und schnellen Abfragen. Es macht wahrscheinlich
Sinn, eine reine 1-Wire Erweiterung für den RPi zu entwickeln, oder den
1-Wire Anschluss über den USB-Port des RPi zu verwirklichen.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Genau das war ja auch der Stresstest, nach dem das Ding so lange durchgehalten hatte... Das Device aus DS2406 und Sharp SSR werkelt inzwischen auf dem Boden und steuert die Warmwasserumwälzpumpe anstelle eines FS20 Funkschalters, der 2te Kanal überwacht den Druck im Heizkreislauf. Das alles funktioniert mit OWX absolut stabil, nur eben nicht auf dem RasPi.
Die Teile für den 2ten USB 1-wire Adapter mit DS2480 sind auf dem Weg mit Hongkong Post. Wenn der zusammengelötet ist, geht der Stresstest für den RasPi in eine neue Runde. Schauen wir mal...
lg det.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich habe die Teile für einen weiteren USB-Adapter schon, muss aber noch die
Zeit finden ...
Meine diversen Teile am USB des Raspberry Pi hängen übrigens inzwischen an
drei Hubs - ohne Probleme.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Mal so, ne dumme Frage:
Der Adapter für 1-Wire sitzt doch beim COC auf dem konkurierenden I2C von
der RasPi, ist vielleicht der I2C ein Problem?
Ich habe ja schon öfters mit 1-wire gebastelt und bin bisher nicht in diese
Art von Probleme geraten, deshalb habe ich mich gefragt was hier anders ist
als bei meinen anderen "Projekten".
Ich hatte bisher WRT54 mit passiven Adapter zu 1-wire, lief mit vielen
DS1820 problemlos.
Hatte Arduino mit 1-wire, dort gabs hin und wieder hänger weil im Treiber
nicht lange genug auf die Antwort gewartet wurde --> festgehen der
Applikation auf Arduino, bei WD neustart (sieht ähnlich aus beim COC)
Etherape mit ECMD, bisher keine Probleme beim 1-wire, nur beim
ECMD-Protokoll ständig irgendwelche hänger.
Deshalb war ich ja glücklich das jemand 1-wire mit CUNO/COC nativ umgesetzt
hat.
Vielleicht findet ja jemand Zeit und guckt in die CULFW-Quellen der mehr
als ich davon versteht.
Weiter könnte ein Umbau des COC und nutzung des UART1 zum 1-wire Adapter am
1284p vielleicht was nutzen, da ist man weg vom I2C...
Nur malk so ein paar Gedanken von mir...
Gruß
VT
Am Montag, 12. November 2012 07:53:54 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> Ich habe die Teile für einen weiteren USB-Adapter schon, muss aber noch
> die Zeit finden ...
>
> Meine diversen Teile am USB des Raspberry Pi hängen übrigens inzwischen an
> drei Hubs - ohne Probleme.
>
> LG
>
> pah
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
I have 8 DS18B20 one-wire and 10 FHT80B on my COC
Everything works well for about three hours and then a reset and reboot is
required (using set COC raw B00 which works on my COC - revision 316?) It
does look from the logs as if it is the one-wire devices that are causing
the problems. My next step is to replace the PSU with a VERY expensive 5v
PSU (cheap on eBay ! ) to see if that helps. After that I will try
disconnecting the one-wire bus to see how that works.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 12.11.2012 um 08:07 schrieb V T:
> Der Adapter für 1-Wire sitzt doch beim COC auf dem konkurierenden I2C von der RasPi, ist vielleicht der I2C ein Problem?
Ich versteh' eigentlich auch garnicht, wieso der Raspberry-Linux-User "culfw" auf dem COC als 1wire Schnittstelle verwendet obwohl es stabile Treiber unter Linux gibt die den i2c 1-wire Controller direkt treiben können?
Meines Wissens war die 1-wire Implementierung ursprünglich für Emulation von Temp.-Sensor -> HMS Device gedacht und nicht als Gateway!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 12.11.2012 um 12,39 schrieb DT:
>Ich versteh' eigentlich auch garnicht, wieso der Raspberry-Linux-User "culfw" auf dem COC als 1wire Schnittstelle verwendet >obwohl es stabile Treiber unter Linux gibt die den i2c 1-wire Controller direkt treiben können?
>Meines Wissens war die 1-wire Implementierung ursprünglich für Emulation von Temp.-Sensor -> HMS Device gedacht und nicht als >Gateway!
Ich schrieb dazu am 26.10. in einem früheren Post zu der Problematik:
@pah
"Da Deine Module hier schon länger "am Markt" sind wie der COC und hervorragend funktionieren - (klar, dass es bei Open Source immer Anpassungen und auch mal unstabile Zustände gibt, das macht die Sache ja auch so spannend) - kann man als Kunde doch davon ausgehen, das der Hersteller des COC einen Plan hat, was die Kunden mit so einem Teil anstellen wollen, wenn sie es gekauft haben."
Als Verkäufern würde man sagen - am Markt vorbei entwickelt, oder nicht vorher recherchiert, was der Kunde eigentlich für Anforderungen hat.
Wenn das der letzte Stand bleibt, dann nehme ich schon mal Gebote für meinen COC an, denn 1-Wire leistet wesentlich mehr als ein paar billige Temp.-Sensoren abzufragen!
lg det.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Tja, da bin ich nun überfragt...
Alleine heute an Reboots gehabt, die durch den Watchdog ausgelöst wurden
2012.11.12 08:17:28 1: Including /etc/fhem.cfg
2012.11.12 13:17:35 1: Including /etc/fhem.cfg
2012.11.12 14:17:31 1: Including /etc/fhem.cfg
Wobei mir dabei auffällt, dass dies immer um 17 Minuten nach der vollen
Stunde passiert. Hm...........
Gestern auch.
Der COC enthält doch eine ECHTZEITUHR für den RPi. Die sollte man sich mal
genauer ansehen, vielleicht steckt der Wurm ja da drinnen ?
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Moin,
es scheint, dass die Gemüter hier ein wenig erhitzt sind.
Ich habe das Gefühl, dass der RPi an sich nicht stabil läuft und die
Ursache der Abstürze ist.
Mein RPi hat heute morgen nun endlich den Geist aufgegeben und auf der
Unterseite der Platine direkt unter dem Prozesser sieht der Lötstop-Lack
wegen Überhitzung unschön aus. Genau da sind auch eine Menge
SMD-Kondensatoren und Widerstände angebracht.
Leider komme ich selbst nicht dazu und ich habe auch kein großes Arsenal an
1wire, aber eine Überlegung wäre den COC über die Buchsenleiste mittels
eines RS232/USB-Umsetzers an ein PC anzuhängen (ohne RPi) und von dort die
Stabilitätstests analog durchzuführen.
Der COC ist sehr hochwertig produziert und die Schaltung is sehr einfach.
Und FS20/868MHz verarbeitet es sehr zuverlässig.
vg
Maz
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
HI all,
das Problem liegt weder am RPi noch an seiner Firmware. Die Firmware, die
dort läuft, wurde für den CUNO entwickelt, das stimmt, und ursprünglich war
eine HMS-emulation angedacht, welche auch implementiert wurde.
Um mal eben mit einem FALSCHEN Gerücht aufzuräumen, was einige immer wieder
anführen: dies hat NICHTS mit HOMEMATIC zu tun. Wer das behauptet hat
einfach die Specs nicht gelesen und keine Ahnung.
Nichts desto trotz funktioniert auch eine direkte Ansteuerung des OneWire
Busses über den Befehlssatz der Firmware, man muß nur die Befehle auch
korrekt auslesen und die Daten abholen. Ein 10 Sek. Intervall ist überhaupt
kein Problem, sofern man die Daten korrekt verarbeitet. Die Firmware und
der RPi können das ohne Probleme. Nur leider die Module nicht, die die
Daten abholen.
Wer sich also die Mühe macht, und ein Modul schreibt (z.B. für FHEM),
welches die Daten dann auch korrekt abholt und auf die Timings achtet, die
die Schnittstelle hat, der wird auch keine Probleme damit haben.
Zu den Aussagen, dass die Firmware NUR 10 1-Wire Devices unterstützt:
Dies gilt NUR für die HMS Emulation, sofern man die Firmware-eigenen
Routinen zum Auffinden von 1-Wire Devices nutzt. Das kann man ändern, wenn
man mag, indem man die Firmware ändert. In den DEFS wurde definiert,
wieviel Speicherplatz für 1-Wire Adressen vorgehalten wird. Da die Firmware
auf dem dem CUNO/COC läuft, steht dort einfach nicht unendlich Platz zur
Verfügung. Daher erst einmal die 10 Devices.
Wer aber meint, dass dies alles wäre, was das 1-Wire Interface dort kann,
irrt. Diejenigen haben einfach nur nicht genug Erfahrung oder Lust eine
eigene 1-Wire Suche zu implementieren. Denn diese könnte dann beliebeig
viele Devices finden, sofern die Daten außerhalb der Firmware gespeichert
werden.
Die Beschränkung ist also außerhalb der Firmware, denn alle notwendigen
Befehle um den 1-Wire Buis anzusteuern sind vorhanden. Alles andere sind
Probleme von Modulen, die entweder mangehaft ode rmit falschem Timing auf
die 1-Wire Befehle der Firmware zugreifen.
Soviel aus meinen Erfahrungen dazu. Habe nämlich den Firmware-Teil zu
1-Wire für CUNO realisiert.
Gruß,
Olaf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Na, da macht es sich aber jemand sehr einfach...
Zum RPi: Es ist unbestreitbar, dass dieser sich in unregelmäßigen Abständen
ins Nirwana verabschiedet. Das pfeifen auch die Spatzen von den Dächern,
wenn man die entsprechenden Foren liest ...
Ein solcher Totalabsturz kann in einem Linux-System aber durch die
Ausführung einer Hochsprache (wie Perl) nur dann erzeugt werden, wenn die
Kernelmodule Fehler aufweisen.
Zum CUNO/COC Timing: Möglicherweise habe ich ja eine wichtige und überall
verfügbare Dokumentation übersehen, die etwas zum Timing der Ansteuerung
aussagt. Etwa "rühre das Interface für x Millisekunden nicht mehr an, wenn
es eine Antwort gegeben hat". Möglicherweise ist mir auch vollkommen
unklar, was der Satz
"B - Read one
BYTE from the OneWire Bus; Return: :dd Hex-Value of Data "
in der culfw-commandref bedeutet und wo dort das Timing besprochen wird.
Diese beiden Möglichkeiten halte ich aber für vernachlässigbar
unwahrscheinlich - bleibt also nur der Schluss, dass dieses angebliche
"Timing der Schnittstelle" entweder nicht existiert oder nicht ordentlich
dokumentiert wurde.
Zum CUNO/COC Zugriff: Von einem "mangelhafter Zugriff" könnte man sicher
sprechen, wenn der Zugriff unter reproduzierbaren Bedingungen Fehler in den
abgefragten Daten produziert. Die Fehlermeldung lautet aber
"COC: unknown message"
und nicht etwa "Der Read-Befehl hat irgendwelche Daten nicht abgeholt". Und
diese Meldung stammt nicht aus den OWX-Modulen...
Versuchen wir doch einmal, konstruktiv zu sein. Es sollte ohne große
Probleme möglich sein, der culfw-Software beizubringen, nicht nur jeweils
EIN BYTE zu lesen und zu schreiben. Sondern die Anzahl der zu lesenden
Bytes als Parameter zu nehmen, und die Anzahl der zu sendenden Bytes aus
der Länge des übergebenen Strings zu holen. Das würde den Zugriff auf den
1-Wire Bus in CUNO und COC sehr stark vereinfachen und deren Prozessor
entlasten.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Zum RPi: Es ist unbestreitbar, dass dieser sich in unregelmäßigen Abständen
> ins Nirwana verabschiedet. Das pfeifen auch die Spatzen von den Dächern,
> wenn man die entsprechenden Foren liest ...
Das stimmt so generell nicht: ich habe Zugriff auf zwei RPi's mit fhem (eins
mit CUL ueber ETH0, eins mit COC ueber WLAN), und beide laufen ohne Probleme
seit 27 bzw. 17 Tagen. Das allerdings erst, nachdem ich die Taktraten-
Spielereien wieder ausgebaut habe, davor hatte ich alle ein- bis zwei Tage
einen Haenger.
Onewire verwende ich nicht.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nun ja, Taktratenspielereien verwende ich sowieso nicht.
Und vielleicht solltest Du mal etwas an den USB-Port hängen und mit FHEM
kommunizieren lassen - das wirkt hier Wunder...
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Und vielleicht solltest Du mal etwas an den USB-Port hängen und mit FHEM
> kommunizieren lassen - das wirkt hier Wunder...
Bin ich damit gemeint? Und was ist mit "Wunder" gemeint?
Wie gesagt, einer der RPis arbeitet mit CUL (== USB), das andere mit COC, und
ist ueber ein USB WLAN Modul angebunden. Also bei beiden ist USB aktiv, und
Wunder gibts keine.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
ich bin ja bekannt für Dumme Fragen.
Kann man die Schnittstelle des COC auf 19200 setzen?
Compilieren und so kriege ich schon hin, wobei bei der neuen avr-gcc lib
bekommt man ja Probleme mit dem PROGMEM Deklarationen.
Diese müßten in der culfw vielleicht mal geradegezogen werden...any way
Bekomme ich bei der obigen Aktion Probleme mit dem Bootloader, der ja
weiter auf 38400 läuft?
Oder muß ich einfach nur darauf achten das Bootloader 38400 und "FHEM" dann
auf 19200 läuft?
Dann hätte ich noch eine Frage zur Hardware des COC:
Warum ist der Levelshifter hinter dem DS2482 eingebaut? Und nicht davor im
I2C Bus?
So als Laie hätte ich den Levelshifter in den I2C unmittelbar vor dem
DS2482 eingebaut, den DS2482 auf 5V gesetzt und den Transistor für Strong
Pullup direkt an den DS gebunden.
Aber dafür gibts sicher Gründe, aber so als Neugieriger lerne ich gern dazu
und wollte eben fragen warum?
Mist, das sollte ich ja wieder in culfans fragen...
Also Gruß
VT
Am Dienstag, 13. November 2012 12:55:08 UTC+1 schrieb Rudolf Koenig:
>
> > Und vielleicht solltest Du mal etwas an den USB-Port h�ngen und mit
> FHEM
> > kommunizieren lassen - das wirkt hier Wunder...
>
> Bin ich damit gemeint? Und was ist mit "Wunder" gemeint?
>
> Wie gesagt, einer der RPis arbeitet mit CUL (== USB), das andere mit COC,
> und
> ist ueber ein USB WLAN Modul angebunden. Also bei beiden ist USB aktiv,
> und
> Wunder gibts keine.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Das mit RPi-Stabilität ist schon eine seltsame Sache. Ich bin absolut
überrascht, so etwas auf einem Debian basierten System zu sehen. Meine
Sheevaplug sowie mein QNAP laufen seit Jahren ohne irgendwelche Abstürze,
owbohl da auch CULs sowie weitere USB-Geräte angeschlossen sind.
Ein Kollege von mir hat bei seinem RPi massive Stabilitätsprobleme mit dem
Ethernet bei einem über USB angeschlossenen CULv2. Seine derzeitige Lösung
ist den RPi automatisch zu rebooten, wenn das Problem auftaucht. Das
cshient bei RPi-Usern zum Standard zu werden.....
Ich habe dagegen zwei RPis (256MB und 512MB-Version) mit unterschiedlichen
USB-Geräten (USB-WDE1 mit cp210x-Treiber, sowie ein weiteres USB-Gerät
mit cdc_acm-Treiber) seit Wochen ohne Stabilitätsprobleme im
Einsatz. Seltsamerweise hat der Kollege denselben Linux-Kernel.
Um auszuprobieren, ob es am Einsatz von CULv2 mit FHEM liegt, habe ich vor
1,5 Tagen auf dem einem RPi einen CULv2 sowie FHEM konfiguriert. Bisher
auch ohne Abstürze. Ob mein RPi kaputt ist, weil er nicht ordnungsgemäß
abstürzt? ;-)
Man stellt ja die seltsamsten Vermutungen an, warum das so ist. Meine
neueste abwegige Theorie ist, dass es am Ethernet liegt (Ethernet-Switch
oder bestimmte Ethernet-Pakete im Netz).
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ach ja: COC haben weder mein Kollege noch ich im Einsatz.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die Stromversorgung des rpi ist auch ein maßgeblicher StabilitätFaktor
gerade mit Ethernet und USB devices
Von meinem Xperia™-Smartphone gesendet
Am 13.11.2012 15:14 schrieb "Willi" :
> Ach ja: COC haben weder mein Kollege noch ich im Einsatz.
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo
ich reihe mich mal ein...
RasPi (256) bisher keinen Absturz seit ca. 30Tagen
COC sporadisch mehrere Male pro Tag Absturz und solche Meldungen:
2012.11.13 07:52:38.545 3: COC01: Possible commands: mCFAZOGMRTVWXefltux
2012.11.13 07:52:38.388 1: /dev/ttyAMA0 reappeared (COC01)
2012.11.13 07:52:27.586 1: /dev/ttyAMA0 disconnected, waiting to reappear
2012.11.13 07:52:26.563 1: OWX: CUNO/COC device COC01 defined
2012.11.13 07:52:26.361 3: COC01: Possible commands: mCFAZOGMRTVWXefltux
2012.11.13 07:52:26.206 3: COC01 device opened
2012.11.13 07:52:26.195 3: Setting COC01 baudrate to 38400
2012.11.13 07:52:25.894 3: Opening COC01 device /dev/ttyAMA0
Gruß
VT
Am Dienstag, 13. November 2012 16:14:45 UTC+1 schrieb drdownload:
>
> Die Stromversorgung des rpi ist auch ein maßgeblicher StabilitätFaktor
> gerade mit Ethernet und USB devices
>
> Von meinem Xperia™-Smartphone gesendet
> Am 13.11.2012 15:14 schrieb "Willi"
> >:
>
>> Ach ja: COC haben weder mein Kollege noch ich im Einsatz.
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Schön zu sehen, dass bei vielen der RPi mit dem COC funktioniert. Wie Rudi
sagte, das ist kein generelles Problem.
Was FHEM und OneWire angeht sind die Probleme mit dem OWX-Modul bekannt,
und von den Hardware/Firmware Entwicklern hinreichend kommuniziert worden.
Denn, wir Entwickler unterhalten uns ja auch untereinander.
Wenn dann nicht darauf gehört wird ist das schade.
Wenn dann auch nicht gelesen wird, wie bei FHEM-Devices wie CUNO/COC Daten
korrekt als Antwort abgeholt werden, ohne in Sync-Probleme zu laufen ist
das ebenfalls schade.
Dann auch noch zu behaupten, dass es sich die Anderen einfach machen ist
grotesk.
Der Code entspricht nicht den einfachsten Richtlinien für synchronisierte
Antworten, wie man sie in Modulen wie FHT oder CUL_IR nachlesen könnte.
Dann allerdings den Eindruck zu erwecken das Problem läge im COC oder
genereller im RPi ist bedauerlich, denn damit wird eine hervorragend
arbeitende Hardware zu unrecht verurteilt, nur weil schlechter OpenSource
Code einfach unpassend programmiert wurde.
Hoffe unsere User verlieren nicht den Mut durch derart schlechte Propaganda.
Olaf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Immer wieder erstaunlich, wie wenig die einfache Logik selbst in
akademischen Kreisen verbreitet ist. Selbstverständlich ist es ein
generelles Problem, wenn ein erklecklicher Anteil der RPi-Benutzer häufige
Reboots erlebt. Darüber klagen nämlich auch RPi-Benutzer in den
einschlägigen Foren, die FHEM überhaupt nicht kennen.
"Wir Entwickler unterhalten uns ja auch untereinander" als hinreichende
Kommunikation zu bezeichnen, ist allerdings eher witzig - ebenso, wie dass
man Richtlinien in Modulen nachlesen könne. Muss irgendwie mit der eher
einsamen Umgebung zusammenhängen.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Olaf,
ich wollte mich gerade mal weiterbilden und habe die Module 11_FHT.pm und
10_CUL_IR.pm geöffnet um mal zu verstehen worüber Ihr beiden Streithähne da
herumkaspert.
;o) Sorry der Ausdruck mußte mal sein, könntet Ihr Euren Frust mal ins Klo
schütten, das bringt hier keinen weiter...
Wie gesagt ich wollte mal gucken wie mann es richtig macht...aber Olaf, ich
finde beim besten Willen keine Beschreibungen oder erschöpfende Kommentare
im Quellcode die mir das als Softwareentwickler irgendwie nahebringen.
Kannst Du mal genau sagen, wo ich ein Programmierbeispiel/Template oder
ähnliches im Wiki oder auch in den benannten Codes finden kann?
Vielleicht gibts auch ein Diagramm oder Ablaufplan der das einfach mal
graphisch veranschaulicht?
Denn es ist doch von Vorteil wenn man viele der User auch als "wissende"
Tester mit einbeziehen kann.
Ich bin wirklich interessiert daran hier mal dahinter zu steigen.
Danke
VT
Am Dienstag, 13. November 2012 22:53:10 UTC+1 schrieb Olaf:
>
> Schön zu sehen, dass bei vielen der RPi mit dem COC funktioniert. Wie Rudi
> sagte, das ist kein generelles Problem.
>
> Was FHEM und OneWire angeht sind die Probleme mit dem OWX-Modul bekannt,
> und von den Hardware/Firmware Entwicklern hinreichend kommuniziert worden.
> Denn, wir Entwickler unterhalten uns ja auch untereinander.
> Wenn dann nicht darauf gehört wird ist das schade.
> Wenn dann auch nicht gelesen wird, wie bei FHEM-Devices wie CUNO/COC Daten
> korrekt als Antwort abgeholt werden, ohne in Sync-Probleme zu laufen ist
> das ebenfalls schade.
> Dann auch noch zu behaupten, dass es sich die Anderen einfach machen ist
> grotesk.
> Der Code entspricht nicht den einfachsten Richtlinien für synchronisierte
> Antworten, wie man sie in Modulen wie FHT oder CUL_IR nachlesen könnte.
>
> Dann allerdings den Eindruck zu erwecken das Problem läge im COC oder
> genereller im RPi ist bedauerlich, denn damit wird eine hervorragend
> arbeitende Hardware zu unrecht verurteilt, nur weil schlechter OpenSource
> Code einfach unpassend programmiert wurde.
>
> Hoffe unsere User verlieren nicht den Mut durch derart schlechte
> Propaganda.
>
> Olaf
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
VT ... der Begriff Streithähne ist hier nicht das worum es geht, sondern um
den Begriff "Propaganda".
Ein solches Forum ist ein wertvoller Informationspool VOR ALLEM für
Einsteiger. Der Eindruck, der durch eine Einzelperson oft geweckt wird,
schreckt viele ab hier konstruktiv mitzuarbeiten, und schickt diejenigen
dies dennoch tun oft in eine flasche Richtung.
Wenn diese Person dann auch noch behauptet in der Erwachsenenbildung tätig
zu sein, dann bin ich an der Grenze meiner Glaubwürdigkeit angekommen. Ich
zweifle inzwischen sowohl Titel und Grad, und vor allem die hier als
"Eigene Leistung" vorgestellte Arbeit an.
Und wenn jemand seinen Prof.Dr. Hasse-Nich-Gesehn Schiess-Mich-Tot völlig
schamlos (auch) unter jedes fremde fitzelchen Papier setzt, um den Eindruck
zu erwecken, es sei seinem Geist entsprungen, der ruft einfach ab und an
derartige Kommentare auf den Plan. Sehr zu recht, wie ich finde. Besonders,
weil in diesem Zusammenhang die eigene Unfehlbarkeit und Kritik-Unfähigkeit
immer in den Vordergrund gestellt wird.
Vor Wochen hatte ich schon die Probleme mit OWX und RPi/COC erwähnt, da
hiess es aus dem gleichen Munde "Bei mir läuft alles fehlerlos". Heute
scheint die Meinung eine andere zu sein.
Hardware-Interface aus Philips Application Notes werden mal eben kopiert
und mit eigenem Namen versehen ins WiKi gestellt.
...ich will's kurz machen: die OWX Familie hat sicher Potential, aber die
ART des Maintainers finde ich persönlich zum k.
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi all,
es geht um die Frage, wie man eine Antwort vom CUL/CUNO/COC abruft, die
eben nicht in bestimmten Timings sicher ankommt.
Und wie Dirk bereits hier öffentlich im Forum geschrieben hat, ist es NICHT
die Lösung einfach mal ein Read-Kommando auf das Device abzusetzen in der
Hoffnung, dass schon alle Daten vorhanden sind. Das hat nichts mit
gescheitem Umgang von asynchron zueinander laufenden Prozessen zu tun.
Eine Möglichkeit, wie sie halt in FHT und CUL_IR genutzt wird ist folgendes
Konstrukt:
my $msg = CallFn($io->{NAME}, "GetFn", $io, (" ", "raw",
"..".$reccommand));
Alternativ könnte man bis zum LF lesen, so wie Dirk es vorgeschlagen hat.
Ist ja nicht so, als wären nicht genug Informationen dazu geflossen. Werden
halt nur ignoriert.
Und wer das Wiki lesen kann weiß, dass diese Dinge eben noch zu
dokumentieren sind. Aber eine höfliche Nachfrage bei Entwicklern, die sowas
schonmal gemacht haben, hätte ja Erleuchtung bringen können. Aber damit
wären wir beim Thema Unehlbarkeit ..... schwierig schwierig ;)
Gruß
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Äh Hallo,
Oben sagst Du:
Wenn dann auch nicht gelesen wird, wie bei FHEM-Devices wie CUNO/COC Daten
korrekt als Antwort abgeholt werden, ohne in Sync-Probleme zu laufen ist
das ebenfalls schade.
...
Der Code entspricht nicht den einfachsten Richtlinien für synchronisierte
Antworten, wie man sie in Modulen wie FHT oder CUL_IR nachlesen könnte.
Jetzt sagst Du:
Und wer das Wiki lesen kann weiß, dass diese Dinge eben noch zu
dokumentieren sind. Aber eine höfliche Nachfrage bei Entwicklern, die sowas
schonmal gemacht haben, hätte ja Erleuchtung bringen können.
Ich wollte doch nur mal einen Überblick über so ein Modul, was gehört immer
rein, was ist optional. Wie sieht ein bis oben hin vollständiges Modul aus.
Wie ist die Standardroutine zum Einfangen von Telegrammen. u.s.w.
Weiter sagst Du es gibt eine Richtlinie für synchronisierte Antworten, wo
kann ich die finden?
Ich habe zwar danach gegoo... äh nachgeschlagen, aber da kam nichts
brauchbaren bei heraus.
Das ist auch die Frage die ich stelle, kann man so was irgendwo nachlesen
(nein sagst Du jetzt, gibts im Wiki noch nicht),
dann frage ich Dich ganz höflich, ob Du mir so etwas zukommen lassen kannst?
Geht das?
Gruß
VT
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich lese und wundere mich. Nicht über den kleinen Bastelheimer, der den
Zusammenhang zwischen Urheberrecht und Wikipedia nicht kennt - den kann man
nur ignorieren.
Sondern über die hoch aufgebauschte Behauptung von Olaf Droegehorn, alles
sei klar und genügend Informationen seien geflossen, würden aber ignoriert.
Die dann doch in den eher kleinlauten Rohrkrepierer mündet "Muss halt noch
dokumentiert werden". Tolle Art, ein Open Source Projekt gegen die Wand zu
fahren.
Zur Klarstellung: Die OWX-Module wurden geschrieben, um eine direkte
Kommunikation mit dem 1-Wire Bus über eine serielle Schnittstelle (und
damit synchron !) durchzuführen. Und das läuft, basta. Das Ansprechen von
CUNO und COC wurde nachträglich eingeschoben und funktioniert so leidlich.
Stabil bei schnellem FHEM-Rechner und wenigen Devices am CUNO - aber
instabil auf dem RPi und bei hoher Last auf dem CUNO. Klar gibt es
Möglichkeiten, das zu ändern - darum ist es ja freie Software, und jeder
kann sich daran wagen.
Mein Interesse, hier für andere etwas zu arbeiten, nimmt jedenfalls rapide
ab.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich lese und staune. An einen akademischen Diskurs erinnert mich das
allerdings nicht.
Wer macht jetzt den Anfang und sagt völlig uneitel 'Schwamm drüber'?
Diese (von allen Seiten) vorgetragenen Animositäten tun dem Projekt fhem
jedenfalls nicht gut, es sei denn man schätzt den Unterhaltungswert des
Schlagabtausches.
Am Mittwoch, 14. November 2012 16:24:39 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> Ich lese und wundere mich. Nicht über den kleinen Bastelheimer, der den
> Zusammenhang zwischen Urheberrecht und Wikipedia nicht kennt - den kann man
> nur ignorieren.
>
>
> Mein Interesse, hier für andere etwas zu arbeiten, nimmt jedenfalls rapide
> ab.
>
Ich fände es schade, wenn das Deine Aktivitäten erschränken würde. Ich habe
schon viel davon profitiert.
Jorge
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich denke, hier muss von beiden Seiten etwas getan werden.
Einen *Wunsch* an die Firmware von CUNO/COC habe ich bereits spezifiziert:
Es wäre schön, wenn man mehrere Bytes mit einem Kommando senden bzw.
empfangen könnte. Das würde den Overhead von CUNO und COC m.E. dramatisch
reduzieren.
Mir ist umgekehrt sehr klar, wie viele Baustellen meine Module noch haben:
Ein Abfangen der verzögerten Datenlieferung durch CUNO/COC brauche ich
selbst am Dringendsten. Außerdem ist in den wenigsten Modulen bisher ein
Abfangen falscher Readings durch die Kontrolle des CRC implementiert.
Außerdem musst der event-on-update-Mechanismus angepasst werden. Außerdem
muss die Alarmfunktionalität überarbeitet werden. Außerdem müsste die
OWFS-Anbindung in die Module eingebaut werden. Außerdem muss eine
Ankopplung an Adapter ermöglicht werden, die über die libusb angebunden
werden, und, und und...
Mein Fokus lag im vergangenen Halbjahr aber auf der Erweiterung um neue
1-Wire Sensoren und Aktoren, und das war ja auch sehr erfolgreich :-)
Ich habe aber nur sehr wenig Muße, mich darum zu kümmern. Derzeit
beispielsweise hocke ich in London auf einer Konferenz über medizinische
Weiterbildung - deshalb kann ich da auch keine Programmierarbeiten
ausführen....
So, die Session fängt an.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Liste,
Ich lese ebenfalls staunend mit, schätze ehrlich gesagt zunehmend den Unterhaltungswert der Diskussion und bin aber auch in Sorge, dass pah die Lust an dem Projekt verlieren könnte.
Im Gegensatz zu den vielen kleinen Bastelheimern, zu denen auch ich gehöre, hat pah mit dem OWX ein auf der FB über USB Interface stabil laufendes 1-wire System mit vielen weiteren Sensoren neben den Thermometern ermöglicht. Davon profitieren hier sicher viele Mitleser.
Da sich inzwischen glücklicher Weise mit Olaf und DT auch die Spezialisten für hardwarenahe Programmierung und Hardware zu Wort gemeldet haben meine Frage: was können wir tun, um diese Fachleute an einen (virtuellen) Tisch zu bringen? Gemeinsam hätten sie die Herausforderung, um die hier schon Wochen gestritten wird sicher bald gelöst.
Zeit schenken können wir Euch leider nicht, mit Geld seid Ihr bestimmt nicht zu locken (PayPal Spende für eine gemeinsame Spezialistenrunde? (LOL)) - also appelliere ich an Eure Ehre! - findet einfach eine Lösung, bei der keiner sein Gesicht verliert und alle davon profitieren = win win story
Danke!
lg det.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com