OWTHERM blockiert FHEM

Begonnen von dan1180, 13 April 2014, 23:09:56

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Nun, wenn ich um 1:40 in der Frühe eine Mail von Joachim bekomme mit einem Zitat von Karl Popper, fühle ich mich schon sehr an http://rationalwiki.org/wiki/File:Xkcd_comic_386.png erinnert...

Zum Thema OWX und Schleifen: Richtig, stimmt, die kleinen Schleifen mit ein paar ms sind drin - an die hatte ich nicht mehr gedacht. Diese sind aber zeitkritisch bei der Ansteuerung des DS2480, und durch viel Ausprobieren entstanden. Übrigens auch das abschließende 10ms lange Segment...
Ich hatte die langen Wartezeiten vor Augen, über die sich hier mehrere Leute beschwert haben.

Betreffend die Semantik: Ich habe keine Lust, seitenlange Episteln über die Semantik des Wortes "Fehler" zu schreiben. Dennoch, den Begriff "Designfehler" lehne ich nach wie vor ab und finde ihn tatsächlich offensiv und herabsetzend. Ich schreibe niemandem vor, welche Worte er zu verwenden hat - also such es Dir aus, ob Du das als notwendig erachtest. Vor allem, wenn Du Deine eigenen Programmierkenntnisse auf 1984 datierst.

LG

pah


Joachim

Moin pah,
ich bin erschüttert, ich hatte mich schon so auf eine sachliche Diskussion mit einem hochintelligenten Gegenüber gefreut.
Schade ansich,denn genau solche Diskussionen bringen die Wissenschaft voran.
Jetzt wirkt es so, als ob Du kneifen möchtest, da Dir
a) diese Diskussion lästig wird
oder
b) Du glaubst in dieser Diskussion zu unterliegen, da Du zugeben musst, das ich recht habe.

Dein Verhalten erinnert mich sehr an die allseits bekannte Salami-Taktik, Behauptungen aufstellen, und dann scheibchenweise nur das zugeben, was nicht mehr zu leugnen ist und sich dabei auf Gedächnisslücken zu berufen. Da hätte ich mehr von Dir erwartet.
Wahrscheinlich habe ich Popper dann doch besser verstanden wie erwünscht.

Es ist schon traurig, wenn Dir nichts besseres mehr einfällt, als zum widerholten Male auf der Uhrzeit 1:40 herumzureiten.

Was die lange Wartezeit von 800 ms in OWTHERM angeht, da kann ich nur sagen, die ist indiskutabel in einem SingleThreadet Programm wie FHEM, aber warum sollte ich in der Diskussion gleich mit den Brüllern kommen, wenn es doch auch noch die Kleinigkeiten gibt. Ich hatte doch schon geschrieben, dass ich dich nicht demontieren will, das machst Du ja von ganz alleine, da benötigst Du meine Mithilfe nicht.
Betreffen der Wortwahl "Designfehler": Ich habe mir das nicht ausgedacht, sondern Nachgelesen, wie dieser Fehler zu benennen ist, die Definition ist also nicht von mir, und mehr als darauf hinweisen, dass
ZitatIch sehe in der Wortwahl "Designfehler" auch keine offensive oder herabsetzende Wortwahl. Sollte das bei Dir so angekommen sein, entschuldige ich mich dafür.
kann ich nicht.
Hier mal einigeLinks:
http://www.elg-halle.de/fachschaften/informatik/Klassen/11/Fehlerarten%20Debuggen.pdf
http://wiki.infowiss.net/Designfehler
http://de.wikipedia.org/wiki/Programmfehler#Klassifizierung_von_Fehlern

Und komm mal von Deinem hohen Ross herunter, nur weil ich Programmierkenntnisse von 1984 habe, heißt das noch lange nicht, das mir der logische Menschenverstand und das analytische Denken fehlt, nein, im Gegensatz zu Dir bin ich mir durchaus bewusst, das ich weiß, das ich nichts weiß.
Oder um es in Poppers Worten zu sagen:
Zitat,,Wie Sokrates weiß der Stückwerk-Ingenieur, wie wenig er weiß. Er weiß, dass wir nur aus unseren Fehlern lernen können. Daher wird er nur Schritt für Schritt vorgehen und die erwarteten Resultate stets sorgfältig mit den erreichten vergleichen..."
Vgl. Karl Popper, Das Elend des Historizismus, Tübingen 1965, S. 53 f.

Zusammenfassen bleibt zu Sagen:
Es gibt einen grundlegenden Designfehler in den OW-Modulen.
Du bist nicht halb so intelligent, wie ich gedacht habe.
Du stellst unwahre Behauptungen auf, und berufst dich nachträglich auf Gedächnislücken.
Und Deine Berufsehre war auch nur vorgeschoben.

