OWX asynchron überarbeitet

[det.]

hab OWLCD 3.35 grade ins SVN committet. Die schlechte Performance beim Schreiben liegt nicht am Modul selbst, das kommt vom asynchronen Scheduling in der OWX_Executor.pm. Da arbeite ich jetzt dran. Stay tuned...

Gruß,

Norbert

habe gerade noch mal etwas getestet mit OWX_ASYNC - das Display soll auf 4 Zeilen jeweils einen Temperaturwert von 4 Stück DS1820 zeigen. Tut es auch, wird aber nicht in Echtzeit aktualisiert, sondern irgendwie stochastisch. Wenn man die Refreshrate auf dem Bus auf 5s erhöht, kommt das System total durcheinander - die Temperaturwerte der DS1820 werden spontan einem anderen Sensor zugewiesen, auf dem Display wird nach einem richtigen Wert auf einmal ein früherer Wert angezeigt etc. - gut zu sehen, wenn man einem der Sensoren richtig einheizt und die über 60°C dann immer mal auf einer anderen Zeile angezeigt werden...- auch im state der Sensoren...
Synchron funktioniert alles prima, auch nach heutiger Aktualisierung mit OWLCD 3.35 auf dem Produktivsystem mit 2 angeschlossenen Displays.

[AHA1805]

Hallo zusammen,

ich habe heute das Modul auch mal getestet und war begeistert, das alles gleich nach dem Ersetzen von

define OWio1 OWX /dev/ttyUSB0
durch
define OWio1 OWX_ASYNC/dev/ttyUSB0
sofort funktionierte.

Grund warum ich es gemacht habe:
Ich habe Perfmon getestet, welcher mir anzeigte, dass ich alle 5 Minuten (OWX Aktualisierungszeit) eine Verzögerung von bis zu 2 Sekunden habe.

Der Effekt nach der Umstellung war auch genial ich konnte mit Perfmon keine Verzögerung in fhem > 1 Sekunde feststellen 

BIS ...
ich begonnen habe einen anderen Fehler zu suchen (Codemirror funktionierte nicht, tut nichts zur Sache nur so am Rande)
dadurch musste ich den FHEM relativ oft starten.

Plötzlich lief FHEM nicht mehr hoch die CPU Last von perl lag bei 60-95% und im fhem.log stand immer als letzter Eintrag.
OWX_SER: Serial device /dev/ttyUSB0@9600 defined
Beispiel aus der Logdatei:

Code Auswählen Erweitern

2014.04.21 00:58:36 1: Including fhem.cfg
2014.04.21 00:58:37 2: Perfmon: ready to watch out for delays greater than one second
2014.04.21 00:58:37 3: telnetPort: port 1872 opened
2014.04.21 00:58:37 3: WEB: port 1883 opened
2014.04.21 00:58:37 3: WEBphone: port 1884 opened
2014.04.21 00:58:37 3: WEBtablet: port 1885 opened
2014.04.21 00:58:37 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.04.21 00:58:37 3: Opening HMLAN1 device 192.168.18.26:1000
2014.04.21 00:58:37 3: HMLAN1 device opened
2014.04.21 00:58:37 1: HMLAN_Parse: HMLAN1 new condition init
2014.04.21 00:58:37 3: Opening fbaha device 192.168.18.1:2002
2014.04.21 00:58:37 3: fbaha device opened
2014.04.21 00:58:37 1: FBAHA fbaha registered with handle: 00000017
2014.04.21 00:58:37 3: BBB_BMP180 BMP180: created
2014.04.21 00:58:37 3: Opening CUL_0 device /dev/ttyACM0
2014.04.21 00:58:37 3: Setting CUL_0 baudrate to 38400
2014.04.21 00:58:37 3: CUL_0 device opened
2014.04.21 00:58:37 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2014.04.21 00:58:45 3: OWTHERM: Device ow_2 defined.
2014.04.21 00:58:45 3: OWTHERM: Device ow_4 defined.
2014.04.21 00:58:45 3: OWTHERM: Device ow_1 defined.
2014.04.21 00:58:45 3: OWTHERM: Device ow_3 defined.
2014.04.21 00:58:45 3: OWMULTI: Device ow_m defined.
2014.04.21 00:58:45 3: OWCOUNT: Device ow_Counter defined.
2014.04.21 00:58:45 3: FHEM2FHEM opening ds1 at 192.168.18.1:1872
2014.04.21 00:58:45 3: FHEM2FHEM device opened (ds1)
2014.04.21 00:58:46 1: Including ./log/fhem.save
2014.04.21 00:58:46 3: Opening OWio1 device /dev/ttyUSB0
2014.04.21 00:58:46 3: Setting OWio1 baudrate to 9600
2014.04.21 00:58:46 3: OWio1 device opened
2014.04.21 00:58:46 1: OWX_SER: Serial device /dev/ttyUSB0@9600 defined



