Status negiert übertragen

[Homoran]

@zimbl sagte in Status negiert übertragen:

irgendwie komme ich nun hier bei den ganzen etwas durcheinander.

wäre nach über 5 Jahren Ruhe im Thread nicht ein neuer angesagt?

[Zimbl]

@homoran

ja sorry, wollte nicht unnötig wieder etwas neues beginne. Da das Thema ja ähnlich bzw. fast das gleiche ist.

aber bei dem nächsten mal werde ich mich dran halten, es wird ja immer gesagt. Ob man die SuFu auch benutzt.

Aber werde mich beim nächsten mal dran halten. Versprochen...

[bahnuhr]

@zimbl sagte in Status negiert übertragen:

on(idSrc, function(dp) { // Triggern bei Änderung setState(idDst, !dp.state.val); });

Ich habs nicht richtig verstanden was du willst.
Aber baue doch einfach if Abfragen rein.

z.B. so:

var idSrc = "tuya.0.658013063c6105ee34fe.36";
var idDst = "rpi2.0.gpio.11.state";
  
on(idSrc, function(dp) {  // Triggern bei Änderung
   if (dp.state.val == 0) {
      setState(idDst, false);
   } else {
      setState(idDst, true);
   }
});

Wie gesagt, habe deine Bedingungen nicht ganz verstanden.
Aber vielleicht ist dies ja ne Grundlage für dich.

[paul53]

@zimbl sagte:

Typ Number Open 0 = Typ Bool FALSE
Typ Number Close 1 = Typ Bool TRUE

setState(idDst, !!dp.state.val);

@zimbl sagte in Status negiert übertragen:

nur in umgekehrter Reihenfolge....

Oder ist Quelle vom Typ "boolean" und Ziel vom Typ "number"? Dann

setState(idDst, dp.state.val ? 1 : 0);

[Zimbl]

@bahnuhr

das ist schon sehr gut.
Es scheint auch zu funktionieren, ich sehe das an anderer Stelle, das er einen Wertänderung mitbekommen hat. Aber wenn ich im RPI2 unter GPIO schaue, wird der Wert nicht geändert.
Obwohl er dazu einen Befehl bekommt.

Woran könnte das noch liegen ?

[Zimbl]

@paul53

genau rumgedreht.
Das andere ist vom Typ Number und das Ziel ist ein GPIO...also vom Typ Bool.

[Codierknecht]

@tobo sagte in Status negiert übertragen:

Ich habe noch eine prinzipielle Verständnisfrage zur Abarbeitung von Scripts. Ich erstelle ein Script, speichere es und drücke auf Ablauf. Ich denke mal, dann wird das Script einmal abgearbeitet. Wie gehts dann weiter?

Nur für den Fall, dass die Funktionsweise noch nicht so klar wurde:

ioBroker arbeitet Scripte prinzipiell nicht zyklisch ab, wie man das bei prozeduraler Programmierung gewohnt ist.
Mit dem on() wird ein Trigger deklariert. In dem Sinne, dass hier eine Ereignisbehandlung registriert wird. Der Trigger "abonniert" also quasi Nachrichten, die bei Änderungen an einem Objekt gesendet werden.

Hier mal @paul53 's Vorschlag etwas kommentiert:

// In den Variablen werden die Namen der Datenpunkte gehalten
// Könnte man durchaus auch als const deklarieren
// Diese beiden Zeilen werden 1x beim Start des Scripts ausgeführt
var idSrc = "hm-rpc.0.OEQ0119091.1.STATE";
var idDst = "s7.0.Outputs.0.Status_Haustür";
 
// hier wird ein Trigger "registriert"
// er reagiert auf Änderungen am DP "idScr" und ruft dann die hier hinterlegte ANONYME Funktion auf
// Diese Funktion setzt den DP "idDest" auf den gewünschten Wert (Wert des triggernden "dp" negiert)
on(idSrc, function(dp) {  // Triggern bei Änderung
   setState(idDst, !dp.state.val);
});
 
// auch die folgende Zeile wird nur einmal beim Start des Scripts ausgeführt und setzt den Zieldatenpunkt initial auf einen definierten Wert (NICHT idSrc)
setState(idDst, !getState(idSrc).val);

Man muss sich grundsätzlich davon verabschieden, dass Programme (Scripte) Zeile für Zeile abgearbeitet werden.
Was sich nicht innerhalb eines Triggers oder Zeitplans befindet, wird nur 1x beim Start des Script ausgeführt.
Alles andere reagiert entweder auf Ereignisse (Trigger) oder wird zyklisch bzw. zu bestimmten Zeiten (Zeitplan) ausgeführt.
Das heißt dann aber auch: Ein Script wird gespeichert und dann auch gestartet, Es wird in der Regel nicht gestoppt! Sonst könnte die Ereignisbehandlung ja nicht mehr reagieren.

Insbesondere wenn man von SPS kommt, sollte man sich von zyklischen Dingen verabschieden.
In ioBroker prüft man nicht zyklisch bestimmte Zustände.
Man registriert Trigger, die genau dann feuern wenn sich ein Zustand ändert.
Wozu sollte man auch z.B. alle 10 Sekunden einen Zustand überwachen, der sich möglicherweise nur alle paar Tage ändert?

Signale müssen dazu auch nicht eine bestimmte Zeit lang anliegen. Ändert sich ein Wert, wird das erkannt und der Trigger feuert. Dazu reichen Mikrosekunden.
Wenn ein Signal eine bestimmte Zeit lang anliegen muss, bevor eine Reaktion erfolgen soll, muss man da gesondert reagieren. Das kommt dann später.

Auch von mir der Tipp: Fang erstmal mit Blockly an und schau Dir dann an, was da an JS-Code generiert wird.

[Zimbl]

@codierknecht

Ja du hast da völlig recht, im Blockly sollte man erstmal beginnen.

Hast du auch alles wirklich gut erklärt....vielen Dank für deine Mühe.

Ich habe ja nun das Skript angenommen, es funktioniert ja auch.

Könnte es jetzt wirklich sein, das dass Signal zu kurz nur ansteht ?
Weil ich sehe ja in einem anderem Skript das die Funktion ausgeführt wird, da die Änderung dort registriert wird. Aber wenn ich in den Objekten schaue, ist der Wechsel von FALSE zu TRUE oder rumgedreht nicht ausgeführt.

Muss der Befehl dann länger anstehen ? wie kann man das machen ? oder hast du für mich generell eine vereinfachte Blockly ausführung, wo ich vielleicht dann noch ein paar Dinge hinzufügen kann...zu einem späteren Zeitpunkt...

[Codierknecht]

@zimbl
Das wäre so ziemlich das einfachste Blockly für diesen Zweck.

Die passenden Objekte musst Du allerdings noch selbst auswählen.

Spoiler

<xml xmlns="https://developers.google.com/blockly/xml">
 <block type="on" id="9U[w!yJt78v$!lb!TS!/" x="-212" y="-388">
   <field name="OID">Object ID</field>
   <field name="CONDITION">ne</field>
   <field name="ACK_CONDITION"></field>
   <statement name="STATEMENT">
     <block type="debug" id="v?A*66$aiHG;Z4N59J;$">
       <field name="Severity">log</field>
       <value name="TEXT">
         <shadow type="text" id="wZRVQ6SNaRdcOWw}t)OC">
           <field name="TEXT">test</field>
         </shadow>
         <block type="on_source" id="b6P{{7~HJfK/|AaKEg-L">
           <field name="ATTR">state.val</field>
         </block>
       </value>
       <next>
         <block type="control" id="OK0XhMdTXH04zJwz(~,o">
           <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation>
           <field name="OID">Object ID</field>
           <field name="WITH_DELAY">FALSE</field>
           <value name="VALUE">
             <block type="logic_negate" id="^;vQx/ZTOH6`r$LPLf$G">
               <value name="BOOL">
                 <block type="on_source" id="Usf86VZt5:lU1dZJUba(">
                   <field name="ATTR">state.val</field>
                 </block>
               </value>
             </block>
           </value>
         </block>
       </next>
     </block>
   </statement>
 </block>
</xml>

[Homoran]

@zimbl sagte in Status negiert übertragen:

Muss der Befehl dann länger anstehen ?

was meinst du damit?
Sobald die Änderung des DP in ioBroker ankommt, würde ein darauf triggerndes Skript auch arbeiten.

@zimbl sagte in Status negiert übertragen:

Ich habe ja nun das Skript angenommen, es funktioniert ja auch.

welches Skript?

und wo ist das Problem wenn es funktioniert?

[Zimbl]

@homoran

mein Problem ist derzeit egal welche Änderung ansteht.
Beim GPIO..state...switch findet keine Änderung statt....

Der steht immer auf dem gleichen Wert....ich kann ihn
von Hand aus umschalten...sowohl über APP als auch direkt
unter Objekte...aber das Skript scheint nichts zu bewirken...

[Homoran]

@zimbl sagte in Status negiert übertragen:

Beim GPIO..state...switch findet keine Änderung statt....

heisst genau was?
https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1

@zimbl sagte in Status negiert übertragen:

das Skript scheint nichts zu bewirken...

nochmal:

@homoran sagte in Status negiert übertragen:

welches Skript?

@zimbl sagte in Status negiert übertragen:

ich kann ihn
von Hand aus umschalten...direkt unter Objekte.

wie genau?

alles zeigen!
so istcdas ein großes Rätselraten.