rtrbt

This is really strange. To find out when the IPConnection is disconnected, you can use the DisconnectedCallback, for example like this: static void DisconnectedCB(IPConnection sender, short disconnectReason) { Debug.WriteLine(string.format("Disconnected at {}; reason: {}", DateTime.Now, disconnectReason)); } Then register the callback with ipcon.DisconnectedCallback += DisconnectedCB; in the Start_Click function. If you also add similar debug logging to the other functions, you should be able to see when the disconnect happens.

Sorry für die späte Antwort, war im Urlaub. Im Moment nur durch Bug-Reports. Ich bin leider immer noch mit anderen Projekten beschäftigt. Wenn du jetzt auf Switch umstellst, musst du aber daran denken, eventuell in ein paar Monaten wieder auf Contact zu wechseln. Langfristig werden reine Inputs wieder Contacts sein. Hm da hast du einen interessanten Bug getroffen. Anscheinend passiert folgendes: Ich habe ja die Remote Switch Bricklets von Hand implementiert, damit sie Bridges sind für die Funksteckdosen usw. Ich habe da eine Warteschlange von Tasks (z.b. Schalte die Dose xyz), eine Funktion die die Tasks abarbeitet und eine Variable über die ich mir merke, ob das Bricklet gerade schaltet (Die Funktion darf dann keinen neuen Schaltvorgang auslösen, wenn die Variable gesetzt ist). Diese Variable wird über das isSwitchingDone-Callback des Bricklets zurückgesetzt. Du hattest da jetzt anscheinend das Pech, dass das Callback verloren gegangen ist, also die Variable nie zurückgesetzt wird und deshalb keine Tasks mehr abgearbeitet werden. Der Reset über den Brick Viewer führt dazu, dass openHAB das Device neu initialisiert, da wird auch die Variable zurückgesetzt, die Warteschlange aber nicht geleert, deshalb die aufgestauten Schaltvorgänge. Ich baue mal einen Fix dafür, indem ich einfach ~alle 2 Sekunden explizit den Schaltzustand des Bricklets abfrage und darüber die Variable zurücksetze, falls es fertig ist. Dann kann dieses Problem nicht mehr auftreten. @MiRo Der Aufbau von oben lief bei mir seit dem 2.10. durch und die LEDs blinken noch. Falls sich das ganze doch aufhängt melde ich mich nochmal.

This is strange: This exception is only thrown if your IPConnection was not connected. However I don't see how you can reach the Timer1_Tick without first calling connect in your "Prikupljanje" function. This is because if you never call .Disconnect(), you will still receive callbacks. If you use the following implementation of Timer1_Tick public void Timer1_Tick(object sender, EventArgs e) { Timer1.Enabled = false; Debug.WriteLine("Timer1_Tick"); } Do you get the "Timer1_Tick" output only once? If not, your single-shot logic does not work. Some other things: You should switch the order of the following lines: Timer1.Enabled = true; Timer1.Interval = t2; If you enable the Timer before setting the interval, it is possible, that the timer runs with the wrong pre-configured interval first. A similar problem is with these lines: a.SetContinuousAccelerationConfiguration(true, true, true, Convert.ToByte(1)); a.ContinuousAcceleration16BitCallback += AccelerationCB; If you first register the callback and then call the Set...Configuration function to enable the callback, you don't miss any callback packets.

Hi, After registering the callback, you are calling ipcon.Disconnect(), but if you disconnect from the Ethernet Extension, no callbacks can be delivered. Removing this line should fix your problem. Closing the connection is still a good idea, but I think you do this (i.e. call ipcon.Disconnect()) in the Timer1_Tick handler.

Der Fix sollte automatisch in der nächsten Beta landen, er ist schon im Repository. Das ist ein interessanter Punkt über den ich so noch nicht nachgedacht hatte. Das hängt ja daran, dass ich nochmal alle (Generator-)Konfigurationen durchgehe und die deutsche Doku schreibe usw. Das heißt es ist vermutlich sinnvoll, wenn ich den Wechsel auf openHAB-3-Only möglichst spät mache, damit möglichst viel was noch auf meiner Liste steht es in eine 2.5er Beta schafft. Werde ich auf jeden Fall berücksichtigen.

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.

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

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