Problem mit knx_listen bei internen Events

[Sipple]

Servus

Ich ziehe gerade Schritt für Schritt meinen alten Smarthome Server auf einen neuen um.

Der alte läuft noch mit SH 1.0 und smartVISU 2.7 (bzw eine alte Develop Version, die sich schon als 2.8 meldet).

Der neue läuft natürlich mit SHNG 1.7.1 und smartVISU 2.9.2.

Im alten sind z.B. folgende items definiert:

[Zentral_Aus]
    type = bool
    knx_dpt = 1
    knx_send = 0/1/0
    enforce_updates = yes
[Dauerlicht]
    type = bool
    knx_dpt = 1
    knx_send = 2/4/1
    knx_cache = 2/4/1
    knx_listen = 0/1/0

Um es gleich vorwegzunehmen, das macht grundsätzlich sowohl über den Bus als auch intern exakt das was es soll.

Im neuen sehen sie so aus:

Zentral_Aus:
    type: bool
    knx_dpt: '1'
    knx_send: 0/1/0
    enforce_updates: 'True'
Dauerlicht:
    type: bool
    knx_dpt: '1'
    knx_send: 2/4/1
    knx_cache: 2/4/1
    knx_listen: 0/1/0

Zentral_Aus macht das, wonach es sich anhört. Es schaltet fast alle Lichter aus und eben auch die Dauerlichtfunktion. Dauerlicht ist also nur ein Beispiel für ein Item, das zusätzlich auf die 0/1/0 hören soll.

In der Visu habe ich mehrere basic.stateswitch die das Zentral_Aus triggern.
Das funktioniert sendend auch einwandfrei. Die 0/1/0 kommt definitiv korrekt auf den Bus.
ABER: Intern in SHNG (und somit auch in der neuen Visu) wird kein item, das auf die 0/1/0 hört, upgedatet.
Der Brüller ist aber, dass ein VOM Bus empfangenes 0/1/0 wunderbar funktioniert. Also funktioniert das knx_listen doch - irgendwie.

Also nochmal kurz: SHNG schickt 0/1/0 auf den Bus, aber interne listener bekommen das nicht mit.

Wie gesagt, auf dem alten Server geht das so. Ich kann sogar per alter Visu Zentral_Aus triggern und im neuen Server wird alles richtig gesetzt.

Fehlermeldungen im Log gibt es keine. Probleme mit der Visu kann ich eigentlich fast ausschließen, denn Zentral_Aus wird ja getriggert und über den Bus empfangen klappt abenfalls.
Im Admininterface von SHNG sieht man , dass der Status der Items, die darauf hören sollten, NICHT geändert wurde.

Ich habe die Anleitung vom Plugin mehrfach durchgesehen, finde aber keinen Hinweis oder ich übersehe ihn, weil ich es wahrscheinlich nicht kapiere.

Danke im Voraus

Martin

P.S. Falls das relevant sein sollte: Der alte Server ist ein Jetway Atom Board mit Debian 7.11 (Wheezy). Der neue ein Intel NUC mit Debian 10.4 (Buster)

[wvhn]

Die Anführungszeichen beim dpt sind mir fremd. Ich kann aber nicht sagen, ob das die Ursache sein kann.

[Msinn]

Hierbei

Dauerlicht:
    type: bool
    knx_dpt: '1'
    knx_send: 2/4/1
    knx_cache: 2/4/1
    knx_listen: 0/1/0

sind mir 2 Sachen aufgefallen:

• dpt ohne Anführungszeichen (sollte aber keine Probleme machen)
• knx_cache und knx_listen zusammen macht keinen Sinn, schon gar nicht mit zwei verschiedenen Gruppenadressen. Welche soll denn nun gelesen werden (2/4/1 oder 0/1/0)?

Das funktioniert sendend auch einwandfrei. Die 0/1/0 kommt definitiv korrekt auf den Bus.
ABER: Intern in SHNG (und somit auch in der neuen Visu) wird kein item, das auf die 0/1/0 hört, upgedatet.
Der Brüller ist aber, dass ein VOM Bus empfangenes 0/1/0 wunderbar funktioniert. Also funktioniert das knx_listen doch - irgendwie.

Das ist kein Brüller sondern "works as designed". Das knx Plugin gibt keine Werte die es selbst auf den Bus geschrieben hat an SmartHomeNG zurück (und hat es auch nie getan). Wenn Du das Ergebnis vom Bus haben willst, musst Du auf die Statusinfo des entsprechenden Aktors lauschen.

