rtrbt

Moin, Du kannst nicht explizit die Verbindungsdaten speichern, das wird nur gemacht, wenn du Connect klickst. Das geht bei dir aber nicht, weil der RED-Brick kein angeschlossenes Modem detektiert. Du hast da ja vermutlich gerade einen WLAN-Stick angeschlossen. Du musst dich also vermutlich mal per Mini-USB mit dem RED-Brick verbinden, den 3G-Stick anschließen und dann die Konfiguration machen.

Moin, Das ist mehr oder weniger normal. Der Brick Daemon pollt alle Anschlüsse (mit fallender Frequenz) selbst wenn nichts angeschlossen ist, damit er es mitbekommt, wenn du eben doch etwas anschließt. Mit der nächsten Brick Daemon-Version wechseln wir für den Raspberry Pi aber vermutlich das Backend, was zu einer niedrigeren CPU-Last führen sollte. Den Effekt wirst du dann trotzdem, wenn auch schwächer, sehen. Edit: Wenn du Bricklets angeschlossen hast, die keine großen Performanceanforderungen haben (also z.b. ein Barometer Bricklet im Gegensatz zum Thermal Imaging Bricklet), kannst du in /etc/brickd.conf die Zeit zwischen den Polling-Vorgängen erhöhen. Dafür musst du die folgenden Einträge hinzufügen oder verändern: bricklet.portA.sleep_between_reads = 200 bricklet.portB.sleep_between_reads = 200 [usw bis portH] bricklet.portHAT.sleep_between_reads = 200 200 heißt dabei, dass der entsprechende Port alle 200µs auf ein neues Datenpaket gepollt wird. Du kannst damit experimentieren, es ist aber möglich, dass du dir die Performance der Bricklets deutlich verschlechterst, wenn du die Zeiten zu hoch stellst.

Da sehe ich spontan nicht was das Problem ist, hier ein paar Gedanken dazu: Du hast vermutlich kein WiFi-Problem zwischen dem Stapel und openHAB/Brick Viewer: Das Bricklet zählt den "Last Change" selbst mit, d.h. wenn die 12403 Sekunden sich sekündlich aktualisieren kommst du ohne Probleme zum Bricklet. (Übrigens: Siehst du im Brick Viewer Timeouts oder funktioniert das auch alles wie es soll?) Das ist mir abgesehen von einem Hardware-Defekt absolut unklar wie das passieren kann. Eigentlich solltest du nicht "halbe Pakete" oder so empfangen können. Hast du eventuell etwas anderes in der Nähe, das das Frequenzband stört? Das ist natürlich der schwierigste Punkt um ihn herauszufinden, das kannst du vermutlich am einfachsten testen, indem du das Outdoor Weather Bricklet direkt neben den Sensor legst oder andersrum.

Moin, Die Presets bekommen wir von diesem Projekt. Da gibt es immer mal Änderungen, die sind aber außerhalb unserer Kontrolle. Das sind aber, wie der Name schon sagt, Presets. Du kannst also auch die notwendigen Informationen von Hand eintragen, danach sollte es gehen. Fragen dazu: Wie heißt der Provider genau? Entweder bin ich unfähig zu suchen oder "Simply" gab es so nie in der Liste. Bei welcher Version gab es Simply in der Liste noch? Wenn du den Brick Viewer wieder auf diese Version down-gradest, funktioniert es dann? Funktioniert es, wenn du die Provider-Informationen von Hand einträgst oder ist das prinzipiell kaputt? Gruß, Erik

Moin, Das scheint zu stimmen. Deshalb bekommst du da auch keinen Unterschied, macOS hat ja jeweils nur eine Option wie der Brick Viewer gerendert werden kann.

Moin, Das sieht von außen nicht openHAB-spezifisch aus. Passiert das auch, wenn du (je nachdem was einfacher ist) das Bricklet aus openHAB entfernst und oder openHAB kurz runterfährst, dann das Bricklet neustartest und mit dem Brick Viewer nachsiehst? Das würde das Debugging schonmal immens erleichtern, wenn es kein openHAB-Problem ist ;)

Moin, Wir suchen einen oder mehrere Freiwillige, die die angehangene Brick Viewer-Version auf einen Mac testen können, der sowohl einen in die CPU integrierten Graphikchip, als auch einen dedizierten Graphikchip hat. Hintergrund ist, dass das normale Verhalten von Qt-Programmen scheinbar ist, dass sie immer auf dem dedizierten Chip gerendert werden, was den Energieverbrauch erhöht. Ich habe deshalb eine Version des Brick Viewers gebaut, die macOS mitteilt, das sie auch auf dem integrierten Chip laufen kann. Wir haben leider weder in der Firma noch privat Macs mit dediziertem Chip, was das Testen erschwert. Mich würden folgende Dinge interessieren: Was zeigt der Energietab der Aktivitätsanzeige an, wenn die "normale" Brick Viewer-Version 2.4.14 läuft? Meine Erwartungshaltung wäre "Graphics Card: High Perf.". (Siehe die Screenshots im unten verlinkten Issue) Wenn jetzt stattdessen die angehangene Brick Viewer-Version verwendet wird, wird dann stattdessen "Graphics Card: Integrated" angezeigt? Damit der Test sinnvoll ist muss aber "Integrated" bereits angezeigt werden, wenn keine Version des Brick Viewers läuft. Ansonsten hat ein anderes Programm den Wechsel auf "High Perf." ausgelöst. Weitere Details finden sich in diesem Issue auf Github. Gruß und danke für's testen! Erik brickv_macos_2_4_14_snapshot_02df3f2.dmg

Moin, Interpretiere ich den Graphen richtig, dass sich die Kommunikation mit dem Bricklet nicht mehr komplett aufhängt? Wenn du jede Minute den Pin änderst müsste ja ansonsten der FailureCounter ab diesem Punkt jede Minute um eins wachsen. Es sind aber in beiden Graphen Zeitabschnitte deutlich größer eine Minute bis der Zähler weiter hochspringt.

Moin, Bei dir passieren zwei Dinge: 1. Können die Bindings nicht das Distance US Bricklet mit der UID 123 finden. Hast du da eventuell einfach die falsche UID? Sieh am besten mal mit dem Brick Viewer nach. 2. Wird genau dieser Fehler falsch behandelt, deshalb die komische Ausgabe. Eigentlich sollte da der übliche Timeout ausgegeben werden. Das erste Problem musst du auf deiner Seite fixen, das zweite sollte mit der Version im Anhang repariert sein. Gruß, Erik tinkerforge_mqtt_bindings_2_0_11_bf38edd1.zip

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