Datenpunkte in der API gesucht

[dejmfse1]

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

[dejmfse1]

---

@HerrP  schrieb:

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?

---

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

ja, wenn ich das script beende und wieder starte geht alles seinen normalen Gang und Vitoconnect und das Lesen und Schreiben über den "mqtt explorer" funktioniert. Damit ist die Problematik mit der ttys0 device nicht mehr vorhanden.

Jetzt muss ich das automatische Aktivieren des venv noch realisieren, um bei einem reboot des RPIs den Start des Services nicht vor die Wand zu fahren. An welcher Stelle kann ich das gesichert erreichen?

1. boot RPI

2. aktiviere venv

3. starte den Service Optolink Splitter

Dann muss ich heute Nacht sehen, ob der Service nach meiner Sicherung der Daten immer noch läuft. Ich werde die Services mosquitto und den optolink-splitter nicht beenden und starten lassen.

Ich möchte mich hier für deine Geduld und Unterstützung, die mit meiner Installation einhergingen, recht herzlich bedanken. 😊

Grüße,

Joachim

[HerrP]

mach einen systemctl service wie ein paar seiten zurück beschrieben! den kannst du wie jeden anderen Dienst beim Booten automatisch starten, anhalten und wieder starten. dabei brauchst du dich um die virtuelle Umgebung nicht zu kümmern, die ist sozusagen inklusive.

Aber gerade dann ist es nötig, die ttyAMA0 zu benutzen, weil du ja keinen Reboot machst (oder machst du einen?).

Ja, der Weg war ein wenig 'steinig', und du hattest es zwischendrin geschafft, mich etwas zu verunsichern, aber es freut mich auch, dass es jetzt läuft!!

Können wir noch mal die Stolpersteine listen?!

- es fing an mit dem 'externally-managed-environment'

- dann MQTT Anmeldung, aber eigentlich hatte das doch alles funktioniert, oder? Auch mit dem dynamischen Import des mqtt_util war letzendlich kein Problem? Was war das Problem?!? (OS Err 22, Invalid argument)

- der Timestamp, der bei WP anders ist als bei Gas -> Index out of range

- serielle Console disablen, serielle Schnittstelle für Apps freischalten

- die Geschichte mit ttyS0 ttyAMA0 - Eintrag an der richtigen Stelle von config.txt (oder geht es auch unter [all]?)

