CUxD-Einstellungen für Eltako FGW14-USB

Anbindung von FS20-Komponenten, ELV-Wetterstationen, EnOcean und DMX an HomeMatic

Moderator: Co-Administratoren

mittelhessen
Beiträge: 162
Registriert: 24.07.2015, 21:39

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mittelhessen » 19.12.2020, 12:01

Oh je, das hätte ich vorher wissen sollen. An der Hardware habe ich nichts geändert. Ich habe ja lediglich die Zeilen schon mal vorbereitet. Von SSH habe ich keine Ahnung.

mpcc
Beiträge: 639
Registriert: 09.03.2007, 16:38
Wohnort: Eichwalde bei Berlin
Hat sich bedankt: 2 Mal
Danksagung erhalten: 17 Mal
Kontaktdaten:

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mpcc » 19.12.2020, 12:11

Dann bleibt nur eine Fernwartung
Hast du SSH in der CCU angehakt und ein Passwort vergeben ?

Termin machen wir via PN aus ...
Gruss Marco Pniok
http://www.piotek-smarthome.de, eQ-3 Fachpartner, Joonior Systemintegrator, PEHA EnOcean, Eltako-Partner, Viessmann Vitocontrol200 Partner, HomeMatic, HomeMatic IP, PioTek-Tracker , IP-Symcon, Symbox, IPS-Studio, Wibutler ....

mittelhessen
Beiträge: 162
Registriert: 24.07.2015, 21:39

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mittelhessen » 19.12.2020, 20:15

Nun habe ich die Betriebsart des FGW14-USB auf "6" (also 57600 Baud) gestellt, in der Hoffnung, dass sich CUxD wieder fängt. Trotz Neustart der CCU und des Eltakobus ist das aber leider nicht der Fall. Spielt es eine Rolle, an welchem physikalischen USB-Anschlusss der Raspberrymatic das FGW14-USB, das FAM14-USB und ein USB-Stick hängen?

SSH habe ich aktiviert, allerings ohne Passwort. Einen Benutzernamen kann ich dort ja gar nicht vergeben. Also habe ich die Verbindung mal ohne Benutzernamen und Passwort versucht. Das funktioniert aber genauso wenig, wie wenn ich ein Passwort vergebe.

Wegen der Fernwartung gebe ich Dir Bescheid.

mittelhessen
Beiträge: 162
Registriert: 24.07.2015, 21:39

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mittelhessen » 20.12.2020, 10:43

Ein kleines Stückchen weiter bin ich gekommen. Dass ich mich nicht per SSH verbinden konnte, lag schlichtweg daran, dass man bei der Verbindungsherstellung als Benutzername "root" eingeben muss. Als Newbie wusste ich das bis dato nicht. Die cuxd.ini habe ich gefunden und erstmal die TTYPARAM rauseditiert. Siehe da, CUxD läuft erstmal wieder stabil! 8) Als nächstes habe ich im Setup die folgende Ergänzung vorgenommen:
KEY=EO:1234567890
TTYPARAM=ttyUSB1:57600
TTYASSIGN=ttyUSB1:ESP3
KEY=EO:0987654321
TTYPARAM=ttyUSB2:57600
TTYASSIGN=ttyUSB2:ESP2
Im Statusfenster wird nun folgendes ausgegeben:
USB 1-1 - (2514) [HUB] - Sun Dec 20 10:34:54 2020
USB 1-1.1 - (2514) [HUB] - Sun Dec 20 10:34:54 2020
USB 1-1.1.1 - (7800) [FF] - no driver - Sun Dec 20 10:34:54 2020
USB 1-1.1.3 - Ultra Fit [STORAGE] - Sun Dec 20 10:34:54 2020
USB 1-1.2 - {NONE} FAM V2.4 [FF] - /dev/ttyUSB0 - Sun Dec 20 10:34:54 2020
USB 1-1.2+1 - {ESP3} FAM V2.4 [FF] - /dev/ttyUSB1 [R] {:75s} - TCM SW 2.15.1.0, API 2.6.12.0, CID xxxxxxxx - KEY - Sun Dec 20 10:34:54 2020
USB 1-1.3 - {ESP2} FT232R USB UART [FF] - /dev/ttyUSB2 [R] {:75s} - FGW14, ID xx - KEY - Sun Dec 20 10:34:54 2020
Es sieht aus, als wäre das Ganze nun startbereit. Irgendwie scheinen da jetzt noch Reste (.../dev/ttyUSB0...) von vorherigen Anschlüssen/Tests drin zu sein. Um das Ganze schön zu machen, kann mir jemand vielleicht noch verraten, wir ich die Nummerierung der ttyUSB0 lösche/neu sortiere?!

mpcc
Beiträge: 639
Registriert: 09.03.2007, 16:38
Wohnort: Eichwalde bei Berlin
Hat sich bedankt: 2 Mal
Danksagung erhalten: 17 Mal
Kontaktdaten:

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mpcc » 20.12.2020, 12:27

mittelhessen hat geschrieben:
20.12.2020, 10:43
Im Statusfenster wird nun folgendes ausgegeben:
USB 1-1 - (2514) [HUB] - Sun Dec 20 10:34:54 2020
USB 1-1.1 - (2514) [HUB] - Sun Dec 20 10:34:54 2020
USB 1-1.1.1 - (7800) [FF] - no driver - Sun Dec 20 10:34:54 2020
USB 1-1.1.3 - Ultra Fit [STORAGE] - Sun Dec 20 10:34:54 2020
USB 1-1.2 - {NONE} FAM V2.4 [FF] - /dev/ttyUSB0 - Sun Dec 20 10:34:54 2020
USB 1-1.2+1 - {ESP3} FAM V2.4 [FF] - /dev/ttyUSB1 [R] {:75s} - TCM SW 2.15.1.0, API 2.6.12.0, CID xxxxxxxx - KEY - Sun Dec 20 10:34:54 2020
USB 1-1.3 - {ESP2} FT232R USB UART [FF] - /dev/ttyUSB2 [R] {:75s} - FGW14, ID xx - KEY - Sun Dec 20 10:34:54 2020
Es sieht aus, als wäre das Ganze nun startbereit. Irgendwie scheinen da jetzt noch Reste (.../dev/ttyUSB0...) von vorherigen Anschlüssen/Tests drin zu sein. Um das Ganze schön zu machen, kann mir jemand vielleicht noch verraten, wir ich die Nummerierung der ttyUSB0 lösche/neu sortiere?!
Ja so ist jetzt alles OK :)
"Reste" sind das nicht sondern die anderen "Geräte" wie wohl auch ein USB Speicherstick. Das lässt du alles bitte so und
versuchst auch nicht irgendetwas zu "löschen" oder zu "sortieren". Wenn du das alles so lässt wird das stabil laufen.

Wir werden in der CUxD Entwicklung sicher noch etwas tun , damit dass in Zukunft besser klappt (Anschlüsse)

Wenn weitere Fragen sind stellst du Sie bitte auch hier ...
Gruss Marco Pniok
http://www.piotek-smarthome.de, eQ-3 Fachpartner, Joonior Systemintegrator, PEHA EnOcean, Eltako-Partner, Viessmann Vitocontrol200 Partner, HomeMatic, HomeMatic IP, PioTek-Tracker , IP-Symcon, Symbox, IPS-Studio, Wibutler ....

mittelhessen
Beiträge: 162
Registriert: 24.07.2015, 21:39

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mittelhessen » 28.12.2020, 11:47

