Hallo zusammen,
ich habe ein paar HM-LC-Bl1PBU-FM, die ich nun in SmartVisu einbinden will. Den ersten habe ich jetzt mit {{ device.shutter('shutter4', 'Fenster', 'WZ.Rolladen.Fenster.move', 'WZ.Rolladen.Fenster.stop', 'WZ.Rolladen.Fenster.pos', '', '', '','0','100' ) }} angelegt und GAD
...move mit
- reading: state
- converter OnOff
- cmd set: state
verknüpft. Das funktioniert soweit.
Ich kriege aber nicht hin, daß der Stop-Button "set <device> stop" auslöst. Wenn ich im Stop-GAD
- reading: state
- converter: Direct
- cmd set: stop
einstelle, wird immer eine "1" drangehängt:
set HG_WZ_RL_Fenster stop 1 : stop requires no parameters
Mit dem Vorschlag in der DropDownList stop:noArgs kommt set HG_WZ_RL_Fenster stop:noArg 1 : Unknown argument stop:noArg, choose one of assignHmKey:noArg...
Wie muß ich denn den Stop Button richtig verdrahten?
Gruß Roland
Hallo,
ich stehe genau vor dem gleichen Problem. Hat niemand eine Idee?
Gruß
Andreas
Nehmt als Converter "Direct". Cmdset und Reading beides auf "state". Das geht bei mir. Ich schaue mir aber morgen mal mein Smartvisu-Widget an. Vielleicht habe ich da noch eine Änderung gemacht.
Gruß, Sascha
Hallo Sascha,
hast du das mit dem Stop Befehl bei dir geprüft?
Ich stehe auch vor dem gleichem Problem, beim drücken der StopTaste fährt der Rollo in die andere Richtung an die Endposition.
Auch die anderen Kombinationen im GAD Editor habe ich ausprobiert, kein Erfolg.
Gruß
Michael
Das Stop-Problem mit Homematic-Rollladenaktoren habe ich mit einem neuen Konverter "Dummy" gelöst, so wie es muecke36 hier https://forum.fhem.de/index.php/topic,33231.msg418747.html#msg418747 (https://forum.fhem.de/index.php/topic,33231.msg418747.html#msg418747) beschrieben hat.
Viele Grüße
Hallo Romoker,
danke für den Hinweis.
Habe die Funktion Dummy von muecke36 in die die 99_myUtils.pm eingefügt und jetzt?
Bei mir hat sich leider nichts geändert.
Steh da leider etwas auf dem Schlauch. :-\
Ist Dein GAD wie folgt definiert?
Device Rolloname
reading state
converter Dummy
cmd set stop
Viele Grüße
Edit:
Ein möglicher zweiter Grund ist mir noch eingefallen: Im FHEM fronthem WIKI https://wiki.fhem.de/wiki/Fronthem#eigene_Converter (https://wiki.fhem.de/wiki/Fronthem#eigene_Converter) gibt es den Hinweis, dass eigene Converter im gleichen namespace stehen müssen wie die Konverter im fhconverter.pm. D.h. Du musst in 99_myUtils.pm noch am Anfang die Zeile "package fronthem" einfügen. Ich habe meinem Dummy-Konverter eine eigene Modul-Datei 99_myFronthemConverterUtils.pm spendiert.
Hallo Romoker,
jetzt klappt :D ;D es !
Mein GAD war noch nicht ganz richtig (hatte noch den State anstatt Stop im "cmd set" ::) ) und der Namespace hatte auch gefehlt!
Vielen Dank für deine Unterstützung und allen FHEM'er einen guten Rutsch ins neue Jahr
Michael
Hallo,
ich habe mich auch an der Lösung versucht, aber irgendwie erkennt Fronthem wohl die Datei 99_fronthemUtils.pm nicht. Es kommt nur die folgende Fehlermeldung:
2018.01.18 20:27:13 1 : PC_Buero: error doing $result = fronthem::Dummy($param); Undefined subroutine &fronthem::Dummy called at (eval 43) line 1.
Die Filezuordnungen zu user fhem und group dialout sind gesetzt, ebenso die Lese- und Schreibrechte unter Debian Stretch. Die GAD-Zuordnung ist wie bei Romokers Beispiel. Mir gehen leider die Ideen aus...
Hat jemand eine Idee, woran es haken könnte?
Aua, manchmal sind die einfachsten Fehler die blödesten...
In der Zeile vor dem Fehler fehlte ein ";". Jetzt funktioniert die Einbindung. :-[