Archiv ‘IT’

Sonntag, 9. Oktober 2022

speedtest-cli funktioniert nur mehr sporadisch

Meine stündlichen Ookla Speedtests auf verschiedenen von mir verwalteten Servern funktionierten in den letzten Wochen nur noch sporadisch. Irgendwann einmal wurde es mir zu viel, und ich beschäftigte mich genauer mit der Sache.

Folgende Fehlermeldung wurde ausgespuckt, wenn der Cron-Job fehl schlug (ich hatte Glück, dass ich gerade einen solchen Moment erwischt habe):

$ /usr/local/bin/isp/speedtest-cli --simple
Cannot retrieve speedtest configuration
ERROR: HTTP Error 403: Forbidden

Nach etwas Googlen dann die Lösung in Speedtest-cli only works with –secure via Speedtest-cli error:

$ /usr/local/bin/isp/speedtest-cli --simple --secure

Seit dem ich dieses Argument mitgebe, laufen die Cron-Jobs wieder anstandslos durch.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 5. Oktober 2022

Das neueste duplicity unter macOS installieren und zum Laufen bringen

Seit einer Woche funktioniert das Backup meines Mac mini auf Backblaze mit duplicity nicht mehr.

Das erste Problem war beim manuellen Aufruf des Backup-Scripts rasch erkannt: Letzte Woche scheint es mit den internen DHCP- und DNS-Servern ein Problem gegeben zu haben, weshalb der Mac mini nicht seinen ordentlichen DNS-Namen erhielt. duplicity verweigerte deshalb das Backup, da es davon ausgehen musste, dass jemand versucht, zwei Systeme auf dieselbe Destination zu sichern. Die Kommandozeilenoption --allow-source-mismatch löste dieses Problem.

Nichtdestotrotz konnte ich das Backup-Script nicht ausführen, weil das Python-Modul duplicity nicht (mehr) gefunden werden konnte. Da hatten wohl die Updates der letzten Tage irgendwas zerschossen.

Auf meinem System habe ich MacPorts installiert und verwende deren Python-Interpreter, um Python-Scripts laufen zu lassen. duplicity habe ich auch als MacPorts-Paket installiert. Doch ich konnte mich erinnern, dass ich nicht dieses duplicity verwende, sondern jeweils den neuesten Quellcode von launchpad.net herunterlade.

Nach viel Pröbeln dann die Lösung (ich ging auf Nummer sicher und installierte Duplicity sowie alle benötigten Python-Pakete für alle drei vorhandenen Python-Versionen):

cd ~/Downloads/duplicity-1.0.1

sudo /opt/local/bin/python3.7 setup.py install --librsync-dir=/opt/local
sudo /opt/local/bin/python3.8 setup.py install --librsync-dir=/opt/local
sudo /opt/local/bin/python3.9 setup.py install --librsync-dir=/opt/local

sudo /opt/local/bin/python3.7 -m pip install -r requirements.txt
sudo /opt/local/bin/python3.8 -m pip install -r requirements.txt
sudo /opt/local/bin/python3.9 -m pip install -r requirements.txt

sudo /opt/local/bin/python3.7 -m pip install b2sdk
sudo /opt/local/bin/python3.8 -m pip install b2sdk
sudo /opt/local/bin/python3.9 -m pip install b2sdk

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 5. Oktober 2022

Credit Suisse Direct: „Das Datum kann kein Feiertag sein“

Als Nachteule kommt es vor, dass ich manchmal zu später Abendstunde (eher: früher Morgenstunde) mit Credit Suisse Direct, dem Online-Banking unserer Hausbank, eine Überweisung aufsetzen möchte.

Vor einigen Tagen traute ich meinen Augen nicht:

Der Freitag, 30. September 2022, ist ein ganz normaler Arbeitstag. Was schwafelt CS da?

Am Morgen, zu Beginn der Bürozeiten, versuchte ich die Überweisung erneut aufzusetzen — dann klappte es problemlos.

