Adapter von I²C auf Multicom

Jakob · November 19, 2025, 10:43pm

Moin,

ich habe noch den “einfachen“ Core und will dort zusätzlich zu meinem Dimmy noch einen Dimmy Pro und ein In Out X Pro hinzufügen.

Da der Adapter noch lange Lieferzeit hat, habe ich mir den Kurzerhand selber gebaut.

In dem ich vom JST Stecker 3V, GND, SDA und SCL auf einen RJ45 Stecker gepatscht habe.

Die Leitung ist ca 2m lang und abgeschirmt mit verdrillten Paaren.

Nach dem Reboot öffnet sich im Browser auch die Seite, wo ich theoretisch den Dimmy und das IN Out X steuern kann.

Leider tut sich nichts, sobald der Bus angeschlossen ist, kann ich auch nicht mehr die Relais auf dem Core ansteuern, woran kann das liegen?

Habe die Belegung der Pins mehrfach gemessen, die 3,3 V kommen auch bei den Geräten an.

Habe es auch bereist solo versucht, die Geräte einzeln an zu steuern.

Kann ich den einfachen Dimmy einfach parallel mit in den BUS hängen?

rolbra70 · November 25, 2025, 5:02pm

Hallo,

Ich muss das auch noch angehen, ich habe den MaxxFan Adapter, ich habe einen RJ45 auf Schraubklemmen Adapter gekauft um es erstmal zu testen, habe aber noch keine Zeit dafür gehabt…

Mit einen Oszi könnte man das mal mitlesen…

2 Meter finde ich schon recht lang, je nachdem mit welcher Datenrate gesendet wird.

Ich würde mir das nochmal Grimpen aber nur ein kurzes Stück 50cm oder so…

i²c ist eigentlich ein Bus, und an diesen können mehrere Geräte mit unterschiedlicher ID angeschlossen werden. Meines Wissens ist eine “Sternverkabelung” schlecht. Also die Abgänge möglichst kurz halten….

Aber das Thema interessiert mich auf jeden Fall.

Gruß

Roland

ahtdf · November 25, 2025, 6:46pm

Stern Verkabelung ist kein Problem, aber möglichst kurz ist richtig. Ich hab bei mir im Bus bis 4m hat mich schon gewundert das es funktioniert.

Hier ist eine interessante Website über I²C

rolbra70 · November 25, 2025, 7:38pm

i²c ist für Kabellänge unter einem Meter entwickelt, dass es bei dir mit 4 Meter läuft hast richtig Glück, hast du am ende mehrere Geräte oder nur eins angeschlossen?

Ich weiß nicht, wie es sich mit der Kapazität und dem Widerstand verhält, evetuell reicht auf die Länge und mehreren Geräten der Pullup Widerstand nicht.

Es wir geraten den unter Umständen kleiner als 4.7k zu machen… (auf beiden Leitungen SCL & SDA)

Ich war mal so frei ChatGPT bezüglich der Eigenschaften zu Fragen:

Ich geh mal davon aus, du meinst generell: Was kann I²C elektrisch so ab, was sind sinnvolle Kabellängen, Datenraten, Pull-Ups usw.?
Ich halte es übersichtlich und praxisnah.

Grundlegende I²C-Datenraten

Typische Standard-Modi:

Standard Mode: bis 100 kHz

Fast Mode: bis 400 kHz

Fast Mode Plus: bis 1 MHz

High-Speed Mode: bis 3,4 MHz (seltener im Hobby-Bereich)

Es gibt auch spezielle Erweiterungen (z. B. FM+ für längere Leitungen), aber typischerµµ Arduino/ESP-Alltag ist 100–400 kHz.

Je länger das Kabel und je höher die Kapazität, desto niedriger sollte die Taktfrequenz sein.

Kabellänge bei I²C

Faustregeln (für typische Bastelumgebungen, z. B. ESP32, Arduino, 3,3/5 V):

Auf dem gleichen Board / kurzer Abstand (bis ca. 20–30 cm)
→ 400 kHz fast immer unkritisch.

Bis ca. 50–100 cm
→ meist noch 100–400 kHz möglich, wenn:

sauberes Kabel (Twisted Pair, z. B. Netzwerkkabel),

gemeinsame Masse,

passende Pull-Ups,

wenig Störungen (kein Motor direkt daneben).

1 m
→ wird kritisch; dann:

Takt stark reduzieren (z. B. 50 kHz oder 10–20 kHz),

saubere Verdrahtung (Twisted Pair, abgeschirmt),

