Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
nehme an es liegt an den zwei Feldern und dem 'ok'?
Code:
mxxxxs@ebusd:~ $ ebusctl find -f Ntc1Sensor
r,vms,Ntc1Sensor,NTC 1 Sensor,,06,b509,0d0500,temp,s,D2C,,°C,Temperature in solar flow (from solar collector),sensor,s,UCH,0=ok;85=circuit;170=cutoff,,Fühlerstatus
Hatte das eigentlich so verstanden, dass durch die Angabe von temp nur das erste Feld mit dem Zahlenwert an die GA übergeben wird? So müsste es doch eigentlich funktionieren? Wo ist mein Denkfehler?
Zuletzt geändert von Hantago; 30.12.2022, 21:37.
Grund: Problem gelöst
Scroll mal nach oben. Genau das gleiche hatte ich auch....
OK, ich war zunächst nicht sicher weil ich der Meinung war Du hättest zusätzlich auch noch knxd am laufen.
Aber ich bin jetzt ein bisschen weiter, verstanden hab ich es ehrlich gesagt noch nicht aber mit try & error habe ich mich jetzt etwas vorgearbeitet.
meine /etc/ebusd/knx.cfg sieht jetzt so aus. Angepasst habe ich nur die (phy.) Adresse und die outsidetemperatur die scheinbar auf temp2 kommt, warum auch immer:
Damit kann ich zumindest im Gruppenmonitor die GA abfragen und komme den Wert zurück. Jetzt beobachte ich mal, ob ich auch regelmäßig bzw. bei Änderungen der Aussentemperatur etwas im Gruppenmonitor sehe.
Aber ganz ehrlich, verstanden habe ich die Materie noch lange nicht.....
ich habe letze Woche meinen ebus3 WIFI Adapter bekommen und der läuft mit ebusd problemlos. Jetzt bin ich dabei zu versuchen die Daten direkt auf den KNX Bus zu senden, allerdings kommt auf dem Bus nichts an. Eine Verbindung scheint es aber zu geben, denn ich sehe im log (/var/log/ebusd.log) folgende Meldung, wenn ich in der ETS die GA lesen will:
022-11-15 13:56:31.531 [knx notice] received read request from ff01 to 2a01 for broadcast/datetime/outsidetemp
2022-11-15 13:56:31.531 [bus error] prepare message part 0: ERR: invalid argument
Ich habe einen Enertex KNXnet/IP Router.
Vielleicht hat ja jemand einen Tipp oder sieht sofort wo ich einen Fehler gemacht habe.
Meine /etc/default/ebusd sieht wie folgt aus:
cat /etc/default/ebusd
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
äh, wie jetzt genau? Meinst Du mit "meine USB Schnittstelle" das KNX Interface?
Nein, da hast du mich falsch verstanden. Damit meinte ich meine separate Gira USB Schnittstelle, mit der ich in der ETS den Bus beobachtet habe.
Den KNXD habe ich nicht angefasst, der hat seine eigene Schnittstelle zum KNX.
Ich denke ich habe es jetzt verstanden. Ich werde ebusd nochmal neu kompilieren.
Muss ich beim selbst kompilieren noch etwas beachten, damit ich die Version mit dem knxd Support erhalte?
Wird zukünftig das Release auch den KNXD Support erhalten?
Ich habe auch mal angefangen die KNX Funktion zu testen, scheitere aber bei der Verbindung zum KNXD. Ich habe aktuell keinen KNX-IP Router und nutze ausschließlich den KNXD (für Node-Red und Homebridge). Programmieren in der ETS kann ich damit auch. Multicast sollte eigentlich funktionieren, da ich auch zum testen mal nen Shelly mit Tasmota-KNX laufen habe und der funktioniert (Das funktioniert ja auch mit Multicast, wenn ich das richtig verstanden habe).
Wenn ich in der /etc/default/ebusd folgendes eintrage:
2022-10-15 07:24:24.700 [knx error] multicast addr
Anstelle der IP-Adresse habe ich es mit localhost versucht, kommt aber das Selbe raus.
Also nochmal: es gibt entweder die Möglichkeit via IP multicast anzubinden, dann kann man ein ebusd Release verwenden. Oder man nimmt die ebusd Quellen und kompiliert mit knxd Support, dann kann man auch eine TCP Verbindung zu knxd verwenden.
Das spiegelt sich entsprechend in der KNX URL wieder. Übrigens hilft es durchaus, "ebusd --help" aufzurufen, denn da sieht man, welche URLs prinzipiell möglich sind.
Beim ebusd release ist das laut Hilfe ausschließlich
Code:
"[multicast][@interface]" for KNXnet/IP
, also optional Multicastadresse gefolgt von optional "@" plus Interface Adresse. Die ist wichtig, wenn der Host mehr als ein IP Interface hat und das Routing für Multicast nicht oder nicht richtig konfiguriert ist. Also bspw. wenn "ip a" auf dem Host zeigt, dass es neben dem localhost Interface noch zwei Interfaces mit Adressen bspw. 192.168.1.100 und 172.29.1.100 gibt und der KNX/ip multicast Router im Netz von 172.29... hängt, dann würde man "--knxurl=@172.29.1.100" verwenden müssen.
Bei einem selbst kompilierten ebusd mit knxd Support hat man dann zusätzlich noch die Möglichkeit, direkt den knxd TCP Port zu verwenden (normalerweise auf Port 6720), d.h. dann könnte man via "--knxurl=ip:10.10.10.10" mit knxd auf dem Host mit Adresse 10.10.10.10 verbinden (statt KNX/ip Multicast) oder sogar dessen Unix Domain Socket ansprechen via "--knxurl=local:/run/knx", sofern knxd auf dem lokalen Host läuft und dessen Socket offen ist.
EBUSD_OPTS="--scanconfig -c /etc/ebusd/ --mqtthost=10.0.5.77 --mqttport=1883 --mqttjson --mqtttopic=ebusd/%circuit/%name --knxurl --knxint=/etc/ebusd/knx.cfg"
und bekomme folgenden Log-Eintrag:
2022-10-15 07:30:15.532 [knx notice] connected to KNXnet/IP multicast
Allerdings kommt nichts auf dem Bus an und auf Lese-Anfragen aus der ETS wird auch nicht reagiert.
des Weiteren ist in dieser Konstellation der KNXD auch nicht mehr in der ETS erreichbar (nutze dann meine USB-Schnittstelle)
äh, wie jetzt genau? Meinst Du mit "meine USB Schnittstelle" das KNX Interface? Damit kann ebusd natürlich nichts anfangen (ist ja schließlich kein knxd), also unbedingt mit "-d /dev/tty..." das richtige Device für ebusd konfigurieren. So ist es klar, dass knxd kein KNX mehr machen kann, wenn Du dem sein Device wegnimmst. Ich vermute stark, dass /dev/knx ein Symlink auf /dev/ttyUSB0 ist.
Somit gibts natürlich auch keinen KNX Traffic mehr. Also bissl genauer hinschauen bitte
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?
Das Feld muss zwingend angegeben werden wegen der Zuordnung. Hat ein Feld einer Message keinen Namen (z.B. laut "ebusctl find -f ..."), dann lässt sich das Feld via Index nutzen, also einer Zahl ab 0 aufsteigend.
2. Frage:
Wie ist das KNX debug Log zu verstehen? Ich kann die Einträge in der Logdatei nicht deuten.
Code:
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
naja also erstmal ist es ein debug log, sprich normalerweise hat man das nicht aktiv, wenn ebusd in Betrieb ist. Anyway, es wird in diesem Level auch von KNX empfangener Traffic protokolliert und man kann daran z.B. sehen, wenn read oder write von KNX zwar ankommen, aber mangels Zuordnung zu eBUS Nachrichten nicht von ebusd beantwortet werden wie in den beiden beispielhaften Zeilen oben. "unsubscribed" ist der Hinweis auf KNX Nachrichten ohne die Zuordnung zu eBUS.
Ja, das habe ich mehrmals gelesen, aber ehrlich gesagt nicht ganz verstanden.
Den KNXD habe ich schon lange laufen.
Ebusd habe ich nicht neu kompiliert, sondern
via apt upgrade auf die neueste Version gehoben.
Weißt du was damit gemeint war? Muss ich ggf noch etwas nachinstallieren?
eine physikalische Adresse habe ich aber auch in der knx.cfg vergeben. Hat leider keine Änderung gebracht.
Er hat keinen IP-Router. Deshalb braucht er knxd. Zumindest wenn ich es richtig verstanden habe.
Andreas, hast Du oben gelesen was John mir geschrieben hat als ich meine Fehlerversuche hatte? Zwecks ebus mit knxd kompilieren, etc..? Ich habs ja auch nicht ganz verstanden. Aber da solltest Du evtl. was rauslesen können.
Wenn du eine Multicast Verbindung hast, benötigst du den knxd nicht. Musst aber in der knx.cfg eine physikalische Adresse angeben.
Dann solltest du die ebusd global Variablen mit passenden Gruppenadressen versehen und auch ggf. die Filtertabellen in Kopplern aktualisieren. Dann solltest du beim Start von ebusd auch die globalen Infos auf dem Bus sehen.
Ich habe auch laaaange probiert
Hallo Zusammen
Ich habe auch mal angefangen die KNX Funktion zu testen, scheitere aber bei der Verbindung zum KNXD. Ich habe aktuell keinen KNX-IP Router und nutze ausschließlich den KNXD (für Node-Red und Homebridge). Programmieren in der ETS kann ich damit auch. Multicast sollte eigentlich funktionieren, da ich auch zum testen mal nen Shelly mit Tasmota-KNX laufen habe und der funktioniert (Das funktioniert ja auch mit Multicast, wenn ich das richtig verstanden habe).
Wenn ich in der /etc/default/ebusd folgendes eintrage:
2022-10-15 07:24:24.700 [knx error] multicast addr
Anstelle der IP-Adresse habe ich es mit localhost versucht, kommt aber das Selbe raus.
Dann habe ich einfach mal die ip weggelassen:
EBUSD_OPTS="--scanconfig -c /etc/ebusd/ --mqtthost=10.0.5.77 --mqttport=1883 --mqttjson --mqtttopic=ebusd/%circuit/%name --knxurl --knxint=/etc/ebusd/knx.cfg"
und bekomme folgenden Log-Eintrag:
2022-10-15 07:30:15.532 [knx notice] connected to KNXnet/IP multicast
Allerdings kommt nichts auf dem Bus an und auf Lese-Anfragen aus der ETS wird auch nicht reagiert.
des Weiteren ist in dieser Konstellation der KNXD auch nicht mehr in der ETS erreichbar (nutze dann meine USB-Schnittstelle)
Zur Vollständigkeit hier noch meine Konfiguration des KNXD:
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: