photron

Firmware: Real-Time Clock Bricklet 2.0 2.0.2 Datums und Uhrzeit Getter sind wieder synchron, um Timeouts durch überschriebene Anfragen zu vermeiden Download: Real-Time Clock 2.0

Firmware: Real-Time Clock Bricklet 2.0 2.0.1 Remove unnecessary I2C communication to avoid date-time jumps Download: Real-Time Clock 2.0

Firmware: Real-Time Clock Bricklet 2.0 2.0.1 Unnötige I2C Kommunikation entfernt, um Uhrzeitsprünge zu vermeiden Download: Real-Time Clock 2.0

Brick Daemon 2.3.2 Fix notification event name handling on Windows 10 IoT Core Read USB string descriptors instead of faking them on Windows 10 IoT Core Add backward compatibility to RED Brick Image 1.9 Update bundled libusb to 1.0.22 on Windows and macOS, this fixes enumeration problems with ASMedia USB hubs, composite devices and bogus USB device address reports on Windows Add MSVC project on Windows Use systemd instead of init.d on Linux, if available Add initial Android support, no precompiled app available yet, brickd for Android has to be compiled from source Downloads: Windows, Linux (amd64, i386, armhf), macOS

Brick Daemon 2.3.2 Notification Event Namensbehandlung auf Windows 10 IoT Core korrigiert USB String Descriptors werden jetzt auf Windows 10 IoT Core ausgelesen anstatt sie zu fingieren Abwärtskompatibilität zu RED Brick Image 1.9 wiederhergestellt Mitgelieferte libusb auf Windows und macOS auf 1.0.22 aktualisiert, dies behebt Enumerations-Probleme mit ASMedia USB Hubs, Composite Geräten und falschen USB Geräteadressen auf Windows MSVC Projekt auf Windows hinzugefügt Auf Linux wird systemd anstelle von init.d verwendet, wenn verfügbar Grundlegenden Android Support hinzugefügt, momentan gibt es keine vorkompilierte App, brickd für Android muss aus dem Quelltext erstellt werden Downloads: Windows, Linux (amd64, i386, armhf), macOS

This isn't a Problem with Python 3.6. The Problem ist that you're using the IMU Brick (1.0) example with an IMU Brick 2.0. Try this example: https://www.tinkerforge.com/en/doc/Software/Bricks/IMUV2_Brick_Python.html#simple

That's one of the reasons we are switching the Bricklet connector to a different connector that doesn't have this kind of free standing pins.

Error code 31 means timeout. The Bricklet didn't respond in time to a request send by the example, see https://www.tinkerforge.com/de/doc/Software/Bricklets/SoundPressureLevel_Bricklet_JavaScript.html#api. Did you change the UID in the example to the UID of your Bricklet, as stated in line 5 of the example? var UID = 'XYZ'; // Change XYZ to the UID of your Sound Pressure Level Bricklet If you didn't then the example tries to talk to a Bricklet that doesn't exists and therefore will not answer, resulting in a timeout error.

Standardmäßig ist es so, dass Android eine Activity bei Config Änderungen wie Rotation neustartet. Die brickd App startet im onCreate der Activity den Service uns stoppt ihn im onDestroy. Im Service läuft der eigentliche brickd Code. Das Problem hier ist jetzt, dass der Service in einem extra Thread die C main() Funktion von brickd aufruft. Der Neustart der Activity und des Service führt jetzt dazu, dass main() verlassen und dann nochmal aufgerufen wird. Das ist etwas was in der normalen Version von brickd nicht passiert. Wenn dort main() verlassen wird, dann endet der Prozess. Daher kommen einige Teile des brickd C Codes nicht damit klar, dass main() ein zweites mal aufgerufen wird. Weil beim zweiten Aufruf von main() gewissen Annahmen, die der Code über den Zustand des Programms macht, nicht mehr gelten. Die kurzfristige Lösung ist es den Neustart der Activity und damit des Services und damit des zweiten main() Aufrufs zu unterbinden. Dazu muss die Activity angeben, dass es die Config Änderungen wie Rotation selbst behandeln kann und daher nicht neugestartet werden muss. Das habe ich jetzt erstmal eingebaut. Die langfristige Lösung wird sein dem C Code beizubringen, dass main() auch mehrfach aufgerufen werden kann. Potentiell muss auch das Verhältnis von Activity und Service zu einander anders gebaut werden.

Das ist komisch, dass du da die Parameter beim Starten alle angeben musst. Denn du gibst da jeweils exakt die Standardwerte an, außer beim Update Intervall, das ist standardmäßig 3 Sekunden. Beim Subscribe kennt MQTT # und * als Platzhalter im Topic. Dabei steht # für beliebig viele Element im Topic und * für exakt ein Element im Topic. Wenn du also das hier ausführst mosquitto_sub -v -t tinkerforge/bricklet/outdoor_weather/# dann sendet mosquitto_sub eine Subscribe Anfrage an den Broker für das tinkerforge/bricklet/outdoor_weather/# Topic. Der Broker vergleicht dann alle eingehenden Nachrichten mit dem Topic und sendet dann an mosquitto_sub alle die übereinstimmen. Der mosquitto_sub hat aber keinen Einfluss darauf was das brick-mqtt-proxy.py Script tut. So funktioniert MQTT nicht. MQTT arbeitet nach dem Publish/Subscribe Modell. Clients (mosquitto_sub, mosquitto_pub, brick-mqtt-proxy.py, etc) kommunizieren nicht direkt miteinander, sondern immer nur mit einem Broker der dann die Nachrichten zwischen den Clients weiterleitet. brick-mqtt-proxy.py verbindet sich mit dem Broker und sendet (Publish) im Update Intervall Nachrichten über die Bricks und Bricklets an den Broker. Das ist völlig unabhängig davon, ob noch anderen Clients verbunden sind, die die Nachrichten empfangen können, oder nicht. mosquitto_sub verbindet sich mit dem Broker und teilt diesem mit (Subscribe), dass es gerne Nachrichten unter dem angegebenen Topic empfangen würde. Der Broker schaut sich die Topics der eingehenden Nachrichten an (z.B. von brick-mqtt-proxy.py). Wenn eine Übereinstimmung mit einer Subscription vorliegt, dann wird die Nachricht an den entsprechenden Client weitergeleitet. Wenn sich keiner für die Nachricht interessiert wird sie im Broker verworfen. Du kannst dir das als stille Post mit 3 Personen vorstellen. Der Broker sitzt in der Mitte und brick-mqtt-proxy.py flüstert dem Broker was von links ins Ohr. Der Broker flüstert dann die Nachrichten weiter an mosquitto_sub auf der rechten Seite, aber nur die Nachrichten mit einem Topic das mosquitto_sub dem Broker vorher genannt hat. Wenn es nur darum geht deinem Nachbarn Daten weiterreichen zu können, dann ist wahrscheinlich eine einfache Portfreigabe des Broker Ports am einfachsten.

Ich starte brick-mqtt-proxy.py auf dem PC an dem auch das Outdoor Weather Bricklet angeschlossen ist und der Mosquitto Broker läuft: python brick-mqtt-proxy.py Und dann laufen da unter tinkerforge/bricklet/outdoor_weather/<UID>/station_data tinkerforge/bricklet/outdoor_weather/<UID>/sensor_data die Daten ein: mosquitto_sub -v -t tinkerforge/bricklet/outdoor_weather/#

Du kannst hier die aktuellste Version der brick-mqtt-proxy.py Datei herunterladen https://raw.githubusercontent.com/Tinkerforge/brick-mqtt-proxy/master/brick-mqtt-proxy.py und deine Version damit ersetzen. Dass sollte dann schon alles sein.

Die jetzige Implementierung erwartete da folgendes: mosquitto_pub -t tinkerforge/bricklet/outdoor_weather/Es8/get_sensor_data/set -m 24 Das Vorgehen ist aber inkonsistent zum restlichen Verhalten des MQTT Proxies. An anderen Stellen wo wir solche Getter haben die ein Parameter haben ruft der MQTT Proxy intern den Getter mit allen möglichen Parameterwerten ab und erstellt daraus dann eine Message. Das habe ich jetzt auch für das Outdoor Weather Bricklet so abgeändert. Mit der aktuellen git Version kommt dann da sowas bei heraus (formatiert für bessere Übersicht): tinkerforge/bricklet/outdoor_weather/Fax/station_data { "_timestamp":1530613201.561859, "241":{ "wind_speed":0, "temperature":265, "wind_direction":255, "gust_speed":6, "rain":120, "humidity":31, "last_change":1526, "battery_low":false }, "149":{ "wind_speed":0, "temperature":262, "wind_direction":15, "gust_speed":0, "rain":969, "humidity":32, "last_change":38, "battery_low":false } } tinkerforge/bricklet/outdoor_weather/Fax/sensor_data { "_timestamp":1530613201.572538, "179":{ "last_change":37, "temperature":253, "humidity":38 } } Ich empfange hier zwei Stationen (241 und 149) und einen Sensor (179).

Stimmt, da ist ein Bug. Das hat original mal funktioniert, und ja die $serverNonce Variable war schon immer überflüssig. Allerdings wurde danach die Unpack Logik überarbeitet, so dass dann _brickd_get_authentication_nonce() nicht mehr ein Array sondern eine Referenz auf ein Array zurückgegeben hat. Die authenticate Funktion wurde aber daran nicht angepasst. Deine Lösung dazu funktioniert, hier ist meine: https://github.com/Tinkerforge/generators/commit/ce21670b63cc07417e0d3540a57f9f0d53a32fd7 Danke für den Hinweis!

