Replies: 2 comments 49 replies
-
|
thanks for reporting and for the debug data! what we see is that 'in the middle of a successfull communication' (after a correct response to a Viconn request) the Vicon re-initializes the VS2 telegram. This behavior did not appear in former times and is not covered by the program structure. I realized that with VS1 protocol already and I have to revert the program structure accordingly. This is not trivial because the reception of Viconn is running in a seperate thread independently from the main loop. I will hurry... |
Beta Was this translation helpful? Give feedback.
-
|
man finde den Fehler...
links der geschickte vitolog (mit splitter), rechts der kürzlich geschickte serlog (ohne splitter). sieht jemand irgendeinen Grund (oder auch nur einen Unterschied), warum das Vitoconnect links seinen Dienst abbricht, rechts aber weiterläuft?? aber zumindest funktioniert das re-init sauber... |
Beta Was this translation helpful? Give feedback.
-
|
ok, ich habe einen Unterschied gefunden: Du schreibst auf NKU_Tagesprogramm_ZP~0x9318 in Zeile 29/5234 auf Adr 9321 (offset 9) eine andere Uhrzeit. links 80 b0 01, rechts 80 b0 02. Wahrscheinlich die erste Schaltzeit am 2. WochenTag. Das ist seltsam organisiert: ich denke mal das ist so ein Fall, wo das bulk read nicht funktioniert ;-) aber eine andere Zeit am 2 Tag ist kein Grund, dass es dann nach dem Schreiben der (li und re gleichen) Zeit exakt 2 Tage weiter (offset 16 dez) abschmiert!?! |
Beta Was this translation helpful? Give feedback.
-
Die Organisation der Schaltzeiten im Fall der Zirkulationspumpe (ZP) sieht folgender maßen aus: 0x9318 Montag für jeden Tag stehen 8 Adressen(Schaltzeiten) zur Verfügung (zB. 9318 ,9319, 931A, 931B, 931C, 931D, 931E und 931F für Montag) Die 168 Bytes ergeben sich dann aus 7 Tage x 8 Schaltzeiten x 3 Bytes.
Bisher lese ich die Schaltzeiten noch nicht aus. Das LogFile zeigt was das Vitoconnect macht. Die Schaltzeiten selber wurden über ViCare geändert und das Vitoconnect überträgt die kompletten Schaltzeiten mit leichter Verzögerung an die Heizung.
Es fällt halt nur auf, das es immer in dem Bereich abschmiert wo man was verändert hat. Also ändere ich die Schaltzeiten für HK2 so schmiert es dann auch in dem Bereich ab, oder beim ändern der Schaltzeiten für WW dann im Adressbereich für WW. Gibts denn hier noch jemand der das gleiche Problem hat ??? |
Beta Was this translation helpful? Give feedback.
-
|
Das Vitolog (sendet und) sieht/empfängt ja nur Daten. Bei den beiden Logs sowohl die Daten identisch als auch das Timing (im Rahmen weniger ms +/-). ok, die letzte Antwort hat links 19ms länger gebraucht, aber dieser Rahmen ist oben mehrfach durchgegangen, vergl z.B. Z. 26, 36, ... und 19ms sind fast nix. Es wurde auch zwischendurch nix gepollt. Ich verstehe den Unterschied / den Grund nicht!? möglicherweise die Gesamtdauer der 168 Bytes? ich guck das noch mal, aber dafür brauch ich logs im Fehhlerfall, die vor dem Abbruch weiter zurück gehen. Wenn das so wäre, wäre das ziemlich problematisch, weil ja auch das Internet nicht auf ms deterministisch ist |
Beta Was this translation helpful? Give feedback.
-
@Mini-Disc ich hab vorhin im vitolog von @jomifa gesehen, dass bei ihm die Änderung / das Schreiben von 9318 bis 934f problemlos durchgelaufen ist und auch danach nix 'aussergewöhnliches' passiert ist (Neuverbindung oder so) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
is so ruhig geworden hier... haben sich jetzt alle dran gewöhnt oder geht wieder was wie von Geisterhand? @EarlSneedSinclair hast du Erfahrungen gesammelt mit der neuesten Version und kannst irgendwas berichten?! |
Beta Was this translation helpful? Give feedback.
-
|
Danke für die Nachfrage und die schnelle Lösung des Problems. Bei mir läuft es nun. Ich kann allerdings kein aussagekräftiges Log dazu liefern, da ich den Access Point im Keller temporär anders platzieren musste und die WLAN-Verbindung deshalb instabil ist. Aber sowohl der Optolink-Splitter als auch die ViCare-App kommen damit klar. |
Beta Was this translation helpful? Give feedback.
-
Durch den automatischen Reconnect zum Vitoconnect hat das Problem quasi an Bedeutung verloren. Was ich immer noch beim Aufrufen des Status angezeigt bekomme: 'Mar 07 03:45:22 raspberrypi3B python[7916]: Error Message 04' , das Ganze steht 10x drin, schaue ich morgen nach wird ne andere Zeit bei stehen. Hier kann ich aber nicht ausschliessen das dies durch einen Eintrag in poll_list.py hervorgerufen wird. Für Details könnt ich mal im Logfile suchen .... Das ist inzwischen fast 450MB groß. |
Beta Was this translation helpful? Give feedback.
-
|
das Den Log kannst du ja mal löschen oder zumindest umbenennen, damit ein neuer kommt (und irgendwann dann den alten wegwefen). danke für die Rückmeldungen euch beiden! |
Beta Was this translation helpful? Give feedback.
-
|
by the way - interessant wäre ja noch, ob die Änderung einer "weit hinten gelegenen" Schaltzeit, also Freitag oder so, auch wirklich geschrieben wird, oder ob das Schreiben des 168 Byte Datenpunkts vorher immer abbricht und alles beim alten bleibt.... ich guck auch noch mal anhand deiner zuletzt geschickten Logs, ob ein 'Gesamt-Timeout' pro Datennpunkt zu erkennen ist, was dann wohlmöglich zuschlägt |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Communication to Vitoconnect often freezes and then gets stuck in a loop linke this:
01-short.txt
02-short.txt
03-short.txt
04-short.txt
05-short.txt
06-short.txt
07-short.txt
08-short.txt
09-short.txt
This only affects the communication to Vitoconnect, reading the data for MQTT still works !
Restarting the optolink-splitter.service makes it work again for a while. Changing the switching times via ViCare also seems to speed up the problem.
Beta Was this translation helpful? Give feedback.
All reactions