HM-LC-Sw1-Pl-CT-R1 schaltet dauerthaft ein über FHEM

Begonnen von Peete, 04 Februar 2016, 22:33:00

Vorheriges Thema - Nächstes Thema

stmeyer

Hi,
ich habe die Bedeutung von "regSet" erkannt und "intKeyVisib" auf visib gesetzt.

Dann ein getConfig und nun klappt's wieder einwandfrei.  :D

Gruß
Stefan

Leupi

Hallo,
ich hatte das gleiche Problem, aber die Kommentare geben ja nur Hinweise und keine konkreten Befehle.
Daher poste ich mal die komplette Befehlsliste, die ich jetzt erfolgreich verwendet habe, um mein Garagentor über den HM-LC-Sw1-Pl-CT-R1 zu steuern.

Über die Telnet-Schnittstelle sieht das dann so aus, aber die Kommandos lassen sich genauso natürlich auch über die Web-Oberfläche ausführen.

fhem> set HMVCCU hmPairForSec 300
fhem> rename HM_xxxxxx Garage_Tor
fhem> attr Garage_Tor room Test
fhem> attr Garage_Tor group Garage
fhem> attr Garage_Tor icon fts_garage
fhem> attr Garage_Tor webCmd press
fhem> set Garage_Tor regSet intKeyVisib visib
fhem> set Garage_Tor getConfig
fhem> save


Jetzt zieht der Aktor kurz an, wenn man den Taster am Gerät bedient oder in der Web-Oberfläche auf "press" klickt.
In FHEM lässt sich das natürlich auch per Kommando ausführen:

fhem> set Garage_Tor press

Viel Erfolg damit.

Gruß,

   -Stefan-

HansDampfHH

#17
Okay, erledigt. Sorry, hatte erst das gleich Problem, jetzt geht es :-)
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

Udomatic

#18
Hallo,

ich bin nach der Anleitung aus dem Beitrag von Leupi vorgegangen.
Kann mir bitte jemand sagen, wie ich prüfe ob intKeyVisib visib gesetzt wurde? Dachte ich sehe das nach setzen in den Readings

Vielen Dank im Voraus
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Hi,

man setzet kein Reading, man setzt ein Register. Danach ein getConfig und das Reading sollte zu sehen sein -> R-intKeyVisib

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

martinp876

Register sind nicht alle direkt im reading zu sehen. du kannst es sichtbar schalten mit

attr global schowinternalvalues 1
oder
set <device> expert 1

oder einfach ein
get <device> regTable

wie Otto schon gesagt, die Readings sind eine kopie der Register des Device. Sie müssen erst gelesen werden (automatisch oder manuell). Manuell geht es mit getConfig


Udomatic

Zitat von: martinp876 am 07 Dezember 2018, 19:55:51
attr global schowinternalvalues 1

Danke, das hat geholfen. Jetzt sehe ich das Reading R-intKeyVisib und es steht auf visib.

Ich kann auch soweit mein Garagentor öffne und schließen. Allerdings wird das Device als Switch geführt und nicht als Taster, was mein Ziel war.

Als Switch ist das Tor dann auch in der HomeApp zu sehen und kann darüber betätigt werden. Im Moment ist allerdings das Tor zu und der Switch steht auf "Ein".

Wie bekomme ich das noch gelöst?

Vielen Dank!
Udo
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

martinp876

Kommt darauf an, wie du es bedienen willst.
Dass es "ein" ist ist quasi normal, aber schlecht. Es soll sicher nur einen puls auslösen. So 1sec.
Primär einfach ist, is über buttons zu betreiben. Nutze templates. Peere alle buttons, die es schalten sollen. Dann nutze ein template welches wie ein trepoenhausschalter für 1s einschaltet, dann wieder aus ( oder 2s, oder 5)
Auch der interne taster self01 sollte so geschaltet werden.

Nun vermeide, on oder off zu nutzen. Press ist eine alternative. Oder onfortimer.

Udomatic

Zitat von: martinp876 am 07 Dezember 2018, 20:51:03
Primär einfach ist, is über buttons zu betreiben. Nutze templates. Peere alle buttons, die es schalten sollen. Dann nutze ein template welches wie ein trepoenhausschalter für 1s einschaltet, dann wieder aus ( oder 2s, oder 5)
Auch der interne taster self01 sollte so geschaltet werden.

Kannst du das bitte noch etwas ausführen. Bin seit 3 Monaten am aufbauen von FHEM auf einem PI und habe lese wirklich viel. Ich merke aber auch, dass man zu den diversen Themen viel Wissen aufbauen muss und bemühe mich so gut es geht das Forum und alle fertigen Anleitungen zu studieren und zu nutzen.

Also was genau meinst du mit Buttons und Peere diese alle? Welche Templates?

2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Pfriemler

