Jump to content

duaw

Members
  • Content Count

    92
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

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

  1. 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
  2. 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
  3. 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
  4. Ja. Auf iMac und MacBook. Mit jedem Update von macOS kommt immer ein Reboot, klar. Aber ansonsten läuft der brickd absolut solide.
  5. Nein. Hier läuft alles absolut problemlos. Rocksolid. Mit und ohne Schlafen. Manchmal tage-, wochenlang ohne Reboot der Maschinen am Stück. Gruß, Uwe
  6. Nein, --ipcon-timeout 10000 hat nicht geholfen. Das dauert auch weniger als 2,5 Sekunden ... Nein, das Problem liegt vielmehr ganz woanders: Ich habe mehrere Stapel mit Ethernet-Extensions im Einsatz. Ich lasse also für jede IP-Adresse eine Instanz des MQTT-API-Binding laufen. Muss ich ja, da ich dem Binding genau EINEN ipcon-host nennen kann. Also: tinkerforge_mqtt mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 tinkerforge_mqtt_112 mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.112 ... tinkerforge_mqtt_115 mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.115 In Node-RED requeste ich per MQTT tinkerforge/request/temperature_bricklet/aK1/get_temperature . Das Bricklet ist am Stapel mit der IP 192.168.1.111 ALLE 5 laufenden services erhalten die Nachricht, fühlen sich dann also angesprochen, aber nur einem service gelingt es, die Temperatur zu liefern (dem, der an ipcon-host 111 horcht), die 4 anderen versuchen es und geben dann auf. Es kommt also 1 mal die Temperatur und 4 mal die Fehlermeldung. Hmmm ... Möglichkeiten: Ich werde versuchen, das mit dem --global-topic-prefix-Parameter irgendwie hinzubasteln. Da steht in der Doku Der Präfix kann beispielsweise verwendet werden, um mehrere Binding-Instanzen, die mit dem selben Broker verbunden sind, zu trennen. Dann muss ich selbst drum kümmern ... Alternativ: tinkerforge_mqtt "wird Multi-ipcon-host"-fähig und bekommt beim Aufruf eine Liste von --ipcon-hosts (Nein.) tinkerforge_mqtt findet heraus, dass das Bricklet vom gewünschten Typ mit der UID nicht da ist und ignoriert den Aufruf (Eher unwahrscheinlich) tinkerforge_mqtt hat eine Option, mit der auf die "Antwort" verzichtet wird. (Warum nicht. Ich kann/muss mich eh' drum kümmern. Ob sie nun nicht gekommen ist oder als Nachricht, dass sie nicht kam ist mir egal) die IP-Adresse wird Bestandteil von payload oder topic Gruß, Uwe
  7. Mit schöner Regelmäßigkeit – alles 30 sec wird gepollt – kommt: mosquitto_sub -t tinkerforge/response/temperature_bricklet/ziB/get_temperature -h 192.168.1.18 {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} {"temperature": 1756} {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} {"temperature": 1756} {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"} Erst ein Timeout, dann der Wert, dann 3x Timeout ... 30 sec Pause … dann Timeout, dann der Wert, dann 3x Timeout. Hmmm. Muss noch mal checken, ob da Node-RED mehrere Abfragen feuert ... Gruß, Uwe
  8. Ich habe Temperature / Humidity / Barometer / Dual Relay und nehme die Temperatur aus ... Temperature. Das Bricklet zeigte -38,43°C. Dual Relay schaltet die Luftzufuhr ins Haus zwischen "lang" und "kurz" . Habe da ein Eltako 1393097 dazwischen, weil das Schalten via Dual Relay nur so zuverlässig ging. Beim Ausfall der Temperatur vorhin wurde aber nicht geschaltet. Ich habe noch openHAB 2.4 am Laufen mit dem alten Binding von Theo. Habe irgendwie Angst vor der Migration ... solange das "Beta", die Doku unvollständig ist und der Einarbeitungsaufwand irgendwie nicht überschaubar erscheint. Never touch a running system . Und wie gesagt: Node-RED ist ganz nett! (mit oH ist es aber einfacher, gut aussehende Resultate zu erzielen ...) ------ Eher ein Thema für einen neuen Thread: Wo liegen die Nachteile / Vorteile oH-nativ vs. oH-MQTT ? In Node-RED kommt ja alles via MQTT an (Für jeden Stapel mit eigener IP-Adresse starte ich einen eigenen Service.) Das ginge ja auch in oH. Mir gefällt Deine MQTT-Lösung sehr gut! Warum sollte ich das TF-oH-Bindung benutzen? (Noch 'ne Frage, definitiv etwas off-topic: Noch rufe ich in Node-RED MQTT request auf. Das ist nicht zeitkritisch. Regelmäßig kommt auch {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet aK1)\"}"} Das ignoriere ich. Dann kommt wieder {"temperature": 1556} . Die Verbindung via BrickV steht. Woran kann das liegen? Irgendwo ein zu aggressives Timing im MQTT-service-API? Stapel ist im Aussenbereich via Powerline angeschlossen. ) Gruß, Uwe
  9. Hallo! Schwups, es ist wieder passiert. Eben 6:42 Uhr. Beobachtung: (Habe noch keine Regel) Reset aus dem Brickviewer, kurz die 10°, dann wieder -38,4; noch ein Reset, dann dann ok ... Es war der Aufbau mit dem Barometer / Humidity / Dual Relay / PoE, aber es gab keinen Schaltvorgang im Garten. EMI dort?. Da ist noch openHAB mit dem alten TF-Binding im Einsatz. Parallel wechsle ich langsam auf Node-RED/MQTT, noch mit periodischer 30sec-Abfrage. Mit MQTT kann ich auch den i2c-Modus setzen. Gruß, Uwe
  10. Hallo, André, ich habe im überdachten Aussenbereich (!) einen Stapel mit Temp / Bar / Hum / Dual Relay / PoE (ich meine, das läuft stabil) zum Regeln der Luftzufuhr / Messen. Und dann in einer Hütte wieder via Powerline zur Überwinterung Hum / 2x Temp (unten, oben) / Hum mit Ethernet (nicht PoE) und Steckernetzteil. Ich meine, das ist der Kandidat. Sporadisch: Dieses Jahr noch nicht. Letztes Jahr im Sommer ? 1 mal ? Davor länger nicht ? Ich glaube sogar, ich musste den Stapel stromlos machen, weiss das aber nicht mehr genau. So selten, dass ich es nicht genau weiß, aber so häufig, dass ich die Überwinterung noch nicht Node-RED bzw. openHAB anvertraue. Hatte auch immer mal Powerline-Probleme (und die SW läuft auf einem Rechner im Haus!), da zweifle ich an der Zuverlässigkeit. Werde die Überwinterung vor Ort steuern (mit Backup ... ) Gruß, Uwe
  11. Hallo! Ja, ganz, ganz, ganz sporadisch passiert das bei mir auch an einer Mess-Stelle: -38,43°C. Masterbrick 2.1, Temperature-Bricklet alt (und mehr), aktuelle SW. Das ist aussen, per Powerline angebunden. Ich habe bisher kein Muster erkannt. Ich lasse mich informieren und resette dann 😉 . Ist etwas unbefriedigend. Gruß, Uwe
  12. Hallo, Erik, yeah, einen Fehler in der Firmware gefunden! Und der ist dann gleich behoben worden: Ja, so passt es auch bei mir. Jetzt musst Du nur noch checken, ob die Kategorie auch woanders noch im Bricklet-Zoo zuschlagen kann. Und: Wer lesen kann, der ist eindeutig im Vorteil ... Stand das schon immer da? Gruß, Uwe
  13. Hallo! Ich habe zwei Fragen zum "stabilen Ansatz". Mein Aufbau: Ich will das (erste und bei mir auch einzige) Bricklet einer Art (hier: RotaryPoti) via USB/localhost erkennen und dieses auch über USB-ab/an-Zyklen betreiben. (macOS, sehe gerade, dass ich mit den Bindings erst bei 2.1.24 bin, sonst aktuell) Wenn das Programm bei bei verbundenem Bricklet, startet, dann ist alles ok: ->cb_enumerate y6V available, NOW valid, callback set Ist verfügbar, ich kann abfragen. Mein callback wird nicht aufgerufen, hat sich ja auch nicht verändert. Dann ziehe ich das USB-Kabel. Frage 1: Beim IPCON_ENUMERATION_TYPE_DISCONNECTED wird dem Callback zwar die uid des nicht mehr vorhandenen RotaryPoti übergeben, aber nicht der device_identifier, der immer 0 ist. Warum? Ausgabe meines Beispielprogramms beim Abziehen des USB-Kabels ->cb_enumerate y6V (device_identifier 0) disconnected, NOW invalid Könnte nicht hier auch mitgeteilt werden, dass es ein ROTARY_POTI_DEVICE_IDENTIFIER-Bricklet war, das jetzt nicht mehr da ist? Ich finde, mein Programm sollte hier ->cb_enumerate y6V (device_identifier 215) disconnected, NOW invalid ausgeben! Nach dem (Wieder-) Anstecken des USB-Kabels wird enummeriert, alles erscheint zunächst gut: ->cb_enumerate y6V connected, NOW valid, callback set Dann aber wird sofort folgendes ausgegeben ->cb_position_has_changed Position y6V: 150 ->cb_position_has_changed Position y6V: -100 Frage 2: Warum wird mein Callback doppelt aufgerufen? Und dann auch noch beim ersten Mal mit einem ungültigen Poti-Wert 150? (Dass mein callback aufgerufen wird, ist fein! Der zweite Aufruf liefert den richtigen Wert. ) Oder mache ich etwas grundsätzlich falsch hier? Mein Programm hängt an. Gruß, Uwe potitest.c
  14. Copy in / Paste aus BrickV: Geht. Oh mann, die Blau-Nuancen sind sich SO ähnlich, dass ich bis eben nicht gesehen habe, dass sie unterschiedlich sind. Habe noch nie gesehen, dass da etwas "markiert" war ... Habe ergo noch nie versucht, da etwas zu kopieren ... Weder hier noch unter Windows, seit ALLEN Versionen bisher ... Danke für die Aufklärung! Gruß, Uwe
  15. Hallo, Photron, ich benutze 10.14.4 und auch 2.4.2. (Wie finde ich raus, welches python etc. Brickv verwendet? Oder liefert er alles mit, was er braucht?) Ich habe NICHT gesagt, dass ich nach nano kopiere! nano macht alles richtig beim Kopieren! Ich habe im Netbeans-Editor (8.2) die kopierte Zeichenkette zwischen zwei Anführungszeichen eingefügt. Da wird nichts angezeigt, die Bytes sind aber da, und sie bleiben beim Speichern. Wenn nano diese Datei öffnet, dann zeigt nano ein Extra-Space an. Der Netbeans-Editor weist das Verhalten nur auf, wenn zwischen Anführungszeichen eingefügt wird. (seems to be feature, not a bug ... ) Ich hab mal aus ein paar anderen Apps Text aus Masken und Menüs kopiert und im Editor von Netbeans zwischen zwei "" eingefügt. NUR beim Text, der aus dem Brickv kopiert wurde, wird in meinen Versuchen diese UTF-8 Byte Order Mark mit eingefügt. Das lässt mich denken, dass beim Markieren und Kopieren aus dem Brickv diese Information der Zwischenablage mit übergeben bzw. dort hinzugefügt wird. Vielleicht kann man dieses Verhalten abschalten? Danke für das ToDo! Schönes Wochenende, Uwe P.S. Wie kann man aus der Setup-Tabelle des Brickv die UID kopieren? Ein Klick markiert die Zeile, ein Doppelklick wechselt direkt zum Tab und ein Rechtsklick bewirkt bei mir gar nichts.
×
×
  • Create New...