NEWS
Adapter ein/ausschalten?
-
@humidor sagte: so ?
Ja, besser:
const obj = getObject("system.adapter.fronius.0"); schedule("0 22 * * *", async function () { obj.common.enabled = false; setObject("system.adapter.fronius.0", obj); }); schedule("0 6 * * *", async function () { obj.common.enabled = true; setObject("system.adapter.fronius.0", obj); });
-
@paul53 das auch OK ?
// Fronius const objfronius = getObject("system.adapter.fronius.0"); schedule("0 22 * * *", async function () { objfronius.common.enabled = false; setObject("system.adapter.fronius.0", objfronius); }); schedule("0 6 * * *", async function () { objfronius.common.enabled = true; setObject("system.adapter.fronius.0", objfronius); }); // Modbus const objmodbus = getObject("system.adapter.modbus.0"); schedule("0 22 * * *", async function () { objmodbus.common.enabled = false; setObject("system.adapter.modbus.0", objmodbus); }); schedule("0 6 * * *", async function () { objmodbus.common.enabled = true; setObject("system.adapter.modbus.0", objmodbus); });
-
@humidor sagte: das auch OK ?
Weshalb jeweils zwei Trigger zur gleichen Zeit?
const objfronius = getObject("system.adapter.fronius.0"); // Fronius const objmodbus = getObject("system.adapter.modbus.0"); // Modbus schedule("0 22 * * *", function () { objfronius.common.enabled = false; setObject("system.adapter.fronius.0", objfronius); objmodbus.common.enabled = false; setObject("system.adapter.modbus.0", objmodbus); }); schedule("0 6 * * *", function () { objfronius.common.enabled = true; setObject("system.adapter.fronius.0", objfronius); objmodbus.common.enabled = true; setObject("system.adapter.modbus.0", objmodbus); });
-
Moin,
Die enstsprechenden Datenpunkte findes du nur im "Expertenmodus" unter <System>.
Was mir fehlt ist der Status eines Adapters. Wo finde ich den ?
Growatt und Renault spinnen ja im Moment total und müllen das Log zu. -
@humidor
Ich würde weniger Scheduler anlegen und dafür alles im selben Callback machen, e.g.:const adapterInstances = ["system.adapter.fronius.0", "system.adapter.modbus.0"]; schedule("0 22 * * *", async function () { for await (const instance of adapterInstances) { const obj = await getObjectAsync(instance); obj.common.enabled = false; await setObjectAsync(instance, obj); } );
Und das gleiche dann fürs Wiedereinschalten.
-
Hier ein Blockly:
<xml xmlns="https://developers.google.com/blockly/xml"> <block type="on_ext" id="(Vc.;+u)EemPg:pnn4@:" x="13" y="-212"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="1"></mutation> <field name="CONDITION">false</field> <field name="ACK_CONDITION"></field> <value name="OID0"> <shadow type="field_oid" id="?ECw1KyYt(zP$11Ax(q8"> <field name="oid">radar2.0.Server_01._here</field> </shadow> </value> <statement name="STATEMENT"> <block type="debug" id="I;s5fP(*iC~FWey%#~D1"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="Gok#O-Jua~b]xNQBXpc9"> <field name="TEXT">Server_01 offline</field> </shadow> </value> <next> <block type="timeouts_wait" id="6JmXYyG]?pfPW-~*|Q3n"> <field name="DELAY">1</field> <field name="UNIT">sec</field> <next> <block type="exec" id="3MX+6fHPC)!6L1DKW4#R"> <mutation xmlns="http://www.w3.org/1999/xhtml" with_statement="false"></mutation> <field name="WITH_STATEMENT">FALSE</field> <field name="LOG"></field> <value name="COMMAND"> <shadow type="text" id="$`qC7@9HvfRLMd[Bnt0="> <field name="TEXT">iobroker stop snmp.0</field> </shadow> </value> <next> <block type="debug" id="pKsh;?SH02gPWVNqcf0s"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="e5HZOS4M-5VIO*L-(|}!"> <field name="TEXT">Server_01 abgeschaltet >> snmp-Adapter wird beendet</field> </shadow> </value> </block> </next> </block> </next> </block> </next> </block> </statement> </block> <block type="on_ext" id="$FK68Yj.F%+F0.q3MNI8" x="13" y="188"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="1"></mutation> <field name="CONDITION">true</field> <field name="ACK_CONDITION"></field> <value name="OID0"> <shadow type="field_oid" id="K/K{6k_p_EacL+#jjUIu"> <field name="oid">radar2.0.Server_01._here</field> </shadow> </value> <statement name="STATEMENT"> <block type="debug" id="$#{~3Xs*v9?4`x,et`bg"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="c`Z/Xwl]:UsepLk.EM5o"> <field name="TEXT">Server_01 online</field> </shadow> </value> <next> <block type="timeouts_wait" id="d}E~{KwEpj%tnF=|+w)E"> <field name="DELAY">3</field> <field name="UNIT">min</field> <next> <block type="exec" id="2`T7i)qslUPNdKzUoz%s"> <mutation xmlns="http://www.w3.org/1999/xhtml" with_statement="false"></mutation> <field name="WITH_STATEMENT">FALSE</field> <field name="LOG"></field> <value name="COMMAND"> <shadow type="text" id=")6Qb(%33FJ1(Uze5mmW}"> <field name="TEXT">iobroker start snmp.0</field> </shadow> </value> <next> <block type="debug" id=":0pz(wd#jO}3j085k/*2"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="S@0OEqdy.3@nAv=Ta:Qd"> <field name="TEXT">Server_01 eingeschaltet >> snmp-Adapter wird gestartet</field> </shadow> </value> </block> </next> </block> </next> </block> </next> </block> </statement> </block> </xml>
-
@gregors ich sehe aber die notwendige Variable nicht
-
@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.
-
@gregors ah ja, hab nicht genau geschaut, danke.
-
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}});
-
Könnt ihr die Info mit dem Java Script zusammenführen?
-
@bertman2000 sagte: mach es lieber so
Diese Version verwendet intern getObject(id) und setObject(id), bringt also keinen Vorteil.
-
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.
-
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.
-
@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.
-
@humidor sagte: sehe den Alive-Status nicht im Objektbaum
Unter "system.adapter.fronius.0".
-
@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.
-
Um 06:25 läuft deine PV schon ?
Verrückt. -
@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. -
@humidor sagte in Adapter ein/ausschalten?:
Error: connect EHOSTUNREACH 192.168.0.96:80
Die Kiste (bzw. der Port 80) ist nicht erreichbar.