VisualStudio Code und Devcontainer

OliverIO

@UncleSam
leider bei buanet beta ebenfalls keine Änderung.
Dann muss ich mal schauen, was da im iobroker alles passiert.
Hast du mit vscode schon mal den ganzen iobroker mit einem debugger laufen lassen?
Hast du da eine Launch-Konfiguration?

UncleSam

@Asgothian sagte in VisualStudio Code und Devcontainer:

was heisst "F5" ?

Genau das was du machst: In VS Code debuggen mit einer Launch Config.

Egal was ich mache, ich bekomme keinerlei Möglichkeiten etwas zu debuggen. Wenn ich mir ein "launch.js" anlege und dann diese Konfiguration starte (Siehe Bild: Launch ioBroker.zigbee)
starte kommt es (wahrscheinlich wie erwartet) zurück. Irgendwelche Breakpoints ausserhalb des "main" werden nicht angesprochen.

Ja, da geht etwas noch schief. Hast du es mal mit einem anderen Adapter versucht (z.B. mein Loxone). Geht es da auch nicht?

Spricht irgend etwas dagegen das lokale Verzeichnis direkt in /opt/iobroker/node-modules/name des adapters zu spiegeln ?

Wieso nicht einfach npm link? Der Grund ist: wenn jemand aus versehen npm install im ioBroker Verzeichnis macht, wird der gesamte Inhalt des Ordners überschrieben und damit ist dann dein Source Code weg.

UncleSam

@OliverIO sagte in VisualStudio Code und Devcontainer:

Hast du mit vscode schon mal den ganzen iobroker mit einem debugger laufen lassen?
Hast du da eine Launch-Konfiguration?

Nein, noch nie versucht.

AlCalzone

@UncleSam sagte in VisualStudio Code und Devcontainer:

Wieso nicht einfach npm link?

Das setzt voraus, dass das dev-Verzeichnis direkt in /opt/iobroker liegt. Spricht grundsätzlich erst mal nix dagegen, aber das ist aktuell noch nicht der Fall.

UncleSam

@AlCalzone sagte in VisualStudio Code und Devcontainer:

@UncleSam sagte in VisualStudio Code und Devcontainer:

Wieso nicht einfach npm link?

Das setzt voraus, dass das dev-Verzeichnis direkt in /opt/iobroker liegt. Spricht grundsätzlich erst mal nix dagegen, aber das ist aktuell noch nicht der Fall.

Wieso denn das? Wieso funktioniert ein Link /workspace nach /opt/iobroker nicht?

Asgothian

@UncleSam sagte in VisualStudio Code und Devcontainer:

Ja, da geht etwas noch schief. Hast du es mal mit einem anderen Adapter versucht (z.B. mein Loxone). Geht es da auch nicht?

Bisher nur mit dem Zigbee Adapter bzw. dem mit dem create-adapter erzeugten.

Aber wenn ich die Diskussion vollständig verstanden habe ist es so das ich generell nur den Start des Adapters debuggen kann, nicht die Events wenn sie denn kommen. Ist das korrekt ?

A.

UncleSam

@Asgothian sagte in VisualStudio Code und Devcontainer:

Aber wenn ich die Diskussion vollständig verstanden habe ist es so das ich generell nur den Start des Adapters debuggen kann, nicht die Events wenn sie denn kommen. Ist das korrekt ?

Nein, das stimmt nicht. Sobald der Adapter läuft kann man jederzeit Breakpoints haben (neue erstellen oder in alte laufen); also auch, wenn ein neues Event aus einem Drittsystem reinkommt.

Asgothian

@UncleSam
Hmm.. Das funktioniert bei mir bisher durchgängig nicht.

A.

UncleSam

@Asgothian sagte in VisualStudio Code und Devcontainer:

Das funktioniert bei mir bisher durchgängig nicht.

Ich weiss leider wirklich nicht, was das Problem ist. Hier ein GIF mit meinem Loxone Adapter, frisch von master und nach einem Container Rebuild:

Zuerst starte ich den Debugger, dann kommt er im onReady() in einen Breakpoint. Danach setze ich einen zweiten Breakpoint in einem "Event Handler," der dann nach einiger Zeit auch angesprungen wird (wenn eben ein neues Event vom Miniserver kommt).

Asgothian

@UncleSam

Nochmal vielen Dank für die Hilfe. Soweit ist es ok. Entscheidend war die Anpassung des Adapterpfades, sprich das einfügen von

            dirname: __dirname.indexOf('node_modules') !== -1 ? undefined : __dirname,

in die Optionen beim Aufruf des Adapter Contstructors,
sowie das hinzufügen der Argumente im launch.json

  "args": ["--debug", "0"],

Letzteres war im übrigen auch notwendig wenn man einen Adapter hat der vom create-adapter für den .devcontainer vorbereitet wurde. Ohne diese Argumente kann der Adapter nicht vom Studio aus gestartet werden.

