photron

Ja, da macht Microsoft es einem nicht leicht Laut SmartScreen Dokumentation warnt Windows über alle Software die Microsoft noch nicht kennt. Diese Warnung sollte also nach ein Weile von selbst verschwinden, wenn genug Leute die Software installiert haben und Microsoft sie so kennengelernt hat. Da können wir leider nichts dran ändern. In der ersten Version hatten wir Abtrennen per Doppelklick auf den Tab. Nachteil: Man muss wissen, dass das jetzt geht. Vorteil: Man kann es nicht so einfach unabsichtlich auslösen. Die jetzige Version mit Knopf hat den Vorteil, dass man direkt sieht da gibt es etwas neues, aber auch den Nachteil, dass man das schneller unabsichtlich Klicken kann. Drag'n'Drop zum Abtrennen wäre auch möglich, hätte aber den gleichen Nachteil wie Doppelklick. Das jetzige Vorgehen ist da nicht in Stein gemeißelt, mal hören was andere Leute dazu meinen

The RED Brick will be released really soon now Brick Daemon and Brick Viewer got support for the RED Brick. We'd like to use the remaining time until the release for an release candidate test to find and fix potential problems before the release. You can download RC1 versions of brickd and brickv 2.2.0 for testing here: http://download.tinkerforge.com/_stuff/red_brick_rc1/ Please report all problems and findings here, thanks! -------------------------------------------------------- Apart from the RED Brick support there are some other changes and additions as well: Brick Viewer 2.2.0 Allow to rearrange Brick and Bricklet tabs and detach them from the main window Improve UI for NFC/RFID Bricklet read and write operations Windows installer and drivers are signed now Fix occasional bounce of the connect button Fix UI font selection on Mac OS X 10.9 and 10.10 Brick Daemon 2.2.0 Colorized log messages Detect and drop pending requests that will never get a response Windows installer and drivers are signed now Mac OS X installer signed on Mac OS X 10.10 to make it pass the Gatekeeper again Enable logrotate for brickd.log on Linux Remove all categories from logging system

Die Veröffentlichung des RED Bricks steht kurz bevor Brick Daemon und Brick Viewer haben Support für den RED Brick erhalten. Wir möchten die Zeit bis zum Release für einen Release Candidate Test nutzen, um mögliche neue Probleme noch vor dem Release finden und beheben zu können. Auf der folgenden Seite stehen die RC1 Version von brickd und brickv 2.2.0 zum Download und Test bereit: http://download.tinkerforge.com/_stuff/red_brick_rc1/ Alle Probleme und Unstimmigkeiten die ihr findet bitte hier posten, Danke! -------------------------------------------------------- Neben RED Brick Support sind auch noch einige andere Änderungen hinzugekommen: Brick Viewer 2.2.0 Brick und Bricklet Tabs können umsortiert und vom Hauptfenster abgetrennt werden Verbessertes UI für NFC/RFID Bricklet Lese/Schreiboperation Windows Installer und Treiber sind jetzt digital signiert Ab und zu auftretendes Prellen des Connect Knopfes behoben Problem mit UI Schrift auf Mac OS X 10.9 und 10.10 verbessert Brick Daemon 2.2.0 Logmeldungen sind jetzt bunt Requests für die kein Response mehr kommen kann werden erkannt und verworfen Windows Installer und Treiber sind jetzt digital signiert Mac OS X Installer wird jetzt auf Mac OS X 10.10 digital signiert, damit er den Gatekeeper wieder passieren kann logrotate für brickd.log auf Linux aktiviert Kategorieren aus dem Logging-System entfernt

kPa Base58 decodiert ist dezimal 66651, nicht 63287. Abgesehen davon sollte dein Hex-Code funktionieren. Das TCP/IP Protokoll das die Bricks und Bricklets verwenden ist binär und kennt keine Terminierungszeichen.

Dass heißt, für Titanium müssten unsere JavaScript Bindings erweitert werden, damit sie Titanium erkennen und dann die Titanium spezifischen Funktionen für Socket und Buffer verwenden können?

