Stabilisierung von RaspBerry Pi + COC

[tostmann]

                                                 

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

[det.]

                                                 

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

[Guest]

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

[Guest]

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

[nobody0472]

                                                                 

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

[Guest]

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

[rudolfkoenig]

                                                   

> 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

[Guest]

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

[rudolfkoenig]

                                                   

> 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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[nobody0472]

                                                                 

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