1-Wire OWX Update 4.4.2013

[Prof. Dr. Peter Henning]

So, habe mal wieder ein kleines Update der 21_OW... Module vorgenommen.

Bereinigt wurde ibs. 21_OWCOUNT.pm, das Problem mit den wechselnden Mitternachtseinträgen sollte behoben sein. Sonst keine nennenswerten Änderungen.

Im Backend hat sich Einiges getan, Norbert Truchsess und ich haben 00_OWX.pm von den hardwarespezifischen Funktionen für USB, COC/CUNO und Arduino getrennt. Das Einchecken dieser neuen Backendmodule wird aber erst in Kürze erfolgen.

LG

pah

[UweH]

OK, Danke, wird getestet.

[det.]

hallo pah,
danach ging der RPI auf Tauchstation:

Code Auswählen Erweitern

2013.04.04 23:58:38 1: OWCOUNT_GetMonth: Attribute LogM is missing

[Prof. Dr. Peter Henning]

Das kann zwar zu einer Fehlermeldung führen, aber sicher nicht zum Absturz des RPI.

Die einfachste Abhilfe ist zunächst, das Attribut LogM zu setzen ...

Ich werde die Fehlermeldung abfangen, dauert aber bis heute abend.

LG

pah

[Alexander Bauer]

Hallo,

bei mir ist FHEM auch auf Tauchstation gegangen. Ich werde jetzt das LogM setzen.

[Prof. Dr. Peter Henning]

Ich habe eine modifizierte Version, dies diesen Fehler abfängt, ins SVN repository eingestellt.

LG

pah

[det.]

Hallo pah,
vielen Dank, es geht jetzt wie gewünscht. Habe neue Meldungen seit dem Update von OWX im LOG, kanst Du mir dazu einen Tip geben?

Code Auswählen Erweitern

2013.04.06 13:02:46 1:  testing A against A and A
2013.04.06 13:03:01 1:  testing A against A and A
2013.04.06 13:07:46 1:  testing A against A and ADie haben sicher weniger mit Deinen Modulen zu tun, ich tippe auf eine Unsauberkeit im Zusammenhang mit Heating Control, wo ein OWSwitch am Schaltung und Fensterüberwachung beteiligt ist. Aber die Meldungen kommen exakt seit dem Update.
Danke!

[Prof. Dr. Peter Henning]

Ups, das ist doch meine Schuld - bei den diversen Fehlerbereinigungen habe ich vergessen, eine Zeile "Log 1, ..." bei ca. Zeile 610 in OWSWITCH.pm wieder auszukommentieren. Bitte einfach diese Zeile mit dem "testing" herauswerfen - sonst füllt sich das Logfile.

Ich habe eine bereinigte Version gerade eben eingecheckt.

LG

pah

[det.]

Danke, da bin ich ja beruhigt. Dann hatte ich den Fehler mit der Endlosschleife bei Heating Control doch vorgestern mit Erfolg beseitigt.

[Joachim]

(siehe Anhang / see attachement)Moin Prof.,
kann es sein, dass Du bei der Initialisierung von OWX / OWMULTI etwas verschlimmbessert hast?

bis zum 4.4. ist die Kurve bei einem ShutdownRestart nicht zusammengebrochen (siehe Bild)

gruß Joachim

[det.]

dto.(siehe Anhang / see attachement)

[Prof. Dr. Peter Henning]

Ist in der Tat passiert. Habe ich auch schon behoben - aber da ich die ganze Initialisierung umgebaut habe, wollte ich eigentlich noch weiter testen.

Ich stelle das neue OWMULTI aber mal spaßeshalber schon vorab ins SVN.

LG

pah

[det.]

Hallo pah,
wir testen doch immer gern. Die früheren Meckerer haben sich ja inzwischen anderen Alternativen zugewandt und merken nicht, wenn mal bei einer Zwischenversion was nicht ganz so funktioniert. OWMULTI macht es jetzt wie gewünscht - vielen Dank! Stell es also bitte rein, wenn Du was Neues hast.
Deine Module werden jetzt wichtiger denn je, wenn sich die geniale Anbindung über Ardunio rumspricht. Das bringt uns einerseits einen Busmaster für nur 9 EUR, der andererseits noch den FHEM Server vom polling der 1-wire Sensoren entlastet.

[Joachim]

Moin Prof.,

Update gemacht, rennt wieder.

Danke Joachim

[Tobias]

Hi,
habe gestern ein Update gemacht und nun folgende Fehlemeldungen nach FHEM-Start:

Code Auswählen Erweitern

Scalar value @monthv[0] better written as $monthv[0] at ./FHEM/21_OWCOUNT.pm line 481, <$fh> line 487.
Scalar value @monthv[1] better written as $monthv[1] at ./FHEM/21_OWCOUNT.pm line 482, <$fh> line 487.
Scalar value @monthv[0] better written as $monthv[0] at ./FHEM/21_OWCOUNT.pm line 484, <$fh> line 487.
[...]
Argument "5699.000000^P^AM-^?M-^?M-\0\0M-?M-^?\0^AM-}M--^H\0^?^?^H..." isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1168.
Argument "5428.000000^P^BM-7M-}^Q^PM-^?M-^?M-\0\0M-_M-_\0@M-z^?\0^A..." isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1175.
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWCOUNT.pm line 803.
Argument "" isn't numeric in sprintf at ./FHEM/21_OWMULTI.pm line 338.
[...]
Argument "" isn't numeric in numeric lt (<) at ./FHEM/21_OWTHERM.pm line 950.
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 09:20:31.004 1: +++++++++> Alarm enabling for 1wire_Hub channel 0 is 0 0  2.54
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 09:20:31.005 1: +++++++++> Alarm enabling for 1wire_Hub channel 1 is 0 0  2.54
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 09:20:31.006 1: +++++++++> Alarm enabling for 1wire_Hub channel 2 is 0 0  2.54
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 09:20:31.007 1: +++++++++> Alarm enabling for 1wire_Hub channel 3 is 0 0  2.54
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value $ret1 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
Use of uninitialized value $ret2 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
2013.04.12 09:20:31.344 1: Status return
2013.04.12 09:20:33.997 1: +++++++++> Alarm enabling for Wasserdruck channel 0 is 0 0 0 2.54
2013.04.12 09:20:33.998 1: +++++++++> Alarm enabling for Wasserdruck channel 1 is 0 0 0 2.54
2013.04.12 09:20:33.999 1: +++++++++> Alarm enabling for Wasserdruck channel 2 is 0 0 0 2.54
2013.04.12 09:20:33.000 1: +++++++++> Alarm enabling for Wasserdruck channel 3 is 0 0 0 2.54
Use of uninitialized value $ret1 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
Use of uninitialized value $ret2 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
2013.04.12 09:20:34.335 1: Status return
2013.04.12 09:20:36.874 1: +++++++++> Alarm enabling for Bodenfeuchte channel 0 is 0 0 0 0.14
2013.04.12 09:20:36.874 1: +++++++++> Alarm enabling for Bodenfeuchte channel 1 is 0 0 0 0.14
2013.04.12 09:20:36.875 1: +++++++++> Alarm enabling for Bodenfeuchte channel 2 is 0 0 0 0.14
2013.04.12 09:20:36.876 1: +++++++++> Alarm enabling for Bodenfeuchte channel 3 is 0 0 0 5
Use of uninitialized value $ret1 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
Use of uninitialized value $ret2 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
2013.04.12 09:20:37.212 1: Status return


[Prof. Dr. Peter Henning]

Die Fehlermeldungen, die angeblich aus OWCOUNT stammen, verwundern mich etwas - denn die Zeilennummern können nicht stimmen. Zeile 1168 z.B. enthält keine Multiplikation. Sicher, dass die richtige Version installiert ist ? Kann man mit get <name> version abfragen, sollte 3.23 sein.

Die Logmeldungen beim Start von OWAD sind beabsichtigt, daran feile ich gerade etwas herum.

LG

pah

[Tobias]

hab mal einen kompletten Restart gemacht:

Code Auswählen Erweitern

Wasserzaehler.version => 3.23

Code Auswählen Erweitern

