Systemvariablen Metadaten Konsistenzcheck

[Black]

ok, das schaut gut aus... dann. EQ3 war da selber ein wenig inkonsequent.
die bei mir u.B. aufgetretetenen meldungen basierten darauf, das es mein Spielesystemist und ich da beim Programmeiren auch viel rumprobiert habe und auhc shcon mal öfters Typüen gewwechselt habe.

[jmaus]

auch von mir eine Rückmeldung für Dein Inkonsistenzscript. Das Ergebnis:

Code: Alles auswählen

Geprüft: 189 Systemvariablen
Davon 26 Systemvariablen auffällig mit 26 möglichen Inkonsistenzen

Das gleiche Bild wie bei Sven_A. Es sind ausschließlich die von den Meßaktoren und Zählersensoren angelegten Systemvariablen "svEnergyCounter..." betroffen.

Wenn es sich wirklich auf diese automatischen Systemvariablen "svEnergyCounterXXX" beschränkt sollte es in der Tat ein leichtes sein diese Skripte so zu reparieren das die Systemvariablen korrekt mit ihren passenden Metadaten angelegt werden. Wenn mir dazu einer mal ein RaspberryMatic GitHub Ticket mit entsprechendem Beispiel aufmacht kann ich das gerne in einer der nächsten Versionen reparieren.

[alchy]

Lieber Alchy, wie oft muss ich es eigentlich noch betonen/erläutern,

Überhaupt nicht, weil es mich schlichtweg nicht interessiert.
Es wäre ja ein Leichtes für mich gewesen statt einer viel teuren CCU3 eine Alternative zu verwenden. Aber aus schon genannten Gründen habe ich davon Abstand gehalten. Auch den Usern, die einfach nur eine CCU3 kaufen und die sich nicht mit den Internas von XYZ rumärgern wollen, soll eben geholfen werden. Selbst der Support hier im Forum ist dadurch schwieriger, da man immer Bedenken muss, was ist wo wie gestrickt.

Auch dient RaspberryMatic dazu den eQ3 Verantwortlichen zu zeigen das gewisse Features und teilweise Bugfixes nicht nur von der Community so gewollt sind sondern sich auch einfach und stabil umsetzen lassen. Ein aktuelles Beispiel ist z.B. die in der neuesten 3.43.15 umgesetzten HDMI Port Abschaltung

War klar. Ich habe sowohl das Finden der Usache halbwegs verfolgt als auch die Äußerungen dazu.

Deshalb (wenn du dir mal das RaspberryMatic GitHub angeschaut hast) generiere ich grundsätzlich für jedes neue Feature/Bugfix Patches gegen die OCCU Quellen. Das erlaubt diese Patches in einfachster Art und weise den eQ3 Entwicklern vorzulegen um diese davon zu überzeugen das 1. keine äußere Sicherheitslücken dadurch eingeschleust werden und 2. die Änderung sich einfach anwenden und umsetzen lässt mit minimalem Implementierungs- und QC Aufwand (da RaspberryMatic inzwischen >15T Nutzer hat).

Klar du lässt ja auch keine Gelegenheit (auch in der Antwort hier) aus, den Usern mitzuteilen, das viele Features nur in der RaspberryMatic vorhanden sind und sie doch dies nutzen sollten.
Wenn das so gewollt ist, dann ist es eben so. Eigentlich müsste es ja EQ-3 schon als Abwerbung betrachten.
Die Anzahl der User sagt aber nicht viel aus, denn wenn ich mir die positiven wie auch negativen Wortmeldungen so ansehe ist nur ein verschwindend kleiner Teil von den den Usern in der Lage zu beurteilen, ob irgendetwas korrekt oder nicht korrekt ist.
Den meisten fällt ja nichts davon auf, und ja weil schon Einiges (auch Dank deiner Arbeit) durchaus besser geworden ist.

Insofern kannst du natürlich gerne zusätzlich deine eQ3 Tickets weiter aufmachen, darauf hoffen das diese dann bearbeitet werden und am Schluss dich wundern das dies nicht so schnell umgesetzt wurde wie du das vielleicht erhofft hast.

wie gesagt, EQ-3 und auch Du hattet eure Chance.
Ich habe es z.B. mit equalthan anders versucht und hier Anpassungen veröffentlicht die schlussendlich immer noch nicht in die Firmware vorgedrungen ist. Das könnte ich nun zwar immer weiter so treiben. Ich implementiere Verbesserungen oder fixe Fehler, du übernimmst es in die RaspberryMatic - ich hoffe, das es irgendwann mal auch in die CCU kommt...

Effektiver wäre es IMHO allerdings zumindest zusätzlich auch im RaspberryMatic GitHub ein entsprechendes Ticket/Issue aufzumachen mit den selben Informationen und wenn es dann eine Lösung gibt die z.B. auch von jemanden aus der Community kommen kann, dann ist es ein leichtes (und geht viel schneller) diese Änderung via der RaspberryMatic Patches an eQ3 zur Integrierung zu übergeben.

