borg

RED Brick Software-Infrastruktur Blogeintrag

Wo steht das man das "tinkerforge." entfernen soll? Das solltest du nur entfernen wenn die ip_connection.py und die brick_master.py usw im gleichen order wie das auszuführende Script liegt. Du schmeißt da alles ein wenig durcheinander . Wenn du die .egg installierst brauchst du den tinkerforge/ Order selbst nicht mehr, da die Python library direkt im System installiert wird. Oder andersrum: Wenn du den tinkerforge/ Order da hast wird nicht der Kram benutzt der über das .egg im System installiert ist.

Die IP Verbindung wird zum Brick Daemon aufgebaut, die ist auch im anderen Beispielprogramm. Kannst du die neue Exception hier nochmal posten?

Wo hast du den Code denn weg? in deiner Exception steht etwas von "xip_connection", das kommt aber im Code gar nicht vor. Kann es sein das sich da irgendwie aus versehen ein zusätzlich "x" eingeschlichen hat was da nicht hingehört?

Auf einen Master Brick kann man maximal 8 weitere Master Bricks stecken. An diese wiederum können je 4 Bricklets angeschlossen werden. Summa summarum macht das maximal 36 Sensoren.

Du solltest dich ohne etwas in der brickd.config einzustellen mit dem Brick Viewer auf localhost:4223 (host:port) verbinden können.

Das ist komisch. Tritt das Problem denn nur auf wenn du alle Bricklets am Master hast? Oder tritt das Problem auch schon auf wenn du nur ein Temp IR am Master hast?

Naja du kannst eine aspx Anwendung mit mono auf dem RPi schreiben, das ist kein Problem. Dafür musst du natürlich ein Webserver einrichten (sowas wie Apache und nginx). Eine kurze google Suche hat mir diese Anleitung direkt fürs RPi gefunden: http://www.mikeobrien.net/blog/configuring-nginx-mono-and-asp-net-on-raspberry-pi/

Was sagt die Ausgabe von "dmesg" nachdem der Master neu gestartet hat? Ist ein Hub zwischen Master und PC?

Cool . Wie stellst du sicher dass das Licht nicht in die Nachbarelemente reinstrahlt? Hast du eine dicke MDF Platte verwendet wie in dem mikrokontroller.net Artikel?

Kannst du mal die angehängte Master Firmware ausprobieren? Ich hab mal Testweise die USB Hotplug Erkennung ausgebaut. Ich halte es zwar für unwahrscheinlich das es dran liegt, aber hier im anderen Thread hat es für einen Aufbau mit Stepper Brick geholfen: http://www.tinkerunity.org/forum/index.php/topic,2309.0.html Falls es daran liegt sollten wir vermutlich die Hotplug Erkennung komplett rausbauen, sie ist sowieso nur in relativ seltenen Fällen sinnvoll, wo man dann auch den Reset-Taster betätigen kann. Edit: PS: Sowohl auf dem Dual Relay Gehäuse als auch auf der Halteplatte sitzt noch eine abziehbare Schutzfolie Edit: Veraltete Firmware entfernt.

Abstrus! Kannst du denn die erste HE877 als Typ C anlernen? Ich kann das mit den Steckdosen die ich hier hab nicht reproduzieren . Komisch ist das vor allem weil Typ A und C ein sehr ähnliches Protokoll haben während Typ B stark abweicht von den beiden.

Wir bekommen da nur einen Analogwert raus, die eigentliche "Berechnung" wird komplett in Hardware gemacht. Man kann da denke ich also nur mit Averaging rumspielen um Peaks abzufangen.

Möchtest du die JavaScript Bindings für Browser oder für node.js nutzen? Die npm Zeile ist nur für node.js. Zum testen kannst du einfach eines der Beispiele im Browser öffnen und ausprobieren: http://www.tinkerforge.com/de/doc/Software/Examples/JavaScript/Temperature_Bricklet_JavaScript_ExampleSimple.html Vergiss nicht websockets im brickd freizuschalten: http://www.tinkerforge.com/de/doc/Software/Brickd.html#websockets Zum programmieren später muss nur die Tinkerforge.js irgendwo liegen wo der Browser sie finden kann. Im Beispiel also im gleichen Verzeichnis wie die .html.

http://www.tinkerforge.com/de/blog/2014/5/21/red-brick:-tut-es-oder-tut-es-nicht

RED Brick: Tut es? Oder tut es nicht? Blogeintrag

RED Brick: Does it work? Blog entry

You can set the frequency of your measurements with set_debounce_period and then use the CALLBACK_INTENSITY_REACHED by setting an intensity threshold (set_intensity_callback_threshold) of something like "smaller than 4095", so it is always active.

Wenn der PC das LED Strip Bricklet erkennt, heißt es nicht unbedingt das die LED Pixel korrekt angeschlossen sind am Bricklet. Es kann zum Beispiel einfach passieren das man die LED Pixel von der falschen Seite her anschließt oder die Stromversorgung könnte falsch angeschlossen sein.

Kannst du Fotos von der Verkabelung machen?

There is no commercial reason behind this whatsoever (besides us not wanting to invest the time). It is all about usability. It would absolutely be a pain in the ass to use. It wouldn't be possible to debug it without having a logic analyzer or similar. You can't just add a print to an intermediate state of the I2C communication to see what is going on for example. It would be a lot harder to use than Arduino, which kind of defeats the purpose.

Das hat keine große Auswirkung. Wenn du den Stepper Brick über eine Step-Down Power Supply versorgst und dann den USB Stecker reinsteckst wird dies nicht erkannt. Du musst dann den Reset Taster betätigen damit der Brick erkennt das USB eingesteckt ist.

We have looked at the CMUcam5 Pixy already, it is indeed pretty cool. I could imagine a "Cam Brick" that connects to the CMUcam5 Pixy and translates their API to our system, so you can use it with all of our languages. A Bricklet that speaks I2C/SPI or API for the IO4 for I2C/SPI is not planned. We discussed that internally and we think it doesn't fit into our system.

Unfortunately the hardware of the Bricklet can't do more than to set a frequency between 585Hz and 7100Hz and turn the frequency on and off.

Something like an additional "displayValue(uint16 value, bool useTrailingZeros)" wouldn't hurt in the API. I wrote it on my TODO list (which is pretty long ). But in the meantime i think you could also use startCounter with valueFrom and valueTo set to the same value.