neue Infos zur Vaillant KNX Anbindung

[Nico184]

Du musst nicht über den KNX-Bus gehen. Der ebusd hat einen MQTT Client integriert.
Ich gehe diesen Weg um meine Daten mittels telegraf in eine Influxdb zu speichern.

[XueSheng]

Danke Nico184 für den Hinweis. Da ich mich mit MQTT aktuell nicht auskenne und auch nicht Influxdb nutzen möchte, wird vermutlich der Ansatz, die RRDs über KNX zu füllen, einfacher sein.

So ganz habe ich ebusd aber auch noch nicht verstanden. Mir ist z.B. unklar, warum ich den Legionellenschutz nicht aktivieren kann.

$ ebusctl scan result
1 scan(s) still running
08;Vaillant;EHP00;0416;7201;21;12;17;0010009074;0006;005255;N3
15;Vaillant;UIH00;0370;6901;21;12;09;0020101780;0907;010136;N6
23;Vaillant;EHP00;0416;7201;21;12;17;0010009074;0006;005255;N3
25;Vaillant;EHP00;0416;7201;21;12;17;0010009074;0006;005255;N3​

$ ebusctl find -f LegioProtectionEnabled
r,hwc,LegioProtectionEnabled,Legionellenschutz,,25,b509,0d4000,yesno,s,UCH,0=no;1=yes,,"Der Legionellenschutz wird, wenn eine Zusatzheizung aktiviert ist, bei „AN“ Mittwochs zur eingestellten Uhrzeit durch die Zusatzheizung ausgeführt"​

$ ebusctl read LegioProtectionEnabled
no​

ebusctl write -c hwc LegioProtectionEnabled 1
ERR: element not found​

Laut "find" handelt es sich also nur um einen Parameter zum Auslesen. Aber in der github config ist dieser Parameter als "r,wi" eingetragen.
Muss/Kann ich das lokal irgendwie überschreiben, so dass ich den Legionellenschutz auch aktivieren kann?

[Nico184]

"r, wi" bedeutet, dass die Massage nur schreibbar ist, wenn du den access level #installer (siehe Zeile 5) hast.
Siehe Wiki...
Zudem muss in der Config File die Startoption --accesslevel=installer noch ergänzt werden.

[XueSheng]

Danke Nico184, das erklärt es.

Die Anbindung an KNX habe ich noch nicht im Griff. Manche Werte werden einfach nicht auf den Bus gesendet, obwohl diese problemlos über ebusctl gelesen werden können und auch die entsprechenden Einträge in der knx.cfg existieren. Bei anderen Werten klappt es dann wieder problemlos.
Bin nun gerade dabei die Anbindung an KNX wieder über yawgd zu realisieren. Das scheint mir zuverlässiger zu funktionieren und löst auch mein "Problem", die RRDs zu schreiben.

[Nico184]

Die KNX Anbindung hat mich auch nerven gekostet. Wichtig ist, dass die Zuordnung in der knx.cfg korrekt, d.h. case sensitiv geschrieben werden und eine PA vergeben wird. Danach dauert es etwas, bis ebusd das mapping "verstanden" hat, dann sollte das Lesen der Werte auch funktionieren.

[jcd]

Mal was anderes. Ich habe gerade das ISE Gateway für den Vaillant eBus ausgepackt und mir kam die Art wie die Bedienungsanleitung gefalten war komisch bekannt vor.
Dann hab ich einen Gira Taster ausgepackt und .... etwas gegooglet. Wusstet ihr, dass ISE zum Gira-Konzern gehört?

https://www.facebook.com/gira.de/pos...0812631293774/

Damit wird mir nun um einiges klarer, wie ein Unternehmen alleine von der Nische "KNX-zu-irgendwas-Gateway" zu vergleichsweise günstigen Preisen leben kann.

[Beleuchtfix]

Ja, seit vielen Jahren Interessant ist, dass die selben Geräte teilweise bei ISE günstiger sind, und Änderungen am ISE z.B. deutlich früher bei ISE auftauchen als bei Gira.
Gruß Florian

[knxodernix]

Das Gira Logo ist mit Black Diamond Diamantstaub gedruckt und die Lötstellen der Elektronik sind mit purem Silber gelötet. Nebenbei auch praktisch zur Vampirabwehr.

[jcd]

Ich hab das ise eBUS Gateway in Betrieb genommen. Nach einer kurzen Ernüchterung ("kein Systemregler gefunden") hatte ich die Erkenntnis, dass das Geräte noch mit der alten Firmware ausgeliefert wurde und erst mal das Update auf v2.1 brauchte. Davon abgesehen hat alles sehr gut geklappt.

Was ich nur nicht verstehe:
Ich habe eine Trinkwasserstation VPM 20/25/2 W. Die ist an den eBus angeschlossen und wird über den sensoComfort gesteuert.