2013.04.12 12:56:03.545 1: OWX: 1-Wire devices found on bus 1wireBus (Wasserdruck,1wire_Hub,Heizung_Steuerung,Keller_Terrasse_Temperatur2,Schalter_links,Schalter_rechts,Wasserzaehler)
Argument "5699.000000^P^AM-^?M-^?M-\0\0M-?M-^?\0^AM-}M--^H\0^?^?^H..." isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1175.
Argument "5428.000000^P^BM-7M-}^Q^PM-^?M-^?M-\0\0M-_M-_\0@M-z^?\0^A..." isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1182.
Argument "" isn't numeric in numeric lt (<) at ./FHEM/21_OWTHERM.pm line 950.
Argument "" isn't numeric in sprintf at ./FHEM/21_OWMULTI.pm line 338.
2013.04.12 12:57:03.949 1: OWX: 1-Wire devices found on bus 1wireMp00202 (Bodenfeuchte,Gaestezimmer_Raumtemp,Oelkeller_Raumtemp,BadezimmerKG_Raumtemp,Naehzimmer_Raumtemp,Heizung_Raumtemp,Waschkueche_Raumtemp,Garage_Raumtemp,Keller_Eingangstuer_Raumtemp,BadezimmerKG_Fenster,Heizung_Fenster,Oelkeller_Fenster,Garage_Tor,Gaestezimmer_Fenster,Naehzimmer_Fenster,Garage_Tuer,Waschkueche_Fenster,Garage_Fenster,Oelkeller_Tuer,Keller_Eingangstuer,OWX_01_932E7B140000)
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 12:57:04.854 1: +++++++++> Alarm enabling for 1wire_Hub channel 0 is 0 0  2.54
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 12:57:04.854 1: +++++++++> Alarm enabling for 1wire_Hub channel 1 is 0 0  2.54
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 12:57:04.855 1: +++++++++> Alarm enabling for 1wire_Hub channel 2 is 0 0  2.54
Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWAD.pm line 768.
2013.04.12 12:57:04.856 1: +++++++++> Alarm enabling for 1wire_Hub channel 3 is 0 0  2.54
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value within @owg_vlow in multiplication (*) at ./FHEM/21_OWAD.pm line 1341.
Use of uninitialized value $ret1 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
Use of uninitialized value $ret2 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
2013.04.12 12:57:05.193 1: Status return
2013.04.12 12:57:07.778 1: +++++++++> Alarm enabling for Wasserdruck channel 0 is 0 0 0 2.54
2013.04.12 12:57:07.779 1: +++++++++> Alarm enabling for Wasserdruck channel 1 is 0 0 0 2.54
2013.04.12 12:57:07.780 1: +++++++++> Alarm enabling for Wasserdruck channel 2 is 0 0 0 2.54
2013.04.12 12:57:07.780 1: +++++++++> Alarm enabling for Wasserdruck channel 3 is 0 0 0 2.54
Use of uninitialized value $ret1 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
Use of uninitialized value $ret2 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
2013.04.12 12:57:08.116 1: Status return
2013.04.12 12:57:10.657 1: +++++++++> Alarm enabling for Bodenfeuchte channel 0 is 0 0 0 0.14
2013.04.12 12:57:10.658 1: +++++++++> Alarm enabling for Bodenfeuchte channel 1 is 0 0 0 0.14
2013.04.12 12:57:10.659 1: +++++++++> Alarm enabling for Bodenfeuchte channel 2 is 0 0 0 0.14
2013.04.12 12:57:10.660 1: +++++++++> Alarm enabling for Bodenfeuchte channel 3 is 0 0 0 5
Use of uninitialized value $ret1 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
Use of uninitialized value $ret2 in concatenation (.) or string at ./FHEM/21_OWAD.pm line 783.
2013.04.12 12:57:10.995 1: Status return


Ich habe also Fehler in
OWMULTI: 338
OWAD: 768, 783, 1341
OWCOUNT: 1175,1182
OWTHERM: 950

Grüsse

[Philipp]

Hallo pah,

erstmals vielen Dank für deine Module, laufen bei mir mit einem CUNO wirklich super. Ich habe nur eine Frage zum ERRCOUNT in der 21_OWTHERM.pm.