Nach den Feiertagen, hier zunächst der noch ausstehende, ausfühliche Statusbericht des bisherigen Standes. Bevor ich mich um die Einbindung der 14er-Aktoren in CUxD gekümmert habe, hatte ich als Grundlage erstmal den Eltako-Bus sauber durchadressiert. Hier lag noch einiges im Argen, so dass dies erstmal die Basis für das weitere Vorgehen war. Inzwischen läuft der Eltako-Bus (fast) "sauber". "Fast" deshalb, weil sich ein einziger Aktor nicht beschreiben lässt, sobald der Abschlusswiderstand auf dem letzten Aktor ordnungsgemäß aufgesteckt ist. Sobald der Abschlusswiderstand entfernt wird, läuft alles bestens. Im Betrieb habe ich den Abschlusswiderstand allerdings stets aufgesteckt. Das Problem habe ich beim Eltako-Support gemeldet, aber eine Rückmeldung dazu ist erst im neuen Jahr zu erwarten.

Zunächst das grundlegend Positive: Alle 14er-Aktoren konnte ich in CUxD anlegen, in die Homematic übernehmen und lassen sich einwandfrei bedienen.

Momentan hänge ich etwas an der Zuverlässigkeit betreffend der Rückmeldungen der Aktoren. Als BiDi-Code habe ich in allen Kanälen die dezimale Adresse des Kanals im Eltako-Bus gefolgt von einem "." eingetragen und gespeichert. CUxD wandelt den dezimalen Code automatisch in einen hexadezimalen Code um (was natürlich bei den ersten Adressen erstmal gar nicht auffällt). Sehr wichtig für die Rückmeldungen ist dann ja noch der obere BA-Drehschalter des FAM14. Hierzu kommen nur folgende Positionen in Frage:

Pos. 2: zyklische Abfrage von Bestätigungstelegrammen nach Scan-Liste (mit Versand in den Gebäudefunk)
Pos. 3: zyklische Abfrage von Bestätigungstelegrammen nach Scan-Liste (ohne Versand in den Gebäudefunk)
Pos. 4: zyklische Abfrage von Bestätigungs- und Statustelegrammen nach Scan-Liste (ohne Versand in den Gebäudefunk)
Pos. 5: zyklische Abfrage von Bestätigungstelegrammen nach mit PCT14 eingetragener Geräteliste im FAM14 (mit Versand in den Gebäudefunk)
Pos. 6: zyklische Abfrage von Bestätigungstelegrammen nach mit PCT14 eingetragener Geräteliste im FAM14 (ohne Versand in den Gebäudefunk)
Pos. 7: zyklische Abfrage von Bestätigungs- und Statustelegrammen nach mit PCT14 eingetragener Geräteliste im FAM14 (ohne Versand in den Gebäudefunk)

Mit PCT14 habe ich im FAM14 alle Aktoren in die Geräteliste eingetragen. Demnach sollte es keine Rolle spielen, ob ich die Pos. 2-4 oder 5-7 wähle. Rückmeldungen in den Gebäudefunk benötige ich (bisher) nicht, da das FGW14-USB mit der Raspberrymatic verkabelt ist und ich bisher noch keine EnOcean- Sensoren oder Aktoren einsetze. Der Unterschied zwischen Bestätigungs- und Statustelegrammen ist mir bisher allerdings nicht klar. Meinem Verständnis nach, könnte es sein, dass die Aktoren Bestätigungstelegramme einmalig nach der Änderung ihres Status versenden, während sie Statustelegramme zyklisch versenden. Den oberen BA-Drehschalter des FAM14 habe ich deshalb in Pos. 4. Da ich nicht weiß, ob es hier einen Zusammenhang mit dem Haken der "Zyklischen Statusmeldung" des jeweiligen Aktors gibt, habe ich für alle Aktoren die "Zyklische Statusmeldung" aktiviert, was meinem Verständnis nach hoffentlich keine Probleme verursachen sollte. Hierzu bitte ich jedoch unbedingt um Rückmeldung, ob das so ok ist!

