OWX asynchron überarbeitet

[det.]

dokick-support in OWX_ASYNC einzubauen
Wenn man dokick=1 im OWX_ASYNC aktiviert hat, dann wird im Abstand des Attributs 'interval' (am OWX_ASYNC-device) die Temperaturwandlung für alle DS18B20 parallel angestoßen. Eine Sekunde später fangen dann alle OWTHERM-devices bei denen das Attribut 'tempconv' auf 'onkick' steht an die gewandelten Temperaturen asynchron auszulesen. Neu gegenüber OWX ist, dass das Auslesen auf die Wandlung zeitlich abgestimmt ist. Es empfiehlt sich keinen Mischbetrieb zu fahren, weil sonst bei den nicht über 'onkick' ausgelesenen DS18B20 die von OWX_ASYNC für alle gemeinsam gestartete Temperaturwandlung mit der vom OWTHERM in Konflikt kommen kann (das ist beim klassischen OWX nicht anders)....

Hallo Norbert,
Vielen Dank! Gleich mal getestet mit 1820 2438 2450 und 2406/8. Konnte keine Fehlfunktion feststellen, bis auf eine gewisse Trägheit der Switch auf den Schaltbefehl zu reagieren. Alle anderen Sensoren im 5s Intervall - prima! Wegen div. anderer Baustellen kann ich erst gegen Ende der Woche  mehr Zeit investieren. Wenn Du bestimmte Sachen getestet haben willst, schreib das bitte hier. Es liegen noch div. Hardware Parts ungenutzt rum.

[ntruchsess]

Den Fehler (der nur ein kosmetischer war), konnte ich grade beheben:

Code Auswählen Erweitern

2014.04.22 18:33:28 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reason

Dann noch ein falsches OWCOUNT_parseMidnight in OWCOUNT_ParseMidnight (übriggeblieben vom Merge mit Pahs Bereinigungen) gefixed.

... Und mit FRM getestet. Läuft (ohne jede Änderung am FRM) völlig unauffällig. Natürlich auch über Ethernet

Scheint Zeit zu werden, owx_async_protothreads ins SVN zu mergen.

Gruß,

Norbert

P.S.: Nur falls jemand testen wollte und die beschriebenen Fehler sind noch da: Ich habe grade (05.05.2014, 15:11 Uhr) gemerkt, dass ich die Änderungen gestern abend nicht auf Github gepushed habe. Habe ich grade nachgeholt.

[det.]

P.S.: Nur falls jemand testen wollte und die beschriebenen Fehler sind noch da: Ich habe grade (05.05.2014, 15:11 Uhr) gemerkt, dass ich die Änderungen gestern abend nicht auf Github gepushed habe. Habe ich grade nachgeholt.

ok, natürlich erst gelesen, als ich heute noch mal die Testergebnisse komentieren wollte - Fehlermeldung ist jetzt weg. Es geht soweit prima, auch LCD funktioniert, sofern die Aktualisierungsrate nicht zu ambitioniert eingestellt wird. Bei 5s flimmert es noch mal ordentlich und geht dann aus.
Da die Ansteuerbefehle für das asynchrone OWLCD sich völlig von den bisherigen unterscheiden gibt es da bei der produktiv Umstellung einiges an Arbeit - ich hoffe da sehr auf eine gute Dokumentation in der commandref - sonst wird das try and error.
Die OWSWITCH haben ein reading alarm, was es so im bisherigen OWX bei den Switches nicht gibt. Das steht auf 1 und erzeugt diese Log Einträge:

Code Auswählen Erweitern

2014.05.07 19:37:53 1:  Alarms = 12.4EF17B000000.B0 29.565713000000.CB
2014.05.07 19:37:33 1:  Alarms = 12.4EF17B000000.B0 29.565713000000.CB
2014.05.07 19:37:13 1:  Alarms = 12.4EF17B000000.B0 29.565713000000.CB
2014.05.07 19:36:53 1:  Alarms = 12.4EF17B000000.B0 29.565713000000.CB
2014.05.07 19:36:33 1:  Alarms = 12.4EF17B000000.B0 29.565713000000.CB
Wozu ist das gut und wie kann ich das abstellen?

