borg

Hat der USB Stecker auf dem Brick vielleicht einen leichten Wackelkontakt? Du könntest mal ausprobieren das Kabel in eine Richtung zu "drücken" und gucken ob es dadurch besser wird. Eine andere Idee wäre noch, dass ein Pin in einem der Bricklet Stecker vom Master Brick krumm ist und dadurch einen Kurzschluss erzeugt, so wie hier: http://www.tinkerforge.com/de/doc/FAQ.html#mein-brick-wird-heisz Einen krummen Pin kann man evtl wieder gerade biegen, ansonsten schick bitte eine Email mit der der Bestellnummer zu welcher der Master Brick gehört an info@tinkerforge.com, wir tauschen den Master Brick dann aus. Entschuldigung für die Probleme!

Du kannst den RED Brick (wenn du möchtest) benutzen wie einen Master Brick ohne Bricklet Ports. D.h. du verbindest den RED Brick per USB mit dem PC, stapelst Bricks auf den RED Brick und steuerst vom PC .

Klingt super. Was mich bei Variante 2 interessieren würde, ist die Frage ob man beide Kanäle dann auch simultan auslesen kann? Ja, kann man .

This currently not planned, but it wouldn't be hugely complicated to implement. Perhaps we can implement it as an "inofficial" feature with the next Java Bindings release.

That is strange, i can not explain that at all. I will have to try it out.

Ich hab mit LookAndFeel in der Zwischenzeit einige Emails ausgetauscht. Wir konnten die HE800S Steckdose bisher nicht zum Laufen bekommen (auch nicht mit einem neuen Remote Switch Bricklet). Ich habe mir daher eines der Sets bestellt um es ausprobieren. Dabei ist etwas ganz erstaunliches herausgekommen . Die Steckdose kriege ich in der Tat nicht mit Protokoll B gesteuert. Allerdings kann ich die Steckdose mit einer Fernbedienung aus einem anderen Set (welches mit Protokoll B steuerbar ist) ansteuern. Nach einer längeren Phase von Verwirrung haben wir herausgefunden das einige der Fernbedienungen aus der "ELRO HomeEasy" Reihe mehrere Protokolle gleichzeitig sprechen, während die Steckdosen immer nur eins verstehen! Die Steckdose aus dem HE800S Set, welches ich mir besorgt hatte, spricht sogar nicht zwei oder drei Protokolle, sondern gleich vier Stück . Wenn ich einmal ganz kurz den Knopf der Fernbedienung drücke bekomme ich folgendes Ergebnis Wie wir sehen können, werden vier unterschiedliche Protokolle hintereinanderweg gesendet. Dabei gilt folgendes 1. Dieses Protokoll: https://code.google.com/p/rc-switch/wiki/KnowHow_LineCoding#EV1527,_RT1527,_FP1527_or_HS1527 2. Protokoll B 3. Dieses Protokoll: http://wiki.pilight.org/doku.php/elro_ad 4. Protokoll C Das erste hab ich sonst so noch bei keinen der Open Source Implementierungen gesehen, ich vermute das ist hier nicht relevant. Das dritte Protokoll scheint mir sehr interessant zu sein. Dies nutzt (genauso wie Protokoll B) "Adress" und "Unit" und es kann alle Steckdosen die in einer "Unit" sind auf einmal schalten. Ich denke ich werde versuchen dem Remote Switch Bricklet beizubringen das zweite und dritte Protokoll immer gleichzeitig zu sprechen, ähnlich wie es die Fernbedienung auch macht. Im Moment hab ich einen vollen Terminplan, es wird dann aber sobald ich es dazwischen kriege ein Update der Remote Switch Bricklet Firmware geben .

