AuronX

Wäre es nicht (für Lötfreunde) möglich, den Reset-Taster am Masterbrick des Stapels durch das RED-Brick auszulösen? Ungefähr so (Achtung, ich weiß nciht was ich rede): 1. Reset-Knopf am Master ablöten 2. GPIO-Ausgänge die am RED übrig sind auf Kontakte des Reset-Knopf auflöten 3. per Software Reset auslösen

Wenn ich die Frage richtig verstehe, dann steht die Antwort hier: http://www.tinkerforge.com/de/doc/Software/Bricklets/IndustrialQuadRelay_Bricklet_C.html#industrial_quad_relay_get_monoflop

Tut mir leid, das hätte ich in meinem Originalpost klarer kenntlich machen sollen. Ich bezog mich tatsächlich lediglich auf den Einsatz im Rahmen von PHP-Webseiten

Grundsätzlich muss ich bei den PHP-Bindings sagen, dass ich auf den EInsatz von Callbacks verzichten würde. Das liegt daran, dass die PHP-Bindings Callbacks nur sonderbar unterstützen. Du musst eine blockierende Methode aufrufen, die die Callbacks bearbeitet, dafür passiert aber sosnt nix tolles... Also mein Tipp: Bei PHP keine Callbacks Den anderen Teil deiner Frage habe ich nicht so recht verstanden. Aber es reicht wenn du eine IPConnection für viele Bricklets nutzt.

Ist die Kommunikation über SPI wirklich so viel besser als USB? Kann ich mir nicht vorstellen. @TF: Habt ihr da eine Erwartungshaltung zu?

Wie du vielleicht gelesen hast (oder auch nciht, ist etwas begraben glaube ich) kann diese spezielle Kanone nicht mehr als 1000 Messages pro Sekunde... ich würde sagen nimm den Pi, wenn du im RED keinen Vorteil siehst edit: falsche zahl korrigiert ^^

Auf der von dir verlinkten Seite ist oben rechts ein Panasonic-Logo ^^ Aber eigentlich wollte ich das beitragen: Ich habe diese speziellen Akkus auch inzwischen überall im Einsatz, weil sie einfach gut sind. (Unabhängig von TF-Anwendungen) Insbesondere haben sie nahezu keinen Leistungsverlust bei Lagerung (einige andere Akkus die ich habe sind nach einem Monat nicht mehr ohne erneutes Laden brauchbar)

Ah verzeihung, den Link habe ich übersehen... bzw. ich dachte da würde was WRT-spezifisches kommen ^^

Gab es da nicht ein Poti (Drehregler) um den Kontrast einzustellen? Klingt für mich nach verstelltem Kontrast... Die Fotos die hier alle posten sehen immer sehr gut ablesbar aus...

IDE finde ich schwierig... Immerhin ist es ja schon das ambitionierte Ziel alle verfügbaren Sprachen/Umgebungen durchs Hochladen zu unterstützen... Jetzt auch noch für alle davon eine IDE halte ich für übertrieben...

Das Pi ist nur deswegen so billig weil es auch in größeren Stückzahlen produziert wird befürchte ich. Sobald du das Hardware-Layout anpasst musst du dich ja wieder selbst kümmern. Ansonsten benutzen ja viele (mich eingeschlossen) schon heute einen Pi um den Stack anzusteuern.

Ist schon klar, aber AuronX schlägt vor die HDMI wegzulassen, wie kann dem Benutzer dann das GUI vermittelt werden ?! Sorry meine Frage bezog sich quasi auf Variante 0,5... aber bei den Preisen ist das schon eher Unsinn das wegzulassen ^^

Ich frage mich auch ob es nciht lohnen würde HDMI und USB-Host wegzuwerfen... Ethernet wäre ja auch verzichtbar, wenn ich das Setup über Mini-USB machen würde könnte.

Wie borg schon sagte können ja all diese Sprachen bereits TCP, also sind sie bereits heute abgedeckt. Das einheitliche Programmiermodell wird doch weitestgehend durch die Bindings erreicht. Das heißt Tinkerforge baut für dich die Bindings die du dann einsetzen kannst um dich nicht darum scheren zu müssen wie die Kommunikation wirklich aussieht. Wenn du tatsächlich dein HTTP-Protokoll nutzen wolltest oder aber das existierende TCP-Protokoll (ich sehe da keinen Unterschied (@Loeti: netcat ^^)), dann müsstest du dich pltzöich selbst um alles kümmern und dir die Abstraktion vom Kommunikationskanal auf deine Programmierumgebung schaffen. Effektiv hast du dann deine eigenen Bindings gebaut. Auf jeden Fall wäre TF damit nicht "automatisch" überall unterstützt. Sehe ich ebenso

Ja klar. Aber was nützt dir das? Was ist das höhere Ziel das du erreichen willst? Also welche Anwendung würde diese HTTP-API nutzen, aber nicht die existierenden Bindings oder die angedachten JavaScript-Bindings nutzen können?

Equinox, wenn du über deine Frage noch einen Moment nachdenkst wirst du merken, dass das nicht funktionieren kann. Woher soll man wissen wie viele getValues es gibt? Woher soll man den rohen Datentyp wissen? (char, (u)int16, (u)int32) Woher soll man wissen wie aus dem rohen Wert der "richtige Wert wird? Was ist mit settern? Und viel wichtiger: Was würde das ganze am Ende denn nützen? Dann habe ich irgendeinen Dienst den ich wieder nach irgendetwas fragen kann. Aber mit was frage ich das ganze dann ab? Der Client muss ja doch wieder irgendein Protokoll sprechen. Mir erschließt sich nicht an welcher Stelle ein Web-Service mächtiger/portabler wäre...

Auf jeden Fall! Ich bin wieder nicht auf den guten Gedanken gekommen den brickd zu erweitern. Wäre das auch auf den TCP-Extensions (WLAN/LAN) implementierbar? Weil ansonsten natürlich wieder ein Ungleichgewicht entsteht das unter Umständen schwer erklärbar ist... (JS geht nur mit "vanilla" brickd, aber nicht mit Extensions) Ansonsten eine sehr coole Idee. Es wäre ja trotzdem möglich den "Online-Brickv" auch herunterzuladen und auf einem eigenen Server zu platzieren.

Node.js ist im wesentlichen ein eigener Server der mittels Javascript programmiert wird. Das heißt du nutzt Javascript als Programmiersprache, hast aber mehr API für Dinge, die im Browser nicht gehen/gewollt sind: Dateizugriff, echte Sockets usw. Der Unterschied ist also, dass es eigentlich zwei Dinge sind: 1. JavaScript eine Sprache 2. node.js: Ein Server der JS ausführt und dazu API in JS bereitstellt die es im Browser nicht gibt Vor- und Nachteile sind wohl Geschmacksfrage Das würde nicht für node.js gelten. JavaScript-Bindings im Browser halte ich derzeit für nicht umsetzbar, aber ich bin tatsächlich nicht all-zu bewandert auf diesem Gebiet

1. Vermutlich gehört die RPC-Diskussion in einen extra Thread weil es keine neue Sprache wäre... 2. Ich sehe nicht wo das den Standalone-Betrieb erleichtert Kein Rechner: Keiner stellt anfragen an den Webservice Smartphone: Objective-C / Java und alle sind glücklich mit den existierenden Bindings

Ich kann deine Frage leider nicht selbst beantworten. Bevor du aber zu lange auf eine Antwort warten musst versuche ich es so: Wusstest du, dass TF alle Schaltpläne usw. auch auf Github veröffentlicht? Hier ist der Schaltplan fürs Step-Down... und hier viele andere Dateien... Ich habe keine Ahnung was diese Striche und Zahlen bedeuten... Aber du vielleicht schon

Ich glaube die 15% beziehen sich auf Kelvin... bin da aber nicht 100% sicher und vermutlich sollte es auch erwähnt werden wenn es so wäre ^^

Könntest du bitte nocheinmal prüfen ob die Temperatur in deiner Wohnung... oh okay, das hast du schon geprüft! Dann: Hast du die korrekten UIDs eingetragen? Holst du dir die Temperatur auch über den out-parameter von temperature_get_temperature? Wie ist der Rückgabewert von temperature_get_temparature? Schau dir auf jeden Fall auch die Dokus zu den einzelnen Bricklets an, z.B. diese

Ich vermute es geht so: position = js.get_position() print position.x print position.y Aber das ist geraten und eine google-suche nach python named tuple würde mich vermutlich weiterbringen... edit: http://stackoverflow.com/questions/2970608/what-are-named-tuples-in-python

Wie sollte dieses blockieren denn funktionieren? In den Bindings geht es vermutlich nicht, weil die generiert werden. Im Bricklet-Code geht es nicht, weil die Bindings (aus gutem Grund) ein Timeout haben. Oder verpasse ich da etwas?

Was wären denn die Konsequenzen aus einer zusätzlichen Antwort? Also ja: Die API würde streng genommen gebrochen, aber was passiert dann? Für jemanden der mit neuer Firmware auch neue Bindings nutzt Nichts, denn aus void wird int (o.ä.) und das ist echt ungefährlich. Nahezu jeder Code sollte vorher und nachher kompilieren (Ausnahme: Func<TResult, ...>). Einziges Problem: Neues Timing + Es kann Timeouts geben Für jemanden mit neuer Firmware und alten Bindings Das ist mir nicht ganz klar... ich glaube aber mich zu erinnern, dass unerwartete Antworten von den Bindings verworfen werden... sollte also gar kein Problem sein. Für jemanden mit neuer Firmware und ohne Bindings (TCP) Okay... der hat je nachdem wie er es implementiert hat wirklich ein Problem... aber ich weiß nicht wie wichtig dieser Use Case ist... Frage: Ist das vertretbar? (Habt ihr so viele Nutzer die das tatsächlich schmerzen würde) (jetzt kommt der allgemeine Teil) Die Alternative zu solchen inkompatiblen Änderungen ist ja immer nur eine schlechte API. Entweder schlecht weil die existierenden Probleme nicht behoben werden oder schlecht weil es zu viele Methoden gibt die nur aus Kompatibilitätsgründen existieren... Vorschlag: Vielleicht solltet ihr über soetwas wie deprecation nachdenken... Also halt jetzt eine neue Methode einführen die den Rückgabewert hat (und einen ordentlichen Namen) und die alte Methode deprecaten, damit ihr sie in einem halben Jahr löschen könnt... ich fürchte aber, dass das aufgrund eures knappen Speichers auf den Bricklets nicht überall klappen wird...