@mcu Der Adapter ist toll. Mir gehts allerdings hauptsächlich um die Visualisierung und auch um andere zeitgesteuerte Geräte.
Ein vollwertiges Timermodul wäre natürlich schick, aber am Ende würde mir eine Visualisierung reichen, die dann ein JSON Objekt erzeugt, z.B.

{
	"timers": [
		{
			"starttime": 1663711200000,
			"days": [
				1,
				1,
				1,
				1,
				1,
				1,
				1
			],
			"device": "bla",
			"value": 15,
			"active": true
		},
		{
			"starttime": 1663711200000,
			"days": [
				1,
				1,
				0,
				0,
				0,
				0,
				0
			],
			"device": "blubb",
			"event": "ON",
			"active": true
		}
	]
}

Das kann man dann flexibel in einer Logik weiter verarbeiten

Ich würde gerne verschiedene Geräte mit verschiedenen Schaltzeitpunkten steuern. Speziell die Heizung, aber auch andere Geräte

Also in der Art:

Gerät 1:
- 00:00 - 04:00 Wert 20
- 04:00 - 10:00 Wert 19 
- ...

Gerät 2:
- 00:00 - 17:00 Wert 18
- 17:00 - 00:00 Wert 19

Gerät 3:
- 17:00 - 00:00 Wert "ON"
- 00:00 - 17:00 Wert "OFF"

In der UI sollten Schaltzeitpunkte flexibel editierbar sein, d.h. ändern, löschen, hinzufügen. Im Idealfall sogar verschiedene Profile anlegbar. Gibt es eine solche Möglichkeit?

@mickym said in Jarvis - Schalter via MQTT:

Ich nutze ja auch das NodeRed Dashboard - finde aber Jarvis durchaus interessant, da man ebenfalls schnell zu Ergebnissen kommt, aber mit dem fixen Design so eine Zwischenlösung zwischen vis und dem responsive Design des NodeRed Dashboards darstellt..

Absolut an diesem Punkt bin ich auch gerade. 99% meiner Logik ist in NR untergebracht und dort auch mit den (etwas deprimierenden) Dashboard-Funktionen umgesezt.
Wegen einem Gerätedefekt hab ich aber die Struktur jetzt an vielen Stellen geändert

• Homematic von dediziertem Pi auf Proxmox
• ioBroker, Grafana und Influx auch auf Proxmox
• NR vorher via Redmatic in homematic integriert, jetzt komplett in iob NR umgezogen. Hier wäre mir aber eine dedizierte Installation die mit iob sprechen kann immer noch am liebsten (bin aber zu faul alles über MQTT zu machen). Komme immer mehr von den zu hoch verdichteten Lösungen weg, da ich mir jetzt schon mehrfach damit die Finger verbrannt habe. Deswegen bleibt es auch bei zigbee2mqtt und kein Umzug in den iob Adapter
• Aus Interesse mal alles noch in eine homeassistant Installation gepackt. Auch sehr schick, aber bei Konfigurationen / Logiken über YAML und Jinja bekomme ich Herzrhythmusstörungen.

Wie @mickym beschrieben hat:

• Speziell bei zigbee2mqtt, aber generell auch bei MQTT ist oft den Kommando-Kanal ein anderer als der Status-Kanal
• Zustände sollen nicht "optimistisch" gesetzt werden, also setzen und hoffen, dass es geklappt hat
• Die Anzeige soll sich nach dem tatsächlichen Resultat richten
• Jarvis kennt momentan keine Unterscheidung zwischen Kommando und Status-Kanal

--> Damit bleibt nur die beiden Kanäle über ein Alias zu koppeln:

Vielen Dank an alle für den Input.

@mickym Deine Lösung klappt. Hatt vor dem JS script auch schon mit den Alises experimentiert, aber übersehen, das JSON richtig zu konvertieren. Vielen Dank.

@mickym said in Jarvis - Schalter via MQTT:

Im Prinzip wirst Du beim zigbee2mqtt um einen Alias nicht drum rumkommen, da du ja unterschiedliche Werte zum Setzen und Lesen brauchst.

Ja, ist es schade, dass Jarvis hier keine flexible interne Lösung kennt, eine entsprechenden Payload zu generieren und zwischen CMD und STATUS Kanälen zu unterscheiden.
Ich habs in Jarvis auch mit {"setOn":"{\"state\": \"ON\"}","setOff":"{\"state\": \"OFF\"}"} versucht, aber das funktioniert genau einmal und dann hängt der Switch.

