[wiregate] Probleme bei Programmierung mit der ETS5

[blaubaerli]

Hallo zusammen,

bis dato hatte ich das Forum nur "lesend" zur Vorbereitung meiner Renovierungsvorbereitung genutzt. Zunächst mal besten Dank an all diejenigen, die hier mit ihrem KnowHow Neuligen wie mir das Leben extrem erleichtern.

Nun versuche ich nach und nach die erworbenen Komponenten in Gang zu bringen und bin jetzt an dem Punkt angelangt, dass ich hier meine erste Frage in die Runde werfen muss.

Zunächst mal meine Komponentenliste:

• WireGate Multifunktionsgateway (Patchlevel 38.1)
• KNX-Interface für Wiregate 1 Multifunktionsgateway mit USB-Schnittstelle
• 1-Wire Busmaster / USB Hostadapter DS9490R
• diverse 1-Wire-Sensoren
• ETS 5.0.1 (Build 902) - als ETS5 Lite Lizenz
• SOMFY Jalousieaktoren KNX/EIB 4 AC Motor
• Merten - 617519 - Taster 4fach plus mit IR-Empfänger
• Windows 7 Professional (64 Bit)
• FireWall ist während aller Tests deaktiviert
• Es ist die von der ETS eigenständig erkannte "eibd on WireGate"-Verbindung in Benutzung

Die 1-Wire-Seite läuft einwandfrei!
Die Programmierung der KNX-Komponenten mit der ETS 5 über das WireGate macht mir aber nun leider richtig Stress.
Die üblichen Verdächtigen kann ich Dank der bisher gelesenen Formusbeiträge hoffentlich ausschließen:

In der Konfig des eibd auf dem WireGate ist Tunneling aktiviert (Routing nicht). Die PA passt zur Linie im ETS-Projekt.

Das Programmieren der PA einer jungfräulichen KNX-Komponente über die Funktion des WireGate klappt einwandfrei. Die Programmier-LED erlischt eigenständig nach dem Vorgang.

Aber das Programmieren aus der ETS klappt einfach nicht sauber.
Wenn ich den Sensor, dem ich über das WireGate die PA 1.1.10 sauber zugewiesen habe, dann mittels ETS programmieren will - Programmieren (Physikalische Adresse & Applikationsprogramm) - bekomme ich die beigefügte Fehlermeldung. Zwischendurch sehe ich in der ETS mal die Meldung "Gerät wird neu gstartet". Aber mehr auch nicht. Die anderen Programmieroptionen sind übrigens auch nicht hilfreicher.

Hier dazu die relevante Passage aus dem /var/log/eib.log:

2014-10-18 23:10:41.655,,1.1.10,1.1.254,,,,,0,system,6,T_DISC ONNECT_REQ,0
2014-10-18 23:10:46.138,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:10:46.167,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:10:49.151,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:10:52.165,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:10:55.175,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:10:55.184,A_PhysicalAddress_Response,1.1.10,0/0/0,00,,,,0,system,6,T_DATA_XXX_REQ,0
2014-10-18 23:10:58.158,,1.1.254,1.1.10,,,,,0,system,5,T_CONN ECT_REQ,0
2014-10-18 23:11:04.181,,1.1.10,1.1.254,,,,,0,system,6,T_DISC ONNECT_REQ,0
2014-10-18 23:11:09.175,,1.1.254,1.1.10,,,,,0,system,5,T_CONN ECT_REQ,0
2014-10-18 23:11:15.189,,1.1.10,1.1.254,,,,,0,system,6,T_DISC ONNECT_REQ,0
2014-10-18 23:11:19.675,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:11:19.704,A_PhysicalAddress_Response,1.1.10,0/0/0,00,,,,0,system,6,T_DATA_XXX_REQ,0
2014-10-18 23:11:22.928,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:11:22.961,A_PhysicalAddress_Response,1.1.10,0/0/0,00,,,,0,system,6,T_DATA_XXX_REQ,0
2014-10-18 23:11:22.976,A_PhysicalAddress_Response,1.1.10,0/0/0,00,,,,1,system,6,T_DATA_XXX_REQ,0
2014-10-18 23:11:26.184,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:11:26.208,A_PhysicalAddress_Response,1.1.10,0/0/0,00,,,,0,system,6,T_DATA_XXX_REQ,0
2014-10-18 23:11:29.452,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:11:29.461,A_PhysicalAddress_Response,1.1.10,0/0/0,00,,,,0,system,6,T_DATA_XXX_REQ,0
2014-10-18 23:11:32.684,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-18 23:11:32.713,A_PhysicalAddress_Response,1.1.10,0/0/0,00,,,,0,system,6,T_DATA_XXX_REQ,0

Dieses Read/Response-PingPong geht dann Ewigkeiten, ohne sinnvolles Ergebnis. Habe es dann nach einer Stunde abgebrochen. Für den Mini-KNX-Testaufbau kann das doch nicht sein, oder?

