relative Dimmfunktion über 2 Lichtquellen

[Cannon]

Aber in dem Fall hast du's jetzt ja eh gelöst..

Noch nicht ganz. Ich probiere das Stück für Stück umzusetzen - es funktioniert auch immer mehr. Allerdings kann man nicht immer alles auf einmal testen. Man sieht die Sachen erst im laufenden Betrieb Stück für Stück. Aktuell ist das Problem, dass der Status des schaltens nicht so übermittelt wird, wie ich mir das vorstelle.

                DualWhite:
                    schalten:
                        type: bool
                        knx_dpt: 1
                        knx_send: 5/0/8
                        knx_init: 5/2/8
                        visu_acl: rw
                        Status:
                            type: bool
                            knx_dpt: 1
                            knx_send: 5/2/8
                            enforce_updates: yes
                            eval: or
                            eval_trigger:
                                - ....WW.schalten
                                - ....CW.schalten
                        Tastsensor:
                            type: bool
                            knx_dpt: 1
                            knx_cache: 5/5/1
                            enforce_updates: yes
                            on_update:
                                - ...sperren = False if value and sh....sperren() else None
                                - ...schalten = value
                                - ...Dimmwert = min(255, sh....Dimmwert() + 64) if value and sh....Dimmwert() > 0 else None

Den Tastsensor werte ich aus und setze damit den externen Tastereingang am Präsenzmelder. Dieser sendet dann den Dimmwrt zurück. Das item Status ist die Rückmeldung, ob ein Kanal an ist oder nicht. Dieser sendet dann quasi den Status schalten auf den Bus zurück. Nach meinem Verständnis sollte aber dann auch das item schalten über die Adresse 5/2/8 aktualisiert werden. Das tut sie aber nicht, sprich schalten.Status ist true, aber schalten ist false. Wieso ist das so?

[Onkelandy]

Bin mir noch nicht ganz sicher, ob ich's verstanden habe. Was genau ist die GA 5/2/8? Die Statusrückmeldung des Lichtaktors? Die ist ja nicht schreibbar, sondern gibt dir automatisch den Wert auf den Bus, auf dem sich der Aktor befindet?

[Cannon]

Bin mir noch nicht ganz sicher, ob ich's verstanden habe. Was genau ist die GA 5/2/8? Die Statusrückmeldung des Lichtaktors? Die ist ja nicht schreibbar, sondern gibt dir automatisch den Wert auf den Bus, auf dem sich der Aktor befindet?

Ja es ist quasi die Rückmeldung. Allerdings ist ja nur WW und CW mit dem Aktor (DALI-Gateway) verbunden und DualWhite wertet das nur aus und sendet demnach hier an den Bus zurück, wenn einer der beiden an ist.

