LBS19000193 - 1wire-owphp

[mfd]

Feuchtigkeit + Lux: Eigener LBS (noch nicht im DL-Bereich; müsste ich die Tage mal nachholen), weil die Werte nicht direkt nutzbar sind

Da seitdem ja schon ein paar Tage vergangen sind wollte ich mal vorsichtig nachfragen, ob die Chance besteht, dass du dein Werk in Form eines LBS "freigibst"?

[mfd]

Wow, vielen Dank für das Update!
Das macht es um einiges eleganter...

[jonofe]

Ein Update des LBS auf Version 0.3.1 ist jetzt verfügbar. Es wird nun an A2 ein Fehler beim Auslesen eines Sensors signalisiert. Wie viele Lesefehler toleriert werden, bevor A2 einen Fehler signalisiert (=1) hängt vom neuen Eingang E8 ab (Default: 0). An A3 sieht man im Fehlerfall die Anzahl aufeinanderfolgender Lesefehler. A2 und A3 werden bei jedem erfolgreichen Auslesen auf 0 zurückgesetzt. Damit sollte ein entsprechendes Monitoring von wichtigen Sensoren möglich sein.

[mfd]

Du meinst wenn Read Error im Log landet, dann einen Error Ausgang A2 auf 1 setzen?

Ja, sowas in der Art hatte ich mir vorgestellt. Für wichtige Sensoren, die bspw. für Regel- oder Schaltaufgaben verwendet werden wäre das sehr sinnvoll. Auch für eine Visu ist es natürlich nicht schlecht das erkennen zu können, bevor ein Temperaturwert tagelang keine neuen Werte mehr liefert...

Ob das schon bei der ersten Anfrage oder erst nach dem x-ten erfolglosen Leseversuch einen Fehler ausspucken sollte kann ich jetzt schlecht beurteilen. Das kannst du sicher besser überblicken.

[jonofe]

Du meinst wenn Read Error im Log landet, dann einen Error Ausgang A2 auf 1 setzen?
Wenn ja, sollte machbar sein. Schau ich mir an ...

[gulp2k]

Ich hab dafür einen Watchdog LBS genommen.
Ist aber bei vielen Senosre ziemlicher Overhead...

[mfd]

jonofe ist es technisch möglich eine Art "Ausfallerkennung" für den abgefragten Sensor einzubauen, oder müsste das serverseitig bewerkstelligt werden? Es wäre hilfreich, so etwas wie eine Kontrolle über den abgerufenen Sensor zu haben, für den Fall, dass dieser nicht (mehr) auf die Leseanforderung reagiert...

[mfd]

Vielleicht sollte ich wirklich mal einen USB-Busmaster testen. Allerdings steht die Investition erst noch an hinterer Stelle (KNX-Bewegungsmelder und Taster gehen vor :-) ).

Ich denke die 20€ für einen einfachen Busmaster sind keine schlechte Investition. Schließlich ist man damit auch unabhängiger von der Hardware.

Edit: Full Quotes bitte vermeiden.

[Langer89]

@Langer89: Bei mir ist in der owfs.conf das Anlegen des Mountpoints auskommentiert. Ich hatte das für die Inbetriebnahme mal aktiv, um zu sehen, wie die Daten abgelegt werden. Aber notwendig ist es für den Normalbetrieb nicht.

Ich habe bei mir zwei RasPi3 laufen, die über ein USB-1Wire-Modul (DS9490R) jeweils 14 bzw 16 DS18B20 auslesen. Beschreibung siehe hier. Da sind die Anschlüsse allerdings alle < 1m. Die Verkabelung ist natürlich sternförmig.
Ein dritter RasPi2 ließt auch DS18B20 aus, die in den Räumen in den Thermostatreglern stecken. Ich nutze für die Verkabelung die gelbe und weiße Ader des KNX-Kabels.
Die Verschaltung ist auch hier sternförmig. Der RasPi hat als 1wire-Modul in diesem Fall ein ROT-Modul von Busware.
In allen drei Fällen gibt es keine Probleme mit der Abfrage der Sensoren.
Evtl. ist die GPIO4-Lösung nicht stabil genug.