Im CUxD-Statusfenster sieht man, dass der Status alle Aktoren zyklisch aktualsiert wird. Hinter dem hexadezimalen BiDi-Code steht immer ":1s" bis ":5s", woraus sich für mich schließen lässt, dass alle Aktoren zyklisch im Abstand von ca. 1-5 Sekunden abgefragt werden. AUSNAHME sind die FSB14 Aktoren, die offenbar nicht zyklisch abgefragt werden, sondern deren Status sich nur bei einer Bedienung des jeweiligen Aktors ändert, siehe unterer Auszug aus dem CUxD-Statusfenster. Eine Servicemeldung über einen nicht erreichbaren Aktor habe ich, entgegen der CUxD-Anleitung, auch nach über 60 Minuten noch nicht bekommen. Im Wesentlichen habe ich das Problem, dass die Status-LED am Bustaster eingeschaltet bleibt, wenn der Rollo nur über Homematic bedient wird. Auch wenn der Rollo vollständig herab und anschließend vollständig herauf gefahren wird bleibt die Status-LED am Bustaster dauerhaft eingeschaltet. Bei Hoch- und Runterfahren mit dem Bustaster selbst, funktioniert die Status-LED korrekt. Es scheint also so, als bekäme sie bei Steuerung über Homematic nur mit, wenn der Rollo heruntergefahren wird, nicht aber wenn er (vollständig) hochgefahren wird.
CUX3600001: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(0:00000002:4s) id2(1:00000003:4s) id3(2:00000004:4s) id4(3:00000005:4s)
CUX3600002: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(4:00000006:4s) id2(5:00000007:4s) id3(6:00000008:4s) id4(7:00000009:3s)
CUX3600003: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(13:0000000F:3s) id2(14:00000010:3s) id3(15:00000011:3s) id4(16:00000012:3s)
CUX3600004: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(17:00000013:3s) id2(18:00000014:3s) id3(19:00000015:3s) id4(20:00000016:3s)
CUX3600005: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(21:00000017:3s) id2(22:00000018:3s) id3(23:00000019:3s) id4(24:0000001A:3s)
CUX3600006: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(25:0000001B:2s) id2(26:0000001C:2s) id3(27:0000001D:2s) id4(28:0000001E:2s)
CUX3600007: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(32:00000022:2s) id2(33:00000023:2s) id3(34:00000024:2s) id4(35:00000025:2s)
CUX3600008: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(36:00000026:2s) id2(37:00000027:2s) id3(38:00000028:2s) id4(39:00000029:2s)
CUX3600009: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(40:0000002A:2s) id2(41:0000002B:2s) id3(42:0000002C:1s) id4(43:0000002D:1s)
CUX3600010: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(52:00000036:1s) id2(53:00000037:1s) id3(54:00000038:1s) id4(55:00000039:1s)
CUX3600011: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(56:0000003A:1s) id2(57:0000003B:1s) id3(58:0000003C:1s) id4(59:0000003D:0s)
CUX3600012: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(60:0000003E:0s) id2(61:0000003F:0s) id3(62:00000040:0s) id4(63:00000041:0s)
CUX3600013: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(64:00000042:0s) id2(65:00000043:0s) id3(66:00000044:0s) id4(67:00000045:0s)
CUX3600014: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(68:00000046:0s) id2(69:00000047:0s) id3(70:00000048:0s) id4(71:00000049:0s)
CUX3600015: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(72:0000004A:4s) id2(73:0000004B:4s) id3(74:0000004C:4s) id4(75:0000004D:4s)
CUX3601001: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(8:0000000A:3s)
CUX3601002: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(29:0000001F:2s)
CUX3601003: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(44:0000002E:1s)
CUX3601004: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(45:0000002F:1s)
CUX3601005: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(46:00000030:1s)
CUX3601006: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(47:00000031:1s)
CUX3602001: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(9:0000000B:1h) id2(10:0000000C:1h)
CUX3602002: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(11:0000000D:1h) id2(12:0000000E:1h)
CUX3602003: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(30:00000020:1h) id2(31:00000021:1h)
CUX3602004: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(48:00000032:1h) id2(49:00000033:1h)
CUX3602005: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(50:00000034:1h) id2(51:00000035:1h)

