[gelöst]knx und notify

[speedy_gonzales]

Hallo Forum,

tja, da hat man seit gefühlter Ewigkeit ein funktionierendes gemischtes System aus knx und homematic Komponenten, und dann juckt es einem plötzlich in den Fingern. Never touch a running system. Mit Einführung von fhem Version 5.7 hatte ich das System nicht mehr angepackt. Meine vielfach verwendete Variable % sollte duch $event ersetzt werden. Das war mir dann doch zu heikel. Aber jetzt wollte ich ein paar neue Sachen ausprobieren. Also update auf 5.7. Tief durchatmen und .... nichts funktioniert mehr.

Inzwischen weiss ich, dass ich vermutlich Wochen beschäftigt bin, bis das System wieder so, wie früher läuft. Also fangen wir an:

Mein eibd funktionierte nicht mehr. Ich hatte dies vor Jahren zunächst auf fritzbox und dann rasberypi installiert. Aufbauend auf eibd basierten dann meinen weitere Skripte und wie ich schon schrieb mit einem hohen Grad an Reife.

Nach einer Woche Kompilierei auf dem Rasberypi habe ich nun einen funktionierenden knxd Daemon am Laufen. Zumindest denke ich das.

Trotzdem funktionierte nichts. knx Syntax ist vollig anders als eibd.

Vorher: define BZ_Licht_Decke EIB 1106
Jetzt: define BZ_Licht_Decke KNX 1/1/06:dpt1
Bei 100 Gruppenadressen schön viel TippArbeit, wenn man sich nicht extra Skripte zum Konvertieren schreiben will.

Gut auch das Problem ist inzwischen gelöst.

Trotzdem funktioniert alles nicht wirklich richtig. Der Taster an der Wand im Badezimmer schaltet das Licht an der Decke an. Das funktioniert über knx ohne fhem. Fhem wird darüber informiert und soll dann weiter Aktionen starten. Mal geht es, mal nicht, manchmal muss man zweimal schalten, dann geht es oder auch wieder nicht. Also irgendwie ist der Wurm drinne. Jetzt ist systematische Fehlersuche angesagt, eigentlisch soll Hausautomation das Leben leichter machen, aber kein Selbstzweck sein. Oder ist das die moderne Form von der Spielzeugeisenbahn im Keller. Ich bin ein wenig gefrustet....

Nun brauche ich Hilfe: Notify meldet einen Fehler.
Das Badezimmer Licht wird eingeschaltet und über ein Notify soll eine Steckdose geschaltet werden, damit das Radio im Badezimmer angeht. Funktioniert auch, aber der Fehler im Log lautet:

set BZ_Steckdose setG1: off : unknown argument, choose one of off on on-for-timer on-until raw string value

Statt nur off erhält Notify "setG1: off". Eigentlich sollte es aber nur ein on/off erhalten.

Die Syntax des notify lautet:

define BZ_Licht_Decke_notify notify BZ_Licht_Decke set BZ_Steckdose $EVENT

$EVENT enthält also SetG1: off statt nur off. Der Befehl set BZ_Steckdose $EVENT wird zweimal ausgeführt einmall mit SetG1: was zu der Fehlermeldung führt und danach mit off, was zum gewünschten Ergebnis führt: die Steckdose schaltet.

Meine Definitionen entsprechen genau dem Wiki und haben jahrelang fehlerfrei funktioniert.
Ist das jetzt ein Fehler in knx oder ist das so gewollt. Lösen kann ich das Problem, indem ich die Regexp einschränke mit (on|off), aber das kann doch nicht die Lösung sein, oder. Soll ich alle notify umbauen?

Oder übersehe ich etwas, muss die Syntax für das Schalten des Lichtes jetzt anders sein

Vielen Dank für die HIlfe

Norbert

[Andi291]

Abend!

Anteilig kann ich Deinen Frust nachvollziehen. Ich habe in Summe 600 Adressen, mit EIB 12k LOC. Den KNX habe ich deutlich geändert. Dadurch komme ich auf 3k LOC. Das macht es schon übersichtlicher.
Eine Migration mittels Skript hat auch hier keinen Sinn gemacht - um besser zu werden, muss Hirnschmalz rein. Einfach umbenamsen ist Käse...

Zu Deinem Problem:
Der KNX wirft per Default drei Events bei jedem Telegram.
1. das eingehende Rading (getG1: off)
2. den letzten Sender
3. den Inhalt von state (off)

