Technische Hintergrundfrage, Webanbindung, REST

[SvB]

Die Maschinensteuerung ist in Delphi geschrieben und steht irgendwo beim Kunden im Netzwerk, hat also nur Kommunikationsmöglichkeit nach außen. Vom Internet her ist die Maschine nicht direkt erreichbar, es gibt also keinen Portweiterleitung von außen nach innen.
Die Maschine muss sich also irgendwie mit dem Webserver verbinden, entweder über regelmäßige periodische Abfrage ob es was neues gibt oder direkt verbunden sein.
In der Kundenumgebung können auch mehrere Maschinen stehen, bzw. über Standorte verteilt sein und es wird auch Konfigurationen für Gruppen von Maschinen geben.

Ich werde mir das mit dem Broker und MQTT ansehen, hört sich interessant an. Der erzeugte Traffic sollte für die reine Änderungsinfo auch nicht so groß sein.

[HolgerX]

Hmm..

Da lt. TE die Maschinen ja anscheinend mit einem REST_Server 'sprechen' können,
sollte dort bereits eine TCP-IP Kommunikation vorhanden sein (Ohne die geht HTTP/REST nicht).

TCP/IP ist für MQTT die Mindest-Voraussetzung, optional können auch andere Schnittstellen benutzt werden, sie müssen nur Bytes als Stream verschicken können und im Brocker zur Verbindung zur Verfügung stehen.

Jede Message bestehrt aus wenigen Bytes als Header und dem Payload.
Der Payload beinhaltet eigendlich die Message und kann alles sein, von Bytes über einfache Strings hin zu XML/JSON...

Es müsste somit nur eine (verallgemeinerte) Definition eben dieses Payloads erstellt werden, über den die Maschine mitteilt, was sie als Konfiguration erwarten kann und eben die Steuerbefehle entschlüsselt.

Alternativ würde bei (alten) Maschinen ohne TCP/IP eh ein PI oder Microcontroller dazwischen geschaltet werden müssen, um das Protokoll zu implementieren, dort würde dann der MQTT-Client installiert werden plus die Hardware-Seitige Anbindung zur Maschine.

Altrernativ könnte das sogar auf einem 8-Bit Microcontroller installiert werden, da die benötigten Resourcen überschaubar sind

Beispiel:
Die Maschine meldet sich am Broker an und schickt (in definierter Form) eine Beschreibung aller Sensoren und Aktoren, welche sie zur Verfügung stellt.

Der REST-Service wird per Brocker benachrichtigt, erhält die Definition (MQTT kennt den Inhalt nicht!) und richtet bei sich dann die Views und Parametereinträge ein, welche von Extern dann angesprochen werden können.

Bei Änderung (durch REST-Put/GET.. von externen System) würde dann der REST per MQTT an die Maschine einen (im Format definierten) Befehl schicken, um den Sensor X abzufragen oder den Aktor Y auf Wert XXX zu sezten.

Was das nun wirklich für Sensoren oder Aktoren sind, braucht der REST-Service nicht komplett zu kennen. Auch, wie die Daten dann Technisch bei der Maschine ankommen bzw. Umgesetzt werden ist dem REST-Service egal, dass macht dann der MQTT-Client auf der Maschinenseite..

[HolgerX]

Hmm..

Zitat von SvB:

Der erzeugte Traffic sollte für die reine Änderungsinfo auch nicht so groß sein.

Bei MQTT sind das im Minimum nur wenige Bytes..
Hängt von deiner Definition der Kommandos/Payload-Daten ab

[SvB]

Die Kommunikationsart, bzw. das Protokoll ist noch nicht festgelegt. Deshalb dieser Beitrag, weil ich in der Richtung noch nichts gemacht habe und von daher nicht weiß mit welcher Technologie man da am besten ran geht. Auf der Webseite ist noch alles offen, da gibt es noch nichts. Auf der Maschinenseite gibt es nur die Steuerung, die Anbindung an den Server (im Internet) ist auch noch offen.

Wie gesagt, ich schaue mir eure Vorschläge mal an. Hört sich auf jeden Fall vielversprechend an.