Aufgrund einer user Fehlermmeldung ist mir aufgefallen das update (produziert ja events) auch den Inhalt von "changed" als event verteilt ?
ist das absichtlich so ?
Wenn in changed jetzt zB ein Eintrag "initialized" lautet dann wird dadurch "global:initialized" getriggert, etc.
Patch zur Beseitigung erwünscht ?
vg
joerg
2016.01.10 16:45:58 1: UPD docs/commandref_frame_DE.html
2016.01.10 16:45:58 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/32_TechemHKV.pm line 85.
2016.01.10 16:45:58 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/32_TechemHKV.pm line 87.
2016.01.10 16:45:58 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/32_TechemHKV.pm line 89.
2016.01.10 16:45:58 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/32_TechemWZ.pm line 122.
2016.01.10 16:45:58 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/32_TechemWZ.pm line 124.
2016.01.10 16:45:58 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/32_TechemWZ.pm line 126.
2016.01.10 16:45:58 1:
2016.01.10 16:45:58 1: New entries in the CHANGED file:
2016.01.10 16:45:58 1: - change: FB_CALLMONITOR: reading "missed_call_line" will not be triggered
2016.01.10 16:45:58 1: anymore. Use internal_number instead, which
2016.01.10 16:45:58 1: contains the same content
2016.01.10 16:45:58 1: - feature: FB_CALLMONITOR: new attribute answMachine-is-missed-call to
2016.01.10 16:45:58 1: treat incoming calls, which were taken by
2016.01.10 16:45:58 1: an answering machine, as "missed call"
2016.01.10 16:45:59 1: Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
Dazu müssten in CHANGED diese entsprechenden Events auch in Großbuchstaben enthalten sein. Wenn man auf "global:INITIALIZED" ein notify hat, dann ist das kein Problem. Bei "global:.*INITIALIZED.*" durchaus, sofern eben "INITIALIZED" im CHANGED irgendwo auftaucht.
Eine sichere Möglichkeit in FHEM selber, dass zu unterbinden sehe ich nicht, außer alle global-Events (INITIALIZED, REREADCFG, ...) in CHANGED zu verbieten (z.B. über pre-commit Hook).
Gruß
Markus
Übrigens fehlt im Eventmonitor seit einiger Zeit die abschließende Meldung nach generieren der Commandref, dass das Update abgeschlossen wurde.
Zitat von: Markus Bloch am 11 Januar 2016, 00:23:40
Dazu müssten in CHANGED diese entsprechenden Events auch in Großbuchstaben enthalten sein. Wenn man auf "global:INITIALIZED" ein notify hat, dann ist das kein Problem. Bei "global:.*INITIALIZED.*" durchaus, sofern eben "INITIALIZED" im CHANGED irgendwo auftaucht.
Eine sichere Möglichkeit in FHEM selber, dass zu unterbinden sehe ich nicht, außer alle global-Events (INITIALIZED, REREADCFG, ...) in CHANGED zu verbieten (z.B. über pre-commit Hook).
Gruß
Markus
ich denke das geht.
Frage 1: muss der Inhalt von "changed" überhaupt per event verteilt werden ?
Wenn das überhaupt so sein soll dann könnte man ein "UPD changed:" oder so etwas VOR jede Zeile setzen. Dann wäre das auch beseitigt. Aufgefallen ist mir das im übrigen auch nur weil ich auf "global" nach "initialized" suche und die erste leere Zeile hat produziert ein "global" undef .
vg
joerg
Die Daten per Event an das Frontend zu schicken ist ein grober Hack, ich meine wir haben auch andere Mechanismen fuer diese Aufgabe.
Ich nehme es auf meine TODO Liste.
drängt nicht. Wenn ich helfen kann bitte Info.
vg
joerg
Vielleicht kann man ja hier jetzt die "withLog" Option im Event-Monitor nutzen. Anstatt Events zu triggern gibt es dann nur noch Logmeldungen die dann in Rot erscheinen.
Gruß
Markus
Zitat von: Markus Bloch am 11 Januar 2016, 08:41:16
Vielleicht kann man ja hier jetzt die "withLog" Option im Event-Monitor nutzen. Anstatt Events zu triggern gibt es dann nur noch Logmeldungen die dann in Rot erscheinen.
Gruß
Markus
Da wäre ich dafür, das sieht in meinen Augen am saubersten aus. Auch für die User.
Grüße
Zitat von: Markus Bloch am 11 Januar 2016, 08:41:16
gibt es dann nur noch Logmeldungen die dann in Rot erscheinen.
rot sollten - wenn überhaupt - nur Meldungen erscheinen, die tatsächlich Fehler sind.
Auch war. Da halt gelb ;)
Zitat von: betateilchen am 11 Januar 2016, 10:43:47
rot sollten - wenn überhaupt - nur Meldungen erscheinen, die tatsächlich Fehler sind.
Mag durchaus sein, so ist es aktuell im Event-Monitor implementiert um Logmeldungen von Events zu unterscheiden. Ich war das nicht, da musst du dich bei Rudi beschweren.
Rudi hat es doch auf todo genommen. Und sooo dringend ist es doch wirklich nicht...
Vg
Joerg
Zitat von: Markus Bloch am 11 Januar 2016, 11:10:59
so ist es aktuell im Event-Monitor implementiert um Logmeldungen von Events zu unterscheiden
Ich beschwere mich ja nicht, ich habe die Logmeldungen im Eventmonitor noch nie gebraucht.
Für mich gehören die da auch nicht hin.
Geaendert:
- default bei update ist jetzt "updateInBackground" (Voreinstellung geaendert)
- update in background erzeugt keine Events mehr, nur noch logs
- ActivateInformFn aktiviert das Beobachten des Logs (wird bisher nur vom Update verwendet).
- CommandInform von fhem.pl nach telnet.pm geschoben.
- log als Parameter zum inform Befehl hinzugefuegt
- Logmeldungen im EventMonitor sind nicht mehr rot, sondern gruen (im default) oder weiss (darkstyle)
- update bug gefixt (keine Abschlussmeldung in manchen Faellen bei mehreren Quellen)
Zitat von: rudolfkoenig am 17 Januar 2016, 12:03:48
- update bug gefixt (keine Abschlussmeldung in manchen Faellen bei mehreren Quellen)
Danke, Rudi!
Mir ist noch etwas aufgefallen. Irgendwie scheint ein Update von einer Drittquelle hier nicht richtig verarbeitet zu werden, denn ich bekomme die Meldung jedes Mal bei einem erneuten Update:
2016-01-17 12:21:49 Global global fhemtabletui
2016-01-17 12:21:50 Global global UPD www/tablet/js/widget_button.js
2016-01-17 12:21:50 Global global
2016-01-17 12:21:50 Global global New entries in the CHANGED file:
2016-01-17 12:21:50 Global global FHEM tablet UI last change:
2016-01-17 12:21:50 Global global 2016-01-16
2016-01-17 12:21:50 Global global - Updated thermostat
2016-01-17 12:21:50 Global global
2016-01-17 12:21:50 Global global
2016-01-17 12:21:50 Global global widgets-for-fhem-tablet-ui
2016-01-17 12:21:50 Global global UPD www/tablet/js/widget_button.js
Kann ich nicht nachvollziehen, ich kriege:
...
2016.01.17 12:43:03 1 : UPD www/pgm2/console.js
2016.01.17 12:43:03 1 : UPD www/pgm2/darkCommon.css
2016.01.17 12:43:03 1 : UPD www/pgm2/defaultCommon.css
2016.01.17 12:43:03 1 :
2016.01.17 12:43:03 1 :
2016.01.17 12:43:03 1 : fhemtabletui
2016.01.17 12:43:04 1 : nothing to do...
2016.01.17 12:43:04 1 : Calling perl ./contrib/commandref_join.pl -noWarnings, this may take a while
2016.01.17 12:43:08 1 :
2016.01.17 12:43:08 1 : update finished, "shutdown restart" is needed to activate the changes.
2016.01.17 12:43:08 1 :
2016.01.17 12:43:08 1 : Please consider using the global attribute sendStatistics
Ach, ich seh's grad...
die zwei sich eigentlich ergänzenden Drittquellen überschneiden sich und das File wird mehrfach geändert:
Zitat
2016-01-17 13:08:52 Global global fhemtabletui
2016-01-17 13:08:52 Global global UPD www/tablet/js/widget_button.js
2016-01-17 13:08:52 Global global
2016-01-17 13:08:52 Global global New entries in the CHANGED file:
2016-01-17 13:08:52 Global global FHEM tablet UI last change:
2016-01-17 13:08:52 Global global 2016-01-16
2016-01-17 13:08:52 Global global - Updated thermostat
2016-01-17 13:08:52 Global global
2016-01-17 13:08:52 Global global
2016-01-17 13:08:52 Global global widgets-for-fhem-tablet-ui
2016-01-17 13:08:53 Global global UPD www/tablet/js/widget_button.js
Ich melde das mal in einem extra Fred (http://forum.fhem.de/index.php/topic,47626.0.html)...
Ich möchte noch auf diesen Thread hinweisen: http://forum.fhem.de/index.php/topic,47854.0.html
Das dort beschriebene Problem kann ich bestätigen. Wenn man ein update durchführt, kommen einem hier sämtliche Events dazwischen, da der Event-Filter mit ".*" alles einschließt. Evtl. sollte man hier den Filter auf "global" belassen.
Gruß
Markus