Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Hohenbostler]

Sorry aber so baue ich mir doch einen loop.

Weil beide States gegenseitig sich triggern und ausführen. usw usw. Sicher dass das so geht ?

[Asgothian]

@Hohenbostler sagte in Zigbee Lichttaster parallel halten.:

Sorry aber so baue ich mir doch einen loop.

Weil beide States gegenseitig sich triggern und ausführen. usw usw. Sicher dass das so geht ?

Ganz Sicher. Das liegt an der Kombination von was changed und ack is update. Wenn du einen der States via Skript schaltest dann wird dieser Trigger nicht aktiv, da die Änderung mit ack = false, sprich control rein kommt

A.

[Hohenbostler]

Sorry meins ist auf deutsch. Ist das dann so richtig ?

[Asgothian]

Das ist so richtig.

[Hohenbostler]

Sprich um das nochmal für mich verständlich zu machen. Drücke ich einen der Taster Physisch wird ack = true mitgesendet. Wenn aber ein Schalter durch zB das BLockly geschaltet wird kommt ein ack= false mit ?

Was genau ist denn wenn ich einen der Schalter nicht Physisch drücke sondern per Visualisierung ?

[Asgothian]

@Hohenbostler sagte in Zigbee Lichttaster parallel halten.:

Sprich um das nochmal für mich verständlich zu machen. Drücke ich einen der Taster Physisch wird ack = true mitgesendet. Wenn aber ein Schalter durch zB das BLockly geschaltet wird kommt ein ack= false mit ?

Wenn du am Schalter direkt drückst ändert sich der Status der Hardware, und dieser wird als aktualiserung mit ack=true an den ioBroker gemeldet.

Wenn du den Schalter über den Datenpunkt steuerst musst du das als steuerung mit ack=false senden. Die Hardware quittiert das dann mit einer aktualisierung mit ack=true (aber dann ist der Wert schon gesetzt, sprich, dann hast du keine Änderung.)

Was genau ist denn wenn ich einen der Schalter nicht Physisch drücke sondern per Visualisierung ?

Das wird komplexer. Wenn du das auch abfangen willst, dann geht das etwas anders:

Über die Abfrage des 'origin' kannst du alle Änderungen heraus nehmen die nicht von dieser einen Quelle (deiner Vis) kommen.

Was ich Dir nicht sagen kann ist was in dem roten Rahmen stehen muss - ich hab keine Visualisierung, daher weiss ich nicht mit welchem origin die Änderungen via Visualisierung herein kommen.

A.

[Siggi0904]

Kannst du aber auch mit binding machen und die Datenpunkte aneinander binden.
Habe ich so gemacht, um eine Wechselschaltung nachzubauen.

[paul53]

@Hohenbostler sagte: Schalter nicht Physisch drücke sondern per Visualisierung ?

So verhindert man eine Trigger-Schleife unabhängig davon, wie ein Schalter betätigt wird:

EDIT: Außerdem werden weniger Ressourcen verbraucht, da in jeder Subscription nur ein Block "steuere" enthalten ist.

[Hohenbostler]

@Siggi0904 habe ich damals schon Probleme mit gehabt. Kannst du mir zeigen wie du es gelöst hast ?

[Siggi0904]

[Hohenbostler]

@Siggi0904 wenn ich das richtig sehe bindest du die Zustände gegenseitig ?

[Siggi0904]

Ja, der eine Schalter sagt dem anderen Schalter Bescheid, wenn sich was ändert.

[Homoran]

@Hohenbostler sagte in Zigbee Lichttaster parallel halten.:

bindest du die Zustände gegenseitig ?

wie soll das denn sonst funktionieren?
du willst doch jeweils den anderen steuern, egal wo du etwas änderst

[paul53]

@Siggi0904 sagte: der eine Schalter sagt dem anderen Schalter Bescheid, wenn sich was ändert.

Das kann unter bestimmten Umständen (Laufzeiteffekte) zu einer Trigger-Endlosschleife führen. Mein Vorschlag ist nahezu identisch, was den resultierenden Javascript-Code betrifft, allerdings mit dem Unterschied, dass durch die zusätzliche Prüfung eine Trigger-Schleife mit Sicherheit verhindert wird.

on({ id: 'alias.0.Flur.Licht.Switch1', change: 'ne' }, (obj) => {
  if(obj.state.c != scriptName) setState('alias.0.Flur.Licht.Switch2', obj.state.val);
});
on({ id: 'alias.0.Flur.Licht.Switch2', change: 'ne' }, (obj) => {
  if(obj.state.c != scriptName) setState('alias.0.Flur.Licht.Switch1', obj.state.val);
});