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
OK, Danke, wird getestet.
hallo pah,
danach ging der RPI auf Tauchstation:
2013.04.04 23:58:38 1: OWCOUNT_GetMonth: Attribute LogM is missing
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
Hallo,
bei mir ist FHEM auch auf Tauchstation gegangen. Ich werde jetzt das LogM setzen.
Ich habe eine modifizierte Version, dies diesen Fehler abfängt, ins SVN repository eingestellt.
LG
pah
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?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!
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
Danke, da bin ich ja beruhigt. Dann hatte ich den Fehler mit der Endlosschleife bei Heating Control doch vorgestern mit Erfolg beseitigt.
(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
dto.
(siehe Anhang / see attachement)
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
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.
Moin Prof.,
Update gemacht, rennt wieder.
Danke Joachim
Hi,
habe gestern ein Update gemacht und nun folgende Fehlemeldungen nach FHEM-Start:
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
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
hab mal einen kompletten Restart gemacht:
Wasserzaehler.version => 3.23
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
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
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
jetzt hab ich auch schon den Grund der Fehler gefunden. Der CUNO trennt die Verbindung und dann kommts logischerweise zu den Fehlern.
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
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
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
An einen Reset des CUNO glaube ich nicht - das ist einfach der inadequate Timeout des CUL-Moduls.
LG
pah
Update: die Fehlermeldung erscheint nicht im Log sondern nur in der Shell, in der FHEM gestart wurde.
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...
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
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
get Wasserzaehler midnight A
OWCOUNT: Wasserzaehler.midnight [14] =>2072
OWCOUNT: Wasserzaehler.midnight [15] =>0
zurInfo:
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
Hm, erstaunlich - das stimmt alles soweit.
Dann vielleicht mal von Hand setzen "set <device> midnight A 2072.0"
LG
pah
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
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
Hast du schon eine Idee oder Workaround den ich mal testen kann?
nochmal *hochschieb* für pah ;)
Ich habe echt keine Ahnung wie ich die Fehlermeldungen aus den Logs bekomme
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
Zitat von: Prof. Dr. Peter Henning schrieb am Mo, 22 April 2013 13:41Das 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
Habe mal ein Update gemacht. Bis jetzt sieht es gut aus :) keine Fehlermeldungen mehr *freu*
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?
Zitat von: Alexander Bauer schrieb am Mo, 03 Juni 2013 05:51wenn 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
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
Hallo Norbert,
ich hatte die Zeilen schon mal angepaßt,
das Problem mit den Fehlermeldungen ist dann weg.
Ciao
Alexander