Update von 2.9 auf 3.0 in einfach - mal vorsichtig nachgefragt

[2malmama]

Hallihallo in die Runde

ich überlege gerade, ob meine Vorgehensweise für das Update im Nachhinein irgendwelche Schwierigkeiten nach sich ziehen könnte.
So dachte ich, ich frag mal nach Eurer Meinung.

Vorweg - ich bin überhaupt erst darauf gekommen das so zu lösen, weil ich auf keinem der beiden Raspis (einmal Proxy - einmal für die Schaltzentrale) die passende Zeile für die Änderung auf das neue Verzeichnis gefunden habe.

Deshalb habe ich schlichtweg den alten smartvisu-Ordner in smartvisu2.9 umbenannt und den neuen (den ich zunächst der Übersicht halber smartvisu3 nannte) nach der Installation und der Rechtevergabe in smartvisu umbenannt.

Die neue Oberfläche wird anstandslos geladen, ich habe dann wieder meine Einstellungen im Config-Menü vorgenommen. Da ich alle Einstellungen im globalen Bereich vorgenommen habe, musste ich auch keine config.ini anpassen. (Hätte allerdings erwartet, dass er die globalen Einstellungen automatisch übernimmt).

So, jetzt hoffe ich mal, dass keiner die Hände über dem Kopf zusammenschlägt

[wvhn]

Das ist absolut das richtige Vorgehen.
Die globalen Einstellungen können nicht automatisch übernommen werden. Dazu müsstest Du höchstens die config.ini aus dem alten Hauptverzeichnnis (smartvisu2.9) in das neue Hauptverzeichnis kopieren. Das ist aber keine so gute Idee, weil in v3.0 ein paar neue Einstellungen hinzu gekommen sind.

Der Vorteil der beiden „parallelen“ Ordner ist außerdem, dass Du Deine bisherige Visu mit dem geänderten Ordnernamen 1:1 weiter verwenden kannst, während Du die neue Visu ggfls. mit neuen Features aus v3.0 weiter entwickelst.

Gruß
Wolfram

[2malmama]

na da bin ich ja mal absolut beruhigt

Vielen lieben Dank Wolfram, für Dein Feedback und die erklärenden Zusatzinfos!

[ooUrmeloo]

Hallo,
darf ich mich hier mal mit dran hängen?
Ich bin ebenfalls gerade dabei, von 2.9 auf 3.0 umzusteigen.
Ich habe die neue Version in /var/www/html/smartvisu30 installiert und habe in meiner plugin.yaml noch den Pfad geändert.

smartvisu:
plugin_name: visu_smartvisu
# # '"neue" Linux Versionen (z.B. Debian > 8.x, Ubuntu > 14.x)'
smartvisu_dir: /var/www/html/smartvisu30

Aber es wird mir immer noch die alte Version angezeigt bzw. in der Config finde ich weiterhin die Verzeichnisse aus dem Original-Verzeichnis.
Wo muss ich denn den Pfad (sonst noch) ändern??

[wvhn]

Das neue Plugin heißt „smartvisu“. Näheres sieht hier.

Gruß
Wolfram

[ooUrmeloo]

Das neue Plugin heißt „smartvisu“. Näheres sieht hier.

Gruß
Wolfram

Danke, das hat mich schon einen Schritt weiter gebracht. Wenn ich das richtig verstanden habe, dann ersetzt das "smartvisu" Plugin das alte "visu_smartvisu" und "visu_websocket"?!?

Wenn ich allerdings beide alten deaktiviere, kommt die Fehlermeldung: "Could not connect to smarthome.py server! Websocket error undefined".

Wenn ich versuchsweise den "visu_websocket" noch drin lasse, kommen im log folgende Fehler:
"Plugins "visu_websocket" and "smartvisu" define the same item-attribute 'visu-acl'" -> ok, verstehe ich ... ist ja dann doppelt.
"The new websocket module is not configured/loaded" -> wo mache ich das? Ist das nicht automatisch mit dem neuen smartvisu Plugin getan?
SmartHomeNG läuft, auf die Konfiguration kann ich zugreifen.

Wo stehe ich auf dem Schlauch??

Apropos ... noch eine andere Frage ... beim Template Checker gibt es nach dem Umstieg diverse Fehlermeldung zu den widgets.
Haben die sich alle geändert? Gibt's da einen Changelog o.ä., wo man die Änderungen alle nachvollziehen kann?
Oder hängt das an dem oben genannten Fehler?

Viele Grüße aus dem nicht ganz weit entfernten Bietigheim.

[wvhn]

Du brauchst zusätzlich noch die websocket Verbindung. Das ist entweder das neue Websocket-Modul, oder das Plugin visu_websocket. Wenn Du bei dem Link, den ich Dir geschickt hatte, eine Seite weiter blätterst, findest Du die Beschreibung. Die doppelte Definition von visu-acl ist unkritisch.

Seit v2.9 sind einige Widgets veraltet und waren dort bereits durch neue Widgets ersetzt. Beispiel: basic.stateswitch ersetzt basic.switch und basic.dual. Die veralteten Widgets sind jetzt in v3.0 gelöscht. Der Templatechecker gibt Dir Hinweise mit konkreten Parametrierungen für die Umstellung. Zudem kannst Du den Widget Assistent zum Parametrieren und Ausprobieren nutzen.

Das Changelog ist im Rootverzeichnis von smartVISU.

