OWTHERM blockiert FHEM

[ntruchsess]

günstige Alternative (zum selberlöten): USB-Interface_für_1-Wire. Den verwendeten FT232RL kauft man ab besten als fertiges Modul mit USB-buchse auf eBay ab 5 EUR, dann gibt man für die ganze Schaltung keine 15 EUR aus.

Das gleiche von Damian hier im Forum fertig aufgebaut angeboten (falls er noch welche hat). Konkurenzlos günstiger Preis (finde ich...). Funktioniert hier bei mir astrein

Oder Arduino, braucht nur einen externen Pull-up-wiederstand als zusätzliche Beschaltung, auf eBay ab ca. 7 EUR (Arduino-clones aus China, ein Nano V3 genügt, sollte nur 32kb Flash oder mehr haben).

Die Problematik der Delays beim 'normalen' OWX mit OWTHERM (und die oben angesprochenen Lösungsmöglichkeiten) besteht allerdings unabhängig vom verwendeten Busmaster. Der DS9097 braucht halt etwas mehr Rechenleistung im FHEM, das wars dann aber schon. Wichtiger ist da eher, dass die 'echten' Busmaster elektrisch besser auf den Bus angepasst sind, also eher längere Buslängen erlauben, als der rein passive Adapter.

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Hallo Norbert,

OK, habe Deine Änderungen noch nicht soweit nachvollzogen, dass ich gemerkt habe, dass Du je nach Aufruf mit 3 oder Parametern andere Dinge machst. Halte ich auch für unglücklich, weil aus der Semantik des Aufrufes nicht erkennbar ist, was passieren soll.

Betreffend Die Unabhängigkeit vom Busmaster: Nee, nicht ganz. DS9097 ist wirklich bei der Bus-Suche granatenmäßig schlechter als Interfaces mit echtem Busmaster.

LG

pah

[ntruchsess]

Halte ich auch für unglücklich, weil aus der Semantik des Aufrufes nicht erkennbar ist, was passieren soll.

Bin ich auch nicht wirklich glücklich drüber. Für konstruktive Vorschläge wie man das schöner bzw. verständlicher macht bin ich offen.

Betreffend Die Unabhängigkeit vom Busmaster: Nee, nicht ganz. DS9097 ist wirklich bei der Bus-Suche granatenmäßig schlechter als Interfaces mit echtem Busmaster.

muss mir wohl doch mal einen Löten, oder mag mir jemand einen sponsoren? Sonst rede ich hier wie ein Blinder von der Farbe

Gruß,

Norbert

[dan1180]

Hallo  Nornert,

schlag dir nen Deal vor. Du stellst mir ne Einkaufsliste und den Link zum Bauen eines (guten) aktiven Busmasters zusammen, gerne auch Links, und ich schick dir meinen DS9097 sobald ich das neue Ding angeschlossen habe.

Gruß Dan

[ntruchsess]

Um so was wie diesen hier zu bauen brauchst Du:

so einen USB-FT232RL-Zu-Seriell-Adapter (oder diesen hier, bei dem kann man die Spannung per Schalter auf 3,3V ändern, bei ersterem nur per Lötbrücke).

Dann einen DS2480. Zum Schutz vor Elektrostatik ist optional ein DS9503 sinnvoll (siehe DS2480 Datenblatt, Kapitel 'HARDWARE APPLICATION EXAMPLES' ab Seite 24.)

Zur Stabilisierung der 5V-Versorgungsspannung 1x 22µF + 1x 100nF (siehe obrigen Schaltplan im FHEM-Wiki). Optional zum R/C-Filtern des 1-Wire-busses: 62 Ohm + 470pF (DS2480-Datenblatt ab Seite 24)

wenn Du keine Platine herstellen, sondern nur auf Lochraster verdraten willst, würde ich Dir zu SMD-Adaptern für SO-8 raten, mit so was habe ich gute Erfahrungen gemacht. (Das TSOC-gehäuse vom DS9503 läßt sich da auch drauflöten, da gehen nur die Pins unter das IC, nicht - wie bei SO-8 nach außen).

Bei mir funktioniert die Minimalbeschaltung aus dem FHEM-Wiki gut, die ESD-Schutzdioden sind primär sinnvoll, wenn man iButtons benutzen will (da liegen die Kontakte ja offen!).

Viel Erfolg,

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Die Frage ist, ob es nicht günstiger wäre, dieses hier (oder Ähnliches) zu kaufen:

http://www.ebay.de/itm/USB-1-wire-Adapter-mit-FT232RL-DS2480B-chipset-DS18S20-sensor-/171041719472?pt=Wissenschaftliche_Ger%C3%A4te&hash=item27d2e184b0

Und zum Thema "Einkaufsliste": http://www.fhemwiki.de/wiki/USB-Interface_f%C3%BCr_1-Wire

