selfbus.org

Hallo Fehli,

ganz so schlimm ist es ja zum Glück dann doch nicht. Bei mir laufen Komponenten von Siemens, ABB und Merten problemlos mit dem Selfbus-Komponenten zusammen.

Erst MDT macht Zicken. Hier ist natürlich guter Rat teuer, anscheinend verhält sich die Software von MDT nicht so, wie die ETS bzw. die Selfbus-Software das erwartet. Warum - in meinem Fall - der Taster plötzlich nicht mehr antwortet lässt sich ohne Debugging im Code des Tasters vermutlich nicht wirklich rausfinden

Ich werde mir zum Programmieren erst mal eine günstige andere Schnittstelle besorgen. Das tägliche Doing als IP-Schnittstelle für meine Visualisierung macht die Selfbus-Schnittstelle ja hervorragend.

MDT hat sich auf meine Anfrage hin auch schon zurück gemeldet. Mal sehen, wie kooperationsbereit die sind, wenn die hören, dass meine Schnittstelle kein offizielles KNX-Siegel hat

Beste Grüße,
Malte

Hallo zusammen,

Ich habe bei mir keinerlei Probleme im "Mischbetrieb".
Im Einsatz sind:
- Rolloaktoren (freebus)
- Relaisaktoren (freebus)
- Tasterschnittstellen (freebus)
- Eingangsmodule (selfbus)
- Argus Bewegungsmelder (merten)
- 8-fach Taster (8-Tasten und LEDs) (merten)
- 6-fach Taster (6-Tasten und LEDs) (MDT)
- UP-Dimmer (Siemens)
- 8-fach Relaisaktor (MDT)
- Spannungsversorgung incl. Drossel (Hager)

Programmieren und Automatisieren über Raspberry und FHEM. Anbindung an den Bus über TUL (Busware) und EIBD.

Bisher keine Probleme, lediglich die LPCs machen ohne Oszillator zicken schon mal, "mehrere Geräte im Programmiermodus". Möchte nach und nach mal Oszillatoren nachrüsten...

Im Moment tausche ich dann so lange die LPCs aus, bis ruhe ist. Die die rumzicken bekommen einen Farbpunkt und werden in einem Controller mit Oszillator eingesetzt.

Viele Grüße
Mochael

Hallo Elektron.

Wenn ich deinen Beitrag richtig verstehe, dann ist das TUL deine Schnittstelle.
Da ist ja genau wie beim BTM2 eine "richtige" TP-UART drauf.

Ich dachte es ging um das Raspi Modul, bzw die normale FT1.2.

Gruß fehli

Hallo zusammen,

kurzes Feedback: Busware-TPUART-Schnittstelle gekauft. Selfbus-Modul runter, Busware-Modul drauf. Das Startskript von FT1.2 auf TPUARTS geändert - läuft alles ohne Probleme.

Können irgendwelche Logfiles helfen?

Beste Grüße,
Malte

Hallo zusammen.
FT12 runter, neue FT12 aus dem repo selfbus-incubation drauf --> läuft ohne Probleme.

Es wäre schön wenn ihr den Zwischenstand mal testen könntet.
Ich konnte damit den MDT Heizungsaktor programmieren.

Hallo,

bei mir hat's geholfen. Mit der alten FW konnte ich meinen MDT 8-fach Taster nicht programmieren. Mit der neuen Version aus software-incubation funktioniert es bis dato einwandfrei... Vielen Dank für das Update!

Gruß

Nils

Hallo,

ich habe doch noch Probleme mit der FW. Der eibd bekommt beim start nur eine Rückmeldung dann ist Feierabend...

Layer 1(01AA9988,54C212A2) Open
Layer 1(01AA9988,54C212A2) Opened
Layer 2(01AB9F70,54C212A2) Open
Layer 2(01AB9F70,54C212A2) Opened
Layer 3(01ACA4B0,54C212A2) Open
Layer 2(01AB9F70,54C212A2) OpenL2
Layer 1(01AA9988,54C212A2) SendReset
Layer 1(01AA9988,54C212A2) Send(007): A9 1E 12 34 56 78 9A
Layer 0(01AA9988,54C212A2) Send(004): 10 40 40 16
Layer 1(01AA9988,54C212A2) Send(007): A9 00 18 34 56 78 0A
Layer 0(01AA9988,54C212A2) Send(004): 10 40 40 16
Layer 0(01AA9988,54C212A2) Recv(001): E5
Layer 0(01AA9988,54C212A2) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78 9A E8 16
Layer 0(01AA9988,54C212A2) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78 9A E8 16
Layer 0(01AA9988,54C212A2) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78 9A E8 16
Layer 0(01AA9988,54C212A2) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78 9A E8 16
Layer 0(01AA9988,54C212A2) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78 9A E8 16
Layer 0(01AA9988,54C212A2) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78 9A E8 16
...

Das geht dann so weiter. Nach einer Weile leuchten beide LED's des Raspberry-Moduls. Es hat aber definitiv auch schon funktioniert! Alte FW ft1_2-1-12.hex funzt...

Der eibd versucht den Kommunikationsmodus der FT1.2 umzuschalten (PEI_Switch). Das gelingt ihm nicht. Das ist Teil der Initialisierung die der eibd durchführt und hat noch nichts mit Buskommunikation zu tun.

Ok, das fällt vermutlich unter relativ unwichtiges Wissen, aber vielleicht interessiert es irgendwen

Hallo,

warum versucht der eibd das? Bei der alten FW funktioniert die Kommunikation eibd<->ft12 ja bestens nur nicht ft12<->bus. Bei der neuen FW ist es - zumindest bei mir - andersherum

Meine eibd Einstellungen lauten wie folgt:

# Device that eibd shall use
EIBD_DEVICE=/dev/ttyAMA0

# Type of the eibd device
EIBD_DEVICE_TYPE=ft12

# Options for eibd
EIBD_OPTS="--eibaddr=0.0.254 -D -T -S -i --trace=15"

Ist da was nicht korrekt?

Gruß

Nils

deeznutz hat geschrieben: warum versucht der eibd das?

Das macht der eibd immer.

Zuerst wird ein Reset gesendet: Send(004): 10 40 40 16
dann wird die FT1.2 auf einen passenden Modus geschaltet: Send(014): 68 08 08 68 73 A9 1E 12 34 56 78 9A E8 16
E5 ist die FT1.2 Bestätigung: Recv(001): E5.

Es ist durchaus normal dass am Anfang kaum (E5) Bestätigungen von der FT1.2 kommen. Vermutlich wegen dem Reset am Anfang. Aber normalerweise ist das nach ein paar Sekunden durch und danach funktioniert das normale Handshake Protokoll.

Ich versuche es mal am Abend bei mir, ich habe einen passenden Raspi am Schreibtisch liegen.