Verständnisfrage Rules und Scripte in OH3

[thissiac]

Ich habe mir parallel zu meinem OH2.5 eine OH3 Instanz (Raspi) aufgebaut, um sanft zu migrieren.
Meine Zigbee Sensoren fange ich über einen USB-Stick und zigbee2mqtt ab. Hier steige ich um auf die Sonoff ZBridge mit Tasmota.
Meine Shellys jage ich auch ins MQTT.
Meine HUE'e gehen über das Gateway - Binding - ins OH.

Also der Umstieg ist relativ einfach.

Jetzt komme ich aber an die Rules und da scheint sich einiges geändert zu haben. Das kopieren von OH2 > OH3 wird nicht funktionieren,
weil ich meine Namenskonventionen für Items und Things geändert habe. Auch das Ändern der Namen in der Rules hat viele neue Probleme
mit sich gebracht. Also nutze ich die Gelegenheit, die eine oder andere Regel neu zu erstellen. Da über die UI nicht alles möglich ist, werde
ich mich wohl mit Blocky beschäftigen müssen, da Javascript nicht zu meinen Stärken gehört

Trotz einigen yt's und Forenbeiträgen habe ich den roten Faden noch nicht gefunden. Bei Blocky habe ich vergebens das "when" für den Trigger
gesucht. Dann weiß ich nicht, wann man ein Script nutzt, wann Blocky besser ist und ob ich noch Textfiles für globale Variablen brauche.
Kann es sein, dass ich den Trigger "WHEN" über die UI setzen muß, aber das "THEN" über Blocky oder ein Script ausführen muß??

Die Doku ist auch nicht unbedingt hilfreich. Bei meinen regeln geht es nicht nur um Lichter ein und ausschalten. Da sind schon einige
IF-THEN-ELSE-NOCHMAL ELSE-DARIN NOCH EINIGE IFs-usw. verschachtelt. Gibt es irgendwo was zu lesen, über den Ansatz, der dahinter steckt??

Fragen über Fragen. Ich war sooo glücklich mit meinem OH2. Aber ich weiß, irgendwann mußt das ja kommen

[./mf]

Deine Rules kannst du in der Main UI weiterhin erstellen.

Neue Rule erstellen und Name vergeben.
Deine Trigger alle im "When" Block definieren.
Im "Then" Block startest du ein "Script" "DSL". Dort kannst du 1:1 alles aus deiner Rule aus dem "Then" Block einfügen.

Wie du schreibst, hast du die Item Bezeichnungen geändert. Diese musst du in der Rule auch anpassen.

[int5749]

Also der Umstieg ist relativ einfach.

Ja, relativ

Jetzt komme ich aber an die Rules und da scheint sich einiges geändert zu haben. Das kopieren von OH2 > OH3 wird nicht funktionieren,
weil ich meine Namenskonventionen für Items und Things geändert habe. Auch das Ändern der Namen in der Rules hat viele neue Probleme
mit sich gebracht. Also nutze ich die Gelegenheit, die eine oder andere Regel neu zu erstellen. Da über die UI nicht alles möglich ist, werde
ich mich wohl mit Blocky beschäftigen müssen, da Javascript nicht zu meinen Stärken gehört

Hier kann ich nicht ganz folgen. Eigentlich sollte alle Rules wie gewohnt weiter funktionieren, ausser => Abfragen für die Zeit.
Denn OH2 nutze Joda-Zeit und mit OH3 muss dies auf Java-Zeit umgestellt werden. ist aber kein Hexenwerk und eigentlich schnell erledigt.

Ich bin seit meiner Umstellung für einigen Monaten immer noch mit den Rules unterwegs, die unter OH2 aktiv waren.

Gleiches gilt bei mir für things und items. Ich nutze die Main UI nur zur Installation von Bindings und Spielereien mit den Pages.
Produktiv ist bei mir immer noch die Sitemap, auch wenn die Pages mittlerweile auch in der iOS App verfügbar sind.

Viele Grüße

[thissiac]

Ich hab jetzt mal alle Test-Rules usw. rausgenommen und nochmal Schritt-für-Schritt eine Beispielregel übernommen.
Herhalten für Tests muß immer unser Gäste-WC

In OH3 habe ich die ersten Things und Items über die UI angelegt. In OH2 habe ich ausschließlich mit TXT gearbeitet.
Ich habe eine "Spiel"-Rule aus dem OH2 Verzeichnis in das OH3 Verzeichnis kopiert.

In der UI taucht die Rule nun mit einem Schloss auf. Einzige Unterschied, der Trigger wurde rauskommentiert.

Code: Alles auswählen

// Triggers:
// - When EG_WC_Occupancy changed

