Bösartige kleine Ungenauigkeiten der WebUI.... oder versteckte Fehlerquellen bei Programmen

[Black]

Wenn man ein bisschen tiefer in den Objekten der Programme gräbt, stösst man immer wieder an manche ich nenns mal merkwürde Inkonsistenzen, die vllt auch die Ursache des einen oder anderen nicht so funktionierenden Programmes sind.

Kleines Beispiel:
ein WebUI Programm hat die Abfrage:
Wenn Systemzustand IntegerVariable von 0 bis kleiner 10 bei Änderung.
so findet sich, wenn man sich mal die Singlecondition anschaut dort ein
ConditionType = 6 (von .. bis kleine ...)
und die RightVals jeweils ivt_Integer 0 und ivt_Integer 10

soweit schön
lege ich eine zweite Bedingung an
Wenn Systemzustand BooleanVariable bei False bei Änderung.
so findet sich, wenn man sich mal die Singlecondition anschaut dort ein
ConditionType = 1 (bei)
und die RightVals jeweils ivt_binary false und ivt_binary false

ändere ich nun die obere Bedinung, die vorher Integer war auf eine Boolean,
so passen sich zwar die beinen Rightvals an, ber nicht der Conditiontype.
der bleibt weiterhin beoi 6 (von... bis kleiner )...

Richtig Spassig wird es nun
ich lege eine Bedingung an: systemvariable typ float
schreibe wieder eine Bedingung:
Wenn Systemzustand zzz von 1 bis 20 bei Änderung.
soweit alles gut
nun änder ich den Typ der systemvariablen von float in boolean
gehe in der WebUi wieder ins program:
in der WebUI wird auch schön angezeigt:
Wenn Systemvariable zzz bei False bei Änderung.
ich denke, alles nett , speicher dieses und gucke mir nun mal die SingleCondition an:
der Typ ist immer noch 6, wie oben auch... aber

die rightval stehen immer noch auf ivt_float 1 und ivt_float 20
die Bedingung kann

in den destination beim wenn steht:
screibe ins Syslog: Wenn Teil ausgeführt

in den destination bei sonst steht:
screibe ins Syslog: SonstTeil ausgeführt

Nun trigger ich diese Boolean Variable zzz .. true, false, true, false...

es kam noch einmal der Eintrag
Feb 3 19:59:44 homematic-ccu2 daemon.info cuxd[543]: CUX2801001:1 Sonst teil
danach triggerte das programm nicht mehr, auch keine fehler im syslog

unter status und bedieung kann ich aber sehen, dass das programm geriggert wird der Zeitstempel ändert sich.
aber es tritt oben kein wechsel von false nach true mehr auf bzw von true nach false...

Black

Das harmlos und richtig aussehende Programm:

Die nicht richtig aussehende SingleCondition:

[Xel66]

...ändere ich nun die obere Bedinung, die vorher Integer war auf eine Boolean,
...nun änder ich den Typ der systemvariablen von float in boolean

Ich nehme für mich daraus mit, dass Systemvariablen nie nicht im Typ geändert werden sollten, sondern besser bei Umwidmungen gelöscht und neu angelegt werden sollten, um dieses Problem zu umgehen. Habe ich in der Vergangenheit sowieso so gehandhabt und vielleicht aus diesem Grund vermeintlich noch nie Probleme damit gehabt. Aber danke für die Analyse.

Gruß Xel66

[Black]

Aber ein erster Test brachte da auch etwas gutes:

ein kleines programm, welches die Eigenschaften der SingleConditon in ihren Methoden für eine Bool Variable wieder richtig beschrieb.

sah so aus anschliessend, wie eine SC für eine Bool Variable aussieht, wenn man sie flammneu anlegt.

führte dann wirklich wieder dazu, dass wnn ich die Systemvariable zzz wieder abwechselnd mit true, false, true, false gesteuert habe,
dass das programm wieder arbeitet.

Code: Alles auswählen

Feb  3 20:28:11 homematic-ccu2 daemon.info cuxd[543]: CUX2801001:1 Wenn teil
Feb  3 20:28:26 homematic-ccu2 daemon.info cuxd[543]: CUX2801001:1 Sonst teil

Es scheint also so zu sein, dass man durch einen Plausibilitätstest und gegenfalls ändern der Eigenschaften der SC bzw evl auch einer SD, die Programme wieder ordnungsgemäß zum funktionieren zu bekommen sind.

Mal schauen, aber sieht interessant aus.

Black

[alchy]

Prima. Dann bist du auch nicht mehr weit davon entfernt raus zu finden, warum z.B. ein Stringvergleich an erster/einziger Stelle eines Programms nicht funktioniert.
Tipp: Schau dir mal den ConditionTyp und dessen Änderung beim Abspeichern eines Programms an.

Alchy

[Black]

interessant..

da hättest aber auch gleich sagen können, das wenn man ein programm in der web ui anlegt mit string vergleich bei auf änderung ist Standartmäßig die ConditionType erstmal 1 (bei) , das beim Abspeichern des Programmes blöderweise diese auf 6 (bis kleiner) geändert wird und damit die condition im Fall einer Triggerung wohl eher nicht wahr werden wird.

ein gleicher versuch mit aufgezwungenem ConditionType =5 (Gleich) führt aber zu reproduzierbaren Triggerverhalten.

Code: Alles auswählen

Feb  3 21:47:10 homematic-ccu2 daemon.info cuxd[543]: CUX2801001:1 Sonst teil STRING
Feb  3 21:48:00 homematic-ccu2 daemon.info cuxd[543]: CUX2801001:1 Wenn teil STRING

Ist also ein Fall für Jens.....

Wobei ich noch nirgends die Causal Folge gelesen habe, nur immer: das geht nicht

Black

Immerhin scheint ein Programm, dessen Conditiontype via des SDV auf 5 geändert wurde, diesen wert zu behalten, auch wenn es mehrfach geöffnet und wieder gespeichert wurde.. Zumindest ein Lösungsansatz (wobei die 1 (bei) es wahrscheinlich auch tun würde, müsst ich mal testen)

[alchy]

Was mit dem ConditionTypen beim Speichern von Programmen passiert, habe ich schon irgendwo erwähnt und auch ein Ticket bei EQ-3 erstellt.
Bin ja schon vor langer Zeit darüber gestolpert und bei der Arbeit an equalthan wieder.

Alchy