http://blog.inspirant.de/feed.php 2026-02-25T20:10:45+01:00 <p><img class="nb-align-right" style="margin-right: 10px; box-shadow: 3px 3px 10px 1px rgba(0,0,0,0.75); margin-bottom: 20px;" src="http://blog.inspirant.de/content/public/upload/software_0_o.jpg" alt="software am Bildschirm eines Programmierers" width="231" height="154" />Schon seit mehreren Jahren nutzen wir auf der Arbeit KI-Tools. Aber meist für kleine oder spezifische Aufgaben. Also eine spezielle Funktion erstellen lassen, ein kurzes Bash-Script oder auch zu Recherche-Zwecken. Meist war es aber frustrierend, denn die KI hat sich ständig Funktionen ausgedacht, die es gar nicht gab (Halluzinationen) und nicht selten wurden wir durch die KI auch auf die falsche Spur geschickt. Erkennbar war aber auch, dass die Qualität von Code besser wird, je mehr Code es davon im Internet gibt. Bei der Hilfe zu einem WebExtension Add-On für Thunderbird, hat die KI extrem viel Halluziniert und war kaum zu gebrauchen. Es hat eher Zeit gekostet. Wenn man aber C, C++, JAVA oder go Code generieren lässt, ist es deutlich besser.</p> <p>Dennoch ist es eine interessante und faszinierende Technologie. Aus passendem Anlass heraus, weil die Projekte klein und die Sprache <em>go</em> sein sollte, habe ich soeben mein erstes kleines Software-Projekt vollkommen mit KI-Unterstützung erstellt. Ich habe dabei viel über die Arbeit mit der KI gelernt und auch einen noch tieferen Einblick in die Materie erhalten.</p> <p>Hier die Randbedingungen:</p> <ul> <li>Ich nutze <strong>Visual Studio Code</strong> mit dem <strong>Blackbox AI</strong> Coding-Assistenten.</li> <li>Das Projekt wurde in <em><strong>go</strong></em> (oder auch golang) geschrieben.</li> <li>Es verwendet die <strong>Cassandra</strong>-Datenbank.</li> <li>Es ist im Prinzip ein einfacher <strong>REST API Endpunkt</strong>, der im Netz verfügbar sein soll und dessen Verbindungen durch LetsEncrypt gesichert sein sollen (https).</li> <li><strong>Ich kenne <em>go</em> bereits</strong> und habe bereits damit programmiert.</li> </ul> <p><em>Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!</em></p> <p><!-- pagebreak --></p> <h1>Der initiale Prompt</h1> <p>Die Ausarbeitung des initialen Prompts war durchaus anspruchsvoll. Ich musste mir ja klar darüber werden, was ich haben möchte, welche Technologievorgaben ich mache und in welcher Sprache, an welchem Ort das Projekt abgelegt werden soll, ob und welche Konfig-Dateien verwendet werden sollen etc. Als besonders schwierig empfand ich, das so schreiben zu müssen als wenn ein Anfänger vor mir sitzt. Ich darf von kaum einer Sache erwarten, dass sie bereits bekannt ist. Also muss man sich gut sortieren und auch kleine Gedanken zum Aufbau oder der Struktur erfassen.</p> <p><strong>Mir fiel währenddessen sofort auf, dass ich diesen Prompt nur so schreiben konnte, weil ich bereits Ahnung von Softwareentwicklung habe und durch geschickte Vorgaben bereits viele Anfängerfehler vermeiden konnte. </strong></p> <p>Ich habe klare Vorgaben gemacht: Zur Struktur der API, der Konfig-Dateien und deren Werte, zur Verschlüsselung und dem Encoding, zu Prüfungen und Rückgabecodes und auch zu den Frameworks die in <em>go</em> verwendet werden sollen (zB <em>echo</em> als web framework und router). Ohne Erfahrung in diesem Gebiet wäre der erste Schuss deutlich wahrscheinlicher nach hinten los gegangen…</p> <h1>Nacharbeit</h1> <p>Nachdem der Prompt abgegeben wurde, hat die KI in wenigen Minuten das Projekt erstellt und auch gleich getestet. Aber einiges hat mir nicht gefallen und ich habe durch viele Prompts Dinge am Code korrigiert (Auszug):</p> <ul> <li>Es wurden viele Parameter einzeln an Funktionen übergeben, statt einfach die Konfigurations-Struktur zu übergeben.</li> <li>Verschlüsselungs-Keys wurden unnötig komplex und verbose gespeichert.</li> <li>Die Software hatte keinen sauberen Shutdown und damit beim Beenden der Software (SIGKILL oder Ctrl+d) die Datenbank potentiell beschädigt oder Verbindungen verwaisen lassen.</li> <li>Entscheidungen zur API und den Rückmeldungen nahmen keine Rücksicht auf die anderen Komponenten, die später darauf zugreifen sollen.</li> <li>Funktionen waren teilweise sehr Lang und Umfangreich, statt diese in leichter zu wartende Teilfunktionen zu unterteilen.</li> <li>Es wurde keinerlei Debugging-Log Funktion eingebaut. Die Suche nach Problemen ohne Debugging-Logs würde sich unnötig schwierig erweisen und sehr lange dauern.</li> <li>Ständig hat mir die KI neue Abhängigkeiten erzeugt. Mal eben ein anderes Framework für Logs, ein Framework für Stringverarbeitung etc. Ich musste das über mehrere Chats aus dem Projekt entfernen um ein möglichst wartbares Projekt zu erhalten.</li> </ul> <h1>Fazit</h1> <p>Die benötigte Entwicklungs-Zeit bis zum lauffähigen Produkt war unschlagbar kurz. In nur wenigen Stunden wurde das Projekt lauffähig erzeugt und auch dokumentiert. Das wäre mir, durch traditionelles Programmieren, völlig unmöglich gewesen. Keine Chance. Das kann also durchaus eine echte Hilfe im Alltag von Programmierern sein. Vor allem Routineaufgaben wie Validierung von API- und Nutzer-Eingaben oder die Errichtung eines Grundgerüstes und der Datenbank-Verbindung hat mir sehr gut gefallen und wirkliche Erleichterung gebracht.</p> <p>Aber auch die Schattenseiten sind deutlich: Nur weil ich bereits programmieren kann und auch Erfahrung mit solchen Projekten habe, konnte ein brauchbares Konstrukt entstehen. Ohne mein Eingreifen und die bereits im Prompt, und dann später im Chat, erfolgten Korrekturen und Detailanweisungen, wäre es definitiv kein produktionsfähiges Softwareprodukt geworden. Also, es hätte schon irgendwie funktioniert, aber im Nachgang im Setup, im Betrieb, in der Weiterentwicklung und in der Wartung viele Probleme verursacht. Diese hätten die Zeitersparnis dann sicher zunichtegemacht und über lange Zeit für Probleme gesorgt.</p> <p style="text-align: center;"><em>Wir müssen in der nahen Zukunft wohl mit viel Software rechnen, die "irgendwie funktioniert".<br />Aber eben nicht gut, sicher oder performant arbeitet.</em></p> <p>Es braucht also einen Senior-Entwickler, der Erfahrung hat und die Programmiersprache und die Tücken kennt. Aber woher lernt man das, wenn man nur Vibe-Coding macht? Ein Entwickler, der von Anfang an nur Vibe-Coding macht, wird diese Fertigkeiten und Erfahrung niemals aufbauen. Das bedeutet, wir bilden aus finanziellen Gründen, aber auch Bequemlichkeit, vermutlich bald keine Programmierer mehr aus. Solange es noch Senior-Programmierer gibt, welche die KI sinnvoll bedienen können, ist das eine nachvollziehbare Sache. Aber was ist in 10 bis 20 Jahren? Wenn die Entwickler mit Erfahrung in Rente gehen oder wegfallen? Hoffen wir mal, dass bis dahin diese Probleme keine Probleme mehr sind und die KI auch die Nebenschauplätze abdecken kann. Also den Kundenwunsch verstehen, in eine klare Definition und Anforderungs-Spezifikation umwandeln und dann auch Entwickeln und in Betrieb nehmen.</p> <p>Auf Dauer wird demnach der Job des Entwicklers oder Programmierers wegfallen. Bisher habe ich das bezweifelt, aber mit der Zeit wird das wohl so kommen.</p> <p>Für junge Leute mit Interesse am Programmieren gibt es, meines Erachtens, nur zwei mögliche Entscheidungen:</p> <p>1) Lerne das Programmieren mit konsequentem Verzicht auf KI, um ein guter Programmierer zu werden. Das geht nur so! Dann, später, kann man die größeren Software-Projekte verstehen und mit KI-Einsatz gutes ermöglichen. Das wird auch in Zukunft ein guter Job sein, und auch gefragt sein.</p> <p>oder</p> <p>2) Verzichte auf eine Karriere als Programmierer und mach das allenfalls zu deinem Hobby für private Projekte. Nutze KI und akzeptiere, dass du es möglicherweise nicht richten kannst, wenn die KI versagt.</p> <p> </p> http://blog.inspirant.de/index.php?controller=post&amp;action=view&amp;id_post=61 2026-02-25T20:10:45+01:00 <p><img class="nb-align-right" style="margin-right: 10px; box-shadow: 3px 3px 10px 1px rgba(0,0,0,0.75);" src="http://blog.inspirant.de/content/public/upload/securitybad_0_o.jpg" alt="undefined" width="180" height="180" />Ich nutze Linux schon seit vielen Jahren. Zuerst Kubuntu, Lubuntu. Dann später KDE Neon. Und seit ich bei OpenSUSE LEAP gelandet bin, habe ich die für mich ideale Distribution gefunden. Aber obwohl ich jetzt seit Jahren Linux nutze, ist mir erst jetzt bewusst gewesen, dass mein Linux-System von zB Microsoft jederzeit übernommen oder gekillt werden kann. Warum? Weil ich für dauernde Teams-Meeting-Einladungen gezwungen war, Microsoft Edge in der Linux-Version zu nutzen. Auch nutze ich gerne Visual Studio Code für die Entwicklung. Und beide Tools habe ich über die offiziellen Linux-Repositories von Microsoft in mein System eingebunden. Warum ich das so tat? Weil ich so immer die neuesten Updates bekomme.</p> <p><strong>Ich war der Meinung, dass mich mein Linux auf angemessene Weise vor Missbrauch durch externe Repository-Maintainer schützt. Das ist aber nicht so!</strong></p> <p><em>Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!</em></p> <p><!-- pagebreak --></p> <p><strong>Hinweis:</strong> Ich habe mir beim formulieren dieses Artikels von <a href="https://chat.mistral.ai" target="_blank">Le Chat</a> helfen lassen. Die Erkenntnisse und der gesamte Text wurden aber von mir überarbeitet und geprüft.</p> <h1>Das Problem</h1> <p>Linux gilt als sicher – doch <strong>diese Sicherheit hat einen blinden Fleck: externe Repositories</strong>. Sobald du ein Repository eines Drittanbieters (z. B. für Microsoft Edge, Visual Studio Code, NVIDIA-Treiber oder Codecs) einbindest, gibst du de facto Administratorrechte an den Repository-Maintainer ab. Warum? Weil dieser beim nächsten Update folgende Dinge tun könnte:</p> <ol> <li><strong>Systemkomponenten überschreiben</strong><br />Ein Repository kann beliebige Pakete anbieten – auch solche, die Systembibliotheken oder Kernel-Module ersetzen.<br /><br /><strong>Beispiel:<br /></strong>Ein bösartiges Repository könnte eine manipulierte Version von glibc, openssl oder sogar dem Kernel anbieten.<br /><br /><strong>Folge:<br /></strong>Dein System wird kompromittiert, sobald du <em>zypper up</em> oder <em>apt</em> <em>upgrade</em> ausführst.<br /><br />Du fragst wie? Der Maintainer veröffentlicht ein Update für ein scheinbar harmloses Paket (z. B. codecs), das Abhängigkeiten zu Systempaketen hat. Dein <em>apt upgrade</em> (oder <em>zypper up</em> in OpenSUSE) schlägt vor, diese Abhängigkeiten zu installieren. Du sagst wie immer "ja" – und schon ist dein System infiziert.<br /><br /></li> <li><strong>Automatische Updates als Einfallstor</strong><br />Viele Nutzer aktivieren automatische Updates – was praktisch ist, aber gefährlich, wenn externe Repositories eingebunden sind.<br /><br /><strong>Szenario:</strong><ol> <li>Du bindest ein Repository für eine tolle externe Software ein.</li> <li>Der Repository-Maintainer oder ein Angreifer, der das Repository kompromittiert, veröffentlicht ein bösartiges Update für libc6.</li> <li>Dein System installiert es automatisch, ohne dass du es merkst.<br /><br /></li> </ol></li> <li><strong>Social Engineering: Vertrauensmissbrauch</strong><br />Repository-Maintainer können Pakete mit vertrauenswürdigen Namen anbieten (zB "openssl-security-patch"), die in Wahrheit Backdoors, Trojaner, Viren oder Spyware enthalten.<br /><br /><strong>Beispiel:</strong><br />Ein Repository bietet ein Paket namens "nvidia-driver-fix" an, das tatsächlich einen Rootkit installiert.<br />Da der Name seriös klingt, installieren Nutzer es ohne Misstrauen.<br /><br /></li> </ol> <h2>Warum ist das ein strukturelles Problem?</h2> <p>Linux vertraut dem Nutzer. <strong>Paketmanager</strong> wie <em>zypper</em>, <em>apt</em> oder <em>dnf</em> <strong>gehen davon aus, dass der Nutzer weiß, was er tut</strong>. In der Realität wählen die meisten Nutzer aber einfach "Installieren", ohne die Quelle zu prüfen. Geschweige denn, dass jemand wüsste wie man eine Quelle prüft…</p> <p>Es gibt auch keine Standard-Warnungen. Auch wenn diese in der Wirkung zweifelhaft sind; im Gegensatz zu Windows un MacOS warnt Linux nicht aktiv vor den Risiken externer Repositories.</p> <p>Auch erzwingen manche Hersteller externe Repositories, wenn man immer aktuell sein möchte. Viele Programme (zB Microsoft Edge, NVIDIA-Treiber, Steam, Visual Studio Code) sind nur über externe Repositories verfügbar – Nutzer müssen sie einbinden oder mit Nachteilen leben (siehe später weiter unten).</p> <p style="text-align: center;"><span style="color: #0000ff;"><em>"Linux ist nur so sicher wie die Repositories, denen du vertraust.<br />Sobald du ein externes Repository einbindest, öffnest du die Tür<br />für potenzielle Angriffe durch diesen Anbieter – und <br />die meisten Nutzer wissen das nicht."</em></span></p> <p> </p> <h1>Lösungsansätze</h1> <p>Es gibt mehrere Wege, das Problem zu entschärfen – aber keine perfekte Lösung. Hier sind die wichtigsten Ansätze mit ihren Vor- und Nachteilen:</p> <h2>Flatpak: Sandboxing für Anwendungen</h2> <p>Wie es funktioniert:</p> <p>Anwendungen laufen in einer isolierten Umgebung (Sandbox) und haben keinen Zugriff auf das System (außer auf explizit von Dir freigegebene Bereiche). Pakete kommen aus zentralen Stores (z. B. Flathub), die Signaturen und Reviews erzwingen.</p> <p>Vorteile:</p> <ul> <li>Hohe Sicherheit (keine Systemänderungen).</li> <li>Automatische Updates (über den Store).</li> <li>Keine externen Repositories nötig.</li> </ul> <p>Nachteile:</p> <ul> <li>Nicht alle Programme verfügbar (zB VS Code, Edge nur als Community-Versionen).</li> <li>Langsamer Start (durch Sandboxing).</li> <li>Ressourcenintensiv (jede App läuft in einem Container).</li> </ul> <p>Für wen?</p> <p>Nutzer, die Sicherheit über Komfort stellen und auf offizielle Flatpaks setzen können. Aber Du musst darauf verztrauen, dass der Abbieter des Flatpaks dir nichts böses möchte und dass Du auch regelmässig wichtige Sicherheits-Updates bekommst. bei Community-Versionen sind zumindest Updates nicht selten nie oder nur sehr spät verfügbar.</p> <h2>AppImage: Portable Anwendungen ohne Installation</h2> <p>Wie es funktioniert:</p> <p>Anwendungen werden als einzelne ausführbare Datei heruntergeladen und ohne Installation gestartet. Keine Repository-Einbindung nötig.</p> <p>Vorteile:</p> <ul> <li>Keine Systemänderungen (läuft im User-Space).</li> <li>Keine Abhängigkeiten oder Repos nötig.</li> <li>Einfach zu nutzen (herunterladen, ausführbar machen, starten).</li> </ul> <p>Nachteile:</p> <ul> <li>Keine automatischen Updates (Nutzer muss manuell neue Versionen herunterladen).</li> <li>Keine Sandbox (AppImages können beliebigen Code ausführen).</li> <li>Nicht alle Programme verfügbar (z. B. Treiber, Systemtools).</li> </ul> <p>Für wen?</p> <p>Nutzer, die keine Repositories einbinden wollen und manuelle Updates in Kauf nehmen.</p> <h2>Manuelle Installation von .rpm/.deb-Paketen</h2> <p>Wie es funktioniert:</p> <p>Statt ein Repository einzubinden, lädst du die offiziellen Pakete (zB .rpm von Microsoft) manuell herunter und installierst sie. Zum Beispiel so:</p> <pre>sudo dpkg -i /pfad/zur/datei.deb # Debian/Ubuntu<br />sudo zypper in /pfad/zur/datei.rpm # openSUSE</pre> <p>Vorteile:</p> <ul> <li>Keine externen Repositories nötig.</li> <li>Offizielle Quelle → vertrauenswürdig.</li> <li>Volle Kontrolle über installierte Pakete.</li> </ul> <p>Nachteile:</p> <ul> <li>Keine automatischen Updates (muss manuell geprüft und gemacht werden).</li> <li>Umständlich (Nutzer muss selbst auf neue Versionen achten).</li> </ul> <p>Für wen?</p> <p>Nutzer, die maximale Kontrolle wollen und keine externen Repositories einbinden möchten.</p> <h2>Immutable OS: Unveränderliche Systeme</h2> <p>Wie es funktioniert:</p> <p>Das gesamte Linux-System ist unveränderlich (Solche Linux-Distributionen sind zB Fedora Silverblue, openSUSE MicroOS). Änderungen werden nur über atomare Updates eingespielt (keine klassischen <em>apt</em>, <em>dnf</em> oder <em>zypper</em> Installations-Befehle). Anwendungen werden als Flatpaks oder Container installiert.</p> <p>Vorteile:</p> <ul> <li>Maximale Sicherheit (keine externen Repositories nötig).</li> <li>Atomare Updates (keine "kaputten" Systeme nach Updates).</li> <li>Isolation (Anwendungen laufen in Containern).</li> </ul> <p>Nachteile:</p> <ul> <li>Radikale Umstellung (kein klassisches Paketmanagement mehr).</li> <li>Nicht alle Programme verfügbar (z. B. proprietäre Treiber).</li> <li>Komplex für Einsteiger.</li> </ul> <p>Für wen?</p> <p>Sicherheitsbewusste Nutzer, die bereit sind, neue Workflows zu lernen.</p> <h2>Distrobox/Toolbx: Containerisierte Distributionen</h2> <p>Wie es funktioniert:</p> <p>Du erstellst einen Container mit einer vollständigen Distribution (z. B. Ubuntu, Arch) und installierst dort die Software. Die Anwendungen werden im Host-System integriert, laufen aber isoliert im Container.</p> <p>Vorteile:</p> <ul> <li>Volle Isolation (externe Repositories bleiben im Container).</li> <li>Keine Änderungen am Host-System.</li> <li>Volle Kompatibilität (alle Pakete verfügbar).</li> </ul> <p>Nachteile:</p> <ul> <li>Komplex einzurichten (X11-Weiterleitung, Berechtigungen).</li> <li>Ressourcenintensiv (jeder Container ist eine Mini-Distribution).</li> </ul> <p>Für wen?</p> <p>Fortgeschrittene Nutzer, die externe Software sicher testen wollen.</p> <h2>SIGStore &amp; Cosign: Signaturprüfung für Pakete</h2> <p>Wie es funktioniert:</p> <p>SIGStore ermöglicht kryptografische Signaturprüfung für Software-Artefakte (inkl. RPM/DEB-Pakete). Cosign prüft Signaturen vor der Installation.</p> <p>Vorteile:</p> <ul> <li>Zukunftssicher (wird von der Linux Foundation gepusht).</li> <li>Automatisierte Signaturprüfung.</li> </ul> <p>Nachteile:</p> <ul> <li>Noch nicht flächendeckend eingesetzt.</li> <li>Nutzt nichts, wenn Nutzer Signaturen ignorieren.</li> </ul> <p>Für wen?</p> <p>Zukunftsorientierte Nutzer, die auf neue Sicherheitsstandards setzen wollen.</p> <p style="text-align: center;"><span style="color: #0000ff;">Die har<em>te Wahrheit ist:<br />"Es gibt keine perfekte Lösung. Du musst Kompromisse eingehen – entweder<br />bei der Sicherheit, beim Komfort oder beim Aufwand."</em></span></p> <h2>Zusammenfassung: Was kannst du heute tun?</h2> <p>Wenn ein externes Repository für Dich jetzt nicht mehr in Frage kommt, hast Du diese Optionen:</p> <ul> <li><strong>Flatpak/Snap</strong> nutzen, wo möglich (z. B. TeamViewer, Spotify).</li> <li><strong>Offizielle .rpm/.deb-Pakete</strong> manuell installieren (z. B. VS Code, Edge).</li> <li>Externe <strong>Repositories strikt beschränken</strong> (nur bestimmte Pakete erlauben).</li> <li><strong>Immutable OS</strong> testen (z. B. Fedora Silverblue), falls du experimentierfreudig bist.</li> <li><strong>Distrobox</strong> für unsichere Software nutzen (z. B. AnyDesk in einem Container).</li> </ul> <p> </p> <h1>Die bittere Wahrheit</h1> <p>Linux ist nicht unsicher – aber es erfordert Wissen und Disziplin. Sobald du externe Repositories einbindest, gibst du Sicherheit für Komfort auf. Es gibt aktuell keine Lösung, die beides vereint: Maximale Sicherheit und automatische Updates ohne manuellen Aufwand.</p> <p>Natürlich gibt es die Vision der optimalen Lösung. Vor allem, wenn Linux jetzt durch mehr Leute genutzt wird, weil Microsoft sich ja größte Mühe gibt den Leuten Windows auszutreiben. Also, was wäre die ideale Lösung?</p> <p>Vielleicht eine Kombination aus:</p> <ul> <li>Strikten Sandboxing-Standards (wie Flatpak) für alle Anwendungen.</li> <li>Signaturprüfung per Default (wie SIGStore) für alle Pakete.</li> <li>Bessere Nutzeraufklärung (Warnungen bei externen Repositories).</li> <li>Hersteller-Unterstützung für sichere Distribution (z. B. offizielle Flatpaks von Microsoft, NVIDIA etc.).</li> </ul> <p>Bis dahin bleibt es dabei:</p> <ul> <li>Entweder du verzichtest auf automatische Updates (manuelle .rpm-Installation).</li> <li>Oder du akzeptierst ein Sicherheitsrisiko (externe Repositories).</li> <li>Oder du gehst den häufig unbequemen Weg (Flatpak, Immutable OS, Container).</li> </ul> http://blog.inspirant.de/index.php?controller=post&amp;action=view&amp;id_post=60 2026-02-16T21:36:16+01:00 <p><img class="nb-align-right" style="margin-right: 10px; box-shadow: 3px 3px 10px 1px rgba(0,0,0,0.75); border-radius: 10px;" src="http://blog.inspirant.de/content/public/upload/wecker20257_0_o.png" alt="undefined" width="180" />Schon vor einigen Jahren habe ich mir selbst <a href="/index.php?controller=post&amp;action=view&amp;id_post=20" target="_blank">einen Wecker gebaut</a>, der bis heute in Benutzung ist und mit dem ich sehr zufrieden bin.</p> <p>Für dieses Weihnachten war die Idee, meiner Mutter einen neuen Radio-Wecker zu kaufen. Aber die Auswahl ist alles andere als Seniorengerecht und die Anforderungen waren doch so einfach:</p> <ul> <li>Großes Display</li> <li>Display-Helligkeit passt sich der Umgebung an</li> <li>Eine(!) Weckzeit</li> <li>Einfachste Bedienung ohne Hürden</li> <li>Wecken mit Radio</li> </ul> <p>Stellt sich raus, dass es Oft mit USB, Internet, zwei Weckzeiten und 6 bis 10 Knöpfen einhergeht. Dazu alles in Englisch und Mini-Taster oder schwergängige Schieber. Dazu zeigen die wenigsten Seniorengerecht die aktuelle Weckzeit an (nur winziges Wecker-Symbol etc). Scheinbar scheint bei allen ein großes Display ausreichend um das Senioren- oder Demenz-Radio nennen zu dürfen.</p> <p>Also muss ein neuer Wecker selbst gebaut werden! Ein durchaus anspruchsvolles Projekt und ein strammer Zeitplan. Ich bin sehr gespannt, ob ich das bis Weihnachten hinbekomme oder ob das Geschenk am Ende Zeitverzug hat.</p> <p><em>Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!</em></p> <p><!-- pagebreak --></p> <p style="text-align: center;"><span style="color: #0000ff; font-size: 150%;"><strong>Achtung, Nachbau auf eigene Gefahr!<br /> Keine Haftung!</strong></span></p> <h2>09.11.2025</h2> <p>Ich bin gestartet mit einer Einkaufsliste (inzwischen mehrfach aktualisiert und ergänzt):</p> <ul> <li>Display 4 Zoll TFT mit SPI-Schnittstelle</li> <li><span style="text-decoration: line-through;">Teensy 3.2</span></li> <li>ESP-32 Dev Kit C V4</li> <li>Real Time Clock RTC-Modul DS3231 I2C Echtzeituhr</li> <li>Rotary Encoder (aus dem Fundus)</li> <li>Große farbige Drucktastenschalter (Edelstahl, RUNCCI-YUN)</li> <li>Mini Kippschalter (aus dem Fundus)</li> <li>Verstärker-Modul (PAM8406)</li> <li>Radio-Modul (TEA5767 mit i2c-Schnittstelle)</li> <li><span style="text-decoration: line-through;">Lautsprecher (Zerone, 5 W 8 Ohm TV-Lautsprecher)</span></li> <li>VISATON Breitbandlautsprecher FR 7, 5W an 4Ω</li> <li>USB-C Buchse zur Stromversorgung (RUNCCI-YUN)</li> <li>3.3 DC Spannungsregler Step Down Netzteilmodul 4.75V-12V bis 3.3V 800mA</li> <li>Pegelwandler (Logic Level Shifter), 4 Kanal, BiDirektional, 5V~3.3V (i2c)</li> </ul> <p>Alles was fehlt, muss also immer wieder nachbestellt werden...</p> <h2>10.11.2025</h2> <p>Erste Tests am CAD. Da ich die meisten Bauteile noch nicht habe, sind das erst mal nur Versuche um eine Design-Idee zu finden. Möglichst kurze Druckzeit am 3D-Drucker soll es auch haben etc. Aber eigentlich kenne ich noch nicht einmal die finalen Abmessungen. Ich breche also wieder ab...</p> <p><img src="http://blog.inspirant.de/content/public/upload/wecker20251_0_o.png" alt="undefined" width="274" height="213" /></p> <h2>12.11.2025</h2> <p>Okay, der Teensy, den ich als Plattform wollte, ist mir zu Teuer. Kaum unter 30,- EUR zu bekommen. Daher soll es jetzt ein ESP32 sein. Die WLAN- und Bluetooth-Funktionen brauche ich nicht. Dazu noch ein Uhrenmodul mit Batterie als Echtzeit-Uhr (RTC). Auch eine USB-C-Buchse soll als Stromversorgung noch rein.</p> <h2>14.11.2025</h2> <p>Erste Teile sind eingetroffen, daher geht es wieder an das CAD. Den ersten Entwurf für den Deckel habe ich nach Rücksprache mit einem Bekannten neu designt und statt Ihn "Aufzusetzen" werde ich Ihn lieber "Einsetzen". Die Abmessungen sind jetzt vermutlich 140 x 80 x 70 (Breite, Tiefe, Höhe). Dann vier Gummi-Füße aufkleben und fertig.</p> <p>So schaut der Entwurf jetzt aus. Um zu erkennen wo was hin muss und wo Löcher benötigt werden und ob es Platzprobleme gibt, habe ich das Display, den Lautsprecher und andere Teile konstruiert. So kann ich Ein- und Ausblenden wann immer ich etwas benötige:</p> <p><img src="http://blog.inspirant.de/content/public/upload/wecker20252_0_o.png" alt="undefined" width="513" height="335" /></p> <p><img src="http://blog.inspirant.de/content/public/upload/wecker20253_0_o.png" alt="undefined" width="513" height="329" /></p> <p>Auch das Lautstärkerad ist jetzt eingeplant und sichtbar sowie "Böcke" für das Radio-Modul (oben links im Bild) und das Verstärker-Modul (Rechts in Bild).</p> <p>Falls es jemand interessiert, ich nutze <strong><a href="https://www.plasticity.xyz/" target="_blank">Plasticity</a></strong> als CAD-Software unter OpenSUSE LEAP 15.6 (Linux). Dieses CAD ist Fantastisch und ich liebe es. Klar, die Einarbeitungszeit muss man einrechnen. Aber vieles ist intuitiv und gut gelöst. Daher hat man schnell Erfolge. Klare Empfehlung! In Plasticity exportiere ich dann als STL und slice das dann für den 3D-Druck mit CUDA.</p> <h2>15.11.2025</h2> <p>Weitere Testdrucke mit dem Deckel. Löcher sind zu klein und die Idee, Schrift auf den Deckel direkt zu drucken, wird verworfen. Das wird weder schön noch lesbar :-( Aber Aufkleber oder mit Stift aufgemalte Symbole oder Text werden nicht haltbar genug sein. Daher versuche ich 0,4mm hohe Symbole aufzudrucken.</p> <p>Neuester Stand am CAD:</p> <p><img src="http://blog.inspirant.de/content/public/upload/wecker20254_0_o.png" alt="undefined" width="513" height="324" /></p> <p>Testdrucke des Deckels sind hoffentlich bald erledigt. Das Gehäuse wird im Druck nochmal Anspruchsvoll. Eine erste Schätzung ergibt, dass das Gehäuse über 10 Stunden drucken wird. Ich denke darüber nach, das ganze Gehäuse bei einem Profi drucken zu lassen.</p> <p>Nachtrag: Hab es selbst gedruckt. War einfach zu Neugierig :-)</p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl20251120125018592_0_o.jpg" alt="undefined" width="513" height="289" /></p> <h2>06.12.2025</h2> <p>Ja, es hat eine Weile gedauert bis ich die Zeit finde wieder etwas hier aufzuschreiben. Ich fasse die letzten Tage daher hier zusammen.</p> <p><em><strong>Erster 3D-Testdruck</strong></em></p> <p>Ich habe das Gehäuse und den Deckel selbst gedruckt und bin erst mal sehr zufrieden. Bis auf wenige Probleme am Gehäuse war es größtenteils Super. Probleme waren vereinzelte Durchmesser mit ein paar Zehntel mm zu wenig aber auch die Tatsache, dass das TFT-Display gar nicht auf der gesamten Glasfläche anzeigt sondern unterschiedliche Ränder aufzeigt. Also wurde der Ausschnitt für das TFT-Display und einige Durchmesser korrigiert. Auch die Lage des Bocks für das Radio-Modul wurde verändert (nach rechts geschoben), denn nur so passt der zugehörige Stecker zwischen die Taster im Deckel.</p> <p><strong><em>Lautsprecher</em></strong></p> <p>Bei einem ersten Test der Endstufe mit den kleinen Lautsprechern kam schnell Ernüchterung. <strong>Die sind viel zu leise!</strong> Auch wenn der Klang für die Größe beeindruckend ist, sind sie doch viel zu Leise für einen Senior. Da ich die Endstufe nicht wechseln möchte, musste ich bessere (größere) Lautsprecher suchen die zur Endstufe und in mein Gehäuse passen. Am Ende bin ich bei Pollin Fündig geworden und habe VISATON Lautsprecher mit 5W an 4Ω gekauft. Tatsächlich, diese haben deutlich mehr "Wumms" und klingen auch gut. Allerdings passen die so nicht in der geplante Gehäuse. Ich habe mich entschlossen, den Lautsprecher auf Grund der optimalen Lautstärke und Klang nach vorne gerichtet einzubauen. Das Gehäuse musste also wachsen:</p> <p> <img src="http://blog.inspirant.de/content/public/upload/wecker20257_0_o.png" alt="undefined" width="509" height="325" /></p> <p><em><strong>Zweiter Testdruck</strong></em></p> <p>Eine Abdeckung für den Lautsprecher werde ich bestimmt finden und verschiebe diese Frage in die Zukunft. Diesen Gehäuse-Entwurf hab ich dann auch gedruckt (über 12 Stunden) und zweimal schwarz lackiert (Acryl-Farbdose mit Matt-Schwarz):</p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl20251205063226638_0_o.jpg" alt="undefined" width="515" height="290" /></p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl20251205063234832_0_o.jpg" alt="undefined" width="515" height="290" /></p> <p>Man kann hinten links bei der Kabelklemme sehen, dass ich eine Vorrichtung zur Aufnahme eines Fotowiderstandes eingedruckt habe. Der Wecker soll seine Display-Helligkeit ja dem Umgebungslicht anpassen.</p> <p><em><strong>ESP32</strong></em></p> <p>Da das Gehäuse jetzt größtenteils fertig war, ging es an den Aufbau. Ich hatte noch nie zuvor ein ESP32-Projekt durchgeführt und hatte einiges an Lernkurve zu diesem speziellen Mikrocontroller. Das WLAN und Bluetooth werde ich vorerst nicht nutzen, aber ein ESP32 ist deutlich günstiger als der ursprünglich angedachte Teensy. Das sind die bisherigen Lernerfahrungen, ganz kurz zusammengefasst:</p> <ul> <li>Der ESP32 hat einen 3,3V Spannungswandler, der aber nur begrenzt Leistungsfähig ist. Eine echte Doku mit dem gesicherten Wert hab ich nicht gefunden, aber in verschiedenen Foren war immer wieder ein Maximum von 200mA genannt. Da das TFT so um den Dreh benötigt (bei Aktivität) wollte ich es nicht strapazieren und habe noch einen separaten 5V zu 3,3V Spannungsregler besorgt.</li> <li>Viele PINs sind nicht für alle Aufgaben geeignet. Das offizielle PIN-Sheet verschweigt die meisten davon und nur intensives Forschen hat mir dann offenbart, welche PINs tatsächlich nutzbar sind. Vermeiden sollte man 0,1, 3, 6, 7, 8, 9, 10, 11, 12, 15, 21 + 22 (i2c), 5+23+18+19 (SPI). Weiterhin sind 34, 35, 36 und 39 nur als Eingänge ohne eingebaute Pull-Up oder Pull-Down nutzbar. Das schränkt die Sache deutlich ein und verursacht unnötigen Aufwand und Fehler. Da war der Teensy deutlich besser!</li> <li>Der ESP32 ist nicht 5V-tolerant. Daher kann das Radio-Modul, welches 5V benötigt, nicht einfach per i2c-Bus direkt an den ESP32 angeschlossen werden. Es braucht einen Pegelwandler (Logic Level Shifter 5V~3.3V) am i2c. Das verkompliziert nochmal alles.</li> <li>Den ESP32 unbedingt auf einen Sockel oder Sockelleisten drücken. So kann man später viel leichter Probleme durchmessen! Siehe Bericht weiter unten.</li> </ul> <p><em><strong>Planung</strong></em></p> <p>Diese zwei Blätter hab ich mir in der Planungsphase als Anhaltspunkt gemacht. Sie sind aber inzwischen bereits teilweise überholt:</p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl20251208064716807_0_o.jpg" alt="undefined" width="646" height="424" /></p> <p>Ich hab dann die Lochraster-Platine benutzt um den ESP32, den Spannungswandler und einige Stiftleisten aufzubauen. Auch den Deckel hab ich mit den Tastern und Elementen verschraubt und verlötet (an Stiftleiste). Ich möchte alle Teile einfach an- und abstecken können, damit der Aufbau und das Testen etwas leichter fallen.</p> <p><em><strong>Programmierung</strong></em></p> <p>Dann ging es an die Programmierung, die zuerst einmal das TFT ansteuern soll. Ich hab mir eine menge Dinge zusammen-gegoogelt und benutze Visual Studio Code mit PlatformIO als Grundlage für das Projekt.</p> <p>Das größte Problem ist aktuell die benötigte große Schriftart für die Uhr-Anzeige. Ich finde viele Fonts für Arduino- und ESP32-Projekte, aber keiner ist Groß genug für mein Display. Am Ende entscheide ich mich dafür, die Ziffern 0-9 und den Doppelpunkt als 1 Bit Bitmaps zu nutzen. Dafür hab ich mir einen Lizenzfreien Monospaced Font auf fonts.google.com gesucht und die Zeichenfolge "0123456789:" als Test mit 180px ausgeben lassen. Davon dann einen Screenshot gemacht und mit <strong>GIMP</strong> das passende Schnitt-Raster gesucht (Bild -&gt; Raster konfigurieren). Dann mit diesen Zahlen das <strong>imagemagick</strong> "convert" tool verwendet um die Ziffern auszuschneiden (<em>convert Numbers_Fragment-Mono-200px.png -shave 12x0 -crop 123x149 +repage +adjoin Numbers-Mono-200px_%02d.png</em>). Am Ende hab ich die Bildchen dann mit einem Online-Tool wie <a href="https://javl.github.io/image2cpp/" target="_blank">image2cpp</a> in Arduino-Kompatiblen Code konvertiert.</p> <p>Als Grafik-Library für das TFT-Display habe ich mich für <a href="https://github.com/lovyan03/LovyanGFX" target="_blank">LovyanGFX</a> entschieden. Die originale Arduino-Lib war mit ihrer SPI-Implementation einfach viel zu langsam. Außerdem hat LovyanGFX noch weitere praktische Funktionen wie Text zentriert auszugeben oder mehr eingebaute Fonts. Ich nutzte das also um einen ersten Entwurf zur Oberfläche zu gestalten und einen ersten Loop für die Steuerung zu gestalten. Das Programmgerüst ist sogar schon recht brauchbar.</p> <p>Nach weiteren 10 Stunden dann die ersten Erfolge!</p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl20251205063127956_0_o.jpg" alt="undefined" width="516" height="369" /></p> <p><em><strong>Erster Rückschlag</strong></em></p> <p>Am folgenden Tag hab ich dann noch den Spannungsteiler aufgelötet und dann kam beim Anschluss ein herber Rückschlag:</p> <p>Die i2c Kommunikation war plötzlich total kaputt. Die RTC Uhr lieferte nicht mehr 0:00 und den 01.01.2000 sondern total verrückte Zahlen wie 165:233 und auch das Datum sprang wie Wild umher. Im Serial-Monitor wurde dann ein i2c Fehler 263 angezeigt, der irgend einen Timeout darstellt. Am Ende sprangen die Zahlen sogar dann, wenn die i2c Kabel wieder weg-gelötet hab. Ich war total frustriert. Und weil ich sowohl das RTC als auch den ESP32 direkt auf die Platine gelötet hab (ich Vollpfosten) konnte ich nur schwer bis gar nicht nach den Fehlern suchen.</p> <p>Ich hab mich nach mehreren Stunden Fehlersuche schweren Herzens dazu entschieden, einen zweiten ESP32 und ein neues RTC-Modul zu nutzen um alles neu aufzubauen. Zum Glück hab ich gleich jeweils zwei bestellt. Also wieder stundenlanges löten...</p> <p>Die Version 2 hat den ESP32 und auch das RTC-Modul jetzt steckbar und ich hab mit größter Sorgfalt gearbeitet. Ein erster Test hat dann sogar wieder funktioniert.</p> <p>Doch einen Tag später kommt plötzlich das i2c-Problem wieder! Das selbe Phänomen, der selbe Fehler im Serial-Monitor. <strong>WTF</strong></p> <p>Und dazu kommt noch, dass das TFT-Display manchmal weiß bleibt. Und manchmal startet der Serial-Monitor nicht und re-startet den ESP32 die ganze Zeit. Ich kann meinen Frust kaum in Worte fassen. Meine Teensy-Pojekte hatten solche Probleme selten.</p> <p>Ich untersuche alles, ziehe den ESP32 und messe alle Leitungen. Am späten Abend einen kleinen Erfolg. Ich finde einen Kurzschluss zwischen zwei PINs auf meiner Platine. Zwar kann ich den mit den Augen nicht sehen, aber definitiv messen. Also nehme ich Isopropanol und eine alte Zahnbürste und schrubbe meine Lötkontakte und zumindest die seltsamen Re-Boots und das weiße Display kann ich damit reparieren. Es ist aber auch ein Hinweis, dass es evtl. weitere PINs sind, die da eine Rolle spielen.</p> <p>Am Abend später stelle ich fest, dass der PIN 12, den ich für den Taster am Rotary-Encoder nutzen wollte, Probleme macht wenn man den mit Pull-Up-Widerstand programmiert. Er hat wohl eine Rolle beim Flashen und definiert die Flash-Spannung beim Re-Boot (oder so ähnlich). Der darf also auch nicht verwendet werden. Ich tausche den gegen den noch freien PIN 26 und dann geht es mit funktionierendem Serial-Monitor weiter. Langsam werden die nutzbaren PINs knapp. Fast 21 PINs sind nicht nutzbar oder nur für bestimmte Zwecke. Die offizielle Pin-Grafik erweckt den Eindruck, dass man mit vielen PINs basteln darf. Das stimmt aber nicht! <br /><strong>Tipp:</strong> Die KI von blackbox.ai hat mir bei der Suche nach Problem-Pins ganz gut weitergeholfen.</p> <h2>07.12.2025</h2> <p>Heute messe ich meine Platine nochmal durch um die restlichen Probleme zu identifizieren. Und tatsächlich finde ich noch weitere Fehler. Die 4K7 Terminator-Wiederstände am i2c-Bus hab ich versehentlich gegen 3,3V verbunden statt gegen GND. Bin beim abzählen im Raster wohl um eins verkommen. Autsch, das ist doof. Und ich finde noch ein kleines Masse-Kabel das ich von oben durch die Leiterplatine geführt hab welches sich per Pinzette raus-ziehen lässt. Auch das muss ich neu verlöten. Und siehe da, ich hab endlich das RTC am i2c-Bus und das TFT-Display wieder am funktionieren! Uff, das erleichtert ungemein.</p> <p>Auch die seltsame Fehlermeldung zum i2c-Bus ging weg, nachdem ich ein Downgrade der ESP32 Basis-Library auf die Version 5.0.0 durchgeführt hab. Darauf hat mich ein Forums-Post gebracht. Scheinbar ist neuer nicht besser...</p> <p>Also schließe ich den Pegelwandler an den i2c-Bus und klemme das Radio-Modul an. Dazu auch gleich den Verstärker und einen Lautsprecher. Man will das ja mal testen.</p> <p><em><strong>Zweiter Rückschlag</strong></em></p> <p>Leider <strong>rauscht</strong> der Lautsprecher laut und dazu kommt ein penetranter <strong>Pfeifton</strong>. Ich steppe alle FM-Frequenzen durch und trotz eingesteckter Antenne finde ich <strong>nur zwei Sender</strong> im Rauschen. Als Ursache für den Ton kann ich das TFT-Display ausmachen. Sobald ich es abstecke ist der Ton weg. Stecke ich es wieder an, pfeift es wieder. Ich beende den Abend mit der Erkenntnis, dass ich Kondensatoren (106, 104), Drosseln und Abschirmung brauche. Amazon-Bestellung ist getätigt. Ich bin aber skeptisch, ob das ausreichen wird :-( Und laut einer KI-Frage ist die Antenne mit ca 30cm zu kurz und sollte eher so 75cm betragen? Warum liefern die dann eine 30cm Antenne mit?</p> <h2>10.12.2025</h2> <p>Ich habe weitere Stunden mit der Suche nach einer Lösung für das Rausch- und Pfeifproblem verbracht. Auch Kondensatoren in der Spannungsversorgung des Radio-Moduls, und eine Drossel mit 47 mH Induktivität haben das Problem nicht gelöst. Scheinbar hab ich bei meinen Tests sogar das Radio-Modul zerstört, denn seit neuestem liefert es nur noch Rauschen und findet keinerlei Sender mehr. Es reagiert und ich bekomme Callbacks etc, aber alle Frequenzen haben jetzt eine Signal-Strength von 0. I2c läuft demnach noch, aber das Radio-Modul selbst irgendwie nicht mehr.</p> <p>Nach aktuellem Stand habe ich jetzt folgende Möglichkeiten:</p> <ol> <li>Ein neues Radio-Modul kaufen und das rauschen weiter untersuchen.</li> <li>Ein anderes Radio-Modul kaufen, welches "angeblich" störungsresistenter sei.</li> <li>Ein separates Radio-Modul kaufen, welches nur Taster für Sendersuchlauf und laut/leise hat. Die Taster dann über den ESP32 steuern.</li> <li>Statt Radio nur piepen oder pfeifen als Weckton einbauen.</li> </ol> <p>Ich hab auch mal überlegt, ob ich das Radio-Modul und die Endstufe über Akkus (4 x 1,2V) betreiben soll um die von den Störquellen (SPI, I2C, Microcontroller) abzuklemmen. Aber eine gemeinsame Masse wäre wegen i2c dennoch nötig, laden müsste ich über die selbe Spannungsquelle und ich bräuchte eine gute Ladelogik damit das klappt. Ich hab da Zweifel...</p> <p>Allerdings habe ich dann Zeit gefunden am Interface zu arbeiten und aktuell schaut es so aus:</p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl20251210171145892_0_o.jpg" alt="undefined" width="518" height="291" /></p> <p>Man sieht links über dem ESP32 den Stecker für das Radio-Modul (aktuell abgesteckt) und unter dem RTC-Modul den braunen Stecker für die Stromversorgung der Endstufe. Beide bekommen 5V und das Radio-Modul läuft noch durch den level Shifter oben rechts auf der Platine. Ganz oben rechts im Bild sieht man den Lichtwiederstand, der aktuell die Display-Helligkeit steuert. Auch das läuft bereits (geglätteter Durchschnitt der letzten 10 Messungen alle 500ms).</p> <p>Das Display zeigt aktuell die Uhrzeit und unten den aktiven Alarm (Schalter auf dem Deckel ist aktiv).</p> <p>Inzwischen habe ich auch ein Menü-System programmiert mit dem man bereits jetzt per Drehencoder die Uhrzeit und das Datum setzen kann. Das setzt dann die Zeit und das Datum auf der RTC. Die Uhrzeit übersteht jetzt also auch Stromverlust.</p> <h2>23.12.2025</h2> <p>Ich habe mich entschieden ein neues Radio-Modul zu kaufen und das funktioniert tatsächlich wieder. Keine Ahnung woran das erste Modul kaputt gegangen ist? Soweit funktioniert jetzt alles, bis auf die Störgeräusche im Radio. Die Programmierung habe ich fertig gestellt. Es lässt sich jetzt auch der Alarm einfach einstellen und er funktioniert auch. Das einzige was jetzt noch fehlt sind Kleinigkeiten. Ich möchte noch einen Menüpunkt zum einstellen der Dimmer-Funktion einbauen. Und wenn der Alarm losgeht, sollte das Display noch heller werden. Aktuell wird es nur kurz heller und dann wieder Dunkler. Da muss ich noch was machen.</p> <p style="text-align: center;"><em><strong>Aber ich kann es so nicht verschenken. Die Mission ist also gescheitert :-(</strong> </em></p> <p>Das Radio surrt und fiept inakzeptabel und ich kann nicht herausfinden, woher es überhaupt kommt. Ist es auf der Spannungsversorgung? Oder "Over the Air"? Oder liegt das Störsignal auf der i2c-Leitung? Da muss ich noch viel Tests machen. Da ich kein Oszilloskop besitze, muss ich viele Tests "auf die harte Tour" machen. Also Leitungen abklemmen, zweites Netzteil parallel nutzen etc. Eventuell meld eich mich auch mal in einem Forum. Eventuell haben die Experten da ja gute Hilfe für mich?</p> <p>Dazu sollte ich mit dem Radio auch die Endstufe ein- und ausschalten. Auch wenn das Radio-Modul auf Standby steht, ist ein leises surren zu hören weil die Endstufe ja immer aktiv ist. Die hat aber Pins für MUTE und die sollte ich wohl nutzen um bei ausgeschaltetem Radio auch die Endstufe auszuschalten.</p> <p>Es gibt also noch viel zu tun. Ich versuche den Wecker bis im April funktionsfähig zu haben. Denn im Mai hat meine Mutter dann Geburtstag. Das wäre ja eine gute Gelegenheit :-)</p> <p>Anbei ein paar Bilder vom aktuellen Stand:</p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl202512271019287332_0_o.jpg" alt="undefined" width="519" height="317" /></p> <p><img src="http://blog.inspirant.de/content/public/upload/pxl202512271016153682_0_o.jpg" alt="undefined" width="517" height="317" /></p> <p><img src="http://blog.inspirant.de/content/public/upload/schaltplanv1_0_o.png" alt="undefined" width="821" height="519" /></p> http://blog.inspirant.de/index.php?controller=post&amp;action=view&amp;id_post=59 2025-11-09T19:01:57+01:00 <p><img class="nb-align-right" style="margin-right: 10px; box-shadow: 3px 3px 10px 1px rgba(0,0,0,0.75); border-radius: 10px;" src="http://blog.inspirant.de/content/public/upload/stoprating_0_o.jpg" alt="undefined" width="180" height="180" />Ich habe vor einigen Jahren auf Google Maps ein Restaurant in Donaueschingen mit nur drei von fünf Sternen bewertet. Das war der Text der Rezension:</p> <p style="padding-left: 30px;"><strong><em><img style="border: 1px solid #333333;" src="http://blog.inspirant.de/content/public/upload/rezensiondoublesixdiner_0_o.png" alt="undefined" width="358" height="285" /></em></strong></p> <p>Am 20. Juni 2025 habe ich dann diese E-Mail von Google erhalten:</p> <p style="padding-left: 30px;"><em>Sehr geehrte Damen und Herren,</em></p> <p style="padding-left: 30px;"><em>Google hat eine Beschwerde über die nachfolgende(n) URL(s) aus den folgenden rechtlichen Gründen erhalten: Diffamierung</em></p> <p style="padding-left: 30px;"><em>Nach einer Überprüfung informieren wir Sie hiermit darüber, dass wir folgende Entscheidungen getroffen haben:</em></p> <p style="padding-left: 30px;"><em>Betroffene Inhalte: Beitrag</em></p> <p style="padding-left: 30px;"><em>Rechtsprechung: Deutschland</em></p> <p style="padding-left: 30px;"><em>Verstößt anscheinend gegen: <strong>Diffamierung</strong></em></p> <p style="padding-left: 30px;"><em>Folge: Zugriffsbeschränkung</em></p> <p>Das bedeutet, das Restaurant in Donaueschingen hat meine Rezension löschen lassen weil sie angeblich Diffamierend sei. Das ist sie ganz offensichtlich nicht (<a href="https://de.wikipedia.org/wiki/Diffamierung" target="_blank">siehe Wikipedia zur Begriffsdefinition</a>) und ich habe das am 23. Juni 2025 in meiner Antwort so begründet:</p> <p style="padding-left: 30px;"><em>Ich stehe dazu. Als ich die Bewertung abgegeben habe, war das der genaue Sachverhalt zu diesem Zeitpunkt. Wenn Sie unangenehme Bewertungen sowieso entfernen, dann können Sie das mit den Bewertungen auch gleich sein lassen.</em></p> <p style="padding-left: 30px;"><em>Ihre Ablehnung meiner Bewertung stellt meine Integrität in Frage! Sie, oder das bewertete Unternehmen, unterstellen mir eine Fehlangabe oder sogar Verleumdung. Das ist unverschämt! Sie(!) müssten das begründen, nicht ich! Ich habe sogar Zeugen dafür, dass das der Richtigkeit entspricht!</em></p> <p>Daraufhin bekam ich dann von Google am 25. Juni 2025 diese Auskunft:</p> <p style="padding-left: 30px;"><em>Sie können sich auch an eine zertifizierte außergerichtliche Schlichtungsstelle oder an ein Gericht wenden. Hier finden Sie weitere Informationen zu den verfügbaren Optionen. Wenn Sie rechtliche Fragen haben oder die anderen Rechtsmittel prüfen möchten, die Sie möglicherweise nutzen können, sollten Sie sich an Ihren eigenen Anwalt wenden.</em></p> <h3 style="text-align: center;">Ich müsste mir einen Anwalt suchen und potentiell Geld investieren, um die korrekte und nicht diffamierende Bewertung sichtbar zu halten!</h3> <p>Das werde ich natürlich keinesfalls tun, denn ich hab ja noch was anderes zu tun. Und genau das ist der Grund, warum das ganze System der Bewertungen keinen Sinn mehr macht!</p> <h3 style="text-align: center;">Mit dieser Taktik bleiben dem Unternehmen nur die besten Bewertungen erhalten.<br /> Alle kritischen Stimmen werden getilgt.<br />Dadurch verliert das gesamte System der Rezensionen seine Daseinsberechtigung!</h3> <p>Ich kann also nur raten sich die Zeit für Bewertungen bei Google zu sparen. Macht was besseres mit Eurer Freizeit.</p> <h3 style="text-align: center;">Traut den Bewertungen nicht. Sie haben keine Aussagekraft mehr.</h3> <p>Im schlimmsten Fall werdet ihr vorsätzlich getäuscht!</p> http://blog.inspirant.de/index.php?controller=post&amp;action=view&amp;id_post=57 2025-06-25T11:18:07+02:00