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

[foxriver76]

Vielleicht in der großen Runde mal die Meinung zum Alleinstellungsmerkmal von ioBroker.

• Wo unterscheiden wir uns aktuell von den anderen Open Source Smart Home Lösungen?
• Wo möchten wir uns in Zukunft von den anderen Lösungen abheben/unterscheiden?

Daraus kann man in Zukunft eine Vision & Strategie für ioBroker als Plattform ableiten.

Ich war in letzter Zeit öfter in derartige Gespräche entwickelt und wenn gefragt wurde was wir anderes als z. B. HA machen, ist mir oftmals nur die Community-Nähe und nativ deutschsprachige Community eingefallen. Mir fehlt auch leider der Überblick was andere Plattformen treiben, evtl. haben andere Meeting-Teilnehmer da bereits Erfahrungen gemacht.

[Jey Cee]

@foxriver76 sagte in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

Wo unterscheiden wir uns aktuell von den anderen Open Source Smart Home Lösungen?

Wäre halt super wenn sich für jedes System jemand findet der damit auch Erfahrung hat und das dann den anderen kurz vorstellt. So haben wir ne gute Basis um die Unterschiede heraus zu Arbeiten.

Ich persönlich hab mit keinem der anderen Systeme Nennenswerte Erfahrungen, obwohl ich mir immer vorgenommen habe mal HA im Betrieb zu Testen.

Für FHEM würde ich jetzt mal @haus-automatisierung nominieren da er auch schon dafür Entwickelt hat und Videos dazu gemacht hat.

[jogibear9988]

@jey-cee

Welche System gibt es denn?

homeAssistant
openHAB
ioBroker
FHEM

Grundlegender unterschied ist ja erst mal die Technologie, oder?
HomeAssistant -> python, openHAB -> Java, ioBroker -> Node,
FHEM -> Perl
Sonst können doch alle ziemlich das gleiche, wobei bei vielen glaube sehr viel config über Textfiles etc geht, und bei ioBroker fast alles über die UI.

Ich hatte schon FHEM (vor gefühlt 15 Jahren) und OpenHab im Einsatz, aber ist beides schon so lange her, das ich da auch komplett raus bin.

[Jey Cee]

@jogibear9988 sagte in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

Welche System gibt es denn?

Gibt noch non Open Source die man auch betrachten sollte.

Homee
Homey
IPSymcon
... Mehr fallen mir jetzt adhoc nicht ein

Domoticz wäre noch open source soweit ich weis.
Außerdem findet mqtt (gateways) immer mehr Verbreitung und auch da gibt es schon Ansätze Smart Home Apps und Plattformen zu Bauen.

[Garfonso]

Also ich hab HomeAssistant selber noch nicht viel genutzt, aber da ich aktuell den Lovelace-Adapter maintaine, der die Oberfläche von HomeAssistant auf ioBroker umbiegt (bzw. ioBroker umbiegt, so dass die Oberfläche von HomeAssistant funktioniert), könnte ich was dazu sagen, wenn ich es schaffe mal wieder da zu sein. Wobei Bluefox da sicherlich auch viel zu weiß.

@jogibear9988 said in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

onst können doch alle ziemlich das gleiche, wobei bei vielen glaube sehr viel config über Textfiles etc geht, und bei ioBroker fast alles über die UI.

Das geht mittlerweile in HomeAssistant auch. Ich glaube da muss man nur noch in ganz seltenen Fällen ans Yaml. (da ist das bei ioBroker wieder deutlich mehr geworden, im neuen Admin sind Objektänderungen z.B. im JSON direkt).

[simatec]

Aktuell scheinen ja gefühlt alle Leute ziemlich aggressiv unterwegs zu sein und dies auch gefühlt so ein Trend in der Bevölkerung zu sein scheint.

In Issues bekommt man das inzwischen auch mehr und mehr zu spüren und ich finde, wir könnten im Meeting mal allgemein darüber diskutieren, wie man mit Beleidigungen und Äußerungen unter der Gürtellinie am besten umgeht und die innerhalb der Community behandelt.

Im Prinzip mal so einen kurzen Leitfaden diskutieren, wie man Einheitlich damit umgeht.

@andre und ich hatten gerade die letzten Tage wieder so einen Extremfall...

[Neuschwansteini]

@simatec