Komplette 1Wire Konfiguration

Code Auswählen Erweitern

define FileLog_ow_m FileLog ./log/ow_m-%Y.log ow_m
attr FileLog_ow_m disable 1
attr FileLog_ow_m room OWX
define OWio1 OWX /dev/ttyUSB0
attr OWio1 room OWX
define ow_2 OWTHERM DS1820 98CC70010800
attr ow_2 IODev OWio1
attr ow_2 alias Heizung Rücklauf
attr ow_2 event-on-change-reading state
attr ow_2 group _Heizung_
attr ow_2 model DS1820
attr ow_2 room OWX,Sensoren
attr ow_2 tempHigh 75
attr ow_2 tempLow 18
define ow_4 OWTHERM DS1820 F1CD70010800
attr ow_4 IODev OWio1
attr ow_4 event-on-change-reading state
attr ow_4 model DS1820
attr ow_4 room OWX,Sensoren
attr ow_4 tempHigh 75
attr ow_4 tempLow 18
define ow_1 OWTHERM DS1820 45D070010800
attr ow_1 IODev OWio1
attr ow_1 alias Heizung Vorlauf
attr ow_1 event-on-change-reading state
attr ow_1 group _Heizung_
attr ow_1 model DS1820
attr ow_1 room OWX,Sensoren
attr ow_1 tempHigh 65
attr ow_1 tempLow 18
define ow_3 OWTHERM DS1820 B7AD70010800
attr ow_3 IODev OWio1
attr ow_3 alias Temp Zählerschrank
attr ow_3 event-on-change-reading state
attr ow_3 model DS1820
attr ow_3 room OWX,Sensoren
attr ow_3 tempHigh 25
attr ow_3 tempLow 18

define ow_m OWMULTI DS2438 F47D9B000000
attr ow_m IODev OWio1
attr ow_m VFunction ((V/VDD - 0.1515) / 0.00636) / (1.0546 - 0.00216 *  T )
attr ow_m VName relHumidity|rH
attr ow_m VUnit percent|%
attr ow_m alias Heizraum
attr ow_m devStateStyle style="text-align:left;;;;font-weight:bold;;;;"
attr ow_m group _Heizung_
attr ow_m model DS2438
attr ow_m room OWX
attr ow_m stateFormat {sprintf("Luftfeuchte: %.1f \% Temperatur: %.1f C",ReadingsVal("ow_m","relHumidity",0), ReadingsVal("ow_m","temperature",0))}


define ow_Counter OWCOUNT DS2423 A2D984000005
attr ow_Counter AFactor 0.01
attr ow_Counter AMode daily
attr ow_Counter AName G-Energy|energy
attr ow_Counter AOffset 1067591
attr ow_Counter ARate G-Power|gas
attr ow_Counter AUnit kWh|kWh
attr ow_Counter BFactor 0.00125
attr ow_Counter BMode daily
attr ow_Counter BName E-Energy|energy
attr ow_Counter BOffset 12262851
attr ow_Counter BRate E-Power|power
attr ow_Counter BUnit kWh|kWh
attr ow_Counter IODev OWio1
attr ow_Counter alias Energie
attr ow_Counter group _Heizung_
attr ow_Counter model DS2423eold
attr ow_Counter nomemory 1
attr ow_Counter room OWX
attr ow_Counter stateFormat {sprintf("Strom:  %.3f kW/h [%.3f kW] Gas:  %.2f qm",ReadingsVal("ow_Counter","E-Energy",0), ReadingsVal("ow_Counter","E-Power",0),ReadingsVal("ow_Counter","G-Energy",0))}