[ntruchsess]

sofern die Aktualisierungsrate nicht zu ambitioniert eingestellt wird. Bei 5s flimmert es noch mal ordentlich und geht dann aus.

Schutz gegen Überlast ist noch nicht eingebaut. Wenn man zu viel scheduled, dann stauen sich die Protothread-objekte. Aber was bitte 'flimmert' da?

Code Auswählen Erweitern

2014.05.07 19:36:33 1:  Alarms = 12.4EF17B000000.B0 29.565713000000.CB
Wozu ist das gut und wie kann ich das abstellen?

Die DS2406/8 etc. antworten auf die Conditional Search (damit könnte man z.B. schneller auf Änderungen an den I/O-pins reagieren), dazu (sowohl zum Reagieren, als auch überhaupt die Conditional-search-condition festzulegen) ist aber noch keine Unterstützung in OWSWITCH eingebaut. Also 'nutzt nichts, schaded nichts'.

Abstellen aktuell nur, indem Du den Aufruf von OWX_ASYNC_Alarms in OWX_ASYNC, Zeile 839 auskommentierst.

Gruß,

Norbert

[det.]

Hallo Norbert,
Läuft wie schon geschrieben seit Sonntag prima, übrigens auf einem RPI mit dem Displayshield von locutus - an dem habe ich am internen (COC) DS2482 einen DS1820 über synchrones OWX und über USB ein Eigenbauinterface mit DS2480b und ASYNC OWX mit mehreren Devices. Geht also auch ohne Störung im Mischbetrieb. Das "flimmern" war die Hintergrundbeleuchtung (LED) des Displays kurz vor der Verabschiedung = dunkel und geht erst wieder nach dem nächsten Neustart. Das ist aber weg, seit ich Intervall von 5 auf 20 gestellt habe.
Was mir bei OWLCD außer den geänderten Ansteuerbefehlen noch auffällt, in den letzten synchronen Versionen war es nicht mehr nötig (wie früher immer), nach dem Neustart die Befehlsfolge set XXX lcd off ... on zu senden um alle 4 Zeilen zu initialisieren. Kannst Du das wieder einbauen?

[ntruchsess]

... Geht also auch ohne Störung im Mischbetrieb.

danke für das Feedback, ich habe den owx_async_protothreads-branch gerade ins SVN committed, damit steht die Version morgen per update zur Verfügung. Für das synchrone OWX sollte sich dadurch nix ändern.

Das "flimmern" war die Hintergrundbeleuchtung (LED) des Displays kurz vor der Verabschiedung = dunkel und geht erst wieder nach dem nächsten Neustart. Das ist aber weg, seit ich Intervall von 5 auf 20 gestellt habe.

Du meinst das 'interval'-attribut vom OWX_ASYNC? Das steuert nicht nur die Temperaturkonvertierung der OWTHERMs, es macht zusätzlich bei jedem Durchgang 2 Bussearches um present und alarm der Devices upzudaten. Möglicherweise kommt das OWLCD (das ist eine 1-Wire Softwarelösung auf einem PIC-µC) damit bei zu hohen Wiederholfrequenzen nicht mehr klar.

Was mir bei OWLCD außer den geänderten Ansteuerbefehlen noch auffällt, in den letzten synchronen Versionen war es nicht mehr nötig (wie früher immer), nach dem Neustart die Befehlsfolge set XXX lcd off ... on zu senden um alle 4 Zeilen zu initialisieren. Kannst Du das wieder einbauen?

hmm... kannst Du das präzisieren (welche SVN-revision-id) Du genau meinst, in der das ging und ab welchem commit nicht mehr?

Gruß,

Norbert

[det.]

..Du meinst das 'interval'-attribut vom OWX_ASYNC? Das steuert nicht nur die Temperaturkonvertierung der OWTHERMs, es macht zusätzlich bei jedem Durchgang 2 Bussearches um present und alarm der Devices upzudaten. Möglicherweise kommt das OWLCD (das ist eine 1-Wire Softwarelösung auf einem PIC-µC) damit bei zu hohen Wiederholfrequenzen nicht mehr klar.

