Jump to content

All Activity

This stream auto-updates

  1. Yesterday
  2. Hallo zusammen, vor einiger Zeit hatte ich mit folgendes angeschafft: 1x Tinkerforge Starterkit: Wetterstation 1x WIFI Master Extension 1x Weather Station Push Button Add-on 1x Step-Down Power Supply Die Wetterstation habe ich zusammengebaut, aber zu mehr bin ich nie gekommen - daher möchte ich alles zusammen gerne verkaufen. Preis ist VHB, Versand erfolgt versichert mit DHL für 5,90 €. Ihr könnt mir einfach eine Nachricht über das Forum zukommen lassen. VG Stefan
  3. Last week
  4. Hi, Wie ihr vielleicht schon gesehen habt gibt es jetzt eine "WARP"-Kategorie bei uns im Shop. Dabei handelt es sich um die Kategorie für unsere neuen WARP Charger (Wall Attached Recharge Point) und dazu passendes Zubehör. Beim WARP Charger handelt es sich um eine von Tinkerforge entwickelte Open Source KfW 440 förderfähige Wallbox! Details dazu könnt ihr im Blog nachlesen: https://www.tinkerforge.com/de/blog/warp-charger/ Da wir in der offiziellen KfW-Förderliste bereits mit aufgeführt sind, wurden wir tatsächlich von einer regelrechten Anfragenwelle überrascht. Wir haben
  5. Hello, As far as I know, all IMUs suffer from random bias every time they are powered on. Such a bias cannot be removed with one-time calibration. You can accept the randomness of the sensor loosing some accuracy or calibrate the sensor every time you power it on. Alternatively you can implement algorithms that consider stochastic phenomena such as a Kalman Filter. Cheers.
  6. ftr

    LED Streifen

    Danke für die Antworten.
  7. Ich lasse mal einen Langzeittest mit den Sensoren laufen die ich hier hab, mal schauen ob ich es reproduzieren kann.
  8. Update: Mit weniger Sensoren verhält es sich gleich. Was mir jedoch aufgefallen ist. Die Zeit bis es zu diesem verhalten kommt, sind nicht immer 12h. Es ist mir auch schon nach 1h passiert aber genauso auch erst nach 14h. Es lässt sich also zeitlich nicht wirklich eingrenzen. Mit nur einem Sensor habe ich den Fehler nicht bekommen. Ein weiters verhalten was ich nun festgestellt habe ist, dass manche Sensoren plötzlich keine Temperatur mehr liefern. Diese sind nicht am gleichen Verteiler noch immer die selben. Es kommen dann immer wieder Temperaturwerte von -0.1°C. Zusätzlich werden dann Sen
  9. Habe mir das gerade mal angesehen und musste feststellen, dass das nicht klappt. Die Umbenennungen von org.eclipse.smarthome nach org.openhab sind in openHAB 2 nur halb gemacht, aber in openHAB 3 komplett. Das heißt, dass ich bestimmte Pakete nicht einheitlich importieren kann. Der nächste Schritt wird dann wohl sein, noch eine letzte openHAB 2 kompatible Beta zu bauen, mit den kleineren Änderungen die so aufgelaufen sind, und danach auf openHAB 3 zu wechseln. Das wird wie gesagt aber noch etwas dauern, sorry.
  10. Ok jetzt verstehe ich das. Den nebenbei habe ich noch den Brickviewer geöffnet. Ah irgendwie bin ich davon ausgegangen das es nötig sein sollte die Objekte bei einem Verbindungsverlust neu zu erstellen. Habe den Code nun nach deinem Beispiel angepasst. Jetzt funktioniert es. Vielen Danke! 😀
  11. Hi Photron, Thanks for responding. I am basically just a lazy programmer who likes magic. What I have done so far is write a little bit of Ruby that 1) takes stock of Device descendants. 2) requires one of TF's source-files. 3) takes stock again and compares to (1) to identify any newly defined class. 4) gets DEVICE_IDENTIFIER and DEVICE_DISPLAY_NAME from the newly defined class. 5) Repeats for all source-files. This generates a device_info.txt which maps device_identifier, device class, source-file, and device_display_name. You can use any of these four to look up the other thr
  12. Tinkerforge::DEVICE_DISPLAY_NAMES is internal for error message purposes. What you're looking for is a device factory. The Ruby bindings don't have that. That's not a bad idea at all, that basically how Brick Viewer solves this problem. But instead of doing a linear search, Brick Viewer builds a dictionary that maps device identifier to device class and then uses that dictionary to do the lookup efficiently. What are you trying to build that requires a device factory?
  13. Das Brick Daemon Debian Package ist jetzt auch für arm64 verfügbar.
  14. The Brick Daemon Debian package is now also available for arm64 architecture.
  15. Brick Daemon 2.4.3 Fix SPI clock for HAT (Zero) Brick on Linux, if core_freq differs from 250 MHz Add config option to override SPI backend detection Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS
  16. Brick Daemon 2.4.3 SPI-Clock für HAT (Zero) Brick auf Linux korrigiert, falls core_freq von 250 MHz abweicht Config-Option zur Überstimmung der SPI Backend-Bestimmung hinzugefügt Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS
  17. Wie in der Doku beschrieben kommt ein Enumerate-Connected unaufgefordert durch Starten oder Resetten der Hardware. Ein Enumerate-Available kommt durch Anforderung über die enumerate() Funktion. Ich erwarte, dass bei den beiden Enumerate-Callbacks einer ein Connected- und einer ein Available-Callback ist. Alternativ hast du noch ein anderes Programm laufen, dass auch enumerate() aufruft. Enumerate Callback die von einem Programm ausgelöst werden kommen auch an allen Programmen an die zur gleichen Adresse verbunden sind. Anstatt die Toten die Lebenden finden. Den Fall, dass die onewire L
  18. Danke für deine Antwort. Ok jetzt wird es mir klarer. Nein auf den enumeration_type habe ich nicht geachtet jedoch habe ich den Code einfach vom Beispiel übernommen es steht also folgendes: if enumeration_type == IPConnection.ENUMERATION_TYPE_CONNECTED or enumeration_type == IPConnection.ENUMERATION_TYPE_AVAILABLE: Ich bin davon ausgegangen das es schon sinn machen würde sobald ein Enumeration Event ausgelöst wurde einfach die Objekte neu zu erzeugen und auch zu konfigurieren. Ok also ich ersetzte das Objekt nicht in der Liste. Sondern nur temporär das i Objekt. Wie würdest
  19. Nein. Ja. Schaust du auf den enumerate_type und unterscheidest Connected und Available Enumerate Callbacks? Zu der "Device has been replaced" Fehlermeldung: Die IPConnection hält intern eine Liste von UID auf Device Object. Wenn du für eine UID ein neues Device Object anlegst, dann wird das alte Device Object ersetzt. Wenn du dann auf dem alten Device Object Funktionen aufrufst, dann bekommst du den "Device has been replaced" Fehler. Das ganze kommt durch die "i = BrickletOneWire(uid, self.ipcon)" Zeile. Das ersetzt nicht den Eintrag in der onewire Liste, sondern du ä
  20. "erstmal so" würde ja vorerst reichen, es funktioniert ja ohne große Probleme. Danke.
  21. Hello, I have a question about discovery of devices with Ruby. Enumeration supplies the numeric device_identifier for each device, for instance 2103 for a 'LED Strip Bricklet 2.0'. See documentation. Next steps would be to load the file defining the matching class, and to initialize an instance of that class: require 'tinkerforge/bricklet_led_strip_v2' Tinkerforge::BrickletLEDStripV2.new ... In other words, I need the name of the matching class for a '2103 device' and the file which defines that class. Tinkerforge::DEVICE_DISPLAY_NAMES only maps device_identifier to
  22. Ja, das wird in 2.4.3 drin sein. Ich denke das kommt noch heute oder morgen raus.
  23. Ich habe leider keine grobe Timeline, wann ich überhaupt wieder für openHAB Zeit habe. Ich sehe mal zu, dass ich im Dezember noch ein paar Tage zwischendurch investieren kann. Wenn es sich ergibt, teste ich diese Woche mal, ob ich das Binding zumindest erstmal so bauen kann, dass es mit openHAB 2 und 3 kompatibel ist.
  24. Ich suche nun schon seit Tagen an einem Fehler jedoch komme ich einfach nicht dahinter. Wahrscheinlich habe ich einen Denkfehler oder sonnst etwas. Ich hoffe das mal jemand darüber schauen kann und mir sagen was ich Falsch mache. Folgendes möchte ich umsetzten. Ich verfolge dabei den Robusten Tinkerforge Ansatz in Python. Es gibt eben eine Rugged Class wobei ich mir hier zwei Instanzen erstelle in einem Programm. Jede Instanz hat einen HOST(brickdeamon) jedoch gibt es eine Master Instanz. Der Grund für diese Masterinstanz ist das alle anderen Instanzen neue Bricklets oder auch
  25. Diese Version funktioniert. So wie es aussieht, ist alles wie es sein soll! Danke für die schnelle Hilfe. Werden die Korrekturen irgendwann in den offiziellen brickd eingebaut? Viele Grüße, Martin
  26. Das funktioniert auf dem Raspberry Pi 4 auch nur zufällig, weil der CPU Governor dort die Core Clock bei wenig Last runter skaliert. Auf dem Raspberry Pi Zero läuft die Core Clock aber auf volle Pulle und dadurch ist die SPI Kommunikation zu schnell, weil brickd die falsch berechnet. Dadurch verstehen die Bricklets das dann nicht. Teste mal bitte die angehängte brickd Version. brickd_2.4.2+snapshot~b4e01c3_armhf.deb
  1. Load more activity
×
×
  • Create New...