OWServer/OWDevice nonblocking patch

[justme1968]

leider gab bis jetzt doch noch das problem das rereadcfg mit meinen änderungen nicht mehr funktioniert hat.

rudi hat inzwischen aber mit NOTIFYDEV die möglichkeit eingebaut rereadcfg ohne klimmzüge und ohne performance nachteile abzufangen.

die änderungen insgesamt sind:
- NOTIFYDEV verwenden
- NotifyFn vereinfacht
- random start etwas vereinfacht und schon beim ersten auslesen anwenden
- nach autocreate wird automatisch save aufgerufen wenn autosave für autocreate gesetzt ist

@boris: würdest du das bitte anschauen und einchecken

gruss
  andre

[Dr. Boris Neubert]

Herzlichen Dank für Deine Arbeit.

Die beiden Dateien sind eingecheckt.

Viele Grüße
Boris

[fiedel]

Hi Andre,

vielen Dank für die gute Arbeit! Ich hab in den letzten Tagen auch meine Temperatursensor- Kette vom CUNO auf das "richtige" Onewire  umgezogen und freue mich daher besonders, dass das jetzt auch perfekt läuft!

Viele Grüße

Frank

[UweH]

Hallo zusammen,

seit Tagen quält mich FHEM mit folgenden Einträgen im Log:

Code Auswählen Erweitern

Use of uninitialized value $ret in concatenation (.) or string at /usr/share/fhem/FHEM/10_OWServer.pm line 262.
Use of uninitialized value $ret in print at /usr/share/fhem/FHEM/10_OWServer.pm line 264.
Use of uninitialized value $ret in chomp at /usr/share/fhem/FHEM/10_OWServer.pm line 281.
Use of uninitialized value $ret in concatenation (.) or string at /usr/share/fhem/FHEM/10_OWServer.pm line 262.
Use of uninitialized value $ret in print at /usr/share/fhem/FHEM/10_OWServer.pm line 264.
Use of uninitialized value $ret in chomp at /usr/share/fhem/FHEM/10_OWServer.pm line 281.
.
.
.
usw.
FHEM läuft dabei aber problemlos weiter. Welche Ursache könnte das haben? Ich stelle diese Frage mal hier, weil die angegebenen Zeilen aus dem nonblocking-Bereich des OWServer-Moduls stammen.

[justme1968]

die zeilen haben aber nichts mit dem patch zu tun sondern waren vorher schon genau so da.

aus irgend einem grund liefert OWNet/owfs keinen wert zurück.

gab es irgend ein update? vielleicht von owfs selber ?

gruss
  andre

[fiedel]

Hi Uwe,

suche mal im Forum nach der Meldung! Ich habe letztens ein paar Tipps zur Fehlersuche dazu gegeben. Vielleicht helfen die dir, das Prob. zu lösen.

Gruß

Frank

[UweH]

OK, Danke für die Hinweise. Ich geh dann mal auf Fehlersuche...

[justme1968]

anbei eine erste test version die beim pollen der readings asynchron arbeitet.

die idee ist nach dem forken im parent nicht mehr blockierend zu warten sondern per selectlist asynchron.

um das ganze zu testen muss wie bei nonblocking auch schon für das OWServer device nonblocking gesetzt sein und zusätzlich für jedes OWDevice das asynchron funktionieren soll.

wie bisher ist nonblocking nur für das pollen im betrieb implementiert. die initialisierung beim start von fhem ist auf jeden fall noch blockierend. ein manuelles get ebenso. wobei bei letzterem zumindest der 4 sekunden timeout greift und nicht alles hängen bleibt.

zur zeit ist das erst mal nur für 'normale' device readings implementiert. noch nicht für alarm und id. alarm ist im prinzip kein problem, id ist zur zeit noch eins weil client und server so weit entkoppelt sind das eine leere antwort für ein nicht vorhandenes device noch nicht von einer leeren antwort auf grund eines kommunikationsproblems unterschieden werden kann.

wenn der ansatz sich bewährt sollte nicht für jedes reading ein neuer child prozess gestartet werden sondern ein child sollte die ganze zeit laufen und bidirektional mit dem parent kommunizieren. dazu wäre dann noch ein mechanismus nötig um bei nicht erreichbarkeit von owfs nicht immer mehr readings aufzustauen sondern pro typ und device immer nur eins.

momentan gibt es auch noch einiges mehr an unnötigem overhead da noch nichts weiter optimiert ist. man kann aber deutlich sehen das perfmon nichts mehr meldet auch wenn man alle DS18B20 in höchster auflösung auf uncached laufen lässt.

gruss
  andre

[eldrik]

Hi,