meiner Meinung nach am Sinnvollsten, wenn man wegen Issues wegen Beleidigung oder wiederholt fehlenden Angaben schliesst.
Ich bin es auch Muede, 100x nach Versionsnummer und logfile-Meldungen zu fragen.
Einen Standardtext zurechtlegen, der das abfragt, erfolgt keine Antwort auf die Frage, Issue zu.
Kommen weitere Kommentare ohne die Angaben, dann Verwarnung an den User, nach naechsten "Vergehen" dann ein Block auf Github.
Hab auch schon mehrere auf der Blocklist, da ich mir das selbst als Nicht-Developer und nur als Tester nicht antue, wenn man nett nach Details fragt und man nicht faehig ist, diese zu nennen und nur mit "geht nicht" gibts halt nur ein "gibts nicht" zurueck..

[Garfonso]

@ilovegym

für die Standard-Sachen hilft auch ein Template für issues. Ich meine das hat der creator mittlerweile drin (?), wenn nicht, sollten wir das einführen. Einige iobroker repositories haben sowas (admin und js-controller, glaube ich)

[mcm1957]

@garfonso
Ja hat er

[mcm1957]

Ich hätt da noch ein Thema - Erkennung von veralteten Adaptern

Hintergrund:
Derzeit erfahren "wir" nur eher zufällig von veralteten, nicht mehr sinnvoll verwendbaren Adaptern, da es keine geplante Vorgangsweise gibt, diese zu erfassen. Ergebnis sind unbrauchbare Adapter im Repository.

Wichtig erschint mir v.a. Punkt a) - wie erfahren wir davon?

Bedarf / Ziel:

a) Festlegung wie Problemadapter an ioBroker Team herangetragen werden können:

• Issue in AdapterRequests od. neuem AdapterProblems
• eigener Forumsbereich
• andere Ideen ?

Das wäre dann v.a im Forum zu kommunizieren.

b) Vorgangsweise beim Verwerfen von Adaptern (- eher low prior, das funktioniert eigentlich eh -)

• Adapter aufzeigen in Telegramm
• Topic im Forum
• Admin news
• ggF Issue in Requests
• Falls maintainer Migration in community
• sonst Enrtfernung aus Repos

Neuestes Beispiel:
https://github.com/BuZZy1337/ioBroker.roadtraffic
seit 4 Jahren keine commits
seit Jänner ein Issue das er nicht geht
jetzt zufällig im Forum aufgefallen weil wer ein Problem hat

[Jey Cee]

@mcm57 sagte in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

andere Ideen

1. Sentry im Admin nutzen um die Systeme zu Zählen bei denen ein Adapter (Je Version) crasht.

Ist kein Ersatz für die Meldung der User, da Adapter zwar laufen aber nicht zwangsweise Daten liefern. Hilft aber Adapter zu identifizieren die gar nicht mehr laufen.

2. Rezensionen lesen

3. Adapter Repositories auf Github überprüfen wann zu letzt die GH Action Tests gelaufen sind und ob sie Erfolgreich waren.
   Bei bedarf forken, GH Action Tests Aktualisieren und laufen lassen.

[mcm1957]

@jey-cee said in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

1. Sentry im Admin nutzen um die Systeme zu Zählen bei denen ein Adapter (Je Version) crasht.
   Ist kein Ersatz für die Meldung der User, da Adapter zwar laufen aber nicht zwangsweise Daten liefern. Hilft aber Adapter zu identifizieren die gar nicht mehr laufen.

Das sollte durchaus weiter verfolgt werden. Auch wenn dafür eher der js-controller zuständig scheint.

2. Rezensionen lesen

Das ist bei 100ten Adaptern schwer. Ich kenn keinen Weg z.B. die letzen xx Rezensionen über alle Adapter anzuzeigen. Man könnte aber prüfen, ob es ein Art Infomail / Subscription sinnvoll wäre um neue Rezessionen z.B. per push Mail zu erhalten. Generell werden aber m.E. die Rezensionen kaum genutzt.

3. Adapter Repositories auf Github überprüfen wann zuletzt die GH Action Tests gelaufen sind und ob sie Erfolgreich waren.
   Bei bedarf forken, GH Action Tests Aktualisieren und laufen lassen.

Das sagt nur bedingt etwas über die Verwendbarkeit aus. Nicht alle Adapter haben GH Tests. Manuell ist diese Aufgabe unmöglich (Aufwand) und ich bezweifle, dass da in absehbarer Zeit wer einen Automatismus schreiben wird.

Mir gehts im Prinzip zunächst mal um einen definierten Weg wie wir von Problemadaptern erfahren können - sprich aktive Meldungen von Usern (od. auch von @Thomas-Braun der ja 200% aller Posts zu lesen scheint) erhalten können die 'man' (auch ich) dann gezielt durchforsten kann.