Du kannst jetzt also entweder die notifies anpacken, oder die nicht gewünschten readings per Attribut eventOnChangeReading oder eventOnUpdateReading verhindern.

Grüße, Andi

[Andi291]

P.S.: Manchmal hilft ein Blick in den Event-Monitor

[speedy_gonzales]

Hallo Andi,

danke für die schnelle Antwort und Dein Verständnis für meinen Frust.

Ich habe vermutet, dass es genau die von Dir genannten Lösungen gibt (bin ja bereits durch Versuche selber darauf gekommen).

Was ich nicht verstehe, wieso das setG1 mit versendet werden muss als Standard. Idealerweise, das wäre dann FHEM konform, würde nur on oder off gesendet. Vermutlich sind sehr viele notifies so aufgebaut, wie im Wiki beschrieben und diese funktionieren jetzt alle nicht mehr, bzw. funktionieren diese noch, aber nur wenige haben bisher gemerkt, dass das notifiy mehrfach ausgelöst wird.

Als Lösung werde ich wohl das Attribut change-on-update setzen. Ich denke, an der Stelle läßt sich einfacher kontrollieren, was gesendet wird, als alle notifies darauf zu untersuchen, was diese empfangen dürfen.

Besten Gruß aus Köln

Norbert

[speedy_gonzales]

Uups meinte eventOnUpdateReading

[speedy_gonzales]

Nachtrag

attr BZ_Licht_Decke event-on-update-reading state

funktioniert einwandfrei. Das Notfy arbeitet wieder wie gewohnt. An $EVENT wird state aus dem Reading des triggernden device (hier BZ_Licht_Decke) übergeben und dort ist dann nur noch on oder off eingetragen. Ein "setG1 on" verursacht also keine Fehlermeldung mehr.

Das Thema kann als gelöst betrachtet werden.

Übrig bleibt die Frage bzw. verstehe ich noch nicht Sinn und Zweck der Übergabe des Wertes setG1. Wo und wie nutzt das, bzw. was kann ich damit anfangen.

Danke an Andi

[Andi291]

Hallo Norbert,

wird dann sinnvoll wenn man

1. mit mehreren GA in einem Device arbeitet - in state wird dann nämlich nur der letzte Wert reingeladen.
2. die verwendeten GPlots übersichtlicher gestalten möchte, oder auf unterschiedliche GA in einem Device reagieren möchte
3. zum Beispiel senderabhängige Aktionen auslösen möchte
4. das Busverhalten protokollieren möchte

Grüße, Andi

[speedy_gonzales]

Hallo Andi,

ok, ich beginne zu ahnen, was man damit machen kann. Ich könnte also einen Schalter bestehend aus dem Taster und dem Aktor (z.B. B&J 6920/40) über ein Device in fhem steuern, also z.B. Tastenereignis, LED, Schalten des Aktors usw. Bisher steuere ich das über eine Szene in ETS und schleife die zugehörige Gruppenadresse durch nach fhem.

Bei mir hat jede existierende Gruppenadresse ein eigenes Device in fhem. Sei es der Status eines Aktors, oder der Status einer LED im Taster oder der Aktor, Taster jeweils oder die acht Schalter des Fußbodenheizungsmoduls jeweils usw.

Die Grundprogrammierung der Szenen erfolgt in Ets, weil so das System robust ist, falls z.B. fhem aus welchem Grund auch immer ausfallen sollte (Ist noch nie passiert, ausser nach einem Stromausfall nachts): Licht läßt sich einschalten, wenn ich nach Hause komme und die Heizung funktioniert auch immer, weil direkt über knx gesteuert.

Der Vorteil ist also, dass ich alles, was ich bisher über die ETS gemacht habe, jetzt einfacher über fhem programmieren kann? Na gut.

Die Robustheit des eigenständigen knx Systems hat mir eigentlich gut gefallen und der Zweck von fhem ist primär knx mit meinen anderen (inzwischen gut einem dutzend) unterschiedlichen Systemen zu verbinden, also primär das notify zu nutzen, um z.B. homematic Thermostate (viel billiger als B J Thermostate) oder die harmony Fernbedienung mit knx zu verknüpfen.

Mein System werde ich jetzt erstmal mit dem neuen knxd wieder so zum laufen bringen, wie es vorher mit eibd funktioniert hat. Das wird mich noch viele Stunden kosten. Danach werde ich mal schauen, ob knxd für die ein oder andere Optimierung nützlich ist, sich also der Einsatz für die Neuprogrammierung wirklich gelohnt hat. Die letzten fünf Jahre hat eibd für mich perfekt funktioniert.

Trotzdem finde ich Deine Leistung toll. Also Danke dafür.

Beste Grüsse aus Köln

Norbert

[Andi291]

Danke Dir - sehr gerne

Und ich teile Deine Meinung - die Systeme, die ich projektiert und installiert habe, arbeiten alle autark. Ich setzt FHEM ausschließlich als Visualisierungstool ein. Aber selbst hier lassen sich massiv Effizienzen holen, wenn man verschiedene Elemente (GAD) in einer Organisationseinheit (Device) bündelt.

In diesem Sinne - Kopf hoch! Auf dass es wieder 5 Jahre robust läuft!

[smurfix]

Mein System werde ich jetzt erstmal mit dem neuen knxd wieder so zum laufen bringen, wie es vorher mit eibd funktioniert hat. Das wird mich noch viele Stunden kosten.

Korrektur bitte: der Grund für die Arbeit ist nicht eibd vs. knxd. Der Grund is altes vs. neues FHEM.

Die (binären) Daten, die zwischen FHEM und eibd/knxd ausgetauscht werden, sind exakt dieselben geblieben. (Abgesehen vom einen oder anderen Bugfix.)

[Andi291]

Da hat er recht

[speedy_gonzales]

Vielleicht ist das misverständlich, aber ich kritisiere knxd nicht und beschwere mich auch nicht.

Die Riesenarbeit ist entstanden, weil ich nicht meinem Instinkt gefolgt bin und die Finger vom update auf 5.7 gelassen habe. Hätte ich klug gehandelt, hätte ich mit dd von der SD-Karte eine Kopie angefertigt und nach dem Schock, dass eibd nicht mehr geht, die 1:1 Kopie eingesteckt und vermutlich die nächsten fünf Jahre mit 5.6 gelebt. Ich hatte einfach nicht damit gerechnet, dass der Daemon mit 5.7 ausgetauscht wird.

Es ist spitzfindig zu sagen, dass die Arbeit nun durch den Wechsel des Daemon oder das update verursacht wird. Meine eingesetzen eibd (auf fritz und rapi) habe ich als fertige Pakete (ja auch den für die Fritzbox, auch wenn das viele jetzt nicht glauben wollen) aus dem Internet gezogen. Da musste ich nichts kompilieren, die liefen out of the box. Der knxd musste kompiliert werden und ich hatte sehr viele Abbrüche mit anschliessender Recherche, bis ich alle Fehler gefunden und beseitigt hatte. Dafür sind gut zehn Stunden Arbeit draufgegangen. Für mich sieht das also erstmal so aus, als ob der Wechsel zu knxd der Verursacher meines  Aufwands ist.

Die Feststellung, dass sich an dem Datenaustausch zwischen fhem und knxd bzw. eibd nichts geändert hat, nutzt mir wenig.

Jetzt habe ich noch viel Arbeit vor mir, weil die Syntax in fhem sich verändert hat. Meine erste Freude, dass sich mit dem attr event-on-update-reading, schnell alle weiteren Probleme lösen lassen, hat sich gelegt.

Jedes zweite notify zickt rum, ich muss also für jedes notify die von state übergebenen Informationen loggen, um anschliessend passende regex zu erstellen. Reicht das nicht aus, muss ich zusätzliche if Abfragen erstellen, und alles nur, um ein simples on/off zu erhalten.

Beispiel: Der Deckenventialtor ist, weil der knx Schalter den Anlaufstrom nicht verträgt über ein homematic switch geschaltet: Ein Taster sendet ein Signal via ip-Interface über knxd an fhem. Das Signal wird über event-on-update reading gefiltert, so dass nur ein on/off beim notify ankommt. Die Information, dass der Switch nun an ist, soll zurück an die LED im Taster, um diese von rot auf grün zu schalten. Aber das notify , dass über knxd die LED schalten soll, will einfach nicht, mit der regex lassen sich ein paar Informationen filtern, aber zum Schluss muss noch eine if Abfrage erfolgen.

Wie gesagt, ich hatte sehr lange ein funktionierendes System mit einfachst konstruierten notifies, ohne aufwändige Filterung und if Abfragen.

Ich schreibe schon sehr lange fhem Skripte, so dass ich alle Probleme lösen kann, aber es ist halt frustierend die ganze Arbeit zu haben. Und da ist ss wirklich egal, wo jetzt die Ursache zu suchen ist.

Und damit mich keiner falsch versteht. Ich finde es toll, dass so viele Leute an dem Projekt mitarbeiten, also die Weiterentwicklung von knxd und fhem vorantreiben.

Für mich ist fhem kein Bastelprojekt, es soll die verschiedenen Systeme meiner Hausautomation zuverlässig kontrollieren und verbinden. Deshalb sind updates immer eine schwierige Sache, insbesondere, wenn deshalb plötzlich ein System im produktiven Einsatz ausfällt. Es ist eben keine Spielzeugeisenbahn im Keller.

Und meine Frau wird bekloppt, wenn das nicht bald alles wieder so ist, wie vorher.

Beste Grüße aus Köln

Norbert

[Andi291]

Servus Norbert,

also um den Umstieg einfacher zu gestalten, gibt es durchaus die Möglichkeit das MODUL eib weiter zu verwenden (steht auch so in der commandref). Ich selbst habe auch zunächst den Kompatibilitätsmodus eingeschalten, und Objekt für Objekt migriert. Dazu bitte einfach in der TUL das attr useEib auf 1 stellen.

Dann bleibt Deine Frau ruhig, und Du kannst ein Objekt nach dem anderen angehen.

Der Grund, warum ich dieses Attribut standardmäßig deaktiviert habe, ist um Neuinstallateure gleich zum KNX zu nötigen.

Grüße, Andi

P.S.: Poste doch bitte mal das komplette Ventilatorbeispiel. Vielleicht fällt mir noch was ein. Ich bin bei 600 devices mit ZWEI IF's ausgekommen...Mag ich nämlich nicht...

[speedy_gonzales]

Hallo Andy,

leider ist das bei mir nicht so gelaufen.

Nachdem fhem update funktionierte nichts mehr richtig und dann habe ich im LOG gelesen, dass eibd abgeschaltet ist und durch knxd ersetzt wurde. Da setzte bereits die Panik ein, weil ich ja kein Kopie der SD Karte erstellt hatte. Von einem Kompatibilitätsmodus und das eibd weiterhin funktioniert, stand da nichts.
Da kommt man dann auch nichts als erstes auf die Idee, in der commandref nachzulesen, denn die bezieht sich ja auf das Modul knx und das ist ja überhaupt nicht installiert.

Der erste Weg war für mich also ins Forum und dort habe ich sofort die Installationsanleitung für knxd gefunden. Beim Kompilieren, muss man aber, warum auch immer den eibd deinstallieren, sonst läuft knxd nicht durch. Und ab da, gab es keinen Weg mehr zurück. Natürlich gibt es immer einen Weg zurück, aber weitergehen erschien mir der schnellere Weg.

Warum ich das schreibe? Vielleicht muss die Information, dass es einen Kompatibilitätsmodus gibt, an prominentere Stelle, denn die commandref war in diesem Fall der letzte Ort, wo ich nachgeschaut hätte.

Danke Andi für das Angebot mal über das Ventialtorbeispiel zu schauen, aber ich habe es ja bereits gelöst.

Wenn Du meinst, dass es exemplarische Bedeutung für die Mitlesenden haben könnte, will ich es gerne posten, ansonsten wird Deine Hilfe vermutlich woanders dringlicher gebraucht.

Norbert

[Andi291]

Hallo Norbert,

schade, dass das bei Dir nicht so glücklich gelaufen ist.

Rein Interesse halber - in Deinem Log müsste stehen:
"Using EIB is deprecated. Please migrate to KNX soon. Module 10_EIB is not maintained any longer. If you still want to use the module EIB, please set the attribute useEIB to 1."

Ist dem so?

[speedy_gonzales]

Hallo Andi,

schwierige Frage, mit update auf 5.7 und der Installation von knxd habe ich die alten logs gelöscht. Dachte, dass ich die nicht mehr brauche, weil ich ja nun neue und andere Fehlermeldungen bekomme. Den ersten log, den ich noch habe, ist der erstmalige Start von Version 5.7 mit dem neuen knxd. Und dort steht nur EIB is no longer supported. Message is discarded. Die Meldung kommt allerdings hundertfach.

Vielleicht ist die von Dir genannte Fehlermeldung ja vor der Installation von knxd erschienen, dann habe ich diese wohl falsch verstanden, eben das 10_EIB nicht mehr unterstützt wird und man schnellstmöglich nach knx migrieren muss (nicht soll). Das die Migration nur optional ist, also nicht zwingend, wie ich meinte, habe ich jedenfalls nicht mitbekommen, war ja auch nicht in bester Stimmung, weil nichts mehr richtig funktionierte. Hätte ich das mitbekommen oder irgendwo im Forum gelesen, dann würden wir heute nicht kommunizieren.

