AVB in der Theorie super aber die Praxis ist eher bescheiden

Es wird ein AVB 1722.1 Controller, der sich aber auch mit dem Mechanismen des AES67 ausstatteten ließe. Somit zu einen universellen Controller, der mit kniffen sogar in der Lage wäre AES67<-> AVB Geräte zu verbinden. Das Projekt könnte auf einer Switch laufen und somit auch SRP Attribute etc. anzeigen. Die REST API ist ja vorhanden und das Webinterface liefert den Controller gleich mit.

Zahlen muss laut jetziger Planung keiner etwas, trotz die vielen Arbeit.

https://www.l-acoustics.com/en/hotnews/l-a…s10-avb-switch/ kenne ich und ich vermute auch auf welcher Basis die Hardware basiert. Aus dem Grund bin ich gespannt, wie konform mit der Norm das Gerät wirklich ist. Angesichts der über 2000 Seiten nur beim Thema 802.1Q eine spannende Frage

Kurt entschuldige Bitte die schlechte Grammatik und wenn du etwas nicht verstanden hast frage einfach nach

Nunja es ist deutlich komplizierter ;). Denn die IEEE 1722.1 beschreibt die Geräte umfassend. Genau das was bei AES67 und eben auch bei Dante fehlt. Mit der AES70 wird ähnliches versucht Geräte zu beschreiben und Steuerungsmöglichkeiten zu vereinheitlichen.

So mal ein Einblick in das Thema Datenbank. Viola.. Jetzt ergeben sich völlig neue Möglichkeiten. Hier suche in der DB nach Geräten die den selben Modell Identifier besitzen.

Noch unklar ist ob ich die Descriptoren in je einer Tabelle ablege oder als Blob in einer pro entity.

Wenn man pro Descriptor Type eine Tabelle verwendet, ließen sich weitere Filter anwenden. Z.Bsp suche noch den gleichen Streamformat etc.

Das Problem ist er erwartet eine Bunter Oberfläche .. Da er auch verständlicherweise nicht die Technologie versteht... Wie ein Browser aus den zur verfügen gestellten Daten per Javascript und HTML5 genau das baut. Hierzu muss er dann auch keine Software installieren, einen Browser hat jedes Gerät.

Nicht nur das auch andere Geräte z.Bsp Sprachassistenten, Mikrocontroller ohne OS kommen mit der HTML Schnittstelle klar.

Sprachassistenten ?? Wer will mit seinen Mischpult reden .. Das nicht aber im Auto schon, wenn du die Sitzheizung hoch stellen willst und das Auto per AVB/TSN verkabelt wurde. HTML mit REST ist leicht in vielen Dingen zu integrieren.

Durch die Datenbank ist es möglich große Mengen an Geräten mit Eigenschaften zu verwalten. Auch von mehren Standorten. Bisher gibt es keinen Controller der über das Internet ins Layer2 funktionieren würde. Es gibt keinen funktionierenden im Standard vorgesehene Proxy und den braucht man auf beiden Seiten.

Zuletzt könnte das Projekt die Möglichkeit bieten AES67 mit AVB Geräten zu verbinden.

Der Controller könnte auch ein Display etc. besitzen. Von SD oder USB könnte man Konfigurationen in die Geräte spielen... Ja so etwas wäre möglich....

Das einzige Problem ist eben das ich mich alleine Abmühe und immer wieder neue Herausforderung auf einen zu kommen. Die gelöst werden wollen und ich dafür kein Cent bisher bekommen habe.

Jemand der mit HTML und Javascript gut umgehen kann wäre Gold wert... Dann könnte man auch nochmal über die REST API reden. Durch die Datenbank ergeben sich völlig neue Möglichkeiten.

Genau der baut eine simple Oberfläche, der Ansatzweise die Möglichkeiten aufzeigen. In der Hoffnung das dann die Dinge von alleine Fahrt aufnehmen.

Naja es würde mir ja schon reichen wenn jemanden über die API schaut. Ob man diese so verwenden und wie HATEOAS dort integriert werden kann. Meine Angst ist das ich aufgrund der Null Vorerfahrung etwas baue was mir gut gefällt aber von Ansatz her irrend wie nicht gut verwendbar ist. Die JSON API muss einen Status erreichen der Fix ist, bzw. die Regeln wie sie erzeugt werden.

Wenn als Ergebnis ein paar funktionale Seiten heraus kommen z.Bsp. (finden,auflisten und verbinden von Geräten) wäre das eine Tolle Sache. So muss ich an dem Thema nicht viel Zeit verlieren. Die File API ist ja schon seit langen integriert, der Controller ist also in der Lage den HTML und Javascript Code auch auszuliefern.

