Stefan

There is an API to disable the status led since Master Brick firmware 2.3.2.

Seit Master Firmware 2.3.2 kann man die LED per API deaktivieren. Eine sehr gute API-Erweiterung. Ich hoffe, dass sie auch in zukünftigen Firmware- und Hardwareversionen erhalten bleibt.

Die Werte haben irgendwelche Werte. Diese stimmen nicht unbedingt mit den anliegenden überein. Dies tritt vor dem Öffnen von Brick Viewer ein. Danach öffne ich Brick Viewer und sehe, dass die einzelnen Pins ganz schnell von Low auf High und wieder zurück springen, vermutlich geht die Einstellung Pull-Up irgendwie verloren.

Hi Theo, das IO16-Bricklet macht bei mir etwas Probleme. Nach einer gewissen Zeit stimmen die Werte nicht mehr. Öffne ich jetzt den Brick Viewer dann flippen die Zustände mehrere Male pro Sekunde von Low auf High und wieder zurück. Wenn ich ich für einen der Ports (A und B) einen Pin wieder mit dieser Option einstelle Direction: Input Config: Pull-Up , dann werden wieder für alle Pins an diesem Port die korrekten Werte angezeigt. Leider gehen durch Brick Viewer bedingt, aber die Output Pins verloren. Es wäre super, wenn du dir es mal anschauen könntest.

Man könnte einen Netzwerk-/Ethernetumschalter verwenden und diesen mit Tinkerforge automatisieren. Es gäbe z.B. von Micma solche Geräte, die entweder per Schalter (gegebenfalls über Tinkerforge steuerbar) oder per Anlegen einer Spannung (über Tinkerforge steuerbar) sich steuern lassen.

You could use openHAB. There are a Tinkerforge binding and a SNMP binding. With less effort you should be able to build a transformation from Tinkerforge to SNMP. https://github.com/openhab/openhab/wiki https://github.com/openhab/openhab/wiki/Tinkerforge-Binding https://github.com/openhab/openhab/wiki/Snmp-Binding

Super, dass es geklappt hat. Openhab und das Tinkerforgebinding sind sehr cool

Laut openhab Tinkerforge binding wiki Seite https://github.com/openhab/openhab/wiki/Tinkerforge-Binding müsste es funktionieren.

In der openhab.cfg muss folgendes eingetragen werden: tinkerforge:hosts=ip1 ip2

Ich fände ein IR-Fernbedienungs-Bricklet würde gut in euer Sortiment passen.

Um dies zu verhindern, kann man auch statt einem Standard Switch auch zwei Buttons benutzen, diese können beliebig beschriftet werden, z.B. mit on und off. In der Sitemap dies definieren: Switch item=YourItem mappings=[ON = "on", OFF = "off"]

Jetzt verstehe ich den Einsatzzweck für die Authentifiakation. Ich persönlich habe mein Brick nicht im Internet (z.B. per dyndns) hängen. Da müsste sich der Angreifer in meinem Heimnetzwerk befinden. Natürlich wäre es besser, wenn dagegen auch das Brick geschützt wäre, aber dies ist nur ein "nice to have" und nicht unbedingt nötig. Ich würde diese Problematik und die Lösung mit dem VPN in die Dokumentation eintragen. Anfänger könnten denken, dass die Authentifikation unknackbar ist und so z.B. das Brick direkt per dyndns betreiben.

Heißt dies, dass der Man-in-the-middle Angreifer auch nach dem Verbindungsaufbau die bestehende Verbindung übernehmen kann? Beim Verbindungsaufbau kann er ohne Probleme die Verbindung übernehmen. Hier gäbe es aber eine Lösungsmöglichkeiten. Der HMAC-SHA1 würde asymmetrisch verschlüsselt übertragen. Ich kann aber nicht einschätzen, ob ein Brick mit Ethernet bzw. Wifi-Extension in der Lage ist, dies zu machen. Man könnte die Verschlüsselung auch optional anbieten, falls Brickd (dieser läuft ja meistens auf relativ potente Hardware) eingesetzt wird. Optional könnte man in Verbindung mit Brickd auch eine vollständige symmetrische Verschlüsselung (nach asymmetrischem Schlüsselaustausch) anbieten. Dies müsste auch sicher sein, wenn der Man-in-the-middle Angreifer auch nach dem Verbindungsaufbau die bestehende Verbindung übernehmen kann.