Was ich verstanden habe, fasse ich mal so zusammen:
1. Der besagte Aktor ist ein Switch, kein Taster. Logisch gehört er zu den Schaltern. Man kann ihn ein- und ausschalten, mehr nicht.
2. Für den geplanten Anwendungsfall macht das i.d.R. keinen Sinn. Deshalb ist hier der interne Taster und auch gepeerte externe Tasten per default so programmiert, dass ein Trigger (Schaltbefehl) den Aktor nicht dauerhaft einschaltet, sondern nach kurzer Zeit wieder aus. Das kann man mit praktisch jedem Homematic-Aktor auch nachträglich so programmieren, aber nur hier passiert es eben automatisch.
3. Löst man aus FHEM per "press" aus, gelten hier die für den Peer definierten Schaltregeln - der Aktor verhält sich so, als ob ein Befehl vom Button oder einer Fernbedienung gekommen wäre, wendet die internen Regeln an - und schaltet nach gewünscht kurzer Zeit aus.
4. Schaltet man aus FHEM den Aktor per "on" ein, bleibt er dauerhaft an. "on-for-timer" ist ja schon wieder ein Spezialfall.
5. Das gleiche passiert, wenn man mit einer Fremd-App als GUI über FHEM schaltet. Das dürfte das Problem von Udomatic sein.

Der einzige Workaround, der mir hier spontan einfiele, wäre ein Notify in FHEM, welches durch den Einschaltzustand des Aktors getriggert wird und diesen sofort wieder ausschaltet. Hier entsteht aber zwangsläufig eine Verzögerung von mehreren Sekunden, weil der Aktor seinen neuen Schaltzustand mit einer gewissen Verzögerung zurückmeldet (auf den Trigger/Button reagiert er sofort und schaltet auch, aber die geänderte Zustandsmeldung, die er an seine Zentrale (hier FHEM) sendet, kommt eben etwas später.
Deswegen wird man mit diesem Verfahren kaum unter 2s Betätigungszeit bleiben. Wenn das dem angeschlossenen Gerät nichts tut, ist das dann doch kein Problem.

Jm2c.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Udomatic

#25
Das ist meine bisherige Lösung, die auch funktioniert, dass ich sowohl über FHEM als auch Homekit, das Tor per Impuls öffnen kann und nach 1 Sekunde der Schalter wieder aus geht.


IODev      myHmUART
   autoReadReg 4_reqStatus
   eventMap   /on-for-timer 1:Press/
   expert     2_raw
   firmware   2.5
   homebridgeMapping clear On=state,valueOn=on,cmdOn=on-for-timer+1,cmdOff=on-for-timer+1
   icon       fts_garage
   model      HM-LC-Sw1-Pl-CT-R1
   peerIDs    00000000,56257F01,
   room       CUL_HM,Garage,Homekit
   serialNr   xxxxxxxxx
   siriName   Tor
   subType    switch
   webCmd     Press


Was mir jetzt noch fehlt ist der wirkliche Zustand des Tors Offen / Geschlossen.

Vielen Dank soweit für die Hilfestellungen
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Pfriemler

Tor auf/zu nur über Impulse zu toggeln finde ich ja mutig... einmal desynchronisiert öffnet/schließt das Tor auch umgekehrt. Ohne echte Zustandserkennung wird das doch nix.
Ich habe früher einen Dummy dafür bemüht, der Zustände und Wünsche gleichermaßen zwischenspeicherte und ein DOIF, welches situationsabhängig Befehle geschickt hat.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Udomatic

Zitat von: Pfriemler am 12 Dezember 2018, 15:23:22
Tor auf/zu nur über Impulse zu toggeln finde ich ja mutig... einmal desynchronisiert öffnet/schließt das Tor auch umgekehrt. Ohne echte Zustandserkennung wird das doch nix.

Ich habe mir jetzt noch einen HM-Sec-Tis angeschafft und eingerichtet. Mit dieser Kombination bin ich vorerst zufrieden.

Aber was meintest du eigentlich genau mit desynchronisiert?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Pfriemler

Wie ich verstanden hatte hast Du bisher einen Pseudoschalter betätigt - Tor auf, Tor zu ... bei jeder Zustandsänderung ein toggle an den Antrieb. Wenn da mal ein Knoten ist,  zeigen Dummy und Tor gegensätzliche Zustände.

Wenn Du den Torzustand direkt vom Tis nimmst, kann das auch Probleme machen,  wenn während der Fahrt ein neuer Befehl kommt. Ich hatte dann einige Logik eingebaut und das klappte schließlich bestens. Ich konnte dann öffnen, schließen stoppen - und die Logik hat entsprechend Takte gesendet - oder eben auch nicht.

Dann verließ mich der Motor und seither tut ein intelligenter Antrieb, dem ich die Positionen direkt vorgeben kann ...

Wenn Interesse, kann ich das nochmal raussuchen aus dem Archiv.

via Tapatalk

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."