rtrbt

Moin, Interessant wäre da natürlich, wovon genau der Speicher verbraucht wird (z.B: das Python-Programm, der Brick Daemon oder vielleicht auch das Terminal, das 3 Tage an Ausgabe im RAM hält). Das kannst du rausfinden, indem du das ganze nochmal laufen lässt und dann in einem Terminal htop --sort-key=PERCENT_MEM ausführst. Mach davon mal einen Screenshot und häng ihn hier an. Teste am besten vorher, ob htop installiert ist und funktioniert, mit F10 kannst du es wieder beenden. Da kannst du auch gleich nachsehen, wie viel RAM ohne das laufende Programm schon weg ist. Das zeigt htop in der Mem-Zeile rechts an. Du musst damit nicht unbedingt drei Tage warten, wenn nach ein paar Stunden schon deutlich mehr RAM belegt ist, als beim Start des Programms, ist das schon interessant. Gruß, Erik

Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.6 Add all voltages callback Download: Industrial Dual Analog In 2.0

Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.6 All Voltages-Callback hinzugefügt Download: Industrial Dual Analog In 2.0

Moin, Die Datenbank gibt es noch, aber keine schöne Möglichkeit darauf zuzugreifen. Am einfachsten ist es, wenn du die Wayback-Machine bemühst. Es gibt hier ein Capture von 2017: https://web.archive.org/web/20170404212840/http://www.tinkerunity.org/wiki/index.php/DE/Hauptseite

Hm das sieht wirklich seltsam aus. Eventuell kratzt du genau am Timeout, auch wenn mir unklar ist, warum das 2,5 Sekunden dauern sollte. Du kannst mal versuchen, die MQTT-Bindings mit --ipcon-timeout 10000 zu starten, eventuell hilft das.

Moin, Ich fange mal etwas grundlegender an: Die "neuen" openHAB-Tinkerforge-Bindings findest du hier: https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/ Die sind aber noch in der Beta, also nicht 100%ig fertig. Outdoor Weather Bricklets werden aber gut unterstützt. Wenn du die installiert hast, kannst du in der Inbox manuell einen Brick Daemon hinzufügen, dann wird das Bricklet automatisch gefunden und du kannst es hinzufügen Die Wetterstation musst du dann aber wieder von Hand hinzufügen über die Inbox, das Bricklet als Bridge angeben und die ID der Station eintragen. (Das Bricklet hat einen Channel der die gefundenen IDs anzeigt). Hintergrund warum du das händisch machen musst ist, dass du dann, wenn die Station neustartet (z.b. bei Batteriewechsel) du nur die ID in der Thing-Konfiguration ändern musst und nicht alles neu anlegen. Gruß, Erik

Die 1000ms sind tatsächlich etwas lang, ich setze mir mal auf die Liste, mir die Default-Werte mal anzusehen für alles, was nur Callbacks schickt, wenn der Wert sich ändert. In dem Zuge kommt dann auch das Update-Interval für die IO-16 1.0, das gibt es aber ich habe die Funktion an die falsche Stelle konfiguriert. Hm, beim alten IO-16 und dem Dual Button fehlt da das read-only-Flag, füge ich mal ein. Wie immer Danke fürs Testen!

Das wäre durchaus möglich. Beim Entwickeln ist mir das zumindest manchmal passiert. Da installiere ich das Binding natürlich ungleich öfter, aber wer weiß, was genau das Problem ist. Ich habe gerade Beta 22 hochgeladen, du kannst damit nochmal testen, ich hoffe, dass die kombiniert mit deiner Neuinstallation die ganzen Probleme löst. Wenn sich Bricklets nochmal in einem offline-Zustand festhängen oder andere Bindings nicht mehr gehen, sag unbedingt nochmal bescheid, das ist ja doch eher kritisch. @matthiask Das LED-Strip-Index-Problem ist in Beta 22 gefixt, du kannst bei dir mal den String "2,255,0,0,255,255,255,0,255,0,0,0,0,0,0,255" testen, der sollte zwei LEDs auslassen, dann eine rot, eine weiß, eine grün, eine schwarz (aus) und eine blau setzen.

Ah, die Fehlermeldung war wirklich hilfreich, da habe ich das Problem direkt mit gefunden: Ich habe ja vor einer Weile etwas Magie eingebaut, damit Channel dynamisch erzeugt und gelöscht werden können, z.B. für die IO-16-Pin-Konfiguration. Da gibt es das interessante Problem, dass ich, wenn ich alle Channel neu erstelle (also jedes Mal, wenn die Konfiguration sich ändert), die Konfiguration von Channels, die bereits da waren, behalten will, bei neu erstellten Channeln lade ich die Standardkonfiguration. Das Nachschlagen der vorhandenen Konfiguration funktioniert so, dass ich das Thing nach dem Channel mit der UID des (eventuell vorhandenen) Channels frage, was wenn das Thing den Channel gerade nicht kennt null zurückgibt. Damit muss der Code umgehen können, also wenn null zurückkommt, einen neuen Channel mit der Default-Konfiguration erstellen. Ich hatte im Zuge der letzten Beta einmal das null-Handling aufgehübscht, da verwendet openHAB Tools um den Code zu annotieren (z.B. "Diese Funktion gibt nie null zurück") und dazu ein Analysewerkzeug, das Warnungen erstellt, wenn man das falsch macht (also z.B. bei einer Funktion die null zurückgeben kann dann ohne Prüfung den Rückgabewert verwendet). Die Analyse ist nicht ganz perfekt, und ich habe an der Stelle nicht genug nachgedacht und den Hinweis, dass da ein Nullcheck unnötig ist einfach geglaubt, das stimmte aber offensichtlich nicht, deshalb fliegt dir das gerade um die Ohren. Ich fixe das mal und baue eine neue Beta. Das Discovery-Remove-Problem liegt daran, dass ich in Beta 20 die alten Discovery-Ergebnisse entfernt habe, bevor die neuen eingefügt werden. Das korrekte Vorgehen (was Beta 21 auch tut) ist, erst die neuen einzufügen und dann alle, die älter sind zu entfernen.

Moin, Den Fehler habe ich schon mal gesehen, bin mir aber gerade unsicher, ob das etwas war, was ich durch eine openHAB-Neuinstallation losgeworden bin, oder ob da im Code was kaputt war. Da bei dir aber auch die anderen Bindings kaputt sind, vermute ich, dass du in das Problem gelaufen bist, dass ich beim Entwickeln manchmal treffe: Wenn man einzelne Bindings in openHAB zu oft oder mit ungünstigem Timing aktualisiert, scheint es manchmal zu passieren, dass irgendein interner Cache falsche Werte hat, dann kann man die Installation gefühlt wegwerfen. Ich habe da aber noch in keiner Weise eine Regelmäßigkeit ausmachen können, deshalb gibt es da keinen Bug-Report, den ich gefunden oder geschrieben hätte. Haben da dann die anderen Bindings wieder mit dir geredet? Das ist erwartet: openHAB fragt alle ThingType/ChannelType/ConfigDescriptionProvider nach, ob sie für IDs einen entsprechenden Typen oder eine Description liefern können, unabhängig davon ob die Provider zu einem spezifischen Binding gehören oder nicht. Deshalb ist die Meldung auch nur DEBUG, ich benutze die intern, um Konfigurationsfehler in der Generator-Config zu finden. Das sollte auf jeden Fall helfen, ich hoffe das hat dir nicht dein Produktivsystem zerschossen. Gruß, Erik

