AuronX

Hat der RPi denn einen AD-Wandler? Dachte der hätte nur binäre Inputs...

Ich gebe dir recht Loeti. Wenn zum Start des Brickv schon ein Callback aktiv war, dann sollte er zumindest am Ende nicht deaktiviert werden. Vorsichtiger kann man aber leider nicht mehr sein. Beim Beenden beispielsweise den Wert vom Start wiederherzustellen ist beispielsweise auch nicht für Anwendungen geeignet, die zwischendurch Änderungen am jeweiligen Wert vornehmen. Deswegen sollte grundsätzlich klar sein, dass zwei Anwendungen aktiv aufeinander abgestimmt werden müssen, damit sie sich parallel verbinden können.

In diesem Bereich sind aber viele weitere Probleme denkbar: - Period wird nur angepasst (statt alle 50ms nur alle 5s) - Threshold wird angepasst - irgendwelche anderen Settings werden überschrieben Am Ende muss man einfach festhalten, dass keine zwei beliebigen Anwendungen auf den gleichen Stack zugreifen dürfen. Wenn beide Anwendungen von dir stammen, dann kannst du natürlich Spielregeln einhalten durch die das trotzdem funktioniert... (etwa: Einheitliche Periods, kein Abschalten bei Schließen der Anwendung usw.)

Mir war ehrlich gesagt neu, dass irgendwelche Callbacks ausgeschaltet werden, wenn sich ein Host disconnected...

Ja

Abgesehen von dem Problem mit dem "Hänger": Einfach mal den Enum-Callback registrieren und nen log o.ä. schreiben, wenn sich dort was regt. Dann siehst du, ob der "robuste Ansatz" dein Problem beheben würde oder ob das auch nciht helfen würde.

Das kann passieren wenn du nur Setter und keine Getter nutzt. Du kannst aber die Setter so einstellen, dass auch diese auf eine Bestätigung warten und sonst eine TimeoutException werfen, müsste in der Doku zu finden sein. Wenn der Prozess normal geschlossen wird, dann wird in der Regel das Betriebssystem hinter dir aufräumen und die Verbindungen beenden. Bei einer Zwangsbeendigung des Programms oder Stromausfall würde das OS nciht aufräumen, die Verbindungen würden also halb-offen bleiben. Das würde der Brickd nur dann merken, wenn er Daten sendet (dann kommt nämlich das WSAECONNRESET).

Man sieht das alles schick aus

Ach witzig... das sah so kontrolliert aus wie sich das IR-Bricklet bewegt hat ^^

Warum bewegt er sich in die eine Richtung immer so fix und in die andere zittert er so langsam? War das absicht (zwei Geschwindigkeiten probiert) oder ist das ein ungeklärtes Phänomen? Sieht auf jeden Fall ziemlich cool aus Im eigenen Drucker gedruckt oder online drucken lassen?

Uh that looks darn pretty! very nice!

Du würdest im Keller folgendes brauchen: - LAN-Extension - Master-Brick - das Bricklet das du eigentlich haben willst (Temperatur oder was auch immer) Das kannst du dann mit einer neuen Connection ansprechen, einen brickd brauchst du in diesem Fall nicht. Deine Software kann den Stapel unmittelbar ansprechen. Um weiter nachzuhaken: Wäre es für dich sinnvoll beide Stapel über eine Verbindung anzusprechen? Habe schon länger überlegt mal nen naiven Multiplexing-brickd zu bauen. Damit man eben viele Stapel über eine Verbindung ansprechen könnte...

Nope... I currently only have "random value" bricklets for the basic gettable devices (Temperature, Ambi, Barometer). I think I don't support threshold callbacks, but I don't remember surely (I started implementing that once...)... There is currently no UI or anything involved, thatswhy I did not implement any "settable" device (like a DC Brick or an LCD). What would you need from an emulated LCD? Output on the screen? Console or GUI? only responding via API? Best regards Jan

I believe sending the data only when requested is a good option, but it leaves the open API... Looking at the method GetWifiEncryption I am not quite sure if it is neccessary to be able to retrieve the key-component. Sure it is convienient, but to argue with common practice in password-field: It is possible to Ctrl+V into a password-field, but it is usually not possible to Ctrl+C out of a password-field. Which purpose - other than displaying the password to the user after reconnect - does reading it have? You might just return an empty string for the key in GetWifiEncryption... You might also want to show a warning before saving the password, whenever the brickv is not connected to localhost...

In contrast my approach is on the TCP/IP-side, so it works with all languages. However it is written in C#. On the other hand I did not currently implement hardware-backing, though that would be a nice option My rough estimate would be that Java is one of the more popular languages here, only based on my feeling about forum posts.

Das war nur auf den von mir zitierten Stichpunkt bezogen... Der Stand da so für sich, dass ich den Eindruck gewonnen habe du würdest eine höhere Hürde in der vorhandenen .NET-Anwendung sehen als in einer (imaginären) vorhandenen Java oder Python-Anwendung. Sollte ich das falsch verstanden haben, bitte ich meinen Kommentar nur als Ergänzung zu deinen Ausführungen zu betrachten

@rifmetroid/Fabian: Thanks for cross-posting that... I nearly didn't see it. Indeed I lay some foundations for that in C#, my Thread also links to the corresponding github-page. I think my current design is quite okay... I really tried to reduce the amount of duplicated code as much as possible (especially for the Brick(let)-implementations). @JavaLaurence: Have you already written some code that you like to share?

