neue Infos zur Vaillant KNX Anbindung

[gibsonrocker]

Ah sorry....ich habe am Handy den unteren Teil von Deinem Beitrag übersehen. Kannst Du die Werte lesen? Oder hast Du nur Probleme beim schreiben?

Wenn Du die Werte lesen kannst: Wie versuchst Du die Werte zu schreiben?

[gibsonrocker]

In meinem Beispiel gibt's aber leider temp0 und temp1 gleich zweimal....Sonst geht's wie Du geschrieben hast, richtig.

[Nico184]

Es ist mir gelungen die Außentemperatur ebenfalls auf den Bus zu bekommen, indem ich /temp2 ergänzt habe. Warum das so sein muss, habe ich der Erklärung in der knx.cfg nicht verstanden?

Ich hatte das Mapping "circuit/massage/field" so verstanden, dass man damit auch Werte aus den Arrays abfragen kann, wenn die einzelnen Teile mittels "field" definiert sind. Wie ich das in den folgenden Beispielen in meinen *.csv's gemacht habe um die einzelnen Felder über MQTT zu bekommen.
Hier ein Beispiel aus der hwcmode.inc:

r,,Status,VorlaufSoll/UVStatus/Ist/SpeicherSoll,,,,0D,HWCTempDesired,,temp0,,,WW-Solltemperatur,LP/UV1ValveStatus,,onoff,,,LP/UV1-Status,TempStorage,,temp,,,WW-SpeicherIst,StorageTempDesired,,temp0,,,WW-SpeicherSoll

Das sieht dann über HTML so aus:
json.jpg
und über MQTT so:
MQTT.jpg
Aber wie ich da einzelne Werte inx KNX bekomme habe ich noch nicht herausgefunden 🙃

Am Schreiben scheitere ich aber ebenfalls noch...

[gibsonrocker]

Hi,

genau. Bei mir "broadcast/outsidetemp/temp2 = x/x/x".

Ich bin übrigens begeistert. Es geht jetzt (fast) alles. Über KNX schreiben auch. Jetzt kann ich endlich vernünftig mit der Heizung arbeiten! Leider kommen nur sehr wenige Werte selbstständig über EBUS raus. Aber klar, warum sollte die Heizung via EBUS auch melden, dass jetzt die Heizkreispumpe angesteuert wird. Das muss ich halt "geschickt" abfragen.

Dadurch, dass jetzt aber kein MQTT mehr dazwischen ist, ist die Performance super. Im Notfall könnte man auch via bash/cronjob manche Werte zyklisch direkt am EBUS-Client anstoßen. Dann brauchts keine Logik über KNX (in meinem Fall Edomi).

Mit dem Parameter "Rage" in der ebus-Config habe ich jetzt keine guten Erfahrungen gemacht.

Mit Rage Parameter:

- Ich lese einen Wert über die ETS
- Wert kommt und stimmt
- Ich ändere den Wert über die VRC700
- Ich lese den Wert
- Der Wert stimmt nicht. Es ist noch der alte. Der neue Wert ist nicht lesbar.

Ohne Rage Parameter:

- Ich lese einen Wert über die ETS
- Wert kommt und stimmt
- Ich ändere den Wert über die VRC700
- Ich lese den Wert
- Der Wert kommt und stimmt.

Noch was:
Wie ich die "Arrays" aus dem EBUS auf KNX bringe habe ich noch nicht rausgefunden.
Z.B. "bai Status02 = hwcmode=auto;temp0=60;temp1=45.0;temp0=80;temp1=62 .0"

johnm: Hast Du da einen Tipp für mich? Oder Du Nico?

[Nico184]

Bei mir werkelt eine auroMatic VRS 620/3 die eine ecoTec plus VC-226/5-5 steuert.
Hast du die Zuweisung in der knx.cfg mit "broadcast/outsidetemp/temp2 = X/X/X" angegeben?
Mir ist bewusst, dass die Außentemperatur über die vaillantspezifische broadcast.csv kommt. In dieser ist für die Außentemperatur kein "field" angegeben, sondern nur der Datentyp mit temp2.

# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m;s),type / templates,divider / values,unit,comment,field2,part (m;s),type / templates,divider / values,unit,comment,field3,part (m;s),type / templates,divider / values,unit,comment
*b,broadcast,,,,"FE","B516",,,,,,,,,,,,,,,,,,,
*wi,broadcast,,,,"FE","B516",,,,,,,,,,,,,,,,,,,
b;wi,,vdatetime,Datum/Uhrzeit,,,,"00",time,,BTI,,,,date,,BDA,,,,,,,,,
b,,outsidetemp,Außentemperatur,,,,"01",,,temp2,,,,,,,,,,,,,,,
*b,broadcast,,,,"FE","B505",,,,,,,,,,,,,,,,,,,
b,,hwcStatus,Status Warmwasser,,,,"27",,,onoff,,,,VF1,,temp0,,,,,,onoff,,,
b,,load,Quick - WW Speicherladung,,,,"06",,,onoff,,,,,,,,,,,,,,,​

[gibsonrocker]

Zu 1: Ich denke, ja. Die globalen vordefinierten Werte sind ja auch ohne "field".

Welche Heizung hast Du denn?

Bei mir kommt die "Outsidetemp" über "broadcast/outsidetemp/temp2". Meine Frage oben hat sich also beantwortet. Ich hatte einfach die falsche Outsidetemp und diese wird auch bei einer Änderung automatisch vom ebus auf knx geschickt.

Ich habe jetzt ALLE meine Heizungswerte in Gruppenadressen geschmissen und werde das jetzt mal in meine Config einfügen. Mal sehen was so geht.

[Nico184]

Hallo,
ich hänge mich mal hier mit rein, da ich auch gerade versuche den ebusd mit KNX zum kommunizieren zu bringen.
Als erstes nochmal vielen Dank für die hervorragende Arbeit an diesem Projekt!

Ich nutze dafür IP/muticast.
Leider gelingt es mir nicht, die Kommunikation von selbst verknüpften Gruppenadressen und Ebus-Nachrichten in Gang zu bekommen.
Die Kommunikation der globalen Ebusd Infos (running/Version...) funktioniert. Beim Start des ebusd sehe ich diese auf dem KNX, auch das Lesen vom KNX funktioniert.
1. Frage:
Nach Definition muss in der knx.cfg die ebusd Nachricht mit circuit/message/field mit der Gruppenadresse verknüpft werden. Nun haben nicht alle ebusd Nachrichten eine Bezeichnung für field, kann diese auch weggelassen werden?
2. Frage:
Wie ist das KNX debug Log zu verstehen? Ich kann die Einträge in der Logdatei nicht deuten.

