mqtt2.template: Contributing

[hapege]

Hallo,
nachdem kein Shelly Template so richtig für den Shelly 1 Mini G3 funktioniert habe ich mal eins zusammengestellt (anbei als Du darfst diesen Dateianhang nicht ansehen. .template). Es enthält mqttt (simple) und rpc.
Hoffe es taugt so

[rico5588]

Hallo zusammen,

hier mein Template für die Shelly Colorbulb Gen3. (Multicolor Bulb E27 Gen3)

Schönes Wochenende.

[rico5588]

Hallo Zusammen,

hier ein Template für den Shelly Plug M Gen3
Ich nutze ein kleines Script welches mir die IP und den Status Online (true) ebenfalls in ein Reading schreibt.
Damit kann ich den readingswatcher nutzen...

Code Auswählen Erweitern

// Universal Shelly Status & IP Script
const deviceId = Shelly.getDeviceInfo().id;
const onlineTopic = deviceId + "/online";
const ipTopic = deviceId + "/ip";
const intervalMs = 300000; // 5 Minuten (300.000 ms)
const qos = 1;
const retain = true;
let timer = null;

// IP-Adresse effizient ohne doppelte Aufrufe ermitteln
function getIPAddress(callback) {
  Shelly.call("Eth.GetStatus", {}, function(ethResult) {
    if (ethResult && ethResult.ip && ethResult.ip !== "0.0.0.0") {
      callback(ethResult.ip);
    } else {
      // Wenn Ethernet fehlschlägt oder 0.0.0.0 ist -> WLAN versuchen
      Shelly.call("Wifi.GetStatus", {}, function(wifiResult) {
        if (wifiResult && wifiResult.sta_ip && wifiResult.sta_ip !== "0.0.0.0") {
          callback(wifiResult.sta_ip);
        } else {
          callback("n/a");
        }
      });
    }
  });
}

// IP & Status in einem einzigen Durchlauf verarbeiten
function updateNetworkStatus() {
  getIPAddress(function(ip) {
    const isOnline = (ip !== "n/a");
    try {
      MQTT.publish(onlineTopic, isOnline ? "true" : "false", qos, retain);
      MQTT.publish(ipTopic, ip, qos, retain);
      print("Network Update -> IP:", ip, "| Status:", isOnline ? "ONLINE" : "OFFLINE");
    } catch (e) {
      print("MQTT Fehler:", e);
    }
  });
}

// Timer initialisieren
function startTimer() {
  if (timer) Timer.clear(timer);
  updateNetworkStatus();
  timer = Timer.set(intervalMs, true, updateNetworkStatus);
}

// Zusammengefasster Status-Handler (verhindert doppelte Aufrufe)
Shelly.addStatusHandler(function(status) {
  // Netzwerk-Events
  if (status.component === "eth" || status.component === "wifi") {
    print("Netzwerkänderung erkannt:", status.component);
    updateNetworkStatus();
  }
 
  // MQTT-Events
  if (status.component === "mqtt" && status.delta) {
    if (status.delta.connected === true) {
      print("MQTT verbunden -> Starte Intervall");
      startTimer();
    } else if (status.delta.connected === false) {
      print("MQTT getrennt");
      if (timer) Timer.clear(timer);
    }
  }
});

// Shutdown-Handler
Shelly.addEventHandler(function(event) {
  if (event === "SHUTDOWN") {
    MQTT.publish(onlineTopic, "false", qos, retain);
  }
});

// Initialisierung
print("=== Universal Shelly Network Script gestartet ===");
startTimer();
Gruß Rico

[dadoc]

Generelle Anmerkungen zur attrTemplate-Funktion bitte hier posten.

Da kann man leider nicht posten... ggfalls bitte verschieben.

Was ich posten wollte: bei Geräten mit vielen verfügbaren attrTemplate-Einträgen wird die Auswahl über das Dropdown für mich zunehmend unübersichtlich und die Suche langwierig. Ich habe deshalb für mich AttrTemplate.pm lokal um eine Suchfunktion erweitert.

Funktionsweise

* Sobald im Aktionsmenü eines Geräts attrTemplate ausgewählt wird, erscheint ein Suchfeld.
* Die Suche berücksichtigt sowohl den Templatenamen als auch die Beschreibung.
* Die Treffer werden dynamisch als anklickbare Liste angezeigt.
* Durch Anklicken eines Treffers wird das entsprechende Template in der regulären Dropdown-Auswahl ausgewählt.
* Die Suche verwendet die von FHEM für das jeweilige Gerät bereitgestellte Template-Liste. Die bestehende Filterung nach dem jeweiligen Gerät bleibt damit erhalten.