Vermutungen: Entweder wurde ein Entwickler zu Arbeitsbeginn auf das Problem aufmerksam und hat es umgehend gelöst, oder aber es ist nicht möglich, in den frühen Morgenstunden eine Überweisung aufzusetzen (wieso?), es wird dem Kunden aber eine falsche Fehlermeldung angezeigt (Codierfehler?).

Tags: , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen

Donnerstag, 22. September 2022

ddclient: WARNING: found neither ipv4 nor ipv6 address

Seit dem 19. September meldet ein von mir verwalteter Router sporadisch folgendes Problem bei der Aktualisierung der IP einer Dynamischen DNS-Adresse (mein DynDNS Anbieter: no-ip.com; sunrise upc ist der ISP, an welchem der Router hängt):

Sep 19 14:00:13 ROUTER ddclient[2733]: WARNING:  found neither ipv4 nor ipv6 address

Bis jetzt konnte ich das Problem nicht lösen. Mittlerweile habe ich den DynDNS-Service auf dem EdgeRouter ER-4 deaktiviert, und führe stattdessen auf einem Debian GNU/Linux-System im dahinterliegenden LAN ddclient aus.

Leider hat das auch nicht komplett geholfen, obwohl die Fehlermeldungen weniger wurden:

Sep 22 12:31:56 SERVER ddclient[3248354]: WARNING:  found neither ipv4 nor ipv6 address

Als ich gestern das Problem analysiert habe, fiel mir Folgendes auf:

$ host checkip.dyndns.org
checkip.dyndns.org is an alias for checkip.dyndns.com.
checkip.dyndns.com has address 132.226.247.73
checkip.dyndns.com has address 193.122.130.0
checkip.dyndns.com has address 158.101.44.242
checkip.dyndns.com has address 132.226.8.169
checkip.dyndns.com has address 193.122.6.168

$ wget "http://checkip.dyndns.org/"
--2022-09-22 01:42:06--  http://checkip.dyndns.org/
Resolving checkip.dyndns.org (checkip.dyndns.org)... 132.226.247.73, 132.226.8.169, 193.122.130.0, ...
Connecting to checkip.dyndns.org (checkip.dyndns.org)|132.226.247.73|:80... connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2022-09-22 01:42:09 ERROR 502: Bad Gateway.

$ wget "http://checkip.dyndns.org/"
--2022-09-22 01:42:48--  http://checkip.dyndns.org/
Resolving checkip.dyndns.org (checkip.dyndns.org)... 132.226.8.169, 193.122.130.0, 158.101.44.242, ...
Connecting to checkip.dyndns.org (checkip.dyndns.org)|132.226.8.169|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 105 [text/html]
Saving to: ‘index.html’

index.html              100%[===============================>]     105  --.-KB/s    in 0s      

2022-09-22 01:42:50 (8.82 MB/s) - ‘index.html’ saved [105/105]

Es scheint, als würde entweder eine der 5 IPs hinter checkip.dyndns.org streiken, oder aber der ERROR 502-Fehler tritt unregelmässig bei allen IPs auf.

Ob das aber wirklich das Problem hinter den Fehlermeldungen ist, kann ich derzeit nicht sagen.

Tags: , , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 9. Juni 2022

verkaufen.ch: „Neu und ungeöffnet“

Ich habe mir am Dienstag über verkaufen.ch (Recommerce AG) ein iPhone 13 mini 512GB Mitternacht gekauft (890 CHF anstelle 1010 CHF Neupreis).

Auf der Produkteseite wurde angegeben „Neu und ungeöffnet“ (auf der Rechnung: „Originalverpackt und versiegelt“).

Da ich bei einem solchen Preis für ein faktisches Neugerät irgendeinen Haken erwartete, schaute ich beim Auspacken genau hin.

Das iPhone war nicht in Plastic verschweisst. Schon mal wie erwartet.

Besonderes Augenmerk richtete ich auf die zwei Laschen, welche man von Hand horizontal abziehen muss:

Fazit: Ich glaube, dass „ungeöffnet“ schon etwas geflunkert ist. Stichwort Japanmesser.

