openHab2 startup chaos

Thursday, October 25. 2018

starting and stopping openhab2 is a messy affair, filling the logs with loads of Java's verbose exception messages and since the order of loaded models is basically random things may or may not work as intended when items have not been loaded or rules not executed that are assumed to be there.

As it was, manual corrections and reloads were needed after each restart.

There is an elegant workaround discussed at community.openhab.org/t/cleaning-up-the-startup-process-renaming-rules-windows-possible/38438/9 which uses systemd's ExecStartPre and ExecStartPost commands to deactivate all rules before starting openhab, and then reactivate them one by one when the system is up and has it's feet on the ground.

It did not work exactly like described there for me, but I still found a solution that has cleaned up the messy startup here.

A small bash script does the renaming. I put it in /etc/openhab2 next to openhab's configuration into a new folder /exec-scripts:

#!/bin/bash
#######################
#
# clean up the start process 
#  starting rules in a sorted manner after openhab2 got it's feet on the ground
#  called from systemd pre start 
#  to rename *.rules away initially 
#
#  synopsis: move_rules_at_start.sh org-extension new-extension (POST)
#  
#  first call is from
#  /etc/systemd/system/openhab2.service.d/override.conf
#
#  called from the running openhab again to rename them back one by one
#
# $3 allows to distinguish between pre and post action 
#
# REF: https://community.openhab.org/t/cleaning-up-the-startup-process-renaming-rules-windows-possible/38438/9


ORG=$1
NEW=$2
THX=$3
DUR=1
IGNORE=005_start.rules

