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

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

Vorheriges Thema - Nächstes Thema

hubi3922

Hallo cs-online,
danke für deine Antwort; ich werde es mit CNC-Shield versuchen.

Ich habe einen etwas leistungsstärkeren Steppmotor mit Getriebe geplant. Das wäre von der Leistung dann auch ausreichend.
An einen 40er oder 60er Rolladenmotor habe ich auch schon gedacht; die Markise ist etwas älter. Rolladenmoter passt da nicht rein. 

Gruß
RaspberryPi 2b;FHEM 5.7; Busware CUL-USB-V3; HM-Rolladenaktoren; HM-Drehgriffkontakt; HM-Bewegungsmelder; zukünftig auch im selbstbau

cs-online

...bin gespannt, wie es wird ! Lass uns mal dran teilhaben, wenn es soweit ist...
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

Raspi-lars

Hallo in die Runde,

ich verwende nun auch das Modul mit einem HM-LC-Sw1-Pl-CT und als Sensor für das Geschlossene Tor den HM-Sec-SCo und finde es auch sehr gut.
Ich habe nur eine Verständnisfrage:
Wenn ich das Tor über einen schon vorhandenen Taster schalte, wird das Modul auf Inkosistent gestellt. Sollte dann nicht der Sensor den Tatsächlichen zustand als forceClose oder forceOpen korrigieren?
Ich habe meinen Sensor als closeSensorDevice und openSensorDevice jeweils mit closed event und open event angelegt. Ist das so gedacht?
Ich habe keine weitere Beschreibung der Attribute gefunden.

Gruß
Lars

steffen83

Hallo Lars, habe die gleichen Probleme. Das läuft zwar alles sauber auch wenn eine Fehlermeldung kommt.
Aber sonst tut sich hier leider nichts. Script und Idee wären und sind aber topp
Schade

Gesendet von meinem MI 8 mit Tapatalk

Raspberry Pi 3 (Noobs, aktuelle Fhem und Pilight) | FHEMduino | HM-OCCU-SDK | HM-Sec-SCo | HM-Sec-SD-2 | HM-CC-RT-DN | HM-LC-Bl1PBU-FM

cs-online

...meine Vermutung ist, dass mit dem Modul nicht automatisch die Force Open/Closed gesetzt werden, so weit war der Schöpfer des Moduls wohl noch nicht und er hat sich leider schon lange nicht mehr dazu geäußert... Also wahrscheinlich muss man das selber per Notify setzen

Grüße

Christian
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

Wzut

Zitat von: cs-online am 14 Dezember 2018, 07:38:46
und er hat sich leider schon lange nicht mehr dazu geäußert

Letzter Besuch: 30 Juli 2018, 13:17:39
und was machen wir ? Ich hatte ja auf der Seite vorher angeboten Verbesserungsvorschläge zu machen, leider halt auch ohne Reaktion :(
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

steffen83

Ja schade, da kannte ich das Modul noch nicht  :-)

Aber mal sehen, soweit läuft es ja bei mir und kann mich nicht beklagen. Die "eine" Fehlermeldung kann man mit einem Notify umgehen.
Raspberry Pi 3 (Noobs, aktuelle Fhem und Pilight) | FHEMduino | HM-OCCU-SDK | HM-Sec-SCo | HM-Sec-SD-2 | HM-CC-RT-DN | HM-LC-Bl1PBU-FM


Damian

Zitat von: travelling-man am 14 Dezember 2018, 16:30:42
Moin,

hier gibt es schon ein sehr gutes DOIF Beispiel: https://forum.fhem.de/index.php/topic,84969.msg822560.html#msg822560

VG

ja, es war ein Demonstrationsbeispiel der neuen Möglichkeiten im DOIF. Es lässt sich sicherlich gut auf eigene Bedürfnisse anpassen bzw. erweitern und das Gute ist: der Autor ist noch aktiv ;)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Raspi-lars

Ich hab das jetzt mit doif und forceclose/forceopen gelöst.
Funktioniert einwandfrei!
Dank für die Hilfe.

hf007

Habe auch das Problem mit dem inconsistent.
Hast Du es komplett auf eine DoIf Lösung umgestellt?

Mihca

#101
Also hier eine mE ziemlich einfache Lösung mit Fhem Bordmitteln. Funktioniert bei mir prima. Man kann allerdings keine bestimmten Öffnungen anfahren.

Im Perl-Code ist kommentiert, welche Devices anzulegen sind.

#
##################################################################################################################
#
sub myGarage
#
# Fährt Garagentor auf/zu
#
# Erforderliche Devices:
#
# Garagentor: zB Homematic Funk-Tür-/Fensterkontakt, optisch HM-Sec-SCo
#
# Garage_auf_zu: define Garage_auf_zu dummy
# attr Garage_auf_zu webCmd auf:zu
#
# Garagentor_auf_zu_DoIf: define Garagentor_auf_zu_DoIf DOIF (([Garage_auf_zu] eq "auf") or ([Garage_auf_zu] eq "zu")) ({myGarage})
# attr Garagentor_auf_zu_DoIf do always
#
{
my $StatusIst; my $StatusSoll;

if (Value("Garagentor") eq "open") {$StatusIst = "auf"} else  {$StatusIst = "zu"};
$StatusSoll = Value("Garage_auf_zu");
#
if ($StatusSoll ne $StatusIst)

{
{fhem("set 4CH_Switch_E_Keller POWER4 on")}; # Kurzer Schaltimpuls von potentialfreiem Schalter an Garagentor Tastereingang
{Log 3, "Garagentor ist $StatusIst und fährt jetzt $StatusSoll"};
{if(!defined($defs{'Garagentor_next'})) {fhem("define Garagentor_next at +00:00:20 {myGarage}")}} # Zu-/Auffahren des Tors dauert ca. 20 Sekunden
};
#
##########################################################################################################################
}
#
# Ende
#
Viele Grüße
Achim
__________
Kein Fehler ist so dumm, dass man ihn nicht machen könnte.
Raspi Ubuntu 22.04 Perl 5.34, Rollo-, Sonnen-, Licht-, Heizungs-, Poolsteuerung, Energiebilanzen -- HomeMatic, FS20, ESP/Tasmota/ESPEasy, CUL868v3 USB, MAX! Cube LAN mit CUL-Firmware HomeMatic

Beetle2003

Hallo,

ich teste das Modul derzeit. Funktioniert zuverlässig.

Nun stellt sich mir die Frage:
Kann eine Lüftungsposition angefahren werden? Denke da an eine Funktion wie bei den Rolloaktoren bei denen ein Prozentwert angegeben werden kann.

Danke


Hellspawn

Zitat von: Raspi-lars am 19 Dezember 2018, 11:09:52
Ich hab das jetzt mit doif und forceclose/forceopen gelöst.
Funktioniert einwandfrei!

Könntest Du das komplette DoIf mal zur Verfügung stellen? Wäre glaube ich für alle sehr hilfreich  :D

Dankeschön
Carsten

Niko1987

Zitat von: hf007 am 04 März 2019, 22:45:41
Habe auch das Problem mit dem inconsistent.
Hast Du es komplett auf eine DoIf Lösung umgestellt?

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

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.
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.
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.

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.

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.
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. :o

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