Nitram

@ArcaneDraconum grundsätzlich stimme ich dir zu, dass die Implementierung jedes noch so kleinen Features kosten produziert die am Ende ggf. quer Finanziert werden. Dennoch sollte man auch bedenken, das gerade der gewerbliche Einsatz, der mit dem modularen Konzept durchaus machbar ist, auch den Vorteil großer Abnahmemengen bringen kann. Wenn jedoch im Vorfeld direkt gesagt wird, dass das Ziel nur Private Abnehmer in kleinen Stückzahlen ohne große Anforderungen ist, dann frage ich mich für was es "Reseller" Preislisten gibt. (http://www.tinkerforge.com/reseller_conditions) Wir nutzen das hier für Entwicklungen im gewerblichen Umfeld, weil wir mit der Tinkerforge Lösung erheblich schneller und kostengünstiger Entwickeln können, als mit herkömmlichen Bauteilen. Aufgrund der meist individuellen Entwicklungen, lohnt der Aufwand eigener Boards und Co für uns nicht. Für uns sind ein paar Zukunftsaussichten wichtig, da sonst TF als Basis dafür schlichtweg nicht geeignet wäre. Ich denke das dies anderen potenziellen gewerblichen Abnehmern ähnlich geht. @IPv6 - Wenn das Modul das nicht kann ist das halt schade aber genau deshalb hatte ich es angesprochen. Insofern es (und da kenn ich leider gar keine) ein Modul mit IPv6 gäbe, wäre dies schon schöner.

jo, sag ja NAT+Translation im Heimnetz wirds geben, die Sache ist nur bei Hardware oft etwas limitiert und wenn man mit IPv4 plant und keinen freien Speicher für deutlich größere IPv6 mehr hat, dann kann man schlichtweg nicht auf den Zug springen, weshalb es von vornherein geplant sein sollte. Geplant bedeutet ja nicht umgesetzt, lediglich die Möglichkeit vorgehalten.

IPv6 ist eigentlich pflicht Program, da man sonst in den nächsten Jahren erst anfängt etwas zu entwickeln, dass eigentlich schon Standard sein müsste. Selbst die großen ISPs kommen langsam auf den Trichter das man IPv6 braucht, und sobald der erste große ISP (z.B. Telekom) auf IPv6 umstellt, werden alle anderen und super viele Webseiten etc. nachziehen müssen. Wenn mann dann nicht schon passendes Know-How in dem Bereich gesammelt hat, beginnt die Suche nach dem Schuldigen im Unternehmen . Ansich ist IPv6 im Heimbedarf ziemlich wurst. Der private Adressraum kann nicht überfüllt sein, da hinter jedem NAT ein neuer beginnt. Jedoch wäre es einfacher wenn alles einheitlich und gleich ist, dazu müssen einfach alle Netzwerkgeräte IPv6 können. Zugleich hohlt man sich mit IPv6 einige Sicherheitsprobleme ins Haus, die bislang wenig bis kaum gelöst wurden. Beispielsweise gerade das NAT das im IPv4 Bereich stark verbreitet ist sollte im IPv6 bereich weniger stark bis gar nicht genutzt werden (so die "experten"). Gleichzeitig bietet NAT jedoch eine gute Basis-Sicherheit für Netzwerke und damit auch für Geräte wie den Brick. Ich fände es schon wichtig wenn TF bei allen Geräten IPv6 direkt dazu plant, da in meiner Firma dies bereits seit 2 Jahren der Standard ist. Wer IPv6 kann, hat keine Nachteile, wer nur IPv4 kann verliert. Wäre also schön wenn TF Zukunftsorientiert entwickelt! Danke für das tolle Produkt

Hallo, nachdem ich selbst ein paar Probleme mit einem gelieferten IO16 Bricklet hatte, möchte ich das gerne zur Hilfe für etwaige ebenfalls in diese Probleme laufenden hier posten. Geliefert wurde mir sehr schnell ein Master Brick, 1 Dual Relay und 2 IO16 Bricklets. Begeistert davon habe ich direkt alles angeschlossen und dann den BrickD und BrickV installiert. Was sich jedoch zeigte war nichts . Um dem Problem auf die Spur zu kommen, habe ich nochmal alles abgesteckt und nur den Master angeschlossen. Resultat, dieser funktionierte und wurde auch korrekt im BrickViewer angezeigt. Nachdem ich nun einzeln die Bricklets angeschlossen hatte, konnte ich einen der beiden IO16 als "defekt" für mich erkennen. Sobald ich diesen IO16 an dem Master angeschlossen hatte, wurde weder Master noch Bricklet im BrickV gefunden. Auch die tolle LED Animation auf dem Master kam nicht mehr. Da es sicherlich auch DoA (dead on arrival) bei Tinkerforge geben kann, hatte ich eine kurze Mail mit dieser Beschreibung verschickt. Nach mehrmaligem Hin und Her des überaus freundlichen Supports von Bastian N. stellte ich dann bei Ausführung seiner Beschreibung ein Problem im BrickV fest. Ich setze Ubuntu 11.04 ein und dort liegt der Desktop im Verzeichnis /home/martin/Arbeitsfläche. Dort hatte ich die für den Flash des IO16 Bricklet benötigte Firmware abgelegt. Leider scheint in der aktuellen BrickV jedoch ein Bug zu existieren, der es unmöglich macht ein Bricklet aus Ordnern mit Zeichen wie äöü zu Flashen. Es gibt keine Fehlermeldung und nichts was darauf hinweist. Zu erkennen ist dies daran, das eben gar nichts passiert wenn man auf Save klickt. Die Lösung war also erst den Master Brick anzustecken, dann den "defekten" IO16 der nicht im BrickV zu sehen war anzuhängen. Nun den Brick mittels Advanced Functions flashen und dabei schlichtweg die Datei in einem "schönen" Ordner zu legen. Obwohl dennoch "Check failed" als Resultat aufpoppte, startet und funktioniert nun das IO16 korrekt. Sollte also jemand die selben Probleme haben, hoffe ich dass diese Information weiter hilft und das es ggf. ein Update an BrickV gibt das eben auch Sonderzeichen möglich sind. Danke an den Support von Bastian und weiterhin gutes gelingen. Macht weiter so, ich freu mich auf das Ethernet Brick mit PoE! Grüße Martin

Abhängig vom geplanten Einsatzzweck lässt sich ein längerer Callback auch mittels pcntl_fork() auslagern. Dazu gibt es ein paar einfache Klassen die öffentlich verfügbar sind, die den Aufwand zur Verwaltung erheblich reduzieren. Die Frage ist schlicht was genau notwendige Arbeiten bzw. wie stark der Informationsaustausch zwischen den Prozessen dann wird, da dies schon eine Menge zusätzlichen Codes bedarf. Auf nachfolgendem Link ist dazu ein Beispiel zu finden: http://blog.motane.lu/2009/01/02/multithreading-in-php/

Hallo, ja, das hat geholfen, nachdem ich den IO16 geupdated habe, funktioniert nun auch io.get_port() hätte ich auch ma selbst machen können Dankeschön Grüße Martin

Hi, ja wenn ich die eine Zeile rausmach dann geht es, aber sobald ich die io.get_port('a') rein setz, gehts nicht mehr. Da die IP Connection ansich funktioniert und alle anderen Funktion ebenfalls, sieht es für mich nach einem Problem speziell von dieser python Funktion aus. Da ich aber bis gestern kein bischen mit Python gemacht habe, bin ich mir da nicht ganz sicher Grüße Martin

Hallo, ich teste gerade ein wenig mit dem IO16 Modul, das gestern hier angekommen ist. Bei Aufruf von io.get_port('b') erhalte ich einen Fehler bei io.get_port_configuration('b') jedoch nicht. Traceback (most recent call last): File "./test.py", line 50, in <module> print io.get_port('b') File "/usr/local/lib/python2.7/dist-packages/tinkerforge.egg/tinkerforge/ip_connection.py", line 67, in func return f(self, *args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/tinkerforge.egg/tinkerforge/bricklet_io16.py", line 46, in get_port return self.ipcon.write(self, IO16.TYPE_GET_PORT, (port,), 'c', 'B') File "/usr/local/lib/python2.7/dist-packages/tinkerforge.egg/tinkerforge/ip_connection.py", line 263, in write raise Error(Error.TIMEOUT, msg) tinkerforge.ip_connection.Error: -1: Did not receive answer for message('b',)in time Woran kann das liegen und wie lässt sich das lösen? Grüße Martin