Aufruf der lokalen API mit cURL

MKR · Mittwoch, 10:42

Wir meinen das Selbe🥰

MKR · Mittwoch, 15:31

So Freunde der Nacht, ich hab mir mal die Konfig-File angeguckt, die man mit dem Smarthome-commander abspeichern kann und was soll ich sagen, das sieht in weiten Teilen wie oben aus 🤟🏻

CharlyT · Mittwoch, 16:43

Zitat von CharlyT

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???

So, alles vorbereitet ... und hänge gerade am 4. Punkt: "POST des Devices via API an die SHC2"

Mal davon Abgesehen, dass Locations beim Anlegen von Devices REQUIRED sind (hab ich so nicht in der Reference gelesen, egal) müssen also über GET All Locations diese vorher auch gesichert werden und als erstes eingespielt werden. Alternativ kann einen Dummy-Raum via API erzeugt werden und diese Raum-ID für das Device verwendet werden.

Request:

Code

POST http://192.168.178.108:8080/device/: {
  "Request Headers": {
...
  },
  "Request Body": "
    {
        "id": "cd8e7dd784114656ac5e3dc8498792d0",
        "tags": {
            "type": "TFairyLightsId",
            "typeCategory": "TCLightId"
        },
        "config": {
            "name": "Lichterkette",
            "protocolId": "Cosip",
            "timeOfAcceptance": "2024-02-20T16:12:29+00:00",
            "timeOfDiscovery": "2024-02-20T16:12:03+00:00"
        },
        "manufacturer": "RWE",
        "type": "PSSO",
        "version": "1.0",
        "desc": "/desc/device/PSSO.RWE/1.0",
        "class": "",
        "product": "CosipDevices.RWE",
        "serialNumber": "914171#####",
        "location": "/location/55e107583c364c3584a9e58b64d54bf1",
        "capabilities": [
            "/capability/dd13f6097ff44d24b29801eeefe933db"
        ]
    }
",
  "Response Headers": {
    "access-control-allow-origin": "*",
    "content-type": "application/json",
    "content-length": "113"
  },
...
"
}

Alles anzeigen

Dann kommt ein ERROR 3000:

JavaScript

"Response Body": "
{
    "errorcode": 3000,
    "description": "The requested entity does not exist",
    "messages": [
        "device is not discovered"
    ]
}"

PSSO Gerät ist resettet, USB Stick mit KEY steckt ... Ideen??

Ralph · Mittwoch, 16:47

Schaut mal....ich hab das was gebaut :

Einfach IP-Adresse und Passwort eintragen und auf das Knöpfchen drücken...

dann kommt die Konfig aus der Zentrale.

Jetzt muss ich diese nur noch in zwei Dateien ablegen und dann "nur" noch den umgekehrten Weg abbilden....dann hätten wir doch ein Prima Backup-Restore-Tool oder ?

Gruß Ralph

Pegasus · Mittwoch, 17:21

Zitat von Ralph

Schaut mal....ich hab das was gebaut :

Einfach IP-Adresse und Passwort eintragen und auf das Knöpfchen drücken...

dann kommt die Konfig aus der Zentrale.

Jetzt muss ich diese nur noch in zwei Dateien ablegen und dann "nur" noch den umgekehrten Weg abbilden....dann hätten wir doch ein Prima Backup-Restore-Tool oder ?

Gruß Ralph

Alles anzeigen

Ralph · Mittwoch, 17:39

Also - mittlerweile hole ich auch die Räume und weitere Daten aus der Konfig ab.

Was ich mittlerweile rausgefunden habe ist, dass man die Räume nicht als ganzes "in einem Rutsch" in einer neuen Zentrale anlegen kann, sondern, dass man diese einzeln an die API schicken muss.

Ich gehe davon aus, dass das mit Szenarien und Geräten ähnlich ist....

Ich schaue mal weiter.....

Ralph · Mittwoch, 18:46

Also bei den Devices scheint es kompliziert zu sein:

