siyman.de | blogging und GNU/*buntu

Tatsächlich greift die lokale kaco-App nicht via Modbus sondern via http die vorhandenen Daten ab. Heraus findet man das, indem man die angegeben URL via Webbrowser checkt, und zwar hinter dem Port 8484, also bspw. über 192.168.0.100:8484.

Doch eine 440-Seite kommt zum Vorschein und man steht in der Sackgasse.

Doch halt: l4x hat auf Github seine Versuche von vor acht Monaten dokumentiert und zeigt, dass in einer wunderschön übersichtlichen JSON-formatierten Ausgabe alles steht, was man so braucht.

Für mich siehts dann so aus: Zugriff über meine interne IP mit meiner entsprechenden Seriennummer über http://192.168.XXX.XXX:8484/getdevdata.cgi?device=2&sn=8.0NX3120XXXXX führt zu meiner Datenausgabe inklusive Zeitstempel und dem für mich sehr wichtigen pac-Wert – der aktuellen Leistungsbeschreibung der PV-Anlage.

Ab jetzt versuche ich mal über openHAB Steckdosen abhängig von der vorhandenen Leistung anzusprechen =)

Da will man seit jeher nicht die Kontakte an Amazon schicken und wenn es dann doch Mal soweit ist, klappt es nicht …

Diverse Reddit und Amazon Forums Threads haben mich nicht weitergebracht. Was geholfen hat war die Navigation auf amazon.de zu “mein Konto” -> meine öffentlichen Profile und dort das Löschen aller Produkte mit Ausnahme des Hauptprofils.

Danach musste ich außerdem noch die Alexa app neu installieren, ab hier ging es ohne Schwierigkeiten.

nervig! Insbesondere weil ich nach dreißig Minuten Suche genau diese Lösung nirgends finden konnte. Hoffentlich hilft es jemand anderem.

Eine Kollegin hat ihr Macbook Pro 7,1 seit Januar nicht mehr in Benutzung, da nach einem Update und anschließender Installation von Paragon-Software das Gerät nicht mehr in die Mehrbenutzeroberfläche kommt.
Safe Mode? Fehlanzeige. NVRAM rücksetzen? Ohne Erfolg. Rescue Mode? Die Festplatte ist top in Schuss, geändert hat sich nichts. Single User Mode? Ich komme ins System und erhalte keine Fehlermeldung.

Was also tun? Ich vermutete eine Kernel-Extension, die beim Hochfahren stört. Deshalb bin ich über diesen Beitrag gestolpert und konnte tatsächlich mit dem Entfernen aus dem Startup-Prozess wieder in die GUI booten. Geholfen hat mir seine Schritt-für-Schritt-Anleitung, die aus dem Terminal heraus im Rescue Mode (Einschalttaste drücken, loslassen und anschließend sehr schnell Shift+R gedrückt halten) durchgeführt wird:

mount -rw /
cd /Volumes/Macintosh\ HD/Library/Extensions/
mkdir Unsupported
mv *.kext Unsupported
reboot

https://www.justinsilver.com/technology/os-x-el-capitan-10-11-1-hanging-on-boot-fixed/

Hiernach ist es noch Aufgabe, die entsprechende Extension zu finden, die im Wege stand – einfaches Trial and Error, also das nacheinander zurückspielen der einzelnen Dateien aus dem Unsupported-Ordner, ist hier sehr hilfreich.

Und Paragons NTFS-Tools kommen ihr hoffentlich nicht mehr ins System 😉

Wirklich, es ist doch zum Haare ausreißen. Modernste PCs mit Linux und nVidia-Grafikkarten schaffen es nicht zuverlässig aus dem Standby (Suspend to Disk = Hibernate bzw. Suspend to RAM = Standby) aufzuwachen. Das nervt!

Jüngst bin ich auf folgenden Eintrag bei Github gestoßen. Bisher kann ich das System tatsächlich schlafen legen und wieder aufwecken, ohne dass mein Monitor schlicht schwarz bleibt. Und dabei habe ich noch nicht einmal die im Thread hauptsächlich verlinkte Hilfe in Anspruch genommen, sondern einen Hinweis jenseits der Massen:

ein einfaches “exit 0” am Ende von /usr/bin/nvidia-sleep.sh hinzugefügt hat meine seit Jahren schwelenden Suspendsorgen schlicht beseitigt.

Dass da nicht schon vorher jemand drauf gekommen ist Oo

Ich bin ja überzeugter netcup.de-Nutzer. Allerdings war es mir bisher nicht möglich, ein automatisiertes Backup auf den Fritzbox-eigenen FTP-Server vom netcup-eigenen Interface herzustellen. Zwar konnte der Speicher erfolgreich eingerichtet werden und alle Zugangsdaten, Adressen etc. haben gestimmt, doch hat das Backup stets mit der gleichen Fehlermeldung gestreikt, dass ein Schreiben nicht möglich gewesen sei.

Hier gab es dann die Erleuchtung, dass ein einfaches Anlegen einer Datei in demjenigen Ordner, der von der Fritzbox selbst für den FTP-Zugriff erstellt worden ist, ausreicht, um das Problem zu lösen. Und siehe da – es klappt.

Schön, denn jetzt kann mein Webspace abrauchen und die Fritzbox hält für mich ein aktuelles Backup bereit, was mir in Zukunft im Falle der Fälle einiges an Mühe erspart. Und wenn das Haus abbrennen sollte, dann habe ich eh gänzlich andere Probleme, sodass erweiterte Backupstrategien hierfür nicht notwendig sind 😉

Mal schauen was der Fritz!OS-Support auf meine Supportanfrage hin anstellt. Ich vermute ein Problem bei der Rechtevergabe beim Ordneranlegen, welches hoffentlich in wenigen Zeilen Code gelöst werden kann.