Leere Ordner in Netzlaufwerk (Samba-Share)

[Skolle]

Liebe Community des OpenHAB-Forums,
mit Erscheinen von Version 3 sind meine Ambitionen wieder neu geweckt, nachdem ich bei 2.5 etwas hängen geblieben bin.

Nach Installation von Openhabian mit Openhab 3.0 auf einem Rasberry Pi 4 kann ich
-Samba konfigurieren (sudo vim /etc/samba/smb.conf); es ist also installiert
-per Putty auf meinen Raspberry Pi zugreifen
-Netzlaufwerk verbinden, so dass ich die Ordner html...things...transform sehe
-mit Visual Studio den Ordner des Netzlaufwerks einsehen.

Ich habe einige Things erstellt und sehe mein KNX-Gateway und meinen Receiver online.
ABER:
ich sehe keine Änderungen in den Ordnern des Netzlaufwerks; nicht in Windows und nicht in VS: es ist immer nur die readme.txt vorhanden.
Ich kann somit keine weiteren Konfigurationen durchführen.

Könnt ihr mir helfen?
Vielen Dank im Voraus

[udo1toni]

Es gilt das gleiche wie schon immer:
Die Konfigurationsdateien unter /etc/openhab/ (das ist der freigegebene Ordner openhab-conf) werden nicht mit Änderungen in der Main UI synchronisiert.
openHAB3 ist nach wie vor in der Lage, diese Konfigurationsdateien einzulesen, aber die Idee ist, die Konfiguration über die UI zu erledigen. Man kann die Konfiguration auch in der UI als Text bearbeiten.

[Skolle]

Alle klar,
vielen Dank für die schnelle Antwort.
Dann hatte ich da wohl in einem der vielen Tutorials, die ich gesehen habe, falsch verstanden.

[udo1toni]

Viele Tutorials für openHAB3?

[Skolle]

Eher welche für OH2.
Aber du schriebst ja: "das war schon immer so".
Und dann habe das wohl bei OH2 gesehen.

Ich frage mich dann: wofür wird dann immer Visual Studio empfohlen, wenn der Code doch in der Main UI geschrieben wird bzw. werden soll.
Oder anders: Wie kriege ich den denn synchronisiert?

[udo1toni]

Der Punkt ist, dass es in openHAB1 ausschließlich Textkonfiguration gab. Um es Umsteigern zu vereinfachen, die alte Konfiguration weiter zu verwenden, wurde in openHAB2 die identische Konfigurationsmethode ermöglicht. Jedoch sollte openHAB2 auch dazu in der Lage sein, per Autodiscovery konfiguriert zu werden, was, wenn man es in das Textformat gepresst hätte, unglaublich kompliziert geworden wäre. Der beschrittene Weg war dann, bei Änderungen an den Textdateien diese erneut in den Speicher von openHAB einzulesen, die entsprechenden Teile der Konfiguration aber als nur lesbar zu markieren.

In openHAB3 ist die Textkonfiguration nur noch verfügbar, weil viele Anwender (mich eingeschlossen) weiterhin über die alten Textdateien konfiguriert haben und dies der leichteste Weg ist, eine vorhandene Installation in openHAB3 weiter zu betreiben. Das wird beim nächsten Update nicht mehr so fortgeführt werden, da bin ich sehr sicher.

Was VSCode betrifft, das ist erst mal nur für openHAB2 empfohlen, aber es kann durchaus sein, dass hier auch für openHAB3 "Anschluss" gefunden wird. Das wird aber sicher etwas dauern, und es wird mit Sicherheit anders laufen als mit openHAB2.

[Skolle]

Ok,
dann werde ich nach vorne schauen und es so verwenden, wie es für OH3 vorgesehen ist: erstmal ohne Textkonfiguration und ohne VSC.
Danke für den schönen Austausch.

[Anbeku]

Ich hänge mich hier mal dran, weil ich da auch noch Fragen zu habe.

Der Punkt ist, dass es in openHAB1 ausschließlich Textkonfiguration gab. Um es Umsteigern zu vereinfachen, die alte Konfiguration weiter zu verwenden, wurde in openHAB2 die identische Konfigurationsmethode ermöglicht. Jedoch sollte openHAB2 auch dazu in der Lage sein, per Autodiscovery konfiguriert zu werden, was, wenn man es in das Textformat gepresst hätte, unglaublich kompliziert geworden wäre. Der beschrittene Weg war dann, bei Änderungen an den Textdateien diese erneut in den Speicher von openHAB einzulesen, die entsprechenden Teile der Konfiguration aber als nur lesbar zu markieren.

In openHAB3 ist die Textkonfiguration nur noch verfügbar, weil viele Anwender (mich eingeschlossen) weiterhin über die alten Textdateien konfiguriert haben und dies der leichteste Weg ist, eine vorhandene Installation in openHAB3 weiter zu betreiben. Das wird beim nächsten Update nicht mehr so fortgeführt werden, da bin ich sehr sicher.

Prinzipiell ist das ja alles schön mit OH3. Man kann die Thinks gut über die autodiscovery anlegen und auch die Models sind schnell als Hirarchie angelegt und damit hat man schon erstaunlich viel Funktionalität. Umständlich wird es aber bei den Rules. Da kann man einfache Sachen zusammenklicken, aber viel weiter als commandos senden scheint da direkkt nicht zu gehen und das ist schon verdammt umständlich. Wenn man sich das dann als code anschaut (ohne Garantie das die Rule richtig ist) kommt da dann so etwas raus:

Code: Alles auswählen

triggers:
  - id: "1"
    configuration:
      itemName: Aktuelles_Wetter_Aussentemperatur
      state: < 4
    type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: TeichUVLampe_Betrieb
      command: ON
    type: core.ItemCommandAction

Da kann ich dann auch drin editieren oder? Was genau ist das jetzt für eine Syntax? Da finde ich nichts drüber. Wenn ich da jetzt etwas komplexeres machen möchte wie:

Code: Alles auswählen

val telegramAction = getActions("telegram","telegram:telegramBot:xxxxxxxx")
telegramAction.sendTelegram("Hello world!")

Dann muss ich da doch wieder ein Skript in der alten Rules DSL einhängen?

[udo1toni]

Die Notation ist yaml. Ich denke nicht, dass es darum geht, in yaml Rules zu schreiben. Es ist aber als Austauschformat praktisch
da ich selbst noch nicht umgestiegen bin, habe ich mich auch noch nicht weiter mit Rules beschäftigt, aber bis auf Weiters kann man ja ohne Probleme die alten Rules auch mit der neuen Rules engine nutzen, einzige Einschränkung: man muss aus Joda Time Java Time machen.

[Anbeku]

Die Notation ist yaml. Ich denke nicht, dass es darum geht, in yaml Rules zu schreiben. Es ist aber als Austauschformat praktisch

Stimmt, Yaml hatttest du schon mal erwähnt aber hatte ich nicht mehr dran gedacht.

da ich selbst noch nicht umgestiegen bin, habe ich mich auch noch nicht weiter mit Rules beschäftigt, aber bis auf Weiters kann man ja ohne Probleme die alten Rules auch mit der neuen Rules engine nutzen, einzige Einschränkung: man muss aus Joda Time Java Time machen.

Ich habe keine alten Rules aber hab mal testweise eine geschrieben. Das funktioniert tatsächlich problemlos, und die Rule wird als nicht editierbar in der Gui angezeigt. Die interessante Frage ist was man machen soll, wenn man jetzt unter OH3 neu Regeln erstellt. Es scheint so gedacht zu sein, dass man sich den Trigger-Teil zusammenklickt und dann ggf den SCRIPT_BLOCK selber in der DSL schreibt. Ich finde das eher umständlich und mann kann offenbar keine globalen variablen verwenden. Also z.B. ein Timer der die Rule überdauert und eventuell von mehreren rules verwendet wird wüsste ich jetzt nicht wie das laufen sollte, aber vielleicht gibt es da auch Lösungen, die ich noch nicht gefunden habe.