Equinox

Naja, so würde ich das nicht sehen. Für Java sind die 100KB ja wohl zu klein und wenn man dann auch noch das komplette Java haben will sowieso. Mich würde aber auch interessieren, bei was ich mit On Device Programming Vorteile habe gegenüber einer Lösung mit z.B. dem Raspi. Klar ist es schicker, wenn man keinen zusätzlichen Rechner braucht, aber im Moment stellt es sich für mich so dar, dass ich damit dann mit einigen Einschränkungen leben muss. Also: Was konkret kann man damit machen (mit den momentanen Einschränkungen), das Riesenvorteile gegenüber den momentanen Möglichkeiten hat? Keine Speicherwereiterung möglich? Das finde ich jetzt schwach Als ich das auf meine Wunschliste gesetzt habe, hieß es, dass es möglich sei.

Da haben wir uns wohl missverstanden. Die Variablen sollten natürlich nicht auf der SD-Card liegen. Unter "Speicher"-Brick verstehe ich ein RAM, Main Memory, Hauptspeicher. Damit dürfte dann auch klar sein, warum ich da kein Flash will bzw. brauche. Also: Die Programme liegen auf der SD-Card und werden dann in den "RAM-Speicher" Brick geladen (kann natürlich auch alles auf einem Brick integriert sein, was ich auch bevorzugen würde). Ausgeführt werden die Programme im RAM, ebenso können dort Variablen etc. abgelegt werden. Dieser RAM ist völlig unabhängig vom Speicher in dem die Firmware liegt. Ehrlich gesagt halte ich das auch für besser, da ich mit meinem Programm nicht mit der Firmware ins Gehege kommen will (weder organisatorisch noch technisch auf dem Brick). Also im Prinzip wie auf einem Raspberry PI. Das Ding lädt die Programme auch von einer SD-Card in den RAM und führt sie von dort aus. Ich hoffe, das wurde jetzt klar, wie ich das meine. Die Programme waren aber auch weder in C noch in Python geschrieben Wie sieht es im Vergleich dazu mit Python aus?

Was ist der Grund, warum es ein Speicher-Brick nicht geben wird? Es muss auch nicht ein Flash-Speicher sein. Es würde reichen, wenn man Programme von der SD-Card liest und dann in den Speicher einliest. Zusätzlich könnte man dann dort noch Variablen usw. ablegen, auch als eine Art "Shared-Memory", auf das man von allen Clients aus zugreifen kann. Ich halte das für wesentlich sinnvoller als nur ein "SD-Card Brick". Dies würde vieles ermöglichen bzw. vereinfachen. Bei nur 100KB stellt sich mir sowieso die Frage, ob sich da On Device Programming lohnt. Ich vermute, dass damit dann nichts "großes/komplexes" realisierbar ist. Gibt es Abschätzungen, wie groß z.B. ein Python- oder C-Programm (in Lines of Code) maximal sein darf? Im Moment habe ich das Gefühl, dass On Device Programming nur mit größerem (Haupt-)Speicher Sinn macht.

Die Plattformunabhängigkeit gilt für Python nur eingeschränkt. Vtml. würde ein Programm, das auf dem PC entwickelt wird und man ein paar Dinge beachtet auch auf den TF-Bricks laufen. Aber Java ist sehr weit verbreitet (nicht nur bei "einigen") und läuft auf Millionen von Endgeräten. Es wäre doch z.B. super, wenn das Programm unverändert auch auf deinem Android-Handy laufen würde, oder? Mit Python geht das sicher nicht. Abgesehen davon, glaube ich, dass die 200N/s bei Java für 99,5% der Fälle locker ausreicht. Und Python wird als interpretierte Sprache vmtl. auch nicht an die 1000N/s rankommen. Ok, ich wußte nicht, dass ihr nur 100KB zur Verfügung habt. Das wird mit Java wohl wirklich nicht gehen. Allerdings bin ich auch davon ausgegangen, dass die Programme auf einem extra Speicher-Brick liegen (wie hier vorgeschlagen wurde). Das halte ich in jedem Fall für sinnvoll, egal bei welcher Sprache. Diese Einschränkung (100KB) ist meiner Meinung nach ein größeres Problem als die "nur" 1000N/s.

Um doch nochmals Java ins Spiel zu bringen: Die Plattformunabhängigkeit ist doch ein geniales Argument dafür. Man könnte seine Programme ausführlich auf einem PC/Mac/Raspi testen und sie dann völlig unverändert auf den TF-Stapel schieben. Ist doch super, oder?

Um es gleich voraus zu schicken: Ich kann weder Python noch (richtig) C (deshalb bin ich ja auch für Java). Für Python spricht die leichtere Erlernbarkeit und der unkompliziertere Umgang, da es eben nicht compiliert werden muss. Klar, dadurch ist es langsamer, aber wenn ich daran denke, dass ich ein C-Programm compilieren und dann evtl. noch irgendwie mit zusammen mit dem Firmware-Code flashen muss, dann stellen sich mir alle Haare zu Berge. Ein "oberflächliches" C wäre meiner Meinung nach auch zu proprietär. D.h., wenn ich schon eine neue Programmiersprache lernen muss, dann sollte sie auch anderweitig einsetzbar sein. Ich denke auch, dass die allgemein die Hemmschwelle bei Python geringer ist. Und es sollen ja möglichst viele in den Genuss kommen, ohne Rechner die TF-Teile nutzen zu können.

Wie schon einige vor mir, bin ich auch der Meinung, dass der Fokus nicht auf der Geschwindigkeit liegen sollte, sondern auf der Anwendbarkeit bzw. Nutzbarkeit (zumal noch nicht wirklich viele Beispiele für 1000N/s gekommen sind). Ich denke, dass es zunächst einfach mal wichtig ist, ohne Rechner TF nutzen zu können, und das möglichst einfach, was für mich ganz klar für eine Hochsprache (höher als C) spricht. Aus meiner Sicht reichen die 200 N/s mit einer JVM locker aus und würde On Device Programming für sehr viele interessant machen.

Hallo, ich schließe mich JavaLaurence im englischen Thread an. Ich würde es auch bevorzugen, wenn man in Java auf den Bricks/Bricklets programmieren könnte. Wäre das soviel aufwändiger? Falls das nicht machbar ist, dann bin ich für Python.

Hallo The_Real_Black, ich bin leider auch kein Experte für Linux und schon gar nicht für Tomcat, aber hast du schon probiert, die Installation mit "sudo" auszuführen? Ansonsten hilft dir bestimmt Herr Google (ich habe vor einiger Zeit mal eine schöne Anleitung gefunden, wie man das alles auf dem Himbeerkuchen installieren kann, finde den Link aber natürlich im Moment nicht ...) Was meinst du mit "Package für Eclipse"? Für den Raspberry Pi brauchst du kein spezielles Package für Eclipse. Einfach Java installieren und mit den ganz normalen Java-Klassen in Eclipse entwickeln und dann auf den Raspi schieben. Oder habe ich da was falsch verstanden?

Hallo, die Chibi-Extension hört sich interessant an. 2km Reichweite sind super und 250kbit/s reichen völlig aus. Wenn man das jetzt noch zu einem vernünftigen Preis in die Bricklets inkl. Stromversorgung integrieren könnte, wäre das super (man braucht dafür, wenn ich es richtig verstanden habe, noch immer einen Master, die Extension, die Stromversorgung und das eigentliche Bricklet. Das sollte möglichst nur ein kleiner Baustein sein). Und auch der eine Master sollte nicht per USB, sondern auch per WiFi angebunden werden können.

Hi, das ist natürlich wirklich schade Wie würde es aussehen, wenn man statt der Knopfzelle auch einen USB-Anschluss zur Stromversorgung wie am Master-Brick verwenden würde? Das würde die Flexibilität natürlich gegenüber der Lösung mit der Knopfzelle einschränken, wäre aber trotzdem flexibler als die momentane kabelgebundene Lösung. Oder wie wäre eine Art "Step-Down-Supply" für Bricklets, sozusagen eine Stromversorung, die direkt an die Bricklets angeschlossen werden kann, also nicht über den Stapel? Wie würde es preislich bei der Funksteckdose aussehen? Wie sieht es mit der Realsierbarkeit und den Chancen für die anderen Wünsche aus?

Hallo, bei den "Funk-Bricklets" (also den Sensoren für Temperatur, Luftfeuchtigkeit, usw.) dachte ich nicht an eine Stromversorgung per Steckdose, sondern (um möglichst unabhängig in der Platzierung zu sein) an Knopfzellen. Die Funkreichweite sollte natürlich möglichst groß sein (keine Ahnung, welche "Technologie" hierfür am besten geeignet ist. Wäre BlueTooth günstiger?). 50€ - 60€ wären mir aber definitiv zu viel. Ich habe auf max. 15€ - 20€ für die Bricklets gehofft. Die zugehörige Master-Extensions kann dann schon eher bei 40€ bis 50€ liegen. Die Funksteckdosen dürfen meiner Meinung nach preislich auch über den aus dem Baumarkt liegen (können ja dann auch mehr), ich denke an max. 20€-25€ pro Steckdose (im Baumarkt bekommt man das 3er-Set ja schon für 12€ inkl. Sender. Wäre natürlich schön, aber ist mit klar, dass das nicht geht). Vielleicht kann man bei den Master-Extensions ja auch Synergie-Effekte nutzen, d.h. z.B. einen "Super-Master-Brick" bauen, der die Funktionen des jetzigen Master-Bricks plus WiFi plus "Funk für Steckdosen/Bricklets" plus Memory hat? Wie sieht es denn grundsätzlich mit der Realsierbarkeit der Wünsche aus und falls es geht, wie stehen die Chancen, dass sie erfüllt werden? Oder habe ich hier vollkommenen Quatsch von mir gegeben?

