Hallo zusammen,
habe bereits im Forum nach passenden Threads geschaut, aber leider nichts gefunden, was mir tatsächlich weiterhilft.
Ich habe Visual Studio Code gemäß dem Tutorial hier aufgesetzt: https://www.youtube.com/watch?v=MvpWAxR0ev4
Authentifizierung funktiontiert soweit und es kommen keine Fehlermeldungen. Es scheint allerdings so zu sein, dass der im Windows verknüpfte Pfad nicht der tatächlich genutzte Pfad ist. Direkte Änderungen in Openhab (z.B. Anlage eines Skripts) werden nicht im VS Explorer angezeigt und sind auch nicht unter Windows im gemappten Netzlaufwerk erkennbar. Das gilt auch für die andere Richtung.
Ich vermute daher, dass die Openhab Installation ggf. einen anderen Ordner verwendet. Hat jemand ähnliche Erfahrungswerte? Liegt es ggf. an samba? Auf welches Verzeichnis müsste ich ggf. in der samba cfg verweisen bzw. an welchen Stellen müsste ich die cfg alles anpassen?
Was etwas verwirrend ist, dass Items und Things im "Openhab"-Reiter korrekt angezeigt werden:
Falls ich etwas im Forum übersehen oder irgendein Tutorial im Netz übersehen habe, gerne darauf verweisen. Im Netz finden sich leider Tutorials hauptsächlich zu älteren OH Versionen, sodass man sich nicht sicher ist, ob die zu dem Zeitpunkt geäußerte Problemstellung und der Lösungsansatz noch aktuell sind.
Danke Euch!
Visual Studio Code Explorer Sync Problem
-
- Beiträge: 2
- Registriert: 13. Dez 2022 15:38
Visual Studio Code Explorer Sync Problem
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
- udo1toni
- Beiträge: 15248
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Visual Studio Code Explorer Sync Problem
Herzlich willkommen im Forum!
Nein, das sieht alles vollkommen korrekt aus. Eher vermute ich ein Missverständnis, was ca. elfundneunzig Prozent aller neuen User trifft.
Wenn Du in der UI etwas konfigurierst, hat das genau gar nichts (!) mit den Dateien im freigegebenen Verzeichnis zu tun. Da wird nichts geändert, nichts angelegt.
Wenn Du in VSCode Dateien im freigegebenen Verzeichnis speicherst (an passender Stelle, mit korrektem Inhalt) taucht die Konfiguration in der UI auf, ist dort aber nicht editierbar. Stattdessen wird ein Schloss an Thing, Item oder auch Rule angezeigt, um darauf hinzuweisen, dass es sich um eine Text Konfiguration handelt.
Warum ist das so?
In openHAB1 gab es ausschließlich die Text Konfiguration. UI war ausschließlich der Vorgänger der Basic UI oder auf Wunsch GreenT, aber kein Zugriff auf irgendeinen Teil der Konfiguration, das war auch nicht nötig
In openHAB2 wurde Autodiscovery mit eingebaut und damit war es sinnvoll und wichtig, die Konfiguration auch über ein Webinterface erledigen zu können. Und natürlich sollte dann auch möglichst viel (nicht alles...) über die UI konfiguriert werden können. Also wurde eine UI erstellt.
ABER.
Die UI verwendete zum Speichern der Einstellungen nicht die ursprünglichen Textdateien, sondern JSON Objekte, einfach, weíl es unfassbar viel effizienter ist (so Faktor 200, wenn ich mich richtig erinnere).
Auf der anderen Seite wollte man aber auch keinen alten User vergrätzen, es sollte möglich sein "einfach" umzusteigen. Deshalb (im Grunde nur als Übergang) konnte man die Textdateien unverändert weiter nutzen.
Nur war leider die UI von openHAB2 unfassbar schlecht, wenn es um die effiziente Erstellung von Konfigurationen geht. Und das hat sich für openHAB3 leider nicht völlig geändert, aber zumindest etwas verbessert.
Die Textkonfiguration ist halt mal um Längen effizienter, wenn man nicht beliebige Itemnamen haben möchte und massig Items und Things anlegen will.
Deshalb hat man auf Entwicklerseite auch ein Einsehen gehabt, zumindest für openHAB3
und die Textkonfiguration nicht angefasst, auch wenn damit immer noch die Kröte der zweigleisigen zueinander inkompatiblen Konfiguration bestehen bleibt. Es gab übrigens für openHAB auch einen anderen UI-Entwurf, den ich extrem gut fand, dort konnte man einfach zwischen grafischer und textlicher Konfiguration umschalten, überall (wobei die Textkonfiguraiton aber eher so wie in der Code-Ansicht aussah, aber trotzdem...), aber es ist halt die Main UI geworden.
Nein, das sieht alles vollkommen korrekt aus. Eher vermute ich ein Missverständnis, was ca. elfundneunzig Prozent aller neuen User trifft.
Wenn Du in der UI etwas konfigurierst, hat das genau gar nichts (!) mit den Dateien im freigegebenen Verzeichnis zu tun. Da wird nichts geändert, nichts angelegt.
Wenn Du in VSCode Dateien im freigegebenen Verzeichnis speicherst (an passender Stelle, mit korrektem Inhalt) taucht die Konfiguration in der UI auf, ist dort aber nicht editierbar. Stattdessen wird ein Schloss an Thing, Item oder auch Rule angezeigt, um darauf hinzuweisen, dass es sich um eine Text Konfiguration handelt.
Warum ist das so?
In openHAB1 gab es ausschließlich die Text Konfiguration. UI war ausschließlich der Vorgänger der Basic UI oder auf Wunsch GreenT, aber kein Zugriff auf irgendeinen Teil der Konfiguration, das war auch nicht nötig

