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?

[thiemjoerg]

vitolog_1000.txt

[thiemjoerg]

here you go ...

[philippoo66]

ok, thank you @thiemjoerg !

The initial exception

Dec 01 03:30:00 raspberrypi-wp python[1053]: File "/home/pi/optolink-splitter/myvenv/lib/python3.11/site-packages/serial/serialposix.py>
Dec 01 03:30:00 raspberrypi-wp python[1053]: raise SerialException('write failed: {}'.format(e))
Dec 01 03:30:00 raspberrypi-wp python[1053]: serial.serialutil.SerialException: write failed: [Errno 5] Input/output error

indicates that a serial interface 'disappeared'. The serialposix was not able to write out data.

The other exception during handling of the above exception

Dec 01 03:30:00 raspberrypi-wp python[1053]: serViDev.write([0x04]) #TODO yes or no?
Dec 01 03:30:00 raspberrypi-wp python[1053]: ^^^^^^^^^^^^^^^^^^^^^^

clearly shows that writing to the Optolink serial was not possible.

The final lines of vitolog (1 hour offset because of UTC/CET)

shows that at 03:29:59,130 the splitter successfully sent out the resonse to Vitoconnect and 101ms later it successfully received the subsequent request from the Viconnect which got not responded anymore.

Conlusion:

• something happend ~03:30:00 (at least) to the serial the Opto is connect to. This is clearly not caused by anything coming from the Vitoconnect. Since both serials are different matters (Vicon is on the on-board UART, Opto is an emulated USB serial), it is quite unlikely that even a failure in the Vicon serial might have influence on the Opto serial.

Please check if there is anthing wrong with the USB serial! Check all system logs for possible hints. Perhaps look for and try another driver. Check if according hardware gets warm/hot.

Also often a cause if 'the unexplainable' happens: The power supply of the Raspi. Often 5V 'chargers' are used which may not accord to the requirements of a truly stabilized 5V power supply. See e.g. here http://www.elektronik-kompendium.de/sites/raspberry-pi/1912111.htm Does the power supply offer enough current?

Is something scheduled for 03:30h which might cause drawing extra power (e.g. a backup causing a USB HDD or SSD starting up - probably such a device may even exceed the allowed 500mA during starting up) or which might cause EMC 'trouble' (perhaps compressor start of Vical)?

[thiemjoerg]

Hi @philippoo66 .
Thank you very much for your effort.
With your help, I managed to solve the issue.
For yome reason, the pi changed the usb relation from ttyusb0 to ttyusb1.
Thanks and best regards
Jörg

[philippoo66]

thank you for the feedback.

you can assign a dedicated name (e.g. 'ttyVito') to the Optolink Head. described here: https://github.com/philippoo66/optolink-splitter/wiki/130-Fixed-Naming-of-USB-tty-devices-%E2%80%90-udev-rule

but if a change of connection happens while the script is running, it is not too likely that this might help, since the port gets opened on start of script and the serial object is used afterwards. If the 'target' of the object disappears, the script will still be 'lost'.

[thiemjoerg]

Hi @philippoo66 .
Merry Christmas.

Unfortunately, since 26.12.2024 at 23:45 my pi publishes no optolink messages anymore.
The datapoint LWT (?) is updating. So, commnunication itself seems to work.
The service is starting after every 2 minutes. :-(
Best regards
Jörg

[thiemjoerg]

(myvenv) pi@raspberrypi-wp:~/optolink-splitter $ python optolinkvs2_switch.py awaiting VS2... Server listening on 0.0.0.0:65234 Broker granted the following QoS: 0

[philippoo66]

hm, this again looks like a problem with the opto serial. there is an ENQ every 2 secs on the Viconn but nothing happens.
is the show_opto_rx = True in settings_ini still set?
did you power-cycle the raspi ('hard reset')?

[philippoo66]

well, no. The ENQ comes from the Opto device. So receiving works.

but nothing coming from the Viconn. usually there should sometime be a 04 (reset) followed by the init vs2 sequence. That is not happening. Usually after 2 Minutes you should get the time-out message on the console - don't you?!

please try port_vitoconnect = None to test without Viconn!

if it works then, power-cycle the Viconnect. If after that still nothing more in the vitolog, verify the Viconn is connected to the Internet. If it is, then someting went wrong at Viessmann site and nobody is there to care for. Continue without Viconn and wait for holidays end ;-)

[thiemjoerg]

the vitoconnect isn't pluged in the pi, I am trying the connection with pi and the optolink only, is this not possible or do I have to adjust the settings fpr this?

[thiemjoerg]

I am stupid !
That's the solution: port_vitoconnect = None
Sorry for this. I didn't know this.