ja, genau so wird es wohl sein

.hmm... kannst Du das präzisieren (welche SVN-revision-id) Du genau meinst, in der das ging und ab welchem commit nicht mehr?

auf dem Produktiv CUBIE2 ist noch

Code Auswählen Erweitern

# $Id: 21_OWLCD.pm 5538 2014-04-16 20:21:14Z ntruchsess $ damit geht es, bei

Code Auswählen Erweitern

# $Id: 21_OWLCD.pm 5789 2014-05-08 20:17:42Z ntruchsess $ zeigt es alle 4 Zeilen erst nach einem

Code Auswählen Erweitern

set <name> lcd onan, sonst nur die 1. und 3. Zeile total übersteuert. Das war in den Anfängen von OWLCD immer so und irgendwann dann mal weg.

[Prof. Dr. Peter Henning]

Na ja, mit den Versionen geht das im Moment ziemlich durcheinander 

Allerdings ist mir die Fehlerbeschreibung etwas undurchsichtig: Set LCD on schaltet den Controller ein - sonst wäre er aus. Die verwurstelten Zeilen deuten darauf hin, dass ein paar Parameter nicht stimmen. Aber was ist gemeint mit "übersteuert" ?

LG

pah

[det.]

Allerdings ist mir die Fehlerbeschreibung etwas undurchsichtig: Set LCD on schaltet den Controller ein - sonst wäre er aus. Die verwurstelten Zeilen deuten darauf hin, dass ein paar Parameter nicht stimmen. Aber was ist gemeint mit "übersteuert"

Hallo Peter,
Die Fehlerbeschreibung hatten wir vor 2 Jahren schon mal. Die billigen 4 Zeilen x 20 Zeichen China Displays zeig(ten) nach shutdown restart immer nur die 0.  und 2. Zeile sehr hell an - entsprechend nichts auf Zeile 1 und 3. Mit einem anschließenden set LCD on gehen dann alle 4 Zeilen. Das hatte ich über eine include.cfg gelöst, die es bei jedem Systemneustart einmal aufgerufen hat und die meine 2 Displays faktisch neu initialisiert hatten. Irgendwann letztes Jahr (mglw. nach einem Systemumzug auf andere Serverhardware) ging das dann ohne diese Klimmzüge.  Wenn da im Code nichts eingebaut wurde, liegt es mglw. an FB / RPI vs. Cubie2?

[Prof. Dr. Peter Henning]

I have a dream: Irgendwann in absehbarer Zukunft werden wir wenigstens die Frontendmodule auf einem ganz stabilen Stand haben.

Norbert Truchsess macht sehr gute Arbeit mit seinem Refactoring, die Zeit hätte ich in den nächsten 2-3 Jahren auf keinen Fall gehabt. Aber das führt halt im Moment dazu, dass die Versionen und branches etwas durcheinander gehen.

LG

pah

[det.]

I have a dream: Irgendwann in absehbarer Zukunft werden wir wenigstens die Frontendmodule auf einem ganz stabilen Stand haben.

Norbert Truchsess macht sehr gute Arbeit mit seinem Refactoring, die Zeit hätte ich in den nächsten 2-3 Jahren auf keinen Fall gehabt. Aber das führt halt im Moment dazu, dass die Versionen und branches etwas durcheinander gehen.

LG

pah

genau so wird es werden! Um diese gute Arbeit ein wenig zu unterstützen, liegt bei mir im Homeoffice ein Wirrwarr von 1-wire Zeugs rum als Testumgebung. Wenn ich also hier schreibe, was ggf. nicht so richtig geht, betrifft das immer diese Laborinstallation und soll nur helfen, diesen Traum schneller wahr werden zu lassen.

[cwagner]

Hi Norbert,

da die Heizperiode hier im Norden fast vorüber ist, riskiere ich den Einsatz von OWX_ASYMC mit OWTHERN,, OWAD und OWSwitch auf einem Produktivsystem. Der bisher erreichte Stand der Neuentwicklung ist beeindruckend. Die Systembelastung etwa 4% geringer, die Stabilität schon sehr erfolgversprechend.
Habe nun den Stand im SVN vom 8.5. eingespielt und dabei aber noch ein Problem:

Die Interval-Settings in den OWTHERM (bei mir 10 Sensoren mit Einstellungen zwischen 5 und 300 Sekunden, die meisten bei 30 Sekunden). Nach Neustart waren diese Einträge alle auf 9999. Per Set <name> interval habe ich sie auf die Werte gebracht, die ich brauche. (das jeweilige Attribut interval habe ich immer auf dem selben Wert wie das Settings-INGERVAL).
Die gesetzten Werte waren aber nach dem ersten Messwertupdate dann doch wieder auf 9999.
Das Thema habe ich nur in den Griff bekommen, als ich aus der Datensicherung die vorherige OWTHERM (Version V 5.1) ($Id: 21_OWTHERM.pm 5675 2014-04-27 09:03:47Z pahenning $) eingespielt habe.

Herzliche Grüße

Christian

[det.]

Hallo Christian,
Schau mal hier im Beitrag Post 120 an - dokick sollte das Problem lösen - bei mir ging es danach.

[cwagner]

Hallo det,
danke für den Anstoß, doch leider:
Den Beitrag 120 hatte ich im Sinn, bin aber noch einmal auf Nummer sicher gegangen und habe auch bei OWX_ASYNC dem folgend das Interval auf 30 Sekunden gestellt.
Im Test: OWTHERM version 5.16
Es bleibt dabei: Der state wird bei allen Sensoren nur einmal nach dem Neustart aktualisiert oder wenn ich von Hand Interval auf einen Wert # 9999 stelle, danach wird er nicht mehr aktualisiert. Ein get temperature funktioniert und ergibt jeweils eine richtige, neue Temperatur, aber es werden nicht fortlaufend und von selbst EVENTS erzeugt.

IM Fhem.log finde ich diese Fehlermeldungen:

Code Auswählen Erweitern

2014.05.11 10:33:04 3: OWX_DS2480: Search 2nd return has wrong parameter with length = 17
2014.05.11 10:33:05 5: OWX_ASYNC_PT_Kick: doing tempConv for OWAD, tempConv: -
2014.05.11 10:33:35 5: OWX_ASYNC_PT_Kick: doing tempConv for OWAD, tempConv: -
2014.05.11 10:33:36 1:  Alarms = 10.787E83020800.65 10.541E0B000800.35 10.0576A8020800.6D 28.905F9B010000.8B 28.A8A49B010000.11 28.CA0FAC040000.04 28.0E37AC040000.FD 28.AEE870010000.B6 28.1307AC040000.68 29.68980C000000.DA
2014.05.11 10:34:04 3: OWX_DS2480: Search 2nd return has wrong parameter with length = 17
2014.05.11 10:34:05 5: OWX_ASYNC_PT_Kick: doing tempConv for OWAD, tempConv: -


An meinem Bus hängen:

Code Auswählen Erweitern

OWX: 1-Wire devices found on bus OWio1
20.0C2C0C000000      DS2450         Umweltsensor
10.787E83020800      DS18S20/DS1920 T_Vorlauf_FBH
10.541E0B000800      DS18S20/DS1920 T_Warmwasser
10.0576A8020800      DS18S20/DS1920 T_Heizung
28.905F9B010000      DS18B20        Aussenluft
28.A8A49B010000      DS18B20        T_Ruecklauf_Anhebung
28.CA0FAC040000      DS18B20        Zuluft
28.0E37AC040000      DS18B20        Abluft
28.AEE870010000      DS18B20        Dachfenster_Sued
28.810671010000      DS18B20        T_Ruecklauf
28.1307AC040000      DS18B20        Fortluft
29.68980C000000      DS2408         Switch_Heizkeller

Edit: Neben dokick im OWX_ASYNC muss auch in den Geräten das Attribut tempConv auf "onkick" stehen.

Vielleicht hilft das bei der Aufklärung meines Problems...

lg
Christian

[hexenmeister]

Habe auch mal testweise dokick gesetzt. Alle intervale gingen auf 9999. Kurz nach dem manuellen ändern waren die wieder auf 9999.