Equinox

Hallo, laut Doku: Current12-Bricklet: Bis 12,5A Current25-Bricklet: Bis 25A Analog In-Bricklet: Bis 45V Voltage-Bricklet: Bis 50V Voltage/Current Bricklet: Bis 36V und 20A Da sollte doch was dabei sein!

Genau. Der Browser baut eine Verbindung via WebSocket zum BrickD auf. Diese Verbindung bleibt bestehen, wobei der Server (BrickD) "unaufgefordert", d.h. ohne erneuten Request vom Client, Daten an den Browser schicken kann.

Hallo, Die angedachte Implementierung des Brickd soll WebSockets nutzen. Damit sind Callbacks möglich, d.h. der Server kann "unaufgefordert" Daten an den Client schicken. Da bei "normalen" WebServices keine Verbindung bestehen bleibt, geht es da nicht.

Coole Sache Aber wenn das geht: Dann müsste doch auch das gehen: Wobei der WebService dann eben nicht auf dem Master Brick läuft, sondern auf der WiFi- bzw. Ethernet-Extension. Wenn ein "Full-Blown" WebService zu aufwändig ist, dann könnte ich mir auch einen ganz normalen HTTP GET-Request vorstellen. So in der Art: http://<IP des Stapels>:<Port>/<Bricklet UID>/<getter> oder http://<IP des Stapels>:<Port>/<getter(Bricklet UID)> Also z.B.: http://192.168.10.100:80/aBC/getHumidity() Der Aufruf gibt dann einfach die gemessene Luftfeuchtigkeit zurück, also z.B. 758 (für 75,8%).

Es sind drei(?) Diskussionen: [*]Node.js: Das wäre einfach nur ein weiteres Binding wie PHP, Java, usw. [*]"WebService auf MasterBrick": Hier geht es darum, sprachunabhängig die Daten der Bricklets ohne Server und ohne Installation von irgendwelchen Bindings auf dem Client auszulesen. Da dies aber wohl nicht geht, ist die Diskussion hinfällig (es sei denn, es kommt einer und sagt dies dies realistisch möglich ist). [*]JavaScript im Browser: Binding wie PHP, Java, usw., aber eben ausgeführt im Browser. (So habe ich es zumindest verstanden )

Eben. Eine Plattform (mit dem auch auch einen Web-Server implementieren kann), die man mit JavaScript programmieren kann. Wenn eure Bindings also auch in JavaScript geschrieben werden, dann sollte das doch auch im Browser laufen (es sei denn, es werden "verbotene" Operationen (Dateizugriffe usw.) verwendet)?!

Hallo, Ahh, ich glaube jetzt habe ich verstanden, was du mit deinem ursprünglichen Post gemeint hast. Es ging dabei um nicht um den Vorschlag, WebServices "standalone" auf dem Master Brick anzubieten, sondern um "echte" JavaScript-Bindings für den Browser? Falls ja, dann bin ich wieder in der Spur Hmm, da sehe ich jetzt keinen Unterschied zu einem in meinem LAN betriebenen Web-Server. Auch hier muss ich im Router den Port freischalten und die IP-Adresse kennen (wobei man hier ja im Normalfall sowas wie DynDNS nutzt). In dem Fall und im Fall, dass man gar keinen Server hat. Ich denke, dass es nicht so selten ist, dass ein Web-Server im eigenen LAN keinen Zugriff auf die Bricks hat. Aber mal eine Frage: Wenn ihr Bindings für Node.js entwickelt, funktionieren die dann nicht "automatisch" für JavaScript im Browser? D.h., wären das dann nicht zwei Fliegen mit einer Klappe?

Hallo, jetzt bin ich völlig verloren Geschickter als was? So muss man es doch im Moment machen, da man sich nicht direkt via JavaScript verbinden kann, oder? ?? Wenn eine Abfrage direkt per WebServices möglich wäre, dann wäre der Stapel nicht per USB verbunden, sondern per WiFi- oder Ethernet-Extension (eben standalone). Wenn man das natürlich auf einer hochfrequentierten Seite macht, kann das natürlich trotzdem zu Problemen führen. Aber das wird wohl eher die ganz große Ausnahme sein (typischerweise wird es wohl nur einige wenige Benutzer aus dem eigenen LAN geben). Oder was habe ich hier falsch verstanden? ?? Wieso Webseite bei *euch* aufrufen, um *eigene* Bricklets anzusehen ?? Man könnte damit vmtl. tatsächlich einen Brickviewer über einen Browser basteln, der dann aber im eigenen LAN läuft (also ohne Internet-Zugriff). Oder was geht hier an mir vorbei? Vielleicht ist es einfach zu spät ...

Das sollte ja dann eigentlich keine Rolle spielen Ich würde allerdings Java, PHP, Node.js und (Micro-)Python verwenden. Umgebungen: Windows PC, NAS mit Linux, Raspberry Pi, Android Handy, Microcontroller. Für das Meiste davon gibt es ja schon Bindings (die auf jeden Fall mächtiger sind als WebServices), aber manchmal kann/möchte man einfach keine zusätzlichen Installationen (d.h. die Bindings) machen. Ich denke aber, dass es vor allem für euch einfacher wird, da ihr damit automatisch "alle" Programmiersprachen abdecken würdet. Das hat allerdings keine große Priorität für mich (wichtiger wären die Bindings für Node.js). Und da es eh nicht geht, hat es sich ja eigentlich auch schon erledigt.

Hallo, Dann würde das Programm, das mir die Daten per JSON, RPC/XML usw. zur Verfügung stellt, standalone auf dem Master Brick laufen. D.h., das wäre im Prinzip "nur" eine andere Schnittstelle, um an die Daten der Bricklets zu kommen. Oder vielleicht anders formuliert: Eine Möglichkeit, dass ein Client direkt auf die Daten der Bricklets zugreifen kann (ohne Rechner/Server dazwischen), wobei die Daten standardisiert über WebServices geliefert werden (RPC/XML, JSON), d.h., dass auch auf dem Client keine TF-spezifischen Bibliotheken/Bindings vorhanden sein müssen. Ein Zugriff auf die Daten wäre damit vollkommen sprachunabhängig, d.h. jede Sprache, die WebServices unterstützt, könnte auf die Daten zugreifen (auch die Sprachen, für die es noch keine TF-Bindings gibt).

Hallo, Weil ja schon lange die Idee kursiert, Programme standalone auf dem Masterbrick laufen zu lassen, wäre das einfach nur ein erster Schritt dorthin bzw. eine "Light"-Möglichkeit, die TF-Hardware ohne zusätzlichen Rechner abzufragen bzw. zu nutzen. Einen zusätzlichen Daemon mit JSON oder RPC/XML-API brauche ich nicht, solange er weiterhin einen eigenen Rechner braucht. Wenn das also nicht geht, dann wäre mein nächster Wunsch nur die Unterstützung von Node.js.

Naja, die paar Bytes machen den Kohl nicht fett. Mir ist wichtig, dass ich eine WSDL zur Verfügung habe und damit der Zugriff (bei den meisten Programmiersprachen) sehr einfach wird. Wenn es um die Datenmenge geht, dann ist auch JSON schon zuviel, also einfach nur den Wert ohne Schnickschnack drumherum zurückgeben. Aber man kann ja auch beides unterstützen. Meines Wissens kann der Client in seinem Request angeben, in welchem Format er die Antwort gerne haben möchte. Die Frage ist nur, ob es einen genügend schlanken Webserver gibt, der diese Aufgaben auf dem Masterbrick erledigen kann.

Cool Das Ganze jetzt noch schön verpackt wie bei den anderen Bindings und schon ist auch das fertig Dann hätte ich noch einen Wunsch (wobei ich befürchte, dass dies nicht machbar ist): Ich hätte gern einen WebServer auf dem Masterbrick, der mir die ganzen "Getter" und "Setter" der Bricklets als WebServices zur Verfügung stellt (RPC Style). Diese könnten sprachunabhängig genutzt werden und wären ein erster Schritt zur "standalone" Nutzung der TF Hardware. Die gewünschte "Logik" müsste dann natürlich in den Client-Programmen jeweils selbst implementiert werden. Aber oft will man ja nur einen Wert wissen oder etwas manuell einschalten. Ist dafür genügend Platz auf dem Masterbrick?

