borg

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

Ich würde den Bricklets einfach ein bisschen mehr Zeit geben damit sie sich akklimatisieren können. Ich könnte mir vorstellen dass das vierte Baromter Bricklet nach ein paar Tagen aufhört davonzudriften .

Die anderen uniTEC Funksteckdosen (48110 etc) sehen genauso aus wie die von Elro, die sind bestimmt kompatibel. Die EIM-826 scheint mir ein Auslaufmodell zu sein, ich kann sie zumindest nicht bei den großen Online-Händlern finden. Ich weiß nicht ob es sich lohnt für ein einzelnes Funksteckdosenmodell was es kaum zu kaufen gibt Unterstützung einzubauen . Wie gesagt, eine Geräteliste vom Hersteller wäre praktisch, damit man sich einen Überblick machen kann. Aber ich kann noch nichtmal eine Homepage von uniTEC finden .

Schwer zu sagen, diesen Gong von Conrad haben wir nicht getestet. Wir haben bisher nur die Gongs von Elro und Intertechno getestet. Eventuell funktioniert das anlernen nur zufällig, der Conrad-Gong spricht aber im Endeffekt dann doch ein anderen Protokoll?

Das ist beides OK, da gibt es keine Schwierigkeiten. Nur wenn du über LAN und USB gleichzeitig kommunizierst funktioniert das Messagerouting bei Callbacks nicht mehr.

Es gibt schon erste Fortschritte: http://www.tinkerforge.com/de/blog/2014/2/21/tinkerforge-goes-stand-alone-aka-red-brick

Some progress has already been made: http://www.tinkerforge.com/en/blog/2014/2/21/tinkerforge-goes-stand-alone-aka-red-brick

Tinkerforge goes Stand-Alone aka RED Brick Blog entry

Tinkerforge goes Stand-Alone aka RED Brick Blogeintrag

I just added a miniature version of a websocket server to brickd: https://github.com/Tinkerforge/brickd/commit/45b8da4a27af5c61054ea8093e2a1149784e7b23 It needs some more testing before we can publish it as a beta, but i already have a question about some details: What do you think would be the right port for the websocket server in brickd? I am currently using port 80 (as defined in the standard). But this will obviously interfere with normal webservers if they happen to run on the same machine. Do you think we should use a default websocket port that is different from 80? Independent of the default port you can change the port in the brickd config of course.

Ein Beta-Release für den Browser machen wir Ende dieser Woche oder Anfang nächster Woche, solange musst du dich noch gedulden .

Eine erste Beta-Version der JavaScript Bindings ist fertig: http://www.tinkerunity.org/forum/index.php/topic,2216.msg14527.html Feedback etc wenn möglich bitte auf englisch. Die Bindings unterstützen aktuell nur Node.JS, allerdings wird Unterstützung für den Browser bald folgen, es fehlt lediglich noch die Implementierung eines WebSocket Servers in brickd. Für die Ethernet Extension existiert bereits eine. Eine Implementierung für die WIFI Extension wird nach dem Release folgen wenn klar ist dass die JavaScript Bindings auch wirklich Anklang finden. Dies ist leider sehr viel Aufwand.