1) Zwischen SHC1 und SHC2 unterscheidet sich die JSON-Struktur und deren Inhalt

2) Man kann Devices nur einbinden, wenn das DeviceDiscovery auf der Zentrale läuft....das muss ich momentan noch manuell anstoßen - geht aber bestimmt auch über die API....

3) Das ist das größte Problem: Man kann Geräte nur mit der ID einbinden, die die Zentrale (irgendie selbst) für das Gerät festlegt und nicht mit einer ID aus einer Sicherung einer anderen Zentrale....momentan habe ich noch nicht rausgefunden, ob und wie man die von der Zentrale beim eigenen Discovery festgelegte ID für das Gerät herausbekommt...

MKR · Mittwoch, 18:48

Zitat von Ralph

Also - mittlerweile hole ich auch die Räume und weitere Daten aus der Konfig ab.
Was ich mittlerweile rausgefunden habe ist, dass man die Räume nicht als ganzes "in einem Rutsch" in einer neuen Zentrale anlegen kann, sondern, dass man diese einzeln an die API schicken muss.

Ich gehe davon aus, dass das mit Szenarien und Geräten ähnlich ist....

Ich schaue mal weiter.....

Alles anzeigen

Wie gesagt, ich würde mir mal die Datei von MSagner angucken, da gab es glaub ich 4 Kategorien.... Zu klären bleibt ja auch, wie ein SHC den Geräten sagt, dass er der neue Chef ist .. also sie "kapert" dafür muss es ja auch noch ne Funktion geben ...🤷🏼‍♀️

Ralph · Mittwoch, 19:37

Das "Kapern" wird über die API denke ich nicht gehen.....es wird schon seinen Grund haben, warum LIVISI das Backup/Restore nicht mehr umgesetzt hat....wenn es so wäre, dass ich das an einem Nachmittag hinbekomme, dann hätten die das wohl auch gemacht

JH76 · Mittwoch, 19:51

Zitat von Ralph

Das "Kapern" wird über die API denke ich nicht gehen.....es wird schon seinen Grund haben, warum LIVISI das Backup/Restore nicht mehr umgesetzt hat....wenn es so wäre, dass ich das an einem Nachmittag hinbekomme, dann hätten die das wohl auch gemacht

Ein herkömmliches Backup & Restore klappt tatsächlich nicht.

Man könnte aber ein Programm bauen, welches über die API alle Szenarien, Geräte, Räume und alle Einstellungen als Backup speichert.

Für das Restore könnte man dann sogar verschiedene Geräte in den Szenarien austauschen lassen und man könnte über ein solches Programm theoretisch sogar eine Gerätetauschfunktion für defekte Geräte umsetzen.

Wenn ich Zeit hätte, würde ich das furchtbar gerne machen, aber es haut nicht hin.

Ralph · Mittwoch, 20:10

ok ....dann leg ich das Zeug jetzt mal weg.

Wenn die Id's der Geräte aus dem Backup nicht übernommen werden können, sondern zuerst alle Geräte manuell eingebunden werden müssten dann wird das leider nichts.

Desweiteren habe ich gesehen, dass es logisch keinen direkten Zusammenhang zwischen den Devices und den Szenarien gibt, sondern dazwischen noch die sog. Capabilities stehen. Ebenfalls ein Sammelsurium von eindeutigen Ids, die m. E. auch nicht einfach übernommen werden können.

In den Szenarien sind dann wiederum die Ids der Capabilities enthalten, die wiederum auf die Geräte verweisen, das heißt, es bringt dann überhaupt nichts, die Szenarien wiederherstellen zu wollen.....

Sorry - aber das ist mir dann zu komplex und zu zeitaufwändig....

Ralph · Vor 20 Stunden

Hallo zusammen,

es hat mir natürlich keine Ruhe gelassen - und ich kann Lichtblicke melden.....

Mein Tool sieht mittlerweile folgendermaßen aus:

Damit kann man jetzt Szenarien von einer Zentrale auf eine andere Zentrale übertragen.

Dabei das geht auch von und zu SHC1 oder SHC2.....egal.

Dabei gelten folgende Rahmenbedingungen:

Die Zielzentrale muss zu Beginn "leer" sein - keine Räume, keine Geräte, nichts....
Man liest die Konfig der Quellzentrale ein.
Man liest die Konfig der Zielzentrale ein
Danach klickt man auf den Button "Standorte wiederherstellen"
Daraufhin werden alle Standorte (mit den entsprechenden IDs) in der neuen Zentrale angelegt.
Jetzt muss man (leider) alle Geräte der Quellzentrale manuell in der Zielzentrale einbinden
Dabei müssen diese Geräte genauso benannt werden und in den gleichen Räumen liegen wie bei der Quellzentrale.
Jetzt legt man alle Zustände manuell an - auch hier müssen diese genauso heißen wie in der alten Zentrale
Wenn das alles abgeschlossen ist, liest man die Konfig der Ziel-Zentrale nochmals ein.
Jetzt kann man die gewünschten Szenarien in der Liste markieren und durch einen Klick auf den Knopf "Szenarien wiederherstellen" in die neue Zentrale übertragen.

Voilà !!

Warum ist das alles so kompliziert und warum kann man keine Geräte übertragen ?

Also - Jedes Gerät bekommt beim ersten Mal wenn es bei einer Zentrale eingebunden wird eine eindeutige ID zugeordnet. Diese ID ist innerhalb jeder Zentrale eindeutig und ändert sich später auch nicht mehr - auch dann nicht, wenn das Gerät entfernt und später wieder erneut eingebunden wird - ich nehme an, dass die ID errechnet und nicht gewürfelt wird. Diese Berechnung muss u. a. mit der "Identität" der Zentrale zu tun haben. (darauf komme ich später nochmal zurück)

Leider ist es aber so, dass das gleiche Gerät wenn es an einer anderen SHC eingebunden wird eine andere interne ID erhält. Das macht es erst einmal unmöglich, Geräte einfach zu kopieren....Soweit so gut...

Neben den Geräten gibt es auch sogenannte "Capabilities" für jedes Gerät. Das sind sozusagen "Fähigkeiten". Ein RST hat z. B. die Fähigkeit zur Temperaturmessung aber auch zur Feuchtigkeitsmessung. Diese Fähigkeiten erhalten beim Einbinden des Gerätes ebenfalls eindeutige IDs zugeordnet, die leider auch immer verschieden sind, wenn das Gerät in einen andere Zentrale eingebunden wird.

In den Szenarien schließlich wird für die Auslöser und Aktionen nicht auf die Geräte referenziert, sondern direkt auf die Capabilities. Das heißt, in jedem Szenario sind die IDs der Capabilites enthalten.

Wenn jetzt also ein Szenario von einer Zentrale auf eine andere übertragen werden soll, dann müssen beim kopieren die ganzen IDs der Capabilities durch ihr Pendant auf der neuen Zentrale ersetzt werden.

Dazu muss jedoch ein Matching zwischen den alten und den neuen Geräten gemacht werden und darüber dann wiederum ein Matching zwischen den alten und den neuen Capabilities. Somit kommt man dann von einer alten Capability-ID auf die entsprechende neue Capability-ID.

Genau dieser Vorgang geschieht in meinem Tool....

Dieses Matching erfolgt in meinem Tool über die Gleichnamigkeit von Räumen und Gerätenamen. Deshalb muss das auch so sein. Ich habe es absichtlich nicht über die Seriennummer gemacht, denn es könnte ja sein, dass ein Gerät mittlerweile durch ein anderes ersetzt wurde weil es defekt war.

Wieso kann LIVISI das bei einem Wechsel der Zentrale ohne diesen ganzen Schnick-Schnack ?