Was mach ich falsch? Hat jemand eine gute Idee? Ich hoffe nicht, dass die ETS 5 das Problem ist. Das Teil ist ja noch recht neu.

Beste Grüße aus Kerpen

Euer Blaubaerli

[makki]

Ich hatte noch keine Gelegenheit mit der ETS5 zu testen (der KNX-Standard hat sich jedoch seither nicht wesentlich verändert )

Gibts weitere Erfahrungen von anderen mit der ETS5 ?

Makki

[Robert_Mini]

Ich hatte das 1x auch unter ETS3f nachdem ich einen Programmiervorgang abgebrochen hatte. Das Gerät hat dann nicht mehr gestartet und beim Programmieren diese Meldung verursacht.
Lösung war Buskabel vom Gerät nehmen, 30s warten und dann PA+Applikation neu programmieren. Möglicherweise hilft zusätzlich auch Entladen des Geräts.

Lg
Robert

[blaubaerli]

Hi Robert_Mini,

leider klappt das auch nicht stabil. Wenn ich in der ETS5 im Hauptmenü unter "Bus-Physikalische Adressen-Programmiermodus" auswähle, wird jedes Gerät das ich in dann wieder in den Programmiermodus versetze mit seiner PA dargestellt. Auch beim "Linien-Scan" werden alle PA's erkannt. Egal, ob jene die ich über das WireGate gesetzt habe, oder diejenigen die über den abgebrochen Programmiervorgang aus der ETS gesetzt wurden.

Will ich aber über "Bus-Diagnose-Gerät entladen" den Entladevorgang starten, erhalte ich die Meldung "Das Gerät mit der physikalischen Adresse x.x.x wurde nicht gefunden" (Screeshot im Anhang). Verrückt ist dabei, dass ich hier ja keine Adresse vorgebe, sondern das zu entladende Gerät per Programmiertaste identifiziere. Trotzdem wird in dem Dialog die korrekte Adresse angezeigt. Im Log des WireGate stellt sich das dann wie folgt dar:

2014-10-19 11:17:15.584,A_PhysicalAddress_Read,1.1.254,0/0/0,00,,,,0,system,5,T_DATA_XXX_REQ,0
2014-10-19 11:17:15.613,A_PhysicalAddress_Response,1.1.3,0/0/0,00,,,,0,system,6,T_DATA_XXX_REQ,0
2014-10-19 11:17:18.564,,1.1.254,1.1.3,,,,,0,system,5,T_CONNE CT_REQ,0
2014-10-19 11:17:24.587,,1.1.3,1.1.254,,,,,0,system,6,T_DISCO NNECT_REQ,0
2014-10-19 11:17:29.571,,1.1.254,1.1.3,,,,,0,system,5,T_CONNE CT_REQ,0
2014-10-19 11:17:35.592,,1.1.3,1.1.254,,,,,0,system,6,T_DISCO NNECT_REQ,0

Anlog verhält sich der Dialog "Bus-Diagnose-Geräteinfo". Hier gebe ich allerdings die Adresse vor. Danach kommt in der ETS die identische Meldung. Die Einträge des Logs sind entsprechend folgende:

2014-10-19 11:26:59.614,,1.1.254,1.1.3,,,,,0,system,5,T_CONNE CT_REQ,0
2014-10-19 11:27:05.637,,1.1.3,1.1.254,,,,,0,system,6,T_DISCO NNECT_REQ,0
2014-10-19 11:27:10.673,,1.1.254,1.1.3,,,,,0,system,5,T_CONNE CT_REQ,0
2014-10-19 11:27:16.695,,1.1.3,1.1.254,,,,,0,system,6,T_DISCO NNECT_REQ,0

Also klappt derzeit mehr oder weniger über die ETS mal gar nichts. Auch das Entladen nicht. Gibts hier ne Methode über das WireGate?

Beste Grüße

Blaubaerli

[makki]

Ähm, also nur damit ich das richtig verstehe: du drückst die Prog.-Taste und willst das Gerät dann "entladen"?

Hab ich noch nie ausprobiert aber versuchs doch mal ohne Prog.-Taste -> die ist nur zum programmieren der PA notwendig!
Und immer nur ein Gerät in der gesamten Topologie darf diese gedrückt haben..

Edit: viele der "Diagnose-Sachen" gehen nicht über KNXnet/IP, nur mit einer lokalen Schnittstelle an der ETS. Also Tipp: Gruppenmonitor statt Busmonitor verwenden etc..

Makki

[blaubaerli]

Hallo Makki,

die "Entladen"-Option findet sich ja an mehreren Stellen in der ETS. Z. B. im Kontextmenü der jeweiligen Komponente und via "Bus-Diagnose-Gerät Entladen". Egal welche Variante ich wähle, die ETS fordert mich immer zum Drücken des "Programmierknopfes" auf (siehe Screenshot).

