UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Rene55]

@integer63 Danke für die Rückmeldung. Wie hast du denn deinen WR per Modbus physikalisch angeschlossen. Bei mir sehe ich nur die Möglichkeit über das integrierte WLAN-Modul.

[Ralf Roessler]

@rene55 Hi Rene, habe das neue Update installiert, leider noch immer der gleiche Fehler, es funktioniert einmal am Anfang und danach kommt der Timeoutfehler (es funktioniert ganz selten).
" [initializeStation] error: AxiosError: timeout of 4000ms exceeded"

[Rene55]

@ralf-roessler Das ist ärgerlich. Da bringt die Ausdehnung des Timeouts nicht wirklich was. Ich hatte heute auch 4 Warnungen im Log. Hast du eine dünne/wackelige Internetverbindung? Das könnte erklären, dass du viel mehr dieser Timeouts hast.

[Ralf Roessler]

@rene55 Internet steht stabil, daran kann es nicht liegen. Arbeite den ganzen Tag problemlos darüber. Komisch ist das nach einem Neustart des Adapters erst mal alles eingelesen wird. Da kommen die Daten einmal.

[Rene55]

@ralf-roessler Ok, stabiles Internet ist schon mal gut. Ich geh mal davon aus, dass die Bandbreite eventuell durch HomeOffice / Videostreaming nicht voll ausgereizt ist. Aber dann fällt mir auch schon nichts mehr ein.

[Ralf Roessler]

@rene55 trotzdem danke für deine Hilfe

[integer63]

@rene55 Ich bin nicht ganz sicher, ob ich die Frage richtig verstehe. Du brauchst ein Gerät, auf dem ein Venus OS läuft (bei mir ist es ein Cerbo GX, kann aber auch ein Raspi sein). Dort kann man dann Modbus aktivieren:

Und dann über die Netzwerkadresse des GX Gerätes ansprechen:

[Rene55]

@integer63 Ja. das ist schon die Antwort auf meine Frage. Also brauche ich noch ein Zusatzgerät und die Anbindung per RS485. Da ist bei mir schon Ende, da ich keinen RS485 Anschluss sondern nur WLAN habe. Ich geb mal Gas bei meinen Adapter

[Bambulko]

@Rene55 Ich bekomme jetzt ziemlich viele Fehlermeldungen:

solarmanpv.0
	2023-02-13 12:52:13.064	error	DB closed
solarmanpv.0
	2023-02-13 12:52:13.063	error	Error: DB closed at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25) at Socket.<anonymous> (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:151:20) at Object.onceWrapper (events.js:520:26) at Socket.emit (events.js:400:28) at TCP.<anonymous> (net.js:686:12)
solarmanpv.0
	2023-02-13 12:52:13.062	error	unhandled promise rejection: DB closed
solarmanpv.0
	2023-02-13 12:52:13.046	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
solarmanpv.0
	2023-02-13 12:52:13.018	error	DB closed
solarmanpv.0
	2023-02-13 12:52:13.017	error	Error: DB closed at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25) at Socket.<anonymous> (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:151:20) at Object.onceWrapper (events.js:520:26) at Socket.emit (events.js:400:28) at TCP.<anonymous> (net.js:686:12)
solarmanpv.0
	2023-02-13 12:52:12.991	error	unhandled promise rejection: DB closed
solarmanpv.0
	2023-02-13 12:52:12.989	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
solarmanpv.0
	2023-02-13 12:52:12.986	error	DB closed
solarmanpv.0
	2023-02-13 12:52:12.966	error	Error: DB closed at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25) at Socket.<anonymous> (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:151:20) at Object.onceWrapper (events.js:520:26) at Socket.emit (events.js:400:28) at TCP.<anonymous> (net.js:686:12)
solarmanpv.0
	2023-02-13 12:52:12.965	error	unhandled promise rejection: DB closed
solarmanpv.0
	2023-02-13 12:52:12.963	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
solarmanpv.0
	2023-02-13 12:52:12.944	error	DB closed
solarmanpv.0
	2023-02-13 12:52:12.926	error	Error: DB closed at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25) at Socket.<anonymous> (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:151:20) at Object.onceWrapper (events.js:520:26) at Socket.emit (events.js:400:28) at TCP.<anonymous> (net.js:686:12)
solarmanpv.0
	2023-02-13 12:52:12.925	error	unhandled promise rejection: DB closed

[Rene55]

@bambulko Das sieht nicht so gut aus. Kamen die Fehler beim Start oder beim Beenden des Adapters - oder einfach so?

[Bambulko]

@rene55 Einfach so. Das ging ein paar Minuten so und hat dann von selbst aufgehört.

[Rene55]

@bambulko Da scheint wohl zu diesem Zeitpunkt deine ioBroker DB nicht da gewesen zu sein: Error: DB closed at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25).
Warum auch immer. Bitte weiter beobachten.

[typhos]

@rene55 Seit heute kann ich das auch durchgängig beobachten. Beim Neustart des Adapters wird einmal sauber eingelesen - alle folgenden Starts (per cron) laufen auf das Timeout. Internet ist stabil. Probleme mit der China-Cloud? In der (Handy-)App bekomme ich alle Daten aktuell angezeigt.

[Ein ehemaliger Benutzer]

@typhos laeuft hier einwandfrei, keine Probleme mit Timeouts..

[typhos]

@ilovegym Komisch... Wenn ich den Request per curl von der Maschine aus mache, funktioniert es immer wunderbar... aus dem Adapter irgendwie nicht mehr. Jemand eine Idee, was das sein könnte oder was man noch prüfen könnte?

[Rene55]

@typhos Da bin ich dann auch ein bisschen überfragt. Ich hatte gerade einen Ausfall des Accesspoints, an dem mein Inverter hängt. Da bekam ich dann auch aus der ChinaCloud mehrere unbeantwortete Abfragen: 2023-02-15 11:18:05.208 warn [getDeviceData] error: undefined. Ob es damit zusammenhängt ? ? ?

[Ein ehemaliger Benutzer]

@typhos ich hab 2 Stueck, laufen. Hast du irgendn Blocker Pihole oder sowas drin?

[typhos]

@rene55 Ich denke nicht... was ich beobachten konnte, ist, dass ein schnell wiederholter Request deutlich schneller geht - vermutlich cachen die Jungs in der Cloud die Responses ein paar Sekunden. Ich habe dann testweise mal den Adapter auf Start alle 30 Sekunden gestellt, dann bekomme ich so ziemlich jedes 2. Mal ne vernünftige Antwort (vermutlich dann immer die gecachte vom vorherigen Request, der auf einen Timeout gelaufen ist)...
Wäre es möglich, dass man den Timeout mal selbst setzen kann im Adapter? Vielleicht ist es - aus welchen Gründen auch immer - mit 4s doch ein bisschen eng? Auch wenn ich das Gefühl habe, dass die Requests per curl schneller sind als 4s.

[typhos]

@ilovegym Blocker hab ich nicht laufen... generell funktionieren die Requests ja auch - dauern vermutlich nur zu lange...

[Rene55]

@typhos Ich hab schon von Version 0.2.0 (2 Sekunden) in Version 0.2.2 auf 4 Sekunden hochgesetzt. Ich selber glaube nicht, dass ich deswegen weniger TimeOuts hatte. Parametrierbar ist das nur im Quellcode.