ioBroker Adapter für die Smart Home integration

[Alex]

was für Geräte frägst Du denn noch in nem ähnlichen Intervall übers Netzwerk ab?

[thakikka]

Screenshot_30.jpg (95.22 KiB) 244 mal betrachtet

bspw. "harmony", fragt den Zustand der ganzen via Logitech-Harmony Hub eingebundenen Geräte ab
oder "smartgarden" für den Zustand vom Mähroboter
oder "alexa2" für den Zustand von sämtlichen da eingebundenen Devices

Ist das vergleichbar?

Es sind zu viele mögliche Baustellen, fürchte ich. Es könnte im Grunde ja an allem liegen...

BTW, ich sehe gerade, dass hier ( https://github.com/ylabonte/ioBroker.procon-ip/issues/8 ) ja offenbar schon mal jemand in einer früheren Version das Problem mit "ECONNRESET" hatte.

[Alex]

>>Ist das vergleichbar?
Eher nicht. Das meiste wird nicht übers lokale Netzwerk "direkt" abgefragt sondern sind cloudbasierte Systeme.

>>Es könnte im Grunde ja an allem liegen...
zu 99% liegt's an den WLan Strecken. Leg ein Kabel hin (Patchkabel, provisorisch) und probier's aus. Die Fehler sind ja scheinbar täglich/immer da (?) und nicht nur nur alle paar Wochen mal sporadisch. Zeigt sich ja also relativ schnell ob es dann weg ist oder nicht.

[yannic]

Sorry, dass ich mich erst jetzt wieder melde... aber eigentlich hat Alex den Support hier auch wunderbar übernommen! Da kann ich eigentlich nicht viel ergänzen.

Portainer scheint auf einen flüchtigen Blick nur eine grafische Weboberfläche für die (angeblich leichtere) Verwaltung von Docker, Swarm und Kubernetes zu sein. Also eigentlich für den Betrieb nicht nötig. Zumindest nicht, wenn dein NAS dir von Haus aus eine grafische Bedienoberfläche mitbringt, mit der du zufrieden bist. Hast du die Anleitung noch? Dann würde ich mir das auch mal anschauen.

Ich hätte sonst auch eine Anleitung (https://github.com/ylabonte/ioBroker.docker) und eigene Docker Images (https://hub.docker.com/r/labonte/iobroker) online, die ich selber nutze, um ioBroker auf meinem NAS laufen zu lassen. Aber das nur am Rande bemerkt. Ich denke nicht, dass das Problem darin zu suchen ist. Ich vermute ebenso wie Alex, dass die Verbindung zur Poolsteuerung nicht ganz stabil ist und der Browser, falls er denn die selbe Strecke nehmen muss, da einfach etwas hartnäckiger ist (z.B. ein großzügigeres Timeout hat, was anderes fällt mir gerade nicht ein), als mein Request über NodeJS. Vielleicht kann ich an dem Timeout noch etwas machen und zusätzlich z.B. drei Versuche unternehmen, bevor der Fehler geloggt wird.
Die Gegenprobe mit dem Kabel wäre sicherlich das Optimum! Voraussetzung dafür ist natürlich, dass ein ausreichend langes Kabel zur Verfügung steht.

Das mit dem Issue auf Github ist richtig. Wollte das auch ursprünglich in meiner ersten Antwort an dich verlinkt haben. Aber da es zu keiner Lösung des Problems, nur einem Herabsetzen der Fehlerstufe geführt hat und damals nur der Reset erwähnt wurde (in deinem ersten Post zum Problem aber nur das Timeout), dachte ich, dass ich nur Verwirrung stifte, wenn ich das alte Issue ins Spiel bringe.

[thakikka]

Ich habe nun testweise einen Netgear Repeater statt des Fritz-Repeaters genommen.

Exakt gleiche Problematik, die wie folgt aussieht:

In der FritzBox ist der Netgear Repeater stabil verbunden und dauerhaft "da" (unter Mesh und unter Netzwerk).

Lediglich der Poocontroller "verschwindet" und wird als "nicht verbunden" angezeigt. Erst wenn ich die Weboberfläche des Poolcontrollers im Browser aufrufe, wird der Poolcontroller unter Mesh und Netzwerk in der Fritzbox wieder als verbunden angezeigt.

Ich begreife das einfach nicht, wieso dieses eine Gerät sich nicht dauerhaft via WLAN-LAN-Verbindung verbinden lassen will. Ich muss mal überlegen, welches andere LAN-Gerät ich mal testweise da an den Repeater hängen könnte um zu sehen, ob das dann auch immer wieder "verschwindet".

Ihr glaubt nicht, wie sehr mich der Mist mittlerweile aufregt und vor allem an Zeit kostet. Hätte ich Idiot doch bloß ein LAN-Kabel in die Ecke gezogen, als hier alles aufgebuddelt war...

Muss ich ansonsten alternativ so eine Steckdosen-Verbindung kaufen und einrichten? Sind die stabiler? Wobei die WLAN-Verbindung im Grunde ja auch stabil ist, aber irgendwie nicht der Poolcontroller dauerhaft verbunden bleiben mag, obwohl der Repeater (mit dem er ja via LAN verbunden ist) dauerhaft stabil verbunden ist.

Ach man...

[Alex]

>>aber irgendwie nicht der Poolcontroller dauerhaft verbunden bleiben mag
Wenn er nicht verbunden wär, könntest Du ihn doch gar nicht über die Benutzeroberfläche aufrufen.

[thakikka]

Das ist ja das Verrückte! Ich kann den Poolcontroller jederzeit via Weboberfläche aufrufen.

Was ich beschrieben habe, war die Tatsache, dass zwischendurch der Poolcontroller als Gerät nicht mehr in der Fritzbox unter "Heimnetz" (sowohl bei "Mesh" als auch bei "Netzwerk") nicht (mehr) bei den bestehenden Verbindungen aufgeführt ist. Rufe ich dann die Weboberfläche via Browser auf, ist er wieder da.

[yannic]

Ich habe bislang nichts testen können. Wird sich auch noch etwas hinziehen. Aber um dir den Log in ioBroker nicht damit zuzumüllen, kannst du das Loglevel für den Adapter erhöhen, damit nur noch echte Error geloggt werden.

Loglevel eines Adapters ändern

Bildschirmfoto 2020-08-25 um 01.33.02.png (453.6 KiB) 216 mal betrachtet

(Das soll nicht heißen, dass ich nicht auch noch etwas tue, um mit solchen Verbindungsfehlern Log-schonender umzugehen. Aber bis dahin, könnte dir das den Log etwas sauberer halten.)

[thakikka]

Danke dir für den Tipp!

Ich beobachte aktuell ja fleißig alle Logfiles. Mir ist heute Morgen etwas aufgefallen.

Code: Alles auswählen

[...]
2020-08-25 00:29:18.972 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 00:49:13.114 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 01:31:58.850 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 01:45:40.919 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 03:31:45.268 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 03:36:27.256 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 03:50:45.511 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 03:53:39.482 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 04:29:01.076 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 05:15:13.666 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 06:02:32.329 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 06:27:44.668 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 06:30:59.731 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 07:02:39.163 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 07:07:42.213 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 07:36:54.539 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 07:55:12.844 - warn: procon-ip.0 (2147) Error: read ECONNRESET
2020-08-25 08:08:10.583 - info: alexa2.0 (516) Alexa-Push-Connection disconnected - retry: Retry Connection in 35s
2020-08-25 08:08:45.228 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:08:46.437 - info: alexa2.0 (516) Alexa-Push-Connection established. Disable Polling
2020-08-25 08:08:48.172 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:08:51.116 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:08:54.188 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:08:57.132 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:09:00.204 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:09:03.148 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:09:06.220 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
2020-08-25 08:09:09.164 - warn: procon-ip.0 (2147) Error: connect ETIMEDOUT 192.168.0.111:80
[...]

Wie man sieht, kommt dieser ECONNRESET unregelmäßig und immer wieder.

Das ETIMEDOUT kam aber erst heute früh um 08:08 Uhr. Also habe ich mal ins Ereignisprotokoll der Fritzbox geschaut und das gefunden:

Screenshot_31.jpg (13.38 KiB) 210 mal betrachtet

Das findet sich offenbar immer dann im Log, wenn die Verbindung ganz (ETIMEDOUT) abreisst.

Ich habe nach der Meldung mal gegoogelt und offenbar liegt es an "WPA3". Ich habe daraufhin eben mal alles auf WPA2 umgestellt und beobachte weiter.

Ich glaube aber offen gesagt nicht, dass es final daran liegt, denn die Umstellung auf "WPA2+WPA3" habe ich erst kürzlich vorgenommen und davor gab es das Problem hier auch bereits.

Aber endlich konnte ich wenigstens mal einen direkten Zusammenhang in einem Logfile finden.

[yannic]

Ich habe nun ein Update veröffentlicht, das dir hoffentlich ein Wenig hilft.

Natürlich kann ich nichts an den Verbindungsunterbrechungen tun. Aber

• ich habe das Timeout konfigurierbar gemacht und
• einen Toleranzwert eingebaut, mit dem man einstellen kann, nach wie vielen Fehlern in der Status-Abfrage eine Warning geloggt wird.
• Für das Senden von Befehlen habe ich es so umgebaut, dass immer drei Versuche unternommen werden, den Schaltbefehl abzusetzen, bevor es einen Error gibt.

[thakikka]

Danke dir!

Ich bin mit den Erkenntnissen mittlerweile ein bisschen weiter, aber umso verwirrter:

- Irgendwann kommen die Fehler im Log.
-> Der Status unter Instanzen ist dann auch gelb. Ein Neustart der Instanz o.ä. ändert nichts daran.
-> In der FritzBox taucht der Poolcontroller nicht mehr auf, lediglich der Repeater, an dem er (via LAN-Kabel) angeschlossen ist.
-> Rufe ich die Weboberfläche des Repeaters auf, taucht dort der Poolcontroller spannenderweise NICHT unter den angeschlossenen Geräten auf.
-> Egal, was ich tue - erst wenn ich die Weboberfläche des Poolcontrollers im Browser aufrufe (dann dauert es meist etwas länger), taucht er plötzlich wieder überall auf: In der Fritzbox (Mesh), im Repeater (verbundene Geräte) und der Instanz-Status wechselt auf Grün.

Jetzt wäre meine Schlußfolgerung, es könnte an dem Repeater liegen, dass der irgendwie den Poolcontroller, der an ihm via LAN angeschlossen ist, "schlafen legt". Kann aber nicht sein, denn ich habe es ja bereits mit anderen Repeatern ausprobiert und dort war das Verhalten exakt gleich, sowohl bei FritzRepeatern als auch bei Fremdmarken-Repeatern.

Das macht mich echt verrückt.

Liegt es vielleicht am Poolcontroller? Am LAN-Anschluss? Kann da irgendwas "kaputt" sein?

[Alex]

Nein da ist nichts kaputt und der kennt auch kein Standby.
Frag es halt mal bei AVM an, wie der repeater mit Geräten umgeht die angeschlossen sind, selber aber stundenlang keinen Traffic erzeugen. Wenn er die dann aus der Liste rausnimmt weil er denkt sie sind offline, ist das ein Thema von AVM. ... oder es sind halt doch noch irgendwo irgendwelche StandBy / Energiespar / Green-Ethernet Funktionen aktiv.

[markus]

Sehr interessant das Thema, weil bei mir exakt das gleiche Verhalten ist. (Nur Zugriff mit Handy)
Ich bilde mir zudem noch ein, das es auch eine Rolle spielt mit welchem meiner Repeater ich verbunden bin.

Ich lege auf jeden Fall jetzt ein LAN Kabel, dann ist hoffentlich Ruhe....

[Renderender]

Ich habe meinen PoolController mit Kabel ohne repeater an der FB7490... auch Hier ist er ab und an nicht mehr unter den aktiven Geräten aufgelistet, obwohl erreichbar...

[thakikka]

Screenshot_43.jpg (204.56 KiB) 141 mal betrachtet

Ich habe die Relais teilweise geändert. Wie bekomme ich die "Objects" aktualisiert, speziell die Spalte "Name"? Macht er das automatisch irgendwann? Ein Reload der Instanz hat nicht geholfen.

edit: Ich habe nun einfach die Instanz gelöscht und anschließend neu erstellt.

[yannic]

Ups, ich dachte eigentlich, dass ich hier noch Freitagabend geantwortet hätte. Naja, jedenfalls hast du da definitiv einen Bug entdeckt. Als ich irgendwann bei den Überarbeitungen für die Version 1.0 kurzerhand die Namensattribute für alle Readings ergänzt habe, habe ich nicht bedacht, dass ich darauf achten muss, wenn sich das Label ändert. Das muss ich mit dem nächsten Update fixen.

Bis dahin ist das von dir gewählte Vorgehen (Adapter Instanz löschen und neu anlegen) der einzige Workaround. Sorry.

[thakikka]

Kommt man eigentlich irgendwie an das Fehlerlog ran? Ich würde gerne via ioBroker erkennen, wenn bspw. die Pumpe durch eine Regel einen Fehler produziert hat (und ausgeschaltet wurde).

[Alex]

/log/error.log

...ein Eintrag sieht irgendwie so aus
E33=14.sep.2020 09:17:40,129.8 mV

für die Analog-Alarme würde ... E10 bis E17 an erster Stelle stehen....

[Bernd P.]

Probleme mit Raspi4 8GB Ram und Procon IP 1.1
Ich habe jetzt mal Testweise den IObroker auf einen Raspberry 4 mit 8GB Ram installiert, läuft alles sehr gut nur der Procon-IP Adapter in der neuesten Version bekommt keine Verbindung zum Poolcontroller, die Objekte werden zwar geladen aber bei Verbindung bleibt er GELB. Ich würde gerne die Version 1.0.2 am Raspi testen aber leider finde ich die bei Github nicht und über npm i iobroker-ip@1.0.2 lädt er mir die auch nicht.

Auf meiner Synology mit Iobroker im Docker läuft noch die V1.0.2 ohne Probleme, ich wüßte jetzt nur gerne obs an meiner Raspi installation liegt oder an der neuesten Version vom Procon Adapter.

[yannic]

Hi Bernd,
die Version 1.1.0 befindet sich derzeit noch in der Entwicklung (weshalb es auch noch kein npm Paket mit entsprechender Versionsnummer gibt).

Die Installation des Adapters sollte inzwischen eigentlich wenn möglich wie hier im oberen Abschnitt beschrieben, über das ioBroker latest/Beta Repository durchgeführt werden.

Der Rollback auf die Version 1.0.2 sollte eigentlich mittels

Code: Alles auswählen

sudo -u iobroker npm i iobroker.procon-ip@1.0.2 --production --prefix=/opt/iobroker

und anschließendem Neustart des Adapters funktionieren (hat es zumindest beim Selbstversuch eben). Die Tabellen-Ansicht der Adapter in ioBroker muss danach auch aktualisiert werden (über den Button "Adapterinformationen aktualisieren" oberhalb der Tabelle), damit hier wieder die korrekte Version angezeigt wird.

Viele Grüße
Yannic