Equinox

Hi,

So any website out there that you open in your browser can access your stack, even if you didn't expose port 4280 to the Internet.

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,

Also TF spielt seine Stärken sicherlich nicht über den Preis aus, sondern über die einfache Bedienbarkeit, die gute Doku, das Bauskasten Prinzip.....)

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,

... als alle möglichen eher schlecht zu unterstützen.

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,

dass man nicht jede Sprache unterstützen sollte. Lieber eine paar weniger dafür die anderen richtig.

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,

2. Die Spannung für die Messseite wird über den Brick durch einen DC/DC Wandler auf dem Bricklet bereitgestellt.

Ich bevorzuge diese Variante.

Hallo,

(Ich meine dyndns ist kostenpflichtig.)

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,

Das USB Host vom RED Brick ist ein ganz normaler USB Anschluss und kann auch genauso verwendet werden. D.h. das Flashen eines Bricks ist darüber auch möglich. Die Frage ist dann nur wie dieser in den Bootloader kommt.

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?

Zitat

 

    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?

 

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,

Im Stack zu unterst: Industry Digital I/O, dann Stepdown, Master, Wifi Extension. Bricklets hats sonst noch 3 PTC Bricklets.

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,

Die Unterstützung unserer WIFI Extension ist von uns nicht geplant.

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,

Der Master sieht sowas wie "FID=1, UID=xyz, length=20, data=[...]". Die Daten sind absolute Binärdaten, das könnte jetzt 20x uint8 sein, oder 5x uint32 oder nen string aus 20 Zeichen. Mehr Informationen sind nicht da.

...

Die Informationen die in den Bindings steckt, nämlich wie der Aufbau der Daten für eine gegebene FID ist, die hat der Master nicht.

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,

Mit TCP/IP und Websocket müssten nahezu alle Sprachen abgedeckt sein.

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).

Einen Art Miniserver könnte sich ja zukünftig jeder mit der On Device Programmierschnittstelle zusammenprogrammieren. Hier sind die Ansprüche viel  zu verschieden, der eine möchte JSON, der andere XML...

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)?

Also welche Anwendung würde diese HTTP-API nutzen, aber nicht die existierenden Bindings oder die angedachten JavaScript-Bindings nutzen können?

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".

Woher soll man wissen wie viele getValues es gibt?

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).

Woher soll man den rohen Datentyp wissen? (char, (u)int16, (u)int32)

Auch das ist einfach: Immer einen String zurückgeben.

Woher soll man wissen wie aus dem rohen Wert der "richtige Wert wird?

Woher weißt du das jetzt? Ist nichts anderes ...

Was ist mit settern?

Die braucht man natürlich auch, habe ich nur der Einfachheit halber weggelassen.

Aber mit was frage ich das ganze dann ab?

Siehe mein voriges Post: Mit HTTP GET-Request.

Das Problem, dass brickd dann aufmal alle Funktionen mit Namen usw. kennen müsste gilt auch für den Stapel. Dann müssten dort auf einmal auch alle Funktionen mit Namen usw. bekannt sein.

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,

Eine RESTartige Schnittstelle würde also eher als extra Proxy realisiert werden, der brickd vorgeschaltet wird. So ein Proxy stellt z.B. der listen Befehl der Shell Bindings dar, der über einen Socket Textbefehle entgegennimmt und dann weiss wie die getTemperature aussieht.

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.