Verständnisfrage zur Kontaktierung mehrerer I2C Clients

Hallo,
ich bräuchte Unterstützung zum Verständnis vom Aufbau und Abbau von I2C Verbindungen wenn mehrere I2C Clients angeschlossen sind.

Meiner Ansicht nach müsste ich doch bei jedem Aufruf eines I2C Clients mit seiner Adresse die Verbindung gestartet werden, Daten übertragen, dann die Verbindung beendet, um das Gleiche beim nächsten Client mit einer anderen Adresse zu wiederholen.

Filktives Beispiel für zwei Clients unter den Adressen 1 und 2, an die ein "X" und ein "Y" geschickt wird:

Wire.beginTransmission(1); 
Wire.write('X');
Wire.endTransmission();

Wire.beginTransmission(2); 
Wire.write('Y');
Wire.endTransmission();

Wäre das so prinzipiell richtig ?

Mein konkretes Problem:
Ich scheitere damit derzeit bei der Kombination des Aufrufs eines CO2 Sensors Sensirium SCD30 und eines I2C Clients (2. Arduino als i2Client nach dem Standardbeispiel).
(GitHub - Sensirion/arduino-i2c-scd30: Arduino I2C driver for Sensirion's SCD30 sensor, Sensirion I2C Example).
Der Sensirion I2C Beispielssketch geht ja, aber ich weiß nicht, wie ich für diesen Sensor die I2C Verbindung beenden kann, um einen anderen Client ansprechen zu können-
Es gibt für den CO2 Sensor keinen Befehl sensor.endTransmission() oder sensor.end , der Compiler meckert. Soll ich da einfach pauschalt dann wire.end oder Wire.endTransmission() nutzen ?
ich finde in der Sensirion-lib dort auch unter keywords.txt nichts passendes, oder wäre das "StopMeasurement" richtig ?

Danke,
Tütenflieger

Wie wäre es, wenn du mal in die Doku schaust, wie man eine Verbindung schließt bzw. offen hält.

Parameters
stop: true or false. True will send a stop message, releasing the bus after transmission. False will send a restart, keeping the connection active.

Also ich finde unter

u.a. folgenden Befehl:

Soll ich lieber

wire.stop

nehmen ?

Erstmal: Nein!
So ich das sehe: Du buddelst auf der falschen Baustelle.
Oder anders: Du hast dich verrannt.

gehe mal exakt so for wie im Beispiel:

die Library stellt dir also ein Interface in der Form:

error = sensor.blockingReadMeasurementData(co2Concentration, temperature,
                                               humidity);

zur Verfügung.
Du hast für den Sensor überhaupt nichts zu tun bezüglich den low level I2C Funktionen.
Das erledigt die Library für dich!

Beispielsweise in der Bibliotheksdatei SensirionI2CCommunication.cpp findest Du:

uint16_t SensirionI2CCommunication::sendFrame(uint8_t address,
                                              SensirionI2CTxFrame& frame,
                                              TwoWire& i2cBus) {
    i2cBus.beginTransmission(address);
    size_t writtenBytes = i2cBus.write(frame._buffer, frame._index);
    uint8_t i2c_error = i2cBus.endTransmission();

Meines Erachtens macht das die Bibliothek für Dich.

Danke für die Info, daß die I2C Verbindung schon innerhalb des Sensirion-Sensoraufrufs dann wieder beendet wird (so verstehe ich agmue).

Wenn ich dann aber über I2C Daten an einen anderen Client schicken will (hier dient ein Arduino als I2C->parallel Wandler für ein Display) , kommt auf der seriellen Schnittstelle nur noch Datenmüll raus, der Sensor scheint sich laufend zu resetten (die Initialisierung ist über die serielle Schnitstelle immer wieder neu zu sehen), und es wird nichts auf der Anzeige angezeigt.

CO2_Sensor_HDSP_2112ProMiniPaket_ESP8266_Test4.ino (4.7 KB)

Nur falls nach der Hardware gefragt werden sollte:
Das Ansteuern des Displays für sich alleine geht, da Ansteuern des CO2 Sensors für sich alleine auch. Hardwaremäßig wird am Aufbau nichts geändert. Der Arduino zur Anzeige wird über einen Levelshifter mit 5V-Signalen versorgt, der CO2 Sensor direkt mit den 3,3V Signalen die aus dem ESP8266 (Wemos D1 Mini) herauskommen .
ich tippe daher eher auf ein Fehler in meinem Softwareverständnis.

Tütenflieger

du meinst die Daten die du mit den Zeilen ab 125 schickst?

Wie sieht denn dazu der Code vom Empfänger/Slave aus?

Natürlich dürfen wir den nicht sehen!
Ist auch ok, so ich finde.

Auf der Displayseite läuft folgendes.
Das entspricht von der i2C- Seite dem Standardbeispiel des i2C Clients: Wire / slave receiver

CO2_Sensor_HDSP_2112ProMiniPaket_ESP8266_Test4.ino (4.7 KB)

warum heist die Datei gleich wie in post #8?

@combie
Hier der unspektakuläre Breadboardaufbau

@noiasca : Sorry, da habe ich mich vertan.
HDSP_2112_an_ProMini_I2C_Test3.ino (5.9 KB)
Der Code basiert auf einem Programm von Arno Welzel:
https://arnowelzel.de/hdsp-211x

eigenartige Funktion receiveEvent hast da.

Warum gibts eine Behandlung für Escapes/27? Sehe im Sender nicht, wo Escape Sequenzen herkommen sollen?

Warum überhaupt so kompliziert?
Warum fixierst du am Master das CO2konz nicht einfach auf 16 oder 32bit Breite und überträgst dann die 2 bzw. 4 Byte ohne dem ganzen Zahlenlänge-Ermitteln - padden - Fixtext " CO2" hinten dran?

Und warum postest du die Sketche nicht so, wie es gehört, hier direkt in den Beitrag in Code-Tags. Dann können den auch alle lesen und du hättest mehr Helfende.

Wenn du meinst....

Alleine das stört mich schon:
image

@combie
Bei den kleinen Levelshifter-Platinen fand ich es praktischer, auf einer Seite die Stiftleisten nach unten zu löten für Steckbretter, auf der anderen nach oben für Kabel.

@noiasca
Die Escapesequenz wird genutzt um die Helligkeit des Displays einstellen zu können, das ist auf der Senderseite hier noch nicht implementiert.

Den Code für die Ansteuerung des Displays habe ich von Arno Welzel übernommen. Siehe

Ich gelobe zukünftige Besserung mit der Einbindung des Codes, für längeren Code hatte ich bei direkter Einbindung Bedenken bzgl. der Lesbarkeit.

Tütenflieger

@noiasca
Dieser ganze Teil mit der Zahlenlängenermittlung dient einer ästhetischen rechtsbündigen Darstellung des Messwerts vor der Angabe der Einheit.