cfranz

R99, Du kannst (bei einem iOS Device, dass Du nicht jailbreaked hast) nur dann eine selbstentwickelte App auf das Device laden, wenn Du die dafür notwendigen Certificates hast. Diese Certs verwendet XCode, um die Executables digital zu signieren, damit iOS sie nicht zurückweist (schützt in der Form auch vor Viren, da deine app, sobald sie von einem Virus oder Drittpartei modifiziert wurde, nicht mehr der Signatur entspricht). Während der Entwicklung gehst Du nicht den Umweg via iTunes, sondern lädst deine App direkt vom Mac (du brauchst einen Mac dafür) auf das Device. XCode kann dann die App monitoren und 'fernsteuern', inklusive dem Lesen aller Variablen, setzen von Breakpoints usw. In einem normalen Entwicklungszyklus kannst Du nämlich davon ausgehen, dass Du deine App 5-10 mal pro Tag (häufiger beim debuggen) auf das Gerät lädst. Da ist es gut, dass Du nicht über iTunes gehen musst... Und hier ist das Problem: die Certificates bekommst Du nur über Dein Developer Account. Und soweit ich weiss knöpft Dir Apple dafür pro Jahr 99 USD ab. Darin sind allerdings (aber nur für professionelle Entwickler wirklich interessant) zwei Support-Anfragen an Apple's engineering enthalten. Wenn Du die Support Cases nicht brauchst, hättest du von den 99$ mehr, wenn du Tabak reinstreust und rauchen würdest - aber das kostet halt der Eintritt. Was allerdings auch ohne zu Zahlen geht, ist der Simulator, der mit XCode kommt. Mit dem kannst Du eine ganze Menge anfangen, solange Du nicht bestimmte hardware ansprichst (bspw. accelerometer). In Verbindung mit der WiFi Extension kann auch der Simulator gute Ergebnisse liefern. Und ohne die WiFi-Extension (oder Ethernet) kann kein iOS-Gerät was mit den TF Stacks anfangen. Gruss und viel Spass, -ch

Gibt es ein Bricklet, mit dem ich Lautstärke (in dB nehme ich an?) messen kann? Ich verstehe ja nicht viel (genauer: gar nichts) von Elektronik, weshalb ich so gerne die fertigen Bricklets verwende. Konkret möchte ich gerne periodisch messen, wie 'laut' es in der Umgebung vom sensor ist. Ist das so elementar umsetzbar, dass niemand dafür einen Brick gebaut hat, so kompliziert, dass es zur zur zeit nicht gemacht werden kann, oder so saublöd, dass es ausser mir niemand braucht? Gruss, -ch

Danke! Das mir dem Step-Down (den ich komplett übersehen habe, weil ich dachte, der sein nur für das Treiben von Motoren da) macht die Sache in der Tat viel einfacher. Ist 'gleichgerichteter stom' das gleiche, was amateure wie ich 'gleichstom' nennen (also z.b. 5V DC)? Und wie ist das mit 'geglättetem' (spannungsstabilisiertem?) gleichstom? Muss ich darauf achten oder macht da das brickli? Oh, und was für werkzeug brauche ich für den stecker? ich habe nix bei mir gefunden, was dafür passend was machen kann. Gruss, -ch

Wenn wir schon bei dem thema sind: Für absolute Elektronik-nieten wie mich ist es schwer, herauszufinden, was für ein Netzteil ich brauche. Leider bietet TF selber ja keine Netzgeräte an, noch empfehlen sie etwas. Wenn ich nicht selber löten möchte, sondern nur mit einer Steckplatine und TF-kabeln arbeite and keine Lasten wie e-motoren treiben will: Habt ihr eine Empfehlung, was ich mir zulegen sollte? Hier um die Ecke ist sogar ein Conrad shop, der eigentlich gut sortiert ist. Danke für jede Empfehlung.

Das stimmt nur bedingt. Wenn Du hart am Metall coden kannst, dann ja. Dann brauchst Du nur kleine oder keine Libraries. Sobald Du aber mit einer 'komfortablen' umgebung arbeiten willst, brauchst du libraries (=platz) oder interpreter (viel platz) und der code wird viel länger. 100 KB ist viel, wenn du mit einem 6502 prozessor arbeitest (mehr, als der addressieren kannst), absolut nichts wenn du mit modernen entwicklungsumbegungen arbeitest. Was natürlich der Ausgangspunkt dieser diskussion ist So wie ich das jetzt verstanden habe, bin ich immer mehr auf den Paspberry Pi neugierig geworden. Braucht es für die Integration irgend was bestimmtes, oder wird der einfach mit usb an den master angeschlossen, der Pi mit strom versorg und alles in einen schuhkarton geworfen? -ch

OK, da sieht man mal wieder, wie wenig ich von hardware verstehe. Ich bin davon ausgegangen, dass es sich bei dem brick nicht um einen 'refurbished master' handelt, sondern einen eigenen Prozessor mit entsprechendem Speicher in der Grössenordnung 8 MB (für programm und variables) oder mehr hat, der nach dem bootvorgang sein programm z.b. von einer SD-Karte zieht. Wie gesagt, ich verstehe davon nix, aber ein 64mbit chip kostet ca 3.00 EUR in kleinen mengen, weshalb ich davon ausging, dass das preislich kein problem darstellt. 100 KB ist weniger als der literal table einer 'hello world' app bei vielen interpretierten sprachen. Autsch. OK, in solchen grössenordnungen hat nur C oder assembler eine chance.

Wenn es simple ist, c (compiliert neheme ich an) auszuführen, dann sollte es auch einfach sein (sofern der speicher gross genug ist) auch beliebige interpretierte sprachen auszuführen. Bspw wird ein Py programm zusammen mit dem interpreter als compiliertes c programm geladen. Der interpreter wird ausgeführt und lässt dann das Py programm laufen. Bereits der alte Apple II funtionierte 1977 mit BASIC so. Wenn es also einen open source Py interpreter gibt, sollte es nicht allzu schwierig sein, so etwas zusammenzuschustern. Der c brick wird also jedesmal mit einem paket bestehend aus interpreter und Py programm geladen. Oder mit einem basic-interpreter und zugehörigem basic-programm etc. Aber evtl habe ich die ausgangslage nicht voll verstanden. Ich ging davon aus, dass auf dem brick ein prozessor läuft, der einen native maschinencode benötigt. Wenn ich dich richtig verstehe, läuft auf dem brick aber Py native? Hab ich das richtig verstanden? Was sind zur zeit die Parameter, die für so ein programmierbares device gelten? Ich dachte ein prozessor, der mit maschinensprache programmiert wird, ein paar MB RAM und etwas IO.

Ich bin mir nicht sicher, dass ich die diskussion ganz verstehe, aber ich bin eventuell auch zu spät erst dazugestossen. Meine Annahme: Ihr wollt einen TF block herausbringen, der die bricks/bricklets direkt steuert, also quasi die Daemon/PC-kombination ersetzt. Nun scheint die Frage zu sein, ob der brick eher in C oder Python programmiert werden soll. Meine Frage: wieso 'oder'? Soweit ich weiss, ist Py eine interpretierte Sprache, C wird kompiliert (also direkter maschinencode). Aus meiner Sicht (die sehr beschränkten ist, immerhin habe ich das letzte mal vor gut 20 jahren einen compiler geschrieben) sind im Endeffekt beide das gleiche. Ein interpretiertes Programm wird halt mit dem Interpreter plus Library und dem byte/tokencode auf den brick gebracht. Ein voll compiliertes programm wird direkt aufgespielt. Das ist doch 'bloss' ein Problem deiner Toolchain. Kann euer compiler nicht automatisch den python zwischencode mit einem interpreter verpacken und als maschinencode auf den chip bringen? Alternativ könntet ihr den chip do entweder als Py engine oder 'straight machine' flashen. So können die C heads direkt (schnelle programme), die pythoners den interpretierten code draufknallen. Und die community kann dann noch interpreter für andere dialekte (z.b. das erwähnte TF-Basic) dazu schreiben Was habe ich übersehen? -ch [eine sache die ich nicht geschnallt habe: wieso wird C hier als Guru-Sprache bezeichnet? C++ meinetwegen. Aber oldskool C ist eher ein glorifizierter Macroassemberl. Das ist nur unbequem, nicht schwierig. Py ist hat viel eleganter.]

Arnim, ich bin mit nicht sicher, dass es für Deine Frage eine eindeutige Antwort gibt. Wenn ich Dich richtig verstanden habe, willst Du auf dem *selben* Rechner eine Art 'Totmann'-Schalter implementieren. Ein countdown wird gestartet, der regelmässig auf den anfangswert zurückgesetzt wird, solange das system läuft. Kann der Countdown erfolgreich durchlaufen, erfolgt der reset-zyklus. Deine Frage ist, ob der daemon immer noch läuft (und daher den countdown weiter laufen lässt), wenn sich der server aufhängt. Falls nein, würde dann der selbst-reset nicht ausgeführt werden. Meine persönliche Meinung: 1. Mit grosser sicherheit wird der daemon und der server auf unterchiedlichen prozessen/threads laufen. In vielen Fällen sollte es funktionieren 2. Es gibt beliebig viele vorstellbare konstellationen, wo der serverprozess absäuft, aber die steuersoftware nicht. In diesem fall wird es keinen reset geben 3. Es wird sicher auch konstellationen geben, wo sich der kernel zentral aufhängt und nix mehr geht. auch dann kommt kein reset. 4. Wie behandelst du false positives? Was, wenn aufgrund unglücklicher umstände der countdown voll durchläuft, obwohl der server läuft? Ich glaube, dass Du nie alle probleme ausschliessen kannst. Am sichersten aber wäre in so einem setup, wenn du zwei unabhängige rechner hast. der eine ist nur dafür da, regelmässig den serverprozess auf dem hauptrechner abzufragen und wenn kein signal kommt, den reset-vorgang auszulösen. So etwas kannst du beispielsweise mit einem Raspberry Pi umsetzen. Aber eventuell habe ich alles falsch verstanden. -ch

Ich glaube, das Wichtigste ist, dass Ihr euch vorher noch einmal genau darüber gedanken macht, wer eigentlich eure Zielgruppen sind, und die dann so ansprecht, dass sich diese Leute verstanden und bei Euch gut aufgehoben führt (Achtung: ich sage nicht, dass Ihr das nicht tut - lediglich, dass ihr es besser könnt). So wie ich das sehe, habt ihr mindestens zwei sehr unterscheidliche Zielgruppen: Da sind die codeheads wie ich, reinste Softwareleute, die endlich einmal mit dem code etwas Hardware steuern möchten. Wir haben marginals Wissen über Digitaltechnik (wenn ihr Glück habt - und selbst meines erstreckt sich nur auf die alte 74LS.. Baureihe), null komma null Erfahrung mit Elektrik/Elektronik. TF ist deswegen für mich interessant, weil ich wenig bis nix Löten muss und mit plug&play dennoch viel hinbekommen kann. Jedenfalls ist das meine Erwartung/Hoffnung. Eure Doku in bezug auf Programmierung ist für mich einfach zu verstehen (das Wort Binding war vom Kontext her klar; 'Interfaces' hätte auch gereicht), aber die Doku richtet sich weniger an Programmierer als an Digitaltechniker - es ist auch einfach zu erkennen, dass das Design eher auf den Bricks/Bricklets liegt als auf der Software (Bindings). Ich hätte mir weniger technische Beispiele gewünscht, mehr (triviale) Schaltbeispiele und Programmierungen um das Spielkind in mir zu fördern. Auch wenn dann der Elektrotechniker an 'Kindergarten' oder 'Lego' denkt. Beipielsweise eine kleine Gruppe von Experimenten geschrieben für euer Starterset plus ein paar Leuchtdioden und eine Steckplatine. Damit 'spiele' ich nämlich rum und habe *extrem* viel spass. Oder *einfachste* Beispiele wie man mit den bricks ein muster von LED ansteuert, eine kleine Alarmanlage baut etc. Worauf ein Depp wie ich achten muss, wenn er andere Dinge anschliessen will. Und ein oder zwei komplette Beispiele, wie man ein oder zwei servos richtig anschliesst, warum das so angeschlossen wird, welchen Spielraum man bei den Bauteilen hat, worauf zu achten ist etc. Und am allerwichtigsten: ihr braucht für 'schreibtischtäter' wie mich ein oder zwei netzteile im shop. Elektronieten wie ich wissen nicht, worauf wir achten müssen. Ein Netzteil, das ausreicht 8 bricks und ein paar Servos zu treiben würde ich mir sofort bei euch kaufen aus dem einfachen grund, dass ich weiss, dass ihr es empfehlt und ich vermute, dass es passt. Die zweite Zielgruppe sind wahrscheinlich elektro- und digitaltechniker, die sich wünschen, ihre designs und geräte mit mehr automatisierung zu versehen oder verschiedene geräte zu einem viel komplexerem ganzen zu verbinden. Diese Leute sind götter der elektrotechnik; mit den Fragen einer IDE, verschiedenen Compilers, OS-Integration, deamons und Kernel extensions kommen sie nur unwillig zurecht. Mit den Bindings selber werden sie weniger Probleme haben (vermute ich), da sie vom Design her eher die 'Sprache' der Hardware abbildet als die Integration in ein OS. Als ich auf der Suche nach einer Möglichkeit war, etwas Hardware mit Software einfach zu steuern, bin ich eher durch Zufall auf Euch gestossen ('hardware mit computer steuern' bringt keinen google-treffer), nachdem ein Programmierkollege an der Uni Stockholm (!) mir einen Tipp gegeben hat. Überzeugt hatte mich dann euer Filmchen. Verstanden hatte ich zwar nur die Grundaussage, aber das hat gereicht. Ich bin sicher, Ihr habt selber ein viel besseres Bild von euren Kunden und es ist gut möglich, dass ihr die bereits perfekt ansprecht. Um mehr SW-lastige Kunden anzusprechen (die nicht gleich vorhaben, einen Raspberry zu verbauen), könntet ihr vielleicht schon ein paar Änderungen anbringen. Hoffentlich habe ich genügend zum Ausdruck gebracht, dass ich all das hier nicht schreibe, um euch blöd anzumachen, sondern weil ich von TF begeistert bin und mir wünsche, dass noch viel mehr Leute an euch Freude finden sollten. Ich habe fertig. -ch

Ich bin gerade dabei, mit einem Ind Quad herumzuexperimentieren und habe eine Anregung: Meine Dual Relays haben eine kleine Leuchtdiode neben jedem relay, die den Status anzeigt (gechlossen = leuchtet). Ist so etwas auch für die nächste revision der quads möglich? Es ermöglich mir das debugging viel einfacher (ich kann schon sehen, ob der code stimmt, bevor ich mit dem messgerät an die pins gehe). -ch

Jetzt klappt's!!! Danke, -ch

ah! jetzt wird auch mir das klar. Danke! -ch

Ich bin gerade dabei, die callbacks von ipcon auzutesten. Die Dokumentation erklärt ja bereits eine ganze Menge, und meine Test sind gut voran gekommen. Eine Interpretation der callbacks von mir aber scheint falsch gewesen zu sein; daher würde ich mich über ein paar mehr Erläuterungen freuen. Aufbau: master mit 4 bricklets hängen via USB an meinem Mac ipcon ist configuriert, dass für alle drei klassen der callbacks (IPCON_CALLBACK_ENUMERATE, IPCON_CALLBACK_CONNECTED und IPCON_CALLBACK_DISCONNECTED) meine callbacks angesprungen werden. Zur Verständnisfrage: Wenn ich während des Betriebes den USB-Stecker ziehe, dann hatte ich erwartet, dass der callback für IPCON_CALLBACK_DISCONNECTED angesprungen wird. Statt dessen erhalte ich (was ja auch logisch ist), 5 mal IPCON_CALLBACK_ENUMERATE mit reason=IPCON_ENUMERATION_TYPE_DISCONNECTED. So weit, so gut - hab ich nun geschnallt. Aber unter welchen Umständen erhalte ich einen IPCON_CALLBACK_DISCONNECTED? Genauer: wie kann ich so etwas testen? Danke, -ch

Ich fürchte, meine elektronik-kenntnisse sind sehr gering (ich weiss gerade mal, warum die steckdose zwei löcher hat: eines für den strom, das andere für die spannung...). Ich habe eben die IO16-doku eingesehen. Die sagt, dass die pins verschieden konfiguriert werden können - unter anderem als input 'floating' und als output low (wahrscheinlich mit GND verbunden - ich verstehe wirklich nicht viel davon). Könnte ich diese beiden states in meiner steuerung dazu verwenden, um das relais zu simulieren? also im normalzustand die pins auf input-floating setzen. Dann zum ansteuern (beispielsweise mittels monoflop) die pins fur 0.5 sekunden auf output low schalten um danach zu input-float zurückzukehren? Könnte ich so das relais in der schaltung durch einen IO blöckli ersetzen? -ch

