AuronX

Ohne echtes Neuaufsetzen: - Virtuelle Maschine aufsetzen - versuchen genauso zu konfigurieren wie dein live-system - USB-Gerät durchreichen Ich würde gleich nach dem aufsetzen der VM mal schauen ob es geht, bei nem frischen System sollte da eigentlich nix im Weg stehen.

Ich habe das nur als App Store gelesen. Also ich baue eine Heizungsregelung basierend auf TF-Komponenten und dann können das andere nutzen. Glaube social steht da nur weil noch ein Buzzword gefehlt hat oder klar sein sollte, dass die Apps von Nutzern kommen. @jan_ck: Sinnvoll wäre es dann sicherlich, dass so eine "App" dann auch öffentliche Variablen anbietet, die per UI geändert werden können. Sonst muss der "einfache" Nutzer irgendwo zwischen meine Module kriechen, nur um die Raumtemperatur von 20°C auf 21°C zu ändern. Ich denke eure Idee könnte die Baukasten-Vision von TF & Co noch weiter vorantreiben, ich beobachte euch ^^ @Acane: Ich würde es auch definitiv PipeStore oder so nennen ^^

Wegen der API-Methoden: hier Dort wird inzwischen sogar erklärt, was genau weggeworfen und was behalten wird. Als ich damals gefragt habe hieß es nur sinngemäß: "je kälter, desto länger dauert es"

Ich habe meinen grad nicht hier zu liegen, aber so weit ich mich erinnere hat er auch im Bereich unter 100 Lux noch gut gemessen (also ohne größere Sprünge). Was ist deine Leuchtquelle? LED? Bei mir sind es diese Energiesparlampen wo so viel Quecksilber drin ist. Soweit ich weiß gibt es bei LEDs ja das Phänomen, dass sie "flackern". Das merkt man z.B. wenn man mit einer Kamera die Stopplichter von Autos filmt. Was du beschreibst ist m.E. entweder ein defektes Ambilight-Bricklet oder eines mit dem der Nachweis von LED-Licht im Raum möglich ist. Bei absoluter Dunkelheit solltest du zumindest nicht bis über 100 Lux kommen

Ich glaube ich habe noch nicht ganz verstanden was PipesBox ist und was es nicht ist. Bisher verstanden: Es ist eine Laufzeitumgebung, es steuert also meine eigenen Komponenten. Im Falle von TF heißt das ich muss mein Programm nicht selbst schreiben, sondern ich klicke mir meine Pipes zusammen und dann passiert was. Dabei verbindet ihr viele Produkte (Homematic, TF, Twitter). So weit ziemlich cool! (Habe ja gehört hier nutzen mehrere Leute mehr als nur TF) Euer Geschäftmodell scheint irgendwo in diesem Zitat versteckt zu sein: Was bedeutet "den ganzen Tag statt nur auf dem Laptop"? (Nachts ists kälter als draußen) Heißt das in der Cloud? Oder doch bei mir, aber bisher habe ich eine zeitlich begrenzte Demo? Oder ist die Plattform eingeschränkt? (x86 kostenlos) Mir ist nicht klar: - was der Teil ist den ich bei euch (später) kostenpflichtig erwerbe - was das dann kosten wird Letzteres wisst ihr möglicherweise auch selbst noch gar nicht, aber ich wollte mal gefragt haben ^^ Wie schon gesagt: Die Idee ist ziemlich cool und mit grafischem Designer setzt sie um, was schon oft gewünscht wurde. Mit der Interoperabilität setzt ihr dann sogar das um was nur sehr zaghaft offen gewünscht wird, obwohl es sicherlich jeder haben will der mehr als ein System nutzt ^^

Grundsätzlich kann das Servo-Brick nur mit Servos und Fahrtenreglern (in der Regel elektronische Fahrtenregler, kurz ESC) umgehen. An einem ESC kann dann wiederum ein Motor hängen. (Nur um Missverständnisse zu vermeiden) Was du bei setDegree einstellst ist vollkommen dir überlassen. Das ist nur dazu da dir eine "Übersetzung zu bieten. Du kannst zum Beispiel auch als Maximum einfach 1000 angeben. Dann würde 1000 bedeuten "volle Kraft" und 900 wäre 90%. Insbesondere kommt es auch auf deinen ESC an, ob 90% wirklich bedeutet "90% der Drehzahl".

