OWX asynchron überarbeitet

[ntruchsess]

wie schon in Arduino/FRM-bezogenen Threads angekündigt, habe ich das OWX-Modul dahingehend überarbeitet, das es den 1-Wire-bus asynchron bedienen kann. D.h. das Scannen des Busses und Auslesen der Werte aus den 1-Wire devices findet in der Regel im Hintergrund statt, so dass z.B. das Web-interface unabhängig von der Aktivität auf dem 1-Wire bus nicht ausgebremst wird.

Der aktuelle Stand findet sich hier auf Github

Für die asynchrone Verarbeitung portiert und von mir getestet sind aktuell der code für Arduino und serielle Busmaster (DS2480 oder passives Serielles Interface), dazu noch die Module OWTHERM und OWCOUNT.
Was ich nicht testen kann ist der Code für den CUNO. Der läuft jetzt zwar noch nicht asynchron musste aber natürlich an den überarbeiteten OWX-code angepasst werden. Auch die anderen OWxxxx-module sind noch unverändert (weil mir die passende Hardware zum testen fehlt).

Ich würde das ganze jetzt gerne mal stabilisieren und zu Ende bringen um es in den svn-trunk überführen zu können damit alle was davon haben. Ich würde mich daher freuen, wenn Ihr den aktuellen Stand mal testen würdet, insbesonders auch jemand, der einen CUNO oder weitere 1-Wire Devices besitzt.

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Die Module für die anderen Sensoren / Devices (also OWSWITCH, OWAD, OWMULTI, OWID OWLCD) sollten davon gar nichts merken.

Bei einem OWX-Zugang über USB habe ich bisher keinen negativen Effekt gefunden - allerdings auch keinen Vorteil bemerkt.

Beim CUNO aber taucht das Problem auf, dass das CUL-Modul den CUNO bedient und OWX auf das CUL-Modul zugreift. Und, pardon: Bisher hat das CUL-Modul Schwierigkeiten mit dem CUNO gemacht.

LG

pah

[det.]

Habe es gestern kurz auf meinem Produktivsystem RPI mit OWX über 2 USB Adapter DS2480 getestet. Die 17 OWTHERM lieferten Werte wie gewünscht und der Aufbau der Web Oberfläche ging gefühlt etwas schneller. Allerdings funktionierte OWSWITCH und OWLCD nicht und schrieb das LOG mit Fehlermeldungen voll:

Code Auswählen Erweitern

2013.06.30 12:45:06 3: OWSWITCH: Could not get values from device OWSWITCHBoden, reason not accessible in reading
2013.06.30 12:45:08 3: OWSWITCH: Could not get values from device OWX_Vaillant, reason not accessible in reading
2013.06.30 12:45:09 3: set OWSWITCHBoden output A OFF : OWSWITCH: Could not set device OWSWITCHBoden, reason: not accessible in readingdevice 12.15AF7B000000.51 not accessible in writing
2013.06.30 12:45:09 3: tempNotify return value: OWSWITCH: Could not set device OWSWITCHBoden, reason: not accessible in readingdevice 12.15AF7B000000.51 not accessible in writing
2013.06.30 12:45:10 3: OWSWITCH: Could not get values from device OWSWITCHB, reason not accessible in reading
2013.06.30 12:45:11 3: W_LCD11 return value: OWLCD: Device FF.C90700000100.9A not accessible for writing
2013.06.30 12:45:12 3: W_LCD01 return value: OWLCD: Device FF.8E0700000100.6A not accessible for writing
2013.06.30 12:45:12 3: W_LCD01 return value: OWLCD: Device FF.8E0700000100.6A not accessible for writing
2013.06.30 12:45:12 3: W_LCD02 return value: OWLCD: Device FF.8E0700000100.6A not accessible for writing
2013.06.30 12:45:12 3: W_LCD02 return value: OWLCD: Device FF.8E0700000100.6A not accessible for writing
OWMULTI erzeugte keine LOG Einträge, lieferte aber auch keine Messwerte, also schnell wieder bisherige Module zurückgespielt.
Der Test RPI mit OWX über FIRMATA läuft mit OWSWITCH und OWTHERM dagegen prima.

[ntruchsess]

Habe es gestern kurz auf meinem Produktivsystem RPI mit OWX über 2 USB Adapter DS2480 getestet. Die 17 OWTHERM lieferten Werte wie gewünscht und der Aufbau der Web Oberfläche ging gefühlt etwas schneller. Allerdings funktionierte OWSWITCH und OWLCD nicht und schrieb das LOG mit Fehlermeldungen voll:[...]
Der Test RPI mit OWX über FIRMATA läuft mit OWSWITCH und OWTHERM dagegen prima.

Danke für das Feedback, schade dass die OWSWITCH und OWLCD-devices nicht gehen. Aber Danke für das Log, das bringt mich schon einen Schritt weiter. Ich muss mir aber wohl doch noch ein paar andere 1-Wire Devices zulegen um das zu Ende refactoren zu können...

