Einschaltautomatik mit Steinel True Präsenz

[n3de]

Dann bau das ganze Konstrukt halt einfach nochmal mit anderen Kanälen.

Der Steinel bietet nicht die Funktion mit der Einschaltautomatik und ich will, dass er das gleiche Licht schaltet. Ansonsten kann es ja passieren, dass ein PM schaltet und der andere später nochmal.

[gbglace]

Deswegen soll der Steinel auch nichts mit Einschaltautomatik machen, der taugt mit seiner Applikation einfach nur als Zuspieler für die Information hier ist jetzt wer. Alles andere machst halt in einem anderen freien PM-Kanal irgendeines BJ-Melders, egal wo der im Haus sitzt. Oder besser gleich sowas wie dem OpenKNX VPM/Logik-Modul. da haust einfach die Bewegungs und Raumhelligkeitswerte des Steinel rein und machst dann alles andere in der VPM Applikation.

[n3de]

OK, aber dann steuere ich ihn ja über das Slave Objekt des anderen PM und scheinbar schaltet der PM direkt über das Slave Objekt und berücksichtigt nicht die Einschaltautomatik. Ich würde daher davon ausgehen, dass der BJ hier einen Fehler hat, oder? Neben dem OpenKNX VPM, könnte ich das noch über mein NodeRED mache. Hatte aber gedacht, es geht auch direkt.

[gbglace]

Ist halt was speziell was Du da vorhast.

[willisurf]

Neben dem OpenKNX VPM, könnte ich das noch über mein NodeRED mache.

Dann würde ich auch gleich austesten, ob das Licht noch -zur Not manuell- an/aus geht, wenn NodeRed mal nicht läuft. Ich vermeide so etwas. NodeRed ist bei mir nach KNX-nativ und X1 wirklich nur die oberste Schicht und darin läuft nichts essenzielles.

Falls es nicht offensichtlich geworden ist, das war ein Plädoyer für KNX nativ, mit Bordmitteln oder OpenKNX VPM.

[FrankMaier]

Ich würde es so lösen:
grafik.png
Der GT schaltet einfach den Lichtaktor an/aus.
Der BJ PM ist gesperrt, wenn das Licht an geht. Über eine Logik, die nur 1 sendet. D.h. wenn das Licht aus geht, bleibt der PM gesperrt.
Der BJ PM wird durch den GT_lang entsperrt, da dieser eine 0 sendet. Wenn das Licht angeht, wird der PM wieder gesperrt.
Der Steinel TP ist am Slave Eingang des BJ. Der BJ reagiert nur auf den Slave Eingang, wenn er entsperrt ist.

Wenn du beim Betätigen der langen Taste auch noch das Licht ausschalten willst, dann könntest du von GA_lang auf eine Logik gehen, welche nur eine 0 sendet und dies GA dann mit dem Schaltaktor Eingang Schalten verknüpfst.

Vielleicht habe ich noch einen Denkfehler, ein Versuch wäre es wert.
(Edit: Der BJ braucht natürlich noch den Status vom Lichtaktor)

[n3de]

Dann würde ich auch gleich austesten, ob das Licht noch -zur Not manuell- an/aus geht, wenn NodeRed mal nicht läuft. Ich vermeide so etwas. NodeRed ist bei mir nach KNX-nativ und X1 wirklich nur die oberste Schicht und darin läuft nichts essenzielles.

Falls es nicht offensichtlich geworden ist, das war ein Plädoyer für KNX nativ, mit Bordmitteln oder OpenKNX VPM.

Ja, die Basisfunktionen decke ich direkt mit KNX ab. Soweit es geht auch Szenarien/Automatik. Nur wenn etwas mit KNX nicht geht, oder weitere Aktoren einbezieht, dann binde ich NodeRed mit ein.

Ich würde es so lösen:
grafik.png
Der GT schaltet einfach den Lichtaktor an/aus.
Der BJ PM ist gesperrt, wenn das Licht an geht. Über eine Logik, die nur 1 sendet. D.h. wenn das Licht aus geht, bleibt der PM gesperrt.
Der BJ PM wird durch den GT_lang entsperrt, da dieser eine 0 sendet. Wenn das Licht angeht, wird der PM wieder gesperrt.
Der Steinel TP ist am Slave Eingang des BJ. Der BJ reagiert nur auf den Slave Eingang, wenn er entsperrt ist.

Wenn du beim Betätigen der langen Taste auch noch das Licht ausschalten willst, dann könntest du von GA_lang auf eine Logik gehen, welche nur eine 0 sendet und dies GA dann mit dem Schaltaktor Eingang Schalten verknüpfst.

Vielleicht habe ich noch einen Denkfehler, ein Versuch wäre es wert.
(Edit: Der BJ braucht natürlich noch den Status vom Lichtaktor)

Hm, ich würde den Vorschlag gerne ausprobieren, aber ich sehe noch den Unterschied zur aktuellen Lösung nicht. Das Problem ist das hier:

"Der Steinel TP ist am Slave Eingang des BJ. Der BJ reagiert nur auf den Slave Eingang, wenn er entsperrt ist."

Das Funktioniert ja nicht. Obwohl der BJ PM gesperrt ist (Einschaltautomatik mit Freigabe über den externen Taster), schaltet er über den Slaveeingang.

[FrankMaier]

Das Funktioniert ja nicht. Obwohl der BJ PM gesperrt ist (Einschaltautomatik mit Freigabe über den externen Taster), schaltet er über den Slaveeingang.

