Grundsätzlich ist
.state ein Status. Ein Status kann unterschiedlich interpretiert werden, je nachdem, was der Status ist, z.B. ein Switch Item kann den Status
ON oder
OFF haben. Ganz wichtig:
ON und
OFF sind hier
keine Strings, sondern Status vom Typ
OnOffType.
openHAB kann diverse Datentypen ganz gut selbst zuordnen und liegt auch meist richtig bei der Wahl, aber manchmal geht das halt auch schief.
Dann muss man openHAB explizit anweisen, einen bestimmten Datentyp zu verwenden. Dieser Vorgang heißt "Type Casting".
Der Haken an der Sache: Ein Type Casting funktioniert nur, wenn der Status auch als dieser Typ interpretierbar ist, man muss also zuerst prüfen, ob der Status auch zu diesem Typ passt. Das macht man gewöhnlich mit
instanceof, welches
true oder
false liefert.
Wenn ich in Rules (egal welche Sprache) auf Methoden zugreifen will, muss ich vorher sicherstellen, dass diese Methoden auch zur Verfügung stehen, das geschieht ebenfalls über das Type Casting. Wenn ich beispielsweise aus einer beliebigen Zahl einen Integer generieren will, brauche ich die Methode
.intValue, welche für den Type Number definiert ist. Also erzeuge ich ein Number Objekt (mittels Type Casting) und wende dann die Methode
.intValue an.
Code: Alles auswählen
var meinIntegerWert = 0
if(meinNumberItem.state instanceof Number)
meinIntegerWert = (meinNumberItem.state as Number).intValue
Du kannst in Blockly programmieren, dafür ist Blockly ja da. Blockly hat aus meiner Sicht vor allem den Vorteil, dass Du alle möglichen Blocks sehen kannst, während Du für z.B. die DSL "wissen" musst, welche Befehle zur Verfügung stehen.
Die DSL ist nicht in Gänze dokumentiert.
Andererseits gibt es inzwischen wohl an die 100.000 Rules "da draußen", die bestens dokumentiert sind, oftmals kann man in den entsprechenden Threads sogar die Evolution der Rule nachverfolgen und lernen, warum eine Rule ursprünglich nicht funktioniert hat.
Die DSL (DomainSpecificLanguage) ist in XTend entwickelt worden (ein Modul, welches dazu entwickelt wurde, DSLs zu entwickeln), XTend wiederum ist in Java geschrieben, so dass es naheliegend ist, dass die DSL sich in weiten Teilen an Java orientiert.
Letztlich sind viele Dinge sehr ähnlich wie in Java, der openHAB-spezifische Teil der DSL besteht hauptsächlich aus dem Item Modell, so dass man extrem bequem auf die Items zugreifen kann - was locker 99% der Rules ausmachen dürfte.
Das Problem mit den Versionen ist so alt wie openHAB 
sprich, das gab es auch beim Wechsel von OH1 zu OH2 schon, wenn man allerdings in die offizielle Doku schaut, ist das alles extrem gut getrennt. Die Version lässt sich oben links auswählen, auch für recht alte Versionen.