photron

Jeder Setter-Aufruf in der API sendet exakt eine Nachricht. Bei jedem Getter kommt dann auch noch exakt eine Nachricht zurück. set_port_configuration() sendet also eine Nachricht. Die IO-16 ist in Port A und Port B unterteilt und an jedem Port sind 8 Pins. Mit set_port_configuration() kannst du die 8 Pins an einem Port setzen. Du brauchst also zwei set_port_configuration() Aufrufe um alle Pins einer IO-16 einmal zu setzen. Wenn du nur zwischen Output-High und Output-Low umschalten willst kannst du auch einmal mit set_port_configuration() alle Pins auf Output stellen und dann mit set_port() zwischen High und Low wechseln.

Da muss du zuerst den aktuellen Text aus dem Textfeld löschen. Das geht z.B, mit T.delete(1.0, END) bevor du mit T.insert() in der cb_temperature() Funktionen neuen einfügst. Etwa so: def cb_temperature(temperature): #print('Temperature: ' + str(temperature/100.0) + ' °C') T.delete(1.0, END) T.insert(END, 'Temperature: ' + str(temperature/100.0) + ' °C\n')

Bindings: C/C++ 2.1.1 Add extern "C" markup to all files to force proper symbol names in C++ Explicitly use ANSI version of WinAPI functions to support UNICODE builds on Windows Add simple library Makefile for Linux Fix race condition between device destruction and callback dispatch Download: C/C++

Bindings: C/C++ 2.1.1 extern "C" Markup zu allen Dateien hinzugefügt, um C Symbolnamen in C++ zu erzwingen Explizit ANSI Version von WinAPI Funktionen verwendet, um die UNICODE Compile-Option unter Windows zu unterstützen Einfaches Library Makefile für Linux hinzugefügt Race Condition zwischen device_destroy() Funktion und Callback-Auslieferung behoben Download: C/C++

Take a look at the interrupt example for the IO-4 Bricklet. You connect your button to pin 0 and a GND pin on the IO-4 Bricklet. Each time the button is pressed or released you get an interrupt callback. You can modify the cb_interrupt() function from the example like this (untested): def cb_interrupt(interrupt_mask, value_mask): # test if interrupt is from pin 0 if interrupt_mask & (1 << 0): # test if button is pressed or released if value_mask & (1 << 0): print "button released" else print "button pressed" if system_activ: system_activ = False print "surveillance is disabled" else: system_activ = True print "surveillance is enabled" Now your script can tell if the button was pressed or released. With this information you can then set your system_activ variable.

Du hast da mehrere Probleme in deinem Script. Die if __name__ == "__main__": Blöcke gehören so nicht innerhalb von Funktionen, bzw. machen da keinen Sinn. Du hast bei der Einrückung Tabs und Spaces gemischt, das mag Python im Zweifels so nicht und führt zu komischen Problemen, da Blöcke in Python durch Einrückung gebildet werden. Die Registrierung und Aktivierung des Temperature-Callbacks erfolgt in der Callback Funktion. Dass kann so nicht funktionieren, das muss außerhalb von cb_temperature() passieren. Etwa so: #!/usr/bin/env python # -*- coding: utf-8 -*- from Tkinter import * from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_remote_switch import RemoteSwitch from tinkerforge.bricklet_temperature import Temperature import os #Tinkerforge HOST = "127.0.0.1" PORT = 4223 RemoteSwitch_UID = "jNw" Temperature_UID = "dFu" root = Tk() root.title("GUI") WMWIDTH, WMHEIGHT, WMLEFT, WMTOP = root.winfo_screenwidth(), root.winfo_screenheight(), 0, 0 root.overrideredirect(1) root.geometry("%dx%d+%d+%d" % (WMWIDTH, WMHEIGHT, WMLEFT, WMTOP)) #Temperature T = None def cb_temperature(temperature): #print('Temperature: ' + str(temperature/100.0) + ' °C') T.insert(END, 'Temperature: ' + str(temperature/100.0) + ' °C\n') def shutdown(): os.system("sudo shutdown -h now") def reboot(): os.system("sudo shutdown -r now") def light_on(): rs.switch_socket_b(1, 1, RemoteSwitch.SWITCH_TO_ON) def light_off(): rs.switch_socket_b(1, 1, RemoteSwitch.SWITCH_TO_OFF) #def netio(): # os.system("sudo python /home/pi/GUI/tinkerforge/tinkerforge listen --enable-execute") def exit(): sys.exit() #b=Button(root, text= "NetIO", command=netio) #b.pack() # Create UI logo = PhotoImage(file="/home/pi/GUI/images/rpi_inside.gif") w1 = Label(root, image=logo height=32, width=32).grid(row=1, column=3) MyButton1 = Button(root, text="Shutdown", width=10, command=shutdown) MyButton1.grid(row=1, column=0) MyButton1 = Button(root, text="Reboot", width=10, command=reboot) MyButton1.grid(row=2, column=0) MyButton1 = Button(root, text="Exit", width=10, command=exit) MyButton1.grid(row=3, column=2) MyButton1 = Button(root, text="Licht an", width=10, command=light_on) MyButton1.grid(row=4, column=1) MyButton1 = Button(root, text="Licht aus", width=10, command=light_off) MyButton1.grid(row=5, column=1) T = Text(root, height=2, width=30) T.grid(row=6, column=3) # Create Tinkerforge objects ipcon = IPConnection() rs = RemoteSwitch(RemoteSwitch_UID, ipcon) t = Temperature(Temperature_UID, ipcon) ipcon.connect(HOST, PORT) t.register_callback(t.CALLBACK_TEMPERATURE, cb_temperature) t.set_temperature_callback_period(1000) # Start mainloop root.mainloop()

Wenn du auf dem RPi kein X laufen hast, kannst du kein brickv starten, das ist normal. Die Verzeichnisstruktur muss so aussehen: /home/pi/tinkerforge/ -> dein_script.py -> tinkerforge/ ----> __init__.py ----> ip_connection.py ----> brick_master.py ----> ... ----> bricklet_ambient_light.py ----> ... Die Bindings müssen in einem tinkerforge Unterverzeichnis neben deinem Script liegen und nicht im gleichen Verzeichnis wie dein Script. Und dieses tinkerforge Unterverzeichnis muss eine __init__.py Datei beinhalten, was aber schon der Fall sein sollte wenn du es aus dem ZIP kopierst. xip_connection? Das sollte wenn ip_connection ohne x sein.

Du kannst den Master Brick, der als RS485 Master arbeitet, auch mittels Ethernet oder WIFI Extension mit dem PC verbinden. Es muss nicht USB sein. Die Dokumentation ist da jetzt auch klarere formuliert. Danke für den Hinweise.

Loetkolben, mehrere Python Versionen gleichzeitig installiert zu haben ist normal und kein Problem. RouvenE, irgendwie mach bei dir easy_install Probleme, warum ist mir nicht ganz klar. Lass mich mal zusammenfassen: brickd und brickv sind installiert und funktionieren soweit. Aber die Python Bindings fehlen. Probier mal Folgendes aus: [*]Python Bindings herunterladen und entpacken. [*]Aus dem source Verzeichnis das tinkerforge Verzeichnis neben das Python Script kopieren, das du verwenden willst. [*]Dann sollte Python die Bindings finden können. Damit hast du die Bindings jetzt noch nicht global im System installiert, aber das sollte so erstmal als Test funktionieren.

Das ist komisch. Teste mal ob auch wirklich jemand auf Port 4223 lauscht: netstat -l | grep 4223 Das sollte folgendes ausgeben: tcp 0 0 *:4223 *:* LISTEN Ansonsten kannst du mal versuchen die listen.address Option in /etc/brickd.conf auf 127.0.0.1 zu setzen. Dann werden nur noch lokale Verbindungen angenommen. 0.0.0.0 bedeutet Verbindungen werden von überall her angenommen. Hast vielleicht irgendwelche Firewall Dinge auf dem Raspberry Pi aktiviert, die die lokale Verbindung verhindern?

Leider kann die WIFI Extension (noch) keine Websockets, sonst könntest du auf deinem Smartphone einfach brickv.com aufrufen und dich direkt zu WIFI Extension verbinden un die Temperatur auslesen. Eine Mögliche alternative wäre eine Ethernet Extension (diese kann Websockets). Oder eine Raspberry Pi dazuhängen und die Daten nach Xively hochladen und sie dann auf der Xively Website vom Smartphone aus ansehen. Für die Wetterstation haben wir das samt Beispiel Programm dokumentiert. Du könntest auch NetIO verwenden. Dann brauchst du allerdings noch einen Rechner auf dem die Shell Bindings als NetIO Proxy laufen.

Das sieht alles soweit gut aus. Ich nehme an du meinst, dass sich brickv mit einer Fehlermeldung beschwert, wenn du den Connect Knopf klickst? Die Fehlermeldung hat diesen Text: Could not connect. Please check host, check port and ensure that Brick Daemon is running. Dann jetzt ein einfacher Test. Kopiere diese vier Zeile Python Code in eine Datei namens test.py: import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('localhost', 4223)) print('done') und start sie mittels: python test.py Wenn "done" ausgegeben wird hat die Verbindung zu brickd funktioniert. Wenn nicht, dann wird ein Traceback ausgegeben, den dann bitte hier posten.

Create an IPConnection object and connect it to the host. If connect fails then the host is not reachable. With the connected IPConnection object create an object for the Bricklet and call its getIdentity method. If the method fails with a timeout then the Bricklet is not connected. The default timeout is 2.5 seconds. If that's too long you can make it shorter. How short it can be and still work reliable depends on the TCP/IP connection speed. You'll have to experiment.

Hast du dir schon die Beispielprogramme angesehen? Zu allen gibt es auch den Quelltext, da kannst du dir anschauen wie wir das gemacht haben.

Die Fehlermeldung besagt, dass Dev-C++ eine kaputte .exe Datei erstellt hat. Das scheint mit erstmal nichts direkt etwas mit dem Wetterstationscode zusammen zu hängen. Hast du mal versucht ein einfaches Hello World Programm zu erstellen? Ich schätze mal, dass Dev-C++ da Beispiele mitbringt.

brickd is relying on udev events to be notified about USB device arrival/removal. The kernel message sound like the musb driver is not handling the disconnect properly. In the end there is no udev event send for this USB device removal and brickd does not get notified about it. I'm afraid there's not much I can do here.

The events of stopping brickd and unplugging a stack from USB is delivered with different callbacks. If you stop brickd, it'll close all open client connections. Your program and brickv will receive a disconnected callback for this event. If you unplug a stack from USB then brickd will send you an enumerate callback with type disconnected for this event. In brickv this event is used to remove the affected Bricks and Bricklets from the devices list. If this is not working in brickv then there might be a problem with USB hot(un)plug detection on your Linux system. You can take a look at the brickd log at /var/log/brickd.log, as brickd logs USB device arrival/removal.

Brick Daemon maintains a context per client connection for routing responses. But it doesn't try to be clever about callbacks, because if brickd is wrong about its guesses about callback handling then your application can miss a callback because brickd made the wrong decision. For example, how should brickd decide which enumeration callbacks to send to a particular client connection? Should it keep track about when the last enumerate request was received from a client and pass all incoming enumerate-available callbacks to that client for until x milliseconds after the last enumerate request? But then what's the correct value for x? If it's too short you might miss enumerate-available callbacks you should have received. If it's too large you could get callbacks you want to have filtered out. Also, if the time windows for two client connections for the enumerate-available callback passing overlaps then you still get callbacks twice. It's much easier to deal with this in the client application itself. If you see an enumerate callback that tells you that a Brick(let) is connected/available/disconnected and your client application already knows that the Brick(let) is in that state then you can just ignore this event. Yes, this means your client application needs some state tracking for this. But it is much better suited in your client application than in brickd. Because in your app you can do it in a way that fits your needs. In brickd there would have to be one model that has to fit all needs. Also brickd is designed to keep as minimal state information as possible. The less state brickd has to track the less state can be wrong or out-of-sync. This is something we learned from protocol version 1, were brickd had to track more state information. This approach allows you to restart brickd at any time because with the current protocol version 2, there is no essential state information anymore. The minimal state that brickd tracks is optional and just used to optimize the response routing.

You want to provide 5V to the stack via the black connector on the Servo Brick? That's not possible. This black connector on the Servo Brick can only be used to power servo motors connected to the Servo Brick. You can use a Step-Down Power Supply or the USB connector on the master of the stack to provide the 5V stack power.

Ein NULL-terminierter String kann kein '\0' enthalten. Daher ist der erste Custom Character nicht aus ASCII Code 0, sondern 8: lcd_20x4_write_line(&lcd, 0, 0, "\x08");

theo, lass mich da mal einen Blick drauf werfen.

Du kannst beide Bricks jeweils einzeln per USB an den PC anschließen, kein Problem. Dass heißt, du braucht pro Brick einen USB Anschluss. Ein Master Brick ist hier optional und würde dir erlauben die Bricks zu stapeln und alle über eine gemeinsame USB Verbindung zu erreichen.

brickd führt intern eine Liste darüber welche IPConnection noch auf Antworten (Response) von Brick(let)s warten. Dafür merkt er er sich die Anfragen (Request). Die Meldung besagt jetzt, dass eine IPConnection geschlossen wurde, obwohl sie aus der Sicht von brickd noch auf eine Antwort wartet. Das kann passieren wenn z.B. ein Getter-Aufruf einen Timeout erzeugt, also keine Antwort kommt. So direkt sehe ich da keinen Zusammenhang mit deinem Problem. Das sollte normaler weise nicht passieren. Das besagt, das es einen USB Event gegeben hat (z.B. Antwort ist eingegangen) dieser aber in diesem Durchgang nicht behandelt wurde (werden konnte) von brickd. Das sollte nicht kritisch sein. Und auch hier sehe ich gerade keinen direkten Zusammenhang mit deinem eigentlichen Problem.

Nein, das ist hardwaretechnisch nicht möglich.

brick-flash-cmd hat es jetzt auch in die Dokumentation geschafft: http://www.tinkerforge.com/de/doc/Software/Brickv.html#mit-brick-flash-cmd-auf-linux