Die Umsetzung ergänzt den vorhandenen JavaScript-Code in AttrTemplate.pm. Es ist keine zusätzliche Installation erforderlich. Nach dem Austausch der Moduldatei muss FHEM neu gestartet werden, damit der geänderte JavaScript-Code neu eingebunden wird.

Ich hänge die geänderte AttrTemplate.pm an. Die Änderung ist lokal getestet; Suche nach Namen und Beschreibung sowie die Auswahl der Treffer funktionieren bei mir, aber alles natürlich ohne Gewähr...

Viele Grüße
Martin

[Beta-User]

Was ich posten wollte: bei Geräten mit vielen verfügbaren attrTemplate-Einträgen wird die Auswahl über das Dropdown für mich zunehmend unübersichtlich und die Suche langwierig. Ich habe deshalb für mich AttrTemplate.pm lokal um eine Suchfunktion erweitert.

@Rudi: Hab' mir kurz von der funktionalen Seite angeschaut und finde das eine nette Idee. Vielleicht magst du es dir auch mal ansehen?

Ansonsten:
Sorry, dass ich erst jetzt dazu komme, mir das eine oder andere mal näher anzusehen.

Der Reihe nach:
Den Lichtsensor habe ich wie vorgeschlagen eingecheckt.

Hoffe es taugt so

Alles rund um den Kommentar

Code Auswählen Erweitern

# store on/off state in stateOnOff, not state, since state changes with every setList commanderschließt sich mir nicht so recht. Warum ist das nicht mit

Code Auswählen Erweitern

attr DEVICE setStateList on off togglezu lösen?

Und warum eine zu den sonstigen Gepflogenheiten abweichende source? (Wg. der "Beerdigung" der Rückmeldung)

Die "getxy" wären evtl. in einer getList besser aufgehoben?

(Mist, muss leider wieder zu früh weg, demnächst mehr, auch zum Rest.)

[Beta-User]

So, noch ein paar weitere Anmerkungen, v.a. zu shelly1minig3.template:
- Allgemein habe ich Vorbehalte gegen userReadings, v.a., wenn es darum geht, nachträglich etwas gerade zu biegen, das man auch vorher hätte korrigieren können. Leider wird der Code dadurch lang und unleserlich, wenn man solche Korrekturen in readingList macht. Hier kommt dazu, dass der userReadings-Eintrag ohne trigger daherkommt.
- Das per stateFormat zu lösen (wie die anderen beiden Vorschläge), ist m.E. auch keine wirklich zielführende Lösung des Problems. Dazu kommen ein paar andere Kleinigkeiten (wie die CID (?!?) in der readingList, die erst noch zu diskutieren wären...
- Für Shelly-(rpc-)MQTT gibt es zwischenzeitlich ein Modul, das die in dem o.g. template ebenfalls enthaltenen Anfragen dazu verwendet, das Gerät gleich automatisch zu konfigurieren. An sich eine tolle Idee, leider sind die Ergebnisse nicht immer "fhemish" in dem Sinn, dass der Hauptkanal direkt per "set <device> on" geschaltet werden kann. Modulvorstellung wäre hier zu finden: MQTT2_Discovery - nativer HA/Tasmota discovery Support 

Zusammengefasst: Mir kommt es so vor, als seien viele Aspekte, die in den bisherigen attrTemplate immer und immer wieder diskutiert worden sind, nicht allgemein angekommen, und ich kaue seit geraumer Zeit darauf herum, wie man das eine oder andere besser machen kann. Denn gerade für die "großen Gerätefamilien" Tasmota, Shelly-rpc und zigbee2mqtt (letzteres ist meine eigentliche Baustelle) wäre es sehr viel effizienter, wenn man die "üblichen Transformationen" zentraler erledigen würde, als das jedes Mal wieder gleich in die readingList reinzuknödeln und jedem Interessierten dann wieder (häufig erfolglos...) zu erläutern, warum denn nun gerade diese Variante "gut" ist. 

Nun kam jüngst martinp876 mit einigen sehr kritischen Fragen daher, die in Teilen auch zu meinen Gedanken gepaßt haben MQTT best current practice. Im Rahmen der damit ausgelösten Diskussion hat Rudi ein paar Optionen bereitgestellt, mit denen man jetzt in der Tat z.B. diese "familien-üblichen Tranformationen" zentral erledigen lassen könnte. Jetzt hoffe ich nur, irgendwann die Zeit zu finden, das von TomLee dankenswerterweise bereitgestellte "Gerippe" (https://forum.fhem.de/index.php?msg=1369863, indirekt via RHASSPY auf Basis von MQTT_GENERIC_BRIDGE) mit etwas Fleisch versehen zu können.

Unterstützung ist gerne willkommen.