Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.554
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    150

Alle erstellten Inhalte von rtrbt

  1. Hi, Seems like my edit interleaved with you loading the thread. Can you please try again with the ee8d2719-Version?
  2. 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.
  3. 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
  4. Da will ich nicht die Hand für ins Feuer legen, aber das sollte klappen. Die Kabellänge ist extrem relevant bei EMV-Kram.
  5. 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
  6. Nur um das gerade nochmal auseinanderzunehmen, das sind die Symptome: Wenn das Temperature Bricklet anfängt die falschen Werte zu erzeugen, bringt es den I²C-Bus in einen kaputten Zustand, weshalb das Barometer Bricklet dann auch anfängt falsche Werte zu produzieren. Wenn das Barometer Bricklet selbst damit anfängt, liefert es nur ein paar falsche Werte, irgendwann bekommt es sich aber wieder ein. Das heißt doch, dass in deinen Logs eher das Temperature Bricklet der Auslöser ist. Interessant ist allerdings, dass es im zweiten Log um 6:52 wieder funktioniert (oder hast du da nochmal neugestartet?) Die Firmware 2.0.3 benutzt, wenn konfiguriert, überall den langsamen Modus, das hatte ich in der Firmware, die für dich gebaut wurde an manchen Stellen vergessen. Außerdem liest sie auch die Kalibrierung des Sensors immer im langsamen Modus. Das passiert beim Hochfahren, da hatte der Nutzer noch keine Chance den Modus zu konfigurieren. Da dein Problem ja aber anscheinend wieder vom Temperature Bricklet kommt, würde ich spekulieren (kannst du aber trotzdem testen), dass es nicht helfen sollte, wenn du die Spezial-Firmware wieder verwendest. Gibt es tatsächlich: Das Temperature und Barometer Bricklet sind ja per I²C angeschlossen. Das ist tendenziell eher Störanfällig bei längeren Entfernungen (siehe auch hier). Das Humidity Bricklet liefert direkt eine Spannung, die vom ADC des Master Bricks in einen Wert umgewandelt wird. Das Ambient Light V3 ist deutlich neuer, der Brick spricht mit dem Koprozessor auf dem Bricklet SPI mit Checksumme usw.. Da ist es deutlich unwahrscheinlicher (aber nicht ganz unmöglich) dass falsche Daten bis zu deinem Programm durchkommen. In Summe würde ich folgendes Vorschlagen: Wenn du nicht noch spontane Wunderheilung beobachtest, schreib mal eine E-Mail an sales@tinkerforge.com, dann schicken wir dir ein Barometer 2.0 und Temperature 2.0 zu. Schreib dazu, was du an Kabellänge brauchst.
  7. Hm klassisches Informatiker-Problem "Das hätte eigentlich funktionieren sollen". Kommen die -83,87°C vom Barometer oder vom Temperature Bricklet? Hast du den Modus bei beiden auf Slow gesetzt? Hing danach eins der Bricklets oder war das nur ein Ausreißer und danach kamen wieder sinnvolle Werte? Der Aufruf sieht korrekt aus, probiere danach mal sicherheitshalber folgendes: uint8_t mode; barometer_get_i2c_mode(bl_baro, &mode); printf("i2c mode %s\n", mode == BAROMETER_I2C_MODE_FAST ? "BAROMETER_I2C_MODE_FAST" : "BAROMETER_I2C_MODE_SLOW"); (Achtung, ungetesteter Code!)
  8. Das kannst du mal probieren, ja. Die IMU benutzt unter anderem ein Magnetometer, das du eventuell durch die anderen Bricks im Stapel (vor allem die Servo Bricks) störst. Alternativ kannst du testen, die IMU mit dem Brick Viewer nochmal im Stapel zu kalibrieren, damit sie die Störung kompensiert. Dann solltest du aber auf jeden Fall prüfen, ob das noch funktioniert, wenn die Servos angesteuert werden, falls die Störung lastabhängig ist. Wenn das alles nichts hilft, kannst du noch probieren, die IMU in etwas Entfernung vom Stapel zu betreiben, der RED-Brick hat ja einen USB-Port.
  9. Das klingt seltsam. Du kannst sicherheitshalber das Log-Level vom Astro- und NTP-Binding mal auch auf Trace stellen, das sollte eigentlich genauso funktionieren.
  10. Was suchst du denn genau? Notfalls kann man sich ja durch die Datenbank wühlen.
  11. Moin, Wenn du den Servobrick testweise wieder wegnimmst, liegt der Winkel dann wieder auf 0°?
  12. Firmware: Barometer Bricklet 2.0.3 Add Get/Set I2C Mode to mitigate EMI issues Download: Barometer Bricklet
  13. Firmware: Barometer Bricklet 2.0.3 Get/Set I2C Mode hinzugefügt, um EMV-Probleme zu umgehen Download: Barometer Bricklet
  14. Jupp, der Brick Viewer sollte schon fleißig Update-Meldungen erzeugen. Die Bindings sind angehangen. tinkerforge_c_bindings_2_1_28_barometer_i2c.zip
  15. Moin, Ich habe die Firmware-Anpassungen fürs Barometer Bricklet noch etwas robuster gemacht und in das nächste Firmware-Release eingebaut, die 2.0.3 sollte jetzt verfügbar sein. Das Default ist aber wieder der schnelle Modus. D.h. du musst den langsamen Modus jetzt explizit mit set_i2c_mode aktivieren, so wie es beim Temp-Bricklet auch funktioniert. Welche Sprache benutzt du? Dann erstelle ich dir dafür die Bindings neu, damit du die Funktion benutzen kannst. @duaw Ah das erklärt das Problem. Für genau deinen Fall ist der global-topic-prefix-Parameter da. Die Alternativen sind alle schwierig, 1. und 4. könnte man nur zusammen fahren (sonst müssten die MQTT-Bindings routen, das ist ein Krampf) 2. ist unschön, wenn man am Einrichten des ganzen ist, weil man dann nicht mitbekommt, dass die UID falsch ist, 3. macht ein riesiges Fass auf, weil man dann allgemeine Message-Filter bauen müsste. Da ist es einfacher für dich als Anwender alle Messages mit "_ERROR"-Key zu ignorieren. Das würde auch das "Fern-Debuggen" erschweren, wenn jemand Probleme damit hat.
  16. 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
  17. Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.6 Add all voltages callback Download: Industrial Dual Analog In 2.0
  18. Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.6 All Voltages-Callback hinzugefügt Download: Industrial Dual Analog In 2.0
  19. 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
  20. 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.
  21. 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
  22. 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!
  23. 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.
  24. 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.
  25. 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
×
×
  • Neu erstellen...