Ich bin mir auch nicht sicher, ob eine Abfrage per LBS direkt dazu führt, dass der OWFS-Server diese Abfrage auf den 1-wire-Bus schickt, oder ob er quasi aus (s)einem Cache antwortet. Wäre letzteres der Fall, könnte man eine Kollision bei der Abfrage der Sensoren ausschließen.
Vielleicht kann man den Modus (direkt oder Cache-Abfrage) am Server auch einstellen. Dann kann man ihm das saubere Auslesen der Sensoren überlassen und kann die Abfrage durch das LBS beliebig schnell wiederholen ohne dass es zu Kollisionen auf dem Bus führt.
Allerdings wäre es für die oben beschriebene Anwendung der Reaktion mit Licht im Bad auf einen schnellen Temperaturanstieg nicht hilfreich.

Ich habe jetzt mal ein paar Tage mit nur 3 bzw. 2 Sensoren am Bus getestet. Selbst dann bekomme ich noch Lesefehler. Im OWFS Webfrontend allerdings immer noch ohne Fehler.Verkabelt ist alles mit den 5m Anschlussleitungen die direkt am Fühler sitzen. Im Regelbetrieb soll es aber auch über KNX-Leitung laufen. Leider konnte ich zu der Arbeitsweise vom OWFS bisher nichts finden. Auch eine erhöhung des Loglevels ist meiner Meinung nach nicht möglich. Vielleicht sollte ich wirklich mal einen USB-Busmaster testen. Allerdings steht die Investition erst noch an hinterer Stelle (KNX-Bewegungsmelder und Taster gehen vor :-) ). Hätte mich gefreut wenn es einfach über die GPIO-Variante im "kleinen" funktioneirt hätte.

Danke auf jeden Fall für eure Hilfe!

[Wingfighter]

@Langer89: Bei mir ist in der owfs.conf das Anlegen des Mountpoints auskommentiert. Ich hatte das für die Inbetriebnahme mal aktiv, um zu sehen, wie die Daten abgelegt werden. Aber notwendig ist es für den Normalbetrieb nicht.

Ich habe bei mir zwei RasPi3 laufen, die über ein USB-1Wire-Modul (DS9490R) jeweils 14 bzw 16 DS18B20 auslesen. Beschreibung siehe hier. Da sind die Anschlüsse allerdings alle < 1m. Die Verkabelung ist natürlich sternförmig.
Ein dritter RasPi2 ließt auch DS18B20 aus, die in den Räumen in den Thermostatreglern stecken. Ich nutze für die Verkabelung die gelbe und weiße Ader des KNX-Kabels.
Die Verschaltung ist auch hier sternförmig. Der RasPi hat als 1wire-Modul in diesem Fall ein ROT-Modul von Busware.
In allen drei Fällen gibt es keine Probleme mit der Abfrage der Sensoren.
Evtl. ist die GPIO4-Lösung nicht stabil genug.

Ich bin mir auch nicht sicher, ob eine Abfrage per LBS direkt dazu führt, dass der OWFS-Server diese Abfrage auf den 1-wire-Bus schickt, oder ob er quasi aus (s)einem Cache antwortet. Wäre letzteres der Fall, könnte man eine Kollision bei der Abfrage der Sensoren ausschließen.
Vielleicht kann man den Modus (direkt oder Cache-Abfrage) am Server auch einstellen. Dann kann man ihm das saubere Auslesen der Sensoren überlassen und kann die Abfrage durch das LBS beliebig schnell wiederholen ohne dass es zu Kollisionen auf dem Bus führt.
Allerdings wäre es für die oben beschriebene Anwendung der Reaktion mit Licht im Bad auf einen schnellen Temperaturanstieg nicht hilfreich.

[mfd]

@mfd: muss ich noch schön machen, dann gerne... wird noch etwas dauern.

Ich warte ganz brav. Vielleicht gibts dann ja Weihnachtsgeschenke...

[Langer89]