- Slash vergessen - kann passieren (braucht aber nich in's Readme denk ich) 😉

- nochwas?

Einiges hab ich ja schon in's Wiki gepackt. Sollten trotzdem Hinweise in's Readme? welche?

[HerrP]

ps. Startreihenfolge von Diensten kannst du beeinflussen. (erst moquitto, dann splitter z.B.) Farg mal ChatGPT, das kann das wahrscheinlich sofort sagen, wie du das hinbekommst.

Ich hab da übrigens garkeine Rücksicht drauf genommen. wenn moquitto noch nicht da ist, geht splitter schief und wird nach 3 Sekunden wieder probiert - solange bis es läuft.

[dejmfse1]

---

@HerrP  schrieb:

mach einen systemctl service wie ein paar seiten zurück beschrieben! den kannst du wie jeden anderen Dienst beim Booten automatisch starten, anhalten und wieder starten. dabei brauchst du dich um die virtuelle Umgebung nicht zu kümmern, die ist sozusagen inklusive.

Aber gerade dann ist es nötig, die ttyAMA0 zu benutzen, weil du ja keinen Reboot machst (oder machst du einen?).

Ja, der Weg war ein wenig 'steinig', und du hattest es zwischendrin geschafft, mich etwas zu verunsichern, aber es freut mich auch, dass es jetzt läuft!!

Können wir noch mal die Stolpersteine listen?!

- es fing an mit dem 'externally-managed-environment'

- dann MQTT Anmeldung, aber eigentlich hatte das doch alles funktioniert, oder? Auch mit dem dynamischen Import des mqtt_util war letzendlich kein Problem? Was war das Problem?!? (OS Err 22, Invalid argument)

- der Timestamp, der bei WP anders ist als bei Gas -> Index out of range

- serielle Console disablen, serielle Schnittstelle für Apps freischalten

- die Geschichte mit ttyS0 ttyAMA0 - Eintrag an der richtigen Stelle von config.txt (oder geht es auch unter [all]?)

- Slash vergessen - kann passieren (braucht aber nich in's Readme denk ich) 😉

- nochwas?

Einiges hab ich ja schon in's Wiki gepackt. Sollten trotzdem Hinweise in's Readme? welche?

---

Ich habe dir eine Liste der Probleme aus meiner Sicht beigefügt. Bei einem Reboot des RPi läuft die Vitoconnect nicht (siehe Aufstellung und manuelle Vorgehensweise). Ob der Eintrag unter der [all] in der config.txt auch funktioniert habe ich nicht überprüft. Das mit dem ttyAMA0 hatte ich ganz anders verstanden. Ich dachte wir hätten die Änderung gemacht, damit man die device immer wieder erneut benutzen kann unabhängig davon ob neu gebootet bzw. das script optolinkvs2_ini.py erneut aufgerufen wird

[HerrP]

>> damit man die device immer wieder erneut benutzen kann unabhängig davon ob neu gebootet

genau dafür haben wir es gemacht. Die ttyS0 würde bei einem erneuten Start des skripts ohne vorherigen reboot nicht funktionieren.

Wir müssen der 'Neu/Startproblematik' noch mal genau auf den Grund gehen.

Ich vermute, das Vitoconnect muss neu gestartet werden, nicht die ganze Anlage. Bei den Opto1 war es so, dass das beim Einschalten zuerst die Verbindung zur Heizung aufgebaut hat, und wenn die stand, die WLAN Verbindung und dann die Verbindung zum Viessmann Server.

Wenn man jetzt bei laufender Serververbindung die Heizung 'ausmacht' (so sieht das für das Viconnect aus, wenn man das Skript stoppt), kann es sein, dass es die ursprüngliche Initialisierungssequenz wieder erwartet - d.h. Viconnect aus, Heizung an, ...

Um dahinter zu kommen, was passiert, müsstest du man in der settings_ini  log_vitoconnect = True  setzen und  poll_interval = -1  Dann wäre es gut, wenn du im Betrieb mal den Optolinkkopf für 1..2 Minuten abziehen und wieder drauf stecken würdest (an der Heizung, ich weiss, das ist etwas friemelig, aber es hilft uns).

Wenn dann die Vitoconnect Verbindung weiter läuft, haben wir Chancen, das mit dem Neu Starten in der Software hin zu bekommen. Sonst hilft nur das Vitoconnect mit einem Relais neu zu starten (können wir unkompliziert auch automatisiert realisieren).

Danke für die Liste! Ich werde die Punkte mal angehen.

[dejmfse1]

Leider läuft die Vitoconnect nicht weiter. Ich hatte in meiner Liste beschrieben wie die Verbindung manuell wieder erneut hergestellt werden kann ohne an der Hardware herumfummeln zu müssen. Kann man diesen Ablauf nicht in einem script realisieren?

[HerrP]

jetzt müssen wir noch mal genau klären:

a) läuft das Vitoconnect nicht weiter, wenn du den Kopf rusziehst und nach ner Weile wieder rein steckst?

oder

b) wird die Virtuelle Umgebung nicht mit/von dem Service gestartet?

ich habe ChatGPT noch mal gebeten und explizit drauf hingewiesen, dass der Dienst myvenv und darin das Skript starten soll:

[Unit]
Description=Optolink VS2 Switch Service
After=network.target

[Service]
Type=simple

# Benutzer und Gruppe, unter der der Service laufen soll
User=pi
Group=pi

# Pfad zum Arbeitsverzeichnis
WorkingDirectory=/home/pi/optolink/

# Aktivierung der virtuellen Umgebung und Ausführung des Skripts
ExecStart=/bin/bash -c 'source /home/pi/optolink/myvenv/bin/activate && exec /home/pi/optolink/myvenv/bin/python /home/pi/optolink/optolinkvs2_switch.py'

# Optionale Einstellungen:
Restart=always # Service neu starten, wenn er abstürzt
RestartSec=10 # Wartezeit vor dem Neustart

[Install]
WantedBy=multi-user.target

das ExecStart sieht schon ein wenig anders aus (Achtung, keinen Zeilenumbruch machen! ich habs noch mal als pdf angehängt). Aber mir scheint ChatGPT ist auch nicht unbedingt zuverlässig in dieser Angelegenheit.

ich habe einen Branch "debug_venv" gemacht mit folgender Egänzung in der optolinkv2s_switch.py:

damit sehen wir dann im vitolog, ob das Skript wirklich in der myvenv läuft.

Könntest du das mal ausprobieren mit der Änderung des Service!?

[HerrP]

ps. du kannst die Zeile auch einfach bei dir reinschreiben,

vitolog.write(f"Python executable path: {sys.executable}\n")

musst aber oben bei den imports noch

import sys

dazu machen.

[HerrP]

pps. sorry für die späte Antwort! ich war heute unterwegs....

[dejmfse1]

