Item wird in Blockly nicht als Auswahl (Pick) angezeigt

[Maverick-811]

Hallo zusammen,

gerade ein Problem (Beitrag: Setpoint über Alexa steuern) gelöst und schon ist ein neues da.

Ich habe in Visual Studio eine ***.items Datei erstellt und darin eine (eigentlich 6 Thermostate)

Code: Alles auswählen

Group  ThermostatDusche             "Thermostat Dusche"         {alexa="Thermostat"}
Number TargetSetpointDusche     "Target Setpoint Dusche [%.1f °C]" (ThermostatDusche)  {alexa="TargetTemperature"}

eingetragen.

In OH3 wird unter Model (ein Häkchen in Show non-Semantic) eine
Group Thermostat Dusche und darunter ein Target Setpoint Dusche angezeigt.

Ich kann über Alexa jetzt die Sollwert Temperatur steuern.

Jetzt wollte ich natürlich damit ein Relay steuern und dazu eine Ist-Temperatur mit dem Sollwert vergleichen.
Also, eine Rules erstellt:

Mit Design Blockly eine If-Anweisung mit Vergleich von „get state of item“ (Ist-Temperatur) eingetragen (funktioniert) und
ein „get state of item“ für den Sollwert.

Aber: Wenn ich beim Eingeben für den Sollwert das Fenster zum Picken aufmache, dann wird nur das Thermostat Dusche (Group) angezeigt, nicht aber das item für Target Setpoint Dusche.

Was mache ich falsch?

Vielen Dank im Voraus.
Horst

PS: Das gleiche ist auch für weitere 6 Thermostate zu sehen.

[udo1toni]

Erst mal kannst Du die Items auch über die *.items Dateien ganz leicht ins semantic Model integrieren, indem Du passende Tags hinzufügst.
Es gilt dabei: Ein Item darf maximal einmal im gesamten semantic Model auftauchen, entweder als Location, oder als Equipment oder als Point.
Ein Item darf dennoch beliebig vielen Gruppen angehören, die dürfen dann halt nicht Teil des Semantic Model sein (bzw. maximal eine, damit das ITem nur einmal im Model auftaucht)

Code: Alles auswählen

Group ThermostatDusche "Thermostat Dusche" ["Valve"] {alexa="Thermostat"}
Number TargetSetpointDusche     "Target Setpoint Dusche [%.1f °C]" (ThermostatDusche) ["Temperature"] {alexa="TargetTemperature"}

Vermutlich sollte die Temperatur auch besser ein Number:Temperature Item sein.

Willst Du nicht lieber zu openHAB4.1 wechseln?

[Maverick-811]

Vielen Dank für deine Antwort.

Voller Erfolg!!!

Willst Du nicht lieber zu openHAB4.1 wechseln?

Ja, bin mir nur nicht sicher, wie aufwendig das ist.
Gibt es eine Möglichkeit, dass einfach zu gestalten oder muss ich alles neu machen?

Gruß
Horst

[udo1toni]

Du kannst die Konfiguration gewöhnlich vollständig übernehmen. Je nachdem, wie alt die Version ist, von der Du kommst, musst Du naturgemäß Dinge anpassen, die in 4.1 anders laufen, je älter die Version, umso mehr Änderungen

Von OH1 nach OH2 Umstellung vieler Bindings auf thing-basierte Konfiguration.
Von OH2 nach OH3 alles, was noch v1 ist, muss auf thing-basiert geändert werden. Außerdem muss Joda Time auf JavaTime geändert werden.
Spätestens mit v3 ist es auch sinnvoll, sich mit UoM und auf jeden Fall mit dem Semantic Model auseinander zu setzen.
OH3 nach OH4... öhhh... Kleinigkeiten (also gefühlt...) Ein "Problem" mit UoM war bisher, dass die Persistence nicht damit umgehen kann. Es ist auch nicht so ohne weiteres möglich, das zu ändern (je nach Backend vielleicht gar nicht), weshalb man sich einen Workaround überlegt hat. Ab Version 4 muss deshalb für jedes UoM Item die Einheit mit angegeben werden, in der das Item den Wert als Zahl hält. Diese Einheit sollte dann auch nicht mehr geändert werden, denn Daten, die von der Persistence geladen werden, bekommen automatisch ebenfalls diese Einheit verpasst. Wenn man die Einheit nun nach einiger Zeit ändern würde, bekäme man z.B. in Charts einen Sprung.

Auf Seiten der Oberfläche hat sich extrem viel geändert, und da werden auch die größeren Hürden sein, gerade beim Umstieg von OH2 auf OH3 (OH1 hatte ja gar keine UI für die Verwaltung), aber auch von OH3 auf OH4, und sogar von OH4.0 auf OH4.1, weil viele Dinge nun anders (aber sinnvoll) angeordnet sind, es kann also schon passieren, dass man ein Funktion vermisst, nur um dann nach einer ganzen Weile durch Zufall im Forum darüber zu stolpern, dass sie lediglich auf anderem Weg erreichbar ist, und jetzt sogar viel einfacher als zuvor...

[Maverick-811]

Hallo Udo1toni,

ich habe auf einem Windows PC versucht ein Update/Upgrade von OH 3.4.4 auf OH 4.1 zu machen. Katastrophe!

Bin jetzt dazu übergegangen, eine neue OH 4.1 zu installieren.

1. Die Pages werde ich neu erstellen.

2. Jetzt habe ich gesehen. dass viele (ca. 80%) meiner Shelly Produkte selbständig erkannt wurden. Warum nicht alle? Gibt es da einen Trick?

3. Ich habe ca. 20 Rules und Scripts mit Blockly in meiner OH 3.4.4 Version.
Gibt es eine Möglichkeit diese einfach in OH 4.1 zu übernehmen?

Vielleicht macht es Sinn einen neue Beitrag mit diesen Fragen zu eröffnen. ???

Gruß
Horst

[udo1toni]

Grundsätzlich sollte es kein Problem sein, die komplette aus dem Altsystem zu übernehmen. Es gibt meines Wissens auch in der Windows Umgebung ein Tool, um ein Backup der Konfiguration zu erstellen (unter GNU/Linux openhab-cli backup, es müsste ein bin-Verzeichnis in der Nähe der Runtime geben). das backup landet so oder so in einer zip-Datei, die dann alles enthält, um den Zustand zum Zeitpunkt des Backups wieder herzustellen, beinhaltet aber ausdrücklich ausschließlich die Daten, nicht irgendwelche Programmversionen, sprich, man kann die Konfiguration auch versionsübergreifend einspielen, wobei man nicht damit rechnen sollte, dass versionsübergreifend alles einfach funktioniert
Alternativ kannst Du beides Systeme parallel nebeneinander öffnen und die Rules über die Codeansicht kopieren, wobei Du auf dem Zielsystem immer einen Rumpf einer Rule mit der korrekten ID anlegen musst, alles andere wird dann über den Code eingefügt.
Blockly verwendet unter OH3 Nashorn, unter OH4 kommt aber Graal zum Einsatz. Zumindest wenn die Rules über das Backup eingespielt werden, reicht es, die Rules einmal zu öffnen und neu abzuspeichern, openHAB passt den Code dann automatisch an (immer vorausgesetzt, man hat auch JavaScript Scripting Graal installiert)