Ich habe im Moment 4 Temperatursensoren und einen Atmel als 1Wire Zähler. Daten kommen rein, 1 Sensor mit 300s und die anderen 3 mit 60s. Hat alles funktioniert,
nur am nächsten Tag kamen dann keine Werte mehr an.
Intervall war auf 9999, Ursache gesucht, ERRCOUNT gefunden. Meine Frage: Wäre es sinnvoll ERRCOUNT wieder auf 0 zu setzen wenn wieder gültige Werte kommen?
Sicher sollte ein 1-Wire Netzwerk keine Fehler produzieren, aber früher oder später sind die 5 Fehler erreicht.

Danke
Philipp

[Prof. Dr. Peter Henning]

Erstens interessiert mich, welche Firmware Version der CUNO hat - mit meinem eigenen CUNO kämpfe ich nämlich sehr :-((.

Zweitens: Ich arbeite gerade an einem Mechanismus, der genau das leisten soll: Wenn das 1-Wire Netz mal ausgefallen ist, wird nach gewissen Abständen versucht,das Ding wieder in Betrieb zu nehmen.
Damit wird sich auch das mit dem ERRCOUNT ändern. Dauert aber noch eine Weile - also Zwischenlösung: Aus der 5 eine 5000 machen.

Drittens: Hm, wieso sollte das 1-Wire Netz ab und zu Fehler produzieren ?? Passiert normalerweise nicht.

LG

pah

[Philipp]

jetzt hab ich auch schon den Grund der Fehler gefunden. Der CUNO trennt die Verbindung und dann kommts logischerweise zu den Fehlern.

Code Auswählen Erweitern

2013.04.13 18:27:13 1: 192.168.1.9:2323 disconnected, waiting to reappear
2013.04.13 18:27:21 3: OWTHERM: Could not get values from device Temp.Speicher for 5 times, reason invalid data length, 1 instead of 10 bytes
2013.04.13 18:28:27 3: OWTHERM: Could not get values from device Temp.Vorlauf for 4 times, reason invalid data length, 1 instead of 10 bytes
2013.04.13 18:28:31 3: OWTHERM: Could not get values from device Temp.Warmwasser for 5 times, reason invalid data length, 1 instead of 10 bytes
2013.04.13 18:28:34 3: OWTHERM: Could not get values from device Temp.Keller for 4 times, reason invalid data length, 1 instead of 10 bytes
2013.04.13 18:28:37 3: OWTHERM: Could not get values from device Temp.Speicher for 6 times, reason invalid data length, 1 instead of 10 bytes
2013.04.13 18:29:27 3: OWTHERM: Could not get values from device Temp.Vorlauf for 5 times, reason invalid data length, 1 instead of 10 bytes
2013.04.13 18:29:27 1: 192.168.1.9:2323 reappeared (CUNO)
2013.04.13 18:29:27 3: CUNO: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq

CUNO hat die Fw 1.53. Sollte ich mal eine andere versuchen?

Ich habe auch die 00_OWX.pm anpassen müssen (Zeile 221, CUL_SimpleWrite($owx_hwdevice, "Oi"); auskommentiert). Sonst erkennt er einen CUL ohne 1Wire Interface.

Ich werde mir morgen mal den Levelshifter auf 5V vornehmen, mal sehen, denke aber nicht das es besser wird.

Danke für die Hilfe!
Philipp

[Prof. Dr. Peter Henning]

Das genau ist auch der Haken mit meinem CUNO. Denn eigentlich trennt er gar nichts - nur die Netzwerklatenz sorgt für einen ungerechtfertigten Abbruch im Modul CUL.

Mit den OWX-Modulen hat das also _gar nichts_ zu tun. Man kann diese Abbrüche auch ganz ohne OWX durch Abfrage der ASCII-Schnittstelle des CUNO erreichen.

Aus meiner Sicht wäre es also nötig, die Abfrage des CUNO im CUL-Modul besser an die begrenzten Fähigkeiten der CUNO-Firmware anzupassen.

LG

pah

[Philipp]

Genau. Ich glaube sogar dass der CUNO sich resetet und neu startet.
Hab ich zumindest mit telnet so wahrgenommen.

So gesehen wärs wahrscheinlich besser über ein anderes Interface zu gehen.

Philipp

[Prof. Dr. Peter Henning]

An einen Reset des CUNO glaube ich nicht - das ist einfach der inadequate Timeout des CUL-Moduls.

LG

pah

[Tobias]

Update: die Fehlermeldung erscheint nicht im Log sondern nur in der Shell, in der FHEM gestart wurde.

Code Auswählen Erweitern

Argument "" isn't numeric in sprintf at ./FHEM/21_OWMULTI.pm line 338.
Argument "2072.000000^P^AM-^?M-^?M-\0\0M-?M-^?\0^AM-}M--^H\0^?^?^H..." isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1175.
Argument "0.000000000^P^BM-7M-}^Q^PM-^?M-^?M-\0\0M-_M-_\0@M-z^?\0^A..." isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1182.


Edit: jetzt hab ich die Meldungen auch im Log gesehen...

[Tobias]

pah, könntest du dir das mal btte kurz anschauen? Hab nur ich den Fehler?  Hab eben nochmal ein update gemacht, aber OWCOUNT hat ich nicht geändert, bzw hab ich den Fehler immer noch

[Prof. Dr. Peter Henning]

Habe ich schon längst, kann es aber nicht nachvollziehen. In beiden Fällen handelt es sich darum, dass der aus dem internen memory gelesene midnight-Wert falsche Zeichen enthält.
Das aber wiederum kann nicht sein, weil die beiden Zeilen 1174 und 1181
alle Zeichen außer Ziffern und Punkt entfernen.

Also bitte mal posten, was sich durch "get <device> midnight A" (bzw. B) ergibt.

LG

pah

[Tobias]

Code Auswählen Erweitern

get Wasserzaehler midnight A
OWCOUNT: Wasserzaehler.midnight [14] =>2072
OWCOUNT: Wasserzaehler.midnight [15] =>0

zurInfo:

Code Auswählen Erweitern

Internals:
   CHANGED    
   DEF        DS2423 FEC30D000000 60
   INTERVAL   60
   IODev      1wireBus
   NAME       Wasserzaehler
   NR         140
   NTFY_TRIGGERTIME 2013-04-22 13:22:35
   OW_FAMILY  1D
   OW_ID      FEC30D000000
   PRESENT    1
   ROM_ID     1D.FEC30D000000.53
   STATE      A: 2087.0 Liter A_rate:  0.00 Liter/h B:   0.0 cts B_rate:  0.00 cts/h
   TYPE       OWCOUNT
   CHANGETIME:
   Readings:
     2013-04-22 13:54:36   A               2087
     2013-04-15 15:43:22   A_avg_day       846.3
     2013-04-15 15:43:22   A_avg_month     846.0
     2013-04-15 15:43:22   A_cum_day       47903592
     2013-04-15 15:43:22   A_cum_month     1144319592
     2013-04-15 15:43:22   A_max_day       906.0
     2013-04-15 15:43:22   A_max_month     906.0
     2013-04-15 15:50:25   A_min_day       846
     2013-04-15 15:50:25   A_min_month     846
     2013-04-22 13:54:36   A_rate          0
     2013-04-15 15:43:22   A_rate_avg_day  360.2
     2013-04-15 15:43:22   A_rate_avg_month 360.0
     2013-04-15 15:43:22   A_rate_cum_day  20387520
     2013-04-15 15:43:22   A_rate_cum_month 486947520
     2013-04-15 15:35:22   A_rate_max_day  420.0
     2013-04-15 15:35:22   A_rate_max_month 420.0
     2013-04-15 15:50:25   A_rate_min_day  360
     2013-04-15 15:50:25   A_rate_min_month 360
     2013-04-22 13:54:36   B               0
     2013-04-22 13:54:36   B_rate          0
     2013-04-21 23:59:21   day             D21  A: 2072.0 Liter Am:   0.0 Liter  B:   0.0 cts Bm:   0.0 cts
     2013-04-22 13:54:36   state           A: 2087.0 Liter A_rate:  0.00 Liter/h B:   0.0 cts B_rate:  0.00 cts/h
     2013-04-15 15:43:22   verbrauch_stunde 359.997569577413
Attributes:
   AMode      normal
   AOffset    -5699
   APeriod    hour
   AUnit      L|Liter
   BOffset    -5428
   IODev      1wireBus
   event-on-change-reading A,B
   model      DS2423
   room       OWX

[Prof. Dr. Peter Henning]

Hm, erstaunlich - das stimmt alles soweit.

Dann vielleicht mal von Hand setzen "set <device> midnight A 2072.0"

LG

pah

[Prof. Dr. Peter Henning]

Ich glaube, dass ich da jetzt doch etwas gefunden habe: Es kann sein, dass diese Fehlermeldung daher rührt, dass eine leere Logdatei für die Monate wieder eingelesen wird.

Muss ich noch ausprobieren.

LG

pah

[Tobias]

schön das du es nachvollziehen konntest... selbst bei WochenLogs wird dieses ganz gut groß durch die Meldungen.
Das LogM oder LogY Attr hab ich nicht gesetzt

[Tobias]

Hast du schon eine Idee oder Workaround den ich mal testen kann?

[Tobias]

nochmal *hochschieb* für pah ;)
Ich habe echt keine Ahnung wie ich die Fehlermeldungen aus den Logs bekomme

[Prof. Dr. Peter Henning]

Na ja, "hochschieb" ist gut.

Solange ich den Fehler aber nicht reproduzieren kann, ist das eher schwierig.

Also nochmal:
- Bitte Auszug aus der Konfigurationsdatei posten - das fehlt m.E. noch
- Bitte Auszug aus dem Log posten, idealerweise mit dem o.a. Kram zusammen

Letzteres steht schon in einem Post - es ist aber einfacher für mich, wenn die Sachen beieinander stehen.

LG

pah

[ntruchsess]

Das aber wiederum kann nicht sein, weil die beiden Zeilen 1174 und 1181 alle Zeichen außer Ziffern und Punkt entfernen.

Hallo Peter,

ich hab die regexp in Zeile 1174/1181 mal korrigiert, damit sie das auch tut:

$owg_str =~ /([\d\.])+/ prüft, ob $owg_str aus Ziffern und Punkten besteht. Rückgabewert ist true oder false, $owg_str bleibt unverändert.
$owg_str =~ s/[^\d\.]+//g; ersetzt alles was nicht Ziffer oder Punkt ist durch "". Rückgabewert, der auch $owg_str zugewiesen wird, ist das Ergebnis.

gruß,

Norbert

[Tobias]

Habe mal ein Update gemacht. Bis jetzt sieht es gut aus :) keine Fehlermeldungen mehr *freu*

