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

[Beetle2003]

Hallo in die Runde,

nutze das Garagentor Modul seit einiger Zeit. Habe nun auch die Weiterentwicklung von Niko1987 eingebaut.
Ist eine echt gute Lösung.
Habe es bei mir mit Reedkontakten und einem originalen HM-SCI-3 gelöst. Beim zweiten Tor auch mit Reedkontakten und einem selbstgebauten HM-SCI-3 von Asksinpp. Der von Asksinpp gefällt mir besser, da er den Status direkt ausgibt.

Nun bin ich wieder auf eine neue Fragestellung gekommen:
Ich habe festgestellt, dass wenn ich das Tor durch open ansteuere und der Antrieb ist gar nicht am Strom, so zeigt das Modul nach der eingestellten Zeit offen obwohl es geschlossen ist. Fragt Ihr noch einmal expleziet die Kontakte nach dem Zustand ab und gebt ggf einen Fehler aus?

Hat jemand von Euch eine Lüftungsöffnung programmiert?

Danke

[Beetle2003]

Servus,
ich hatte das Problem auch. Hab einfach die 98_GarageDoorSingleButton.pm angepasst:

Code Auswählen Erweitern

elsif ( $hash->{helper}{DOORSTATE} == GarageDoorSingleButton_State_Open ) {
        $hash->{helper}{TC} = $totalTimeDown;
        $hash->{helper}{TO} = 0;
        RemoveInternalTimer($hash);
        readingsBulkUpdate($hash, "state","Open");
        Log3 $name, 3, "[GarageDoorSingleButton] Change state: Open"; 
        my $openSensorDeviceEvent = AttrVal( $name, "openSensorDeviceEvent", "closed" );
        my $closeSensorDeviceEvent = AttrVal( $name, "closeSensorDeviceEvent", "open" );
        if ( fhem("get ".$hash->{CLOSE_SENSOR_DEVICE}." param state") eq $closeSensorDeviceEvent ||
            fhem("get ".$hash->{OPEN_SENSOR_DEVICE}." param state") ne $openSensorDeviceEvent ) {
            readingsBulkUpdate($hash, "inconsistent","No");
        }else{
            readingsBulkUpdate($hash, "inconsistent","Yes");

Ich habe die Werte des CLOSE_SENSOR_DEVICE und des OPEN_SENSORT_DEVICE so angepasst.

Code Auswählen Erweitern

my $openSensorDeviceEvent = AttrVal( $name, "openSensorDeviceEvent", "closed" );
        my $closeSensorDeviceEvent = AttrVal( $name, "closeSensorDeviceEvent", "open" );
Der Close Sensor hat bei mir den State "open" wenn das Garagentor offen ist.
Der Open Sensor hat bei mir den State "closed" wenn das Garagentor offen ist.

Ausserdem Hab ich die readingsBulkUpdate genau vertauscht.

Code Auswählen Erweitern

readingsBulkUpdate($hash, "inconsistent","No");
        }else{
            readingsBulkUpdate($hash, "inconsistent","Yes");
Das heisst, wenn er die oberen States hat setzt er das Modul auf inconsistent No, wenn er andere States bekommt dann auf insconsistent yes.


Das gleiche Spiel muss aber auch beim Zustand geschlossen geändert werden.

Code Auswählen Erweitern

elsif ( $hash->{helper}{DOORSTATE} == GarageDoorSingleButton_State_Closed ) {
        $hash->{helper}{TC} = 0;
        $hash->{helper}{TO} = $totalTimeUp;
        RemoveInternalTimer($hash);
        readingsBulkUpdate($hash, "state","Closed");
        Log3 $name, 3, "[GarageDoorSingleButton] Change state: Closed";   

        my $openSensorDeviceEvent = AttrVal( $name, "openSensorDeviceEvent", "open" );
        my $closeSensorDeviceEvent = AttrVal( $name, "closeSensorDeviceEvent", "closed" );

        if ( fhem("get ".$hash->{CLOSE_SENSOR_DEVICE}." param state") ne $closeSensorDeviceEvent ||
            fhem("get ".$hash->{OPEN_SENSOR_DEVICE}." param state") eq $openSensorDeviceEvent ) {
            readingsBulkUpdate($hash, "inconsistent","No");
        }else{
            readingsBulkUpdate($hash, "inconsistent","Yes");

Hier habe die auch die Werte des CLOSE_SENSOR_DEVICE und des OPEN_SENSOR_DEVICE so angepasst.

Code Auswählen Erweitern

my $openSensorDeviceEvent = AttrVal( $name, "openSensorDeviceEvent", "open" );
        my $closeSensorDeviceEvent = AttrVal( $name, "closeSensorDeviceEvent", "closed" );


Der Close Sensor hat bei mir den State "closed" wenn das Garagentor zu ist.
Der Open Sensor hat bei mir den State "open" wenn das Garagentor zu ist.

Hier habe ich die  auch readingsBulkUpdate genau vertauscht.

Code Auswählen Erweitern

readingsBulkUpdate($hash, "inconsistent","No");
        }else{
            readingsBulkUpdate($hash, "inconsistent","Yes");



Jetzt bekommt das Modul auch mit wenn ich das Tor (ohne Fhem) von Hand oder mit der Original Fernbedienung öffne.
Hatte mal eine Postbotin, die hat so stark am Tor gezogen, dass nie Notentriegelung aus der Kette gerutscht ist.... Hab ich nie geschafft, egal wie stark ich ziehe.

Vielleicht hilft das jemanden weiter.
Ich häng die Datei mal mit an.
Gruß
Flo

Hallo,

ich nutze auch Deine Anpassung.

Nun versuche ich noch eine Lösung zu finden, dass wenn das Tor manuell geöffnet wurde und noch nicht ganz auf ist, dieses auch angezeigt wird.
Ich finde den Punkt nicht, wo und wie dieses zu machen ist. Sprich:
Torfahrzeit ist abgelaufen, Tor noch nicht am Schalter für geöffnet, Anzeige derzeit geschlossen - möchte das dann ein Icon angezeigt wird, dass das Tor teilgeöffnet ist.

Kannst Du mich bei dieser Umstellung unterstützen?

Danke

[Niko1987]

Hallo Beetle,

Ich bin ehrlich gesagt kein Programmierer... ich hab das ganze über ein Usereadings gelöst wobei ich dazu sagen muss,
dass FHEM für mich nur die Verbindung zu Loxone ist und Loxone solche Dinge wie "Tor nicht in vorgegebener Zeit geschlossen"-Dinge
mitbringt und für mich erledigt. Drum ist mir die Oberfläche von Fhem erst mal nicht so wichtig.

Code Auswählen Erweitern

attr Garage UserReadings TorStatus {if(ReadingsVal("GarageOffenSensor","state","") eq "closed") {return 100}
elsif (ReadingsVal("Garagentor","state","") eq "closed") {return 0}
elsif (ReadingsVal("Garagentor","state","") eq "open") {return 50}
elsif (ReadingsVal("GarageOffenSensor","state","") eq "open") {return 50}
else {return 999}}

Vielleicht hilft dir das etwas.
"Garage" ist bei mir das Device der Ein-Knopf-Garagentor-Steuerung.
Mein Sensor der closed steht wenn das Tor zu heißt: Garagentor
Mein Sensor der closed steht wenn das Tor offen heißt: GarageOffenSensor

Du hättest dann ein zusätzliches Reading mit dem Namen TorStatus der folgende Werte hat:
0 wenn das Tor zu ist
100 wenn das Tor offen steht
50 wenn das Tor weder die obere, noch die untere Lage erreicht hat.
999 wenn einer der beiden Sensoren einen Blödsinn im State stehen hat.

mit einem

Code Auswählen Erweitern

attr Garage stateFormat TorStatus

und mit

Code Auswählen Erweitern

attr Garage devStateIcon  100:fts_garage_door_10 0:fts_garage_door_100 50:fts_garage_door_50@red
hättest du dann auch die Icons dementsprechend im Status


Gruß Flo

[farion]

Hi,

ich hatte leider letztes Jahr wenig Zeit mich um FHEM zu kümmern. Entschuldigung dafür. Ich setzte das Modul aber immer noch erfolgreich ein. Bin also an einer Weiterentwicklung durchaus noch interessiert.

Was sind denn die aktuellen Wünsche und Probleme mit dem Modul? Wenn ich es richtig gelesen habe:
- Problem mit dem Status, Inkonsistenzen werden nicht immer korrekt erkannt.
- Manuelles Steuern des Tors wird nicht erkannt.
- Das Modul soll - ähnlich wie ein Rollladen - eine prozentuale Öffnung bekommen?
- Kalibrierungslauf

Das Modul befindet sich jetzt auch auf Github (siehe auch erster Post):

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/farion/fhem-garagedoorsinglebutton/master/controls_garagedoorsinglebutton.txt

Gruss farion

[farion]

@Wzut hatte oben erwähnt, dass die Eventnamen hardcoded sind. Das ist in der aktuellen Version auf jeden Fall nicht mehr so.

Es gibt im Modul 4 Attribute:

openSensorDevice
openSensorDeviceEvent
closeSensorDevice
closeSensorDeviceEvent

Das ist jeweils das Sensor-Gerät und der Eventname. Per default ist der Eventname "closed" - im Sinne von, der Sensor ist geschlossen. Da kann man aber auch beliebige andere Namen eintragen. Also z.B. "open". Den Code muss man dafür nicht ändern, sondern nur in FHEM das entsprechende Attribut setzten.

Wichtig ist, dass das openSensorDevice triggert wenn das Tor komplett geöffnet ist. Der openSensor ist optional.

[kabanett]

Hallo
und schön das es weitergeht!

Ich nutze einen ESP8266. Zum einen um das Tor zu steuern (Relais) und zum anderen den Status zu erfahren. Das funktioniert über angeschlossene Magnetschalter. Das Steuern funktioniert tatellos. Doch die Sensoren kann ich zwar im Modul angeben, aber diese werden nicht berücksichtigt. Momentan habe ich das über ein DOIF gelöst. Es macht dann ein entsprechendes set force open/close.

Es wurde hier im Thread auch schon ein paar mal nach eine Lüftungsposition gefragt. Wenn es zum Beispiel einen prozentualen Status gäbe den man anfahren kann, wäre das für mich selbst auch sehr interessant! Momentan habe ich einen dritten Sensor für die Lüftungsposition. Beim auslösen wurde das Tor gestopt. Das funktionierte jedoch nicht verlässlich durch die Verzögerung beim schalten und die unterschiedliche Geschwindigkeit beim öffnen und schliessen.
Fährt man diese Position aus dem geöffneten Zustand an, bekommt man dann auch noch das Telegram "Tor steht offen" wenn man so etwas nutzt

Gruß

[farion]

@kabanett
Kannst du mal den Log mit den Logs deiner Sensor-Events anhängen?

[kabanett]

Hi,
ist so aus dem "Event monitor" kopiert!

Code Auswählen Erweitern


2020-01-19 16:22:29 ESPEasy Garagentor_unten unten: off
2020-01-19 16:22:29 ESPEasy Garagentor_unten off

2020-01-19 16:22:39 ESPEasy Garagentor_unten unten: on
2020-01-19 16:22:39 ESPEasy Garagentor_unten on

Gruß

[xerion]

Moin zusammen,

ich wäre auch an der Weiterentwicklung des Moduls interessiert. Gerade die Punkte "Erkennung externe Betätigung" und "set pct" für die Teilöffnung würden mir sehr helfen.

Momentan habe ich aber noch ein problem mit den SensorDevice bzw. mit dem reading. Was wird dort genau unter "closeSensorDeviceEvent" erwartet?

Ich habe für die "auf und zu" Position jeweils einen Reed Kontakt der per GPIO an einem Sonoff über MQTT2 in fhem ausgewertet wird. Die events sind laut Event Monitor wie folgt:

Code Auswählen Erweitern

2020-01-21 09:04:20 MQTT2_DEVICE Hoermann_Tor_Zu POWER2: on
2020-01-21 09:02:37 MQTT2_DEVICE Hoermann_Tor_Auf POWER3: on

"on" bedeutet das der Reed Kontakt geschlossen ist, also die Position erreicht wurde.
Folgende Events habe ich schon getestet aber "inconsistent" blieb immer auf "Yes".

Code Auswählen Erweitern

attr closeSensorDevice Hoermann_Tor_Zu
attr closeSensorDeviceEvent POWER2:on
attr openSensorDevice Hoermann_Tor_Auf
attr openSensorDeviceEvent POWER3:on

und so:

Code Auswählen Erweitern

attr closeSensorDevice Hoermann_Tor_Zu
attr closeSensorDeviceEvent on
attr openSensorDevice Hoermann_Tor_Auf
attr openSensorDeviceEvent on

[Beetle2003]

Hallo,

ich wäre auch an der Weiterentwicklung interessiert.

Für mich wäre es schön. wenn
a) eine manuelle Fahrt erkannt und angezeigt würde
b) eine prozentuell Öffnung angezeigt und angesteuert werde könnte ( analog Rollosteuerung )
c) eine Lüftungsposition eingestellt und angefahren werden könnte
d) ein automatisches Schliessen bei Abwesenheit  und
c) ein automatische Schliessen Abends ( nach Uhrzeit zu definieren wäre.

Weitere Ideen sind sicherlich vorhanden

[kabanett]

d) ein automatisches Schliessen bei Abwesenheit  und
c) ein automatische Schliessen Abends ( nach Uhrzeit zu definieren wäre.

Hallo,
das geht doch jetzt schon, mit entsprechenden Helfer!
Keine Ahnung, ob so etwas in ein Gerätemodul gehört.

Den Rest unterschreibe ich so! 

Gruß

[xerion]

Das Problem mit inconsistent habe ich höchstwahrscheinlich gefunden. Wenn ich das richtig interpretiert habe (bin kein Programmierer) liegt es an dem Aufruf wie der state der Sensoren abgefragt wird. Es wird dort per "get" Befehl versucht, was z.B. in meinem Aufbau nicht funktioniert, da ich die Werte im einen MQTT2 Device habe aber in einem Dummy schreiben lasse. Beide Devices unterstützen aber keinen "get" Befehl.

So sieht der original Code beispielhaft für open aus:

Code Auswählen Erweitern

if ( fhem("get ".$hash->{CLOSE_SENSOR_DEVICE}." param state") ne $closeSensorDeviceEvent ||
            fhem("get ".$hash->{OPEN_SENSOR_DEVICE}." param state") eq $openSensorDeviceEvent ) {
            readingsBulkUpdate($hash, "inconsistent","Yes");
        }else{
            readingsBulkUpdate($hash, "inconsistent","No");

Ich habe das nun mit ReadingsVal gelöst:

Code Auswählen Erweitern

if (ReadingsVal($hash->{CLOSE_SENSOR_DEVICE},'state', '') eq $closeSensorDeviceEvent or
            ReadingsVal($hash->{OPEN_SENSOR_DEVICE},'state', '') ne $openSensorDeviceEvent ) {
            readingsBulkUpdate($hash, "inconsistent","Yes");
        }else{
            readingsBulkUpdate($hash, "inconsistent","No");

Das einzige was bei mir noch nicht funktioniert, dass bei events der Sensoren automatisch forceClose bzw. forceOpen gesetzt wird, das habe ich momentan noch mit einen DOIF gelöst.

[martin1966]

Ich hätte da noch eine Idee, um das hardwaremäßig zu unterstützen.

Evtl. könnte man die Position mit einem "VL53L0X Zeit-von-Flug (ToF) Laser Ranging Sensor" oder einem US-Sensor die Position des Tores abfragen. das schließen und öffnen ließe sich mit einem Abgriff am Motor realisieren.

Auch könnte man mit diesen Modulen eine Erkennung realisieren, die erkennt wann das Auto aus der Garage fährt und dann automatisch schließen..

[davedeluxe]

Hallo zusammen,

ich nutze seit zwei Wochen dieses Modul und bin soweit ganz glücklich damit.
Leider scheint die Entwicklung etwas ins Stocken geraten zu sein

Ich habe in der Garage noch den Schalter vom Hersteller, wenn ich diesen nutze um das Tor runter zu fahren stimmt natürlich gar nichts mehr wenn das Modul denkt das Tor sei geöffnet.
Kann man das irgendwie beheben?
Ich habe auch einen Sensor (closeSensorDevice) welcher detektiert ob das Tor auf oder zu ist aber ich sehe dahinter keine Funktion außer, dass das Reading inconsistent auf "Yes" springt

Grüße Dave

[marvin78]

Du kannst aber mit einem notify darauf reagieren und die set force* Befehle benutzen. Am besten nutzt du 2 Sensoren, einen für oben und einen für unten.