Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[paul53]

@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);
});

[Humidor]

@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);
});

[paul53]

@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);
});

[Ein ehemaliger Benutzer]

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.

Spoiler

<block xmlns="https://developers.google.com/blockly/xml" type="control" id="YieLf#,C9L$H*I,6%(Bp" x="-766" y="-472">
 <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation>
 <field name="OID">system.adapter.fronius.0.alive</field>
 <field name="WITH_DELAY">FALSE</field>
 <value name="VALUE">
   <block type="logic_boolean" id="ja6$#g+YPW?g,1=kxcK9">
     <field name="BOOL">TRUE</field>
   </block>
 </value>
</block>

[Ein ehemaliger Benutzer]

@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.

[GregorS]

@humidor

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 &gt;&gt; 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 &gt;&gt; snmp-Adapter wird gestartet</field>
                      </shadow>
                    </value>
                  </block>
                </next>
              </block>
            </next>
          </block>
        </next>
      </block>
    </statement>
  </block>
</xml>

[Humidor]

@gregors ich sehe aber die notwendige Variable nicht

[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.