[gelöst]knx und notify

[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