Ich habe das jetzt so gut wie gelöst und es funktioniert auch. Allerdings und das hat was mit SmartHomeNG zu tun, weil ich das wohl nicht ganz Bescheid weiß, wird die Statusrückmeldung nicht in einem Item raus gesendet und bei dem anderen empfangen.

                DualWhite:
                    schalten:
                        type: bool
                        knx_dpt: 1
                        knx_send: 5/0/8
                        knx_cache: 5/2/8
                        enforce_updates: yes
                        visu_acl: rw
                        Status:
                            type: bool
                            knx_dpt: 1
                            knx_send: 5/2/8
                            enforce_updates: yes
                            eval: or
                            eval_trigger:
                                - ....WW.schalten
                                - ....CW.schalten
                        Tastsensor:
                            type: bool
                            knx_dpt: 1
                            knx_listen: 5/5/1
                            enforce_updates: yes
                            on_update:
                                - ...schalten = True if value and sh....Dimmwert() == 0 else False if not value else None
                                - ...Dimmwert = min(255, sh....Dimmwert() + 64) if value and sh....Dimmwert() > 0 else None
                    Dimmwert:
                        type: num
                        knx_dpt: 5
                        knx_send: 5/3/8
                        knx_cache: 5/3/8
                        visu_acl: rw
                        alexa_device: DALI_Buero
                        alexa_actions: AdjustBrightness SetBrightness
                        on_change:
                            - ...WW.Dimmwert = min(value * 2, 255) if sh.EG.Buero.TagNacht() else None
                            - ...CW.Dimmwert = max(value * 2 - 255, 0) if sh.EG.Buero.TagNacht() else None
                            - ...CW.Dimmwert = min(value * 2, 255) if not sh.EG.Buero.TagNacht() else None
                            - ...WW.Dimmwert = max(value * 2 - 255, 0) if not sh.EG.Buero.TagNacht() else None
                    dimmen:
                        type: list
                        knx_dpt: 3
                        knx_listen: 5/1/8
                        on_change:
                            - .dimmen_auf = sh...Dimmwert()
                            - .dimmen_ab = sh...Dimmwert()
                            - .dimmen_auf = sh..dimmen_auf.fade(255, 5, 0.2) if value[0] == 1 and value[1] == 1 else -1 if value[0] == 1 and value[1] == 0 else None
                            - .dimmen_ab = sh..dimmen_ab.fade(0, 5, 0.2) if value[0] == 0 and value[1] == 1 else -1 if value[0] == 0 and value[1] == 0 else None
                        on_update:
                            - ..sperren = True if value[0] == 0 and not sh...schalten.Status() else None
                        dimmen_auf:
                            type: num
                            on_change: ...Dimmwert = value if value != -1 else max(0, sh....Dimmwert() - 5)
                        dimmen_ab:
                            type: num
                            on_change: ...Dimmwert = value if value != -1 else min(255, sh....Dimmwert() + 5)
                    TagNachtWechsel:
                        type: bool
                        eval: value
                        eval_trigger: EG.Buero.TagNacht
                        on_change:
                            - .backup_ww = sh....WW.Dimmwert()
                            - .backup_cw = sh....CW.Dimmwert()
                            - ...WW.Dimmwert = sh....WW.Dimmwert.fade(sh..backup_cw(), 1, 600/abs(sh..backup_cw()-sh..backup_ww())) if sh..backup_cw()-sh..backup_ww() > 0 else None
                            - ...CW.Dimmwert = sh....CW.Dimmwert.fade(sh..backup_ww(), 1, 600/abs(sh..backup_cw()-sh..backup_ww())) if sh..backup_cw()-sh..backup_ww() > 0 else None
                        backup_ww:
                            type: num
                        backup_cw:
                            type: num
                WW:
                    schalten:
                        type: bool
                        knx_dpt: 1
                        knx_send: 5/0/9
                        knx_cache: 5/2/9
                        enforce_updates: yes
                        visu_acl: rw
                    Dimmwert:
                        type: num
                        knx_dpt: 5
                        knx_send: 5/3/9
                        knx_cache: 5/2/41
                        visu_acl: rw
                CW:
                    schalten:
                        type: bool
                        knx_dpt: 1
                        knx_send: 5/0/10
                        knx_cache: 5/2/10
                        enforce_updates: yes
                        visu_acl: rw
                    Dimmwert:
                        type: num
                        knx_dpt: 5
                        knx_send: 5/3/10
                        knx_cache: 5/2/42
                        visu_acl: rw

Als besonderen Bonus führt jedes erneute Drücken des Tastsensor eine Erhöhung der Helligkeit um 25% durch.

[Onkelandy]

Aber sonst funktioniert das mit knx_cache und knx_listen, oder? Kannst ja mal den Monitor der ETS nutzen, um zu checken, was auf dem Bus so passiert. Ansonsten hier mal nen Screenshot der relevanten ETS Teile hier posten. Mit ist nämlich noch nicht klar womit 5/0/8 und 5/2/8 verbunden ist. Musst du den Umweg über KNX hier wirklich machen oder könntest du nicht einfach DualWhite.schalten mittels eval und eval_trigger aktualisieren bzw. gleich durch den Inhalt deines Status-Items ersetzen (mit knx_send 5/0/8)?

Falls 5/0/8 nur dazu da ist, um die LED beim Tastsensor zu ändern, könntest du vermutlich auch einfach 5/0/9 und 5/0/10 mit deinem Taster-Status verbinden. Bei mir zumindest werden 2 GAs beim Tasterstatus als "oder" ausgewertet und das Lichtchen leuchtet, sobald weiß und/oder kalt an ist.

Warum genau hast du das on_update nicht so geschrieben?

 
 - ...CW.Dimmwert = max(value * 2 - 255, 0) if sh.EG.Buero.TagNacht() else min(value * 2, 255)

[Cannon]

Aber sonst funktioniert das mit knx_cache und knx_listen, oder?

Ja das ja. Gruppenmonitor nutze ich sowieso, sonst würde ich das glaueb ich gar nicht schaffen. ;-)