Das JavaScript Browser Callback Beispiel für's Color Bricklet funktioniert hier ohne Probleme, wie es soll. Wie genau testet du das Beispiel? Wenn du am Voltage/Current Bricklet nichts angeschlossen hast, dann ist die Strommessung recht stabil bei 0A. Callbacks für solche Messwerte werden aber nur dann gesendet, wenn sich der Messwert ändert. Wenn der Messwert aber stabil ist, dann wird auch kein Callback gesendet.

Problem gefunden. Illuminance und Color Temperature wurden nur dann neu berechnet, wenn der Color Callback aktiviert war. Das ist jetzt in Color Bricklet Plugin Version 2.0.1 korrigiert. Dein Program sollte also nach einem Update des Color Bricklet Plugins funktionieren wie erwartet. Danke für den Hinweis!

Plugin: Color Bricklet 2.0.1 Always use up-to-date RGB values in color temperature and illuminance calculation, independent of the color callback state Download: Color Bricklet

Plugin: Color Bricklet 2.0.1 Es werden immer aktuelle RGB Werte in der Color Temperature und Illuminance Berechnung genutzt, unabhängig davon, ob der Color Callback aktiviert ist oder nicht Download: Color Bricklet

Du machst da gar nichts falsch! Ich kann das Problem hier reproduzieren, sieht nach einem Problem in der Firmware des Bricklets aus. Muss ich mir genauer ansehen.

Hrm, bin ich etwas ratlos. Mach mal testweise aus dem illuminance/10.0 ein illuminance/10 um zu sehen ob das deinen Unterschied macht.

Welche Version des Compilers verwendest du denn, also was gibt "msc --version" aus? Der Fehler bezieht sich auf Zeichen 77 in Zeile 18. In WeatherStation.cs steht dort: string text = string.Format("Illuminanc {0,6:###.00} lx", illuminance/10.0); Wenn die Tabs als jeweils ein Zeichen gezählt werden dann ist Zeichen 77 die schließende Klammer nach 10.0. Ergibt so richtig keine sinn warum das ein Problem sein sollte. Steht bei dir etwas anderes in Zeile 18 in einfache_Wetterstation.cs?

Did you test this yet? Any feedback on this?

Dass heißt jedes dieser drei Bricklets einzeln am Servo Brick angeschlossen macht kein Problem. Sobald du aber irgendein zweites Bricklet anschließt funktioniert die WLAN Verbindung deutlich schlechter? Ist die Kombination der Bricklets egal, oder gibt es eine spezielle Kombination die das Problem erzeugt? Wie lang sind die Bricklet Kabel die du verwendest? Funktioniert es besser wenn du kürzere Kabel verwendest, unter der Annahme dass du noch nicht die kürzesten Kabel verwendest?

Komische Fehlermeldung, vom Text her. Was ist der genau Text der Fehlermeldung? Hört sich an als ob der System.Net Namespace fehlt. Der kommt aus der System.dll (oder der System.Net.dll (?)), die sollte aber eigentlich automatisch zu deinem C# Projekt hinzugefügt worden sein.

Sprichts du denn das Protokoll auch so wie hier beschrieben: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/Modbus.html#requests-and-responses Sprich pollst du den Slave für Responses nachdem du ihm den Request gesendet hast? Slaves dürfen von sich aus keinen Response senden, sondern nur als Antwort auf einen Request. Edit: Hätte mal richtig lesen sollen. Wie handhabt dein RS485 Wandler den Transmitter und Receiver Enable? Steuerst du das von Hand, oder passiert das automatisch? Wenn der Transmitter auf der Master-Seite aktiviert ist wenn der Slave antwortet dann kann die Antwort verfälscht ankommen.

Welche Bricklets hast du denn am Servo Brick getestet?

Hrm, da ist wohl einiges schief gelaufen mit dieser Funktion. Ich hab mir die Dokumention gar nicht angesehen, sondern die Firmware. Die Dokumention ist schlicht falsch, sorry. Ich habe sie jetzt korrigiert, danke für den Hinweis.