Um den Tread von dan1180 nicht weiter zu kapern, sollten wir es dann hier beenden, der geneigte Leser mag sich selbst ein Bild machen.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Prof. Dr. Peter Henning

Nun, wer es nötig hat, Aussagen über die Intelligenz anderer Leute zu treffen, soll das eben tun. Ist damit für mich erledigt.

pah


dan1180

#48
Hallo Leute,

also ich war jetzt ein paar Tage weg und bin mittelmäßig erschüttert, was aus meiner Hilfesuche geworden ist. Wenn ich die Programmschnipsel mal ausblende, die ich leider (noch) nicht verstehe, kann ich aus euren Beiträgen folgendes lesen:

Das Modul OWTHWERM kommt mit den aktuellen Anforderungen in FHEM, ins Besondere mit zeitkritisch kommunizierenden Komponenten, wie z.B. HomeMatic, nicht klar. Ob ihr das jetzt "Designfehler", "Fehler" oder "veraltet" nennt ist - mir zumindest - ziemlich egal. Kann ich für mich abspeichern, dass OWTHERN das nicht in der benötigten Kürze kann?

Pah ist durchaus bewusst, dass dieses Problem besteht, wehrt sich jedoch gegen den Begriff "Designfehler"? Sollte dem so sein wäre mir zur Lösung (nicht nur meines) Problems sehr recht, wenn wir uns vielleicht auf einen allseits genehmen Begriff einigen könnten (nennen wir es doch ein "veraltetes Design"). Damit würden wir die Möglichkeit schaffen, dass die Personen das Problem lösen können denen ich jetzt einfach mal die fachliche Kompetenz zuspreche.

Joachim scheint ein klasse Analyst ohne Programmierkenntnisse zu sein (ist jetzt wirklich anerkennend gemeint). Durch seine Fragen und Analysen konnte, zumindest in meinem System, die Verzögerung in OWTHERM als Ursache für meine HomeMatic Aussetzer gefunden werden. Wenn doch die veralteten Programmzeilen durch ihn analysiert wurden, warum setzten wir (besser gesagt ihr, die das könnt) da nicht an und baut dieses Modul um?

ntruchsess ist ein scheinheiliger Mensch, der mir vor der Nase den letzten verfügbaren 1wire Bus wegkauft und mir dann hier den Tip gibt mal nachzufragen, ob denn noch einer verfügbar sei  ;D Aber keine Angst...ich kann wohl noch einen aus einer neuen Charche bekommen. Vielen Dank für den Hinweis! Und danke für den Versuch diesen Beitrag wieder in eine sachliche Diskussion zu verwandeln. Auch wenn der Erfolg noch auf sich warten lässt.

Alle zusammen könnt ihr euch vielleicht, wie schon gaaanz am Anfang mal erwähnt, auf das eigentliche Problem stürzen, ohne euch all zu viele Gedanken über die Benennung des Selben zu machen. Denn der Sinn dieses Beitrags war ursrünglich mein Anliegen 1wire und HomeMatic stabil mit einer FHEM Installation zu betreiben. Ich weiß, das ist lange her. Deshalb diese Erinnerung. Ich bin jetzt einfach mal so egoistisch auf MEIN PROBLEM zurück kommen zu wollen denn ich vermute, dass es am Ende doch der Allgemeinheit zuguten kommt.

Und zu guter letzt auch von mir noch ein Zitat:
ZitatWarum passieren mir immer Sachen, die sonst nur dämlichen Menschen passieren?
Homer
FHEM 6.2 auf RPi4B
Raspberrymatic 3.X auf RPI3B

1xDS2408 und 6xDS18B20 an GPIO über Modul RPI_1Wire
>50 Homematic-Geräte

Joachim

#49
Moin Dan 1180,
Ich hatte mich ja schon für das Kapern Deines Threades entschuldigt, ich hoffe, das Popcorn war gut.