Oft mitgeteilt ich werde als Alchy aus persönlichen und rechtlichen Gründen nicht im github anfangen. Hält dich ja nicht davon ab, selber ein Ticket/Issue aufzumachen.


Aber aber endlich wieder zum Thema des Threads zurückzukommen. Der Test mit deinem Script ergibt bei mir:

Code: Alles auswählen

Konsistenzcheck Systemvariablen
Metadaten Konsistenzcheck
Auszug aus PreRelease SDV 3.07.10
Black in 2019
---------------------------------
[ID]: 50597 - (svEnergyCounter_50557_000855699C334D:7) Type Zahl - MetaData : UNIT fehlt
[ID]: 57038 - (svEnergyCounter_57023_KEQ0968370:2) Type Zahl - MetaData : UNIT fehlt
[ID]: 60072 - (svEnergyCounter_60055_0001D3C990BFAC:6) Type Zahl - MetaData : UNIT fehlt
[ID]: 15010 - (svEnergyCounterOldVal_15001) Type Zahl - MetaData : UNIT fehlt
[ID]: 17321 - (svEnergyCounterOldVal_17312) Type Zahl - MetaData : UNIT fehlt
[ID]: 44065 - (svEnergyCounterOldVal_44052) Type Zahl - MetaData : UNIT fehlt
[ID]: 48797 - (svEnergyCounterOldVal_48784) Type Zahl - MetaData : UNIT fehlt
[ID]: 50598 - (svEnergyCounterOldVal_50557) Type Zahl - MetaData : UNIT fehlt
[ID]: 57039 - (svEnergyCounterOldVal_57023) Type Zahl - MetaData : UNIT fehlt
[ID]: 60071 - (svEnergyCounterOldVal_60055) Type Zahl - MetaData : UNIT fehlt
---------------------------------
Geprüft: 57 Systemvariablen
Davon 10 Systemvariablen auffällig mit 10 möglichen Inkonsistenzen

Allerdings sind bei mir anderweitige Fehler schon repariert gewesen durch das BadenPower Tool.

Wenn es sich wirklich auf diese automatischen Systemvariablen "svEnergyCounterXXX" beschränkt sollte es in der Tat ein leichtes sein diese Skripte so zu reparieren das die Systemvariablen korrekt mit ihren passenden Metadaten angelegt werden.

Freu dich nicht zu früh.
Jede z.B. Logikvariable welche ich in eine z.B. Wertelistenvariable ÄNDERE,wird dann vom Script als unzulässig erfasst.
Eine Werteliste, welche ich in eine Zeichenkette ÄNDERE wird dann erfasst usw. usw.
Trifft so ähnlich zu, wie bei den Conditions in den Programmen.


Alchy

[Black]

hi jens,

bei den beiden letzten kollegen waren dies nur die automatisch generierten Variablen.

Bei Slice kamen noch ein paar andere Fälle hinzu, genau wie bei mir auf meiem testsystem auch (auch stellenweise provozierte Fälle)

Das fehlende "Unit" der automatisch generierten lässt sich einfach durch oID.ValueUnit (""); beheben, wobei oID das Object der jeweiligen Sysvar repräsentiert.

Black

Das korrigieren habe ich nun in die FPC version implementiert

Das testsystem mir vorher
Geprüft: 67 Systemvariablen
Davon 10 Systemvariablen auffällig mit 19 möglichen Inkonsistenzen

bringt nun nur noch die folgende Fehlermeldung (auch nur, weil ich den einen Eintrag händisch getillt habe:

Code: Alles auswählen

Konsistenzcheck Systemvariablen
Metadaten Konsistenzcheck
Auszug aus PreRelease SDV 3.07.10
Black in 2019
---------------------------------
[ID]: 8664 - (testBool2) Type Logigwert - MetaData : BV0 fehlt --> Korrigiert
---------------------------------
Geprüft: 68 Systemvariablen
Davon 1 Systemvariablen auffällig mit 1 möglichen Inkonsistenzen

ohne das vorherige zwangslöschen ergibt sich

Code: Alles auswählen

Konsistenzcheck Systemvariablen
Metadaten Konsistenzcheck
Auszug aus PreRelease SDV 3.07.10
Black in 2019
---------------------------------
---------------------------------
Geprüft: 68 Systemvariablen
Keine Auffälligkeiten festgestellt

Black

[alchy]

Wenn es sich wirklich auf diese automatischen Systemvariablen "svEnergyCounterXXX" beschränkt sollte es in der Tat ein leichtes sein diese Skripte so zu reparieren das die Systemvariablen korrekt mit ihren passenden Metadaten angelegt werden.

Freu dich nicht zu früh.
Jede z.B. Logikvariable welche ich in eine z.B. Wertelistenvariable ÄNDERE,wird dann vom Script als unzulässig erfasst.
Eine Werteliste, welche ich in eine Zeichenkette ÄNDERE wird dann erfasst usw. usw.
Trifft so ähnlich zu, wie bei den Conditions in den Programmen.

Und dann schau dir mal an wenn du z.B. Logik->Zeichenkette->Logik vs. Logik->Zeichenkette->Alarm->Logik durchführst.

[EDIT]
Logik->Werteliste->Logik vs Logik->Werteliste->Alarm->Logik

ist gemeint. Sorry, mein Fehler - richtige Testreihe gemeint, aber falsch aufgeschrieben.
viewtopic.php?f=26&t=49228&start=20#p493230

Alchy

[Black]

... Und dann schau dir mal an wenn du z.B. Logik->Zeichenkette->Logik vs. Logik->Zeichenkette->Alarm->Logik durchführst...

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

[jmaus]

Insofern kannst du natürlich gerne zusätzlich deine eQ3 Tickets weiter aufmachen, darauf hoffen das diese dann bearbeitet werden und am Schluss dich wundern das dies nicht so schnell umgesetzt wurde wie du das vielleicht erhofft hast.

wie gesagt, EQ-3 und auch Du hattet eure Chance.
Ich habe es z.B. mit equalthan anders versucht und hier Anpassungen veröffentlicht die schlussendlich immer noch nicht in die Firmware vorgedrungen ist. Das könnte ich nun zwar immer weiter so treiben. Ich implementiere Verbesserungen oder fixe Fehler, du übernimmst es in die RaspberryMatic - ich hoffe, das es irgendwann mal auch in die CCU kommt...

Keine Angst, das kommt schon. Es dauert aber eben einige Zeit länger bis ein kommerziell denkendes Unternehmen von dem Nutzen dieses Features überzeugt ist wenn da nicht von den >1Mio Nutzern mindestens 100T plötzlich danach rufen. Ist halt einfach eine Frage des Kosten und Nutzens. Und dadurch das eQ3 eben eine andere Agenda/Prioritäten hat dauert sowas eben entsprechend - auch weil die eine recht strikte QC haben die im Zweifel lieber nichts ändert als potentiell dadurch sich Fehler einzuhandeln. Deshalb sind da immer recht viele Gespräche notwendig und ein kontinuierliches Nachhaken. Den Kopf allerdings in den Sand zu stecken erscheint mir definitiv nicht der richtige Weg zu sein. Dein Feature wurde ja in RaspberryMatic aufgenommen und verrichtet dort seinen Dienst sehr gut. Und so ist es nur eine Frage der Zeit bis das auch in die CCU3 aufgenommen wird. Und es ist ja nicht so das sowas nicht schon in der Vergangenheit passiert ist. Ich könnte hier eine ziemlich lange Liste von Dingen aufführen die inzwischen in der CCU Firmware übernommen wurden und das das passiert ist ist doch eine gute Sachen und ein gutes Zeichen IMHO.

Wenn es sich wirklich auf diese automatischen Systemvariablen "svEnergyCounterXXX" beschränkt sollte es in der Tat ein leichtes sein diese Skripte so zu reparieren das die Systemvariablen korrekt mit ihren passenden Metadaten angelegt werden.

Freu dich nicht zu früh.
Jede z.B. Logikvariable welche ich in eine z.B. Wertelistenvariable ÄNDERE,wird dann vom Script als unzulässig erfasst.
Eine Werteliste, welche ich in eine Zeichenkette ÄNDERE wird dann erfasst usw. usw.
Trifft so ähnlich zu, wie bei den Conditions in den Programmen.

Auch das sollte sich doch recht einfach lösen lassen (ggf. sogar direkt in ReGaHss). Aber wie gesagt, am besten wäre wenn ich hierfür ein Ticket/Issue in GitHub hätte damit ich das dann bei Gelegenheit abarbeiten kann.

[debianatoe]

Mein Ergebnis:

Code: Alles auswählen

Geprüft: 211 Systemvariablen
Davon 19 Systemvariablen auffällig mit 19 möglichen Inkonsistenzen

Betroffen sind bei mir nur Anwesenheit.* (von hmpdetect) und svEnergyCounter SVs.

[Black]

Mein Ergebnis:

Code: Alles auswählen

Geprüft: 211 Systemvariablen
Davon 19 Systemvariablen auffällig mit 19 möglichen Inkonsistenzen

Betroffen sind bei mir nur Anwesenheit.* (von hmpdetect) und svEnergyCounter SVs.

darf ich fragen wie die Fehlerzeile zu der Anwesenheit aussieht ?

[debianatoe]

Hier die Fehlerzeilen zu den Anwesenheit-SVs:

Code: Alles auswählen

[ID]: 19171 - (Anwesenheit.Gast) Type Logigwert - MetaData : UNIT fehlt
[ID]: 19170 - (Anwesenheit.Nutzer) Type Logigwert - MetaData : UNIT fehlt
[ID]: 19173 - (Anwesenheit.string) Type Zeichenkette - MetaData : UNIT fehlt