abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 
Beantwortet! Gehe zur Lösung.

Datenpunkte in der API gesucht

Hallo,

ich versuche es einmal auf diesem Weg an die genauen Bezeichnungen der API features (DP) für meine Vitocal 222-S zu kommen.

 

Ich suche hier die Datenpunkte für folgende VitoConnect Bezeichnungen:

 

- elektrische Zusatzheizung

- Heizwasserdurchlauferhitzer

- Speicherladepumpe

 

Vielleicht kann mir jemand auf die Sprünge helfen. Bitte keine Verweise auf das Entwicklungsforum. Da wurden mir bisher die Fragen nicht beantwortet.

 

Vielleicht weiß auch jemand, wie man die Advanced Datenpunkte der API erwerben kann.

 

Vielen Dank.

 

Gruß

Joachim

111 ANTWORTEN 111

sudo raspi-config

 

HerrP_0-1723643403068.png

 

HerrP_1-1723643457361.png

 

HerrP_2-1723643483454.png

 

HerrP_3-1723643508640.png

 

HerrP_4-1723643522831.png

 

 

 

du musst einen reboot machen danach.... sagt Raspi aber auch

puh, du machst es einem aber auch nicht einfach 😉 den meisten Usern ist klar, dass die Serielle Console nicht laufen darf, wenn man die UART als serielle Schnittstelle für Anwendungen benutzen will. Aber vielleicht sollte ich es trotzdem in's ReadMe schreiben. 

Überhaupt sollten wir, wenn du es dann endlich am Laufen haben wirst (und das wirst du, da bin ich mir ziemlich sicher, weil du jetzt nach der ganzen 'Arbeit' wohl nicht aufgeben wirst), noch mal rekapitulieren, wodran es denn eigentlich gehapert hatte, damit wir dem für die 'Nachwelt' gleich vorbeugen können. 

wenn du hinterher Datenpunke suchst, mach das mit dem MQTT Explorer:

 

HerrP_0-1723645269833.png

 

dann musst du nicht dauernd die poll_list editieren und das Skript neu starten 😉

Gute Idee, dass mit der Doku. Du darfst nicht zuviel bei Nutzern voraussetzen. Was für dich als Entwickler in diesem Umfeld klar ist, ist für andere längst nicht klar. 😉 Im Linux Umfeld empfinde ich mich als beginner. 

 

Ich habe jetzt die serielle Console aus- und die UART mittels "raspi-config" eingeschaltet, die Änderung "dtoverlay=miniuart-bt"in der /boot/firmware/config.txt unter der Sektion [ALL] eingetragen, in den "settings_ini.py" den Eintrag "port_vitoconnect = 'dev/ttyAMA0'" vorgenommen, rebooted und alles wieder aktiviert. Trotzdem mag er die ttyAMA0 nicht öffnen. Vielleicht habe ich etwas übersehen. Kann man die Änderungen im laufenden System überprüfen.

 

Für mich ist es wichtig, dass wir Vitoconnect ans Laufen bringen (Gewährleistung). Darüber hinaus muss das ganze 24*7*365 lauffähig sein. Das bedeutet, dass ich aus Backup Gründen täglich viele Services automatisch beende, die Daten sichere und wieder die Servives starte. Dein Optolink-Service muss dieser Regel folgen können. Das gilt auch für das virtuelle Environment. Es muss automatisch gestartet werden.

 

myvenv) pi@Pi4JMF:~/optolink $ python optolinkvs2_switch.py
[Errno 2] could not open port dev/ttyAMA0: [Errno 2] No such file or directory: 'dev/ttyAMA0'
exit close
cancel poll timer
exiting TCP/IP client
(myvenv) pi@Pi4JMF:~/optolink $ dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0 smsc95xx.macaddr=E4:5F:01:D6:1D:82 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 console=tty1 root=PARTUUID=2d8815d8-02 rootfstype=ext4 fsck.repair=yes rootwait
[ 0.000340] printk: console [tty1] enabled
[ 1.584973] fe215040.serial: ttyS0 at MMIO 0xfe215040 (irq = 36, base_baud = 62500000) is a 16550
[ 1.585241] serial serial0: tty port ttyS0 registered
[ 1.613034] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 38, base_baud = 0) is a PL011 rev2
[ 6.070119] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[ 7.808842] usb 1-1.3: ch341-uart converter now attached to ttyUSB0

Das habe ich bereits ausprobiert und das Lesen und Schreiben über den MQTT Explorer funktioniert. Die Fleißarbeit beginnt, wenn das Produkt so läuft, wie ich es haben will.

ok, eins nach den andren.

 

Was liefert

  ls /dev/tty*

? sowas?

HerrP_0-1723645543995.png

 

steht da die ttyAMA0 drin?

versuch auch mal

  python list_ports.py

HerrP_1-1723645667162.png

 

das sieht doch eigentlich schon ganz gut aus

 

HerrP_2-1723645969899.png

 

auf meinem Raspi4 (wo ich die AMA0 benutze (zwar für meinen Stromzähler aber egal) eigentlich auch so:

 

HerrP_4-1723646108455.png

 

es kann halt sein, dass sie noch anderweitig belegt ist. dann hat dein config.txt Änderung nicht gefruchtet (steht der Kram oben und nicht in einer section [xyz]?).

Wichtig ist, dass die AMA0 bei python list_ports.py auftaucht.

 

Das sieht bei mir ähnlich aus.

 

(myvenv) pi@Pi4JMF:~/optolink $ python list_ports.py
Verfügbare serielle Ports:
/dev/ttyAMA0: ttyAMA0 [fe201000.serial]
/dev/ttyUSB0: USB Serial [USB VID:PID=1A86:7523 LOCATION=1-1.3]

 

Kann es sein, dass der USB Port für den CP2102 falsch angeschlossen ist?

etwas komisch ist

 

HerrP_6-1723646628062.png

 

bei meinem Vito Raspi steht da

 

HerrP_7-1723646857347.png

 

dein Optolink Kopf scheint einen anderen Chip drin zu haben. Hoffen wir, dass dein Vitoconnect auch mit den CP2102 klar kommt! Aber das muss es ja eigentlich, weil die alten Köpfe alle den Chip haben. #

 

Ist das eine Opto1 oder eine Opto2?

>> die Änderung "dtoverlay=miniuart-bt"in der /boot/firmware/config.txt unter der Sektion [ALL] eingetragen

 

Sektion [ALL] ist falsch! es muss nach oben! (garkeine Section...)

HerrP_9-1723647355948.png

 

 

hier ein paar Fotos über den Anschluss des CP2001 und dem Optokopf

CP2102.jpg
RPI4.jpg
Optolink Anschluss.jpg
Optolink Anschluss #2.jpg

gleiches Ergebnis nach Änderung in "/boot/firmware/config.txt"

 

(myvenv) pi@Pi4JMF:~/optolink $ python list_ports.py
Verfügbare serielle Ports:
/dev/ttyAMA0: ttyAMA0 [fe201000.serial]
/dev/ttyUSB0: USB Serial [USB VID:PID=1A86:7523 LOCATION=1-1.3]
(myvenv) pi@Pi4JMF:~/optolink $ python optolinkvs2_switch.py
[Errno 2] could not open port dev/ttyAMA0: [Errno 2] No such file or directory: 'dev/ttyAMA0'
exit close
cancel poll timer
exiting TCP/IP client

versuch mal erst, bei dem Adapter nur TX, RX und GND am Raspi anzuschliessen. Ich denke der bekommt seine Spannungsversorgung über den USB Stecker.

 

HerrP_0-1723650353463.png

 

Dann muss er natürlich im Vitoconnect stecken und das muss an sein, damit er auch Spannung bekommt.

 

Zwei sich bekämpfende 3.3V (eine vom Voltage Regulator vom Chip und eine vom Raspi) sind nicht gut. Die sollten nicht verbunden werden. Solange du den USB am Vitoconnect nicht eingestöpselt hast, kannst du die 3.3V vom Raspi nehmen. Aber hinterher nicht beides gleichzeitig.

 

Der Stecker am gelben Kabel steckt am Raspi nicht auf einem PIN! Zumindest sieht das auf dem Foto so aus.

 

Ansonsten sieht das richtig aus. TX/RX sind gekreuzt, wie das sein muss.

 

~~~~~~~~~~~~

 

wenn list_ports den AMA0 sieht ist er auch da!

- hast du 0 (Null) und nicht O (Buchst O) geschrieben?

- hast du in der settings_ini "/dev/ttyAMA0" geschrieben (mit führendem slash)?

 

 

 

ja bis auf den Namen /dev/ttyVito.

dejmfse1_0-1723652163824.png

 

 

ja, das hatten wir schon.

 

dejmfse1_1-1723652382445.png

 

ja der Kram steht oben und taucht auch in der Abfrage auf.

 

dejmfse1_2-1723652537405.png

 

 

 

 

 

>> Der Stecker am gelben Kabel steckt am Raspi nicht auf einem PIN! Zumindest sieht das auf dem Foto so aus.

 

Der gelbe Stecker ist angeschlossen

 

>> Zwei sich bekämpfende 3.3V (eine vom Voltage Regulator vom Chip und eine vom Raspi) sind nicht gut. Die sollten nicht verbunden werden. Solange du den USB am Vitoconnect nicht eingestöpselt hast, kannst du die 3.3V vom Raspi nehmen. Aber hinterher nicht beides gleichzeitig.

 

Alle Ports sind verbunden und haben damit auch die 3.3V

 

>> wenn list_ports den AMA0 sieht ist er auch da!

- hast du 0 (Null) und nicht O (Buchst O) geschrieben?

- hast du in der settings_ini "/dev/ttyAMA0" geschrieben (mit führendem slash)?

 

Bingo, das war es. Ich hatte dev/ttyAMA0 anstatt /dev/ttyAMA0 geschrieben. Die Vitoconnect läuft jetzt ebenfalls.

 

Aber 😎 Ich bekomme jetzt im Millisekunden Takt:

 

rx 06
rx 41 06 01 a1 7d 00 01 03 29
rx 41 05 00 c1 7d 0a 02 4f
rx 06
rx 41 07 01 c1 7d 0a 02 78 00 ca
rx 41 05 00 e1 7d 0b 02 70
rx 06
rx 41 07 01 e1 7d 0b 02 aa 00 1d
rx 41 05 00 01 7d 0c 02 91
rx 06
rx 41 07 01 01 7d 0c 02 d7 00 6b
rx 41 05 00 21 7e 80 01 25
rx 06
rx 41 06 01 21 7e 80 01 00 27
rx 41 05 00 41 7e 81 02 47
rx 06
rx 41 07 01 41 7e 81 02 6e 00 b8
rx 41 05 00 61 7e 82 01 67
rx 06
rx 41 06 01 61 7e 82 01 00 69
rx 41 05 00 81 7e 83 01 88
rx 06
rx 41 06 01 81 7e 83 01 04 8e
rx 41 05 00 a1 7e 91 02 b7

 

 

das wird die Kommunikation des Vitoconnect sein. scheint also zu laufen 😎

>> Alle Ports sind verbunden und haben damit auch die 3.3V

 

ja, aber es sind nie und nicht überall 3.3000000000 Volt, also unterschiedlich

 

HerrP_2-1723654688034.png

 

Wenn du jetzt den 3.3V Pin mit 3.3V vom Raspi bestromst, belastet du den Voltage Regulator. Der wird nicht viel können wird, zumin weniger als der Raspi. Das geht ne Weile gut, aber auf Dauer läufst du Gefahr den durchzubrennen.

 

Lass die Verbindung einfach weg! Falls es dann nicht gehen sollte, kanns du ihn ja wieder drauf stecken (dann ist der Voltage Regulator schon abgeraucht)

>> ja, aber es sind nie und nicht überall 3.3000000000 Volt, also unterschiedlich

 

ohne die 3.3V geht es nicht. In deinem Video hattest du das gleiche mit 5V erwähnt. Den hatte ich auch weggelassen.

nagut, wahrscheinlich ist der kleine Spannungsregler im kleinen Chip dann schon hinüber. Es könnte allerdings auch sein, dass die 5V von USB garnicht angeschlossen sind. Ich muss mir das mal in Ruhe anschauen, ich hab auch noch so ein Boardchen hier.

 

Aber egal - Hauptsache es funktioniert.

 

Hast du jetzt schon mal das Skript angehalten und nach ner Weile wieder gestartet? Fängt das Vitoconnect dann wieder an zu blubbern?

 

Ansonsten ist doch jetzt soweit alles am Laufen, oder?

 

Falls es dich interessiert - dein Output oben bedeutet folgendes:

 

rx 06
rx 41 06 01 a1 7d 00 01 03 29 -> (Antwort vorheriges Telegramm, 7d00 hat 1 Byte und Wert 0x03)


rx 41 05 00 c1 7d 0a 02 4f -> Vitoconnect an Vitocal: read 7d0a, 2 Bytes
rx 06 -> (Vitocal an Vitoconnect: ok, verstanden; ist eigentlich das 1. Byte des Antworttelegramms)
rx 41 07 01 c1 7d 0a 02 78 00 ca  -> Vitocal an Vitoconnect: 7d0a gelesen, 2 Bytes, Wert: 0x0078 

 

rx 41 05 00 e1 7d 0b 02 70 -> Vitoconnect an Vitocal: read 7d0b, 2 Bytes
rx 06
rx 41 07 01 e1 7d 0b 02 aa 00 1d -> Vitocal an Vitoconnect: Wert 0x00aa

 

rx 41 05 00 01 7d 0c 02 91 -> (usw.)
rx 06
rx 41 07 01 01 7d 0c 02 d7 00 6b  -> 7d0c: 0x00d7

 

rx 41 05 00 21 7e 80 01 25  -> Vitoconnect an Vitocal: read 7e80, 1 Byte
rx 06
rx 41 06 01 21 7e 80 01 00 27 -> Vitocal an Vitoconnect: Wert 0x00

 

rx 41 05 00 41 7e 81 02 47
rx 06
rx 41 07 01 41 7e 81 02 6e 00 b8  -> 7e81: 0x006e

 

rx 41 05 00 61 7e 82 01 67
rx 06
rx 41 06 01 61 7e 82 01 00 69  -> 7e82: 0x00

 

rx 41 05 00 81 7e 83 01 88
rx 06
rx 41 06 01 81 7e 83 01 04 8e  -> 7e83: 0x04

 

rx 41 05 00 a1 7e 91 02 b7 -> Vitoconnect an Vitocal: read 7e91, 2 Bytes

...

 

auf die Weise siehst du, welche Datenpunkte Viessmann ausliest. Wenn Viessmann was schreibt, wird das Rosane eine 2 und die Daten (Wert) kommen natürlich im Request. vielleicht nutzt dir das was 😉

 

du kannst das auch mitschreiben lassen, wenn du in der settings_ini  log_vitoconnect = True  setzt.

Top-Lösungsautoren