Das ist natürlich eine hochinteressante frage der philosophie beim programmieren. Klar müssen API aussagekräftig und lesbar sein, doch die Frage ist hier die Interpretation des Wortes 'aussagekräftig' bzw. 'lesbar'. Wenn aus dem Kontext klar ist, um was für ein objekt es sich handelt, ist die 'value' funktion (meiner meinung nach) genau so lesbar wie 'geschwindigkeit'. als code-dinosaurier habe ich natürlich beide arten der programmierung kennen gelernt. dein besipiel ist ein klassischer vertreter der hochverlässlichen programmierung wie sie bei kritischen systemen (z.b. kraftwerken, schiffssteuerungen) zu anwendung kommt: eieindeutiger code, auditierbar, hochgeradig wartbar, sicher. die nachteile (kaum refactoring oder reuse) fallen nicht ins gewicht, weil diese art von code spezifisch hergestellt wird. ich habe selber einmal für ein jahr im team so programmiert - für ein echtzeitsystem einer bank, die damit zahlungen abwickelt. da muss jede zeile sitzen, doppeldeutigkeiten sind ein no-go. der objektorientiere ansatz (generische prozedurnamen - z.b. gibt es in einem grafikprogramm x verschiedene geometrische objekte, die alle die generische nachricht 'draw' kennen) kommt dann zum einsatz, wenn es nicht so auf die code-sicherheit ankommt und der code effizient programmiert (nicht unbedingt ausgeführt) werden soll. in den letzten zwanzig jahren habe ich diese art des programmieres sehr zu schätzen gelernt. in der programmierung von consumer-applications, wo ein fehler keine katastrophalen auswirkungen hat, kann ich so für den bruchteil des aufwandes eine gute, lauffähige app schreiben - die immerhin noch 80% der resilienz einer klassichen secure app hat. wo passen da die TF block APIs ins bild? ich glaube, die art wie heute die bindings erzeugt werden, hat sehr viel damit zu tun. Da viele verschiedene sprachen unterstützt werde sollen, wird ein generator verwendet. bei dem design des generators wurde das augenmerk (meiner meinung nach) darauf gelegt, möglichst schnell und verlässlich ein akzeptables ergebnis zu liefern. Dies erfüllt der generator gut. dass das ergebnis nicht alle glücklich macht war nicht nur vorhersehbar, es ist auch einigermassen irrelevant - denn jeder, der nicht zufrieden ist kann sich ja (so wie ich) hinsetzen und was "besseres" machen - und dann hier darüber philosophieren, wie viel besser die welt doch wäre, wenn er selber das sagen hätte. Nur weil ich hier über das API rummeckere heisst das noch lange nicht, dass es schlecht ist oder meine Lösung besser. Wie heisst es so schön: "gute ideen gibt es viele..." Als 99% software-Typ (ich verstehe fast gar nichts von elektronik) ist es klar, dass ich mich auf die SW stürze und damit rumspiele. Was ich mit meinen bricks baue ist dementsprechend wenig anspruchsvoll. dafür ist die software voll durchgestylt. Am wichtigsten für mich aber: ich habe extrem viel spass. -ch

