rtrbt

Beim Humidity Bricklet 2.0 gibt es tatsächlich das Problem, dass sich das Bricklet selbst erwärmt und dann die Messung verfälscht. Dem kann man entgegenwirken, indem man die Messfrequenz kleiner wählt. Wir haben in Firmware 2.0.3 deshalb die Standardmessfrequenz auf 1 Hz gesetzt (von ursprünglich 20) du kannst aber, gerade wenn das was du messen willst eher träge ist, die Messfrequenz noch weiter verringern:

https://www.tinkerforge.com/de/doc/Software/Bricklets/HumidityV2_Bricklet_Python.html#BrickletHumidityV2.set_samples_per_second

Beim Temperature 2.0 könnte es einen ähnlichen Effekt geben, es gibt aber soweit ich das sehe gibt es keine API mit der du die Messfrequenz beeinflussen kannst.

7 hours ago, KlausGünther said:

Und dann wird es mit der neuen Rule Engine eh spannend bis das alles läuft....

Soweit ich das verstanden habe kannst du bei der neuen Engine die alten Rules weiterverwenden, die werden dann übersetzt. Stecke in den Details aber nicht drin.

@MiRo Das sieht dann wirklich nach einem reinen openHAB-Problem aus. Ich habe bei mir mal folgenden Aufbau hingestellt:

Ich schalte einmal pro Sekunde per Rule jeweils Pin 0, lese das auf Pin 1 zurück (das läuft dann über das Callback, also ohne expliziten REFRESH) und schalte mit dem Ergebnis die LED auf Pin 4. Falls das hängt kann ich mit den Schaltern nochmal versuchen Ereignisse auszulösen zum debuggen.

Das ganze sind eine IO16 2.0, zwei IO16 1.2 und eine IO16 1.1 an einem Master Brick 2.1 an einem Pi auf dem openHAB läuft.

Ich melde mich, wenn ich damit etwas rausbekomme.

Darüber habe ich die Tage auch nachgedacht. Soweit ich das sehe wäre das Portieren auf openHAB 3 ein eher überschaubarer Aufwand. Da meines Wissens damit die alte Rule-Engine rausfliegt hätte das sogar diverse Vorteile, da ich viel Code und redundante Namen sparen könnte. Die Actions könnten dann z.b. rgb.getColor() anstelle von rgb.brickletRGBLEDButtonGetColor() bekommen.

Die Frage wäre dann eher was ich mit openHAB 2 mache. Zwei Versionen warten kommt nicht in Frage, das heißt man könnte das ganze entweder als openHAB 2 Binding lassen, das auch in openHAB 3 funktioniert, oder eben alternativ openHAB 2 Support verwerfen und die ganzen Vereinfachungen die sich dann ergeben mitnehmen.

Ich habe aber noch auf absehbare Zeit (lies mindestens den nächsten Monat) noch andere Aufgaben die dringender sind, d.h. es eilt nicht da eine Entscheidung zu treffen.

Frage an die künftigen Nutzer (auch @StefanOHAN ) Plant ihr dann eher schnell auf openHAB 3 zu wechseln oder eher auf openHAB 2.5 zu bleiben?

Du benutzt das Authenticate falsch, den setInputValueCallbackConfiguration-Aufruf (und alles weitere was erst passieren soll, wenn die Verbindung steht und authentisiert ist) musst du in das returnCallback des authenticate-Aufrufs packen.

Moin,

Der Brick Viewer liest die installierten Pythonversionen per /usr/bin/python3 --version (bzw. python2) aus. /usr/bin/python3 ist höchstwahrscheinlich ein Symlink, den du auf deine installierte Python-Version umbiegen musst, dann sollte das funktionieren.

Bezüglich der Flankenverwirrung: Ich kenne dein Setup nicht genau, hier mein Verständnis davon, bitte korrigiere mal was falsch ist:

• Die IO-16-Bricklets haben alle relevanten Pins als Input mit Pull-Up konfiguriert
• Du hast da Taster/Schalter angeschlossen, die ganze Zeit den IO-Pin mit Ground verbinden und wenn du schaltest, trennen sie die Verbindung, weshalb der Pull-Up auf HIGH zieht.
• Dann ergibt z.B.

  2: 2020:09:28 20:54:22.162
  2: Port: a
  2: Interrupt Mask: 0x1
  2: Value Mask: 0x1
  
  2: 2020:09:28 20:54:22.711
  2: Port: a
  2: Interrupt Mask: 0x1
  2: Value Mask: 0x0

  Sinn weil du erst das Ereignis "Pin 1 hat sich geändert, ist jetzt HIGH" hast und dann das Ereignis "Pin 1 hat sich geändert, ist jetzt LOW"