Im Gruppenmonitor spiegelt sich dann das Bild aus der /var/log/eib.log wider.

Beste Grüße

Blaubaerli

[makki]

Hmm. das sieht bei ET3 & ETS4 anders aus.
Ich habe wiegesagt leider keine ETS5 zur Hand (bzw. kein Windows 7, weil die gekaufte, lizensierte Version grad nicht in der VM startet) sonst würde ich es testen.

Ich vermute aber ehrlichgesagt eher einen Gerätedefekt oder Verständniss-/Bedien-/Topologie-problem als eines mit der ETS5 und/oder WireGate.

Der KNX hat sich mit der ETS5 ja nicht geändert und der Disconnect kommt vom Gerät(!)

Grüsse Makki

P.S.: Natürlich kann es sein, das sich die ETS5 mal wieder (wäre nicht das erste mal!) neue "Eigenheiten" zugelegt hat, daher auch die Frage an alle: Erfahrungen zum Thema:
mit ETS5 & via WireGate/eibd 0.0.5 programmieren?

[blaubaerli]

Hallo Makki,

das mit dem Verständnisproblem mag schon sein...

Den Gerätedefekt schließe ich aktuell mal noch aus. Da ich sowohl von den Sensoren, als auch von den Aktoren jeweils mehr als 1 Stück habe und sich die Teile identisch verhalten.

Ich habe aktuell nur ein Miniprojekt zum Test angelegt und dort nur den einen Sensor aus der Produktdatenbank eingefügt. Es ist noch nichts an GA's oder Verbindungen zugewiesen. Ich habe nur eine Linie und die hat als Topologie TP.

Da dürfte nach meinem bisherigen Verständnis noch nicht viel Potential für Verständnisfehler drinstecken, oder? Die PA vergibt die ETS ja automatisch und das Programmieren sollte doch so dann schon klappen, oder verstehe ich da grundsätzlich noch was falsch?

Beste Grüße

Blaubaerli

[makki]

Zum Thema Topologie: da kann man schon Fehler machen (auch wenn die meisten vom WG - teils absichtlich - grösszügig ignoriert werden) - betrachte das mal wie einen KNXnet/IP Router/Schnittstelle ohne PA.

Faktisch ist die TP Linie hier 1.1, also das übergeordnete KNXnet/IP Backbone zwangsläufig 0.X - evtl. ist die ETS5 hier etwas "genauer".. Glaub ich aber ehrlichgesagt nicht.

Gehen denn andere Geräte? Optimalerweise anderer Hersteller/Typ..
Oder, ich tippe jetzt mal ins blaue: Windows/Personal-Firewall des Virenscanners(?)

Makki

[blaubaerli]

Hallo Makki,

da scheinen wir dem Problem ja ggf. schon näher zu kommen. Wenn ich ein neues Projekt erstelle, muss ich hier bei der Backbone-Topologie TP oder IP wählen? Bisher läuft meines als TP. Weil ich davon ausgegangen bin, dass mein reines KNX-Netz ja über TP läuft. Wenn ich mal eines mit IP anlege, wird beim Programmierversuch eine netter Dialog (siehe Screenshots) angezeigt. Bei dessen Beantwortung habe ich dann aber leider auch wieder Probleme. Was muss ich hier denn dann bei der Physikalischen Adresse eintragen? Die Maskenversion ist nicht editierbar. Was hat es denn damit auf sich?

Firewall ist aus! Geräte sind unterschiedliche. Merten Sensor und Somfy-Aktor. Identisches Verhalten.

Beste Grüße

Blaubaerli

[makki]

Ich muss da vorsichtig sein, da ich zwar den KNX Standard ganz gut kenne, aber nicht die ETS5.. (vermutlich hats aber garnichts damit zu tun)

Also:
- Falls WG als KNXnet/IP Tunneling-Schnittstelle dürfte die Einstellung "TP" richtig sein.
- Falls KNXnet/IP Routing (einfach mal probieren? natürlich vorher auch im WG aktivieren, es kann beides!) ist "IP Backbone" technisch richtig.

Dumme Frage: Sind die Geräte auch zertifiziert? Bei Merten sicher, also nimm zum testen mal lieber den, sehe auf den Gruppenmonitor/eib.log.
Vergleiche: kommt da alles an, was im eib.log steht? (ich tippe immernoch auf FW..)

Du hast ja einige Infos (löblich!) für meine Glaskugel geliefert (Alfred, wo ist der Glaskugel-Smiley? Der war so Klasse!), aber mehr gibt sie momentan nicht her.

Makki

[MatthiasS]

Doppelpunkt wahrsagen

[vento66]

Meinst den?
gibt es mit

 :wahrsagen

[vento66]

shit 2.

[makki]

Danke,
Matthias 1.
Micha 2.

Was an so schön ist: die Glaskugel braucht halt alle Infos: Schnittstelle, *alle* Geräte (Edit: Details, Bestellnummer, ..), Windows X?, ...

Makki