borg

A callback is only triggered if the value actually changes. So for example if you set a callback period of 1 second and the temperature stays the same for 30 seconds until it changes, you will only get the callback after 30 seconds. This is probably what you are seeing here. To try this out you can heat/cool the Bricklet rapidly. We do this to save bandwidth on the USB.

Das ist ein bisschen unspezifisch . Welche Fehlermeldung bekommst du denn?

Eventuell entfernen wir die Hotplug-Funktionalität wieder, wenn es da wirklich ein Probleme gibt (da warten wir noch auf Feedback). Das sollte allerdings irrelevant sein solange dein Master Brick nicht übermäßig heiß wird .

Theoretisch ist das natürlich möglich, in der Praxis haben wir so ein Problem aber noch nie nachweisen können .

Es könnte Störungen auf dem Kabel sein (die Bricklets sind beide Digital, d.h. die Störungen müssten gerade in den Daten sein). Es könnten aber auch Störungen sein welche dazu führen das die Sensoren selbst falsche Werte zurückgeben. Bei dem Temperature Bricklet kannst du die I2C Geschwindigkeit einstellen. Falls durch ein verringern der Geschwindigkeit auf 100kHz die Probleme geringer werden deutet es auf eine Störung im Kabel hin. Da wären dann im Zweifelsfall kürzere Kabel die einfachste Lösung.

Zuvor war es so, dass sich der Stapel dauerhaft weggehängt hat. Ich füge es gleich noch der API Dokumentation hinzu, das ein Wert von -99,99°C bedeutet das ein Fehler vorliegt.

Plugin: Temperature 2.0.3 Gebe -99.99°C zurück im Falle eines Fehlers während der Kommunikation (zuvor wurde der komplette Stapel blockiert) Download: Temperature Bricklet

Plugin: Temperature 2.0.3 Return -99.99°C in case of an error during communication (before it would block the whole stack) Download: Temperature Bricklet

Can you make a minimal example that crashes, so i can try to get it running? It is possible to install Python 3.4 on Debian Wheezy (which we are using), but it is a bit of a hassle: http://www.extellisys.com/articles/python-on-debian-wheezy

If you put "192.168.0.24" into the listen address, brickd can only be accessed by the IP "192.168.0.24". Which means that redapid can't connect to brickd (since it connects through localhost). Thank explains it indeed .

That is strange. The latest brickd log is from December 29th, while the latest redapid log that says that brickd connected is from January 3rd. I don't know how that could possibly happen . If you delete the brickd.log and reboot, is there a new one written?

Zwei Pixel leuchten weiß und die restlichen Pixel funktionieren? Oder nur die zwei Pixel leuchten und sonst geht gar nichts? Kannst du vielleicht ein Foto machen vom LED Strip Bricklet mit den angeschlossenen Kabeln bis zum ersten Pixel?

Hast du überprüft ob evtl. ein Pin krumm ist (am Master Brick oder am NFC/RFID Bricklet)?

Wir hatten im Master Brick 2.0 (und allen vorherigen Hardware Versionen) das Problem, dass manchmal das einstecken eines USB Kabels erkannt wurde, obwohl gar kein USB Kabel eingesteckt wird. Dies kam durch Temperaturänderungen zustande, da sich dadurch Widerstandswerte geändert haben. Dies war abhängig von den Toleranzen der Widerstände und trat deswegen nur bei wenigen Nutzern auf. Eigentlich sollte das Problem im Master Brick 2.1 behoben sein, es klingt aber so als hättest du dieses Problem. Die Firmware entfernt die Hotplug-Funktionalität wieder.