Unsere Python Bindings und Beispiele verwenden ipdb nicht. Daher muss der Import dafür aus deinem Code kommen. Ist dein Python Code denn in einer Datei namens "Python-Code__geändert2.0.py", die dort erwähnt wird?

But the Master Brick worked before you put it into bootloader mode? Do you have anything connected to the Master Brick, apart from the USB cable? If yes, disconnect everything apart from the USB cable and try again. Is the reset button stuck, keeping the Brick in reset? Or does the reset button feel normal?

Try to put in in bootloader mode a second time, even if the blue LED is already off.

Nic, freut mich das es funktioniert. Das zeigt mir, dass ich z.B. nicht vergessen habe die Hälfte der relevanten Dateien zu committen Ich habe jetzt auch Hotplug hinzugefügt. Zwei Dinge die jetzt noch fehlen: eine Möglichkeit die Konfiguration zu ändern und das Log einsehen zu können.

libusb funktioniert jetzt auch. Es fehlen noch ein paar Dinge, das ganze ist aber jetzt erstmal grundsätzlich funktional und funktioniert auch runter bis Android 4.4.

duaw, stimmt es fehlen momentan einige Beispiele, das ist nicht gut. Wir arbeiten daran und haben mit dem Release der neuen Bricklets diese Woche die Lücke auch schon ein Stück weiter geschlossen. Ich denke wir werden die Lücke in den nächsten 1-2 Wochen ganz schließen können. NoCee, du hast Recht, die GUI Integration ist nicht gut dokumentiert. Das "Problem" hier ist, dass GUI Beispiele typischerweise länger und, abhängig von der Programmiersprache und GUI Framework, oft aus mehreren Dateien bestehen. Die Beispiele sind aber absichtlich möglichst kurz gehalten. Ich setzte mir dafür mal ein "GUI Integrations" Tutorial auf die TODO Liste in dem man das dann besser beschreiben kann und ein GUI Beispiel mit allen API Bindings umsetzt.

RED Brick Image 1.12 Fix booting with an RS485 Extension present Update Brick Viewer to version 2.3.15 pdate all API bindings: C/C++ 2.1.20, C# 2.1.18, Delphi/Lazarus 2.1.19, Java 2.1.18, JavaScript 2.0.18, Octave 2.0.18, Perl 2.1.17, PHP 2.1.17, Python 2.1.17, Ruby 2.1.17, Shell 2.1.17, Visual Basic .NET 2.1.17 Download: RED Brick Image

RED Brick Image 1.12 Boot mit aufgesteckter RS485 Extension funktioniert wieder Brick Viewer auf Version 2.3.15 aktualisiert Alle API Bindings aktualisiert: C/C++ 2.1.20, C# 2.1.18, Delphi/Lazarus 2.1.19, Java 2.1.18, JavaScript 2.0.18, Octave 2.0.18, Perl 2.1.17, PHP 2.1.17, Python 2.1.17, Ruby 2.1.16, Shell 2.1.17, Visual Basic .NET 2.1.17 Download: RED Brick Image

Ich habe da mal gerade einen ersten Schuss gemacht. Im brickd git unter src/build_data/android/brickd liegt jetzt ein Android Studio Projekt, dass mittels NDK den brickd C Code in eine Android App verpackt. brickd an sich funktioniert und ich kann mich von meinem PC aus mit Brick Viewer auf mein Android Phone verbinden. Was noch fehlt ist eine funktionierende libusb Version. libusb kann für Android kompiliert werden. Dem Android Studio Projekt unter src/build_data/android/brickd habe ich eine kompiliert libusb Version beigelegt. Aber der libusb_init Aufruf schlägt fehl, da die offizielle libusb Version nicht mit den Restriktionen eines nicht-gerooteten Android Phones umgehen kann. Das ist ein bekanntes Problem, aber kein großes Problem, denke ich. Es finden sich genug Forks von libusb auf GitHub, die sich mit diesem Problem befassen. Da muss man sich jetzt nur das passende heraussuchen.

Brick Logger 2.0.7 Add support for CAN 2.0, Industrial Counter, Industrial Digital In 4 2.0, Industrial Dual Relay, Industrial Quad Relay 2.0, IO-4 2.0, LED Strip 2.0, Load Cell 2.0, Particulate Matter, PTC 2.0, Real-Time Clock 2.0, Sound Pressure Level, Thermocouple 2.0 and Voltage/Current Bricklet 2.0 Downloads: Windows, Linux, Mac OS X, RED Brick

Brick Logger 2.0.7 Support für CAN 2.0, Industrial Counter, Industrial Digital In 4 2.0, Industrial Dual Relay, Industrial Quad Relay 2.0, IO-4 2.0, LED Strip 2.0, Load Cell 2.0, Particulate Matter, PTC 2.0, Real-Time Clock 2.0, Sound Pressure Level, Thermocouple 2.0 und Voltage/Current Bricklet 2.0 hinzgefügt Downloads: Windows, Linux, Mac OS X, RED Brick