Moin, @André K. Teste mal die angehangene Firmware für das Barometer Bricklet. Ich habe das Verhalten vom Temperature Bricklet, wenn man es auf slow konfiguriert hat, nachgebaut. Das heißt, du musst nichts konfigurieren, aber wenn das Barometer Bricklet die selben Probleme hat, sollten sie mit dieser Firmware weg sein. @duaw Ich bin mir nicht ganz sicher, wie Theos Binding mit den Bricklets arbeitet (also ob es z.B. manchmal explizit resettet). Du kannst aber testen, ob die langsamere I²C-Geschwindigkeit bei dir hilft, indem du periodisch (z.B. alle 5 Minuten) mit MQTT oder einen Python-Script die set_i2c_mode-Funktion benutzt um den langsamen Modus zu erzwingen. Die angehangene Firmware für das Barometer Bricklet kannst du auch testen, falls du damit auch Probleme hast. Dafür musst du nichts am Setup ändern. Der Hauptvorteil an den openHAB-Bindings ist, dass sie dir viel Arbeit abnehmen, weil sie z.B. Messwerte direkt in Items legen, ohne dass du etwas konfigurieren musst. Brick(let)-Konfiguration geht direkt über die PaperUI und wird automatisch angewandt, wenn du z.B. den Stapel ziehst und neu ansteckst oder die Verbindung zum Brick Daemon mal weg war. Theoretisch musst du, wenn du das neue Binding benutzt nie eine Textdatei anfassen. Mit den MQTT-Bindings hast du andererseits die volle Kontrolle über die Bricks/Bricklets, musst dich dafür aber selbst um die Robustheit kümmern. Zu deinem Timeout-Problem: Die Meldung kommt von den MQTT-Bindings. Der Timeout (der übrigens eigentlich konfigurierbar sein sollte, habe ich mir mal auf die TODO-Liste gesetzt) sollte auf den standardmäßigen 2,5 Sekunden stehen. Das ist etwas unerwartet, dass bei deinem Aufbau (da ist jetzt nichts Traffic-intensives dabei) regelmäßig Timeouts kommen (was heißt übrigens regelmäßig? Einmal pro Minute/Stunde/Tag?) aber an sich kann es schon passieren, dass mal ein Paket verloren geht. barometer-bricklet-slow-i2c.bin

Hast du an dem Aufbau auch ein Temperature Bricklet oder ist das die Temperatur, die du vom Barometer Bricklet bekommst? Das könnte ja eventuell die These zu Grabe tragen, dass nur das Temperature Bricklet die Probleme verursacht. Eigenwerbung: Mit den neuen openHAB-Bindings (siehe den Beta-Thread) kannst du den I²C Modus auch setzen

Der RED-Brick verwendet aus der Konfiguration der Ethernet Extension nur die MAC-Adresse. Dir kann aber folgendes passieren: Wenn du den Stack per PoE bootest, startet der Master Brick relativ schnell, verwendet die Konfiguration, nach einer Weile ist der RED-Brick gebootet, der resettet den Stack und benutzt dann seine eigene Konfiguration. Das heißt, dass du, wenn du a) auf dem Master und dem RED-Brick die selbe statische IP-Konfiguration hast und b) schnell genug bist, dich auf den Master Brick verbinden kannst, der dir dann nach ein paar Sekunden weg-resettet wird. Davon nicht verwirren lassen. Wenn du willst, dass dieser Effekt nicht auftreten kann, kannst du die Ethernet Extension auf statische IPs konfigurieren und alle IPs auf 0.0.0.0 setzen, dann siehst du die erst im Netz, wenn der RED-Brick damit läuft.

Nein, das Temperatur Bricklet setzt die Geschwindigkeit nur vor seiner Abfrage kurz runter und danach wieder hoch. Nein, nur durch einen Reset des Bricklets. Unter der Prämisse, dass es nur das Temperature Bricklet ist, das den Bus lahmlegt sollte das nicht notwendig sein. Falls das Barometer das auch hinbekommt, kann man sich das natürlich nochmal ansehen.

Das ist unabhängig davon ob du Callbacks oder Getter benutzt. In beiden Fällen muss der Master Brick mit dem Sensor kommunizieren.

Moin André, Versuch mal das Temperature Bricklet im langsamen I²C-Modus zu betreiben. Eventuell hast du auf deinem Dach Störstrahlung. Bei den alten Temperature/Barometer Bricklets hängen die Sensoren am selben I²C-Bus, es wäre also möglich, dass eine Störung des Temperature Bricklets das Barometer Bricklet mitreißt. Das würde sich auch mit deinem Log decken.

Die Wärmeentwicklung ist erwartet: Die Ethernet-Extension muss von 48 Volt auf 5 Volt Spannungswandeln und der RED-Brick zieht deutlich mehr Strom als der andere Stapel. Außerdem erzeugt er selbst einiges an Abwärme. Ansonsten bin ich mir noch nicht sicher, was genau das Problem ist. Stell als erstes mal mit dem Brick Viewer die Systemzeit des RED-Bricks ein: Das geht unter RED Brick->Settings->Date/Time da gibt es den Update Brick to Local Time Button. Ich habe dir mal ein Testskript gebaut, den Anhang kannst du im Import/Export-Tab des RED-Bricks importieren. Das Programm läuft einmal pro Minute und schreibt in die Log-Dateien des Program-Tabs. Damit du auch wenn das USB-Kabel nicht angeschlossen ist, siehst ob das Programm durchgelaufen ist, habe ich eingebaut, dass es die rote LED des RED-Bricks kontrolliert: LED aus: Programm lief noch nicht (Die LED flackert beim Booten kurz, das macht der Brick selbst) LED an: Programm ist mindestens einmal durchgelaufen LED macht Heartbeat (wie die grüne LED daneben): Programm läuft gerade Im Idealfall probierst du zuerst aus, ob das Programm bei dir funktioniert, indem du einen Aufbau baust, bei dem du den anderen Stack erreichst und es dann ausführen lässt. Im Brick Viewer unter RED Brick->Program->Logs sollte dann unter Continuous eine stderr.log und eine stdout.log liegen, die stderr.log sollte nur die Zeit der Ausführung enthalten, die stdout.log hat die Zeit, die Ping-Tests und die IP-Connection-Tests mit jeweils den Enumerate-Ergebnissen (also die Hardware die an dieser IP angeschlossen ist) und falls Thermocouple-Bricklets gefunden wurden deren Zustand. Teste dann mal bitte folgende Aufbauten: Stapel 1: RED-Brick + Ethernet-Extension (ohne Master Brick), Stapel 2: Master Brick + Ethernet Extension. Beide Stapel ohne Thermocouple-Bricklets. Stapel 1: RED-Brick + Ethernet-Extension (mit Master Brick), Stapel 2: Master Brick + Ethernet Extension. Beide Stapel ohne Thermocouple-Bricklets. Stapel 1: RED-Brick + Ethernet-Extension (mit Master Brick), Stapel 2: Master Brick + Ethernet Extension. Beide Stapel mit Thermocouple-Bricklets ohne Thermofühler. Stapel 1: RED-Brick + Ethernet-Extension (mit Master Brick), Stapel 2: Master Brick + Ethernet Extension. Beide Stapel mit Thermocouple-Bricklets mit Thermofühler. Stapel 1: RED-Brick + Ethernet-Extension (mit Master Brick), Stapel 2: Master Brick + Ethernet Extension. Stapel mit Thermocouple-Bricklets ohne Thermofühler. Stapel 2 mit Thermocouple-Bricklets mit Thermofühler. Stapel 1: RED-Brick + Ethernet-Extension (mit Master Brick), Stapel 2: Master Brick + Ethernet Extension. Stapel mit Thermocouple-Bricklets mit Thermofühler. Stapel 2 mit Thermocouple-Bricklets ohne Thermofühler. Folgende Tests dann für jeden der Aufbauten durchführen: Ohne USB-Kabel booten Warten bis die rote LED am RED-Brick einen Heartbeat macht Zeit aufschreiben (das ist wichtig, damit ich das Log der Ausführung zuordnen kann, die Logs werden hintereinander geschrieben) Warten bis die rote LED am RED-Brick dauerhaft leuchtet USB-Kabel anschließen Warten bis die rote LED am RED-Brick einen Heartbeat macht Zeit aufschreiben Warten bis die rote LED am RED-Brick dauerhaft leuchtet. Runterfahren/Strom trennen USB-Kabel angeschlossen lassen, wieder booten Warten bis die rote LED am RED-Brick einen Heartbeat macht Zeit aufschreiben Warten bis die rote LED am RED-Brick dauerhaft leuchtet USB-Kabel abziehen Warten bis die rote LED am RED-Brick einen Heartbeat macht Zeit aufschreiben Warten bis die rote LED am RED-Brick dauerhaft leuchtet. Runterfahren/Strom trennen Wenn du das für alle Aufbauten gemacht hast, häng hier mal die Logs an. Die kannst du mit dem Brick Viewer im Programs-Tab des RED-Bricks unter Logs runterladen. Dazu brauche ich dann noch die Zeit->Test-Aufschlüsselung. Sorry, dass das so ein komplizierter Test ist, aber es ist ja auch ein kompliziertes Problem thermotester.tfrba

