Jump to content

AuronX

Members
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    887

  • Benutzer seit

  • Letzter Besuch

 Inhaltstyp 

Posts erstellt von AuronX

    [PHP] Grundfunktion, Callbacks und mehrere Sensoren auslesen

    in Anfängerfragen und FAQ

    Geschrieben

    Grundsätzlich muss ich bei den PHP-Bindings sagen, dass ich auf den EInsatz von Callbacks verzichten würde.

    Das liegt daran, dass die PHP-Bindings Callbacks nur sonderbar unterstützen. Du musst eine blockierende Methode aufrufen, die die Callbacks bearbeitet, dafür passiert aber sosnt nix tolles...

     

    Also mein Tipp: Bei PHP keine Callbacks

    Den anderen Teil deiner Frage habe ich nicht so recht verstanden. Aber es reicht wenn du eine IPConnection für viele Bricklets nutzt.

    Step-Down Power Supply - richtige Akkus?

    in Hardware

    Geschrieben

    So viel ich weiss werden alle Akkus die auf dieser Technologie beruhen nur von 2 Firmen hergestellt. Zum einen Sanyo und die andere weiss ich nicht.

     

    Auf der von dir verlinkten Seite ist oben rechts ein Panasonic-Logo ^^

     

    Aber eigentlich wollte ich das beitragen: Ich habe diese speziellen Akkus auch inzwischen überall im Einsatz, weil sie einfach gut sind. (Unabhängig von TF-Anwendungen)

     

    Insbesondere haben sie nahezu keinen Leistungsverlust bei Lagerung (einige andere Akkus die ich habe sind nach einem Monat nicht mehr ohne erneutes Laden brauchbar)

    [Umfrage] Welche Programmiersprache sollen wir als nächstes unterstützen?

    in Software, Programmierung und externe Tools

    Geschrieben

    Wie schon mehrfach erwähnt, wären damit automatisch alle Sprachen abgedeckt, die HTTP-Requests absetzen können, also auch die, für die es keine Bindings gibt.

    Desweiteren könnte man ein einheitliches Programmiermodell über all seine Clients völlig sprachunabhängig realisieren und müsste sich nicht mit der Pflege unterschiedlicher Bindings auf all seinen Clients "herumplagen".

     

    Wie borg schon sagte können ja all diese Sprachen bereits TCP, also sind sie bereits heute abgedeckt.

    Das einheitliche Programmiermodell wird doch weitestgehend durch die Bindings erreicht. Das heißt Tinkerforge baut für dich die Bindings die du dann einsetzen kannst um dich nicht darum scheren zu müssen wie die Kommunikation wirklich aussieht.

     

    Wenn du tatsächlich dein HTTP-Protokoll nutzen wolltest oder aber das existierende TCP-Protokoll (ich sehe da keinen Unterschied (@Loeti: netcat ^^)), dann müsstest du dich pltzöich selbst um alles kümmern und dir die Abstraktion vom Kommunikationskanal auf deine Programmierumgebung schaffen. Effektiv hast du dann deine eigenen Bindings gebaut. Auf jeden Fall wäre TF damit nicht "automatisch" überall unterstützt.

     

    Mit TCP/IP und Websocket müssten nahezu alle Sprachen abgedeckt sein.

     

    Sehe ich ebenso

    [Umfrage] Welche Programmiersprache sollen wir als nächstes unterstützen?

    in Software, Programmierung und externe Tools

    Geschrieben

    Equinox, wenn du über deine Frage noch einen Moment nachdenkst wirst du merken, dass das nicht funktionieren kann.

     

    Woher soll man wissen wie viele getValues es gibt?

    Woher soll man den rohen Datentyp wissen? (char, (u)int16, (u)int32)

    Woher soll man wissen wie aus dem rohen Wert der "richtige Wert wird?

    Was ist mit settern?

     

    Und viel wichtiger: Was würde das ganze am Ende denn nützen? Dann habe ich irgendeinen Dienst den ich wieder nach irgendetwas fragen kann. Aber mit was frage ich das ganze dann ab? Der Client muss ja doch wieder irgendein Protokoll sprechen. Mir erschließt sich nicht an welcher Stelle ein Web-Service mächtiger/portabler wäre...

    [Umfrage] Welche Programmiersprache sollen wir als nächstes unterstützen?

    in Software, Programmierung und externe Tools

    Geschrieben

    Auf jeden Fall!

     

    Ich bin wieder nicht auf den guten Gedanken gekommen den brickd zu erweitern.

     

    Wäre das auch auf den TCP-Extensions (WLAN/LAN) implementierbar? Weil ansonsten natürlich wieder ein Ungleichgewicht entsteht das unter Umständen schwer erklärbar ist... (JS geht nur mit "vanilla" brickd, aber nicht mit Extensions)

     

    Ansonsten eine sehr coole Idee. Es wäre ja trotzdem möglich den "Online-Brickv" auch herunterzuladen und auf einem eigenen Server zu platzieren.

    [Umfrage] Welche Programmiersprache sollen wir als nächstes unterstützen?

    in Software, Programmierung und externe Tools

    Geschrieben

    Node.js ist im wesentlichen ein eigener Server der mittels Javascript programmiert wird. Das heißt du nutzt Javascript als Programmiersprache, hast aber mehr API für Dinge, die im Browser nicht gehen/gewollt sind: Dateizugriff, echte Sockets usw.

     

    Der Unterschied ist also, dass es eigentlich zwei Dinge sind:

    1. JavaScript eine Sprache

    2. node.js: Ein Server der JS ausführt und dazu API in JS bereitstellt die es im Browser nicht gibt

     

    JavaScript direkt als Binding würde ich beführworten ( wenn dies so "einfach" umzusetzten ist), auch wenn es wohl keine großen Vor- oder Nachteile zu PHP hätte oder?

     

    Vor- und Nachteile sind wohl Geschmacksfrage

     

    Außer dass es im Browser direkt ausgeführt wird.

     

    Das würde nicht für node.js gelten.

    JavaScript-Bindings im Browser halte ich derzeit für nicht umsetzbar, aber ich bin tatsächlich nicht all-zu bewandert auf diesem Gebiet

    Step-Down Power Supply - Belastbarkeit

    in Hardware

    Geschrieben

    Ich kann deine Frage leider nicht selbst beantworten. Bevor du aber zu lange auf eine Antwort warten musst versuche ich es so:

     

    Wusstest du, dass TF alle Schaltpläne usw. auch auf Github veröffentlicht?

     

    Hier ist der Schaltplan fürs Step-Down...

     

    und hier viele andere Dateien...

     

    Ich habe keine Ahnung was diese Striche und Zahlen bedeuten... Aber du vielleicht schon :D

    [C/C++] Keine Werte für Temperatur und Feuchtigkeit in Linux

    in Software, Programmierung und externe Tools

    Geschrieben

    Könntest du bitte nocheinmal prüfen ob die Temperatur in deiner Wohnung... oh okay, das hast du schon geprüft! Dann:

     

    Hast du die korrekten UIDs eingetragen?

    Holst du dir die Temperatur auch über den out-parameter von temperature_get_temperature?

    Wie ist der Rückgabewert von temperature_get_temparature?

     

    Schau dir auf jeden Fall auch die Dokus zu den einzelnen Bricklets an, z.B. diese

    Wie Steckdosen von 2 "Sendern" konfliktfrei schalten?

    in Software, Programmierung und externe Tools

    Geschrieben

    Was wären denn die Konsequenzen aus einer zusätzlichen Antwort? Also ja: Die API würde streng genommen gebrochen, aber was passiert dann?

     

    Für jemanden der mit neuer Firmware auch neue Bindings nutzt

    Nichts, denn aus void wird int (o.ä.) und das ist echt ungefährlich. Nahezu jeder Code sollte vorher und nachher kompilieren (Ausnahme: Func<TResult, ...>).

    Einziges Problem: Neues Timing + Es kann Timeouts geben

     

    Für jemanden mit neuer Firmware und alten Bindings

    Das ist mir nicht ganz klar... ich glaube aber mich zu erinnern, dass unerwartete Antworten von den Bindings verworfen werden... sollte also gar kein Problem sein.

     

    Für jemanden mit neuer Firmware und ohne Bindings (TCP)

    Okay... der hat je nachdem wie er es implementiert hat wirklich ein Problem... aber ich weiß nicht wie wichtig dieser Use Case ist...

     

    Frage: Ist das vertretbar? (Habt ihr so viele Nutzer die das tatsächlich schmerzen würde)

     

    (jetzt kommt der allgemeine Teil)

     

    Die Alternative zu solchen inkompatiblen Änderungen ist ja immer nur eine schlechte API. Entweder schlecht weil die existierenden Probleme nicht behoben werden oder schlecht weil es zu viele Methoden gibt die nur aus Kompatibilitätsgründen existieren...

     

    Vorschlag: Vielleicht solltet ihr über soetwas wie deprecation nachdenken... Also halt jetzt eine neue Methode einführen die den Rückgabewert hat (und einen ordentlichen Namen) und die alte Methode deprecaten, damit ihr sie in einem halben Jahr löschen könnt... ich fürchte aber, dass das aufgrund eures knappen Speichers auf den Bricklets nicht überall klappen wird...

    Wie Steckdosen von 2 "Sendern" konfliktfrei schalten?

    in Software, Programmierung und externe Tools

    Geschrieben

    Also grundsätzlich kann man im eigenen Code (und in einem Programm) durch Locking usw schon dafür sorgen, dass diese Methoden funktionieren...

     

    object switchLock = new object();

void firstAccessor()
{
  lock (switchLock)
  {
    if (bricklet.GetSwitchingState() == SWITCHING_STATE_READY)
    {
      //do switch
    }
  }
}

void otherAccessor()
{
  lock (switchLock)
  {
    if (bricklet.GetSwitchingState() == SWITCHING_STATE_READY)
    {
      //do switch on something different
    }
  }
}

     

    Das Problem: Wenn jeder per locking darauf zugreifen würde, dann wäre es ausgeschlossen, dass jemals ein busy zurück kommt. Deswegen ist der Fall, dass man eine Anwendung für alles hat quasi auch ohne TF gelöst.

     

    Aber was ist beispielsweise wenn die Clients von Loetkolben auf unterschiedlichen Maschinen oder zumindest ohne gemeinsamen Speicher laufen? Dann wäre es gut, wenn man allein mit TF-Mitteln das Locking realisiert bekommt... Dazu die beiden Vorschläge.

×
×
  • Neu erstellen...