Gestern brachte mich ein Kumpel auf die Idee einen iOS-Kurzbefehl zu schreiben, um meinen Shelly Plug S1 per Tap zu schalten.2 Eigentlich einfach, aber die Tücke liegt im Detail…
Wenn man sich die entsprechende API-Dokumentation ansieht, dann ist das nicht schwierig. Man ruft eine URL in folgender Form auf:
http://shellyplug-s-XXXXXX/relay/0?turn=toggle
Die “XXXXXX” in der URL stellen den gerätespezifischen Teil des Gerätenamens dar und ist an das jeweilige Gerät anzupassen.
Der Parameter toggle schaltet zwischen An und Aus hin und her. Möchte man einen definierten Zustand vorgeben, dann kann man on bzw. off verwenden.
Sofern das Shelly mehrere Relays hat, ist der Index hinter dem …/relay/ (im Beispiel 0) entsprechend anzupassen, wobei des erste Relay mit „0“ bezeichnet ist.
Ist der Zugriff auf den Shelly mit Usernamen und Passwort gesichert, dann sind diese dem Gerätenamen voranzustellen:
http://username:password@shellyplug-s-XXXXXX/relay/0?turn=toggle
Um die Funktion der codierten URL zu prüfen habe ich diese einfach in meinen Desktop-Bowser reingeworfen. Dabei wurde ich immer wieder zur Eingabe von Usernamen und Passwort aufgefordert, obwohl ich diese zutreffend in der URL kodiert war.
Irgendwann habe ich die URL in den Kurzbefehl eingesetzt und den Kurzbefehl laufen lassen. Und es funktionierte.
Die Desktop-Browser (hier Safari und Chrome) scheinen das Authentifikationsschema zu identifizieren und aufgerund der ungesicherten http-Verbindung die Credentials aus der URL zu entfernen. In der Folge erscheint der Dialog zur Abfrage von Usernamen und Passwort. ARGH!
Achso, der iOS-Kurzbefehl: Man verwendet die Aktion Inhalte von URL abrufen mit der entsprechend angepassten URL. Den Kurzbefehl kann man hier abrufen, muss die URL dann aber noch entsprechend anpassen.