Hast du schon mal getestet, ob es einen Unterschied macht, wenn du den Stack in einer anderen Reihenfolge zusammensteckst? Step-Down und Master müssen ganz unten bleiben, alles andere darüber kannst du beliebig vertauschen. Wenn du nur Master Brick und WIFI Extension verwendest und über USB versorgst, funktioniert dann die WLAN Verbindung auf dauer besser?

is_light_on() ist nicht negiert. is_light_on() gibt keinen bool zurück, sondern einen uint8 mit 2 definierten Werten LIGHT_ON = 0 und LIGHT_OFF = 1. ilor.light = PIN_LED.pio->PIO_PDSR & PIN_LED.mask ? LIGHT_ON : LIGHT_OFF; Wenn du das als bool betrachten willst dann ist das negiert, ja. Man hätte da einen bool zurückgeben können. So ist es aber nicht definiert worden und jetzt ist es zu spät das zu ändern, sorry.

Das init Script wird als root ausgeführt. Funktioniert Folgendes? sudo java -jar /home/pi/FerienHaus.jar

Ein JAR ist keine ausführbare Datei. Die --exec Option des start-stop-daemons erwartet aber eine ausführbare Datei. Es sollte funktionieren, wenn du DAEMON=/home/pi/FerienHaus.jar OPTIONS=--daemon durch DAEMON=java OPTIONS=-jar /home/pi/FerienHaus.jar ersetzt. Unter der Annahme, dass dein FerienHaus.jar einen Main-Class Eintrag im Manifest hat.

Dein Problem liegt hier: $VALUE_ON = (1 << 3); $iqr->setMonoflop($VALUE_ON, 1, 500); Die Signatur ist so: setMonoflop(int $selection_mask, int $value_mask, int $time) Für die selection_mask nimmst du 1 << 3, also eine 1 um 3 Bit nach links geschoben, in Binär 0b1000 (0b als Prefix für Binär, so wie 0x für Hexadezimal). Damit hast du das Relais 3 (von 0 gezählt) ausgewählt. Für die value_mask nimmst du 1, in Binär 0b0001. Damit gibst du für Relais 0 vor dass es eingeschaltet werden soll und alle anderen ausgeschaltet. Da du mit der selection_mask von 0b1000 aber gesagt hast, dass über haupt nur Relais 3 geschaltet werden soll passiert nichts, da Relais 3 schon aus ist. Die selection_mask sagt welche Relais überhaupt geschaltet werden sollen und die value_mask sagt wie geschaltet werden sollen. 0b1000 selection_mask 0b0001 value_mask In der value_mask werden also nur die Stellen betrachtet, für die in der selection_mask eine 1 steht. Du schaltest also Relais 3 aus und alle anderen bleiben unverändert. Um Relais 3 einzuschalten muss es so aussehen: 0b1000 selection_mask 0b1000 value_mask und daher so in PHP: $SELECT_3 = (1 << 3); $VALUE_3_ON = (1 << 3); $iqr->setMonoflop($SELECT_3, $VALUE_3_ON, 500); Bitmasken können verwirrend sein

Leider nein, das hatte ich schon beim eigenen Ausprobieren getestet, Fehlermeldung "adress already in use" Doch doch, das geht, du musst dann nur für den zweiten Listen Aufruf einen anderen Port nehmen. Standardmäßig lauscht Listen auf Port 4217 auf eingehende Verbindungen von NetIO. Hier mit lauscht das zweite Listen auf Port 4218 für die zweite Ethernet Extension: tinkerforge --host 192.168.2.242 --port 4222 listen --port 4218

Wenn du den Listen Modus so startest tinkerforge --host 192.168.2.241 --port 4222 listen dann werden all Befehle die von NetIO eingehen an 192.168.2.241:4222 geschickt. Für deine zweite Ethernet Extension kannst du jetzt die Shell Bindings in zweites Mal im Listen Modus mit der anderen IP Adresse starten. In NetIO verwendet du dann auch zwei verschiedene Connections. Du kannst aber auch die --enable-host und --enable-port Option des Listen Modus nutzen. Dann kannst du von NetIO aus für jeden Befehl --host und --port setzen. Also tinkerforge listen --enable-host --enable-port und dann in NetIO statt "call ..." --host 192.168.2.241 --port 4222 call ...