Gruß
Wolfram

[ooUrmeloo]

Und nochmals danke! Das war's. Mit dem Websocket Modul scheint's zu funktionieren.
Allerdings kommt immer noch ein roter "Error" in der Ecke ... mit "Unknown Error"
Jetzt muss ich mich wohl an die Widgets ran machen.
Ich habe m.E. schon alle aktuellen Widgets aber irgendwie scheint was nicht zu passen.
Z.B. sind alle Temperaturen auch auf °F umgestellt und ein paar andere "Ungereimtheiten" ...

[wvhn]

Der Templatechecker sagt Dir, ob alle Systemvoraussetzungen erfüllt sind und was an den Widgets nicht stimmt. Nicht vorhandene Widgets führen eher zu einem Twig Template Engine Fehler, nicht zu dem roten Dreieck.

Das rote Dreieck mit "unknown error" könnte eher von den Services (Kalender, Phone, Wetter) stammen. Die kannst Du erstmal jeweils auf "Service disabled" stellen und dann sehen, ob der Fehler verschwindet.

°F verschwindet, wenn Du die Sprache auf Deutsch einstellst. Eventuell hast Du auch eine alte config.ini einfach kopiert und die im alten System eingestellte individuelle Sprachdatei existiert im neuen System noch nicht. v3.0.x nimmt dann Englisch als default.

Wenn die config.ini kopiert wurde, musst Du einmal das Design ändern, abspeichern und dann das gewünschte Design wieder einstellen. Das ist notwendig, um die Farbzuordnungen richtig einzustellen. Deshalb wird hier im Forum empfohlen, die config.ini nicht zu kopieren, sondern neu anzulegen. Möglicherweise ist auch das die Ursache für das rote Dreieck.

Am besten schaltest Du den Cache erst ein, wenn alle Änderungen erledigt sind und die Visu wieder richtig läuft.

Gruß
Wolfram

[ooUrmeloo]

Hat zwar ein paar Tage gedauert, wollte aber trotzdem nochmal kurz Rückmeldung geben.
Rotes Dreieck kam wirklich von Kalender + Phone (hatte ich aus einem Beispiel drin aber nie konfiguriert, war aber in 2.9 kein Problem).
Habe es jetzt ganz rausgeworfen, und jetzt gibt es keine Fehlermeldung mehr.

Interessanterweise bringt mein Widget-Checker einige Error Fehlermeldungen mit "Item is not valid" obwohl sie einwandfrei zu funktionieren scheinen.
Na ja, muss ich mal mit etwas mehr Zeit nochmal schauen.
Temperatur hat sich übrigens auch geklärt ...
Ich benutze die Visu in Englisch, das war schon richtig. Aber wenn man statt English (UK) halt English (US) einstellt, dann kommt halt °F ...

Danke nochmals für die Tipps!

[wvhn]

Danke für die Rückmeldung. Die ‚item is not valid‘ Meldungen könntest Du mal posten (item-Name, item-Typ und Widget). Ich kann die Typen dann ggfs. in die Widgets aufnehmen.

Gruß
Wolfram

[ooUrmeloo]

Am Ende waren es doch gar nicht so viele, da einige Wiederholungen.
Beim Wetter gab es ein paar Fehler, alle bei diesem oder ähnlichen Widget:
basic.print('sunrise', 'env.location.sunrise', 'time')

und bei einigen uzsu wie bei dem hier:
device.uzsuicon('eg_esszimmer_licht_uzsu', 'EG.Esszimmer.Licht.schalten', 'Light Table')

Außerdem gab's ein paar "ID already in use" Errors. Das war aber mein Fehler durch copy&paste.

[wvhn]

OK. Die Zeitstempel der env-items sind in shNG mit Datentyp "foo" definiert. Das akzeptiert der Templatechecker nicht als gültigen Typ für basic.print. Da ich en Typ aber auch nicht als gültig aufnehmen möchte (sonst rutscht jedes item mit undefiniertem item-Typ durch), muss ich das mit shNG klären.

Funktionieren Deine UZSUs? D.h. kannst Du die aus der Visu so ändern, dass die geänderten Werte auch im Scheduler ankommen? Dazu müsste nämlich das item 'EG.Esszimmer.Licht.schalten' das UZSU-Item vom Typ dict sein. In der Visu muss das UZSU-item angegeben werden, nicht das zu schaltende item.

Mit der item-Definition

eg:
    esszimmer:
        licht:
            fenster:
                type: bool
                visu_acl: rw
                knx_dpt: 1
                knx_listen: 1/5/19
                knx_send: 1/0/19
                struct: uzsu.child

bekomme ich in shNG ein item 'eg.esszimmer.licht.fenster.uzsu', dass ich im Widget device.uzsuicon angebe.

Gruß
Wolfram

[ooUrmeloo]

mammamia ... hattest natürlich Recht ...
muss natürlich
device.uzsuicon('eg_esszimmer_licht_uzsu', 'EG.Esszimmer.Licht.schalten.uzsu', 'Light Table')

heißen. Dann klappt's auch.
Ja, alle anderen UZSUs für Heizung, Rollläden, Lichter laufen einwandfrei.
Und das letzte jetzt auch. (nach einem Cache clean-up).

Alle anderen "kritischen" roten Widget Fehler sind auch beseitigt. Scheint alles rund zu laufen.
Dank nochmal für die Hilfe!