2022-10-12 21:18:10.898 [knx debug] received unsubscribed write from 100d to 9212, len 2
...
2022-10-12 21:18:12.070 [knx debug] received unsubscribed write from 100c to 9204, len 2
2022-10-12 21:18:12.106 [knx debug] received unsubscribed write from 100c to 9206, len 2
2022-10-12 21:18:12.142 [knx debug] received unsubscribed write from 100c to 9208, len 2
2022-10-12 21:18:12.177 [knx debug] received unsubscribed write from 100c to 920a, len 2
2022-10-12 21:18:12.212 [knx debug] received unsubscribed write from 100c to 920c, len 2
...
2022-10-12 21:18:12.247 [knx debug] received unsubscribed write from 100c to 9210, len 2
2022-10-12 21:18:12.284 [knx debug] received unsubscribed write from 100c to 9200, len 2
2022-10-12 21:18:12.320 [knx debug] received unsubscribed write from 100c to 9202, len 2
2022-10-12 21:18:12.533 [knx debug] received unsubscribed write from 100d to 9214, len 2
2022-10-12 21:18:12.556 [knx debug] received unsubscribed write from 1065 to 8100, len 4
...
2022-10-12 21:18:13.684 [knx debug] received unsubscribed write from 1036 to 9309, len 2
2022-10-12 21:18:13.720 [knx debug] received unsubscribed write from 1036 to 930b, len 2
...
2022-10-12 21:18:17.413 [knx debug] received unsubscribed write from 1036 to 9301, len 2
...
2022-10-12 21:18:19.838 [knx debug] received unsubscribed write from 1101 to 1101, len 4
...
2022-10-12 21:18:19.939 [knx debug] received unsubscribed write from 1101 to 110b, len 4
2022-10-12 21:18:20.040 [knx debug] received unsubscribed write from 1101 to 1115, len 4
...
2022-10-12 21:18:24.417 [knx debug] received unsubscribed write from 1036 to 9305, len 2
....
2022-10-12 21:18:26.573 [knx debug] received unsubscribed write from 1036 to 9302, len 2
2022-10-12 21:18:26.662 [knx debug] received unsubscribed write from 1008 to 8106, len 3
2022-10-12 21:18:27.571 [knx debug] received unsubscribed write from 1036 to 9307, len 2
...
2022-10-12 21:18:27.928 [knx debug] received unsubscribed write from 10a9 to 8c01, len 4
2022-10-12 21:18:28.236 [knx debug] received unsubscribed write from 100d to 9216, len 2
...
2022-10-12 21:18:30.096 [knx debug] received subscribed read from 10fb to 0a04, len 2
2022-10-12 21:18:30.096 [knx debug] sent response, dest 0a04, len 4
2022-10-12 21:18:30.601 [knx debug] received unsubscribed write from 1036 to 930e, len 2
...
2022-10-12 21:18:30.925 [knx debug] received unsubscribed write from 100d to 9212, len 2
....
2022-10-12 21:18:32.071 [knx debug] received unsubscribed write from 100c to 9204, len 2
2022-10-12 21:18:32.106 [knx debug] received unsubscribed write from 100c to 9206, len 2
2022-10-12 21:18:32.142 [knx debug] received unsubscribed write from 100c to 9208, len 2
2022-10-12 21:18:32.177 [knx debug] received unsubscribed write from 100c to 920a, len 2
2022-10-12 21:18:32.213 [knx debug] received unsubscribed write from 100c to 920c, len 2
2022-10-12 21:18:32.248 [knx debug] received unsubscribed write from 100c to 9210, len 2
2022-10-12 21:18:32.285 [knx debug] received unsubscribed write from 100c to 9200, len 2
2022-10-12 21:18:32.321 [knx debug] received unsubscribed write from 100c to 9202, len 2
2022-10-12 21:18:32.561 [knx debug] received unsubscribed write from 100d to 9214, len 2
...
2022-10-12 21:18:33.692 [knx debug] received unsubscribed write from 1036 to 9309, len 2
2022-10-12 21:18:33.729 [knx debug] received unsubscribed write from 1036 to 930b, len 2
...
2022-10-12 21:18:36.969 [knx debug] received unsubscribed write from 100f to 930f, len 2
....
2022-10-12 21:18:44.437 [knx debug] received unsubscribed write from 1036 to 9305, len 2
....
2022-10-12 21:18:46.591 [knx debug] received unsubscribed write from 1036 to 9302, len 2
2022-10-12 21:18:47.444 [knx debug] received unsubscribed write from 1036 to 9301, len 2
...
2022-10-12 21:18:48.249 [knx debug] received unsubscribed write from 100d to 9216, len 2
...
2022-10-12 21:18:50.938 [knx debug] received unsubscribed write from 100d to 9212, len 2
...
2022-10-12 21:18:52.079 [knx debug] received unsubscribed write from 100c to 9204, len 2
2022-10-12 21:18:52.115 [knx debug] received unsubscribed write from 100c to 9206, len 2
2022-10-12 21:18:52.150 [knx debug] received unsubscribed write from 100c to 9208, len 2
2022-10-12 21:18:52.185 [knx debug] received unsubscribed write from 100c to 920a, len 2
2022-10-12 21:18:52.222 [knx debug] received unsubscribed write from 100c to 920c, len 2
2022-10-12 21:18:52.258 [knx debug] received unsubscribed write from 100c to 9210, len 2
2022-10-12 21:18:52.293 [knx debug] received unsubscribed write from 100c to 9200, len 2
2022-10-12 21:18:52.330 [knx debug] received unsubscribed write from 100c to 9202, len 2
2022-10-12 21:18:52.574 [knx debug] received unsubscribed write from 100d to 9214, len 2

​

Hier die KNX.cgf (gekürzt)

# Configuration file for ebusd KNX integration with knxd (https://github.com/knxd/knxd).
[...]
# the own individual address (only relevant when running in KNXnet/IP mode)
address = 2.1.1
# the global value group assignments for running, version, signal, uptime, updatecheck, and scan.
# running: 1 bit, 1=running, DPT 1.002
global/running = 1/2/3
# version: 2 octets, major in MSB, minor in LSB, DPT 217.001 "DPT_Version"
global/version = 1/2/4
# signal: 1 bit, 1=signal acquired, DPT 1.002
global/signal = 1/2/5
# uptime: 4 octets int, seconds since start, sent once every hour, DPT 12.100
global/uptime = 1/2/6
# updatecheck: 1 bit, 1=update available, DPT 1.002
global/updatecheck = 1/2/7
# scan: 1 bit, 1=running, DPT 1.002
global/scan = 1/2/8

