ReGaHss-Inkonsistenzen bzgl. DP ValueType() vs MIN/MAX MetaDaten

[jmaus]

entsprechend in der WebUI angepasst werden das beim wechsel der Systemvariablen in ein Integer-type bzw. anderen type auch die MIN/MAX Metadatenwerte entsprechend mit geändert werden.

Quasi hier?
https://github.com/eq-3/occu/blob/maste ... #L813-L844

Müsste dann wohl mit in 0097 rein, weil der Patch den betreffenden Block schon modifiziert

Genau. Am besten sollte man dann auch gleich noch testen welche metadaten es sonst noch so gibt die ggf resettet gehören bei einem wechsel und das typ unabhängig. Denn eine zeichenketten sysvar braucht ja z.b. gar kein min/max und dann muss das halt weg. Bastelst du da ein PR?

[jp112sdl]

Bastelst du da ein PR?

Würde ich, aber vorher solltest du festlegen, welche Werte für MIN und MAX je nach SV-Typ gesetzt werden sollten.

An sich ist es wohl nur der Variablentyp "Zahl", bei dem man überhaupt einen ValueMin und einen ValueMax (in der WebUI) definieren kann.
Für alle anderen Typen könnte grundsätzlich obj.ValueMin=null;obj.ValueMax=null; stehen.

[Black]

Wechsel des types der sysvar z.b. muss auch zu Anpassungen in den singleconditions führen, in denen die verwendet wird.

Ist sonst einer der Gründe weshalb webui Programme dann nicht mehr triggern

Black

[Silverstar]

Wäre es dann nicht sinnvoller, das Ändern der Variablen ganz zu streichen? Ob ich eine Variable ändere oder (lösche und) neu anlege, macht kaum einen Unterschied.

Ein Vorteil, dass die ja im Programm bleibt wenn man sie nur ändert, sehe ich nicht. Muss das Programm ja eh ändern, wenn ich nun z.B. von Helligkeit >200 auf Helligkeit "wahr" wechsel.

[jmaus]

Wäre es dann nicht sinnvoller, das Ändern der Variablen ganz zu streichen? Ob ich eine Variable ändere oder (lösche und) neu anlege, macht kaum einen Unterschied.

Prinzipiell geb ich dir da recht. Aber das Feature würde ich jetzt nicht einfach streichen wollen, gerade auch weil man ja nicht jede Systemvariable nun in einem WebUI Programm nutzt und da es durchaus gut/sinnvoll sein kann wenn man da einfach den Typ ändern kann ohne das sich die ISEid ändert. Ich würde eher dafür plädieren einen Check einzubauen ob die SysVar in einem Programm verwendet wird und dann eine Warnung ausspucken wenn das so ist.

[MichaelN]

Es sollte aber doch nicht viel aufwendiger sein gleich die Programme zu korrigieren. Ich glaube den Code dafür bekomme sogar ich noch hin.

[jmaus]

Es sollte aber doch nicht viel aufwendiger sein gleich die Programme zu korrigieren. Ich glaube den Code dafür bekomme sogar ich noch hin.

Na dann her mit dem PR

[MichaelN]

Na dann her mit dem PR

Mit der Github-Bürokratie stehe ich immer noch auf Kriegsfuß. Ich habe mein bestes gegeben: https://github.com/jens-maus/RaspberryMatic/pull/2183

Folgender Code eingefügt in system.fn in Zeile https://github.com/eq-3/occu/blob/18bbb ... em.fn#L851

Code: Alles auswählen

string SingleCond; object SingleCondObjekt;
foreach(SingleCond,dom.GetObject(ID_SCONDITIONS).EnumIDs() ){
	SingleCondObjekt = dom.GetObject(SingleCond);
    if (SingleCondObjekt) {
    	if (((SingleCondObjekt.LeftVal() == sv.ID() ) && (SingleCondObjekt.LeftValType()== ivtSystemId ) )) {
                     if ((ist == istAlarm) || (ist == istBool)) {
                     	SingleCondObjekt.ConditionType(1);
                     	SingleCondObjekt.RightVal1ValType(ivtBinary); SingleCondObjekt.RightVal1(false);
                     	SingleCondObjekt.RightVal2ValType(ivtBinary); SingleCondObjekt.RightVal2(false);
                    } elseif (ist == istGeneric) {
                     	SingleCondObjekt.ConditionType(8);
                     	SingleCondObjekt.RightVal1ValType(ivtFloat); SingleCondObjekt.RightVal1(system.GetVar("iMinVal"));
                     	SingleCondObjekt.RightVal2ValType(ivtFloat); SingleCondObjekt.RightVal2(0.0);
                    } elseif (ist == istEnum) {
                     	SingleCondObjekt.ConditionType(1);
                     	SingleCondObjekt.RightVal1ValType(ivtInteger); SingleCondObjekt.RightVal1(0);
                     	SingleCondObjekt.RightVal2ValType(ivtInteger); SingleCondObjekt.RightVal2(0);
                    } elseif (ist == istChar8859) {
                     	SingleCondObjekt.ConditionType(1);
                     	SingleCondObjekt.RightVal1ValType(ivtString); SingleCondObjekt.RightVal1("");
                     	SingleCondObjekt.RightVal2ValType(ivtString); SingleCondObjekt.RightVal2("");
                    }
        }
    }
}

passt die SingleConditions ordnungsgemäß an den neuen Variablentyp an. Bei Zahlen wird der definierte Min-Wert berücksichtigt.
Getestet mit FW 3.67.10.20230119


Programm vorher:

Programm nach dem Ändern der Systemvariable auf Typ Zahl

[jmaus]

Hier nur kurz die Nachinfo das ich inzwischen die entsprechenden Änderungen in der WebUI bzw. im hm_startup file von ReGaHss umgesetzt habe um die Datentyp overflow/underflow Probleme zu lösen die dazu geführt haben das 1. die TIME_OF_OPERATION Datenpunkte bei einem HmIP-SWSD nicht die korrekten Werte zurückgeliefert hat und 2. auch die RSSI_XXXXX Datenpunkte innerhalb von ReGaHss die RSSI Werte immer positiv ausgegeben haben und man die immer via subtrahieren von 256 auf den korrekten Wert zu schieben der via XMLRPC aber korrekt ausgegeben wurde. Siehe hier:

https://github.com/jens-maus/RaspberryM ... 933592d231

Diese Anpassungen sollte diese Probleme meinen Tests nach nun beseitigen. Es fehlt jetzt nur noch die entsprechende ReGaHss Änderung das der korrekte Datentyp schon beim Anlernen eines Gerätes für alle Datenpunkte korrekt gesetzt wird und nicht für RSSI_XXX und TIME_OF_OPERATION standardmäßig auf ivtByte gesetzt wird (was eben falsch war). Diese Änderung wird aber demnächst kommen.

Für interessierte Tester die einen HmIP-SWSD haben oder sich schon immer gewundert haben warum die RSSI_XXXX Datenpunkte die RSSI Werte nie im Minusbereich ausgegeben hatte sollte mit dem nächsten nightly snapshot diese Probleme beseitigt sein. Gerne bitte schön breit testen und einfach mal testen ob die RSSI Werte nun passen und auch die Ausgabe/Anzeige des TIME_OF_OPERATION Datenpunktes nun passt.

Auch sollte nach dem ersten Starten mit der neuen nightly snapshot dann der folgende ReGa-Skript keinerlei HSSDP Datenpunkt mehr anzeigen der dem ivtByte Datenpunkt zugeordnet ist:

Code: Alles auswählen

WriteLine("Searching for invalid ivtByte typed HSSDPs:");
string sDP;
foreach(sDP, dom.GetObject(ID_DATAPOINTS).EnumIDs()) {
  object obj = dom.GetObject(sDP.ToInteger());
  if((obj) && (obj.Type() == OT_HSSDP) && (obj.ValueType() == ivtByte)) {
    WriteLine(obj.ID() # " - " # obj.ValueType() # "/" # obj.ValueSubType() # " - " # obj.Name() # " - " # obj.Value() # " MIN:" # obj.ValueMin() # " MAX: " # obj.ValueMax());
    ! obj.ValueType(ivtInteger);
    ! obj.ValueSubType(istGeneric);
  }
}
WriteLine("DONE");

[Henke]

Code: Alles auswählen

WriteLine("Searching for invalid ivtByte typed HSSDPs:")

fehlt am Ende das ";"

keinerlei HSSDP Datenpunkt mehr anzeigen der dem ivtByte Datenpunkt zugeordnet ist:

Was ist mit dem folgendem Datenpunkten:

Code: Alles auswählen

1504 - 8/24 - HmIP-RF.0010DD899E5483:0.ERROR_CODE - 0 MIN:0 MAX: 255
3115 - 8/24 - VirtualDevices.INT0000002:0.ERROR_CODE - 0 MIN:0 MAX: 255