Hallo zusammen

Wie am letzten Meeting angekündigt, habe ich den dev-server nun veröffentlicht. Danke an @Bluefox und @apollon77 für die Unterstützung.

Was ist der dev-server?
Es ist ein Tool, das euch erlaubt, euren Adapter in einer eigenen, abgeschlossenen ioBroker-Instanz zu testen und rasch weiter zu entwickeln.

Weshalb sollte ich dev-server verwenden?
Wie hast du bis jetzt deine Anpassungen an den HTML-Dateien getestet? Ich garantiere dir, es ist jetzt viel einfacher:

1. dev-server run ausführen
2. HTML Datei in deinem lokalen Entwicklungsverzeichnis ändern und speichern
3. Fertig - der Browser lädt die Admin-Seite des Adapters automatisch neu.

Und nur deshalb sollte ich ein neues Tool benutzen?
Wie hast du denn bis jetzt deinen Adapter entwickelt und getestet? Auch hier ist es viel einfacher geworden:

1. dev-server watch ausführen
2. JavaScript (oder TypeScript) Adapter Code ändern und speichern
3. Fertig - der Adapter startet automatsich neu

Hui, das ist zu viel Maggi Magie für mich!
Dann debugge einfach deinen Adapter mit dem dev-server:

1. dev-server debug ausführen
2. Wenn du willst, kannst du nun deinen Debugger attachen
3. Mit Ctrl-C beenden und wieder bei Schritt 1. starten, wenn du Änderungen gemacht hast

Hast du nicht noch etwas vergessen?
Ja, stimmt: installieren sollte man das Tool schon noch zuerst. Aber auch das ist KISS:

1. npm install --global @iobroker/dev-server ausführen
2. In dein Adapter Entwicklungsverzeichnis wechseln
3. dev-server setup ausführen
4. Das .dev-server Verzeichnis in .npmignore und .gitignore eintragen

Aber ich will noch ....
Dann gib mal dev-server --help respektive dev-server <command> --help ein. Wenn's dann immer noch nicht geht, dann freue ich mich auf dein Feedback hier und natürlich in den GitHub Issues. PRs sind selbstverständlich willkommen.

/UncleSam

In den nächsten Monaten werde ich versuchen, wieder etwas in die ioBroker-Entwicklung einzusteigen; deshalb würde ich gerne als Diskussionspunkt die DX (Developer Experience) einbringen.
Fragen: was braucht ihr, was habt ihr, was sollte noch dazu kommen?
In meiner letzten aktiven Zeit bei ioBroker habe ich:

• das Developer Portal hochgezogen
• mit @AlCalzone den Adapter Creator weiter entwickelt
• mit @AlCalzone adapter-dev gestartet
• Weblate eingeführt

Was davon macht heute keinen Sinn mehr, was müsste weiter entwickelt werden und wo haben wir noch Lücken?

Ich glaube, es gibt einige Punkte, wo wir die DX noch verbessern könnten (danke übrigens an @mcm1957 für seine Arbeit in diesem Bereich in den letzten Monaten!) und die würde ich gerne von euch hören. In meinem "anderen Leben" bin ich Entwickler und "Berater" in diesem Bereich und habe in den letzten drei Jahren sehr viel gelernt (GitHub Automatisierung, vollständig automatische DevOps-Pipelines, ...) und von dem würde ich ioBroker gerne profitieren lassen.

Wie immer: bitte nicht hier diskutieren, sondern im Meeting. Wer keine Zeit hat ans Meeting zu kommen, gerne PN mit Vorschlägen / Kritik an mich.

Auch wenn ich der erste bin, der antwortet, soll das nicht heissen, dass meine Meinung wichtiger ist als die meiner Nachredner.

Es ist schon etwas dran, dass das Leben für Adapter Entwickler nicht ganz einfach ist. In der Vergangenheit wurden oft neue Features in js-controller und vor allem Admin entwickelt, ohne dass den Adapter Entwicklern frühzeitig klar kommuniziert wurde, was das für Auswirkungen hat. (Ich spreche hier nicht über die Objekt-Warnungen)

Seit über einem Jahr habe ich mir auf die Fahne geschrieben, die Adapter-Entwicklung und -Pflege zu vereinfachen und habe zusammen mit verschiedenen von euch schon einiges erreichen können:

• ioBroker Entwickler Portal
• dev-server
• Weblate für Übersetzungen
• adapter-dev
• neue Features im Adapter Creator

und im Moment arbeiten wir in einem Team an der komplett überarbeiteten Entwickler-Doku.

Beruflich wie auch bei ioBroker bin ich davon überzeugt, dass nur gutes Tooling zu guter Software führen kann. Und das war in der Vergangenheit schon ein grösseres Problem bei ioBroker. Das soll jetzt nicht eine Kritik am Core Team sein, sondern an uns allen: wir alle können dazu beitragen, das Ökosystem für uns besser zu machen.

Allerdings an einem Punkt darf das Core Team sich schon noch verbessern (wobei es schon grosse Fortschritte gab): die Kommunikation.

Ich weiss, ich bin auf keine Gegenliebe gestossen als ich vorgeschlagen habe, dass wir keine neue js-controller-Version veröffentlichen, bevor wir die Dokumentation nicht aktualisiert haben. Aber ein solcher Schritt wäre wirklich mal nötig um das Leben von "Teilzeitentwicklern" (und das sind ja die meisten von uns ) zu vereinfachen. Gewisse Diskussionen auf Telegram (z.B. mit @jogibear9988) haben schon gezeigt, dass vieles schlecht und gewisses sogar falsch dokumentiert ist.

Setzen wir uns alle doch zum Ziel für's 2022, dass wir noch besser kommunizieren und wir versuchen, unser Leben als Entwickler noch einfacher zu machen. Dann macht es nämlich auch weiterhin Spass, neue und alte Adapter (weiter) zu entwickeln!

Des Öfteren werde ich hier im Forum gefragt, was ich denn in Sachen Hausautomation bei unserem Umbau gemacht habe. Hier versuche ich, alles zu erklären. Fragen und Anmerkungen sind gerne willkommen, aber erwartet bitte nicht, dass ich das Haus nochmals umbaue!

Standort
Einfamilienhaus aus den 1960er Jahren im Dorfkern in der Region Bern / Solothurn im Schweizer Mittelland.

Gebäude
Kurz wie das Gebäude aufgebaut ist:

• DG: Dachgeschoss; Wohnzimmer, ein Bad und Arbeitszimmer
  • wurde komplett weggeräumt und durch einen (höheren) Holzaufbau ersetzt (auch: steileres Dach = mehr Raum)
• OG: Obergeschoss; die meisten Räume und alle Schlafzimmer befinden sich im Moment hier
  • Doppel-Mauerwerk, Decke als Balkenlage (nicht sichtbar) mit heruntergesetzter Decke
• EG: Erdgeschoss; Abstell- und Arbeitsräume, Technik und Waschküche
  • Mauern: Beton-Steine (einfach), Decke: Ziegeldecke (Hourdisdecke)
• UG: Garage mit drei Plätzen sowie Raum für die Wasserversorgung (eigene Quelle) - das UG befindet sich vor dem Haus und ist nicht direkt verbunden
  • Neubau aus Beton

EG und teilweise OG behandle ich wie einen Umbau, DG und UG sind wie ein Neubau zu sehen.

Grundsätze
Vor dem Umbau habe ich mir einige Grundsätze festgelegt und diese (wenn immer möglich) auch während der Planung und Ausführung eingehalten:

• Das Haus ist zu bedienen wie ein "dummes" Haus: es gibt für alles Schalter, dort wo man sie auch erwarten würde (nur erweiterte Funktionen sind ausschliesslich via App/Vis verfügbar)
• Alle möglichen Sensoren und Aktoren sollen vorhanden sein, auch wenn sie nicht von Anfang an benutzt oder automatisiert werden.
• Alles ist verkabelt - Funk gibt es nur, wo keine Kabel hingezogen werden können (oder die bestehenden Röhrchen zu klein sind). WLAN wird nicht für die Hausautomation verwendet (da nachts ausgeschaltet)!
• Kein Komplett-System von einem Anbieter sondern in jedem Bereich das optimale Produkt (wobei Preis und WAF genauso relevant sind wie der Funktionsumfang)
• Jede grosse Steckdose auf Bodenhöhe hat immer auch eine geschaltete (in der Schweiz haben wir 3-fach-Steckdosen in einer Dose, von denen jeweils eine geschaltet sein kann) und die meisten haben auch eine LAN-Dose mit zwei Anschlüssen
• Es gibt keine Switches in einzelnen Räumen, alle Netzwerkkabel laufen an einem Ort zusammen
• Es gibt keine LED-Trafos in einzelnen Räumen, sondern nur an einem zentralen Ort
• Beleuchtung wird wo möglich mit 24V LEDs gemacht

