Die Anbindung der IoT-Devices an das Backend (und bei Bedarf auch die Kommunikation der Backend-Komponenten untereinander) sollte am Besten über einen MQTT-Server gemäß einer asynchronen Publish/Subscribe-Architektur erfolgen. Für unser Projekt steht deshalb folgender Server zur Verfügung:
TCP/IP unverschlüsselt: tcp://mqtt.iot-embedded.de:1883
TCP/IP mit Verschlüsselung: ssl://mqtt.iot-embedded.de:8883
WebSocket unverschlüsselt: ws://mqtt.iot-embedded.de:80/
WebSocket mit Verschlüsselung: wss://mqtt.iot-embedded.de:443/
Aus Sicherheitsgründen sollte immer eine verschlüsselte Verbindung gewählt werden. Die unverschlüsselte Verbindung ist nur zum Test und zur Fehlersuche vorgesehen. Unter Java ist daher unbedingt erforderlich, den zur Verfügung gestellten Beispiel-Quellcode zu verwenden. Bei Verwendung der WebSocket-URL auf keinen Fall den / am Ende vergessen. Sonst lehnt der Server die Verbindung ebenfalls ab.
| Projektgruppe | Benutzername | Präfix der erlaubten Topics |
| Indoor-Navigation | indoor-nav | /nav/ |
| Smart Carpool | smart-carpool | /smc/ |
| Smart Office | smart-office | /smo/ |
| Smart Parking | smart-parking | /smp/ |
| Smart Workbench | smart-workbench | /smw/ |
| Transportüberwachung | transport | /trn/ |
| Dozenten | dozent | / |
Die jeweiligen Passwörter werden den einzelnen Projektgruppen gesondert bekannt gegeben.
Jede Projektgruppe besitzt einen eigenen „Namensraum“ für ihre MQTT-Topics. Es muss daher darauf geachtet werden, nur Topics zu verwenden, die mit den oben genannten Präfixen beginnen. Andernfalls werden die Nachrichten vom Server abgewiesen. Dadurch ist sichergestellt, dass sich die verschiedenen Projektgruppen nicht aus Versehen in die Quere kommen. Natürlich können (und sollten) innerhalb des eigenen Namensraums weitere Topics wie zum Beispiel /nav/device-manager oder /nav/device/47110815 verwendet werden.
Wenn gar nichts klappen will
Falls es bei der Verwendung des projekteigenen MQTT-Servers zu unerklärlichen Fehlern kommt, kann es ganz sinnvoll sein, mit einem öffentlichen, nicht abgesicherten MQTT-Server zu testen. Läuft die Anwendung dann damit, lässt sich ein generelles Problem schon einmal ausschließen. Dann kann es nur noch sein, dass entweder falsche Anmeldedaten verwendet werden, die angesprochene Topics nicht der Namenskonvention entsprechen oder der verschlüsselte Verbindungsaufbau nicht klappt. Nach der Fehlerbehebung sollte aber aus Sicherheitsgründen unbedingt wieder auf unseren eigenen MQTT-Server gewechselt werden.
TCP/IP unverschlüsselt: tcp://iot.eclipse.org:1883
TCP/IP mit Verschlüsselung: ssl://iot.eclipse.org:8883
WebSocket unverschlüsselt: ws://iot.eclipse.org:80/ws
WebSocket mit Verschlüsselung: wss://iot.eclipse.org:443/ws