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

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

[OliverIO]

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 habe

Umbruch in Tabellen, wenn der Bildschirm nicht breit genug ist.
Aktuell wird muss links/rechts gescrollt werden um alle felder zu erreichen

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 hochkant

[Ben1983]

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.

[mcm1957]

@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 habe

Umbruch in Tabellen, wenn der Bildschirm nicht breit genug ist.
Aktuell wird muss links/rechts gescrollt werden um alle felder zu erreichen

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 hochkant

Zu 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

mcm1957 created this issue in ioBroker/ioBroker.admin

open [enhancement]: Responsive Design / jsonConfig & Tables #2674

[simatec]

@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 hochkant

Das kann man in der jsonConfig mit tabsStyle konfigurieren.

https://github.com/simatec/ioBroker.backitup/blob/7ec5b6d7815aecf805834f50abb8dce8b17ffde2/admin/jsonConfig.json5#L4

[mcm1957]

@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 hochkant

Das kann man in der jsonConfig mit tabsStyle konfigurieren.

https://github.com/simatec/ioBroker.backitup/blob/7ec5b6d7815aecf805834f50abb8dce8b17ffde2/admin/jsonConfig.json5#L4

Ä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?

[mcm1957]

@mcm1957
Weil wir gestern über die width Daten für sm xs, ... gesprochen haben hir der Link zu den Daten die BlueFox erwähnt hat:

https://mui.com/material-ui/customization/breakpoints/#default-breakpoints

xs, extra-small: 0px
sm, small: 600px
md, medium: 900px
lg, large: 1200px
xl, extra-large: 1536px

Wie diese allerdings zu interpretieren sind bin ich mir nicht sicher.
xs < 600px?
sm 600 - 900
md 900 -1200
lg 1200 - 1536
xl > 1536
usw ???

@Bluefox
Ist das so richtig zusammengesucht? Wenn ja könnte man (tm) / auch ich wenn ich dran denke, das in die jsonSchema Datei eintragen

[Jey Cee]

@mcm1957 bluefox hat es schon so wie im Link übernommen in das Schema.
Ich interpretiere das genau so wie du und man sollte es zum besseren Verständnis auch so übernehmen.

[OliverIO]

@mcm1957

Die Zahlen, die du aufgeschrieben hast, ist die Pixelbreite des Endgeräts, bei dem dann die jeweilige Einstellung wirkt.
md lg xl eher bei desktops
Xx dann eher bei mobilgeräte, wobei man auch immer berücksichtigen muss ob jemand das Gerät hoch oder quer hält.
Für jeden Einstellung kannst du einen Wert von 1 bis 12 eintragen, was dann einem zwölften des Bildschirms entspricht.
12 entspricht dann der vollen bildschirmbreite

Bspw 4 Felder alle mit xs =12 und md=3,
Auf dem Handy sind dann die Felder alle untereinander, auf dem Desktop sind die 4 Felder alle in einer Zeile

[ldittmar]

Bitte sucht euch einem Termin für ein Frontend Meeting aus: https://forum.iobroker.net/topic/77012/umfrage-meeting-frontend-responsive-design