Quantasy

Im Folgenden steht der IO16 symbolisch für alle Bricklets, bei denen ein setMonoflop eine Maske verlangt, das monoflopDoneEvent eine Maske zurück gibt, !aber der getMonoflop als Argument noch einen zusätzlichen Pin verlangt und dann nur den Wert für diesen einen Pin zurückgibt!. Warum benötigt die getPortMonofolp Methode einen Pin als Argument? Es gibt doch pro Port genau einen Monoflop, der mehrere Pins steuert... also nicht einen Monoflop pro Pin. Momentan müssen so für eine Monoflop-Statusabfrage im Beispiel IO16 2x8 Methodenaufrufe stattfinden... statt nur deren 2. Wäre es euch möglich, bei allen Bricklets, bei denen ein setMonoflop mit Maske als Input... die Methode getMonoflop neu anzubieten, welche die Maske als Output liefert? Dann wäre es konsistent mit dem monoflopDoneEvent, welches ja auch jeweils die Maske zurückgibt.

Ich möchte auch noch einmal nachfragen, ob die TF-Dual-Relays (v1.2) für irgend etwas taugen?! Ich habe damit eine klassische Storen-Steuerung (230V-AC) gemacht. Relay A für Nichtstrom/Strom und Relay B für Auf/Ab Aber bei fast jedem Ausschalten hängt sich die Hälfte des Stacks (Noch ein Master mit einem RemoteSwitch Bricklet) komplett auf :-( Ich will aber eigentlich nicht auf SSR ausweichen, da ich Angst habe, dass ein Programmierfehler dann plötzlich für 'Auf' und für 'Ab' Strom liefert... Ich glaub das wäre schlecht. Wie also kann ich den Stack vor der Induktion des DualRelays schützen? Wenn das nicht geht... warum gibts die Dinger denn? Die bereiten in dem Falle ja nur Ärger?

Bei folgendem Szenario hängt sich der TF-Stack garantiert auf und kann ausschliesslich durch einen 'Kaltstart' wieder (für den nächsten Aufhänger) gestartet werden: Hier der Stack: Master 2.0 -> LED-Bricklet (2801 40LEDs) (12V-5A) Master 2.1 -> LED-Bricklet (2812 160LEDs) (5V-8A) WiFi Ext 1.0 mit Fritzbox über (b+g+n) WPA2 verbunden Master 2.0 -> LED-Bricklet (2812 192RGB-LEDs) (5V-10A) StepDown von gespiesen mit (12V 5A) Via LAN ist ein PC angehängt (irgend ein Debian System) BrickViewer (2.3.6) BrickDaemon (2.2.2) Nun alle LEDs per BrickViewer anschalten (showColor) Vielleicht noch ein wenig am RGB-Channel was ändern... und #@PENG@# Das GUI des BrickViewers reagiert nicht mehr.... Das geht meist nur ein paar Sekunden, manchmal aber auch bis zu einer Stunde (Scheint mir eine Race-Condition o.ä. zu sein). Irgendwann versucht BrickViewer wieder zu reconnecten... Aber die Fritzbox meldet klar, dass der Tinkerforge-Stack nicht mehr angehängt sei. Ping ist auch schluss. Mach ich was grundsätzlich falsch? Ist das die Grenze von TF via WLAN? Via USB läuft die Sache nämlich (obwohl ich das aber nicht über längere Zeit (Tage) getestet). Ich habe mehrere WiFi Extensions v.1 getestet... Immer das selbe Resultat. Auch mit einem 2.1 Master scheint es sich gleich zu verhalten, kann aber, wenn da noch Hoffnung besteht gerne nochmals nachgucken. Kann da irgendwer weiterhelfen? Ich weiss, es gibt da verschiedenste Threads, die dazu (oder irgendwie verwandt) am Laufen sind, aber dieser Thread schien mir so ziemlich genau den Nagel auf den Kopf zu treffen... auch wenn er schon älter ist. Ich habe auch einen Debug und ein Log gemacht. Aber... schaut selber, hab nix geändert daran. logger_debug_1477592997.log logger_data_1477592997.csv

Frage: Habt ihr zufälligerweise den Patch von borg eingepflegt, oder ging der irgendwo verloren (oder ist das eine Regression durch die Einführung von RGBW)? Phänomen: Ich wollte heute an einem MasterBrick folgendes laufen lassen: A: 40x2801 (RGB) C: 160x2812 (RGB) Da gabs aber stets blitze und wilde Flackereien; scheinbar haben sich die zwei ins Memory geschrieben?! Wenn ich die zwei dann auf jeweils einen separaten Master getan habe, gings ohne zu mucken.

YES! Toll, habe endlich eine Ladung RGBWs zum Testen erhalten. Hab die Implementierung getestet und die geht ja wunderbar! Herrlich, danke für die Umsetzung. Bin begeistert.

Liebe Tinkerforge Bricklet Designer Das RGB LED Bricklet ist ... mmmhhh ... ein bisschen eine ... ich möchte jetzt doch nix unnettes schreiben... Ich habe eigentlich gehofft, es würde nicht einfach der WS28xx in der LED benutzt, sondern dass der Chip und die (Leistungs-)Elektronik extern ist, sodass dann z.B. einzelne LEDs an den jeweiligen R,G,B Kanal gehängt werden könnten. So wäre es möglich einen RGB-Flutstrahler zu unterstützen und die nächste Studiobeleuchtung selber zu stricken. Hier ist, was ich meine und was nicht nach Europa geliefert wird... Wenn das von TF käme, ja dann...: https://www.tindie.com/products/RobG/10w-rgb-flood-light-pixel-kit-ws2811/ Oder noch 'dümmer' (soll nicht wertend sein, ich beziehe mich auf die RGB-LED, welche verwendet werden kann) https://www.tindie.com/products/RobG/20w-rgb-flood-light-kit-dumb-rgb/ Momentan muss ich da was selber zusammenbasteln mit 3 (drei) DC Bricks. Ist doch ein leichter Overkill!? (Blutet da nicht eure Elektroniker-Ehre... vielleicht ein bisschen... hoffentlich ;-) ) Ja? Vielleicht ein PowerRGB Bricklet?

Die Library schreitet mutig voran und unterstützt bereits eine nette Menge an Bricks und Bricklets. Nun ist auch noch NFC dazugekommen, welches das ganze NFC-Handling um einiges vereinfacht! Die Library arbeitet intern mit Callbacks und ist stark parallelisiert. Wie nutzt man die Library: Um einen Stack (z.B. USB) verwalten zu können muss folgende Message versandt werden: Topic: TF/Manager/stack/address/add Message: localhost Es können beliebige weitere Stacks verwaltet werden (Bsp: via wlan): Topic: TF/Manager/stack/address/add Message: 192.168.1.97 Um eine LCD-Display (mit UID a1e) anzusteuern: Topic: TF/LCD20x4/a1e/intent/backlight Message: true Um NFC-Tags discovern zu können (UID oop): Topic: TF/NfcRfid/ouu/intent/scanning/callbackPeriod Message: 1000 Um eine Temperatur auslesen zu können (UID aad): Topic: TF/NfcRfid/aad/intent/scanning/callbackPeriod Message: 1000 Dabei ist es absolut egal, an welchem Stack sich ein Sensor/Aktor befindet, der wird immer über seinen Typ und UID identifiziert. Wäre toll, wenn diese Library auch von anderen benutzt werden könnte, so würde ich Feedback erlangen. https://github.com/knr1/ch.quantasy.tinkerforge.mqtt.gateway @ piwo: Stimmt, das nächste wäre nun eine state-machine... Aber he, der Sommer ist noch laaaaang ;-)

Ah ja, stimmt! Das würde bei uns zu Hause den 'WAF' erheblich erhöhen

YES! Dieser 'Patch' funktioniert für uns, wir haben es für A/C bzw. B/D mit jeweils 120LEDs pro Port erfolgreich probiert. @borg: Danke für Deine Strick-Kunst. @Loetkolben: Vielleicht könnte man ja so wie die Kalibrierungsdaten bei der IMU oder beim LoadCell die Werte persistieren?! Das scheint mir wirklich eine gute Idee... Denn normalerweise ändert man den LED-Strip nicht so häufig. (Aber es sollte wie bei der LoadCell mit Hilfe der API gehen... nicht 'nur' per brickv.)

Immer mal wieder kommt Adafruit mit was Neuem raus. Nun sind es 4-Kanal rgbw-Neo-Pixels, wobei der 4te Kanal eine 'Weisse' LED steuert. Wäre es denkbar, das LED-Strip Bricklet auf 4-Kanäle aufzubohren? https://www.adafruit.com/products/2757

Aha, danke für das Feedback. Ist das nun eher ein 'Bug' oder ein 'WONTFIX' weil Design-bedingt? Wir sind eben fleissig am LED-Strips verteilen und so würden wir das Doppelte an Master-Bricks verbauen müssen (vielleicht dann doch eher ein 'Feature' auf der €-Seite ;-) ), was auch das doppelte an Platz verbraucht. Würde denn ein spezielles Auswählen der Ports auf dem Master-Brick was helfen... Soz. Port A und Prot C o.ä.?

Liebe Tinkerforger Ich habe eine Frage bzgl: LED-Strips Wenn ich zwei LED-StripBricklets an den gleichen MasterBrick hänge und je 120RGB-LEDS vom Typ WS2811 individuell ansteuern will, dann scheinen sich die zwei Bricklets mit dem RAM in die Quere zu kommen, Ist das denn nicht erlaubt? Die beiden Bricklets sollten doch jeweils separaten Speicher erhalten? Scheint mir grad so, als ob das Speichermanagement der Masterbrick in diesem Fall fehlschlägt (weil beide sich von jeweils einem vermeintlich anderen Port noch RAM 'borgen'? )?! Anmerkung: Wenn ich die zwei Bricklets dann an jeweils einen Master hänge, dann läuft dies als gesamt-Stack wunderbar.

Wollte nachfragen, ob das Update für den RealtimeClock vielleicht vergessen ging, oder vielleicht ein zu optimistisches Release-Datum gewählt wurde? In allen Changelogs APIs und PlugIn ist die Änderung aufgeführt (z.B. Plugin-Changelog im RealtimeClock wurde für das Update auf 2.0.1 der Termin 2016-05-13 erwähnt.

Wird der Mosquitto Broker für das RED-Brick mit WebSocket support gebildet? Wenn ja, super. Wenn nein, wäre es möglich, dies per default anzubieten? Grüsse Quantasy

Hallo Tinkerforge-ler da draussen Ich habe für meine Studenten (und vor allem für mich) eine neue MQTT-Repräsentation der Tinkerforge-Device erstellt. Dabei ist jedes Device als 'Service' ausgeführt, welches Anfragen jeweils über Intent-Topics entgegen nimmt (Der Service ist darauf subscribed). Antwort darauf in Event- und Status-Topics ausgibt (Der Service published dort drauf). Jede Device-Klasse ist in einer eigenen MQTT-Topic (description) beschrieben. Die Implementation auf Dynamik und Robustheit aus und erwartet, dass die Bandbreite der MQTT-Anbindung auch mal schlecht ist. Deshalb werden sämtliche Events als "Array of Events" versandt, sodass auf keinen Fall ein Event verpasst wird (Vielleicht aber halt eine Liste von veralteten Events daher kommt). Als Syntax wurde YAML gewählt, "weil diese dem Menschen einfach noch am nächsten liegt" (Aussage eines Studenten der auf diesem Gebiet die Bachelorarbeit gemacht hat). Noch wird die Implementierung mit heisser Nadel weiter gestrickt und muss bestimmt noch ein wenig abkühlen (-> Dokumentiert werden) ehe sie als 'Rock-Solid' gelten darf.... Aber das ist das Ziel... darauf arbeite ich hin. Dennoch, für mutige "Probierer", welche sich in MQTT und Tinkerforge ein wenig zu Hause fühlen sei die Sache bereits dienlich. https://github.com/knr1/ch.quantasy.tinkerforge.mqtt.gateway P.S. Ich habe versucht, mich so nahe wie möglich an der Tinkerforge (Java) Dokumentation zu halten, sodass es sich für einen Tinkerforge-ler sehr natürlich anfühlt. Bloss bei einzelnen z.B. LEDStrip habe ich eine Vereinfachung für den Benutzer vorgenommen... So muss man sich nicht um das LED-Handling kümmern, kann einfach nur die kompletten Daten für ein neues Frame hochsenden.

Nach unseren Tests mit den APA102Cs muss ich sagen, dass es sich wirklich lohnt, diese zu unterstützen. Von der 'einfacheren' Ansteuerung mal abgesehen, welche ja sowieso durch euch gekapselt wird, sind diese LEDs endlich angenehm anzusehen. Kein flackern oder 'Zerreissen', da der PWM bei 20kHz ist. (Bei Neo-Pixel ist er ja bei 400Hz) und das merkt man wirklich extrem; vor allem, wenn die Lichtinstallationen grösser werden. Vielleicht ist ja einem von euch grad ein wenig nach LED-Erweiterung zu Mute?! Ja?! ... Ich würde das auf jeden Fall superst finden, und alle anderen bestimmt auch... Liebe Grüsse Quantasy

Frage zur API LinearPoti und RotaryPoti Eigentlich ist das auf 'Programmierebene' ja 'das gleiche'. Aber die beiden Methoden @Override public void position(xxx i) { } @Override public void positionReached(xxx i) { } sind bei... ...LinearPoti xxx=int ...RotaryPoty xxx=short Wäre da eine Harmonisierung denkbar? Grüsse Quantasy

Kann es sein, dass die Dokumentation des Laser Range Finder bei der Geschwindigkeit 'ungünstig' ist? " public short getVelocity() Returns the measured velocity. The value has a range of 0 to 12700 and is given in 1/100 m/s. " Aber das ist so nicht korrekt, denn es sind auch Werte <0 möglich. Dann, wenn sich das Mess-Subjekt vom Sensor weg bewegt?!

Ist es denkbar die LED-Pixel APA102C (Dotstar) per Tinkerforge (LED-Bricklet) anzusteuern? So was meine ich: https://www.adafruit.com/category/37

Da hat sich wieder mal ein 'freudscher' Fehler eingeschlichen: In der Dokumentation steht: ... public short isLEDOn() Returns true if the LED is enabled, false otherwise. ... Schön wärs ja, aber ihr sendet einen 'short' zurück. Da ist das verflixte daran, dass 11=>true und 12=>false ist, was doch leicht verwirrend ist... Falls Ihr keinen Boolean zurückgeben könnt, müsstet vielleicht wieder zwei Konstanten einführen --wie beim 'Color' Bricklet. Gruss Quantasy

Habe zwei Fragen zum Humidity Bricklet : Firmware V.2.0.0 Java Tinkerforge-2.1.5 (Maven) Gibt es einen Grund, dass die Argumente für min und max bei setHumidityCallbackThreshold(option, min, max) vom Typ 'short' sind, obwohl es in der Dok 'int' sind? Dann ist mir noch was aufgefallen: Wenn ich die getDebouncePeriod() aufrufe kriege stets eine... com.tinkerforge.TimeoutException: Did not receive response in time for function ID 12 at com.tinkerforge.DeviceBase.sendRequest(DeviceBase.java:169) at com.tinkerforge.BrickletHumidity.getDebouncePeriod(BrickletHumidity.java:438) Habe ich da was falsch verstanden, oder ist da ein kleiner Bug im Spiel? Quantasy

Selbstverständlich könnte die Implementierung auch von 'ausserhalb' geschehen... so wie Nic das vorschlägt (vielleicht aber sollten wir in diesem Fall nicht zu toll auf IBM hoffen :-) ). -Falls wir also hier mit so einer Integration anfangen sollten, wollte ich bloss et-welche 'Doppelspurigkeit' vermeiden!

Danke für den Tipp bzgl. Verwirrung, habe mein Posting dem entsprechend angepasst! :-)

Der Bereich IoT ist ja komplett am explodieren (Mit all den zugehörigen Kollateralschäden)... IBM hat mit Node-RED einen erfreulich einfachen Einstieg in diese Welt erschaffen. (Ich arbeite nicht dort!) http://nodered.org/ Bin ich komplett auf dem Holzweg wenn ich frage, ob Tinkerforge ein 'API' für Node-Red schreiben würde? D.h. sämtliche Brick(let)s würden als Nodes in Node-RED zur Verfügung gestellt?! Wenn dann Node-RED statt auf dem Raspi sogar noch auf RED-Brick laufen würde, könnte Tinkerforge die bereits erfreulich grosse Palette an Möglichkeiten für die Entwickler nochmals um eine Stufe 'abstrahieren'. Oder nicht?

Frage: Kann der RED-Brick in einen suspend-ähnlichen Zustand (Deep-Sleep) gebracht werden, und per Interrupt oder Timer wieder geweckt werden? So könnte ein Aufbau z.B. immer in der Nacht laufen, am Tage aber 'ruhend' / 'ausgeschaltet' sein. Oder aber die Sensoren könnten den RED aus dem Suspend holen (z.B. eine Vibration) Naja... ich träum mal noch ein wenig :-)