Ganz einfach - ich nehme an, dass LIVISI beim Wechsel der Zentrale und der Übertragung der Infos vom BackEnd auf die neue Zentrale auch die oben erwähnte "Identität" der Zentrale mitkopiert. Damit ergeben sich auf der neuen Zentrale die gleichen IDs wie auf der alten und damit ist alles viel einfacher.

Ohne das BackEnd und damit ohne die Möglichkeit zum Identitätswechsel geht das halt nicht.

Jetzt stellt sich die Tausend-Dollar-Frage:

"Wie verhalten sich "geklonte" Zentralen? Müssten dort die Geräte- und Capability-IDs nicht die gleichen sein wie bei der Quellzentrale, denn wir haben ja lautet gleiche Identitäten...?"

Die Antwort ist - ich weiß es nicht, denn ich möchte meine geklonten Zentralen vor dem 01.03.2024 nicht anschließen, weil ich Angst habe, dass sie gelöscht werden.

So - das war jetzt viel Geschwurbel....mein Tool ist noch lange nicht fertig...für Fragen wie "kann ich das mal haben" ist es noch zu früh....

Was ich schon mal sagen kann ist - es wird nur unter Windows laufen, denn es ist mit VB6 programmiert.

Alle die jetzt lachen sollen lachen....aber mit VB6 kenne ich mich halt aus...bin leider nicht mehr so jung wie auf dem Bild

meyk · Vor 19 Stunden

Ralph, ein fettes Lob.
Da hast Du ja richtig die Ärmel hochgekrempelt.
Wow!

Ich bin auch noch so ein alter VB6er.
Und ja, auf dem Bild sehe ich auch jünger aus. Muss mal ein neues machen. Ist noch von der Erstanmeldung.
Vielleicht verrät LIVISI Dir ja noch einige Dinge, die Dir weiterhelfen.

Update: Hab dann gleich mal einen alten Mann aus mir gemacht.

Zitat von Ralph

Hallo zusammen,

es hat mir natürlich keine Ruhe gelassen - und ich kann Lichtblicke melden.....
Mein Tool sieht mittlerweile folgendermaßen aus:

Damit kann man jetzt Szenarien von einer Zentrale auf eine andere Zentrale übertragen.
Dabei das geht auch von und zu SHC1 oder SHC2.....egal.

Dabei gelten folgende Rahmenbedingungen:
Die Zielzentrale muss zu beginn "leer" sein - keine Räume, keine Geräte, nichts....
Man liest die Konfig der Quellzentrale ein.
Man liest die Konfig der Zielzentrale ein
Danach klickt man auf den Button "Standorte wiederherstellen"
Daraufhin werden alle Standorte (mit den entsprechenden IDs) in der neuen Zentrale angelegt.
Jetzt muss man (leider) alle Geräte der Quellzentrale manuell in der Zielzentrale einbinden
Dabei müssen diese Geräte genauso benannt werden und in den gleichen Räumen liegen wie bei der Quellzentrale.
Jetzt legt man alle Zustände manuell an - auch hier müssen diese genauso heißen wie in der alten Zentrale
Wenn das alles abgeschlossen ist, liest man die Konfig der Ziel-Zentrale nochmals ein.
Jetzt kann man die gewünschten Szenarien in der Liste markieren und durch einen Klick auf den Knopf "Szenarien wiederherstellen" in die neue Zentrale übertragen.

Voilà !!

Warum ist das alles so kompliziert und warum kann man keine Geräte übertragen ?

Also - Jedes Gerät bekommt beim ersten Mal wenn es bei einer Zentrale eingebunden wird eine eindeutige ID zugeordnet. Diese ID ist innerhalb jeder Zentrale eindeutig und ändert sich später auch nicht mehr - auch dann nicht, wenn das Gerät entfernt und später wieder erneut eingebunden wird - ich nehme an, dass die ID errechnet und nicht gewürfelt wird. Diese Berechnung muss u. a. mit der "Identität" der Zentrale zu tun haben. (darauf komme ich später nochmal zurück)