Technologien
Die folgenden Technologien habe ich eingesetzt:

• Wärmepumpe CTA Aeroheat 16iL (Luxtronik-basiert)
• Solaranlage mit Wechselrichter von SMA (aktuell ohne Speicher)
• Homematic mit CCU2 (kein HM IP)
• Loxone mit Miniserver Go
• Philips Hue
• 5V 16-Relaiskarten via I/O-Expander an I2C
• DMX-Dimmer (230V und 24V) via USB-DMX-Adapter
• Bodenheizungsaktoren (24V)
• Griesser Storen mit 230V Motor
• Fenstersensoren in den Siegenia-Fenstern verbaut (UMS001: kombinierte Verschluss- und Öffnungsüberwachung)
• Velux Dachfenster mit eingebautem Solar-Motor (kabellos)
• Landroid Rasenmäher mit 3 Zonen

Hardware und Netzwerk

• Router: DSL Fritzbox (mit VoIP)
• Netzwerkkomponenten: UniFi USG, Switches und WiFi APs
• QNAP NAS mit Virtualization Station und Container Station (ioBroker Master)
• 4x Raspberry Pi 3 (ioBroker Slave)

ioBroker Architektur

• Multihost (Master auf NAS, Raspis als Slaves)
• Redis
• MariaDB als History-Datenbank
• Alle Adapter, die nicht direkt mit Hardware sprechen, sind auf dem NAS installiert
• Auf den Raspis laufen nur I2C und (einmal) uDMX

Technik-"Räume"
Es gibt im gesamten Haus drei Orte, an denen die Technik verbaut ist:

• EG: Schrank in der Waschküche mit:
  • NAS
  • USV für alle Geräte der Hausautomation (verkabelt in die zwei anderen Technik-"Räume")
  • 1 Raspberry Pi für 4 Relaiskarten (230V)
  • 1 Raspberry Pi für 2 Relaiskarten (230V), USB-DMX Adapter und USB-IR-Kopf für Stromzähler
  • 1 Raspberry Pi für 2 Relaiskarten (24V) sowie alle digitalen Ein- und Ausgänge
  • Loxone Miniserver Go mit Loxone Tree Extension
  • 2 DMX 12-Kanal LED Dimmer (3A pro Kanal)
  • 2-Kanal-DMX Dimmer 230V
  • 2 Meanwell 24V 26A Netzteile für LEDs und Bodenheizung
• OG: Reduit (Vorratsraum) mit:
  • Fritzbox
  • UniFi USG
  • UniFi 24-Port Switch
  • UniFi 8-Port Switch mit PoE
  • 48-Port Patch-Panel für alle Netzwerkanschlüsse im Haus
  • 12-Port Patch-Panel für Telefonie
  • UniFi AC AP PRO (Haupt-AP im Haus)
  • Hue Bridge (V1!)
• DG: Hager Kasten in der Hohlwand
  • Raspberry Pi für 2 Releaikarten (230V) und 1 Relaiskarte für Dachfenstersteuerung (3.3V)
  • 2-Kanal-DMX Dimmer 230V
  • 5 Fernsteuerungen für Velux-Fenster (gesteuert über insgesamt 15 Relais)

Loxone
Den Loxone Miniserver Go zusammen mit der Tree Extension verwende ich einzig für die "intelligenten" Lichtschalter. Im ganzen Haus sind 16 Loxone Touch Tree und 4 Loxone Touch Air (im EG) verbaut. Mit ihnen mache ich folgendes:

• Mittlere Haupttaste:
  • Kurzes Drücken (<1sec): Licht ein / Licht aus
  • Langes Drücken (>1sec): Licht-Szene wechseln jede Sekunde; hört auf, sobald der Taster losgelassen wird
• Linke/rechte Tasten:
  • Storen hoch/runter
• Temperatur- und Luftfeuchtigkeitssensor

