[erledigt] Dummy MQTT-Device für SmartApplianceEnabler

Begonnen von bismosa, 23 Mai 2024, 13:33:29

Vorheriges Thema - Nächstes Thema

bismosa

Hallo!

Ich nutze einen Wechselrichter in Kombination mit einem SunnyHomeManager 2.0 von SMA.
Im Sunnyportal hat man die Möglichkeit weitere Geräte als Verbraucher hinzuzufügen.
Leider gibt es da nicht sehr viele kompatible Geräte. Um dennoch weitere Geräte hinzuzufügen habe ich das Projekt SmartApplianceEnabler
( https://github.com/camueller/SmartApplianceEnabler ) gefunden. Das sieht sehr vielversprechend aus. Bisher habe ich hier im Forum aber noch nichts darüber gefunden.

Ich habe bereits eine Zigbee-Steckdose damit eingebunden...und nun möchte ich in FHEM ein Gerät einrichten, das vom Portal genau so gesteuert wird.

Bei mir handelt es sich erstmal um meine Poolpumpe. Die wird von FHEM eingeschaltet (per GPIO). Schön ist es, wenn man dann auch einen Verbrauch übermittelt. Sonst geht das Portal davon aus, das der Strom die ganze Zeit verbraucht wird.
Also benötige ich ein Dummy-Device das so tut als wäre es eine solche Steckdose mit Energiemessung.

Ich habe jetzt mit einem dummy angefangen, bin aber nicht sicher, ob dies der richtige Weg ist. Immerhin muss ich wiederholt den Status vom Device übermitteln.
defmod mqtt2_dummy MQTT2_DEVICE
attr mqtt2_dummy devicetopic 0x0001
attr mqtt2_dummy setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
  off:noArg $DEVICETOPIC/set {"state":"OFF"}\
  toggle:noArg $DEVICETOPIC/set {"state":"TOGGLE"}\
  power $DEVICETOPIC/power {"power":"$EVTPART1"}
Wäre es denn besser, mit einem DOIF ein Konstrukt dafür aufzubauen? Da könnte ich dann evtl. mit einer MQTT Generic Bridge arbeiten?
Hat das vielleicht schon mal jemand gemacht?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Beta-User

Zitat von: bismosa am 23 Mai 2024, 13:33:29Wäre es denn besser, mit einem DOIF ein Konstrukt dafür aufzubauen? Da könnte ich dann evtl. mit einer MQTT Generic Bridge arbeiten?
Den Zusammenhang zwischen DOIF und MQTT_GENERIC_BRIDGE (MGB) verstehe ich nicht so ganz...

Der Reihe nach:
Falls ich es richtig verstanden habe, braucht der Dienst zum einen aktuelle Status-Werte, und zwar 1a) möglichst direkt zum Zeitpunkt des Messens/Schaltens, und 1b) regelmäßig (1xpro Minute ist empfohlene Mindestmenge). Dann sollte 2. das Device ggf. auch noch via MQTT schaltbar sein?

Die Punkte 1a und 2 würde ich in der Tat mit einer MGB erledigen, v.a. wegen der Schaltbarkeit von MQTT-Seite (sonst ginge auch ein einfaches notify (oder DOIF), das die Werte bei Änderung verschickt).

Was regelmäßige updates gem. 1b angeht, braucht es halt irgendeine timer-Funktion, die die betreffenden Werte sammelt und dann via MQTT versendet. Geht mit einem at, DOIF, ... oder (per periodicCmd) auch direkt in einem MQTT2_DEVICE. Ich würde das per at lösen (und jeden notwendigen Wert halt in einen publish-Befehl packen), aber das ist Geschmackssache...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

bismosa

Hallo!

Danke für die Antwort!
Ja, du hast das genau richtig verstanden. Ich muss periodisch den aktuellen Status publishen und es soll auch noch schaltbar sein (damit das Portal festlegen kann, wann das Gerät eingeschaltet werden kann)
Durch ein "dummy-Wert" für den Energieverbrauch, kann ich den tatsächlichen Verbrauch dann auch gut übermitteln und in die Statistiken des Portals aufnehmen.

Zitat von: Beta-User am 23 Mai 2024, 14:25:24Den Zusammenhang zwischen DOIF und MQTT_GENERIC_BRIDGE (MGB) verstehe ich nicht so ganz...
Wenn ich die MQTT_GENERIC_BRIDGE richtig verstanden habe, dann kann ich jedes Device um MQTT erweitern. Mit einem doif kann man sehr gut Timer erstellen, die dann das Senden des Status übernehmen.
Da ich mit dem Modul noch keine Erfahrungen habe, war ich mir nicht sicher, ob dies für mein Anwendungsfall das richtige ist. Wäre dann halt (außer die MGB) nur ein Device, das sich um "alles" kümmert.

Zitat von: Beta-User am 23 Mai 2024, 14:25:24oder (per periodicCmd) auch direkt in einem MQTT2_DEVICE
Das ist natürlich auch spannend. In meinem Fall würde das ja vermutlich ausreichen...allerdings könnte die Minute schon knapp werden. Dann sollte das auch alles mit einem MQTT2_Device machbar sein.

Ich werde das mal testen...

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

bismosa

Hallo!

Nur um das hier abzuschließen und für evtl. Mitleser:
Ich habe diesen Weg nun nicht weiter verfolgt. Durch den SmartApplianceEnabler (den ich hier nicht schlecht reden möchte) hatte ich so viel MQTT-Traffic das mein System in die Knie gegangen ist. Ich liege mit meiner Hardware doch schon an der Leistungsgrenze.
Bei der weiteren Recherche bin ich auf das Modul SolarForecast gekommen. Das ist für meine Zwecke wohl die bessere Wahl. Dann bin ich nicht auf Portal angewiesen und habe bessere Steuerungsmöglichkeiten.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...