AVB in der Theorie super aber die Praxis ist eher bescheiden

Du kannst die Geräte konfigurieren, überwachen etc. und es funktioniert außerhalb der AVB und PTP Wolke. Also auch über das Netz und die Ressourcen können auch verteilt sein, sie werden ja durch href abgebildet.

Die Bilder oben sind reine Funktionalitäten die man von einen Webserver erwarten würde..

Als ich es mal ausprobieren wollte, also per AJAX https://de.wikipedia.org/wiki/Ajax_(Programmierung) mir Daten zu holen viel mir das Sicherheitskonzept vom Browser auf die Füße. https://de.wikipedia.org/wiki/Cross-Origin_Resource_Sharing

Die Header wurden global in einer Funktion erzeugt, das ging dann so nicht mehr . Die ganze REST Funktionen wurden in einer neue REST Struktur portiert und der Code wurde umgestaltet. So das in jeder Funktion es möglich wird eigene Status Codes und Header zurückzugeben.

Die neue REST Struktur kommt den Konzept schon sehr Nahe.

/entity

/entity/{entity_id}

/entity/{entity_id}/descovery

/entity/{entity_id}/descriptor/{desc_type}/{desc_index}

/entity/{entity_id}/descriptor/{desc_type}/{desc_index}/configuration

usw..

Mit den Methoden GET, POST, PUT, DELETE lassen sich die Ressourcen beeinflussen.

Wenn du am Einstiegspunkt vorbeikommt /entity werden dir bei GET alle Entity anzeigt -> Directory listing.

Frei nach dem Motto von Unix/Linux betrachte alles als Datei.. natürlich

Was ich noch erwähnen wollte .. Die Entwicklung einer Grafischen User Interfaces ist nicht mein Entwicklungsfokus. Da gibt es schon einige Sachen und es liegt auch daran das ich mich in HTLM5 und Javascript stärker einarbeiten müsste. Zumal mit Javascript mein C Stil versaue. Ich hoffe das sich andere finden werden.

Das schöne ist ja man muss nicht einmal die Webserver Funktionalitäten vom Controller nutzen, man kann das auf jeden Server aufsetzen und links setzen zum Controller.

MQTT ist auch in Planung, steht aber in der Timeline ganz hinten... Ist ja schon jetzt möglich -> NodeJs

Mal ein kleiner Einblick in das neue REST Konzept..

http://localhost:7778/avb/ oder http://localhost:7778/avb/entity liefert die verfügbaren Geräte zurück -> Einstiegspfad..

http://localhost:7778/avb/entity/7D-…scriptor/entity den Deskriptor entity

http://localhost:7778/avb/entity/7D-…onfiguration/0/ Deskriptor der Konfiguration vom Index 0

http://http//localhost:777…n/0/audioUnit/0 Deskriptor der Konfiguration vom Index 0 vom Type Audio Unit mit dem index 0

wie kann man jetzt Ressourcen beeinflussen ?

http://localhost:7778/avb/entity/7D-…on/0/lockEntity per PUT setzt einen lock auf dem Deskriptor

http://localhost:7778/avb/entity/7D-…r/entity/name/0 gibt den Name vom Deskriptor mit dem Name Index 0

geht auch mit der Audio Unit per GET und setzten per PUT

http://http//localhost:777…ioUnit/0/name/0

Die Deskriptoren sind untereinander verschachtelt z.Bsp so

Gibt das Sensor Format zurück GET und setzt es PUT

http://localhost:7778/avb/entity/00-…/0/sensorFormat

Gibt den Deskriptor sensorCluster mit dem Index 0 zurück

http://localhost:7778/avb/entity/00-…ensorCluster/0/

gibt die aktuelle Konfiguration zurück GET oder setzt sie PUT

http://localhost:7778/avb/entity/7D-…0/configuration

Prinzip verstanden ? Bitte auf das Link Symbol mit der Mouse fahren um die komplette URI zu sehen...

der Clou ist dann das in der Antwort Links enthalten sind mit relativen Pfad, der Client muss von der Struktur nichts wissen. Er folgt dann einfach den links. Die das komplette Geräte wird so abgebildet.