Tags: , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 30. Mai 2022

Turris Omnia auf einen anderen Branch wechseln

Je nachdem, auf welchen Branch man wechseln will, wählt man die entsprechende Zeile aus:

# switch-branch hbs # Stable, aka Snails
# switch-branch hbt # Testing, aka Turtle
# switch-branch hbl # Latest, aka Lions
# switch-branch crashlab

Tags: , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Montag, 30. Mai 2022

Umstieg von dump1090 auf tar1090: Wo ist das Flugzeug-JSON?

Vor einigen Monaten habe ich meinen FlightRadar24 Raspberry Pi softwaretechnisch so umgebaut, dass er seine Daten auch mit ADS-B Exchange teilt. Hierzu wurde dump1090 mit tar1090 ersetzt.

Mit Cacti zeichne ich die Anzahl Messages pro Minute sowie die aktuell getrackten Flugzeuge auf. Leider funktionierte nach der Umstellung die Abfrage der JSON-Datei nicht mehr, welche bis anhin unter http://1.2.3.4/dump1090/data/aircraft.json abgerufen werden konnte.

Nach etwas Recherche dann die Erlösung: Die URL lautet neu nun http://1.2.3.4/tar1090/data/aircraft.json. Das Python-Script schwupp-di-wupp angepasst, und nun zeichnet Cacti wieder einen wunderschönen Graphen:

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 22. Mai 2022

Xiaomi Aqara Temperatursensoren gehen immer wieder verloren

Mein Haus ist voll mit kleinen quadratischen Xiaomi Aqara Temperatursensoren (Produktnummer: WSDCGQ11LM), die man auf Ali Express für etwa 15 Franken pro Stück kauft. Die Sensoren werden mit einer Knopfbatterie ausgestattet, die monatelang hält.

Etwa die Hälfte davon ist mit einem Aqara Hub verbunden, die andere Hälfte habe ich inzwischen auf einen Deconz Conbee II USB-Stick migriert, welcher an einem Linux-Server hängt.

Die Sensoren kommunizieren mit dem ZigBee-Standard.

Leider kommt es alle paar Wochen wieder vor, dass einer oder mehrere der am weitesten vom Hub resp. dem Linux-Server entfernten Sensoren „verloren“ gehen, das heisst plötzlich aufhören, periodisch Messwerte zu senden.

Da dies immer wieder passiert, habe ich ein Script geschrieben, dass mich alarmiert, wenn die letzte Messwertmeldung eines Sensor mehrere Stunden zurückliegt.

Ist dies der Fall, muss ich den Sensor neu mit deCONZ verbinden, indem ich den Reset-Knopf am Sensor mit einem japanischen Ess-Stäbchen mehrere Sekunden lang gedrückt halte, bis die LED des Sensors mehrfach blinkt. Danach noch ein kurzer Tipper auf den Reset-Knopf, und dann ist der Sensor wieder mit deCONZ gepaart.

Nichtsdestotrotz: Das nervt. Gewaltig.

Das Problem ist im Netz bekannt:

The Xiaomi/Aqara sensors use a non-standard zigbee protocol, where the time between check-ins is longer than most. For a lot of zigbee repeaters, the time is just longer than the threshold, so the devices get dropped from the network when they don’t check in “on time”. […] Xiaomi/Aqara devices enter “test mode” for the first couple hours after pairing, where they send data every 3-5 seconds rather than on events or at regular ~1hr check ins. I am in the habit of pairing any battery operated sensors in close proximity to the hub, and leaving them very close to the hub for a few hours after pairing to ensure proper communication and connection after the test mode ends.

My guess is that your sensor is connected to a repeater that doesn’t like the long time between check-ins, and is happy with the sensor while it’s in test mode, but drops it from the network after that.

Quelle: Xiaomi aqara loosing connection every couple hrs

Philips Hue und IKEA Tradfri Repeater helfen nichts

