UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Thorsten Missenberger]

@Garfonso

Er Import mir die knxproj unter 1.0.20 jedoch legt er die "hörende" Adresse nicht an.

Habe mir jetzt eine DemoProjekt angelegt.

4 Gruppenadressen
Beleuchtung 1
Beleuchtung 1 RM
Beleuchtung 2
Beleuchtung 2 RM

das auf einen Autor verknüpft.

Nicht mal das kann ich unter 1.0.3x importieren.

Immer die gleiche Fehlermeldung:
https://github.com/ioBroker/ioBroker.knx/issues/80

[Garfonso]

@Thorsten-Missenberger
Ja, den gleichen Fehler hatte ich mit der letzten oder vorletzten Version auch... ich fürchte da ist in irgendeinem Zweig wirklich ein doofer Bug... :-(

[Schrubbel]

Das Problem mit dem ewig laufenden blauen Balken habe ich jetzt auch.
Es gab ja die Tage das ETS 5.7.3 Update, kann es daher kommen?
Vorher war bei mir alles ohne Probleme und beim KNX Adapter gab es ja auch kein Update.

[Thorsten Missenberger]

@Schrubbel 5.7.3 hatte ich mal kurz in einer VM und hat bei mir auch nicht funktioniert.

Bin jetzt einen anderen Weg gegangen. Ist zwar mit ein wenig aufwand verbunden.

Bringe die KNX Über NodeRed rein und verlinke auf ioBroker-Objekte.
Hat aber den Vorteil das ich auch nur die Objekte habe die ich wirklich zum Zeitpunkt der Implementierung habe.

Bis jetzt geht es und ich brauch nicht immer mit der knxproj rumspielen. Da ja ETS bekanntlich immer wieder alles über den Haufen wirft.

Vielleicht stellt Chefkoch irgendwann den Import um in Form einer Excel oder des CSV Export aus der ETS.

[sourex]

Hi.
Als erstes ein Danke für den Adapter !

Da ich Ihn nicht wirklich zum laufen bekommen mit den Statusadressen aber nun zur Frage.
In openHAB ist es ja möglich die RM alle manuell zuzuweisen was ich auch gemacht habe.
Kann ich da nicht einfach über den openHAB Adapter alle Datenpunkte nutzen ? Würde es da mit dem RM nicht besser gehen ?? Hätte es Nachteile über diesen Umweg ?

Guten Rutsch !!

[Garfonso]

@sourex
Das geht sicherlich. Der einzige Nachteil ist halt höhere Komplexität, weil du openHAB dann noch laufen haben musst.

[sourex]

Wie ich nun bemerkt habe gehts nicht wirklich weil man in den Widgets ja garkeine RM Datenpunkte angeben kann.
Dann werde ich wohl IO nur für die VIS benutzen können, was ich schade finde.

[Garfonso]

@sourex
Für vis kannst du zur Not auch mit einem Javascript arbeiten. Wobei ich da jetzt nicht ganz verstanden habe, wo der Vorteil von openHAB ist, wenn du immer noch Schalten und RM als einzelne Datenpunkte hast? Der Trick beim knx Adapter ist ja, dass wenn die Zuordnung funktioniert, am Ende nur noch der Schalt-Datenpunkt genutzt werden muss und der dann z.B. in Vis eingetragen werden kann, weil da der Status vom RM auch reingeschrieben wird.

[sourex]

Der Vorteil von OpenHAB ist für mich das manuelle anlegen der RM. Das liegt für mich ganz einfach daran das ich es im IO einfach nicht hinbekomme :(.
Aber generell ist es ja schon suboptimal das man alle Namen in der ETS anpassen muss um es möglich zu machen. Wie die meißten Anfänger habe ich mich bei dem GAs am Eibmeier gehalten und da passt es natürlich garnicht. Kann mir aber auch nicht vorstellen das ein Könner die GAs so nennt wie der Adapter das wünscht.
Warum nicht einfach ein manuelles zuordnen der RMs wie auch in der ETS ?

[Garfonso]

@sourex
Das manuelle Zuordnen steht schon lange auf der Liste. Chefkoch hat es bisher nicht geschafft es umzusetzen.

Wobei eine manuelle Zuordnung schon möglich ist, wenn man im Raw-Teil der Objekte rumeditiert. Das ist relativ mühsam, geht aber auch.

Admin -> Objekte, da ein KNX Objekt ansteuern, ganz rechts auf den "Stift" klicken zum editieren des Objekts, dann sollte das folgende Fenster kommen, da dann auf den Tab "Raw" gehen. Das sieht dann ca. wie hier aus:

Wenn die Zuordnung geklappt hat, sieht es so aus. Ansonsten kann man die manuell machen. "addressRefId" ist die Id einer GA. Bei der Schalt-GA muss dann unter "statusGARefId" die addressRefId der RM-GA stehen. Und bei der RM-GA muss unter "actGARefId" die addressRefId der Schalt-GA stehen. Man muss also 3 mal editieren pro Zuordnung:

• Id der Schalt-GA kopieren
• Bei RM-GA einfügen, Id der RM-GA kopieren
• Bei Schalt-GA einfügen

Wenn man die Zuordnung so gemacht hat dann nochmal den KNX Adapter neustarten, damit der das mitbekommt und dann geht es auch. Das Problem dabei ist halt, dass man dann die Objekte nicht löschen und neu einfügen lassen sollte.. Insofern war es für mich irgendwann einfacher im ETS einfach die GAs alle umzubenennen. Denn für das KNX System ist der Name ja irrelevant. Die Aufteilung in Gruppen und Mittelgruppen ist auch nicht wichtig, nur halt der identische Name + Status (oder RM geht wohl auch, mittlerweile).

[ecki945]

@Garfonso Gehe ich richtig in der Annahme, dass die manuellen Zuordnung in deinem obigen Beispiel auch so für die Dimmwerte bzw. Rückmeldedimmwerte gilt?

[Garfonso]

@ecki945
Das gilt für alles.

Im Grunde macht man halt das, was der Adapter automatisch machen würde selber. Der weiß nach dem Neustart nicht, dass nicht der Adapter das eingefüllt hat, sondern der Nutzer manuell und das macht für den keinen Unterschied. Da kann man dem alles unterjubeln, was man will. :-)

[fuchs1978]

Ich habe meine Installation Mal auf den aktuellen Stand gebracht und somit auch den KNX Adapter auf die Version 36 gebracht. Leider verbindet sich der Adapter nicht. Ich habe dann probiert, welche noch funktioniert. Die Version 20 verbindet sich sofort ohne Probleme, die Version 30 bleibt gelb. Mit welchen Daten kann ich beim debug helfen?

[fuchs1978]

Was ist eigentlich der Vorteil wenn ich die Status Adresse korrekt zuordne?

[killroy2]

Ich vermeide mittlerweile das Suffix Status zu verwenden da es mir viele Probleme bereitet hat.
Den Status wollte ich über eine Logikfunktion berechnen. Der Import bringt addressRefId und actGARefId zusammen.
Sobald das KNX Objekt empfangen wird schreibt er automatisch das Status Objekt mit dem Wert auf den Bus. Warum er das macht ist mir rätselhaft.

von IOBroker generiertes Datum mit Status am Ende vom Namen:
{
"_id": "knx.0.Objekt_Status",
"type": "state",
"common": {
"type": "boolean",
"read": false,
"write": true,
"role": "value",
"min": false,
"max": true
},
"native": {
"dpt": "DPT1.001",
"address": "8/0/5",
"addressRefId": "P-03DA-0_GA-818",
"statusGARefId": "",
"actGARefId": "P-03DA-0_GA-772"
},

KNX Input:
{
"_id": "knx.0.Objekt",
"type": "state",
"common": {
"type": "boolean",
"read": true,
"write": false,
"role": "value",
"min": false,
"max": true
},
"native": {
"dpt": "DPT1.001",
"address": "8/3/0",
"addressRefId": "P-03DA-0_GA-772",
"statusGARefId": "P-03DA-0_GA-818",
"actGARefId": ""

[sourex]

Wenn man die Zuordnung so gemacht hat dann nochmal den KNX Adapter neustarten, damit der das mitbekommt und dann geht es auch. Das Problem dabei ist halt, dass man dann die Objekte nicht löschen und neu einfügen lassen sollte.. Insofern war es für mich irgendwann einfacher im ETS einfach die GAs alle umzubenennen. Denn für das KNX System ist der Name ja irrelevant. Die Aufteilung in Gruppen und Mittelgruppen ist auch nicht wichtig, nur halt der identische Name + Status (oder RM geht wohl auch, mittlerweile).

Danke schon mal für die ausführliche Beschreibung. Wie ich schon sagte ist das manuelle ändern nicht gerade mein Ding, da das doch schon ziemlich aufwendig ist und halt überschrieben wird falls ich es mal neu einlese. Versuche ich es also nochmal mit der Änderung der GA. Da es ja anscheinend bei dir erfolgreich war würde ich dich dazu noch mal befragen, da ich es anscheinend nicht richtig verstanden habe. So habe ich es gemacht aktuell:

Was ist der Fehler ? Ist es eigentlich nötig gewesen jede einzelne GA umzubenennen oder hätten die Mittelgruppen gereicht ? Muss ich anschließend wirklich alle Objekte (zuvor den KNX Adapter) entfernen und dann wieder neu einzulesen ??

Vielen Dank

[Hansi1234]

Guten Morgen liebe Broker Freunde.
Hat von euch auch jemand das Problem, dass die Lamellenstellung ca. erst eine Minute später reagiert? Auf/Ab reagiert sofort, die Stellung nicht.

MFG
Hansi

[Garfonso]

@sourex said in Test Adapter KNX v1.0.x:

Was ist der Fehler ?

Was geht denn nicht? ;-)
Ich kann auf deinem Bild die Namen der Schalt GAs nicht sehen... ich würde aber vermuten, dass der Adapter nicht mag, dass nach dem RM noch etwas kommt und daher die Zuordnung nicht stimmt.

Bei mir sieht es so aus:

Wie du siehst sind die Namen der GAs zu 100% identisch (meist habe ich sogar mit copy & paste gearbeitet) nur mit einem "Status" angehängt. Da müsste wohl mittlerweile auch "RM" gehen.

Ist es eigentlich nötig gewesen jede einzelne GA umzubenennen oder hätten die Mittelgruppen gereicht ?

Meine Erfahrung ist, dass der Name der Mittelgruppen egal ist und nur der Name der GAs zählt. Also ja, jede GA muss umbenannt werden.

Muss ich anschließend wirklich alle Objekte (zuvor den KNX Adapter) entfernen und dann wieder neu einzulesen ??

Das würde ich dringend empfehlen. Die ID vom Objekt wird aus dem Namen der GA generiert. Alte Objekte werden dabei vom Adapter nicht gelöscht (was ich auch eher suboptimal finde, könnte er eigentlich machen. Naja. Feature Request)... Daher, wenn du alle GAs umbenennst, dann hast du hinterher doppelt so viele Objekte bei KNX und nur 50% davon gehen, der Rest macht nix... das ist keine sinnvolle Situation.
Achja, ich würde dringend die Nutzung der neuen Alias Funktion oder eigener JS Scripte empfehlen für den KNX Adapter... und dann nur die Alias-Objekte in Skripten, Vis oder Räumen/Funktionen/Typen usw. aufräumen für die Geräteerkennung. Alles andere macht irgendwie keinen Spaß...
Mit einem eigenen JS Script könnte man auch die Zuordnung manuell lösen. Das hatte ich selber auch eine Zeit lang gemacht, aber dann doch irgendwann die ~700 GAs umbenannt nach und nach.

[Garfonso]

@fuchs1978 said in Test Adapter KNX v1.0.x:

Was ist eigentlich der Vorteil wenn ich die Status Adresse korrekt zuordne?

Das sich die Objekte dann so verhalten, wie der ioBroker es erwartet... bei KNX ist es ja im Grunde so, dass du auf der einen GA einen Befehl sendest und auf der Status (oder Rückmeldung) GA kommt der Status und der kommt da auch, wenn jemand anders schaltet (also z.B. ein Taster und nicht der ioBroker).

Im ioBroker ist die Idee aber, dass es nur ein Objekt gibt, was mit ack=false beschrieben wird und so einen Befehl auslöst und vom Adapter mit ack=true beschrieben wird und so eine Statusänderung am Gerät darstellt.

Wenn du z.B. den Vis Adapter nutzen möchtest für eine Visualisierung, dann kannst du da für eine Lampe nur ein objekt eintragen. Trägst du da eine unverknüpfte Schalt-GA ein, dann kannst du zwar mit der Vis schalten, schaltest du aber mit einem Taster z.B., dann siehst du die Änderung nicht in der Vis. Wenn es die Verknüpfung gibt, wird durch die Nachricht des Geräts auf der Status GA im ioBroker (und nur da) auch bei der Schalt-GA der aktuelle Wert eingetragen und es reicht dann im ioBroker aus die Objekte für die Schalt-GA überall zu verwenden und man kann damit dann eine Vis oder Skripte oder was auch immer bauen.

@killroy2 said in Test Adapter KNX v1.0.x:

Sobald das KNX Objekt empfangen wird schreibt er automatisch das Status Objekt mit dem Wert auf den Bus. Warum er das macht ist mir rätselhaft.

Nein, tut er hier definitiv nicht. Hast du da ggf. irgendwelche Skripte laufen? Und über welche GA schreibt er das? Das solltest du als Bug reporten.

@killroy2 said in Test Adapter KNX v1.0.x:

Den Status wollte ich über eine Logikfunktion berechnen.

Wie willst du den Status über eine Logikfunktion berechnen? grübel
Du kannst natürlich in einem Skript Status GA und Objekt GA auf ein neues Objekt vereinen. Habe ich auch eine Zeit lang gemacht.

[tombox]

@Hansi1234 hatte mal probleme weil nicht explizit dpt 1.008 ausgewählt war sondern nur 1.*. Bzw teste mal 1.0.31, 1.0.20 ob sich da was bewegt