habe die aktuellen Dateien eingespielt und kann keine Perfmon Meldungen mehr feststellen.

Abfrageintervalle 5x DS1820 á 60 Sek., 2x DS2408 á 1 Sek., 3x DS2413 á 60 Sek., 1x DS2450 á 120 Sek.

Edit: Nachtrag bei allen Devices =! DS1820 werden mit nonblocking 1 keine Daten mehr in fhem aktualisiert

Greetz
Eldrik

[justme1968]

fehler gefunden und oben 10_OWServer.pm aktualisiert. (es war der . in den namen der readings)

gruss
  andre

[eldrik]

jetzt werden die readings brav aktualisiert! 

Mir ist aufgefallen, das bei global verbose 3 jede Menge OWDevice parse "readings" Einträge ins Log geschrieben werden, ist dies beabsichtigt?

Ferner beträgt mit den oben aufgeführten Intervallen die CPU Last über top auf meinem raspberry ca 50% für den process Perl und 15% für den process owserver, ist hier noch Optimierungspotential vorhanden? 

Greetz
Eldrik

[justme1968]

die log nachricht hab ich vergessen raus zu nehmen.

bei deinen Intervallen kann es passieren das 4 oder 5 anfragen in eben so vielen prozessen gleichzeitig auf owfs losgelassen werden weil die alte zwangs serialisierung weg ist. das ist an sich noch nicht schlimm so lange das system noch schnell reagiert. das ist ja unser ziel: ein system das noch reagiert auch wenn es ausgelastet ist im gegensatz zu einem system das blockiert weil es auf eine einzige antwort wartet.

die load ist dafür nur bedingt ein guter indikator weil sie 'nur' aussagt wie viele prozesse auf io warten. und genau das wird genutzt. das warten auf mehr als einen prozess zu verteilen damit nicht blockiert wird.

perfmon ist dafür sehr viel besser geeignet. eventuell später auch mit ein intervall das deutlich unter einer sekunde liegt.

ansonsten gibt es noch sehr viel optimierungspotential :

- optimieren der reverse suche mit einem hash

- optimieren des parsens und teilweise verlagern in den geforkten prozess

- nicht für jedes reading neu forken sondern nur pro device oder sogar nur ein mal

- nur ein reading pro device ausstehen lassen

- abfragen unter dem owfs caching intervall sind nur auf uncached sinnvoll und da auch nur auf Intervalle dir größer als dir auslese zeit des sensors sind.

- noch eine ganze reihe mehr

die version oben ist wirklich nur ein aller erster test ob es so geht und ob es vor allem auch mit mehr als meinem 10 sensoren und anderen intervallen geht. wenn das so ist und perfmon sich nicht mehr beschwert dann kann man daran gehen das ganze weiter zu optimieren.

gruss
  andre

[eldrik]

Hey Andre,

jede Verbesserung begrüße ich

Ich bin derzeit noch im Hausumbau, daher könnte ich erst in ein paar Wochen/Monaten weitere Sensoren verteilt auf drei Raspberry 1Wire Netzwerke (UG, EG, OG) testweise zu einem großen 1Wire Netzwerk zusammenfassen, die Erweiterung wäre min. 13x Temp, 3xDS2408, 3x DS2450, 4x DS2413

Wie sieht denn die Möglichkeit aus, 1Wire conditional search zu implementieren?

http://techwww.in.tu-clausthal.de/site/Dokumentation/OneWire/ApplicationNotes/App187_1WSearch.pdf

Gruß
Jens

[justme1968]

ich habe noch nicht rausgefunden ob und wie owfs die conditional search implementiert. es gibt ein paar hinweise in verbindung mit dem alerting/alarm directory aber die doku ist ziemlich dünn.

wenn es auf owfs seite eine schnittstelle gibt kann man das natürlich auch in fhem nachziehen. wenn nicht ist ein fhem modul das dichter an der eigentlichen hardware sitzt vermutlich besser.

gruss
  andre

[eldrik]

Hey,

ja ich habe auch noch nicht "die" Anleitung gefunden, wie conditional search nun funktioniert, in diesem Thread wird das Vorgehen zwar beschrieben, es wird aber nicht explizit darauf eingegangen, ob das setzten über "set_alarm" alleine dafür sorgt, dass owfs bzw. owserver nunmehr den conditional search benutzt.

http://comments.gmane.org/gmane.comp.file-systems.owfs.devel/8422

Vl. kann man auch von anderen Projekten partizipieren?

http://www.openremote.org/display/forums/Extended+OneWire+support

https://github.com/pakerfeldt/jowfsclient/blob/master/src/test/java/org/owfs/jowfsclient/integration/OwfsClientDS2408InputTest.java

Gruß
Jens