remotecontrol

Ich denke, das sollte gehen, Stichwort "linux smstools".

 

Da gibt es vermutlich auch noch andere Möglichkeiten, aber Senden und Empfangen von SMS mit UMTS Stick muss gehen.

Du hast ein VoltageCurrent-Bricklet verwendet?

Und bist Du Dir sicher, dass Du die Pole richtig angeschlossen hast?

 

Das VoltageCurrent Bricklet ist nicht verpolungssicher, sollte aber auch Spannung messen können, auch wenn kein Strom fliesst.

Auf jeden Fall beachten, dass auf der einen Seite des Displays im Gehäuse der Wetterstation Sensoren nach innen ragen. Das nimmt weiteren Platz weg. Ich hab' das nicht alles reinbekommen, was ich da rein haben wollte und bin inzwischen auf ein anderes Gehäuse mit mehr Tiefe umgestiegen.

Kann der Brick durch irgendetwas gestört werden? Ich habe/hatte solche Effekte nur bei:

- Spannungsschwankungen

- Elektrische Störungen durch Motoren, Relais oder Schalter in der Nähe.

 

Dann hat der Brick bei mir einen Reset gemacht.

 

Der Brick hat auch einen Watchdog, der einen Reset auslösen kann (http://www.tinkerunity.org/forum/index.php/topic,673.msg10219.html#msg10219), wie der genau arbeitet weiss ich aber nicht.

Falls das auftreten würde, ist das aus meiner Sicht aber ein Fehler in der Anwendung, die den Brick ansteuert.

Mit dem

deviceIdentifier = BrickletVoltageCurrent.DEVICE_IDENTIFIER

liegst Du richtig. Anhand des Identifiers im Enumerate kannst Du den Typ von Brick(let) erkennen.

 

Bei den Callbacks liegst Du auch richtig: du musst pro Bricklet und Callbacktyp je einen registrieren, also 4x etwas registrieren. Allerdings kannst Du eine Callbackfunktion ggf. wieder verwenden. Das hängt davon ab, wie Du sie implementierst.

 

Wenn Du 4 Funktionen machst, ist damit schon klar definiert, welche Funktion für welches Bricklet wann aufgerufen wird. Wenn Du 2 Funktionen machst (z.B. je eine für Voltage und eine für Current) musst Du in der Funktion anhand des Bricklets (leider doch UID oder User-Parameter) unterscheiden.

 

Ich habe auch eine Anwendung wo ich z.B. zwei Quad-Relais nutze. Da komme ich nicht drum herum, der Anwendung per Konfiguration (konkret UID) zu sagen, welches der beiden Relais welche Kanäle schaltet. Der Enumerate stellt ja keine Reihenfolge sicher.

 

D.h. ich nutze dennoch den Enumerate, weise im Enumerate aber dann anhand der UID (falls ich mehr als 1 Bricklet gleicher Art erwerte) eine bestimmte Funktion zu.

Ich mache das auch so ähnlich, aber in C++ mit Mutex und std::chrono. Damit kann ich bis auf Millisekunden genau (oder auch noch genauer) sagen, wann der Thread wieder aufwachen soll. Wenn der Thread dann 0,4ms rechnet wacht er auch brav nach weiteren 0,6ms wieder auf und verschäft nicht eine ganze Millisekunde ...

 

Damit kann ich diesen Thread dann auch gezielt schnell beenden, wenn das Programm sich beenden soll.

 

Stichworte: std::chrono::system_clock::time_point, std::unique_lock<std::mutex> und std::condition_variable

Ein timer_create funktioniert doch zusammen mit Signal-Handlern. Aus einem Signal-Handler darfst Du aber nicht beliebige Funktionen aufrufen, insbesondere keinen IO Funktionen. Vielleicht liegt eher da das Problem.

 

Die Tinkerforge API nutzt eigentlich keine Signale.

You wrote

send the UDP packets to the Master Brick

, but you mean: you send TCP/IP packets to the brickd service or directly to a master with an ethernet extension?

 

You'll need a TCP socket, not an UPD socket.

 

You followed this instruction: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html#llproto-tcpip?

You should dump your data packet in your code first, then you can compare which bytes sequence you're sending.

Die Anwendung sollte zum Zeitpunkt der Ausführung keine Rechte setzen müssen, das ist klar.

 

Das

ich vom brickv aus für dieses Verzeichnis (nicht für mehr) die Berechtigungen öffnen kann

geht eben nur bedingt: wenn "dieses Verzeichnis" per Default ein bin Verzeichnis ist sollte man das eben nicht ändern und da fängt es dann doch an, dass man etwas mehr Wissen über die Ablaufumgebung braucht, weil man die Skripte je nach Funktion anders einrichten oder starten muss.

 

Ich habe in der Doku gesehen, dass beim Hochladen das Arbeitsverzeichnis angezeigt wird (im Beispiel war es "." was wohl == "/" ist): kannst Du das beim Hochladen auch vorgeben/ändern im brickv?

 

Vielleicht reicht es ja, das Arbeitsverzeichnis auf das HOME-Verzeichnis des RED Users zu setzen.

 

Je mehr Anforderungen die Anwendungen haben, umso mehr muss sich der Anwender auch mit der Umgebung auskennen. Selbst wenn das über brickv ginge: mal einfach globale Schreibrechte auf's "bin" Verzeichnis vergeben ist eine ganz schlechte Idee ...

 

Die Anwendung sollte selber gezielt steuern, wohin sie die Daten schreibt. Ggf. beim Einrichten des Dienstes das Arbeitsverzeichnis explizit setzen auf das HOME Verzeichnis des Dienste Users (ich habe keine RED, kann darum nicht prüfen, welches User das ist). Dann müsste es schon gehen, wenn die Anwendung einfach ins Arbeitsverzeichnis schreibt.

 

Letzteres (einfach ins Arbeitsverzeichnis schreiben) ist kein empfehlenswertes Vorgehen für Dienste. Da verliert man schnell die Kontrolle und sucht verzweifelt, wo denn der Output gelandet ist. Lieber mit einem Parameter arbeiten, der das Zielverzeichnis explizit festlegt.

Wie wird das Skript gestartet? Wenn das als Dienst läuft, dann ist das Arbeitsverzeichnis meist "/" und da hat nur root Schreibrechte. Du solltest sicher stellen, dass Du einen absoluten Pfad verwendest und der Dienste-User Schreibrechte darin hat.

Das Gehäuse bietet innen nur ca. 40mm - 41mm Platz in der Tiefe, da passt kein Stapel aus 4 Elementen rein. Selbst mit dem alten 9mm Masterbrick ergibt sich 12+12+9+12 = 45mm Höhe.

Die Bricklets selber sind ja erstmal relativ "dumm" und die Bricks steuern weitestgehend die Callbacks. Aber viel Speicher haben die Bricks nicht, d.h. einen größeren Puffer kann man da gar nicht einbauen.

 

Eine machbare Funktion wäre wohl, alle X Millisekunden vom LCD einen Callback auszulösen der nur sagt "Timer abgelaufen". Aber das bringt nicht viel. Das kannst direkt in C/C++ machen. Das kommt auch nicht mit den TF Threads in Konflikt.

 

Ich mache das so, dass ich mehrere "virtuelle" Displays habe. Die Anwendung schreibt von beliebigen Stellen/Threads in die virtuellen Displays und ein anderer Thread kontrolliert wann welcher Inhalt auf dem LCD ausgegeben wird - geht wunderbar (nur muss man auf saubere Thread-Synchronisierung achten).

Wobei die GUI ein separates Projekt ist, welches den Emulator als Bibliothek einbindet.

Den GIT Link hatte ich auch vergessen ...

Make a "ping" to your stack connected via WIFI: you might get something below 10ms, but on average I would not rely on this.

 

My experience is that I can transport about 50 data packages per second via WIFI (which makes 20ms per package) and that other WIFI networks in the surroundings have a big impact on the performance.

Mein Emulator kann diese Funktion jetzt auch und die GUI dazu ebenfalls ...

 

http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Stackemulator_%28stubserver%29#Qt_GUI

Welche Spannungen haben die LEDs-Lampen und die Pumpen? Sind das alle 220V Geräte? 5W LEDs würde ich vermutlich mit dem Dual-Relais schalten.

 

Auf jeden Fall dran denken: die Extension muss über dem Master sitzen und nicht drunter.

Die Bricks können ja maximal 1000 Requests pro Sekunde verarbeiten (also max ein Request oder Callback pro Millisekunde), d.h. 2ms ist schon hart an der Grenze dessen, was die IO hergibt und Du hast 2 Callbacks mit je 2ms, also jede Millisekunde ein Callback. Das wird wohl etwas zu viel.

 

Hast Du noch andere Bricks/Bricklets im Stack?

Sehr gut getippt, das war's ... mit einem neueren Treiber geht's jetzt auch unter Windows.

Wenn ich mir die Bindings aus dem GIT Repository selber erzeuge, dann sind die Funktionen da ..

Schöne Funktion, nur scheint die API das noch nicht zu beinhalten:

die Doku hat sie schon, der Download der C-API 2.1.6 enthält die Funktion aber nicht, d.h. die Doku und die Firmware sind da weiter als die veröffentlichte API ??

Auf meine USB3-Ports kann ich auch unter Windows zugreifen - das nutze ich immer zum Speicherkarten auslesen (und schaffe 80MB/s).

 

Funktioniert eigentlich alles, nur der kleine Unterschied mit den Bricks ... Muss aber ein Software-Thema sein, da es unter Linux ja klappt.

CPU-Zeit ist ungleich verstrichener Zeit: sleep(10) wartet 10 Sekunden. In der Zwischenzeit verbraucht Dein Programm nur minimal CPU-Zeit, eben die 0.000271s CPU-Sekunden.

 

Das Programm rechnet ja nicht aktiv vor sich hin, sondern wartet auf Events, d.h. es tut nichts => CPU-Zeit sehr gering => völlig normal.

 

Willst Du CPU-Zeit oder verstichene Zeit (Delta zwischen 2 Zeitpunkten) messen? Delta zwischen zwei Zeitpunkten kannst Du mit gettimeofday Mikrosekunden genau machen. CPU-Zeit geht mit getrusage oder clock.

Aber dann passt doch alles  - was war dann das Problem?

clock() liefert die Processor-Zeit (CPU-Zeit), und das ist wohl nicht das was Du willst - oder?

Dazu kommt noch, dass clock() stark systemabhängig ist - ich habe damit zumindest eher schlechte Erfahrungen gemacht (verhält sich anders zwischen Linux/Windows).

 

Das Ganze soll C bleiben - oder? Dann geht die reine Zeitmessung auch mit

#include <sys/time.h>
struct timeval current;
gettimeofday(&current, NULL);

 

Noch ein kleiner Tipp:

anstelle von

void cb_interrupt(char port, uint8_t interrupt_mask, uint8_t value_mask, void *user_data) {
        // avoid unused parameter warning
        (void)user_data;

sollte auch

void cb_interrupt(char port, uint8_t interrupt_mask, uint8_t value_mask, void *) {

gehen und somit das gleiche Ergebnis bei Warnings liefren.