LG

pah

[dan1180]

Also unabhängig davon ob ich nun einen Busmaster baue oder ihn fertig kaufe stellt sich mir noch die Frage, ob dann alles funktioniert. In einem Anderen Beitrag, durch den ich auf den Konflikt mit OWTHERM gekommen bin wurde mir auf die Frage, ob ein aktover Busmaster die Lösung ist, folgendes geantwortet:

Jain,
wie im letzten Beitrag von mir schon geschrieben, gibt es einen grundsätzlichen Designfehler in den 1-Wire-Modulen, der FHEM auf jeden Fall ca.1200 msec blockiert. Damit muss man z.Z. bei 1-Wire leben, auch wenn hier Abhilfe in Arbeit ist.
http://forum.fhem.de/index.php/topic,13580.0.html
Das ist aber z.Z. noch experimentell, und kostet Hardwareperformance.
Diese Verzögerung kann man auch mit einem aktiven Busmaster nicht beseitigen, deshalb mein Vorschlag mit seperater FHEM Instanz, FHEM2FHEM und cloneDummy. Dafür habe ich den cloneDummy gebaut.
Das andere Problem ist wahrscheinlich Dein passiver Eigenbau Busmaster. Bei dem wird die "low level" Kommunikation durch FHEM/OWX resourssenverbrauchend auf Deiner Hardware gemacht, dabei muß Durch die Hardware die Kommunikation ("High und Low") auf dem Bus peinlich genau eingehalten werden. Wenn hier die Zeitschlitze nicht stimmen, funktioniert die Kommunikation mit den Sensoren nicht, es kommt zu Lesefehlern und die Zeit, in der FHEM blockiert wird verlängert sich. hier kann ein aktiver Busmaster helfen, da sich dieser dann selbst um die Kommunikation auf dem Bus kümmert, und die Hardware auf der FHEM läuft raus ist. Zusätzlich gibt es bei einigen aktiven Busmasten aktive pull up widerstände, die für eine bessere Flankensteilheit zwischen High und Low sorgen, und damit die Stabilität auf dem Bus erhöhen.

Was meint ihr als 1Wire-Spezialisten dazu?

[ntruchsess]

ja, das ist so. Im Wesentlichen haben wir das hier im Thread auch nicht anders dargestellt.

Mit einem DS2480-Busmaster könntest Du OWX_ASYNC benutzen, das legt nicht pro Sensor und Messinterval die 1Sek. Wartepause ein. Ist bisher allerdings nur für Sensoren stabil. Aktoren funktionieren noch nicht so gut.

[Prof. Dr. Peter Henning]

Allerdings verwahre ich mich dagegen, dass dies ein "Designfehler" ist - wer hat das denn geschrieben ?

Ohne das OWX-Backendmodul und die ganzen Frontendmodule wäre die 1-Wire-Ankopplung an FHEM echt in den Kinderschuhen.

Und das es gar nicht so trivial ist, das asynchron zu machen, merken wir derzeit.

LG

pah

[det.]

Hallo pah,
Ich bin als Anwender schon recht lange mit Deinen OWX Modulen dabei und möchte hier mal auf die FHEM Statistik Seite verweisen. Wer hier meint, dass es nicht richtig läuft mit OWX sollte sich da mal die Zahl der installierten OWX, OWSWITCH, OWCOUNT etc. ansehen. Kaum zu glauben, das nur Deppen das einsetzten, die nicht merken wenn es nicht richtig läuft.
Bei mir im Produktiveinsatz mit 2 USB Adaptern DS2480 und weit über 20 Sensoren geht das jedenfalls sehr gut. Vielen Dank für die prima Modulentwicklung!
Daneben beobachte und teste ich natürlich auch gern die Weiterentwicklung in Richtung Async OWX.

[Joachim]

Allerdings verwahre ich mich dagegen, dass dies ein "Designfehler" ist - wer hat das denn geschrieben ?