mittelhessen
Beiträge: 162
Registriert: 24.07.2015, 21:39

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mittelhessen » 04.01.2021, 14:06

Da ich bezüglich der FSB14 nicht weitergekommen bin, habe ich alle fünf FSB14 mit "Gerät von CCU löschen !" aus CUxD und damit auch von der CCU gelöscht und sicherheitshalber einen anschließenden Reboot der CCU vorgenommen. Anschließend habe ich die FSB14 in CUxD wieder als neue Geräte angelegt, in der CCU übernommen und wieder parametriert. Ergebnis: Alle FSB14 funktionieren einwandfrei, inkl. Rückmeldung, solange man per Homemativ ansteuert. Eine Ansteuerung über die Eltako-Taster, bekommt die Homematic nicht mit, da ja noch die Rückmeldeadressen eingetragen werden müssen. Also habe ich die Rückmeldeadressen eingetragen und siehe da: alles funktioniert (momentan) so wie es soll.

Was nun der Fehler war, lässt sich im Nachhinein nicht herausfinden. Wichtig ist, dass das Ablernen und erneute Anlernen, scheinbar nun alles geradegezogen hat.

Wie im vorher dargstellten Ausschnitt des CUxD-Statusfensters, werden meine FSB14 allerdings weiterhin nicht zyklisch aktualisiert. Solange alle Rückmeldungen aber einwandfrei funktionieren, stört mich das nicht.

Benutzeravatar
uwe111
Beiträge: 4266
Registriert: 26.02.2011, 22:22
Danksagung erhalten: 73 Mal
Kontaktdaten:

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von uwe111 » 05.01.2021, 17:45

mittelhessen hat geschrieben:
04.01.2021, 14:06
Wie im vorher dargstellten Ausschnitt des CUxD-Statusfensters, werden meine FSB14 allerdings weiterhin nicht zyklisch aktualisiert.
Nach spätestens 60min sollte der CUxD aktiv eine Statusabfrage machen. Kannst Du das mal bitte prüfen?

Viele Grüße

Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.5, SSH KeyDir

mittelhessen
Beiträge: 162
Registriert: 24.07.2015, 21:39

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mittelhessen » 05.01.2021, 17:50

Hallo Uwe,

ich würde sagen, dass dem nicht so ist. Wie man im folgenden Status sieht, stehen da zwei Kanäle dabei die länger nicht bedient wurden und inzwischen auf 18h bzw. 6h stehen.
CUX3602001: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(9:0000000B:1h) id2(10:0000000C:1h)
CUX3602002: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(11:0000000D:26m) id2(12:0000000E:18h)
CUX3602003: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(30:00000020:33m) id2(31:00000021:33m)
CUX3602004: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(48:00000032:34m) id2(49:00000033:34m)
CUX3602005: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(50:00000034:33m) id2(51:00000035:6h)

mittelhessen
Beiträge: 162
Registriert: 24.07.2015, 21:39

Re: CUxD-Einstellungen für Eltako FGW14-USB

Beitrag von mittelhessen » 19.01.2021, 22:09

Hallo Uwe, bist Du mit der Thematik schon irgendwie weitergekommen? Inzwischen habe ich auf CUxD 2.5.1 aktualisiert, aber am Verhalten hat sich nichts geändert. Die FSB14 werden weiterhin nicht zyklisch (auch nicht nach 60 Minuten) abgefragt. Ich gehe davon aus, dass da bei dem Minor-Update auch nichts geändert wurde.

Zu einigen FSB14 in meinem Bus habe ich unregelmäßig, aber wiederholt, eine gestörte Gerätekommunikation im Status. Ob es da einen Zusammenhang zu den nicht ausgeführten, zyklischen Statusmeldungen gibt, weiß ich nicht. Bei allen anderen Aktoren des Typs FSR14-4x, F4SR14-LED und FUD14 hatte ich noch keinerlei Statusmeldungen zur gestörten Gerätekommunikation.

Antworten

Zurück zu „CUxD“