evtl. spezielle I²C-Bus-Extender (P82B715, PCA9615, etc.),

ansonsten lieber andere Protokolle (UART, RS-485, CAN).

Offiziell ist I²C eher für kurze Verbindungen auf einer Platine gedacht. Alles über 1 m ist schon „Trickkiste“.

Pull-Up-Widerstände (SDA & SCL)

I²C braucht Pull-Ups an SDA und SCL, sonst funktioniert der Bus nicht zuverlässig.

Typische Werte

Für Hobby / Standard-MCUs (3,3 V oder 5 V):

Häufig: 4,7 kΩ pro Leitung

Alternativ:

10 kΩ bei sehr wenigen Devices / langsamer Bus / wenig Kapazität

2,2–3,3 kΩ bei höherer Kapazität oder höheren Geschwindigkeiten (400 kHz+)

Wichtige Punkte:

Die Pull-Ups hängen an der I²C-Versorgungsspannung (z. B. 3,3 V).

Nicht an jedem Modul noch mal starke Pull-Ups lassen – wenn viele Module jeweils 4,7 kΩ haben, wird der Gesamtwiderstand zu klein → hoher Strom / unsaubere Flanken.
→ Oft sinnvoll, auf Modulen Pull-Ups zu deaktivieren (Lötjumper) und nur einen Satz Pull-Ups am Bus zu lassen.

Wie stark dürfen die Pull-Ups sein?

Daumenregel:
Gesamt-Pull-Up-Strom pro Leitung bei Low-Pegel sollte etwa im Bereich 1–3 mA liegen, maximal ein paar Milliampere, sonst müssen die Devices zu viel Strom sinken.

Beispielrechnungen (für 3,3 V):

3,3 V / 4,7 kΩ ≈ 0,7 mA

3,3 V / 2,2 kΩ ≈ 1,5 mA

3,3 V / 1 kΩ ≈ 3,3 mA (geht schon stark in Richtung „zu viel“)

Kapazität des Busses

I²C ist auf eine maximale Buskapazität von typ. 400 pF ausgelegt (inkl. Leitungen + Eingänge der ICs).
Längere Kabel → höhere Kapazität → langsamere Flanken → Probleme bei hohen Taktraten.

Was heißt das praktisch?

Kurze Leitungen auf einer Platine: kein Problem.

1 m billiges Flachbandkabel: kann schnell ~100–200 pF erreichen.

Mehrere Meter: meist deutlich zu viel für 400 kHz.

Daher gilt:
Je länger das Kabel, desto niedriger die Frequenz und desto stärker (kleinere kΩ-Werte) die Pull-Ups – aber mit Augenmaß.

Praxis-Tipps

Wenn du konkret was planst (z. B. ESP32 ↔ Sensor im Auto / Camper):

Takt reduzieren

I²C-Clock testweise auf 100 kHz oder noch weniger stellen (z. B. 50 kHz).

Pull-Up-Widerstand wählen

Start mit 4,7 kΩ.

Wenn es instabil ist → ggf. auf 3,3 kΩ oder 2,2 kΩ runter.

Kabelwahl

Twisted Pair (z. B. CAT5/CAT6):

Paar 1: SDA mit GND

Paar 2: SCL mit GND

Damit reduzierst du Störungen.

Gute Masseführung

GND von Master und Slave(s) muss sauber verbunden sein.

Bei >1 m Distanz

Takt < 100 kHz

ggf. Bus-Extender (P82B715 etc.) oder gleich anderes Protokoll (z. B. RS-485 mit Modbus).

Wenn du magst, schreib kurz dein konkretes Setup (Spannung, geplante Kabellänge, grobe Umgebung: z. B. Camper, Werkstatt, Motor in der Nähe etc.), dann kann ich dir eine konkrete Empfehlung geben:

sinnvolle Taktfrequenz

konkreter Pull-Up-Wert

und ob I²C da überhaupt noch Sinn macht oder lieber was anderes.

Jakob · November 29, 2025, 9:40pm

Moin,

ich habe es jetzt mit dem Adapter aus dem Shop gelöst.
Vor dem Adapter ca 10cm ein Abzweiger zum alten Dimmy.
Und ab dem Adapter mit einem abgeschirmten Netzwerkkabel ca 3,5m zum Dimmy pro und dann mit 25cm zum in-out x pro gepatcht.

Klappt an sich echt gut, lediglich in der App klappt die Ansicht für die Dimmer nicht.

Fehler: Internetverbindung.

Über den Browser geht alles.

