Jump to content

duaw

Members
  • Posts

    120
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

duaw's Achievements

Newbie

Newbie (1/14)

  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare
  • Dedicated Rare
  • One Year In Rare

Recent Badges

0

Reputation

  1. Hallo! Bei meinem Mac mini M1 erscheinen keine seriellen Ports zur Wahl zum Flashen eines Masters (2.1) im BrickV (letzte und vorletzte Version). Passiert auch beim RED. Anschluss direkt am USB-A Port des Mini. (Sonst funktioniert alles.) macOS 11.6 auf Intel Mac läuft (Gott Sei Dank!) Gruß, Uwe
  2. Hallo! Ich habe mehrere Instanzen von tinkerforge_mqtt laufen (linux). Ich habe dazu verschiedene Service-Dateien angelegt (tinkerforge_mqtt_111.service, tinkerforge_mqtt_112.service ... ) Die Dateien sind gleich, der Name ist unterschiedlich. Das sind Linux-Services. Ich gebe jeder Instanz das Spezifische beim Start mit: ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 --global-topic-prefix tinkerforge/111 So kann ich beim Broker nett unterscheiden, woher was kommt. Ich denke, das geht so oder so ähnlich auch in anderen Betriebssystemen. War das das Problem? Gruß, Uwe
  3. Also, eine "Instanz" von ipcon.c , die beim Linken mit gebunden wird, ermöglicht in einem Programm dann einen einzelnen Listener. Da funkt der Brickv natürlich dazwischen. (Wann er das tut, weiß ich nicht. Beim Connect? Bei Klicken auf den Tab? ...) Blind, blind, blind ... Habe blind auf "Callbacks" geklickt und das Kapitel "Konfigurationsfunktionen für Callbacks" oberhalb übersehen ... Dass ich das auch in der Header-Datei übersehen habe ... tsss ... Werde zukünftig NICHT mehr an euch zweifeln.
  4. Ich lese in der Doku: Java: "Dieser [BrickletLEDStripV2.FrameStartedListener()] Listener kann mit der Funktion addFrameStartedListener() hinzugefügt werden." (Ein 'n' fehlt.) C: "Die Registrierung kann mit der led_strip_v2_register_callback() Funktion durchgeführt werden:" Beobachtung: Man kann zu einem Zeitpunkt nur nur einen Listener haben. Wenn unterschiedliche Programm auf das Bricklet zugreifen (z.B. ein parallel geöffneter Brick Viewer), dann ist das Ergebnis erratisch ... Ich lese in der Doku: Java: "Ein hinzugefügter Listener kann mit der Funktion removeFrameStartedListener() wieder entfernt werden." C: Ich vermisse in der Doku int led_strip_v2_set_frame_started_callback_configuration(LEDStripV2 *led_strip_v2, bool enable) Diese Funktion (und int led_strip_v2_get_frame_started_callback_configuration(LEDStripV2 *led_strip_v2, bool *ret_enable)) ist ja definiert. Gruß, Uwe
  5. Geht! 👍 (Ausprobiert auf dem neuen Mac mini, auf dem das Symptom aufgetreten ist. Noch nicht gecheckt, ob es auf dem MacBook Pro -alt- auch noch geht. 😏)
  6. Hmm ... wieso geht es dann bei mir von einem Mac aus, aber nicht vom anderen? Wie gesagt: Kein drängendes Problem. Der Urlaub ist definitiv verdient! Gruß, Uwe
  7. Hallo! Nach dem (eigentlich reibungslosen) Umzug auf einen neuen Mac mini mit M1 sehe ich im Brick Viewer am unteren Fensterrand die Message "Update information could not be downloaded from tinkerforge.com. Is your computer connected to the Internet?" Ist er natürlich. Ich habe auch sonst absolut keine Probleme, auch Brickd und der Rest vom Brickv laufen einwandfrei. Ist nur unschön, aber nicht überlebenswichtig. Gruß, Uwe
  8. Hallo, Thomas, ich verwende NodeRED. Die ankommende Nachricht übersetzte ich und veröffentliche sie so, wie ich das brauche, einfach nochmal. Die (Prozessor-) Last ist dabei nicht sehr hoch. Das erschien mir der einfachste Weg, insbesondere bei neuen Versionen des Bindings. Gruß, Uwe
  9. Hallo, luxor, klar, das Bindung läuft irgendwo. Bei mir läuft für jeden Stapel mit eigener IP-Nummer eine Instanz davon bei mir im Netz auf einer HW, da wird das Topic mit gesetzt. Das Bindung läuft bei mir also "nah" an der TF HW, im selben Netzwerk. Der MQTT-Broker kann dann laufen, wo er will, Hauptsache er ist erreichbar (bei mir im lokalen Netz). Und NodeRED kann auch laufen, wo es will -- Hauptsache, der Weg zum Broker ist frei. (NodeRED in der Cloud ist für mich keine Option. Ich will grundsätzlich, dass alles auch ohne Cloud funktioniert.) Ich habe das TF-MQTT-Binding noch nie neu gestartet. Das liegt aber vielleicht auch daran, dass ich polle. NodeRED weiß, welche HW ich habe, dort wird der Request per MQTT abgegeben, das Bindung hat kriegt das dann mit. Was der ESP32-Brick grundsätzlich anders machen soll als der Red-Brick überblicke ich nicht. Gruß, Uwe
  10. Für mich zum Verstehen: Nutzt du die Nodes? (Ich habe sie noch nicht ausprobiert.) Welchen wirklichen Benefit siehst Du grundsätzlich im Vergleich zu MQTT? MQTT ist immer top-aktuell. Zur Verwendung braucht es natürlich ein laufendes MQTT-Binding ... aber das läuft ja einfach. Alles, was von dritter Seite zur Unterstützung von TF kommt, hängt immer hinterher. (Etwas, das ich bei NodeRED als suboptimal empfinde ist die Unübersichtlichkeit über third-party-Nodes. Welche gibt es, wie sind die dokumentiert und gepflegt?) Gruß, Uwe
  11. Hallo, ewu68! Bei mir läuft das Trio NodeRED, MQTT und Tinkerforge super erfolgreich und komfortabel. Auf einem Raspi in der isolierten Gartenhütte steuert/regelt es Licht und Temperatur gegen den Pflanzentot im Winter, ein Server, der eh läuft, erledigt allerhand nebenher. Da ist dank MQTT auch anderes (z.B. Shelly) dabei und es gibt ja allerhand NodRED-Nodes für Dinge, die nicht MQTT sprechen (mir gefällt immer noch mein LaMetric-Display). Also ich bin sehr zufrieden. Ich brauche keine Tinkerforge-NodeRED-Nodes. Läuft. Ist performant, stabil, erweiterbar, wartbar (man muss aber wie bei allen grafischen "Sprachen" aufpassen und sich selbst disziplinieren. Was mir nicht immer gelingt ... ) Etwas off-topic: Ich kann – ganz ehrlich – auch nicht den Bedarf am TF-openHAB-Binding nachvollziehen. Ja, Komfort bei der Einrichtung. Noch etwas? Aber um welchen Preis? Warum nicht einfach per MQTT an openHAB andocken? (Ich habe mich aber von openHAB getrennt. NodeRED und ich sind jetzt ein Paar ;-) ) Gruß, Uwe
  12. duaw

    ESP32 Brick

    Schön (heraus-) zu lesen, dass das Geschäft mit den Wallboxen dermaßen brummt ... Die Kehrseite der Medaille ist dann leider ... Bleibt spannend! Gruß, Uwe
  13. Ja, Batti, das klingt gut. Ich gehe gerne zu Fuß! Ich habe in der Nähe vom Einsatzort im Keller schon einen Stapel zum Überwachen/Steuern der Zu-/Abluft, am Stack ist noch ein Steckplatz frei. Mit nem langen Bricklet-Kabel könnte das was werden. Dann einklinken in MQTT und NodeRED, fertig ist es! @DoIT: Das Wasser kam von außen rein über die Zu-/Abluft. Die Entwässerung derselben (im Sommer gibt es da Kondenswasser, jetzt war alles so draußen gesättigt, dass das Regenwasser im Boden seinen Weg da in die Zuluft hinein fand) in das Abwasser hatte ein – wirklich zweckfreies – Sieb, das sich zugesetzt hatte. Abschalten muss ich da nix. Wäre grundsätzlich natürlich bei Waschmaschinen etc. sinnvoll. Hmm, ich kenne niemanden, dem die ausgelaufen ist. Gruß, Uwe
  14. Hallo, zusammen, nachdem es viel Wasser von oben und eine Verstopfung im Abfluss nach unten gab, stand das Wasser im Keller. Blöd. (Freundlicherweise war es klares Wasser, dass seinen Weg gefunden hatte, keine braune Brühe ... ) Wie würde man einen Wasserstandswarner mit TF realisieren? Mit welchem Bricklet (und ggf. Zusatz-HW) könnte man auf welche Art & Weise stehendes Wasser >1mm auf dem Boden feststellen und so die Basis für eine Wasserwarnung realisieren? Gruß, Uwe
×
×
  • Create New...