Jump to content

rtrbt

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    1.401

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

 Inhaltstyp 

Posts erstellt von rtrbt

    Probleme mit Lastmanagement

    in WARP Charger

    Geschrieben

    Kurzes Update: Ich habe in das Lastmanagement testweise eingebaut, dass wenn Strom übrig ist, dieser an Wallboxen zugeteilt wird, die bereits einmal geladen haben ohne dass danach das Fahrzeug abgezogen wurde. Kannst du bitte kurz mit der angehangenen Firmware testen ob nachdem du deinen Tesla normal auf 70% geladen hast (und nicht abgezogen!) der Ladestart über die App funktioniert bzw die Heizung über Wallbox-Strom? Bis auf diese Änderung ist die Firmware identisch zu 1.1.1.

    warp2_firmware_1_1_1_61b32328_merged.bin

    Veröffentlichungen

    in WARP Charger

    Geschrieben

    Firmware: WARP1 1.3.1

    • Unnötige Logmeldungen des Logins entfernt
    • Übersetzungen überarbeitet
    • Konfigurationspartition auf robusteres Dateisystem umgestellt
    • Login-Probleme nach Update von Firmwares älter als 1.3.0 behoben
    • Modalfenster für NFC-Karten und gesteuerte Wallboxen verbessert
    • Bug der zur Anzeige eines leeren Webinterfaces führt behoben
    • Recovery-Seite hinzugefügt
    • Warnung vor Downgrades hinzugefügt
    • Logmeldungen über mehr Netzwerkereignisse hinzugefügt

    Download: WARP1 1.3.1

    Veröffentlichungen

    in WARP Charger

    Geschrieben

    Firmware: WARP2 1.1.1

    • Unnötige Logmeldungen des Logins entfernt
    • Übersetzungen überarbeitet
    • Konfigurationspartition auf robusteres Dateisystem umgestellt
    • Modalfenster für NFC-Karten und gesteuerte Wallboxen verbessert
    • Bug der zur Anzeige eines leeren Webinterfaces führt behoben
    • Watchdog des verfügbaren Lastmanagementstroms zurückgesetzt wenn dieser über die API gesetzt wird.
    • Recovery-Seite hinzugefügt
    • Warnung vor Downgrades hinzugefügt
    • Logmeldungen über mehr Netzwerkereignisse hinzugefügt
    • Detektion aktiver und verbundener Phasen verbessert (durch Update auf Ladecontroller-Firmware 2.0.6)
    • Detektion von Fahrzeugen verbessert, falls beim Start ein Fehler vorliegt (durch Update auf Ladecontroller-Firmware 2.0.6)

    Download: WARP2 1.1.1

    Verbindung zur Wallbox verloren

    in WARP Charger

    Geschrieben

    On 12/6/2021 at 5:52 PM, e-Dream said:

    Eine Fritzbox ist doch ein sehr verbreitet Router,dass da sonst niemand Probleme hat?

    Bisher kenne ich nur den einen anderen Kunden mit LAN-Problemen. Bei ihm ist es auch eine Fritzbox (7362SL) . Auf der anderen Seite haben wir aber extrem viele Kunden, Kollegen und auch die Wallboxen hier in der Firma an Fritzboxen, bei denen die LAN-Verbindung anstandslos funktioniert. In Summe bin ich davon so verwirrt wie du.

    On 12/6/2021 at 5:52 PM, e-Dream said:

    Ich warte einmal deine Test ab,ob dies wirklich ein DHCP-Problem in Verbindung mit einer Fritzbox ist.

    Das hat sich zerschlagen, statische IPs haben auch nicht geholfen.

    Als letzte Idee: Hast du

    On 12/3/2021 at 4:02 PM, rtrbt said:

    (Auch auf der Recovery-Seite) Wenn das LAN nicht mehr geht und du in die Box unter API folgendes einträgst:
        {"method": "PUT", "url":"/ethernet/force_reset", "payload":"null"}
        und auf Call API klickst, funktioniert LAN dann nach ~ 10 Sekunden wieder?

    getestet? Wenn das nicht hilft wäre der nächste Schritt vermutlich den ESP Ethernet Brick auszutauschen, der in der Wallbox verbaut ist.

    Als ganz verzweifelte Idee: Besteht die Möglichkeit, dass du ein anderes LAN-Kabel ausprobierst?

    Verbindung zur Wallbox verloren

    in WARP Charger

    Geschrieben

    2 hours ago, e-Dream said:

    Ich benutze den Browser von Samsung( hat mit dem ja vor der statischen IP Umstellung  auch funktioniert).

    Ich habe kurz mit dem Samsung-Handy von einem Kollegen getestet: Scheinbar ist die Websocket-Unterstützung des Samsung Browsers kaputt bzw. unterstützt NUR wss. Ich fürchte, da müsstest du mal den Browser wechseln. Mit Chrome und Firefox funktionierts.

    2 hours ago, e-Dream said:

    Gibt es ein bestimmtes Vorgehen bei Betrieb/Verbindung mit einem LAN-Kabel.

    Also erst LAN Kabel rein oder erst die Box stromlos machen und dann das LAN rein o.ä?

    Eigentlich sollte sofort wenn du ein LAN-Kabel ansteckst die Verbindung aufgebaut werden. Bei dem anderen Kunden mit dem selben Problem sieht es derzeit aber tatsächlich nach einem DHCP-Problem mit der Fritzbox aus. Ich habe hier ein Testscript laufen, falls ich damit etwas rausfinde melde ich mich nochmal.

    • Thanks 1

    Verbindung zur Wallbox verloren

    in WARP Charger

    Geschrieben

    14 hours ago, e-Dream said:

    Gibt es den keine weitere Möglichkeit (ohne die Wallbox aufzuschrauben) einen Werksreset durchzuführen?

    Mit der neuen Firmware schon. Unter http://10.0.0.1/recovery gibt es einen Button dafür. Du musst nur erst RESET in die Textbox davor schreiben, damit man das nicht ausversehen auslöst:

    grafik.png

     

    Dass das Webinterface nicht sinnvoll angezeigt wird ist suspekt. Was für einen Browser benutzt du auf deinem Handy?

    Verbindung zur Wallbox verloren

    in WARP Charger

    Geschrieben

    Der neue Thread bzw. der Post in den Veröffentlichungen folgt noch. Die neue Firmware findest du hier:

    http://warp-charger.com/firmwares/warp2_firmware_1_1_1_61aa27dd_merged.bin

    Auf der Website seibst wird die Firmware erst am Montag sichtbar, man sollte ja nicht große Änderungen Freitag Nachmittags veröffentlichen ;)

    Die neue Firmware kannst du, wenn du mit dem Access Point der Wallbox verbunden bist unter http://10.0.0.1/update flashen.

    Teste mit der neuen Firmware dann bitte folgende Dinge:

    1. Du hattest geschrieben, dass es nach einem Neustart für ein paar Minuten funktioniert, danach kommst du nur noch per WLAN auf die Wallbox.
      1.  Lade eine Debug-Report von der Wallbox herunter, wenn die LAN-Verbindung gerade geht
      2. Lade noch einen herunter (über WLAN) wenn die LAN-Verbindung nicht mehr geht
    2.  Du hattest geschrieben, dass wenn es nicht mehr geht, du einen Neustart der Wallbox machen musst. Reicht es dann über WLAN einen Neustart über das Webinterface auszulösen? (System -> Firmware-Aktualisierung)
      1. Gehe über WLAN auf IP der Wallbox/recovery, also z.B. http://192.168.178.123/recovery und löse einen Force Reboot aus. Geht das LAN dann wieder für ein paar Minuten?
      2. (Auch auf der Recovery-Seite) Wenn das LAN nicht mehr geht und du in die Box unter API folgendes einträgst:
            {"method": "PUT", "url":"/ethernet/force_reset", "payload":"null"}
            und auf Call API klickst, funktioniert LAN dann nach ~ 10 Sekunden wieder?
    3. Falls du ohne größere Probleme einen Rechner neben die Wallbox bekommst: Konfiguriere auf der Wallbox und auf dem Rechner statische IPs und verbinde beide direkt mit einem LAN-Kabel. Funktioniert das?

    Was für eine Fritz Box hast du genau?

    Verbindung zur Wallbox verloren

    in WARP Charger

    Geschrieben

    Sorry, war gestern nicht mehr dazu gekommen dir was zu schreiben. Ich baue gerade die Recovery-Seite der Wallbox aus, damit die HTTP-Put-Geschichte einfacher ist (und man darüber den Reset auf Werkszustand auslösen kann). Wenn das fertig ist, kommt es in Firmware 1.1.1, die diese Woche noch erscheint. Mit der finden wir dann hoffentlich raus, warum bei dir (und auch bei mindestens einer anderen Wallbox, siehe hier:

    ) diese Ethernet-Probleme bestehen.

    WARP1: Core 1 panic'ed

    in WARP Charger

    Geschrieben

    https://github.com/Tinkerforge/esp32-firmware/commit/f25ea41db9f65459cf4a27c9d17cd6c212a24954

    sollte das Problem gelöst haben. Ich hatte in

    https://github.com/Tinkerforge/esp32-firmware/commit/3a77faec23b6557dbb4c91a1c0fc062b0f1390b2

    alle Designated Initializers aus dem Code geworfen, weil das eher C-Stil ist und die C++-Compiler sich (berechtigterweise) darüber beschweren. Bei der Initialisierung der MQTT-Config fehlten aber die geschweiften Klammern, damit erstmal alles auf 0 (technisch gesehen: auf die jeweiligen defaults) initialisiert wird. Das führte dann dazu, dass esp-mqtt versucht hat die Länge des nicht initialisierten Last-Will-Topics zu bestimmen:

    https://github.com/espressif/esp-mqtt/blob/89894bd0c611b1392967fe90bb49682eba858383/mqtt_client.c#L407

    (einem Wert den wir nicht schreiben, das kommt eventuell noch, siehe https://github.com/Tinkerforge/esp32-firmware/issues/34). Daher dann der Crash.

    Nochmal danke fürs melden!

    • Like 1

    Verbindung zur Wallbox verloren

    in WARP Charger

    Geschrieben

    1 hour ago, e-Dream said:

    Vermute stark,dass bei der statischen IP-Vergabe was in die Hose gegangen ist.

    Laut Debug-Report sieht das soweit gut aus:

    Quote

    "ip": [192, 168, 178, 175],
    "gateway": [192, 168, 178, 1],
    "subnet": [255, 255, 255, 0],

    Da ich die API falsch im Kopf hatte ist aber im Report kein Event-Log enthalten. Kannst du den bitte auch noch abrufen? Sorry, dass ich nicht gleich daran gedacht habe. Das Eventlog bekommst du unter http://10.0.0.1/event_log

    1 hour ago, e-Dream said:

    Reset(auf Werkseinstellung zurücksetzen)=Stromlos und Knopf gedrückt halten,warum geht dies nicht mehr?

    Das haben wir aus der Firmware genommen, da viele Elektriker die Box testen, ohne den Deckel wieder anzuschließen. Der Taster ist ein Öffner, das heißt, wenn er nicht angeschlossen ist, denkt die Wallbox, dass er gedrückt ist. Wenn man dann die Box ohne Deckel (und damit ohne Taster) betreibt, geht sie in eine Reset-Schleife.

    Für einen Reset auf Werkseinstellungen gibt es jetzt noch zwei Möglichkeiten (und bald noch eine dritte, einfacher zu benutzende): Entweder musst du die Box aufschrauben, den ESP ausbauen und an einen PC anschließen, das wird in der aktuellen Anleitung genauer erklärt (https://www.warp-charger.com/documents/WARP2_Betriebsanleitung.pdf?v=2 Seite 12), oder wir müssen entweder das Webinterface wieder zum Laufen bekommen, bzw. du musst einen HTTP-Put-Request absetzen können, das wäre tendenziell mit einem Laptop einfacher.

    Verbindung zur Wallbox verloren

    in WARP Charger

    Geschrieben

    Dass das Webinterface über den WLAN Access Point nicht geht liegt eventuell daran, dass du deine mobile Datenverbindung aktiviert hast. Viele Handys kommen dann mit dem Routing durcheinander. Wenn du die deaktivierst, würde ich erwarten, dass es funktioniert.

    Zum LAN-Problem: Ruf, wenn du auf das Webinterface zugreifen kannst mal einen Debug-Report ab (unter System->Ereignis-Log) und poste ihn hier, eventuell sehen wir dann mehr.

    Falls die Idee von oben nicht hilft, kannst du versuchen den Report händisch abzurufen, indem du auf http://10.0.0.1/debug_report gehst.

    WARP1: Core 1 panic'ed

    in WARP Charger

    Geschrieben

    Moin Thomas,

    Das sieht im ersten Moment in der Tat so aus, als wäre es ein SPIFFS-Problem, ist es aber vermutlich nicht. Die verwirrenden Meldungen kommen daher, dass wir in letzter Zeit von SPIFFS auf LittleFS umgestellt haben, weil das schneller und vorallem robuster ist. Damit dann bei einem Update von einer SPIFFS auf eine LittleFS-Firmware nicht die Konfiguration verloren geht, macht die (neue) Firmware einen Migrationsschritt, der unter anderem involviert, dass die zunächst geprüft wird, ob die Konfigurationspartition eine SPIFFS-Partition ist, und wenn ja, wird die Migration ausgeführt.

    Diese Prüfung führt aber noch dazu, dass Meldungen wie

    Quote 
    E (27) SPIFFS: mount failed, -10025

    angezeigt werden. Das aufzuhübschen ist einer der nächsten Schritte, ich hatte dann als Schnellschuss erstmal die Meldung davor eingebaut:

    Quote 
    Checking if spiffs is mountable as SPIFFS. Please ignore following SPIFFS errors

    D.h. du kannst das ignorieren. Es hatte erstmal nicht die höchste Priorität, die verwirrenden Meldungen loszuwerden, da man sie ja nur auf der seriellen Konsole sieht.

    Quote 
    Checking if spiffs is mountable as LittleFS. Please ignore following LittleFS errors
90          Mounted configuration partition. 8192 of 3538944 bytes (0.2 %) used

    Diese Kombination aus Logmeldungen sagt dann übrigens, dass alles soweit okay ist, die Konfigurationspartition ist ein LittleFS und lies sich erfolgreich mounten.

     

    Zu deinem eigentlichen Problem: Da das Mounten klappt, steckt der Fehler wo anders. Am besten decodierst du den Backtrace, der ausgegeben wird, dann siehst du, in welchem Codestück der ESP sich aufhängt: Dazu brauchst du die zugehörige .elf-Datei zu der .bin-Datei, die du geflasht hast (die sollte im build-Verzeichnis liegen und die selbe Versionsnummer haben. Also zu warp2_firmware_1_3_0-61a119ca.bin z.B. die warp2_firmware_1_3_0-61a119ca.elf.). Das Dekodieren kannst du mit xtensa-esp32-elf-addr2line auf der Kommandozeile machen machen, das liegt im Platformio-Ordner (https://docs.platformio.org/en/latest/projectconf/section_platformio.html#directory-options) unter packages/toolchain-xtensa-esp32/bin/ 

    xtensa-esp32-elf-addr2line -pfiaC -e /pfad/zur/warp2_firmware_1_3_0-61a119ca.elf 0x4008a8e1:0x3ffb1f900x40089c1a:0x3ffb1fa0 0x40089c09:0x3ffb1fc0 0x40137329:0x3ffb1fe0 0x401383ec:0x3ffb2000 0x40138be3:0x3ffb2040 0x400f2e00:0x3ffb2090 0x400e0f11:0x3ffb21e0 0x4010627e:0x3ffb2820

    Sollte dir dann einen sinnvollen Backtrace ausgeben, mit Dateinamen und Zeilennummern. Den kannst du gerne hier posten, dann werfe ich auch mal einen Blick darauf, vorallem wenn das Problem nicht in deinem Code auftritt.

    Grüße,
    Erik

    Starthilfe TCP/IP

    in Anfängerfragen und FAQ

    Geschrieben

    Ah, dass du mit MaxMSP direkt ohne Code und SDK TCP-Pakete schicken/empfangen kannst war mir nicht klar. Das ändert natürlich einiges. Ich bin da beim googlen falsch abgebogen und dachte, dass du mit dem SDK ein C-Modul schreibst.

    Wenn du das TFP-Protokoll händisch benutzen willst, musst du im Endeffekt nur die Bricklets dazu bringen, dass sie ihre Callbacks aktivieren, lies: dass sie von sich aus Daten zu dir senden. Das RGB LED Button Bricklet macht das automatisch, deshalb funktioniert das einfach so, bei den anderen müsstest die entsprechende Funktion aufrufen (was heißt, das entsprechende TCP-Paket schicken)

    Um an den Payload zu kommen, kannst du also entweder in der TCP/IP-Dokumentation die einzelnen Paketformate nachschlagen (z.B. hier für die Position des Motorized Linear Poti Bricklets) oder du schneidest den Traffic des Brick Viewers oder eines kleinen Testprogramms mit.

    Probleme mit Lastmanagement

    in WARP Charger

    Geschrieben

    Du hast vollkommen recht, das ist in der Firmware kaputt. Das Problem ist, dass der Lastmanager auf der Wallbox nicht die API benutzt, sondern ein eigenes Protokoll mit den anderen Boxen spricht. Wenn du über die API managed_current aktualisierst, fehlt der Aufruf, der den Watchdog entschärft. Ich habe das im Quellcode gerade gefixt.

    https://github.com/Tinkerforge/esp32-firmware/commit/d2834cf2af5f8e3f20cff4da682db36afccb10e5

    Es kommt diese Woche noch Firmware 1.3.1, der API-Fix wird enthalten sein, eventuell kommt dann auch der Fix für das eigentliche Problem mit dem Lastmanager, das kann ich dir aber noch nicht versprechen.

    Edit: Firmware 1.1.1, wir reden ja von WARP 2.

    Anmeldung an Warp1 nach FW Update 1.3.0 nicht mehr möglich

    in WARP Charger

    Geschrieben

    On 11/19/2021 at 7:42 PM, int5749 said:

    Ich habe immer mehrere Instanzen von FF mit einigen Fenstern laufen.

    Das ist eine gute Erklärung, der Firefox cacht das in der Tat, bis er einmal komplett neustartet.

    On 11/19/2021 at 7:42 PM, int5749 said:

    Schon seltsam, war das Verhalten: Es wurde ja scheinbar das PW abgelehnt, dies wurde rot umrandet.

    Jain, die Loginseite fragt den Server nur, ob der komplette Satz Login-Daten korrekt ist, die Rückmeldung ist dann aber immer "falsches Passwort".

    On 11/19/2021 at 11:24 PM, jensstark said:

    Bei mir identischer Effekt mit Edge. Richtiges Passwort loopte wieder zur Anmeldung, falsches blinkte noch ein wenig. :D

    Hm dass ein richtiges Passwort wieder die Anmeldeseite lädt ist interessant: Das heißt, dass Edge scheinbar für jede Unter-URL einen eigenen Cache hat und dann mit der neuen Realm die Login-Daten geprüft hat, aber für die Hauptseite wieder die alte verwendet.

    Probleme mit Lastmanagement

    in WARP Charger

    Geschrieben

    Moin Christoph,

    12 hours ago, ChriSpi68 said:

    Erst nach einem Neustart weist der Lastmanager der ersten Wallbox 16A zu, so dass er mit voller Leistung laden kann. Ich habe die beiden Wallboxen schon mehrfach zurückgesetzt und bei beiden den Lastmanager probiert.

    Einem Neustart wovon? Prinzipiell musst du die Wallbox, auf der du den Lastmanager eingerichtet hast, einmal neustarten, wenn die Konfiguration verändert wird (also wenn du auf der Lastmanagement-Unterseite Änderungen vornimmst). Danach sollte es aber ohne Neustart funktionieren.

    12 hours ago, ChriSpi68 said:

    Nach Abschluss des Ladevorgangs setzt der Lademanager die Leistung auf 0A. Der Tesla lädt damit nicht nach, wenn der SOC unter den Sollwert sinkt. Zu Lösung muss ich wieder mehrfach neue Starten der das Kabel ziehen und wieder einstecken. Dies ist aber nicht praktikabel, wenn ich beispielsweise im Urlaub bin und durch den Grundverbrauch der SOC sinkt.

    Das ist ein sehr interessanter Punkt. Der Lastmanager nimmt nachdem ein Ladevorgang abgeschlossen ist die Ladeerlaubnis weg (indem eben der Strom auf 0A gesetzt wird), damit andere Ladevorgänge die gleichzeitig laufen könnten mehr Strom zur Verfügung haben. Die Box bleibt dann blockiert, bis das Auto einmal abgezogen wird. Der Grund dafür ist, dass die Kommunikation zwischen Wallbox und Auto sehr limitiert ist: Wenn das Lastmanagement gerade blockiert, kann nicht unterschieden werden, ob ein Auto gerade Strom möchte oder nicht.

    Das erklärt auch das Verhalten wenn du den Ziel-SoC änderst bzw. die Heizung verwendest.

    Ganz ehrlich: Das Problem, dass ein Auto sich dann einmal voll laden und dann über Wochen wieder leerstehen kann, bzw. die Sache mit der Heizung hatte ich nicht auf dem Schirm. Wir werden aber eine Lösung dafür bauen. Der erste Schnellschuss wäre, dass wenn Strom nach der üblichen Verteilung übrig ist, dieser dann auf Wallboxen verteilt wird, deren Autos bereits einmal geladen haben. Eventuell dafür dann nur der Minimalstrom von 6 A, um praktisch zu testen ob das Auto wieder Strom möchte. Das muss ich aber nochmal in Ruhe überdenken, Änderungen auf dem Niveau sind immer gefährlich. Ich habe mal ein Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/73

    13 hours ago, ChriSpi68 said:

    Im Log erscheint alle 30 Sekunden die Meldung, dass der Watchdog die Ladeleistung aufgrund von Inaktivität auf 16A setzt. Sie bleibt aber trotzdem bei 0A.

    Da musst du aufpassen: Das ist der Watchdog für eine externe Steuerung. Die Dokumentation dazu ist leider noch etwas dünn (Siehe auch: https://github.com/Tinkerforge/esp32-firmware/issues/58) Die Kurzzusammenfassung ist: Wenn du von extern dem Lastmanager vorgegen willst, wie viel Strom er gerade verteilen darf, z.B. weil du eine PV-Anlage hast, dann kannst du das über die API machen und den Watchdog aktivieren, der dann, falls deine externe Steuerung ausfällt, den Ladestrom zurück auf den Default-Wert setzt.

    Es gibt noch einen zweiten Watchdog, der immer auf 0A setzen sollte, der ist dafür da, dass wenn der Lastmanager selbst ausfällt, einzelne Boxen nicht durchdrehen können. (Das betrifft die Lastmanagement-Ladestromgrenze die du unter Ladecontroller sehen kannst).

    13 hours ago, ChriSpi68 said:

    Ich habe versucht, meinen eigenen Lastmanager zu programmieren. Mit "curl -H "Content-Type: application/json" -X PUT -d "{\"current\":9000}" 192.168.1.27/evse/managed_current_update" setze ich den maximalen Strom im Abstand von 10 Sekunden. Die 9A erscheinen aber nur manchmal im Web-Interface und dann auch nur für kurze Zeit. Ansonsten wird hier nur 0A angezeigt.

    Das sollte so funktionieren. Die einzige Erklärung die ich hätte ist, dass du eventuell deinen eigenen Lastmanager und den eingebauten gleichzeitig aktiv hast? Ansonsten gehe ich dem mal nach.

    13 hours ago, ChriSpi68 said:

    Hier im Forum ist auch die Rede von einem neuen API-Call "managed_current". Allerdings tritt beim Aufruf ein URL-Fehler auf.

    Das ist genau der, den du benutzt. Wenn du ein GET auf "managed_current" (ohne _update) machst, kannst du den Strom den du gesetzt hast wieder auslesen. Wenn du ihn setzen willst musst du aber die Variante mit _update benutzen (und ein PUT machen), das ist damit die API einheitlich zur MQTT-API ist, bei der man sonst nicht unterscheiden kann welche Updates von der Box selbst kamen.

    Starthilfe TCP/IP

    in Anfängerfragen und FAQ

    Geschrieben

    Die erste Frage dazu: Hast du die TCP-Verbindung selbst aufgebaut und versuchst das TFP-Protokoll händisch zu sprechen? Höchstwahrscheinlich ist es einfacher, wenn du nicht direkt per TCP/IP mit dem Stapel bzw. mit dem Brick Daemon redest, sondern eins unserer Bindings dafür verwendest. Ich habe kurz danach gesucht, es gibt ein SDK mit dem man eigene C-Erweiterungen schreiben kann: https://cycling74.com/sdk/max-sdk-8.2.0/ (Bitte korrigiere mich falls ich da falsch abgebogen bin, MaxMSP sagte mir soweit nichts.)

    Am einfachsten ist es deshalb vermutlich, wenn du mit dem SDK ein Plugin für MaxMSP schreibst, dass unsere C-Bindings benutzt. Sieh dir am besten mal die Beispiele für den RGB-LED-Button an, um ein Gefühl dafür zu bekommen.

    12 hours ago, Tonquader said:

    Anders gefragt, muss ich mit den Befehlen die ich brauche ein eigenes Plugin erstellen welches ich erstmal auf das Bricklet laden muss?

    Du musst nichts auf den Master Brick oder die Bricklets hochladen, das ist kein Arduino, bei dem du eine eigene Firmware schreiben musst. Prinzipiell kannst du das zwar machen, aber das ist ein sehr esoterischer Anwendungsfall.

    12 hours ago, Tonquader said:

    Oder muss ich einfach den benötigten Befehl per Hexdump von MaxMSP aus an das Bricklet senden?

    Das geht prinzipiell auch, du gewinnst aber nichts gegenüber den C-Bindings.

×
×
  • Neu erstellen...