Eine Spezifikation des Protokolls gibt es hier: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Für unser Generator-Framework gibt es aktuell leider keine richtige Dokumentation. Ganz grob gibt es zwei Teile: Funktionen/Klassen welche die Kommunikation steuern und Pakete auslesen usw. Diese werden händisch geschrieben. Funktionen/Klassen welche die eigentliche API abbilden. Diese werden generiert. Finden kannst du die Generatoren unter https://github.com/Tinkerforge/generators Ich würde mir eine Programmiersprache aussuchen die ich kenne und die ähnlich zu Go ist. Diese kann man dann solange umändern bis am Ende Go bei rauskommt . Also die Funktionen stück für stück übersetzen. Am besten angefangen bei den Funktionen welche direkt auf dem Socket arbeiten, da kann man dann sofort testen und hat direkt erste Erfolgserlebnisse. Einem Brick eine (handgeschriebene) Nachricht schicken und die Antwort darauf wieder auslesen bekommt man in 15 Minuten hin. Also z.B. für C (https://github.com/Tinkerforge/generators/tree/master/c) ist der erste Teil in der ip_connection.c/h (https://github.com/Tinkerforge/generators/blob/master/c/ip_connection.c) und der zweite Teil wird über die generate_c_bindings.py generiert (https://github.com/Tinkerforge/generators/blob/master/c/generate_c_bindings.py) Das sind die beiden Dinge die du grundsätzlich schreiben musst um Bindings zu generieren. Wenn das veröffentlicht werden soll müssen natürlich auch noch ein Dokumentationsgenerator sowie die Beispiele geschrieben werden. Das ist dann aber nur Fleißarbeit.

Hier gibt es ein Beispiel dafür: http://www.tinkerforge.com/de/doc/Software/IPConnection_VBNET.html#enumerate

Es sind aktuell keine Go Bindings in Arbeit. Allerdings steht es bei uns auf der Liste als möglicher Kandidat. Es ist relativ einfach C und Go zu mischen: http://golang.org/cmd/cgo/ Ich könnte mir vorstellen das du ohne riesigen Aufwand die C Bindings in Go nutzen könntest (habe ich nicht getestet).

Ja, der Wagen wird von Kugellagern an allen 4 Seiten des Profils festgehalten.

Nach meinem Verständnis braucht man sowas wie 2cm Durchmesser um die NFC Spezifikation zu erreichen (10cm Reichweite). Google hat mir das hier gefunden: http://www.tec-tus.de/de/transponder/10-mm-x-10-mm-x-1-mm-mini-nfc-tag, Allerdings gibt es da keinen Online-Shop o.ä. Dort steht "Lesedistanz: 10 mm". Um was für ein Werkzeug handelt es sich denn, könnte man vielleicht einfach irgendwo ein Aufkleber anbringen? https://www.tinkerforge.com/de/shop/5x-nfc-sticker.html

Wir schicken ein neues Remote Switch Bricklet mit Rückumschlag für das defekte raus, dann können wir uns das hier angucken. Ich melde mich wegen der Adresse nochmal per Email. Entschuldigung für die Probleme!

Klingt korrekt, du könntest mal eine Adress und Unit ungleich 0 probieren und die repeats auf 10 oder so setzen. Sollte aber eigentlich egal sein. Du könntest auch noch nachgucken ob evtl. ein Beinchen vom Bricklet-Stecker des Remote Switch Bricklets oder des Master Bricks krumm ist, so wie hier: http://www.tinkerforge.com/de/doc/FAQ.html#mein-brick-wird-heisz Je nach Pin könnte das Bricklet erkannt werden aber die Kommunikation mit dem Funkmodul nicht funktionieren.

Wie versuchst du sie denn anzulernen? Funktionieren die Funksteckdosen mit der Fernbedienung? Du musst das Remote Switch Bricklet genauso anlernen wie auch die Fernbedienungen. Also die Funksteckdose neu einstecken (dann blinkt eine LED für 10 Sekunden) und dann innerhalb der 10 Sekunden auf "Switch On" klicken.

Neue, günstigere LED Streifen im Shop Blogeintrag

New cheaper LED strips Blog entry

Ah, i didn't think of that. I don't know the exact cabling of your blinds. Perhaps you can cable it in a way that you can use one Relay to drive forward and one to drive backward to get the functionality back (by switching between two relays in software).

The USB specification has a max length of something like 2m, i don't think you will be able to make a long USB cable with your cat5 cabling. You can however use the Ethernet Extension For 6V/40mA motors you can also use the Industrial Quad Relay Bricklet, which is way more cost efficient for your use case. So to control 4 blinds you would need Master Brick, Ethernet Extension, Industrial Quad Relay Bricklet and some kind of power supply (USB Power Supply, Step-Down Power Supply or Ethernet Extension with PoE). Than you can directly use your cat5 cable and connect it to your local network. I think that would be the best solution .