Ich kann dem Kommentar von teichsta nur beipflichten - ich bin ja gerade dabei, ein abstraktes interface zu schreiben (einen objective-C layer für TF). Nicht nur die relais sind wenig einheitlich - alle Sensoren (so nenne ich die bricks, die einen wert messen und einen A/D-Wert zurückliefern (Temperatur, Entfernung, Feuchtigkeit, Luftdruck etc.). Die prozeduren haben anstelle einer method 'value' einzeln benannte 'humidity', 'temperature' etc. Macht mich wahnsinnig In diesem Zusammenhang ist ein Abstraktionslayer sehr sinnvoll. Ohne falsche Bescheidenheit - die TF-Blöcke in Objective-C zu programmieren (mit meinem Layer natürlich - ich sagte ja *ohne* Bescheidenheit) ist viel eleganter und schneller als mit purem C. Andererseits - wo bleibt denn bei voll durchengineerten Layers der Bastlerspass? -ch

Mal eine blöde Frage: Warum nimmst Du ein IndQuad Relais? Würde Deiner Meinung nach auch ein IO16 funktionieren? Wenn ich das richtig sehe, schaltest Du ja keine grossen Ströme. Oder verwendest Du die Relais, weil Du den Stromkreis vom Sender und den vom TF Brick getrennt hast? Ich frage, weil ich so ein IO16 rumliegen habe, und mich schon lange mit dem Gedanken trage, so was ähnliches zu machen... -ch

Zu allererst würde ich versuchen, ob du beide mit dem brickv sehen kannst, wenn sie an den gleichen master angeschlossen sind. Wenn ja, dann ist das ein hinweis, dass sie sich zumindest theoretisch mögen. Um dir dann zu helfen wäre es wahrscheinlich gut, wenn du uns hier den code zeigst, mit dem du die beiden und die ipcon initialisierst. -ch

Sorry, wenn ich noch mal auf meine Frage zurückkomme. Ich möchte bei meinem IO16 das pin 7 bank A auf FALSE setzten (eine LED ist angeschlossen, die zeigt, dass es zur zeit High ist). Mit char port = 'a'; uint8_t mask = 0x80; uint8_t value = 0x00; io16_set_selected_values(&theIO16, port, mask, value); sollte meiner meinung nach pin 7 auf 0 gesetzt werden. Geht aber nicht. werden geräteseitig eventuell doch die oberen 4 bit gelöscht? Mit der älteren proc char port = 'a'; uint8_t mask = 0x7f; io16_set_port(&theIO16, port, mask); kann ich problemlos das bit löschen. Für mich kein echtes Problem, aber ich habe mir vorhin fast mein letztes Haar deswegen ausgerissen.

Was ist der Unterschied zwischen io16_set_port(IO16 *io16, char port, uint8_t value_mask) und io16_set_selected_values(IO16 *io16, char port, uint8_t selection_mask, uint8_t value_mask) ? Ist set_port das gleiche wie set_selected mit einer selection mask 0b11111111? Wenn ja, müsste es im Kommentar der header doku anstelle von /* The bitmask is 4 bit long, nicht heissen: *8* bit? <kratzt sich am Kopf> Jedenfalls bei allem was ich herumexperimentiere sieht das so aus...

OK, ein kurzer update: Über der Wochenende habe ich den Layer auf das neue TF-Protokoll emigriert - und er funktioniert schon! Aber das beste: mit dem neuen TF-Protokoll kann der Layer nun auch callbacks unterstützen (was ja bekanntlich mit objektive-C messages nicht geht). Callbacks gehen im Cocoa-Layer via delegate objects und dem niegelnagelneuem TDevice-Protokoll. Muss jetzt noch die Doku updaten und ein paar neue objekte einbinden - dann sollte der neue Layer für eine erste Testrunde bereit stehen. Bastian - ich werde dann auf Dich zukommen, damit wir die neue version gleich in die Ecke stellen können, die Du dafür bereit gemacht hast. -ch

Zur Zeit sind die callbacks noch nicht mit Cocoa verwendbar - eine Objective-C Method kann bekanntlich nicht als callback für eine C/C++-Prozedur übergeben werden (Limitation der Sprache/LLVM). Sobald die TF 2.0 Bindings definiert sind (sind je bereits im test, wenn ich das richtig gesehen habe), haben die Callbacks einen (void *) pointer, mit dem wir das Objekt übergeben können, welches als delegate die callbacks umsetzt. Sofern dein Objekt dann das (noch zu definierende) Cocoa-Layer (Objective-C) TinkerForge-Protokoll unterstützt, geht das auch mit den Delegates. Habe mir noch nicht allzuviel gedanken darüber gemacht, aber nie Änderungen am Cocoa-Layer sollten sich in Grenzen halten. Als resultat haben wir dann hoffentlich einen layer, der der eleganz der TF-bausteine gerecht wird. C hat das ja nicht Gruss, -ch

Danke, Bastian - hatte das natürlich gesehen, aber war noch nicht dazu gekommen (= zu faul) die doku umzuformatieren. werde mich mal in den nächsten tagen dranmachen. gruss, -ch

(english summary: new version of cocoa layer that contains minor bug fixes, plus new objects for the folowing: Master Brick (incl. all extensions), Temperatrue Bricklet, Barometric Pressure Bricklet) Frohes neues Jahr! Weihnachten ist vorbei und der Weihnachtsmann hat mir ein paar neue bricklets mitgebracht. In der neuen Version des CocoaLayers sind die folgenden objects neu enthalten: - Master (mit allen extension) - Temperature - Barometric Pressure Viel Spass, -ch Tinkerforge_Cocoa_Layer.zip