Vielen Dank für die immer wieder tolle Anleitung.
LG, Sebastian

Somit wird z.B.

location @loc_smartvisu {
proxy_pass http:///$request_uri;
include /etc/nginx/headers.conf;
}

richtigerweiße zu:

location @loc_smartvisu {
proxy_pass http:///$request_uri;
include /etc/nginx/headers.conf;
include /etc/nginx/proxy_params;
}

Alternativ könnte man auch den Inhalt der proxy_params Datei in die headers.conf einfügen und so den bestehenden include für eine Datei lassen.

Problem:
Rolläden werden über mehrere knx-Objekte angesteuert, eines zum fahren, eines zum anhalten, etc.
Wenn man nun den Rollladen schließt, unterwegs anhält und dann weiter schießen, so muß das Objekt ‚Fahren‘ erneut mit demselben Wert ’schließen‘ gesendet werden.
SmarthoneNG sendet per default kein knx-Objekt, wenn das Item für diese knx-Objekt sich nicht geändert hat.
Daher wird dieser Use-Case so nicht funktionieren.

Lösung:
smartHome anweisen, das Item immer zu aktualisieren mit ‚enforce_update‘.

Vollständiges Beispiel:
* knx-Aktor: Betriebsart Rollladen
+ Langzeitbetrieb (=öffnen/schließen) -> knx-Objekt (z.B.) 3/3/1
+ Kurzzeitbetrieb: (=stopp) -> knx-Objekt (z.B.) 3/3/2

* smartHome-Items:
> NB_DG:
> name: „Dachgeschoß“
>
> # Items zur knx-Steuerung:
> velux_rollladen:
> move: # Taste Langzeitbetrieb. $00 = oeffnen / $01 = schliessen
> type: bool
> enforce_change: true # force send knx object even if value did not change
> knx_dpt: 1
> knx_send: 3/3/1
> knx_init: 3/3/1
> knx_listen: 3/3/1
>
> stop: # Taste Kurzzeitbetrieb (konfiguriert als Stop im Aktor):
> type: bool
> enforce_change: true # force send knx object even if value did not change
> knx_dpt: 1
> knx_send: 3/3/2
> knx_init: 3/3/2
> knx_listen: 3/3/2
> setPosition: # 0 = offen / 100(%) geschlossen
> type: num
> enforce_change: true # force send knx object even if value did not change
> initial_value: 75
> knx_dpt: 5.001
> knx_send: 3/3/3
>
> isPosition_pc:
> type: num
> knx_dpt: 5.001
> knx_send: 3/3/5
> knx_init: 3/3/5
> knx_listen: 3/3/5
>
> # Items zur automatischen Generierung der smartVISU-Seite:
> sv_page: room
> sv_img: control_building_dg.svg
> visublock01:
> name: Aufenthaltsraum
> sv_widget: „{{ device.shutter (“, “, ‚..velux_rollladen.move‘, ‚..velux_rollladen.stop‘, ‚..velux_rollladen.isPosition_pc‘, “, “, ‚..velux_rollladen.setPosition‘, ‚0‘, ‚100‘, “, “, “, ’50‘, ’75‘, ‚50%‘, ‚75% zu‘) }}

„… Ein Beispiel für etc/logging.yaml.default im Folgenden:
…
# items.new_device:
…
# handlers: [items_file] …“

Hier bitte korrigieren nach:
# handlers: [shng_items_file]

Da das Release bereits einige Monate alt ist und Du der erste bist, der mit der Admin GUI Probleme hat, würde ich noch nicht notwendigerweise auf ein allgemeines Problem mit der Doku schließen. Dazu müssen wir erst herausfinden, was bei Dir anders ist, als bei denen bei denen die Installation funktioniert hat.

Vielleicht bin ich da ganz am Holzweg, aber sollte es hier nicht logics.scheduler_trigger etc. heißen statt sh.scheduler.trigger? Spricht was dagegen, hier auch add und remove hinzuzunehmen? Und.. bei change auch noch, dass man sowohl next, als auch value aktualisieren kann..?

Kann das auch gerne selbst aktualisieren, wenn meine Annahmen passen.

ich verstehe ein Beispiel nicht aus der Dokumentation
type: num
autotimer: sh.item.dauer() = 0
dauer:
initial_value: 45
wert:
initial_value: 1
setzt nach der in item.dauer angegebenen Dauer (hier initial 45 Sekunden) den Wert des Items auf in item.wert (hier initial mit 1 angegebenen)
Zwei Fragen dazu:
1) ist es wirklich ‚hardcoded‘, dass auf „wert“ gesetzt wird? Mich wundert die Wahl des deutschen Begriffes und die Festlegung darauf
ich hätte eher etwas erwartet wie
autotimer: sh.item.dauer()=sh.item.wert()