AuronX

Üblicherweise sind entweder alle Bricks erreichbar oder keines. Bei echten Hardwarefehlern kann sich das natürlich ändern. Bzw. wenn du die Extensions für Chibi oder RSxxx nutzt.

Lesen ist okay, ich schreibe ihn nur ungerne ^^ Ich hatte ja damals überlegt einen Brickd zu schreiben der statt USB-Geräten andere brickd's anschließt, um das Problem der mehrfachen IPConnections für diejenigen zu lösen die selbst nur mit einer Verbindung arbeiten wollen. Allerdings war mir das im alten Protokoll zu stressig, da ich es selbst vermutlich nie genutzt hätte. Beim neuen Protokoll scheint das aber sehr leicht realisierbar zu sein. Danke für die Erläuterung. LG Jan

Hallo, ich meine zwar, dass irgendwo stand, dass es so geplant war, aber zur Sicherheit frage ich nocheinmal nach: der neue brickd wird routing-technisch vollständig stateless arbeiten oder? Also weder routing-tabellen, noch Merker für die Callback-Zustellung o.ä. Oder gibt es doch State den der brickd sich merken muss? (Die Frage kommt auch daher, dass Planung und Umsetzung ja manchmal divergieren ^^) Viele Grüße Jan

Heizungssteuerung alleine ist schon cool, aber das ganze könnte man auch mit Jalousien verbinden. Also bei hoher Temperatur Heizung aus und Rollos runter, im Winter Rollos hoch wenn die Sonne scheint. Villt auch als Tageslichtwecker, je nachdem ob du zu Zeiten aufstehst zu denen üblicherweise Tageslicht verfügbar ist.

Zu der Sache wie du am Besten auf Fehler reagierst: Exception-Handling ist der richtige Weg. Ich muss jetzt ein wenig raten wie dein Script bisher aussieht, ich nehme mal diesen Pseudo-code: foreach (row in MySQLDatabase) { connectToHostAndRegulateRoomTemperature() } das Try-catch soll jetzt also im Fehlerfall diesen einen Raum auslassen, aber nicht die gesamte Schleife abbrechen, also ab damit in den Rumpf der Schleife: foreach (row in MySQLDatabase) { try { connectToHostAndRegulateRoomTemperature() } catch(exception) { logError("could not set room temperature for room X") } } Ist alles pseudo-code, die genaue Syntax von PHP habe ich gerade nicht im Kopf.

Wird das nicht ziemlich nass?

Falls das noch hilft: Die Fehlermeldungen aus deinem Log (nicht aufgelöstes externes Symbol) deuten für mich darauf hin, dass die *.c Dateien der IPConnection nicht mit kompiliert wurden, sondern nur die *.h Dateien. Dann kennt er die Methoden (weil die in den h-Dateien deklariert wurden), kennt aber keine Implementierung (die normalerweise in den zugehörigen c-Dateien liegt).