Oh schade, bin über Weihnachten außer Reichweite meiner Bricks. Hätte aber gerne geholfen ^^ Noch etwas zu C#: Ich habe ja damals empfohlen, dass man den sender als Object in die Calbacks reingibt. Ich habe gerade darüber meditiert warum das sinnvoll ist. Der übliche Use-Case ist ja Wiederverwendbarkeit, ich möchte also, dass verschiedene Klassen das gleich Event anbieten könnten. Aber im Fall von der TF-API sind ja die Event-Delegates alleine schon an die Klasse gebunden (z.B. BrickServo.PositionReachedEventHandler). Dann kann man eigentlich auch den sender direkt korrekt getypt übergeben, das macht Callbacks noch einfacher (und typsicherer): static void ReachedCB(BrickServo sender, byte servoNum, short position) { sender.SetPosition(servoNum, -9000); } Sorry für den späten Hinweis ^^ Frohes Fest! edit: Spannende Lektüre

Okay, umgesetzt habe ich sowas noch nicht, dennoch: Dir zumindest schonmal ein paar Komponenten zum vorherigen Spielen zu kaufen halte ich für sinnvoll. Es geht ja nciht nur darum dich einzuarbeiten, sondern auch das TF-System mal kennenzulernen und auszuprobieren. Dadurch merkst du dann, ob du jetzt wirklich nochmal zehn weitere Relay-Bricklets für dein Haus bestellen willst oder nicht. Off-Topic: Was mich noch persönlich interessieren würde: Hast du in deinem Haus eine Ethernet-Verkabelung eingeplant? Falls ja: Wie viele Anschlüsse pro Raum? Vollständig stern-förmig oder mit mehr als einem Switch?

Jop das geht. Also wie es innerhalb des gleichen Netzwerks geht weißt du ja offensichtlich bereits. Um das ganze auch hinzubekommen wenn der andere Rechner hinter einem anderen Internetanschluss hängt brauchst du zwei Dinge: 1. Die IP-Adresse des anderen Anschlusses Diese erfährst du über die Weboberfläche des entfernten Routers, allerdings ändert sie sich bei üblichen Verträgen alle 24 Stunden. Die Lösung hierfür ist DynDNS. Dabei registrierst du bei einem Anbieter (wie z.B. dyndns.org) eine eigene (meist kostenlose) subdomain (z.B. meineip.dyndns.org). Die meisten Router unterstützen eine Handvoll verschiedener solcher Dienstleister und sind in der Lage bei einer Änderung ihrer eigenen IP dies dem DynDNS-Anbieter mitzuteilen. Wenn du das eingerichtet hast kannst du per wasauchimmer.dein-dyndns-anbieter.com den entfernten Router erreichen. Anmerkung: Solltest du eine statische IP-Adresse in der Ferne haben, dann ist die Domain nicht notwendig, weil die IP immer die gleiche ist (domainnamen lassen sich aber leichter merken ). 2. Eine Freigabe im Router Gut, jetzt erreichst du deinen Router. Aber eben nur den und nicht dein Brick. Was du jetzt brauchst ist eine Portweiterleitung. Das heißt sobald dein Router eine Anfrage auf dem Port des brickd erhält, muss er diese an den Rechner weiterleiten an den dein Brick angeschlossen ist. Dies geht über die Weboberfläche deines Routers, du findest es unter Stichworten wie NAT, Adressübersetzung oder Portweiterleitung. Die Einstellungen sollten ungefähr so aussehen: Protokoll: TCP Öffentlicher Port: Der Port auf den du dich verbinden möchtest um den brickd zu erreichen Interner Port: Der Port auf dem der brickd wirklich läuft (intern und extern sind üblicherweise gleich, müssen sie aber nicht sein) Rechner an den die weiterleitung erfolgt: IP des Rechners auf dem der Brickd läuft bzw. IP der WLAN/Ethernet-Extension Einmal umrühren und fertig ist der Fernzugriff auf dein Brick. Warnung: Ich habe dir gerade erklärt wie du dein Brick für jeden öffentlich erreichbar machst. Wenn es darum geht nur Wetterdaten auszulesen ist das nciht schlimm. Wenn auf diese Weise dein Garagentor geöffnet werden kann, dann ist das potenziell gefährlich (für dein Auto und für Leute unter dem Garagentor). Wenn du etwas sicheres willst dann gibt es weitere Optionen: 1. Bald gibt es Authentifikation im Protokoll, das bringt sicherheit wenn du es einsetzt 2. Du musst nicht dein Brick direkt freigeben. Du kannst auch eine eigene SOftware aus der Ferne steuern, dann kannst du dort selbst Sicherhitsmechanismen einbauen 3. Du richtest ein VPN zwischen dem Netzwerk deines Bricks und dem von wo aus du die Abfrage machen möchtest ein Viele Grüße Jan

hier beim DC-Brick (und diese Warnung steht auch beim Servo Brick, da weiß ich aber nicht ob sie auch dort korrekt ist)

Ich habe leider wenig Ahnung von Homematik, deswegen kann ich dazu nix sagen ^^ TF macht mir Spaß, weil ich weniger Ahnung von Hardware habe als von Software-Programmierung (und mit "Soft" meine ich Anwendungen, nicht Firmware ^^). Nach dem was du schreibst scheinst du die wesentlichen Regeln zu befolgen, um bösen Überraschungen mit TF zu entgehen (Rückkopplungen durch Relays). Eine wichtige Frage deren Antwort ich für Hausautomatisierung auch noch nicht kenne. Es klingt erstmal ziemlich cool, immer! Das Gute: Es taugt auf jeden Fall zum Hobby. Wenn du aber nach echtem Sinn fragst, dann solltest du dir konkrete Use Cases überlegen. Beispiel (frei interpretiert aus deiner Beschreibung): "Ich möchte, dass die Rolladen mein Wohnzimmer bei starkem Lichteinfall automatisch verdunkeln. Sie sollten mich aber nicht aussperren, während ich auf dem Balkon stehe." Wenn du solche Use Cases hast kannst du dir überlegen ob das 1. sinnvoll ist und 2. ob du dafür TF brauchst oder eine einfache Lösung reicht. Viele Grüße Jan, 24 aus Potsdam P.S.: Wann steht das Haus?/Wie viel Zeit hast du noch dich endgültig zu entscheiden?

Habe gerade nochmal Doku und Shop-Beschreibung gelesen. Beim DC-Brick steht tatsächlich die von dir angeführte Warnung in den Docs. Dort wird also die Input-Spannung "durchgereicht" und bei leerer Batterie kann die Spannung plötzlich steigen. Das Servo-Brick sollte sich hier jedoch sicher verhalten, da die Ausgangsspannung kontrolliert wird. Allerdings (TF bitte mitlesen ^^): In der Doku zum Servo Brick findet sich ebenfalls der Hinweis mit der steigenden Spannung. Dort wird aber auch munter von Motoren geschrieben. Ich bin mir also abschließend nicht sicher, ob eine Gefahr für Servos besteht oder das nur ein Copy & Paste Fehler in der Doku ist. Meine Intuition würde aber sagen, dass das Servo Brick safe ist.

@Arcane: Die Ausgangsspannung des Servos ist doch regelbar oO Also selbst wenn es zum Umschalten kommt sollte in meinen Augen die Ausgangsspannung gleich bleiben. Was ich gerade nicht aus dem Hut weiß: Würde die externe Quelle gewählt, wenn deren Spannung geringer ist als die im Stack?

Mal noch etwas Troubleshooting: - Brick abziehen - Brickd neustarten (im Zweifel durch Neustart des Rechners) - Mit Brickv verbinden - Brick wieder anstecken Geht das? (Das würde ausschließen, dass sich nur der brickd doof aufhängt, das hat er bei mir [früher] manchmal getan)

Da du den Servo-Brick steuern möchtest: Nimm am Besten die Step-Down und versorge damit deinen Stack. Step-Down bedeutet du führst Strom "beliebiger" (siehe Datenblatt) Spannung in die Step-Down und dein Stack ist mit allem versorgt was er braucht. Dazu kannst du beispielsweise Akkus aus dem Modellbau oder entsprechende Akkupacks benutzen (alles von Fremdherstellern). Ansonsten kannst du deinen Stack auch per USB versorgen. Beispielsweise mit einem USB-Netzteil oder einem PC. Für das Servo-Brick brauchst du aber in jedem Fall noch eine externe Stromversorgung, deswegen mein Ratschlag mit dem Step-Down. Zusatzgedanke: Je nachdem was du tust ist es vielleicht doof, wenn bei geringem Batteriestand durch eine Servo-Bewegung die SPannung abfällt und dadurch dein Stack plötzlich nicht mehr ordentlich versorgt wird. Dann möchtest du möglicherweise doch deine Servos aus einer anderen Spannungsquelle speisen als deinen Stack.