list OWio1

Code Auswählen Erweitern

fhem> list OWio1
Internals:
   ALARMED    no
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0@9600
   FD         28
   INTERFACE  DS2480
   NAME       OWio1
   NOTIFYDEV  global
   NR         509
   NTFY_ORDER 50-OWio1
   PARTIAL
   PRESENT    1
   ROM_ID     FF
   STATE      Active
   TYPE       OWX
   followAlarms off
   interval   300
   ALARMDEVS:
   DEVS:
     10.98CC70010800.9D
     10.45D070010800.4E
     10.B7AD70010800.D3
     26.F47D9B000000.3B
     1D.A2D984000005.B4
   Readings:
     2014-04-21 01:01:02   state           defined
Attributes:
   room       OWX


Erst nachdem ich wieder auf OWX umstellte funktionierte es wieder.

Diesen Fehler konnte ich ab jetzt auch immer reproduzieren, wobei mir nicht klar ist, warum es zuerst für ein paar Stunden einwandfrei funktionierte.

Gruß Hannes

[ntruchsess]

Diesen Fehler konnte ich ab jetzt auch immer reproduzieren, wobei mir nicht klar ist, warum es zuerst für ein paar Stunden einwandfrei funktionierte.

Das habe ich gerade gefixed. Lag daran, dass der DS2480 in manchen Fällen nicht auf das initiale Reset-kommando reagiert plus eine fehlerhafte implementierung des Read-timeout im OWX_SER. Jetzt forciere ich beim Initialisieren erst mal einen Master-reset des DS2480 (und der Timeout geht...).

Gruß,

Norbert

[AHA1805]

Hallo Norbert,

danke werde ich heute abend mal testen und dann berichten

Gruß Hannes

Gesendet von Unterwegs mit Tapatalk 4

Nachtrag : 21:57:
Habe es gerade getestet funktioniert bisher wie beim ersten Mal sofort   
werde es mal beobachten.
Gruss und Danke Hannes

[AHA1805]

Guten Morgen

Kann diese Fehlermeldung    "Invalid conversion in ..." von OWX_ASYNC kommen?

Code Auswählen Erweitern



2014.04.22 06:55:40 5: OWX_Executor: item ds2438.writestatusvdd for 26.F47D9B000000.3B eligible to run
2014.04.22 06:55:40 5: schedule next item at 1398142539.1799613 -0.526886
2014.04.22 06:55:40 5: schedule next item at 1398142539.1799613 -0.520006
2014.04.22 06:55:40 5: schedule next item at 1398142539.1799613 -0.512528
2014.04.22 06:55:40 5: AfterExecute: context: ds2438.writestatusvdd, success: 1, reset: 1, owx_dev: 26.F47D9B000000.3B, writedata: 4e0008, numread: 0, readdata:
Invalid conversion in sprintf: "% T" at (eval 41859) line 1.
2014.04.22 06:55:40 5: Triggering ow_m (1 changes)
2014.04.22 06:55:40 5: Notify loop for ow_m PRESENT: 1
2014.04.22 06:55:40 5: schedule next item at 1398142539.1799613 -0.462964
2014.04.22 06:55:40 5: OWX_Executor: item ds2438.copyscratchpadvdd for 26.F47D9B000000.3B eligible to run
2014.04.22 06:55:40 5: schedule next item at 1398142539.1799613 -0.377856
2014.04.22 06:55:40 5: schedule next item at 1398142539.1799613 -0.371303
2014.04.22 06:55:40 5: schedule next item at 1398142539.1799613 -0.364328
2014.04.22 06:55:40 5: AfterExecute: context: ds2438.copyscratchpadvdd, success: 1, reset: 1, owx_dev: 26.F47D9B000000.3B, writedata: 4800, numread: 0, readdata:
Invalid conversion in sprintf: "% T" at (eval 41860) line 1.



Da weder eine Zeilennummer noch sonst was dabei steht.

