NEWS
KNX Adapter überholt
-
Ich bin auf den neuen RasPi umgestiegen weil IOBroker mit 1G Ram nach wenigen Tagen laufzeit nicht mehr brauchbar läuft. Die vorige Installation war ca. 1 Jahr alt, Backup übertragen hat nicht funktioniert. Deswegen nutze ich die Gelegenheit ein neues System aufzusetzen, inkl. meiner KNX Installation.
Erste Hürde ist wieder der KNX Import. Ich habe jetzt viele Objektstati manuell editiert weil die KNX Objekte von Iobroker nicht geschrieben werden konnten.Um mir die Zeit zu sparen würde ich gerne Verstehen wie der Adapter gedacht ist so dass ich mir die ganze händische Arbeit spare.
In der Anleitung steht:
In dem ETS Export sind die Schalt- und Statusadressen nicht hinterlegt. Somit führe ich eine Ähnlichkeitsprüfung aller Gruppenadressnamen durch mit der Auswertung auf status und state. Wird ein Pärchen gefunden, dessen Ähnlichkeit mehr als 90% beträgt, dann wird angenommen, das die GA1 die Schaltadresse und GA2 die Statusadresse ist. Dabei erhält GA1 das write=true und read=false und GA2 das write=false und read=true.Wie wird bei 2 ähnlichen GAs GA1 und GA2 ermittelt? Ist GA1 die Adresse die zuerst gefunden wird, z.B. anhand lexikografischer Ordnung?
Ausserdem werden die DPT abgeglichen aus der jeweilig korrespondierenden GA. Aus diesem Grund ist es schwierig, Pärchen zu finden, wenn die Gruppenadressbeschriftungen nicht konsistent sind.Wie und was wird abgeglichen? Was kommt dabei heraus?
Was ist der Sinn dahinter, sollen nur Schaltadressen schreibbar gemacht werden? Bei mir trift die Logik - eine Statusadresse mit einer Schaltadresse - in so gut wie keinem Fall zu. z.B. Jalousiekator, der hat ein Kommando zum auf oder ab Verfahren oder Position anfahren. Zustände gibt es oben erreicht, unten erreicht, fährt hoch, runter, etc.
Wäre es nicht sinnvoller alle Adressen schreibbar zu machen? Warum passiert das nicht per Default?Wichtig ist wie der Entwickler des Adapters hier schon geschrieben hat, eine saubere Einrichtung und Einstellung des ETS Projektes. Dazu gehört auch das richtige setzen der Datentypen, der K L S Ü A Flags und die Zuordnung der KNX Bauteile in Räume und Gewerke.
So sieht das z.b. bei mir in der der ETS aus:
Und im IoBroker dann wie folgt:
Alle Adressen schreibbar zu machen ist Unsinn.
-
Wichtig ist wie der Entwickler des Adapters hier schon geschrieben hat, eine saubere Einrichtung und Einstellung des ETS Projektes. Dazu gehört auch das richtige setzen der Datentypen, der K L S Ü A Flags und die Zuordnung der KNX Bauteile in Räume und Gewerke.
So sieht das z.b. bei mir in der der ETS aus:
Und im IoBroker dann wie folgt:
Alle Adressen schreibbar zu machen ist Unsinn.
@ecki945 danke für die Antwort. Mein Projekt ist so sauber wie möglich, allerdings habe ich es auf drei ETS Projekte aufgeteilt. Um die resultierenden Probleme aufzulösen müsste ich wissen wie der KNX Import funktioniert. Ich schaue mir deswegen nur Kommunikationsbeziehungen zwischen Geräten in meinem Master Projekt an.
0/1/57 hat einen Sender und einen Empfänger.
Der Bewegungsmelder sendet und ändert den Wert.
IOBroker soll den Wert empfangen.
Damit die Werte beim Export nicht weggefiltert werden habe ich eine Repräsentation von IOBroker im ETS angelegt. Ich hoffe mal das fehlende K Flag stört nicht.
Das macht der Import daraus:
Warum will er hier senden und empfangen? Wie ist die generelle Logik - wann fühlt sich der Import angesprochen ein L oder S Flag zu setzen?
Wie wird das Ü Flag gesetzt- zusammen mit L pauschal?Ein sauberer Weg wäre gewesen IOBroker als Gerät in der ETS Konfig auftauchen zu lassen, der Nutzer stellt die Kommunikationsbeziehungen im geeigneten Tool sauber dar und der Import muss nicht anfangen zu raten.
Support us
753
Online32.6k
Benutzer82.1k
Themen1.3m
Beiträge