[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?