borg

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.

Also h3 driftet ständig über Wochen hinweg verglichen mit den anderen Bricklets? Das ist echt komisch. Da kann ich dir nur anbieten das wir das Bricklet austauschen. Melde dich mit der Bestellnummer bei info@tinkerforge.com falls das eine Option ist.

The risk is the same as before, but i can see your point. It is easier to get me to open a malicious website that uses port 4280 then to plant a malicious program on my pc that uses port 4223. I see two possible ways to prevent an attack from a random malicious website: 1. We use the origin field from the websocket handshake. In this case the user would have to give the brickd or Ethernet Extension a list of websites that are allowed to connect. The problem here is that we can't store a big list of websites on the Ethernet Extension, perhaps two or three? Another problem is that URLs are allowed to use any UTF8 character nowadays, we may have problems handling some URLs on the Brick because of that. 2. We (mis-)use the Sec-WebSocket-Protocol field of the websocket handshake and add a passphrase to our protocol that has to be configured for the Ethernet Extension or brickd. This would stop the attacks from a random malicious website but it couldn't do anything against "man-in-the-middle" attacks for obvious reasons. But for security relevant projects where you fear that someone is trying to actively attack your Bricks/Bricklets you should only allow secure connections from a VPN or similar in any case! Edit: We could also add the passphrase to the Request-Line field of the websocket handshake. That would probably make more sense, we wouldn't have to misuse any of the handshake fields.

Das ist alles weniger schwierig als du es dir vorstellst. Wir werden da einfach ein Debian verwenden und zusätzliche Pakete hinzufügen (für brickd, brickv, Bindings, Interface zum hochladen von Programmen, usw). Updates und Sicherheits-Updates kommen weiterhin ganz normal über Debian. Das dürfte auch einen Großteil deiner anderen Fragen klären: Das RED Brick ist ein kleiner Linux PC mit 1GHz, 512MB RAM, Debian und kann wie ein ganz normaler Linux PC genutzt werden. Man kann den RED Brick aber auch als "Blackbox" betrachten auf die man über den Brick Viewer oder ein Webinterface sein vorher am PC entwickeltes Programm hochläd welches dann Standalone im Stack ausgeführt wird. So werden wir es bewerben .

Swiss Reseller Blog entry

Wiederverkäufer in der Schweiz Blogeintrag