// context: EC_WC-1

		if (EG_WC_Occupancy.state == "false" || EG_WC_Occupancy.state == OFF) {
		....

Für mich sieht es so aus, als währe die Rule in ein einfaches Script umgewandelt.

Ich habe dann über die UI eine Regel erstellt mit der ich das Item EG_WC_Occupancy trigger
und als "THEN" die o.g. Script EC_WC-1 ausführe.

Ergebnis:

Code: Alles auswählen

2022-01-13 11:47:49.234 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'EC_WC-1' failed: The name 'EG_WC_Occupancy' cannot be resolved to an item or type; line 10, column 7, length 15 in EC_WC

Der Name kann nicht aufgelöst werden?

Das Item sehe ich und kann es über die UI auch steuern.
Habe ich ein Knick im Gehirn?

[int5749]

Habe ich ein Knick im Gehirn?

Nun ja, dies ist eine offene Frage, aber ich antworte mal nicht darauf, denn den habe ich auch manchmal

In der UI taucht die Rule nun mit einem Schloss auf. Einzige Unterschied, der Trigger wurde rauskommentiert.

Nein, da ist nix auskommentiert, dies ist nur eine andere Darstellung
Man achte auf den kleinen aber feinen Unterschied
// - When EG_WC_Occupancy changed << Trigger

// When EG_WC_Occupancy changed << Kommentar

Das Schloß ist da, weil es eine Text-basierte Rule ist. Diese kann in der Main UI angeschauen, aber nicht bearbeiten.

Ich habe dann über die UI eine Regel erstellt mit der ich das Item EG_WC_Occupancy trigger
und als "THEN" die o.g. Script EC_WC-1 ausführe.

Nun sind wir wieder bei dem Knick
EC_WC-1 ist KEIN Script, sondern einfach nur eine Benamung der Text-basierten Rule in der Main UI. Dies kann nicht angesprochen werden.


Poste doch mal die Rule und natürlich auch die dazu gehörenden Items. Evtl. kann man mit den notwendigen Information dann auch besser helfen

Viele Grüße

[udo1toni]

Insbesondere, eine Rule, die per *.rules Datei angelegt ist, wird in der UI angezeigt, aber sie ist schon angelegt. Da musst Du nichts weiter tun, die ist bereits aktiv.

[thissiac]

ok .. ich gehorche.



EG_WC.rules

Code: Alles auswählen

rule "WC_Licht ON/OFF"

when 

    	Item EG_WC_Occupancy changed 

    then 

		if (EG_WC_Occupancy.state == "false" || EG_WC_Occupancy.state == OFF) {

			EG_WC_Licht.sendCommand(OFF)
			
			logInfo("WC-RULE", "LICHT		| WC Sensor Bewegung:		" + EG_WC_Occupancy.state)
    			logInfo("WC-RULE", "LICHT		| WC Licht:				" + EG_WC_Licht.state)
 
			
		} 
		
		else if (EG_WC_Occupancy.state == "true" || EG_WC_Occupancy.state == ON) {
			
			EG_WC_Licht.sendCommand(ON)

			logInfo("WC-RULE", "LICHT		| WC Sensor Bewegung:		" + EG_WC_Occupancy.state)
    			logInfo("WC-RULE", "LICHT		| WC Licht:				" + EG_WC_Licht.state)
		}
end

UI > Rules

Code: Alles auswählen

// Triggers:
// - When EG_WC_Occupancy changed

// context: EC_WC-1


		if (EG_WC_Occupancy.state == "false" || EG_WC_Occupancy.state == OFF) {

       		
			EG_WC_Licht.sendCommand(OFF)
			
			logInfo("WC-RULE", "LICHT		| WC Sensor Bewegung:		" + EG_WC_Occupancy.state)
   		logInfo("WC-RULE", "LICHT		| WC Licht:					" + EG_WC_Licht.state)


		} 
		
		else if (EG_WC_Occupancy.state == "true" || EG_WC_Occupancy.state == ON) {
			
			EG_WC_Licht.sendCommand(ON)

			logInfo("WC-RULE", "LICHT		| WC Sensor Bewegung:		" + EG_WC_Occupancy.state)
   		logInfo("WC-RULE", "LICHT		| WC Licht:					" + EG_WC_Licht.state)
		}
		

[peter-pan]

Also so wie ich das sehe, heisst der "EG_WC_Licht eigentlich "Shelly11FE_Relay" und der "EG_WC_Occupancy" heisst "XiamoSensor182FEGWC_Occupancy". Und diese Item-Namen gibt es nicht in deiner Rule. Du benutzt anstelle der Item-Namen die Item Labels.

Versuch mal diese Namen in deiner Regel zu ändern.

[thissiac]

ok ... das war es.

Dann habe ich mich in die Irre leiten lassen, bzw. hab mich selber in die Irre geleitet.
Ich dachte, ich habe mir ein gutes Namenskonzept überlegt. Gut ist es, aber offensichtlich
führt es zu Interpretationsfehler. Eigentlich wollte ich genau das Gegenteil erreichen.

Item Name und Item Label muß ich nochmal überdenken

Aber vielen Dank. Ich dachte mir schon, dass das Problem vor dem Bildschirm zu suchen ist.

[peter-pan]

...Nobody's perfekt.

Ich nehme mal an du machst das alles über die MainUI und da musst du halt unter "Namen" deinen (gewünschten) internen Namen vergeben und unter "Label" die Bezeichnung, die du am Bildschirm sehen willst. Im Prinzip war das aber schon immer so. Aber durch die "neue Oberfläche" kann man da leicht verwirrt werden.
Ich benutze für die Anlage der Items immer noch die "Old-School-Version" und lege sie genau wie die Regeln in Text-Files ab. Das ist für mich übersichtlicher. Sollte das, was aber mittelfristig nicht geplant ist, mal geändert werden, kann ich die Items immer noch per Massenimport (Add items from Textual Definition) einlesen.