Typ Konsistenz Analyse - Auszug aus dem Pre-Release des SDV

[alchy]

Klar mit dem Script kann man den Bug auch nachträglich reparieren, und nicht wie in meiner Lösung allgemein gültig umgehen. Der Hersteller könnte es aber auch fixen in dem er die Dateien welche dafür verantwortlich sind, entspechend ändert.

Alchy

[Black]

Fix durch den hersteller ist als finales Resultat natürlich das Ziel. Bis dahin ist den Kollegen aber mit einem work around mehr geholfen als mit warten auf Godot... ok Warten bis der hersteller das ändert. Oder auch nicht... Insha'allah.

Black

[debianatoe]

Nicht nur für dich.
Das Stringvergleich Problem habe ich sogar schon ein 2. Mal vor ein paar Tagen gemeldet. E197F595CC429
Ich habe sogar Dateinamen mitgesendet, wo sie nachschauen können. Außer die lapidare Eingangsbestätigung ist aber wieder nichts passiert.

Das wirft kein gutes Licht auf eQ3. Mir ging es beim Melden eines Bugs bei der 8-fach Fernbedienung HM-RC-8 genauso. Die Bug-Bestätigung habe ich bekommen, aber auf eine korrigierte Firmware warte ich seit über 2 Jahren.

Nach meiner Erfahrung, wird eben NICHT ausgelöst, obwohl es auslösen müsste wenn ein Stringvergleich als erste Bedingung in einem Programm angelegt wurde. In deinem Fall würde also der String Regen keine Auslösung hervorbringen.

Das ist richtig. Ich habe das eben nochmal getestet und bei Regen wird tatsächlich nicht ausgelöst, dafür aber bei Wolkig.

Ich würde an deiner Stelle mein Script >> Auslöser eines Programmes finden und loggen << in das Programm einbauen ins DANN und im SONST um sicherzustellen, das der Trigger für das DANN auch so ist, wie du denkst.

Gute Idee! Ich habe das mal eingebaut. Dein Programm läßt sich bestimmt auch an vielen anderen Stellen nützlich zur Fehlersuche verwenden.
Hier ist der relevante Teil des Systemprotokolls, den Dein Programm erzeugt hat:

Code: Alles auswählen

00:00:09	10.02.2019	Programme_loggen	
Programm: DANN Niederschlagsermittlung durch: WetterBedingungen mit dem Wert: Wolkig am: 10.02. 00:00 Uhr

Condition: 9 ist allerdings wieder etwas Neues, wenn ich mich Recht erinnere, kommt es doch zu 6.

Scheinbar ist dieser Fehler doch etwas umfangreicher ...
Seit welcher Firmware tritt dieser Fehler eigentlich auf?
Betrifft das nur die CCU2 oder auch CCU3 und Raspberrymatic?
In der Raspberrymatic werden die Bugs ja meist etwas schneller korrigiert.

Nun, laut RegaHss ist ja auch wolkig nun mal größer als heiter
Glaubst du nicht?

Doch, ich glaube es, aber leider ist Wolkig auch größer als Regen und von daher ist diese Logik nicht wirklich nutzbar.

[debianatoe]

du machst folgendens:
1. Backup
2. lasst mein Script nochmal laufen wichtig ist die folgende Angabe: SCND-ID: 24188
3. Diese SCND-ID ist die IseID des Objektes, welches wir nun etwas modifizieren wollen
4. du schreibst folgendes kleines Progrämmchen

Code: Alles auswählen

object o=dom.GetObject (24188);
if (o) {
  if (o.Type() == OT_SINGLECONDITION) {
    o.ConditionType (1);
    WriteLine ("ConditionType geändert");
  } else {WriteLine ("Fehler ID ist keine Singlecondition"); }
} else {WriteLine ("ID ungültig"); }

Danach: Ausprobieren obs geht

Genau so bin ich vorgegangen. Dabei hat mich zuerst einmal gewundert, daß sich die IDs gegenüber gestern verändert hatten:

Code: Alles auswählen

Analyse Program: Niederschlagsermittlung [ID: 23865]
		Inkonsistenz [SCND-ID: 24206] Rule-Nr: 1, CND-Nr: 1, SCND-Nr: 1 -- Value: 20 [ivtString], Condition: 9 [größer oder gleich ..]

Ist das normal?
Ich habe Dein Korrekturprogramm statt mit der ID von gestern (24188) mit der neuen ID 24206 ausgeführt und der Test hat dann ergeben, daß Wolkig nicht mehr auslöst, aber Regen immer noch nicht auslöst. Immerhin schon mal eine Verbesserung der Situation
Dein Analyse-Programm zeigt nun auch eine veränderte Situation (statt Condition 9 nun 6):

Code: Alles auswählen

Analyse Program: Niederschlagsermittlung [ID: 23865]
		Inkonsistenz [SCND-ID: 24206] Rule-Nr: 1, CND-Nr: 1, SCND-Nr: 1 -- Value: 20 [ivtString], Condition: 6 [von..bis kleiner..]