A.

AlCalzone

@UncleSam sagte in VisualStudio Code und Devcontainer:

Wieso denn das? Wieso funktioniert ein Link /workspace nach /opt/iobroker nicht?

Weil dann die Suche nach dem Adapter-mainfile im JS-Controller nicht funktioniert, da den Links nicht gefolgt wird. Innerhalb des ioBroker-Verzeichnisses geht es aber (empirisch herausgefunden).

OliverIO

@AlCalzone @UncleSam
Falls Interesse an der launch.json besteht, wie man den iobroker an sich debuggen kann:

Folgendes ist zu beachten, ausgehend von der oben genannten devcontainer Konfiguration:

Das Startverzeichnis muss für vs code geändert werden, in dem man unter
Menü File -> Open Folder dann /opt/iobroker auswählt
Bei ersten mal kann mann dann über den Befehl
Menü Run -> Add Configuration (falls noch keine launch.json für diesens Startverzeichnis besteht, alternativ Open Confiuration) eine Konfiguration anlegen und den unten angegebenen Inhalt einkopieren
Für ein entsprechenden Befehl (bspw start, oder wie hier "host set x" muss in args jedes einzelne Argument separat als Arrayelement aufgezählt werde.
Danach können Breakpoints gesetzt werden und mit F5 das Debugging gestartet werden.

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "args": ["host","set","x","--debug", "0"],    
            //"stopOnEntry": true,        
            "program": "/opt/iobroker/node_modules/iobroker.js-controller/iobroker.js"
        }
    ]
}

OliverIO

ich kam ein wenig weiter mit meinem Problem.
leider funktioniert es auch nicht die Befehle aus der postCreateCommand auf der shell nochmal einzugeben, da objects.json in einem inkonsistenten Zustand vorliegt.
Im Rahmen der Containererzeugung von buanet muss ja der Hostname nochmal neu gesetzt werden, da iobroker den temporären Hostnamen des Containers nimmt.
Im Rahmen dieses umbenennens gibt es wohl einen Fehler, so das zwar alle Objekte umbenannt werden, aber nicht die Instanzen.
Als Workaround konnte ich das beheben, in dem ich alles nochmal auf den temporären Hostnamen umbenenne (Name muss aus objects.json ausgelesen werden oder aus dem docker-log), im Anschluss kann dann der eigentliche Name nochmal gesetzt werden (Befehl iob host set <name>)
Der Fehler tritt aber nur auf, wenn in postCreateCommand etwas drin steht. Welcher Fehler da auftritt, lässt sich aus den Logs aktuell leider nicht auslesen.

UncleSam

@OliverIO Das ist schon mal ein guter erster Schritt! Ich denke, wir müssen Bug möglichst schnell finden und wenn möglich noch im nächsten Release des js-contoller fixen. Immer mehr Leute setzen auf Docker, das sollte sauber laufen.

AlCalzone

@OliverIO @UncleSam
Ich finde das mit den Instanznamen äußerst komisch und kann mir derzeit nicht erklären, an welcher Stelle es schief läuft.
Wenn ich direkt unter Windows arbeite und VSCode den Docker-Container erstellen lasse, passt alles. Können wir das eingrenzen, ob es ggf. nur mit Docker auf Linux auftritt?

UncleSam

@AlCalzone Mit @Asgothian zusammen habe ich gestern herausgefunden, dass es auf einem Mac mit "cached" Probleme gibt. Möglicherweise ist das hier dasselbe Problem. Dateien, die im ioBroker Verzeichnis lagen, waren plötzlich korrupt, was zu ganz komischen Fehlern führte.

@OliverIO, kannst du mal versuchen, im docker-compose.yml das :cached zu löschen?

OliverIO

@UncleSam
cached habe ich gelöscht, dann volume image und container für luxtronik gelöscht und container neu erzeugt.
Ich habe keine Veränderung zu den vorherigen Versuchen entdecken können.
Mit postCreateCommand kein Start, ohne startet iobroker.
Die korrupten Dateien sind in welchem Verzeichnis entstanden? Soll ich da nochmal speziell schauen?

UncleSam

@OliverIO sagte in VisualStudio Code und Devcontainer:

Die korrupten Dateien sind in welchem Verzeichnis entstanden? Soll ich da nochmal speziell schauen?

Das ganze /opt/iobroker wird ja gemountet, also irgendwas dort drin (wäre ja auch bei dir so). Es war ein installiertes Node Module.

OliverIO

@UncleSam
dann ist im Windows-Fall nichts korrupt. Ohne postCreateCommand läuft alles super.
Mit postCreateCommand erst nachdem man die hosts wie beschrieben wieder umbenannt hat.
Mir dünkt, das die Befehle in postCreateCommand gar nicht ausgeführt wird. Muss aber nochmal genauer schauen.

OliverIO