Nun zu Deinem eigentlichen Thread:
Es sind hier mehrere Lösungen am werden, allerdings alle noch in der Erprobung.
Variante 1, siehe hier:
http://forum.fhem.de/index.php/topic,13580.0.html
Sieht schon recht gut aus, aber noch in der Versuchsphase, Stabilität für ein Produktivsystem kann noch nicht garantiert werden.
Beruht auf den bekannten, guten und stabilen OWX-Modulen von pah, und umgeht den "Designfehler" durch Auslagern in Protothreads
Variante 2, siehe hier:
http://forum.fhem.de/index.php/topic,16945.0.html
Sieht ebenfalls schon recht gut aus, ist aber auch definitiv noch "beta". Es ist eine Kombination von OWFS als soliden Unterbau und einer Anbindung über OWServer/OWDevice an FHEM, es ist ebenfalls eine Weiterentwicklung, da die ursprüngliche OWServer/OWDevice einen vergleichbaren "Designfehler" hatte.
Variante 3, das FHEM mit 1-Wire als seperaten Prozess entweder auf der selben Hardware, oder einer abgesetzten Hardware laufen lassen, mittels FHEM2FHEM und cloneDevice die Sensoren auf das Hauptsystem clonen.

Variante 3, 1-Wire (mit OWX) mit einem LinkUSBi oder dem Kristech-Adapter auf der FB7390 läuft bei mir in Verbindung mit Max-Cube und HM-LAN auf dem Hauptsystem, Raspberry Pi, zufriedenstellend.
Für welche Variante Du Dich letztendlich entscheidest, kannst nur Du selber sagen.

Solltest Du noch weiter Fragen haben, melde Dich einfach wieder.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Prof. Dr. Peter Henning

@dan1180: Es ist kein Designfehler - weder in OWX, noch in OWServer. Da sollte man vielleicht auch bei der Beurteilung lieber den Leuten vertrauen, die die Sachen entwickeln - und nicht denjenigen, die anderen die Intelligenz absprechen.

Bei vielen Nutzern laufen OWTHERM-Module zusammen mit anderen, auch zeitkritischen FHEM-Subsystemen. Eine Modifikation in Richtung auf eine asynchrone Abfrage ist alles andere als einfach, seit mehr als einem Jahr sitzen wir (vorwiegend Norbert Truchsess) da dran.

LG

pah

det.

Zitat von: dan1180 am 24 April 2014, 22:22:57
... vor der Nase den letzten verfügbaren 1wire Bus wegkauft ... oh weh, der letze Bus fuhr ohne Dich ab. Ich hätte da noch einige Meter WLAN Kabel günstig anzubieten!
Lies bitte einfach noch mal meinen Beitrag weiter unten, ich habe auch die Heizkörper komplett über Homematic geregelt und schon sehr lange (direkt nach dem pah die OWX Module hier im alten Forum veröffentlicht hat) über 2 Dutzend 1-wire Devices im Dauereinsatz. OK, letzten September bin ich vom RPI auf Cubieboard2 umgestiegen, da FHEMWEB sterbend langsam reagierte und vorher von FB7390 auf RPI. Aber das hat eher mit der gewachsenen Größe meiner Haussteuerung an sich zu tun. Bei derzeit 1660 Zeilen in der fhem.cfg musste die Serverhardware eben ab und an mal was beschleunigt werden.
Ich teste aktuell die asynchronen Bemühungen von Norbert auf einem extra System. Das scheint wirklich schwierig zu sein, bei jedem Release geht was anderes nicht wie gewünscht. Da sollten wir Nichtprogrammierer mMn. schön ruhig sein, testen und abwarten bis es am Ende sicher geht.

LG
det.

Prof. Dr. Peter Henning

@det. Guter Ansatz - aber wo bitte hast Du das Zitat mit dem WLAN-Kabel her ?

LG

pah

dan1180

Hallo,

@det:
Außer deinem Lob an pah finde ich nur den Beitrag mit der Spannungsversorgung der Sensoren. Ich habe darauf geantwortet, dass mein BUS mit Spannungsversorgung ist, dies nur in FHEM nicht eingeschaltet/bekanntgegeben wurde. Seit ich das kurzzeitig umgestellt hatte tut mein 1wire gar nicht mehr. Wie ebenfalls geschreiben aber wahrscheinlich in dem "Gezanke" ;D untergegangen, habe ich die Frage gestellt, ob es da einen Zusammenhang geben kann. Digitemp (ist das bekannt? http://www.kompf.de/weather/pionewire.html) findet meine Sensoren alle, gibt jedoch keine Temperaturen aus. FHEM failed schon beim Verbinden von OWio1. Neuer BUS ist, wie ebenfalls beschreiben, in Beschaffung.

@pah:
Bitte versteh, dass es mir reichlich egal ist ob es sich um einen Designfehler handelt oder nicht. Ich hätte eine solch kindische (damit mein ich alle beteiligten) Diskussion hier nicht erwartet. Wenn doch so viele die Kombination aus HomeMatic und OWTHERM verwenden, warum kann mir dann niemand sagen was ich tun muss damit es funktioniert? Meine Probleme, die zu diesem Beitrag geführt haben, könnt ihr alle unter http://forum.fhem.de/index.php/topic,22223.msg159096.html#msg159096 nachlesen.

@Joachim:
Auch wenn ich deinen Teil der Diskussion nicht weniger kindisch finde als den von pah; danke für die bisherige Hilfe. Ich werde mir, sofern nicht bessere Lösungen von denen kommen die das alles "ohne Probleme seit Jahren" betreiben die genannten Ansätze mal anschauen. Die zweite FHEM Installation schließe ich eher aus, da wohl trotzdem in einem gaaanz dummen Fall (wie von dir etwas vorher beschrieben) auch hier ein Konflikt auftreten kann.

Weitere SACHDIENLICHE Beiträge sind gerne erwünscht!

...und dafür schon einmal vielen Dank ;)
FHEM 6.2 auf RPi4B
Raspberrymatic 3.X auf RPI3B

