borg

Da wir immer wieder anfragen bzgl. eines galvanisch getrennten Analog In bekommen haben wir mal ein paar Möglichkeiten durchgespielt. Das Industrial Analog In hätte (wie alle Industrial Bricklets) den grünen Steckbaren 8-Pol Stecker mit folgenden Eigenschaften (für alle Möglichkeiten): Komplett galvanisch getrennt von den anderen Bricks/Bricklets (über DC/DC Wandler) Auflösung 0,002µV (24 Bit) Genauigkeit (über kompletten Temperaturbereich) ca. 1mV Möglichkeit 1: Messbereich 0 - 30V 2 Kanal VK Preis: 28,99€ Möglichkeit 2: Messbereich 0 - 30V 6 Kanal VK Preis: 36,99€ Möglichkeit 3: Messbereich -30 - 30V 2 Kanal VK Preis: 37,99€ Möglichkeit 4: Industrial DAQ (Data Acquisition) Bricklet Messbereich -30 - 30V 2 Kanal Umschaltung zwischen Spannungs/Strommessung BNC Buchsen auf Bricklet Beinhaltet eine Schaltung wie die eines professionellen "DAQ" Könnte als Ersatz eines Multimeter genutzt werden VK Preis : 44,99€ Was meint ihr? Welche Möglichkeit würde euch am besten gefallen? Ist euch die galvanische Trennung überhaupt soviel Wert?

der connection state ist 0 weil du get_connection_state aufrufst bevor du connect aufrufst. Zu dem Zeitpunkt ist die Verbindung noch nicht hergestellt. Warum die Relais nicht schalten weiß ich allerdings nicht. Ist die UID korrekt?

Kannst du dein Perl Script hier posten? Ansonsten ist es schwierig etwas dazu zu sagen .

@Robin: As i said, the current version only supports Ambient Light, Barometer, Humidity and Temperature Bricklet. It is a very early alpha, i just started the project 4 days ago . Connecting when pressing enter is a good idea. It is a project that you can get into really easy. You can just clone the git, add some small features and make a pull request. After we accept the pull request it will automatically be available on brickv.com. I was hoping to get some help from the community with this project after we officially release the JavaScript Bindings, we will see if it works out .

I only tested in IE11, it should work in IE10. IE9 and below won't work. We will probably release the JavaScript Bindings with all of the needed updates for brickd/brickv and the firmwares (authentification and so on) in the end of march. So you will have to wait until then .

I would like to introduce an early alpha version of the Web Brick Viewer: http://www.brickv.com It is our attempt to implement a Bick Viewer-like tool with web technologies and new JavaScript for browser bindings. The current version supports Ambient Light, Barometer, Humidity and Temperature Bricklet. If you open http://www.brickv.com your browser will download an index.html and lots of JavaScript. After that everything is done in your browser and on your local PC, there is no communication with the internet whatsoever. You can also find brickv.com on github: https://github.com/Tinkerforge/brickv.com if you download it from there you can just open the index.html with your browser, there is no webserver necessary! This is currently just a small side project to test and debug the JavaScript Bindings in combination with HTML5 and modern browsers. I tried it on the latest versions of Firefox, Chrome/Chromium and IE. In IE you need to allow access to local intranet sites, see last answer here: http://stackoverflow.com/questions/15114279/websocket-on-ie10-giving-a-securityerror. If you want to help us develop a Web Brick Viewer, this is a very easy to understand project! It should be easy to get into. We would appreciate any help. The version that is currently online is compatible to the Brick Daemon release candidate that we released in this thread. Before we make an official release we will add authentication to our protocol and the Brick Daemon, which will then also be added to the Web Brick Viewer. At the moment the Web Brick Viewer is just a side project but the trend seems to go more and more towards smart phones and tablets instead of PCs. This means that it might be necessary for us to create access and configuration possibilities directly from Android/iOS/Windows Phone. So in the future it might become a replacement or supplement for the Desktop Brick Viewer. brickv.com should adjust itself to the resolution of your device (smart phone vs tablet vs PC) and delivery a UI that is best suited for your device.

Du bekommst dann jede ms einen neuen wert insofern sich der Wert seit dem letzten Callback geändert hat.

Ist gefixt, Danke!

Klar, das ist kein Problem. Du musst erstmal die neuesten Versionen von brickd und brickv installieren, dann die Bricks auf die neueste Version flashen und dann die Bricklets aktualisieren. Dann ist auch schon wieder alles auf dem neuesten Stand und du kannst loslegen . Hier gibt es eine ausführlichere Anleitung dazu: http://www.tinkerforge.com/de/doc/Transitioning_Guide_1To2.html

Ich weiß nicht ob ich dein Problem richtig verstehe, aber das Tilt Bricklet besteht ja nur aus einer Röhre mit einer Kugel drin. Wenn die Kugel unten aufliegt ist ein Schaltkreis geschlossen und sonst nicht. D.h. Die Kugel fängt schon ab 45° oder so das rollen an und schließt den Schaltkreis, dadurch ist dann aber dein Tisch noch nicht waagerecht?

I just tried it in Eclipse and i get the same two errors. But after formatting the js around that place a little better so it is human-readable i can't find a problem. I think the Eclipse parser is either not able to parse the relatively complex output of browserify or it has problems with ECMA 5. The eclipse i have only seems to be able to understand ECMA 3, while the code might need a ECMA 5 parser. The Javascript for Browser Bindings will only support the (currently) latest Browsers and versions up from here. The latest Firefox, Chrome, Safari and even IE are very standard compliant and compatible regarding JavaScript and Websockets. If you go only 2 or 3 versions down it suddenly becomes a minefield .

LabVIEW Bindings verfügbar Blogeintrag