Also, ich weiss nicht sicher, ob das im LOG gestanden hat, aber irgendwoher wusste ich dann sehr schnell, dass knxd eibd ersetzt.

Grüsse Norbert

[knxhm]

Code Auswählen Erweitern


habe ich im LOG gelesen, dass eibd abgeschaltet ist und durch knxd ersetzt

Kann es sein das ihr an einander vorbeiredet? Es gibt den eibd Dämon und den knxd Dämon, die haben mit FHEM gar nichts zu tun wie smurfix schon anmerkte. Dann gibts Andi291 Module 10_EIB und 10_KNX in FHEM.
Was Andi291 geändert hat ist die default Verwendung des 10_KNX Moduls anstelle des 10_EIB Moduls in FHEM.
Ich habe zwar selbst auch knxd am laufen, aber ich denke das FHEM 10_KNX Modul kann sich mit beiden Dämonen unterhalten und ich glaube das wird hier verwechselt.
Anders gesagt, die Änderung von Andi291 EIB -> KNX bedingt nicht zwangsläufig die Verwendung des knxd, der eibd kann bleiben. Wenn dieses Verständnis falsch ist bitte um Korrektur.

Was vieleicht ein bischen zur Verwirrung beiträgt ist das der tul in der fhem.cfg immer noch mit eibd:.... definiert ist obwohl auf diesem Ding vielleicht sogar doch der knxd läuft. Das sollte man aber wohl auch nicht ändern.

[speedy_gonzales]

Hallo knxhm,

interessanter Einwand. Vielleicht bin ich ja tatsächlich die ganze Zeit auf dem Holzweg. Ich denke tatsächlich die ganze Zeit, dass 10_KNX nur mit dem knxd kommuniziert und 10_EIB  nur mit dem eibd Daemon.

Der Grund für meine Annahme ist/war, dass 10_KNX eben nicht mehr mit meinem eibd funktioniert hat, aber sofort funktioniert hat, nachdem ich knxd kompiliert und installiert habe.

Auch hat mich die Eingabe der Fehlermeldung in die Suchfunktion sofort zu einem Beitrag gebracht, der sich mit der Installation von knxd beschäftigte. Deshalb dachte ich auch, dass Andi der Programmierer von knxd ist, denn in dem Forumsbeitrag wurde explizit nach einer Installationanleitung von Andi gefragt.

Rätsel?

Gruss Norbert

[smurfix]

Der Grund für meine Annahme ist/war, dass 10_KNX eben nicht mehr mit meinem eibd funktioniert hat, aber sofort funktioniert hat, nachdem ich knxd kompiliert und installiert habe.
Gruss Norbert

Kannst du "hat nicht funktioniert" etwas konkretisieren?

Das Einzige, was sich inkompatibel geändert hat, ist der Pfad zum Unixsocket -- der ist nicht mehr in /tmp (wo er definitiv deplatziert war), sondern in /run.
Aber man kann dem knxd problemlos mitteilen, auch auf dem alten Socket zu lauschen.

[Andi291]

Guter einwand. Ich kann versichern, das 10_eib und 10_knx beide mit knxd und eibd können. Nur,dass die nutzng  von 10_eib per default eben aus ist.

[speedy_gonzales]

Gut, dann ist ja jetzt alles klar.

10_KNX und 10_EIBD funktionieren beide sowohl mit eibd als auch mit knxd.

Ich habe mich anhand der Fehlersymptome verwirren lassen und statt mit kühlem Kopf Fehleranalyse zu betreiben, mir unnötig Arbeit gemacht.

@smurfix:
Zu den Fehlersymptomen: Nach update auf 5.7 funktionierte das autarke KNX weiterhin. Aber weitergehende Funktionen, die über fhem mit notify gesteuert wurden z.B. "Wenn Licht im Badezimmer angeht, dann Radio einschalten" nicht mehr.

