UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[apollon77]

Und mit AlCalzone hatten wir eine DIksussion zu "welche Versionen am besten in io-package lassen" um das idealerweise im release script zu automatisieren

[Dutchman]

Bitte wünsch Termin eintragen : https://doodle.com/poll/u4wassupgmdzznwe

[carsten04]

Themenvorschlag: einheitlicher Dokustandard für Adapter. Idee: Nutzung von VuePress. Vorteile: einfaches Handling und Integration in z.B. GitHub Pages. Habe ich bei meinem milight-smart-light Adapter umgesetzt, könnte z.B. so aussehen: Doku milight-smart-light Adapter.

[Homoran]

@carsten04 sagte in Online Meeting für ioBroker Core/Dev/Admin September Edition:

Themenvorschlag: einheitlicher Dokustandard für Adapter. Idee: Nutzung von VuePress. Vorteile: einfaches Handling und Integration in z.B. GitHub Pages. Habe ich bei meinem milight-smart-light Adapter umgesetzt, könnte z.B. so aussehen: Doku milight-smart-light Adapter.

gefällt mir optisch gut, wie ist es mit der Pflege und der Versions- Verlauf"kontrolle"?
Ist die Einbindung in die Adapterseite im Admin möglich?

[Jey Cee]

@carsten04 aus meiner sicht gibt es da nichts zu Diskutieren, den es gibt schon lange einen Standard -> https://www.iobroker.net/#de/documentation/dev/adapterdocstyleguide.md

[carsten04]

@Homoran Das ganze ist ja im GitHub verortet (wie ein normales Adapter-Projekt), d.h. alle Versionskontrollmechanismen können genutzt werden. Im Admin (index_m.html) fügst Du dann einfach z.B. den folgenden Link ein:

<a target="_blank" href="https://steiger04.github.io/milight-smart-light-doku/">
                    <i class="small material-icons">import_contacts</i>
                    <div style="font-size: x-small">Doku</div>
                </a>
``

[Homoran]

@carsten04 klingt gut, jetzt muss ich mich damit mal näher befassen, ob das außer für die Adapterdoku auch für den Rest brauchbar ist

[carsten04]

@Homoran Man kann mit VuePress fast beliebig skalieren. Ein gutes Beispiel dafür ist die openHAB-Doku, die komplett mit VuePress erstellt wurde.

[Homoran]

@carsten04
Das muss dann @Bluefox entscheiden.
Es wäre dann die dritte Doku-Software. Erst Wordpress, das ließ sich (für mich) relativ leicht bedienen, dann natives MD über github, womit ich so meine Probleme habe. VuePress scheint da wieder für nicht-Devs in kryptischen Befehlen zu "progammieren" sein.
Oder habe ich das im schnellen Überfliegen falsch interpretiert
https://vuepress.vuejs.org/guide/

[carsten04]

@Jey-Cee Der Style-Guide ist ja auch schon super und verweist auf Markdown. Das ist auch die
Basis für VuePress, aber Du bekommst halt noch einen Static-Site-Generator dazu und hast damit eine out of the box Website, die supereinfach wartbar ist und komplett getrennt vom restlichen Adapter-Code gehandelt werden kann. Ich finde schon das es wert ist, darüber einmal nachzudenken und zu diskutieren.

[FredF]

@carsten04 @Homoran
Da ich auch bei so zwei, drei (oder mehr?) Adaptern bei der Doku geholfen habe, möchte ich auch mal meinen Senf dazugeben und für die Einführung von VuPress voten. Habe das zwar noch nie benutzt aber alleine die Möglichkeit einer Navigation spricht dafür.

[Dutchman]

@carsten04 sagte in Online Meeting für ioBroker Core/Dev/Admin September Edition:

Themenvorschlag: einheitlicher Dokustandard für Adapter. Idee: Nutzung von VuePress.

@FredF sagte in Online Meeting für ioBroker Core/Dev/Admin September Edition:

für die Einführung von VuPress voten.

Habe das Thema auf die liste aufgenommen, @carsten04 es wuerde helfen wen du uns während des meetings etwas dazu zeigen könntest wie es aussieht usw.
Vorschlag : TimeBox 15 min

Cheers,

Dutch

[carsten04]

@Homoran Schau Dir mal folgendes an: Doku für milight-smart-light
VuePress erzeugt für Dich wirklich sehr einfach eine statische Seite aus Markdown-Dokumenten. Du mußt also nur Markdown beherrschen, den Rest übernimmt VuePress für Dich. Den Source Markdown findest Du z.B. in den subfoldern /admin, /app, /introduction, /iot, /versionen für mein Projekt. Der Ordner /docs wird dann für Dich von VuePress erzeugt und enthält die statische Seite. Wir könnten halt über VuePress ein einheitliches Layout und auch Struktur für die Adapter vorgeben und der Entwickler muss dann nur noch das Markdown schreiben und anschließend alles auf GitHub Pages publizieren.