Aber du sperrst deinen PM doch gar nicht. Du hast sogar einen Screenshot gepostet in welchem du eindeutig das Freigabeobjekt nicht aktiviert hast. Dein PM ist "gesperrt" da er vermutlich keine Ahnung vom Status hat und denkt das Licht ist an und schaltet es deswegen nicht nochmal an. Du nutzt deinen PM in meinen Augen schlicht falsch. Es macht in meinen AUgen auch schon gar keinen Sinn zwei verschiedene Gruppenadressen für dieselbe Funktion zu nutzen. Du hast ein GA für Einschalten und eine GA für Ausschalten. Das macht man mit einer einzigen GA und man teilt dem PM den Status des Aktors mit. Man sperrt den PM mit dem Freigabeobjekt, ...
Und wenn man den PM dann so sperrt, wie im Handbuch beschrieben, dann verhält sich der Slave Eingang auch so wie im Handbuch beschrieben.

[TabSel]

>>ein Plädoyer für KNX nativ, mit Bordmitteln oder
>>OpenKNX VPM.

Gestern hat sich mein Masifi Encoean Gateway aufgehängt. Die Logiken darauf waren weg. Rollo-Steuerung war plötzlich „wild“…
ne ausgefuchste Logik für die WC-Lichtsteuerung auf die ich echt stolz war *lach* funktioniert grad - nach Tagen - nicht mehr, totales Licht-Chaos im WC… alles KNX nativ. Kein Eibpc, kein nodered…

Ich bin ja absolut Deiner Meinung, aber „besser“ wird’s dadurch nicht *g*

[willisurf]

Gestern hat sich mein Masifi Encoean Gateway aufgehängt. Die Logiken darauf waren weg.

Mmh, ist mir in über einem Jahr kontinuierlichem Betrieb mit zwei ENO GW noch nie vorgekommen.
Aber natürlich setzt KNX nativ eine stabile Basis voraus, damit der Plan aufgeht.
Und um Missverständnisse zu vermeiden kurz ergänzt, aus meiner Sicht (mit über einem Jahr Erfahrung mit in Summe mehr als 7 Geräten im Dauereinsatz) sind die DIY Geräte mit der Software von mumpf genau solch eine stabile Basis.
Schön das Waldemar sich das anschaut.

[mumpf]

Gestern hat sich mein Masifi Encoean Gateway aufgehängt.

Das sollten wir genauer untersuchen. Ich bin eigentlich stolz darauf, dass die Firmware sehr robust läuft und sich nicht aufhängt.

Die Logiken darauf waren weg.

Die Aussage verstehe ich nicht. Selbst wenn sich da was aufhängt, ist nach einem Reset nichts "weg"?

ne ausgefuchste Logik für die WC-Lichtsteuerung auf die ich echt stolz war *lach* funktioniert grad - nach Tagen - nicht mehr, totales Licht-Chaos im WC…

Bei knx-Geräten hast Du doch selbst in so einem Fall den Vorteil, dass Du einfach nur das Gerät resetten und neu programmieren musst. Das geht auch genau so beim ENOCEAN-Gateway.

Ich verwende selber kein Enocean, deswegen nutze ich das Gateway nicht produktiv. Aber zumindest die anderen Module, die ich verwende, laufen robust. Robust bedeutet auch, dass falsche Logiken auch falsch laufen . Ich weiß nicht, was Du da gemacht hast, aber ich biete an, das weiter zu untersuchen. Wie immer ist es software, die Fehler enthalten kann. Aber lass uns das in dem entsprechenden ENO-Thread machen.

Gruß, Waldemar

P.S.: willisurf und ich testen gerade das nächste Release vom ENO (1.6.), das kommt voraussichtlich kommende Woche raus.

[TabSel]

bitte nicht in den falschen Hals bekommen, das Teil ist super!!!
die logiken waren auch nicht weg, sondern wurden nicht mehr ausgeführt wodurch Zeugs nicht mehr so lief wie gedacht, Rollo-Chaos als Resultat. Nachdem ich den Bis resettete ging alles wieder!

was die Urssche war weiß ich nicht, es lies sich plötzlich nicht mehr programmieren, war nicht mehr erreichbar unter der PA. Seltsam. Busreset half.

trotzdem stehst erst mal da wie der Ochs vorm Berg *lach*

[mumpf]

Neee, ich hab das nicht in den falschen Hals bekommen.

Ich meine das aber so, wie ich das schreibe: Ich bin stark daran interessiert, dass die Sachen dauerhaft laufen können. Eben der "gute Geist" im Hintergrund.
Nicht erreichbar über den Bus bedeutet hänger intern. Die einzigen mir bisher bekannten Probleme für komplette Hänger sind Speicherprobleme. Eigentlich ist beim ENO aber recht viel Speicher frei (ca. 5k, das ist mehr als genug).

Folgender Vorschlag: In der kommenden ENO-Version wird es den Diagnosebefehl "m" (wie Memory) geben, mit dem kann man sich den momentan noch freien Speicher über das Diagnoseobjekt ausgeben lassen. Du könntest dann - falls Du die Möglichkeit hast - diese Ausgabe aufzeichnen lassen und den Langzeitverlauf schauen. Falls das über Zeit weniger wird (als Tendenz, nicht kurzfristiger Speicherbedarf), wäre das ein guter Indikator, wo ich noch schauen muss.
Sonst kann man auch ne Zeit lang täglich manuell den Befehl aufrufen und die Werte aufschreiben, dann bekommt man auch ein Gefühl dafür.

Dann sehen wir weiter.

Und jetzt genug OT, weiteres gerne über Issue auf Github oder den ENO-Thread hier im Forum.

Gruß, Waldemar