Samstag, 2. Januar 2021

Müllkalender in die Owncloud importieren

Mein Entsorger bietet eine praktische Funktion an, in der er die Abholungstermine als iCal (.ics) Datei bereitstellt. 
Leider kann die .ics Datei so nicht ohne weiteres in die Owncloud importiert werden. Zur Umwandlung der Datei verwende ich folgendes Linux Kommando:

sed 's/\r//' Downloads/muellkalender.ics | sed '/DTSTART.*/s/$/T060000Z/' | sed '/DTEND.*/s/$/T060000Z/' > owncloud-cal.ics

Die Datei owncloud-cal.ics, kann jetzt einfach importiert werden.

*** UPDATE ***

Seit letztem Jahr wurden die Einträge immer für zwei aufeinanderfolgende Tage angezeigt. Das habe ich gefixt, allerdings braucht man dazu ein kleines Python Skript.

Dazu den folgenden Inhalt die Date bdg4owc,py kopieren und anschließend:

python bdg4owc.py <Pfad zur BDG Datei.ics>  aufrufen. Der konvertierte Kalender befindet sich dann in /tmp/bdg4owncloud.ics.

Python: 

#!/bin/python
import sys

in_cal = open(sys.argv[1], "r")
out_cal = open('/tmp/bdg4owncloud.ics', 'w')

content = in_cal.readlines()
dt_start=""
for line in content:
if line.startswith('DTSTART'):
parts = line.split(':')
if parts[1].find('T') == -1:
out_cal.write(line.strip() + 'T060000Z\n')
dt_start = parts[1].strip()+'T060000Z'
elif line.startswith('DTEND'):
parts = line.split(':')
if len(dt_start) == 0:
out_cal.write(line.strip() + 'T060000Z\n')
else:
out_cal.write(parts[0]+":"+dt_start+'\n')
else:
out_cal.write(line)



Freitag, 24. April 2020

Adafruit Feather 32u4 mit MacOS Catalina

Wenn man versucht das Feather 32u4 von Adafruit mit seiner Arduino IDE (1.8.12) zu verwenden, läuft man auf diesen Fehler auf:

 Bad CPU type in executable

Das liegt daran, das seit MacOS 10.15 nur noch 64Bit executables ausgeführt werden können. Unglücklicherweise liefert das Boardpackage (1.4.13) von Adafruit noch 32 Bit Executables für die Ansteuerung des Boards aus.  Glücklicherweise liefert die IDE alle Tools, die man benötigt in 64 Bit mit.

En möglichst wenig invasiver Eingriff, und as Problem zu fixen sieht so aus:

  1. cd ~/Library/Arduino15/packages/arduino/tools/avr-gcc
    An dieser Stelle liegen die 32 Bit Executables.
  2. mv 4.9.2-atmel3.5.4-arduino2/ 4.9.2-atmel3.5.4-arduino2-orig
    Damit werden die 32Bit Executables verschoben.
  3. ln -s /Applications/Arduino.app/Contents/Java/hardware/tools/avr/ 4.9.2-atmel3.5.4-arduino2
    Mit diesem Kommando stellen wir die Verbindung zum den neuen 64Bit executables her, die mit der IDE geliefert werden.
Damit wurde der Compiler angepasst und man kann den Sketch übersetzen. Als nächstes muss die Kommunikation mit dem Board hergestellt werden. Dies wird mit dem Programm avrdude bewerkstelligt, was in der Auslieferung des Adafruit Packages ebenfalls nur in 32Bit verfügbar ist. Um den avrdude gegen die neue version zu tauschen kann man wie folgt vorgehen:
  1. cd ~/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9/bin
    An dieser Stelle liegen der 32 Bit avrdude.
  2. mv avrdude avrdude-orig
    Das 32Bit Executable wird verschoben.
  3. ln -s /Applications/Arduino.app/Contents/Java//hardware/tools/avr/bin/avrdude avrdude
    Mit diesem Kommando stellen wir die Verbindung zum den neuen 64Bit avrdude her.
Jetzt sollte alles wie gewohnt in der Arduino IDE funktionieren. 

Sonntag, 6. Oktober 2019

Neue SAT over IP Sender in Apple TV einrichten

Mit einer M3U Liste kann man eine alternative Senderlisten in die SAT>IP App des Apple TV einspielen. Das Format dieser Liste ist recht schlecht dokumentiert weswegen ich es hier aufschreibe.

Die M3U Liste ist eine Textdatei. Eine einfache Beschreibung findet man hier. In einer SAT>IP Liste wird folgendes Format erwartet:

#EXTINF:0,1. Das Erste HD
rtsp://sat.ip/?src=1&freq=11494&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,5100,5101,5102,5104