Moin Phil,

ich habe deine Anweisungen durchgeführt.

Zeile für das Schreiben in den Vitolog in optolinkvs2_ini.py eingefügt

Zeilen für Logging und polllimit in settings_ini.py eingefügt

Dienst optolink-splitter neu definiert in  etc/systemd/system/optolink-splitter.service

in den Angaben für den System Dienst darf kein Kommentar mit # hinter den Defintionen stehen. Es gibt sonst Parse Fehler.

Nach einem Restart des Service bekomme ich folgende Anzeige bei der Status Abfrage für den Dienst:

pi@Pi4JMF:~/optolink $ systemctl status optolink-splitter
● optolink-splitter.service - Optolink VS2 Switch Service
Loaded: loaded (/etc/systemd/system/optolink-splitter.service; disabled; preset: enabled)
Active: activating (auto-restart) since Thu 2024-08-15 23:47:40 CEST; 1s ago
Process: 7912 ExecStart=/bin/bash -c source /home/pi/optolink/myvenv/bin/activate && exec /home/pi/optolink/myvenv/bin/python /home/pi/optolink/optolinkvs2_switch.py (code=exited, status=0/SUCCESS)
Main PID: 7912 (code=exited, status=0/SUCCESS)
CPU: 265ms

Der Dienst ist nicht avtive sondern activating, was bedeutet, dass der Dienst nicht vollstädig gestartet wurde. Daraus folgt, dass Vitoconnect nicht läuft.

[HerrP]

aber da steht doch "Main PID: 7912 (code=exited, status=0/SUCCESS)"

Für mich sieht das aus als wäre der Prozess erfolgreich gestartet.

mach mal

top -p 7912

Eigentlich sollte da jetzt CMD python3 stehen.

Hast du mal ein MQTT read im MQTT Explorer versucht? Kommt auf das cmnd ein resp ? dann liefe das skript.

Was sagt die Ausgabe im vitolog (wofür wir die Zeile eingebaut haben)? Lösch das vlt vorm Starten mal

>> Zeilen für Logging und polllimit in settings_ini.py eingefügt

ich denke du meinst du hast die Einträge entsprechend gesetzt? die stehen schon drin, du brauchst nix einfügen.

[HerrP]

ich hab mir auch noch mal ne venv gebaut und das mit dem Service versucht. Es geht bei mir auch nicht, mit keiner der bisherigen Varianten.

Wir müssen mal googeln, ChatGPT schein da nicht weiter zu bringen.

Aber heute is spät, morgen ist auch ein Tag

[HerrP]

die Variante mit

ExecStart=/home/pi/olstest/myvenv/bin/python /home/pi/olstest/optolinkvs2_switch.py

funktioniert bei mir doch. ich hatte mich vorher verschrieben.

Allerdings habe ich Python Vers. 3.9.2. Auf 3.12 soll es anders sein. siehe z.B. https://github.com/open3e/open3e/issues/98

hier ist open3e aber kein skript mehr. aber in der richtung müssen wir weiterschhauen.

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

ich habe deine Idee mit dem bash skript ausprobiert!

ein olstest.sh mit dem Inhalt

#!/bin/bash
source /home/pi/olstest/myvenv/bin/activate
exec /home/pi/olstest/myvenv/bin/python /home/pi/olstest/optolinkvs2_switch.py

die .sh muss ausführbar sein!

chmod +x /home/pi/olstest/olstest.sh

dann in dem Servicegedöhns:

WorkingDirectory=/home/pi/olstest/
Environment="PATH=/home/pi/olstest/myvenv/bin"
ExecStart=/home/pi/olstest/olstest.sh

das funktioniert bei mir!

das ist in meinen Augen zwar wenig Anderes als das

ExecStart=/bin/bash -c 'source /home/pi/optolink/myvenv/bin/activate && exec /home/pi/optolink/myvenv/bin/python /home/pi/optolink/optolinkvs2_switch.py'

aber wie gesagt - mit dem sh Skript funktioniert es.

[HerrP]

so, jetzt ist aber wirklich Zeit für's Bett. ggf. probier ich das morgen auf meinem Raspi 4, aber da iat auch 'nur' python V 3.11 drauf.

[dejmfse1]

Moin Phil,

du scheinst auch lieber eine Beziehung mit dem IT Kram zu pflegen als mit deinem Bett. 😉

Ich hatte gestern Abend den Splitter deaktiviert und die Vitoconnect wieder direkt angeschlossen. Ich bekam den Splitter weder in der alten noch in der neuen Version einfach nicht mehr zum fliegen.

Heute Morgen habe ich ihn wieder auf den RPi umgesteckt und er lief mit den alten systemctl Definitionen problemlos.

Die Ausgabe im Vitolog war übrigens:

Python executable path: /home/pi/optolink/myvenv/bin/python

was ja korrekt sein sollte.

Du hast recht damit, dass der Prozess erfolgreich gestartet war aber er war nicht "running" sondern "activating".

Zu dem bash script zum Setzen des venv. Das müsste, wenn es was bewirken sollte vor dem Start des Dienstes laufen. An welcher zeitlichen Stelle muss es dafür ausgeführt werden?

[dejmfse1]

<< Zu dem bash script zum Setzen des venv. Das müsste, wenn es was bewirken sollte vor dem Start des Dienstes laufen. An welcher zeitlichen Stelle muss es dafür ausgeführt werden?

vergiss diese Aussage von mir. Das script würde beides tun wäre allerdings kein Dienst mehr

[HerrP]

ich habe ja per Dienst das sh skript gestartet. das funktioniert bei mir wunderbar. Starten und Stoppen, Starten...

Python executable path: /home/pi/olstest/myvenv/bin/python.

alles gut und in meinen Augen ein Dienst?!?

[HerrP]

Guten Morgen erstmal! 😁

[HerrP]

könnte nur ein Problemchen geben: im Journal landen jetzt alle Consolen-Ausgaben:

das wird ruck zuck ziiieeemlich viel....

aber das könnte man  show_opto_rx = False  in der settings ini abschalten.

[HerrP]

aber wenn es jetzt wieder mit dem ganz normalen ExecStart = /venv/bin/python ol_switch.py klappt, scheint das Problem ja wo anders zu liegen.

ich befürchte nach wie vor Probleme mit dem Vitoconnect bei Heizungs-seitger Unterbrechung der Kommunikation.... schauen wir.

[dejmfse1]

ja, funktioniert im laufenden Betrieb bei mir. ABER, wenn ich den RPi boote, dann wird der Dienst nicht aktiv:

pi@Pi4JMF:~/optolink $ systemctl status optolink-splittersh
○ optolink-splittersh.service - Optolink-Splitter Service als shell
Loaded: loaded (/etc/systemd/system/optolink-splittersh.service; disabled; preset: enabled)
Active: inactive (dead).

Genau das hatte ich unter den alten Definitionen auch und erst nach einem Restart des Dienstes wird dieser Dienst aktiv:

pi@Pi4JMF:~/optolink $ systemctl status optolink-splittersh
● optolink-splittersh.service - Optolink-Splitter Service als shell
Loaded: loaded (/etc/systemd/system/optolink-splittersh.service; disabled; preset: enabled)
Active: active (running) since Fri 2024-08-16 17:19:12 CEST; 6s ago
Main PID: 930 (python)
Tasks: 4 (limit: 1581)
CPU: 320ms
CGroup: /system.slice/optolink-splittersh.service
└─930 /home/pi/optolink/myvenv/bin/python /home/pi/optolink/optolinkvs2_switch.py

Allerdings ohne die Vitoconnect Verbindung.

[dejmfse1]

wenn ci den journal Befehl absetze erhalte ich folgende Ausgabe:

pi@Pi4JMF:~/optolink $ journalctl -u olstest --since "2024-08-16 15:00"
-- No entries --
pi@Pi4JMF:~/optolink $

Wobei ich nicht weiß,ob der hier angegebene User "olstest" der richtige bei mir ist

[dejmfse1]

Also ich habe auch keine Vorstellung darüber warum es manchmal klappt und manchmal nicht.

Ich würde vorschlagen, dass wir das Geschreibe lassen und in den Abenstunden einmal eine TeamViewer Session durchführen. Das dürfte etwas zielführender sein.

[HerrP]

gute Idee!

dein journal befehl oben ist nicht richtig, du muss ihn mit deinem Service aufrufen, also

journalctl -u optolink-splittersh --since "2024-08-16 15:00"

ein Versuch, den wir machen könnten, wäre, einen Service für die Virtuelle Umgebung und einen für den optolink-switch, und in zweiterem 

After=network.target my_venv_service.service
Requires=my_venv_service.service

zu setzen.

Aber wir müssen erstmal sicher sein, ob es wirklich dadran liegt.

was hälst du von bsw 20:30 oder 21:00 heute Abend?! (ich wollte grad essen und dann ein kleines Nickerchen machen, die letzte Nach war recht kurz....)

[dejmfse1]

Gute Idee, wie wollen wir vorgehen? Kann man hier im Forum in den Privatmodus wechseln um private Daten auszutauschen?