Stabilisierung von RaspBerry Pi + COC

[Guest]

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

[Guest]

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

[Guest]

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

[nobody0472]

                                                                 

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

[Guest]

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

[Guest]

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

[jorge]

                                         

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

[Guest]

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

[det.]

                                                 

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