Um z.Bsp auf den Memory Inhalt zu zugreifen..

ließt den Inhalt vom Memory mit dem Index 0 GET oder PUT schreibt

http://localhost:7778/avb/entity/7D-…/0/memoryAccess

Das ist die Entity Identfier, die ist für alle Geräte eindeutig. Ähnlich wie die UID(RDM), MAC Adresse, teilweise setzt sie sich diese aus der MAC Adresse des AVB Interfaces zusammen.

Es gibt Möglichkeiten im Protokoll auf den Speicher der Geräte zu zugreifen. Z.Bsp für Firmware Updates, Piktogramme, Control Daten, oder snapshot etc. aus den Geräten zu laden bzw zu schreiben. Das ist im Descriptor "Memory beschrieben. Also Start und Anfangsadresse, um was es sich handelt usw. Abgehandelt wird das ganze dann nicht über den Descriptor sondern über das AECP_AA Protokoll.

Ich schau dann in den Descriptor setzte die richtigen Adressen und liefere dir in der Response den richtigen MIME Typ zurück . Sonst müsstest du wie oben gezeigt erst den Descriptor auslesen und das Kommando richtig absetzten. All das entfällt und es können auf die Ressourcen ohne tieferes Wissen zugriffen werden.

https://www.l-acoustics.com/en/hotnews/l-a…s10-avb-switch/

mal was neues, mich würde interessieren ob hier Marvell oder Microchip zum Einsatz kam.

Ich mir das auch mal mit dem MILAN angeschaut. Kurz gefasst sind es Absprachen welche Funktionen ein Gerät unterstützten muss. Ein paar Kommandos wurde die Response um Felder erweitert, was ich unschön finde. Da dies an einer nicht vorgesehenen Stelle passiert. Wenn die IEEE das Protokoll erweitert gibt es den Salat. Beim ACMP haben sie die Funktionen umbenannte und die Timeouts auf 200ms festgelegt. AVB Geräte haben hier z.Bsp beim TX_CONNECT 3s Zeit. Ob das ausreicht um die Bandbreite mit SRP über 7 Switches zu reservieren !? Da zweifel ich die 200ms arg an...

Man hat sich auch auf ein einfaches Streamformat geeinigt, AM824 ist doch zu komplex.

Außerdem wurde ein Vendor basierendes Protokoll hinzu gefügt, mit dem Kommando get_milan_info.

Alles halb sie schlimm, wenn ich noch heraus bekommen wie man milan Geräte sicher erkennt.

So es hat sich was getan...

- Rest API wurde komplett überarbeitet

- die JSON auch

- die API wurde dokumentiert damit man auch damit was anfangen kann

- der controller macht sich jetzt auch per ADP discovery im AVB Netztwerk bekannt

- AECP AEM kann er auch und es lässt sich der Descriptor entity anrufen, dann ist auch ersichtlich wie das Schwein heißt, mit anderen Controller lässt dann auch ein Namen etc zuweisen (noch nicht implementiert )

- Bugs beseitigt und Verbesserung umgesetzt..

Wer schauen will https://insomnia.rest/ den Workspace im ZIP File importieren. Unter den Reiter Doc sieht man auch was zurückkommt. Um es auszuprobieren benötigt man den Controller . Wer es wirklich probieren möchte kann die Einzelheiten mit mir abklären.

Rechtschreibfehler und unklare Äußerungen sind inkl. . Es fehlen noch die HATEOAS links.. https://en.wikipedia.org/wiki/HATEOAS . Noch muss man die Struktur des Entitys kennen oder sich durch arbeiten.

Ich muss nochmal auf die Frage des Entity Identfier eingehen.

Nun hat man sich im Standard 2016 ausgedacht das diese auch dynamisch vergeben werden können. So wie das bei USB üblich ist. Das bedeutet sobald das Gerät bootet hat es eine andere UID. "schulze tauscht mit Lehmann, Lehmann mit Maier..

Dynamische EUIs kann man anhand der Bits erkennen https://de.wikipedia.org/wiki/EUI-64.

Die Geräte müssen dabei sicherstellen das keine EUI doppelt vergeben wird.

Für den Controller bedeutet das mitzubekommen wenn ein Gerät bootet um den Datenbestand neu aufzubauen. (Bei mir erfüllt ).

Für den Anwender muss klar sein das diese Daten nicht sicher sind und ich hoffe das kein Hersteller auf die Idee kommt Stageboxen mit dynamischen EUIs herzustellen.

Nunja das mit dem dynamischen EUIs hat seinen Hintergrund das man Geräten einfachen Zugang zum AVB Netzwerk ermöglichen möchte. Feste EUIs müssen Formal Registriert sein. Jeder Hersteller bekommt seinen Bereich zugewiesen. Das ist mit Aufwand und mit kosten verbunden.

Bei DMX RDM ist die Zuweisung kostenlos, auch ich habe eine eigene UID zugewiesen bekommen und kann damit offiziell im RDM Netzwerk teilnehmen .

Die bekannten Schlitzaugen kopieren auch UIDs und MAC Adressen, da diesen der Aufwand sie formal zu Registrieren zu hoch erscheint. So kommt es dann mal vor das Geräte mit deinen Adressen auftauchen.

Das Problem mit dem dynamischen Geräten ist er das Controller damit umgehen müssen das sie plötzlich mit Lehmann anstatt mit Schulze sprechen.

Per MAAP werden ja MAC Adressen für den Stream schon dynamisch vergeben. Der Pool umfasst 255 Adressen. Diese Adressen sind in der Switch als Multicast registriert. Somit ist die Anzahl der Streams in einer AVB Netzwerk auf 255 Streams begrenzt.

Zitat von Karel Noon

das wäre natürlich ein Unding, bei Avid ist es so das man den Stageboxen zwar Namen geben kann, diese sind aber nur oberflächlich, selbst wenn ich als Beispiel Stage1 und Stage2 habe, und die Namen tausche, also 1 gegen zwei kommen die doch wieder an die alte Stelle im System.

Scheint also zumindest dort richtig gemacht worden zu sein.

Du änderst ja die entity ID nicht die ist fix und pro Gerät nur einmal vergeben. Außer sie wird dynamisch erzeugt. Denn kann das Gerät nach dem booten eine andere entity ID bekommen. Vorher muss aber das entity sicherstellen das die ID nicht vergeben ist. Hierzu müsste es erst mal ein ADP entity_disccover senden worauf alle entitys mit einen ADP entity_available antworten.

Kurz um entity_disccover antwortet nur Apple... XMOS nicht -> das werde ich aber noch fixen :). Hier muss man ein viertel der valid_time abwarten bis das entity die entity_available messages versendet.

Der Controller macht beim starten genau das gleiche, er sendet ein ADP entity_disccover womit sich alle entity melden sollten und somit sofort in der liste erscheinen. Die valid_time kann von 2-62 sec vom entity vorgegeben werden. Es dauert also maximal 62 Sekunden bis ein Entity in den Timeout läuft.

Ein Entity kann sich aber auch abmelden wenn sich der Controller beendet sendet dieser eine entity_departs messages.

der xmos hat noch einen entscheiden BUG der mir auffiel, er verzählt sich im available_index. Womit mein Controller sich veranlasst fühlt, das entity neu einzulesen. Es könnte ja gebootet haben..

Ich bin gerade damit das Problem mit der Datenbank in angriff zu nehmen .

Meine Auswahl viel auf http://whitedb.org/ womit durch die GPLV3 in unsicheres Fahrwasser begebe .. Deswegen habe ich beschlossen den Reiter nicht ausschließlich auf dieses Pferd zu setzen. Was bedeutet das der alte Code basierend auf einen File erhalten bleibt und die Grundsätzlichen Funktionen nachgeführt werden. So kann man sich später entscheiden oder den Code austauschen.

So eine In-Memory-Datenbank hat viele Vorteile und die ersten Test sehen vielversprechend aus...

Warum jetzt doch hat damit zu tun das ich den Mechanismus "unsolicited notification" Implementieren wollte.

Damit kann ich ein Controller beim Entity registrieren und erhält die Antworten vom Kommandos die Änderungen auslösen ebenfalls. Z.Bsp wenn ändert man die Samplerate, oder einen Namen etc.

Ich wollte die Daten dann im zugehörigen Descriptor Aktualisieren und nicht wie andere alle Descriptoren neu einlesen . Genau ist ja auch nicht der Sinn der Kommandos aber einige haben sich das einfach gemacht, z.Bsp Riedel AVB Manager.

Andere haben da ganz andere Ideen http://grouper.ieee.org/groups/1722/1/…tion%20time.pdf

Genau das bitte nicht und schon gar nicht Pakete teilen wenn sie dann zu groß sind ! Es gibt keine Dynamischen Infos, es sind Daten die zu den Descriptoren gehören bzw. aus diesen ihren Ursprung haben.

Der Controller muss die Daten in den Descriptoren nach führen ohne diese neu zu lesen, alles andere Erzeugt jedes mal eine hohes Trafic aufkommen, welches die Warteschlange überfordert.

Genau hierzu braucht man eine Datenbank in dem man die Einträge heraus sucht und aktualisiert und die Anfragen der Clients erfolgen kann aus der db heraus und nicht aus den entitys.

kleines Update...

also ich hatte mich in die Datenbank mit whitedb vertieft und das an hat sich schon funktioniert. Aber den Ansatz doch erst mal verworfen. Der Grund war wie schon erwähnt Lizenz Probleme und auch mit dem Code um dem sich der Entwickler nicht mehr kümmern mag. Damit mir das nicht um die Ohren fliegt habe ich das erst mal ausgesetzt. Aber der Code ist so gestaltet das man es von dem File basierten speicher zu etwas anderem wechseln kann.

Hierzu musste ich leider auch teile entfernen die sehr performant waren. Das Öffnen/Schließen des Files dauert bis die Hardware antwortet. Auch die ADP Daten werden so gespeichert das sie als Blob in einen db verwendbar sind.

Was jetzt funktioniert ist die "unsolicited notification".. Ich lese die oder den descriptor nicht neu sondern tausche die Daten aus. Hinzu kam auch ein neuer query Parameter bei GET Anfragen, der es ermöglicht das ziel für die Anfrage zu beeinflussen. Man kann also Daten aus der DB oder vom entity abfragen. Somit ist der Controller weiterhin für die Entwicklung brauchbar oder wenn eine entity nicht wie vorgesehen funktioniert.

Ein intelligenter Algorithmus wird dann entscheiden ob eine GET Anfragen zum entity oder aus der DB beantwortet werden. So zieht der Controller die Last zu sich, hält aber die Daten trotzdem Aktuell. Wie beschrieben lässt sich dieser Algorithmus mit einen Query Parameter übergehen.

Hier mal ein kleines update...

Ich arbeite ein einen Datenbank basierten speicher.... Da die bisherige Form alles in ein File zu schreiben den Anforderungen nicht mehr gerecht werden kann. Das Problem besteht vor allen daran mapping Tables zu speichern und wenn diese dynamisch erfolgen werden diese nicht einmal über einen descriptor beschrieben.

Das speichern und vor allen das suchen in einen unorganisierten File ist nicht gerade performant und zielführend. Sich darüber Gedanken zu machen wie es lösbar wäre verbraucht genau oder mehr Energie als gleich eine Datenbanklösung einzubauen.

Es wird doch eine SQL Lösung... Die Wahl viel auf sqlite https://www.sqlite.org..

Dadurch ergeben sich Möglichkeiten die dem Projekt sehr förderlich sind. Man könnte sich auch seine eigenen JSON oder XML Antworten zusammen bauen.

Da der SQL Syntax weitestgehend portable wäre eine Anbindung an eine externe Datenbank möglich.

Ich arbeite an den Tabellen um das DB tauglich umzusetzen. Funktionalitäten gab es erst mal keine, "unsolicited notification" funktioniert so lange sich die Daten in einen Descriptor abbilden lassen werden diese auch aktualisiert. Wer an den aktuellen Stand interessiert ist möge sich melden...

p.s der RPI läuft seit 3 Monaten durch ..