Damit ich da den Überblick nicht verliere, du hast folgendes Ausgangszenario: LAN-Kabel sind alle eingesteckt, das USB-Kabel am RED-Brick nicht, Switch ist aus. Und dann folgende Tests gemacht? Switch an, RED-Brick bootet über PoE, Netzwerkverbindung funktioniert Dann USB-Kabel eingesteckt, dann verlierst du die Netzwerkverbindung zum anderen Stapel Alles aus, USB-Kabel eingesteckt gelassen, dann alles wieder gebootet, dann funktioniert es nur, wenn du die Thermofühler an den Bricklets angeschlossen hast?

Moin, Das klingt alles sehr verwirrend. Mich würde mal ein Foto vom Aufbau interessieren. Zusätzlich kannst du auf der RED-Brick-Konsole mal versuchen, die IP des Switches und der Stapel jeweils anzupingen (mit ping 192.168.0.1 usw.) Edit: Wenn du beim Switch die IP konfigurieren kannst, ist das ein Managed Switch, d.h. mit eigener Konfiguration per Web-Interface oder so? Eventuell ist da auch etwas falsch konfiguriert.

@matthiask Der InvalidParameter-Fehler der von der Rule geworfen wird kommt direkt vom Bricklet. Das heißt in dem Fall, dass requestTagID aufgerufen wurde, obwohl das Bricklet nicht in einem der Idle-States war. Hast du eventuell noch etwas nebenbei laufen? (Andere Rules, die das Bricklet benutzen, andere Programme, den Brick Viewer?) Eventuell ist es sinnvoll, die Rule so umzuschreiben, dass periodisch requestTagID aufgerufen wird und eine zweite Rule das Ergebnis abfragt, dann ist das zumindest selbstreparierend. Zu dem LED-Strip-Problem: Ich erinnere mich, dass es beim Testen ein Krampf war, mit den short-Arrays umzugehen, dazu kommt auf jeden Fall noch ein Beispiel. Dass das Bricklet short-Arrays erwartet, liegt an den Java-Bindings, deren Typmapping (von Java-Typen auf Device-Typen) ich unverändert übernehme: Das war in den ersten Versionen effizient im Sinne von short benutzen, wenn der Wertebereich klein genug ist. Da das in Java aber zu vielen nötigen Casts usw. führt, wurde das irgendwann umgestellt. Für die da schon veröffentlichten Devices kann das aber nicht geändert werden, ohne dass die Bindings nicht mehr rückwärtskompatibel zu alten Programmen sind.

Was hast du in deinem Python-Programm als HOST eingetragen? Das steht leider nicht in der Fehlermeldung mit drin. Ansonsten fällt mir nur auf, dass ein paar deiner Subnetzmasken nicht ganz passen: Das sollte eigentlich immer 255.255.255.0 sein. Edit: Wo führst du das Programm aus? Auf dem RED-Brick? Und mit dem PC bist du per USB an den Stacks verbunden?

Dann kannst du eigentlich das selbe machen: Solange die Extensions sich einig sind, wie das Netz funktioniert, können sie auch untereinander kommunizieren.

Moin, Was hast du denn genau konfiguriert? Folgendermaßen sollte es klappen: Sieh mal nach was der IP-Präfix ist, den deine FritzBox verwendet (Das siehst du in deren Einstellungen, oder indem du eine der Extensions auf DHCP stellst und dir dann die IP ansiehst, die sie bekommt). Standardmäßig ist das 192.168.178., wenn es was anderes ist musst du den Rest anpassen. Die statischen IPs sollten nicht mit denen kollidieren, die die FritzBox vergibt. Normalerweise vergibt sie IPs bis .200, also sollten 192.168.178.201 usw. gefahrlos nutzbar sein. Dann kannst du pro Extension eine IP vergeben, z.b. 192.168.178.201 für die erste ....202 für die zweite usw. Wenn du sicher gehen willst, dass die IPs frei sind, kannst du auf der Konsole die IP mit "ping 192.168.178.201" oder so anpingen, wenn keine Antwort kommt ist die IP noch nicht vergeben. Die Subnetzmaske ist typischerweise 255.255.255.0 (das heißt, dass dein Netz, einen festen Präfix auf den ersten drei Blöcken hat, der vierte Block ist dann die Adressierung im Netz, das wird hier ganz gut erklärt) Das Gateway ist die IP deiner FritzBox, also vermutlich die 192.168.178.1 Edit: Subnetzmaske war falsch herum