Aber freut mich doch sehr, dass die Teile mit der Firmata schon mal laufen :-)

Ich habe grade ein Update auf GitHub committet, jetzt erkennt (bzw. soll erkennen) das OWX-Modul selbsttätig, ob die verwendete Perl-version threads unterstützt und der dazu passende code verwendet. Zusätzlich kann man diesen Background-thread mit dem Attribute 'async' des OWX-moduls für Serielle Busmaster und CUNO abschalten. Firmata verwendet keinen separaten perl-Thread, da läuft die asynchrone bearbeitung ja auf dem Arduino per se eigenständig.

Bei einem OWX-Zugang über USB habe ich bisher keinen negativen Effekt gefunden - allerdings auch keinen Vorteil bemerkt.

Einen Vorteil sieht man dann, wenn der 1-Wire-Bus gut ausgelastet wird - also wenn man das refreshintervall für DS18B20 auf 2 Sekunden stellt oder so... Wenn auf dem Bus alles rund läuft und man nicht zu schnell pollt, dann merkt man keinen wirklichen Unterschied.

Beim CUNO aber taucht das Problem auf, dass das CUL-Modul den CUNO bedient und OWX auf das CUL-Modul zugreift. Und, pardon: Bisher hat das CUL-Modul Schwierigkeiten mit dem CUNO gemacht.