In der Log Datei war nur sinngemäß die Meldung, dass knx eib ersetzt - ich hatte schon geschrieben, dass ich die Logs gelöscht habe -. Es wurden keine Fehlermeldung der notifies z.B. von dem Radio angezeigt, daraus habe ich geschlossen, dass knx kein Signal an fhem geschickt hat, weil sonst das notify mit einer Fehlermeldung reagiert hätte und ich wäre auf die Idee gekommen, dass sich nur die Syntax  geändert hat. Kein Signal bedeutete für mich, dass eibd nicht mehr mit 10_KNX funktioniert, also eibd durch knxd ersetzt werden muss. Nach der Installation von knxd erschien es mir logisch die Gruppenadressen noch anzupassen, siehe meinen Eingangspost und voila das Senden und empfangen klappte wieder, die Fehlermeldungen vom notify waren zu sehen.

Ich entschuldige mich für die Verwirrung, die ich gestiftet habe. Letztendlich bin ich mit meiner falschen Diagnose und eurer Hilfe zur richtigen Lösung gekommen allerdings mit sehr viel Arbeitsaufwand.

Grüße Norbert

[Andi291]

Hallo Norbert,

brauchst Dich nicht zu entschuldigen...

Um das Thema zum Abschluss zu bringen:
Wo und welcher Hinweis hätte Dir geholfen?

Grüße, Andi

[speedy_gonzales]

Hallo Andi,

das ergibt sich ja jetzt als Zusammenfassung der vorherigen Beiträge.

Im Log sollte eine ausführlichere Mitteilung stehen, ich hatte ja die Mitteilung zunächst dahingehend interpretiert, dass eibd nicht mehr funktioniert, aber knx selber genauso wie eib funktioniert.

Also im LOG könnte vielleicht sinngemäß etwa dieses stehen:

knx ist jetzt als Standard gesetzt und ersetzt eib.
knx hat eine geänderte Syntax! Lies die commandref!
Änderungen betreffen nicht nur die Definitionen der devices, sondern auch die Übergabe der readings (Auswirkungen z.B. auf notify).
Für eine Übergangszeit funktioniert weiterhin eib.
Dazu ist das attr useeib 1 zu setzen unter <=hier sollte dann stehen, wo das attr zu setzen ist: unter Global oder dem device, denn das ist die nächste Stelle, die dem Anwender Kopfzerbrechen bereit. =>
knx ist kompatibel zu allen Schnittstellen (eibd, knxd, ...), die mit eib funktionieren.

Das Problem tritt ja eigentlich nur bei den Anwendern auf, die ein update machen und bisher überhaupt nicht auf dem Schirm haben, dass eib durch knx ersetzt wurde. Für die kommt die Änderung dann doch ein wenig plötzlich. Z.B. wollte ich ja eigentlich was ganz anderes machen (mit mailcheck und ifttt experimentieren) und zerschiesse das System mit knx, an einer Stelle, die seit Jahren fehlerfrei läuft. Völlig unerwartet. Und genau für die paar Wenigen muss die Fehlermeldung im LOG so ausführlich sein, damit sie nicht noch mehr kaputt machen, wie ich.

Die meisten haben sich ja vorab informiert und wissen dann meist, was zu tun ist, wenn sie ein update machen. Für diese ist die vorhandene Fehlermeldung wahrscheinlich eindeutig und ausreichend. Für mich jetzt im nachhinein auch . Hinterher ist man immer schlauer.

Grüsse Norbert

[Andi291]

Hallo Norbert,

Anregung aufgenommen und umgesetzt.

Grüße, Andi

[speedy_gonzales]

Klasse!

Eine dummy Frage habe ich noch, wie setzt man diesen Thread auf "gelöst". Ich bin ja eher ein seltener Forist, soll heißen, ich kenne mich mit der Bedienung nicht so gut aus.

Danke,

Norbert

[knxhm]

Einfach die Überschrift editieren und [gelöst] am Anfang schreiben

[simonTS]

Sorry, aber ich werd nicht ganz schlau (oder wills nicht wahr haben).

Nachdem ich lange vor meiner Haustür vergebens aufs öffnen gewartet habe ... Nachgelesen habe ... Mich über mich selbst geärgert habe ... etc.

Wenn ich jetzt attr usEIB 1 setze, muss ich trotzdem die Syntax bei allen anpassen?
define xy EIB 6/4/10 auf was? dpt hinzufügen bei allen devices? buhuhu...

Die commandref schlaut mich ehrlich gesagt auch nicht wirklich auf. Oder vllt. bin ich noch blind vor schock!

EDIT: vor lauter schock... das attr falsch angegeben. funktioniert dann doch noch mit Eib. Thx. mache mich die Tage mal an knx UND MACHE EIN dd DER KARTE, BEVOR ICH WEITERMACHE