Martin

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

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

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

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

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

Hallo Theo, das ging ja schnell. Der Snapshot vom 20. Juni spätabends scheint bei mir zu funktionieren. Vielen Dank!!! Martin

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

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

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

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

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

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

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

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

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