1xDS2408 und 6xDS18B20 an GPIO über Modul RPI_1Wire
>50 Homematic-Geräte

det.

Zitat von: Prof. Dr. Peter Henning am 25 April 2014, 19:20:10
@det. Guter Ansatz - aber wo bitte hast Du das Zitat mit dem WLAN-Kabel her ?

LG

pah
Hallo pah,
Das "Zitat" gehörte außerhalb der "Zitatbox" als bosnickliche Anmerkung von mir. Die Forensoftware bedient sich gruselig vom IPad aus.
LG
det.


dan1180

So, ein Problem scheint gelöst zu sein. Mein 1wire BUS wurde nicht mehr gefunden, weil meine 00_OWX.pm wohl bei einem Update überschrieben wurde. Hier war mein DS9097 manuell eingetragen.

FHEM ist nun leider wieder sterbens langsam... :'( Werd deshalb jetzt mal das mit dem ASYNC testen. Drückt mir die Daumen!
FHEM 6.2 auf RPi4B
Raspberrymatic 3.X auf RPI3B

1xDS2408 und 6xDS18B20 an GPIO über Modul RPI_1Wire
>50 Homematic-Geräte

det.

@dan,
Asynchron ging schon mal richtig super, wenn Du nur Thermometer Sensoren dran hast - aber nimm nicht die letzte Version hier aus dem Beitrag, da aktualisierten sich genau die Thermometer nicht - dafür schalten die Switch. Ist wie schon geschrieben nicht so einfach.
Norbert wird da aber bestimmt dranbleiben, vielleicht wartest Du noch bis die nächste Version wieder die Temperaturen regelmäßig aktualisiert. Ich habe produktiv alle möglichen Devices pro 1wire Bus durcheinander - leider, so warte ich bis ASYNC für alle funktioniert.
LG
det.

dan1180

#58
Hallo det,

zu spät  :-\
Ich glaub aber ich weiß was du meinst...Ich hab vor 25 Min fhem WEB aufgerufen und das dauert immernoch. Werd den ganzen Ordner "FHEM", den ich glücklicherweise gesichert habe, wieder überschreiben und auf Standard zurückk gehen. Bringt es eigentlich was, wenn ich mein Abfrageintervall größer stelle?

...So, jetzt ist alles wieder beim Alten...LEIDER! Was mir noch eingefallen ist: Ihr sagt, dass ihr 1wire mit HomeMatic im Einsatz habt und keine Probleme. Hat von euch jemand einen HM-CC-VD im Einsatz? Der war nämlich das ursprüngliche Problem. Da FHEM durch die Blockadezeit von 1wire eine Abfrage des Stellantriebs verpasst hat ging dieser ständig in Notbetrieb (Ventilposition 15%).
Naja und das FHEM-WEB mit OWTHERM ar...langsam ist ist mir jetzt erst wieder bewusst geworden da ich meinen OWX ein paar Tage deaktiviert hatte.
FHEM 6.2 auf RPi4B
Raspberrymatic 3.X auf RPI3B

1xDS2408 und 6xDS18B20 an GPIO über Modul RPI_1Wire
>50 Homematic-Geräte

Prof. Dr. Peter Henning

Erstens stellt sich die Frage, warum DS9097 irgendwo in 00_OWX.pm "manuell eingetragen" war.

Zweitens: Verzögerungen im Bereich von 25 Minuten haben nichts mit den Abfrageintervallen von OWX zu tun - sondern deuten auf einen Fehler in der Konfiguration oder bei der Hardware.

Drittens: Man kann einen DS9097 mit dem ASYNC-Modul beliebig lange testen. Da er davon bisher nicht unterstützt wird, ist das aber nicht sehr erfolgversprechend. Bessere Lösung: Anständiges Interface kaufen für 20 €.

pah