borg

Wenn du set_response_expected_all(True) aufrufst wird für alle Aufrufe (auch für Setter) eine Nachricht vom Brick/Bricklet zurück zum PC gesendet und wenn diese nicht ankommt bekommst du eine TimeoutException.

Die ganzen delays sind da zu Demonstrationszwecken, damit die non-async Funktionen viel Zeit benötigen. Mit dieser Schleife hier while start + 2 > time.time(): await asyncio.sleep(0.1) print(time.time()) Zeige ich dann das ich während die Tinkerforge Getter aufgerufen werden weitere async Funktionen aufrufen kann, was ja Sinn der Sache ist. Hier eine vereinfachte Version: #!/usr/bin/env python3 # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "GKp" # Change XYZ to the UID of your Air Quality Bricklet import asyncio from concurrent.futures import ThreadPoolExecutor from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_air_quality import BrickletAirQuality import time _executor = ThreadPoolExecutor(10) async def tf_async_call(name, func): value = await asyncio.get_event_loop().run_in_executor(_executor, func) print('{0}: {1}'.format(name, value)) async def async_main(aq): task1 = asyncio.ensure_future(tf_async_call('Temperature', aq.get_temperature)) task2 = asyncio.ensure_future(tf_async_call('Humidity', aq.get_humidity)) # Here your async code await asyncio.wait([task1, task2]) print('Done!') if __name__ == "__main__": ipcon = IPConnection() # Create IP connection aq = BrickletAirQuality(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected loop = asyncio.get_event_loop() loop.run_until_complete(asyncio.ensure_future(async_main(aq))) ipcon.disconnect() Edit: Deine Idee mit den MQTT Bindings zu benutzen um damit Python asyncio zu machen hab ich leider nicht verstanden, aber was spricht dagegen den Code oben in einem asyncio-Umfeld einzusetzen?

Du meinst die neuen MQTT Bindings die noch in der Beta sind? Der Code ist zu 100% generiert und in der Tat nicht zum durchlesen gedacht. Allerdings ist dort ja nun wirklich MQTT die Schnittstelle und der Python-Code im Hintergrund für den Nutzer nicht relevant. Du meinst sowas? #!/usr/bin/env python3 # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "GKp" # Change XYZ to the UID of your Air Quality Bricklet import asyncio from concurrent.futures import ThreadPoolExecutor from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_air_quality import BrickletAirQuality import time _executor = ThreadPoolExecutor(10) async def tf_async_call(name, func, delay): def _non_async_delayed_call(func, delay): time.sleep(delay) return func() value = await asyncio.get_event_loop().run_in_executor(_executor, lambda: _non_async_delayed_call(func, delay)) print('{0}: {1}'.format(name, value)) async def async_main(aq): call_temperature = tf_async_call('Temperature', aq.get_temperature, 2) call_humidity = tf_async_call('Humidity', aq.get_humidity, 1) task1 = asyncio.ensure_future(call_temperature) task2 = asyncio.get_event_loop().create_task(call_humidity) print('Do something useful here while humidity and temperature are gathered...') start = time.time() while start + 2 > time.time(): await asyncio.sleep(0.1) print(time.time()) await asyncio.wait([task1, task2]) print('Done!') if __name__ == "__main__": ipcon = IPConnection() # Create IP connection aq = BrickletAirQuality(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected loop = asyncio.get_event_loop() loop.run_until_complete(asyncio.ensure_future(async_main(aq))) ipcon.disconnect() Edit: Hab das gerade nochmal ein bisschen aufgebohrt, damit man sieht das ich wirklich async calls machen kann während der getter-Aufruf läuft

Eine gängige Möglichkeit Callbacks in eine Eventloop einzubinden ist im Callback die Daten in eine Queue zu packen und im Eventloop die Queue auszulesen. Im Brick Viewer nutzen wir zum Beispiel eine Queue um die Daten des Tinkerforge Systems in die Qt-Eventloop zu bekommen ohne das die GUI blockiert wird: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/async_call.py

@piwo: Dass die Python Bindings Threads nutzen ist ja eigentlich erstmal ein internes Implementierungsdetail. Hast du mal ein konkretes Beispiel wo du asyncio extern verwendest aber die aktuellen Python Bindings nicht nutzen kannst?

Firmware: Outdoor Weather Bricklet 2.0.2 Remove Station/Sensor from list of identifiers after 12h with no data Download: Outdoor Weather Bricklet

Firmware: Outdoor Weather Bricklet 2.0.2 Entferne Station/Sensor von der Identifier-Liste wenn diese für mehr als 12 Stunden am Stück keine Daten senden Download: Outdoor Weather Bricklet

I am currently working on the Air Quality Bricklet, there is a bit more API coming too. So this is at the moment simply work in progress and the generator and air quality git are a bit out of sync.