# the message field value group assignments by circuit/message/field name.
# the value coding depends on the field datatype and currently only numeric datatypes are supported.
[...]
#
# note: the mapping for reads/writes from KNX is done as follows:
# - for KNX read, the precedence on picking the ebus message is: active read, passive read+write.
# - for KNX write, the precedence on picking the ebus message is: active write only.
broadcast/outsidetemp/ = 1/1/7
hc/sumflowsensor/ = 1/1/8

​

[johnm]

1.
Die Outsidetemperatur wird ja ständig im EBUS "geupdatet". Der Wert geht aber nicht "von alleine" Richtung KNX. Abrufen geht. Von selbst kommt nichts.

Sollten nicht auch Daten von selbst Richtung KNX geschrieben werden wenn diese vom EBUS kommen?

eigentlich schon, allerdings auch nur, wenn sich der Wert wirklich ändert.

2.
Wie kann ich Daten von KNX auf den EBUS schreiben? Schreibe ich nur den Wert über die Gruppenadresse und EBUSD macht dann den Rest? Also z.B. bei "Speicher-Wunschtemperatur" schreibe ich auf die KNX-Gruppenadresse "nur" eine "50" (wenn ich 50 Grad will). Muss ich noch was beachten?

genau so. man muss natürlich auf den Datentyp achten. Am einfachsten mal nen Wert abholen, dann sieht man ja schon das Format.

[gibsonrocker]

Hallo John,

entschuldige die verspätete Rückmeldung. Es funktioniert jetzt seit 2 Tagen! Das Hauptproblem dürfte gewesen sein, dass ich die Adresse nicht vergeben hatte.

Ich habe mich in dem Zuge auch entschieden komplett von meinem Windows-Host mit Virtual Box weg zu gehen und habe jetzt einen ProxMox-Server und ebusD in einem LXC-Container laufen und Debian.

Seither läuft es. Das Grundproblem war aber sicher mein Unwissen über das Zusammenspiel ebusD <-> knxD. Und die Fehler die Du mir genannt hast.

Danke für Deine Hilfe!

Leider bin ich nur ein Stück weiter bzw. ich habe noch Fragen.

1.
Ich kann im knx.cfg-File Gruppenadressen eintragen und diese auch per ETS abfragen. Es kommt dann auch die "richtige" Antwort aus dem ebus zu KNX. Sehr cool!

Die Outsidetemperatur wird ja ständig im EBUS "geupdatet". Der Wert geht aber nicht "von alleine" Richtung KNX. Abrufen geht. Von selbst kommt nichts.

Sollten nicht auch Daten von selbst Richtung KNX geschrieben werden wenn diese vom EBUS kommen?

2.
Wie kann ich Daten von KNX auf den EBUS schreiben? Schreibe ich nur den Wert über die Gruppenadresse und EBUSD macht dann den Rest? Also z.B. bei "Speicher-Wunschtemperatur" schreibe ich auf die KNX-Gruppenadresse "nur" eine "50" (wenn ich 50 Grad will). Muss ich noch was beachten?

vg, Bernd

[gibsonrocker]

Hi John, Danke für Deine Antwort. Ich melde mich in den nächsten Tagen. Ich muss/will mir dafür Zeit nehmen. Ich versuche so schnell wie möglich alles zu checken.

Danke Dir.
vg, Bernd

[johnm]

...
Also sollte knxd und ebus laufen. Es werden aber keine Daten auf KNX geschickt.

ich vermute, dass Deine knxd Config nicht passt, da mit "-b ip:" nur ein Multicast Client aktiviert wird. Um Traffic von IP auf TP zu routen braucht man aber das Routing Feature von knxd. Oder hast Du ebusd jetzt mit knxd Support compiliert?

