ioBroker-Objekte der piVCCU3 nicht immer richtig

[HerrFrodo]

Hallo zusammen,

ich nutze schon seit einigen Jahren den Raspi 4b mit der Kombi von ioBroker und piVCCU.
Neben kleinen Problemchen war bisher immer alles schnell lösbar.
Nun habe ich nach längerer Zeit (leider kann ich nicht sagen wie lange und welche Vorversionen) das gesamte System geupdatet....

Ich erinnere mich noch, dass bei dem Update eine Mitteilung kam, dass Objektbezeichnungen mit einem Punkt in Unterstrich geändert werden -> von xxx.xxx in xxx_xxx
Danach musste ich bei den Modbus-Adaptern, mit denen ich Victron-Geräte auslese, einiges ändern.....wohl dem der ALIASe verwendet

Leider läuft seitdem der Homematic-Adapter nicht mehr zuverlässig, obwohl alles auf grün ist.

Im Webbrowser der pivCCU werden Werte aktualisiert (auch im iPhone unter pocketControl) und immer korrekt angezeigt.
In den Objekten leider nicht. Sie bleiben teils tagelang unverändert, wenn ich nicht den Adapter neu starte.
Danach geht es eine kurze Zeit wieder.

Hier meine Systeminfos:
Raspberry Pi 4 Model B Rev 1.4

cat /etc/os-release

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

CPU: 41,33 %
RAM: 47,1 %
Betriebszeit: 2d2h
Verfügbar: 4.0.24
Installiert: 4.0.24
Ereignisse: ⇥27 / ↦13
Plattform: linux
Betriebssystem: linux
Architektur: arm
CPUs: 4
Geschwindigkeit: 1500 MHz
Modell: ARMv7 Processor rev 3 (v7l)
RAM: 3.7 GB
System-Betriebszeit: 2 T. 02:11:52
Node.js: v16.20.2
time: 1693220929444
timeOffset: -120
Adapter-Anzahl: 492
NPM: 8.19.4
Datenträgergröße: 13.9 GB
Freier Festplattenspeicher: 3.4 GB
Betriebszeit: 2 T. 02:11:35
Aktive Instanzen: 27
Pfad: /opt/iobroker/
aktiv: true

GCC version 8.3.0
Git-version 2.20.1
Kernel-release 5.10.103-v7l+
Knoten openssl-version 1.1.1v+quic
Perl-version 5.28.1
Python version 2.7.16
Python 3 version 3.7.3
OS openssl-version 1.1.1n
OpenSSL-Bibliothek OpenSSL
v8-version 9.4.146.26-node.26
Bash-Version 5.0.3

HomeMatic ReGaHSS
Installierte Instanzen: 1
Verfügbare Version: 3.0.47
Installierte Version: 3.0.47

HomeMatic RPC
Installierte Instanzen: 3
Verfügbare Version: 1.15.19
Installierte Version: 1.15.19

Beispiel wired aktoren - hm-rpc.2
Hier, obwohl die Lampe an ist und auch in Homematic und pocketControl korrekt angezeigt wird:

Ebenso bei diesem wired Aktor:

HM-RPC.1 - HM IP
Jetzt geht er, oft nicht - erst nach neustart:

Bei den Funk-Wand-Thermostaten(hm-rpc.0.admin), ist mir bisher noch kein Fehler aufgefallen.

Was braucht ihr noch für Infos?

Vielen Dank!!!

[Homoran]

@herrfrodo bevor ich hier alles versuche nachzuvollziehen, schalte bitte mal Sentry in den Instanzen ab

wenn das nicht hilft, bitte ein debug-log vom Neustart der rpc Instanzen

[Thomas Braun]

@herrfrodo sagte in ioBroker-Objekte der piVCCU3 nicht immer richtig:

Nun habe ich nach längerer Zeit (leider kann ich nicht sagen wie lange und welche Vorversionen) das gesamte System geupdatet....

Dann wäre ich aber auch bis ans Ende gelaufen und hätte den Buster durch Bullseye / Debian 11 ersetzt. Und nodejs hätte ich auch auf v18 gehoben.

[HerrFrodo]

@homoran vielen Dank für Deine schnelle Antwort!
Ich habe nun bei den HM-Instanzen Sentry deaktiviert.

Ich schau mir das nun genauer an und melde mich.

Besten Dank!

[HerrFrodo]

@thomas-braun Ist mir leider heute auch aufgefallen....
Ich wollte nur vorher Googeln was ich beachten muss, wenn ich 10 durch 11 ersetze und node.js von 16 auf 18.
Mitunter braucht man viel Zeit um alles wieder ans laufen zu bringen - aber wem sag ich das.

[Thomas Braun]

@herrfrodo sagte in ioBroker-Objekte der piVCCU3 nicht immer richtig:

Mitunter braucht man viel Zeit um alles wieder ans laufen zu bringen

Pro Tip: Je häufiger man sein Gesamtsystem auf Stand bringt desto weniger Zeit muss man da insgesamt investieren.

[HerrFrodo]

@homoran Gibt es die Möglichkeit eines "Watchdogs", um die HM-Adapter/Objekte zu checken?
Beim diyBMS verwende ich fb-presence um zu checken ob die WLAN-Verbindung besteht. Das geht auch mit dem ping-Adapter.
Bei den hm-rpc.x fehlt mir das Wissen.
Höchstens über eine Abfrage der Timestamps.
Hast Du dazu eine Idee?

[HerrFrodo]

@thomas-braun Hast Du einen Tip was ich bei 10 auf 11 beachten muss?

[Thomas Braun]

@herrfrodo

Da hab ich mir sogar seinerzeit schon mal Gedanken zu gemacht:

https://forum.iobroker.net/topic/47213/upgrade-von-debian-10-buster-auf-11-bullseye

[Homoran]

@herrfrodo sagte in ioBroker-Objekte der piVCCU3 nicht immer richtig:

Höchstens über eine Abfrage der Timestamps.

aber auch das wäre die falsche Herangehensweise.
Wenn etwas nicht klappt muss die Ursache behoben werden.
Alles andere ist herumdoktern an Symptomen.

bei mir läuft hm-rpc seit knapp 10 Jahren sauber durch.

Mehrere Generationen piVCCU/YAHM/lxccu/CCU1 sowie diverse Generationen ioBroker Installationen auf diverser Hardware.

[HerrFrodo]

@thomas-braun Ja Wahnsinn - beim Scrollen nach unten gibts gar kein Ende.....doch.
Die Anleitung finde ich super! Danke für Deine Arbeit und Doku!!!
Wenn ich mir die Frage erlauben darf - wurde die Anleitung im weiteren Verlauf noch geändert?

Ich mach ne SD-copy und probiere das dann aus.

[Thomas Braun]

@herrfrodo sagte in ioBroker-Objekte der piVCCU3 nicht immer richtig:

Wenn ich mir die Frage erlauben darf - wurde die Anleitung im weiteren Verlauf noch geändert?

Was meinst du damit?
In der 'heißen' Upgrade-Phase ist das immer um Dinge ergänzt worden, die bei mir gar nicht aufgetreten sind.
Z. B. das mit dem gcc-8-base hatte ich auf meinem eigenen System nicht.

[HerrFrodo]

@homoran Bei mir lief es bis zum Update auch super.

Grundsätzlich stimme ich Dir zu!
Aber! Vielleicht möchte ich sowas gerne haben, weil ich ein spielmops bin

[HerrFrodo]

@thomas-braun said in ioBroker-Objekte der piVCCU3 nicht immer richtig:

@herrfrodo sagte in ioBroker-Objekte der piVCCU3 nicht immer richtig:
was meinst du damit?

Ich wollte in Erfahrung bringen, ob ich bis zum Ende alles durchlesen muss, um richtig auf Bullseye umzustellen oder ob Du nachträglich in Deiner Anleitung irgendwas geändert hast.

[Thomas Braun]

@herrfrodo

Nein, wenn dein System nicht komplett verfummelt ist kannst du dich am initialen Posting entlang hangeln.

[HerrFrodo]

@thomas-braun na toll.....soviel zu verwurschtelt.....

Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Get:3 https://repos.influxdata.com/debian jessie InRelease [7,038 B]
Hit:4 https://deb.nodesource.com/node_16.x buster InRelease
Get:5 https://packages.grafana.com/oss/deb stable InRelease [5,984 B]
Hit:6 https://apt.pivccu.de/piVCCU stable InRelease
Hit:7 https://deb.nodesource.com/node_18.x bullseye InRelease
Err:3 https://repos.influxdata.com/debian jessie InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D8FF8E1F7DF8B07E
Err:5 https://packages.grafana.com/oss/deb stable InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 963FA27710458545
Fetched 7,038 B in 2s (4,180 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://repos.influxdata.com/debian jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D8FF8E1F7DF8B07E
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.grafana.com/oss/deb stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 963FA27710458545
W: Failed to fetch https://packages.grafana.com/oss/deb/dists/stable/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 963FA27710458545
W: Failed to fetch https://repos.influxdata.com/debian/dists/jessie/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D8FF8E1F7DF8B07E
W: Some index files failed to download. They have been ignored, or old ones used instead.

[HerrFrodo]

@thomas-braun Grafana und Influx nutze ich nicht - kann weg
Wie soll ich das ohne wurschteln machen?

[Thomas Braun]

@herrfrodo

Jessie ist komplett falsch, da gehört Buster in die list-Datei. Das ist wohl 'schon immer falsch' gewesen bei dir. Und dann müssen die Keys für grafana sowie influxdb frisch reingeladen werden. Gibt aber auch dazu Threads von mir.

Edith:

sudo rm /etc/apt/sources.list.d/graf*
sudo rm /etc/apt/sources.list.d/influ*
sudo apt update

[HerrFrodo]

@thomas-braun Viel besser!

pi@raspberrypi:~ $ sudo rm /etc/apt/sources.list.d/graf*
pi@raspberrypi:~ $ sudo rm /etc/apt/sources.list.d/influ*
pi@raspberrypi:~ $ sudo apt update
Hit:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:2 http://archive.raspberrypi.org/debian buster InRelease
Hit:3 https://deb.nodesource.com/node_16.x buster InRelease
Hit:4 https://apt.pivccu.de/piVCCU stable InRelease
Hit:5 https://deb.nodesource.com/node_18.x bullseye InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

[HerrFrodo]

@thomas-braun Damit ist aber Grafana und Influx noch da, gelle.
Das gockel ich dann in Deinen Threads