Systemvariablen Metadaten Konsistenzcheck

[Black]

Ok. Danke dir. Das schaut auch aus als wenn das von etwas externen oder einem Addon angelegt worden wäre. Also unkritisch. Danke, black

[alchy]

.

auch weil die eine recht strikte QC haben die im Zweifel lieber nichts ändert als potentiell dadurch sich Fehler einzuhandeln.

Das glaubst du doch selber nicht - selten so gelacht.
Da legen die aber sehr unterschiedliche Maßstäbe an, was die schon für Gurken durchgelassen haben.

ich hab diese Transformationen via WebUi mal durchgespielt...
Die Systemvariable hatte nach einem Korrekturlauf immer sinnige Einträge

Mein Fehler. falsche Konstellation aufgeschrieben. Ich meine:

Logik->Werteliste->Logik vs Logik->Werteliste->Alarm->Logik


Und ausführlich:
Testlauf 1

1. Neue Systemvariable Typ Logik angelegt - Scriptduchlauf -> o.k
2. diese Variable zur Werteliste ÄNDERN -> Scriptduchlauf:
[ID]: 60135 - (Atest_logik) Type WerteListe - MetaData : BV0 nicht zulässig
[ID]: 60135 - (Atest_logik) Type WerteListe - MetaData : BV1 nicht zulässig
3. diese Variable zur Logik ÄNDERN -> Scriptdurchlauf:
[ID]: 60135 - (Atest_logik) Type Logigwert - MetaData : VALUE_LIST nicht zulässig


Testlauf 2
1. Neue Systemvariable Typ Logik angelegt - Scriptduchlauf -> o.k
2. diese Variable zur Werteliste ÄNDERN -> Scriptduchlauf:
[ID]: 60136 - (Atest_logik) Type WerteListe - MetaData : BV0 nicht zulässig
[ID]: 60136 - (Atest_logik) Type WerteListe - MetaData : BV1 nicht zulässig
3. diese Variable zur ALARM ÄNDERN -> Scriptdurchlauf -> o.k:
3. diese Variable zur Logik ÄNDERN -> Scriptdurchlauf -> o.k:

Jetzt hoffe ich es richtig beschrieben zu haben. Wenn dies nur bei mir so wäre, wäre das natürlich doof.
Würde mich freuen, wenn wer den Test so durchführt und schreibt das es bei ihm nicht so ist.

Alchy

[Black]

@Alchy, dem kann ich so zustimmen, ist aber auch in sich logisch, ok, nicht korrekt aber logisch.

die Rega macht anscheineind:
wenn aus einer Bool einer Werteliste machst kommt der Eintrag: VALUE_LIST Hinzu, dein Lauf erkennt dann, wie Badenpowers Tool auch, das zwar die VALUE_LIST hinzugekomen ist, aber die alten BV0 und BV1 nicht entfernt wurden.
wenn dann zurück in Bool änderst, sind die BO0 und BV1 korrekterweise vorhaden, die vorher als Weteliste erzeugte Value_LIST aber immer noch da und damit als Bool natürlich falsch,

bei dem zweiten schritt isses dann identisch.

ist inkonsequent auf Regaseite, keine Frage.

Black

[Xel66]

Eine schnelle und private Lösung des Problems wäre doch, eine nachträgliche Typänderung zu verhindern und den Anwender zum Löschrn und der Neuanlage zu zwingen. Ich sehe auch keinen wirklichen Grund, bestehende Systemvariablen ggf. mit Inhalt, der nachher nicht mehr zum Typ passt, zu ändern. Eine Neuanlage mit anderem Typ ist logisch und würde viele negative Effekte verhindern.

Gruß Xel66

[debianatoe]

Ok. Danke dir. Das schaut auch aus als wenn das von etwas externen oder einem Addon angelegt worden wäre. Also unkritisch. Danke, black

Ja, korrekt. Es handelt sich um das Addon "Fritzbox-basierte Anwesenheitserkennung hm_pdetect" von jmaus. Dieses Addon legt die SVs automatisch an.

[nimmnenkeks]

Habe exakt das gleiche Verhalten, wie in Alchy's aufgeführtem Test (jedoch mit CCU2).
Habe dann das Ergebnis des o.g. Skriptes mit BadenPower's HM-Investigator geprüft.
Skript lief eh in seinem Code-Editor
Dann mit Analyse-Teil die Gegenprobe und mit dem Investigator dann die Ausgabe auch noch laufen lassen.