Nun, mit dem CUNO bin ich was 1-Wire angeht auch noch nicht so ganz im Reinen. Den kann ich nicht asynchron in einem eigenen Thread bedienen, wenn noch andere Kommunikation über das CUL-modul läuft. Deshalb ist dieser für das OWX_CCC-submodul per default abgeschaltet (kann aber zu testen mit dem 'async'-attribut angestellt werden. Aber auch ohne eigenen Thread wird z.B. das Delay zwischen der Konvertierung und dem Auslesen im OWTHERM nicht einfach in einem select gewartet, sondern die Kontrolle zwischendurch an den fhem-mainloop zurückgegeben, so dass auch ein CUNO bei kürzeren Refreshraten das System nicht so sehr bremsen sollte. (In der Theorie... ich hab ja keinen zum Testen...)

Gruß,

Norbert

[ntruchsess]

Device FF.C90700000100.9A not accessible for writing

Hi Detlev,

War eigentlich nur eine Kleinigkeit, ich hab dafür gerade einen Fix commitet.
Falls Du Zeit hast, kannst Du das jeweils mit dem OWX-Attribute 'async 1' und 'async 0' testen?

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Ich bin ja Willens, das auch mit den anderen Devices zu testen. Aber im Moment (und das schon seit Monaten ...) am Anschlag mit meiner Zeit. Mal sehen, ob jetzt im Sommer etwas Muße ist, dann können wir das etwas weiter treiben.

LG

pah

[ntruchsess]

Ich bin ja Willens, das auch mit den anderen Devices zu testen.

Kein Problem, mal hat man Zeit und mal eben nicht. So ist das bei Open-source-projekten.
Ich hab mir jedenfalls grade einen Schwung fehlender 1-Wire chips bestellt um selber mit dem Thema weiterzukommen.

Gruß,

Norbert

[ergerd]

Hallo zusammen,

ich habe am 29.06.2013 ein Update gemacht und unter anderem auch 21_OWCOUNT.pm mit folgender Kennung bekommen:
# $Id: 21_OWCOUNT.pm 3253 2013-06-06 22:15:14Z ntruchsess $
Mit dieser OWCOUNT läuft mein System ab Datumswechsel um 24 Uhr mit 100% CPU-Last und FHEM stellt die Arbeit ein.
Ich habe aus dem Backup die alte Version des OWCOUNT restauriert, Kennung:
# $Id: 21_OWCOUNT.pm 3337 2013-06-26 14:03:43Z pahenning $
Damit läuft es wieder vernünftig. Vielleicht helfen euch diese Infos beim Bugfixing.

Viele Grüße
 Rainer

[ergerd]

Zu dumm, ich habe die Versionen durcheinander geworfen.
Die Version vom 26.06.2013 läuft bei mir nicht, beim Tageswechsel geht die CPU auf 100% Last und FHEM stellt die Arbeit ein.
Ich bin wieder auf die Version vom 6.06. zurück gegangen.
Grüße
Rainer

[Prof. Dr. Peter Henning]

Mit welchem Interface denn ? Was sagt das Logfile um Mitternacht ?

LG

pah

[ergerd]

Hallo pah,

im Logfile ist nur der letzte Eintrag zu sehen:
2013.06.03 23:19:25 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
danach wird bis zum Neustart von FHEM nichts mehr geschrieben.

Hier meine fhem.cfg:
define myOWFS OWServer localhost:4304
attr myOWFS nonblocking 1
attr myOWFS room 40_keller
define myOWFS_C1 OWCOUNT DS2423 2BD20D000000 300
attr myOWFS_C1 AFactor 0.001
attr myOWFS_C1 AMode daily
attr myOWFS_C1 AName Stromverbrauch1|energy
attr myOWFS_C1 APeriod hour
attr myOWFS_C1 AUnit kWh|kWh
attr myOWFS_C1 BFactor 0.001
attr myOWFS_C1 BMode daily
attr myOWFS_C1 BName Stromverbrauch2|energy
attr myOWFS_C1 BPeriod hour
attr myOWFS_C1 BUnit kWh|kWh
attr myOWFS_C1 LogM FileLog_myOWFS_C_M
attr myOWFS_C1 fp_Erdgeschoss 820,200,0,
attr myOWFS_C1 model DS2423
attr myOWFS_C1 room 40_keller
define myOWFS_C2 OWCOUNT DS2423 404C0F000000 300
attr myOWFS_C2 AFactor 0.001
attr myOWFS_C2 AMode daily
attr myOWFS_C2 AName Stromverbrauch3|energy
attr myOWFS_C2 APeriod hour
attr myOWFS_C2 AUnit kWh|kWh
attr myOWFS_C2 BFactor 0.001
attr myOWFS_C2 BMode daily
attr myOWFS_C2 BName Stromverbrauch4|energy
attr myOWFS_C2 BPeriod hour
attr myOWFS_C2 BUnit kWh|kWh
attr myOWFS_C2 LogM FileLog_myOWFS_C_M
attr myOWFS_C2 fp_Erdgeschoss 830,200,0,
attr myOWFS_C2 model DS2423
attr myOWFS_C2 room 40_keller
define FileLog_myOWFS_C FileLog /volumeUSB1/usr/local/FHEM/var/log/myOWFS_C-%Y-%m.log (myOWFS_C1|myOWFS_C2).*(kWh).*
attr FileLog_myOWFS_C room 40_keller
define wl_FileLog_myOWFS_C_1 weblink fileplot FileLog_myOWFS_C:wl_FileLog_myOWFS_C_1:CURRENT
attr wl_FileLog_myOWFS_C_1 room 40_keller
define FileLog_myOWFS_C_M FileLog /volumeUSB1/usr/local/FHEM/var/log/myOWFS_C_M-%Y-%m.log (myOWFS_C1|myOWFS_C2):day.*
attr FileLog_myOWFS_C_M room 40_keller

Grüße
Rainer

[ntruchsess]

Zu dumm, ich habe die Versionen durcheinander geworfen.
Die Version vom 26.06.2013 läuft bei mir nicht, beim Tageswechsel geht die CPU auf 100% Last und FHEM stellt die Arbeit ein.
Ich bin wieder auf die Version vom 6.06. zurück gegangen.
Grüße
Rainer

bitte diskutiere das im passenden Thread, meine für asynchrone Verarbeitung überarbeitete OWX-Version ist noch nicht über 'update development' installierbar, da noch nicht ins FHEM-SVN eingecheckt sondern (ausschließlich) von Github herunterlad- und manuel installierbar.

Gruß,

Norbert

[ntruchsess]

so, es gab ja mit den Modulen OWSWITCH und OWMULTI noch Schwierigkeiten im asynchronen Modus, was unter anderem daran lag, das sie noch gar nicht überarbeitet waren und sozusagen im 'Kompatibilitätsmodus' liefen.

Nachdem die Chips gestern gekommen sind, konnte ich die vorher schon 'blind' angepassten Module 21_OWID.pm, 21_OWSWITCH.pm, 12_OWMULTI.pm und 21_OWAD.pm jetzt mal testen und initial zum laufen kriegen. OWAD wirft ohne definierte Alarmschwellen noch einen Haufen Meldungen wie 'Use of uninitialized value in numeric eq (==)'. (Das ist mit der originalen OWAD-version aber wohl auch so, da werde ich aber noch nachschäfen). Der Rest ist hier bei mir unauffällig.

Ein Dauertest mit je ein DS2401, DS2406, DS2408, DS2413, DS2438, DS2450 und 2 DS18B20 an einem DS2480 seriellen Busmaster, alle Module auf 5-Sekunden Aktualisierungsinterval eingestellt, läuft gerade seit 1 Stunde. Bis jetzt ist das Webinterface immer noch gut bedienbar :-)

21_OWLCD.pm fehlt noch.

Alle Module wie bisher auf Github.

Gruß,

Norbert

[ergerd]

Geht klar. Allerdings bin ich jetzt verunsichert. Ich gebe in meinem FHEM immer nur "update" bzw. "update check" ein, ich habe auch noch nie etwas von github heruntergeladen. Wie bin ich dann an die Version gekommen?
Grüße
Rainer

[ntruchsess]

Wie bin ich dann an die Version gekommen?

gar nicht.

am 06.06. hatte ich halt einen Bug im bisherigen OWCOUNT (das man über das update bekommt) gefixed. Der hatte aber nichts mit der hier diskutierten asynchronen Überarbeitung zu tun.

Da Du OWSERVER verwendest, würdest Du von dieser Überarbeitung auch nicht profitierten (bzw. diese gar nicht benötigen).

Gruß,

Norbert