Widget "Window and Shutter" neues Feature "Fensterkontakt invertieren"

[uelpenich]

Neues Feature "Fensterkontakt invertieren" zum Widget "Window and Shutter"

Im Widget "Window and Shutter" ist zur Zeit die Darstellung von Fenster offen <-> Fenster geschlossen fest an das Signal des Fensterkontaktes mit offen = true; geschlossen = false verbunden. Das ist die Arbeitsweise von vielen Nachrüst-Funk-Fenster Kontakten. Die Fensterkontakte aus dem Bereich Alarmanlagen arbeiten genau umgekehrt mit offen = false; geschlossen = true.

Meine Bitte: Erweitern des Widgets "Window and Shutter" mit der Möglichkeit, den Fensterblattsensor sowie den Griffsensor zu invertieren. (Bemerkung: beim Widget "Door" kann der Türkontakt invertiert werden)

möglicher Workaround 2: Invertieren des Fenster Signals beim Einlesen. Möchte ich nicht anwenden, da bei der Verwendung von MDX KNX Rolladen Aktoren mit Binäreingangen die erweiterten Funktionen (z.B. Schutz vor Aussperren) dann nicht mehr möglich sind.

[uelpenich]

Weitere Möglichkeit: true und false könnte man über eine JavaScript Funktion im Zusammenhang mit "Binding of objects" vertauschen. Das funtioniert bei dem Parameter "Fensterblatt-Sensor" nicht (wohl aber bei anderen Parametern, die eine Textausgabe zur Folge haben). Frage: kann man das Widget so erweitern, dass bei allen Parametern "Binding of objects" möglich ist?

[uelpenich]

Brauchbarer Workaround zum "Fensterkontakt invertieren" im Widget "Window and Shutter"

Ich habe für mich eine brauchbare Lösung gefunden, Fensterkontakte aus dem Bereich der Alarmanlagen mit der Arbeitsweise Fenster offen = false; Fenster geschlossen = true richtig mit dem Widget "Window and Shutter" zu visalisieren. Folgende Änderung habe ich an hqwidgets.js (version 1.1.7) im Verzeichnis /opt/iobroker/iobroker-data/files/vis/widgets/hqwidgets/js gemacht: Zeilen 1816 .. 1818 im Original: if ((slidePos == 1 || slidePos === true || slidePos === 'true' || slidePos === 'open' || slidePos === 'opened') && options.type) { div4 +=' hq-blind-blind4-opened-' + options.type; }

Zeilen 1816 .. 1818 abgeändert für Fenster geschlossen = true: if ((slidePos == 0 || slidePos === false || slidePos === 'false' || slidePos === 'open' || slidePos === 'opened') && options.type) { div4 +=' hq-blind-blind4-opened-' + options.type; }

Ich habe das System neu gebootet, um die Änderung wirksam zu machen.

[uelpenich]

Doch keine Lösung?

Kurze Zeit nach dem ich hqwidgets.js wie oben beschrieben geändert habe, wird das Programm wieder mit dem Original überschrieben. Was habe ich übersehen? Wer schreibt das Original zurück? Was muss ich anders machen? Danke für Eure Hinweise.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

[uelpenich]

Sie haben recht, die Invertierung eines Eingangssignals gehört in den Geräte- oder Alias Adapter. Leider ist der Gerätemanager noch nicht zusammenhängen dokumentiert.

[Basti17683]

Gibt es hier bereits etwas neues? Ich stehe aufgrund meiner Integration über KNX genau vor demselben Problem

[uelpenich]

Nein, nichts Neues. Siehe die beiden Posts vom 16. und 17.04.2022. Der Programmcode wird sehr unübersichtlich, wenn man jedes Signal in beiden Richtungen parametrieren können will. Weiterhin verschiebt sich die Bedeutung von offen / geschlossen im Zusammenhang mit gekippt / nicht gekippt.

=> ich habe den "linkeddevices" Adapter verwendet, um das offen/geschlossen Signal zu drehen. Auf meinen Workaround habe ich verzichtet, weil ich mich damit von der Weiterentwicklung des Widgets abkoppele.

[Basti17683]

Danke für deine schnelle Antwort. Ich bekomme immer mehr das Gefühl als ob dieses komplette Vis für die KNX Welt irgendwie nicht das richtige ist... Geht ja nicht nur um die Jalousien welche keine Shutter Stellungen anzeigen. Tunable White, RGBW usw wird alles nur durch kompliziertes umwandeln in zig Skripten möglich. Das kostet mir zu viel Zeit... Danke nochmal und einen schönen Tag noch

[uelpenich]

Wir sind immer noch im "Bananenstecker Zeitalter", wo die Signale mit einzeln gesteckten Kabeln von A nach B und B nach A transportiert werden. ioBroker und der KNX Adapter bieten schon den Vorteil, dass sie mit Zweipoligen Kabeln und Steckern das Steuersignal und die Rückmeldung zusammenfassen können. Über komplizertere Dinge wie Dimmer, RGBW, Heizkessel, . . ., wo mehrere Signalpaare von unterschiedlichen Typen zusammen gehören, wird noch nachgedacht und diskutiert. Da sind die Sprachassistenten schon weiter und definieren "Skills".

Es wird ein sauberes Ebenen Modell benötigt: Signalerfassung, Signalverarbeitung und Verknüpfung, Geräte Definitionen und Präsentation. Es kann nicht sein, dass die Signalverarbeitung und Verknüpfung in der Visualisierungsebene abgewickelt wird. Überall blickt die Hardware durch, für das ioBroker einmal entwickelt wurde.

. . . wird alles nur durch kompliziertes umwandeln in zig Skripten möglich . . . => ich bin weitgehend ohne Skripte ausgekommen. Sie erledigen die Signalverarbeitung, bilden aber keine Geräte ab. Damit wird es unübersichtlich. Etwas anderes sind Skripte für Zeit- und Ablaufsteuerungen. Meine Skripte fahren die Rolladen in Abhängigkeit von Sonnenauf- und -untergang, übertragen die 1wire Temperaturwerte ins KNX System und übertragen die KNX Taster Befehle über FHEM auf Baushaus Funksteckdosen (weil FHEM über SIGNALduino besser mit den unterschiedlichen Funkprotokollen zurecht kommt). Signalverarbeitung im Sinne von Umrechnungen mache ich über "linkeddevices". Schade dass linkeddevices jeweils nur ein Eingangssignal kann. Weitere Eingangssignale über die Bindings Syntax wären eine schöne Sache.

[uelpenich]

Das Problem hat sich erledigt mit der vis-2-beta. Der Wert des Griff Sensors lässt sich mit einem vorangestellten ! invertiren

[Basti17683]

Danke für die INfo! Werd gleich mal sehen wie ich die Beta Vis installiere und probier das aus. Danke :)