Puh, das muss ich mir am Montag genauer angucken. Ich bin gerade kurz die Commits durchgegangen, IMO hat sich seit dem allerersten Release nichts am eigentlichen Verbindungsaufbau geändert (dieser schlägt ja fehl hier). Es ist auch komisch, dass die JavaScript Bindings schuld zu sein scheinen. Die WebSocket Server Implementierung im Brickd und im Master Brick ist komplett von uns, da kann ich mir gut vorstellen, dass wir irgendwo RFC 6455 nicht 100%ig korrekt implementieren und es nach einem Browser-Update auf einmal nicht mehr geht. Für die Bindings nutzen wir die WebSocket Implementierung des jeweiligen Browsers. Warum sollte sich da etwas ändern nach einem Update der Bindings? Sehr komisch. Wenn du Lust hast das genauer zu debuggen könntest du versuchen die Kommunikation mit Wireshark aufzunehmen. Einmal mit einer funktionierenden und einmal mit einer nicht-funktionierenden Bindings Version. Interessant wäre dabei dann zu sehen wo genau im WebSocket Handshake der Unterschied ist zwischen den beiden. Ich komme da sonst frühstens am Montag oder Dienstag zu.

Can you ssh into the RED Brick and take a look at /var/log/brickd.log and /var/log/redapid.log?

Mhh, i am not sure, again it works for me: tf@red-brick:~$ python Python 2.7.3 (default, Mar 14 2014, 17:55:54) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from apscheduler.schedulers.background import BackgroundScheduler >>> No errors.

Wenn du den RED Brick per USB an den PC anschließt und localhost statt der IP nimmst, funktioniert es dann? Edit: Nur um zu gucken ob es ein generelles Problem mit brickd ist oder spezifisch mit dem RED Brick zu tun hat.

Danke, ist gefixt. Das mit dem "true" ist schon OK so. Wenn in der Dokumentation von der API Codeschnipsel sind, ist das immer Pseudocode. Die Dokumentation existiert nur einmal und wird für alle Sprachen generiert, daher ist der Code an der Stelle nie sprachspezifisch.

Currently the only way is to flash the sd card and reconfigure. There will be an export/import function for the programs and configurations in one of the next Brick Viewer versions. It will be a lot easier to upgrade with that .

It works for me. You will need to run pip as root however: tf@red-brick:~$ sudo pip install apscheduler Collecting apscheduler Downloading APScheduler-3.0.1-py2.py3-none-any.whl (47kB) 100% |################################| 49kB 535kB/s Collecting six (from apscheduler) Downloading six-1.8.0-py2.py3-none-any.whl Collecting futures (from apscheduler) Downloading futures-2.2.0-py2.py3-none-any.whl Requirement already satisfied (use --upgrade to upgrade): pytz in /usr/lib/pytho n2.7/dist-packages (from apscheduler) Collecting tzlocal (from apscheduler) Downloading tzlocal-1.1.2.zip Installing collected packages: tzlocal, futures, six, apscheduler Running setup.py install for tzlocal Successfully installed apscheduler-3.0.1 futures-2.2.0 six-1.8.0 tzlocal-1.1.2 tf@red-brick:~$

RED Brick Images: Full and Fast 1.3 Probleme mit der Namensauflösung (DNS) behoben. Download: Full, Fast

RED Brick Images: Full and Fast 1.3 Fix problems wit name resolution (DNS) Download: Full, Fast

Die Ethernet Extension wird auf dem RED Brick komplett vom Linux Kernel Betrieben, der Master Brick hat da nichts mehr mit zu tun und man kann auch entsprechend die API nicht benutzen. Du müsstest dafür nutzen was das Linux bietet, also z.B. ifconfig usw.

Wenn keine Step-Down angeschlossen ist oder die Step-Down nicht mit Strom versorgt wird, sind die Leitungen mit denen wir Spannung und Strom messen "Floating". Wir haben da zwar extra noch einen Pull-Down-Widerstand dran, allerdings scheint hin und wieder, je nach Umgebung, nicht auszureichen. D.h. wenn der Stack nicht über die Step-Down versorgt wird, hat StackVoltage und StackCurrent keine Aussage!