Nic

Nehmen wir an du kannst das Nadelöhr USB irgendwie umgehen und der HostPC bzw. RED empfängt und verarbeitet die Interrupts und Bricklets ohne Umweg dann kommst du mit den TF-Teilen niemals schneller als 1ms: http://www.tinkerunity.org/forum/index.php/topic,2525.msg16509.html#msg16509 und http://www.tinkerunity.org/forum/index.php/topic,2127.msg14118.html#msg14118 Ich würde mal sagen, dass die TF Firmware und Protokoll quasi wie im Zeitscheibenprinzip konzipiert ist.

Du sprichst von mehreren Lichtschranken (?), wieso reicht nicht eine Lichtschranke am Zielpunkt ? Es kommt noch hinzu dass die Interrupts (je Lichtschranke) bedingt durch den USB m.W. nicht parallel beim PC auflaufen wenn 2 Wagen auf die ms gleichzeitig durchs Ziel jagen. Du triggerst nur die Zeit, wenn der Callback sich in deinem Programm meldet.

Wenn damit Node.js auf dem RED Image 1.3 gemeint ist, stimmt das so nicht. Ich hatte eine Node.js Anwendung mit einem Http-Server in wenigen Min. auf dem RED erstellt. Ohne irgendein Package nachzuinstallieren.

Alternativer Ansatz serverseitig und ev. mit angenehmeren Sprachdialekt als Phython (Geschmackssache ) mit Node.js bzw. Javascript und ev. in Kombination mit den Websockets. Node.js ist im RED enthalten und mit http.createServer erzeugt man einen kleinen Webserver der auf Requests vom Browser lauscht. Beispiel unter http://www.sitepoint.com/creating-a-http-server-in-node-js/. Websockets werden z.B. in der Beispielanwendung von TF IOT http://www.iot-remote.com/ ganz gut gezeigt.

Sockets werden zum Zweck der Kommunikationsschicht in der Tinkerforge API intern verwendet. Remotecontrol meinte eher an ein eigenes, selbstgeschriebens Protokoll von dir, das ebenso Sockets verwendet. Ev. würden Websockets besser passen als ein Komm.Protokoll neu aufzurollen. Mittels der Websockets die dann spätestens im Image 1.4 vom RED unterstützt werden, sollten sich sich Web-Anwendungen schreiben lassen, die im Android z.B. nur den Browser erfordern.

Mit dem RED wurde quasi der HostPC näher zu den Bricks/Bricklets gebracht, d.h. die Kommunikation über USB ist dann nicht mehr gegeben. Der RED kommuniziert intern mit den Bricks über das SPI Interface. Allerdings bedingt durch die USB Anbindung von Anfang an, ist auch das interne SW-Design ausgelegt auf höchstens 1ms Auflösung egal ob nun via USB oder SPI. Was noch noch gar nicht erwähnt wurde, ist die IO Schnittstelle am RED die bisher sw-und hw-seitig noch nicht unterstützt wird. Aber ich bezweifel ob damit wesentlich schnellere Verarb. als mit den Brick-Teilen möglich ist, dann wird das zum Tragen kommen was borg schon bzgl. der Betriebssystem-Limits erwähnte. Mich würde interessieren warum der Verlust von 10-20ms dir zu lang ist ?

Würde ich nicht zulassen und bis es den angekündigten Nachfolger geben wird http://www.tinkerunity.org/forum/index.php/topic,2643.msg17235.html#msg17235 kannst Du mir alternativ solange deinen RED gerne überlassen

Also ich ziehe einfach den USB Stecker und dann ist der Stack nicht mehr unter Strom. Das hatte bei den deployten Programmen bisher keine negativen Auswirkungen. Allerdings wurden auch keine Schreibvorgänge gemacht. Für solche Anwendungen reicht es den Strom per Schalter zu unterbrechen, idealerweise bei der Eingangsspannung ins PowerSupply. So habe es gerade als root auf der Console ausprobiert, geht prima: shutdown -h now. Damit fährt man den RED runter. LEDs glühen ein wenig nach und dann nach etwa 2-3sec. geht alles aus. Restart mit Knopfdruck am RED. shutdown -r 1 Löst z.B. ein Restart in 1 Minute aus. Hab es getestet. Keine Ahnung ob man sowas ev. von außen auslösen könnte etwa über die Shell-Bindings und das Event Knopfdruck auf Lcd, Button Bricket etc programmatisch abfangen.

Ein Brick Stack ist dauerhauft unter Strom solange USB Kabel gesteckt oder das PowerSupply mit Strom versorgt ist. Auf allen Platinen befindet sich kein PowerOn/off. Ausnahme der Red: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#power-button

Wenn damit die einzelne Schraubklemme gemeint ist wo unten +/- und darüber "Only Output" steht dann kann man aus der Doku zitieren "Eine zusätzliche Schraubklemme führt die gewählte Spannung nach außen."

Kann es sein dass ihr beiden einfach nur die tatsächliche Luftfeuchtigkeit der Umgebung erfasst, und noch etwas Meßungenauigkeit den Wert auf die volle 100% schiebt ? Hier auf der Karte sieht man deutlich wie es in Deutschland bzgl. Feuchte aussieht: http://www.neuwetter.de/vorhersage/luftfeuchtigkeit.html Norddeutschland zw.97-100% ! Zum Testen den Sensor in der Wohnung "trocknen" lassen und prüfen wie sich der Messwert verhält.

@Zikke Bist du sicher dass die WIFi Extension mit dem RED funktioniert ? Bis jetzt werden nur die Ethernet und RS485 unterstützt... http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#brick-stapel-stecker

Erst mal eine Gegenfrage, warum geht der RFID Bricklet nicht ? http://www.tinkerforge.com/de/doc/Hardware/Bricklets/NFC_RFID.html Überschätze Linux nicht zu hoch Meine Linux Kenntnisse waren auch bei NULL, zwar bin ich mit VC20, c64, DOS/Win3.x aufgewachsen, aber erst durch den RED habe ich angefangen mich mit Linux richtig zu beschäftigen. Ich möchte nicht behaupten, daß ich da schon fit bin. Aber es ist meistens eine Gewöhnungssache, bzw. mir ist es schon gelungen, Hardware und neue Software per Console zu installieren. Und was das Programmieren, Hochladen und Deployen von eigenen Programmen angeht, so war das beim RED in etwa 10 Min. erledigt und lauffähig .

Habe die aktuelle Version von Iceweasel v31.4 (=Firefox) auf den RED installiert. Unter https://html5test.com bekomme ich einen Score von 426, Websockets werden komplett unterstützt. Aber beim EnumExample bekomme ich weiterhin eine Error 13. Vermutl.identisch mit http://www.tinkerunity.org/forum/index.php/topic,2788.msg17706.html. Der Workaround/Bugfix löst aber nichts, der BrickD kann nicht wieder gestartet werden.

Ich habe den RED auf Websocket-Kompatibilität mit https://html5test.com/ getestet, die Ergebnisse sind positiv. Warum geht es dann nicht mit dem EnumExample ?

Oder alternativ mit den PHP Bindings oder serverseitig mit den Javascript Bindings und einem simplen Http-Server aus Node.js: http://www.sitepoint.com/creating-a-http-server-in-node-js/

Mit welchem Browser oder Tools habt ihr die Websockets auf dem RED getestet ?

Habe am DesktopPC die Websockets freigeschaltet mit Port 4280, listen Address bleibt bei 0.0.0.0. Lade das Beispiel unter http://www.tinkerforge.com/de/doc/Software/Examples/JavaScript/IPConnection_JavaScript_ExampleEnumerate.html. Enum gibt alle am PC angeschl. Bricks zurück. Schalte die Websockets am RED ebenso auf die 4280, dabei verwende ich den BrickV am DesktopPC Per RemoteDesktop verbinde ich mich zum RED-Desktop. Starte den Midori Browser und lade die o.g. Beispielseite. Am RED ist nur ein Master angesteckt. Enum gibt aber nur Error 13 zurück. Habe ich etwas übersehen ? Image Full 1.3

Da hat sich m.W. noch nichts geändert ! Der RemoteSwitch kann - so wie er aktuell ausgeliefert wird - nur senden. Der RemoteSwitch agiert quasi wie die Fernbedienung für Funksteckdosen: Kompatibilität gem.: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Remote_Switch.html#liste-unterstutzter-gerate Augenblicklich lassen sich Stacks per Funk nur über die WiFi-Extension plus Master bzw. RED plus Wlan-Stick plus Master (falls zusätzl. Bricklet Ports gebraucht werden) steuern.

Etwas versteckt, und da muss ich immer etwas suchen http://www.tinkerunity.org/forum/index.php/topic,2450.msg16046.html oder in Doku http://www.tinkerforge.com/de/doc/Technical_Data.html#usb-stecker Gaaaaanz unten

Liste http://www.tinkerunity.org/wiki/index.php/DE/RED_USB aktualisiert. Bitte tragt noch nicht genannte WLAN-Sticks oder weitere HW, die zum RED kompatibel ist, dort ein.

Wenn ich das Datenblatt zur 47 Seg. Bricklet Anzeige deute handelt es sich um eine Spezialanf. für TF. Bevor Du dir unnötig Arbeit machst die Mini-Bauteile aufwendig zu tauschen, würde ich alternativ das LCD Bricklet nehmen oder geduldig warten, ob ev. eine OLED-Display von TF erscheint.

Bitte tragt euren WLAN-Stick (wenn er vom RED erkannt wurde!) mit Angabe der exakten Modell-Nr. in http://www.tinkerunity.org/wiki/index.php/DE/RED_USB oder http://www.tinkerunity.org/forum/index.php/topic,2772.0.html ein. Damit wir hier im Forum die zum RED kompatible Hardware sammeln können.

Und das gibt es schon als Script. Beschrieben unter http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#datum-uhrzeit und als Script hier https://github.com/Tinkerforge/red-brick/tree/master/programs/gps_time

I.d.R. wenn die Motoren den gängigen Industrie-Standards entsprechen, sollten viele Modelle an den Bricks funktionieren. D.h. diese Liste würde irgendwann den Rahmen des Portals sprengen. Aktueller wäre hier ins Forum zurückzukommen und die User um Rat zu fragen. Was Schrittmotoren mit Getriebe angeht, so bin ich mit diesen hier sehr zufrieden:http://www.omc-stepperonline.com/. Import aus CH und erfordert etwas Wartezeit