Leider ist es aber so, dass das gleiche Gerät wenn es an einer anderen SHC eingebunden wird eine andere interne ID erhält. Das macht es erst einmal unmöglich, Geräte einfach zu kopieren....Soweit so gut...

Neben den Geräten gibt es auch sogenannte "Capabilities" für jedes Gerät. Das sind sozusagen "Fähigkeiten". Ein RST hat z. B. die Fähigkeit zur Temperaturmessung aber auch zur Feuchtigkeitsmessung. Diese Fähigkeiten erhalten beim Einbinden des Gerätes ebenfalls eindeutige IDs zugeordnet, die leider auch immer verschieden sind, wenn das Gerät in eine ander SHC eingebunden wird.

In den Szenarien schließlich wird für die Auslöser und Aktionen nicht auf die Geräte referenziert, sondern direkt auf die Capabilities. Das heißt, in jedem Szenario sind die IDs der Capabilites enthalten.

Wenn jetzt also ein Szenario von einer SHC auf eine andere übertragen werden soll, dann müssen beim kopieren die ganzen IDs der Capabilities durch ihr Pendant auf der neuen Zentrale ersetzt werden.

Dazu muss jedoch ein Matching zwischen den alten und den neuen Geräten gemacht werden und darüber dann wiederum ein Matching zwischen den alten und den neuen Capabilities. Somit kommt man dann von einer alten Capability-ID auf die entsprechende neue Capability-ID.

Genau dieser Vorgang geschieht in meinem Tool....
Dieses Matching erfolgt in meinem Tool über die Gleichnamigkeit von Räumen und Gerätenamen. Deshalb muss das auch so sein. Ich habe es absichtlich nicht über die Seriennummer gemacht, denn es könnte ja sein, dass ein Gerät mittlerweile durch ein anderes ersetzt wurde weil es defekt war.

Wieso kann LIVISI das bei einem Wechsel der Zentrale ohne diesen ganzen Schnick-Schnack ?

Ganz einfach - ich nehme an, dass LIVISI beim Wechsel der Zentrale und der Übertragung der Infos vom BackEnd auf die neue Zentrale auch die oben erwähnte "Identität" der Zentrale mitkopiert. Damit ergeben sich auf der neuen Zentrale die gleichen IDs wie auf der alten und damit ist alles viel einfacher.

Ohne das BackEnd und damit ohne die Möglichkeit zum Identitätswechsel geht das halt nicht.

Jetzt stellt sich die Tausend-Dollar-Frage:
"Wie verhalten sich "geklonte" Zentralen? Müssten dort die Geräte- und Capability-IDs nicht die gleichen sein wie bei der Quellzentrale, denn wir haben ja lautet gleiche Identitäten...?"

Die Antwort ist - ich weiß es nicht, denn ich möchte meine geklonten Zentralen vor dem 01.03.2024 nicht anschließen, weil ich Angst habe, dass sie gelöscht werden.

So - das war jetzt viel Geschwurbel....mein Tool ist noch lange nicht fertig...für Fragen wie "kann ich das mal haben" ist es noch zu früh....

Was ich schon mal sagen kann ist - es wird nur unter Windows laufen, denn es ist mit VB6 programmiert.
Alle die jetzt lachen sollen lachen....aber mit VB6 kenne ich mich halt aus...bin leider nicht mehr so jung wie auf dem Bild

Alles anzeigen

Torham · Vor 18 Stunden

Ich hatte ja 2 geklonte zentralen gleichzeitig laufen, also eher 1 offizielle und ein Klon mit gesperrten Server. Das die Zentrale die gleiche Identitäten haben, hatte ich eigentlich wegen dem Verhalten der Geräte ausgeschlossen. Zwischenstecker funktionierten ausschließlich auf der letzten offiziellen Zentrale. Auf dem Klon der zeitgleich lief waren sie dauerhaft unerreichbar. Das Heizungsthermostat lief dauerhaft problemlos auf der offiziellen letzten. Auf dem Klon wechselte es minütlich zwischen erreichbar und unerreichbar. In dem Moment wo es erreichbar war, war es aber tatsächlich steuerbar. Medion Geräte liefen bei beiden problemlos zeitgleich.

