SmartHomeNG Release v1.8

[Msinn]

Ok, dann weiss ich wo das her kommt. Ich baue gerade einen Fix, der die Exception abfangen sollte.

Mir ist allerdings weiterhin schleierhaft wer und warum die Websocket Verbindung bei euch beiden überhaupt geschlossen wird.

Spannend wäre auch noch, wenn ihr das ganze mal ohne Nutzung der Admin GUI testen könntet, also stattdessen die smartVISU aufmacht. Kommt dann auch der Error? Wird dann also die Verbindung auch geschlossen oder passiert das nur mit der Admin GUI?

[Msinn]

Ich habe bei mir

• SamartHomeNG auf einem älteren Debian (Linux-4.9.0-6-amd64-x86_64-with-glibc2.17)
• getestete Browser auf Mac OS
  • Safari
  • Chrome
  • Firefox

das Verhalten nicht nachstellen können.

[Scaramangas]

Spannend wäre auch noch, wenn ihr das ganze mal ohne Nutzung der Admin GUI testen könntet, also stattdessen die smartVISU aufmacht. Kommt dann auch der Error? Wird dann also die Verbindung auch geschlossen oder passiert das nur mit der Admin GUI?

hab das jetzt ein paar mal ausprobiert und mich durch die smartVISU geklickt, bis jetzt taucht der Fehler nicht auf rein mit smartVISU

[Scaramangas]

Ich habe bei mir

• SamartHomeNG auf einem älteren Debian (Linux-4.9.0-6-amd64-x86_64-with-glibc2.17)
• getestete Browser auf Mac OS
  • Safari
  • Chrome
  • Firefox

das Verhalten nicht nachstellen können.

würd`s dir was helfen das System direkt anzuschauen?

[Msinn]

Nicht wirklich. Wichtig wäre, ob es so bleibt, dass das Problem mit der smartVISU nicht auftritt.

[Scaramangas]

Wichtig wäre, ob es so bleibt, dass das Problem mit der smartVISU nicht auftritt.

bis jetzt kann ich das bestätigen, schaue mir die Logs direkt über das Dateisystem an, nicht über die Admin-GUI.

[Sipple]

Ich schaue morgen mal genauer. Muss erst noch smartVISU installieren. Grad schnell mal auf nem iPad mit Safari versucht. Gleiches Verhalten wie mit Firefox auf den Windows Maschinen.
der Webserver auf dem Raspi ist Apache. Nur zur Info.

[Morg]

Nur als kurzes Feedback:

ich habe von 1.7.1_master auf 1.8_master umgestellt. Die anfänglichen Starts waren... sagen wir mal holprig, die oben angesprochenen Fehler (1005 und authentication failed on REST) hatte ich da auch.

Seitdem ich alle aktiven Plugins und Module "fertig" konfiguriert habe, habe ich die Fehlermeldung nicht mehr gehabt. SmartVisu 2.9dev (aktuell) lädt eine Reihe von Daten und mindestens drei Plot-Serien.

RasPi 3B+, Debian 10.4, Python 3.7.3, websockets 8.1, janus 0.6.1

[Msinn]

schuma

1. Wie kann ich diesen Logik Aufruf nun mit dem neuen smartvisu Plugin umsetzen?

sh.visu.url('index.php?page=index', sh.Setup.Schalter.Raumseiten.morgens.IP())

Im kommenden Release 1.8.1 ist das dann im smartvisu Plugin implementiert. Zu beachten ist nur, dass im Aufruf sh.visu.url() visu der Name des Abschnitts in der etc/plugin.yaml ist, der das Plugin konfiguriert in dem die Funktion url() implementiert ist. Bei Dir also früher das visu_websocket Plugin.

Statt visu musst Du also dann in Zukunft den Namen des Abschnitts einsetzen, in dem Du das smartvisu Plugin konfiguriert hast.

[schuma]

Statt visu musst Du also dann in Zukunft den Namen des Abschnitts einsetzen, in dem Du das smartvisu Plugin konfiguriert hast.

Ok, vielen Dank!

[Sipple]

Noch eine kleine Information zu dem Websocket Error.
Der Logeintrag erscheint nicht schon wenn man zur Systemseite HINnavigiert, sondern erst wenn man davon WEGnavigiert.
Weiß nicht, ob die Info nützlich ist.

[Sipple]

so sollte in der Plugin.yaml der Abschnitt für das samartvisu-Plugin aussehen:

smartvisu:
plugin_name: smartvisu
smartvisu_dir: /var/www/html/smartVISU
generate_pages: false
handle_widgets: false
list_deprecated_warnings: true
overwrite_templates: no

Wenn Du die Generierung von Seiten oder das Handling von Plugin-spezifischen Widgets nicht brauchst, dann schreibt das Plugin nur das masteritem-File, das der Widget Assistant benötigt, ins konfigurierte Seitenverzeichnis und lädt die Liste der deprecated/removed Widgets von smartVISU in shNG. Danach geht es in den Pausen-Modus.

Gruß
Wolfram

Ok, habe ich mal so eingerichtet. Bei overwrite_templates kommt bei mir false anstatt no. Denke mal, das ist egal.
Mit "Pausen-Modus" meinst du, dass das Plugin in der Plugin-Liste links am Rand dann auch ein rotes Pausensymbol anzeigt? Ist also normal?
In diesem Pausen Modus, ist das default_acl dann noch relevant? Möchte ungern ein paar hundert items modifzieren müssen.

[schuma]

Noch etwas ist mir aufgefallen:
In den beiden Alexa Plugins (Alexarc4shng und alexa4p3) fehlen Dateien. Wie z.B. die requirements.txt.
Ich hatte meine Verzeichnisse beim Update umbenannt und die Ordner die mit dem Git Pull kamen waren nicht vollständig.
AndreK Könntest Du hier auch noch mal drüber gucken?

[Msinn]

Der Logeintrag erscheint nicht schon wenn man zur Systemseite HINnavigiert, sondern erst wenn man davon WEGnavigiert.
Weiß nicht, ob die Info nützlich ist.

Danke das hilft mir auf jeden Fall weiter bei der Eingrenzung. Ich habe nun eine Idee in welcher Ecke das liegt. Ich kann es nur leider bisher auf Systemen von mir nicht nachstellen, bin daher etwas im Blindflug.

[Msinn]

Ist also normal?
In diesem Pausen Modus, ist das default_acl dann noch relevant?

Ja

Möchte ungern ein paar hundert items modifzieren müssen.

Wenn Du bisher keine visu_acl bzw. acl Einträge in den Items hast, brauchst Du die Items auch nicht zu modifizieren. Die Grundeinstellung nimmt der Parameter default_acl vor.

Wenn Du in einem Item jedoch einen Eintrag hast, greift natürlich der und nicht die Voreinstellung aus default_acl.