Aber nochmal von vorne:
Wenn ich das jetzt richtig sehe, hast Du knxd lediglich für ebusd angeworfen, richtig?
Dein Endpoint ist aber eigentlich ein KNX Device, das regulär IP multicast kann, korrekt?
Dann brauchst Du keinen knxd und das macht dir eigentlich nur alles unnötig komplizierter.

Was in der ebusd/knx.cfg auf jeden Fall fehlt ist die Zuweisung der Adresse mittels "address = ...", da über IP Multicast sonst keine Adresse zugewiesen ist.

broadcast/datetime/outsidetemp = 4/0/106

das passt

Der Witz ist, dass wenn ich die Gruppenadresse 4/0/106 (Outsidetemp) abfrage dann kommt in der ebusd.log auch ein Fehler. Die Verbindung zu KNX sollte also da sein. Deshalb glaube ich, ich check das Mapping nicht. Der Fehler "invalid argument" könnte ja auf einen Fehler im Datentyp hindeuten. Ich weiß es aber leider nicht. Ich komme nicht drauf.

das ist ja schon mal gut, dass bei ebusd die Anfrage von KNX ankommt. Wundert mich jetzt allerdings, weil ebusd in der Konfiguration bei Dir jetzt gar keine eigene Adresse in KNX haben dürfte und insofern auch gar nicht antworten kann. Aber das klärt sich vielleicht mit den Antworten auf meine Fragen oben.

Allerdings hast Du noch einen kleinen Fehler in ebusd aufgedeckt, nämlich dass broadcast Nachrichten ja nicht aktiv vom eBUS abgerufen werden können. Das hab ich übersehen. Als Workaround müsstest Du ebusd noch einen Startparameter "--knxrage=9999" oder so mitgeben, damit der Cache für die Antwort erstmal reicht.

VG John

[gibsonrocker]

Hi johnm, bzw. alle anderen (falls es jemand am laufen hat)...

Ich kriege es nicht hin. Irgendwas versteh ich scheinbar nicht richtig. Ich habe das Gefühl, dass ich die EBUS->KNX-Config nicht verstehe. Ich habe mir das File schon zig-mal durchgelesen. Aber ich werde nicht 100% schlau aus dem "Mapping" der ebus-Daten zu den KNX Kommunikationsobjekten.

Ich fange mal von vorne an:
Das mit dem Multicast sollte jetzt passen. Ich habe knxd auf der gleichen Maschine und eine Verbindung zu KNX.

Wenn ich hier schaue habe ich Daten von KNX:

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Sep 23 10:02:05 2022 from 192.168.1.22
root@debian:~# knxtool groupsocketlisten local:
Write from 1.1.250 to 8/1/27: 01
Write from 1.1.48 to 5/0/182: 00 00
Write from 1.1.30 to 5/1/31: 01
Write from 1.1.250 to 8/1/40: 01
Write from 1.1.33 to 5/1/232: 0F 6C
Write from 1.1.34 to 4/2/0: 0C 22
Write from 1.1.30 to 5/1/31: 00
​

ebusctl find -v, spuckt mir Werte aus. Also läuft ebus.

root@debian:~# ebusctl read outsidetemp
10.688​

Also sollte knxd und ebus laufen. Es werden aber keine Daten auf KNX geschickt.

Anbei meine Configs:

knxd.conf

# configuration for knxd.service
# KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip:"

KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -c -b ip:224.0.23.12"

# configuration for knxd.service using new configuration format in /etc/knxd.ini
# use only this line if you used knxd_args to convert your old startup options
# KNXD_OPTS=/etc/knxd.ini

# The default options are "-u /tmp/eib -b ip:"
# which tell knxd to route between all of
#  /tmp/eib (legacy socket (-u))
#  multicast client (-b ip:).
# knxd's own bus address is 0.0.1; it will assign 0.0.2…0.0.9 to clients.
# The knxd.socket file also tells knxd to listen to
#  /run/eib (socket activation via systemd)
#  TCP port 6720 (socket activation via systemd)
# You *need* the -e option. Clients cannot connect without "-E".

# You can read knxd's logs with
# $ journalctl -u knxd --since "10 min ago"
# (or whatever). See the manpage for details.
# You need to be a member of the "adm" group.
# Add "-f9 -t1023" to the beginning of the command line for extensive logging.

# *** DO NOT use "-u" / "-u /run/knx" or "-i" / "-i 6720" here.
# Systemd already does that on behalf of knxd, via 'knx.socket'.

