Aufruf der lokalen API mit cURL

    Hallo Community,


    in all den Jahren hatte ich nie ein größeres Problem mit der SHC 1.0. Jetzt mit der lokalen App habe ich mich an das Thema API gemacht.

    Ich möchte gerne mit cURL Befehle auf der SHC aufrufen, um mich nicht immer einloggen zu müssen.


    Allerdings scheitere ich bereits an der Authentifizierung mit diesem Befehl:

    Code
    curl -X POST http://192.168.0.150:8080/auth/token -H "Content-Type: application/json" -d '{"grant_type":"password","username":"admin","password":"meinPasswort"}'


    Ich bekomme auf der CLI diese Nachricht zurück:
    {"errorcode":2003,"description":"The client ID or password are invalid","messages":[]}


    Wenn ich mich im Browser einlogge, kann ich bisher nicht den Fehler 2003 reproduzieren, sondern bekommen bei einem falschen Passwort den error code 2009.


    Hat jemand schon mal erfolgreich mit curl und der lokalen App gearbeitet?


    Danke für jede Hilfe :)

    Also ich habe noch nicht mit der API gearbeitet, habe es aber irgendwann mal vor. Wenn ich jedoch in die Doku schaue:

    3. Authorization API


    dann scheint man den eigenen, selbst geschriebenen Client erstmal bekannt machen zu müssen. Du erhältst dann eine Client-ID , welche Du an den Server schickst. Damit bekommst Du eine Login-Seite bzw. wirst auf Deine eigene Loginseite gelenkt. Von dort dann User/Pass senden und du bekommst ein Token, welches Du für alle weiteren Dinge benötigst. Das ist klassisches OAuth2.

    Mistery is solved. To get a valid token, you need to run


    Code
    curl -X POST http://192.168.0.106:8080/auth/token
   -H "Content-Type: application/json"
   -H 'Authorization: Basic Y2xpZW50SWQ6Y2xpZW50UGFzcw=='
   -d '{
    "username": "admin",
    "password": "myPassword",
    "grant_type": "password"
}'

    The string in header "Authentication: Basic" Y2xpZW50SWQ6Y2xpZW50UGFzcw== needs to be exactly like this (decoded value is "clientId:clientPass".


    Running this curl, the access token is returned.

    Thanks a lot... now it works ^^

    Zitat von Lactans

    Mistery is solved. To get a valid token, you need to run


    Code
    curl -X POST http://192.168.0.106:8080/auth/token
   -H "Content-Type: application/json"
   -H 'Authorization: Basic Y2xpZW50SWQ6Y2xpZW50UGFzcw=='
   -d '{
    "username": "admin",
    "password": "myPassword",
    "grant_type": "password"
}'

    The string in header "Authentication: Basic" Y2xpZW50SWQ6Y2xpZW50UGFzcw== needs to be exactly like this (decoded value is "clientId:clientPass".


    Running this curl, the access token is returned.

    Danke an Lactans für die Anpassung an clientID_secret und den grant_type.

    Dadurch bekomme ich meine Authorization: Bearer eyJhbGciOiJSUzI1NiIs....


    Als nächstes wollte ich mir ganz simpel ALLE Geräte ausgeben lassen (GET All Devices) - was bei mir nicht klappt. Ich bekomme keinen ERROR, sondern nur "NOT FOUND". Selbes bei "status"-Abfrage.

    Ist meine API-URL http://192.168.178.100:8080/api/1.1/status falsch?


    DANKE schon mal 😉,

    Tom


    Meine Hardware: SHC-1, 2 x SHC-2 (als Reserve)

    2 Mal editiert, zuletzt von CharlyT () aus folgendem Grund: update meiner SHC

    Hello everybody,


    currently I am at the same point when trying with calls to the local API on SHC-1, while using Postman.

    After successfully generating a bearer token, "Get" requests for "status", "devices" or "message" always return the same fault, here e.g. for "message":


    http://192.168.1.113:8080/api/1.1/message


    Responce body:


    <html>

    <head>
        <title>NotFound</title>
    </head>

    <body>
        <h1>NotFound</h1>
        <p></p>
        <hr>
    </body>

    </html>


    Maybe someone has an idea what is wrong?


    Thanks in advance! Werner


    Addition:


    Inbetween I found my mistake: "/API/1.1" must be left away.


    http://192.168.1.113:8080/message

    Hier mal ein kurzes Feedback, was ich via POSTMAN und über die lokale API geschafft habe. Vielleicht hilft das ja anderen Nutzern, die überlegen, wie sie im Fall des Falles all ihre "Interactions" (= Szenen) wieder einspielen könnten:


    Ich habe folgendes Test-Szenario erfolgreich über die lokale API umgesetzt:

    1. Reset einer SHC V2 mit aktueller (letzter Software) auf einen von mir freien Account
    2. Lokalen Account eingerichtet
    3. Anlernen eines PSSO Zwischensteckers
    4. Anlegen eines Szenarios, Sonnenuntergang +30 min, dann Steckdose PSSO an
    5. Lokalen Access zur SHC V2 via POSTMAN hergestellt
    6. "GET All Interactions" ausgeführt (bekommen somit ALLE Szenarien als JSON)
    7. JSON in einem Texteditor abgelegt
    8. Auf der SHC V2 lokal das Szenario händisch gelöscht (und neu gestartet)
    9. Erneuter Connect zur SHC via API
    10. "POST Create Interaction" mit meinem zwischengespeicherten JSON des vorherigen Szenarios ausgeführt.
    11. Szene ist KORREKT auf der lokalen SHC V2 vorhanden!!

    Das war "nur" ein kleines Szenario, welches erfolgreich über ein BackUp wieder eingespielt werden konnte. Somit lassen sich meiner Meinung nach auch ALLE Szenarien wieder zurückspielen.


    - Bin auf eure Erfahrungen und Meinungen gespannt 😉


    Hinweis:

    • Das Gerät PSSO wurde nicht entfernt, aber die Device ID bekommt man zur Not über "GET All Devices" und kann diese einsetzen
    • Die URL für den lokalen Zugriff (egal ob SHC V1 oder V2) muss immer "http://{IP}/..." sein. Hat mich zig Nerven gekostet, da für die Online-Server-Variante "https://services-smarthome.de/api/1.1/..." notwendig ist.

    Viele Grüße

    Tom

    Zitat von CharlyT

    Kann ich ausprobieren 😊 .
    Gebe hier wieder Feedback ...

    Geht auch mit Devices!!!


    • Hab das Device PSSO als JSON via GET geholt
    • in der Zentrale den PSSO gelöscht
    • über "POST Device Include" das JSON wieder eingespielt
    • --> sofort war das Device da

    ==> Devices Sichern und Einspielen klappt auch via API


    Was meinerseits offen ist: Wie übergibt man nach dem 1.3. die KEY's von unbekannten Geräten?

    - Eventuell reicht es, den USB-Stick an der Zentrale zu haben


    Komme einer Sicherung OHNE clone nahe 😉

    So jetzt hast du mich und ich werde mich nun doch in die Untiefen der API begeben....


    Die Schlüssel werden ja alle automatisch mit reinstecken des Sticks auf die Zentrale gepumpt ...


    Wenn das so trivial über die API geht, dann sollten wir doch ein einfaches Tool hinbekommen oder?


    🖖🏻

    Solange das für mich noch ein Buch mit 6 Siegeln ist, wäre die Frage, was passiert, wenn du das include bei eine anderen Zentrale machst die aber den schlüssel schon kennt und als Königsdisziplin: die keine Verbindung zur Cloud hat 🙈😉🖖🏻🤷🏼‍♀️🤟🏻

    Zitat von MKR

    Solange das für mich noch ein Buch mit 6 Siegeln ist, wäre die Frage, was passiert, wenn du das include bei eine anderen Zentrale machst die aber den schlüssel schon kennt und als Königsdisziplin: die keine Verbindung zur Cloud hat 🙈😉🖖🏻🤷🏼‍♀️🤟🏻

    Klär mich auf, wieso eine Zentrale, die schon die Schlüssel kennt?

    Um Devices einzuspielen, wäre es nicht realistischer, eine blanke Zentrale mit aktueller Version und Internet blocked zu nehmen?

    Dieses Thema beginnt auch mich zu interessieren.

    Könnt ihr die von Euch genau verwendeten Befehle mal posten bzw. wo habt ihr denn die API-Beschreibung her ?


    Wenn das mit cURL geht, dann lässt sich das bestimmt auch mit VB oder ähnlichem in ein Tool mit Oberfläche gießen.....

    Zitat von Ralph

    Dieses Thema beginnt auch mich zu interessieren.

    Könnt ihr die von Euch genau verwendeten Befehle mal posten bzw. wo habt ihr denn die API-Beschreibung her ?


    Wenn das mit cURL geht, dann lässt sich das bestimmt auch mit VB oder ähnlichem in ein Tool mit Oberfläche gießen.....

    Hi Ralph,


    Die Intro ist hier: https://developer.services-sma…core_concepts/quickstart/

    Zitat

    ...
    1. Setting up Postman

    1. Download Postman on getpostman.com and install it
    2. Open Postman
    3. Download the LIVISI Postman Collection and Environment
    4. Import the LIVISI Postman Collection and Environment

    Die API-Reference ist "noch" hier:

    SmartHome Api

    Die Settings unter "Environment" in Postman

    POST Token

    In Postman hab ich 4 Modifikationen vornehmen müssen


    1. URL (muss m man immer anpassen):

    https://{{capiURL}}/api/{{capiVersion}}/ --> http://{{capiURL}}/

    2. im Tab Authorization hat bei mit nur über "inherit auth from parent" geklappt

    3. Headers in Postmann ergänzen, da sonst wegen "nicht JSON" es nicht geklappt hat

    4. Body mit Zugangsdaten und ganz wichtig via "grant_type"


    Dann sollte ein Request folgendermaßen aussehen:
    POST http://192.168.178.102:8080/auth/token


    Um alle Devices als JSON zu bekommen

    GET http://192.168.178.102:8080/device/

    Hier eine Beispiel-Response (JSON)

    Hab nur 2 Geräte eingebunden, Router und Außensteckdose. Der Rest kommt als Standard mit

    Zitat von CharlyT

    Klär mich auf, wieso eine Zentrale, die schon die Schlüssel kennt?

    Um Devices einzuspielen, wäre es nicht realistischer, eine blanke Zentrale mit aktueller Version und Internet blocked zu nehmen?



    Na ohne Schlüssel wirds wohl nichts, jetzt hast du ja die selbe Zentrale genommen, wenn du das mit Ner blanken machst, dann wird das imho ohne den Schlüssel für dieses Device in der Zentrale (USB Stick ) nix...


    Würde mich jedenfalls sehr stark überraschen...


    🖖🏻

    Wäre halt die Frage, ob der Schlüssel irgendwo im Jason auftaucht und wenn ja, ob verschlüsselt oder im Klartext. Irgendwie muss die Zentrale ja die Zuordnung zwischen Schlüssel und Seriennummer herstellen. Wenn sie Grundsätzlich nur nachfragt "ich hab hier Seriennummer XYZ... hab ich einen passenden Schlüssel dazu in meiner DB", sollte es ja eigentlich reichen wenn man die Schlüssel irgendwie auf die neue Zentrale läd... mittels USB.


    Das aber zu testen, sollte ja eigentlich relativ einfach sein... sofern man mehr wie eine Ersatzzentrale hat.

    Zitat von MKR

    Na ohne Schlüssel wirds wohl nichts, jetzt hast du ja die selbe Zentrale genommen, wenn du das mit Ner blanken machst, dann wird das imho ohne den Schlüssel für dieses Device in der Zentrale (USB Stick ) nix...


    Würde mich jedenfalls sehr stark überraschen...


    🖖🏻

    Vielleicht meinen mir beide doch das selbe. 😉


    Lass mich mal meine Idee ausführlicher aufzählen:

    • Save eines Devices als JSON von einer bekannten SHC1, inkl KEY auf USB
    • NEUE SHC2 hochfahren,
      • ohne Internetverbindung,
      • die SHC2 hat noch nie das Device gesehen (somit kein Schlüssel vorhanden)
    • Mein USB-Stick mit allen Device-Keys an der NEUEN SHC2 anschließen
    • POST des Devices via API an die SHC2
    • Ergebnis: TBD

    Was könnte das beweisen:

    • Import von Devices auf blanken Geräten via API
    • Import von Szenen auf blanken Geräten via API
    • --> ???BackUp-Möglichkeit ALLER Einstellungen nach 1.3.2024???
    Zitat von Andre26

    Wäre halt die Frage, ob der Schlüssel irgendwo im Jason auftaucht und wenn ja, ob verschlüsselt oder im Klartext. Irgendwie muss die Zentrale ja die Zuordnung zwischen Schlüssel und Seriennummer herstellen. Wenn sie Grundsätzlich nur nachfragt "ich hab hier Seriennummer XYZ... hab ich einen passenden Schlüssel dazu in meiner DB", sollte es ja eigentlich reichen wenn man die Schlüssel irgendwie auf die neue Zentrale läd... mittels USB.


    Das aber zu testen, sollte ja eigentlich relativ einfach sein... sofern man mehr wie eine Ersatzzentrale hat.

    Der KEY ist nicht im JSON Object des GET-Devices vorhanden. Deshalb muss der USB Stick m.M. nach immer manuell zusätzlich eingesteckt werden

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden