rtrbt

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.

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.

Hi, You have to correct this in your program, the outdoor weather station can't correct this itself.

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).

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.

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

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.

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.

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

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.

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.

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

Firmware: DC Brick 2.3.10 Fix response length of get_drive_mode Download: DC Brick

Firmware: DC Brick 2.3.10 Länge der Antwort der get_drive_mode-Funktion repariert Download: DC Brick

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

Wir bieten zumindest keins an. Da müsstest du dir selbst etwas basteln.

Kein Problem, ich hatte schon mit sowas gerechnet. Caching ist ein schweres Problem und ich bin selbst oft genug über openHAB-Caching-Probleme gestolpert

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.

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

Are you sure that you run the right version of the bindings? I've just tested the attached zip and your script on a Pi 3B+ and it works fine.

Hi, Seems like my edit interleaved with you loading the thread. Can you please try again with the ee8d2719-Version?

Moin, Ich habe das hier mal getestet, bei mir funktionierte alles nach dem Stapelwechsel, nur die PaperUI zeigt an, dass das Bricklet offline ist, das hat sich aber durch einen Neustart des Stacks behoben. (Das Bricklet einfach so umstecken während alles läuft ist ja technisch gesehen nicht unterstützt) Das Bricklet wird bei dir in der PaperUI als online angezeigt? Dann leg dir mal ein Item für den Draw Status des Bricklets an. Das Item kannst du dann mit "smarthome:send Jzc_DrawStatus REFRESH" aktualisieren, eventuell siehst du dann im Debug-Log etwas interessantes. Die Konfiguration über Text-Dateien habe ich vor einer Weile mal getestet, aus irgendeinem Grund hatte ich dann alle Items doppelt pro Thing, dem bin ich noch nicht nachgegangen.

Hi, I can not reproduce your first problem. The output looks like you are passing something that is not a string, but the type check of the bindings should detect that and print a more helpful error message. Does this happen every time you attempt to call write_line, or only in specific cases? Did you call any other functions before calling write_line? Your second problem should be fixed with the attached version of the bindings. Erik Edit: The first problem happens only when using Python 2. It should be fixed in the attached version. tinkerforge_mqtt_bindings_2_0_9_ee8d2719.zip

Da will ich nicht die Hand für ins Feuer legen, aber das sollte klappen. Die Kabellänge ist extrem relevant bei EMV-Kram.

Hm die einzelnen Ausreißer sind dann eventuell einfach weniger starke Störungen. Da reicht es ja, wenn ein Bit flippt. Das geht natürlich auch, fall nicht runter Ich würde erwarten, dass es hilft, mit dem Ambient Light V3 hast du ja keine Probleme soweit. Die Koprozessor-Bricklets (also alle mit 7-Pol-Stecker) sprechen alle das selbe Protokoll. Kannst du natürlich machen. Das 2.0 gibt den Luftdruck eine Größenordnung genauer aus und misst auch die Temperatur. Sieh dir dann auf jeden Fall noch die Sensor-Konfiguration vom Barometer 2.0 an (und wenn du das Humidity 2.0 kaufst, die set_samples_per_second), bei deinem Anwendungsfall reicht es ja, wenn du die Temperatur selten misst (also alle z.B. 10 Sekunden), bei hohen Messfrequenzen (eher in der Region mehrmals pro Sekunde) erwärmen sich die Sensoren. Erik