5/0/8 sendet an den Präsenzmelder auf den externen Taster-Eingang. 5/2/9 bzw. 5/2/10 ist die Rückmeldung vom DALI-Gateway (Status schalten), der ist das was an die LED vom Tastsesor ran geht.

Bei mir zumindest werden 2 GAs beim Tasterstatus als "oder" ausgewertet und das Lichtchen leuchtet, sobald weiß und/oder kalt an ist.

Ja, weil das bei KNX so ist, dass in der Regel immer der letzte "Impuls" übernommen wird. Das wäre insofern natürlich sinnvoll. Allerdings möchte ich das ja nachher auch in der VISU richtig haben und dafür wäre meines erachtens die Statusrückmeldung des Aktors immer die richtige Lösung. Deshalb liegt der knx_chache auf 5/2/8 (Status DualWhite schalten). Aber genau dieser Status wird zwar auf den Bus gesendet beim ITEM schalten.Status, allerdings beim ITEM schalten wird das nicht zurückgelesen.

- ...CW.Dimmwert = max(value * 2 - 255, 0) if sh.EG.Buero.TagNacht() else min(value * 2, 255)

Ich denke das war noch vom testen der Übersichtlichkeit halber. Kann ich aber natürlich jetzt kürzen. Den TagNachtWechsel könnte man ja auch kürzen, war mir aber so übersichtlicher. :-)

[Cannon]

Naja optimal läuft es nicht. Ich bin also noch nicht ganz zufrieden. Ich habe das jetzt auch geändert und es läuft direkt im KNX. Indem ich nämlich erste die eine Farbe hochfahre und beim nächsten Druck erst die 2. Farbe anspreche, dann fallen diese Latenzen weg....

Was mir aber noch unklar ist, wieso das lesen von knx nicht funktioniert, wenn der Wert in SmartHomeNG geändert wird. Ist das ein Fehler?

                DualWhite:
                    schalten:
                        type: bool
                        knx_dpt: 1
                        knx_send: 5/0/8
                        knx_cache: 5/2/8
                        knx_reply: 5/0/8
                        enforce_updates: yes
                        visu_acl: rw
                        Status:
                            type: bool
                            knx_dpt: 1
                            knx_send: 5/2/8
                            knx_reply: 5/2/8
                            eval: or
                            eval_trigger:
                                - ....WW.schalten
                                - ....CW.schalten

Sobald ich den Dimmwert beispielsweise bei WW setze wird auch WW eingeschaltet und der Status (DualWhite.Status) wird auf true gesetzt. Das Ganze wird dann auch auf den Bus 5/2/8 gesendet (Status schalten). Allerdings bleibt das item schalten dennoch false, obwohl ja knx_cache auch 5/2/8 ist ... es ändert auch nichts knx_cache auf listen zu ändern .... Nach meinem Empfinden sollte doch schalten dann auch true. Wird es aber nicht. Kann es sein, dass ich mit SmartHomeNG , wenn ich auf eine GA schreibe die gleiche GA nicht an anderer Stelle wieder zurücklesen kann?

[mumpf]

Hi Cannon,

Du hast einen der Gründe gefunden, die mich davon abhalten, auf shNG.py zurückzuwechseln (ist nicht der einzige, aber ein wichtiger). Ich halte das für einen Fehler! Natürlich müsste ein Item, dass auf eine GA hört, immer von einer Änderung des GA-Wertes betroffen sein, und nicht nur, wenn die GA von außen (Bus) kommt! Dass dies technisch nicht über den Bus passieren muss, sonder auch intern im knx-plugin gelöst werden kann, ist eine andere Geschichte.

Abstrakt gesehen müsste das für jedes Kommunikations-Plugin gelten: Wenn ich über das nw-Plugin mit einem Item auf eine IP:PORT schreibe und mit einem anderen Item auf die gleiche IP:PORT höre, sollte das andere Item das mitbekommen.

Derzeit musst Du selber dafür sorgen, entweder über eval/eval_trigger oder über on_update/on_change.

Gruß, Waldemar

[Cannon]

Du hast einen der Gründe gefunden, die mich davon abhalten, auf shNG.py zurückzuwechseln

Was nutzt du denn? :-)

Ich halte das für einen Fehler!

Gut, denn oft bin ich nicht sicher, ob ich da nicht einen Denkfehler habe. Weniger gut aber, dass es ein Fehler ist.

Derzeit musst Du selber dafür sorgen, entweder über eval/eval_trigger oder über on_update/on_change.

