rtrbt
Administrators
-
Benutzer seit
-
Letzter Besuch
Alle erstellten Inhalte von rtrbt
- Thermal Imaging - Visual Basic .NET Code - PictureBox
-
Betaversion der openHAB-Bindings
Moin, Das klingt gut Die Java-Bindings 2.1.27 haben neue API für das Industrial Dual Analog In 2.0 Bricklet und das Barometer Bricklet hinzugefügt. Die openhab-Bindings benutzen die API aber noch nicht, deshalb habe ich die Abhängigkeit noch nicht aktualisiert. Gruß, Erik
-
Problem mit build_environment_setup.sh
Moin, Ich habe hier auf einer frischen VM nochmal getestet und diverse weitere Probleme mit dem Script gefunden. Ich komme aber erst am Montag dazu, das Script fertig zu reparieren. Wenn du die Dokumentation bauen willst, empfehle ich dir aber Docker zu verwenden. Aus Altlast-Gründen verwenden wir da eine gepatchte ältere Sphinx-Version, die aufzusetzen ist etwas kompliziert. Mit Docker geht das automatisch. Zum Installieren musst du folgendes machen: sudo apt install docker.io sudo usermod -a -G docker $USER # Aus und einloggen oder alternativ: newgrp docker docker pull tinkerforge/build_environment_full Danach kannst du im doc-Git mit ./make_with_docker html die Dokumentation bauen. Perspektivisch werde ich das build_environment_setup.sh mal so umbauen, dass es Docker und das Image mitinstalliert. Gruß, Erik
-
Announcements
Firmware: LCD 128x64 Bricklet 2.0.9 Improve draw performance Download: LCD 128x64
-
Veröffentlichungen
Firmware: LCD 128x64 Bricklet 2.0.9 Performance des Zeichnens verbessert Download: LCD 128x64
-
Alternativen zu Temperatur/Luftfeuchte Sensor TH-6148?
Moin, Hier ist kein anderer kompatibler Sensor bekannt. Das Outdoor Weather Bricklet implementiert nur genau die Kommunikation mit der Weather Station und dem TH-6148.
-
Problem mit build_environment_setup.sh
Moin, Hat build_environment_setup.sh etwas interessantes ausgegeben? generate_tables.py setzt das generators-Git in seinen Import-Path und verlässt sich darauf, das darin device_infos.py erstellt wurde. Das sollte das Shellscript eigentlich gemacht haben, weil darin, bevor die Doku gebaut wird, generate_all.py in generators ausgeführt wird.
-
RED Brick Progammierung in C++
Es sieht so aus, als ob du nicht gegen die pthread-Bibliothek linkst. Wenn du in deinem Makefile den cc-Aufrufen das Argument -pthread mitgibst, sollte es funktionieren.
-
Outdoor Weather Station - Wind Direction sensor
Hi, You have to correct this in your program, the outdoor weather station can't correct this itself.
-
Outdoor Weather Station - Wind Direction sensor
In case you mean the orientation of the cardinal directions: The Outdoor Weather Bricklet does not support remapping the directions (i.e. north, east, south, west -> east, south, west, north).
-
Outdoor Weather Station - Wind Direction sensor
The sensor operates mechanical and the station does not have any facility to calibrate for non-horizontal orientation, so you must install the station as horizontal as possible. On top of the rain fall sensor, there is a small bubble level that can help you orient the station.
-
Betaversion der openHAB-Bindings
Moin, Das liegt daran, dass ich eigentlich alles, was eine boolsche Variable ist auf einen Switch abbilde. Der Generator bekommt es aber nicht hin zu sehen, dass die Channel zumindest read only sein sollten. Ich gebe dir aber recht, dass Contact hier sinnvoller wäre. Setze ich mir mal auf die TODO-Liste. Das funktioniert bei mir (sowohl mit der alten IO-16 als auch der 2.0). Welche openHAB und Bindings-Versionen hast du? Legst du neue Items für die Inputs an oder verlinkst du sie auf bereits existente Items? Ich sehe im Log (log:tail in der Karaf-Konsole) folgende Ausgabe, wenn ich ein neues Item anlege: 15:20:09.589 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'H5H_InputValuePin1A1-tinkerforge:brickletio16v2:H5H:BrickletIO16V2InputPin1' has been added. 15:20:09.592 [INFO ] [smarthome.event.ItemStateChangedEvent] - H5H_InputValuePin1A1 changed from NULL to ON Gruß, Erik
-
Frage zum HatBrick in Verbindung mit RaspberryPI & Touch
Etwas fertiges gibt es nicht. Ich sehe spontan folgende Optionen: Du kannst ein Bricklet-Kabel nehmen und entweder ein Breakout Board oder direkt am Kabel die 5 Volt abgreifen. Alternativ kannst du ein USB-Kabel zerlegen und den Stecker an eine der USB-Buchsen des Raspberry Pis anschließen.
-
Betaversion der openHAB-Bindings
Moin, Beta 23 ist im Post oben. DC Bricks haben jetzt Kontrollchannel und LED Strips einen Channel der konfigurierbar viele LEDs auf die selbe Farbe setzt. Die Farbe wird vom HSBType z.B. eines ColorPickers automatisch nach RGB(W) konvertiert. Die Dokumentation sollte gleich auf dem Tinkerforge-Server sein.
-
Herr Mevada
Hi Ravi, If the GPIO pins on your Raspberry Pi are not occupied yet, you can connect the Thermal Imaging Bricklet with either a HAT Brick or HAT Zero Brick and a 7p-7p cable of any length. If the GPIO pins are occupied, you need a Master Brick and a 7p-10p cable. Cables are available here. Erik
-
MASTER_CALLBACK_STACK_VOLTAGE_REACHED funktioniert nicht mehr, warum?
Da muss ich meine Aussage von oben korrigieren: get_stack_voltage/current misst _nur_ Spannung/Strom an der Eingangsbuchse einer Step Down Power Supply. Das bringt dich mit PoE also nicht weiter. Das muss ich in der Doku mal ausbessern, steht jetzt auf der TODO-Liste. Warum bei dir das Callback nicht auslöst kann ich dir jetzt nicht sagen. Du kannst aber stattdessen irgendein Callback der neueren Bricklets benutzen, da kannst du explizit "value_has_to_change" auf false setzen.
-
MASTER_CALLBACK_STACK_VOLTAGE_REACHED funktioniert nicht mehr, warum?
Das Problem ist, dass du den Strom per USB einspeist. Die Stack-Voltage ist die Spannung, die über den Strom-Stecker des Stapels ankommt. Wenn du dein Programm testen willst, musst du also auch wenn du per USB an den Master gehst, zumindest den Strom über PoE oder eine Step-Down-Power-Supply einspeisen. Es gibt auch noch get_usb_voltage und zugehörige Callbacks, die funktionieren aber mit dem Master 2.1 nicht mehr.
-
Betaversion der openHAB-Bindings
Moin Kurzer Zwischenstand: Ich habe die DC-Brick-Modellierung nochmal umgebaut, die Target Velocity, Acceleration usw. sind jetzt Channel, das vereinfacht das schreiben von Rules (und macht sie in manchen Fällen sogar unnötig) Bezüglich der LED-Strip-Color-Picker-Geschichte: Das habe ich mal angefangen zu implementieren, musste aber feststellen, dass hier gerade keine RGBW-LEDs auffindbar sind. Habe mal neue bestellt. Das dauert aber noch ein paar Tage, bis die ankommen und ich die HSB->RGBW-Farbkonvertierung getestet habe. Ich will nichts versprechen, aber eventuell gibt es nächste Woche eine neue Beta, mit der kannst du dann beides testen. Erik
-
Announcements
Firmware: DC Brick 2.3.10 Fix response length of get_drive_mode Download: DC Brick
-
Veröffentlichungen
Firmware: DC Brick 2.3.10 Länge der Antwort der get_drive_mode-Funktion repariert Download: DC Brick
-
Betaversion der openHAB-Bindings
Moin, Ich bin bisher noch nicht dazu gekommen, muss gerade ein anderes Projekt priorisieren. Ich werde aber diese Woche noch einen Tag für diversen Kleinkram Zeit haben, da sollte auf jeden Fall die DC-Brick-Rule rausfallen. Erik
-
Accelerometer Bricklet 2.0
Wir bieten zumindest keins an. Da müsstest du dir selbst etwas basteln.
-
Betaversion der openHAB-Bindings
Kein Problem, ich hatte schon mit sowas gerechnet. Caching ist ein schweres Problem und ich bin selbst oft genug über openHAB-Caching-Probleme gestolpert
-
Betaversion der openHAB-Bindings
Ich habe das bei mir mit 2.5.3 getestet, ich würde aber nicht erwarten, dass sich 2.5.4 groß anders verhält. Das Changelog scheint nur Änderungen in den Addons zu haben.
-
MultiTouch Proximity Verständnisfrage
Moin, Eventuell musst du da mit Sensitivität und Rekalibrierung experimentieren. Der Proximity-Wert funktioniert so, dass intern alle Elektroden zusammengeschaltet werden. Damit bekommst du, je nach den konkreten angeschlossenen Elektroden, ein größeres Detektionsfeld. Das wird hier genauer erklärt. Erik