nach dem Update von IPS v5.1 nach v5.2 habe ich beim Datentransfer über JSON-RPC zwischen zwei PIs groessere Probleme. Wenn beide neu gestartet wurden, läuft der Transfer (siehe PHP Script) ohne Probleme. Nach einer gewissen Zeit, werden aber keine Daten mehr übermittelt (siehe Temperaturgraph kurz vor 4 Uhr) und es werden Fehlermeldungen ausgegeben. Mit dem Fernzugriff von intern und extern ist alles andere in Ordnung.
Warning: file_get_contents(http://192.168.178.88:3777/api/): failed to open stream: Verbindungsaufbau abgelehnt in /usr/share/symcon/scripts/__rpc.inc.php on line 89
Fatal error: Uncaught Exception: Unable to connect in /usr/share/symcon/scripts/__rpc.inc.php:93
Stack trace:
#0 /usr/share/symcon/scripts/__rpc.inc.php(37): JSONRPC::makeRequest('http://192.168....', 'MyIPS@mymail...', 'password', 'SetValueFloat', Array, false)
#1 /var/lib/symcon/scripts/18087.ips.php(7): JSONRPC->__call('SetValueFloat', Array)
#2 {main}
thrown in /usr/share/symcon/scripts/__rpc.inc.php on line 93
Hat da jemand einen Tipp für mich, an was das liegen könnte und wie man es beseitigen kann.
Kannst du denn mal testen an welchem der beiden Pi’s es liegt? Also mal nur einen neu Starten und gucken ob es dann geht? Oder musst du beide neu Starten?
genau das habe ich auch gedacht und sogar schon gemacht.
[ul]
[li]Zuerst den sendenden PI neu gebootet, keine Veränderung es wird nichts mehr übertragen und es gibt die bekannten Fehlermeldungen.
[/li][li]Anschließend den empfangenden PI durchgebootet und nach kurzer Zeit werden wieder Daten übertragen
[/li][/ul]
Noch als zusätzliche Info, auf dem empfangenden PI läuft auch pivccu und damit der LAN-Adapter im Bridge Mode
hat etwas gedauert bis der Fehler wieder aufgetreten ist (~3 Tage). Die JSON-RPC-Kommunikation ist Heute kurz nach 3 Uhr Nacht wieder abgebrochen (siehe Hardcopy). Auf dem empfangenden PI kann die Konsole weiterhin aufgerufen werden (http://192.168.1XX.XX:3777/console/).
Lokal funktioniert der Aufruf übrigens ohne Probleme (siehe Hardcopy Local_Script.jpg)
Nach dem Neustart (~21:30) des empfangenden PIs läuft alles wieder wie gewohnt. Ein Neustart der sendenden PIs war nicht erforderlich.
Hab damit (JSON-RPC) jetzt auch Probleme, allerdings beim update von 5.2 auf 5.3 … aber etwas anders: Die JSON-Befehle kommen erst nach ziemlich genau 6 Minuten an. Die Zeiten auf den RasPis stimmen !
Und diese Latenzzeit steigt bei mir, jetzt nach etwa einer halben Stunde beträgt die Verzögerung schon 13 Minuten.
Da schaukelt sich irgendetwas auf…
top - 09:06:15 up 1:19, 1 user, load average: 2.39, 2.87, 2.68
Tasks: 150 total, 1 running, 91 sleeping, 0 stopped, 0 zombie
%Cpu(s): 36.5 us, 2.9 sy, 0.0 ni, 59.3 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
KiB Mem : 948304 total, 34292 free, 398104 used, 515908 buff/cache
KiB Swap: 204796 total, 3288 free, 201508 used. 463792 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
440 root 20 0 1416916 241720 33880 S 138.0 25.5 124:17.91 symcon
29701 fr24 20 0 25700 6960 1928 S 8.9 0.7 0:34.17 dump1090-m+
1783 root 20 0 9336 1612 1428 S 3.6 0.2 2:59.47 pigpiod
625 root 10 -10 13368 3112 2776 S 3.0 0.3 2:30.96 lcnpchk
31941 root 20 0 9732 3264 2740 R 0.7 0.3 0:00.18 top
Wie komme ich am einfachsten auf die 5.2 zurück ? Von Fragen nach Backups bitte ich abzusehen
NACHTRAG: Mein Beitrag ist hier im falschen Thread, glaube ich.
ich habe jetzt einfach ein wenige Wochen altes Backup des symcon Verzeichnisses zurückgespielt - allerdings die symon binary im bin Verzeichnis auf die 5.3. belassen und die Probleme sind verschwunden.
Es lag also weniger am upgrade von 5.2 nach 5.3. sondern vielleicht an den Modulupgrades, die ich parallel auch gemacht hatte.
@icey: Ich habe bisher keine Idee was dort schief laufen kann. Wenn die Konsole und der lokale Aufruf geht, dann bedeutet das, dass IP-Symcon per se korrekt funktioniert. Hast du irgendeine Firewall im Netzwerk installiert die ggf. auf die Menge der Anfragen früher oder später allergisch (DDoS) reagiert und blockiert?
ich bin auch etwas ratlos, zumahl der Fehler erst nach mehreren Tagen auftritt. Alles andere (Webfront, Remoteconsole, SSH-Zugriff, usw.) funktioniert ja weiterhin ohne Einschränkung.
Ja, bei mir läuft eine Firewall. Die beiden betroffenen PIs sind aber im gleichen Netzsegment, müssen also nicht über die Firewall kommunizieren. Sie können sich auch gegenseitig mit IPv4 anpingen, über RPC kommt aber die bekannte Fehlermeldung.
Ich habe auf dem Ziel-PI ein kleines Script erstellt, welches die LAN-Schnittstelle down und wieder up setzt und gehofft, dass ein Reset der LAN-Schnittstelle hilft. Leider auch erfolglos.
Ich kann dir anbieten, dass wir uns das Problem zusammen einmal ansehen, sobald es wieder auftritt. Aktuell habe ich nämlich noch keine Idee wer dies verursacht. Schick mir doch mal eine PM sobald es wieder da ist (oder ruf tagsüber gerne direkt im Office an)
ich werde den Ziel-PI3B+ nun mal „from scratch“ neu mit allen Zusatzkomponenten PIGPIO, Zigbee2Mqtt, Z-Wave und piVCCU auf Rasbian Buster (oder sollte ich noch bei Stretch bleiben) hochziehen und dann testen.
Sollte es dann immer noch bei dem Fehlerbild bleiben, nehme ich deine Hilfe gerne in Anspruch.
nach vielen Stunden durchflöhen von Logfiles und Wireshark dumps habe ich den Fehler endlich gefunden. Im DHCP Log habe ich gesehen, dass die IP-Adresse des IPsymcon-PI auch an einen AVM Repeater vergeben worden ist. Da der PI über LAN am Netzwerk angebunden ist und der AVM nur über WLAN, konnte der PI meistens schneller reagieren und war damit im arp-cache des Quellsystems gespeichert. Wenn das Quellsystem aber gerade seinen arp-cache gelöscht hat, der PI zu dem Zeitpunkt beschäftigt ist, antwortet der AVM schneller und schon steht die falsche MAC im arp-cache des Quellsystems. Da diese Konstellation sehr selten vorgekommen ist, hat es auch immer sehr lange gedauert, bis der Fehler wieder aufgetreten ist.
Saublöder Fehler, aber jetzt ist Ruhe. Warum mein DHCP-Server die gleiche IP an zwei unterschiedliche MAC-Adressen vergeben hat, konnte ich nicht mehr nachvollziehen.
