André K. Geschrieben May 5, 2020 at 14:42 Autor Share Geschrieben May 5, 2020 at 14:42 So, heute erst dazu gekommen, aber das FW-Update ist drin und mein Meteodat-Daemon ist nun gegen die neueste Version der Bindings gelinkt und führt auch die Initialisierung durch. Ich bin gespannt und beobachte das in den nächsten Tagen André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 5, 2020 at 20:48 Autor Share Geschrieben May 5, 2020 at 20:48 (bearbeitet) Kommando leider zurück: Jetzt ist obendrein die -83,87° wieder aufgetreten 😕 *seufz* Ich wollte eigentlich morgen die komplette Einbindung in die Website vornehmen und ich hatte so ein gutes Gefühl … 😩 So ist der Aufruf doch richtig: /* Langsame Busgeschwindigkeit: */ barometer_set_i2c_mode(bl_baro, BAROMETER_I2C_MODE_SLOW); bearbeitet May 5, 2020 at 21:07 von André K. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben May 6, 2020 at 08:44 Share Geschrieben May 6, 2020 at 08:44 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!) Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 6, 2020 at 09:55 Autor Share Geschrieben May 6, 2020 at 09:55 Puh okay, erstmal Asche auf mein Haupt 😅 Wie ich gerade bemerkt habe, hat systemd gestern gar nicht die neue Version des Binarys verwendet, sondern noch die vorige Version. Ist mir leider erst jetzt aufgefallen, weil systemd die komplette Ausgabe von stdout immer erst beim Beenden ins Log schreibt (warum eigentlich erst dann?). Ich lasse mir jetzt beim Start direkt eine Info mit der Version ins Syslog schreiben und kann daher sagen, daß nun wirklich die richtige Version läuft 🙈 André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 7, 2020 at 05:35 Autor Share Geschrieben May 7, 2020 at 05:35 (bearbeitet) Leider ist es heute morgen wieder aufgetreten, sogar zwei mal ganz kurz hintereinander. Mittlerweile bin ich natürlich auch etwas paranoid und schaue gefühlt alle 30 Sekunden drauf 😅 Ich habe den Verlauf mal isoliert, Fall 1 von 6:38 Uhr: 428482 2020-05-07 06:38:26 Temperature 331 428485 2020-05-07 06:38:27 Pressure 980778 428486 2020-05-07 06:38:27 Temperature 337 428489 2020-05-07 06:38:28 Pressure 980788 428493 2020-05-07 06:38:29 Pressure 980785 428496 2020-05-07 06:38:30 Pressure 980808 428499 2020-05-07 06:38:31 Pressure 980790 428503 2020-05-07 06:38:32 Pressure 980773 428506 2020-05-07 06:38:33 Temperature -3843 428507 2020-05-07 06:38:33 Pressure 10000 428819 2020-05-07 06:40:39 Temperature 0 428822 2020-05-07 06:40:40 Temperature -3843 429029 2020-05-07 06:41:59 Temperature -8387 429032 2020-05-07 06:42:00 Temperature -3843 430148 2020-05-07 06:47:48 Temperature -8387 430151 2020-05-07 06:47:49 Temperature -3843 430176 2020-05-07 06:48:01 Pressure 980942 430194 2020-05-07 06:48:01 Temperature 418 430198 2020-05-07 06:48:02 Pressure 980901 430207 2020-05-07 06:48:03 Pressure 980907 430210 2020-05-07 06:48:04 Pressure 980926 Um 6:48 habe ich dann manuell via Brick-Viewer resettet. Dann ist es eine Minute später gleich wieder passiert: 430487 2020-05-07 06:49:03 Pressure 980906 430494 2020-05-07 06:49:04 Pressure 980910 430500 2020-05-07 06:49:05 Pressure 980926 430504 2020-05-07 06:49:06 Pressure 980902 430507 2020-05-07 06:49:07 Pressure 980906 430508 2020-05-07 06:49:07 Temperature -3843 430512 2020-05-07 06:49:08 Pressure 10000 430604 2020-05-07 06:49:31 Temperature -8387 430613 2020-05-07 06:49:32 Temperature -3843 430765 2020-05-07 06:50:09 Temperature -8387 430769 2020-05-07 06:50:10 Temperature -3843 430789 2020-05-07 06:50:17 Temperature -8387 430794 2020-05-07 06:50:18 Temperature -3843 431211 2020-05-07 06:52:28 Pressure 980906 431212 2020-05-07 06:52:28 Temperature 475 431216 2020-05-07 06:52:29 Pressure 980897 431220 2020-05-07 06:52:30 Pressure 980882 Besteht denn ein Unterschied zwischen der "Spezial-Firmware" von letzter Woche und der neuen "offiziellen" FW in Kombination mit dem langsamen Modus? Edit: Die Temperatur ist die vom Temperature-Bricklet, die vom Barometer beachte ich in der Erfassung gar nicht Edit 2: Ich bin ja echt froh daß "nur" diese beiden Bricklets davon betroffen sind. Aber gibt es dafür eigentlich eine schlüssige Erklärung? An demselben Master hängen ja noch Humidity und Ambient Light 3.0. André bearbeitet May 7, 2020 at 06:01 von André K. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben May 7, 2020 at 08:03 Share Geschrieben May 7, 2020 at 08:03 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?) 3 hours ago, André K. said: Besteht denn ein Unterschied zwischen der "Spezial-Firmware" von letzter Woche und der neuen "offiziellen" FW in Kombination mit dem langsamen Modus? 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. 3 hours ago, André K. said: Edit 2: Ich bin ja echt froh daß "nur" diese beiden Bricklets davon betroffen sind. Aber gibt es dafür eigentlich eine schlüssige Erklärung? An demselben Master hängen ja noch Humidity und Ambient Light 3.0. 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 7, 2020 at 08:52 Autor Share Geschrieben May 7, 2020 at 08:52 (bearbeitet) vor 51 Minuten schrieb rtrbt: 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. Ganz so kann man das nicht sagen. Sowohl Temperature- als auch Barometer-Bricklet hauen sporadisch mal nur einen einzelnen falschen Wert raus, zum Beispiel gestern Abend einfach mal zwischen drin -1°C, hier gut an der Min/Max Auswertung zu sehen: Temperature 8.21858 7.87 8.68 2020-05-06 22:00:00 Temperature 9.21769 8.68 9.75 2020-05-06 21:30:00 Temperature 10.2747 -1 10.87 2020-05-06 21:00:00 Temperature 11.5355 10.81 12.31 2020-05-06 20:30:00 Temperature 12.8846 12.31 13.5 2020-05-06 20:00:00 Auch das Barometer macht das: Pressure 978.992 978.792 979.112 2020-05-06 00:00:00 Pressure 978.699 978.598 978.835 2020-05-05 23:30:00 Pressure 977.98 10 978.658 2020-05-05 23:00:00 Pressure 978.07 977.916 978.462 2020-05-05 22:30:00 Pressure 977.916 977.865 977.949 2020-05-05 22:00:00 Dabei geht dann aber nicht gleich der ganze Bus "kaputt". vor 51 Minuten schrieb rtrbt: 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 Humidity 2.0 zu. Schreib dazu, was du an Kabellänge brauchst. Ich habe mir heute morgen auch schon sowas ähnliches gedacht als dann (hoffentlich) endgültige Lösung. Und vielen Dank, aber ich bestelle die dann einfach via Shop, auf die paar Euro kommt es echt nicht mehr an 😅 der größere Hemmschuh ist meine Motivation, nochmal aufs Dach zu kraxeln und in 10 Meter Höhe an dem Kasten herum zu schrauben. Aber wenn's hilft, ist das ein kleiner Preis Ich würde dann folgendes tauschen: Barometer gegen Barometer 2.0, Temperature gegen Temperature 2.0 Die Arbeitsweise vom Humidity mit dem Analogwert gefällt mir eigentlich sehr gut, erinnert mich an die gute alte Conrad-Telemetrie-Wetterstation die an dieser Stelle ja 24 Jahre lang zuverlässigst gearbeitet hat. Oder würdest Du empfehlen da auch auf Humidity 2.0 zu gehen? André bearbeitet May 7, 2020 at 08:55 von André K. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben May 7, 2020 at 09:16 Share Geschrieben May 7, 2020 at 09:16 Hm die einzelnen Ausreißer sind dann eventuell einfach weniger starke Störungen. Da reicht es ja, wenn ein Bit flippt. 14 minutes ago, André K. said: Und vielen Dank, aber ich bestelle die dann einfach via Shop, auf die paar Euro kommt es echt nicht mehr an 😅 der größere Hemmschuh ist meine Motivation, nochmal aufs Dach zu kraxeln und in 10 Meter Höhe an dem Kasten herum zu schrauben. Aber wenn's hilft, ist das ein kleiner Preis 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. 16 minutes ago, André K. said: Oder würdest Du empfehlen da auch auf Humidity 2.0 zu gehen? 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 7, 2020 at 09:29 Autor Share Geschrieben May 7, 2020 at 09:29 Alles klar, vielen Dank. Habe gerade eben nochmal das 2.0-Komplettpaket (Temp, Baro, Humidity) geordert … Kann ich das alte Temp-Bricklet mit einem kurzen Kabel wohl "gefahrlos" an dem einen freien Port am 2. Master anschließen, um die Temperatur innerhalb des Gehäuses zu messen? So hätte es wenigstens noch eine Daseinsberechtigung 😅 André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben May 7, 2020 at 09:44 Share Geschrieben May 7, 2020 at 09:44 Da will ich nicht die Hand für ins Feuer legen, aber das sollte klappen. Die Kabellänge ist extrem relevant bei EMV-Kram. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 10, 2020 at 06:59 Autor Share Geschrieben May 10, 2020 at 06:59 Die neuen Sensoren sind übrigens unterdessen angekommen, habe mir auch einen weiteren Master gegönnt um hier eine Test- und Entwicklungsumgebung zu haben. Aber als ob die beiden Bricklets es mitbekommen hätten daß sie angezählt sind und es ihnen an den Kragen gehen soll, verhalten sie sich seit Tagen völlig normal 😅 André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 16, 2020 at 14:03 Autor Share Geschrieben May 16, 2020 at 14:03 (bearbeitet) Anregung/Verbesserungsvorschlag: Kann man die Berechnung des normalisierten Luftdrucks (also QFF) nicht auch in die Firmware gießen, so daß man dann bloß noch die Höhe bei der Initialisierung übergeben braucht bzw. im EEPROM ablegt? Alternativ wäre natürlich ein kombinierter Callback mit Druck und Temperatur cool. Weil so wie es jetzt ist, lässt es sich eigentlich nicht elegant lösen. Entweder, ich benutze den getter für die Temperatur innerhalb des Druck-Callbacks (unschön, wenn man sonst ohne getter auskommt), oder ich definiere eine globale Variable die von einem separaten Temperatur-Callback gefüllt wird (auch unschön) … Ich glaube ich mache es ermal mit dem getter. Globale Variable ist mehr bäh als ein sekündlicher getter. André bearbeitet May 16, 2020 at 14:07 von André K. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
duaw Geschrieben May 17, 2020 at 08:23 Share Geschrieben May 17, 2020 at 08:23 Am 6.5.2020 um 10:44 schrieb rtrbt: 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!) Hallo! Die aktuellen C/C++-Bindings wurden am 7.4. generiert. Die i2c-Funktionen sind in bricklet_barometer.c/.h noch nicht deklariert/definiert . Die Funktionen der Firmware 2.0.3. vom 5.5. können nicht in C/C++ aufgerufen werden. (Es wurden seitdem nur die MQTT-Bindungs upgedatet, oder?) Gruß, Uwe Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 17, 2020 at 11:33 Autor Share Geschrieben May 17, 2020 at 11:33 Uwe, rtrbt bzw. Erik hat doch die C/C++-Bindings hier im Thread verlinkt, ganz unten auf der vorigen Seite. Die verwende ich, und da ist die Funktion drin. Und BTW, weitere Anregung: Daß ihr den gleitenden Mittelwert in die Firmware von Barometer 2.0 und Hygrometer 2.0 eingebaut habt ist super! Allerdings liefern diese Bricklets ja auch so schon recht stabile Werte … wo das aber echt noch fehlt, ist beim Ambient Light 3.0 — denn egal was ich einstelle, bei Sonne hüpfen die Lux-Werte dermaßen rauf und runter daß ich geneigt bin ab 1000 lx das ganze umspringen zu lassen auf Anzeige in "Kilo-Lux" (falls es das überhaupt gibt ;)) und maximal einer Nachkommastelle. André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
bernhard.graeuler Geschrieben May 17, 2020 at 17:34 Share Geschrieben May 17, 2020 at 17:34 Hi, ich habe gestern meinen TF Stapel seit längerem wieder in Betrieb genommen, und dort auch das alte Temperature Bricklet im Einsatz. Die Firmware hatte ich auf die Version 2.0.4 aktualisiert, und dann nach ein paar Stunden Laufzeit auch das Phänomen "Temperature Bricklet gibt -38.43°C zurück" (temperatureReached Callback). Erst nach einem Reset des Master Bricks funktionierte das System wieder. Als Ursache käme bei mir in Frage, dass das Kabel zwischen Master Brick und Temperature Bricklet ein bischen zu kurz ist, so dass zwischendurch der Stecker am Master Brick teilweise rausgerutscht ist, also schräg im Port steckte. Könnte sein, dass ich den einfach wieder zurückgedrückt, und dann keine Prüfung mehr durchgeführt habe. Ich lasse es jetzt mal so laufen, und schaue, ob das Problem noch einmal auftritt. Gruß Bernhard Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 17, 2020 at 20:07 Autor Share Geschrieben May 17, 2020 at 20:07 vor 2 Stunden schrieb bernhard.graeuler: Als Ursache käme bei mir in Frage, dass das Kabel zwischen Master Brick und Temperature Bricklet ein bischen zu kurz Die spannende Frage für mich ist jetzt: Wie lang ist denn bei Dir "zu kurz"? Bei mir sind es 50cm … André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
bernhard.graeuler Geschrieben May 17, 2020 at 20:37 Share Geschrieben May 17, 2020 at 20:37 Ah nee, Missverständnis: Das Kabel ist lang genug (100cm shielded für ca 80cm Distanz), ich habe den Aufbau in einer Art Schaltschrank, und die Kabel waren zwischen Durchführung von oben und Anschluss am Masterbrick zu kurz (s. rote Linie auf dem angehängten Bild). Wenn man da den Stapel zu weit nach rechts schiebt rutschen die Kabel aus den Buchsen. (Auf dem Bild habe ich das schon umgebaut. Ursprünglich kamen die Kabel von noch weiter links) Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
duaw Geschrieben May 18, 2020 at 05:33 Share Geschrieben May 18, 2020 at 05:33 vor 17 Stunden schrieb André K.: Uwe, rtrbt bzw. Erik hat doch die C/C++-Bindings hier im Thread verlinkt, ganz unten auf der vorigen Seite. Habe ich übersehen, Danke! Aber: Da gehören Sie nicht hin. Und warum nur in C/C++ (und MQTT auch ... oder nicht?). Und undokumentiert. Ich dachte, die Bindings werden generiert. Und an einer zentralen Stelle gehalten. Gruß, Uwe Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 18, 2020 at 06:45 Autor Share Geschrieben May 18, 2020 at 06:45 vor einer Stunde schrieb duaw: Aber: Da gehören Sie nicht hin. Und warum nur in C/C++ (und MQTT auch ... oder nicht?). Und undokumentiert. Kommt ja sicherlich noch. Und C ist halt meiner Ansicht nach eh am Wichtigsten, das ist da wo die Musik spielt xD André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben May 19, 2020 at 12:42 Share Geschrieben May 19, 2020 at 12:42 @duaw Die API Bindings sind generiert, ja, dass heißt aber nicht, dass auch der Release Prozess von 20 verschiedenen API Bindings vollständig automatisch ist (bzw. überhaupt vollständig automatisierbar wäre). Das dauert schon mal einen halben Tag. Daher ist es schon ein großer Unterschied, ob Erik hier im Forum mal eben eine Testversion eines API Bindings jemandem zum Testen gibt (die hier im Thread angehängten C/C++ Bindings für André), oder ob ich alle API Bindings ordentlich veröffentliche. Die MQTT Bindings wurde einzeln wegen des Bugfixes in der Version veröffentlicht und aufgrund der linearen Entwicklung der Bindings ist damit dann auch die neue API für das Barometer Bricklet damit hinein gekommen. Undokumentiert war die neue API, weil ich Dokumentation seit dem noch nicht neu generiert wurde. Die I2C Mode Funktion für das Barometer Bricklet (1.0) ist jetzt vollständig in allen Aspekten veröffentlicht. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
duaw Geschrieben May 19, 2020 at 12:48 Share Geschrieben May 19, 2020 at 12:48 Hallo, photron, da war ich wohl etwas blauäugig, sorry. Und den "Testaspekt"hatte ich nicht bedacht. Auf jeden Fall ein RIESENGROSSES LOB für die sagenhafte Unterstützung und Pflege! Da bleiben eigentlich keine Wünsche offen! Viele Grüße, Uwe Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben May 31, 2020 at 12:18 Autor Share Geschrieben May 31, 2020 at 12:18 So, mal wieder eine kleine Rückmeldung meinerseits Die drei neuen Bricklets für Temperatur, Luftdruck und Luftfeuchte sind seit etwas mehr als anderthalb Wochen montiert und seitdem läuft es absolut störungsfrei, yay! Das "alte" Temp-Bricklet habe ich ins Gehäuse rein gesetzt um die interne Temperatur loggen zu können, wie vermutet funktioniert auch das, aber jetzt ist natürlich auch ein erheblich kürzeres Kabel im Spiel. Wenn ihr mal schauen wollt: http://www.koethur.de/wetter/ Und nicht wundern, die "Live-Aktualisierung" stoppt nach 30s, das ist noch Absicht … André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben June 21, 2020 at 07:40 Autor Share Geschrieben June 21, 2020 at 07:40 The story continues 😅 Gestern Abend hat sich auch das neue Temperatur-Bricklet verabschiedet, nach 35 Tagen störungsfreiem Betrieb. Immerhin nicht mit einem falschen Wert, sondern es hat einfach aufgehört den Callback auszulösen. Wiederbelebung per Brick Viewer war Gott sei Dank wieder möglich. Jetzt bin ich mit meinem Latein so langsam am Ende oder hat jemand von euch noch einen Ansatz? André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben June 22, 2020 at 08:09 Share Geschrieben June 22, 2020 at 08:09 Moin, Das kann eigentlich nur passieren, wenn du entweder einen Code-Pfad hast, der das Callback deaktiviert, oder wenn das Bricklet aus irgendwelchen Gründen beschlossen hat, sich zu resetten. Hast du eventuell ein sporadisches Enumerate vom Bricklet gesehen, bevor keine Daten mehr kamen? Wenn das Bricklet ein Enumerate mit dem Enumeration-Type ENUMERATION_TYPE_CONNECTED (=1) schickt, dann hat es sich neugestartet. Erik Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
André K. Geschrieben June 22, 2020 at 08:28 Autor Share Geschrieben June 22, 2020 at 08:28 Guter Punkt, danke. In meinem Enumerate-Callback ist im Prinzip nur ein großer switch() drin, der sämtliche Callbacks und Initialisierungen einrichtet, und nur für den Master einen Eintrag ins Event-Log schreibt. Außerdem beginnt er folgendermaßen: if(enume_type == IPCON_ENUMERATION_TYPE_AVAILABLE) switch (did) Das heißt, ich bekomme die anderen Types gar nicht mit. Ich baue da mal einen else-Zweig rein der zu einem weiteren Event-Log-Eintrag führt um ein Gefühl dafür zu bekommen was da ggf. ankommt. André Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.