LabVIEW Bindings available Blog entry

Das LED Strip Bricklet kann nur LED Strips steuern die einen WS2801 IC verwenden, also keine "normale" weiße LED Strips. Vielleicht würde es in deinem Fall folgender Aufbau Sinn machen: * Motion Detector Bricklet * Remote Switch Bricklet * Funksteckdose deiner Wahl * LED Strip an Funksteckdose Damit kannst du dann die Funksteckdose per Remote Switch Bricklet schalten sobald das Motion Detector Bricklet etwas sieht. Keine Elektrozeugs notwendig .

Ich hab gerade schnell das Datenblatt vom MC33926 überflogen (der Treiber IC den wir verwenden), ich befürchte das ist nicht möglich mit dem IC . https://github.com/Tinkerforge/dc-brick/raw/master/datasheets/MC33926.pdf

@Shield: Der Vorteil von einem Shield gegenüber einem USB Kabel (egal welches Development Board) ist ernsthaft marginal. Das Shield verkompliziert es nur (zusätzliche Treiber notwendig etc). Ich schreibs mir mal auf meine TODO Liste eine Halteplatte für den RPi zu machen und ~15cm Mini USB Kabel zu besorgen. Dann haben wir auch ein "Shield" .

So 100%ig wissen wir nicht was da Sache ist. Wenn wir das richtig sehen hatten ein paar der Solid State Relais der letzten Produktion einen zu hohen Innenwiderstand wodurch es zu Spannungsabfällen kommt. Grundsätzlich funktional sind sie, aber offensichtlich machen einige Verbraucher Probleme (siehe diesen Thread ). Schick ruhig auch eine Email an info@tinkerforge.com, wir können es auf jeden Fall versuchen das Quad Relay auszutauschen um zu sehen ob du dann die Kamera schalten kannst.

@salomon: Melde dich mal mit der Bestellnummer bei info@tinkerforge.com. Wir haben jetzt eine neue Charge Quad Relays hier und würden alte die Probleme haben hohe Ströme zu schalten austauschen.

Das Industrial Digital In Bricklet ist für die Anwendung auf jeden Fall besser geeignet, da die negativen Spannungen dort auf Grund der galvanischen Trennung keinerlei Auswirkung haben. Warum die Diode hier keine Wirkung zu zeigen scheint weiß ich allerdings auch nicht. Da müsste man genau nachmessen welche Spannungen beim Bricklet nun noch ankommen.

Thank you for the testing. I think we may remove pm-utils as a dependency and add documentation that indicates that you need pm-utils if you want the Bricks to always behave properly after suspend to disk/ram. If you don't use suspend to disk/ram (like on the RPi) you don't need pm-utils anyway...

@pluto: Vielleicht einmal ganz vorn vorne: Wir haben ein System mit dem man einfach mit vielen Programmiersprachen ohne Erfahrung in der embedded-Programmierung oder von Hardwareentwicklung mit der Umwelt interagieren kann. Jetzt gibt es das verständliche Bedürfnis dieses System "Standalone" zu betreiben. Dieses System ist aber technisch nicht auf einem atmega und auch nicht auf den viel Leistungsstärkeren Cortex-M3 die wir verwenden implementierbar. Nun haben wir für Sandalone-Lösungen immer auf das RPi/BeagleBaord/CubieBoard/etc verwiesen und wir bekommen immer wieder gesagt dass dies zu kompliziert ist. Mit dem RED Brick werden wir nun eine Möglichkeit bieten ein auf dem PC programmiertes und getestetes Programm auf ein Modul zu bringen welches man in den Stack steckt. Dies wird in 90% der Fälle ohne jegliche Kenntnisse von Linux-Konfiguration oder ähnlichem möglich sein. Die Tatsache das ein Linux auf dem RED Brick läuft ist nahezu irrelevant. Ich hätte auch noch eine Metapher anzubieten : Ich kann hergehen und mir mit dem RPi eine Funksteckdose bauen die ich per Webbrowser bedienen kann: http://www.openhomeautomation.net/control-a-relay-from-anywhere-using-the-raspberry-pi/ Oder ich kann eine fertige Funksteckdose nehmen die genau das tut: http://www.amazon.de/Belkin-WeMo-Automation-Switch-Android-Ger%C3%A4te/dp/B008TPVZNY Technisch sind die beiden fast gleich. Sowohl auf der WeMo Funksteckdose als auch auf dem RPi läuft ein Linux mit Webserver und einem kleinen einfachem Steuerprogramm. Dadurch verliert die Steckdose aber nicht ihre Daseinsberechtigung . Das RED Brick ist eben nicht "yet another development board", auch wenn es technisch sehr ähnlich ist.

Der SPI Treiber ist noch nicht geschrieben, ist also schwer zu sagen wie portabel er ist . Die Vorteile eines RPi-Shields gegenüber einem USB Kabel sind marginal, das macht nicht viel Sinn. Da wäre schon eher eine Art Halteplatte Sinnvoll wo man das RPi sowie Bricks/Bricklets befestigen kann. Naja, das ist jetzt Ansichtssache. Wir schaffen mit dem RED Brick das, was mit großem Abstand am meisten angefragt wird bei uns: Eine Möglichkeit das Java/C#/PHP/Python/etc Programm in den Stack zu bekommen. Warum ist es dann nicht eigenständig, nur weil ein Linux darauf läuft?

I don't think that is practical. You can't determine what subnet the local network uses. But it doesn't matter, both options also protect the Ethernet and WIFI Extension .

Then the attacker would indeed have to know the IP of the WiFi-Extension. There is no way for the browser to scan your network or similar.

Both options are completely backward compatible. With option 1 the authentication only touches the new websocket bindings and with option 2 the default will still be that authentication is off.