# *** DO NOT use both "-RS" and "-b ip:" (unless you specify a
# different multicast address on one of them). You'd create a loop.

# If you have KNX hardware on a serial port or USB, add the appropriate
# "-b TYPE:…" option. In this case, you probably want to set up a multicast
# server, not a client (i.e. use "-D -T -R -S", not "-b ip:").
# DO NOT use both.
#
# If your KNX hardware is a KNX/IP gateway that doesn't do multicast,
# use "-b ipt:192.168.1.2" (or its DNS name) to talk to it.
#
# KNX MUST NOT have more than one path between any two devices. Thus,
# you need to make sure that the KNX/IP gateway does not route multicast
# before you use both "-S" and "-b ipt:".

# The default bus address of knxd is 0.0.1. If that's in use in your KNX
# network (or if you run more than one knxd on your network), set a
# different address, for example "-e 7.0.99".

# You should have a block of free addresses on your KNX bus which knxd can
# assign to clients: "-E 7.0.100:28" will use 7.0.100 through 7.0.127.
# If no such range is given, or if it's full, knxd uses its own address.
# That mostly works, but separate addresses are much better.

# Run `knxd --help` to get a complete list of available options and drivers.

## DO NOT use the following options:
## -i           -- /lib/systemd/system/knxd.socket does this for us
## -u /run/knx  -- likewise
## -d           -- /lib/systemd/system/knxd.service expects knxd to run in the foreground
## -p PIDFILE   -- please use systemctl to control knxd

###############################################################################
# This file is ignored when NOT using systemd: edit /etc/default/knxd instead #
###############################################################################
​

/etc/default/ebusd

# /etc/default/ebusd:
# config file for ebusd service.

# Options to pass to ebusd (run "ebusd -?" for more info):
# EBUSD_OPTS="--scanconfig"

# EBUSD_OPTS="--scanconfig=full -d enh:192.168.1.155:9999 --knxurl= --knxint=/etc/ebusd/knx.cfg"

EBUSD_OPTS="--scanconfig=full -d enh:192.168.1.155:9999 --knxurl= --knxint=/etc/ebusd/knx.cfg"

# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"

# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
​

/etc/default/knxd

# Defaults for knxd initscript
# sourced by /etc/init.d/knxd
# installed at /etc/default/knxd by the maintainer scripts

########################################################################
# This file is ignored when using systemd: edit /etc/knxd.conf instead #
########################################################################

# start knxd when /etc/init.d/knxd start is run
# by default knxd does NOT start. set to YES to enable
START_KNXD=NO

# Additional options that are passed to the Daemon.
#
# sane default: route between local KNX clients and multicast
DAEMON_ARGS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -u /var/run/knx -i -b ip:"

# The default options are "-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip:"
# which tell knxd to route between all of
#  /tmp/eib (legacy socket (-u))
#  multicast client (-b ip:).
# knxd's own bus address is 0.0.1; it will assign 0.0.2…0.0.9 to clients.
# The knxd.socket file also tells knxd to listen to
#  /run/eib (socket activation via systemd)
#  TCP port 6720 (socket activation via systemd)

# You *need* the -e option. Clients cannot connect without "-E".
# *** DO NOT use "-u" / "-u /run/knx" or "-i" / "-i 6720" here.
# Systemd already does that on behalf of knxd, via 'knx.socket'.

# DO NOT use "-RS" and "-b ip:" at the same time (unless you specify a
# different multicast address on one of them). You'd create a loop.

# If you have KNX hardware on a serial port or USB, add the appropriate
# "-b TYPE:…" option. In this case, you probably want to set up a multicast
# server, not a client (i.e. use "-D -T -R -S", not "-b ip:").
# DO NOT use both.
#
# If your KNX hardware is a KNX/IP gateway that doesn't do multicast,
# use "-b ipt:192.168.1.2" (or its DNS name) to talk to it.
#
# KNX MUST NOT have more than one path between any two devices. Thus,
# you need to make sure that the KNX/IP gateway does not route multicast
# before you use both "-S" and "-b ipt:".

# The default bus address of knxd is 0.0.1. If that's in use in your KNX
# network (or if you run more than one knxd on your network), set a
# different address (-e 15.0.99).


# Run `knxd --help` to get a complete list of available options and drivers.

## DO NOT use the following options:
## -d           -- /etc/rc.d/knxd aleady does that for us
## -p PIDFILE   -- /etc/rc.d/knxd aleady does that for us

/etc/ebusd/knx.cfg

# Configuration file for ebusd KNX integration with knxd (https://github.com/knxd/knxd).

# Use this file with ebusd to establish a bridge between KNX and eBUS for a set of messages.
# The commandline options to ebusd should contain e.g.:
# --knxurl=ip:localhost --knxint=/etc/ebusd/knx.cfg

# Currently only reading from and writing to group addresses as defined here is supported.
# Setting the addresses via ETS is not (yet) possible as well as setting the physical address.
# All entries are set to group address flags as follows:
# - for read and passive write messages: "Read", "Transmit"
# - for active write messages: "Write", "Read" (only answered when value was written before via KNX or eBUS), no "Update"

# The physical address depends on how knxd is configured and might change each time ebusd and/or knxd is restarted when
# a range of possible client addresses were configured on knxd side (which is recommended when there is more than one
# client using knxd).

# the own individual address (only relevant when running in KNXnet/IP mode)
# address = 1.1.1

# the global value group assignments for running, version, signal, uptime, updatecheck, and scan.
# running: 1 bit, 1=running, DPT 1.002
global/running = 4/0/100
# version: 2 octets, major in MSB, minor in LSB, DPT 217.001 "DPT_Version"
global/version = 4/0/101
# signal: 1 bit, 1=signal acquired, DPT 1.002
global/signal = 4/0/102
# uptime: 4 octets int, seconds since start, sent once every hour, DPT 12.100
global/uptime = 4/0/103
# updatecheck: 1 bit, 1=update available, DPT 1.002
global/updatecheck = 4/0/104
# scan: 1 bit, 1=running, DPT 1.002
global/scan = 4/0/105


# the message field value group assignments by circuit/message/field name.
# the value coding depends on the field datatype and currently only numeric datatypes are supported.
# the mapping is as follows:
# - BI0:1 - BI7:1, length 1: 1 bit, DPT 1
# - without divisor:
#   - BI0 - BI6, length >1: 1 octet, unsigned, DPT 5.010
#   - UCH: 1 octet, unsigned, DPT 5.010
#   - SCH, D1B: 1 octet, signed, DPT 6.010
#   - UIN, UIR, PIN: 2 octet, unsigned, DPT 7.001
#   - SIN, SIR: 2 octet, signed, DPT 8.001
#   - U3N, U3R, ULG, ULR: 4 octet, unsigned, DPT 12.001
#   - U3N, U3R, SLG, SLR: 4 octet, signed, DPT 13.001
# - with divisor:
#   - BI0 - BI6, length >1: 2 octet, signed float, DPT 9.*
#   - UCH, SCH, D1B, UIN, UIR, SIN, SIR: 2 octet, signed float, DPT 9.*
#   - U3N, U3R, ULG, ULR, SLG, SLR: 4 octet, signed float, DPT 14.*
# - with or without divisor:
#   - D1C, D2B, D2C, FLT, FLR: 2 octet, signed float, DPT 9.*
#   - EXP, EXR: 4 octet, signed float, DPT 14.*
#
# note: the float conversion from ebus to KNX may loose precision due to the KNX DPT 9 not being able to carry more than
# two digits after the decimal point and having a mantissa of only 11 bits.
# Consequently, when writing a 2-octet float to ebusd, a consecutive read on the same group address is likely to reveal
# a different value if it was using more than two digits after the decimal point or exceeding the KNX float mantissa
# range, e.g.:
# - an ebus D2B value of 10.004 will read as 10.00 2-octet float on KNX,
# - an ebus UIN with divisor 100 (like heating curve) value of 655.34 will read as 655.04 2-octet float on KNX,
# - writing a KNX 2-octet float value of 12.34 to an ebus UIN with divisor 10 will actually write 12.3 and read as 12.3.
#
# note: writing to ebus via KNX currently is only possible if the ebus message contains a single field respectively at
# most one non-ignored field. this is due to otherwise the value to be set for the other fields would have to be
# determined first which is mostly not possible. Group associations to write messages not fulfilling this requirement
# are silently ignored.
#
# note: the mapping for reads/writes from KNX is done as follows:
# - for KNX read, the precedence on picking the ebus message is: active read, passive read+write.
# - for KNX write, the precedence on picking the ebus message is: active write only.

