Jump to content

theobald

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ok - danke! Das war mir bekannt. Aber ich bin fälschlicherweise davon ausgegangen, dass der RED Brick beim booten an einer Ethernet Extension deren IP Parameter automatisch übernimmt. Ich hatte leider übersehen, dass man auf dem RED Brick einmalig, das Interface und die IP Bezugsmethode (static/dhcp) noch einmal gesondert einstellen muss. Jetzt funktioniert alles, wie erwartet. Vielen Dank! vom Theo
  2. ok ich habe jetzt 1. den RED Brick unter den Stapel gesteckt, 2. den Stapel via PoE gestartet 3. den RED Brick parallel via USB->localhost angesprochen und ich kann den RED Brick steuern und der sieht eine PoE Extension leider bleibt die im lokalen Netzwerk unsichtbar, so lange der RED Brick unten steckt... ping geht nicht, nur wenn man den RED abzieht, dann bezieht die Extension eine IP Adresse...
  3. Moin moin, danke für die Antwort. Ich glaube das wird etwas kompliziert. Ich habe noch nicht genau verstanden, wie ich das machen soll. Steckt der RED Brick unter dem Stapel, dann bezieht der Stapel keine IP Adresse via PoE Extension mehr. Oder sollte ich den RED Brick vorher abziehen, den Stapel via PoE starten und danach den RED Brick an den laufenden Stapel anstecken? Ist das gesund für den RED Brick und den Stapel .. ? Viele Grüße. Theo.
  4. Hallo in die Runde, ich habe mehere Stacks laufen und nun einen weiteren für die Softwarentwicklung hinzugekauft. Die Stacks sind alle wie folgt (gemäß Stapelaufbau-Richtlinie) aufgebaut: oben Pos 3 Ethernet Ext PoE Pos 2 Master Pos 1 Red Brick unten Mein Problem: Der neu gekaufte Stack arbeitet nicht via Ethernet. 1. Wenn ich den Red Brick entferne arbeiten Pos 2 + 3 einwnadfrei und erkennen alle angeschlossenen Sensoren. 2. Wenn ich den Red Brick via USB betreibe, dann kann ich alles machen, es funktioniert auf dem Red Brick alles. 3. Stecke ich den Red Brick un
  5. OK vielen Dank! Ich dachte mir schon sowas in der Richtung... Das ist aber kein Problem... Viele Grüße. Theo
  6. Hallo TF-Team! kann man auch Kabel >2m für den Anschluss von Bricklets an den Master bei Euch bekommen? Ich habe Sensoren (Humidity) an einer größeren Wetterstation, die bestimmte Höhen über/unter dem Boden haben müssen, so dass ich einen in 1m in der Erde habe (Bodenfrost) einen 5cm über der Erde und einen in 2m/3m Höhe. Da bräuchte ich 3m/4m Kabel. Gibt es soetwas bei Euch? Viele Grüße. Theo
  7. Danke! Das werde ich gleich testen. Ich habe jetzt ca. 3000 Zeilen code für diese Projekt geschrieben und diese Verfahrensweise bisher nirgendwo beachtet. Steht das in der API-Beschreibung? Asche auf mein Haupt! 😀 Grüße und Danke. Theo
  8. Ja! Danke für die Antwort. Hier kommt mein Code... <!DOCTYPE html> <html> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <head> <title>Tinkerforge | JavaScript Example</title> </head> <body> <div style="text-align:center;"> <h1>IO-16 Bricklet 2.0 Interrupt Example</h1> <p> <input value="192.168.5.42" id="host" type="text" size="20">: <input value="4280" id="port" type="text" size="5">,
  9. Hallo und guten Morgen... ich bin leider hier der Stammkunde! 😀 Ich hoffe, das nimmt mir niemand übel... Durch die intensive Nutzung von Tinkerforge-Baugruppen kommen selbstverständlich viele Fragen auf... Ich habe hier herumgelesen, dass es bei der Verwendung der Interrupte am IO-16V2 mitunter zu 'Verklemmungen' kommt. Ich habe meine Applikation nun schon mit Eurer Hilfe recht weit voranbringen können. Jetzt bin ich beim IO-16V2 und habe auch ein seltsames Problem. Ich habe Kanal 0 bereits mit einem EdgeCounter erfolgreich in Betrieb und wollte nun parallel den Kanal 1 mit eine
  10. Danke! Das ist prima! Es ist viel einfacher, als mit promises. Ich bin davon ausgegangen, dass ich mit promises warten muss, bis die einzelnen Geräte antworten. Das schrittweise neue Timeout, bis das nächste Gerät antwortet, ist jedenfalls viel einfacher als mit promises. Vielen Dank!
  11. Moin moin, also ich muss mich etwas präziser ausdrücken: Genaugenommen habe ich zwei Probleme. 1. sauberen Code schreiben ->Callback-Chain oder Promise Chain und 2. die Ergebnisse der Enumerate-Callbacks für die Laufzeit der Main Loop in einem Array speichern oder beim Reconnect aktualisieren. besonders Nr. 2. liegt mir am Herzen und ich finde keine richtige Lösung... @rtrbtgibt es keinen Kontakt zu einem Entwickler, der die Bindings entworfen hat? Der könnte doch bestimmt zwei drei Tipps geben, in welcher Richtung man suchen muss.... das wäre echt nett 😀
  12. Hi! naja mein oben geposteter Code ist ja bereits die (nicht funktionierende) Erweiterung. Ich weiss leider nicht, wo ich ansetzen soll. Ich müsste/möchte die Ergebnisse der Callbacks verketten, aber das geht so nicht, wie ich es versucht habe. Ich versuche z.B. die Aufrufe des enumerate_callbacks in ein Promise-Array zur schreiben und dieses Array dann aufzulösen. Das funktioniert aber nicht. mein Promise.all wird fullfilled bevor das array geladen wurde. Ich weiss nicht, warum! Ich finde leider auch keine Beispiele...
  13. also ich muss noch weiter fragen. Ich verstehe das Konzept der Callbacks hier nicht so richtig. Da die Tinkerforge API weitgehend Callback-orientiert ist, sollten diese doch entsprechend den Konventionen implementiert sein. Ich habe nun versucht ipcon.on zu verketten, aber das geht nicht. ipcon.on() ist kein EventEmitter und daher kann man ihn nicht verketten mit ipcon.on(CONECCTED).on(ENUMERATE) Wäre das nicht essentiell? Denn nur wenn ipconn.on(Connected) erfolgreich wäre ist erst ipcon.authenticate() sinnvoll und danach ipcon.enumerate() und erst danach Bricklet.on(CALLBACK_HUMIDITY) e
  14. also mir ist es bisher leider nicht gelungen, das Problem zu lösen. Kann mir vielleicht ein JS-Profi etwas behilflich sein? Ich habe jetzt: var device_promises = []; und... // Register Connected Callback ipcon.on(Tinkerforge.IPConnection.CALLBACK_CONNECTED, async function (connectReason) { await enumerateDevices(); } ); und später... ipcon.on(Tinkerforge.IPConnection.CALLBACK_ENUMERATE, // Print incoming enumeration function(uid, connectedUid, position, hardwareVersion, firmwareVersion, deviceIdentifier, enumerationType) { const dp = new Promise(resolve => {
  15. Moin rtrbt, danke! Ja genau! Man weiß nicht, wieviele Bricks/Bricklets sich zurückmelden... Ich werde mich mal in das Problem vertiefen... Wenn ich eine Lösung finde, dann schreibe ich nochmal... Grüße vom Theo
×
×
  • Create New...