• Was mich verwirrt ist dann

  für "3" habe ich wärend der Aufzeichnung den Schalter gedrückt und unten stehende Ausgabe 
  kam, beim Loslassen kam aber nichts.
  3: 2020:09:27 09:21:00.122
  3: Port: b
  3: Interrupt Mask: 0x80
  3: Value Mask: 0x44

  denn die Interrupt Mask sagt ja "Pin 7 hat sich geändert" und die Value Mask sagt "Pin 6 und 2 sind HIGH, der Rest LOW". Das würde danach wie ich deinen Aufbau verstehe aber ja das Ereignis Pin 7 HIGH -> LOW sein, also wenn du den Schalter losläst, nicht wenn du ihn drückst.

Zusatzfragen: Die erste Ziffer der Ausgabe ist die Nummer des IO-16-Bricklets? Du hast ja zwei alte und zwei neue, erzeugst du bei den neuen Interrupt und Value Mask selbst? Die Callbacks funktionieren da ja anders.

Moin,

Kannst du ein vollständiges Beispiel posten bei dem das Problem auftritt? Ich habe gerade versucht das hier nachzustellen aber es funktioniert.

Hast du neben dem Aufruf der Callback-Konfigurationsfunktion das Callback auch mit z.B.

io.on(Tinkerforge.BrickletIO16V2.CALLBACK_INPUT_VALUE,
    // Callback function for input value callback
    function (channel, changed, value) {
        console.log('Channel: ' + channel);
        console.log('Changed: ' + changed);
        console.log('Value: ' + value);
        console.log();
    }
);

registriert? Sonst schickt das Bricklet zwar Callbacks, sie werden aber von den Bindings ignoriert.

Sind die Firmwares aktuell?

Der Error-Callback der setInputValueCallbackConfiguration-Funktion ist soweit ich das sehe hier:

https://www.tinkerforge.com/de/doc/Software/Bricklets/IO16V2_Bricklet_JavaScript.html#BrickletIO16V2.setInputValueCallbackConfiguration

erwähnt. Die allgemeine API-Beschreibung auf derselben Seite (die zugegebenermaßen leicht übersehen werden kann, weil die Beispiele so lang sind) listet auch den Fehlercode auf den du da bekommst.

Den debounce gibt es nur bei dem Flankenzähler soweit ich das ad-hoc sehe.

Gruß,
Erik

Hi,

The palette is gnuplot's PM3D palette. It looks similar to the palettes used by FLIR.

https://stackoverflow.com/questions/28495390/thermal-imaging-palette

has further explainations.

Hi,

Als erste Frage: Sind das Voltage/Current 1.0 oder 2.0?

Moin,

On 9/25/2020 at 5:13 PM, MiRo said:

Ich bekomme seit einiger Zeit diese Traces von "TinkerforgeChannelTypeProvider", aber die beziehen sich jetzt alle auf Homematic: TinkerforgeChannelTypeProvider.txt. Das kommt jede Sekunde einmal.

Das ist normal und erwartet, openHAB fragt alle existierenden ChannelTypeProvider nach allen ChannelTypes bis einer sagt "den kenne ich". Dabei wird nicht darauf geachtet, welches Binding für welche ChannelTypen ist, deshalb fragt openHAB meinen Provider ob er den ChannelType kennt, was er nicht tut.

Daher kommt auch die Log-Flut: Im events.log z.B. ab 2020-09-27 09:00:00 siehst du, dass die Hue-Lampen andauernd offline und online gehen. Anscheinend werden die Channel-Typen jedes Mal wenn eine Lampe wiederkommt neu angelegt und landen dann aber auch bei meinem ChannelTypeProvider, der dann meckert weil er die Typen nicht kennt. Ich muss mal einbauen, dass er auch die Debug-Meldung nur ausgibt wenn der ChannelType mit "tinkerforge:" anfängt, sorry dass ich dir das Log so zumülle.

On 9/27/2020 at 9:48 AM, MiRo said:

Ich habe das program example_interrupt.c so erweitert, dass alle 4 (io16/io16v2) abgefragt werden konnten. Ich hatte nämlich heute gesehen, dass einige io16 noch gehen, andere aber nicht.

Im BrickViewer sah alles wieder gut aus. Aber im OH kamen Events z.B. von io16(UID-io2) nicht mehr an, wohl aber von io16(UID-io1).

Hier mal die Ausgaben von example_interrupt mit Kommentaren: Es fehlen bei einem Port die fallenden Flanken (Taster gedrückt Low->High, Taster losgelassen High->Low).

Wenn das System in dem Zustand ist, kommt nach dem erstmaligen "Verpassen" das HIGH->LOW interrupts. Kein Interrupt mehr für den PIN (oder ganzen PORT?).

Das ist denke ich der interessante Teil. In deinem Brick Viewer Screenshot sehe ich Timeouts, werden das mit der Zeit mehr wenn du in dem Zustand bist?

Fehlt in der example_interrupt-Ausgabe nicht eher die steigende Flanke? Ich sehe erst 0x44 und später 0xc4 0x44, da beim ersten Mal fehlt die Ausgabe die das höchste Bit gesetzt hat. Hat sich später wenn du die 0xc4 wieder bekomsmt das Problem von alleine gelöst oder hast du da das Callback neu konfiguriert o.Ä.?

Im Log selbst habe ich im Fehlerfall nichts relevantes gefunden, den Spam vom ChannelTypeProvider konnte man zum Glück gut per Regex rauswerfen.

Die Threadlisten usw. sehen soweit okay aus.

No you can't stack more than one RS485-Extension on a stack. However you can build a bus roughly like this:

IMU Stack 1                        Single Receiver Stack 
(Master + IMU + RS485) <---------->RS485(1)
IMU Stack 2                  |     Master<---USB---->PC
(Master + IMU + RS485) <------
IMU Stack 3                  |
(Master + IMU + RS485) <------
IMU Stack 4                  |
(Master + IMU + RS485) <------
IMU Stack 5                  |
(Master + IMU + RS485) <------
IMU Stack 6                  |
(Master + IMU + RS485) <------

This is documented here: https://www.tinkerforge.com/en/doc/Hardware/Master_Extensions/RS485_Extension.html#rs485-bus-assembly

1 hour ago, Siddhant said:

Sorry I didnt get this :( Could you please explain it maybe with an illustration as you did before? Thanks!

I just meant, that you need to configure each RS485 Extension only once, as the configuration is saved in the extension's memory. For this you don't have to build the bus already, but can instead just plug in a stack like this:

RS485
Master<--USB-->PC

Then configure the RS485 Extension, unplug the stack, swap the extension and so on.

Moin,

Du musst da an einigen Stellen vorsichtig sein: Die ±2% und ±0.2°C Angaben sind "typisch", was sich auf die Aussage aus dem Datenblatt bezieht. Auf Seite 7 siehst du die "Wahrheit". Die ±2% gehen da nur von 20% bis 60%, bei deinen ~70% bist du eher bei ±3%. Die MIN und MAX-Werte liegen weiter auseinander, da die vermutlich über deine ganze Kurve gehen, nach Augenmaß scheint es aber keinen Zeitpunkt zu geben, wo die ±3% tatsächlich gerissen werden. Ich passe das in der Dokumentation mal an, damit klarer ist, was mit typisch gemeint ist.

1 hour ago, AndiS said:

Hab dann die Funktion zur Kalibrierung des ADC gefunden und per Rotary 2.0 für jedes einzelne Bricklet durchgeführt. Unterschied blieb bestehen :(

Die ADC-Kalibrierung bringt dir nichts, das ist ein Feature, das sich nur auf sehr alte Bricklets auswirkt, die noch direkt vom Master Brick ausgelesen wurden. Die neueren Bricklets (mit 7-Pol-Stecker) haben alle einen eigenen Koprozessor und kommunizieren digital mit dem Master Brick. Im Fall des Humidity Bricklets 2.0 ist es sogar so, dass der ADC direkt im Sensor-Chip sitzt.

Du kannst die Bricklets selbst nicht nachkalibrieren, aber da, wie in deinem Graph zu sehen ist, das ja nur ein konstantes Offset zwischen den Bricklets ist, kannst du diesen auch hinterher, also in deinem Programm ausbessern. Falls du keinen anderen Sensor zum Vergleichen zur Hand hast: Ich würde erwarten, dass der "echte" Wert Nahe der roten/blauen Kurve liegt. Wenn du also bei dem Bricklet mit der grünen Kurve immer 2 Prozentpunkte addierst und bei dem mit der gelben Kurve immer 3 abziehst, solltest du nahe der Wahrheit sein. Bei der Temperatur kannst du das ähnlich machen.

Noch ein Tipp um die Messung genauer zu machen: Die Bricklets leiden unter einer Selbsterwärmung, wenn die Messfrequenz zu hoch ist. Je nachdem wie träge deine Umgebung ist, kann es sein, dass du deutlich seltener messen musst, dann lohnt es sich die set_samples_per_second-Funktion zu verwenden. Ich vermute, dass der kurze starke Temperaturanstieg, den du in den ersten ~200 Sekunden siehst, dieser Effekt ist.

Moin,

Ich habe dazu folgenden Satz Fragen:

• Was ist der komplette Aufbau? Also wie viele Stapel, sind die per USB, Ethernet oder Wifi angeschlossen, usw. Mach am besten mal einen Brick Viewer Screenshot
• Die anderen Bricklets, die noch funktionieren sind am selben Stapel?
• Siehst du etwas interessantes, wenn du das Logging hochdrehst? (mit log:set TRACE org.openhab.tinkerforge, dann bekommst du potentiell viel Ausgabe, aber lass das mal so laufen bis das Problem wieder auftritt) Durch deine Rule solltest du den Zeitpunkt, wann es kaputt ist ja finden, da würden mich die Log-Zeilen ab ~ 3 Minuten davor interessieren.

Probiere außerdem mal folgende Dinge, wenn das System gerade in dem kaputten Zustand ist:

• Die Ausgabe von shell:threads (in der openHAB-Konsole) könnte interessant sein.
• Was passiert, wenn du eine Aktualisierung mit

  smarthome:send Item_Name REFRESH

  erzwingst? Siehst du dann den neuen Zustand?

• Wenn du ein C-Programm nimmst, das sich auf das Input-Callback des IO16v2 registriert, aber das Aktivieren des Callbacks weglässt, kommen dann Callbacks an? (Du kannst z.b. das Interrupt-Beispiel nehmen, aber musst die Zeile mit

  io16_v2_set_input_value_callback_configuration

  weglassen): Ich gehe im Moment davon aus, dass die Callback-Aktivierung aus irgendeinem Grund verloren gegangen ist, wenn das Testprogramm jetzt die Callbacks wieder aktiviert, sehen wir nicht mehr ob das das Problem war.

Hi,

One receiver stack should be enough. You can assign a unique slave address to each of the IMU stacks via Brick Viewer, as per this guide.

For the configuration, connect the IMU stacks via USB, configure them and then build the RS485 bus, the configuration is saved persistently on the extensions. This also means that you can plug the RS485 extensions on the receiver stack (one after another; a stack with two RS485 extensions will not work) and configure them there.

Hi,

The RS485 Extension only works with a Master Brick (that's why it's called Master Extension ;) ). So at least two Master Bricks, two RS485 Extensions and one IMU Brick are required. The Master Bricks have to be bottom most in the stack, for example

RS485<---------->RS485
IMU              Master<-->PC
Master

should work.

Currently the Bindings only work with PaperUI. I've tried implementing support for the text files, but using them causes strange behaviour where things and channels are duplicated. I'm not sure if this can be fixed easily, as I'm assuming this is a problem with the dynamic thing and channel creation.

Hi,

The bindings are still in beta, but everything should be working, there is only some polishing missing, but I've been occupied with other projects for the last few months.

There will be some changes to the modeling of some Bricklets, for example input pins of the IO Bricklets are currently OnOffTypes but will be changed to OpenClosedTypes.

We actually have documentation available here: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html#api-bindings-openhab

Moin,

11 hours ago, ufechner said:

Wie ist die Chance for Julia bindings in 2020?

Schlecht, dieses Jahr sind wir gut ausgelastet. Leider steht Julia auf der Liste der Sprachen, für die man Unterstützung hinzufügen könnte immer noch weit unten auf der Liste.

Julia kann aber Bibliotheken aus diversen anderen Sprachen importieren, ich habe das (wegen der einfachen API) gerade mit den Python-Bindings ausprobiert, folgendes funktioniert bei mir:

using PyCall

ip_connection = pyimport("tinkerforge.ip_connection")
bricklet_gps_v2 = pyimport("tinkerforge.bricklet_gps_v2")

ipcon = ip_connection.IPConnection()
ipcon.connect("localhost", 4223)

gps = bricklet_gps_v2.BrickletGPSV2("Pvy", ipcon)

println(gps.get_coordinates())

ipcon.disconnect()

Wenn es eigene Julia-Bindings gäbe, würden die vermutlich nicht groß anders aussehen.

Gruß,
Erik

Moin,

(Disclaimer: Bin kein JavaScript-Experte)

Das Problem ist sogar noch etwas komplizierter, da du ja nicht weißt, wie viele Bricks/Bricklets vorhanden sind, das heißt rein technisch weißt du nicht, wann du fertig bist mit dem Warten auf die enumerate-Callbacks. Du kannst aber so Kriterien wie "ich weiß es sind genau X Bricks/Bricklets" oder "wenn nach 0.5 Sekunden kein neues Callback kam bin ich fertig" oder einfach "Ich warte eine Sekunde auf Callbacks" o.Ä. verwenden, das ist typischerweise gut genug.

Ein Ansatz der dein Problem löst wäre, wenn das Auslösen mit .enumerate() und die Callback-Verarbeitung zwar nebenläufig ist, du aber mit await darauf warten kannst. Es würde sich also anbieten, wenn du eine Funktion schreibst, die das Array anlegt, das Callback registriert, enumerate auslöst, nach deinen Kriterien auf Antworten wartet und dann das Array zurückgibt. Diese Funktion machst du async, dann kannst du im Hauptprogramm das ganze anschieben und wenn du das Ergebnis brauchst es per await abholen.

Gruß,
Erik

Moin,

Du musst die Parameternamen mitgeben, in deinem Fall sollte das wie folgt sein:

mosquitto_pub -t tinkerforge/request/industrial_dual_relay_bricklet/FLg/set_selected_value -m '{"channel": 0, "value": true}'

Das Flashen musst du über den Brick Viewer machen, siehe hier:

https://www.tinkerforge.com/de/doc/Software/Brickv.html#mit-brick-viewer

Der Brick Viewer läd die Firmware auch selbst runter, d.h. du musst nicht über die Downloadseite gehen.

Die Bilder sehen soweit gut aus, da ist also kein offensichtlicher Hardware-Defekt drauf. Welche Bricklets hast du außerdem Barometer noch zum Testen genommen?

Nur um sicher zu gehen: Auf dem Master Brick ist die aktuelle Firmware, also die 2.4.10? Wenn nicht, musst du die auf jeden Fall mal aktualisieren, der Master Brick unterstützt erst seit 2.4.4 die 7-Pol-Bricklets. Wenn du einen halbwegs aktuellen Brick Viewer verwendest (> 2.4.0) zeigt er übrigens verfügbare Firmware-Updates an.

17 hours ago, theobald said:

Ist schon raus, wann der ESP-Brick ungefähr verfügbar sein wird??

Man soll ja nichts versprechen, aber ich bin mal optimistisch und behaupte dieses Jahr noch.

10 minutes ago, theobald said:

Ich dachte immer der ARM auf dem Red Brick wäre (prinzipiell) schneller als der ESP8266

Ist er, du hast aber zwei Probleme.

1. Die Signale zum RED-Brick zu bekommen, aber wenn du mit den GPIOs schon mal was gemacht hast sollte das gehen (Hast du dann Drähte angelötet oder wie kommst du da ran?)

2. Ist die Frage wie du Interrupts bekommst, da musst du vermutlich einen Kernel-Treiber schreiben o.Ä. Das Linux auf dem RED-Brick ist allgemein eher langsam, im User-Space bist du da von "Echtzeit-Fähigkeit" weit weg.

Damit du nicht unnütz viel Zeit investierst: Es wird in den nächsten Monaten einen ESP32-basierten Brick geben, an dem neben den Bricklet-Ports noch ein paar GPIOs rausgeführt werden. Wenn dein Anwendungsfall einfach ist dieses Signal zu lesen und noch ein paar Bricklets daneben zu verwenden, kannst du auf den ESP32-Brick warten, dann kannst du deine Implementierung weiterverwenden.