In openHAB2 wurde Autodiscovery mit eingebaut und damit war es sinnvoll und wichtig, die Konfiguration auch über ein Webinterface erledigen zu können. Und natürlich sollte dann auch möglichst viel (nicht alles...) über die UI konfiguriert werden können. Also wurde eine UI erstellt.
ABER.
Die UI verwendete zum Speichern der Einstellungen nicht die ursprünglichen Textdateien, sondern JSON Objekte, einfach, weíl es unfassbar viel effizienter ist (so Faktor 200, wenn ich mich richtig erinnere).
Auf der anderen Seite wollte man aber auch keinen alten User vergrätzen, es sollte möglich sein "einfach" umzusteigen. Deshalb (im Grunde nur als Übergang) konnte man die Textdateien unverändert weiter nutzen.
Nur war leider die UI von openHAB2 unfassbar schlecht, wenn es um die effiziente Erstellung von Konfigurationen geht. Und das hat sich für openHAB3 leider nicht völlig geändert, aber zumindest etwas verbessert.
Die Textkonfiguration ist halt mal um Längen effizienter, wenn man nicht beliebige Itemnamen haben möchte und massig Items und Things anlegen will.
Deshalb hat man auf Entwicklerseite auch ein Einsehen gehabt, zumindest für openHAB3

openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 2
- Registriert: 13. Dez 2022 15:38
Re: Visual Studio Code Explorer Sync Problem
Hallo,
danke Dir! Danke auch für die zügige Antwort und die detaillierten Ausführungen.
Habe es aktuell in zwei Ordnern "automation" und "scripts" versucht. Ohne Erfolg:
Danke Dir!
danke Dir! Danke auch für die zügige Antwort und die detaillierten Ausführungen.
-> Ok, an der Stelle gehöre ich definitiv zu "den ca. elfundneunzig Prozent aller User". Hätte eher gedacht, dass bidirektional synchronisert wird.Wenn Du in der UI etwas konfigurierst, hat das genau gar nichts (!) mit den Dateien im freigegebenen Verzeichnis zu tun. Da wird nichts geändert, nichts angelegt.
-> An dieser Stelle habe ich noch aktuell ein Verständnisproblem. Durch das Mapping des Laufwerks in Windows habe ich die Verzeichnisse ja mehr oder weniger vorgegeben: An welcher Stelle müsste ich nun meine Javaskripte ablegen, damit diese in Openhab unter dem Menüpunkt "Skripte" gelistet werden?Wenn Du in VSCode Dateien im freigegebenen Verzeichnis speicherst (an passender Stelle, mit korrektem Inhalt) taucht die Konfiguration in der UI auf, ist dort aber nicht editierbar.
Habe es aktuell in zwei Ordnern "automation" und "scripts" versucht. Ohne Erfolg:
Danke Dir!
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
- udo1toni
- Beiträge: 15248
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Visual Studio Code Explorer Sync Problem
In VSCode greifst Du eigentlich nur auf das Verzeichnis openHAB-conf zu. Dies ist das Verzeichnis, welches in einem GNU/Linux über Paketmanager aufgesetztem openHAB dem Verzeichnis /etc/openhab/ entspricht. Dieses Verzeichnis ist so gemappt, dass Du über Samba von Windows aus darauf zugreifen kannst.
Die JavaScript Scripte gehören meines Wissens unterhalb ./automation/ in den Ordner js/. Allerdings nutze ich kein JavaScript (außer für Transformations, da gehören die Scripte dann ins Verzeichnis ./transform/...)
Grundsätzlich: In den Ordner ./scripts/ kommen ausschließlich DSL Scripte mit der Endung .script. Solche Scripte können aus DSL Rules heraus mit dem Befehl callScript(<name>) aufgerufen werden - und zwar OHNE die Endung. Diese Scripte waren nur dazu gedacht, Rules etwas kompakter zu gestalten. Da man keine Variablen übergeben kann, ist das Ganze nur sehr begrenzt sinnvoll einsetzbar.
In den Ordner ./transform/ kommen JavaScript Scripte für die JS Transformation, Mappings für die MAP Transformation und weitere Dateien verschiedener Formate (.scale, .xslt, keine Ahnung...), eben alles, das die Transformation Services betrifft.
In den Ordner ./rules/ kommen die *.rules Dateien (ausschließlich DSL Rules), in den Ordner ./sitemaps/ kommen die *.sitemap Dateien und so weiter. An der Endung der Datei (.sitemap, .script, .map...) kann man auch ablesen, dass es sich jeweils um EINE Sitemap, EIN Script, EIN Mapping usw. handelt - im Gegensatz zu .rules, .items, .things usw, dort stehen potentiell viele Objekte des entsprechenden Typs in einer Datei drin.
Der ./automation/ Ordner ist relativ neu, die Rules gehören ja eigentlich auch zur Automation, aber die gab es schon in openHAB1, man hätte also eine Inkompatibilität, wenn man den ./rules/ Ordner auch nach ./automation/ verschöbe. Alle neueren Optionen, die Autmation betreffend, findet man aber in diesem Ordner.
Allerdings legt man dort auch eher Module an, die man dann z.B. in den JavaScript Rules importiert. - Da ich das, wie gesagt, selbst nicht nutze, weiß ich nichts Genaues darüber
aber die Doku sollte eigentlich in der Zwischenzeit Einiges dazu hergeben.
Die JavaScript Scripte gehören meines Wissens unterhalb ./automation/ in den Ordner js/. Allerdings nutze ich kein JavaScript (außer für Transformations, da gehören die Scripte dann ins Verzeichnis ./transform/...)
Grundsätzlich: In den Ordner ./scripts/ kommen ausschließlich DSL Scripte mit der Endung .script. Solche Scripte können aus DSL Rules heraus mit dem Befehl callScript(<name>) aufgerufen werden - und zwar OHNE die Endung. Diese Scripte waren nur dazu gedacht, Rules etwas kompakter zu gestalten. Da man keine Variablen übergeben kann, ist das Ganze nur sehr begrenzt sinnvoll einsetzbar.
In den Ordner ./transform/ kommen JavaScript Scripte für die JS Transformation, Mappings für die MAP Transformation und weitere Dateien verschiedener Formate (.scale, .xslt, keine Ahnung...), eben alles, das die Transformation Services betrifft.
In den Ordner ./rules/ kommen die *.rules Dateien (ausschließlich DSL Rules), in den Ordner ./sitemaps/ kommen die *.sitemap Dateien und so weiter. An der Endung der Datei (.sitemap, .script, .map...) kann man auch ablesen, dass es sich jeweils um EINE Sitemap, EIN Script, EIN Mapping usw. handelt - im Gegensatz zu .rules, .items, .things usw, dort stehen potentiell viele Objekte des entsprechenden Typs in einer Datei drin.
Der ./automation/ Ordner ist relativ neu, die Rules gehören ja eigentlich auch zur Automation, aber die gab es schon in openHAB1, man hätte also eine Inkompatibilität, wenn man den ./rules/ Ordner auch nach ./automation/ verschöbe. Alle neueren Optionen, die Autmation betreffend, findet man aber in diesem Ordner.
Allerdings legt man dort auch eher Module an, die man dann z.B. in den JavaScript Rules importiert. - Da ich das, wie gesagt, selbst nicht nutze, weiß ich nichts Genaues darüber

openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 178
- Registriert: 6. Jun 2020 20:55
- Wohnort: Kirchheim Teck
Re: Visual Studio Code Explorer Sync Problem
Jsscripting rules würde ich nur über die UI erstellen. Normal abgespeicherte files unter automation/js/ werden regelmässig gelöscht, wenn du z.B node.js und die damit verbundenen helper libraries von OH installiert hast. (Kann über openhabian-config installiert werden).
Eigene Bibliotheken kann man dann sicher über npm erstellen. Siehe englische forum
Eigene Bibliotheken kann man dann sicher über npm erstellen. Siehe englische forum
Code: Alles auswählen
https://community.openhab.org/t/own-npm-library-is-working-but-why/141953
OH 3.4.2 auf Raspi 4 mit Aeotec z-wave Stick gen 5+ und zigbee conbee II