Moin, Eins vorweg: Alle Aussagen hier gelten nur, wenn du ganze Stacks ansteckst/abziehst. Hot-Plug einzelner Bricks/Bricklets an einen laufenden Stapel wird nicht unterstützt. Da gibt es mindestens die folgenden zwei Möglichkeiten: Du kannst, wenn dein Stapel per USB angeschlossen ist, im enumerate-Callback den ENUMERATION_TYPE_DISCONNECTED verwenden: Wenn du das USB-Kabel ziehst, bekommst du das Callback für jedes Gerät im Stapel, das angeschlossen war und mindestens einmal eine Nachricht geschickt hat. Da kannst du dann das entsprechende Objekt auf None setzen. Achtung: Da sind nur der enumeration_type und die UID sinnvolle Werte, du musst dir bei den _CONNECTED und _AVAILABLE-Enumerations die UIDs speichern und in den _DISCONNECTED-Enumerations dann nachschlagen. Alternativ kannst du bei jedem Aufruf warten, ob ein Timeout kommt (Bei Settern wie backlight_on() musst du response-expected aktivieren, sonst bekommst du das nicht mit). Da bietet es sich an eine Wrapper-Funktion zu schreiben wie z.B. (Achtung, ungetesteter Code): from tinkerforge.ip_connection import Error def wrapper(device, fn): try: fn() except Error as e: if e.value == Error.TIMEOUT: device = None # Verwendung wrapper(self.lcd, self.lcd.backlight_off) # oder wenn der Aufruf Parameter hat wrapper(self.lcd, lambda: self.lcd.write_line(0, 0, s)) Die Fehlerbehandlung kann dann natürlich beliebig komplex sein, je nachdem was du brauchst. Du kannst prinzipiell prüfen, ob ein Brick/Bricklet noch da ist, indem du irgendeine Funktion davon aufrufst (Es bietet sich get_identity an, das wird von allen Bricks/Bricklets unterstützt und hat keine Nebeneffekte) Das kommt auch ganz darauf an, was du brauchst. Eine relativ einfache Variante ist es, wenn du alles was du mit dem LCD machst in zwei Gruppen aufteilst: 1. Konfiguration, die nur einmal passiert, dann aber funktionieren muss. (Das kannst du dann aus dem enumerate-Callback heraus ausführen und self.lcd nur zuweisen, wenn alles fehlerlos durchgelaufen ist) 2. Ausgaben/Anzeigen die du dauerhaft aktualisieren willst, bei denen es aber nicht kritisch ist, wenn eine Aktualisierung verloren geht, weil die nächste das ganze wieder repariert. (z.B. die Temperaturanzeige wie im Beispielcode). Bei denen kannst du mit der Fehlerbehandlung dann lax sein (z.B. ein try...except um alles nur damit das Programm nicht beendet wird) Wenn du periodische Aufgaben hast, die definitiv durchgeführt werden müssen, musst du dir etwas komplexeres bauen, zum Beispiel eine Warteschlange von Tasks, die nacheinander abgearbeitet und bei Fehlern wiederholt werden. So eine Warteschlange kannst du dann auch von außerhalb befüllen.

Moin, @StefanOHAN Dein LCD128x64-Problem war ein Firmware-Bug: DIe Bindings nutzen die neue Version der Java-Bindings, die explizit die Länge der Antwortpakete prüft. Das LCD hat aber fälschlicherweise bei dem remove eines spezifischen Tabs nicht wie von den Bindings erwartet ein leeres Paket zurückgeschickt, sondern die Nummer des Tabs mit hineingeschrieben. Das war ein Byte zuviel, deshalb die Fehlermeldung. Bei dem IO-16 1.0 musst du den Parameter für GetEdgeCount nach short casten, dann sollte es funktionieren: val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(1 as short, true).get("count") as short Das NFC-Beispiel sehe ich mir nochmal an, danke dafür! @matthiask Das muss ich mir nochmal in Ruhe ansehen, war die letzte Woche im Urlaub. Ich melde mich dazu nochmal. Gruß, Erik