Schöne grüße
Hannes

Gesendet von Unterwegs mit Tapatalk 4

[ntruchsess]

Kann diese Fehlermeldung    "Invalid conversion in ..." von OWX_ASYNC kommen?

Code Auswählen Erweitern


Invalid conversion in sprintf: "% T" at (eval 41859) line 1.
2014.04.22 06:55:40 5: Triggering ow_m (1 changes)


Vom OWX_ASYNC direkt nicht, hast Du beim 'ow_m'-device ein stateFormat gesetzt?

[ntruchsess]

so, die nächste Evolutionsstufe ist erreicht:

Ich habe den asynchronen code aller anderen Devices und das Scheduling von OWX_ASYNC auf ProtoThreads umgestellt. Das garantiert die individuelle Nichtunterbrechbarkeit einer Abfolge von 1-Wire Kommandos pro Device und vereinfacht den asynchronen code deutlich. Damit sollte das Problem der Raceconditions bei 1-Wire-Befehlsfolgen von Aktoren behoben sein.

Da ich ab morgen bis Sonntag unterwegs bin habe ich den noch ofenfrischen code noch nicht ins SVN committed, sondern auf Github im branch 'owx_async_protothreads' abgelegt (Muss also manuell installiert werden). Von mir bisher nur mit DS2480 getestet.

00_OWX_ASYNC.pm
OWX_Executor.pm
OWX_SER.pm
OWX_DS2480.pm
21_OWAD.pm
21_OWCOUNT.pm
21_OWLCD.pm
21_OWMULTI.pm
21_OWSWITCH.pm
21_OWTHERM.pm

Wen es interessiert: ProtoThreads sind leichtgewichtige Pseudothreads. Also keine echten Threads, sondern eigentlich normale Methoden die im Kontext des aufrufenden Threads laufen und immer dann, wenn sie Rechenzeit abgeben sollen die Methode mit einem Returnwert von PT_WAITING oder PT_YIELD verlassen. Man ruft die Methode so lange immer wieder mit PT_SCHEDULE auf bis sie zu Ende gelaufen oder (per PT_EXIT) vorzeitig verlassen worden ist. Dahinter arbeitet im Verborgenen eine Statemachine, die dafür sorgt, dass beim Aufruf der Methode von der Stelle PT_BEGIN an den Punkt des jeweils letzten Verlassens gesprungen wird.
Hier ein Beispiel mit 3 quasiparalell laufenden Protothreads, das zeigt, was so geht.

Die berüchtigte 1-Sekunden Pause vom OWTHERM sieht mit Protothreads so aus.

Gruß,

Norbert

[AHA1805]

Hallo Norbert
Mercie für die Antwort.
Ja habe ich, kann es hier Probleme bei der asynchronen Version geben?

Code Auswählen Erweitern


1
fhem>
fhem>
fhem> list ow_m
Internals:
   ASYNC      1
   DEF        DS2438 F47D9B000000
   INTERVAL   300
   IODev      OWio1
   NAME       ow_m
   NR         515
   OW_FAMILY  26
   OW_ID      F47D9B000000
   PRESENT    1
   ROM_ID     26.F47D9B000000.3B
   STATE      Luftfeuchte: 50.9 % Temperatur: 16.4 C
   TYPE       OWMULTI
   Readings:
     2014-04-22 18:45:47   PRESENT         1
     2014-04-22 18:45:47   VDD             5.07
     2014-04-21 21:56:20   present         0
     2014-04-22 18:45:47   relHumidity     50.877
     2014-04-22 18:45:47   state           relHumidity: 50.88 % (T: 16.44 °C)
     2014-04-22 18:45:47   temperature     16.4375
   owg_val:
     16.4375
     5.07
     2.44
   Tempf:
     factor     1
     offset     0
Attributes:
   IODev      OWio1
   VFunction  ((V/VDD - 0.1515) / 0.00636) / (1.0546 - 0.00216 *  T )
   VName      relHumidity|rH
   VUnit      percent|%
   alias      Heizraum
   devStateStyle style="text-align:left;;font-weight:bold;;"
   group      _Heizung_
   model      DS2438
   room       OWX
   stateFormat {sprintf("Luftfeuchte: %.1f \% Temperatur: %.1f C",ReadingsVal("ow_m","relHumidity",0), ReadingsVal("ow_m","temperature",0))}