Ich war's, und es ist in Meinen Augen ein Designfehler.
In einem singlethreadet Programm, wie FHEM, in dem diverse Module betreut werden müssen, ist ein sleep (oder select(undef,undef,undef,3) definitiv ein Designfehler. Das hat in einem singlethreadet Programm definitiv nichts zu suchen.
Lösungsweg 1:
komplette serielle Verarbeitung mit DevIO.pm und Freigabe der fhem-Schleife nach Schreiben in DevIO, wenn DevIO Daten meldet, Kontrolle und Verarbeitung.
Vorteil: FHEM wird nicht angehalten wie jetzt, ressourcenschonend
Nachteil: funktioniert nur bei aktivem Busmaster
Lösungsweg 2:
Auslagerung in seperaten Thread oder Programm
Vorteil: Es lassen sich auch passive Busmaster einbinden
Nachteil: Ressourcenhungrig, Anbindung deutlich komplizierter, Das Rad neu erfinden macht keinen Sinn, wenn OWFS das alles schon kann, und in C geschrieben ist.

Damit wir uns richtig verstehen, Modul läuft bei mir seit über einem Jahr wunderbar, solange keine weiteren Zeitkritischen Module in FHEM laufen. Es ist leider nicht zu gebrauchen, wenn HM oder andere ack-gesteuerte Module mit im Spiel sind

Gruß Joachim

[Prof. Dr. Peter Henning]

@Joachim:
Erstens stimmt es nicht, dass das bei zeitkritischen Modulen nicht funktioniert: Ich habe sowohl Homematic-Devices, als auch OWX mit vier verschiedenen Busmastern im Einsatz. Mit einem aktiven Busmater beträgt die Blockade des Systems auch keine "1200 ms" - sondern gerade mal 100 ms, wenn nicht gerade eine Bussuche durchgeführt wird.
Zweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen - wie Norbert Truchsess gerade erneut bestätigt hat. Das kann man als Schwäche des gesamten 1-Wire-Systems ansehen - aber sicher nicht als Designfehler.

Ich bin selbst Theoretiker und habe immer Verständnis dafür, dass man aus grundlegenden theoretischen Überlegungen eine Realisierung kritisiert. Aber Theorien sind eben nicht beweisbar, sondern nur falsifizierbar - lies mal Deinen Popper nach. Und dann lass Dir sagen, dass die schöne Theorie, das alles über DevIO ganz einfach zu machen sei, eben falsifiziert worden ist.

LG

pah

[ntruchsess]

Zweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen - wie Norbert Truchsess gerade erneut bestätigt hat.

Das ist schon möglich, aber nur, wenn der aktive Busmaster das gesammte Timing einer 1-Wire Befehlsfolge aus Reset/Adressierung/Daten selbstständig durchführen kann.
Die Busmaster-ICs DS2480/DS2482 können das nicht, da muss man mit dem nächsten Befehlsbyte warten, bis die jeweilige 1-Wire-Aktivität abgeschlossen ist. Wartet man á la DevIO asynchron (I have been there...), dann sind die Delays zwischen den Befehlen aber zu unbestimmt (und in der Regel zu lang). Das betrifft im wesentlichen die Länge des Reset-pulses - der Rest ist beim DS2480 unkritisch, da sorgt die Baudrate der seriellen Schnittstelle dafür, dass die nachfolgenden Befehlsbytes mit der richtigen Geschwindigket übermittelt werden. Beim DS2480 muss man also auch bei einer asynchronen Implementierung mit einer Blockade von FHEM in der Größenordnung von 70ms pro 1-Wire-Befehl leben.

100% über DevIO asynchron geht nur mit Einsatz eines µC auf Busmasterseite, wie z.B. bei der Arduino/FRM-Lösung.

Meine OWX_ASYNC-implementierung kann das aktuell schon soweit, dass die Reihenfolge und nötige Delays zwischen 1-Wire-Befehlssequenzen aus Reset/Addresse/Daten pro 1-Wire Device garantiert wird. Außerdem wird eine Bussuche asynchron iterativ durchgeführt (d.h. zwischen jedem gefundenen Device kommt FHEM wieder an die Reihe). Für 1-Wire-Sensoren funktioniert das Prima, Für 1-Wire-Aktoren ist das Desing aber (noch) fehlerhaft. Diese werden in der Regel in mehreren (voneinander abhängigen) Schritten beschrieben. Die Abhängigkeit ist da z.B. das Auslesen einer Prüfsumme nach Übermittlung der Daten und dem nachfolgenden Bestätigen dieser Prüfsumme. Es ist dabei wichtig, dass der betreffende 1-Wire-aktor keine anderen Kommandos dazwischen gesendet bekommt und das kann die aktuelle OWX_ASYNC-implementierung nicht garantieren, weil nicht alle Kommandos schon am Anfang der Abfolge gekannt sind.

Die nächste Evolutionsstufe ist aber schon in Arbeit

Gruß,

Norbert

[dan1180]

Leute, ob das ein Designfehler oder ein generelles 1wire Problem ist, ist doch zweitrangig. Ihr hört euch alle an als hättet ihr ne Menge Ahnung von der Materie und kennt alle das Problem. Versucht es doch gemeinsam zu lösen...

@ntruchsess: Da ich im Moment und in naher Zukunft nur meine 1wire Temperatursensoren abfragen möchte, könnte das doch meine Lösung sein, oder?

Allen noch schöne Ostern!

[ntruchsess]

@ntruchsess: Da ich im Moment und in naher Zukunft nur meine 1wire Temperatursensoren abfragen möchte, könnte das doch meine Lösung sein, oder?

Probier es doch einfach aus.