Wenn ich bei der Parapmetrierung des ise Gateways über die ETS nun wahrheitsgemäß "In der Anlage ist eine Vaillant Trinkwasserstation VPM-W vorhanden" mit "ja" angebe, dann werden alle KO die mit der Warmwasserbereitung zusammenhängen, ausgeblendet/deaktiviert. Das soll laut Handbuch auch so sein. Nur warum??

Verneine ich das Vorhandensein der Trinkwasserstation sind alle KOs da und funktionieren (!). Ich kann z.B. die Warmwassertemperaturen via KNX auslesen und auch ändern. Die Einstellung wird vom sensoComfort und der Trinkwasserstation korrekt übernommen.

Weiß jemand was das soll?

[mivola]

Hallo zusammen,

da ja hier sehr viel über den ebusd gesprochen wird, würde ich gern versuchen eure Hilfe zu bekommen.

Ich nutze den ebusd in einem Docker Container auf der Synology. Das Auslesen/Schreiben der Werte klappt auch sehr gut. Auch die Anbindung an meinen MQTT-Server läuft. Einzig die Verbindung zu KNX funktioniert nicht :-( Ich nutze für den Zugriff auf KNX das wiregate und das funktioniert an anderen Stellen (NodeRED, telegraf/InfluxDB) auch problemlos.

Ich habe schon diverse Versuche unternommen um die Verbindung mit der Umgebungsvariablen "EBUSD_KNXURL" zu definieren, aber ich bekomme immer nur folgendes im Log:

2023-03-13 08:55:09.599 [knx notice] address not assigned yet, entering programming mode
2023-03-13 08:55:09.599 [knx notice] connected to KNXnet/IP multicast

Bei NodeRED und Telegraf nutze ich nur "wiregate:3671" als Gateway-Adresse (alle Container laufen im bridge Netzwerk). Wie müsste ich dies an ebusd-Docker-Container übergeben?


Danke und VG
Micha

[Nico184]

Hey Micha,
ich nehme an, der Code-Auszug ist aus dem ebusd-Log? Hast du in der knx.cfg die physikalische Adresse unter ##Individual Adress vergeben?
Wenn ja, dann solltest du mittels KNX-Busmonitor beim Start vom ebusd die vordefinierten Zuweisungen der globalen Werte (global/running etc...) auf dem Bus sehen. Dabei beachten, dass die Gruppenadressen nicht im IP-Router bzw. in Linienkopplern hängebleiben, weil die Filtertabellen nicht passen.

[XueSheng]

mivola hattest Du meinen Kommentar dazu auf github gesehen?
https://github.com/john30/ebusd/disc...omment-5199567

IP-Router nutzt imho multicast und das wird standardmäßig nicht in den Container geroutet.

[mivola]

Hey Micha,
ich nehme an, der Code-Auszug ist aus dem ebusd-Log? Hast du in der knx.cfg die physikalische Adresse unter ##Individual Adress vergeben?
Wenn ja, dann solltest du mittels KNX-Busmonitor beim Start vom ebusd die vordefinierten Zuweisungen der globalen Werte (global/running etc...) auf dem Bus sehen. Dabei beachten, dass die Gruppenadressen nicht im IP-Router bzw. in Linienkopplern hängebleiben, weil die Filtertabellen nicht passen.

Ja, der Auszug ist aus dem ebusd.log und die physikalische Adresse ist gesetzt. Im eib.log oder Gruppen/Busmonitor sehe ich aber weder etwas von "global/*" noch von meinen definierten Mappings. Linienkoppler habe ich nicht.

Müsste denn für ein versendetes KNX-Telegramm etwas im ebusd.log auftauchen?
Was mich auch wundert ist dieser Logeintrag:

address not assigned yet, entering programming mode

Der kommt von hier: https://github.com/john30/ebusd/blob...ndler.cpp#L197

Danke,
Micha

[mivola]

mivola hattest Du meinen Kommentar dazu auf github gesehen?
https://github.com/john30/ebusd/disc...omment-5199567

IP-Router nutzt imho multicast und das wird standardmäßig nicht in den Container geroutet.

Die Antwort bei github habe ich tatsächlich nicht sehen - aber ich denke, dass Multicast mit Docker prinzipiell funktioniert, wenn man "--net=host" benutzt (zumindest funktioniert der SAE bei mir genau so.

Aber es müsste doch auch ohne Multicast funktionieren, oder? In welcher Syntax müsste ich die Verbindung zum Wiregate dann angeben?

Danke,
Micha

[XueSheng]

Aber es müsste doch auch ohne Multicast funktionieren, oder? In welcher Syntax müsste ich die Verbindung zum Wiregate dann angeben?

Im ebusd docker scheint aktuell knxd nicht vorhanden zu sein. Wenn der container mit knxd gebaut wird, sollten alle knxd üblichen Verbindungen möglich sein.
Habe ebusd lokal ohne docker getestet und war nicht zufrieden. Bin daher bzgl. knx Anbindung wieder bei yawgd (in Kombination mit dem aktuellen ebusd docker).