AVB in der Theorie super aber die Praxis ist eher bescheiden

  • Nun es hat sich einiges getan... Da ich den HTTP Code umgearbeitet habe ist es möglich an jedem Punkt den HTTP Statuscode und auch eine Antwort zu generieren....


    Sämtliche Parameter werden jetzt geprüft, Range,Count, Reihenfolge, Vollständigkeit.


    Ich habe mich auch nochmal mit den Operation Kommando auseinander gesetzt und es korrekt implementiert. Die API musste hier angepasst werden ;)


    Schluss endlich habe ich mich entschieden das HAL aus der RESTapi wieder zu entfernen :huh:...


    Warum ? Das Problem ist das HAL keine Methoden außer GET abbilden kann. Das führt unweigerlich zu einer Einbahnstraße und zu einer schlechten API. Da um andere Methoden anzuwenden müsste man weitere Request erzeugen... Schlechte API...


    Auch wird HAL seit 2016 nicht mehr weiterentwickelt... Ich könnte natürlich es an meine Bedürfnisse anpassen und erweitern. Aber das stellt einen komplizierten Einzelweg dar und man braucht eine weitere Dokumentation. Bringt nichts, weg damit :D... Es bleibt aber erst mal drin bis sich was besseres findet oder jemand mir sagt was sich als geeignet erweist? Es zeigt aber eindrucksvoll was eine Event getriebene API ausmacht...

  • https://de.wikipedia.org/wiki/Hypertext_Application_Language


    Die schicken Screenshots sind ja dynamisch erzeugter HTML Code auf Basis der im Json zur Verfügung gestellten links.


    Das funktioniert auch soweit ganz gut, kommt aber eine seine grenzen wenn es um Methoden außer GET geht. Denn um eine Anfrage zu stellen werden Parameter benötigt, diese Information kann HAL nicht abbilden. https://json-schema.org/ schon.. Aber du musst dir das Schema erst mal holen um das eigentliche Json zu verstehen . Bedeutet zwei Anfragen, A: daten B: schema...


    Das Problem ist gibt vieles mit vor und Nachteile... Es gibt niemanden der ein UI Programmiert also ist die Entscheidung sehr schwer... Mit dem Schema kann man bis zum UI alles beschreiben, z.Bsp ein im Control Descriptor mit einen Fader kann so beschrieben werden das die UI Applikation einen Fader rendert.


    Sinn also ist es die Daten so zu beschreiben das die zukünftige Anwendung sich anhand dieser Daten selber baut ;). Das ist wichtig da die Geräte alle unterschiedliche Eigenschaften haben und man diese Eigenschaften schlecht statisch darstellen kann. Gerade was Control angeht. Da macht es Sinn einen UI Generator zu benutzen :thumbup:.


    Genau dieser Pikante Ansatz mit REST API macht den Unterschied zwischen anderen Controllern aus! Außerdem lassen sich Geräte auch außerhalb der AVB Domain und des lokalen Netzes verwalten.

    2 Mal editiert, zuletzt von marcoboy ()

  • Noch was, bei großen Projekte tritt ein Problem auf das jedes System seinen eigenen Controller mit bringt. Um die Geräte zu bedienen oder zu verwalten benötigt man eine Software die alle Protokolle beherrscht. Solch eine Software ist "Schweine teuer" und aufgrund vieler geschlossener Protokolle meist auch nur über Umwege möglich.


    Durch HTML und einer offene REST API lassen sich AVB Geräte einfach verwalten und steuern. Das Projekt steht ja am Anfang... Wenn jemand genau sagt welche Anforderungen er stellt lässt sich das ja einarbeiten. Das Projekt ist in so weit immer flexibler... Oben gezeigt, man kann die Daten auch binär, XML etc. haben...

  • Ja aber sie liefert in den Antworten Informationen aus , die zum rendern der UI Applikation verwendet werden.


    Wenn sich was ändert, braucht man die Applikation nicht ändern :)


    z.Bsp https://jsonforms.io/docs/what-is-jsonforms


    https://www.informatik-aktuell…te-web-applikationen.html



    Das eigentlich Design legt die Applikation fest.... Verstanden ? Daraus lässt sich auch ganz simple eine eigenständige APP bauen. Es gibt Frameworks in dem man das verwenden kann.

    Einmal editiert, zuletzt von marcoboy ()

  • Achso - und ich dachte du generierst die jSons und dein Controller will drüber angesteuert werden, sodass ein client mit oder ohne UI auch von einem andren rechner im netzwerk aus werkeln könnte.


    Da hätt ich mal einen Versuch mit einem simplen VB client gestartet, aber das scheint ein grobes Missverständis gewesen zu sein. Java und Html kann ich leider (noch?) nicht


    versteh ich das richtig dass die reader- & talker- devices dir diese Jsons abfragen lassen und dem controller seine eigenschaften mitteilen?

    kannst mir das kurz erklären? (ist das eine standardisierte URI oder bei jedem Hersteller/gerät andreas?)


    Gruß

    Dominik

  • Der Controller generiert die Json, XML oder sonst was aus den Daten der Geräte. Die REST API beschreibt die Ressourcen und dessen Methoden.


    Um das ganze zu nutzen musst du ja Kenntnis von der API haben und natürlich auch von AVB. Sonst bist du selbst mit herumprobieren nicht in Stande das Sinnvoll zu nutzen.


    Jetzt kommt die Event gesteuerte API, die gibt dir zusätzliche Informationen was du mit diesen Daten machen kannst und welche Elemente des UI zu steuern Sinnvoll sind. Du musst dir das so vorstellen das hinter jeder Tür weitere Türen auftauchen die der Anwender verwenden kann. So treibt sich die API von alleine ! Wenn du etwas änderst verschiebst du nur die Tür und der Client findet schon den weg da er ja den links folgt. Sonst muss du deinen Client Code anpassen, da du sonst gegen die Wand läufst.


    Der HTML Code wird auf dem Client von einen Javascript erzeugt das die im Json vom Controller gelieferten Informationen verarbeitet. Alles optional, du musst diese Daten nicht verwenden, du kannst auch die Dokumente statisch auswerten. Dann solltest du die API und AVB verstehen.


    Der Controller funktioniert auch wie ein ganz normaler Webserver :). Man kann Files downloaden oder uploaden. Die Ressourcen werden durch den Path beschrieben... In einen HTML Dokument sind ja ganz viele Elemente drin die nachgeladen werden. Scripte,Bilder,Schema etc....


    Der Path kann ja auch unterschiedlich sein http://192.168.1.55/avb/ http://192.168.4.33/avb das ist den HTML Client egal wo die Ressource liegt... Man kann also auch mehre Netze mit einem Client verwalten :). Fast wenn die Cors Regeln das Browsers das nicht blockieren :rolleyes:... https://developer.mozilla.org/de/docs/Web/HTTP/CORS keine Sorge ich kann damit umgehen sonst lädt der Browser die Scripte nicht.

  • Der Controller generiert die Json, XML oder sonst was aus den Daten der Geräte. Die REST API beschreibt die Ressourcen und dessen Methoden.


    Um das ganze zu nutzen musst du ja Kenntnis von der API haben und natürlich auch von AVB. Sonst bist du selbst mit herumprobieren nicht in Stande das Sinnvoll zu nutzen.

    nur um zu prüfen ob ichs nun verstanden hab:


    also ist das generieren der Json dann doch in "deiner Hand" -> d.H. wenn das System nachdem du das jSon strukturierst kennst müsstest du ja auch den ümgekehrten Weg gehen können.


    (jSon und REST hab ich schon kennengelernt - und habs bisher über VB ausgewertet und Objekte entsprechend "befüllt" - da gings aber eher um "Ticketverwaltung" am Servicedesk das war teilweise auch generisch aber folgte einer definierten Struktur ähnlich einem "Objektmodel")


    die Daten der Geräte bekommst du über den MRRP der einzelnen Geräte die sich "anmelden" nehme ich an.

    Jetzt kommt die Event gesteuerte API, die gibt dir zusätzliche Informationen was du mit diesen Daten machen kannst und welche Elemente des UI zu steuern Sinnvoll sind. Du musst dir das so vorstellen das hinter jeder Tür weitere Türen auftauchen die der Anwender verwenden kann. So treibt sich die API von alleine ! Wenn du etwas änderst verschiebst du nur die Tür und der Client findet schon den weg da er ja den links folgt. Sonst muss du deinen Client Code anpassen, da du sonst gegen die Wand läufst.

    als Beispiel für so ein Event: Hallo ich bin ein neuer Talker ich heiße "xxx" kann "y" Kanäle zur Verfügung stellen - als Format kann ich dir x oder z anbieten .....

    Entsprechend dieser info willst du/(bzw machst du bereits?) dann deine HTMLSeite aufbauen.


    wenn das stimmt hab ich den faden wieder gefunden:)

    Einmal editiert, zuletzt von zarfld ()

  • Das Kernproblem ist folgendes.... Ich will vermeiden das es von dem Projekt 100 verschiedene Versionen gibt. Das Projekt verfolgt genau eben nicht solches Ziel, sondern ein Core der so flexible ist das ihn Hersteller trotzdem anpassen können ohne meinen Code anzufassen.


    Ob als Client ein Browser zum Einsatz kommt ist vollkommen irrelevant.


    Nochmal wenn die API nicht kennst kann du sie nicht nutzen. Wie willst du wissen welche Seiten man von einen Webserver abrufen kann wenn sie nicht gelistet sind ?


    Mit HATEOS https://en.wikipedia.org/wiki/HATEOAS wird das ziel verfolgt die Ressourcen zu beschreiben, so das sie von Scripten gelesen werden können.


    Beispiel: http://localhost:7778/avb/v1.0/devices


    liefert das zurück.. Ohne die links wüstest du nicht wie es jetzt weiter geht ?


    Das Objekt _links beschreibt wie es weitergehen könnte... Ein Script verarbeitet das auf dem Client und erzeugt daraus Code... meist HTML...

  • Das Kernproblem ist folgendes.... Ich will vermeiden das es von dem Projekt 100 verschiedene Versionen gibt. Das Projekt verfolgt genau eben nicht solches Ziel, sondern ein Core der so flexible ist das ihn Hersteller trotzdem anpassen können ohne meinen Code anzufassen.


    Ob als Client ein Browser zum Einsatz kommt ist vollkommen irrelevant.


    Nochmal wenn die API nicht kennst kann du sie nicht nutzen. Wie willst du wissen welche Seiten man von einen Webserver abrufen kann wenn sie nicht gelistet sind ?

    das ist klar und macht ja auch Sinn

    Nochmal wenn die API nicht kennst kann du sie nicht nutzen. Wie willst du wissen welche Seiten man von einen Webserver abrufen kann wenn sie nicht gelistet sind ?

    ich natürlich nicht - aber der der den Webserver erstellt müsste doch wissen was er gebaut hat bzw oder besser nach welchen Regeln sie sich generisch aufbaut.


    oder ist dein Problem dass dies noch nicht klar ist bzw du unsicher bist obs dir passt.



    Bitte nicht als Kritik verstehen - ich versuche nur zu folgen bzw. dein Problem zu verstehn.

  • Der das gebaut hat kennt die Struktur und beschreibt diese in seiner Dokumentation. Aber der Erbauer kennt die Geräte nicht! Denn diese haben alle je nach Ausstattung eine andere Struktur. Die mit den "Descriptoren" beschrieben wird.


    Wenn du keine Ahnung von AVB hast wird es schwer die Daten zu analysieren und daraus die richtigen Aktionen abzuleiten.


    Dante und co. machen sich das einfach, denn diese haben alle im Kern die selbst Struktur. So detailliert beim AVB werden die Geräte nicht beschrieben. Sie schicken nur Daten und und her...


    links sind ein Kernelement des Internets. Ohne Suchmaschine und dessen links wäre es schwierig. Fast alle Seiten werden heute dynamisch erzeugt. Sonst wären sie nicht so bunt und toll. Du kannst dir mal mal Screenshots von 20 Jahre alten Seiten anschauen. Berühmt ist diese hier http://soundlight.de/ :D läuft heute noch mit jedem Browser auch auf der Konsole...


    Er im Gegenteil, dir fehlen die Grundlagen zu HTML,REST, und JSON... Was ich erklärt habe sind alles solche Grundlagen, das hat mit den eigentlichen Problem wenig zu tun.


    Das Kernproblem ist welches Prinzip für das Konzept geeignet erscheint.... Das kann mir nur jemand sagen der Erfahrung damit hat... Dieser kennt auch die Grundlagen :/.. Das ist auch nicht böse gemeint....


    Denn auch solch eine API schüttelt man nicht mal so aus der Hand, das ist viel harte Arbeit. Die man mit dummen Bemerkungen mal eben nicht kaputt macht...

    3 Mal editiert, zuletzt von marcoboy ()

  • Mir schon klar, das Projekt richtet sich erst mal nicht an Endanwender . Da wie schon festgestellt eine funktionsfähige Oberfläche fehlt... Ich hoffe das andere "Hersteller" mir diese Arbeit abnehmen bzw. diesen in ihrer Anwendersoftware übernehmen. Also aus dieser heraus den Controller mit der API ansprechen....


    Win10 wird ein Linux Subsystem besitzen und so fern ist die Portierung relativ einfach....


  • Hier mal ein Beispiel was man damit machen könnte... Der Client muss kein Browser sein, hier mit NodeRed ein simples Script gebaut um ein Control Value abzufragen. Um damit eine LED zu steuern.


    Total simple, geht das mit anderen Controller auch !?

  • Das Json sieht so aus..


  • Ich glaube er das GUI ist für das Projekt auch nicht interessant... Interessant ist es für jene die große Netzwerke betreuen und AVB Geräte bauen. Möglicherweise auch für jene die einen AVB Controller in ihrem Systemcontrollern mit einbauen wollen. Durch die REST API kann dieser ja leicht in dessen Interfaces eingefügt werden.


    Vielleicht drücke ich am Ende der Geschichte auch auf "DELETE" :huh:... Immerhin kenne ich mich nun mit AVB aus :D...


    Ich habe keine Ahnung, Kontakte diesbezüglich sind seit der Krise eingeschlafen.


    https://www.amwa.tv/nmos ist ja so was ähnliches... Bis November hatte ich das gar nicht auf dem Schirm, erstaunlich waren aber die parallelen Ansätze ohne das "ich" zumindest nicht ab geschaut habe ;)..

    Was ich mit HAL versucht habe machen Sie mit https://raml.org/ und JSON Schema... Das hatte ich glaube ich schon mal erwähnt, mir war das ganze zu aufgeblasen.... Ich wollte eine API die mit einem Mikrocontroller verarbeitet werden kann und sich auf das wesentliche beschränkt.


    Doch hatte ich überlegt NMOS mit einzubauen und einen Weg zu finden AVB u. AES67 Geräte zu verbinden.


    Zumal ist das mit NMOS deutlich einfacher, da die Geräte nicht so im Detail beschrieben werden... Im 1722.1 ist bis zur Buchse alles beschrieben... Außerhalb der AVB Welt ist der Stream der gemeinsame Nenner, den Rest macht jeder wie wer meint.... NMOS in Geräte zu integrieren ist auch deutlich Ressourcen behafteter als das 1722.... Der Xmos fällt da aus, zu wenig Ressourcen...

    2 Mal editiert, zuletzt von marcoboy ()

  • Es gibt Neuigkeiten, natürlich wurde am Projekt gearbeitet... Der Code wurde optimiert und die values im Path wie auch alles was den Controller übergeben wird geprüft. Man bekommt jetzt auch eine genaue Ursache inkl. HTML Fehlercode zurück. Leider ist durch diese Eingabeprüfung die Möglichkeit verloren gegangen auch values mit falschen Werten zu übergeben. Ganz praktisch wenn man Geräte entwickelt. Deswegen habe ich darüber nachgedacht durch bedingte kompilierung den Check auszuhebeln. Der Controller fängt es ja vorher ab ;).


    Das Thema Operationen funktioniert jetzt inkl. des Status. Sobald man eine Operation auslöst wird dieser im Controller angelegt und der Status der per Broadcast empfangen wird aktualisiert. Man muss die Operation aber selber wieder löschen, das ist leider der Haken an der Geschichte. Die Ursache liegt einfach daran das ich nicht weiß ob ein Client die Ressource noch anfragt, beim status von 100%. Timeout etc. war angedacht ist aber alles Käse und nicht REST Konform das sich was selbst löscht.


    Nebenbei festgestellt das kein Controller oder die Xmos Geräte das Firmware update wie im Standard beschrieben ausführen. Dazu brauchen sie das Operations Command. Es wird einen Path in der API geben in dem dies vereinfacht möglich ist. Man lädt per POST die Firmware hoch und der Controller macht den Rest. Dazu brauch ich aber Tokens und die benötigen OpenSSL. Das bläst das ganze wieder ein Stück auf und ich muss mir auch ein Gerät bauen wo dies wie vorgesehen funktioniert.


    Es gab von der von mir benutzen 1722.1 Bibliothek Fehler, auch beim Xmos. Behoben...


    Ich hänge mal den Workspace an, bitte die neuste Version von Insomnia benutzen es gab mehrere krasse Bugs so das die Variablen nicht mehr funktionierten. Die Kommandos wurden in der Dokumention besser beschrieben und es gab leichte Änderungen. Auch beim HAL, ich tüftle da ab und zu herum.


    Hive soll jetzt auch eine REST API bekommen :/... Ich habe vor der Arbeit und der vielen Fallstricke gewarnt. Irgendwie habe ich das Gefühl das hier ein Wettbewerb aufkeimt. Darauf habe ich ehrlich gesagt keinen Bock...


    Wie immer ich kann euch ein RPI senden um das ganze mal auszuprobieren. Denn das ganze läuft stabil :)...

  • So... ich habe mich jetzt mit cmake https://cmake.org/ befasst.... Unter Unix baut der builder immer noch ein Makefile ;)... Aber es bestünde die Möglichkeit andere builder zu nutzen und den Grundstein zu legen das Projekt zu portieren.


    Ein paar mal ins Klogeriffen und eine Tasse Kaffee mit dem Ellenbogen über den alten Dell geschoben... Mit dem Föhn versucht das teil zu retten und dieser viel dann auch noch auseinander <X... Der Föhn... Was für ein Toller Tag, meine Frau will natürlich einen neuen Föhn...


    Man stelle fest das dass mit cmake gut funktioniert, an den Feinheiten muss ich noch arbeiten. Extra target für Doxygen gebaut, damit wird auch die Dokumention erzeugt wenn man das möchte...


    Jetzt sind nur noch die scipte für die Installation offen...

    Dann wird der Code weiter optimiert...