NEWS
Test Adapter KNX v1.0.x
-
@AndreasK Hi Andreas
Ich bin gerade auch am herum spielen da ich meine KNX Aktoren gerne über Home von Apple schalten möchte.
Leider verzweifle ich schon an dem "einfachen" Aus und Ein schalten eines Kanals.KNX funktioniert bei mir sonst einwandfrei, auch meine Gira Home App ist wunderbar eingerichtet.
Geräte werden bei mir in der Home App angezeigt und theoretisch kann ich es auch schalten....nur passieren tut halt nichtsDas ganze läuft bei mir auf einem Synology Server mit iobroker.
Hast du vielleicht einen Tip für mich?
lg Daniel
-
Hi @Graydens,
bei mir läuft alles auf einem Raspberry.
Zusammen mit dem yahka-Adaper geht es bei mir wunderbar.
Hast du den yahka fertig eingerichtet und im HomeKit angemeldet?
Du musst für jede Leuchte usw, immer ein eigenes Gerät anlegen mit dem dazugehörigen Dienst. Du kannst nicht pro Gerät mehrfach den gleichen Dienst-Typ verwenden. Ggf. liegt es ja daran.
Also z.B. einen Gerät Wohnzimmer Leuchten anlegen und dann dort mehrfach den Dienst bulb hinzufügen. Das funktioniert nicht. Also pro Leuchte ein Gerät und ein Dienst.Ich bin bei dem Thema Verknüpfungen noch nicht weitergekommen. Hast du einen Tipp hierzu? Siehe mein Poste vorher
-
@AndreasK said in Test Adapter KNX v1.0.x:
@Garfonso said in Test Adapter KNX v1.0.x:
Dann sind bei dir Dimmwert und Dimmwert-Status im ioBroker nicht verknüpft. Dafür sorgen, dass alle SchaltGAs mit den passenden StatusGAs verknüpft sind, dann gehen auch die Updates überall, so wie du es willst.
Wie kann ich die Verknüpfung erstellen und wo?
Ich möchte ungern einen weiteren Adapter installieren um dieses ggf. zu lösenDie Verknüpfung erstellt der Adapter automatisch beim Import von Projekten aus den Namen der Gruppenadressen (inklusive Mittelgruppen und ggf. Hauptgruppen?) -> die müssen ähnlich genug sein. Am besten unterscheiden die sich nur durch ein angehängtes
Status
oderRM
.
Das ist relativ viel Arbeit in ETS, wenn man das einmal macht, hat man es aber dann.Alternativ kann man im Raw-Editor der Objekte die IDs hin und her kopieren. Geht auch, wenn man sich relativ sicher ist, dass man keinen neuen Import mehr benötigt (oder nur von neuen GAs). -> das ist beides hier im Thread schon mehrfach erläutert worden.
-
Hallo zusammen,
ich konnte bisher viel Infos und Hilfe aus dem "stillen Studium" dieses und anderer Foren ziehen. Dafür vorab vielen Dank an alle Aktiven!!!
Ich oute mich als ETS Lite Nutzer. Bisher konnte ich mit den Einschränkungen gut leben und habe meine kompletten KNX Geräte (ca. 60) auf mehrere (5) Projekte aufgeteilt. Die GA-Struktur habe ich einmal angelegt und dann in alle Projekte importiert. Diese ist somit konsistent.
Beim Import in den KNX Adapter liefern nur die GA sinnvolle Werte, die im importierten Projekt verwendet werden. Entsprechend liefern wiederum andere Werte, wenn ich eben ein anderes Projekt importiere. Mit sehr großer Wahrscheinlichkeit liegt das daran, dass die read/write Flags und die DPT von der ETS nicht gesetzt und vom Adapter somit nicht sinnvoll importiert werden können. Das sehe ich auch in dem raw Reiter der Objekte, die sich je nach importiertem Projekt unterscheiden.
Ich sehe mich nun schon dabei, alle Objekte einzeln von Hand zu bearbeiten.
Gibt es denn eine Best-Practice-Alternative für ETS Lite Nutzer mit mehreren Projekten? -
@znaeb
passiert das denn auch, wenn du "nur neue Objekte importieren" (oder so) anhakst? Eigentlich sollten sich die alten dann ja nicht ändern, oder? grübelMan kann in der Objekteansicht auch irgendwie ganze Objektbäume exportieren, vielleicht kann man die auch irgendwo importieren und das würde funktionieren statt manueller Bearbeitung? grübel
-
"nur neue Objekte importieren" habe ich nicht getestet. Da ja alle GA in jedem Projekt enthalten sind, dürfte es zu keinem Zeitpunkt "neue Objekte" geben.
Was mich gerade verwirrt: Ich weiß nicht mehr mit welchem Projekt ich gestern abend keine Lust mehr hatte und was ich manuell geändert habe und was nicht. Ich war gestern recht frustriert. Aber die Grafana Logs der letzten 2 Tage zeigen auf die Schnelle eigentlich durchweg plausible Werte an. Das muss ich nochmal prüfen.
Ich hatte eigentlich gehofft, dass es für den Fall mit mehreren Projekten einen bekannten Workaround gibt
-
Guten Morgen,
ich hätte da gleich noch ein Verständnisproblem zu den Flags.
Ein Objekt wird aus einer GA erzeugt. Diese GA verknüpft einen Sensor mit einem Aktor. Die KOs in Sensor und Aktor müssen nicht zwangsläufig die gleichen Flags gesetzt haben. Ich kenn zwar die Tabelle zum setzen der read/write Flags aus der Doku des KNX Adapters, aber an welchen Flags orientiere ich mich dabei. Sensor oder Aktor?
-
Hallo zusammen,
ich möchte nochmal mein Problem mit den Rollladenaktoren und dem KNX Adapter Version >1.0.20 aufgreifen und hören, ob es sich bereits irgendwie gelöst hat.Das Problem: Mit dem KNX Adapter >1.0.20 kann ich keine Rollladen (Rollotube X-Line) steuern, Bool Geräte wie Licht funktionieren jedoch. Die Rollladenaktoren laufen im DPT5.001 und lassen es zu direkte Fahrpositionen ansteuern.
Folgendes konnte ich im Debug-Level im Log Fenster nun herausfinden: Bis KNX Adapter 1.0.20 bekomme ich beim steuern der Rollläden GroupValueWrite -> Rollladen fährt.
Sobald ich eine größere Version verwende erhalte ich GroupValueRead, beim steuern der Rollläden. Ich nutze ETS 5.7.3
Vielleicht hat jemand ähnliche Probleme oder der Entwickler hat inzwischen eine Lösung für das Problem gefunden. Ich würde sehr gern 1.0.42 in Zukunft als KNX Adapter nutzen.Danke schonmal im Voraus!
-
Welche Version nutzt du denn eine größer als die 1.0.20 oder genau die?
Ich habe ein ähnliches Problem bei einer höheren Version. Nutze daher die 1.0.20 und damit geht alles -
@ThaBam
Ich habs mit jeder verfügbaren Version >1.0.20 probiert, keine funktioniert, zu letzt mit 1.0.42, daher nutze ich auch noch weiter die 1.0.20. -
@Jasmin83 said in Test Adapter KNX v1.0.x:
Folgendes konnte ich im Debug-Level im Log Fenster nun herausfinden: Bis KNX Adapter 1.0.20 bekomme ich beim steuern der Rollläden GroupValueWrite -> Rollladen fährt.
Sobald ich eine größere Version verwende erhalte ich GroupValueRead, beim steuern der Rollläden. Ich nutze ETS 5.7.3Funktioniert es denn nicht, wenn du mit 1.0.20 den Import machst und dann erst das Adapter Update?
Ich habe mit einigen GAs (teilweise auch Rolladen) das gleiche Problem, aber wenn der Import mit 1.0.20 (bzw. "nur neue Objekte" und keine Rolladen betroffen) war, dann ist auch mit neueren Versionen alles ok.Ansonsten bleibt dir die Read/Write Flags an den ioBroker Objekten zu ändern ( https://github.com/ioBroker/ioBroker.knx#3-herausfinden-der-schalt--und-statusaddressen ) -> stelle sicher, dass das read-Flag in ioBroker auf
false
steht. Das ist allerdings dann auch ein Zeichen dafür, dass Schalt- und Status-GA nicht richtig verknüpft sind (zumindest war es bei mir immer so). -
@Garfonso
Das wars, besten Dank.Also hier ist meine Lösung für das Problem: In den Fahrpositionen stand noch das Flag L für Lesen mit drin, dabei darf da nur K und S stehen, dies hab ich nun im ETS korrigiert, alles nochmal exportiert, Adapter auf 1.0.42 hochgezogen und knxproj. Datei importiert und läuft.
DANKE für die Hilfe, bzw den Denkanstoß, da hätte ich selber drauf kommen können, als ich die Sachen erstellt habe.
Endlich läuft es mit Version >1.0.20
Ist und bleibt mein wichtigster ioBroker adapter
-
bei mir klappt die automatische zuordnung leider nicht
hier mal ein beispiel meiner gruppen:
knx.0.schalten.EG.licht_abstellraum_schalten
knx.0.schalten_rm.EG.licht_abstellraum_schalten_status{ "_id": "knx.0.schalten.EG.licht_abstellraum_schalten", "type": "state", "common": { "name": "licht_abstellraum_schalten", "type": "boolean", "role": "value", "read": false, "write": true, "max": true, "min": false }, "native": { "dpt": "DPT1.001", "address": "1/1/0", "addressRefId": "P-0191-0_GA-146", "statusGARefId": "", "actGARefId": "", "update": false, "objRef": "O-10_R-256", "devName": "M-0083_A-0096-10-6467", "devInst": "P-0191-0_DI-31", "objectSize": "" }, "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1610028227123, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }
knx.0.schalten_rm.EG.licht_abstellraum_schalten_status
{ "_id": "knx.0.schalten_rm.EG.licht_abstellraum_schalten_status", "type": "state", "common": { "name": "licht_abstellraum_schalten_status", "type": "boolean", "role": "indicator", "read": true, "write": false, "max": true, "min": false }, "native": { "dpt": "DPT1.011", "address": "6/1/0", "addressRefId": "P-0191-0_GA-167", "statusGARefId": "", "actGARefId": "", "update": true, "objRef": "O-63_R-1096", "devName": "M-0083_A-0096-10-6467", "devInst": "P-0191-0_DI-31", "objectSize": "" }, "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1610028227149, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }
wie könnte ich die namen noch optimieren/anpassen dass es zugeordnet wird?
-
Hallo zusammen
Bin seit längerem auf der Suche nach einem Fehler, dem ich aber nicht richtig auf die Spur komme.
Am Abend werden bei mir die Jalousien mittels Shuttercontrol automatisch geschlossen. Das klappt nach einem KNX Adapter Restart auch alles wunderbar.
Nach ca. 1,5 - 2Wochen Dauerbetrieb, beginnt sich der KNX Adapter offensichtlich zu "verschlucken".
Er nimmt die Positionsanforderung von Shuttercontrol entgegen (255) und auch der Status wird auf geschlossen (255) geupdatet, aber bei einzelnen Jalousien schliessen die Lamellen nicht. Die betroffene Jalousie(n) sind zufällig.
Das sieht dann so aus:
Ich frage mich, warum der Status auf 255 zurück gemeldet wird, wenn doch das Objekt nach wie vor auf Status 0 steht (mittels ETS überprüft)
Wenn ich den Wert nochmals manuell sende, dann schliesst die Jalousie Lamelle korrekt.
Adapter Version ist 1.0.42
Anzahl Pakete/s : 30
IP Router ist ein ABB IPR/S2.1
Die Jalousien Schliessbefehle kommen im Abstand von 0,8 Sek.
Die Verlinkung der Objekte für Position und Position-Status ist beim Import korrekt gemacht worden.
Frage: kann sich der KNX Adapter selbst das Statusobjekt updaten? Wenn ja, in welchen Zuständen kann er das?
Ich frage mich, warum und wer setzt das Statusobjekt für die Lamelle auf 255, wenn dieses vom Aktor doch gar nie mit 255 zurückgemeldet wurde..
Für "sachdienliche" Hinweise bin ich sehr - sehr dankbar
Viele Grüsse
RoliEdit - PS. Flag Settings
Auf GA zum Fahren:
resultiert in KNX Adapter:
Auf Status GA
resultiert in KNX Adapter
-- Edit 2
Auch heute ging eine Jalousie nicht - diesmal sind die Objekte für Höhe und Lamellen betroffen.
Auch hier wurden die Werte für Höhe und Lamelle (255 = zu) gesetzt. Auch hier wurde für die Höhe 255 zurück gemeldet. Interessanterweise für die Lamelle nicht.
Die zweite Visu (Eisbär), welche ich aktuell am gleichen Router parallel am Laufen habe, hat von all dem nichts mitbekommen und zeigt den korrekten, offenen Zustand an.
Es macht mir also den Eindruck, dass nicht der ABB Router der Übeltäter ist, welcher falsche Werte zurück liefert, sondern dass dies der KNX Adapter selbst fabriziert.
@chefkoch009 : Kann es sein, dass da im Adapter FIFO, durch was auch immer, was durcheinander geraten kann?
Vielen Dank für Deine Unterstützung!
Roli -
Bei den Werten im KNX-Adapter steht jeweils minimaler Wert 0 und maximaler Wert 1, das passt doch aber nicht mit den Eigenschaftten der GA (0-255) überein, oder?
-
@snapergy said in Test Adapter KNX v1.0.x:
Bei den Werten im KNX-Adapter steht jeweils minimaler Wert 0 und maximaler Wert 1, das passt doch aber nicht mit den Eigenschaftten der GA (0-255) überein, oder?
Da hast Du absolut recht. Allerdings kommt dieses Setting vom automatischen ETS Import. Der Adapter hat dies also selbst aufgrund des Imports so angelegt. Wie geschrieben, grundsätzlich fahren sie nach einem Adapter Neustart für ca. 1,5 Wochen absolut fehlerfrei. Danach geht's los mit den Problemen. Heute wiederum eine andere Jalousie nicht geschlossen.
Den Import hatte ich ursprünglich mit der Version 1.0.36 gemacht. Habe erst vor ca. 2 Wochen geupgraded.
Frage, sind die DPT 5.010 bei Dir korrekt in Min = 0 und Max = 255 importiert worden?
Was mich auch etwas stutzig macht sind die Read / Write Flags auf dem Status. Gemäss Doku sollten beide auf true sein, wenn die Flags L und Ü im ETS gesetzt sind. Diese wurden bei mir nur mit Read = true und Write = false importiert.
Wie sieht das bei Dir aus? -
@mpl1338
vielleicht mal das _status am Ende entfernen versuchen und dann ist der "Abstand" nur noch das "_rm" von der Mittelgruppe. -
Kann mir jemand sagen, wieviele Telegramme bzw. Befehle dieser Apdater innerhalb kurzer Zeit senden/verarbeiten kann?
Ich bekomme zur Zeit immer bei Sonnenaufgang, Untergang, Anwesenheit, Abwesenheit und ähnlichen Zeitpunkten, an denen ich viele Ereignisse auf einmal Triggere folgende Meldung im Log:
knx.0 2021-01-16 10:15:36.759 info (1478) Connected - local UDP Server listening on 192.168.1.178:33211 knx.0 2021-01-16 10:15:36.756 info (1478) Using UDP with local IP: 192.168.1.178 knx.0 2021-01-16 10:15:34.765 info (1478) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0). knx.0 2021-01-16 10:15:34.760 info (1478) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0). knx.0 2021-01-16 10:15:34.755 info (1478) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
Habe das Gefühl, dass der Adapter hier "überlastet" ist und neu startet, kann das sein?
-
@loverz
Der Adapter ist vermutlich nicht überlastet sondern dein KNX <-> IP Connector. Dafür kann man in den Instanzeinstellungen des Adapters die maximale Anzahl Pakete ( = KNX Nachrichten) pro Sekunde einstellen. Wenn mehr Nachrichten reinkommen, verlangsamt der KNX Adapter dann das senden entsprechend.
Ich würde also empfehlen das bei dir mal etwas zu reduzieren. -
Hallo und ein gesundes neues Jahr 2021.
@loverz: der Adapter kann exponentiell mehr Telegramme verarbeiten als der KNX-Bus. Aus diesem Grund wird die Datenrate, wie schon beschrieben, reduziert, weil es sich gezeigt hat, das bei zu hohen Datenraten einige Gateways "umfallen".
VG
chefkoch009