Apache Log4j 2 Intro und Migration von Log4j 1

Überblick, Vorteile gegenüber Log4j 1

Apache Log4j 2 ist der Nachfolger von Log4j 1, bietet eine Reihe von Vorteilen gegenüber dem Vorgänger und integriert auch Verbesserungen, die in Logback von Qos.ch entwickelt wurden (das sich bisher als Nachfolger von Log4j 1 verstand, da hier Probleme mit Log4j 1 gelöst wurden).

Die API ist nicht abwärtskompatibel, es können aber über einen passenden Adapter alle Anwendungen/Bibliotheken weiterhin die Log4j 1 API verwenden.

Ab Log4j Version 2.4 ist Java 7 als Laufzeitumgebung erforderlich (Java 6 bis 2.3).

Den Log4j 2 User’s Guide gibt es auf der Homepage oder als PDF.

Apache Log4j 2 Intro und Migration von Log4j 1 weiterlesen

Tinkerforge Wetter mit MQTT und Node-RED

 

Für den GetCyberphysical Hackathon gab es einen kleinen Hinweis auf Node-RED. Dafür habe ich mal eine kleine Demo mit der Tinkerforge Wetterstation und dem MQTT-Proxy erstellt, die sofort funktionsfähig war:

nodered-tinkerforge-weather

Voraussetzungen:

  • Die Wetterstation ist mit einer WIFI-Extension ausgestattet und im lokalen WLAN adressierbar.
  • Ein MQTT Broker ist erreichbar, der Einfachheit halber Mosquitto auf localhost.
  • Node-RED, Python und der MQTT-Proxy stehen lokal zur Verfügung.

Arbeitsschritte:

1.) MQTT-Proxy mit einem Aktualisierungsintervall von 5 Sekunden starten:

python brick-mqtt-proxy.py --brickd-host 192.168.1.107 --brickd-port 4223 --broker-host localhost --broker-port 1883 --update-interval 5

Mit dem Parameter –debug kann man sehen, auch welche Sensoren/Aktoren sich der Proxy selbst subscribiert, um die ggf. Steuerungssignale über den MQTT-Broker entgehenzunehmen und an die Geräte weiterzuleiten, in diesem Fall betrifft das die Komponenten der Wetterstation:

DEBUG:root:Subscribing to tinkerforge/bricklet/ambient_light/mbJ/_update_interval/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/write_line/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/clear_display/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/backlight_on/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/backlight_off/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/config/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/custom_character/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/default_text/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/default_text_counter/set
DEBUG:root:Subscribing to tinkerforge/bricklet/lcd_20x4/o6B/_update_interval/set
DEBUG:root:Subscribing to tinkerforge/bricklet/barometer/jZR/reference_air_pressure/set
DEBUG:root:Subscribing to tinkerforge/bricklet/barometer/jZR/averaging/set
DEBUG:root:Subscribing to tinkerforge/bricklet/barometer/jZR/_update_interval/set
DEBUG:root:Subscribing to tin

 

Für unsere kleine Testanwendung sind jedoch die Sensorwerte interessant, für die man sich auf entsprechende Topics Subskribieren muss.

Welche genau das sind, kann man der Tinkerforge Dokumentation entnehmen.

Beispielsweise lautet die Subscription für alle Werte des Barometer-Bricklets so:

tinkerforge/bricklet/barometer/jZR/+

Der Bezeichner „jZR“ ist die eindeutige Identifikationsnummer des Bricklets im Tinkerforge-Stapel, die bei allen Zugriffen erforderlich ist.

Was die Sensorwerte genau liefern, ist ebenfalls dokumentiert, zum Beispiel für das Barometer-Bricklet. Entsprechend ist das ggf. für Anwendungen geeignet zu konvertieren.

 

2.) Mit Node-RED Verbindung zum MQTT Broker aufnehmen und Sensorwerte kontinuierlich empfangen:

Jeder MQTT-fähige Client kann nun mit einer Subscription die Werte empfangen, für ein schnelles Prototyping habe ich mit „node-red“ den lokalen Node-RED Server gestartet und 2 Knoten definiert und miteinander verbunden, um die im Screenshot gezeigten Ausgaben zu produzieren.