Nehme den auch erstmal ohne Buchse. Gibt es schon einen Anschaffungswiderstandswert? Sofern ich die Frage vom Löti richtig verstanden habe würde ich deren Antwort auch gerne erfahren: Was wird die Ethernet-Extension kosten?

Ich würde für Nics vorschlag stimmen ^^ Ihr müsst euch nicht rechtfertigen warum ihr das Beispiel in Python schreibt, ihr solltet nur darauf hinweisen, dass ihr es tut

Für Python: http://www.tinkerforge.com/doc/Software/IPConnection_Python.html#ipcon-python

Brick-getriebene Trecker?

Ist es eigentlich eine gute Idee, wenn ich API-Kritik an den 2.0 C#-Bindings nur im github äußere? Ich würde eine offene Diskussion im Forum bevorzugen, allerdings denke ich, dass dieser Thread hier nur das Protokoll an sich betrifft. Macht es Sinn für soetwas noch einen weiteren Thread einzurichten (ich vermute bei anderen Sprachen wird es auch noch Feedback geben)? Viele Grüße Jan

Lieber Mitmensch Nic: Wenn du Antowrten von niemand anderem als dem Threaderöffner möchtest, dann schreibe ihm doch eine PM. Meine Frage bezog sich auf zwei Dinge: 1. Ist deine Frage nach einer Einführung in Unity3D weit außerhalb des Scope eines Tinkerforge-Forums, deswegen dachte ich du hättest eine speziellere Frage 2. Frage ich mich halt ganz ernsthaft was du mit "einfach nur in Java übersetzen" meinst. Willst du den dahinterliegenden Code verstehen, willst du es benutzen? Da du hier gerade fremden Menschen potenziell viel Arbeit aufbürdest wird man wohl nochmal nach dem Hintergrund der Frage fragen dürfen. edit: Was mcih an der Frage nach der Übersetzung halt nervt ist, dass wenn es "einfach nur" übersetzen wäre, dann könntest du es auch selbst machen. Das heißt also da steckt offenbar ein anderes Bedürfnis hinter als am Ende tollen Java-Code bekommen zu haben. Dieses Bedürfnis von dir zu kennen, BEVOR jemand mit der Arbeit beginnt wäre toll...

@Nic: Was genau willst du jetzt erfahren? Welchen Code willst du nach Java übersetzt haben? Eigentlich sieht sich Java und C# ja so ähnlich, dass es dort am verständnis nicht scheitern dürfte

Ich wollte auch sagen, dass ich dir in meiner aktuellen Gedankenlage zustimme Also du registrierst halt nen Callback und sagst wie oft du dir das Pong wünschst. Zwischendurch würdest du aber nichts mehr dafür an den Stack senden. Das mit dem automatischen Reset des Stacks verstehe ich noch nicht ganz: Wird der Stack reseted wenn sich der angeschlossene PC (also das Programm von dir) nciht mehr meldet? oder wann? Da sollte man aufpassen, dass man keine Neustart-Endlosschleifen baut, wenn das eigene Programm abstürzt ^^

Ich würde erstmal nicht denken, dass es möglich ist für nur eine Plattform kaputt zu sein. Wenn du sagst mit einem zweiten Master funktioniert es, dann brauche ich auch nciht zu fragen ob der brickd läuft. Versuchst du es unter Linux auch mit dem brickv odeer mit etwas anderem? Falls etwas anderes: Ist in diesem Programm die UID des funktionierenden Masters eingetragen und das Programm stürzt ab, wenn die UID nicht stimmt?

Dazu wollte ich dich gerade befragen, aber da es jetzt durchgestrichen ist glaube ich, dass wir uns jetzt doch einig sind Warum ein extra Bricklet? Reicht nicht eines der vorhandenen Bricklets um die Erreichbarkeit zu prüfen? Habe die Details unserer letzten Diskussion leider vergessen, aber ich glaube es war sowas wie, dass ich gegen ein Hardware-Ping bin und du dafür ^^ Wenn du dir soetwas vorstellst wie: Programm fragt "ping", Stack antwortet "pong", dann nimm einfach ein enumerate gegen ein einzelnes Brick. Wenn du dir etwas vorstellst wie: Der Stack sagt peiodisch "pong", dann finde ich das im Moment ziemlich cool, zumindest bequemer als immer ping zu rufen und man könnte argumentieren, dass nur die halbe Bandbreite nötig ist ^^