Mein Tipp wäre es mit etwas anzufangen das auch getypt ist und wo die Syntax der von C++ ähnlich ist (C#, Java). Es spricht nichts dagegen später auch C++ zu lernen, aber damit anzufangen ist mit Sicherheit selbstgeißelei. (kein Anfänger hat es Verdient den Unterschied zwischen Variablen, Referenzen und Pointern verstehen zu müssen ^^) edit: Der Trick ist, dass es mit Programmiersprachen so ist wie mit natürlichen Sprachen: Je mehr man spricht, desto leichter wird es eine Neue zu lernen. Deswegen sollte man mit den leichten beginnen, um erstmal die grundlegenden Konzepte zu verstehen. Nic: wenn ich dich richtig verstehe, dann kannst du ja schon programmieren und hast trotzdem nicht die Muße noch C zu lernen. Dann verstehe ich nicht wie du jemandem ohne Vorwissen gleichermaßen dazu raten kannst doch sofort damit zu beginnen.

@Nic: Damit meine ich, dass C++ noch ziemlich unabstrahiert ist, natürlich besser als Assembler ^^ @Tyche: Das meinte ich ja genau, C++ hat keine andere Logik als andere imperative Sprachen... Es ist nur schwerer zu verstehen, weil es bestimmte Details nicht so gut abstrahiert (was für Profis ein Vorteil sein kann). Aber einen Gefallen tust du dir damit definitiv nicht ^^ Zu deinem Fehler: Du hast jetzt eine Zeile #include "ipconnection.h" (beachte die Anführungszeichen) Und beide dateien liegen im gleichen Verzeichnis. Und trotzdem kommt noch immer die Meldung: Datei (Include) kann nicht geöffnet werden: "ip_connection.h": No such file or directory? Das halte ich für unwahrscheinlich....

Liegt die ipconnection.h im gleichen verzeichnis wie die example_stack_status.c? Sieht so aus als wäre das nicht der Fall. Ich rate grundsätzlich allen die keinen guten Grund haben C/C++ zu verwenden, es auch nicht zu nutzen. Gute Gründe sind beispielsweise: - die Zielplattform unterstützt keine höheren Sprachen (embedded Programmierung) - enorme Kontrolle über Speicher/Laufzeit wird benötigt (moderne 3D Computerspiele) Beim letzten Punkt kommt hinzu, dass man wirklich gut sein muss, um das ausnutzen zu können ^^ Für fast alle "normalen" Anwendungsfälle sollte man sich C++ nicht antun, weil es in höheren Sprachen einfach mehr Spaß macht zu programmieren und viele Fehler aus C++-Welt nicht möglich sind (genug lernen tut man dabei trotzdem). Aber der wichtigste Grund ist, dass es mehr Spaß macht und man deswegen mehr programmiert und mehr lernt ^^

Hast du vorher schon in C/C++ programmiert? Also hast du Vorerfahrungen mit einer der beiden Sprachen?

Der SW-Reset ist notwendig oder nur als "Sicherheitsmaßnahme" gedacht?

Du hast mir gerade bewusst gemacht, dass die TF-Specs auch keine Betriebs- und Lagertemperaturen für die Bricks aufführen ^^

Erinnert mich spontan hieran. Kann aber auch was anderes sein.

@Loeti: Mich nervt es zwar auch, wenn Menschen eine Firma des Namens wegen lobpreisen, allerdings: Wenn ich sowas wie "Apple [ist] eine Sekte" in ein öffentliches Forum schreibe, dann muss ich mich auch nicht wundern, wenn das jemanden stört Ich will jetzt groß rumdefinieren, was "Sekte" eigentlich bedeutet, deswegen mach ich es kurz: Mein Onkel ist kürzlich "ausgetreten" und er musste deswegen nicht um sein Leben fürchten. Vielleicht also doch keine Sekte...

Das ist halt was ich meinte. Ich würde den Ping nur ungern im Stack sehen, weil die Anforderungen zu unterschiedlich sind. Zumal - aber da kenne ich die genauen Randbedinungen bei TF nicht - im Bereich von eingebetteten Geräten ja auch der Speicher stark begrenzt ist. Man möchte also im Normalfall nur die Funktionen in Hardware/Firmware lösen die sich nicht sauber in Software lösen lassen, um so den verbleibenden Speicher für Funktionen nutzen zu können, die ohne Hardware nicht gut gehen (z.B. neue Extensions unterstützen usw). Allerdings kann ja da TF villt mal sagen, wie eng es auf dem Masterbrick derzeit ist. Das weiß ich nicht.

Jo, so wie du es jetzt beschrieben hast ist es i.O. ^^ Ich dachte nur du wolltest für jede Operation ein extra Ping durchführen, das wäre dann zu viel des Guten...

Das verstehe ich gerade nicht... Warum ist es besser den Timeout vom Ping zu bekommen als den Timeout vom Function-Call? Der Ping kann immer nur eine Zusatzmaßnahme sein, um den Stack zu überwachen. Man sollte m.E. nicht vor jedem Funktionsruf explizit einen Ping durchführen, weil es unnötig viel kostet ohne einen unmittelbaren Vorteil zu bringen (Den Timeout könntest du auch so erkennen und der Ping schützt dich nicht davor, dass der Funktionsruf doch einen Timeout kriegt).

Was war ncohmal das Problem bei den anderen Frequenzen?

Es wäre in der Tat möglich, dass die Anwesenheit eines Bricks per ping geprüft wird. Das heißt ich schicke ihm regelmäßig eine Nachricht, dadurch kann ich prüfen ob er noch da ist (also auf Timeout warten). Das in die Standard API aufzunehmen ist m.E. deswegen keine gute Idee, weil die Anforderungen jeweils unterschiedlich sind. Der eine möchte die maximale Bandbreite für seine normale Nutzung des Stacks haben, deswegen sollte der Kanal nur selten mit Pings belegt sein. Das führt aber dazu, dass ich nur mit Verzögerung sehe, dass ein Gerät weg ist. Wenn ich das schnell wissen muss, dann geht das nur auf Kosten der Gesamt-Bandbreite. Anderes Problem: Für dich ist nur der Ausfall des Chibi wahrscheinlich, dir reicht also ein Ping zu einem Chibi-Slave-Gerät. Wenn ich meinen Stack irgendwo aufbaue wo es Vibrationen gibt, dann kann mir auch mal ein Kabel rausrutschen oder sich eine Steckverbindung lösen. Da müsste ich alle Stackteilnehmer pingen. Deswegen halte ich es nciht für sinnvoll möglich "die" Lösung anzubieten. Das Gute: Man kann sich einen Ping einfach selbst basteln. So wie man ihn braucht. Beispielsweise könntest du dafür die GetIdentity-Funktion nutzen.

Tatsächlich musst du das Objekt nicht von der IPConnection lösen oder so. Es wird in dieser Zeit nur nicht großartig reagieren, also weder auf Befehle reagieren (es kommt eine TimeoutException), noch Callbacks liefern. Ich vermute, dass beim Disconnect keine Enumeration kommt. Beim Anschließen jedoch solltest du mitbekommen, dass das Device wieder da ist (enumerate mit CONNECTED) und kannst es dementsprechend auch wieder so konfigurieren, dass es einsatzfähig ist.

Zu der Neuerung: Könnt ihr das noch etwas klarer formulieren? Was bedeutet startup? Warum hilft es, wenn der Callback schon registriert ist, bevor die Verbindung hergestellt wird? Nach meinem aktuellen Verständnis kann ja der startup des Stacks auch lange vor dem Verbinden der IPConnection liegen.

Puh... also wenn es jetzt nicht bloß ein simpler Einheitenfehler ist (Bar statt Millibar oder Pascal oder so), dann bin ich überfragt.

Doch, siehe den Thread den ich verlinkt habe. Das ist allerdings sowas von überhaupt nciht mein Spezialgebiet Du musst halt "nur" die QNH bei dir wissen und schon kannst du die Höhe über 0 bestimmen. Das liegt an sich ändernden Luftdrücken aufgrund von Wetter und so. Warum das jetzt QNH heißt und andere tiefergreifende Fragen kann ich aber nimmer beantworten.

Das mit dem Referenzluftdruck hat FlyingDoc mal ganz gut erklärt: http://www.tinkerunity.org/forum/index.php/topic,946.0.html Kurz: Du kannst den Referenzluftdruck einfach auf den aktuellen Druck setzen (dazu reicht es, ihn per API auf "0" zu setzen). Dann ist die angezeigte Höhe relativ zu der Höhe in der dein Bricklet beim Kalibrieren war. Allerdings ändert sich das ganze relativ schnell wieder, so dass du oft nachkalibrieren musst.