Also nochmal kurz: SHNG schickt 0/1/0 auf den Bus, aber interne listener bekommen das nicht mit.

Wie gesagt, dass war schon immer so, auch unter smarthome.py 1.0. An der Funktionalität des knx Plugin hat sich nichts geändert.

[Sipple]

Die Anführungszeichen beim dpt sind mir fremd. Ich kann aber nicht sagen, ob das die Ursache sein kann.

Das macht der YAML Syntax Prüfer vom Admin Interface. Ebenso das 'True' aus yes bei enforce_updates. Da dieser Prüfer Bestandteil von SHNG ist, bin ich davon ausgegangen, dass das passt und weil ja prinzipiell alles funktioniert, bis auf das interne Update, ist das wohl auch so ok.

knx_cache und knx_listen zusammen macht keinen Sinn, schon gar nicht mit zwei verschiedenen Gruppenadressen. Welche soll denn nun gelesen werden (2/4/1 oder 0/1/0)?

Warum sollte das keinen Sinn machen? Er soll aus dem Cache den aktuellen Status von 2/4/1 holen und somit in der Visu die Dauerlichttaster korrekt anzeigen. ZUSÄTZLICH muss er aber beim Empfang von 0/1/0 aka Zentral_Aus auch die Dauerlichttaster zurücksetzten. Da macht imho lesen aus dem Cache gar keinen Sinn, weil Zentral_Aus keinen Status hat. Das ist eine reine Moment-Tasterfunktion die immer 1 sendet. Lesen aus dem Cache wäre da eher kontraproduktiv. Ich wüsste gar nicht, wie man das sonst lösen sollte. Habe das auch nie hinterfragt, weil das damals auf Anhieb funktioniert hat. Exakt wie gewünscht. Isch schwör, dass das mit dem alten smarthome.py und smartVISU 2.7 wirklich klappt. Echt ehrlich.
Das hat immer so funktioniert und tut es auch heute noch in der neuen Visu, solange die 0/1/0 über den Bus kommt.

Wenn ich mir den Hilfetext zu knx_cache anschaue, finde ich da auch keinen Hinweis, dass das nicht gehen sollte:

Die Angabe impliziert knx_listen, also muss knx_listen nicht für diese Gruppenadresse angegeben werden.

Sind ja auch zwei verschiedene Gruppenadressen. Kann es sein, dass du knx_init gelesen hast?

Wie gesagt, dass war schon immer so, auch unter smarthome.py 1.0. An der Funktionalität des knx Plugin hat sich nichts geändert.

Siehe oben. Doch, das geht in 1.0, zumindest bei mir. Leider gibts da kein so schönes Admininterface mit dem man das Updaten des items schnell überprüfen kann. Zeigen kann ich das nur über die korrespondierenden Widgets in der alten Visu und dass meine Lichter, Taster und Aktoren genau so reagieren wie sie sollen. Ich kann ja mal ein kurzes Video machen, wie sich die alte und neue Installation verhält.

Wenn du sagst, dass sich auch SH 1.0 so verhält wie von dir geschrieben, muss ich mich fragen, wie das Verhalten alt zu neu sonst zu erklären wäre. Es gibt auch keine Logiken, die das erklären könnten. Status von einem Aktor geht auch nicht, weil Dauerlicht ja keinen Schaltkanel direkt ansteuert etc., das ist wie ein Sperrobjekt. Keines meiner Geräte kann den Dauerlichtstatus bei Änderung senden. Wenn überhaupt, dann müsste man das pollen.

Du sagst also, dass SHNG keine lokalen items updated, wenn es selbst ein anderes lokales item ändert? Zentral_Aus und Dauerlicht sind ja nicht das selbe item. Warum sollte SHNG/das knx_plugin denn NICHT interne Updates machen?

Wie kann man das dann lösen? Wenn nicht so wie beschrieben.
Bin da jetzt echt ratlos.

Gruß, Martin

[Onkelandy]

Es geht nicht um shng, sondern um das Plugin. Praktisch bei allen Plugins ist das so eingestellt, dass es NICHT auf Änderungen von sich selbst hört. Das würde sonst zu hässlichen Dauerschleifen führen. In deinem Fall zwar nicht, aber sonst durchaus.

Kannst du das wirklich nicht über die ETS parametrieren?

[Msinn]

Wozu willst Du zental-aus überhaupt zurück in SmartHomeNG führen? Wenn zentral-aus den Aktor ausschaltet, liefert er diese Info doch über sein Status-Kommunikationsobjekt zurück. Du musst dieses nur über eine Gruppenadresse mit knx_listen, knx_init oder knx_cache (je nachdem welches Verhalten Du möchtest) in dem Item einlesen.

In Deiner Config hattest Du bei knx_cache die selbe Gruppenadresse angegeben wie bei knx_send, also nicht das Status-Kommunkkationsobjekt des Aktors, sondern einfach auf der Gruppenadresse mitgelauscht, auf der auch andere Devices den Aktor schalten.

welche Gruppenadresse ist denn in der ETS mit dem Status-Objekt des Aktors verbunden?

[Sipple]

Es geht nicht um shng, sondern um das Plugin. Praktisch bei allen Plugins ist das so eingestellt, dass es NICHT auf Änderungen von sich selbst hört. Das würde sonst zu hässlichen Dauerschleifen führen. In deinem Fall zwar nicht, aber sonst durchaus.

Ok, das ist plausibel, dass es das Plugin ist. Auch, dass es unter Umständen zu schleifen kommen könnte. Aber wie du schon sagst, das dürfte in dem Fall nicht passieren.
Da muss sich was geändert haben, denn dass meine alte Visu mit dem alten SH tut wie gewünscht bilde ich mir nicht nur ein.

Ob ich das mit der ETS so lösen kann, dass es so funktioniert wie bisher, weiß ich grad nicht.

Die Ausgangslage ist die:

Ich habe mehrere Leuchten im Haus, die im Aktor als Treppenhauslicht parametriert sind, weil meine Holde sehr gerne mal vergisst Lichter auszuschalten.
Ab und zu will man aber nicht nach 20min im Dunkeln stehen. Dafür gibt es die Sperre, die im Aktor den Timer deaktiviert. Eine 1 auf dieses Objekt sperrt, eine 0 gibt frei.
Um dieses Sperre zu aktivieren, habe ich an strategisch wichtigen Orten physkalische Taster und darauf eine Wippe mit 2/4/1 belegt, Betriebsart "um".
Tut was es soll. Alle Taster senden und hören auf die 2/4/1. Alle Aktoren mit Treppenhauslicht hören auf 2/4/1 auf dem Sperrobjekt. Aber einen STATUS für das Sperrobjekt gibt es nicht. Läßt sich auch nicht parametrieren.

Jetzt habe ich das Verhalten eines physikalischen Tasters in der Visu. Es gibt auf mehreren Seiten einen basic.stateswitch, der genau diese Tasterfunktion nachbildet. Hören und Senden auf die 2/4/1. Das klappt, ist ja auch kein Hexenwerk. Soweit so gut.

Zurück zu den physikalischen Tastern und Aktoren.
Wenn wir das Haus verlassen oder schlafen gehen, drücken wir eine Zentral-Aus Taste. Auch davon gibt es mehrere. Die senden IMMER eine 1 und es gibt natürlich kein Gerät, dass diese 0/1/0 als Status zurück schickt. Dadurch gehen z.B. alle Lichter aus. Außerdem wird damit auch ein aktives Dauerlicht auf allen Aktoren deaktiviert. Das müssen natürlich auch die Dauerlicht-Tasterwippen mitbekommen, also hören diese eben auch auf die 0/1/0.
Daher ist es für mich logisch, dass auch das Dauerlicht item für die Visu "Taster" auf die 0/1/0 hören muss, daher das knx_listen.
Bis hierhin funktioniert auch alles wie gesagt einwandfrei.
Diese Zentral-Aus Funktion habe ich jetzt auch in die Visu integriert und damit bei jedem Klick auf den "Taster" auch wirklich immer eine 1 gesendet wird, brauche ich das enforce_update = yes. Richtig?
Dieses Visu/SHNG getriggerte Zentral_Aus über die 0/1/0 wird auch korrekt auf den Bus gesendet. Alle Lichter gehen aus, die Dauerlicht Sperre wird aufgehoben. Überall, nur nicht lokal. Die Visu denkt immer noch, dass alle Items, die auf 0/1/0 hören und aktiv waren weiterhin aktiv sind.

