Jump to content

Martin

Members
  • Gesamte Inhalte

    19
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von Martin

  1. Hallo, kann jemand einen Link zu den OpenHAB2-Tinkerforge-Binding Beispielen posten? Unter https://www.tinkerunity.org/topic/4909-beta-version-of-the-openhab-bindings/ und https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html finden sich Hinweise, aber bezugnehmend auf finde ich weder für die dort verlinkte beta23 als auch für die neuere https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta24.zip einen examples-Ordner. Die Hinweise im readme_de.txt (und readme_en.txt) scheinen ähnlich zur o.g. Seite. Schon bei der "Konfiguration" wird aber z.B. nicht beschrieben, wo die IP-Adressen der Tinkerforge-Geräte angeben werden. (Beim OpenHAB1-Binding war das die services/tinkerforge.cfg Datei und es gab keinen Bezug der IP-Adressen zu den zugehörigen Bricks/Bricklets.) (Noch scheint das OpenHAB2-Tinkerforge-Binding (beta24) hier aber sowieso noch nicht so recht zu laufen...) Danke, Martin
  2. Hallo, wo findet sich eine "Einstiegsseite" für OpenHAB2+Tinkerforge mit aktuellem Downloadlink und kurzem Readme zur Installation? So eine Diskussion (mit aktuell 15 Seiten) ist recht umständlich, um an die relevante Information zu kommen. Zu Beginn findet sich unter https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/ zwar ein Link auf https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta23.zip (wobei "Die 23. Beta findet sich hier." nicht gerade optimal für eine Internet-Suche ist) Später dann z.B. unter https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/page/12/?tab=comments#comment-30294 noch ein Anhang (https://www.tinkerunity.org/applications/core/interface/file/attachment.php?id=2096), der hier allerdings scheinbar nicht mehr vorhanden ist ("unavailable"). Unter https://download.tinkerforge.com/_stuff/ findet sich aber gerade keine neuere Version. (Wo dann?) Welches Java Binding soll verwendet werden? https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/?do=findComment&comment=31828 Was denn nun? tinkerforge-2.1.26.jar oder 2.1.29? Für Debian/Ubuntu gibt es eine Tinkerforge Repository mit Java-Bindings, s. https://www.tinkerforge.com/de/doc/Software/APT_Repository.html#pakete Nach der Installation von libtinkerforge-java: $ ls -l /usr/share/java/tinkerforge* lrwxrwxrwx 1 root root 15 Nov 2 17:33 /usr/share/java/tinkerforge-2.1.29.jar -> tinkerforge.jar -rw-r--r-- 1 root root 1734763 Nov 2 17:33 /usr/share/java/tinkerforge.jar (Kurios, dass hier die der Link die Version im Namen trägt und nicht die Datei.) Die aktuelle Version ist hier aktuell also 2.1.29. Vielleicht könnte man die openhab Bindings einfach auch hier verfügbar machen. Am besten wäre aber (wieder) ein "offizielles" OpenHAB Binding (am besten gleich für OpenHAB3). Muss (in OpenHAB2) das OpenHAB1 Binding deinstalliert oder nur deaktiviert sein, falls man dieses OpenHAB2 Binding testen will? Martin
  3. Eine Kombination aus Energy_Monitor (https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Energy_Monitor.html), Stromwandler, Stromverlängerungskabel und evtl. sogar noch dem Spannungstransformator in einem Gehäuse, so dass am besten auch nur eine Steckdose belegt ist (was hier auch immer technisch möglich ist). Der Aufbau in https://www.tinkerforge.com/de/shop/media/catalog/product/cache/2/image/1800x/040ec09b1e35df139433887a97daa66f/b/r/bricklet_energy_monitor_tutorial_1_800.jpg ist doch eher eine Bastellösung und nicht direkt so im Haushalt einsetzbar. Gibt es so etwas bereits? Danke, Martin
  4. Hallo, ich würde gerne eine Leitung zu einer Pumpe (Drehstrom) auf Stromfluss prüfen, um festzustellen wann die Pumpe läuft... (True/False ist ausreichend) Die Leitung liegt zwar offen da, soll aber nicht durchtrennt werden, um z.B. etwas zwischenzuschalten. (Die max. Spannung des Voltage/Current Bricklets (http://www.tinkerforge.com/en/doc/Hardware/Bricklets/Voltage_Current.html) wäre mit 36V für diesen Anwendungszweck wohl auch zu klein und ich möchte als Laie auch nicht an der bestehenden Elektroinstallation herumpfuschen.) Ein stromdurchflossener Leiter sollte doch eigenlich ein Magnetfeld aufbauen. Das Hall Effect Bricklet (http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Hall_Effect.html) wird dieses relativ schwache Magnetfeld aber vermutlich nicht detektieren können, oder? Könnte man einen "Non-invasive AC current sensor", wie z.B. einen SCT-013-030/SCT-013-000 (vgl. https://openenergymonitor.org/emon/buildingblocks/report-yhdc-sct-013-000-current-transformer) an ein Analog In Bricklet anschließen? Oder einfach mit Kupferlackdraht eine Rogowskispule basteln und deren Spannung mit einem Analog In Bricklet messen? (Gibt es da eine Anleitung?) Evtl. könnte man ja auch einen günstigen (Metall-&)Spannungsfinder (oder Strommesszange?) umfunktionieren, indem man die Batterieanschlüsse mit einem einfachen Steckernetzteil verbindet, die Lautsprecheranschlüsse (oder LED Anschluß) herausführt und mit einem Analog In Bricklet die Spannung misst? (Falls man bei einer Strommesszange eine Litze/Phase separat messen muss, ist das allerdings nicht praktikabel.) Das alte Analog In Bricklet (http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Analog_In.html) scheint für kleine Spannungen von 0V - 6,05V mit ~1,48mV eine höhere Auflösung als der Nachfolger, das Analog In Bricklet 2.0 (http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Analog_In_V2.html) zu haben, bei dem generell ~10mV angegeben sind. Beim Industrial Dual Analog In Bricklet (https://www.tinkerforge.com/en/shop/bricklets/industrial-dual-analog-in-bricklet.html) sind es 4 mV. Welche Auflösung wird dann für so eine Anwendung benötigt? Hat schon jemand eine "berührungslose" Leitungsstrommessung mit TinkerForge verwirklicht, oder kann Tipps (z.B. Links zu einer Bauanleitung) geben? Danke, Martin
  5. Hallo, ich verwende gerade den Data Logger des Brick Viewers 2.3.4 (unter Linux auf einem Wandboard) um ein Distance US Bricklet (http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Distance_US.html) mit Distance Value 1 und unterschiedlichen Moving Average Length Werten auszulesen: Moving Average Length 0 20160623_115450;Distance US Bricklet;nZ1;Distance Value;1089; 20160623_115451;Distance US Bricklet;nZ1;Distance Value;1083; 20160623_115452;Distance US Bricklet;nZ1;Distance Value;1080; Moving Average Length 10 20160623_115522;Distance US Bricklet;nZ1;Distance Value;10995; 20160623_115523;Distance US Bricklet;nZ1;Distance Value;10993; 20160623_115524;Distance US Bricklet;nZ1;Distance Value;10993; Moving Average Length 20 20160623_115553;Distance US Bricklet;nZ1;Distance Value;5489; 20160623_115554;Distance US Bricklet;nZ1;Distance Value;5489; 20160623_115555;Distance US Bricklet;nZ1;Distance Value;5489; Moving Average Length 100 20160623_115620;Distance US Bricklet;nZ1;Distance Value;1093; 20160623_115621;Distance US Bricklet;nZ1;Distance Value;1088; 20160623_115622;Distance US Bricklet;nZ1;Distance Value;1086; Der Sensor ist stationär montiert und die Unterschiede können kaum von der Messung selbst oder unterschiedlicher Mittelwertbildungen stammen. Woher kommen diese starken Schwankungen? Im Source code (https://codeload.github.com/Tinkerforge/distance-us-bricklet/legacy.zip/master) findet man unter Tinkerforge-distance-us-bricklet-fbe5634/software/src/ in distance-us.h #define MOVING_AVERAGE_DEFAULT 20 #define MOVING_AVERAGE_MAX 100 so dass ein Wert >100 wohl kaum Sinn macht. Betrachtet man distance-us.c sieht man, dass BC->moving_average_sum und BC->moving_average[] im constructor mit 0 initialisiert werden (ab Zeile 100): BC->moving_average_sum = 0; BC->moving_average_tick = 0; BC->moving_average_num = MOVING_AVERAGE_DEFAULT; for(uint8_t i = 0; i < MOVING_AVERAGE_MAX; i++) { BC->moving_average[i] = 0; } In distance_from_analog_value wird die neue Summe dann ausgehend von der alten berechnet (ab Zeile 159): if (BC->moving_average_num > 0) { BC->moving_average_sum = BC->moving_average_sum - BC->moving_average[bC->moving_average_tick] + analog_data; BC->moving_average[bC->moving_average_tick] = analog_data; BC->moving_average_tick = (BC->moving_average_tick + 1) % BC->moving_average_num; ret_value = (BC->moving_average_sum + BC->moving_average_num/2)/BC->moving_average_num; } else { ret_value = analog_data; } Müsste da in set_moving_average (Zeile 190) bei einer Änderung von BC->moving_average_num nicht auch BC->moving_average_sum zunächst einmal wieder neu berechnet werden? void set_moving_average(const ComType com, const SetMovingAverage *data) { BC->moving_average_num = data->average; if(BC->moving_average_num > MOVING_AVERAGE_MAX) { BC->moving_average_num = MOVING_AVERAGE_MAX; } BA->com_return_setter(com, data); } Bei einer Änderung von BC->moving_average_num sollten die fehlenden Werte addiert/überschüssigen Werte subtrahiert werden, um die neue Summe zu berechnen oder einfach alles neu berechnet werden. Ansonsten wird ab der Änderung von einer falschen Summe der älteste Wert subtrahiert und der neueste addiert... Genau genommen sind die Werte in der Anfangsphase zudem noch verfälscht, da evtl. noch Nullwerte eingehen und der Mittelwert für BC->moving_average_num natürlich erst berechnet werden kann, falls so viele Werte vorliegen. BC->moving_average_num müsste also schrittweise heraufgesetzt werden. Aber im Gegensatz zu einem "Summenproblem" verschwindet so ein Fehler nach kurzer Zeit von selbst... Aber wahrscheinlich habe ich das auf die Schnelle nur nicht richtig gesehen... Zum Schluß noch eine weitere Frage zum Data Logger: Wie kann ich das Speichern der Bricklet-Bezeichung in jeder Zeile 20160623_115450;Distance US Bricklet;nZ1;Distance Value;1089; deaktivieren? 20160623_115450;nZ1;Distance Value;1089; reicht mir völlig aus, da ja über die ID nZ1 ja bereits eindeutig spezifiziert ist, um welches Bricklet es sich handelt und so ein unnötiges Datenvolumen vermieden werden kann. Zudem wäre eine kürzere Bezeichnung als Distance Value wünschenswert. Danke, Martin
  6. Hallo Theo, das ging ja schnell. Der Snapshot vom 20. Juni spätabends scheint bei mir zu funktionieren. Vielen Dank!!! Martin
  7. Hallo Theo, musste am Wochenende arbeiten und sehe die Email leider erst jetzt... Mit dem gerade heruntergeladenen org.openhab.binding.tinkerforge-1.9.0-SNAPSHOT.jar erhalte ich nun 2016-06-20 00:19:36.595 [ERROR] [.service.AbstractActiveService] - Error while executing background thread Tinkerforge Refresh Service java.lang.NullPointerException: null at org.openhab.binding.tinkerforge.internal.model.impl.MBrickletDistanceUSImpl.fetchSensorValue(MBrickletDistanceUSImpl.java:949) ~[na:na] at org.openhab.binding.tinkerforge.internal.TinkerforgeBinding.updateItemValues(TinkerforgeBinding.java:625) ~[na:na] at org.openhab.binding.tinkerforge.internal.TinkerforgeBinding.execute(TinkerforgeBinding.java:589) ~[na:na] at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:156) ~[na:na] at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:173) ~[na:na] Es sind anscheinend 105 Zeilen hinzugekommen... Ich hoffe, das hilft Dir weiter. Danke und gute Nacht, Martin
  8. Hallo, betreibt jemand (erfolgreich) ein DistanceUS Bricklet (https://www.tinkerforge.com/en/shop/bricklets/distance-us-bricklet.html) mit OpenHAB (vgl. https://github.com/openhab/openhab/wiki/Tinkerforge-Binding#distance-us-bricklet)? Nachdem hier schon einige Bricklets (Wetterstation&TemperatureIR) erfolgreich über eine Ethernet(POE)-MasterExtension in OpenHAB 1.8.3 eingebunden sind, wollte ich nun über eine weitere IP Adressen noch ein DistanceUS, Moisture und HallEffect Bricklet einbinden. Leider findet sich für das DistanceUS bei jedem Update nun ein Fehler in der Log-Datei, wie z.B.: 2016-06-18 21:44:19.660 [ERROR] [.service.AbstractActiveService] - Error while executing background thread Tinkerforge Refresh Service java.lang.NullPointerException: null at org.openhab.binding.tinkerforge.internal.model.impl.MBrickletDistanceUSImpl.fetchSensorValue(MBrickletDistanceUSImpl.java:844) ~[na:na] at org.openhab.binding.tinkerforge.internal.TinkerforgeBinding.updateItemValues(TinkerforgeBinding.java:645) ~[na:na] at org.openhab.binding.tinkerforge.internal.TinkerforgeBinding.execute(TinkerforgeBinding.java:608) ~[na:na] at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:156) ~[na:na] at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:173) ~[na:na] Die Fehlermeldung ist der unter https://groups.google.com/forum/#!topic/openhab/2djA06ICYYc beschiebenen recht ähnlich. Vor der Suche nach dem/den Konfigurationsfehler(n) wäre es schön zu erfahren, ob das DistanceUS Bricklet schon einmal erfolgreich mit OpenHAB betrieben wurde... Danke, Martin
  9. Hallo, weder auf https://github.com/theoweiss/openhab/wiki noch auf https://github.com/openhab/openhab/wiki/Tinkerforge-Binding habe ich etwas zum Hall Effect Bricklet finden können - zumindest wenn ich nach "hall" suche. (Von OpenHAB Version 1.5 nach 1.7.1 ist das entsprechende Binding doch hoffentlich nicht wieder entfernt worden...) Wie heisst denn das Hall Effect Bricklet (https://www.tinkerforge.com/de/shop/bricklets/hall-effect-bricklet.html) in OpenHAB? @Tinkerforge: Es wäre übrigens schön, wenn unter den "Programmierschnittstellen", wie z.B. http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Hall_Effect.html#programmierschnittstelle auch das OpenHAB Binding mit Link auf die spezifische Dokumentation aufgelistet wäre (auch wenn OpenHAB keine Programmiersprache ist). Schönen Abend und Danke, Martin
  10. Ja, es ist wie bereits erwähnt ein Ubuntu 12.04.4 LTS Netbook, mit dem der brickv/brickd bereits erfolgreich liefen. Wie ich bereits geschrieben habe, hat es auch mit USB 2 nicht funktioniert. (Ich hatte nur USB2 und USB3 verwechselt.) Am USB2 Port meldet sich der Masterbrick laut dmesg zunächst ebenfalls problemlos an und der brickd zeigt keine Fehlermeldungen, aber brickv findet leider ebenfalls nichts... $ dmesg | tail -n 6 [ 4380.955183] usb 3-1: new full-speed USB device number 7 using ohci-pci [ 4381.129497] usb 3-1: New USB device found, idVendor=16d0, idProduct=063d [ 4381.129513] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4381.129522] usb 3-1: Product: Master Brick [ 4381.129530] usb 3-1: Manufacturer: Tinkerforge GmbH [ 4381.129537] usb 3-1: SerialNumber: XXXXXX $ sudo brickd --debug --libusb-debug 2014-03-23 21:17:36.321319 <I> <other|main_linux.c:394> Brick Daemon 2.0.10 started 2014-03-23 21:17:36.321791 <D> <event|event.c:56> Initializing event subsystem 2014-03-23 21:17:36.322035 <D> <event|event.c:139> Added generic event source (handle: 4, events: 1) at index 0 2014-03-23 21:17:36.322257 <D> <hardware|hardware.c:37> Initializing hardware subsystem 2014-03-23 21:17:36.322469 <D> <usb|usb.c:191> Initializing USB subsystem 2014-03-23 21:17:36.322709 <D> <usb|usb_posix.c:151> Successfully loaded brickd (for libusb symbols) 2014-03-23 21:17:36.323187 <D> <event|event.c:139> Added USB event source (handle: 6, events: 1) at index 1 2014-03-23 21:17:36.323422 <D> <event|event.c:139> Added USB event source (handle: 8, events: 1) at index 2 2014-03-23 21:17:36.323635 <D> <usb|usb.c:217> libusb can handle timeouts on its own 2014-03-23 21:17:36.323877 <D> <usb|usb.c:240> libusb does not support hotplug 2014-03-23 21:17:36.325740 <D> <usb|usb.c:119> Found new USB device (bus: 3, device: 7) 2014-03-23 21:17:36.326008 <D> <usb|usb_stack.c:199> Acquiring USB device (bus: 3, device: 7) 2014-03-23 21:17:36.326357 <D> <event|event.c:139> Added USB event source (handle: 9, events: 1) at index 3 2014-03-23 21:17:36.326574 <D> <event|event.c:139> Added USB event source (handle: 11, events: 1) at index 4 2014-03-23 21:17:36.328330 <D> <usb|usb.c:174> Got told to add libusb pollfd (handle: 12, events: 4) 2014-03-23 21:17:36.328594 <D> <event|event.c:139> Added USB event source (handle: 12, events: 4) at index 5 2014-03-23 21:17:36.636910 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1b50 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.636995 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1bc8 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.637037 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1c40 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.637078 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1cb8 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.637117 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1d30 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.637154 <I> <usb|usb.c:144> Added USB device (bus: 3, device: 7) at index 0: Master Brick [XXXXXX] 2014-03-23 21:17:36.637486 <D> <hotplug|udev.c:273> Initializing udev subsystem 2014-03-23 21:17:36.637518 <D> <hotplug|udev.c:167> Trying to load libudev.so.1 2014-03-23 21:17:36.637876 <D> <hotplug|udev.c:172> Could not load libudev.so.1: libudev.so.1: cannot open shared object file: No such file or directory 2014-03-23 21:17:36.637912 <D> <hotplug|udev.c:173> Trying to load libudev.so.0 instead 2014-03-23 21:17:36.638376 <D> <hotplug|udev.c:189> Successfully loaded libudev.so.0 2014-03-23 21:17:36.638652 <D> <event|event.c:139> Added generic event source (handle: 13, events: 1) at index 6 2014-03-23 21:17:36.638719 <D> <network|network.c:120> Initializing network subsystem 2014-03-23 21:17:36.638843 <D> <network|network.c:205> Started listening to '0.0.0.0' (IPv4) on port 4223 2014-03-23 21:17:36.638881 <D> <event|event.c:139> Added generic event source (handle: 14, events: 1) at index 7 2014-03-23 21:17:36.638913 <D> <event|event.c:213> Starting the event loop 2014-03-23 21:17:36.638941 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s) 2014-03-23 21:17:36.687884 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready 2014-03-23 21:17:36.687949 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5 2014-03-23 21:17:36.687998 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1b50 returned successfully from Master Brick [XXXXXX] 2014-03-23 21:17:36.688020 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: XXXXXX, L: 34, F: 253) from Master Brick [XXXXXX] 2014-03-23 21:17:36.688080 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: XXXXXX, L: 34, F: 253) 2014-03-23 21:17:36.688118 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1b50 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.688137 <D> <event|event_posix.c:268> Handled all ready event sources 2014-03-23 21:17:36.688151 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s) 2014-03-23 21:17:36.688838 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready 2014-03-23 21:17:36.688866 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5 2014-03-23 21:17:36.688892 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1bc8 returned successfully from Master Brick [XXXXXX] 2014-03-23 21:17:36.688909 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: jkY, L: 34, F: 253) from Master Brick [XXXXXX] 2014-03-23 21:17:36.688925 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: jkY, L: 34, F: 253) 2014-03-23 21:17:36.688949 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1bc8 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.688966 <D> <event|event_posix.c:268> Handled all ready event sources 2014-03-23 21:17:36.688979 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s) 2014-03-23 21:17:36.689846 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready 2014-03-23 21:17:36.689884 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5 2014-03-23 21:17:36.689913 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1c40 returned successfully from Master Brick [XXXXXX] 2014-03-23 21:17:36.689931 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: jqv, L: 34, F: 253) from Master Brick [XXXXXX] 2014-03-23 21:17:36.689948 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: jqv, L: 34, F: 253) 2014-03-23 21:17:36.689974 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1c40 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.689991 <D> <event|event_posix.c:268> Handled all ready event sources 2014-03-23 21:17:36.690004 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s) 2014-03-23 21:17:36.690855 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready 2014-03-23 21:17:36.690895 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5 2014-03-23 21:17:36.690927 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1cb8 returned successfully from Master Brick [XXXXXX] 2014-03-23 21:17:36.690945 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: hUa, L: 34, F: 253) from Master Brick [XXXXXX] 2014-03-23 21:17:36.690962 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: hUa, L: 34, F: 253) 2014-03-23 21:17:36.690991 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1cb8 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.691008 <D> <event|event_posix.c:268> Handled all ready event sources 2014-03-23 21:17:36.691022 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s) 2014-03-23 21:17:36.691844 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready 2014-03-23 21:17:36.691878 <D> <event|event_posix.c:253> Handling USB event source (handle: 12, received events: 4) at index 5 2014-03-23 21:17:36.691906 <D> <usb|usb_transfer.c:94> Read transfer 0x9c1d30 returned successfully from Master Brick [XXXXXX] 2014-03-23 21:17:36.691924 <D> <usb|usb_stack.c:86> Got enumerate-connected callback (U: jny, L: 34, F: 253) from Master Brick [XXXXXX] 2014-03-23 21:17:36.691940 <D> <network|network.c:301> No clients connected, dropping enumerate-connected callback (U: jny, L: 34, F: 253) 2014-03-23 21:17:36.691965 <D> <usb|usb_transfer.c:265> Submitted read transfer 0x9c1d30 for 80 bytes to Master Brick [XXXXXX] 2014-03-23 21:17:36.691981 <D> <event|event_posix.c:268> Handled all ready event sources 2014-03-23 21:17:36.691995 <D> <event|event_posix.c:207> Starting to poll on 8 event source(s) Aber anscheinend scheint da etwas mit dem Rechner nicht in Ordnung zu sein, denn mit dem RPi klappt es. Ich hatte dieses Wochenende nur etwas wenig Zeit - ich hätte das gleich alles testen sollen. Mitte April bekommt das Netbook dann Ubuntu 14.04 LTS und hoffentlich klappt es dann wieder... Die gute Nachricht ist, dass DHCP nun mit der 2.2.0beta Masterbrick Firmware funktioniert! Ich habe mir mit wireshark die Pakete angesehen und die sehen nun OK aus. Und nun zurück an die Arbeit... Martin
  11. Ja, die Master Extension sollte entfernt werden und das könnte man unter http://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing eigentlich nochmals erwähnen. Das allein hat bei mir aber zunächst noch nichts gebracht. Erst als ich auf dem Ubuntu Notebook den USB3 Port verwendet habe, bei dem statt xhci_hcd nun das ohci-pci Kernelmodul verwendet wird, hat es funktioniert: [ 758.680573] usb 5-1: new full-speed USB device number 27 using xhci_hcd [ 758.703808] usb 5-1: unable to read config index 0 descriptor/all [ 758.703827] usb 5-1: can't read configurations, error -71 [ 758.872597] usb 5-1: new full-speed USB device number 28 using xhci_hcd [ 758.916698] usb 5-1: Device not responding to set address. [ 759.123602] usb 5-1: Device not responding to set address. [ 759.324642] usb 5-1: device not accepting address 28, error -71 [ 759.492524] usb 5-1: new full-speed USB device number 29 using xhci_hcd [ 759.518893] usb 5-1: Device not responding to set address. [ 759.723968] usb 5-1: Device not responding to set address. [ 759.924727] usb 5-1: device not accepting address 29, error -71 [ 760.092611] usb 5-1: new full-speed USB device number 30 using xhci_hcd [ 760.167091] usb 5-1: Device not responding to set address. [ 760.372159] usb 5-1: Device not responding to set address. [ 760.572619] usb 5-1: device not accepting address 30, error -71 [ 760.572689] hub 5-0:1.0: unable to enumerate USB device on port 1 [ 812.956592] usb 3-1: new full-speed USB device number 3 using ohci-pci [ 813.117263] usb 3-1: New USB device found, idVendor=03eb, idProduct=6124 [ 813.117279] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 813.120355] cdc_acm 3-1:1.0: This device cannot do calls on its own. It is not a modem. [ 813.120485] cdc_acm 3-1:1.0: ttyACM0: USB ACM device und ich konnte die firmware_brick_master_2_2_0_beta1.bin auf den Masterbrick flashen. Leider habe ich nun ein neues Problem. Die blauen LED leuchten beim Anschliessen per USB zwar wieder wie gewohnt, der brickv bzw. brickd bekommt aber keine Verbindung hin. USB2- oder USB3-Anschluss spielt hier keine Rolle: [ 4396.861862] usb 5-1: new full-speed USB device number 8 using xhci_hcd [ 4396.884649] usb 5-1: New USB device found, idVendor=16d0, idProduct=063d [ 4396.884665] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4396.884674] usb 5-1: Product: Master Brick [ 4396.884682] usb 5-1: Manufacturer: Tinkerforge GmbH [ 4396.884690] usb 5-1: SerialNumber: XXXXXX $ sudo brickd --debug --libusb-debug 2014-03-22 23:56:50.068939 <I> <other|main_linux.c:394> Brick Daemon 2.0.10 started 2014-03-22 23:56:50.069131 <D> <event|event.c:56> Initializing event subsystem 2014-03-22 23:56:50.069193 <D> <event|event.c:139> Added generic event source (handle: 4, events: 1) at index 0 2014-03-22 23:56:50.069258 <D> <hardware|hardware.c:37> Initializing hardware subsystem 2014-03-22 23:56:50.069299 <D> <usb|usb.c:191> Initializing USB subsystem 2014-03-22 23:56:50.069363 <D> <usb|usb_posix.c:151> Successfully loaded brickd (for libusb symbols) 2014-03-22 23:56:50.069637 <D> <event|event.c:139> Added USB event source (handle: 6, events: 1) at index 1 2014-03-22 23:56:50.069684 <D> <event|event.c:139> Added USB event source (handle: 8, events: 1) at index 2 2014-03-22 23:56:50.069725 <D> <usb|usb.c:217> libusb can handle timeouts on its own 2014-03-22 23:56:50.069762 <D> <usb|usb.c:240> libusb does not support hotplug 2014-03-22 23:56:50.071425 <D> <usb|usb.c:119> Found new USB device (bus: 5, device: 2014-03-22 23:56:50.071496 <D> <usb|usb_stack.c:199> Acquiring USB device (bus: 5, device: 2014-03-22 23:56:50.071656 <D> <event|event.c:139> Added USB event source (handle: 9, events: 1) at index 3 2014-03-22 23:56:50.071700 <D> <event|event.c:139> Added USB event source (handle: 11, events: 1) at index 4 2014-03-22 23:56:50.073204 <D> <usb|usb.c:174> Got told to add libusb pollfd (handle: 12, events: 4) 2014-03-22 23:56:50.073266 <D> <event|event.c:139> Added USB event source (handle: 12, events: 4) at index 5 2014-03-22 23:56:50.266779 <D> <usb|usb.c:183> Got told to remove libusb pollfd (handle: 12) 2014-03-22 23:56:50.266882 <D> <event|event.c:165> Marked USB event source (handle: 12, events: 4) as removed at index 5 2014-03-22 23:56:50.266931 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 5, device: : LIBUSB_ERROR_NO_DEVICE (-4) 2014-03-22 23:56:50.270689 <D> <event|event.c:165> Marked USB event source (handle: 9, events: 1) as removed at index 3 2014-03-22 23:56:50.270759 <D> <event|event.c:165> Marked USB event source (handle: 11, events: 1) as removed at index 4 2014-03-22 23:56:50.270834 <W> <usb|usb.c:134> Ignoring USB device (bus: 5, device: due to an error 2014-03-22 23:56:50.271172 <D> <hotplug|udev.c:273> Initializing udev subsystem 2014-03-22 23:56:50.271205 <D> <hotplug|udev.c:167> Trying to load libudev.so.1 2014-03-22 23:56:50.271569 <D> <hotplug|udev.c:172> Could not load libudev.so.1: libudev.so.1: cannot open shared object file: No such file or directory 2014-03-22 23:56:50.271606 <D> <hotplug|udev.c:173> Trying to load libudev.so.0 instead 2014-03-22 23:56:50.272067 <D> <hotplug|udev.c:189> Successfully loaded libudev.so.0 2014-03-22 23:56:50.272360 <D> <event|event.c:139> Added generic event source (handle: 9, events: 1) at index 6 2014-03-22 23:56:50.272402 <D> <network|network.c:120> Initializing network subsystem 2014-03-22 23:56:50.272514 <D> <network|network.c:205> Started listening to '0.0.0.0' (IPv4) on port 4223 2014-03-22 23:56:50.272551 <D> <event|event.c:139> Added generic event source (handle: 10, events: 1) at index 7 2014-03-22 23:56:50.272583 <D> <event|event.c:213> Starting the event loop 2014-03-22 23:56:50.272609 <D> <event|event.c:189> Removed USB event source (handle: 12, events: 4) at index 5 2014-03-22 23:56:50.272639 <D> <event|event.c:189> Removed USB event source (handle: 11, events: 1) at index 4 2014-03-22 23:56:50.272667 <D> <event|event.c:189> Removed USB event source (handle: 9, events: 1) at index 3 2014-03-22 23:56:50.272694 <D> <event|event_posix.c:207> Starting to poll on 5 event source(s) 2014-03-22 23:56:50.294261 <D> <event|event_posix.c:227> Poll returned 1 event source(s) as ready 2014-03-22 23:56:50.294360 <D> <event|event_posix.c:253> Handling generic event source (handle: 9, received events: 1) at index 3 2014-03-22 23:56:50.294593 <D> <hotplug|udev.c:257> Received udev event (action: remove, dev node: /dev/bus/usb/005/008, sys name: 5-1) 2014-03-22 23:56:50.297523 <D> <event|event_posix.c:268> Handled all ready event sources 2014-03-22 23:56:50.297573 <D> <event|event_posix.c:207> Starting to poll on 5 event source(s) Der "Could not get product string descriptor"-Fehler führt zu einem "Ignoring USB device" und der brickv zeigt bei einem "Connect" deshalb nur: "Please check host, check port and check if the Brick Daemon is running" Vielleicht sollte ich nochmals eine (andere) Masterbrick-Firmware flashen... (Eigentlich besteht aber doch kein Zusammenhang zwischen einem USB product string descriptor und DHCP, oder?) Gute Nacht, Martin
  12. Hallo, leider habe ich nun ein Problem, das Firmware Update zu installieren. Wie in http://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing angegeben, habe ich versucht den Master-Brick in den Bootloader Modus zu versetzen, indem ich den Erase- und anschließend den Reset-Knopf gedückt habe. (Wo sich diese Knöpfe befinden ist unter http://www.tinkerforge.com/de/doc/Hardware/Bricks/Master_Brick.html#anschlussmoglichkeit abgebildet.) Im brickv wird nun unter Updates/Flashing|Brick auch nach einem "Refresh" keinen "Serial Port" angezeigt. ("No Brick in Bootloader found") Anscheinend gibt es nun Probleme mit dem USB (obwohl ich vorher keine Probleme hatte). Das zeigt sich mit dmesg bei mehreren Rechnern: OpenSUSE 13.1: [30007.682714] usb 1-1.5.5: new full-speed USB device number 18 using ehci-pci [30022.751541] usb 1-1.5.5: device descriptor read/64, error -110 [30037.921395] usb 1-1.5.5: device descriptor read/64, error -110 [30038.084486] usb 1-1.5.5: new full-speed USB device number 19 using ehci-pci [30053.153476] usb 1-1.5.5: device descriptor read/64, error -110 [30068.323368] usb 1-1.5.5: device descriptor read/64, error -110 [30068.486595] usb 1-1.5.5: new full-speed USB device number 20 using ehci-pci [30078.893114] usb 1-1.5.5: device not accepting address 20, error -110 [30078.955169] usb 1-1.5.5: new full-speed USB device number 21 using ehci-pci [30089.361898] usb 1-1.5.5: device not accepting address 21, error -110 [30089.362059] hub 1-1.5:1.0: unable to enumerate USB device on port 5 Ubuntu 12.04.4 LTS: [ 9006.015191] usb 5-1: new full-speed USB device number 2 using xhci_hcd [ 9006.059482] usb 5-1: Device not responding to set address. [ 9006.266562] usb 5-1: Device not responding to set address. [ 9006.467229] usb 5-1: device not accepting address 2, error -71 [ 9006.635300] usb 5-1: new full-speed USB device number 3 using xhci_hcd [ 9006.655751] usb 5-1: Device not responding to set address. [ 9006.862830] usb 5-1: Device not responding to set address. [ 9007.063310] usb 5-1: device not accepting address 3, error -71 [ 9007.231364] usb 5-1: new full-speed USB device number 4 using xhci_hcd [ 9007.251939] usb 5-1: Device not responding to set address. [ 9007.459032] usb 5-1: Device not responding to set address. [ 9007.663402] usb 5-1: device not accepting address 4, error -71 [ 9007.831453] usb 5-1: new full-speed USB device number 5 using xhci_hcd [ 9007.846136] usb 5-1: Device not responding to set address. [ 9008.051226] usb 5-1: Device not responding to set address. [ 9008.255521] usb 5-1: device not accepting address 5, error -71 [ 9008.255591] hub 5-0:1.0: unable to enumerate USB device on port 1 Raspbian (Debian 7.4): [ 2835.402012] usb 1-1.3: new full-speed USB device number 9 using dwc_otg [ 2850.482436] usb 1-1.3: device descriptor read/64, error -110 [ 2865.672883] usb 1-1.3: device descriptor read/64, error -110 [ 2865.862914] usb 1-1.3: new full-speed USB device number 10 using dwc_otg [ 2880.943493] usb 1-1.3: device descriptor read/64, error -110 [ 2896.134035] usb 1-1.3: device descriptor read/64, error -110 [ 2896.323956] usb 1-1.3: new full-speed USB device number 11 using dwc_otg [ 2906.744050] usb 1-1.3: device not accepting address 11, error -110 [ 2906.824229] usb 1-1.3: new full-speed USB device number 12 using dwc_otg [ 2917.244408] usb 1-1.3: device not accepting address 12, error -110 [ 2917.244641] hub 1-1:1.0: unable to enumerate USB device on port 3 Das ist jetzt zwar etwas "off topic", aber kann mir jemand einen Tipp geben, wie man so ein Firmware Update durchführt? Jetzt funktioniert gar nichts mehr :-( Danke, Martin
  13. Mir ist klar, dass die Abfrage nach dem Sonderfall "alle Zeichen sind belegt" benötigt wird. Bei einem System, welches etwas mehr Speicher besitzt würde man aber vermutlich einfach ETHERNET_HOSTNAME_LENGTH+1 statt 32 in ethernet.h:47 verwenden und im letzte Byte einfach immer eine Null speichern. Man verschwendet so ein Byte, entledigt sich aber dieses Sonderfalls. Bei einem Brick ist das natürlich etwas anderes! Es ist aber schon seltsam, wie fehlerresistent die getesteten DHCP Server sind. Da schickt man denen ein Paket, welches sie am Ende vermutlich nicht mehr lesen können (dhcpParamRequest und folgende) und mit den schon geparsten Daten wird einfach eine Adresse vergeben... Jedenfalls schon einmal im Voraus Danke für das zu erwartende Update! (Aber jeder Fix birgt auch die Gefahr einen neuen Fehler einzubauen...) Gute Nacht, Martin
  14. Hallo nochmals, zunächst einmal möchte ich anmerken, dass der DCHP Broadcast aus meiner ersten Email direkt vom Masterbrick bzw. der Ethernet Extension gesendet wurde, der DHCP Server noch nicht in Aktion war und somit keine Rolle spielt! Betrachtet man nochmals das Paket (592 Byte Länge) so sieht das Bootstrap Protocol anfangs noch gut aus. Es fällt auf, dass beim Hostname Option: (t=12,l=32) Host Name = "TinkerforgeXXXXXX" die Länge mit 32 (statt 17) übermittelt wird! Die restlichen 15 Byte sind mit 0 aufgefüllt. Nach https://www.ietf.org/rfc/rfc1533 Abschnitt 3.14 gelten Restriktionen für die Zeichenwahl laut https://www.ietf.org/rfc/rfc1035 für den Hostname. Insofern stellt sich schon einmal die Frage, ob das so überhaupt standardkonform ist? Betrachten wir doch einfach einmal den Sourcecode, der ja glücklicherweise online zu finden ist. Zunächst einmal findet sich die Länge des Hostnames im brickv ====== https://github.com/Tinkerforge/brickv/archive/v2.0.9.zip brickv-2.0.9/src/brickv/plugin_system/plugins/master/ui/ethernet.ui: 47 <item> 48 <widget class="QLineEdit" name="ethernet_hostname"> 49 <property name="sizePolicy"> 50 <sizepolicy hsizetype="Minimum" vsizetype="Fixed"> 51 <horstretch>0</horstretch> 52 <verstretch>0</verstretch> 53 </sizepolicy> 54 </property> 55 <property name="toolTip"> 56 <string>Up to 15 chars, leave empty for default</string> 57 </property> 58 <property name="maxLength"> 59 <number>32</number> 60 </property> 61 </widget> 62 </item> wobei der Tooltip (Zeile 56) zwar angibt, dass max. 15 Zeichen für den Hostname zur Verfügung stehen, in Zeile 59 werden aber 32 Zeichen zugelassen. (Die 32 Zeichen stammen vermutlich nicht aus der RFC1533, sind eine Beschränkung mit der man sicher leben kann.) Im master-brick ============ https://github.com/Tinkerforge/master-brick/archive/v2.1.2.zip master-brick-2.1.2/software/src/extensions/ethernet/ethernet.h 40 typedef struct { 41 uint8_t mac_address[6]; 42 uint8_t ip[4]; 43 uint8_t subnet_mask[4]; 44 uint8_t gateway[4]; 45 uint32_t rx_count; 46 uint32_t tx_count; 47 char hostname[32]; 48 } __attribute__((__packed__)) EthernetStatus; scheint der hostname nun ohne die in C übliche Kennung des Endes einer Zeichenkette (0) gespeichert zu werden, denn sonst würde man eine Länge von 33 Zeichen erwarten. Die 32 Zeichen Länge werden übrigens nochmals unter ethernet_config.h:33: #define ETHERNET_HOSTNAME_LENGTH 32 definiert. Initialisiert wird der hostname zunächst einmal mit "TBD" ethernet.h:29: #define ETHERNET_STATUS_DEFAULT {{0x40, 0xD8, 0x55, 0x02, 0xA0, 0x00}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, 0, 0, "TBD"} ethernet.c:48:EthernetStatus ethernet_status = ETHERNET_STATUS_DEFAULT; und wird in ethernet_low_level_init() dann gesetzt: ethernet_low_level.c:76: memcpy(ethernet_status.hostname, ec.hostname, ETHERNET_HOSTNAME_LENGTH); Ob eine Zeichenkette <32 Zeichen nun mit einer 0 endet kann ich gerade auf die Schnelle nicht nachvollziehen. (In ethernet_low_level_get_default_hostname sehe ich das z.B. nicht.) Interessant ist nun die folgende Stelle: master-brick-2.1.2/software/src/extensions/ethernet/ethernet_dhcp.c: 143 // Host name 144 dhcp_message.OPT[i++] = hostName; 145 uint8_t hostname_length = ETHERNET_HOSTNAME_LENGTH; 146 if(ethernet_status.hostname[ETHERNET_HOSTNAME_LENGTH-1] != '\0') { 147 hostname_length = strlen(ethernet_status.hostname); 148 } 149 dhcp_message.OPT[i++] = hostname_length; 150 memcpy((char*)&(dhcp_message.OPT), ethernet_status.hostname, hostname_length); 151 152 i += hostname_length; 153 154 dhcp_message.OPT[i++] = int_to_char(ethernet_status.mac_address[5] % 16); 155 156 dhcp_message.OPT[i++] = dhcpParamRequest; In der dhcp_send_discover Funktion (von dhcp_get_ip() und dhcp_check_timeout() aufgerufen) wird ab Zeile 145 die Länge des Hostnames bestimmt, wobei diese zunächst auf 32 gesetzt wird. Die Zeile 146 scheint mir unsinnig! Steht am Ende eine 0 wird das auch durch den strlen-Befehl detektiert, falls nicht schon vorher eine 0 zu finden ist. Bei einer Zeichenkette mit Länge <32 sollte doch vermutlich eine 0 im Speicher stehen, oder? Das sollte wohl eher "==" statt "!=" heissen! Falls alle 32 Zeichen verwendet werden und kein Platz mehr für eine 0 ist, so ist die Länge 32. Mit einem "==" könnte man das folgendermaßen beschreiben: Nur falls man am Ende noch eine 0 findet, wird die Länge der Zeichenkette ermittelt. (Man sollte übrigens auch Zeile 240 überprüfen.) Und was macht Zeilt 154? Hier sollte ein neuer Optionscode kommen und dann dieser seltsame aus der MAC Adresse generierte Wert "5"... Option: (t=53,l=55) DHCP Message Type length isn't 1 Padding (205 bytes) "5"=53 steht nun für "DHCP Message Type" und erwartet eine 1 als nächsten Wert, da es nur einen Parameter gibt. Es folgt aber 55 für den dhcpParamRequest Optionscode und alles ist "verschoben"... Das war das eigentliche Problem in den DHCP discovery Paketen hier. Und deshalb würde ich die 154 zumindest einmal auskommentieren... Auch wenn der eine oder andere DHCP Server trotzdem antwortet, so sind diese Pakete hier nicht standardkonform. Das scheint mir ein bug zu sein! Eigentlich wollte ich fragen, ob das bei anderen wirklich funktioniert, aber anscheinend gibt es ja nicht nur bei mir Probleme. Ich bin am überlegen, ob ich versuche das zu fixen und einen Patch zu erstellen. Aber evtl. wird das ja sowieso gerade gemacht... Martin
  15. Hallo, ein Wetterstation-Starterkit mit einem Master Brick 2.0, (FW Version 2.1.2) wurde durch eine Ethernet Master Extension (mit PoE) erweitert. Mit einer "Static IP" Connection funktioniert das problemlos. Beim Wechsel zu "DHCP" wird hier nun aber anscheinend keine IP Adresse zugewiesen. Der DHCP Server (eines Routers) zeigt leider keine Log-Einträge. wireshark erfasst für die eingestellte MAC Adresse sich wiederholende DHCP NAK Pakete von Source 0.0.0.0 nach Destination 255.255.255.255 mit dem Bootstrap Protocol: Message type: Boot Request (1) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x12345678 Seconds elapsed: 0 Bootp flags: 0x8000 (Broadcast) Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0 (0.0.0.0) Client MAC address: XX:XX:XX:XX:XX:XX (XX:XX:XX:XX:XX:XX) Client hardware address padding: 00000000000000000000 Server host name not given Boot file name not given Magic cookie: DHCP Option: (t=53,l=1) DHCP Message Type = DHCP Discover Option: (t=61,l=7) Client identifier Option: (t=12,l=32) Host Name = "TinkerforgeXXXXXX" Option: (t=53,l=55) DHCP Message Type length isn't 1 Padding (205 bytes) [Expert Info (Error/Protocol): End option missing] Laut https://www.ietf.org/rfc/rfc2132 Abschnitt 3.2 ist die "End option" eine "Vendor Extension" mit einem Oktett Länge und Wert 255 und findet sich wirklich nicht in den Paketen. Die Fehlermeldung könnte natürlich auch irreführend sein. Ein DHCP NAK (DHCP-Not Acknowledged), also eine Ablehnung einer DHCPREQUEST-Anforderung durch den DHCP-Server erwartet man z.B., falls ein Client eine Adresse anfordert, die es im lokalen Subnetz (hier 192.168.0.0/24) nicht gibt oder die anderweitig vergeben ist. Das kann ich hier aber gerade nicht nachvollziehen. Ist jemand schon einmal auf ein ähnliches DHCP-Problem gestossen und hat evtl. sogar einen Tipp für eine Lösung? (Wie bekommt die Tinkerforge Ethernet Master Extension doch noch seine IP-Adresse?) Danke, Martin
  16. Bestehenden Einplatinencomputer können teilweise auch erweitert werden... Beim BeagleBone Black (http://beagleboard.org/Products/BeagleBone%20Black) werden Erweiterungsplatinen z.B. als "Capes" bezeichnet (http://elinux.org/Beagleboard:BeagleBone_Capes, http://elinux.org/Beagleboard:BeagleBone_Black_Capes) Für die Cubieboards (http://cubieboard.org/) sind anscheinend ebenfalls Erweitungsplatinen (http://docs.cubieboard.org/expander_boards) angedacht und die Wandboards (http://wandboard.org/) bieten wohl einen "EDM standard connector" (EDM=Embedded Design Module, s. z.B. http://www.edm-standard.org/) Der Raspberry Pi hat da sicher auch Möglichkeiten. Und es gibt da natürlich noch viele viele weitere Einplatinencomputer... (s. z.B. http://en.wikipedia.org/wiki/List_of_single_board_computers http://en.wikipedia.org/wiki/Comparison_of_single-board_computers) Für ein geeignetes Board hätte man doch vermutlich auch eine TinkerForge-Erweiterung entwickeln können, oder? Doch welches Board wäre hier ein möglicher Kandidat gewesen? Die Schnittstelle muss ausreichende Möglichkeiten besitzen und wenn man so eine Erweiterung auch mit der jeweils nächsten Generation eines Boards weiterverwenden oder zumindest einfach anpassen kann, wäre das sicher von Vorteil. Das Beagleboard Black (BBB) und die Cubieboards haben z.B. bereits flash storage on-board auf dem man z.B. Teile des Betriebssystems ablegen kann. Im Gegensatz zum Raspberry Pi liefern manche Boards eine batteriegepufferte Uhr, so dass z.B. auch ohne Netzwerkanbindung und NTP-Client eine Speicherung von Sensordaten mit Uhrzeitstempel möglich ist. Mit laut Wikipedia "mehr als 2 Millionen Geräte" wird der Raspberry Pi vermutlich die größten Stückzahlen aufweisen können und die 127450 boards des BBB (http://elinux.org/Beagleboard:BeagleBoneBlack#Board_Shipments) sind da vergleichsweise recht bescheiden. Welche Stückzahlen werden für das RED erwartet? All diese Boards sind aber immerhin schon am Markt. Es sind hier mehrere Preisklassen auszumachen, wobei der Raspberry Pi und der BBB bei den oben erwähnten das untere Ende ausmachen, aber sicher auch weniger Leistung bieten. (Aber immer noch deutlich mehr als z.B. ein "klassischer" Arduino.) Interessant finde ich auch die Frage, welche Boards und Features denn bisher mit TinkerForge verwendet wurden bzw. werden. Mir scheint es wird recht oft der Raspberry Pi genannt und demnach auch eingesetzt. (s. z.B. http://www.tinkerforge.com/en/doc/index.html#embedded-boards) Warum gerade dieses Board so erfolgreich ist? Evtl. die relativ frühe Verfügbarkeit und der relativ niedrige Preis, was zu größeren Stückzahlen und einer großen "Community" geführt hat. Ich selbst habe mir auch einen gekauft und dann später noch einen geschenkt bekommen, bin aber nicht so 100%ig zufrieden und kann somit nicht so recht nachvollziehen warum sich ausgerechnet dieses Board so großer Beliebtheit erfreut. All diese Boards sind nicht speziell für TinkerForge entwickelt und so sind manche Features evtl. nicht nötig. Die GPIO Möglichkeiten des Raspberry Pi habe ich z.B. für TinkerForge Projekte noch nicht eingesetzt, wobei das eigentlich noch ganz gut in diesen Anwendungsbereich passt. Und so wird es bei vielen Features doch den einen oder anderen geben, der das dann doch braucht. Je nach Bedarf kann man aber ja das zum Projekt passende Board einsetzen und das wird sicher auch mit der Verfügbarkeit des RED noch möglich sein... Denn selbst für TinkerForge Projekte sind die Anforderungen doch sicher teilweise recht unterschiedlich. Der Stromverbrauch ist z.B. immer wichtig, wird aber für eine fest an die Wand montierte Wetterstation mit direktem Stromanschluß sicher nicht ganz so kritisch sein wie bei einem Fluggerät, welches keine allzu schweren Akkus befördern kann und auf eine ausreichend lange Flugdauer kommen möchte. Die nötige CPU-Leistung ist im Fall eines Fahrroboters, der eine schwarze Linie verfolgt sicher geringer als bei einem fußballspielenden Roboter, der sich per Bilderkennung selbst orientiert und auch einen Doppelpass mit einem Mitspieler ausführen soll. Welchen Bereich kann hier der RED abdecken? Auch die Größe der Boards kann ein Entscheidungskriterium sein und hier ist der RED sicher im Vorteil, denn die o.g. Boards sind alle etwas größer. Für all die oben erwähnten Boards sind noch Weiterentwicklung zu erwarten. Welche Update-Zyklen sind für das RED vorgesehen? Das RED Brick passt wirklich 100% zum TinkerForge Konzept und das ist sein Stärke! Der Aufwand könnte allerdings recht hoch werden und sich nicht auf die Entwicklung beschränkt. Ein Repository z.B. für Raspbian ist mir bisher nicht bekannt. Das wäre einfacher, als die TinkerForge Bibliotheken per Hand oder den Boardmitteln der Programmiersprachen zu installieren. Beim RED soll ja aber alles anscheinend recht einfach werden. Gibt es da dann einen Paket-Mechanismus wie bei Linux üblich? Die meisten Programmiersprachen können z.B. durch zusätzliche Bibliotheken im Funktionsumfang erweitert werden und diese zusätzlichen Bibliotheken müssen ja installiert werden. Ein WWW-Server und NTP-Client wird vermutlich schon vorinstalliert sein. Wie sieht es aber z.B. mit einem NFS-Client aus? usw. Wie lange wird die "Distribution" gewartet? (Long Term Support?) Wie geht man mit Sicherheitsupdates um? Die Geräte sind ja schließlich teilweise am Netz und gerade das allseits beliebte WLAN kann schlecht über andere Geräte abgesichert werden. Bei den Einplatinencomputer wird das von der entsprechenden "Community" übernommen, beim RED Brick sollte das dann ja TinkerForge übernehmen... Gute Nacht, Martin
  17. Martin

    Pegelsonde?

    Hallo, der hydrostatische Druck in einem Flüssigkeitsbehälter nimmt mit der Tiefe linear zu und entspricht der Summe der Gewichtskraft der Flüssigkeitssäule pro Fläche und des atmosphärischen Drucks auf die Oberfläche. Die Wichte einer Flüssigkeit (bzw. Dichte und Erdbeschleunigung) ist oft bekannt und wird noch leicht durch die Temperatur beeinflusst. Das kann zur Bestimmung der Tiefe (Pegel-/Füllstandsmessung) genutzt werden. Ein Beispiel hierfür wäre ein Öltankanzeiger, wie z.B. http://tecson.de/lx-net_details.html Als Sensor kommt hier eine Pegelsonde, s. http://tecson.de/pegelsonden.html zum Einsatz, die am Boden des Behälters platziert wird. (zu Pegelsonden s. z.B. auch http://www.drucksensor-knowhow.de/blog/2013/03/08/aufbau-einer-pegelsonde-tauchsonde/ + http://www.drucksensor-knowhow.de/blog/2013/03/19/der-aufbau-einer-pegelsonde-tauchsonde-teil-2/) Während bei einer Öltank-Füllstandmessung vermutlich nur zertifizierte Lösungen zum Einsatz kommen dürfen, so ist die Nutzung von Tauchsonden in Wasser (z.B Zisterne) vermutlich auch bei einer Bastellösung unproblematisch. Die TinkerForge Wetterstation bietet schon ein Gehäuse mit einer LCD-Anzeige und einem Barometer. Die Temperatur der Flüssigkeit könnte bei Bedarf vielleicht über ein Temperatur IR Bricklet gemessen werden. Wie sieht es aber in Bezug auf einen Sensor zur Messung des hydrostatischen Drucks am Grund in Form einer Kabelsonde aus? Ein entsprechendes Bricklet scheint es (noch) nicht zu geben. Hat evtl. schon jemand Erfahrungen mit der Realisierung einer solchen Messapparatur mit TinkerForge Hardware gemacht? Kann eine Pegelsonde z.B. einfach an ein Analog In Bricklet angeschlossen werden? Welche sind geeignet und wo zu kaufen? Was ist zu beachten? Laut http://www.drucksensor-knowhow.de/blog/2013/12/19/erdung-von-hydrostatischen-fuellstandssensoren-und-pegelsonden/ sollte man den Füllstandssensor z.B. sachgemäß erden. Danke, Martin
  18. Hallo, die Standardvariante der Wetterstation misst unter anderem die Temperatur und die relative Luftfeuchtigkeit. Mit diesen Werten kann die Taupunkttemperatur berechnet werden, s. z.B. http://de.wikipedia.org/wiki/Taupunkt#Abh.C3.A4ngigkeit_der_Taupunkttemperatur_von_relativer_Luftfeuchtigkeit_und_Lufttemperatur Formel (15) Bei schlecht isolierten Fenstern und Wänden ist z.B. im Winter bei kalten Aussentemperaturen auch die Oberflächentemperaturen innen relativ kalt. Bei feucht-warmen Innenklima kann dann evtl. Wasser kondensieren falls die Oberflächentemperatur innen unter dem Taupunkt liegt. Das kann wiederum auf Dauer zur Schimmelbildung führen. Mit dem Temperature IR Bricklet (https://www.tinkerforge.com/de/shop/bricklets/temperature-ir-bricklet.html) kann man nun die Oberflächentemperatur einer Wand oder eines Fensters messen. Das könnte man als Erweiterung der Wetterstation unter http://www.tinkerforge.com/de/doc/Kits/WeatherStation/WeatherStation.html#konstruktion aufführen. Das Gehäuse der Wetterstation könnte mit entsprechenden Bohrungen dem Bricklet Befestigungspunkte und freien Zugang für den Sensor zur Wand bieten. Hierzu muss die Wetterstation allerdings auch an einer Aussenwand befestigt werden. Wesentlich flexibler und besser ist es meiner Meinung nach aber ein separates Gehäuse zu nutzen, da die interessanten Stellen die Wärmebrücken sind, also z.B. Ecken (geometrische Wärmebrücken) oder Fenster (mit meist kleinerem Wärmedurchgangswiderstand als bei der benachbarten Wand). Betrachtet man aber das Gehäuse unter https://www.tinkerforge.com/de/shop/case-temperature-ir-bricklet.html so ist nicht klar erkennbar, ob es sich für eine Befestigung an einer Wand (Bohrungen für Schrauben und Dübel vorhanden?) oder an einem Fenster (Saugnäpfe?) eignet. Falls im Gehäuse noch Platz für ein Temperaturbricklet wäre, könnte man auch noch die Temperatur direkt an der Wärmebrücke messen. Bricklet-Kabel scheint es bis 2m Länge zu geben. Mit einem zusätzlichen Master-Brick und WLAN-Master-Extension ist man noch ungebundener, aber die beiden Teile passen sicher nicht auch noch in dieses Gehäuse. Bei kritischen Werten könnte ein Alarm zur Stoßlüftung ausgelöst werden... Vermutlich gibt es hier aber noch einen Haken, denn sonst hätte das Tinkerforge das sicher schon als "Erweiterungsprojekt" aufgeführt. Gibt es hier also schon (evtl. negative) Erfahrungen? Danke und gute Nacht, Martin
  19. Hallo, Das RED Brick benötigt doch im Grunde eine TinkerForge Linux-Distribution, deren Wartung mit einigem Aufwand verbunden ist. Programme benötigen oft noch weitere externe Bibliotheken. Ich habe z.B. gerade angefangen die Python Wetterstation-Beispielapplikation mit SQLAlchemy (http://www.sqlalchemy.org/) zu erweitern, um die Daten in einer Datenbank zu speichern. Diese Bibliothek würde ich dann z.B. auch gerne in einem TF-Repository wiederfinden. Mit dem Raspberry Pi, den ich aktuell zur Ansteuerung verwende bin ich allerdings unzufrieden. Nach wenigen Tagen Datensammeln gab es bei mir schon Stabilitätsprobleme (unvollständig geschriebene Daten, SSD korrupt). Da sind vermutlich Software-Bugs im Spiel, aber ich überlege trotzdem evtl. auf eine Alternative, wie z.B. einen Wandboard Quad (http://www.wandboard.org/) oder eben einen RED Brick umzusteigen, die dann aber wohl teurer kommt. (Ein Arbeitskollege hat sich längere Zeit mit Serverraum-Monitoring Raspberries herumgeärgert und diese nun z.B. erfolgreich durch Cubietrucks (http://cubieboard.org/) ersetzt.) Auch die Grenzen der Leistungsfähigkeit scheint beim RaspPi schnell erreicht zu sein und so habe ich die Befürchtung, dass Boards der unteren Preisklasse wie z.B. das BeagleBoneBlack (http://beagleboard.org/products/beaglebone%20black) ebenfalls schnell überfordert sind. Es ist zwar besser, die eigene Software zu optimieren, aber auch bequem Leistungsreserven zu haben. Ein wichtiges Kriterium wäre für mich also auf jeden Fall die Stabilität und Leistungsfähigkeit der Hardware (inkl.Treiber)! Die Stückzahlen einer Speziallösung liegen aber sicherlich deutlich unter denen von Raspberry Pi & Co. und das wirkt sich vermutlich auf den Preis aus. Dennoch würde der RED Brick gut in das TinkerForge Sortiment passen, auch wenn sich das TF-Team hier meiner Meinung nach deutlich mehr Arbeit aufhalst als bei den übrigen Bricks. Und so ist es vielleicht dennoch klüger auf bestehende (möglichst "offene") Boards mit vorhandenen Linuxdistributionen aufzubauen und den Repositories TinkerForge-Pakete beizusteuern. P.S.: TinkerForge-deb-Pakete für Raspbian und anderen Linux-Distributionen (auch rpm) wären bequemer zu installieren und würden die Sichtbarkeit erhöhen. (http://www.raspberryconnect.com/raspbian-packages-list/item/62-raspbian-electronics zeigt z.B. (noch) keine TinkerForge Einträge.) Aber wie gesagt - ich bin mir nicht sicher, ob der Raspberry Pi wirklich das beste Board ist. Auch wenn das natürlich auf den Anwendungsfall ankommt...
×
×
  • Neu erstellen...