Raspberry USB statt CP2102

[thiemjoerg]

Hallo Phil.
Ist es nicht auch möglich einen USB-Port des Pi zu verwenden, für die Kommunikation mit dem Vitoconnect? Das wäre doch eleganter als mit dem CP2102 Adapter.
VG, Jörg

[philippoo66]

Moin Jörg!
du kannst mit einem zweiten TTL_serial-to-USB wieder auf USB gehen. Das Vitoconnect direkt in einen Raspi USB zu stecken geht nicht, weil sowohl der Raspi als auch das Vitoconnect USB Hosts sind. Das ist so, als ob du zwei Anhängerkupplungen aneinander kuppeln wolltest. Der Optolink Kopf ist ein USB Gerät oder USB Peripheral, der CP2102 Adapter auch ;-) Es sei denn, du kennst einen Weg, den (einen) USB Port am Raspi zu einem Peripheral zu machen (es ist ja vieles möglich bei Linux, aber das ist mir bisher nicht über'n Weg gelaufen)?!
Grüsse!
Phil

[thiemjoerg]

Habe hier noch eine Liste und ein setting für die 300-G gefunden
#21
Mal schauen, ob das jetzt passendere Werte liefert...

[FransOv]

04 als Antwort bedeuted die Länge ist falsch. Oft ist die Temperatur zusammen mit der Sensorstatus in eine 3 byte Parameter.
Ich lese die Temperatur in eine 3 byte Parameter so: ("primary_supply_temperature", 0xB400, 3, 'b:0:1', 0.1, True),

[philippoo66]

@thiemjoerg nützlich um den genauen Typ der Steuerung herauszufinden ist immer deviceIdent Adr. f8, 8 bytes und ggf. deviceIdentF0 Adr. f0, 1 byte. Damit kann man dann mit estwas Glück den Typ erkennen und Frans kann die Tabelle dafür erstellen (kommuniziere mit ihm bitte auf Englisch, er ist Niederländer).

Du kannst per MQTT die gleichen Kommandos senden wie mit Putty.

[thiemjoerg]

Hallo Phil.

@thiemjoerg nützlich um den genauen Typ der Steuerung herauszufinden ist immer deviceIdent Adr. f8, 8 bytes und ggf. deviceIdentF0 Adr. f0, 1 byte. Damit kann man dann mit estwas Glück den Typ erkennen und Frans kann die Tabelle dafür erstellen (kommuniziere mit ihm bitte auf Englisch, er ist Niederländer).

Ich habe die Gerätekennung mit 0xF8 auslesen können und erhalte 204b01430000050c
d.h. ecnsysDeviceIdent:204B => CU401B_G
damit weiß ich nun, welche Datenpunkt-Liste ich verwenden muss - Danke

Du kannst per MQTT die gleichen Kommandos senden wie mit Putty.
Ja, das ist viel cooler als putty. Werde ich wohl im weiteren verwenden - Danke

[thiemjoerg]

Hallo.

Temperaturen kriege ich jetzt korrekt rein.

VG
Jörg

[FransOv]

Ich habe in Homeassistant ein Command und ein Response Sensor definiert womit ich einzelne Kommandos eingeben kann.

[philippoo66]

hm, das journal ist interessant - das geht ja etwas 'durcheinander', was aber durchaus normal ist, weil ja die Requests vom Vitoconnect erst gepuffert werden und dann in die Reihe eingeordnet. Leider sieht man nur bedingt, über welchen Kanal da was empfangen wurde, weil die Ausgabe immer aus ein- und demselben Code heraus erfolgt.

Die Fehlermeldung kennen wir ja schon, und die sagt klar, dass (mindestens) auf den Optolink nicht mehr geschrieben werden kann. Bei dem ersten 'write failed' wissen wir leider nicht, wodrauf da geschrieben werden sollte, aber ich vermute auch den Optolink.

[FransOv]

I had a similar problem today. The information via MQTT was valid and kept coming, but the Vitoconnect 100 OPTO 2 error light was blinking and the Viessmann app could not connect to the installation.
I restarted the Vitoconnect by disconnecting and reconnecting the power plug. No result.
I checked the Journal for the main PID of the service (Journalctl | grep ###) and found some time-outs and STX Error 16's.

Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 08 01 01 B4 09 03 33 00 00 FD
Nov 08 15:23:48 orangepi3-lts python3[2812]: Timeout
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 08 01 01 B4 0A 03 A0 02 00 6D
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 08 01 01 B4 0B 03 28 00 00 F4
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 08 01 01 B4 10 03 53 00 00 24
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 08 01 01 B4 11 03 F0 00 00 C2
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 07 01 01 B4 20 02 64 00 43
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 07 01 01 B4 21 02 64 00 44
Nov 08 15:23:48 orangepi3-lts python3[2812]: STX Error 16
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 07 01 01 B4 23 02 37 00 19
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 07 01 01 B4 24 02 1C 00 FF
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 07 01 01 01 19 02 56 01 7C
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 07 01 01 18 04 02 6C 01 94
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 06
Nov 08 15:23:48 orangepi3-lts python3[2812]: rx 41 09 01 01 16 40 04 2B D8 01 00 69

After that I restarted the optolink-switch service. This solved the problem: the error light of the Vitoconnect was off and I could view the installation in the Viessmann app. Also no more time-outs or STX Error 16 in the journal.

[philippoo66]

@FransOv , @thiemjoerg

hm. I asked ChatGPT for the error an this is what it returned:

"An STX Error 16 when using pyserial on a Raspberry Pi often indicates a communication issue over the serial interface. STX stands for "Start of Text" (ASCII character 0x02), and the error number 16 could suggest a problem with data formatting or mismatches between the sender and receiver.

Here are some steps that might help resolve the issue:

• Check Baud Rate: Ensure the baud rate matches on both the sender and receiver sides. For example:

• Verify Serial Settings: Confirm that other serial settings such as parity, stop bits, and byte size align with the connected device’s configuration:

• Ensure Proper Character Encoding: Some devices require specific ASCII control characters, like STX (0x02) or ETX (0x03). Verify that your code sends these control characters if the device expects them.

• Clear Buffer: Clearing the receive buffer before reading or writing can help remove old or corrupted data:

• Implement Error Handling: Catch errors to identify exactly when and where they occur, like this:

• Check Data Flow Control: Some devices require flow control, such as RTS and CTS. Enable hardware flow control if needed:

• Inspect Connection Quality: Poor cable connections or electromagnetic interference can also cause transmission errors. Try using a different cable or USB port.

These steps should help in troubleshooting and potentially resolving the STX Error 16."

I think none of these really apply to the current issue. nevertheless I found one 'situation' where the in-buffer was not cleared befor sending new telegram and added the .reset_input_buffer()

(branch develop)

But this applies to the optolink connection, not to the Vitoconnect.

So I think:

The code worked without problems since a long while. Now recently problems occured more or less 'synchronously' on independent systems (all Opto 2).

Conclusion: Viessmann changed something with a firmware update of the Vitoconnect (nobody recognizes a firmware update happening...) what caused instability in the Vitoconnect optolink communication.

Solution: ?? Perhaps building-in a detection of Vitoconnect communication abortion causing shut.down of the splitter script, followed by automatic restart by systemctl ?!

[thiemjoerg]

Hi @philippoo66 and @FransOv.
To be on the safe side, I checked the wiring again. This is still a flying wiring. At least that's something I can do from my side.

However, I have always been able to solve the problem by resetting the Pi, which is unlikely if the cabling is faulty. The error would have to occur again immediately in this case.

In addition, the MQTT communication has been also instable. But this occurs independantly to the Vitoconnect error, I guess.

Best Regards, Jörg

[thiemjoerg]

Since 11.45 no data is transmitted via MQTT.
Now, I will unplug the connection to the Vitoconnect to check if this produces this issue or the communication PI-OptoLink.

[FransOv]

Hi Phil,
Can it be that due to for instance an outage of the Viessmann portal the vicon thread exits so that the vitoconnect is not queried any more. Is it possible to check the health of that thread?

[philippoo66]

first... The 'STX Error' is an error I defined (in case 0x41 at start of telegram is 'missing') so it was a little stupid to ask KI regarding this. But nevertheless the STX is missing and the possible reasons might be the same.

@FransOv I'm not sure if I got you right - you mean in case Viessmann does not communicate to/with the Vitoconnect 'temporarily'? This will (should?) not cause the problem writing to serViCon as it appeared with @thiemjoerg (SerialException: 'write failed' mit Errno 5 (I/O Error)) and in no case this error appearing when wirting to serViDev (see here).

Let's take a detailed look:

If VM does not send requests to the Vitoconnect anymore, then the viconn_util.get_vicon_request() will return None (line 202) and there will be no write attempt to no serial at all.

If the VM connection disappears just after a request was sent (received by splitter), then worst case the response of the Opto device will get written to the serViCon outbuffer. The out-buffer will always be able to buffer at least two telegrams (KI says default size is 4096 bit).

The vicon_thread does never exit (except in case of program exit). It always listen to the serViCon for VS2 data. As I mentioned above, a problem could appear in case VM stops the Vitoconnect and after restart the Viconnect tries to initialize VS2 protocol what does not accord to VS2 format so will be ignored by the vicon_thread -> deadlock.

In fact that might end up in a 'STX Error' since the init sequence is 04 - (resp. 05) - 16 00 00 - (resp. 06) so no STX anywhere

To identify this kind of problem, we need to activate Vicon logging by log_vitoconnect = True in settings_ini. I hope this will show what happens.

unfortunately I can not test since I do not have Vitoconnect. perhaps it might help for testing if somebody activates ViCon logging and disconnect the wire to the CP2102 of the TX pin of the Raspi?! In this case at least a out-buffer overflow should happen after some while and we will see how this gets logged...

[thiemjoerg]

Hi.
I disconnected yesterday 6.21pm the wire to the RX pin of CP2102 (TX pin of the Raspi). Still no issues via MQTT.

[philippoo66]

sorry, disconnecting the TX to ViCon should not cause a MQTT problem.... question was if this causes the same/'known' problem with the ViCon (serial write error).

In the meanwhile another guy (again with Opto2) realized the same/similar issue. So it is almost sure that it is not related to cabling.

@FransOv @thiemjoerg did one of you get a vitolog.txt of the moment of the fault in the meanwhile?

[FransOv]

No, I cannot use logging now as I'm running from an 8 GB on-board EMMC on a Raspi clone (OrangePi). I'll have to insert an SD card before I can activate logging. I'll try to do that today, it is not in a very accessible place.

[philippoo66]

ok, I got a log from Bernhard (BP77 at Viessmann community):

What we see is:

• VM reads DP4007 (gradient heating curve).
• device responds (0.6).
• VM seems not to receive/realize the reasponse (Internet connection dropout?), and
• after 7 secss they try to initialize the VS2 protocol (16 00 00)
• this does not get performed by the device since it is already in VS2 mode, it continues to send idle bytes (05) every 2 secs
• VM resets the protocol/connection (04)
• then they again initialize the VS2 protocol (16 00 00)
• after the reset, this gets performed correctly by the device and it responds 06
• Then erverything is working fine again.

So...
This is working fine (it appeared several times that night, always worked well).
I did not change anything in my code.
Since it was not working the past days, Viessmann must have done some fix in their firmware or remote communication software.
I hope this fix will apply on your site sooner or later, too, and the communication breakdowns should be past.

@FransOv @thiemjoerg please keep me informed!