fhem>




Gesendet von Unterwegs mit Tapatalk 4

[det.]

Hallo Norbert,
Danke für die neuen Testkandidaten. Gleich eingespielt auf dem Testsystem mit:

Code Auswählen Erweitern


OWX: 1-Wire devices found on bus 1wire_0
20.70C707000000      DS2450         OWX_20_70C707000000
20.B7CB07000000      DS2450         OWX_20_B7CB07000000
28.F213DD030000      DS18B20        OWX_28_F213DD030000
28.76B82A040000      DS18B20        OWX_28_76B82A040000
28.EE81DA030000      DS18B20        OWX_28_EE81DA030000
28.1B7BDA030000      DS18B20        OWX_28_1B7BDA030000
12.4EF17B000000      DS2406/DS2507  OWX_12_4EF17B000000
29.565713000000      DS2408         OWX_29_565713000000
FF.430800000100      LCD            OWX_FF_430800000100OWAD bringt regelmäßig Werte und bei OWSWITCH lassen sich die Ausgänge jetzt schalten, alles mit 5s Takt und ohne Verzögerung! OWLCD zeigt pah's Testsequenz auch jetzt in Echtzeit ohne Wartepausen an, aber:

Code Auswählen Erweitern

2014.04.22 18:15:39 3: W_LCD02 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:39 3: W_LCD02 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:39 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:39 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:38 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:35 3: W_LCD02 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:35 3: W_LCD02 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:34 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:34 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:29 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:29 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:25 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.
2014.04.22 18:15:25 3: W_LCD01 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.es gibt folgende Fehlermeldung im LOG:

Code Auswählen Erweitern

2014.04.22 18:33:28 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reason
2014.04.22 18:33:28 3: OWSWITCH: Could not get values from device OWX_29_565713000000, reason
2014.04.22 18:33:23 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reason
2014.04.22 18:33:23 3: OWSWITCH: Could not get values from device OWX_29_565713000000, reason
2014.04.22 18:33:18 3: OWSWITCH: Could not get values from device OWX_29_565713000000, reason
2014.04.22 18:33:18 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reason
2014.04.22 18:33:15 3: OWSWITCH: Could not get values from device OWX_29_565713000000, reason
2014.04.22 18:33:13 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reason
2014.04.22 18:33:10 3: OWSWITCH: Could not get values from device OWX_29_565713000000, reason
2014.04.22 18:33:08 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reason
2014.04.22 18:33:03 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reason
2014.04.22 18:32:58 3: OWSWITCH: Could not get values from device OWX_29_565713000000, reason
2014.04.22 18:32:58 3: OWSWITCH: Could not get values from device OWX_12_4EF17B000000, reasonwobei die Switch auf set output A off / on sofort und richtig reagieren. Dafür machen die Thermometer nicht mehr was sie sonst schon mal prima gebracht haben (die Temperaturwerte der Sensoren liest es nicht aus) siehe zb wie hier:

Code Auswählen Erweitern

Readings
alarm 0       2014-04-22 20:02:25
present 1     2014-04-22 20:02:25
state T: 20.38 °C  2014-04-22 19:43:49
temperature 20.375 2014-04-22 19:43:49

[ntruchsess]

Ja habe ich, kann es hier Probleme bei der asynchronen Version geben?

Code Auswählen Erweitern


stateFormat {sprintf("Luftfeuchte: %.1f \% Temperatur: %.1f C",ReadingsVal("ow_m","relHumidity",0), ReadingsVal("ow_m","temperature",0))}


Merkwürdig, irgendwie stört sich das sprintf an dem '% T' da drin (obwohl das % mit \ escaped ist). Aber funktioniert scheint ja (Siehe Reading 'STATE') trotzdem zu haben. Hat aber mit dem ASYNC an sich nix zu tun.

[det.]