for f in /etc/openhab2/rules/*.${ORG};
do
    CURRENT=$(basename $f)
    if [ "$CURRENT" == "$IGNORE" ]    
    then
        echo "ignoring $IGNORE"
    else
        OLDFILE=$f
        NEWFILE=${f%$ORG}$NEW
        mv "$OLDFILE" "$NEWFILE"
    fi
    # let some time between each load
    if [ "$THX" == "POST" ]
    then
        /bin/sleep $DUR
    fi
done

# some things left on startup
if [ "$THX" == "POST" ]
then
    /usr/bin/touch /etc/openhab2/things/tradfri.things
fi


Since the openhab2.service file is part of the package and thus is replaced with each update modifying the .service file would need to be repeated whenever a new version gets installed, but, systemd provides a way to override a service definition. systemctl edit openhab2.service creates an override dir and opens the editor to allow creating a service file that is not replaced by the next update.

Now don't try to copy the entire .service file, systemd will complain duplicated statements. My override.conf looks like this:

[Service]
ExecStartPre=/etc/openhab2/exec-scripts/move_rules_at_start.sh rules rules_

The third element is a .rules file in openhab2 that triggers the renaming of all the other .rules once the system is running. It is excepted from the renaming and I named it 005_start.rules. This works for me:


var rulesDelayed
var nada

rule "triggered by system start"
when 
    System started
then
    var duration = 1
    rulesDelayed = createTimer(now.plusMinutes(duration), [|
					logInfo("rulesDelayed", "Timer expired and start")
					nada=executeCommandLine("/bin/bash /etc/openhab2/exec-scripts/move_rules_at_start.sh rules_ rules POST ",90000)
                    logInfo("rulesDelayed", "result: "+nada)
					rulesDelayed = null

				])
    logInfo("rulesDelayed", "Timer set on "+duration+" min")
end


The bash script works the list of rules -files in an alphanumerical order so a naming scheme like praefixing all .rules with a three digit number finally allows to control the order of rules loading.

Startup is much faster now, less or no exceptions and a much cleaner log :-) Openhab is a Java application and those exceptions are super-ugly and come with a performance penalty.

You'll notice that the bash script supports an optional 3. parmeter to distinguish between pre- and post-action and that a certain config file is touched after the renaming. touch-ing triggers a reload of that config file and this was a workaround for a bug in the tradfri-addon, the bug may have been addressed by now.

MindMaps: Xmind -> FreeMind

Thursday, April 21. 2011

Ich setze zur Strukturierung meiner Gedanken gerne MindMaps ein und, was die Software angeht, schon seit längerem XMind. Das ist in Java und so für Win*, MacOsX und Linux (für versch. Architekturen und Distros) verfügbar, sieht ansprechend aus, läuft stabil, ist in einer kostenlosen Variante verfügbar (dazu gleich mehr) und hat nur einen Haken: es versucht den alten Dateiformat-Marketingtrick, nämlich einerseits viele Importformate zu unterstützen, andererseits aber den Export geizig zu handhaben. Erst die kostenpflichtige Pro-Version unterstützt den Export nach .mmap oder .mm, die kostenlose Version bietet in der Zusammenarbeit mit anderen MindMap-Softwares nur Einbahnstrassen. 

Was den Nutzen der Software für die Zusammenarbeit mit anderen doch sehr reduziert, und auch schmerzt, wenn eine Plattform dazukommt, die XMind nicht bedient: in meinem Fall Android 2.3. Da gibt es im Market eine recht überschaubare Anzahl von Mindmap appls, ThinkingSpace und sonst nicht viel.

ThinkingSpace liest und schreibt .mm, und wenn ich also meine am Desktop begonnenen Überlegungen zu einem Thema während der Bahnfahrt auf dem SmartPhone weiterführen will, muss ich die Frage der Dateikonvertierung lösen. (oops, siehe Update unten!) Leider ist MindMapping eher ein Nischenthema und eine Suche nach Konvertern für die drei Dateiformate .xmind, .mmap und .mm geht leer aus. 

Noch einmal zu der kostenlosen Version von XMind: sie ist Crippleware. Ich hatte, noch unter win*, eine aktuelle Version installiert, die etliche MenueEinträge enthielt, die immer nur auf die Pro-Version verwiesen. Die letzte Version, die all' diese - eh nicht verfügbaren - Features auch gar nicht erst anpries, war Version: 3.0.1. das ist auch die Version, die ich unter allen drei OSen einsetze.

Meine Suche nach Datei-Konvertern führte mich nun dazu, dass es die Sourcen für XMind in einem bestimmten Featureset auch als Opensource gibt.  Will heissen: die Opensource-Version 3.2.1 sieht für mich bis auf ein entscheidendes Detail (Exportformate!) einfach gleich aus. Kein Feature-Spam in den Menüs und FreeMind als ExportOption: was wollte ich mehr?

Nun, nach dem Download der Sourcen in einem .zip stellte sich zunächst erst mal die Frage, wie ich das zum Laufen bekomme. Java ist ja doch eher unbekanntes Terrain für mich. Es fand sich aber ein sehr hilfreiches Kochrezept auf code.google.com/p/xmind3/wiki/How_to_build_XMind_from_source  dem ich gefolgt bin und letztlich auch mit Erfolg. Ich hatte aber schon einige Hürden zu überwinden.

Step 1.3:  Copy to {ECLIPSE}/plugins/
ich habe die drei letztlich sowohl zu /home/username/.eclipse/org.eclipse.platform_3.5.0_155965261/plugins als auch nach /usr/lib/eclipse/plugins/ kopiert, habe auch alle in den Comments erwähnten restart/refresh/reloads angewandt, aber aber...

Step 1.5:  Available Software Sites braucht Add: http://download.eclipse.org/tools/gef/updates/releases/

Step 3.2: stehe aber dennoch mit 62 Error da, die sich offenbar alle auf bouncycastle zurückführten. Was es letztlich brachte war, diesem Comment zu folgen:
"Here is what I did to fix it easily.
Right clicked org.bouncycastle jar, choose import
Chose Plugin Development > Plugins and Fragments
Took defaults - hit Next
Choose the org.bouncycastle jar, then "Add"
Finish.
Project is now in workspace and everything compiles."

Fein, nun läuft es als eclipse-> run, wie ich es zu einem standalone compiliere bzw packe, habe ich noch nicht erforscht. Aber mit ps faux|less konnte ich mir die command line mit allen Optionen heraussuchen und habe sie in eine ~/bin/xmind.sh gesteckt, die sich, mit dem KDE - Menu Editor ohne weiteres in das Menu einbinden liess und funzt.

Alles geht wie zuvor, nur zusätzlich endlich eine Export-Option nach FreeMind.  

 

Update:
Hatte ich nur nicht richtig hingesehen oder hat ThinkingSpace seither dazugelernt? Jedenfalls kann die App jetzt Freemind, Mindjet und XMind - Format lesen und Schreiben, verbindet sich optional auch mit MindMeister.

Und so kann man es zum Konvertieren benutzen:
- die.xmind auf die SD-Karte schieben
- ThinkingSpace->Menu->Einstellungen->Default file format->Freemind auswählen
- Rücktaste, in der Liste der vorhandenen mindmaps lange auf die.xmind druecken
- öffnet sich Kontext-Menü, da Kopieren wählen.
- OK, jetzt gibt es auf der SD-Karte neben die.xmind auch die.mm 

Update:
ThinkingSpace heisst jetzt MindJet.

Update 26.9.2012:
Mit Arch Linux finde ich eine Version von XMind,  XMind 2012 (v3.3.0), die den Export und Import von Freemind und Mindjet Manager als Option anbietet (und mehr.) Ich habe auch erstmal kaum "reservierte" Optionen in den Menues gesehen, damit hat sich die Notwendigkeit eines externen Konvertierungstools eigentlich erledigt.

(Page 1 of 1, totaling 2 entries)