AVB in der Theorie super aber die Praxis ist eher bescheiden

  • Halli Hallo -> Statusmeldung :)


    Das meiste an dem AECP Teil wurde umgesetzt, was fehlt ist alles das wo man den Controller als Payload Values übergeben muss. HTTP Methode PUT, der Anhang im Body wird wohl ein Json sein und zwar der Teil der als Value hier im Bild zu sehen ist.


    Das dumme daran war das es keinen Sinn macht solche Daten zu senden wenn sie nicht ein mal angezeigt werden. Also wurde der Control Descriptor komplett aufgelöst -> nochmal 80 Seiten die diesem Beschreiben !


    Da kein Gerät solche Fähigkeiten besitzt habe eins bauen müssen :/..


    Was man sehr schon sieht ist wie das ganze von statten geht.


    control_value_type beschreibt den type der Values

    control_type -> was es zu steuern gibt

    signal_type -> von wo das Signal kommt


    der Rest erklärt sich.. außer der "string" das ist der String Descriptor wo der String(Zeichenkette) liegt die das Value beschreibt. Sieben bedeutet -> NO_STRING.


    Der MAC machte dabei keine gute Figur, nach und nach stellte sich heraus das vieles nicht wie gewollt funktioniert. Teilweise kommt auch Daten Müll zurück.

  • Anbei mal ein Beispiel wo der Riedel controller seine grenzen hat.


    Da wo es erst wird kommt nur murks raus... Offenbar so sehr das hier Array grenzen ungeprüft verlassen werden...


    Anbei mal meine response :) und die von wireshark als Beweis..


    Das Object "value" wird so wieder aufgenommen und per PUT Methode zurück gesendet. Damit man auch was verstellen kann :P..


    *json ist leider kein gültiges Format .. man kann das auch hier https://jsoneditoronline.org/ einfügen und und sich durch die Objekte arbeiten ;)

  • So ich habe die Jsons noch mal optimiert. Das RAW Value wird jetzt nur noch als String angezeigt. Der Rest wird dann aufgelöst. Der "Rohwert" in sofern nicht unbedeutend wenn man etwas setzen möchte. Z.bsp die Samplingrate welche sich in ein Pull Feld zusammensetzt... So muss der Anwender das nicht zusammenbasteln , er kann gleich das gewünschte Value aus dem supported Feldern aufnehmen und setzen.


    Video und Sensor Units werden nun auch voll unterstützt, der Support anderer Controller hört genau dort auf :/..

  • Huhu ... so das Konstrukt REST API steht... Die Ressourcen lassen sich über den Path erreichen und mit dem HTTP Methoden abfragen bzw. beeinflussen :) Man kann sogar eine LED auf dem Board schon steuern :). Allerdings hatte der Xmos Stack noch einen Bug mit der Paket Länge, mir fraglich bei einen zertifizierten code, der alles ander als 1772.1 konform ist. Immer mehr muss ich im Stack die Dinge gerade biegen. Damit habe ich das Gefühl das die Firma Xmos den Code schon aufgegeben hat, die letzte Änderungen war vor zwei Jahren.


    Ich habe mir mal zum Entwickeln der REST API ein anderes Tool besorgt als den Browser. Man kann hier auch die API Dokumentieren und natürlich testen, viel besser als mit dem Browser..


    Erstmal funktioniert das nur im body nur als "application/x-www-form-urlencoded".. Da query die Daten sowie so als Json benötigt -> auch dann "application/json"..


    Hierzu muss aber erstmal ein stream basierten Json parser bauen und nicht alles in den speicher zu laden :/ -> dauert...

  • Das geniale ist ja daran das die eigentliche sprach Wurst ist .. ob Javascript,Java,nodeJs,PHP,Go oder sonst was alle können mit HTTP umgehen und auch mit Json...


    Das mit der Oberfläche dauert aber... im Kern des Controllers sind noch viele Baustellen. Aber mit der Oberfläche wird es dann leichter da man sich dann nur noch Gedanken machen muss wie man die Daten zur Verfügung stellt.


    Setzt die Konfiguration auf 3 mit python :huh:, ohne Kenntnis von AVB lassen sich somit andere Anwendungen bauen ... Unter der Haube unterstützt der Controller schon alle AECP Kommandos.. Das Aufwändige ist aber das darstellen in Json und RET API. Controller und fastcgi Modul sind zwei Programme, man könnte auch ein MQTT Modul andocken.. Was aber kommen wird ist ein Proxy wie dieser im Standard beschrieben ist. Somit ergibt sich eine einheitliche Schnittstelle.

    Einmal editiert, zuletzt von marcoboy ()

  • Das Ziel ist in der Version 1.0 kein halbfertiges Produkt zu liefern wie andere eben, deswegen der Fokus erstmal auf ein funktionierendes Back-End..


    Mir wäre es lieb wenn die Oberfläche jemand anderes macht zur gegeben Zeit...


    Denn ich habe was anderes vor da ich in Xmos keine Zukunft sehe.. einen eigenen AVB Stack auf ARM oder RISC-V.. Das letzte lockt mich 8o Wenn Muttis Breitband auch mal bei mir ankommt können interessierte ohne AVB Netzwerk das Projekt auch testen ...

    Einmal editiert, zuletzt von marcoboy ()

  • Noch ein Beispiel mit welchen Problem man zu tun hat...


    Die Control values haben ein Format welches im entsprechenden Descriptor beschrieben ist. Dort sind Unterschiedliche Typen (8,16,32,64,float,double..) beschrieben... Beim setzen spielt das Format keine Rolle und taucht auch nicht im Command auf. Das führt dazu das man das Value nicht mehr anzeigen kann, auch nicht schreiben.. Ich muss ja wissen wie es sich byte weise zusammensetzt. Das steht im Descriptor und dann muss man sich die zahl HEX 0x5566 -> value[0]=0x55,value[1]=0x66 zusammen schieben.


    So wer jetzt noch mitkommt probiere das jetzt mit float oder double -> bitte.... kleiner Tip https://de.wikipedia.org/wiki/Gleitkommazahl


    So ein Käse unzumutbar...


    Ich stehe jetzt zwischen Baum und Borke.. Alle meine Values zeige ich HEX an, warum ? Bei einer Typen sicheren Programmiersprache wie Java weniger ein Problem, aber unter C will man schon wissen welcher Wert einen erwartet. 0x00 Bit 0x0000 16 Bit -> nächstes Problem MAC Adressen 0x11777277773 ist was völlig anderes als 11:77:72...


    Würde ich jetzt den Control Wert Dezimal entgegen nehmen würde ich das Prinzip verlassen :(.. Macht es aber einfacher für den Anwender, oder man muss im Client den HEX wert umformen. Irgend wie trotzdem doof... Nunja selbst EQ werte lassen sich setzen ...


    Hier mal ein String .... Anhand des Formates wird das dann korrekt an den Controller übergeben..

  • HEX 0x5566 -> value[0]=0x55,value[1]=0x66

    Wirklich, Big-Endian? ;)

    Und wegen dem anderen Problem, in den Projekten in denen ich mitgearbeitet habe und über Text-basierte Protokolle (wie JSON) Daten versendet wurde, haben wir uns immer auf die Dezimaldarstellung geeinigt, weil eindeutig definiert. Gleitkommazahlen entsprechend in wissenschaftlicher Notation. Wobei das erstmal unabhänging vom Zahlensystem wäre. Gleitkommazahlen könnte ich ja trotzdem in Hex darstellen.


    Jedenfalls, wenn du alles als Hexadezimale Zahlen in Textform durchs Netzwerk schickst musst du natürlich beachten wie die jeweilige Systemarchitektur des sendenden/empfangenden Systems ist. Von daher Dezimal ist in diesem Kontext das einzig ware, oder eben fest bspw. auf Network-Byte-Order einigen. Und dann kann man sich gleich überlegen, ob man sich nicht die Mühe macht, ein Datenformat festzulegen und alles binär zu senden.


    Aber cooles Projekt :)
    Ist das auch noch als OpenSource-Projekt angedacht zwecks gemeinsamen Fortschreitens?

  • Ja im Grunde geb ich dir recht.. Das spielt keine Rolle da das CGI Modul und der Controller auf der selben Maschine laufen. Alles was auf das Netz geht ist klar definiert nach IEEE sonst würdest du den String auch nicht lesen können ;)


    In C ist das Wurst und das umformen kann Problem mit Unions machen -> 32bit rein float raus :)


    Wenn du mir das float oder double übergibst muss ich das prüfen denn du kannst mir ja so etwas 1.1999929999299999999299999922229299929 übergeben .. geht noch weiter .... bis die zahl in China wieder raus kommt...


    Ich denk darüber nach... was ich vermeiden will das es zu einer unklaren Durchmischung kommt, gerade was die Parameter betrifft. value=hex&value=dezimal


    Ja soll offen sein unter welcher Lizenz ist noch unklar...

    Einmal editiert, zuletzt von marcoboy ()

  • Das hat in der IEEE1722.1 auch seinen Grund. Denn das Format ist bei dem CMD Control GET/SET wird nicht als Parameter übergeben. Um das Format heraus zu bekommen muss man in den Control Descriptor schauen.


    Damit ist auch klar das es eigentlich keine andere Möglichkeit gäbe die Daten beim Empfang ohne Kenntnis des Descriptors zu entschlüsseln. Also kommt das als byte Array zurück..


    Was für ein Gerät auch nicht schlimm wäre, denn wenn man was setzen will kennt man auch das Format ;) ...


    Ich habe jetzt zwei Möglichkeiten, entweder es den Anwender es zu überlassen die Daten so zu arrangieren und diese mir byte weise zu übergeben. Doch Vorsicht ! Ich bekommt die als String UTF8 Kodiert, reservierte Zeichen müssen entwertet werden. Json ähnlich.. Oder den Type auf Binär setzen...


    So ich habe das schon so einfach gemacht das man anhand des Formates die Values anhängt und somit das schieben entfällt.


    Man stelle sich einen Fader vor und der Client müsse die Daten so aufarbeiten.. Keine wirklich Lösung...


    So da bin ich fertig *lol* sämtliche Formate lassen sich jetzt dezimal eingeben ! Allerdings bei der Antwort muss ich noch was umstricken so das man Parameter mit übergeben kann. Der Count der Formate wird auch geprüft :)


    Das mit dem Parametern kann man auch in der REST Auflösen --/{entity_id}/{command}/{desc_type}/{desc_index}/{format}?value=1.999&value=-10.2

  • So was neues :) Ich bin fast durch mit dem AECP Kommandos.. Ich habe alle

    Security Kommandos umgesetzt ! Somit ist dies der ein zigste Controller der das überhaupt unterstützt. Die Tokens bzw. KEYs müssen als base64 übergeben werden -> https://de.wikipedia.org/wiki/Base64 ... Da die Daten wie schon erwähnt nicht in UTF8 oder reservierte Zeichen enthalten... Ich habe den Xmos Stack so erweitert das dieser mir mit gültigen Daten Antwortet .. Leider ist auch in Wireshark an der Stelle einiges durcheinander geraten :( ..


    https://www.base64decode.org/ -> eG1vcyBmcmlzdCBrZWluZW4gYmFzZTY0IEd1cmtlbnNhbGF0 zum decodieren...


    Die Controller Values nehme ich auch als base64 entgegen und gebe sie so zurück. Wenn man 400 Werte mit value=10&value=1.... füllen muss wird das dann doch doof.


    Anbei habe ich mal einen Rasbpery Pi und Node Red probiert etwas zusammen zu basteln.. Um einfach mal zu schauen wie gut oder auch schlecht sich das Json verarbeiten lässt... Der Flow fragt ein Value ab und steuert abhängig des wertes eine LED :) ...

  • ja auch das Kommando write_descriptor funktioniert :) ... der base64 String "AA4AAQAAAAAAAAAAAAEAAAAAAAAADg=" ist ein descriptor ;)


    Die Response zeig ich aber nicht an, da das Kommando als nicht erfolgreich zurück kam. Laut Standard müsste es die aktuellen Daten zurück liefern -> da das aber kaum einer macht zeige ich sie lieber nicht an :/..

  • Warum ? Also ich hatte noch kein Gerät in der Hand welches den Standard erfüllte. Es sagt ja niemand das es nicht funktioniert. Laut Standard wäre es kein Problem Hersteller A mit B zu verbinden und es zu steuern. Nur halten sich die Hersteller mehr oder weniger nicht an den Standard. Das führt dann dazu das du zwei Controller Applikationen benötigst oder auch drei .... usw.


    Außerhalb von AVB haben andere Protokolle auch kein Problem mit der Switch..


    Es gibt ja nicht mal einen Controller der den Standard 100% unterstützt.. Aber daran arbeiten wir bereits 8o. Ich würde mich auch um die Switch kümmern , nur habe ich nur ein Hirn und zwei Hände.