Jump to content

rtrbt

Administrators
 View Profile  See their activity

  • Content Count

    599

  • Joined

  • Last visited

  • Days Won

    23

 Content Type 

Posts posted by rtrbt

    Brickviewer 'object has no attribute' error

    in General Discussion

    Posted

    Hi,

    can you please try the attached version of Brick Viewer?

     

    The problem seems to be, that the IMU 2.0 3D rendering uses the (very old) immediate mode, which is only supported by OpenGL, not OpenGLES. The Raspberry Pi does not support OpenGL, so we can't render the 3D model, which was not handled.

     

    I will rewrite the rendering to use more modern OpenGL capabilities, which are also supported by OpenGLES. But for now, you can use the attached version, which disables the 3D rendering if only OpenGLES is available.

     

    Thanks for reporting the bug,

    Erik

    brickv-2.4.2_all_opengl_fix.deb

    MQTT / 4x7-segment

    in Allgemeine Diskussionen

    Posted

    Die kurzen Verzögerungen (0,2s schätze ich) waren an localhost / Brickv bemerkbar. Spielt da das Netzwerk eine Rolle???

     

    Hm vielleicht hingen da noch Pakete im Buffer vom Brick Daemon. Im Normalbetrieb sollte das nicht passieren, es sei denn du versuchst mehr als 1000 Nachrichten pro Sekunde an die Bricklets zu schicken. Z.B. wenn du den Counter vom Segment Display auf 1ms konfigurierst und parallel noch andere Sachen machst.

    MQTT / 4x7-segment

    in Allgemeine Diskussionen

    Posted

    Dass die Verzögerungen weg sind, kann ich dir spontan nicht erklären, vielleicht ist das Netzwerk weniger ausgelastet?

     

    Bist du dir sicher, dass du die Version ausführst, die ich angehangen habe? Diese Fehlermeldung kann von der neuen Version eigentlich nicht erzeugt werden, weil die Codezeilen, die ausgegeben werden, so nicht mehr vorkommen. In der neuen Version der tinkerforge_mqtt-Datei steht in Zeile 23 

    from collections.abc import Hashable

    Wenn das fehlt, hast du die falsche.

    MQTT / 4x7-segment

    in Allgemeine Diskussionen

    Posted

    Moin,

     

    die Bindings sollten eigentlich, abgesehen von der Netzwerklatenz, nicht langsam sein. Sind die Reaktionen auch verzögert, wenn du das ganze lokal testest?

     

    {"red": "{", "green": "\"", "blue": "r"}

    Das sieht kaputt aus. Die Zahlen sollten nicht als Zeichen interpretiert werden. Ist das Ausgabe von MQTT.fx?

     

    Das falsche (oder richtige, je nach dem :D) Beispiel habe ich mal repariert, es dauert aber noch etwas bis es sichtbar wird.

     

    Bezüglich des 4x7 Displays, teste bitte mal ob das mit der angehangenen Variante der Bindings auch auftritt.

     

    Gruß und schönes Wochenende,

    Erik

     

    Edit: Du kannst übrigens testen ob die Bindings deine Nachrichten verstehen, indem du den --show-payload Parameter beim Starten mitgibst. Wenn die Bindings dann keine Fehlermeldungen mit dem Payload als string ausgeben, haben sie dich verstanden, wenn es dann nicht klappt, sind die Bindings kaputt.

    tinkerforge_mqtt_bindings_2_0_3.zip

    Beta release of the MQTT bindings

    in General Discussion

    Posted

    Your init file looks good, I've tested it here and got callback responses. You could run the bindings with the --debug parameter and check if there are the following lines in the output:

    <DEBUG> MQTT bindings: Calling function set_station_callback_configuration for device Es8 of type outdoor_weather_bricklet.

<DEBUG> MQTT bindings: Calling function set_station_callback_configuration for device Es8 of type outdoor_weather_bricklet succedded.

<DEBUG> MQTT bindings: Registered callback station_data for device Es8 of type outdoor_weather_bricklet. Will publish messages to tinkerforge/callback/outdoor_weather_bricklet/Es8/station_data.

     

    If these are printed, the bindings should publish a message under the callback topic when there is new data (can take about 45 seconds).

     

    The get_status_led_config request works here, but maybe there are some hints in your debug output.

    Beta release of the MQTT bindings

    in General Discussion

    Posted

    The process for activating and subscribing is quite long ... and does it have te be done after every reboot ... for every sensor?

     

    You don't have to configure the callbacky by hand. Instead you can use an init file, as described here.

     

    What is the best way to autostart the tinkerforge_mqtt system after a reboot?

    You could write a systemd service file. This is explained here. You should definitely use init-files then, or else you would have to reconfigure everything after a reboot.

    Beta release of the MQTT bindings

    in General Discussion

    Posted

    The error messages are left-over debug code, I've removed them, this change will be in the next "official" version (will be posted in a few hours).

     

    The rest looks good to me. Are the callbacks of the outdoor weather station working too? One thing I've noticed in the documentation: The single quotes are only there to mark the payload, so if you use the MQTT-Explorer, you have to omit them.

    Beta release of the MQTT bindings

    in General Discussion

    Posted

    The message published to "callback/bindings/restart" is sent by the bindings to notify other bindings to print the warning you see. As your broker is running on another machine, my first guess is, that there is a timing problem here: Maybe the bindings see their own restart message. But I need to take another look. For now you can ignore the warning if you are sure, there is no other instance running.

     

    Your broker seems to run okay, you don't need to reinstall.

     

    For testing purposes you can try to enumerate the attached devices:

    publish 

    {"register": true}

    to 

    tinkerforge/register/ip_connection/enumerate

    and then publish an empty message to 

    tinkerforge/request/ip_connection/enumerate

    You should then see responses for all found devices under the topic 

    tinkerforge/callback/ip_connection/enumerate

×
×
  • Create New...