Das JSON-Snippet mit dieser Node-RED Anwendung kann über die Import-Funktion auch direkt eingebunden werden, bitte entsprechend die Host- und Port-Angaben sowie die Subscription-Daten an die eigene Umgebung anpassen:

[{"id":"e96a8a4f.169578","type":"mqtt-broker","broker":"localhost","port":"1883","clientid":""},{"id":"e7dcb9a0.182348","type":"mqtt in","name":"tinkerforge/bricklet/barometer/jZR/+","topic":"tinkerforge/bricklet/barometer/jZR/+","broker":"e96a8a4f.169578","x":166,"y":82,"z":"1e029756.e1fd69","wires":[["61f9ce5.f9e063"]]},{"id":"61f9ce5.f9e063","type":"debug","name":"","active":true,"console":"false","complete":"false","x":435,"y":163,"z":"1e029756.e1fd69","wires":[]}]

Fertig. Im nächsten Schritt würde ich das z.B. über eine Java-Anwendung mit Vaadin-Charts visualisieren und das ganze ins Netz stellen. Auf die gleiche Weise ließe sich auch der Rückweg für die Aktoren realisieren.

 

GetCyberphysical Hackathon Sept 18./19. 2015 Hamburg

Am 18./19. September 2015 findet bei der Gründerwerft HH der GetCyberphyiscal Hackathon von Skbuy statt: http://www.getcyberphysical.com/

Dafür habe ich mal ein paar Vorschläge für die Skybus-Integration mit dem mir vorliegenden Equipment gemacht, um das eine oder andere am Samstag konkret angehen zu können mit den an diesem Ansatz interessierten Teilnehmern.

An Hardware bringe ich grob zusammengefasst mit:

Die von mir bevorzugte Software zur Arbeit im Hackathon:

  • MacOS, Eclipse, Java 8, Bibliotheken für MQTT/REST Anwendungen.
  • Tinkerforge Bindings und Adapter, MQTT-Proxy (Python)
  • Vaadin Bibliotheken und Pro Tools Lizenz für GWT-based RIAs mit Charts.

Die möglichweise für Samstag in Frage kommenden Vorschläge:

a.) MQTT-Proxy für Tinkerforge Hardware auf Java portieren und mit
Skybus einige Sensoren/Aktoren instrumentieren bishin zu einer
Vaadin-Anwendung mit Visualisierung via REST oder direkt MQTT.
b.) Skybus-SDK Anbindung des Tinkerforge Kameraschlittens (Motor +
Steuerung), der über Tinkerforge Bricks (inkl. RED Brick Embedded Linux)
gesteuert und im Netzwerk verfügbar gemacht wird. Die Anbindung würde ich mit den Tinkerforge Java-Bindings via MQTT an Skybus realisieren wollen.
Tinkerforge Camera Slider
Tinkerforge Camera Slider
c.) "Skybus-Bridging" einer OpenHAB (http://iot.eclipse.org/) Anwendung (z.B. Wetterstation). Die in OpenHAB definierten Things und Items über Tinkerforge- oder MQTT-Bindings mit Skybus integrieren, OpenHAB Regeln wiederverwenden, ggf. ein Sykbus-Binding entwickeln und beiderseits die Visualierungen inkl. my.OpenHAB Cloud verwenden (Da das Skybus SDK noch bis Samstag eine Unbekannte ist, ist noch unklar, wie sinnvoll das ist ;-)).
d.) Anbindung Tinkerforge LoadCell (Waage) oder Laser-Entfernungsmesser.
Tinkerforge LoadCell Kit
e.) TinkerForge Hardware Hacking Kit mit Funkfernbedienungen nutzen (alte Hardware aufreißen mit, Tinkerforge einbinden und mit Skybus instrumentieren).
f.) Implementierung von Oberflächen für Lösungen im Hackathon mit Vaadin Charts etc. über Skybus REST/MQTT.