Ich hab das jetzt auf die neueste Bosch-Auswertesoftware aktualisiert und gerade einen Dauertest gestartet. Ich würde das jetzt für mindestens 4 Tage laufen lassen, damit er zumindest einmal die kompletten Daten für die Kalibrierung sammeln kann. Danach dann nochmal 1-2 Tage um zu überprüfen ob die Sensor-Daten dann vernünftig sind. Dauert also noch ca. eine Woche bis es ein neues Release gibt (falls ich nicht noch weitere Probleme finde). Es gibt übrigens auch einen Modus wo das Bricklet die letzten 28 Tage zur Kalibrierung verwendet. Was meint ihr, macht es Sinn auf den 28-Tage-Modus umzusteigen um bessere IAQ-Werte zu bekommen? Ich tendiere aktuell dazu das zu tun. Zusätzlich noch eine Funktion um die aktuelle Kalibrierung zu löschen, damit man nicht 28 Tage warten muss bis man wieder vernünftige Werte bekommt wenn man die Umgebung des Bricklets komplett verändert. Man könnte die Kalibrierungszeit auch zwischen 4/28 Tage konfigurierbar für den Nutzer machen.

Da haben sich zwei Bugs miteinander verzahnt. Es gibt einen Bug im Bootloader der dazu führt das ein Bricklet in seltenen Fällen fälschlicherweise die Position 'Z' bekommt (die eigentlich für Bricklets die an Isolator Bricklets angeschlossen sind vorgesehen ist). Das ist an und für sich erstmal gar nicht so schlimm, dadurch geht nichts kaputt. Es führt aber dazu das im Brick Viewer das Bricklet ohne Parent angezeigt wird und die Auto-Update-Funktion hat dafür keine Unterstützung. Dadurch funktioniert auf einmal die Auto-Update-Funktion nicht mehr . Wird zum nächsten Brick Viewer Release gefixt.

You would need to add a RS232 Bricklet and construct this sentence from the data you get from the GPS Bricklet. The GPS Bricklet does not have API that transfers the NMEA sentences to the PC.

Yes, we would make a complete separate v2 version. We also would like to add .NET Core support if we do a major update of the C# bindings. For that we would have to exchange some of the internals with .NET Core compatible stuff too.

Neues Accelerometer Bricklet 2.0 mit Datenrate bis zu 25,6kHz Blogeintrag

New Accelerometer Bricklet 2.0 with data rate up to 25.6kHz Blog entry

Sweet, looks good! The design of the C# bindings is indeed quite old by now and it shows in the API. We try to always maintain backwards compatibility, so it often is hard to add new programming language features over time. Maybe it would make sense to have some kind of C# bindings 2.0 and maintain the old C# bindings for legacy applications for a while.

You can get the PPS signal as a callback in the API. From your question i assume you want it as a digital output? What is can do is: Use a GPS Bricklet 2.0 and a Industrial Digital Out Bricklet and every time you get the callback you set a digital output on the Bricklet. This will of course have a jitter that depends on the USB stack of your PC. I would expect something around +-1ms.

A synchronization directly on the Brick is unfortunately not possible. You can only get the PPS signal from a GPS Bricklet 2.0 and use that as a trigger to call a getter from a IMU Brick 2.0. What application do you have in mind for the synchronization?

Ich hab mir die Daten über das Wochenende loggen lassen und ich hatte in der Tat auch ein paar "Ausreißer" bei mir war es die Luftfeuchte-Messung mit ungefähr 10% Sprüngen nach oben. Das Air Quality Bricklet muss leider einen Binärblob von Bosch nutzen auf den wir aufsetzen. Seitdem wir das Bricklet veröffentlicht haben gibt es eine neue Version von der Bosch-Software mit etlichen Bugfixes laut Changelog. Bosch hat allerdings die API und ein paar Konstanten und Namen verändert. Daher kriege ich das heute nicht aktualisiert, ich denke am Freitag komme ich dazu, da gibt es dann eine neue Firmware-Version. Ich hoffe die Ausreißer sind damit dann gefixt!

Besten Dank, ist gefixt. Da fehlten sogar noch zwei weitere Links in der Doku .

@ChrisCA: Klingt interessant, schaue ich mir an. @theo: Ich kann mir nicht so recht erklären warum Mifare Classic funktioniert aber die anderen Typen nicht. Das kann ja dann zumindest kein Hardwaredefekt sein denke ich? Also der State wechselt von Initialization auf Idle bei dir, richtig? Sonst könntest du Mifare Classic ja auch nicht nutzen. Aber von da nicht zu den anderen States wenn du versuchst einen anderen Tag-Typ zu lesen?

Komisch, das ist mir noch nicht aufgefallen obwohl ich für die Tisch-Wetterstation viel mit dem Air Quality Bricklet getestet hab. Ich habs mir auf die TODO-Liste geschrieben da nochmal einen Test zu schreiben und mir das anzusehen.

Das klingt sehr sinnvoll, schreibe ich mir auf die TODO-Liste .

Du kannst die fcstd Dateien mit freecad öffnen: https://www.freecadweb.org/ Die meisten anderen Dateien sind irgendwelche Zwischenformate oder das Format welches unser spezifischer Laser Cutter versteht.

Die Gehäuse sind hier zu finden: https://github.com/Tinkerforge/cases Das ist leider aktuell eine unaufgeräumte Ansammlung, wie man schon an den unterschiedlichen Benennungen sehen kann. Da muss ich mal irgendwann aufräumen und das alles vernünftig benennen und generierte Dateien entfernen usw.

Die Bricklets mit 7-Pol Stecker werden auf dem RED Brick erst seit Brick Daemon Version 2.3.0 unterstützt. D.h. du müsstest entweder den Brick Daemon auf dem RED Brick aktualisieren oder ein RED Brick Image mit Version 1.9 oder höher verwenden.