Spannend dabei ist, dass ich in jedem Zimmer mindestens eine Philips Hue Deckenlampe montiert habe, welche — da kabelgebunden — als ZigBee-Repeater funktionieren. Zudem habe ich in der Stube, welche luftlinienmässig am weitesten vom DeCONZ-Server entfernt ist, auch noch einen IKEA Tradfri ZigBee-Repeater installiert. Leider bringen diese Repeater in meinem Fall offenbar rein gar nichts.

WLAN-Interferenzen?

Eine mögliche Lösung könnte sein, den WLAN-Kanal zu ändern: FAQ: What WiFi Channel is least likely to interfere with SmartThings? Das möchte ich aber nicht ausprobieren, da ich mein Ubiquiti UniFi-WLAN-Netzwerk solche Parameter selber regeln lasse, und bis jetzt eine äusserst gute WLAN-Qualität hatte.

Neue Hardware?

Mittlerweile bin ich soweit, Xiaomi Aqara den Rücken zu kehren und Sensoren einer anderen Marke zu kaufen, falls sich diese in etwa im selben Preisrahmen bewegen, und stabiler sind.

Leider listet die offizielle Kompatibilitäs-Seite keine Alternativen für reine Temperatur- und Feuchtigkeitssensoren.

Eine inoffizielle Liste ist deutlich grösser.

Bei einer Google-Suche wurde mir der SONOFF WLAN-Luftfeuchte- und Temperatursensor SNZB-02 ZigBee für 12.45 CHF (Brack) präsentiert. Nach anfänglichen Problemen scheinen diese Sensoren gemäss Foren-Beiträgen nun mit deCONZ zu funktionieren. Ich werde mir mal ein Testprodukt bestellen.

Andere potentielle Kandidaten, welche ich auf die Schnelle nicht in Schweizer Shops gefunden habe:

  • Develco Temperature and Humidity Sensor HMSZB-110
  • Rehent Temperature and Humidity Sensor RH-ZTH1
  • Zemismart Temperature and Humidity Sensor ZXZTH

Nachtrag

Gestern, am 4. Januar 2023, sind auf einen Schlag drei Sonoff SNZB-02 Sensoren, welche ich mittlerweile im Haushalt betreibe, fast gleichzeitig stumm gegangen. Die Sensoren waren seit dem 7. Oktober 2022 aktiv und haben täglich zwischen 500 und 600 Mal Werte gesendet. Ein anderer Sonoff Sensor funkt munter weiter. Im DeCONZ Phoscon-Tool werden die Sensoren als offline angezeigt.

Ich habe die Sensoren ins Büro (in die Nähe des Conbee Sticks) gebracht und danach mit DeCONZ Phoscon neu gepaired: DeCONZ Phoscon in den Pairing-Modus schalten (Add new sensor > Other), Druck auf den Reset-Button, bis die rote LED dreimal durch das Gehäuse blinkt, Button loslassen, Sensor auf Tisch ablegen, und 10-15 Sekunden später färbt sich der Modaldialog in DeCONZ Phoscon grün. Ich werde die Sensoren nun über Nacht auf dem Schreibtisch belassen, und morgen — sofern sie immer noch Kontakt haben — wieder an ihren angestammten Ort hinterlegen.

Tags: , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen

Sonntag, 15. Mai 2022

Brandneue Hue Dimmer Switches mit der Basisstation verbinden

Heute habe ich endlich die Hue Dimmer Switches (zu Deutsch: Philips Hue Dimmschalter) mit der Philips Hue Basisstation (Bridge) gekoppelt, welche bei unseren Philips Hue Aurelle Deckenlampen mitgeliefert wurden.

Bei keiner der Fernbedienungen funktionierte die Registration der Schalter nach Entfernen des Plastic-Streifens aus dem Batteriefach auf Anhieb. Ich hatte die Fernbedienung dabei jeweils in ca. 50-75 Zentimeter Entfernung von der Basisstation positioniert.

Unglaublich, was Philips sich hier 2022 mit einem eigentlich reifen Produkt leistet!