Jakob · November 30, 2025, 1:32pm

ahtdf · November 30, 2025, 2:14pm

Das habe ich auch, manchmal, wenn ich den pi neu gestartet habe.

Dann haben die Dimmer eventuell einen undefinierten Zustand, das ist dann ein Fehler, und es wird nix übertragen.

Bei mir hilft dann alles mal ein und ausschalten, damit ein definierter Zustand eingestellt wird.

Jakob · December 13, 2025, 9:19pm

Hi,
Dank dir, leider hilft der Neustart nicht.
hast du noch andere Ideen ?

ahtdf · December 14, 2025, 1:55pm

Ich würde auf der Seite http api im Bereich Dimmy eine Hand voll debug node verstreuen und schauen ob ich da was ungewöhnliches finde.

Sonst hätte ich auch keine Idee

rolbra70 · December 14, 2025, 10:21pm

Ich hatte mir als Adapter zum testen eine Schraubklemme mit RJ45 dran gebastelt.

MULTICOM mit RJ45-Schraubklemme

Als erstes habe ich jedoch erstmal die Farben der jst Stecker richtig gemacht und rot und schwarz vertauscht, das geht recht einfach, mit einem kleinen Schraubendrehet/Skalpell o. Ä…..

Ich finde das eine gefährliche Fehlerquellen wenn man später mal schnell was ändern möchte und nicht daran denkt.

Vincent · December 17, 2025, 3:01pm

@Jakob Die App erwartet für alle Dimmer Namen und hat keinen Safeguard, also wenn ein nur Dimmer keinen Namen liefert, werden diese nicht mehr angezeigt. Also musst du sicherstellen dass jeder Dimmer einen Namen hat, auch die, die du nicht benutzt.

Entweder du tippst einmal für alle Dimmer die Namen durch im Dashboard, oder du ersetzt die Zeilen 91-98 in der markierten Node in der HTTP-API hiermit:

msg.payload[“dimmer8”] = { state: parseInt(global.get(“dimmer7”)) ?? 0, name: global.get(“Ndimmer7”) ?? “DimmyPro 1”, autooff: global.get(“deightoffauto”) ?? 0, offtime: global.get(“offtimeD8”) };
msg.payload[“dimmer9”] = { state: parseInt(global.get(“dimmer8”)) ?? 0, name: global.get(“Ndimmer8”) ?? “DimmyPro 2”, autooff: global.get(“dnineoffauto”) ?? 0, offtime: global.get(“offtimeD9”) };
msg.payload[“dimmer10”] = { state: parseInt(global.get(“dimmer9”)) ?? 0, name: global.get(“Ndimmer9”) ?? “DimmyPro 3”, autooff: global.get(“dtenoffauto”) ?? 0, offtime: global.get(“offtimeD10”) };
msg.payload[“dimmer11”] = { state: parseInt(global.get(“dimmer10”)) ?? 0, name: global.get(“Ndimmer10”) ?? “DimmyPro 4”, autooff: global.get(“delevenoffauto”) ?? 0, offtime: global.get(“offtimeD11”) };
msg.payload[“dimmer12”] = { state: parseInt(global.get(“dimmer11”)) ?? 0, name: global.get(“Ndimmer11”) ?? “DimmyPro 5”, autooff: global.get(“dtwelveoffauto”) ?? 0, offtime: global.get(“offtimeD12”) };
msg.payload[“dimmer13”] = { state: parseInt(global.get(“dimmer12”)) ?? 0, name: global.get(“Ndimmer12”) ?? “DimmyPro 6”, autooff: global.get(“dthirteenoffauto”) ?? 0, offtime: global.get(“offtimeD13”) };
msg.payload[“dimmer14”] = { state: parseInt(global.get(“dimmer13”)) ?? 0, name: global.get(“Ndimmer13”) ?? “DimmyPro 7”, autooff: global.get(“dfourteenoffauto”) ?? 0, offtime: global.get(“offtimeD14”) };
msg.payload[“dimmer15”] = { state: parseInt(global.get(“dimmer14”)) ?? 0, name: global.get(“Ndimmer14”) ?? “DimmyPro 8”, autooff: global.get(“dfifteenoffauto”) ?? 0, offtime: global.get(“offtimeD15”) };

Dann werden Standartwerte für die Namesvariablen des DimmyPro übergeben, sollten diese Variablen undefiniert sein

Jakob · December 17, 2025, 5:29pm

Super, dank dir Vincent!
Jetzt läuft alles wie es soll.
Habe die Den Dimmern allen Namen gegeben