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:
dev-server run ausführen
HTML Datei in deinem lokalen Entwicklungsverzeichnis ändern und speichern
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:
dev-server watch ausführen
JavaScript (oder TypeScript) Adapter Code ändern und speichern
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:
dev-server debug ausführen
Wenn du willst, kannst du nun deinen Debugger attachen
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:
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.
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
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
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
flot: Grafiken in meine Angular Vis (z.B. Temperatur- und Luftfeuchtigkeitsverlauf)
fritzbox: Router
fullcalendar: Temperaturanpassungen durch den Tag und Ladesteckdosen für El. Zahnbürste und Rasierapparat
fullybrowser: Fully läuft auf dem Tablet
habpanel: Alte Vis
hm-rpc: Homematic
hue: Drei Hue Birnen im Einsatz
i2c: (4x) Alle I2C I/O-Expander
icons-mfd-svg: geniale Icons, verwende ich auch in meiner Angular Vis
info: ist klar
javascript: Alle Skripts für Steuerung von Licht, Heizung und vieles mehr
linkeddevices: Wird bald durch Alias ersetzt
loxone: Loxone Touch Taster via Miniserver Go
luxtronik2: Wärmepumpe
modbus: Wechselrichter
nut: Abfrage USV via QNAP NAS
ping: Überwachung Erreichbarkeit von Access Points
rpi2: (4x) GPIOs am Raspberry Pi verwenden (aktuell nicht benutzt)
smartmeter: Landis & Gyr Stromzähler mit D0-Schnittstelle
sql: History Daten
squeezebox: Immer noch das beste Multi-Room System
swiss-weather-api: Wettervorhersage für meinen Wohnort
telegram: Benachrichtigungen für Ereignisse (aktuell: Klingel)
udmx: USB DMX Adapter
unifi: Überwachung Netzwerkkomponenten
web: Für Vis
worx: Landroid Rasenmähroboter
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.
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.
@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.
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:
Die Software muss übersetzbar sein
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).
"{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
OAuth2 Service für Adapter
Immer wieder brauchen Adapter OAuth2 und häufig müssen die Endbenutzer einen Entwickler-Account oder ähnliches beim entsprechenden Service erstellen und dort eine Redirect-Adresse eintragen.
Es wäre schön, wenn es einen "Mittelmann" gibt für ioBroker, der diese Authentifizierung insbesondere mit gültiger Redirect-Adresse anbietet. Das wäre eine "Website", die dann den User mit entsprechendem Token zurück an seine ioBroker-Admin-Instanz redirected. Technisch gesehen ist das ein OAuth2 "chaining".
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 .devcontainerVerzeichnis 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:
Regionale Adapter: Gemäss unserer Diskussion vom Sonntag:
Wäre es möglich, in ioBroker länderspezifische Adapter zu filtern oder hervor zu heben? Ich nehme an, im Moment gibt es sowas nicht, aber für uns Schweizer (und sicher auch für Österreicher) wäre das noch praktisch, wenn wir Adapter für rein lokale Dienste hervorgehoben bekämen.
Das könnte man weiter denken und "Regionen" allgemeiner definieren: zB könnte es ja sein, dass eine Smart City wie Solingen einen Adapter im entsprechenden Kreis anbietet.
Das könnte ja eventuell auch in Discovery eingebaut sein - oder könnte man das schon heute dort umsetzen?
OAuth2 Service für Adapter
Immer wieder brauchen Adapter OAuth2 und häufig müssen die Endbenutzer einen Entwickler-Account oder ähnliches beim entsprechenden Service erstellen und dort eine Redirect-Adresse eintragen.
Es wäre schön, wenn es einen "Mittelmann" gibt für ioBroker, der diese Authentifizierung insbesondere mit gültiger Redirect-Adresse anbietet. Das wäre eine "Website", die dann den User mit entsprechendem Token zurück an seine ioBroker-Admin-Instanz redirected. Technisch gesehen ist das ein OAuth2 "chaining".
Integration von externen "Geräte-Libraries" via "Virtuelle Adapter"
Seit einiger Zeit bietet Loxone die "Loxone Library" an. Dort finden sich zahlreiche Geräte-Integrationen (aktuell wahrscheinlich mehr als 600) als frei herunterladbare Konfigurationen (ZIP mit JSON und XML drin). Ein Grossteil sind Modbus-Geräte (>370), aber auch zahlreiche IP-basierte Geräte (>150).
Für unsere User wäre es genial, all diese Geräte einfach so als Adapter nutzen zu können.
Ich nehme an, es gibt auch andere solche Libraries oder Systeme (wie zB ioBroker.ham), die man mit mehr oder weniger Aufwand einbinden könnte.
Es gibt verschiedene Ansätze, wie wir dies machen könnten; darüber würde ich gerne diskutieren.
Können wir bitte dieses Mal versuchen, uns wieder an die zwei Stunden zu halten? Letztes Mal ist es IMHO etwas aus dem Ruder gelaufen. Wenn es Themen gibt, die unbedingt im Februar-Meeting besprochen werden müssen, können wir die sicher auch in der Agenda nach vorne schieben, damit sie auf jeden Fall behandelt werden.
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 )
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
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.
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 ?!
) zu vereinfachen. Gewisse Diskussionen auf Telegram (z.B. mit 
?!