[Dutchman]

@carsten04 sagte in Online Meeting für ioBroker Core/Dev/Admin September Edition:

Wir könnten halt über VuePress ein einheitliches Layout und auch Struktur für die Adapter vorgeben und der Entwickler muss dann nur noch das Markdown schreiben und anschließend alles auf GitHub Pages publizieren.

So etwas suche ich schon lange, auch damit wir central miteinander unsere doch inhaltlich vorm geben können.
Momentan liegt alles in md files auf git und wird unsere docu Seite daraus übersetzt und integriert

https://www.iobroker.net/#de/documentation

Vorschlag : Alles weitere dazu bitte in einem separaten topic, dieser hier ist gedacht fürs meeting

Danke !

[Jey Cee]

Themenvorschlag: 2FA (Zwei-Faktor-Authentifizierung) kommt ja bei immer mehr Diensten oder als Service dritter. Bis jetzt kommt man oft noch ohne aus, wenn man es aber benutzen möchte funktioniert das nicht immer oder einfach.
Deswegen sollten wir frühzeitig in diese Richtung Planen und nach Möglichkeit die Funktionen im js-controller oder über den Adapter-core zur Verfügung stellen. So das nicht wieder jeder Entwickler alles von vorne Entwickeln muss.
Das ist ähnlich dem Thema Passwörter in Adaptern und wie geht man damit um, das kam dann erst sehr spät.

[AlCalzone]

Ich würde noch docsify in den Raum werfen, kann hier auf Github Pages im Einsatz gesehen werden: https://alcalzone.github.io/node-zwave-js/#/
Ist aber auch in @Homoran s Worten Markdown über github. Wahrscheinlich gibt sich das eh alles nicht viel.

@apollon77 sagte in Online Meeting für ioBroker Core/Dev/Admin September Edition:

Und mit AlCalzone hatten wir eine DIksussion zu "welche Versionen am besten in io-package lassen" um das idealerweise im release script zu automatisieren

Genauer: Wie entscheiden wir was drin bleibt und was nicht? Bluefox will ja die Anzahl (5-7) reduzieren, um das Repo klein zu halten, jetzt könnte es aber sein, dass die letzten 5 Patch-Versionen alle buggy sind und man die eigentlich nicht zum Installieren im Admin anbieten will.

[Dutchman]

@Jey-Cee sagte in Online Meeting für ioBroker Core/Dev/Admin September Edition:

Themenvorschlag: 2FA (Zwei-Faktor-Authentifizierung)

hinzugefügt

@AlCalzone sagte in Online Meeting für ioBroker Core/Dev/Admin September Edition:

Ich würde noch docsify in den Raum werfen, kann hier auf Github Pages im Einsatz gesehen werden: https://alcalzone.github.io/node-zwave-js/#/
Ist aber auch in @Homoran s Worten Markdown über github. Wahrscheinlich gibt sich das eh alles nicht viel.

hinzugefügt

[Dutchman]

• demonstration Discord LiveChat community (Dutchman/JeyCee) 10 min

[apollon77]

@carsten04 Naja wenn müsste man das mit React und so machen das die aktuellen Mechanismen die jetzt schon die Adapter DOku in die Webseite ziehen damit auch tun ... also vue vllt die falsche basis

[carsten04]

@apollon77 Ich glaube gar nicht das das primär ein Vue-Thema ist. Ich bin eigentlich drauf gekommen, weil ich hier immer wieder Fragen zu meinem Adapter gestellt bekommen habe und dann überlegt habe wie kann ich das am Besten dokumentieren. Die jetzigen Adapter-Dokus sind immer ein großes "flaches" MD-File. Das ist gut für kleinere Dokus, wird aber schnell unübersichtlich, wenn es um eine etwas ausführlichere Doku gehen soll. Da fehlen einfach Strukturierungsmöglichkeiten (Sidebar, Menüs, Links etc.). Das alles liefert Vuepress, docsify und auch Andere. Es muß ja kein entweder oder sein. Eine Überlegung wäre z.B. einen zusätzlichen Link auf die GitHub Page in die vorhandene Doku zu setzen, für die Adapter die eben dann eine ausführlichere Doku benötigen und wo der Entwickler gerne aktiv werden möchte. Über Vuepress oder vergleichbar könnten wir dann ein Layout und eine initiale Struktur vorgeben, die immer genutzt werden sollte und bedarfsgerecht erweitert werden kann. Dies würde auch für den Anwender der Adapter einen Wiedererkennungseffekt haben. Die Umsetzung könnte dann z.B. in einem Doku-Template mit Erklärungen erfolgen, dass bei Bedarf vom Entwickler genutzt werden kann. Wenn wir dann noch für das Dokuprojekt eine Namenskonvention für GitHub festlegen, könnte mit geringem Aufwand auch die Verlinkung in der aktuellen Doku automatisiert erfolgen.