raphael_vogel Geschrieben July 24, 2013 at 14:57 Share Geschrieben July 24, 2013 at 14:57 Hi TF team Die Timeline ist ja nicht mehr aktuell. Auf was kann ich mich denn freuen? An welchen Themen seid ihr denn im Moment gerade dran. (On Device programming? Sonic range? ....) Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 24, 2013 at 16:53 Share Geschrieben July 24, 2013 at 16:53 Ja, wir wissen auch nicht so genau was wir da machen sollen. Die Feststellung ist: Wir können Termine bzgl. Hardwareentwicklung nicht wirklich einhalten. Da gibt es einfach zu viele Ungewissheiten. Ich denke wir sollten da vielleicht eine "Produkthistorien"-Seite draus machen mit einer Vaporware-Sektion unten drunter wo Produkte aufgelistet sind die evtl in näherer Zukunft kommen könnten . Es gibt bei uns übrigens immer die Möglichkeit auf github die letzten paar commits durchzugucken, wir entwickeln ja schließlich öffentlich . Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 24, 2013 at 18:06 Share Geschrieben July 24, 2013 at 18:06 Ich bin dafür die Timeline beizubehalten, aber einfach die Zeiten zu streichen... SO eine Art semipriorisierte Liste. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben July 24, 2013 at 18:55 Share Geschrieben July 24, 2013 at 18:55 Na ja ein ungefährer Zeitpunkt wäre schon schön, und wenn es mit +/- x-Wochen angegeben wird. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Bralph Geschrieben July 24, 2013 at 20:27 Share Geschrieben July 24, 2013 at 20:27 d.h. ihr plant zusätzlich ein Tasterbricklet sowie Neigungs-, Regen- u. Feuchtigkeitssensor. Wird dann wohl auch eine Wetterstation 2.0 geben!? Nicht schlecht, ist ja einiges in der Pipeline… Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 26, 2013 at 09:41 Share Geschrieben July 26, 2013 at 09:41 sowie Neigungs-, Regen- u. Feuchtigkeitssensor So ganz kann ich dem nicht folgen Ein Neigungssensor z.B. ist sicher nicht schlecht aber dazu gab es im Forum weniger Nachfrage als etwa zu einer Neuauflage der Chibi-Extension oder ein Schnittstellen-Bricklet für RS-232 :'( Ja, wir wissen auch nicht so genau was wir da machen sollen Wenn sich das auf die OnDevice-API bezieht, so sollte man das Thema nicht ganz aus den Augen verlieren, denn dazu war das Feedback hier im Forum zu groß. Wenn es technologisch (noch) nicht lösbar ist, so würde ich kleinere Schritten in diese Richtung mir mehr wünschen, als eine monolithische API die niemals kommt. Erste Schritte wären z.B. ein Tutorial wie die komplette Entwicklungsumgebung dazu einrichtet wird und wie man die dabei entstehenden Fallstricke und Besonderheiten sicher behandelt. Hierzu gibt es zwar Beiträge im Forum, die m.E. aber für Anfänger zu kryptisch und unvollständig sind. Ideal wären Schritt-für-Schritt Anleitung wie die FW bzw. Plugins der Bricklets um einfache Funktionalität erweitert werden kann. Ev. reicht es auch für viele Zwecke aus, das direkte Ansprechen von Bricklet-Daten am Brick, z.B. Endlagenschalter via IO Signale ohne Umweg direkt am Brick auszuwerten. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 26, 2013 at 12:06 Share Geschrieben July 26, 2013 at 12:06 sowie Neigungs-, Regen- u. Feuchtigkeitssensor So ganz kann ich dem nicht folgen Ein Neigungssensor z.B. ist sicher nicht schlecht aber dazu gab es im Forum weniger Nachfrage als etwa zu einer Neuauflage der Chibi-Extension oder ein Schnittstellen-Bricklet für RS-232 :'( Wir planen einen Schwung von neuen günstigen Bricklets vorzuziehen bevor wir wieder teurere Hardware machen. Wir können nicht jeden Monat ein Projekt der Preisklasse einer Ethernet Extension veröffentlichen, das geht einfach finanziell nicht . Ja, wir wissen auch nicht so genau was wir da machen sollen Wenn sich das auf die OnDevice-API bezieht, so sollte man das Thema nicht ganz aus den Augen verlieren, denn dazu war das Feedback hier im Forum zu groß. Wenn es technologisch (noch) nicht lösbar ist, so würde ich kleinere Schritten in diese Richtung mir mehr wünschen, als eine monolithische API die niemals kommt. Erste Schritte wären z.B. ein Tutorial wie die komplette Entwicklungsumgebung dazu einrichtet wird und wie man die dabei entstehenden Fallstricke und Besonderheiten sicher behandelt. Hierzu gibt es zwar Beiträge im Forum, die m.E. aber für Anfänger zu kryptisch und unvollständig sind. Ideal wären Schritt-für-Schritt Anleitung wie die FW bzw. Plugins der Bricklets um einfache Funktionalität erweitert werden kann. Ev. reicht es auch für viele Zwecke aus, das direkte Ansprechen von Bricklet-Daten am Brick, z.B. Endlagenschalter via IO Signale ohne Umweg direkt am Brick auszuwerten. Die Aussage bezog sich auf Entwicklung neuer Hardware, wie lange es dauert eine OnDevice-API zu bauen wissen wir ganz gut denke ich. Wir haben da diesbezüglich auch schon eine Entscheidung getroffen wie das genau aussehen soll, wir werden unsere Masterplan diesbezüglich denke ich nach dem neuen Schwung von Bricklets veröffentlichen. Es wird ein wenig anders werden als wir es erst selbst vorgeschlagen haben, aber die allermeisten der Anforderungen erfüllen die wir von euch gesammelt haben . Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 26, 2013 at 13:13 Share Geschrieben July 26, 2013 at 13:13 Besten Dank, das hört sich schon mal sehr gut an. Sicher nicht nur ich bin sehr gespannt Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.