borg

Das hängt ganz davon ab wie du deinen GUI-Slider nutzen möchtest. Je nach Anwendung ist es möglich auf die Änderung des Sliders direkt im Callback zu reagieren. Falls es in deinem Programm eine Main-Loop o.ä. gibt die alles behandeln soll, kannst du z.B. die Werte des Sliders in eine Queue (oder ein Future) packen und in der Main-Loop regelmäßig schauen ob etwas in der Queue ist.

Ich würde sagen die Messwerte des Air Quality Bricklet sind dafür gut genug.

Sehr komisch. Hast du diese Probleme auch wenn du das Bricklet an Port A anschließt? Oder nur an Port B?

In the database you can save the global value for each day. When you want to display the value you get the value from last day from the database and the value from today and the difference is the amount of rain from the last 24 hours. You can do the same for the amount of rain for the last 1 hour etc, depending on the frequency with which you save data to the database.

Die Air Quality Bricklet Firmware ist 74kb groß. Der Großteil davon ist kommt durch die Integration von "Bosch BSEC".

Das wird eher nicht funktionieren. Da wirst du die meiste Zeit die Entfernung zur Scheibe messen.

Wir haben drei Prozessoren im Einsatz bei den neuen Bricklets XMC1100_Q024x0016: Wenig Pinne, 16kb Flash (wird für alle Bricklets benutzt die nur einen Sensor auslesen o.ä.) XMC1302_Q024x0032: Wenig Pinne, 32kb Flash (wird benutzt wenn es etwas mehr zu berechnen gibt oder die API groß ist (z.B. LCD128x64) XMC1404_Q048x0200: Viele Pinne, 256kb Flash, Support für externen Quarz (wird benutzt wenn wir ganz viel Flash benötigen (z.B. für Floating Point Math) oder viele Pinne benötigen oder eine präzise Clock benötigen)

Das Air Quality Bricklet ist schon hauptsächlich dafür da den IAQ Index zu messen, die anderen Daten werden erhoben um diesen besser bestimmen zu können. Die Temperatur wird automatisch angeglichen wenn der Heater an ist, das ist aber sicherlich nicht 100% perfekt. Ein Temperature Bricklet wird da schon die besseren Ergebnisse liefern. Ein großer Unterschied ist auch die Abfragerate. Das Barometer Bricklet 2.0 kann mit einer Datenrate abgefragt werden die gut genug ist um damit die Höhe von einem Quadcopter zu kontrollieren. Das Air Quality Bricklet erhebt Daten alle 3 Sekunden. Wenn es nur darum geht Umweltdaten zu messen um langfristige Tendenzen zu erkennen (Temperaturunterschied Tag/Nacht, Luftdruckveränderung über die Wochen etc) sind die Messwerte des Air Quality Bricklets meiner Meinung nach gut genug. Die besten Ergebnisse erzielt man sicherlich mit den "Einzelbricklets". Dazu muss man auch sagen: Die Spezifikationen übernehmen wir natürlich von den Sensorherstellern und gehen davon aus das diese stimmen. Jeder Sensorhersteller hat da aber irgendwo im kleingedruckten andere Sache stehen. Ich hab mir z.B. gestern die Spezifikation des neuen Sensirion CO2 Sensors angesehen. Diese ist sehr gut, im Kleingedruckten steht aber das Sie nur garantieren dass diese Spezifikation für 90% der ausgelieferten Sensoren gilt... So richtig toll vergleichen kann man die unterschiedlichen Sensoren anhand der Spezifikation also leider nicht.

Attachment test. Edit: The attachments work fine for me, i tried Firefox and Chrome.

You have to save the value of the last "last_value" and then read the new value for the new day "new_value". The amount of rain for one day can then be calculated by "new_value - last_value".

Firmware: Temperature IR Bricklet 2.0 2.0.3 Use correct wait times during emissivity change Improved error handling in case of invalid read Download: Temperature IR Bricklet 2.0

Firmware: Temperature IR Bricklet 2.0 2.0.3 Use correct wait times during emissivity change Improved error handling in case of invalid read Download: Temperature IR Bricklet 2.0

The first idea that comes to mind: The Ethernet Extension only supports a limited number of concurrently open sockets. Do you open several sockets at the same time? Or maybe, do you not close a socket and instead of reusing it open a new one? This can happen if you create new IPConnections instead of reusing/closing it.

Kannst du mal einmal die Firmware im Anhang testen? Ich konnte das sporadisch reproduzieren und nach ein bisschen testen sieht es so aus als würden wir mit dem Chip der das Display steuern zu _langsam_ sprechen. Sehr eigenartig. Zumindest konnte ich mir das Problem mit einer höheren Frequenz nicht mehr reproduzieren. segment-display-4x7-bricklet-v2.0.3-beta1.bin

Habe soeben Version 2.0.3 veröffentlicht. Per Default wird jetzt ein 28-Tage-Fenster für die Kalibrierung verwendet welches man per API wieder auf 4 Tage zurück stellen kann. Die API ist dann verfügbar wenn es das nächste Bindings-Release gibt. Die Ausreißer werden jetzt rausgefiltert und nicht verwendet. Ich hab mehrere Tests gemacht bezüglich des IAQ Wertes. Wenn sich die Luftqualität ändert lässt sich das am IAQ-Wert definitiv ablesen. Zum Beispiel steigt der Wert wenn wir den Laser Cutter anstellen oder jemand frischen "dampfendes" Essen reinbringt o.ä. und er sinkt sofort wieder wenn wir lüften. Wenn sich der IAQ-Wert eigentlich nicht ändern sollte (z.B. über das Wochenende wenn keiner hier ist) verhält er sich manchmal ein bisschen komisch, finde ich. Der Wert wandert dann oft leicht auf und ab ohne ersehbaren Grund. Das längere Kalibrierungs-Fenster scheint das aber über die Zeit definitiv zu verbessern. Hab es aber jetzt natürlich noch keine 28 Tage am Stück laufen lassen. Ich habe nochmal einen Test gestartet den ich jetzt für mindestens einen Monat durchlaufen lasse.

Firmware: Air Quality Bricklet 2.0.3 Bosch BSEC aktualisiert auf v1.4.7.1 RemoveCalibration API hinzugefügt Set/GetBackroudCalibration API hinzugefügt Download: Air QualityBricklet

Firmware: Air Quality Bricklet 2.0.3 Update Bosch BSEC to v1.4.7.1 Add RemoveCalibration API Add Set/GetBackroudCalibration API Download: Air QualityBricklet

Komisch, probiere ich morgen aus ich da etwas reproduzieren kann.

Bezüglich deiner dynamischen ID + Name + Klasse-Problematik: Du kannst da dynamisch wie folgt dran kommen: #!/usr/bin/env python3 # -*- coding: utf-8 -*- from tinkerforge import device_factory for device_id in device_factory.DEVICE_CLASSES: name = device_factory.get_device_display_name(device_id) cls = device_factory.get_device_class(device_id) print("Device ID: {0}, Name: {1}, Class: {2}".format(device_id, name, cls))

Wenn du Callbacks nutzt und die Daten nicht direkt im Callback verarbeiten kannst, kommst du nicht darum herum entweder Queue oder vergleichbares zu nutzen oder nur den letzten Wert zu speichern. Das hat jetzt auch nichts mit asynchron vs prozedural zu tun, die Daten fallen nunmal komplett unabhängig von dem Mainloop an. Ich würde es wie folgt lösen: #!/usr/bin/env python3 # -*- coding: utf-8 -*- # HOST = "localhost" PORT = 4223 UID = "XYZ" # Change XYZ to the UID of your Air Quality Bricklet import asyncio from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_air_quality import BrickletAirQuality _air_pressure_queue = asyncio.Queue() def cb_air_pressure(air_pressure, loop): asyncio.run_coroutine_threadsafe(_air_pressure_queue.put(air_pressure), loop) async def event_loop(loop): ipcon = IPConnection() aq = BrickletAirQuality(UID, ipcon) ipcon.connect, HOST, PORT) aq.register_callback(aq.CALLBACK_AIR_PRESSURE, lambda x: cb_air_pressure(x, loop)) aq.set_air_pressure_callback_configuration(100, False, 'x', 0, 0) while True: air_pressure = await _air_pressure_queue.get() print('Air Pressure: {0}'.format(air_pressure)) if __name__ == "__main__": loop = asyncio.get_event_loop() loop.run_until_complete(event_loop(loop)) Wenn es darum geht Daten in einer Datenbank o.ä. zu speichern bietet es sich an eine Queue für alle Daten zu nehmen und den Typ des Datums mit zu speichern, z.B.: queue.put((TYPE_AIR_PRESSURE, air_pressure)) Da kannst du dann in deiner Mainloop eine Stelle haben an der du die Daten entgegen nimmst und ja nach Typ entsprechend bearbeitest und in der Datenbank speicherst

Ich glaube da hast du etwas missverstanden. Die MQTT-Bindings sind dazu da damit man Bricks/Bricklets per MQTT ansprechen kann. Die sind nicht dazu da um irgendetwas per Python zu machen. Das ist sozusagen ein Binary welches du ausführen kannst. Das wir den Code auch veröffentlichen ist nur Zugabe. Zum Beispiel kann man damit über die MQTT-Anbindung von Node-RED Bricks/Brickelts nutzen. Was du dir da anschaust ist generierter Code (genauso wie die Python-Bindings übrigens). Das ist so als würdest du dir generierten X86-Assembler anschauen und dich darüber wundern das es schlecht lesbar ist. Wenn du wissen möchtest wie die MQTT-Bindings zustande kommen musst du hier schauen: https://github.com/Tinkerforge/generators/tree/master/mqtt

Hast du vielleicht vergessen neuzustarten als du das Brickelt an Port B angeschlossen hast? Die Bricklets sind nicht hotplug-fähig.

Die mA-Angaben bei den Bricks und Bricklets beziehen sich auf 5V, während der Stack Current sich bei dir auf 10,7V bezieht. Die 2,5A können also unmöglich stimmen. An welchem Port ist das Segment Display 4x7 angeschlossen? Vielleicht tritt dieses Problem hier auf? https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Segment_Display_4x7.html#bekannte-fehler-probleme

Nichts. Hier nochmal das Beispiel wie du die Python-Bindings asynchron nutzen kannst: #!/usr/bin/env python3 # -*- coding: utf-8 -*- # HOST = "localhost" PORT = 4223 UID = "XYZ" # Change XYZ to the UID of your Air Quality Bricklet import asyncio from concurrent.futures import ThreadPoolExecutor import functools from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_air_quality import BrickletAirQuality _executor = ThreadPoolExecutor(10) async def event_loop(loop): tf_async = functools.partial(loop.run_in_executor, _executor) ipcon = IPConnection() aq = BrickletAirQuality(UID, ipcon) await tf_async(functools.partial(ipcon.connect, HOST, PORT)) task_temperature = tf_async(aq.get_temperature) task_humidity = tf_async(aq.get_humidity) result = await asyncio.gather(task_temperature, task_humidity) print('Temperature: {0}, Humidity: {1}'.format(*result)) if __name__ == "__main__": loop = asyncio.get_event_loop() loop.run_until_complete(event_loop(loop)) Du musst dich in dem Beispiel um keine locks, notify, rendezvous oder barriers kümmern.

Nur um das klar zu stellen: Die Python-Bindings sind zu 100% kompatibel zu Python 3. Piwo möchte die Python-Bindings zusammen mit der Python 3 asyncio Library nutzen und da wir diese nicht intern verwenden benötigt es mehr Boilerplate Code um die Python-Bindings mit asyncio zu nutzen.