Hallo, nein, das halte ich für "überdimensioniert". Ich denke dabei, wie gesagt, an die "einfachen" Sensoren zur Messung der Temperatur, der Luftfeuchtigkeit usw. Vielleicht gibt es ja auch mal einen Magnetschalter(?) o.ä. zum Überwachen, ob eine Tür oder ein Fenster geöffnet wurde. Ich denke, da jedes Mal einen Master Brick, eine WiFi Extension (mit Antenne) und ein Step-Down-Supply anzubringen ist sehr teuer aus Platzgründen zu groß aufwändig zu verwalten/programmieren Man bräuchte natürlich ein "Funk"-(Master?)Brick, der die Verbindung mit den Sensoren herstellt. So ein Sensor müsste dann "nur" noch funken können und mit einer Knopfzelle versorgt werden. Die Sensoren sind ja ziemlich klein (was gut ist). Das sollte auch kabellos so bleiben, damit man sie möglichst unauffällig auch über größere Strecken verteilen kann. So kann man dann z.B. die Temperatur/Luftfeuchtigkeit an mehreren Stellen in einem Raum (oder außen) bzw. in mehreren Räumen messen. Auch mehrere (der noch nicht existierenden Magnetschalter) könnten so einfach zur Überwachung mehrerer Türen/Fenster eingesetzt werden.

Hallo zusammen, ich habe zwar noch nicht sehr viel Erfahrung mit den Bricks und Bricklets, aber bisher bin ich echt begeistert. Trotzdem habe ich ein paar Wünsche. Hier meine (unsortierte) Liste: [*]Ich habe gesehen, dass sich schon jemand ein "Memory" Brick wünscht, allerdings für SD-Karten usw. Ich würde diesen Wunsch erweitern für einen "Shared Memory" Brick, d.h. eine Art "Hauptspeicher" auf den von den Clients aus zugegriffen werden kann. Ich stelle mir dabei einen assoziativen Speicher, d.h. Hashtable, vor. Der Speicher muss nicht groß sein (1 MB reicht völlig) und es würde auch genügen, wenn man "Strings" ablegen kann. D.h. man bräuchte 2 Methoden: memoryBrick.setValue(String varname, String varvalue) String varvalue memoryBrick.getValue(String varname) Warum das Ganze? Ich finde, es würde vieles vereinfachen, wenn man "Zustände" auf den Bricks ablegen könnte, vor allem, wenn man mit verschiedenen Clients (z.B. ein Steuerprogramm auf einem Raspberry Pi und ein anderes Programm auf einem Handy) auf die Stapel zugreift. [*]Super wäre es, wenn dieser "Memory Brick" dann zusätzlich noch einen Logger hätte, der Events (je nach einstellbarem Debug-Level) automatisch in eine Datei (auf der SD-Karte) protokolliert. Ich denke, das würde die Fehlersuche enorm erleichtern. (Ich habe z.B. das Problem, dass Callbacks aus bisher nicht nachvollziehbaren Gründen plötzlich aufhören. Es wäre schön, wenn man auf den Bricks nachschauen könnte, was passiert ist) [*]Es wäre schön, wenn es Bricks/Bricklets geben würde, die mit dem Home Automation Standard "KNX" kompatibel wären. [*]Ich hätte auch gerne eine "fertige" Funksteckdose, d.h. ein Funkbrick sowie passende Funksteckdosen. Bei den Funksteckdosen sollte es auch möglich sein, den Zustand abzufragen. [*]Super wären auch Bricklets, die kabellos, d.h. per Funk, ansprechbar wären. Die Bricklets könnte man z.B. per Knopfzellle mit Strom versorgen. Ich denke da z.B. an die Temperature- oder Humidity-Bricklets, die ich gerne etwas verteilen würde. [*]Schön wäre es auch, wenn die Callback-Period pro "Client" einstellbar wäre. Ich habe z.B. ein Programm, dass ca. alle 5 Sekunden die Werte von Sensoren (z.B. Humidity) per Callback bekommt. Wenn ich jetzt zwischendurch mit dem Brick-Viewer das Humidity-Bricklet "abfrage", dann kommen die Callbacks in viel kürzeren Abständen auch bei meinem Programm an (was kein großes Problem ist). Wenn ich aber die Verbindung im Brick-Viewer kappe, dann kommen keine Callbacks mehr an (das sollte übrigens meiner Meinung nach auch dokumentiert werden, dass der letzte, der die Callback-Period setzt, gewinnt). Als Zwischenlösung schlage ich vor, dass man die momentan gesetzte Callback-Period abfragen kann. Wenn ein Client dann die Verbindung abbricht, dann kann er sie auf den alten Wert zurücksetzen. [*]Last but not least hätte ich gerne einen "StateChanged-Listener" für das Dual-Relay Bricklet, d.h. ein Listener, der informiert wird, wenn das Relais geschaltet wird. Ich weiß, viele der Dinge sind jetzt schon über "Umwege" machbar, aber es sind eben "Umwege".