Martin
-
Gesamte Inhalte
19 -
Benutzer seit
-
Letzter Besuch
Posts erstellt von 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,
Vor dem Release hab ich mich noch mal richtig reingehängt und weitere Bricklets eingebunden. Neu gibt es Unterstützung für Bricklet Segment Display 4x7, Bricklet Digital Out 4, Bricklet Hall Effect, Bricklet IO-4 und was das allerbeste ist: Bricklet LED Strip.
Die vorläufige Beschreibung der Konfiguration findet ihr wieder hier:
https://github.com/theoweiss/openhab/wiki
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 error2014-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
-
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
-
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?
sollte man den Füllstandssensor z.B. sachgemäß erden.
Danke,
Martin
-
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.
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
-
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...
Betaversion der openHAB-Bindings
in Allgemeine Diskussionen
Geschrieben
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