Hallo, das WebSocket-Protokoll ist schon seit Ende 2011 im Status "Proposed Standard", aber de facto ist es ein verabschiedeter Standard, da ihn meines Wissens alle modernen Browser unterstützen. Einer Kommunikation zwischen Browser und Server steht also nichts im Wege. Die Frage ist nur, ob bzw. wie man mit Node.js mit der TF Hardware reden kann. Ich denke aber, dass das gehen sollte, notfalls über die Shell :-)

Hallo, ich hätte gern Bindings für Node.js.

Hallo, Das scheitert leider an zwei Punkten: [*]Zwei linke Hände [*]Zuviel Schiss, mit 230V zu hantieren Daher kommt für mich nur eine einsatzfertige Lösung in Frage. Aber stimmt schon, dass eine Chibi-Extension auf jeden Fall Voraussetzung ist.

Hallo, es wäre ja nicht proprietär, sondern alles rein mit TF-Mitteln. Stromdaten, d.h. Verbrauchsdaten, sind keine schlechte Idee. Man könnte die Dose natürlich noch mit einem Voltage/Current-Bricklet aufbohren und die Daten dann auch noch erfassen. Das wäre dann die "Extended-Version" einer Funksteckdose Kommt darauf an, was du mit "zur Verfügung stehen" meinst. Wenn du meinst, dass es die Transceiver-Einheit auch separat, d.h. nicht verbaut in einer Funksteckdose oder einem Schalter, geben soll, dann ja. Aber das wäre doch genau die Chibi-Extension, oder? Wäre natürlich schön, wenn die Funksteckdose genug Platz hätte, um mit weiteren Bricklets erweitert werden zu können, halte ich aber nicht für notwendig. Mir würde es reichen, wenn die Dose alles schön verpackt in einem Gehäuse hätte.

Hallo, der "wichtigste" Punkt für mich ist die Reichweite, und da ist die Chibi-Extension einfach super. Also kein WLAN oder andere Techniken, die nur 50m schaffen. Der andere sehr wichtige Punkt ist der Rückkanal. So habe ich mir das auch gedacht, d.h. die Chibi-Extension und das Relais-Bricklet (und Button-Bricklet) werden über die 230V versorgt. Da sollte man natürlich keine Batterien einsetzen müssen. Hmmm, ok, dann braucht man da noch ein Teil mehr, um die Spannung auf die TF-kompatible Spannung zu wandeln. Du möchtest also, dass der Schalter auch unabhängig von einem Master/Controller funktioniert? Wäre natürlich nicht schlecht, aber es sollte meiner Meinung nach flexibel sein, d.h. wenn ich den Schalter betätige, dann möchte ich vorher einstellen/konfigurieren können, was (d.h. welche(s) Relais) geschaltet werden soll(en). Das muss nicht zwangsläufig das sein, was direkt am dem Button/im Schalter verbaut ist. Ich denke, da wird es aufwändig. Zumindest für den Anfang würde es mir reichen, wenn die Schalter nur mit Master/Controller funktionieren. Hmm, ob das geht? Dazu müsste man ja die IDs der registrierten Relais in einem nicht-flüchtigen Speicher auf dem Master ablegen. Dafür bräuchte man dann wohl ein SD-Card-Bricklet. Ich denke, es würde reichen, wenn man etwas längere IDs verwenden würde (zumindest für den Anfang).

Hallo, WLAN hat im Vergleich zu Chibi ein sehr viel geringere Reichweite, deshalb würde ich Chibi bevorzugen. Zu den Kosten: Meine Hoffnung ist, dass man zumindest auf Empfänger-Seite (d.h. in der Steckdose oder dem Schalter) keinen Master-Brick braucht, d.h. dass die Neuauflage der Chibi-Extension sozusagen eine "transparente Bridge" bildet, die die notwendige "Intelligenz" an Bord hat. Evtl. ließe sich das ja auch alles auf einem neuen Bricklet unterbringen, d.h. Chibi + Relay (weil man das vmtl. fast immer bei der Heimautomatisierung braucht) und es dadurch dann billiger wird.

