Readingsproxy: Shelly Pro Dual Cover+pct > "not enough parameter" bei set aus SetFN

Begonnen von piet_pit, 09 Februar 2026, 21:31:26

Vorheriges Thema - Nächstes Thema

piet_pit

Hallo zusammen,

ich versuche einen Shelly Pro Dual Cover (FW 1.7.1) in FHEM so einzubinden, dass beide Kanäle jeweils als eigenes Rollo (für AutoShuttersControl / ASC) nutzbar sind.

Das Shelly-Device selbst funktioniert korrekt:

set Dachgeschoss_Rollo open 0
set Dachgeschoss_Rollo closed 0
set Dachgeschoss_Rollo stop 0
set Dachgeschoss_Rollo pct 50 0

→ alle Befehle funktionieren direkt auf dem Parent-Device.

Ich möchte nun jeden Kanal ein eigenes Device (z. B. per readingsProxy) definieren, das:
    •    open / closed / stop / pct
    •    und von ASC genutzt werden kann.

Mein Ansatz mit readingsProxy

define Dachgeschoss_Rollo_Hinten readingsProxy Dachgeschoss_Rollo:pct_0

attr Dachgeschoss_Rollo_Hinten setList \
open:noArg closed:noArg stop:noArg pos:slider,0,1,100

attr Dachgeschoss_Rollo_Hinten setFn {
  my ($hash, $name, $cmd, @args) = @_;

  return "Unknown argument $cmd"
    unless $cmd =~ /^(open|closed|stop|pos)$/;

  my ($parent) = split(":", $hash->{DEF});

  if ($cmd eq "pos") {
    fhem("set $parent pct $args[0] 0");
  }
  elsif ($cmd eq "open") {
    fhem("set $parent open 0");
  }
  elsif ($cmd eq "closed") {
    fhem("set $parent closed 0");
  }
  else {
    fhem("set $parent stop 0");
  }
}

Der setFn wird ausgeführt, aber der Shelly-Befehl schlägt fehl:

set Dachgeschoss_Rollo pct 50 0 : not enough parameter
Obwohl derselbe Befehl direkt auf dem Shelly-Device funktioniert.

Zusätzlich:
    •    disableSetReading wird vom readingsProxy nicht unterstützt
    •    pct als Set-Befehl kollidiert mit dem readingsProxy
    •    auch mit alternativem Set-Befehl (pos) bleibt der Fehler bestehen

Meine Fragen
1.Ist es grundsätzlich nicht möglich, pct eines Shelly Pro Dual Cover über readingsProxy + setFn zuverlässig zu setzen?
2.Gibt es einen Weg, beide Kanäle eines Pro Dual Cover ASC-fähig abzubilden?
   

Vielen Dank für Hinweise
Pit
FHEM Latest Revision: 29615
Raspberry Pi 3, Rasbian-Stretch
FRITZ!Box 7690
HM-Mod-RPI-PCB, JeeLink
CUNO 1.47

Beta-User

Vielleicht mal hier anhängen: https://forum.fhem.de/index.php?topic=142739.0

Mein Verständnis von setFn wäre, dass da ein String zurück gegeben werden sollte, den das Modul dann an das Stamm-Device weiterreicht.

Diese fhem()-Anweisungen kommen jedenfalls mir "falsch" vor
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