Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30
-
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
-
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
-
@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.
-
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 -
- 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
-
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.
-
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 -
Ich habe folgende Themen:
- Ping monitor
- Gui in notifications
- eslint-config (Moritz?)
- Json-Config - State control
- Object Browser - Back Alias link (very small feature)
-
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. -
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.D
a 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.
-
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?
-
Kurzinfo (genügt auch wenn du das nur vorliest, von mir aus kein Diskussions-/Vorstellungsbedarf)
Neue role:
sensor.contact- general contact, closed -trueor open - `falseEDIT:
Scheint doch Diskussionsedarf zu geben. Bitte einplanen.
Siehe Nachfiolegpostings -
@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
-
@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.
-
Die Idee der Rolle "sensor.contact" stammt von mir, deswegen:
Am Beispiel des Zigbee Adapters, da sind mMn die Tür/Fenstersensoren vielfach im EinsatzStand 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" falseBeide 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.
-
zum thema gerade im dev meeting
responsive design mit json config.ich habe gerade mal meine adapter geprüft und ein bisschen rumprobiert.
aktuell sehe ich für mich 2 issues zu denen ich keine Lösung gefunden habeUmbruch in Tabellen, wenn der Bildschirm nicht breit genug ist.
Aktuell wird muss links/rechts gescrollt werden um alle felder zu erreichentabs
kein umbruch bzw schrift wird soweit verkleinert, dann wird aber der text unleserlich
am beispiel iobroker config (weiß nicht ob das json config ist oder react nativ)
können die rechten tabs nicht mehr erreicht werden bei handy format hochkant -
Bezüglich der roles:
Es wurde darüber diskutiert, dass roles hauptsächlich für ui dinge da sind.
Bitte beachten, dass mit dem Selector im Javascript Adapter auch die rollen genutzt werden können und somit diese auch zu Bedingungen für Logiken werden können.
-
@oliverio said in Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30:
zum thema gerade im dev meeting
responsive design mit json config.ich habe gerade mal meine adapter geprüft und ein bisschen rumprobiert.
aktuell sehe ich für mich 2 issues zu denen ich keine Lösung gefunden habeUmbruch in Tabellen, wenn der Bildschirm nicht breit genug ist.
Aktuell wird muss links/rechts gescrollt werden um alle felder zu erreichentabs
kein umbruch bzw schrift wird soweit verkleinert, dann wird aber der text unleserlich
am beispiel iobroker config (weiß nicht ob das json config ist oder react nativ)
können die rechten tabs nicht mehr erreicht werden bei handy format hochkantZu 1) hab ich ein Issue erstellt da wird (ich) das gestern eh auch angesprochen habe. Ev. kann @simatec da noch Isseen für eine Umsetzung anmerken. Bin in UI Sachen absolut nicht fit was geht / nicht geht etc.
https://github.com/ioBroker/ioBroker.admin/issues/2674
ad 2) Oliverio
Ev. erstell du da ein Issue - mir ist nicht 100% klar auf welche Config du dich beziehst wo was nicht erreichbar ist -
@oliverio sagte in Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30:
tabs
kein umbruch bzw schrift wird soweit verkleinert, dann wird aber der text unleserlich
am beispiel iobroker config (weiß nicht ob das json config ist oder react nativ)
können die rechten tabs nicht mehr erreicht werden bei handy format hochkantDas kann man in der jsonConfig mit
tabsStylekonfigurieren. -
@simatec said in Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30:
@oliverio sagte in Meeting für ioBroker Core/Dev/Admin 18.09.24 20:30:
tabs
kein umbruch bzw schrift wird soweit verkleinert, dann wird aber der text unleserlich
am beispiel iobroker config (weiß nicht ob das json config ist oder react nativ)
können die rechten tabs nicht mehr erreicht werden bei handy format hochkantDas kann man in der jsonConfig mit
tabsStylekonfigurieren.Ähmmm
a) Wie wäre es wenn solche Infos in die jsonConfig docu (scheme,md) irgendwie Eingang finden. Bin nicht sicher ob ich mir die Info merke bis ich das wieder brauche. In schema.md steht nur
CSS Styles in React format (marginLeftand notmargin-left) for the Mui-Tabs component.
Ohne React Wissen kann man mit der Beschreibung nichts anfangen. Und der Großteil der jsonConfig Devs haben null Ahnung von react und zumindest ich weiß nicht wo ich mui Infos suchen sollte.b) Wäre es nicht sinnvoll das als default zu setzen wenn es das Problem Tabs Umbruch löst?