broadcast/datetime/outsidetemp = 4/0/106
​

Der Witz ist, dass wenn ich die Gruppenadresse 4/0/106 (Outsidetemp) abfrage dann kommt in der ebusd.log auch ein Fehler. Die Verbindung zu KNX sollte also da sein. Deshalb glaube ich, ich check das Mapping nicht. Der Fehler "invalid argument" könnte ja auf einen Fehler im Datentyp hindeuten. Ich weiß es aber leider nicht. Ich komme nicht drauf.

2022-09-27 12:18:02.668 [update notice] received unknown MS cmd: 1008b5120204ff / 00
2022-09-27 12:18:02.892 [update notice] received update-read broadcast outsidetemp QQ=10: 10.688
2022-09-27 12:18:10.551 [update notice] received read bai Status01 QQ=10: 30.0;-;13.688;0.0;49.0;off
2022-09-27 12:18:10.835 [update notice] received update-write bai SetMode QQ=10: auto;27.0;50.0;-;0;0;0;0;0;0
2022-09-27 12:18:20.585 [update notice] received read bai Status01 QQ=10: 30.0;-;13.688;0.0;49.0;off
2022-09-27 12:18:20.866 [update notice] received update-write bai SetMode QQ=10: auto;27.0;50.0;-;0;0;0;0;0;0
2022-09-27 12:18:25.030 [knx notice] received read request from 11fc to 206a for broadcast/datetime/outsidetemp
2022-09-27 12:18:25.030 [bus error] prepare message part 0: ERR: invalid argument
2022-09-27 12:18:30.568 [update notice] received read bai Status01 QQ=10: 30.0;-;13.938;0.0;49.0;off​

Kannst Du mir bitte noch einmal helfen? Ich habe echt alles versucht.

vg, Bernd

[gibsonrocker]

Hi John,

Danke für Deine schnelle Antwort und die Hilfe bei den Einstellungen. Das mit Multicast erklärt schon mal einen Teil. Ich habe die Clients unter Virtual Box und da geht wohl Multicast nicht "einfach so". Das schaue ich mir aber die Tage noch an. Wenn nicht, dann mache ich es einfach über knxd. Dann sollte es auf jeden Fall gehen.

Ich werde berichten! Danke Dir....

vg, Bernd

[johnm]

EBUSD_OPTS="--scanconfig=full -d enh:192.168.1.155:9999 --knxurl=ip:192.168.1.100 --knxint=/etc/ebusd/knx.cfg"

Die 192.168.1.100 ist mein KNX IP Router von MDT.

"ip:192.168.1.100" wäre das Format für eine knxd Verbindung.
Standardmäßig (wenn Du ebusd nicht selbst compiliert hast), steht aber nur Routing zur Verfügung, d.h. Dein Router muss Multicast Routing können (sollte er). Damit wäre dann der Parameter auf "--knxurl=" (ja, wirklich leer!) zu setzen, wenn dein Host, auf dem ebusd läuft, nur 1 IP Interface hat. Bei mehreren muss stattdessen "--knxurl=@IP" genommen werden, wobei statt "IP" die IP Adresse des Hosts in dem Netzsegment mit dem KNX Router einzusetzen ist.

[gibsonrocker]

was hast Du denn für einen Endpunkt, also hast Du einen KNX Router im Netz hängen oder knxd am Laufen?
Du musst auf jeden Fall "--knxurl=" als Startparameter zu ebusd hinzufügen, sonst wird KNX gar nicht aktiviert.

Ich habe gedacht mit der neuen Version brauche ich kein KNXD mehr auf der Maschine. Aber was heißt "oder"? Brauche ich gar keinen KNXD wenn ich einen IP-Router im Netz habe? Ich habe einen KNX-Router (MDT SCN-IP100.02) im Netz. Meine ebusD Config Zeile sieht jetzt so aus:

EBUSD_OPTS="--scanconfig=full -d enh:192.168.1.155:9999 --knxurl=ip:192.168.1.100 --knxint=/etc/ebusd/knx.cfg"

Die 192.168.1.100 ist mein KNX IP Router von MDT.

Die Gruppenadresse überwache ich mit der ETS. Kommt aber nie was an.

ebusD läuft super. Die Daten kommen von der Heizung an.