Auch gleich mal spasseshalber mit der in BadenPowers HM-Investigator befindliche Reparaturfunktion (Analyse-Tool) ausgeführt und sofort danach das Black's Skript, sowie Abfrage mit BadenPower's HM-Investigator-Tool laufen lassen.
Ergebnis, es wurden keine Fehler mehr gefunden.

Die in den Tests bestätigten Fehler, bestehen ja nicht erst seit der letzten Firmwareversion (CCU-2).

Schaut man sich die Laufzeit der Analyse-und Reparaturfunktion (auch bei 5 SysVars mit Fehlern an), frage ich mich, warum das Kompetenzteam im Leer das nicht direkt bei Änderung in der UI laufen lässt, wenn der User (nach Änderung einer vorhandenen SysVar) auf den OK-Button klickt.

Auch die Fehler bei den Stromzählern sind dem Kompetenzteam nicht erst seit gestern bekannt.
Ob es die Skripte selbst sind (deren Reste nach Ablernen des Aktors gerne verbleiben, oder gar fehlende Skripte bei Neuerstellung).


..

[Black]

Das diese Inkonsistenzen auftreten ist ja unstrittig und jederzeit reproduzierbar.

Gefallen bin ich über dieses Problem, als ich von einem Bekannten gebeten worden war, mal zu gucken, ob ich etwas finde, weil er probleme mit einem externen programm hatte,welches mit 2, 3 Systemvariablen Macken machte. Und da mal tiefer hinter die Kulissen geschaut kam dann dieses Problem zum Vorschein. Das Problem war übrigens dann weg, als meine Version eines Bereinungstools dann die Tags gradegezogen hat und ein Neueinlesen des Variablenstammes dann erfolgreich ging.

Allerdings sollten wir diese Problematiken auf der Sachebene behandeln, rhetorische Wortspielereien wie das "... Kompetenzteam im Leer ..." ich denke die gehören nicht in eine Fachdiskussion.

Die mitgelieferten Stromzählerskripte sind , da muss ich nimmnenkeks rechtgeben, freundlich ausgedrückt suboptimal.

die auf Gitbub liegende V3.7.10 des SDV kann diese Effekte nun auch erfolgreich glattziehen

Black

[alchy]

bei dem zweiten schritt isses dann identisch.

ist inkonsequent auf Regaseite, keine Frage.

Naja, es ist eben nicht identisch.
Was wollte ich mit Testlauf 1 & 2 zeigen?
Wenn ich den Umweg über eine Alarmvariable gehe funktioniert das Ändern, gehe ich den Umweg nicht, funktioniert es nicht korrekt.
Ich kann es zwar im Moment nicht wirklich testen, gehe aber von einem Bug in den internen Scripten aus, genau wie beim Bug Programmtrigger "String Vergleich". Rega hin oder her, nicht alles kommt von da.

*IMHO natürlich kann man es zwar reparieren, aber eben nur bis der User wieder einen Systemvariablentyp "bearbeitet". Und somit kann es nicht zielführend sein, es hinterher zu reparieren, sondern muss vorrangig bei der Entstehung gefixt werden.

Alchy

[Black]

yap, grad nochmal in Ruhe nachvollzogen. Beim übergang von Werteliste --> Alarm wird der Tag "VALUE_LIST" richtigerweise entfernt. interessanterweise auch beim Übergang von Alarm --> WerteListe wird BV0 und BV1 entfernt... alles irgendwie nicht so richtig konsequent.

Black

[jmaus]

yap, grad nochmal in Ruhe nachvollzogen. Beim übergang von Werteliste --> Alarm wird der Tag "VALUE_LIST" richtigerweise entfernt. interessanterweise auch beim Übergang von Alarm --> WerteListe wird BV0 und BV1 entfernt... alles irgendwie nicht so richtig konsequent.

Danke für deine ersten Analysen. Wenn du das entsprechend alles analysiert hast würde ich mich freuen wenn du das hier noch einmal für alle Typen und Übergänge zusammenfassen könntest oder im GitHub ein Ticket dazu aufmachst. Dann kann ich das entweder in ReGaHss direkt oder via startup Skript reparieren sodass die Metadaten dann auch bei einem Wechsel konsistent bleiben.