Jump to content

duaw

Members
  • Gesamte Inhalte

    132
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    2

Alle erstellten Inhalte von duaw

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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.
  6. HEUREKA! Um auch GAAAANZ sicher zu gehen (ja, ich hab's mit den Augen ... ) habe ich die UID im BrickV im Poti-Tab oben links markiert, kopiert, gepastet: "y6V". Und ja, ich hab' mich auch schon bei drei Buchstaben vertippt. Erneutes Testen. Geht! Warum denn Beim erneuten Testen habe ich die UID getippt. Habe dann mal einen Diff gemacht. Siehe da, "y6V" kann etwas anderes als "y6V" sein. Siehe Anhang. Beim Markieren/Kopieren/Pasten aus dem BrickV gab es lt. Hexdump in der UID die drei Bytes EF BB BF vor dem 'y'. Das kann ich auch in meinem Netbeans-Editor bzw. BBEdit merken, aber nur, wenn ich mit Cursor-Rechts/-Links drüber fahre, was ich aber normalerweise nicht mache. nano hätte mir ein space gezeigt, wenn ich das rechtzeitig gemacht hätte. Back to the basic tools ... GRRRR Ist das nur bei mir so oder kann das jemand nachstellen? Ok, die Bindings sind nach wie vor ok!!! Unter Windows passiert das mit den Extra-Bytes nicht bzw. zumindest nicht so, dass ich es im Netbeans-Editor am Cursor-Verhalten merke. (Habe ich aber nicht weiter gecheckt.) Wieder etwas gelernt ... Gruß, Uwe
  7. Hallo! Ich habe das gerade GENAU WIE DU getestet und KANN DAS PROBLEM NACHSTELLEN: fdet-uw-imac:test1 uwe$ ls -ls total 240 40 -rw-r--r-- 1 uwe staff 18113 3 Mai 16:49 bricklet_rotary_poti.c 32 -rw-r--r-- 1 uwe staff 14381 3 Mai 16:49 bricklet_rotary_poti.h 8 -rw-r--r-- 1 uwe staff 920 3 Mai 16:47 example_simple.c 128 -rw-r--r-- 1 uwe staff 65417 3 Mai 16:48 ip_connection.c 32 -rw-r--r-- 1 uwe staff 16139 3 Mai 16:48 ip_connection.h fdet-uw-imac:test1 uwe$ gcc -Wall -pthread -I. *.c fdet-uw-imac:test1 uwe$ ./a.out Could not get position, probably timeout fdet-uw-imac:test1 uwe$ Der Fehlercode ist -1 Mein gepostetes Test-Programm, das erst enumeriert, dann abfragt funktioniert (so, wie der Brickv) fdet-uw-imac:test2 uwe$ ls -la total 240 drwxr-xr-x 7 uwe staff 224 3 Mai 16:36 . drwxr-xr-x@ 130 uwe staff 4160 3 Mai 16:27 .. -rw-r--r--@ 1 uwe staff 18113 3 Mai 16:30 bricklet_rotary_poti.c -rw-r--r--@ 1 uwe staff 14381 3 Mai 16:30 bricklet_rotary_poti.h -rw-r--r--@ 1 uwe staff 65417 3 Mai 16:30 ip_connection.c -rw-r--r--@ 1 uwe staff 16139 3 Mai 16:30 ip_connection.h -rw-r--r--@ 1 uwe staff 4057 3 Mai 16:36 rotpot1.c fdet-uw-imac:test2 uwe$ gcc -Wall -pthread -I. *.c fdet-uw-imac:test2 uwe$ ./a.out Example Program: rotpot1.c Hardware recognition: Dynamically detecting Rotary Bricklet USB disconnect and connect triggers callback! Application logic ..: N/A (no application) Source files .......: Just one (Monolithic). Press return to start ... Example code: read poti once .. Waiting for Rotary Poti Bricklet! ... Connected to demon. Enumeration requested. Rotary Poti Bricklet y6V available. Position: -122 Position: -122 Mein "gcc" ist fdet-uw-imac:test1 uwe$ gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1 Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin fdet-uw-imac:test1 uwe$ Jetzt bin ich verwirrt ... Zumal das ja auch bei mir mal ging. Was kann die Ursache sein? Uwe Nachtrag: Das log des brickd <I> <main_macos.c:168> Brick Daemon 2.3.2 started (pid: 125, daemonized: 0) 2019-05-03 17:14:34.503472 <I> <libusb:darwin_claim_interface> no interface found; setting configuration: 1 2019-05-03 17:14:34.521378 <I> <usb.c:193> Added USB device (bus: 20, device: 4) at index 0: Master Brick [62AKJh] 2019-05-03 17:15:31.927127 <I> <network.c:260> Added new client (N: 127.0.0.1:49273, T: plain-socket, H: 22/22, A: disabled) 2019-05-03 17:15:34.429387 <I> <client.c:251> Client (N: 127.0.0.1:49273, T: plain-socket, H: 22/22, A: disabled) disconnected by peer 2019-05-03 17:15:34.429458 <W> <client.c:419> Destroying client (N: 127.0.0.1:49273, T: plain-socket, H: 22/22, A: disabled) while 1 request(s) are still pending 2019-05-03 17:15:35.504135 <W> <zombie.c:95> Destroying zombie (id: 0) while 1 request(s) are still pending
  8. Hallo, remotecontrol, das Einfachst-Beispiel von der Webseite funktioniert nicht. Da wird nur via rotary_poti_get_position ein einziges mal abgefragt. Und das Abfragen funktioniert, wenn ich (wie im Bsp-Code) dynamisch enumeriere. So macht das der Brick-Viewer ja auch: connecten, USB abziehen, USB anstecken, automatisch re-connecten, geht. Das ist das, was mich irritiert. Beim RGBLED im selben Aufbau funktioniert das Simpel-Beispiel. Sehr irritiert, Uwe
  9. Hallo! Das simple Beispiel aus der Doku läuft nicht mehr ... und ich habe keine Ahnung, warum das so ist! Also: Der Code in example_simple.c liefert beim Aufruf von rotary_poti_get_position den Wert < 0 , also Fehler. example_callback.c macht ... nichts. Ja, ich habe die UID angepasst. In der VirtualBox mit Windows (Cygwin) geht's. Binding 2.1.24, Netbeans 8.2 unter macOS, der "gcc" ist clang-1001.0.46.4. Egal, ob C11, C99 oder C89. (gdb mag nicht.) Identische Projekte (ausser dem Code in der Datei, in der auch main ist). Interessant: Das dritte IDENTISCHE Projekt, in dem erst enumeriert wird, und dann rotary_poti_get_position aufgerufen wird, liefert die Poti-Stellung (Siehe Anhang). Also irgendwo ist da irgendwas oberfaul. Kann das jemand nachstellen? Hat jemand eine Arbeitshypothese oder Richtung, in die ich forschen kann? Wo finde ich die alten C-Bindings, um den schwarzen Peter dem Binding zuzuschustern ;-) Firmwares, Dämon sind aktuell. Jede Anregung ist willkommen, Uwe tfrotaryenum.c
  10. Ein großes Lob auch von meiner an die Sachlichkeit & Besonnenheit von borg in dieser Diskussion! Professionell.
  11. Nachtrag: Die kurzen Verzögerungen (0,2s schätze ich) waren an localhost / Brickv bemerkbar. Spielt da das Netzwerk eine Rolle??? Und die Kiste ist alles andere als ausgelastet. Kann ich aber nicht mehr reproduzieren. Uwe
  12. Uppps ... geht! (Vorschlag: Eine Sub-Versionsnummer im Dateinamen -- 2_0_3_1 -- und in der Datei hätte mir das deutlich gemacht ... ) Sorry. Wie weit habt ihr denn das schon selbst getestet? Gruß (und einen schönen -- arbeitsfreien! -- Sonntag) Uwe
  13. Hallo! Neue Version, -- keine seltsame Ausgabe mehr, keine Verzögerungen (Komisch. Was war das? Es gab nach start_counter über den Brickv auch alle paar Zahlen eine kurze Verzögerung ...) -- Der Aufruf mosquitto_pub -t tinkerforge/request/segment_display_4x7_bricklet/wNX/set_segments -m '{"segments": [102, 91, 91, 79], "brightness": 7, "colon": false}' -h 192.168.1.18 mündet im tinkerforge_mqtt in Traceback (most recent call last): File "/usr/local/bin/tinkerforge_mqtt", line 6138, in on_message response = self.dispatch_call(request_type, device, uid, function, msg.payload, response_path) File "/usr/local/bin/tinkerforge_mqtt", line 6475, in dispatch_call return self.device_call(device, device_class_name, uid, fnName, fnInfo, json_args) File "/usr/local/bin/tinkerforge_mqtt", line 6544, in device_call args = [symbols[data] if data in symbols else data for symbols, data in zip(reversed_symbols, args)] File "/usr/local/bin/tinkerforge_mqtt", line 6544, in <listcomp> args = [symbols[data] if data in symbols else data for symbols, data in zip(reversed_symbols, args)] TypeError: unhashable type: 'list' Gruß, Uwe
  14. Hallo! Ich bin jetzt erst dazu gekommen, mit dem Bindung erste Schritte zu machen. Und schon beim Nachvollziehen komme ich ins Straucheln: --rgb_led_button geht, allerdings dauert es ganz schön lang, bis ein mosquitto_pub -t tinkerforge/request/rgb_led_button_bricklet/Enx/get_color -m '' -h 192.168.1.18 im MQTT.fx eine Reaktion liefert. Und dort kommt auch {"red": "{", "green": "\"", "blue": "r"} an, obwohl ich vorher {"red":0, "green":255, "blue":255} geschickt habe und das auch ankam ... -- Vor lauter Betriebsblindheit habe ich nicht gemerkt, dass das Beispiel nach "Auch aufgetretene Fehler werden unter 'response'-Topics gepublisht, ..." GAR NICHT FEHLERHAFT IST ... Dazu hätte es natürlich so etwas gebraucht: mosquitto_pub -t tinkerforge/request/rgb_led_button_bricklet/D3P/set_color -m '{"red":0, "green":255}' -h 192.168.1.18 {"_ERROR": "The arguments ['blue'] where missing for a call of set_color of device D3P of type rgb_led_button_bricklet."} An der Stelle möchte ich noch mal betonen, dass es gerade für Anfänger absolut wichtig ist, eine vollständige, korrekte, hilfreiche Doku zu haben! Die Doku darf nicht von der Nerd- oder Profi-Warte aus geschrieben sein! Sie muss auch sprachlich, orthografisch und was die Interpunktion angeht, sich auf akzeptablem Niveau bewegen! Da sehe ich Luft nach oben. -- Es gelingt mir partout NICHT die Segmente eines 4x7 zu setzen: mosquitto_pub -t tinkerforge/request/segment_display_4x7_bricklet/wNX/set_segments -m '{"segments": [102, 91, 91, 79], "brightness": 7, "colon": false}' -h 192.168.1.18 (Das Abfragen der Segmente aber schon!) Gruß, Uwe
  15. Hallo, ich erhalte unter macOS 10.14.3 „Brickv“ ist beschädigt und kann nicht geöffnet werden. Es empfiehlt sich, das Objekt in den Papierkorb zu bewegen. Was ich dann auch tue ... Gruß, Uwe
  16. Nachtrag: -- nach dem manuellen Hinzufügen von ptc wird nach Neustart (von oh2) per autodiscovery das ptc-bricklet noch mal gefunden : Ist jetzt 2x als Thing da ... -- jetzt 99,5%rF -- kann nicht ausschließen, dass da etwas hing ... Habe zwischendurch den Stapel resettet. Gruß, Uwe
  17. Super, Theo! Kurzes Feedback: -- BrickletBarometer zeigt -NaN bei "temperature" in Paper-UI/Control, richtig in Brickv (Muss noch sitemap machen ...) -- RotaryEncoder zeigt nach (Neu-) Start von oh2 -NaN bei count (Ist das immer so? Sollte 0 sein.) -- humidity-Bricklet zeigt -NaN (gerade jetzt bei 100% Luftfeuchte, korrekt im Brickv und im alten Binding auf Produktiv-Maschine) -- von meinen 4 PTC (am selben Master) ist einer -NaN im Paper-UI, der und ein weiterer OFFLINE in der Things-Liste (aber alle korrekt im Brickv und im alten Binding Zu einem ptc gibt es die Meldung im log: 019-01-26 11:41:37.613 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler PTCBrickletHandler of thing tinkerforge:ptc:37129507:qbK tried updating channel temperature although the handler was already disposed. -- auch nach manuellem Löschen/Hinzufügen von ptc mit UID qbK bleibt die Meldung mit 1Hz im log. Das thing ist aber da. -- Beim Autodiscover wird das thing mit Namen "ptc" entdeckt. Beim manuellen Anlegen wird das Thing im Paper-UI mit Namen "BrickletPTC" vorgeschlagen. Der Name sollte in beiden Fällen gleich sein. -- Ich empfinde es als unvorteilhaft, wenn Things gleicher Art erkannt werden und alle im PaperUI den gleichen Namen haben "ptc-<UID>" wäre doch schön, oder? Und für die Brickd-Things auch eine Unterscheidung ? (Ich hänge immer die letzte IP-Nummer dran) -- (Kosmetik) ptc Wiremode könnte auf 2/3/4 begrenzt werden (es steht nix da und alle ganzen Zahlen sind möglich. Wird das auf default 2 gesetzt? Die Doku sagt: "Zusätzlich muss die Leiteranzahl mit Hilfe der API gesetzt werden.") -- Ist intensity (Sound) "Number" oder "Number:Dimensionless" ? (-- Und ich hätte echt gedacht, dass es für "Luft-Feuchte" auch eine Einheit gibt.) --dualrelay tickt richtig, industrialquad sieht gut aus Gruß, Uwe
  18. Hallo, Theo, ich stoppe oh2, kopiere das binding nach /usr/share/openhab2/addons lösche brutal die Verzeichnisse cache json tmp in /var/lib/openhab2 starte oh2 und sehe 2019-01-25 16:33:00.942 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.tinkerforge-2.5.0-5-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tinkerforge [191] Unresolved requirement: Import-Package: org.eclipse.jdt.annotation at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?] ... Das passiert mir mit den letzten Versionen 4 und 5. Was mache ich jetzt falsch??? Gruß, Uwe
  19. Kommando zurück, das geht nicht. Nach einem Neustart ist das item nicht richtig im Basic-UI. Man braucht "69eea0f1" als "Location" im item ...
  20. Ok, jetzt geht auch realtimeclock wie erwartet. Meine andere Frage ist war wie folgt: Autodiscover geht natürlich. Alles in der in-box, dann als Thing im Paper UI ganz automatisch ... ... unter "Name" steht "realtimeclock" ... unter "Location" "Bridge Selection" Brickd - tinkerforge:brickd:69eea0f ... unter Configuration Parameters dann "xNx" In der sitemap verwende ich den Namen des Things. Mein item in .items ist zunächst (Copy/Paste aus dem Paper-UI) DateTime datumZeit { channel="tinkerforge:realtimeclock:69eea0f1:xNx:datetime" } gewesen Ich sehe aber gerade (Versuch macht kluch!), dass ich auch nur DateTime datumZeit { channel="tinkerforge:realtimeclock:xNx:datetime" } schreiben kann! Damit hat sich die Frage geklärt! Sollte ich das Bricklet jetzt an einen anderen Brick anstecken, dann muss ich das item nicht anfassen. Und so sollte das sein Ach: Nach dem manuellen Löschen von Things (aller Things, tlw. mit force remove), dem Hinzufügen der Brickd things und der entdeckten things sehe ich massig Meldungen im log wie Handler RealTimeClockBrickletHandler of thing tinkerforge:realtimeclock:f33aed9d:xNx tried updating channel datetime although the handler was already disposed. Irgendwer hat da irgendwie das Löschen nicht mitgekriegt, oder? Gruß, Uwe
  21. Hallo, Theo, Du schreibst: "... der Datentyp von Number auf DateTime geändert. Vermutlich musst du das Thing löschen und neu anlegen." Hmmm. Das habe ich getan. Es wird als online angezeigt. Als DateTime. Aber "Control" des PaperUI zeigt jetzt ein BrickletRealTimeClock mit der DateTime "-" an... (Eine sitemap habe ich nicht angelegt. Im PaperUI müsste es ja stimmen.) Und eine Frage: Mit den alten 1-er Bindings habe ich die IP-Adressen der Bricklets aufgelistet. Dann wurde Bricklet XYZ anhand der UID gefunden. Jetzt muss ich zwingend für das Thing angeben, an welcher TF-IP-Nummer (Brickd) es steckt. Hat das einen Grund ? (Ausser, dass die Realisierung einfacher ist?) Und noch eine Frage: Wenn das Bricklet unerreichbar ist, muss ich das selber feststellen, oder? (Ich behelfe mir mit einem Thing "Zuletzt Gesehen der IP-Adresse") Es kommt nicht irgendwann ein Wechsel zu NULL oder was auch immer? Gruß, Uwe
  22. Hallo Theo, ptc ok, humidityv2 ok (mit richtigen Prozenten in Control des PaperUI), motiondetector ok, barometer ok, soundintensity ok allerdings geht realtimeclock nicht mehr (zeigt NaN, im Brickviewer ok) Und das Kopieren des neuen Bindings in addons allein hat bei mir nicht gereicht. Nach Löschen von /var/lib/openhab2/cache und .../tmp hat es funktioniert Gruß und Danke, Uwe
  23. Hier mein Test: Ubuntu in VM , PaperUI only humidity v2 geht. Die zuschaltbaren Heizung ist aber nicht da. rotary encoder geht fast: Im log sehe ich Button OPEN/CLOSED, aber nicht im PaperUI voltagecurrent geht (ich messe aber nur voltage) Seltsam erscheint mir, dass im PaperUI die Sensorwerte per Klick geändert werden können ... Meine Wunschliste hast Du ja schon,,, Tausend Dank! Uwe
  24. Hallo, Theo, Ich will openHAB 2.4 aufsetzen (in einer VM, Debian) und dann schauen, wie ich meinen Kram rüber bekomme. OH 2.4 sollte ja kein Problem sein, oder? Kann ich alte/neue Bindings parallel verwenden? Wie kommen die zu mir? Da ich noch gar nicht in die Entwicklung der Bindings reingeschaut habe: Was braucht es dazu? Kann man dich anders unterstützen? Gruss, Uwe
×
×
  • Neu erstellen...