Homematic
Hatte ich bereits vor dem Umbau im Einsatz (auch schon in einer Mietwohnung davor) und verwende ich dort, wo ich einfache Sensoren (und evtl. Aktoren) per Funk ansteuern muss (EG). Zudem habe ich neu gekauft:

• 5 Bewegungsmelder für verschiedene Zonen um das Haus herum und in der Garage
• 9 Rauchmelder

Relais
Im Haus sind insgesamt 176 Relais verbaut. Dafür verwende ich 16-Kanal Relais-Karten (5V) von AliExpress. Die Relais werden mit PCF8574(A) und MCP23017 I/O-Expandern über den I2C-Bus angesteuert. Im Nachhinein hätte ich besser 24V-Relais-Karten verwendet, denn das Schalten der Relais bringt (trotz Kondensatoren) manchmal die I/O-Expander zum Absturz (vor allem beim MCP23017 ein Problem).

Digitale Eingänge
Folgende Sachen werte ich als digitale Eingänge aus. Die Eingänge sind alle 5V high-active und haben aktuell keinen Pull-down Widerstand.

• Einfache mechanische Lichtschalter (respektiver Taster), wo keine Storen gesteuert werden müssen
• Fensterkontakte (Reed-Kontakte)
• Lichtschranke vor der Garage

Die mechanischen Taster als "Lichtschalter" verhalten sich übrigens exakt gleich wie die mittlere Taste bei den Loxone Touch (siehe oben).

Digitale Ausgänge
Aktuell verwende ich je zwei digitale Ausgänge für die drei Klingeln (eine pro Stockwerk): dies sind MP3-Module von AliExpress mit eingebautem Verstärker, an denen ein 3W-Lautsprecher hängt. Damit kann ich die Türklingel und das Klingeln des Telefons überall im Haus hören.

Licht
Ich verwende in zwei Räumen je drei 24V LED Panels (60x60cm, warm/kalt-weiss) von Hornbach (die Marke gibt es leider nicht mehr).
Vielerorts sind 24V LED-Streifen verlegt und im Flur/Treppe verwende ich einfache 24V Spots von Loxone (nicht Tree).
Dafür habe ich 2 24V Meanwell Netzteile (je 26A) sowie zwei 12-Kanal-DMX-Dimmer (max. 3A pro Kanal) von AliExpress.

Die restliche Beleuchtung mache ich mit gewöhnlichen 230V Deckendosen und entsprechenden Lampen (von IKEA, Hornbach, ...) und im Wohnzimmer mit Ständerlampen. Gewisse 230V Lampen habe ich mit Philips Hue ausgestattet (Farbe, dimmbar), gewisse Deckendosen sind an 230V DMX Dimmer angehängt (dimmbar).

Tablets / Visualisierung / App
In jedem Stockwerk gibt es einen Ort, wo ein Tablet an der Wand hängen kann (EG: bei der Eingangstüre, sonst jeweils am Ende der Treppe). Im Moment ist aber nur ein Tablet im OG im Einsatz (Xoro MegaPad 2154 V2). Auf dem Tablet läuft der Fully Browser im Kiosk Mode.

Die Visualisierung habe ich schlussendlich selber programmiert als Angular 9 Applikation. In den bestehenden Vis-Lösungen hat mir nicht gefallen, dass sie keine schöne Modularisierung ermöglichen. Beispiel: ich muss 17 Storen steuern, wenn ich nun an dieser Steuerung etwas anpassen will, dann will ich das an genau einem Ort machen können. Mit Angular Komponenten ist das sehr schön möglich. Auch Hierarchien sind möglich: eine Storensteuerung hat 3 Action Buttons, diese sind Buttons, und das sind Widgets.

Das GUI ist komplett responsive (verschiedene Bildschirmgrössen) und kann als PWA z.B. auf Android installiert werden (kommt automatisch im Vollbildmodus und immer Querformat).

Die Visualisierung kommt grundsätzlich ohne Text aus (nur in erweiterten Dialogen gibt es kurze Texte). Es gibt nur eine Navigationsebene - sprich: zu jeder Funktionalität komme ich über einen einzigen Klick.

Es gibt eine Ansicht pro Stockwerk sowie "Gesamtansichten" pro Kategorie (z.B. Fenster/Storen, Steckdosen, Licht, ...). Die meisten Sachen können entweder über die Stockwerksansicht und die Kategorieansicht gesteuert werden.

