{
"resource": "/Volumes/openHAB-conf/rules/test.rules",
"owner": "_generated_diagnostic_collection_name_#0",
"code": "org.eclipse.xtext.xbase.validation.IssueCodes.invalid_mutable_variable_access",
"severity": 8,
"message": "Cannot refer to the non-final variable strSensor inside a lambda expression",
"startLineNumber": 31,
"startColumn": 89,
"endLineNumber": 31,
"endColumn": 98
}
Zum anderen gibt es kein Update des Kombiitems wenn ein entsprechender Rollladen bewegt wird.
Ich habe die Gruppen im Verdacht ? Denn VSC zeigt beim Mouseover der Gruppe grAllshutters sowie deren beiden Untergruppen "NULL"
Egal welche Positionen die Rollladen haben...
So... das isses! Eine Rule mit 77 Zeilen Code ersetzt nun 28 Rules mit ca. 950 Zeilen Code!
Vielen vielen Dank Udo für Deine unermüdliche Geduld!
Hier habe ich nun viel über Gruppenfilter und HasMaps gelernt. Echt Top.
Hier nun die finale Rule (bis jetzt )
Wenn ich darf Udo, würde ich das ganze noch mal gesondert im Projektforum vorstellen.
Bei längerer Betrachtung ist mir aufgefallen das die Sensoren den Wert für die Luftfeuchte OHNE Kommastelle liefern.
Die Rule aber eine Kommastelle hinzufügt.
Liese sich das noch abändern ?
Edit:
Und ich habe beobachtet das wenn sich ein Rollladen Wert ändert wird diese Änderung erst ins entsprechende Kombiitem
geschrieben wenn sich einer der entsprechenden Temp oder Hum werte ändert ?
Das kannst Du gerne verwursten
Was das Komma betrifft: Standard liefert Zahlenobjekt.toString als Format .1f aus. Wenn Du das nicht möchtest (kann ich verstehen ) dann kannst Du dafür String::format("%.0f",Zahlenobjekt) verwenden. Die betreffende Zeile im Code sähe dann so aus:
var String strKombi = strTempTendence + " " + String::format("%.0f °C / ",nTemp) + strHumTendence + " " + String::format("%.0f %%",nHum) // Kombinierter String ohne Shutter
Man kann also die Einheit gleich mit ins Format einbetten.
Das Problem mit dem fehlenden Update bei Rollladenbewegung sollte eigentlich mit dem letzten Codeschnipsel behoben sein...
Wo ich gerade darüber nachdenke, vermutlich musst Du als Trigger die Gruppen angeben, in denen die Shutter unmittelbare Member sind, nicht die Gruppe aller Shutter.
openHAB5.1.3 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime - LXC, 4 Kerne, 3 GByte RAM)
Hostsystem Proxmox VE 9.1.9 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte
Nein, eben nicht Es reicht, die übergeordnete Gruppe zu filtern, beim Filter kann man ja durchaus die "Enkel Items" mit berücksichtigen, nur der Trigger auf das "Stamm Gruppenitem" funktioniert halt leider nicht.
openHAB5.1.3 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime - LXC, 4 Kerne, 3 GByte RAM)
Hostsystem Proxmox VE 9.1.9 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte
PeterA hat geschrieben: 13. Sep 2020 18:32
Nun denn, dann ist es eben so das die Position des Rollladens erst ins Kombiitem geschrieben wird sich wenn ein Temp oder Hum Item ändert.
Funktioniert es denn nicht mit den Triggern?
openHAB5.1.3 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime - LXC, 4 Kerne, 3 GByte RAM)
Hostsystem Proxmox VE 9.1.9 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte