Montag, 30. Mai 2022
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: Branch, Turris, Turris Omnia, Turris OS
Labels: IT
Montag, 30. Mai 2022
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: ADS-B, ADS-B Exchange, dump1090, Flightradar24, fr24, fr24feed, Raspberry Pi, tar1090
Labels: IT
Sonntag, 22. Mai 2022
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
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.
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.
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:
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: Aqara, ConBee II, deCONZ, Phoscon, Temperatur, Temperatursensor, Xiaomi
Labels: IT
Sonntag, 15. Mai 2022
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: Basisstation, Dimmer, Dimmer Switch, Hue, Hue Dimmer Switch, Pairing, Philips, Philips Hue, Schalter, Switch, Verbinden
Labels: IT
Freitag, 22. April 2022
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.
Dieses Mal habe ich einen kompetenteren Support-Mitarbeiter erwischt. Mit folgender Anleitung habe ich die Batterie entsperren können:
- Press and hold the power button until the Omnicharge logo shows up, then,
- While still holding a power button, press the AC, then the USB button in turn for 4 times.
- Release the power button.
- Select SYSTEM MODE from the menu, check UNLOCKED and exit the menus.
- 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: Omni, Omnicharge, Unlock
Labels: IT
Sonntag, 3. April 2022
Kürzlich spammte ein via Cron alle fünf Minuten laufendes imapfilter-Script meine INBOX mit der folgenden Meldung voll:
imapfilter: IMAP (3): 1014 BAD Could not parse command
Wie debuggen? Gar nicht so kompliziert. Man führt das „Rezept“ einfach manuell auf der Kommandozeile aus.
$ imapfilter -l /tmp/log.txt -d /tmp/debug.txt -c recipe.lua
Anschliessend schaut man sich debug.txt an, sucht nach der Nummer des Befehls (hier: 1014) und schaut einige Zeilen davor an, um den Filterbefehl zu isolieren, der zur Fehlermeldung geführt hat. Das kann einige Zeilen vorher gewesen sein, weil imapfilter im Debug-Modus jede Aktion gegen den Mailserver aufführt. Das Gute: Jeder Befehl wird fortlaufend nummeriert. Beispiel:
1013 OK SEARCH completed (Success) ... sending command (5): 1014 UID COPY ... getting response (5): 1014 OK [COPYUID 100 ... sending command (5): 1015 UID STORE ... getting response (5): 1015 BAD Could not parse command
In meinem Fall schienen alte Emails von Batmaid das Problem auszulösen. Ich passte den Filterbefehl an (indem ich jetzt neu gegen das Subject filtere, anstelle gegen den From-Header), und danach verschob ich die Emails auch noch manuell in den Unterordner.
Seither tritt die Fehlermeldung nicht mehr auf.
Vermutung: Irgendein nicht konformer Header im Email.
Tags: Debug, imapfilter
Labels: IT
Dienstag, 15. März 2022
Ubiquiti UniFi Switch mit 16+2 Anschlüssen, von welchen alle Ethernet-Ports PoE machen können (maximal 150W)
Antwort: 16 Watt, ohne dass irgendwelche Geräte angeschlossen sind, und 20 Watt, wenn Netzwerkgeräte (ohne Power-over-Ethernet!) dran hängen.
Quelle: [Power Consumption] Unifi 8-60W vs 8-150W vs 16-150W
Tags: Ubiquiti, UniFi, US-16-150W
Labels: IT
Samstag, 12. März 2022
Kürzlich:
Get:1 http://security.debian.org bullseye-security InRelease [44.1 kB] Get:2 http://debian.ethz.ch/debian bullseye-backports InRelease [44.2 kB] Hit:3 http://phoscon.de/apt/deconz buster InRelease Hit:4 https://debian.ethz.ch/debian bullseye InRelease Hit:5 https://deb.nodesource.com/node_16.x bullseye InRelease Get:6 https://debian.ethz.ch/debian bullseye-updates InRelease [39.4 kB] Get:7 http://packages.cloud.google.com/apt cloud-sdk-bullseye InRelease [6,772 B] Hit:8 https://debian.ethz.ch/debian buster InRelease Get:10 http://debian.ethz.ch/debian bullseye-backports/main Sources.diff/Index [63.3 kB] Get:11 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages.diff/Index [63.3 kB] Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B] Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B] Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB] Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB] Get:9 https://dl.ubnt.com/unifi/debian stable InRelease [3,038 B] Reading package lists... Done E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Die relevante Zeile:
E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0'
Es war aber spätabends und ich war auf keine Experimente mit meinem WLAN aus.
Wie macht man, dass diese Meldung weggeht, und die restlichen, nicht-UniFi Pakete trotzdem aktualisiert werden? Ganz einfach: In /etc/apt/sources.list ersetzt man in der Unifi-Zeile „stable“ mit „oldstable“:
... deb http://www.ubnt.com/downloads/unifi/debian oldstable ubiquiti ...
Tags: apt, Debian, UniFi, UniFi Controller
Labels: IT
Mittwoch, 23. Februar 2022
Ich habe meine lokalen DHCP-Server so konfiguriert, dass Geräte mit ihrem lokalen DNS-Namen auch in named (BIND9) registriert werden.
Gelegentlich treffe ich folgendes Problem an:
Feb 23 01:15:15 SERVER dhcpd[2746174]: Unable to add forward map from apple-tv.domain.tld. to 10.1.2.3: SERVFAIL
Wie ich mittlerweile nach unzähligen verbratenen Stunden herausgefunden habe hängt dies mit diesem beschissenen AppArmor zusammen. Obwohl ich es jeweils deinstalliere, taucht es nach Updates wieder im System auf.
Die Lösung:
# apt-get remove apparmor # systemctl stop apparmor # systemctl disable apparmor
Quelle: How to disable and remove AppArmor in Ubuntu and Debian
Je nach Tageslaune ist dann auch noch ein Reboot nötig.
Mittlerweile habe ich eine monit-Regel eingerichtet, die mich alarmiert, wenn ein solcher Log-Event in /var/log/dhcp.log auftaucht.
(Auf meiner Todo-Liste steht, die Installation mittels apt zu verbieten)
Tags: AppArmor, Bind9, DDNS, Debian, DHCP, DNS, named, SERVFAIL
Labels: IT
Sonntag, 13. Februar 2022
Jetzt ist es klar: Trotz mehreren Stunden Investition habe ich es nicht geschafft, meinen Proscend T-190 g.fast SFP in meinem Turris Omnia mit Turris OS 5.3.5 zum Laufen zu bringen.
Wie der Router den SFP sieht:
[ 13.657984] libphy: SFP I2C Bus: probed [ 14.013558] sfp sfp: module PROSCEND 190-T rev V7.3 sn 19207J7B92080009 dc 31-08-20 [ 14.022906] sfp sfp: unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0% [ 14.031107] sfp sfp: 1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX- [ 14.041249] sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER- [ 14.047550] sfp sfp: Wavelength 0nm, fiber lengths: [ 14.052617] sfp sfp: 9µm SM : unsupported [ 14.057337] sfp sfp: 62.5µm MM OM1: unsupported/unspecified [ 14.063112] sfp sfp: 50µm MM OM2: unsupported/unspecified [ 14.068875] sfp sfp: 50µm MM OM3: unsupported/unspecified [ 14.074659] sfp sfp: 50µm MM OM4: 2.540km [ 14.079030] sfp sfp: Options: retimer [ 14.082886] sfp sfp: Diagnostics:
Vorbemerkung: Ja, das Folgende habe ich gemacht (resp. musste ich nicht machen, war schon so):
# ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot
Die Probleme begannen am 15. Dezember 2021, als der Router sich selbständig von TOS 3 auf 5 aktualisierte — und danach mit dem SFP keine Internet-Verbindung mehr möglich war. Ich habe darüber gebloggt.
Das Traurige: Unter TOS 3 funktioniert der SFP anstandslos.
Meine Vermutung ist es, dass das Problem mit inband/1000base-x zu tun hat:
... [ 13.913182] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode ...
Bei TOS 3 lautete das noch:
... [ 340.701090] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off ...
Ich habe nicht herausgefunden, ob und wie man das anpassen kann.
Ich habe einige Forenbeiträge gefunden, die einem helfen, das Problem nachzuvollziehen:
Vielleicht schafft es ja Turris OS 6.0 mit diesem Patch wieder, meinen SFPs zu unterstützen …
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT (Linux, OSS, Apple), Heim-Automation; mein mittlerweile abgeschlossenes Geschichtsstudium; Erkenntnisse aus meiner aktuellen Tätigkeit in der Informationssicherheit, meine Erfahrungen als IT-Berater, IT-Auditor, Web-Developer und IT-Supporter; die Schweiz, den Kanton Bern, meine ursprüngliche und auch wieder aktuelle Wohngemeinde Neuenegg, meine vorherige Wohngemeinde Bern, über lokale, regionale und globale Politik; meine Reisetätigkeit und Erfahrungen mit anderen Kulturen; und zu Guter letzt auch das Älter werden.
Alle in diesem Blog gemachten Aussagen und Meinungen sind persönlich und nicht als Ansichten meines aktuellen und/oder meiner bisherigen Arbeitgeber zu verstehen.
 |
You are currently browsing the archives for the IT category.