In Normalfall hat man für so etwas ein Team, mit dem man solche Dinge besprechen kann.

Ich hänge man den aktuellen Workspace mit an...

Hallo...

so ich bin jetzt erst mal zu weit das alle Descriptoren in der Datenbank gespeichert werden. Allerdings ergibt das noch immer keine Sinnvolle Struktur ;). Der nächste Schritt ist jetzt zu schauen wie man die Tabellen untereinander Sinnvoll nutzt. Also als "KEY" ist die entity_id relativ ungeeignet da sie als BLOB gespeichert werden muss. SQLITE kann nicht mit unsigned 64bit umgehen. Besser man nutzt die ROW_ID aus der Tabelle ENTITY_LIST. Denn der Zugriff auf die DB dauert zu lange, ich kann dies nicht blocken bis diese fertig ist. Dann könnte es sein das wenn ein Geräte kurz verschwindet und wieder kommt das sich alt und neu nicht auseinanderhalten lassen. Es bekommt dann eine neue ROW_ID und ein Thread räumt dann alle Daten aus der DB auf die keinen Entity mit der ROW_ID zugeordnet werden können welches in meine linked List steht, diese ist atomar. So die Idee... So kann man wenn Zeit ist alle paar Sekunden schauen ob man die DB mal aufräumt und erzeugt nicht jedes mal große DB trafic..

Anbei mal die SQLITE Datenbank.

Man kann sie mit jedem SQLITE Browser öffnen. https://sqlitebrowser.org/

So ich gebe mal ein kleinen Einblick in die HATEOAS Geschichte, nachzulesen hier https://en.wikipedia.org/wiki/HATEOAS

Vorab, es gibt keine Norm wie man die Ressource abbildet. Es gibt hier zu mehre Konzepte aber keine eindeutige Regel. Ich habe mich für HAL https://en.wikipedia.org/wiki/Hypertext_Application_Language entschieden.

Der Sinn der Aktion ist das der Client ohne die Strukture zu kennen durch die Ressourcen browsen kann. Der Client muss also sich die URIs anhand der Informationen zusammen setzten. Der Vorteil ist eben das man ohne die API zu kennen diese benutzen kann. Man muss also nicht in die Dokumentation schauen und diese verstehen was man nun als nächstes tun könnte.

Der Entwickler von HAL liefert das Framework gleich mit um die Informationen zusammen zusetzen. Ein Tool ist der HAL Browser, diesen liefert der Webserver von meinen Controller aus ... Er besitzt ja eine File API .

Von Bild 1 -> 5 browsen wir jetzt durch die Ressourcen. Sollten sich die links ändern braucht man keine neue API-Version, der Client kommt ja weiterhin zum richtigen Ziel.

Bild 1 zeigt den Einstieg

Bild 2 welche API Version man benutzen kann

Bild 3 wir wählen den path der API v1.0

Bild 4 wir ersetzen den Platzhalter mit dem device und wählen die Ressource "discovery"

Bild 5 wir befinden uns in der Ressource wo es nicht mehr weitergeht.

Der Link in der Spalte "doc" führt zu Dokumentation welche die Ressource beschreibt.

Die REST API ist schon wieder obsolet da ich sie nochmal anpassen muss, also die Json Antworten.

So es geht weiter...

Wir gehen von Descriptor "entity" -> current configuration -> tataaaa

von da geht es dann immer weiter...

was einfach ausschaut war in der Sache doch etwas kompliziert, da das "_link" Object unter rann muss..

Offenbar ließt man hier mit... Komisch das die Json Geschichte plötzlich in ähnlichen Projekten an fahrt aufnimmt .

Was aber keiner kann das es trotz des Controller möglich ist direkt mit dem Gerät zu kommunizieren. Deswegen kann ich in den Json Strukturen nur das darstellen was auch in der Antwort enthalten wäre. Um nicht weitere GET Anfragen auszulösen z.Bsp locale gibt ein _embedded Object in dem dann aus der Datenbank Daten drin stehen auf dem aus dem Descriptor verwiesen wird. Ist die Quelle direkt das Gerät gibt es dieses Object einfach nicht. Und der Clou die Objecte die in _links auf andere Descriptoren zeigen tragen alle ein Query Flag und führen direkt auf das Gerät. Man kann also auch ohne die Datenbank das Gerät lesen, muss aber auf einigen Komfort verzichten. Somit bleibt die Möglichkeit für das Testfeld erhalten.... Das zeige ich nochmal umfassend