Beiträge von SamTV

    Hallo Community,


    ich habe das Problem, dass die API sehr rudimentär dokumentiert ist. Manchmal steht da einfach Objekt oder String Map. Gibt es irgendwo eine genaue Auflistung, welche Attribute so alles über die API zurückgegeben werden und zu welchen Geräten diese gehören? Aktuell bin ich mehr am Raten als am Wissen, ob ich das richtige tue. LIVISI könntet ihr bitte die Dokumentation bis zum Ende des Monats als PDF/HTML zum Download bereitstellen, sodass nachdem die Webseite weg ist auch weiterhin alles nachgeschlagen werden kann?

    Code
    2024-01-29T10:31:49.879835352Z Doing db initialization
    
    2024-01-29T10:31:50.766469075Z thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Decode, source: Error("invalid type: null, expected a string", line: 1, column: 265) }', src/api_lib/device.rs:93:14

    Ich komme leider nicht weiter. Passwort scheint laut Doku von der LIVISI API mein selbst erstelltes Passwort zu sein, das habe ich geändert. Ich komme aber leider nicht weiter. SamTV

    Hi. Das Problem sollte behoben sein. Es gab wohl mal wieder Änderungen an der API, die ich nicht mitbekommen habe und das Feld Name ist jetzt optional. Ebenfalls wurde der Websocket Port geändert. Beides ist jetzt hoffentlich behoben.

    Ich habe gerade einfach mal nen USB Stick eingesteckt, gewartet bis er aufgehört zu blinken, abgezogen und am Windows Laptop ausgelesen.


    Tata, auf dem Stick ist eine csv Datei in der alle Geräteschlüssel in Textform abgespeichert sind.


    Würde sagen läuft LIVISI :thumbup:

    Kann man den USB Stick einfach eingesteckt lassen? Ist das CSV mit dem aktuellen Timestamp kodiert? Dann hätte man auch noch einen Verlauf der Geräteschlüssel.

    Das ist ein nettes Angebot, danke.


    Bilder und Graphiken sind das kleinste Problem wenn ein Produkt über 3 unterschiedliche Firmen/Unternehmen hinweg und mit diversen Partnern entwickelt wurde.

    Es gibt locker ein dutzend Verträge die noch gültig sind und welche unser Tun mit bestimmen. Diese wurden nicht nur durch unsere Rechtsabteilung, sondern auch durch eine spezialisierte, externe Kanzlei geprüft - die daraus resultierende Entscheidung steht fest.

    Schade. Aber danke für das Update. Dann bin ich mit meinem Latein leider am Ende. Außer den Source Maps hätte ich keine weitere Idee, aber bei mehr als ein dutzend Verträgen ist das wahrscheinlich auch geregelt.

    LIVISI Sind sämtliche Komponenten rechtlich geschützt? Wenn ihr das In House entwickelt, dann könnt ihr es doch freigeben. Wenn ihr Bilder oder sonstige Grafiken lizensiert habt, könnt ihr die ja entfernen und durch Placeholder ersetzen. Von mir aus kann ich das auch gerne für euch tun. Dann habt ihr überhaupt keine Arbeit/Kosten. Ich würde gerne helfen

    Leider passiert dort seit Monaten nicht mehr von dem LIVISI da versprochen hatte. Die ganzen Ankündiguengen waren m.E. nur Nebelkerzen.

    Geht es aktuell nicht weiter? Wie viele Freiwilligen gibt es denn?


    Ich werde leider von LIVISI seit Monaten ignoriert. Wenn man das Backend, das Frontend und die App öffentlich stellen würde, könnte man als Community das ganze viel einfacher weiterentwickeln. Wäre vielleicht mal nicht schlecht, wenn man als Entwickler irgendetwas an die Hand bekommt, bevor man da reingezogen wird.

    Wir haben uns darüber Gedanken gemacht und arbeiten da auch dran: siehe bspw. "Ich habe versucht, einen neuen SHC nur lokal einzurichten, aber er scheint nicht auf die erforderliche Version zu aktualisieren" in Fragen & Antworten


    Bestimmte Sachen lassen sich aber manchmal auch aus unterschiedlichen Gründen leider nicht umsetzen - in einem Fall sind es rechtliche Hindernisse, im anderen Fall technische Blockaden.

    Wäre es dann zumindest möglich, die einzelnen Teile der lokalen API zu veröffentlichen. Die React-Native App, das React-UI und das Backend könnten gut als Startpunkt für eine eigene Softwarelösung sein, die man dann als Community fortführen kann. Mit regelmäßigen Updates etc. könnte man auf der Lösung aufbauen.

    Ich habe im Code des Frontends nachgeschaut, leider fehlt die Source Map, die den tatsächlichen React Code wieder zusammen basteln kann. Damit könnte man zum Beispiel relativ schnell das UI nachbauen und in Zukunft mit Updates etc. updaten.


    Ohne Insights in den Code befürchte ich, dass ich das Frontend zumindest nicht perfekt nachbauen kann.

    React ist eine Client Side Library. Das heißt das Gerät, das auf die Smarthome Seite geht, macht auch den Request zu Google Maps. Folglich müsste ich im Router global die Google API abschalten, das in der heutigen Zeit nicht mehr möglich ist.


    Man müsste die Zeile also aus dem HTML herauslöschen. Da man das als Endkunde nicht kann, wird das für immer enthalten sein.

    Kein Ahnung was Du meinst ?

    Wo im Frontend ist denn Google Maps zu sehen ?

    Man kann es relativ einfach über die Oberfläche nachvollziehen. Öffne die Developer Tools deines Browsers. Da sieht man im React Index.html direkt die entsprechenden Skripte, die von Google geladen werden mit dem API Key.

    Ich denke das wird bei Einstellungen / Mein Zuhause / Standort aktualisieren benutzt, um u.A. die Astrofunktion mit Daten zu versogen.

    Ja genau. Das wird verwendet, um die Position festzustellen. Ist halt doof, wenn man einen wirklich lokalen Server haben möchte, aber im Hintergrund Daten an Google übermittelt werden.

    Hallo Community,


    wie kann ich Google Maps im Frontend deaktivieren? Ich möchte nicht unbedingt, dass jedes Mal meine IP Adresse an Google Maps übertragen wird, nur um den Standort meines Hubs herauszufinden.


    Danke für die Hilfe.

    Danke. Das habe ich schon gesehen. Das Problem ist, dass das für die Online Dienste von LIVISI gilt. Während der Implementierung bin ich einige Male über Lokale API vs. Online API gestolpert. Z.B. gibt es für /status online ein gateway:{}. In der lokalen Variante wurde das ausgespart. Man wird auch teilweise nicht wirklich schlau, was "das Objekt rekursiv bedeutet" oder welche Geräte gibt es noch und wie sind die Key Value Pairs im XML für Gen Z :D.

    Hallo LIVIS Community,


    in den vergangenen zwei Wochen habe ich an einem Gateway zum Fortbestand nach dem Abschalten der LIVIS Server (direkt aus dem Internet verfügbar) gearbeitet. Es ermöglicht im Gegensatz zur bestehenden SmartHome Zentrale die Möglichkeit dieses unabhängig zu erweitern, z.B. Apps, neue Authentifizierungsmethoden etc.


    Da ich eine Smarthome Zentrale 1 verwende, ist diese doch relativ langsam, daher habe ich einen Cache eingebaut, der einen sehr schnellen Abruf von Daten ermöglicht.


    Außerdem habe ich die Möglichkeit von Basic Authentifizierung, d.h., mittels Nutzernamen und Passwort, sowie OAuth2.0 hinzugefügt. OAuth2.0 bzw. OIDC ermöglicht es sich an der Oberfläche mittels Google, Auth0 oder Keycloak als Selfhosted Variante anzumelden.


    Falls ihr mehr erfahren wollt, könnt ihr gerne hier das Projekt abchecken. Die Installation ist sehr einfach und kann mittels Docker Compose vorgenommen werden. Das Docker-Compose findet ihr direkt im Readme.


    Schönes Wochenende

    Samuel


    P.S.: Ich habe leider immer noch keine vernünftige API Dokumentation von LIVISI erhalten, d.h., ich habe keine Ahnung, wie die anderen Geräte schnittstellentechnisch aussehen. Falls ihr helfen wollt, könnt ihr mich auf GitHub oder hier direkt kontaktieren.

    Man muss in Chrome den Entwicklermodus aufrufen und dann den API Aufruf raussuchen. Dann einen langlebigen Token erstellen.


    Zusätzlich irgendwas mit Shell, wovon ich null Ahnung habe, wie das genau geht. Wenn Du googlest wirst Du auch fündig. Aber wie ich schon sagte, ich kann mit der Anleitung nix anfangen. Habs probiert, hat aber nicht funktioniert.

    Du musst einen Basic Auth Post Request gegen "/auth/token" mit clientId:clientPass im Basic Auth header und dem Body password, username und grant_type=„password“ durchführen.

    Ich arbeite aktuell an einem neuen Frontend, das ich dann auch einfach um weitere Funktionen erweitern kann. Mein Plan wäre es dann per Keycloak das nach außen hin mit Backend anzubieten. Die Software könnte man dann auf Raspberry PI installieren, müsste allerdings entweder per VPN oder Portweiterleitung nach außen weiter gegeben werden. Dadurch hätte man auch eine weiterhin sichere Anwendung.