mqtt2.template: Contributing

Begonnen von Beta-User, 15 Dezember 2018, 11:45:40

Vorheriges Thema - Nächstes Thema

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 :-)
Developer: 70_ESCVP21net.pm, 70_SVDRP.pm
Mitglied FHEM e.V.

rico5588

#256
Hallo zusammen,

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

Schönes Wochenende.
Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS423+
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

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

// 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

Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS423+
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

dadoc

#258
ZitatGenerelle 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
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Beta-User

Zitat von: dadoc am 10 Oktober 2026, 19:20:26Was 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.

Zitat von: hapege am 02 Juli 2026, 21:25:47Hoffe es taugt so :-)
Alles rund um den Kommentar
# 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
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.)
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors