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.