Buttons und KNX
-
Kann man also sagen, dass ioBroker für KNX nicht wirklich geeignet ist oder hat sich hier ein anderer Ablauf bewährt um die Visu entspr. zu erstellen? `
Kann man so pauschal nicht sagen. Die häufig genutzten KNX Aktoren arbeiten mit getrennten Objekten für STATUS und AKTION, da kommt der von Dir genannte Fall auf und dann muss mit dem aktuellen Stand der Widgets der Weg über der Scripts gegangen werden. Das mag bei anderen KNX Aktoren nicht nötig sein, bei MDT ist das so. Es betrifft hier vor allem Dimmer und Heizung, bei Schalter geht's auch direkt mit nur einem Objekt.
VG
- Breisgauer
-
dass ioBroker für KNX nicht wirklich geeignet ist `
Das hängt am KNX-Adapter, der Kommando und Status zusammenführen müsste. Dass dies automatisch erfolgen kann, setzt voraus, dass Kommando und zugehöriger Status eindeutig zuzuordnen sind. Liefert KNX die nötigen Informationen ?Was mir auch aufgefallen ist: KNX liefert offenbar binäre Werte (0 / 1), die Javascript / ioBroker nicht kennt. Diese Werte müssten in boolsche Werte (false / true) gewandelt werden und umgekehrt bei Kommandos. Eine solche Datenpunktdefinition geht gar nicht:
common: { type: "boolean", min: 0, max: 1 } -
Also ich werde das mal testen mit dem Script, aber dann kommt ioBroker für mich eigentlich (noch) nicht in Frage. Das ist mir Zuviel Arbeit. Ich hab ausschließlich MDT und kenne KNX eigentlich auch nur so, dass es Status und Aktion gibt - und zwar getrennt.
Macht für mich als SPS-Programmierer auch Sinn - da wird in der Visu auch zwischen Aktionen und Animationen unterschieden
Bei dieser Trennung könnte man dann auch sicher einfach umsetzen, dass eine Animation auch bei unter 100% Dimmwert (wenn man jetzt mal einen Dimmer als Beispiel nimmt) aktiviert wird.
Für mich sieht das Ganze halt so aus, dass die Entwicklung hier wohl eher in Richtung Homematic oÄ ging und KNX evt. noch nicht lange unterstützt wird bzw. so wenig genutzt wird, dass eine Weiterentwicklung / Optimierung noch nicht passiert ist oder evt. auch nicht mehr passieren wird. Das wäre natürlich interessant zu wissen … dh, ob das Ganze hier für die Zukunft evt. ne Option ist, wenn man "direkt" mit KNX arbeiten kann - einschl. Visu.
EDIT:
Hier mal ne Definition, so wie IOBroker sie geladen hat. Bei "role" steht manchmal auch "level" oder "value" oder eben "switch". Manchmal ist lesen erlaubt, manchmal schreiben erlaubt, manchmal beides. Blick da gerade nich ganz durch
"common": { "name": "EG: Doppelgarage Deckenlicht schalten", "type": "boolean", "role": "switch", "min": 0, "max": 1, "read": true, "write": true } -
Kann man also sagen, dass ioBroker für KNX nicht wirklich geeignet ist oder hat sich hier ein anderer Ablauf bewährt um die Visu entspr. zu erstellen? `
Kann man so pauschal nicht sagen. Die häufig genutzten KNX Aktoren arbeiten mit getrennten Objekten für STATUS und AKTION, da kommt der von Dir genannte Fall auf und dann muss mit dem aktuellen Stand der Widgets der Weg über der Scripts gegangen werden. Das mag bei anderen KNX Aktoren nicht nötig sein, bei MDT ist das so. Es betrifft hier vor allem Dimmer und Heizung, bei Schalter geht's auch direkt mit nur einem Objekt.
VG
- Breisgauer `
Hier muss ich nochmal nachhaken: Wie genau gehts denn mit einem Objekt? Egal was ich mit dem Button "verbinde" (also egal ob Status oder "Befehl"), es wird nur gelesen statt geschrieben. Glaub da hab ich mal was zu gefunden, muss mal schaun wo das war
EDIT: Hab gesehen, dass bei dem Testobjekt (Garage) nur Lesen erlaubt war. Muss mal herausfinden, wieso und wie ich das ändern kann - am besten als Stapelverarbeitung
-
Hallo @all,
ich finde die Idee mit dem Script echt umständlich.
Leichter wäre es, mal kurz hier https://github.com/ioBroker/ioBroker.knx vorbeizuschauen.
VG
chefkoch009
-
Meine persönliche Meinung dazu währe das die am besten im Adapter selber umgesetzt werden könnte.
Alle anderen mir bekannten systeme (homematic, z-wave, zigbee usw) haven niet einen state welchen status und schaltung wiedergeben.
Ergo, meine Logic, KNX ist hier ein Sonderfall gegenüber den anderen Systemen.
Wie ich bereits vorher Mal erwähnte könnte man auch das Script einfacher gestalten um nicht für jedes Gerät/object ein object im Script ein zu fügen. Eine Lösung im Adapter währe aber User freundlicher.
Sent from my iPhone using Tapatalk
-
ich finde die Idee mit dem Script echt umständlich.
Leichter wäre es, mal kurz hier https://github.com/ioBroker/ioBroker.knx vorbeizuschauen. `
Hi,
ich sehe noch keine Option an einem Skript bzw. einer Implementation in einem Widget vorbei.
Beispiel MDT Dimmer, der pro Kanal u.a. 5 GAs/KOs für das Schalten und Dimmen hat:
-
#1 Schalten AKTION: Schaltet EIN/AUS
-
#2 Schalten STATUS: Gibt den Schaltstatus auf dem KNX Bus aus.
-
#3 Dimmen ABSOLUT: Erhöht/verringert den Dimmwert
-
#4 Dimmen RELATIV: Setzt einen Dimmwert
-
#5 Dimmen STATUS: Gibt den aktuellen/geänderten Dimmwert auf dem KNX Bus aus
Wird der Dimmwert über #3 oder #4 geändert, wird der aktualisierte Dimmwert über #5 auf dem Bus ausgegeben. Wird ein Dimmwert auf 0% gesetzt, sendet der Aktor auch ein aktualisierten Schaltstatus über #2. Wird der Dimmwert von 0% auf >0% gesetzt, dann wird ebenfalls der aktualisierte Schaltstatus über #2 kommuniziert.
Wird der Dimmer ein- oder ausgeschalten, wird der Schaltstatus über #2 über den Bus gemeldet und der aktuelle Dimmwert über #5
Ich wüsste nicht, wie der KNX Adapter erkennen will, auf welche Aktionsobjekte ein Statusobjekt wie einwirken soll.
chefkoch009 leistet mit seinem KNX adapter schon Enormes, kommt hier aber langsam an Grenzen, was über die Informationen in einem KNX Projekt und Namenskonventionen bei der Vergabe von Gruppenadressen möglich und zumutbar ist.
Aus meiner Sicht ist eine Zusammenfassung von STATUS und Aktionsobjekten keine Aufgabe die der KNX Adapters automatisch bieten kann. Dafür sind die Implementierungen der KNX Aktoren zu vielfältig, unberechenbar und somit ist das Ergebnis zu fehleranfällig. Eine Anwender-gestützte Verknüpfung von STATUS- und AKTIONs-Objekten nach Import eines KNX Projektes halte ich für robuster.
Was auch helfen würde: Widgets die getrennte STATUS und AKTIONs-Objekte bieten wobei ein STATUS-Objekt optional sein, damit diese Widgets universal einsetzbar bleiben.
Bis dahin hilft das Skripting, wie es in "https://forum.iobroker.net/viewtopic.php?f=30&t=15129&p=158182" besprochen wurde. Das dort gezeigte Skript kann ggf. noch vereinfacht werden, wie es @Dutchman erwähnt hat.
- Breisgauer
-
-
Aus meiner Sicht ist eine Zusammenfassung von STATUS und Aktionsobjekten keine Aufgabe die der KNX Adapters automatisch bieten kann. Dafür sind die Implementierungen der KNX Aktoren zu vielfältig, unberechenbar und somit ist das Ergebnis zu fehleranfällig. Eine Anwender-gestützte Verknüpfung von STATUS- und AKTIONs-Objekten nach Import eines KNX Projektes halte ich für robuster.
Was auch helfen würde: Widgets die getrennte STATUS und AKTIONs-Objekte bieten wobei ein STATUS-Objekt optional sein, damit diese Widgets universal einsetzbar bleiben. `
Das ist absolut ein argument es nicht im adapter loesen zu wollen, muss mir doch mal KNX geraete kaufen und anfangen damit rum zu spielen
Das mit den objecten ist so eine sache, klar es koennte bestimmt geaendert werden (wer wird das machen) und wird es dadurch nicht zu komplex fuer benutzer der "anderen" hersteller marken.
-
Ich glaube da is es echt schwierig, bei der bestehenden Struktur von IOBroker, Visu und KNX Adapter das korrekt anzupassen.
Eigentlich bräuchte man andere Widgets in der Visu, denen man mehrere, zum Teil optionale, Gruppenadressen zuweisen kann (kann man widgets selbst erstelen?!). Bei nem Schalter einmal den Schaltbefehl und einmal die Rückmeldung. Beim Dimmer - je nachdem - zumindest Dimmwert (senden) und Status-Dimmwert sowie ggf. die Schaltbefehl-Rückmeldung (Dimmwert >0% = "1") zwecks Animation, damit das Dimm-Widget nicht selbst auf >0% vergleichen muss.
Solange aber bereits im KNX-Adapter bzw in den Objekten eine Verknüpfung notwendig ist, müsste man diese zumindest ergänzend auch per Hand vornehmen können. Das spart vielleicht auch Arbeit?! Bei EDOMI z.B. wird einfach die Struktur eingelesen und ich selbst wähle bei jedem Objekt - egal ob Logik oder Visu - selbst aus, welche GA nun den Status enthält und welche den Wert erhalten soll.
Mit der Komplexität: Ich bin zwar nich auf den Kopf gefallen, hab aber SEHR wenig Zeit herumzuexperimentieren… da finde ich derzeit, dass man ioBroker mit KNX eigentlich nicht nutzen kann. Die Wahrscheinlichkeit, dass man da zufällig die richtigen Namen in der ETS vergeben hat is nich sehr hoch meiner Ansicht nach. Das nachträgliche Ändern sehr arbeitsintensiv (wenn überhaupt möglich?!) und dies wird sicher bei erneutem Import überschrieben. Wenn ich dann noch an die irgendwie unterschiedlichen "role"-Werte sowie das ebenfalls zufällig vergeben wirkende flag für "read" und "write" denke, ist es nochmal viel mehr an Arbeit um das korrekt einzupflegen.
Das liegt evt auch an der ETS - aber ich weiß nich warum und da es bei EDOMI funktioniert, müsste die Exportdatei eigentl korrekt sein
Das darf jetzt auch niemand falsch verstehen - ich bin noch nich so sehr "in" der Sache io.Broker. Die Struktur und Absichten sind evt ganz andere als dass man den Anspruch erheben könnte, es müsse (einfacher / besser / ...) mit KNX funktionieren
-
Hallo zusammen,
ich bin ganz neuer User von ioBroker und evaluiere grade die Software.
Aktuell automatisiere ich grade mein Haus mit KNX und node-red.
Ich habe ebenfalls eine lange Zeitspanne verbracht, und es noch immer nicht geschafft, mein Deckenlicht im Büro per ioBroker VIS zu steuern.
Ich würde die optionale Status-ID in den Widgets ebenfalls befürworten.
Alternativ wäre eine UI für die Erstellung von eigenen Datenpunkten aus KNX Addressen denkbar, ohne jedesmal noch extra js code dazu programmieren zu müssen.