Bezeichnungen
Mit so vielen Geräten verliert man schnell den Überblick. Deshalb habe ich intern folgendes Namensschema verwendet:

SR-HZZ(X)
^^ ^^  ^
|| ||  + optionaler Index (A-Z), wenn am gleichen Ort mehrere Sachen sind
|| |+--- durchnummerierte Zahl, wenn auf der gleichen Höhe mehrere Orte existieren
|| +---- Höhe: in den meisten Fällen B=Bodennähe, W=Wand, D=Decke, F=Fenster
|+------ Raum
+------- Stockwerk

Die Deckenbeleuchtungsdose im Elternzimmer (OG) ist somit OE-D01.
Die vierte Strom-/Netzwerkdose im Zimmer im DG ist somit DZ-B04.
Der dritte Lichtschalter bei der Treppe im DG ist somit DT-W01C.

Reserve
Von allen Artikeln, die ich bei AliExpress gekauft habe, habe ich ein Stück als Reserve im Schrank (lange Lieferzeiten, grössere Ausfallwahrscheinlichkeit). Glücklicherweise funktioniert aber alles noch nach 3 Jahren. Einzig eine Relaiskarte musste ich gleich zu beginn auswechseln.

Hallo zusammen

Um die Adapter-Entwicklung einfacher zu machen und die Anzahl Abhängigkeiten auf meinem Entwicklungs-PCs zu verkleinern arbeite ich in einem ersten Adapter mit VS Code Devcontainer.

Damit läuft direkt auf meinem PC nur noch VisualStudio Code, der Rest ist in Docker. Ein Container (basierend auf ioBroker for Docker) stellt mir die gesamte Entwicklungs- und Testumgebung zur Verfügung. Ich muss mich nicht um NodeJS Versionen und Updates kümmern und muss nur den Container neu builden, wenn der JS Controller upgedatet wird.

Der Aufbau war etwas schwierig, aber inzwischen läuft es auf meinem Windows 10 Pro PC (mit Docker in WSL2) einwandfrei. Den relevanten Code findet ihr hier:
https://github.com/UncleSamSwiss/ioBroker.loxone/tree/master/.devcontainer

Falls jemand interessiert ist, helfe ich gerne weiter.

/UncleSam

@stefande Da gebe ich dir recht. Mir ist das auch aufgefallen. Ich glaube, wir hätten die Meldung etwas klarer formulieren können. Müssen wir uns für die Zukunft merken.

@Mic Danke für die zahlreichen Zitate

I18N (Internationalization) ist ein häufiges Problem und wir sind sicherlich nicht die ersten (und nicht die letzten), die sich dem annehmen müssen. Als Schweizer Softwareentwickler bin ich fast in jedem Projekt zweisprachig unterwegs (DE/FR); meist kommt noch Englisch dazu.

Die Problematik muss an zwei Stellen angegangen werden:

1. Die Software muss übersetzbar sein
2. Die Übersetzungen müssen einfach gepflegt werden können

Die Diskussion hier dreht sich vor allem um den ersten Punkt, mein Vorschlag für Weblate konzentriert sich auf den zweiten (nur damit wir hier nicht allzu wirr durcheinander reden).

Für 1. gibt es gute Frameworks und gute Beschreibungssprachen. Hier einige Beispiele: https://docs.weblate.org/en/latest/formats.html
Dabei ist wichtig, dass das Tool nicht nur einfache Texte übersetzen kann, sondern zum Beispiel auch mit Plural/Daten umgehen kann. ICU macht das sehr schön: http://userguide.icu-project.org/formatparse/messages :

"{num_guests, plural, offset:1 "
      "=0 {{host} does not give a party.}"
      "=1 {{host} invites {guest} to her party.}"
      "=2 {{host} invites {guest} and one other person to her party.}"
      "other {{host} invites {guest} and # other people to her party.}}}"

Ich denke wir müssen uns für beide Punkte auf etwas einigen und beides muss zusammen passen. Dabei würde ich versuchen, auf Standard-Tools zu setzen und nicht zu viel selber zu erfinden/entwickeln. Bis jetzt habe ich im Web-Bereich nur mit Angular I18N gearbeitet - und allein schon dort gibt es drei populäre Lösungen.

"Im Nachhinein Übersetzen" ist IMHO eine schlechte Strategie, sprich: Übersetzungen müssen von Anfang an in der Software vorgesehen sein. Irgendwie versuchen, Texte herauszusuchen und diese dann in eine Datei abzufüllen funktioniert sehr schlecht. Gerade auch Teilsätze (beim Einsetzen von Daten) können ein heilloses Durcheinander auslösen.

Automatische Übersetzungen sind ein guter erster Schritt, damit ioBroker internationaler wird, aber wer mag Software schlecht die Übersetzung sein or not all translated? Teilweise ist schon Deutsch schwierig, beim Englisch holpert es dann doch öfters in ioBroker.

Ich freue mich auf einen guten Austausch und bin gerne bereit in den nächsten Wochen Zeit in eine gute Lösung zu stecken.

@ldittmar Im Moment ist bei uns (Familie++) noch alles ruhig; falls ich im Meeting dabei bin, erzähle ich gerne etwas (mit Demo) über das Konzept zum neuen " Device Manager" (dm) Adapter: https://forum.iobroker.net/post/731274

In Discord/Telegram ist reges Interesse an Devcontainer vorhanden, deshalb versuche ich hier einige Sachen zu (er)klären.

Wie kann ich Devcontainer in meinem Adapter nützen?

Wenn's geht empfehlen wir immer den Adapter Creator (npx @iobroker/create-adapter) zu nutzen. Wenn das für euren Adapter nicht in Frage kommt, könnt ihr das .devcontainer Verzeichnis von meinem Adapter kopieren und überall den Namen "Loxone" durch euren Adapternamen ersetzen.

Zudem empfehle ich folgende zwei Dateien in VS Code zu ergänzen oder erstellen:

• launch.json: dies ermöglicht ganz einfach per F5 den Adapter zu starten (siehe unten)
• tasks.json: mit dem "Install Adapter" Task kann man ohne in die Kommandozeile abzutauchen den aktuellsten Stand als Adapter in ioBroker installieren

Was brauche ich für Devcontainer?

Microsoft beschreibt dies sehr schön in ihrem Getting Started.

Ich habe alles auf meinem Windows 10 Professional mit WSL2 (Windows Subsystem for Linux) getestet, dort läuft es einwandfrei.

Wie starte ich Devcontainer?

Wenn alle Vorbedingungen erfüllt sind (siehe oben) könnt ihr ganz einfach das Hauptverzeichnis (nicht das .devcontainer-Verzeichnis!) auf eurem PC in Visual Studio Code öffnen ("Ordner öffnen"), dabei fragt VS Code, ob man das Verzeichnis in Remote Container öffnen möchte:

Einfach auf "Reopen in Container" klicken und warten

Falls ihr dabei den folgenden Fehler seht (Messagebox und Konsole beachten!), habt ihr irgendwo noch eine Instanz von ioBroker (oder sonstwas) auf Port 8082* auf eurem PC am laufen:

Es ist zu beachten, dass nur ein "Devcontainer" mit ioBroker auf's mal laufen kann, da Port 8082* nicht nur im Container sondern auf eurem PC benutzt wird.

*= Der Port, auf welchem ioBroker zur Verfügung steht, kann in der Datei docker-compose.yml angepasst werden. Mehr Informationen sind in der Datei .devcontainer/README.md zu finden.

Wie greife ich nun auf ioBroker zu?

Im Devcontainer (docker-compose) läuft ioBroker sobald der Devcontainer gestartet ist. Wenn ihr an der Konfiguration nichts geändert habt, ist ioBroker unter http://localhost:8082 zu erreichen.

Wie entwickle ich im Devcontainer?

Das ist das schöne an Devcontainer: die Entwicklung funktioniert exakt wie bisher. Je nachdem müsst ihr noch VS Code Extensions im Container installieren, aber ansonsten merkt man vom Container gar nichts. In Tat und Wahrheit läuft aber der Grossteil von VS Code im Container und gar nicht mehr direkt auf eurem PC.
Extensions wie eslint und prettier funktionieren weiterhin einwandfrei; je nach Extension läuft sie auf dem PC oder im Container.

Wie starte ich meinen Adapter das erste mal?