[Alexander Bauer]

Hallo Norbert,

wenn OWServer verwendet wird, gibt es auch mit der neuen Version noch die Meldungen.

Argument "722.2100000000M-+^DM-\0IM-^IM-L^HM-^_^I\rM-AM-S" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1031.
Argument "571.3400000000aM-D?tRIM-4M-^PM-^U47M-\0M-[1'M-3_M-H" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1048.

Wären dann die Zeilen 1030 und 1047 auch so zu ändern?

[ntruchsess]

wenn OWServer verwendet wird, gibt es auch mit der neuen Version noch die Meldungen.
[...]Wären dann die Zeilen 1030 und 1047 auch so zu ändern?

Jo, das ist im Prinzip der gleiche Fehler, nur im code für OWSERVER. Ich habe die beiden RegExps angepasst und ins svn committed. Kannst Du das bitte testen? Ich habe selber kein OWSERVER laufen und bin deshalb sehr vorsichtig, was Änderungen an dem Teil des codes angeht.

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Gleiche Antwort wie oben: Kann sein, dass das mit dem Monatswechsel zu tun hat. Ich werde es testen und ggf. noch verändern, bin aber im Moment vollkommen mit Arbeit zu.

LG

pah

[Alexander Bauer]

Hallo Norbert,

ich hatte die Zeilen schon mal angepaßt,
das Problem mit den Fehlermeldungen ist dann weg.

Ciao

Alexander