Hallo, Genau. Also nicht den normalen Transceiver, den die Baumarktsteckdosen haben, sondern stattdessen die Chibi-Extension. Am liebsten fix und fertig in einem Gehäuse verpackt (so wie die Baumarktsteckdosen eben auch). Wann wird es eine neue Chibi-Extension geben? Ich habe im Forum nur gelesen, dass es eine verbesserte Neuauflage geben soll, weil es doch eine große Nachfrage dafür gibt. TF macht aber leider keine Aussagen mehr darüber, wann was kommen wird

Hallo, die handelsüblichen Funksteckdosen in Kombination mit dem Remote Switch Bricklet sind schon eine feine Sache, haben aber meiner Meinung nach 3 Nachteile: [*]Relativ geringe Reichweite [*]Kein Rückkanal (Nebenbei/Off-Topic: Wenn man da ein Voltage/Current Bricklet einbauen könnte, könnte man dies doch als Rückkanal nutzen, oder?) [*]Zumindest bei Typ A Dosen nur relativ wenig Codes möglich Ich denke, TF hat schon alles, um eine Funksteckdose zu bauen, die diese Nachteile nicht hat. Wie wäre es, wenn ihr eine Super-Funksteckdose bestehend aus (der Neuauflage) einer Chibi-Extension und einem (Single) Relay-Bricklet anbieten würdet? Durch die Chibi-Extension hätte man eine super Reichweite, der Zustand des Relay-Bricklet ist änderbar und abfragbar (Rückkanal) und durch die IDs der Bricklets sind mehr Codes möglich (evtl. könnte man da ja sogar noch eine Autorisierungs-ID oder Verschlüsselung einbauen). Ich glaube, damit wärt ihr die Helden am Funksteckdosenmarkt Was meint ihr? Noch weiter gedacht: Diese Funksteckdose wäre nur ein Teil aus einer ganzen Heimautomatisierungsserie. Wie wäre es z.B. mit einem (Licht-)Schalter bestehend aus Chibi-Extension, Button-Bricklet und Relay-Bricklet? Das müsste dann natürlich so kompakt sein, dass man die bisherigen Schalter austauschen kann. Das sollte aber kein großes Problem sein, da dies ja schon für andere Heimautomatisierungssysteme angeboten wird. Voraussetzung ist natürlich eine neue Chibi-Extension. Aber das soll es ja wieder geben.

Hallo, keine Ahnung, wie man das am besten macht. Aus dem Bauch heraus würde ich sagen, dass es sowohl in den Bindings als auch im Bricklet-Code gehen müsste. Vielleicht ist es im Bricklet-Code besser, da es dann einheitlich über alle Bindings ist, aber dazu kenne ich mich viel zu wenig mit den Internas der Bindings und des Bricklet-Codes aus. Ich vertraue da TF, die da bestimmt die beste Lösung finden

Hallo, kleiner Nachtrag: Bei einem blockierenden Aufruf (oder Array) sollte es dann aber trotzdem eine "beepStop()"-Methode geben, um die Beeps abzubrechen.

Hallo, das ist natürlich ein Workaround, den man auch einfach in eine eigene Methode packen kann, aber einen blockierenden Aufruf oder ein Array wären schöner.

Hallo, wäre es möglich, die API des Piezo Speakers um eine blockierende beep-Methode zu erweitern, d.h. wenn ich beep(2000, 1000) und direkt danach beep(2000, 4000) aufrufe, ich zuerst 2 Sekunden 1000Hz höre und dann 2 Sekunden 4000Hz? Im Moment ist es so, dass ich praktisch nur die 4000Hz höre. Hintergrund: Wenn man mehrere unterschiedliche Töne nacheinander abspielen will, dann ist die Methode über den BeepFinishedListener ziemlich umständlich. Ich möchte in meinem Code einfach nur eine Folge von beep-Anweisungen schreiben müssen. Alternativ wäre auch möglich, ein Array von Tonlängen und Frequenzen zu übergeben, die dann gespielt werden und am Ende der kompletten Tonfolge dann erst der BeepFinishedListener aufgerufen wird. Was haltet ihr davon?