@AlCalzone @UncleSam
Hi,

ich hab hier noch ein wenig rum experimentiert und konnte es ein wenig eingrenzen.
Problem 1) sobald der Befehl "iob plugin disable sentry" enthalten ist, erscheint im Log von vs code bei der Erstellung des Containers immer ein postCreateCommand failed

[2020-11-20T12:38:42.946Z] [PID 11220] [8148 ms] Start: Run: docker exec -i -u root -e SSH_AUTH_SOCK=/tmp/vscode-ssh-auth-94fa740e69f0e0f5f0af463318e0645c8f73d97c.sock -e REMOTE_CONTAINERS_IPC=/tmp/vscode-remote-containers-ipc-94fa740e69f0e0f5f0af463318e0645c8f73d97c.sock -e REMOTE_CONTAINERS=true -w /workspace 52441b62fc5a811d95518668a85e15327e3c1ee79f3763a685d25d0fd6351011 /bin/sh -c iob del discovery && iob plugin disable sentry && iob object set system.config common.licenseConfirmed=true && NPM_PACK=$(npm pack) && iob url "$(pwd)/$NPM_PACK" --debug && rm "$NPM_PACK"
[2020-11-20T12:38:45.560Z] [PID 11220] [10762 ms] Delete adapter "discovery"
[2020-11-20T12:38:45.563Z] [PID 11220] [10765 ms] npm uninstall iobroker.discovery --error --prefix "/opt/iobroker" (System call)
[2020-11-20T12:38:48.790Z] [PID 11220] [13992 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
[2020-11-20T12:38:48.797Z] [PID 11220] [13999 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (node_modules/osx-temperature-sensor):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
[2020-11-20T12:38:48.797Z] [PID 11220] [13999 ms] 
[2020-11-20T12:38:53.360Z] [PID 11220] [18562 ms] postCreateCommand "iob del discovery && iob plugin disable sentry && iob object set system.config common.licenseConfirmed=true && NPM_PACK=$(npm pack) && iob url \"$(pwd)/$NPM_PACK\" --debug && rm \"$NPM_PACK\"" failed.

lass ich es weg, dann läuft zumindes die postCreateCommand komplett durch

[8093 ms] Start: Run: docker exec -i -u root -e SSH_AUTH_SOCK=/tmp/vscode-ssh-auth-f5e8539333a46dc4ea70ee13c568241fac389e86.sock -e REMOTE_CONTAINERS_IPC=/tmp/vscode-remote-containers-ipc-f5e8539333a46dc4ea70ee13c568241fac389e86.sock -e REMOTE_CONTAINERS=true -w /workspace fc7f0285e005382bea59f9366038fa839488249323ee8d8291a1e95f49d3125b /bin/sh -c iob del discovery && iob object set system.config common.licenseConfirmed=true && NPM_PACK=$(npm pack) && iob url "$(pwd)/$NPM_PACK" --debug && rm "$NPM_PACK"
[10698 ms] Delete adapter "discovery"
[10702 ms] npm uninstall iobroker.discovery --error --prefix "/opt/iobroker" (System call)
[14117 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
[14125 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (node_modules/osx-temperature-sensor):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
[14126 ms] 
[17551 ms] The object "system.config" was updated successfully.
[21506 ms] install /workspace/iobroker.luxtronik2-0.0.2.tgz
[21644 ms] NPM version: 6.14.8
[21645 ms] npm install /workspace/iobroker.luxtronik2-0.0.2.tgz --loglevel error --prefix "/opt/iobroker" (System call)
[24519 ms] + iobroker.luxtronik2@0.0.2
added 7 packages from 80 contributors in 2.529s
[24659 ms] 
15 packages are looking for funding
  run `npm fund` for details

[24694 ms] upload [4] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/words.js words.js application/javascript
[24750 ms] upload [3] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/style.css style.css text/css
[24804 ms] upload [2] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/luxtronik2.png luxtronik2.png image/png
[24859 ms] upload [1] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/index_m.html index_m.html text/html
[24912 ms] upload [0] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/admin.d.ts admin.d.ts video/mp2t

Aber in beiden Fällen läuft iobroker zwar auf dem Server, aber admin wird nicht gestartet, daher kein Browserzugriff

Problem 2: (denke ich)
Wenn man in beiden Logs den Befehl docker exec anschaut, dann bemerkt man, das zur Ausführung ein temporärer Container gewählt wird und nicht der schon umbenannte.
Das würde zumindest das erklären, warum es keine Probleme gibt, wenn kein postCreateCommand angegeben wurde.

NEWS

VisualStudio Code und Devcontainer

Support us

719
Online

31.7k
Users

79.8k
Topics

1.3m
Posts

NEWS

VisualStudio Code und Devcontainer

Support us

719Online

31.7kUsers

79.8kTopics

1.3mPosts

719
Online

31.7k
Users

79.8k
Topics

1.3m
Posts