C#-Bindings mittels pInvoke sind auch "legales" C# ;-) Aber ich verstehe schon was du meinst... I would also be interested in such statistics, however... I am not sure if download-statistics would be sufficient to give n indication... but they might be...

So sehr ich sowohl C als auch C++ nicht mag: Aber ich finde es noch immer komisch die C-Bindings gleichzeitig als C++-Bindings zu verkaufen. Klar es funktioniert. Aber die C-Bindings müssen sich ihre Objekt-orientierung selbst bauen, während das in C++ alles da wäre. (ich bin gerade wieder drauf gekommen, weil __makx was von Präfixen geschrieben hat... namespaces... geht natürlich nur in C++) Vielleicht wäre das nochmal was? (das "es funktioniert"-Argument würde ja auch für viele andere Sprachen gelten, die native Libraries einbinden können)

Naja... Am Ende musst du halt einen Mechanismus finden der für dich funktioniert. Ein beispiel fällt mir gerade noch ein, funktioniert aber nur bei korrekten Umgebungsbedingungen: Falls der Sensor einen Wert bis maximal 12 °C ausgibt, dann ist es ein Außensensor. Bei über 15 °C ein Innensensor. Das funktioniert im Winter in Deutschland vermutlich recht zuverlässig. Wenn man weiter darüber nachdenkt frage ich mich, wie es noch automatisierter gehen sollte? Also welchen Vorteil hättest du zum Beispiel bei unterschiedlichen Device-Identifiern für alle Temp-Bricklets? Du müsstest dir dann auch wieder merken welcher Identifier zu außen und welcher zu innen gehört. Das hängt ja immer davon ab, wofür du es benutzt.

Alle deine Temperature-Bricklets haben den gleichen Device-Identifier, denn sie sind alle Temperature-Bricklets. Wenn du jetzt mehrere gleiche Bricklets mit unterschiedlichen Aufgaben hast, dann geht das nicht voll-automatisch, sondern du musst es konfigurieren. Option 1: UIDs kennen Du kennst zu jeder UID die "Aufgabe", also außen/innen/oben/unten. Das bietet sich dann an, wenn du dein setup eh nur einmal aufbaust. Option 2: Anschlussort kennen Hier weißt du nur: "Der Außensensor wird immmer an Port A angeschlossen, innen immer an Port B". Das sind Daten die du auch beim enumerate bekommst. Das bietet sich an, wenn du mehrere gleiche Aufbauten hast, etwa Wetterstationen o.ä. Advanced: Stell dir vor du hast 8 Temperatursensoren, dann musst du nicht nur unterscheiden, ob sie an Port A oder B angeschlossen sind, sondern auch ob es Port A vom ersten oder vom zweiten Brick ist.

Das ist einfach nicht korrekt. Du brauchst Mono, das ist korrekt. Das mal eben wegzulassen ist aber genauso wie zu sagen Java würde unter Linux nicht laufen, weil du die JVM brauchst. Ich rede hier nicht von WinEMU oder einer vollwertigen VM in der Windows läuft, Mono ist einfach nur die Laufzeitumgebung für C# (so wie Python-Programme die Python-Umgebung brauchen, Java-Programme die JVM, Ruby-Programme die Ruby-Umgebung usw. usf.) Sofern dein VB.Net-Projekt gegen das .NET-Framework 2.0 gebaut wurde läuft es mit Sicherheit. Falls es gegen eine höhere Version gebaut wurde (3.5/4.0) läuft es noch immer mit hoher Wahrscheinlichkeit. Ich verstehe nicht warum alle Welt so tut als wäre C# eine reine Windows-Kiste, nur weil es von Microsoft entwickelt wurde... Das geht nicht gegen dich nic, weil es wirklich so ziemlich alle tun denen ich begegne... .NET-Anwendungen sind plattformunabhängig, sofern du ein CLR für deine Plattform hast. Unter Linux ist das Mono. Du kannst sogar die gleichen Assemblies nutzen, musst also nicht wie bei C für verschiedene Plattformen kompilieren. Das beste Beispiel ist übrigens TF. Soweit ich weiß werden die C#-Bindings die man hier runterladen kann unter Linux mit Mono gebaut. edit: Wie sich herausstellt ist die Situation sogar besser als ich dachte. Ein kurzes Zitat von dieser Seite:

Wie man die WIFI-Ext konfiguriert steht bei der Master-Doku: http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_CSharp.html#BrickMaster::SetWifiConfiguration__string.byte.byte[].byte[].byte[].i

Wie wäre es einfach nur den Changed-Callback zu nutzen und dann selbst innerhalb der Callback-Behandlung zwischen den Wertebereichen zu switchen? Mehrere Wertebereiche mit jeweils unterschiedlichen Callbacks sind leider nicht möglich.

Historisch ist die korrekte Antwort: Am Anfang war der brickv mitsamt samba.py. Als ich also das Flash-Tool geschrieben habe, habe ich es zum brickv geschoben, um diese Datei nicht kopieren zu müssen (Code-Duplikation vermeiden). Wenn man es ganz genau nimmt müsste mit den einzelnen Komponenten folgendes passieren (aus einer modularen Sicht): - samba.py wandert in eine flash-library, also eine eigenständige Bibliothek um flashen zu können. Möglicherweise auch eine TFLib, für alles mögliche das mit TF zu tun hat - brickv bleibt alleine und hängt von der FlashLib/TFLib ab - flash-cli wandert in eigenes Paket und hängt ebenfalls von der FlashLib/TFLib ab (man könnte auch argumentieren, dass die flash-cli zum brickd wandert und dieser von der Lib abhängt, allerdings würde dann der neue C-brickd von Python abhängen)