Die erste Zeile ist der Titel des Senders und die Programmnummer in diesem Fall 1.
Die zweite Zeile enthält den URL wo dieses Programm vom Apple TV abgerufen werden kann. Dieser URL enthält eine Reihe von Parametern, die die Programmauswahl im Tuner des SAT>IP Servers steuern.

Die Parameter:

  • src: Unbekannt ist aber in den M3U Dateien die ich  finden konnte immer 1.
  • freq: Die Frequenz des Senders.
  • pol: Die Polarisation hier sind die Werte v = vertikal und h = horizontal möglich.
  • ro: DVB Roll ist in den von mir gefundenen Dateien immer 0.35.
  • msys: Kann die Werte dvbs für SD Programme oder dvbs2 für HD Programme annehmen.
  • mtype: Modulationstyp kann die Werte 8psk oder qpsk annehmen
  • plts: Unbekannt, kann den Wert on oder off annehmen. Bei meinen Playlisten war der Wert bei mtype=8psk immer on und bei mtype=qpsk immer off.
  • sr: Symbolrate
  • fec: Unbekannt
  • pids: Eine Liste von pids (Programm Identitäten). Diese Liste beginnt mit: 0,17,18 dann kommt die PMT PID anschließend die VideoPID, danach die AudioPID und die PID für den Videotext.
Die notwendigen Daten für einen Sender kann man hier nachschlagen.

TLC ist im Moment nicht in der offiziellen Liste enthalten. Ein entsprechender Eintrag würde also so aussehen:


#EXTINF:0,23. TLC
rtsp://sat.ip/?src=1&freq=12460&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34&pids=0,17,18,103,1535,1536,37

Wenn dieser Eintrag einer aktuellen List hinzugefügt wird (die gibt es hier) und diese Date auf einem Webserver abgelegt wird, kann der URL in die SAT>IP Apple TV App eingetragen werden.

Das Programm 23 hat zwar kein Icon, aber TLC kann ausgewählt und angesehen werden.

Donnerstag, 22. September 2016

Mac OS Sierra und SSH

Mit dem Sierra Update von Mac OS unterstützt SSH  keine DSA Schlüssel mehr. Das hat zur Folge, dass die Authentifizierung mit diesen Schlüsseln nicht mehr funktioniert und man nach dem Passwort gefragt wird, oder die Authentifizierung scheitert, wenn der Server keine Passworte akzeptiert.

Auf jeden Fall sollten alle DSA Schlüssel durch RSA Schlüssel ersetzt und die neuen PubKeys dann auf dem Server installiert werden.

Um eine Verbindung mit den nun nicht mehr unterstützen Schlüsseln aufbauen zu können, reicht es in der Kommandozeile den Algorithmus zu erlauben.

ssh -o PubkeyAcceptedKeyTypes=+ssh-dss usern@example.com

So kann eine SSH Sitzung mit den alten Schlüsseln aufgebaut werden. Diese Sitzung kann man verwenden, um die neuen Schlüssel in die authorized_keys einzutragen.

Sonntag, 3. Januar 2016

Owncloud Kalender und Kontakte migrieren

Die Migration von Kalendereinträgen und Kontakten zwischen einem alten und einem neuen Owncloud Server oder zwischen inkompatiblen Versionen in meinem Fall von 7.0 nach 8.2.2 ist einfacher, als es sich nach einer einfachen Googlesuche darstellt. 
In meinem Fall versagte das occ Upgrade Utility und ich konnte den Server nicht upgraden.
Hier eine kurze Beschreibung, wie der Transfer von wenigen Personen einfach und schnell durchgeführt werden kann.
Die folgenden Schritte haben bei mir funktioniert:

  1. Export
    Sowohl an den Kalender CalDAV Link (verborgen hinter dem Kettensymbol), als auch bei dem CardDAV Link der Kontakte kann ?export angehängt werden. Den CardDAV Link findet man im Settingsmenü der Kontakte (Zahnradsymbol unten in der ersten Spalte) ebenfalls hinter dem Kettensymbol.
  2. Jeweils einen der Links in die Adresszeile des Browsers kopieren und ?export ohne Leerzeichen hinter den kopierten Link schreiben und die Seite aufrufen.
  3. Es wird jeweils eine Datei heruntergeladen. In der .ics Datei befinden sich alle Kalendereinträge in der .vcf Datei alle Kontakte.
  4. Für die Kontakte verwendet man die Importfunktion, die sich ebenfalls hinter dem Zahnradsymbol im Settingsmenü der Kontakte befindet. Nach dem Hochladen der .vcf Datei dauert es eine ganze Weile bis der Fortschrittsbalken etwas anzeigt, also Geduld.
  5. Bei den Kalenderdaten ist die Import Funktion nicht so offensichtlich. Die .ics Datei in den Dateibereich des Owncloud Servers hochladen. Der Server zeigt dann für die Datei ein Kalendersymbol. Wählt man jetzt die Datei aus beginnt der Importprozess. Auch dieser erscheint eine Weile regungslos, so dass man Bedenken hat, der Prozess sei abgestürzt, auch hier braucht man Geduld.
Das wars auch schon. Das Verfahren hat bei meinen 10 Benutzern gut funktioniert.

Freitag, 6. März 2015

RS-232 mit Java und Mac OS Yosemite

Auch wenn die serielle Kommunikation über RS-232 aus der Mode ist, gibt es immer noch eine Reihe von Geräten, die sich darüber einfach steuern lassen. Um eine serielle Kommunikation über Java zu ermöglichen wird seit Jahren die RXTX Library verwendet. 
Die Mac OS Binaries die auf der Homepage angeboten werden sind leider i386 Binaries, also etwas aus der Mode. Für alle Besitzer eines 64Bit System bleibt nur der Weg die Bibliothek selbst zu kompilieren und Java zur Verfügung zu stellen.

Da dies mit einigen Hürden verbunden hoffe ich, dass die folgenden Schritten anderen Fans der seriellen Kommunikation mit Java ein paar Minuten sparen.

Die folgenden Schritte sind notwendig:
  1. Xcode installieren.
  2. Aktuelles JDK installieren. Ich verwende JDK 1.8_40.
  3. Einen Shell Export für JAVA_HOME erstellen mit: export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home
  4. Macports installieren.
  5. Mit dem Kommando sudo /opt/local/bin/port install libtool glibtool installieren.
  6. RXTX Source Package herunterladen und entpacken.
  7. Im Ordner in dem das RXTX ZIP entpackt worden ist  das Kommando ./configure ausführen.
  8. Im Makefile müssen ein paar Anpassungen durchgeführt werden:
    die Zeile:
    LIBTOOLC = $(GLIBTOOL) --mode=compile $(CC) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(VERBOSE_IOEXCEPTIONS) -c
    muss durch die Zeile:
    LIBTOOLC = $(GLIBTOOL) --tag=CC --mode=compile $(CC) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(VERBOSE_IOEXCEPTIONS) -c
    ersetzt werden.
    Die Zeile:
    JAVAINCLUDEDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/../../../Headers
    muss durch die Zeile:
    JAVAINCLUDEDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/include
    ersetzt werden.
    Jetzt muss noch die Zeile:
    JAVANATINC = -I$(JAVAINCLUDEDIR)/
    durch:
    JAVANATINC = -I$(JAVAINCLUDEDIR)/darwin
    ersetzt werden.
  9. mit dem Kommando make wird der Buildprozess gestartet an dessen Ende zwei relevante Dateien erzeugt worden sind.
  10. In dem Ordner in dem das make Kommando ausgeführt worden ist befindet sich die Datei RXTXcomm.jar.  Im Unterordner i686-apple-darwin14.1.0 befindet sich die Datei librxtxSerial.jnilib
  11. Beide Dateien müssen in den Ordner /Library/Java/Extensions kopiert werden und das Setup ist komplett.
Ich hoffe das es euch hilft.

Dienstag, 6. Januar 2015

Grails 2.x Debugging in Netbeans

Wenn man eine Grails Applikation in Netbeans 8 erstellt und diese mit dem Debugger bearbeiten möchte stellt man fest, dass das nicht geht.
Der Debugger startet zwar und die Oberfläche stellt sich so dar als ob man die Applikation debuggen könnte, allerdings spricht keiner der gesetzten Breakpoints an.

Wenn man in die BuildConfig.groovy schaut stellt man fest, das in allen Forkkonfigurationen debugging disabled ist.

grails.project.fork = [
    // configure settings for compilation JVM, note ...      

    //  compile: [maxMemory: 256, minMemory: 64, de ...

    // configure settings for the test-app JVM, ...
    test: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256, daemon:true],
    // configure settings for the run-app JVM
    run: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256, forkReserve:false],   
    // configure settings for the run-war JVM
    war: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256, forkReserve:false],
    // configure settings for the Console UI JVM
    console: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256]
]



Die naheliegendste Änderung wäre es, true statt false in die BuildConfig.groovy einzutragen. Leider ist das nicht wirklich gut umgesetzt. Der Debugger startet zwar, verbindet sich aber nicht automatisch mit der geforkten JVM.
Der Debugger kann nachträglich attached (localhost:5005) werden und arbeitet dann korrekt. Dieses Vorgehen benötigt aber immer den Schritt des nachträglichen Verbindens mit der JVM.


Die komfortabelste Methode ist es den Fork zu deaktivieren. Dann erhält Netbeans die Kontrolle und die Gralsapplikation verhält sich wie jede andere Applikation in Netbeans.

Zum Deaktivieren des Forks die Zeile:

run: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, forkReserve:false],   

durch:

run: false,   

ersetzen.

Danach kann einfach über das Kontextmenü eine Debugsession gestartet werden.