[Knallochse]

@mcm57 Als Idee möchte ich auf das Bewertungssystem im Admin hinweisen
Man kann unter dem Menüpunkt „Adapter“ 1 bis 5 Sterne vergeben und auch eine Bewertung schreiben.
Vielleicht kann man das so erweitern, dass User ohne Github Account mitteilen können, ob ein Adapter überhaupt funktioniert.

PS: Hab noch 2 Adapter für euch, die schon seit geraumer Zeit nicht mehr funktionieren.
coronavirus-statistics
web-speedy

[mcm1957]

An sich heir offtopic - aber @Dutchman kkanst du was zum coronavirus.statistics sagen?
@knallochse said in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

PS: Hab noch 2 Adapter für euch, die schon seit geraumer Zeit nicht mehr funktionieren.
coronavirus-statistics

Oder verwechsel ich da was mit dutchman und dutchmanNL

[mcm1957]

Zusätzlich noch ein ev. Minitopic.

Wollen wir eine neue Role value.duration

Hintergrund:
https://github.com/ioBroker/ioBroker.admin/issues/2078
Request in admin object browser durations zu formatieren

@apollon77
Ev gleich beim Standardpunkt "Welche neuen Rollen ..." mit erledigen

Eistee82 created this issue in ioBroker/ioBroker.admin

open Object Browser: Display formated Duration #2078

[Knallochse]

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

Aktuell scheinen ja gefühlt alle Leute ziemlich aggressiv unterwegs zu sein und dies auch gefühlt so ein Trend in der Bevölkerung zu sein scheint.

In Issues bekommt man das inzwischen auch mehr und mehr zu spüren und ich finde, wir könnten im Meeting mal allgemein darüber diskutieren, wie man mit Beleidigungen und Äußerungen unter der Gürtellinie am besten umgeht und die innerhalb der Community behandelt.

Im Prinzip mal so einen kurzen Leitfaden diskutieren, wie man Einheitlich damit umgeht.

@andre und ich hatten gerade die letzten Tage wieder so einen Extremfall...

Sicher sollte man sich Beleidigungen nicht gefallen lassen. Ich bin hier für Strafen wie im Fußball.

1. Foul (Beleidigung) - gelbe Karte (für alle User sichtbar)
2. Foul - Platzverweis (Sperre)

Was mich aber bei deinem Beitrag stört, ist die verallgemeinerte Bezeichnung „gefühlt alle Leute“.
Ich bin der festen Überzeugung, dass sich die absolute Mehrheit zu benehmen weiß.

Mir ist aufgefallen, dass sich einige führende Entwickler von IoBroker hier leider kaum noch äußern.
Ich hoffe das es nicht daran liegt, dass die wenigen „Ar…lö…er“ die Entwickler aus diesem Forum vertreiben.
Bitte lasst nicht zu, dass einige wenige uns den gemeinsamen Spaß an IoBroker nehmen.

[Jey Cee]

@dutchman sagte in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

Forum 503 Fehler und Lösung

Aus meiner sicht gibt es keinen Grund dafür das im Dev Meeting zu besprechen. Vorallem nicht weil sowohl die Ursache, wie auch die möglichen Lösungen bekannt sind.
Ich hab das bereits an Bluefox und Apollon77 weiter geleitet.
Vielleicht sollte sich hier die Administrative Ebene sepperat treffen um solche Informationen zu Teilen und über Lösungen zu Sprechen.

[mcm1957]

@jey-cee
Hab mir grad die Tagesordnungspunkte angesehen. Wenn wir noch heute fertig werden wollen sollten wir den Punkt wirklich streichen.

(Hinweis: Beitrag nach Durchsicht der aktuellen Punkte geändert)

[Homoran]

@mcm57 you've got mail

[simatec]

@knallochse sagte in Meeting für ioBroker Core/Dev/Admin 20.09.23 20:30:

Was mich aber bei deinem Beitrag stört, ist die verallgemeinerte Bezeichnung „gefühlt alle Leute“.

Das war auch nicht unbedingt auf das Forum oder die Community bezogen, sondern so ein allgemeiner Trend in der Bevölkerung.
Mein empfinden ist schon so, dass die Leute sehr angespannt und teilweise aggressiv im Alltag rüberkommen.
Egal ob z.B. im Job, oder im Supermarkt... Vielleicht ist es auch nur mein persönliches empfinden...