Hat sich im DOIF-Modul irgendetwas geändert?

[FunkOdyssey]

Ich habe plötzlich DOIFs, die nicht mehr ausgeführt werden.
Und ich vermisse plötzlich wait-Attribute.
Ich forsche weiter, aber kann es sein, dass mit dem SVN von heute irgendetwas gefixt wurde?

Gab es ein Bug?

[Damian]

Ich habe plötzlich DOIFs, die nicht mehr ausgeführt werden.
Und ich vermisse plötzlich wait-Attribute.
Ich forsche weiter, aber kann es sein, dass mit dem SVN von heute irgendetwas gefixt wurde?

Gab es ein Bug?

ja, aktuelle Version laden.

Edit: oder du hast dieses nicht beachtet: https://forum.fhem.de/index.php/topic,84969.msg784859.html#msg784859

[FunkOdyssey]

Ich hatte das SVN von vor zwei Tagen. Jetzt das heutige.
Sind deine Ämderungen oder der gestrige Bugfix denn der Grund wieso bei mir das wait-Attribut entfernt wurden? Das waren allesamt alte DOIFs. Kein Perl.
Das Wait kann ich sogar wieder hinzufügen. Ich habe nur massig DOIFs und mach mir nun ein wenig Sorgen.

[Damian]

Ich hatte das SVN von vor zwei Tagen. Jetzt das heutige.
Sind deine Ämderungen oder der gestrige Bugfix denn der Grund wieso bei mir das wait-Attribut entfernt wurden? Das waren allesamt alte DOIFs. Kein Perl.
Das Wait kann ich sogar wieder hinzufügen. Ich habe nur massig DOIFs und mach mir nun ein wenig Sorgen.

Du hast Leerzeilen vor der ersten Klammer auf in deinen DOIFs, daher wurde der bisherige Modus als Perl-Modus erkannt. Das Problem habe ich gestern gefixt.

[FunkOdyssey]

Oje. Das habe ich überall. Wegen der Optik. Ich habe den Code eingerückt.
Mist. Dann muss ich die fhem.cfg zurücksichern. Und ich habe gestern fleißig gearbeitet.

[Ellert]

Puuh, da habe ich Glück gehabt, nur ein DOIF ist zum Perl-MODEL mutiert.

Man kann es prüfen mit

Code Auswählen Erweitern

list MODEL=Perl

[FunkOdyssey]

Danke für den Tipp. Aber damit wird bei mir ein Perl-DOIF gefunden.
Vermutlich aber auch, weil es zwischenzeitlich gefixt wurde und die DOIFs nur für zwei Tage Perl-DOIFs waren.
Ich muss mal ein DIFF machen, um mir den Schaden anzuschauen.
Ich glaube, dass ich Glück habe, denn ich habe tatsächlich nur wenige DOIFs mit Leerzeichen vor der Klammer. Die meinsten haben einen Zeilenumbruch und der scheint hier keine Rolle gespielt zu haben.

[Damian]

Das Internal Model wird beim Hochfahren des Systems aufgrund der Definition gesetzt. Mit der aktuellen Version sollte es keine alten DOIF-Devices mit Perl-Model geben, wenn ja dann müsste es noch eine Inkompatibilität geben. In diesem Fall bräuchte ich ein List des Moduls.

[Ellert]

Ich hatte ein DOIF mit der Definition, das hat sich in ein Perl-Model verwandelt.

Code Auswählen Erweitern

define testdoif DOIF ##

Meine Vermutung war, dass sich die restliche Definition verflüchtigt hat. Das kann ich aber nicht mehr eindeutig feststellen.

Nebenbei:
Das Internal MODEL wird zur Zeit nicht von fheminfo für DOIF nicht ausgewertet und daher nicht in der FHEM Statistik berücksichtigt.

In der aktuellen 98_fheminfo.pm, Zeile 32 wir DOIF durch die Liste in @noModelList ausgeschlossen.

[Damian]

Ich hatte ein DOIF mit der Definition, das hat sich in ein Perl-Model verwandelt.

Code Auswählen Erweitern

define testdoif DOIF ##

Meine Vermutung war, dass sich die restliche Definition verflüchtigt hat. Das kann ich aber nicht mehr eindeutig feststellen.

Nebenbei:
Das Internal MODEL wird zur Zeit nicht von fheminfo für DOIF nicht ausgewertet und daher nicht in der FHEM Statistik berücksichtigt.

In der aktuellen 98_fheminfo.pm, Zeile 32 wir DOIF durch die Liste in @noModelList ausgeschlossen.

ok, DOIF ## führt tatsächlich zu Perl, den Fall muss ich noch abfangen. Eigentlich kann sich die Definition aufgrund der falschen Erkennung nicht geändert haben. Im schlimmsten Falle konnten bei falsch erkannten DOIFs Attribute fehlen, wenn man die Konfiguration danach gespeichert hatte.

Zur Statistik warst du zwei Minuten schneller, als ich mit meiner Anfrage: https://forum.fhem.de/index.php/topic,86188.0.html

[Damian]

ich habe jetzt auch die Fälle abgefangen, die nur aus Kommentarzeilen und/oder Leerzeilen bestehen -> MODEL="FHEM"

Edit: korrigierte Version eingecheckt

[Ellert]

Eigentlich kann sich die Definition aufgrund der falschen Erkennung nicht geändert haben.

Ja, es kann gut sein, dass ich eine Definition genommen habe und nur probiert habe, ob ## funktioniert.

[Damian]

Ja, es kann gut sein, dass ich eine Definition genommen habe und nur probiert habe, ob ## funktioniert.

ja, ich denke, so langsam sollten alle Sonderfälle abgefangen sein

[betateilchen]

ich habe jetzt auch die Fälle abgefangen,

auch den Fall, dass es gar kein DEF gibt? 

Code Auswählen Erweitern

define doifTest DOIF

Auch dann wird "FHEM" als MODEL gesetzt. Obwohl ich eher der Meinung bin, dass man das als Fehler im DEFINE abfangen und eine entsprechende Meldung ausgeben sollte. Das device wird in diesem Fall nämlich ohne DEF angelegt, man hat also kein entsprechendes INTERNAL, das man durch Anklicken im Frontend nachträglich bearbeiten könnte.

[Damian]

auch den Fall, dass es gar kein DEF gibt? 

Code Auswählen Erweitern

define doifTest DOIF

Auch dann wird "FHEM" als MODEL gesetzt. Obwohl ich eher der Meinung bin, dass man das als Fehler im DEFINE abfangen und eine entsprechende Meldung ausgeben sollte. Das device wird in diesem Fall nämlich ohne DEF angelegt, man hat also kein entsprechendes INTERNAL, das man durch Anklicken im Frontend nachträglich bearbeiten könnte.

DOIF ohne Definition gab es immer schon, daher muss es so bleiben. Solche Definitionen machen Sinn, falls man ein DOIF-Modul nur mit dem Attribut state nutzen möchte.