photron

Plugin: Load Cell Bricklet 2.0.1 Invertierung in der Gewichtsberechnung korrigiert Download: Load Cell Bricklet Falls die Signalleitungen der Wägezelle vertauscht angeschlossen wurden, um diese Problem zu beheben, so müssen sie jetzt zurückgetauscht werden.

Programme werden immer als User tf gestartet. Es gibt keine direkt Option ein Programm als root zu starten. Du versucht wahrscheinlich einen Port < 1024 zu binden. Das benötigt root Rechte. Die einfachste Lösung wäre es einen Port über 1024 zu verwenden, dann brauchst du keine root Rechte mehr. Wenn es unbedingt ein Port < 1024 sein muss, dann kannst du dein Programm aus einem Shell-Skript so als root starten #!/bin/sh echo tf | sudo -S mono server.exe Dein Programm muss dann als Shell anstatt als C# Programm hochgeladen werden.

Okay dann nehme ich die abgewandelten Packages erstmal so für die nächste Image Version mit auf.

Du musst noch pm-utils installieren: sudo apt-get install pm-utils Und dann nochmal sudo dpkg -i brickd_linux_latest_armhf.deb Dann sollte es funktionieren.

Hast du auf dem Raspberry Pi den Brick Daemon installiert? http://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html#raspbian-armhf

Die openHab Dokumentation https://my.openhab.org/docs spricht von "webapps/static" was wahrscheinliche "/usr/share/openhab/webapps/static" meint.

short vs int: remotecontrol hat recht, da ist uns was durcheinander geraten. Das hätte schon immer int sein müssen. In der Doku ist das schon korrigiert. In den Bindings wird das mit der nächsten Release auch int werden. Die häufigste Ursache für eine TimeoutException ist, dass du nicht die UID deines Bricklets verwendest und daruch keine Antwort erhältst.

Ich nehme an du meinst es2_info gibt diesen Fehler aus. Ich habe mir das gerade kurz angesehen aber ich kann nicht wirklich was dazu finden warum eglInitialize() fehlschlägt. Kannst du das noch mal mit einem frischen RED Brick Image testen?

Port bleibt 4223.

Du meinst, wenn du das USB Kabel zu RED Brick abziehst, dann verschwindet er aus Brick Viewer? Dein Brick Viewer ist wahrscheinlich mit Brick Daemon an localhost verbunden. Über Brick Daemon hast du die Verbindung zum RED Brick über USB. Wenn du USB abziehst ist die Verbindung dann natürlich weg. Um die Ethernet Verbindung zum RED Brick zu nutzen musst du dessen IP Adresse oder Hostnamen als Host im Brick Viewer Setup Tab anstatt localhost angeben.

Okay, nächster Versuch. Beim ersten mal hatte ich die Debian Packages nicht exakt genug nachgebaut. libegl1-mesa_2-1.1-1_armhf.deb libgles1-mesa_2-1.1-1_armhf.deb libgles2-mesa_2-1.1-1_armhf.deb libsunxi-mali-x11_1.1-1_armhf.deb

Okay, ich denke ich habe das Problem gefunden. Das sunxi-mali Makefile installiert den Treiber ins falsche Verzeichnis. Zumindest muss es auf dem RED Brick in ein anderes Verzeichnis damit es2gears es benutzt. Ich habe vier Debian Packages angehängt. Installier die mal bitte alle mittels "sudo dpkg -i <package-file>" auf dem RED Brick (Reihenfolge ist egal). Danach sollte es2gears deutlich schneller laufen. Teste das dann auch mal bitte mit deinem richtigen OpenGL Programm, nicht das ich da jetzt bloß es2gears verbessert habe. Edit: Das entspricht übrigens dem was im Wiki Eintrag steht. Das sunxi-mali Makefile installiert die Dateien nach /usr/lib/. Die EGL/GLES Debian Packages, die Dateien gleichen Namens beinhalten installieren diese nach /usr/lib/arm-linux-gnueabihf/ was Vorrang vor /usr/lib/ zu haben scheint. Daher werden im Wiki Eintrag die EGL/GLES Debian aus /usr/lib/arm-linux-gnueabihf/ wegbewegt. Die angehängten Debian Packges ersetzen die original Debian Dateien mit denen aus sunxi-mali. libegl1-mesa_2-1.1-1_armhf.deb libgles1-mesa_2-1.1-1_armhf.deb libgles2-mesa_2-1.1-1_armhf.deb libsunxi-mali-x11_1.1-1_armhf.deb

Port muss 4223 sein.

Der Brick Daemon Installer richtet brickd.exe als Windows Service ein und startet diesen. Der Brick Daemon Läuft also schon automatisch im Hintergrund. Du musst brickd.exe also nicht von Hand starten und solltest es auch nicht. Aber was ist dein eigentliches Problem, dass sich dazu gebracht hat zu versuchen brickd.exe von Hand zu starten? Wenn du das GUI Programm suchst, dann musst du Brick Viewer installieren.

Also kurze Bestandsaufnahme: Ich habe hier RED Brick (frisches 1.7er Image) mit HDMI Display und USB WLAN Stick und verbinde mich über SSH. Da ich mich über SSH verbinde muss ich erstmal DISPLAY=:0 setzen damit die Programm auch den X Server finden: export DISPLAY=:0 Dann installiere ich mesa-utils und mesa-utils-extra und teste mittels glxinfo, glxgears, es2_info und es2gears. tf@red-brick:~$ glxinfo name of display: :0 libGL error: MESA-LOADER: malformed or no PCI ID libGL error: unable to load driver: mali_drm_dri.so libGL error: driver pointer missing libGL error: failed to load driver: mali_drm ... OpenGL renderer string: Software Rasterizer Interessant hier ist, dass glxinfo sich beschwert mali_drm nicht laden zu können, obwohl mali_drm geladen ist: tf@red-brick:~$ lsmod Module Size Used by disp_ump 838 0 mali_drm 2622 1 drm 215517 2 mali_drm 8188eu 506931 0 g_red_brick 37229 3 red_brick_uid 1618 1 g_red_brick mali 110636 0 ump 34163 4 mali,disp_ump es2_info beschwert sich lima nicht laden zu können: tf@red-brick:~$ es2_info libEGL warning: DRI2: failed to open lima (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri) ... GL_RENDERER: Software Rasterizer glxgears beschwert sich genauso wie glxinfo und schaft um die 33 FPS mit dem Software Rasterizer: tf@red-brick:~$ glxgears libGL error: MESA-LOADER: malformed or no PCI ID libGL error: unable to load driver: mali_drm_dri.so libGL error: driver pointer missing libGL error: failed to load driver: mali_drm 166 frames in 5.0 seconds = 33.013 FPS es2gears beschwert sich genauso wie es2_info und schaft um die 16 FPS mit dem Software Rasterizer: tf@red-brick:~$ es2gears libEGL warning: DRI2: failed to open lima (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri) EGL_VERSION = 1.4 (DRI2) vertex shader info: fragment shader info: info: 81 frames in 5.0 seconds = 16.152 FPS Der sunxi-mali Treiber ist im Image eigentlich schon installiert. Warum OpenGL dennoch nicht richtig funktioniert ist mir nicht klar. Muss ich mir im Detail ansehen.

Die minimale Abtastrate des Data Loggers liegt bei einer Sekunde. Der Data Logger ist für langfristige Datenerfassung mit niedriger Frequenz gedacht. Für spezieller Anforderungen wie höherfrequente Datenerfassung ist es das einfachste eines der Beispielprogramme abzuwandeln: http://www.tinkerforge.com/de/doc/Software/Bricks/IMUV2_Brick_Python.html

Lässt sich der Reset Knopf normal drücke und kommt dann auch wieder von selbst zurück? Nicht das der klemmt und den Master Brick durchgehend im Reset hält?

Versuch den Brick noch mal in den Bootloader zu versetzen: Erase gedrückt gehalten und dabei USB anstecken.

If you're subscribed to multiple topics at once and you want to distinguish the different messages, then you should due this based on their topic. Don't try to guess this based on the message content. The mosquitto_sub tool has a -v option that'll also output the topic the messages was received on.

It's a bit tricky. You could use the is_button_pressed() function to poll for button presses in the MQTT proxy. But it's easy to miss button presses this way. So you'd need to use the button_pressed and button_released callbacks. But currently there is no callback handling like this in the proxy. As an example, I've added a new button_pressed topic for the LCD Bricklets, that is fed via the button_pressed and button_released callbacks. Have a look at the latest Brick MQTT Proxy version on github.

Kann ich hier nicht reproduzieren. Mit einem frischen 1.7er Image auf der SD Karte gibt mit "java -version" auf der RED Brick Console folgendes aus: java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode)

Use the Brick Viewer RED Brick Console Tab to get access to the RED Brick console. From there you can use normal Debian tools such as apt-get.

Set custom character 0: mosquitto_pub -t tinkerforge/bricklet/lcd_20x4/SCD32/custom_character/set -m '{"index":0, "character":[0,4,10,27,4,4,14,0]}' Write it: mosquitto_pub -t tinkerforge/bricklet/lcd_20x4/SCD32/write_line/set -m '{"line":0, "position":0, "text":"Up: \u0008"}' Custom character 0-7 map to \u0008-\u00015 \u0008-\u000F. (Edit: \u takes hex numbers)

Der Wiki Link ist kaputt.

You already looked in the right place: https://github.com/Tinkerforge/lcd-20x4-bricklet/raw/master/datasheets/standard_charset.pdf You need to take the 4 bit column and row number (H = 1, L = 0) of the character you want and interpret it as binary like this: 0b<column><row> Convert that to hex and prepend "\u00". You said "°" would be "HHHHHHHL". You where off by one column and had column and row mixed up. Actually "°" is in column HHLH and row HHHH. This translates to 0b11011111, that is 0xDF in hex. Prepended with \u00 you get \u00DF.