Vom Verhalten der Zwischenstecker ging ich davon aus das die Zentralen nicht die gleiche Identität haben. Aber das Verhalten des Thermostates ist ja auch schräg. Wenn die Zentralen wirklich die gleiche Identität haben, also alle Klone, warum gibt es dann einen Unterschied zwischen home Klone und away Klone? Und der ist definitiv da. Ein Home Klon hat sich die Zwischenstecker nicht mehr abgegriffen. Dauerhaft unerreichbar. Ein away Klon hat sie sich direkt abgegriffen. Das passt nicht so richtig mit gleicher Identität zusammen.

Wäre natürlich toll wenn Livisi da was Licht ins Dunkel bringen könnte.

MKR · Vor 18 Stunden

Beitrag

RE: Aufruf der lokalen API mit cURL

Hallo zusammen,

es hat mir natürlich keine Ruhe gelassen - und ich kann Lichtblicke melden.....
Mein Tool sieht mittlerweile folgendermaßen aus:

Damit kann man jetzt Szenarien von einer Zentrale auf eine andere Zentrale übertragen.
Dabei das geht auch von und zu SHC1 oder SHC2.....egal.

Dabei gelten folgende Rahmenbedingungen:

Die Zielzentrale muss zu Beginn "leer" sein - keine Räume, keine Geräte, nichts....
Man liest die Konfig der Quellzentrale ein.
Man liest die Konfig der Zielzentrale ein
Danach

…

Ralph

Vor 20 Stunden

Du bist mein Held Du Macher 🙏🏻🤟🏻👍🏻🫶🏻

MKR · Vor 16 Stunden

Zitat von Torham

Ich hatte ja 2 geklonte zentralen gleichzeitig laufen, also eher 1 offizielle und ein Klon mit gesperrten Server. Das die Zentrale die gleiche Identitäten haben, hatte ich eigentlich wegen dem Verhalten der Geräte ausgeschlossen. Zwischenstecker funktionierten ausschließlich auf der letzten offiziellen Zentrale. Auf dem Klon der zeitgleich lief waren sie dauerhaft unerreichbar. Das Heizungsthermostat lief dauerhaft problemlos auf der offiziellen letzten. Auf dem Klon wechselte es minütlich zwischen erreichbar und unerreichbar. In dem Moment wo es erreichbar war, war es aber tatsächlich steuerbar. Medion Geräte liefen bei beiden problemlos zeitgleich.

Vom Verhalten der Zwischenstecker ging ich davon aus das die Zentralen nicht die gleiche Identität haben. Aber das Verhalten des Thermostates ist ja auch schräg. Wenn die Zentralen wirklich die gleiche Identität haben, also alle Klone, warum gibt es dann einen Unterschied zwischen home Klone und away Klone? Und der ist definitiv da. Ein Home Klon hat sich die Zwischenstecker nicht mehr abgegriffen. Dauerhaft unerreichbar. Ein away Klon hat sie sich direkt abgegriffen. Das passt nicht so richtig mit gleicher Identität zusammen.

Wäre natürlich toll wenn Livisi da was Licht ins Dunkel bringen könnte.

Ich könnte mir gut vorstellen, dass derzeit beim Einrichten einer neuen Zentrale übers Backend die ID der Geräte mit der Seriennummer bzw ID der neuen Zentrale errechnet werden und dann die selben Algorithmen laufen wie hier beschrieben.... Das hieße aber auch, dass "jemand" den Algorithmus kennen würde und das wäre ja jetzt keine Lizenzverletzung den mal zufällig zu veröffentlichen oder?

🖖🏻

hesham · Vor 12 Stunden

tolle Arbeit, bin gespannt

Ich dachte, ich bin der letzte, der VB6 auf dem Laptop hat

Jetzt mitmachen!

Teilen