Merkwürdig, irgendwie stört sich das sprintf an dem '% T' da drin (obwohl das % mit \ escaped ist). Aber funktioniert scheint ja (Siehe Reading 'STATE') trotzdem zu haben. Hat aber mit dem ASYNC an sich nix zu tun.

Diesen Fehler zeigt es mir auf der Konsole auch nach Serverneustart immer paar mal an. Das lässt sich leicht beheben, durch Weglassen des Prozentzeichens nach dem Luftfeuchtewert. Das wiederum sieht aber in FHEMWEB Sch... aus. Daher ein Leben mit dieser Kleinigkeit ist möglich und FHEM stürzt wegen diesem Schönheitsfehler nicht ab.

[ntruchsess]

Hallo det,

danke schon mal für's Feedback!

OWLCD zeigt pah's Testsequenz auch jetzt in Echtzeit ohne Wartepausen an, aber:

Code Auswählen Erweitern

2014.04.22 18:15:39 3: W_LCD02 return value: Can't call method "baudrate" on an undefined value at ./FHEM/00_OWX.pm line 1492.


wie ist "W_LCD02" definiert? Machst Du da direkte Aufrufe von OWXLCD_xxx-methoden? Wenn ja, dann darfst Du ausschließlich die OWLCD_xxx (ohne 'X')-methoden nehmen, die mit 'X' sind Backendspezifisch.

es gibt folgende Fehlermeldung im LOG:

Code Auswählen Erweitern

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

wobei die Switch auf set output A off / on sofort und richtig reagieren.

Kannst Du die Fehlermeldung mit einer bestimmten Aktion korreklieren?

Dafür machen die Thermometer nicht mehr was sie sonst schon mal prima gebracht haben (die Temperaturwerte der Sensoren liest es nicht aus) siehe zb wie hier:

Code Auswählen Erweitern

Readings
alarm 0       2014-04-22 20:02:25
present 1     2014-04-22 20:02:25
state T: 20.38 °C  2014-04-22 19:43:49
temperature 20.375 2014-04-22 19:43:49

Passiert das auch mit einem kleineren Testsetup (nur 1 DS18B20)? Stell mal global verbose 5 an (mit der minimal zum Reproduzieren des Fehlers nötigen Anzahl an Devices), damit man sieht, ob die Sensoren überhaupt korrekt angesprochen werden. Passiert da mit einem DS2480 als Busmaster oder FRM? (Letzteres konnte ich noch nicht Testen)

Gruß,

Norbert

[det.]

wie ist "W_LCD02" definiert? Machst Du da direkte Aufrufe von OWXLCD_xxx-methoden? Wenn ja, dann darfst Du ausschließlich die OWLCD_xxx (ohne 'X')-methoden nehmen, die mit 'X' sind Backendspezifisch.

war falsch mit X definiert - jetzt geändert

Code Auswählen Erweitern

define W_LCD02 notify OWX_28_EE81DA030000 {OWLCD_SetLine($defs{'OWX_FF_430800000100'},2,"Buerotemp:   ".(int($defs{'OWX_28_EE81DA030000'}{READINGS}{temperature}{VAL}*10)/10)." \xDFC")} und neue Meldung:

2014.04.23 17:08:07 3: W_LCD01 return value: Undefined subroutine &main::OWLCD_SetLine called at (eval 810) line 1.
2014.04.23 17:08:07 3: W_LCD01 return value: Undefined subroutine &main::OWLCD_SetLine called at (eval 809) line 1.
2014.04.23 17:08:20 3: W_LCD02 return value: Undefined subroutine &main::OWLCD_SetLine called at (eval 838) line 1.
2014.04.23 17:08:20 3: W_LCD02 return value: Undefined subroutine &main::OWLCD_SetLine called at (eval 837) line 1.

Kannst Du die Fehlermeldung mit einer bestimmten Aktion korreklieren?

- nein

Passiert das auch mit einem kleineren Testsetup (nur 1 DS18B20)? Stell mal global verbose 5 an (mit der minimal zum Reproduzieren des Fehlers nötigen Anzahl an Devices), damit man sieht, ob die Sensoren überhaupt korrekt angesprochen werden.

bei 2x DS1820 dto.

Code Auswählen Erweitern

2014.04.23 17:35:54 4: HTTP FHEMWEB:192.168.2.47:49517 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2014-04.log
2014.04.23 17:35:54 5: OWX_Executor: command 1 eligible to run
2014.04.23 17:35:54 4: Connection closed for FHEMWEB:192.168.2.47:49484
2014.04.23 17:35:48 5: AfterExecute: context: kick, success: 1, reset: 1, owx_dev: undef, writedata: cc44, numread: 0, readdata:
2014.04.23 17:35:48 5: OWX_Executor: item kick for  eligible to run
2014.04.23 17:35:34 1:  Alarms = FF.FFFFFFFFFFFF.FF
2014.04.23 17:35:34 5: OWX_SER::Search: new alarm device found FF.FFFFFFFFFFFF.FF
2014.04.23 17:35:34 5: OWX_Executor: command 2 eligible to run
2014.04.23 17:35:28 5: OWX_Executor: command 1 eligible to run
2014.04.23 17:35:18 5: AfterExecute: context: kick, success: 1, reset: 1, owx_dev: undef, writedata: cc44, numread: 0, readdata:
2014.04.23 17:35:18 5: OWX_Executor: item kick for  eligible to run
2014.04.23 17:35:05 4: HTTP FHEMWEB:192.168.2.47:49484 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=×tamp=1398267302885

Passiert da mit einem DS2480 als Busmaster oder FRM? (Letzteres konnte ich noch nicht Testen)

DS2480

[ntruchsess]

Hallo Detlef,

war ja ein paar Tage unterwegs und bin jetzt etwas unter Wasser. Komme daher leider erst heute zum Antworten:

2014.04.23 17:08:07 3: W_LCD01 return value: Undefined subroutine &main::OWLCD_SetLine called at (eval 810) line 1.

wo er recht hat, hat er recht. ein OWLCD_SetLine gibts nicht. Aber ein 'OWLCD_Set' mit parameter 'line'. Also etwa so:

Code Auswählen Erweitern

define W_LCD02 notify OWX_28_EE81DA030000 {OWLCD_Set($defs{'OWX_FF_430800000100'},"line","2 Buerotemp:   ".(int($defs{'OWX_28_EE81DA030000'}{READINGS}{temperature}{VAL}*10)/10)." \xDFC")}

Code Auswählen Erweitern

2014.04.23 17:35:48 5: AfterExecute: context: kick, success: 1, reset: 1, owx_dev: undef, writedata: cc44, numread: 0, readdata:
2014.04.23 17:35:48 5: OWX_Executor: item kick for  eligible to run


an das Attribut 'dokick' vom OWX_ASYNC bzw. dem Zusammenspiel der OWTHERM-module mit selbigem muss ich noch ran, das ist noch nicht auf Protothreads umgebaut. Probier es bitte mal ohne bzw. Wert 0, dann machen die OWTHERMs das Timing inkl. der Temperaturmesspause komplett selber.

Gruß,

Norbert

[ntruchsess]

an das Attribut 'dokick' vom OWX_ASYNC bzw. dem Zusammenspiel der OWTHERM-module mit selbigem muss ich noch ran, das ist noch nicht auf Protothreads umgebaut.

Soderla... hab grade meine Zugfahrt nach Hause dazu benutzt 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).

Zur Installation wie gehabt die Dateien aus dem owx_async_protothreads-branch auf Github herunterladen (wie die Version von letzter Woche bisher nur mit DS2480 getestet, ich bin unterwegs und habe nur minimal Hardware dabei...):

00_OWX_ASYNC.pm
OWX_Executor.pm
OWX_SER.pm
OWX_DS2480.pm
21_OWAD.pm
21_OWCOUNT.pm
21_OWLCD.pm
21_OWMULTI.pm
21_OWSWITCH.pm
21_OWTHERM.pm

Ich bin ab heute abend wieder zu Hause und kann habe endlich mal die Zeit den owx_async_prothreads-branch eingehender (und endlich auch mal die FRM-unterstützung) zu testen um es dann in das FHEM-SVN mergen zu können. Vielen Dank schon mal an alle, die mir testenderweise zuarbeiten!

Gruß,

Norbert