Stattdessen musste ich jedes mal eine Büroklammer um die 10-15 Sekunden in das Loch auf der Rückseite der Fernbedienung einführen und gedrückt halten, bis die LED der Fernbedienung begann, abwechselnd Regenbogenfarben (Grün, Orange, Rot) anzuzeigen.

Erst dann konnte ich in der App beim „Haben Sie den Plastic-Streifen entfernt?“ auf Weiter klicken. Auch betätigte ich in einigen Fällen eine Taste, als die App die Fernbedienung suchte, und ich habe das Gefühl, dass dies die Entdeckung beschleunigte.

Anschliessend funktionierte alles wie am Schnürchen.

Tags: , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Freitag, 22. April 2022

OmniCharge: „Download APP to Unlock“

Lösung: Siehe ganz unten im Nachtrag

Meine OmniCharge Omni 20+ meldet (wieder einmal) Download APP to Unlock.

Wie ich das genau geschafft habe, weiss ich nicht auf sicher — aber das Problem hatte ich bereits vor zwei Jahren im April 2020 einmal.

Damals hatte ich die Batterie probehalber an einem 10W Solarpanel betrieben, und einen Verbraucher angeschlossen.

Irgendwann kam eine Schlechtwetterperiode, das Solarpanel lieferte kaum mehr Strom, und der Verbraucher leerte die Batterie offenbar bis auf den letzten Tropfen Saft.

Meine Vermutung: Ohne Strom passiert in der Batterie-Firmware irgendwas, und wenn die Batterie wieder Strom hat, denkt sie, dass es sich um ein Leihgerät handelt.

OmniCharge bietet nämlich mit der Omni Power-Station eine Art Ausleihstation mit gerüsteten Batterien an, und Personen können von dort mittels ihres Smartphones und eines Omnicharge-Accounts Batterien ausleihen.

Der Support konnte mir seinerzeit nicht weiterhelfen und löste einen RMA-Auftrag aus. Offenbar hat der Austausch nichts gebracht.

Leider ist es heute (April 2022) nun so, dass die Web-Site omnicharge.co/app nur noch anzeigt: „This page is in the process of being updated, please check back later.“

Folgende App sollte man sich auf das iPhone herunterladen: Omnicharge

Ich hatte von den Handständen vom April 2020 noch ein Konto (inkl. hinterlegter Kreditkarte, aber seit einem Jahr abgelaufen) und konnte mich in die App einloggen. Ich kann mich aber vage daran erinnern, dass die Erstellung des Kontos selbst ungeheur kompliziert war und ich meine Web Entwickler-Kenntnisse und Debug-Werkzeuge anwenden musste. Fragt mich aber bitte nicht mehr, was genau ich damals gemacht habe.

Einmal eingeloggt habe ich folgendes durchgespielt, was die Batterie tatsächlich entsperrt hat (leider nur bis zum … Montag, 20. April … hä?):

Danach war die Batterie entsperrt:

Obwohl ich froh bin, dass die Batterie entsperrt ist — mich nervt solches Gefrickel mit Ware, die ich legal erstanden habe und von der ich erwarte, dass sie einfach funktioniert.

Nachtrag

Dieses Mal habe ich einen kompetenteren Support-Mitarbeiter erwischt. Mit folgender Anleitung habe ich die Batterie entsperren können:

  1. Press and hold the power button until the Omnicharge logo shows up, then,
  2. While still holding a power button, press the AC, then the USB button in turn for 4 times.
  3. Release the power button.
  4. Select SYSTEM MODE from the menu, check UNLOCKED and exit the menus.
  5. Power on Omnicharge, and it should be unlocked.

Durch das Menu zirkelt man mit der AC-Taste (nach oben) und der USB-Taste (nach unten). Einen Menu-Eintrag wählt man mit der Power-Taste aus.

Meine Batterie war im Omnie BLE (3) (Bluetooth Low Energy?) Modus:

Ich habe auf Unlocked (6) gewechselt, und schwupp, die Batterie war entsperrt.

Danke, Dusan!

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen