Neues Modul für Ein-Knopf-Garagentor-Steuerungen

Begonnen von farion, 06 Februar 2016, 18:02:43

Vorheriges Thema - Nächstes Thema

cs-online

Ich stehe gerade an der gleichen Stelle. Ich werde das einfach so machen, daß der Schließkontakt ein notify auslösen wird, das dann "force Close" auslöst, d.h. bei geschlossenem Tor habe ich dann auch die Anzeige "Closed". Wenn ich über den Taster in der Garage oder über den Schlüsselschalter auslöse, zeigt das Modul natürlich nicht richtig an, weil es ja gar nichts mitkriegt. Aber wenn das Tor dann wieder geschlossen ist, stimmts wieder. Wenn über FHEM (z.B. mit einer Intertechno-FB) ausgelöst wird, wird das Modul angestoßen und ich kann dann den Zustand detailliert sehen.

Falls dein CUL das Signal vom Garagentoröffner aufnehmen kann (soll heissen, dein gesendeter Code von FHEM entschlüsselt werden kann), kannst Du wiederum das als Device in das Modul als Signaldevice zum öffnen/schließen nehmen und damit das Modul auslösen...

Ansonsten definieren z.b. bei mir mit:

defmod Garagentorantrieb GarageDoorSingleButton ESPEasy_Schuppen_Relais_8 garagentest\

attr Garagentorantrieb closeSensorDevice garagentest
attr Garagentorantrieb room Garage_&_Schuppen
attr Garagentorantrieb stateFormat {ReadingsVal($name,"state","") ne "Open" && ReadingsVal($name,"state","") ne "Closed" ? ReadingsVal($name,"state","?")." - Level: ".ReadingsVal($name,"level","?")." %" : ReadingsVal($name,"state","?")}
attr Garagentorantrieb totalTimeDown 13,5
attr Garagentorantrieb totalTimeUp 14
attr Garagentorantrieb turnTime 1
attr Garagentorantrieb webCmd open:close:stop:press


mein Schuppenrelais_8 hängt parallel zum Taster am Öffner, mein Tor braucht 14s von unten nach oben und 13,5s nach unten und ca. 1s um die Richtung zu wechseln

BTW: hat das closeSensorDevice schon eine Funktion ? Muss ich den Event irgendwie mit eingeben ? Wie ? Ich habe da ein Schaltdummy zum probieren, da tut sich aber nichts...
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Ingo298

Ich habe es so erstmal gelöst

AUF und ZU Sensor
define Se_Zu_Tor_1 CUL_HM 5F283801
attr Se_Zu_Tor_1 DbLogExclude .*
attr Se_Zu_Tor_1 devStateIcon open:Auf closed:Zu
attr Se_Zu_Tor_1 group Tor_Sensoren
attr Se_Zu_Tor_1 model HM-SCI-3-FM
attr Se_Zu_Tor_1 peerIDs 00000000,
attr Se_Zu_Tor_1 room 00_4 Garage

define Se_Auf_Tor_1 CUL_HM 5F283802
attr Se_Auf_Tor_1 DbLogExclude .*
attr Se_Auf_Tor_1 devStateIcon open:zu closed:auf
attr Se_Auf_Tor_1 group Tor_Sensoren
attr Se_Auf_Tor_1 model HM-SCI-3-FM
attr Se_Auf_Tor_1 peerIDs 00000000,
attr Se_Auf_Tor_1 room 00_4 Garage


Schalter

define SW_Tor_1 CUL_HM 4C346F
attr SW_Tor_1 DbLogExclude .*
attr SW_Tor_1 IODev CUL1
attr SW_Tor_1 IOgrp VCCU
attr SW_Tor_1 autoReadReg 4_reqStatus
attr SW_Tor_1 expert 1_allReg
attr SW_Tor_1 firmware 1.7
attr SW_Tor_1 group Tor_Sensoren
attr SW_Tor_1 model HM-LC-SW1-BA-PCB
attr SW_Tor_1 msgRepeat 1
attr SW_Tor_1 peerIDs 00000000,
attr SW_Tor_1 room 00_4 Garage
attr SW_Tor_1 serialNr NEQ0603514
attr SW_Tor_1 subType switch
attr SW_Tor_1 webCmd statusRequest:toggle:on:off


Steuerung
define Tor_1 GarageDoorSingleButton SW_Tor_1 Se_Zu_Tor_1
attr Tor_1 DbLogExclude .*
attr Tor_1 closeSensorDevice Se_Zu_Tor_1
attr Tor_1 devStateIcon Open:fts_garage_door_10@red Closed:fts_garage_door_100@green DrivingUp:control_arrow_upward@red DrivingDown:control_arrow_downward@red StoppedOnWayUp:fts_garage_door_50@red StoppedOnWayDown:fts_garage_door_50@red
attr Tor_1 group Tor_1
attr Tor_1 room 00_4 Garage
attr Tor_1 totalTimeDown 21
attr Tor_1 totalTimeUp 21
attr Tor_1 turnTime 2
attr Tor_1 warnFct set Push message Alarm | Das Garagentor ist noch offen!
attr Tor_1 warnTime 300
attr Tor_1 webCmd open:close:stop


notify
define Tor_1_closeSensorNotify notify Se_Zu_Tor_1:closed set Tor_1 forceClose
attr Tor_1_closeSensorNotify DbLogExclude .*
attr Tor_1_closeSensorNotify room 99_3 nodify

define Tor_1_openSensorNotify notify Se_Auf_Tor_1:closed set Tor_1 forceOpen
attr Tor_1_openSensorNotify DbLogExclude .*
attr Tor_1_openSensorNotify room 99_3 nodify


Und ein Dummy um mit der Homebridge zu schalten

define Tor_1_Dummy dummy
attr Tor_1_Dummy DbLogExclude .*
attr Tor_1_Dummy devStateIcon auf:fts_garage_door_10@red zu:fts_garage_door_100@green
attr Tor_1_Dummy event-on-change-reading .*
attr Tor_1_Dummy genericDeviceType switch
attr Tor_1_Dummy group Tor_1
attr Tor_1_Dummy room 00_4 Garage,Homekit
attr Tor_1_Dummy setList auf zu
attr Tor_1_Dummy webCmd auf:zu

define Torsteuerung_auf notify Tor_1_Dummy:auf set Tor_1 open
attr Torsteuerung_auf DbLogExclude .*
attr Torsteuerung_auf room 99_3 nodify
define Torsteuerung_zu notify Tor_1_Dummy:zu set Tor_1 close
attr Torsteuerung_zu DbLogExclude .*
RPi4 8GB: Buster FHEM 6.3, FTUI-3, AMAD,10.1" Tablet; MiLight;IT;HM;Dect200;VZLogger;MQTT

cs-online

Hallo,

hat jemand eine Idee, warum ich teilweise beim Anfang des Öffnens/Schließens eine negative Prozentzahl angezeigt bekomme ?

Bei mir funktioniert inzwischen übrigens prima mit einer Intertechno-FB das Garagentor mit "on" auf und mit der "off"-Taste wieder zu schließen :-) Das ist richtig cool !!!
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

RitterSport

#63
Hallo,

nach bisher langem Einsatz bekomme ich jetzt lazfend einen Abstürz von Fhem wenn auf das Modul zugegriffen wir.
Im Log ist der letzte Eintrag: Undefined subroutine &main::GarageDoorSingleButton_PressAborted called at FHEM/Blocking.pm line 142.

Liegt dies am Modul 98_GarageDoorSingleButton.pm oder an der Blocking.pm ? Das <modul selber habe ich in der Version 0.0.1 benutzt, und probehalber auf 0.0.3 updated. Aber kein Unterschied.


*Update*
Ich habe die Blocking.pm vom 3.10. jetzt zurückgesetzt auf eine vom 30.07., damit läuft es einwandfrei. Zeile 142 ist bei beiden jeweils unterschiedlich im Bezug auf das Beenden eines Prozesses.

Apollon

Hallo,

ich habe meinen Garagentorantrieb mit dem Schaltaktor (HM-LC-SW1-BA-PCB) und dem Fenstersensor (HM-SEC-SCo) realisiert. Ich habe es über ein Dummy-Device und einigen Skripten umgesetzt.

Nun bin ich durch Zufall auf diese Lösung gestoßen. Der Schaltaktor funktioniert einwandfrei. Jedoch wird der Status meines Fenstersensors nicht im GarageDoorSingleButton-Device angezeigt.

Gibt es eine Möglichkeit, meinen Sensor mit dem GarageDoorSingleButton-Device zu verknüpfen? 

Gruß
Apollon

andies

#65
Danke farion für den Hinweis zu dem Modul, ich hatte den schon früher mal gesehen, mich aber nicht herangetraut. Ich habe so ganz simple Verständnisfragen, die ich beim Lesen des Codes (hast Du nicht geschrieben, Du seiest kein Perl-Profi oder so - war das Ernst gemeint?!) nicht beantworten konnte:

  • Heißt Button richtig Taster (kurz drücken) oder Schalter (ein schalten und bleibt dann ein, muss wieder aus geschaltet werden)? Ich habe einen Taster an meiner betagten Öffnung. Geht das dann?
  • Wie kann man Prozente der Öffnung angeben, wenn doch nur der Taster die Öffnung auslöst und sperrt? Das kannst Du doch eigentlich nur dadurch "messen", dass eben noch einmal ein Taster gedrückt wurde, oder? Einen anderen Sensor sehe ich hier nicht.
  • Kann ich als Aktor, der dann den Taster/Schalter auslöst, auch ein IT-Gerät angeben? Wo genau mache ich das?
  • Wie verknüpfst Du Eingaben, die nicht von FHEM kommen, mit denen aus FHEM? (Tor ist halb geschlossen, Frau bedient mit FB und macht des 3/4 zu usw.)
  • Wenn ich einen anderen Sensor habe, wie baue ich den hier ein?
Das Modul hört sich wirklich toll an, aber ich steige leider nicht durch. Wenn ich das kapiere, würde ich mich bereit erklären eine kurze Hilfe unter "device specific help" zu schreiben, das finde ich immer bei meinen Sachen sinnvoll, die ich geschrieben habe.

PS Ich finde die Zeichnung im ersten Post auch schön, aber auch das kapiere ich nicht (ich komme nicht aus der Programmierungsecke). Gibt es da den einen oder anderen Tipp, wie man das versteht? (Also zum Beispiel: Warum ist es open_cmd_trigger, wenn das Tor geschlossen werden soll?)
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Apollon

@andies
Ich versuche mal deine Fragen zu beantworten. Meine Erkenntnisse basieren auf eine Testinstallation des Moduls.

zu1. Nach deiner Definition ist der Button ein Taster. Wird der Button ausgelöst, dann wird eingeschaltet und anschließend wieder ausgeschaltet. So wie dein Antrieb funktioniert, sind mWn die meisten Antriebe ausgelegt, ob betagt oder nicht betagt. Genau dafür hat farion diese Modul erstellt.

zu 2. Ich habe nicht versucht, die Programmierung zu entschlüsseln. Aber ohne Sensor geht das nur über die Zeit des Laufs. Hierfür sind die Attribute totalTimeDown und totalTimeUp hilfreich.

zu3. ?? ?? Wenn du über das IT-Gerät verfügst, dann binde doch mal eben das Modul ein. Dafür benötigt man nicht viel Zeit und man erhält einige Antworten. Der Aktor wird beim define oder später über das Attribut BUTTON_DEVICE eingebunden.

zu 4. Das ist immer das Problem, wenn Geräte auch noch von außerhalb geschaltet werden können. Hat man nur einen Fenstersensor, kann auch nur ein Zustand richtig angezeigt werden. Bei 2 Fenstersensoren kann man den offenen und geschlossenen Zustand richtig anzeigen. In diesem Thread hat jemand einen Neigungssensor ins Spiel gebracht. Der wäre natürlich noch viel flexibler.

zu 5. Ich habe auch einen anderen Fenstersensor. Ich habe ihn nicht eingebunden bekommen. Ich habe mein eigenes Skript um einige Funktionalitäten ergänzt, so dass ich nun über die meisten Funktionen aus dem Modul verfüge. Wenn es bei dir nicht funktionieren sollte, kann ich dir mit meinen Ansätzen bestimmt helfen.

Gruß
Apollon

cs-online

Also, natürlich kann das Modul nicht erkennen, ob die Frau am Tor auf den Taster oder auf die FB drückt. Da aber meistens die Zustände die sind, Tor ist ganz auf oder ganz zu, kann man über einen Endschalter in Stellung auf ein ForceOpen bzw. bei Endstellung zu dann ein ForceClosed senden und damit sozusagen FHEM wieder mit dem Torzustand synchronisieren. Den Zwischenlauf, also halb geöffnet funktioniert genau wie beim Rolladen über die absolvierte Laufzeit zwischen den beiden Impulsen (im Verhältnis zur Gesamtlaufzeit in die jeweilige Richtung, das muss vorher einmal als Attribut eingegeben werden), die dann von FHEM kommen oder über Einbindung von  z.B. einer Intertechno-Fernbedienung oder einer anderen mit FHEM kompatiblen Fernbedienung.
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

farion

Apollons Antworten beantworten zwar schon vieles, ich gebe aber trotzdem nochmal meinen Senf dazu.

Erstmal prinzipiell: Das Modul selbst behandelt keine Hardware, sondern benutzt existierende Geräte. Das sind eben der(die) Sensor(en) und der Aktor. Sprich, die Geräte müssen in FHEM angelegt sein und funktionieren. Dem Modul übergibt man dann lediglich wie das Gerät heisst und welche Attribute den gewünschten Wert enthalten (Falls hier eine Einstellungsmöglichkeit fehlt, bitte melden, dann rüsten wir das nach). Wichtig, der gemeinte Aktor ist das Gerät, welches die Garage bedient (die Schaltung in meinem ersten Post). Von aussen gesteuert wird das Modul wiederum über irgendwelche anderen Geräte .. z.B. einen HM-Taster (sowas hab ich im Auto), einem HM-Knopf am Schlüsselbund oder der Weboberfläche. Die triggern am Ende alle Befehle dieses Moduls ... das muss man aber nicht hier um Modul definieren, sondern dort wo der Knopf gedrückt wird.

zu 1: Der ursprüngliche Knopf an der Garage ist wirklich ein Taster. Der HM-LC-SW1-BA-PCB schaltet aber dauerhaft. Deswegen funktioniert die Steuerung so, dass sie durchschaltet und nach 1s wieder ausschaltet um eben einen kurzen Tastendruck über das Relais simuliert.

zu 2: Genau, wie Apollon schrieb muss man im Modul die Zeiten konfigurieren, die das Tor braucht um komplett herunterzufahren, komplett heraufzufahren und die Richtung zu wechseln. Intern benutzt das Modul einen Zustandsautomat (die Zeichnung aus dem ersten Post) und berechnet die %-Angabe.

zu 3: Was ist ein IT-Gerät? Du kannst als Aktor jedes Gerät in FHEM angeben. Mit dem buttonTriggerCommand kannst du auch selbst definieren, was genau passieren soll. Der default ist eben "on-for-trigger 1" ... also für 1s durchschalten ... wenn dein Gerät einen anderen Befehl braucht kannst du den angeben.

zu 4: Eingaben, die nicht von FHEM kommen sind dem Modul nicht bekannt. Also ändert sich der Zustandsautomat nicht und der Status in FHEM ist falsch. Wenn du aber zwei Sensoren hast, wird der Status automatisch repariert, sobald das Tor wieder eine Maximalposition erreicht und einer der Sensoren auslöst. (das was cs-online geschrieben hat). Ich verwende daher wie gesagt die originalen Steuerungsmöglichkeiten nicht.

zu 5: Was meinst du mit "anderem Sensor" ... wie oben geschrieben ist das Modul hardware-unabhängig ... solange das Gerät in FHEM vorhanden ist, kannst du es angeben ... das Attribut, welches abgefragt werden soll kannst du ebenfalls einstellen.

Ich hoffe das hilft erstmal.

Gruss Farion

PS: Die Zeichnung ist ein Zustandsautomat. Ein Kreis ist ein Zustand. Ein Pfeil ein Ereignis, welches den Zustand ändert. Also wenn ich im Zustand "open" drücke(press) bin ich im Zustand "driving down". Die Angaben in den grauen Kästen geben an, wie oft man "drücken" muss um zu öffnen oder zu schliessen. Also im Zustand "driving down" muss ich 2x (also 1x für stoppen, 1x für hochfahren) drücken um das Tor zu öffnen. Aber die grauen Kästen kannst du beim drüber nachdenken erstmal aussen vor lassen, die haben erstmal nix mit dem Automat zu tun.
PPS: Meine Perl-Erfahrung beschränkt sich wirklich auf FHEM. Aber Ahnung von Softwareentwicklung hab ich schon :).
PPPS: Apropos "Ahnung von Softwareentwicklung" ... da scheint es wirklich einen Bug mit GarageDoorSingleButton_PressAborted zu geben. Das war bisher vermutlich nicht schlimm, aber durch eine Änderung im Core ist das jetzt evtl. relevant. Ich fixe das asap.
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

farion

@Apollon
Hast du den korrekten closeSensorDeviceEvent gesetzt?

Gruss Farion

PS: Wenn ich die Tage mal Zeit habe baue ich auch das zweite Sensor-Device mit ein.
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

benz_freak

Zitat von: farion link=topic=48847.msg710283#msg710283 date=150988733

PS: Wenn ich die Tage mal Zeit habe baue ich auch das zweite Sensor-Device mit ein.
/quote]

Hallo Farion
also an den zweiten Sensor hab ich großes Interesse. Da die Garage oft mit einem Schlüsselschalter bedient wird. Alternativ müsste ich halt noch ein Sender der mit FHEM spricht an den Schlüsselschalter bauen. Mir würde der zweite Sensor aber besser gefallen.
Mit freundlichen Grüßen Benjamin


Gesendet mit Tapatalk

farion

Ja, ich hab das schon so halb fertig ... aber durch Job und Familie und so dann liegen gelassen :(. Viel Arbeit ist es glaube nicht mehr. Gruss Farion
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

farion

#72
Hi,

so habe mal die aktuelle Version hochgeladen (erster Post). Die ist nicht wirklich gut getestet, aber falls der ein oder andere Lust dazu hat bin ich für Feedback dankbar.

@benz_freak: Der zweite Sensor ist da mit drin.
@RitterSport: Das sollte dein Problem lösen
@Waldo Pepper: Evtl. deines auch.


Gruss farion
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

Apollon

Zitat von: farion am 05 November 2017, 14:08:55
@Apollon
Hast du den korrekten closeSensorDeviceEvent gesetzt?

Gruss Farion

PS: Wenn ich die Tage mal Zeit habe baue ich auch das zweite Sensor-Device mit ein.
Ja klar habe ich das Device eingetragen. Die unterschiedliche schreibweise der Readings habe ich auch versucht zu korrigieren. Hat aber nicht hingehauen.
Macht aber nichts, ich habe dann meine eigenen Skripte aufgepimpt, so dass ich nun in jeder Stellung auf "Auf", "Ab" und "Stop" drücken kann und immer die richtige Aktion ausgeführt und angezeigt wird.

Ich habe in deinem Code gesehen, dass du mit sleep gearbeitet hast. Sleep hat bei mir immer Probleme verursacht. Meistens, dass die Aktion davor nicht ausgeführt wurde. Deshalb habe ich mit at's weitergemacht. Das ist zwar aufwendig und alle temporären at's müssen bei jeder dazwischenkommenden Aktion erst wieder gelöscht werden, war für mich aber die einzig erkennbare Möglichkeit keine Fehler zu bekommen.

Dein  Modul hat mich dazu inspiriert, meine Steuerung zu verfeinern.

Gruß
Apollon

crispyduck

Hallo,

hab mich nachdem ich am WE mein Garagentor via RPI_GPIO, Relais und Reedkontakt auch in FHEM eingebunden habe, hab ich mir heute mal das Modul angesehen.

@farion, erst mal vielen Dank für dein Modul!

Wie es scheint hast du die v0.0.6 soweit abgeändert das diese nur noch mit OPEN_SENSOR funktioniert.

Eventuell könnte man hier ja noch einbauen ob ein OPEN_SENSOR_DEVICE definiert wurde.

Mit der v0.0.3 habe ich leider das Problem das fhem("get ".$hash->{CLOSE_SENSOR_DEVICE}." param state" beim RPI_GPIO Input device immer nur high oder low liefert.

Ist hier absichtlich ein get? Ein value($hash->{CLOSE_SENSOR_DEVICE}) müsste doch den aktuellen State zurück geben?

Lg,
crispyduck