[alchy]

Dann schlägt wahrscheinlich der Bug wieder zu, weil du das Programm in der Klickibunti gespeichert hast.
Was das Script bei großer oder kleiner ausgibt musst du dir mal erklärenlassen.

Alchy

[Black]

Wie Alchy schon richtig sagte, wenn du ein Programm editierst, ändern sich die IDs (Stichwort CopyID)

Dein Effekt ist nun schon arg merkwürdig. ich hab bei mir ein Programm getestet mit erste Bedingung trigger auf String und Typ zwangsweise auf 5. Das tat es (auf einer aktuellen Raspberrymatik)

bei dir bietet sich folgender Ansatz an:

setzen deiner Conditions welche den Stringvergleich machen auf Typ 5 und dann mal testen
(gibt auch ein Hilfsprogramm, s. meine Signatur)

alternativ deine letzte Bedingung dsNsIntens als erste Bedingung setzen


Gruss, Black

[debianatoe]

Ich habe jetzt einfach die Regen-Abfrage nochmal zusätzlich unten mit ODER hinzugefügt. Damit scheint es nun zu funktionieren. Vielen Dank für Eure Unterstützung!

[Black]

Vllt kann Jens da mal genauer hingucken.

das wird ja schon gespenstisch langsam. Es schliesst sich hier auch nahtlos an den alten Threat an

also wenn ich irgendein programm nehme, in die erste Zeile ein Stringvergleich als trigger reinschreibe, als Ausgabe einen Eintrag ins syslog

Programm abgespeichert, programm vesucht zu triggern, wie erwartet tuts das nicht. (der allseits bekannte Bug)
Wie schon mehrfach dargestellt liegts daran, dass beim Speichern der ConditionType durch WebUi / rega , keine Ahnung, verändert wird.

wird nun aber noch wilder.

Ich programmier grade die korrekturfunktionen des SDV. also die Stringkorrektur kann er. Ergebnis, das Programm triggert auch nun.

Code: Alles auswählen

Apr  5 14:52:24 homematic-ccu2 daemon.info cuxd[1495]: CUX2801001:1 Ich habe getriggert

tuts nun schön.
dachte ich, damit wäre nun das Problem ad akta... dachte, isses aber nicht.
Testausgabe des SDV

Code: Alles auswählen

Geprüft: 36 Programme
Dabei wurden 7 Inkonsistenzen gefunden in 4 Programmen
Von diesen 7 Inkonsistenzen wurden 2 korrigiert

die beiden String Conditiontypes sind nun repariert, das programm triggert
Apr 5 15:03:23 homematic-ccu2 daemon.info cuxd[1495]: CUX2801001:1 Ich habe getriggert

das blöde ist nun, sobald ich die WebUi im PunktProgramme und Zentralenverknüpfung, OHNE DASS ICH DAS PROGRAMM AN SICH GEÖFFNET HABE, auch nur anfasse, ändert mir da irgendwas auf der CCU bei ALLEN programmen , die einen Stringvergleich haben, wieder die ConditionType auf 6 und damit, --> triggert das Programm mal wieder nicht.

Warum fuscht da etwas, was mit dem Seitenaufbau der WEB-UI zusammenhängt, sich durch die ConditionTypes der Programmobjekte und ändert diese selbstständig ? und dazu auch noch falsch ? fragen über Fragen.

Also an Jens, das Offnen oder auch Aktualisieren der Zentralenprogrammansicht führt dazu, dass sich die ConditionTypes dabei verändern.

Den Punbkt nachhaltig durch den SDV verändern geht ja leider nicht, da jedes öffnen der Programmseite oder ändern eines Anderen programmes die Aufgezwungene ConditionType (1) wieder zurückändert.

gruss, Black (FW der Spiele RMMatik: 3.45.5.20190330)

[alchy]

Auch wenn ich nicht jens bin

Warum fuscht da etwas, was mit dem Seitenaufbau der WEB-UI zusammenhängt, sich durch die ConditionTypes der Programmobjekte und ändert diese selbstständig ? und dazu auch noch falsch ? fragen über Fragen.

Wie ich schon schrieb, die Ursache in den internen Scripten muss beseitigt werden, dann gibt es die Wirkung auch nicht mehr.
Hinterher etwas ändern ist meist nicht der richtige Weg. Leider hat EQ-3 wohl keine Ressourcen um sich um so etwas zu kümmern.
Wenn ich zu Hause bin schau ich nach, was du anpassen musst.


Alchy

[Black]

Auch wenn ich nicht jens bin

Wie ich schon schrieb, die Ursache in den internen Scripten muss beseitigt werden, dann gibt es die Wirkung auch nicht mehr.
Hinterher etwas ändern ist meist nicht der richtige Weg. Leider hat EQ-3 wohl keine Ressourcen um sich um so etwas zu kümmern.
Wenn ich zu Hause bin schau ich nach, was du anpassen musst.
Alchy

würde mich mal interessieren, welcher part da amok läuft

black