Equinox

Hi, How does this work? If I block port 4280 for accesses from the Internet, I think (and hope) that no browser will be able to access the stack. Of course, if you want to access your stack from the Internet, that doesn't work either.

Hallo, Genau. Und außerdem ist das Hauptanliegen des RED Bricks, dass man einen Stack "stand alone" betreiben kann.

Hi, works great now!

Hello, I did some simple tests with the new Bindings. Everything worked fine except for the example in "ExampleSwitchSocket" for the RemoteSwitch-Bricklet. Error message: /home/pi/node_progs/tinkerforge/RemoteSwitch/ExampleSwitchSocket.js:24 rs.switchSocketA(17, 1, BrickletRemoteSwitch.SWITCH_TO_ON); ^ ReferenceError: BrickletRemoteSwitch is not defined at Object.0 (/home/pi/node_progs/tinkerforge/RemoteSwitch/ExampleSwitchSocket.js:24:33) at IPConnection.handleConnect (/home/pi/node_modules/tinkerforge/lib/IPConnection.js:280:70) at Socket.EventEmitter.emit (events.js:117:20) at Object.afterConnect [as oncomplete] (net.js:883:10) Replacing "BrickletRemoteSwitch.SWITCH_TO_ON" with "1" works fine. Setup: Tinkerforge stack is connected via WiFi Extension to a Raspberry Pi running Node.js in version v0.10.23.

Hi, please don't use port 80 as default. I suggest to use something uncommon that other servers aren't likely to use, i.e. please also don't use 8080, 8888, etc. I suggest e.g. 16880.

Meine volle Zustimmung!

Hallo, Zugegebenermaßen kenne ich nicht alle Bindings von TF, aber die "schlechte Unterstützung" sehe ich absolut nicht. Da TF ja auch schon vielfach im professionellen Bereich eingesetzt wird, scheint die Unterstützung auch dafür zu reichen. Klar bin ich auch für Verbesserungen, aber was ich bisher gelesen habe überzeugt mich nicht bzw. rechtfertigt in meinen Augen nicht, von "schlechter Unterstützung" zu reden.

Hallo, Das sehe ich ganz anders! Ich bin der Meinung, dass TF u.a. deshalb so erfolgreich ist, weil sie eben eine große Zahl an Sprachen unterstützen und noch mehr unterstützen wollen. Jeder hat eine Lieblingssprache und wenn die nicht unterstützt wird, dann ist die Chance, dass man das Produkt kauft schon ziemlich gering. Und wenn es gar die einzige Sprache ist, die man kann, dann wird man das Produkt wohl ziemlich sicher nicht kaufen. Außerdem ist man manchmal eben durch andere Produkte, mit denen man TF kombinieren will, auf eine bestimmte Sprache angewiesen. Da ist es dann einfach gut, wenn TF nicht der limitierende Faktor ist. Natürlich sollten die Sprachen auch gut unterstützt werden, aber meiner Meinung nach ist das bei TF ausreichend der Fall. Klar gibt es Dinge, die man bei einzelnen Sprachen verbessern kann, aber bisher konnte ich alles umsetzen, was ich wollte (zumindest bin ich noch nie auf ein Problem bei TF gestoßen, das auf einer "mangelhaften" Umsetzung eines Sprachkonzepts beruhte). Und jetzt OO-Konzepte krampfhaft überall einzubauen nur um der OO-Willen, halte ich für sinnlos.

Hallo, Ich bevorzuge diese Variante.

Hallo, Bei DynDNS gibt es noch immer eine kostenlose Variante. Diese hat den Nachteil, dass man sich einmal pro Monat explizit in seinen Account einloggen muss bzw. einen Link zur Verlängerung anklicken muss, da er sonst deaktiviert wird.

Hallo, So wie jetzt auch, oder? D.h. mit dem RED Brick muss ich zum Stapel gehen, diesen in den Bootloader-Modus versetzen und kann dann über den RED USB Host-Anschluss die Master Bricks flashen. Habe ich das richtig verstanden? Anders gesagt: Man kann zwar nicht komplett von Remote (über WiFi) flashen, aber man spart sich zumindest den Abbau des Stapels, oder?

Das wird nicht gehen. Zumindest nicht das ein beliebiger Teilnehmer im Stapel geflasht werden kann. Da werden wir erstmal bei USB bleiben müssen. Was meinst du mit "beliebiger Teilnehmer im Stapel"? Was würde denn gehen? Geht es über den USB-Anschluss des RED, d.h. wenn ich ein USB-Kabel vom RED zum Master Brick anschließe? Das würde notfalls auch reichen.

Hallo, einen Wunsch habe ich noch für die OnDevice-Lösung (egal für welche Variante ihr euch entscheidet): Bitte sorgt dafür, dass man alle Bricks und Bricklets (also auch die Master Bricks) ohne USB flashen kann, d.h., dass man die Firmware auch über WiFi. bzw. Ethernet updaten kann, ohne den Stapel "abzubauen". Meint ihr, dass das geht?

Hallo, ich bin kein PHP-Experte, aber ich denke, dass dein Code so funktionieren müsste. Hast du ihn ausprobiert? Hast du Probleme damit? Du musst nur eine einzige IPConnection haben, die du dann in jedem Konstruktor für die Bricklets verwenden kannst, also so, wie du es im Code schon machst.

Hallo, du brauchst die IPConnection im Konstruktor für jedes Bricklet. Beispiele für PHP für alle Bricklets gibt es hier: http://www.tinkerforge.com/de/doc/Software/API_Bindings_PHP.html#api-bindings-p

Hallo, Nur mal so zwischendurch: Muss Stepdown nicht das unterste im Stack sein?

Hallo, für deine Variante 4: http://www.ebay.de/itm/250886070022?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649

Hallo, Was heißt das genau? Geht die WIFI Extension nur nicht zum Hochschieben der Programme oder grundsätzlich nicht? Auch nicht bei der Variante mit Master Brick?

Hallo, kann ich davon ausgehen, dass in eurer Beschreibung überall wo "Ethernet" steht auch "WiFi-Extension" stehen könnte? D.h., dass ich in Variante 1 zum Hochschieben auch WiFi nutzen kann und ich in den Varianten 2 und 3 ebenfalls statt der Onboard-Ethernet-Schnittstelle auch eine (zusätzliche) WiFi Extension nutzen könnte? Oder bin ich zwingend auf die Onboard-Ethernet-Schnittstelle angewiesen?

Hallo, Klar, dass der Master nicht schön aufbereitete Strings bekommt, die er dann einfach weiterschicken kann, aber könnte man dem Master nicht die Informationen über den Aufbau der Daten für eine FID geben, so dass der Web-Server darauf zugreifen kann und die Daten dann als aufbereitete Strings weitergibt? Deshalb nochmals die Frage: Würde es überhaupt gehen (mit allen notwendigen Änderungen)? Mir ist klar, dass da mehr dahinter sein muss, als ein einfacher Server.

Hallo, Klar, aber es ist eine Frage des Komforts, ansonsten hätte man sich ja auch die ganzen Bindings bisher sparen können und nur das Protokoll veröffentlichen können. Die Bindings bieten aber ja wohl eine deutliche "angenehmere" API an. Und so ist es mit HTTP-Requests auch. Es ist doch einfacher einen simplen HTTP-Request abzusetzen (das kann man sogar komplett ohne Programmierung in jedem Browser) als sich die einzelnen Bits und Bytes für das TF-Protokoll zusammenzupfriemeln (das ich mir persönlich noch nicht einmal angeschaut habe). Klar, aber das ist ja immer so, auch bei den Bindings haben alle verschiedene Wünsche. Ich würde deshalb der Einfachheit/Realisierbarkeit den Vorrang geben und schlicht und einfach Strings zurückgeben. Damit sollte jeder zurechtkommen. Wenn es noch in XML oder JSON verpackt werden kann, ist das nett, aber aus meiner Sicht kein absolutes muss. Aber bevor wir uns über solche "Details" den Kopf zerbrechen, stellt sich doch die Frage, ob es überhaupt realisierbar wäre. Könnte man also auf dem Stapel so einen Web-Server implementieren (also simpler HTTP-Get Request der einfach nur einen String für den entsprechenden Wert zurückgibt)?

Wie schon mehrfach erwähnt, wären damit automatisch alle Sprachen abgedeckt, die HTTP-Requests absetzen können, also auch die, für die es keine Bindings gibt. Desweiteren könnte man ein einheitliches Programmiermodell über all seine Clients völlig sprachunabhängig realisieren und müsste sich nicht mit der Pflege unterschiedlicher Bindings auf all seinen Clients "herumplagen".

Was meinst du mit "man"? Den Entwickler? Falls ja, dann ist es einfach: Der Entwickler weiß, um welches Bricklet es sich handelt und damit weiß er, wieviele Getter es gibt. Abgesehen davon kann evtl. ja der Server feststellen, um was für ein Bricklet es sich handelt (wie beim enumerate). Auch das ist einfach: Immer einen String zurückgeben. Woher weißt du das jetzt? Ist nichts anderes ... Die braucht man natürlich auch, habe ich nur der Einfachheit halber weggelassen. Siehe mein voriges Post: Mit HTTP GET-Request.

Würde das denn grundätzlich gehen? D.h. wäre auf dem Stapel (egal ob auf Master, Extension oder gar Bricklet) soviel Platz, dass man den BrickD oder einen Proxy darauf implementieren kann, der die Funktionen mit Namen kennt? Falls nein, wäre es möglich, eine allgemeine Funktion dafür anzubieten, sozusagen ein "getValue()", das dann eben je nach Bricklet den entsprechenden Wert zurückgibt? Bei mehreren möglichen Werten, sowas wie "getValue(1)" und "getValue(2)" usw.?

Hallo, Ich glaube, die Frage, ob das im BrickD oder in einem vorgeschalteten Proxy passiert, ist für den Endbenutzer/Entwickler letztlich egal. Wichtig ist, *wo* das läuft, d.h. würde der vorgeschaltete Proxy dann auch auf dem Stapel laufen oder auf einem zusätzlichen Rechner. Wenn das auch auf dem Stapel ginge, dann wäre es wirklich genial.