Digest access authentication ist normalerweise durch einen Man-in-the-middle-Angriff verwundbar. Ich konnte in http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html#llproto-tcpip-authentication auf die Schnelle auch keine Maßnahme, die dies verhindert, finden. Ist dies richtig oder habe ich etwas übersehen?

Bei mir funktioniert es. Beim "reconnecten" wurde nicht umgeschaltet (der andere Zustand war der "default" Zustand). Insgesamt ist es aber schwierg zu sagen wann "reconnected" wird, da falls die Verbindung verloren geht, die Zustände - z.B. ON - erhalten bleiben und nicht auf "uninitialized" wechseln. Manchmal kommen bei mir auch die Zustände ganz durcheinander. Dies liegt sehr wahrscheinlich aber nicht mit openHAB und deinem Binding zusammen. Dies habe ich mit Brickv auch. Darum kümmere ich mich aber erst, wenn ich mir einen neuen Rechner hole.

Super und danke, Theo. Den Status aus dem Bricklet auszulesen ist natürlich die beste Lösung. Ich finde die Idee diesen Thread in "Hausautomatisierung mit openHAB" umzubenennen gut. Du kannst es ja vorher nocheinmal ankündigen und schreiben, dass alle ihre E-Mail Benachrichtigung ändern sollen. Vielleicht wäre aber auch der Titel "openHAB Heimautomatisierung" nicht schlecht, da es viele Titel gibt, die mit Heimautomatisierung anfangen und man so sehen würde, welches System gemeint ist.

@Rincewind openHAB hat auch ein FS20 Binding. Ich habe selber jedoch keine FS20-Geräte. Vielleicht wäre es eine Alternative zu FHEM. @derAngler Die openHAB Classic UI ist doch im Apple Style. http://demo.openhab.org:8080/openhab.app?sitemap=demo

Super

Hallo, seit openHAB 1.4 kann man CometVisu als GUI benutzen. Vielleicht gefällt dir dieses GUI besser.

Hallo, funktioniert das Mathematica Binding auch mit Linux bzw. Mono? Falls ja, könnte man dies in der Mathematica Binding Dokumentation erwähnen, da man bei C# erstmal an Windows denkt.

Hi Theo, ein sehr toller und ausführlicher Wikiartikel. Hier hast du ein "will" zuviel. Außerdem hattest du mir dies geantwortet: Dies könnte man, meiner Meinung nach, zu dem von mir zitierten Abschnitt hinzufügen. Der letzte Status wiederherzustellen ist so schwierig, da das Binding nicht den aktuellen Status speichern darf, oder? Könntest du nicht die Option anbieten, dass man neben dem defaultState auch einen defaultStateReconnect hat und diese auch jeweils als "uninitialized" konfigurieren kann. Dann könnte man mit "restoreOnStartup" (habe ich noch nie ausprobiert) oder einer "Rule" doch den letzten Stand laden.

Hast du in dem ersten Satz default Zustand und aktueller Zustand vertauscht und meinst: "Allerdings arbeite ich noch daran, dass für outgoing ports nach dem Reconnect unabhängig vom default Zustand der aktuelle Zustand wieder hergestellt wird. Ich denke es sollte der aktuelle Zustand bleiben." Dies fände ich auch besser.

Hallo Theo, vielen Dank. Ich kann es nur wiederholen, das TinkerForge-Binding ist echt super. @Unexpected Der openhab Designer dient nur zur Erstellung der Konfiguration, dies kann man auch über einen Texteditor machen bzw. die Konfiguration über Windows erstellen und dann auf den anderen Rechner kopieren. Die openhab-runtime müsste auch auf der ARM-Plattform laufen.

Eine Websocketimplementierung auf dem Brickd und der WiFi-/Ethernet-Extension wäre super. Mit TCP/IP und Websocket müssten nahezu alle Sprachen abgedeckt sein. Einen Art Miniserver könnte sich ja zukünftig jeder mit der On Device Programmierschnittstelle zusammenprogrammieren. Hier sind die Ansprüche viel zu verschieden, der eine möchte JSON, der andere XML...

JavaScript hätte auch den Vorteil, dass man das Binding in HTML5-Apps oder im Browser benutzen könnte, wenn es Schnittstellen für TCP gibt. Diese sind, wenn verfügbar z.B. Firefox OS, zwar im Moment sehr proprietär und man müsste das Binding immer daran anpassen, aber vielleicht gibt es irgendwann ein einheitlicher Standard.