...sporadische Fehler sind Moppelkotze... WLAN würde ich nicht vermuten. Insgesamt ist ja wohl alles korrekt aufgebaut. Damit neige ich nun doch wieder dazu, den OWFS-Server im Verdacht zu haben. Hast Du einen Sensor, der besonders oft Fehler liefert? Das müsste man ja im Mount gelegentlich sehen... nur um die Fehlerquelle einzugrenzen.
Welche Analyseoptionen auf OWFS/1-wire bereit stehen, weiß ich leider nicht...

Wie gesagt, Fehler liefern alle Sensoren, anscheinend aber die Fühler Pufferspeicher oben und mitte häufiger. Müssen im mount Daten oder Ordner vorhanden sein? Mein /mnt/1wire ist leer...

Ich würde auch mal versuchen mehr Details auf dem OWFS Server zu bekommen. Ggf. kann man das Logging dort hochdrehen. Es kann durchaus sein, dass der Webserver dir den zuletzt empfangenen Wert zeigt, auch wenn beim letzten Auslesen ein Fehler aufgetreten ist. Wie ist denn denn 1wire Bus Struktur? Hast du Stern, Baum oder lineare Topologie? Bei ersteren beiden, kann es natürlich zu Reflexionen kommen. Vielleicht gibts auch externe Einflüsse?
du könntest natürlich auch den Temperaturwert im Cach des OWFS Servers abrufen. Dann sollte es vermutlich keine Fehler im Edomi geben. löst aber ggf. nicht das Problem, welches du im OWFS Server hast. Das ist aber alles Spekulation solange man nicht genau weiß wo der Fehler genau liegt und welche Ursache er hat.
Tritt der Fehler bei allen Sensoren sporadisch auf? Oder sind es nur bestimmte Sensoren die betroffen sind. Im letzteren Fall könnte man prüfen, ob diese z.B. in einem Strang liegen, der dann beim Busmaster mit anderen Strängen (die keine Fehler produzieren) zusammenläuft.

Topologie ist Stern, 5m Stranglänge, das ganze ist zur Zeit nur ein Testaufbau bei dem ich alle Sensoren Sternförmig in Wagoklemmen führe, von dort aus auf den Raspi. Wie kann ich auf die Temps im Cache zugreifen?

[saegefisch]

@mfd: muss ich noch schön machen, dann gerne... wird noch etwas dauern. Mein Hauptprojekt ist immer noch lBS 19000110 - das mich langsam - nach wirklich vielen Stunden - an den Rand der Verzweifelung bringt... aber ich ich bin willens, das Spiel zu gewinnen... Dann der 1-wire-LBS...

[mfd]

Feuchtigkeit + Lux: Eigener LBS (noch nicht im DL-Bereich; müsste ich die Tage mal nachholen), weil die Werte nicht direkt nutzbar sind.

Das wäre großartig, dann stünde hier einer Migration von 1-wire -> EDOMI nichts mehr im Wege. Aber die Feuchtigkeitssensoren haben mich bislang noch davon abgehalten.

[jonofe]

Ich würde auch mal versuchen mehr Details auf dem OWFS Server zu bekommen. Ggf. kann man das Logging dort hochdrehen. Es kann durchaus sein, dass der Webserver dir den zuletzt empfangenen Wert zeigt, auch wenn beim letzten Auslesen ein Fehler aufgetreten ist. Wie ist denn denn 1wire Bus Struktur? Hast du Stern, Baum oder lineare Topologie? Bei ersteren beiden, kann es natürlich zu Reflexionen kommen. Vielleicht gibts auch externe Einflüsse?
du könntest natürlich auch den Temperaturwert im Cach des OWFS Servers abrufen. Dann sollte es vermutlich keine Fehler im Edomi geben. löst aber ggf. nicht das Problem, welches du im OWFS Server hast. Das ist aber alles Spekulation solange man nicht genau weiß wo der Fehler genau liegt und welche Ursache er hat.
Tritt der Fehler bei allen Sensoren sporadisch auf? Oder sind es nur bestimmte Sensoren die betroffen sind. Im letzteren Fall könnte man prüfen, ob diese z.B. in einem Strang liegen, der dann beim Busmaster mit anderen Strängen (die keine Fehler produzieren) zusammenläuft.