Früher musste ich gar nichts weiter machen, aber wie löst man das Problem nun? Wenn ich euch richtig verstanden habe, dann gibt es keine lokale Lösung.

Das wäre schade. Ich müsste also irgendwo anders eine 0/1/0 auf den Bus "zurück" schicken wenn in der neuen Visu der Zentral-Aus Taster angeklickt wird. Mit einer anderen Gruppenadresse. Oder so.

Hat jemand eine Idee?

[Msinn]

Früher musste ich gar nichts weiter machen, aber wie löst man das Problem nun? Wenn ich euch richtig verstanden habe, dann gibt es keine lokale Lösung.

Das wäre schade. Ich müsste also irgendwo anders eine 0/1/0 auf den Bus "zurück" schicken wenn in der neuen Visu der Zentral-Aus Taster angeklickt wird. Mit einer anderen Gruppenadresse. Oder so.

Hat jemand eine Idee?

Hast Du meinen Post von 22:55 Uhr gelesen?

[Sipple]

welche Gruppenadresse ist denn in der ETS mit dem Status-Objekt des Aktors verbunden?

Unsere Beiträge haben sich überschnitten.
Ich poste morgen mal Screenshots von der ETS. Schon spät heute. Danke erstmal.

[mumpf]

Hi,

ich kann bestätigen, dass das Pattern von Sipple in dem ursprünglichen smarthome.py funktionierte. Habe ich früher öfter verwendet, auch im Nachfolgeprodukt Callidomus. Ich glaube sogar, ich habe das mal vor Urzeiten auch als Fehler hier gemeldet, dass es nicht mehr geht. Und Diskussion hin und her: Natürlich sollte eine Logikengine auch auf GA hören, die sie selber aussendet. Schaut euch mal KNX-Logikmodule an, die machen das auch. Wie soll man sonst komplexere Logiken bauen?

Wie gesagt, dass war schon immer so, auch unter smarthome.py 1.0. An der Funktionalität des knx Plugin hat sich nichts geändert.

Ich weiß nicht, auf welcher Ebene es in sh.py implementiert war. Wenn Du sagst, dass sich das knx Plugin nicht geändert hat, dann war es intern implementiert. Funktioniert hat es ...

Sipple: Du kannst Dein Problem mit

Dauerlicht:
    type: bool
    knx_dpt: '1'
    knx_send: 2/4/1
    knx_cache: 2/4/1
    eval: value
    eval_trigger: Zentral_Aus
    enforce_updates: 'True'

lösen.

Viel Erfolg und Grüße,
Waldemar

[Sipple]

Hallo Waldemar

DANKE!!! Das hat es gebracht.
Musste allerdings trotzdem noch das knx_listen "von früher" drin lassen, sonst hätte es nicht auf Zentral_aus vom Bus reagiert (logisch).

Also:

Dauerlicht:
    type: bool
    knx_dpt: 1
    knx_send: 2/4/1
    knx_cache: 2/4/1
    knx_listen: 0/1/0
    eval: value
    eval_trigger: Zentral_Aus
    enforce_updates: yes

Damit kann ich gut leben, tut wieder wie gewohnt.
Wenn ich nicht noch einen seltenen Fall übersehen habe, ist das die Lösung.

Danke an alle für die Hilfe.

Gruß, Martin

[Msinn]

Für einen reinen Schalt-Aktor funktionert das. Es ist nur für andere Aktoren mit Unsicherheiten behaftet, weil Du aus den Events auf zwei Gruppenadressen die Befehle an den Aktor senden mithörst und rätst/interpretierst welchen Zustand der Aktor eingenommen haben wird.

Ein Beispiel, wo das nicht funktioniert: Wenn das kein Schalt-Aktor sondern ein Dimm-Aktor wäre, kannst Du über eine weiere Gruppenadresse den Helligkeitswert (0 bis 255) einstellen. Wenn Du Helligkeit 0 wählst, wird der Aktor ausgeschaltet. Das würde SmartHomeNG nicht mitbekommen, da auf keiner der beiden Gruppenadressen auf denen SmartHomeNG lauscht ein Befehl gesendet wurde.

Besser wäre es, mit knx_cache auf über eine Gruppenadresse auf dem Status-Kommunikationsobjekt des Aktors zu lauschen. Dann bräuchtest Du auch das knx_listen auf Zentral-Aus nicht, da Du den wirklichen Status des Aktors abfragst.