Ich werde heute eine erste CircleCI-Einrichtung vornehmen, kannst du mir dann beim Docker-ARM-Build helfen? 
(du bist der Experte dafür!)
Ich habe nachgeschaut, der Respeaker v2 läuft auf Debian, genau wie der Raspberry Pi. Meiner Meinung nach sollte es problemlos funktionieren (genau wie Gladys 3 auf dem Respeaker v2 ohne Probleme laufen sollte).
Ja, sobald du deinen Fork gepusht hast 
@VonOx Am Ende wird es wohl eher morgen! 
Heute habe ich weiter an den Boxen des Startbildschirms gearbeitet, ich bin fast fertig mit diesem Teil.
Ich habe mich besonders mit der „Kamera“-Box beschäftigt, und zwar mit dem „RTSP-Kamera“-Dienst von Gladys 4.
Das ist sehr ähnlich zu dem, was @piznel für Gladys 3 gemacht hat. Ich verwende ffmpeg, um einen RTSP-Stream zu lesen und das aktuellste Bild der Kameras im Speicher zu behalten (davon habe ich weiter oben in diesem Thema schon gesprochen, falls es euch interessiert).
Wenn das Frontend geladen wird und ein Kamerabild anfordert, sendet Gladys selbst ein komprimiertes Bild an das Frontend (ohne also die Kamera direkt anzusprechen), was den Vorteil hat, dass es auch außerhalb des Netzwerks und sogar über den Gateway funktioniert – und das ist genau das Tolle daran!
Ein kurzer Twitter-Thread zum Dashboard in Gladys 4:
Es gibt noch etwas Arbeit an den Boxen, aber das Größte ist geschafft!
Zögert nicht, wenn ihr Fragen oder Feedback habt.
@Vonox: Genau das habe ich mir gedacht, nur durch den Wechsel zu CircleCI, ohne irgendwelche Optimierungen, sinkt die CI-Testzeit von 9 Minuten auf 4 Minuten… Und vor allem starten sie sofort, während TravisCI oft 2-3 Minuten in der Warteschlange steht. Seit dem Kauf ist Travis nicht mehr das, was es mal war.
Und ich denke, wir haben noch einige Optimierungen vorzunehmen, z. B. das Caching der Abhängigkeitsinstallationen (sehr einfach mit CircleCI)
Ich habe meinen Teil auf master gemerged (Config => https://github.com/GladysAssistant/gladys-4-playground/blob/master/.circleci/config.yml )
Ich lasse dich mal einen Blick auf den parallelen Docker-Build für x86/ARM werfen?
Ich habe einen Kommentar zu diesem PR auf GitHub bezüglich meiner Vorstellung des Ablaufs zum Hinzufügen eines Geräts für Dienste, die in der Lage sind, das Netzwerk zu scannen, gepostet:
https://github.com/GladysAssistant/gladys-4-playground/pull/121#issuecomment-495109597
Der Ablauf wird sich etwas ändern. Lasst mich wissen, was ihr davon haltet, und wenn ich nicht klar war, sagt es mir!
Wie siehst du die Kommunikation für den Release der V4 von Gladys in einigen Monaten oder sogar Wochen?
Es gibt unzählige Foren zur Hausautomatisierung und zu Hardware-Herstellern.
Wie z. B. Seeed Studio, Arduino, … Wäre es nicht interessant, ein Thema zu erstellen, um zu informieren, was man mit dieser oder jener Hardware von Seeed oder Arduino machen kann, oder noch mehr, und den Lesern Lust darauf zu machen, Gladys zu nutzen?
Dadurch könnte die Community wachsen, die Nutzerfeedback, … erhalten.
Ja, ich mache mich dieses Wochenende daran.
Schon in einigen Wochen ist es nur der Release der ersten Alpha! Lasst uns nicht zu schnell sein Eine Alpha ist eine Version, die für sehr erfahrene Nutzer, quasi Entwickler, gedacht ist. Ich würde keine riesige Kommunikation starten, es wird nur ein quasi-interner Pre-Release sein, um Feedback von der bestehenden Gladys-Community zu erhalten und Anpassungen an vielen Punkten vorzunehmen.
Eine Alpha ist keine produktionsreife Version.
Für den echten Release wird der Kommunikationsplan tatsächlich ziemlich umfangreich sein:
Ich werde wahrscheinlich gleichzeitig einen Wettbewerb starten (wie ich es beim Launch des Community-Pakets gemacht habe) mit Gladys-Stickern und Material als Gewinn!Für diejenigen, die sich erinnern =>
Das Ziel wäre, Artikel/Tests/Bewertungen von Gladys 4 auf diesen Plattformen zu haben.
International werde ich die klassische Kombination machen: Hacker News + Reddit. Ich habe normalerweise gute Rückmeldungen auf dem Raspberry Pi Subreddit.
Und schließlich wird es der Beginn meiner französischen Konferenztour sein, um die v4 zu bewerben Ich habe viele Rückmeldungen zu meiner Umfrage Anfang des Jahres erhalten, anscheinend geht es um 6 Monate Konferenzen in ganz Frankreich, keine Region wird verschont 
Es wird anstrengend sein, aber ich freue mich darauf!
Das ist im Moment, was ich im Kopf habe. Nach einem Launch ist wichtig, aber der langfristige Aspekt ist noch wichtiger.
Wie ich im Manifest sagte, bevorzuge ich, dass 1000 Gladys-Nutzer von Gladys 4 begeistert sind, anstatt dass 10.000 Nutzer nur zufrieden sind
Wenn ihr Ideen habt/ Kontakte für den Launch von Gladys 4, ich bin immer offen dafür!
Das ist schön! 
Halt mich auf dem Laufenden!
Bah da haben wir’s
Gute Grundlage
Falls du Hilfe bei der Erstellung von Tutorials, HTML oder CSS brauchst, kann ich aushelfen.
Bei reiner Entwicklung kann ich nicht helfen, aber das bisschen, was ich tun kann, entlastet die Entwickler 
Nur eine Frage. Wird Gladys 4 in der Lage sein, uns Fragen zu stellen? Zum Beispiel bei der Ankunft in der Wohnung, ob wir Musik hören möchten usw?
Sauber!
Übrigens, bei Docker gibt es noch etwas, das ich noch nicht wirklich angeschaut habe, nämlich wie man es schafft, dass man Netzwerk-Scans (Philips Hue, Sonos, etc.) vom Inneren des Containers aus durchführen kann. Hast du das schon mal gemacht?
[Edit]:
Offenbar sollte das mit network_mode: host funktionieren!
Ich bräuchte tatsächlich Hilfe bei der Dokumentation Ich werde hier darüber sprechen, wenn es soweit ist!
Gute Idee! Ich habe ein Issue erstellt =>
https://github.com/GladysAssistant/gladys-4-playground/issues/128
Das Host-Netzwerk sollte für die meisten Protokolle funktionieren.
Ich habe eine dedizierte macvlan-Schnittstelle für Gladys erstellt. Ich könnte den Hue-Bridge (im Host-Modus) testen.
Hallo zusammen!
Ich habe eine kleine Frage, die ich mir stelle und bei der ich gerne eure Meinung hören würde, bevor ich irgendetwas implementiere: die Verwendung von „Telemetrie“ in Gladys 4.
In jeder Software, ob Open Source oder nicht, gibt es oft Maßnahmen, um anonyme Nutzungsstatistiken des Programms zu sammeln.
Wenn ich Statistiken sage, geht es nur darum, zum Beispiel die Anzahl der Installationen der Software zu kennen. Nichts Schlimmes.
Ich weiß, es ist ein sehr sensibles Thema, und einige von euch werden sich jetzt denken: „Was, will er uns tracken??“
Absolut nicht. Die Privatsphäre der Gladys-Nutzer hat für mich oberste Priorität, und das sieht man an allen meinen Entwicklungsentscheidungen (wir sind praktisch die Einzigen auf dem Markt, die ein Ende-zu-Ende-verschlüsseltes Web-Gateway haben, zumindest soweit ich weiß).
Das aktuelle Problem in Gladys 3 ist, dass wir keine Informationen darüber haben, wie viele Leute Gladys bei sich installiert haben. Ich kenne die Anzahl der Downloads von Gladys, aber das ist eine ziemlich nutzlose Statistik, weil wir nicht wirklich wissen, wer dahinter steckt.
Alle Open-Source-Projekte sammeln anonyme Statistiken, um die Nutzung der Software besser zu verstehen:
Ich denke, es ist schade, diese Informationen nicht zu haben, denn wir arbeiten im Blindflug.
Außerdem sehe ich nicht, wie das Sammeln der installierten Softwareversionen und der Länder/Regionen einen Eingriff in die Privatsphäre darstellt, solange nur die Endstatistiken gespeichert werden und keine persönlichen Informationen gesammelt werden.
Was ich vorhabe
Alle 24 Stunden führt Gladys eine Anfrage durch, um zu prüfen, ob eine neue Version verfügbar ist. Das ist nichts Neues, das war schon in der v3 der Fall.
Die „Best Practice“ für das Sammeln von Statistiken ist es in der Regel, ein Log der API-Aufrufe zu dieser Route zu führen und zu speichern:
Das würde es ermöglichen, die Nutzung von Gladys 4 besser zu messen. Es werden keine persönlichen Informationen gesammelt.
Sagt mir, was ihr davon haltet
Ich hoffe, euch damit nicht zu schockieren, glaubt mir, in der Industrie nehmen die meisten Open-Source-Projekte nicht so viele Rücksichten wie ich auf dieses Thema. Ich will das nach bestem Wissen und Gewissen machen
Hallo,
Ich muss sagen, dass mir mein Schluck Kaffee im Hals stecken blieb, als ich „Telemetrie“ las, aber mit etwas Abstand denke ich, warum nicht… Und wenn es jemanden stört, kann man den Aufruf immer noch über eine Firewall blockieren, für die erfahrenen Nutzer.
Die Nutzung von Telemetrie, um echte Statistiken zu erhalten und beispielsweise die Fragmentierung der Versionen kennenzulernen, dafür bin ich! Auch aus Sicherheitsgründen ist es wichtig, das zu wissen.
Aber es ist nicht nötig, die Stadt zu kennen, nur das Land ist meiner Meinung nach wichtig. Das Land ist interessant, um eine neue Übersetzung zu entwickeln und die Community ein wenig besser kennenzulernen. Die Stadt ist jedoch eine Daten, die nicht viel mehr bringt und beginnt, etwas genauer zu werden (auch wenn GeoIP nicht perfekt ist).
Wenn du wirklich die Region kennen möchtest, könnte die Idee, die Koordinaten zu kürzen, einen Kompromiss ermöglichen 
Hallo, ich bin nicht gegen die Nutzung von Telemetrie, das eigentliche Problem, denke ich, um möglichst viele Daten zu sammeln, ist es, in zwei oder drei nicht zu langen Sätzen zu erklären, welche Daten gesammelt werden und wofür sie dienen. Nicht zu lang, weil die Faulen sofort auf „Ablehnen“ klicken, sobald sie das Wort Telemetrie sehen ^^`
Danach bin ich einverstanden, man sollte großzügig bleiben, die Stadt ist vielleicht ein bisschen zu genau.
Ich gehöre zu den „Faulpelzen“