Aber trotzdem ist Jarvis eine tolle Sache. Vorallem für so Vis-Deppen wie mich. Brauch das nur um den WAF zu gewährleisten.

Ich würde gerne in Jarvis einen Schalter einrichten, der über MQTT geschaltet wird, allerdings ist der Schaltpunkt ein JSON string:

• An: {"STATE": "ON"}
• Aus: {"STATE": "OFF"}

Der einzige Weg, wie ich es hinbekommen habe, ist über einen "Hilfs-DP" und ein Java-Script, welches den Wert entsprechend hinbiegt:

on({id: '0_userdata.0.test', change: 'any', ack: false}, function (obj) {
    if (obj.state.val) {
        setState("mqtt.0.zigbee2mqtt.RelayLightHallEG.set", "{\"state\": \"ON\"}");
    } else {
        setState("mqtt.0.zigbee2mqtt.RelayLightHallEG.set", "{\"state\": \"OFF\"}");
    }
});

Das kann aber doch nicht die Lösung sein, oder?

@mickym Stimmt, auch ne Möglichkeit. Sogar die flexiblere.

@mickym Das ist wohl ein bisschen abhängig davon, was der Adapter erwartet. Die homematic rssiInfo Methode erwartet ein Objekt.

@mickym Sehr elegante Lösung

Ich habe Beispiele wo auch message leer sein kann. Dann rennt das Script auf Fehler. Habs mal so gelöst (Zeile 43):

/**
* Zweck:      Setzt für einen NodeRed Flow - SendTo Kommandos an verschiedene Adapter ab
* Datum:      17.08.2022
* Autor:      @mickym
*/

// In die Variable exchangeWithNodeRed den Pfad des Datenpunktes auswählen, der als Trigger verwendet wird

/*********************************************************************************************************
 *  In den Datenpunkt muss ein Objekt von Node Red mit folgenden Eigenschaften übergeben werden:
 *  {
    "adapter": <Adapterinstanz oder Adapter z.Bsp mqtt.0, sql.0>,
    "command": <Kommando - hängt vom jeweilige Adapter ab - bei sql zum Beispiel query, bei manchen Adaptern auch nicht erforderlich>,
    "message": <Nachricht, die an den Adapter geschickt wird>,
    "result": <optional: Pfad zum Datenpunkt, wo das Ergebnis als String abgespeichert wird, ansonsten wird der Trigger als Ausgabepunkt verwendet>
    }
 *
 *
*/

const exchangeWithNodeRed = '0_userdata.0.NodeRed.sendTo';

on({id: exchangeWithNodeRed, change: 'any', ack: false}, function(obj) {
  console.log(obj.state.val);
  const val = JSON.parse(obj.state.val);
  let returnResult;
  //console.log('adapter: ' + val.adapter);
  //console.log('command: ' + val.command);
  //console.log('message: ' + val.message);
  //console.log('result: ' + val.result);

  if (!val.result) returnResult = exchangeWithNodeRed;
  else returnResult = val.result;
  if (!val.command){
    //console.log('no command');
    sendTo(val.adapter, val.message, function(result) {
      if (result.error) setState(returnResult, result.error, true); 
      else setState(returnResult, JSON.stringify(result.result), true);
    });
  } else {
    //console.log('command: ' + val.command);
    sendTo(val.adapter, val.command, val.message? val.message : {}, function(result) {
      if (result.error) setState(returnResult, result.error, true);
      else setState(returnResult, JSON.stringify(result.result), true);
    });
  }
});

@mickym said in ioBroker Script Funktionen in NR:

Aber es zeigt immerhin, wie integrativ der iobroker ist, um so systemübergreifend zum Ergebnis zu kommen.

ioB ist klasse, da gibt es keine Frage. Harte Kanten und Ecken gibt es immer, egal bei welchem Produkt. Wichtig ist, dass es eine Lösung gibt. Schöne Lösungen natürlich bevorzugt
Vielen Dank für Deine Hilfe nochmal @mickym

Quasi ein hässlicher work-around, den man auch für andere Sachen anwenden könnte:

on("0_userdata.0.randTrigger", function (obj) {
    sendTo('hm-rpc.0', 'rssiInfo', {}, res => {
    setState("0_userdata.0.hmRSSI", res);
    });
});

Schön ist das aber nicht