Der Adapter wird automatisch beim ersten mal Starten von Devcontainer installiert. Es muss einzig noch eine Instanz erstellt werden (vorzugsweise mit Index=0).
Mit dem oben erwähnten Task (Ctrl-Shift-P -> Tasks: Run Task -> "Install Adapter") wird der aktuelle Stand des Source Codes in ein NPM Paket verpackt und in ioBroker (im Container) installiert. Danach kann man den Adapter ganz einfach im Web GUI konfigurieren. Zum starten empfehle ich gleich das Debugging (siehe unten) zu nutzen, es ist aber natürlich auch möglich, den Adapter ganz normal in ioBroker zu starten.

Wie debugge ich im Devcontainer?

Ich nutze dafür die oben bereits erwähnte Launch Konfiguration. Damit kann ich per F5 (oder über den Debug-Tab) den Adapter im Debug-Modus starten. Der Adapter sollte natürlich nicht laufen bevor man F5 drückt.

Was mache ich, wenn nichts mehr geht?

Wenn doch mal ein Devcontainer irgendwo hängt, kann man das über das Docker-Dashboard nachvollziehen. Einfach rechts-Klick auf das Docker Symbol unten rechts in der Taskleiste von Windows und dann "Dashboard" auswählen:

@pskiel Ich haue gleich mal in dieselbe Kerbe wie @ilovegym :

Wenn du dich so wenig auskennst mit Port-Freigaben, dann mach es bitte nicht! Ich will damit nicht sagen, dass du dumm bist, aber es braucht sehr gute IT- und Netzwerkkentnisse um einen Zugang einzurichten, der sicher ist. Das was du machst ist quasi eine Einladung für Hacker.

Verwende das VPN der Fritzbox oder ioBroker.cloud, damit hast du ohne grossen Aufwand eine sichere Verbindung. Wenn's etwas komplizierter sein darf, kann ich auch Google OAuth empfehlen: ich glaube, mein System ist damit sicher - aber da muss man schon etwas tiefer rein.

Wenn ich bei Shodan (einer Live-Datenbank aller offenen Systemen im Internet) "ioBroker" eingebe, erhalte ich 130 potenziell gefährdete Systeme: https://www.shodan.io/search?query=iobroker

Wenn ich mal das zweite Resultat bei Shodan nehme, dann kann ich (ohne weiteres) auf folgende Seite zugreifen:
http://79.⬛.⬛.⬛:8082/vis/edit.html#Heizung (geschwärzt um doch nicht gerade das System bloss zu stellen).
Na super, damit habe ich quasi vollen Zugriff auf diese ioBroker Installation:

Wäre schön, wenn deins nicht noch dazu kommen würde!

Bin gerne auch dabei mit:

• Google Nest Hub Max (Border Router)
• Nanoleaf Glühbirnen
• Eve Energy Steckdose (CH Version )

Möchte alles steuern (und Stromverbrauch messen) aus dem ioBroker heraus.

Edit: ich bin zwar nur mit Google Home unterwegs bis jetzt, aber als treuer Samsung-Kunde könnte ich je nachdem auch Smart Things testen. Hub habe ich aber nicht von Samsung, nur Handys, Tablet (und einen alten Fernseher )

Wenn am Schluss noch Zeit bleibt, kann ich kurz die Ideen hinter meinem Projekt ioBroker in Kubernetes vorstellen.

In den nächsten Monaten werde ich versuchen, wieder etwas in die ioBroker-Entwicklung einzusteigen; deshalb würde ich gerne als Diskussionspunkt die DX (Developer Experience) einbringen.
Fragen: was braucht ihr, was habt ihr, was sollte noch dazu kommen?
In meiner letzten aktiven Zeit bei ioBroker habe ich:

• das Developer Portal hochgezogen
• mit @AlCalzone den Adapter Creator weiter entwickelt
• mit @AlCalzone adapter-dev gestartet
• Weblate eingeführt

Was davon macht heute keinen Sinn mehr, was müsste weiter entwickelt werden und wo haben wir noch Lücken?

Ich glaube, es gibt einige Punkte, wo wir die DX noch verbessern könnten (danke übrigens an @mcm1957 für seine Arbeit in diesem Bereich in den letzten Monaten!) und die würde ich gerne von euch hören. In meinem "anderen Leben" bin ich Entwickler und "Berater" in diesem Bereich und habe in den letzten drei Jahren sehr viel gelernt (GitHub Automatisierung, vollständig automatische DevOps-Pipelines, ...) und von dem würde ich ioBroker gerne profitieren lassen.

Wie immer: bitte nicht hier diskutieren, sondern im Meeting. Wer keine Zeit hat ans Meeting zu kommen, gerne PN mit Vorschlägen / Kritik an mich.

Ja, prettier ist ein geniales Werkzeug. Das darf bei mir in keinem Projekt fehlen, egal ob privat oder beruflich.

Der Creator erstellt (wenn gewünscht) übrigens die nötige Konfiguration:
Beispiel: https://github.com/ioBroker/create-adapter/blob/master/test/baselines/TS_Prettier/.prettierrc.js

Es könnte sich also für den einen oder anderen lohnen, den eigenen Adapter mal auf Creator umzustellen und so die aktuellsten Tools zu verwenden. Eine Hilfe dabei kann die Option --migrate des Creators sein.

Da ich Visual Studio Code verwende, ist dort bei mir immer die Extension esbenp.prettier-vscode installiert (und natürlich auch dbaeumer.vscode-eslint, da ich ja auch einen guten Linter haben will).

@arteck Was, es gibt immer noch Leute die Leerschläge oder Tabs von Hand einfügen ?!

Wenn alles klappt, würde ich gerne @iobroker/adapter-dev vorstellen. Es soll gulp, parcel und tsc ersetzen.

@tbsjah (und alle anderen), ich habe soeben die neuste luxtronik2 Library eingebunden.

Version 0.4.2 sollte somit deine / eure Fehler beheben.

Lasst mich bitte in den Kommentaren wissen, ob alles so tut, wie es sollte.

@ldittmar Im Moment ist bei uns (Familie++) noch alles ruhig; falls ich im Meeting dabei bin, erzähle ich gerne etwas (mit Demo) über das Konzept zum neuen " Device Manager" (dm) Adapter: https://forum.iobroker.net/post/731274

@foxthefox sagte in Core-Entwicklung zu schnell?:

Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.

Du kannst dir ja mal das aktuelle rohe Gerüst anschauen und uns gerne Issues erfassen, wenn dir das etwas fehlt.

Genau eine solche Doku wie du sie wünschst scheint mir absolut wichtig und zentral. Aber es ist auch wichtig, dass wir Feedback wie deines (auf dem richtigen Weg) erhalten und als Basis für die Aktualisierung verwenden.

Hallo zusammen

Ich habe hauptsächlich auf Grund der Spezifikation von @apollon77 einen Adapter erstellt, der die Basis für weitere Diskussionen sein soll:

https://github.com/UncleSamSwiss/ioBroker.dm

Ich freue mich auf euer Feedback, bitte behaltet aber im Kopf, dass es sich hier um einen Prototypen und um die ersten Schritte der kompliziertesten Lösung handelt, die wir machen können. Das soll heissen: wir werden für einfache Use Cases sicherlich noch einiges vereinfachen können, aber ich wollte mal komplexe Use Cases wie den zwave2 von @AlCalzone abbilden können.

Zudem ist noch bei weitem nicht alles implementiert und das GUI hat noch seeeehr viel Verbesserungspotential (wie immer: PRs are welcome ).

Wer einfach mal schnell testen will, wie das ganze funkioniert:

• https://github.com/UncleSamSwiss/ioBroker.dm in einem Test-ioBroker installieren
• https://github.com/UncleSamSwiss/ioBroker.dm-test auf demselben ioBroker installieren und eine Instanz erstellen

Wenn ihr selber einen Adapter anpassen wollt, dann schaut in die Dokumentation der Hilfs-Library:
https://github.com/UncleSamSwiss/dm-utils

So, und jetzt bin ich auf euer kritisches Feedback gespannt (Schulterklopfen brauche ich nicht, das kann ich auch selber machen ).

/UncleSam

@tbsjah Sorry, da hatte ich etwas vergessen (und ich kann es nicht testen, da ich im Urlaub bin).

Version 0.4.1 behebt diese Warnmeldungen und stellt die drei neuen Werte korrekt dar (sie sind aber nicht bearbeitbar).