Leider geht das nicht. Denn ich will ja nur, dass sich der Wert das items ändert, sprich das item eigentlich nur den richtigen Wert hat. on_update oder on_change führen dazu, dass das item wieder Daten auf den Bus schreibt, was aber unsinnig ist und auch dazu führt, dass wieder ein Vorgang im KNX ausgelöst wird. eval und eval_trigger haben den Nachteil, dass ich das item nicht direkt mit einem Wert beschreiben kann. Dazu müsste eval NUR dann aufgerufen werden, wenn der trigger ausgelöst wird. Gibt es diese Möglichkeit irgendwie? Wenn ja würde das vieles erleichten.

[mumpf]

Was nutzt du denn? :-)

Ich nutze callidomus, das ist das Nachfolgeprodukt... allerdings nicht kostenlos. Konzeptionell sehr ähnlich (was die Items angeht), eine integrierte Visu und schön stabil.

Leider geht das nicht.

Ja, jetzt hab ich mir mal genauer Deine Item-Struktur angesehen, so geht das wirklich nicht ohne weiteres. Ich kann Dir nur anbieten, am Wochenende (vorher schaffe ich das nicht) mal meine Struktur zu posten. Ich hab das Gefühl, dass Du Status und Schalten nicht sauber genug trennst, aber ich sehe nicht auf den ersten Blick den Unterschied zu meinem Ansatz. Ich muss mal vergleichen, wie gesagt, mehr am Wochenende.

Gruß, Waldemar

[Cannon]

Ja, jetzt hab ich mir mal genauer Deine Item-Struktur angesehen, so geht das wirklich nicht ohne weiteres. Ich kann Dir nur anbieten, am Wochenende (vorher schaffe ich das nicht) mal meine Struktur zu posten. Ich hab das Gefühl, dass Du Status und Schalten nicht sauber genug trennst, aber ich sehe nicht auf den ersten Blick den Unterschied zu meinem Ansatz. Ich muss mal vergleichen, wie gesagt, mehr am Wochenende.

Mein Ansatz ist auch, das eben nicht zu trennen. Warum auch? Das Ganze ist eine KNX-Geschichte, dass Status und Schalten separate Objekte sind. In SmartHomeNG, sollte doch der Item-Wert meiner Meinung nach idealerweise dem Status-Wert des Aktors entsprechen. Ich will die Status-Items eigentlich auch gar nicht da drin haben, aber so lange das nicht so geht ist das ein notwendiges Übel. Und auch in der VISU gibt es ja nicht zwei Objekte für das Schalten und dem Status. Ich schalte mit dem gleichen Item von dem ich dann auch erwarte das es an ist.

Sag mir, wenn ich völlig falsch liege, aber mein Verständnis von konsistenten Werten basiert darauf, dass ich nicht nur einen Schaltvorgang auslöse, sondern die Status-Rückmeldung auch auswerte.

[Msinn]

mumpf

Ich halte das für einen Fehler! Natürlich müsste ein Item, dass auf eine GA hört, immer von einer Änderung des GA-Wertes betroffen sein, und nicht nur, wenn die GA von außen (Bus) kommt!

Ich glaube dass eibd/knxd das aktiv verhindert (als eine Art Echo-Sperre). Die müsste man im KNX Plugin umschiffen. Dass sich Callidomus da anders verhält, liegt vermutlich daran, dass Markus einen eigenen KNX Treiber geschrieben hat und nicht auf eibd/knxd aufsetzt.

Abstrakt gesehen müsste das für jedes Kommunikations-Plugin gelten: Wenn ich über das nw-Plugin mit einem Item auf eine IP:PORT schreibe und mit einem anderen Item auf die gleiche IP:PORT höre, sollte das andere Item das mitbekommen.

So verallgemeinert würde ich Dir nicht zustimmen. Meiner Meinung nach muss man schon schauen, ob das für das darüber liegende Protokoll welches ein Plugin implementiert auch sinn macht.

[mumpf]

Hi Martin,

Dass sich Callidomus da anders verhält, liegt vermutlich daran, dass Markus einen eigenen KNX Treiber geschrieben hat und nicht auf eibd/knxd aufsetzt.

soviel ich weiß (ohne jetzt nachgeschaut zu haben), macht Markus das im KNX-Plugin: Dieses weiß ja genau, welches Item auf welche GA hört. Wenn also eine GA verändert wird (egal ob durch KNX von außen oder durch ein Item von innen), wird deren Wert in alle Items geschrieben, die auf diese GA hören. Wie stark das KNX-Plugin und sein KNX-Stack verzahnt sind, kann ich allerdings nicht beurteilen.

So verallgemeinert würde ich Dir nicht zustimmen

Das ist schade. Aus Sicht der Item-Konsistenz sehe ich das nämlich als wichtig an, zumindest für bidirektional kommunizierende Plugins. Genau so wie das KNX-Plugin kann jedes Kommunikations-Plugin wissen, auf welches externe Objekt gehört/geschrieben wird. Und da mehrere Items über das gleiche Objekt kommunizieren können, sollten die Plugins dafür sorgen, dass es hier keine Inkonsistenzen geben kann.

Es gibt ja auch noch eine weitere Diskrepanz bei Kommunikation in shNG (und auch in callidomus): Bei KNX hat man darauf geachtet, dass es keine Schreib-Lese-Schleifen geben kann (wenn ein Wert vom Bus kommt und einen Itemwert ändert, wird der neue Wert nicht wieder auf den Bus geschickt - zumindest solange man kxn_send nutzt). Wenn man z.B. das network-Plugin benutzt, werden solche Schleifen-Aspekte gar nicht beachtet. Mir ist schon klar, dass der Grund in der seltenen Nutzung von anderen Kommunikations-Plugins ist, aber schade finde ich es trotzdem.

Cannon: Sorry für das OT, ich wollte nur Martin direkt antworten. Ich schreibe auch gleich noch was zu Deiner letzten Aussage

Gruß, Waldemar

[Msinn]

Hi Waldemar,

ich mache nochmal off Topic weiter (zum Abschluss , sonst sollten wir das per PN weiter vertiefen).

im KNX-Plugin: Dieses weiß ja genau, welches Item auf welche GA hört.

Ja, aus meiner Sicht wäre nur der saubere Weg auf die GA vom Bus zu hören, die leider nicht zurückgeliefert wird (Echosperre) und das vom Plugin wie jedes ander Telegram bearbeiten zu lassen. Der "Kurzschluss" direkt im Plugin ist für mich nur der zweitbeste Weg. Da nicht absehbar ist, dass sich das knxd Verhalten in Zukunft ändern wird, kann man darüber nachdenken das im Plugin zu lösen. Ich würde jedoch dafür plädieren (da dieses ein breaking-Change wäre) das über einen Parameter konfigurierbar zu machen.

Das ist schade.

Ich habe gerade ein Plugin in der Mache, wo Dein Ansatz des generellen Echos problematisch wäre. (Generelle Aussagen, sind durch ein einziges Gegenbeispiel so schön widerlegbar )

Mir ist schon klar, dass der Grund in der seltenen Nutzung von anderen Kommunikations-Plugins ist, aber schade finde ich es trotzdem.

Einen weiteren Grund sehe ich in den verschiedenen Autoren der Plugins. Wenn Du solche Inkonsistenzen siehst, schreib sie mir. Wir können dann sehen ob/wie wir das ändern können.

[thesing]

Eigentlich ist sogar der richtige Weg das im knx-Plugin zu lösen. Bei einem normalen Knx-Gerät funktioniert das so:
- KO 4 wird geschrieben ( Application Service Access Point ist also 4)
- über die Assoziantionstabelle wird ein TSAP ermittelt (Transport Service Access Point im Grunde ein Index für ein Array von Gruppenadresse)
- GA wird mit dem TSAP aus der Adresstabelle ermittelt, and diese GA wird ein Telegramm auf den Bus geschickt.
- über Assoziationstabelle werden mit dem TSAP alle ASAPs (also die KOs) ermittelt die den gleichen TSAP haben. Diese werden auch geupdatet.

Eigene Telegramme sieht ein Gerät natürlich auch, diese werden aber schon in der untersten Schicht verworfen.
Wer mag kann sich dass in der knx-Spezifikation 03_03_07 3.3.1 anschauen. Da dort auch mit ASAP und TSAP gearbeitet wird, hab ich die Begriffe hier auch verwendet.

Ich finde jedoch auch, dass es kein generelles Echo geben sollte. Das sollte dem entsprechenden Plugin überlassen bleiben. Bei meinem knx_ets-Plugin macht das z.B. das externe Python-Modul. Für shNG sieht es so aus, als ob es ein Echo geben würde.