Weihnachtsangebot 2025! 🎄

[GregorS]

@humidor
Welche Variablen?

Im ersten Teil frage ich den Zustand ab (Kann man auch zeitgesteuert machen, aber ich finde es so besser)
Mit dem exec führe ich einen Befehl wie in PuTTY aus.
Stoppe damit den Adapter auf der Konsolenebene.
Der Rest ist nur Anzeige im Log.

Eingeschaltet wird wieder im 2. Teil.

[Humidor]

@gregors ah ja, hab nicht genau geschaut, danke.

[Bertman2000]

Hab den Thread gerade nur schnell überflogen. Hatte letzte woche ein ähnliches problem. Hatte es auch genau so eingesetzt wie hier beschrieben. Leider hat dies z.B. beim OctoPrint Adapter immer dazu geführt, dass nach einem Neustart ( ausschalten und wieder einschalten) der Key verloren ging. Bin dann hier im Forum darauf gestoßen, dass der Aufruf, so wie er hier gemacht wird zu problemen führen kann. Ganz genau habe ich den Grund nicht verstanden. Will jetzt auch keine Halbwahrheiten verbreiten. Auf jeden fall hats danach funktioniert. Finde den Link leider nicht mehr in meiner Chroik.

Lange Rede kurzer Sinn - mach es lieber so, da gehst du ggf. später auftretenden Problemen aus dem Weg:

extendObject('system.adapter.' + Adaptername, {common: {enabled: Zustand}});

[Humidor]

Könnt ihr die Info mit dem Java Script zusammenführen?

[paul53]

@bertman2000 sagte: mach es lieber so

Diese Version verwendet intern getObject(id) und setObject(id), bringt also keinen Vorteil.

[Humidor]

ich habe aktuell das Blockly laufen (im Adapter aktiviert), funktioniert nicht, die Adapter laufen weiter

2022-11-05 22:00:00.043 - info: javascript.0 (143862) script.js.common.Adapter_Blockly: exec: iobroker stop fronius.0
2022-11-05 22:00:00.071 - info: host.raspberrypi instance system.adapter.daswetter.0 started with pid 164348
2022-11-05 22:00:00.079 - info: javascript.0 (143862) script.js.common.Adapter_Blockly: exec: iobroker stop modbus.0
2022-11-05 22:00:00.116 - info: javascript.0 (143862) script.js.common.Adapter_Blockly: exec: iobroker stop modbus.1
2022-11-05 22:00:00.148 - info: javascript.0 (143862) script.js.common.Adapter_Blockly: exec: iobroker stop mqtt.0
2022-11-05 22:00:34.974 - error: modbus.1 (143976) Request timed out.
2022-11-05 22:01:25.958 - error: modbus.1 (143976) Client in error state.
2022-11-05 22:04:41.528 - error: modbus.0 (164056) Request timed out.
2022-11-05 22:05:21.732 - error: modbus.0 (164056) Client in error state.
2022-11-05 22:11:51.678 - error: modbus.1 (143976) Request timed out.
2022-11-05 22:13:17.061 - error: modbus.1 (143976) Client in error state.
2022-11-05 22:25:53.708 - error: modbus.0 (164056) Request timed out.
2022-11-05 22:29:52.950 - error: modbus.0 (164056) Client in error state.

[Ein ehemaliger Benutzer]

Warum nicht einfach :

Die Datenpunkte findet man nur im "Expertenmodus".

evtl noch "Kommando "setObject" im Javascript adapter erlauben. Bin mir aber nicht sicher ob das muss.

[Humidor]

@dreistein ich sehe den Alive-Status nicht im Objektbaum, habe Expertenmodus auch aktiviert

jetzt hab ichs gefunden, unter System-Adapter dort findet sich der Alive.

[paul53]

@humidor sagte: sehe den Alive-Status nicht im Objektbaum

Unter "system.adapter.fronius.0".

[Humidor]

@paul53 jup jetzt macht er es, es gibt da aber ein Problem

um 6:00 gestartet, hat er sich um 6:25 terminiert ?

2022-11-08 06:25:37.062 - info: fronius.0 (143811) Got terminate signal TERMINATE_YOURSELF
2022-11-08 06:25:37.122 - info: host.raspberrypi stopInstance system.adapter.fronius.0 send kill signal
2022-11-08 06:25:37.566 - info: fronius.0 (143811) terminating
2022-11-08 06:25:37.569 - info: fronius.0 (143811) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2022-11-08 06:25:38.140 - info: host.raspberrypi instance system.adapter.fronius.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)

2022-11-08 06:00:00.124 - info: host.raspberrypi instance "system.adapter.fronius.0" enabled via .alive
2022-11-08 06:00:00.220 - info: host.raspberrypi "system.adapter.fronius.0" enabled
2022-11-08 06:00:00.280 - info: host.raspberrypi instance system.adapter.fronius.0 started with pid 143811
2022-11-08 06:00:04.761 - info: fronius.0 (143811) starting. Version 1.1.3 in /opt/iobroker/node_modules/iobroker.fronius, node: v16.17.1, js-controller: 4.0.23
2022-11-08 06:00:23.437 - warn: fronius.0 (143811) getLoggerInfo: Error: connect EHOSTUNREACH 192.168.0.96:80

manuell gestartet, läuft er.

[Ein ehemaliger Benutzer]

@humidor

Um 06:25 läuft deine PV schon ?
Verrückt.

[Humidor]

@dreistein was hat das damit zu tun, ich habe noch keine Routine, damit ich den Adapter abschalte, wenn die PV nichts liefert, bzw. sobald die PV anspringt, das muss ich über die Tageszeit, Lieferung bzw. Hauszähler lösen.
Damit hat das aber nichts zu tun.

[Thomas Braun]

@humidor sagte in Adapter ein/ausschalten?:

Error: connect EHOSTUNREACH 192.168.0.96:80

Die Kiste (bzw. der Port 80) ist nicht erreichbar.

[Humidor]

@thomas-braun OK, why ?

[Thomas Braun]

@humidor

Das weiß ich nicht.
Dienst läuft nicht, WLAN-Kabel gekappt, Störung in der Stratosphäre?

Siehst du die IP denn grundsätzlich im Netz? Pingt die?

[Ein ehemaliger Benutzer]

@Thomas-Braun
Ich hab auch noch einen: Nachtabschaltung im Wechselrichter aktiv ?

[Humidor]

@dreistein Ja sicher, der Fronius schläft tief und fest

der Rapi4 hängt am Lan, kein WLan.

[Humidor]

warum fkt. der Cron nicht ?

[Ein ehemaliger Benutzer]

@humidor
Falsche Zeitzone vieleicht ? Uhrzeit falsch ?
UND bei uns im Norden gibt es im Sommer keine Astronomische Nacht. Die Sonne steht nicht weit genug unter dem Horizont.

Du kannst auch den Trigger umbauen und dann auf "Nicht verbunden" Triggern.
So als idee. Je Nachdem wie Stabil die Verbindung zum WR ist.

Meinen schalte ich "Sonnenuntergang , Versatz 18 Minuten " aus. (Gibts als Trigger "Sonnenaufgang")

[paul53]

@dreistein sagte: Falsche Zeitzone vieleicht ?

Astrotrigger sind unabhängig von der Zeitzone. Man sollte allerdings auch diese Trigger verwenden.