AuronX

Soll ich jetzt erwähnen, dass MAC-Addressen genauso leicht zu fälschen sind? Das Problem ist ja, dass die Leute die WEP nicht knacken können in der Regel auch ncihts böses wollen und erst recht nciht in der Lage sind auf einen TF-Stack zuzugreifen ^^ Die die dir böses wollen, die können dann im Zweifel auch WEP knacken...

Ich glaube die Tipps im FAQ sollten reichen... die an die ich mich erinnere: - Schauen ob irgendwo stecker verbogen sind (Kurzschluss) - UID nue flashen - Firmware (des Bricklet) neu flashen

Du kannst bei bekannter UID einfach eine Anfrage losjagen und schauen ob eine Antwort kommt. Alternativ kannst du eine Enumeration machen (siehe hierzu Doku der IPConnection), dann erhälst du für alle Geräte (Bricks und Bricklets) eine Antwort und weißt somit, dass diese angeschlossen sind.

Dann müsstest du im Main-Thread aber aktiv die Kontrolle an die Bibliothek übergeben, damit das möglich ist... ungefähr so wie es in den PHP-Bindings wegen mangelnden multi-threadings gemacht wird. Was nicht geht ist "heimlich" - also ohne Wissen des Programmierers - Dinge im Main-Thread zu tun, da der Kontrollfluss ja ab einem bestimmten Punkt wieder in deiner Hand liegt und aktiv durch dich abgegeben werden muss. Nomenklatur wäre aber dennoch eine andere ^^ Threadsafe sind die Bindings nämlich dann, wenn ich sicher aus mehreren Threads auf sie zugreifen kann ohne dass es knallt.

Dann ist meine Meinung, dass ihr die WEP-Unterstützung im AP-Modus deaktivieren solltet, da der Nutzer ansonsten denken könnte er hätte es mit einer sicheren Verbindung zu tun. Ich vermute aber, dass ihr diese Meinung nicht teilen werdet ^^ ... obwohl ... *grab*

Ich bin gerade nicht sicher was die Extension alles kann, aber WEP solltest du sein lassen. Nimm WPA(2) oder lass die Verschlüsselung ganz weg WEP ist binnen Minuten (0-30 Minuten) geknackt, wenn man es richtig macht...

Irgendeine chance, dass die zeilenumbrüche falsch geparsed werden? #schussinsblaue

Mal nur des Feedbacks wegen: Ich nutze die OpenHAB-Bindings inzwischen um unser Wohnzimmer permanent zu monitoren, also quasi als Wetterstation. Angebunden ist der Stack über USB un das scheint auch stabil zu laufen.

Hallo, ich beziehe mich mal auf den Code und deine Aussagen dazu: Tatsächlich weißt du das nichtmal... was du hier abfragst (BrickletLCD20x4::DEVICE_IDENTIFIER) ist nur eine Konstante die die ID eines jeden LCD-bricklets enthält (siehe auch http://www.tinkerforge.com/de/doc/Software/Device_Identifier.html#device-identifier). In der Tat hast du einfach nur die Bindings danach gefragt welche Id denn ein LCD20x4 haben sollte, denn das ist es was sich hinter dieser Konstanten verbirgt. Aus deinem Code geht nciht hervor, dass du tatsächlich den Enumerate-Callback verarbeitest. Das bedeutet konkret, dass alles was bei dir im try-catch steht quasi derzeit keine Funktion hat. Was du eigentlich tun möchtest ist einen Callback für enumerate zu registrieren und dann diese Funktion zu rufen. In diesem Callback würdest du dann vergleichen ob das aktuelle Gerät gerade ein LCD20x4 ist, etwa so: function cb_enumerate($uid, $connectedUid, $position, $hardwareVersion, $firmwareVersion, $deviceIdentifier, $enumerationType) { if($enumerationType != IPConnection::ENUMERATION_TYPE_DISCONNECTED) { if($deviceIdentifier == BrickletLCD20x4::DEVICE_IDENTIFIER) { echo "I found an LCD20x4 with the UID " + $uid; return; } } } (Vorsicht: Ungetesteter Code und ich habe schon ewig kein PHP mehr programmiert... vielleicht verkettet man Strings ganz anders... aber das Prinzip sollte deutlich sein) Obiger Code wäre jetzt ein Callback der dann wenn ein LCD entdeckt wird (das nicht gerade abgezogen wurde) dessen UID ausgibt. Dazu müsstest du aber vor dem Aufruf von $ipcon->enumerate() noch folgendes einfügen: $ipcon->registerCallback(IPConnection::CALLBACK_ENUMERATE, 'cb_enumerate'); Ah... und jetzt habe ich gerade noch den Pferdefuß bei PHP entdeckt! Nachdem du $ipcon->enumerate() gerufen hast solltest du als nächstes folgendes tun: $ipcon->dispatchCallbacks(2.5); Das bewirkt, dass für die kommenden 2.5 Sekunden (der standard-timeout aller TF-Anfragen) Callbacks verarbeitet werden. Das heißt während diese Methode läuft wird der oben genannte Callback aufgerufen und du kannst im folgenden Code Dinge tun und dir sicher sein, dass der Callback durchlief. Ich versuche mich jetzt nochmal daran deinen Code in etwa so zu vervollständigen, dass er das tut was du möchtest (wie du bereits merkst, ich lese mich auch erst während des Schreibens in die Thematik ein ): $ipcon = new IPConnection(); // Verbindung aufbauen // ------------- $globalUID = ""; //ich hoffe man kann in PHP einfach so globale variablen nutzen... function cb_enumerate($uid, $connectedUid, $position, $hardwareVersion, $firmwareVersion, $deviceIdentifier, $enumerationType) { if($enumerationType != IPConnection::ENUMERATION_TYPE_DISCONNECTED) { if($deviceIdentifier == BrickletLCD20x4::DEVICE_IDENTIFIER) { echo "I found an LCD20x4 with the UID " + $uid; $globalUID = $uid; return; } } } $ipcon->registerCallback(IPConnection::CALLBACK_ENUMERATE, 'cb_enumerate'); //hier sorgst du dafür, dass die enumerate-antworten auch in deiner funktion landen try { $ipcon->enumerate(); // Devices auflisten $ipcon->dispatchCallbacks(2.5); // hier wird dein callback aufgerufen... } catch ( Exception $e ) { sleep(10); goto connect; } //wenn ein LCD da war, dann kannst du ab hier die uid aus $globalUID auslesen... etwa so: echo "Ich benutze ab sofort folgendes LCD: " + $globalUID; Ich hoffe mein Beispielcode passt ungefähr, zumindest so, dass du das Grundprinzip verstehen konntest. Viel Spaß Jan

Hmmm... mir fällt es ggerade schwer zu antworten, vielleicht kannst du näher ausführen was du am enumerate nicht verstanden hast. Das wäre nämlich mein Tipp gewesen: "Schau dir mal die enumerate-funktion an"... Ich versuch mal zu erklären, wie das gedacht ist: Wenn du enumerate aufrufst sagst du dem Stack damit, dass er dir alle Geräte auflisten soll. Dazu musst du vorher einen Callback definiert haben der dann für jedes Gerät aufgerufen wird. Das passiert parallel (ich glaube auch bei PHP(?)), das heißt dein restliches Programm ab "enumerate()" würde einfach weiterlaufen. Du kannst jetzt eines von zwei Dingen tun: 1. Im Callback nur die Geräte in eine globale Liste schreiben. Dort wo du enumerate gerufen hast wartest du einfach 3 Sekunden und machst erst danach weiter. Das erfordert kaum Anpassung, jetzt aber langsam (immer 3 Sekunden warten) 2. Einfach nichts weiter nach "enumerate()" tun und alles was du dort tun würdest direkt im Callback ausführen. Das erfordert aber etwas mehr Anpassung und du musst auch aufpassen, dass du im Callback nichts tust was lange dauert. Ich hoffe ich habe jetzt erstmal nichts (für PHP) falsches erzählt und vielleicht konnte ich schon etwas Klarheit schaffen. Ansonsten habe ich vielleicht zumindest noch mehr Verwirrung stiften können Falls du konkretere Fragen hast kann ich auch versuchen noch konkreter zu antworten Viele Grüße

Statt im Callback die UIDs in einer globalen Variable zu speichern und im Hauptprogramm alles auszugeben könntest du auch im Callback alles ausgeben. In der einfachsten Form geht das so (ich mach jetzt nur wildes copy & paste in deinem code hier im forum; NICHT GETESTET): #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID_Barometer = None UID_Humidity = None UID_AmbientLight = None from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_barometer import Barometer def my_testcallback(uid, connected_uid, position, hardware_version, firmware_version, device_identifier, enumeration_type): if device_identifier == 221: #b = Barometer(UID_Barometer, ipcon) # die uid`s brauch ich um die bricklets anzusprechen #air_pressure = b.get_air_pressure()/1000.0 #print('Air Pressure: ' + str(air_pressure) + ' mbar') elif device_identifier == 27: # hier wie beim barometer elif device_identifier == 21: # hier wie beim barometer if __name__ == "__main__": ipcon = IPConnection() ipcon.connect(HOST, PORT) ipcon.register_callback(IPConnection.CALLBACK_ENUMERATE, my_testcallback) ipcon.enumerate() print('test2: ' + str(UID_Barometer)) print('test2: ' + str(UID_AmbientLight)) print('test2: ' + str(UID_Humidity)) input('Press any key to exit\n') ipcon.disconnect() Ansonsten kannst du dir mal den Code von der Wetterstation anschauen. Da passiert im wesentlichen das folgende: Hauptprogram - registriert enum-callback - ruft ihn auf enum-callback - erstellt temporär ein device - registriert je nach device die callbacks (temperatur/luftdruck/wasauchimmer) jeder dieser callbacks - gibt aktuellen wert aus / tut dinge damit

Der Aufruf von enumerate blockiert nicht! Das heißt enumerate läuft durch und parallel zu dem was du dann noch schreibst werden irgendwann die callbacks ausgeführt. Das Problem ist dass du nicht sicher sagen kannst wie lange es dauert bis alle Antworten aufs Enumerate angekommen sind. Wenn du sicher gehen willst, dann musst du nach "enumerate()" mindestens 2500ms warten. Das ist meiner Erinnerung nach der Standard-Timeout, alles was länger zum Antworten braucht gilt gemeinhin als "nicht rechtzeitig".

Ich gehe davon aus, dass ein Ambi-Light mit Streulichtblende schon helfen sollte... Damit kannst du ja dann halbwegs gerichtet die Helligkeit messen und da das Streulicht fehlt sollten die 900 Lux auch "länger halten"... also mehr Intensität vorraussetzen... Ist aber nur ein Gedankenexperiment von mir, keine konkreten Erfahrungen.

Ich kannte bisher auch nur screen. Ganz am Ende möchtest du es aber vielleicht sogar mittels init-Skript starten lassen, damit es auch nach einem Neustart direkt wieder funktioniert.

Bei deiner Alternative kannst du dann natürlich auch wieder with nutzen, weil du außerhalb keinen Zugriff auf die datei durchführst. Also wenn du öffnen und schließen beides im cb hast.

Ich bin nicht ganz so fit in Python und könnte mich täuschen, aber ich glaube am Ende des with-Blocks wird csvfile1 geschlossen. Wenn dem so wäre, dann könnten die Callbacks die ja erst nach diesem with-Block eintrudeln gar nichts mehr schreiben, weil die datei ja bereits geschlossen ist. Das with open('gerty_illuminance_data.csv', 'wb') as csvfile1: sollte also durch ein simples csvfile1 = open('gerty_illuminance_data.csv', 'wb') ersetzt werden... natürlich muss diese Datei dann auch bei Programmende selbst geschlossen werden.

Ich vermute wegen der fehlenden galvanischen Trennung und des damit einhergehenden Risikos sich Störungen ins Brick zu holen. Wenn du eine Steckdose schaltest ist ja im wesentlichen nicht klar welche Störungen vom Verbraucher ausgehen können.

Ist das Servo-Brick digital-fähig?

Kleine anpassbare "Klickschieber" zum Anpassen des Spiels am Ende wird es vermutlich nicht geben oder wenn sind sie zu teuer oder? (Hardwarelösung) Ich denke quasi an so dinger mit denen man beim Rasensprenger den Sprengwinkel einstellt... halt nur in mini-mini-größe ^^

Das verstehe ich auch nicht ^^ (also warum vielen das unangenehm ist)

Mit einem Analog-In Bricklet. Die Kapazitätsmessung bei Akkus basiert meines Wissens auf der Annahme, dass die Spannung die aus dem Akku kommt mit sinkender "Füllung" auch geringer wird. Du kannst also die Spannung deines vollen Akkus nehmen und die Spannung deines leeren Akkus und dazwischen dann interpolieren. Die Interpolation sollte je nach Akku unterschiedlich sein. Bei einigen genügt es linear zu interpolieren, bei anderen ist die Spannungkurve eine andere.

Ja Code würde sehr helfen... Grundsätzlich sollte es in einer Forms-Anwendung funktionieren... Allerdings habe ich noch keine konkrete Idee was bei dir schieflaufen könnte. Was heißt du kannst keine verbindung herstellen? Kommt bei deinem Programm eine TimeoutException o.ä. oder passiert einfach gar ncihts? edit: Module scheinen ja nur das Gegenstück zu static classes in C# zu sein, mir ist auf Anhieb nciht klar, warum dein Code dort besser funktionieren sollte als in einer Klasse...

+1 dafür! unbedingt

Ich denke die aller sauberste Lösung wäre es mittels IO4 oder AnalogIn zu schauen, ob gerade Strom durch die Lampe geht. Allerdings weiß ich nicht wie man das beschalten muss damit es kein Feuer gibt. @nic: So wie ich die PHP-Bindings verstehe baut das jeweilige Skript immer nur kurz eine Verbindung zum Stack auf. Dadurch gibt es auch hier diese Beschränkung. Im Zweifel lässt sich in vielen Anwendungsfällen das Limit auch dadurch anheben, dass man nur einen Rechner die Verbindung zum Stack herstellen lässt und dann von dort aus den Stack "freigibt" (mit einem selbst zu schreibenden Programm). Dann ist man das Socketlimit auch wieder los.

Ist das so? An einem Chibi-Slave kann wieder ein RS485-Master hängen? Das wäre ja abgefahren ^^