Yes, you can use a negative "switchOnVelocity": https://github.com/openhab/openhab/wiki/Tinkerforge-Binding#dc-brick To control 4 motors you need 4 DC Bricks. If you just want to switch them for a specified duration you could of course also use the Dual Relay Bricklet or the Solid State Relay Bricklet. Do you know how much power your motors need and at which voltage?

Sehr unschön. Ich befürchte da muss mittelfristig eine neue Lösung her, wir haben da wohl unsere Tests nicht lange genug betrieben . Die Frage ist wie genau eine bessere Lösung aussehen würde. Am besten wäre es vermutlich wir würden sowas mit in den Shop aufnehmen mit einem kleinen dazu passenden Adapterbricklet: http://www.vegetronix.com/Products/VG400/ Leider sehr teuer... Edit: Den hier könnten wir auch gut auslesen (I2C): http://www.adafruit.com/products/1298 Ist aber auch ein ganz guter Preissprung .

I uploaded the Brick firmwares with the current version of the new SPI protocol that will be used with the RED Brick: http://download.tinkerforge.com/_stuff/red_brick_spi_test/ If you have time and you want to help us, you can try it out. The firmwares are compatible to each other, but not to the older firmware versions. There shouldn't be any noticeable difference between the firmwares(regarding speed, latency, etc). If are interested to know why we need a new protocol for the stack communication, i already wrote in a blog entry about it:

Du musst einmal auf Reset drück nachdem du den USB Stecker reinsteckst wenn der Stack selbst schon per Step-Down Power Supply versorgt ist. In den letzten Brick Versionen haben wir die USB Hotplug Funktionalität entfernt, da sie durch große Hitzeentwicklung (unerwünscht) ausgelöst werden konnte. Siehe hier: http://www.tinkerunity.org/forum/index.php/topic,673.msg15985.html#msg15985

Mhhh, das muss ich dann mal selbst nachbauen hier. An und für sich sollten die Bricks jetzt mehr Zeit haben für Berechnungen und andere Kommunikation (da wir während der SPI-Kommunikation weiterlaufen können). Daher kann ich mir das gar nicht erklären.

Wir haben das Analog In aus dem Programm genommen weil wir mit der Messqualität nicht zufrieden waren. Das Bricklet bestand ja quasi aus 4 schaltbaren Widerständen. Dadurch war der Innenwiderstand der Anschlüsse nicht besonders hochohmig und Aufgrund der Verschaltung konnten wir dann auch schonmal sowas wie 5% Messfehler haben. Dazu kommt dann noch das der Messfehler in jedem Bereich anders ist, wodurch es zu Sprüngen kommt wenn man den Messbereich wechselt. In Summe waren wir mit der Qualität des Bricklets überhaupt nicht zufrieden. Wir arbeiten schon länger an einem Ersatz, leider sind wir mit dem letzten Prototypen ein bisschen über das Ziel hinausgeschossen: Dieser Prototyp hat eine galvanische Trennung zwischen Brick- und Messseite und man kann 2x Spannung messen. An die BNC Buchsen kann man direkt Probes anschließen, aber man kann alternativ auch Kabel an die grünen Buchsen anschließen. Leider befürchten wir dass das Bricklet vermutlich zu hochpreisig werden würde, daher haben wir dort erstmal nicht weitergemacht. Ich gehe aber stark davon aus, dass wir auf Dauer wieder ein Bricklet haben welches spezifisch zum Messen von Spannungen ist.

Ich hab Brick Firmwares mit der aktuellen SPI Protokoll Version für den RED Brick hochgeladen: http://download.tinkerforge.com/_stuff/red_brick_spi_test/ Falls jemand Lust und Zeit hat die neue SPI Protokoll Version zu testen wären wir über Feedback dankbar. Die Firmwares sind zueinander kompatibel, allerdings nicht zu älteren Versionen. Es sollte kein großer unterschied zu den alten Firmware Versionen vorhanden sein (was Geschwindigkeit, Latenz usw angeht). Zur Begründung des neuen Protokolls zitiere ich mal einen älteren Blog Eintrag: