Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30

[Ro75]

Ich bin zwar kein ioBroker - Entwickler, hatte aber selber 20 Jahre Windows-Software entwickelt. Aus meiner Sicht gibt es folgende Schwachstellen.

1. In den Adaptern gibt es
   a) zuviel "denglisch"
   b) zuviel "fach-chinesisch" und
   c) nicht selbsterklärende Begriffe/Formulierungen

2. Fehler. In den letzten 18 Monaten kommen zuviele Aktualisierungen mit Fehlern raus. Für mich wirkt das dann immer wie mit "heißer Nadel gestrickt".

3. Gemeldete Fehler / Probleme werden nicht behoben - zumindest fühlt es sich so an. Und wenn dann Adapter viele Monate liefen und dann nicht mehr ist das schade und frustrierend >> siehe Parcel-Adapter - da tut sich nix

4. Viel "lastest", kaum neue echte "stable" Versionen.

Nur ein paar Anmerkungen als Nutzer.

Ro75.

[Homoran]

@ro75 #2 und #4 bedingen sich gegenseitig.
Damit in stable nur stabiles auftaucht braucht es ausreichend (fehlendes) feedback im Beta test.
(latest ist da die falsche Bezeichnung! wurde deswegen auf beta geändert)

[simatec]

Bitte führt hier keine Diskussion darüber... Es ist lediglich in Punkt, den ich fürs Meeting vorgeschlagen habe.
Für eine Diskussion ist der Thread hier nicht gedacht...

[Ro75]

@homoran sagte in Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30:

braucht es ausreichend (fehlendes) feedback

Noch ein Punkt. Es wird immer wieder auf GIT "gelenkt". Ehrlich gesagt, habe ich schon gar keine Lust mehr was auf GIT zu melden. Probleme / Fehler oder "Unlogiken" (wie z.B. Admin Adaper + Skripte mit den Farbeinstellungen). Da werden die Hinweise "abgetan", "niedergebügelt". Manchmal kommt es mir so vor, als ob sich das nicht wirklich richtig durchgelesen wird und im Anschluss gibts noch eine Antwort die aller Logik widerspricht.

Ro75.

EDIT: Letzter Eintrag von mir - wollte nur eine (aber große) USER-Sicht aufzeigen.

[Homoran]

@simatec sagte in Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30:

Für eine Diskussion ist der Thread hier nicht gedacht...

sollte auch keine Diskussion sein, sondern Ergänzungen

[apollon77]

Ok, wie bereits gesagt sollten wir nicht hier im thread diskutieren sondern im Meeting. Das Problem was ich mit einigem hier geschriebenen persönlich habe ist, das es entweder hinlänglich bekannt und immer noch ungelöst ist (zb eine dedizierte ux resource oder mehr ui devs um sowas anzugehen und und und) oder es erstmal (teils sehr) plakative/(für mich) nicht bewertbare aussagen sind wo ich fragen hätte um das genaue Problem zu verstehen und einordnen zu können. Gefühlt sind auch da wieder verschiedene Themen vermittelt drin.

Wir vom Core Team haben einen groben Plan für ein paar der Themen und arbeiten aktiv daran. Das ist nur alles nichts was schnell fertig ist sondern Zeit braucht.

Das systemupdate Thema ist auch in js-controller 6.0.10 geändert. Ist halt noch in latest. Andererseits gab es auch positives Feedback über einige eher überraschte User die jetzt mal wieder Updates machen und dankbar sind negatives Feedback ist erfahrungsgemäß nur halt lauter

Ich lade wir immer gern alle ein beim dev Meeting dabei zu sein um hier mal zu reden. Auch in Solingen ein paar Tage danach kann man sich gern weiter austauschen.

Danke, Ingo

[wcag22]

@ldittmar

Ich schrieb:

Ich weiß nicht, ob ich am Meeting dabei sein kann, daher lediglich einige Fragen, die vlt. beantwortet werden könnten:
... (die hier richtigerweise nicht diskutiert werden sollen),

Edit: Text wegen angeblicher Diskussion gelöscht

[mcm1957]

@wcag22
STOP
wie schon von anderen geschrieben hier bitte KEINE Diskussionen zu einem Thema. Wenn da ein Bedarf besteht dann bitte in einem GETRENNTEN Topic.

HIER sind nur Themen und allfällige Ergänzungen zu Themen (zusätzliche Detailtopics) sinnvoll.

[Gaspode]

Ich würde gerne nochmal auf das Thema Doku eingehen, speziell auf die deutsche Adapter Doku hier:

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

Kann man da die deutsche Übersetzung (s)eines Adapters anpassen?
Wenn ja, wie geht das und wo legt man das Ergebnis ab.

Edit:
Ich lass das mal hier stehen, weil es evtl. andere interessiert, die da auch nicht so tief in der Materie drin sind.
Die Frage selbst wurde mir von @Garfonso bereits auf Discord/Telegram beantwortet, Danke dafür:

Wenn du das selber pflegen willst, kannst du bei dir mehrere readmes oder auch einen docs Ordner machen. Im io-package.json kannst du angegeben, was als readme/Dokumentation genommen wird:
https://iobroker.readthedocs.io/de/latest/development/iopackage.html#confval-common.docs

[foxriver76]

• Aktueller Stand & Aussicht zu Matter (+ Matter Adapter und drum herum) werden @apollon77 und ich sicher etwas zu sagen können
• Controller 6.1 Infos & verkürzter Release Zyklus für diese Version
• Möglichkeit der Nutzung der neuen zentralen eslint-config in Adaptern und Tooling rund um ioBroker

[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.

[J_Paul]

Ich hatte auf Github 2 state.roles angefragt, eigentlich fällt mir noch mindestens noch ein weiterer ein:
Link zu dem Github Issue
Edit: Erledigt, Issue is closed
Edit2: Auf Wunsch ist das Issue wieder auf

[Bluefox]

Ich habe folgende Themen:

• Ping monitor
• Gui in notifications
• eslint-config (Moritz?)
• Json-Config - State control
• Object Browser - Back Alias link (very small feature)

[mcm1957]

Dev Thema:

Der AdapterCreator ist derzeit offen gesagt eher unbrauchbar / funktioniert nicht da dependencies (chai ?) da offenbar klemmen. Siehe Diskussionen in Telegramm und https://github.com/ioBroker/create-adapter/issues/1106

Mit manuellem Patchen der Deps kommt man angeblich kleinweise weiter - aber wirklich funktionieren tut's nicht ..

Und der dev-server scheint bei Neueinrichtung auch Probleme zu haben... Keine Ahnung ob Folgeproblem oder was getrenntes.

Kann sich das wer ansehen?
Wie gehen "wir" da weiter vor?

EDIT: Es gibt ne neue Release. DANKE Ev. hat sich der Punkt erübrigt - bin noch nicht zum Testen gekommen.

EDIT: Testergebnis:
Abbruch wenn dev-server mit selektiert ist - sonst sieht es soweit gut aus.

Garfonso created this issue in ioBroker/create-adapter

closed Need to also pin sinon-chai #1106

[mcm1957]

Noch ne (wahrscheinlich) Kleinigkeit:

@iobroker/testing wurde auf Version 5.0.0 gehoben. Aus dem Changelog geht (für mich) nicht klar hervor ob hier ein Breaking CHange drinnen steckt oder nicht bzw. ob Adapter jederzeit aktualisisert werden können oder ein Update brauchen.

Da das Testing eine zentrale Komponente ist, sollten wir das (wenn bis zum Meeting keine Klarstellung im Changelog steht) das kurz ansprechen.

Hat sich erledigt, BF hat Info in Telegramm veröffentlicht.

[apollon77]

Seit neuestem ist wohl auch die neue Homematic HCU draussen ... https://homematic-ip.com/de/produkt/home-control-unit ... Hat jemand Lust und zeit sich das anzusehen ob das was eigenes braucht oder nah genug an hmip ist? Und ggf zu integrieren?

[mcm1957]

Kurzinfo (genügt auch wenn du das nur vorliest, von mir aus kein Diskussions-/Vorstellungsbedarf)

Neue role:
sensor.contact - general contact, closed -true or open - `false

EDIT:
Scheint doch Diskussionsedarf zu geben. Bitte einplanen.
Siehe Nachfiolegpostings

[Bluefox]

@mcm1957 sagte in Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30:

sensor.contact - general contact, closed -true or open - false

Ich habe die Werte geändert: closed ist false und opened ist true
Sonst es ist alles auseinander:

* `sensor.contact`        - general contact: open - `true` or closed -`false`
* `sensor.window`         - window opened-`true` or closed-`false`
* `sensor.door`           - door opened-`true` or closed-`false`

sonst es ist ein Horror das zu visualisieren

[mcm1957]

@bluefox
Der Wunsch für diesen State war so wie ich es eingetragen habe. Die Werte wurden bewußt so gewählt:

CLOSED = TRUE und OPEN = FALSE.

Das entspricht dem Verhalten eines normalen Schalters - Kontakt geschlossen ? J/N Und genau für solche Fälle sollte die Role zum Einsatz kommen. Kontakt geschlossen = false ist unlogisch auch in meinen Augen.

Türen und Fenster sind eine andere Baustelle.

Alternativ open / close NICHT festlegen und es der Adapterdoku überlassen wann welche Werte gesetzt werden.

Oder sensor.contact.no und sensor.contact.nc (normally open, normally closed) definieren wenn wir beide logischen Mögloichkeiten unterstützen wollen.

Bitte wieder zurück ändern oder im Meeting besprechen.

[J_Paul]

Die Idee der Rolle "sensor.contact" stammt von mir, deswegen:
Am Beispiel des Zigbee Adapters, da sind mMn die Tür/Fenstersensoren vielfach im Einsatz

Stand jetzt:
Es gibt sowohl den state "opened" und state "closed"
Opened ist klar von der Logik: Steht ein Fenster/Tür offen ist der Wert true
Closed ist ebenso klar: Der Wert ist genau gegensätzlich, wenn Fenster/Tür offen ist "Closed" false

Beide habe die Rolle "state" weil es unmöglich ist zu wissen wo die nun verbaut wurden, also der State "opened" kann weder "sensor.window" noch "sensor.door" als Rolle bekommen, gerade, weil die auch im Briefkasten, oder Katzenklappe hängen können.
Deswegen die Idee mit "sensor.contact"
Diese Rolle könnte dem State "Closed" automatisch zugeordnet werden, wenn "Closed" true ist, wenn Kontakt geschlossen.
Bevor aber bei offenem Kontakt die Rolle "sensor.contakt" true ist, während der Wert vom State "Closed" = false ist, dann wäre es wohl besser "sensor.contact" gar nicht erst hinzuzufügen, weil es unlogisch wäre.

Alternativ open / close NICHT festlegen und es der Adapterdoku überlassen wann welche Werte gesetzt werden.