Hi,
Aktuelle Version von Github installieren:
update all https://raw.githubusercontent.com/farion/fhem-garagedoorsinglebutton/master/controls_garagedoorsinglebutton.txtda mir die existierenden Garagenlösungen nicht zusagten habe ich ein entsprechendes Modul implementiert.
Ich habe eine recht betagte aber noch wunderbar funktionierende Garagenmotorsteuerung. Man bedient sie mit einem Knopf.
- Ist das Tor unten, geht es hoch.
- Ist das Tor oben, geht es runter.
- Ist das Tor in Bewegung stoppt es.
- Ist das Tor gestoppt bewegt es sich in die andere Richtung wie vor dem Stop
Denke so sind recht viele Steuerungen aufgebaut. Insbesondere die Älteren.
Meine zusätzliche Hardware ist ein HM-LC-SW1-BA-PCB mit Relais zum potentialfreien Schalten und einem HM-SEC-SC-2 um zu messen wann das Tor zu ist.
Das Modul definiert ein zusätzliches Gerät welches die nötigen Geräte bündelt und entsprechende Aktionen ermöglicht. Es basiert darauf, dass man die Zeiten zum Hoch/Runterfahren per Attribut setzt. Das "Drücken" des Steuerknopfes wird gequeued, damit wird verhindert, dass ungeduldiges öfteres Drücken etwas ausmacht.
- Absolute Befehle für Schliessen und Öffnen, egal in welchem Status sich das Tor befindet
- Readings für Toröffnung in %, Nötige Zeit zum Hoch/Runterfahren, Statistiken über Knopfdrücker und Queue
- Watchdog-Funktion: Wenn das Tor länger offen ist wird ein FHEM-Befehl getriggert (Bei mir z.B. ne Jabber-Nachricht)
Ich werde wohl auf Dauer noch einen zweiten HM-SEC-SC-2 einbauen um den Offen-Zustand eindeutig zu haben. Aber so funktioniert es schon erstaunlich gut. Man kann das Tor auf halben Weg umlenken etc.V0.0.6 erlaubt einen zweiten Sensor.
Einschränkung: Aktuell geht das Modul davon aus, dass das Tor zu Beginn unten ist. Ein "Erkennen" bei Fhem-Start habe ich mir gespart. Das wäre ziemlich nervig wenn das Tor dann erstmal ne Runde durch die Gegend fährt.
Aktuell wird auch noch ein notify für den Sensor automatisch angelegt um den Close-Status zu injekten. Das muss ich noch besser machen, aber es funktioniert.Entfernt seit V0.0.2
Ich hoffe es hilft Jemanden. Vllt. hat auch jemand noch Ideen oder Vorschläge.
Gruss Frieder
PS: Habe noch das Zustandsdiagramm im Anhang. Einfach weil es so schön ist :D. Ausserdem ein Bild der Steuerschaltung und ein Screenshot aus FHEM.
[edit] added version 0.0.2
- Added buttonTriggerCommand
- Added closeSensorDeviceEvent
- Make use of NotifyFn to get events from close device (thx to marvin78)
[edit] added version 0.0.3
- Fixed some bugs (thx to hartenthaler)
[edit] added version 0.0.6 (not well tested)
- Added openSensorDevice and openSensorDeviceEvent for second sensor that shows if door is open.
- Fixed some bugs
ACHTUNG: Beim Installieren der versionierten Module bitte die Datei vorher in 98_GarageDoorSingleButton.pm umbenennen.
Hallo farion,
tolle sache, ich kan's gebrauchen.
vermutlich funktion ähnlich wie das ROLLO Modul mit Positionen wie 10, 20, ... 90, 100, und mit Icons für Position.
Ich werde es bei mir einbinden und Testen.
Danke, Gerhard
Klingt interessant - aber verstehe ich das richtig: du benutzt einen Rauchmelder als Sensor ob das Garagentor zu ist? Zumindest finde ich nur Rauchmelder, wenn ich nach HM-SEC-SD-2 suche.
@Regengott
Ja, man muss auch immer ne Kerze anzünden :D.
Nein im Ernst war ein Typo ... ich meinte natürlich: HM-SEC-SC-2. Habe es im Eingangspost korrigiert. Danke!!
@Gerhard
Nicht ganz. Aktuell gibt es mehr oder weniger nur die Kommandos "open","close". Also "fahre auf 20%" kannst du nicht sagen. Die Readings zeigen aber eine geschätzte Position an. Könnte man aber noch einbauen ... wenn der Sohnemann mit dem Bobycar raus will braucht man das Tor ja nicht ganz hoch fahren :).
Ich teste es jetzt seit 3 Tagen und es funktioniert schon recht gut. Ab und zu kommt er noch mit dem aktuellen Zustand durcheinander. Das muss ich noch robuster machen. Und den zweiten Fensterkontakt für "offen" ... das bringt denke ich viel.
Icons gibt es auch noch keine. Ich verwende die Table-UI und FHEMWEB nur zum Entwickeln. Also da ist noch Platz nach oben :). Ich freue mich aber natürlich über jedes Feedback.
Gruss Frieder
Hi farion,
vll. ein paar Anregungen von hier:
http://forum.fhem.de/index.php/topic,47202.0.html (http://forum.fhem.de/index.php/topic,47202.0.html)
oder
http://www.fhemwiki.de/wiki/ROLLO
ist ähnlich wie dein Modul, fährt nach Zeit, mit Pos. angaben und Icons für die Position,
und jetzt nur mit Ein-Knopf-Steurerung sowie mit Angabe von zwei oder 3? Eingänge für Closed.mid,open.
Gerhard
P.S.
hier der define :
define myRollo_01 ROLLO
attr myRollo_01 automatic-enabled on
attr myRollo_01 devStateIcon offen:fts_shutter_10:geschlossen geschlossen:fts_shutter_100:offen schlitz:fts_shutter_80:geschlossen drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop position-100:fts_shutter_100:offen position-90:fts_shutter_80:geschlossen position-80:fts_shutter_80:geschlossen position-70:fts_shutter_70:geschlossen position-60:fts_shutter_60:geschlossen position-50:fts_shutter_50:geschlossen position-40:fts_shutter_40:offen position-30:fts_shutter_30:offen position-20:fts_shutter_20:offen position-10:fts_shutter_10:offen position-0:fts_shutter_10:geschlossen
attr myRollo_01 drive-down-time-to-100 20
attr myRollo_01 drive-up-time-to-100 20
attr myRollo_01 funktionsweise Typ4
attr myRollo_01 kanal1 EL_BT_Up
attr myRollo_01 kanal2 EL_BT_Down
attr myRollo_01 kanal3 EL_BT_Stop
attr myRollo_01 room ROLLOK
attr myRollo_01 webCmd offen:geschlossen:schlitz:position
Hallo Gerhard,
ich bastel auch gerade an einer Garagentor Steuerung und würde ganz gern das Rollo modul dafür verwenden wie von dir vorgeschlagen.
Was ich daran allerdings vermisse, und das ist wohl der Clou an diesem Garagentor Modul, ist die Einbindung des Sensors der mir ein definiertes Signal für Garage-zu gibt.
Wenn das sich noch in das Rollo Modul integrieren liesse, dann wär es perfekt.
Grüße, Till
Hi Skywalker,
das Modul hat keine Eingänge sondern nur Ausgänge (auf, ab, stopp), und fährt nach Zeit wobei der Befehl Stopp nach Ablauf der Zeit
gesetzt wird, und setzt voraus das der Antrieb auch dort steht wo die Position berechnet wurde.
Eine Überprüfung der Position kann man out of the box machen.
Gerhard
Da kann ich helfen. Hier gibt es für sehr wenig Geld einen mechanischen Neigungsschalter.
http://www.conrad.biz/ce/de/product/185271/Neigungssensor-Print-gewinkelt-1-Schliesser-1-Oeffner?ref=searchDetail
Zwei Stück davon im 90°-Winkel zueinander eingebaut liefern ein eindeutiges Signal für "Tor geschlossen" oder "Tor geöffnet".
Ich betreibe einen sehr komfortablen Garagentoröffner: Von außen per iButton-Auflage mit Identifikation der öffnenden Person, oder per HomeMatic-Fernbedienung. Oder per FHEM, natürlich.
LG
pah
Hallo,
ich habe mir bisher mit dem Sündhaft-Teuren Homematic Neigungsschalter beholfen. Der sendet mir schon ein sehr zuverlässiges Signal ob offen oder zu.
Ich fände es halt cool man würde das ins Rollo Modul so integrieren können das zu nicht nur auf der Zeitkomponente basiert, sondern tatsächlich den Neigungsschalter abfragt ob wirklich zu ist.
Davon abgesehen interessiere ich mich sehr für die weitere Umsetzung des komfortablen Garagentoröffners mit iButton.
lg, Till
Steht hier drin.
http://www.amazon.de/Smart-Home-Hacks-Hausautomatisierung-selber/dp/3960090129
LG
pah
Ist ja schon lange geordert. Dauert halt noch so lange
Hallo Frieder,
vielen Dank für das neue Modul,
ich habe genau die gleichen Probleme mit dem Antrieb von meinem Garagentor.
Ich habe Dein Modul mit eingebaut, sowie ein weiteres notify wenn offen mit gesetzt,
da meine Frau immer noch den alten Hand-Sender benutzt .....
Funktioniert perfekt !
Danke und Gruß
Markus
Hallo Frieder,
ich habe mich jetzt doch mal mit deinem Modul auseinander gesetzt und krieg es nicht zum laufen.
Magst du mir ein paar Tips geben?
Beim Server Start wirft das Modul folgende Meldungen aus:
Use of uninitialized value in numeric eq (==) at ./FHEM/98_GarageDoorSingleButton.pm line 212, <$fh> line 112.
Use of uninitialized value in numeric eq (==) at ./FHEM/98_GarageDoorSingleButton.pm line 212, <$fh> line 112.
Use of uninitialized value in numeric eq (==) at ./FHEM/98_GarageDoorSingleButton.pm line 147, <$fh> line 112.
Use of uninitialized value in numeric eq (==) at ./FHEM/98_GarageDoorSingleButton.pm line 150, <$fh> line 112.
Use of uninitialized value in sprintf at ./FHEM/98_GarageDoorSingleButton.pm line 166, <$fh> line 112.
Use of uninitialized value in sprintf at ./FHEM/98_GarageDoorSingleButton.pm line 166, <$fh> line 112.
Use of uninitialized value in sprintf at ./FHEM/98_GarageDoorSingleButton.pm line 167, <$fh> line 112.
Use of uninitialized value in sprintf at ./FHEM/98_GarageDoorSingleButton.pm line 167, <$fh> line 112.
Use of uninitialized value in division (/) at ./FHEM/98_GarageDoorSingleButton.pm line 168, <$fh> line 112.
2016.04.07 12:43:56 3: [GarageDoorSingleButton] Change state: Closed
2016.04.07 12:43:56 3: get Sensor_Tor_Garage param state : undefined
Argument "close" isn't numeric in numeric ne (!=) at ./FHEM/98_GarageDoorSingleButton.pm line 273, <$fh> line 112.
Argument "undefined" isn't numeric in numeric ne (!=) at ./FHEM/98_GarageDoorSingleButton.pm line 273, <$fh> line 112.
Wenn ich dann "set Tor_Garage open" absetze, dann crashed das modul mit folgender Fehlermeldung:
Undefined subroutine &main::BlockingCall called at ./FHEM/98_GarageDoorSingleButton.pm line 380
danke und Gruß, Till
Hallo
ich habe das Modul jetzt seit gut einer Woche am laufen. Geht bisher einwandfrei. Sensoren, Schalter und Einrichtung wie oben beschrieben.
Gestern habe ich meinen Raspi mit dem Fhem Server neu starten müssen. Bei Start von Fhem bekam ich folgende Fehlermeldung:
2016.05.12 21:56:48 2: Messages collected while initializing FHEM: configfile: Garage_closeSensorNotify already defined, delete it first
Der Notify wird vom Modul angelegt. Da er schon in der Fhem.cfg steht und dies vom Modul nicht abgefragt wird, kommt diese Fehlermeldung.
Könntest Du das Modul dahingehend abändern?
Könnte man vielleicht noch einbauen, das es nur eine bestimmte Anzahl von Warnmeldungen sendet wenn das Tor noch offen ist?
Ansonsten ist das einfach nur klasse :)
Danke
Danke für das Modul. Habe schon vor einige Monaten genau die gleiche HM-Konfiguration verbaut und das notify bislang mit DOIF gelöst. Mit Deinem Modul ist das natürlich komfortabler. Hat auf Anhieb funktioniert.
Bei meinem Marantec 370 Garagenöffner erübrigt sich übrigens das Relais. Kann mit Open-Drain direkt gesteuert werden.
Auch die Spannungsversorgung kann von der Marantec bezogen werden.
Super Modul! Allerdings setze ich einen anderen Aktor ein: HM-LC-Sw1-Pl-CT-R1.
Und da passt die folgende Zeile im Modul nicht:
fhem("set ".$hash->{BUTTON_DEVICE}." on-for-timer 1");
Ich brauche stattdessen:
fhem("set ".$hash->{BUTTON_DEVICE}." press");
Ich würde mir daher ein Attribut im Modul wünschen, das man mit "on-for-timer 1" oder eben mit "press" belegen kann.
PS: als Sensor verwende ich den Homematic-Neigungssensor HM-SEC-TIS.
Zitat von: mbrak am 13 Mai 2016, 10:13:30
Hallo
ich habe das Modul jetzt seit gut einer Woche am laufen. Geht bisher einwandfrei. Sensoren, Schalter und Einrichtung wie oben beschrieben.
Gestern habe ich meinen Raspi mit dem Fhem Server neu starten müssen. Bei Start von Fhem bekam ich folgende Fehlermeldung:
2016.05.12 21:56:48 2: Messages collected while initializing FHEM: configfile: Garage_closeSensorNotify already defined, delete it first
Der Notify wird vom Modul angelegt. Da er schon in der Fhem.cfg steht und dies vom Modul nicht abgefragt wird, kommt diese Fehlermeldung.
Könntest Du das Modul dahingehend abändern?
Könnte man vielleicht noch einbauen, das es nur eine bestimmte Anzahl von Warnmeldungen sendet wenn das Tor noch offen ist?
Ansonsten ist das einfach nur klasse :)
Danke
Habe das gleiche Problem, hat das jemand gelöst?
@: hyper2910 & hartenthaler
ich benutze auch den HM-LC-Sw1-Pl-CT-R1 und den Neigungssensor von homematic.
Ich habe es über ein dummy gelöst, was ich dann dem Modul übergebe:
define GarazsAjto CUL_HM 3BD516
attr GarazsAjto IODev myHMLAN
attr GarazsAjto autoReadReg 4_reqStatus
attr GarazsAjto expert 2_full
attr GarazsAjto firmware 2.5
attr GarazsAjto model HM-LC-Sw1-Pl-CT-R1
attr GarazsAjto peerIDs 00000000,
attr GarazsAjto room Unsorted
attr GarazsAjto serialNr MEQ0351397
attr GarazsAjto subType switch
attr GarazsAjto webCmd statusRequest:toggle:on:off
define GarazsNyto dummy
attr GarazsNyto eventMap toggle
attr GarazsNyto group Garasz
attr GarazsNyto icon refresh
attr GarazsNyto room TECHNIKA
attr GarazsNyto webCmd toggle
#Garagentaster 1 Sekunde schalten
define n_GarazsNytot notify GarazsNyto set GarazsAjto on-for-timer 1
define myGarageDoor GarageDoorSingleButton GarazsNyto closeSensrGarage
attr myGarageDoor devStateIcon Open:fts_garage_door_10 Closed:fts_garage_door_100 DrivingUp:control_arrow_upward@red DrivingDown:control_arrow_downward@red StoppedOnWayUp:fts_garage_door_50@red StoppedOnWayDown:fts_garage_door_50@red
attr myGarageDoor group Garasz
attr myGarageDoor icon fts_garage
attr myGarageDoor room TECHNIKA
attr myGarageDoor totalTimeDown 21.5
attr myGarageDoor totalTimeUp 14.5
attr myGarageDoor webCmd open:close:stop
define myGarageDoor_closeSensorNotify notify closeSensrGarage:closed set myGarageDoor forceClose
define closeSensrGarage CUL_HM 2A8619
attr closeSensrGarage IODev myHMLAN
attr closeSensrGarage actCycle 028:00
attr closeSensrGarage actStatus alive
attr closeSensrGarage autoReadReg 4_reqStatus
attr closeSensrGarage expert 2_full
attr closeSensrGarage firmware 1.5
attr closeSensrGarage group Garasz
attr closeSensrGarage model HM-SEC-TIS
attr closeSensrGarage peerIDs 00000000,
attr closeSensrGarage room TECHNIKA
attr closeSensrGarage serialNr LEQ0428042
attr closeSensrGarage subType threeStateSensor
Gerhard
Zitat von: Gerhard am 26 Juli 2016, 10:40:26
@: hyper2910 & hartenthaler
ich benutze auch den HM-LC-Sw1-Pl-CT-R1 und den Neigungssensor von homematic.
Ich habe es über ein dummy gelöst, was ich dann dem Modul übergebe:
define GarazsAjto CUL_HM 3BD516
attr GarazsAjto IODev myHMLAN
attr GarazsAjto autoReadReg 4_reqStatus
attr GarazsAjto expert 2_full
attr GarazsAjto firmware 2.5
attr GarazsAjto model HM-LC-Sw1-Pl-CT-R1
attr GarazsAjto peerIDs 00000000,
attr GarazsAjto room Unsorted
attr GarazsAjto serialNr MEQ0351397
attr GarazsAjto subType switch
attr GarazsAjto webCmd statusRequest:toggle:on:off
define GarazsNyto dummy
attr GarazsNyto eventMap toggle
attr GarazsNyto group Garasz
attr GarazsNyto icon refresh
attr GarazsNyto room TECHNIKA
attr GarazsNyto webCmd toggle
#Garagentaster 1 Sekunde schalten
define n_GarazsNytot notify GarazsNyto set GarazsAjto on-for-timer 1
define myGarageDoor GarageDoorSingleButton GarazsNyto closeSensrGarage
attr myGarageDoor devStateIcon Open:fts_garage_door_10 Closed:fts_garage_door_100 DrivingUp:control_arrow_upward@red DrivingDown:control_arrow_downward@red StoppedOnWayUp:fts_garage_door_50@red StoppedOnWayDown:fts_garage_door_50@red
attr myGarageDoor group Garasz
attr myGarageDoor icon fts_garage
attr myGarageDoor room TECHNIKA
attr myGarageDoor totalTimeDown 21.5
attr myGarageDoor totalTimeUp 14.5
attr myGarageDoor webCmd open:close:stop
define myGarageDoor_closeSensorNotify notify closeSensrGarage:closed set myGarageDoor forceClose
define closeSensrGarage CUL_HM 2A8619
attr closeSensrGarage IODev myHMLAN
attr closeSensrGarage actCycle 028:00
attr closeSensrGarage actStatus alive
attr closeSensrGarage autoReadReg 4_reqStatus
attr closeSensrGarage expert 2_full
attr closeSensrGarage firmware 1.5
attr closeSensrGarage group Garasz
attr closeSensrGarage model HM-SEC-TIS
attr closeSensrGarage peerIDs 00000000,
attr closeSensrGarage room TECHNIKA
attr closeSensrGarage serialNr LEQ0428042
attr closeSensrGarage subType threeStateSensor
Gerhard
Verstehe nicht wie die Meldung dadurch vermieden wird!
@hyper2910
im Modul 98_GarageDoorSingleButton.pm Zeile 115 auskommentieren, aber den notify in fhem.cfg lassen.
sub GarageDoorSingleButton_Define($$) {
my ( $hash, $def ) = @_;
my @a = split( "[ \t]+", $def, 5 );
return "Usage: define <name> GarageDoorSingleButton <buttonDevice> <closeSensorDevice>"
if ( int(@a) != 4 );
$hash->{NAME} = $a[0];
$hash->{BUTTON_DEVICE} = $a[2];
$hash->{CLOSE_SENSOR_DEVICE} = $a[3];
my $name = $hash->{NAME};
# fhem("define ".$name."_closeSensorNotify notify ".$hash->{CLOSE_SENSOR_DEVICE}.":closed set ".$name." forceClose");
$hash->{helper}{RUNNING_TRIGGER_COUNT} = 0;
Gerhard
Besser wäre, defmod zu verwenden. Dann kann mit dem notify passieren, was will..
Oder das Modul verwendet NotifyFn, dann ist das notify überflüssig.
Ich wollte mir das Modul immer einmal ansehen und für eine zwei Sensor Lösung für mich umschreiben. Leider bin ich noch nicht dazu gekommen und werde es wohl auch nicht so schnell.
vielleicht schieße ich mit meiner Frage knapp an diesem Thread vorbei, aber ich wüßte nicht wo ich das sonst platzieren könnte.
Wenn ich es auf dem Bild von farion richtig erkenne, dienen Batterien für die Stromversorgung. Die beschriebenen Garagentorantriebe liefern aber auch Strom. (z.B. für ein Taster zum Öffnen und Schließen der Garage) Ich meine 24V wären üblich. Könnte man diese Spannung nicht heruntertransformieren um das Relais zu betreiben und damit auf die Batterien zu verzichten? Ich kenne mich Strom nicht besonders gut aus. Aber die Spannung von 24 V auf die 9-15 V für das Relais zu reduzieren, sollte nicht so kompliziert sein, oder?
Zitat von: jorge am 30 Mai 2016, 17:14:22
Bei meinem Marantec 370 Garagenöffner erübrigt sich übrigens das Relais. Kann mit Open-Drain direkt gesteuert werden.
Auch die Spannungsversorgung kann von der Marantec bezogen werden.
Kannst Du hierzu mehr informationen geben? Ich bekomme ebenfalls diesen Antrieb. Und mit dem Impulsschalter/EinKnopf bin ich nur teilgluecklich...
Zitat von: Alcamar am 01 August 2016, 08:57:16
vielleicht schieße ich mit meiner Frage knapp an diesem Thread vorbei, aber ich wüßte nicht wo ich das sonst platzieren könnte.
Wenn ich es auf dem Bild von farion richtig erkenne, dienen Batterien für die Stromversorgung. Die beschriebenen Garagentorantriebe liefern aber auch Strom. (z.B. für ein Taster zum Öffnen und Schließen der Garage) Ich meine 24V wären üblich. Könnte man diese Spannung nicht heruntertransformieren um das Relais zu betreiben und damit auf die Batterien zu verzichten? Ich kenne mich Strom nicht besonders gut aus. Aber die Spannung von 24 V auf die 9-15 V für das Relais zu reduzieren, sollte nicht so kompliziert sein, oder?
Yep. Das geht. Ich mache das über eine z-Diode. Reicht vollkommen und funktioniert prima. Irgendwo hier im Forum hat jemand dazu auch mal ein Schaltbild veröffentlicht wenn ich mich recht erinnere.
Gesendet von iPad mit Tapatalk
Hallo und Guten Tag
Ich habe gerade versucht das Modul für meine Zwecke zu nutzen, da ich es ganz toll finde ::)
ich komme jedoch jetzt irgendwie nicht weiter, vielleicht kann mir jemand meinen Fehler zeigen
meine Definitiondefine GartentorSylvia GarageDoorSingleButton TorSylvia Hoftor
hierbei ist TorSylvia ein Dummy,welcher einen HM-LC-SW4-WM schaltet, da ich zwei Button benötige
(ich habe das ROLLO Modul nicht verwendet, da ich denTürkontakt nicht über ein DOIF oder notify einbinden wollte)
die Dummy Schaltung ohne Garagentormodul funktioniert wunderbar - jedoch über das Modul erhalte ich nur ein on-for-timer vom dummy zurück,jedoch bekomme ich nicht hin,das der dummy trotz notify diesen Befehl an den HM-LC-SW4-WM weitergibt ???
oder gibt es gar die Möglichkeit 2 Button_Device einzubauen und zwei CLOSE_SENSOR_DEVICE ?
lg tagedieb
Zitat von: micomat am 02 August 2016, 06:53:43
Kannst Du hierzu mehr informationen geben? Ich bekomme ebenfalls diesen Antrieb. Und mit dem Impulsschalter/EinKnopf bin ich nur teilgluecklich...
Ich glaube, dann macht Dich meine Lösung auch nicht glücklich: Habe nur einen Ersatz für die Ein-Knopf-Regelung, aber gesteuert über fhem.
Habe den HM-LC-SW4-BA-PCB in Betrieb, 24 V Stromversorgung der Marantec heruntergeregelt auf 12 V, den open-Drain parallel zum Taster geschaltet (ohne Relais!).
Außerdem stelle ich die Torneigung noch über einen HM-Neigungssensor fest und melde den Zustand im 10-Minuten Abstand via DOIF über Lautsprecher im Haus: So wird das Schließen nicht vergessen. Funktioniert bis jetzt gut mit hohem WAF! Eine Feststellung von Teilöffnungszuständen ist so natürlich nicht möglich, vermisse ich aber auch nicht.
LG
Jorge
Zitat von: Alcamar am 01 August 2016, 08:57:16
vielleicht schieße ich mit meiner Frage knapp an diesem Thread vorbei, aber ich wüßte nicht wo ich das sonst platzieren könnte.
Wenn ich es auf dem Bild von farion richtig erkenne, dienen Batterien für die Stromversorgung. Die beschriebenen Garagentorantriebe liefern aber auch Strom. (z.B. für ein Taster zum Öffnen und Schließen der Garage) Ich meine 24V wären üblich. Könnte man diese Spannung nicht heruntertransformieren um das Relais zu betreiben und damit auf die Batterien zu verzichten? Ich kenne mich Strom nicht besonders gut aus. Aber die Spannung von 24 V auf die 9-15 V für das Relais zu reduzieren, sollte nicht so kompliziert sein, oder?
Ja, prinzipiell sollte das gehen. Mein Tor ist leider älter als ich und die Platine sieht abenteuerlich aus ... müsste so um 1975 gebaut worden sein. Ich habe bissel rumgemessen und ich würde 22,5V (glaube das wars) bekommen. Steht auch noch auf meiner Liste. Aktuell hängt das Ding ja auch noch am Originalschalter an der Wand und dort gibt es nur das Schaltkabel. Könnte man besser in das grosse Gehäuse einbauen und dann natürlich auch dort den Strom abgreifen.
Habe ein Update in den ersten Post geladen.
@marvin78: Danke für den Hinweis mit NotifyFn.
@hyper2910 + @Gerhard: Damit löst sich euer Problem.
@hartenthaler: Der Befehl zum Triggern kann nun frei gewählt werden (der Name des close events auch)
@tagedieb: Du hast einen Knopf für hoch und einen für runter? Das macht die Situation eigentlich einfacher. Prinzipiell löst dieses Modul ja genau das Problem, dass man keine zwei Buttons hat. Aber grundsätzlich sollte das schon gehen. Wenn ich Muse habe schaue ich mal ob man das einbauen kann.
Zwei close devices ... meinst du ein open und ein close device? Also so dass der Status oben und unten jeweils per Sensor definiert wird? Das steht bei mir schon auf der Liste. Das hat den Vorteil, dass man nicht per Timer erkennen muss ob das Tor oben ist. Das ist leider nicht immer ganz genau, kostet aber einen Sensor mehr. Ich werde das aber in Zukunft so machen, das erscheint mir lohnenswert.
Fein. Klappt soweit. Allerdings habe ich diverse Fehlermeldungen im Logfile
2016.12.01 18:12:30 1: PERL WARNING: Use of uninitialized value in sprintf at ./FHEM/98_GarageDoorSingleButton.pm line 204, <$fh> line 566.
2016.12.01 18:12:30 1: PERL WARNING: Use of uninitialized value in sprintf at ./FHEM/98_GarageDoorSingleButton.pm line 205, <$fh> line 566.
2016.12.01 18:12:30 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/98_GarageDoorSingleButton.pm line 206, <$fh> line 566.
2016.12.01 18:12:30 3: [GarageDoorSingleButton] Change state: Closed
2016.12.01 18:12:30 3: get Garagentorsensor param state : undefined
2016.12.01 18:12:30 1: PERL WARNING: Argument "close" isn't numeric in numeric ne (!=) at ./FHEM/98_GarageDoorSingleButton.pm line 311, <$fh> line 566.
2016.12.01 18:12:30 1: PERL WARNING: Argument "undefined" isn't numeric in numeric ne (!=) at ./FHEM/98_GarageDoorSingleButton.pm line 311, <$fh> line 566.
Hier die raw-Definition meiner Devices
defmod Garage GarageDoorSingleButton Garagentorsteuerung Garagentorsensor
attr Garage buttonTriggerCommand press
attr Garage devStateIcon offen:fts_garage_door_10@red geschlossen:fts_garage_door_100@green
attr Garage eventMap Open:offen Closed:geschlossen
attr Garage group Tür
attr Garage icon fts_garage
attr Garage room 42_Garage,Tür,Sicherheit
attr Garage totalTimeDown 12
attr Garage totalTimeUp 11
defmod Garagentorsteuerung CUL_HM 34xxxx
attr Garagentorsteuerung IODev HMLAN1
attr Garagentorsteuerung IOgrp VCCU:HMLAN1
attr Garagentorsteuerung autoReadReg 4_reqStatus
attr Garagentorsteuerung eventMap press:on
attr Garagentorsteuerung expert 2_raw
attr Garagentorsteuerung firmware 2.5
attr Garagentorsteuerung group Tür
attr Garagentorsteuerung model HM-LC-Sw1-Pl-CT-R1
attr Garagentorsteuerung peerIDs 00000000,34D9xxxx,
attr Garagentorsteuerung room 42_Garage,Homematic,Tür
attr Garagentorsteuerung serialNr MEQ184xxxx
attr Garagentorsteuerung subType switch
attr Garagentorsteuerung webCmd press
defmod Garagentorsensor CUL_HM 3Axxxx
attr Garagentorsensor userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Tür winOpenName
attr Garagentorsensor IODev HMLAN1
attr Garagentorsensor IOgrp VCCU:HMLAN1
attr Garagentorsensor actCycle 028:00
attr Garagentorsensor actStatus unknown
attr Garagentorsensor autoReadReg 4_reqStatus
attr Garagentorsensor devStateIcon offen:fts_garage_door_10@red geschlossen:fts_garage_door_100@green
attr Garagentorsensor event-on-change-reading state
attr Garagentorsensor eventMap open:offen closed:geschlossen
attr Garagentorsensor expert 2_raw
attr Garagentorsensor firmware 1.5
attr Garagentorsensor fp_ae74_eg_nord 803,1316,1,Garage,
attr Garagentorsensor group Tür
attr Garagentorsensor icon fts_garage
attr Garagentorsensor model HM-SEC-TIS
attr Garagentorsensor room Tür,42_Garage,Homematic,Sicherheit
attr Garagentorsensor serialNr MEQ047xxxx
attr Garagentorsensor subType threeStateSensor
attr Garagentorsensor winOpenMaxTrigger 10
attr Garagentorsensor winOpenName Garagentor
attr Garagentorsensor winOpenTimer 00:00:30
attr Garagentorsensor winOpenTimer2 00:05:00
attr Garagentorsensor winOpenType Türe
Ja ... Perl ist nicht grade meine Leib-und-Magen-Sprache.
Danke fürs Finden, habe ein Update gemacht. Evtl. hast du da einen Bug gefunden, den meine Frau öfter mal triggert. Damit hätte sich dann der WAF enorm erhöht.
Aber warum hatte ich die Meldungen nicht in meinem Log ... seltsam.
Gruss Frieder
Hallo zusammen,
wäre es auch möglich, den Marantec Digital 343 Universalfunkempfänger mit einem CC1101 über dieses Modul zu steuern?
http://www.torado.de/marantec-digital-343-universal-empfanger-2-kanal-868-mhz.html (http://www.torado.de/marantec-digital-343-universal-empfanger-2-kanal-868-mhz.html)
Der funkt auch auf 868 MHz. Ich überlege gerade, mir diesen Funkempfänger zu kaufen, bin mir aber nicht ganz sicher, ob der mit FHEM zusammen funktioniert.
Wie ich gelesen haben, kann wohl auch der HM-LC-SW4-BA-PCB verwendet werden. Aber ich bin absolut kein Löt-Experte und würde daher lieber den Adapter des Herstellers verwenden.
Danke im Voraus!
LG
Hi,
dieses Modul ist erstmal nur ein Logik-Modul. Sprich, sofern dein Device mit FHEM prinzipiell läuft solle es keine Problem geben.
Gruss Frieder
Hey,
danke für die Antwort.
Das ist ja leider genau das, bei dem ich mir nicht so sicher bin. Also ob der Adapter wirklich in FHEM eingebunden werden kann.
Ich wüsste halt gerade nicht, mit welchem Modul ich das Gerät in FHEM bekanntmachen könnte.
LG
Irgendwie glaube ich nicht, dass der Adapter mit FHEM funktioniert. Der ist ja nur für die Kommunikation mit dem Handsender. Ist also alles proprietär was da über den Kanal geht. Mit Aufwand und genügend Fachkenntnis kann man das vermutlich rausfinden. Aber ob das lohnt? Der Weg mit einem HM-LC-SW1-BA-PCB oder HM-LC-SW4-BA-PCB die Knopfdrücke zu simulieren ist da einfacher.
Mehr macht der Handsender ja auch nicht - oder? Interessant wäre es natürlich, wenn man so auch an den Sensor des Garagentors herankommt.
Gruss Frieder
Hi Frieder,
danke Dir für deine Unterstützung. Ich denke das hilft mir weiter :)
LG
Hallo farion,
habe das Modul gerade entdeckt - eigentlich genau das was ich "suche". Die Hardware ist sogar schon verbaut.
Habe allerdings noch nicht ganz genau verstanden was man nach dem DEFINE noch tun muss bzw. kann. Könntest Du vielleicht eine kleine Einführung schreiben?
Gruß
Hallo.
Mal eine Frage, die sich mir stellt: Wie kann ich eigentlich testen oder heraus bekommen, was ich an Hardware zur Ansteuerung des Garagentors benötige?
Ich habe ebenfalls eine 1-Knopf Funkbedienung meines Garagentors. Wie kann ich das denn jetzt testen/einstellen?
Ich benötige am Raspi doch bestimmt eine Art von Sender, oder löst ihr das anders?
LG
Holger
Zitat von: Hoggle am 07 Februar 2017, 09:19:32
Ich habe ebenfalls eine 1-Knopf Funkbedienung meines Garagentors. Wie kann ich das denn jetzt testen/einstellen?
1-Knopf meint in dem Fall eher, dass man einen Schalter an den Motor anschließen kann. Der Schalter kennt aber nicht auf/zu sondern quasi nur "toggle". Man kann also anhand des Aktors nicht feststellen ob das Tor gerade offen oder geschlossen ist.
Zitat von: Hoggle am 07 Februar 2017, 09:19:32
Ich benötige am Raspi doch bestimmt eine Art von Sender, oder löst ihr das anders?
Ich benutze einen ELV Homematic Komplettbausatz Funk-Schaltaktor mit Klemmanschluss, Zwischenstecker (https://www.elv.de/homematic-funk-schaltaktor-mit-klemmanschluss-zwischenstecker-bausatz.html (https://www.elv.de/homematic-funk-schaltaktor-mit-klemmanschluss-zwischenstecker-bausatz.html) / https://www.elv.de/homematic-funk-schaltaktor-mit-klemmanschluss-zwischenstecker.html (https://www.elv.de/homematic-funk-schaltaktor-mit-klemmanschluss-zwischenstecker.html)) und habe einen geflashten MAX! Cube als CUL per Netzwerk an FHEM angebunden. In Verbindung mit einem HomeMatic Fenstersensor sehe ich (bzw dieses Modul) dann ob das Tor geschlossen ist.
Vielen Dank für die schnelle Antwort.
Dann mal anders: Ich habe in der Garage einen Taster (Muß noch mal schauen, ob als Öffner oder als Schließer).
Mache ich einen Gedankenfehler, wenn ich jetzt einfach den Taster gegen einen HM-Schaltaktor (Gibt doch Taster davon) austausche, oder? (Könnte noch Z-Wave oder FS20 einsetzen, da Empfänger vorhanden, aber wo ist denn die Reichweite am Besten?)
Das wäre ja das einfachste ::) Hätte ja mal selbst nachdenken können :-\
Im Aussenbereich habe ich auch noch einen Schlüsselschalter, aber das dürfte doch kein Thema sein.
Zitat von: Hoggle am 07 Februar 2017, 12:28:56
Mache ich einen Gedankenfehler, wenn ich jetzt einfach den Taster gegen einen HM-Schaltaktor (Gibt doch Taster davon) austausche, oder?
Das dürfte nicht gehen, da die angeschlossenen Taster in der Regel potentialfrei sind, aber die HM Schaltaktoren die 230V zum Tasten nutzen. Am einfachsten und plug&play ist in der Regel der schon genannte Homematic Komplettbausatz Funk-Schaltaktor mit Klemmanschluss.
Ich hab auch mal eine Frage: Ich nutze den eben angesprochenen Schaltaktor mit Klemmanschluss. Einen Sensor für geschlossen habe ich noch nicht. Könnte ich das Modul trotzdem nutzen, oder ist ein Sender für die geschlossen-Erkennung notwendig. Ich würde eigentlich das HM Schließerkontakt-Interface nutzen wollen und dort einen entsprechenden Kontakt anschließen. Würde es nicht Sinn machen dann auch einen Schaltkontakt für die offen-Stellung zu nutzen? Den kann das Modul dann aber nicht auswerten oder?
Zitat von: Hoggle am 07 Februar 2017, 12:28:56
(Könnte noch Z-Wave oder FS20 einsetzen, da Empfänger vorhanden, aber wo ist denn die Reichweite am Besten?)
Ich glaube FS20 ist keine gute Idee - da kann doch jeder den Befehl zum Öffnen senden. Da würde ich doch eher auf Homematic gehen
Hi zusammen,
ich löse die Steuerung zur Zeit mit einem ITL-1000. Möchte aber umbauen und mir gefällt die Hardwarelösung hier. Gibt es einen Schaltplan bzw. eine Teileliste dafür? Ginge auch das nachfolgende Modul von Homematic HM-LC-Sw1-PCB?
Danke + Gruß
Benjamin
Ja, der HM-LC-Sw1-PCB lässt sich auch für die Garagensteuerung verwenden.
Moin moin.
Sehr cooles Modul.
Ich würde es gerne mit 2 Sensoren (MAX! ARR-Bausatz Fensterkontakt) für auf und zu realisieren.
Ist das so ohne weiteres möglich?
Grüße.
ich habe mir jetzt diesen Aktor "HM-LC-Sw1-Pl-CT" bestellt.
Meine Frage dazu wäre jetzt, wenn der Aktor in die Steckdose meines Garagentorantriebes gesteckt wird, schalte ich doch damit die Spannung des gesamten Antriebs "Ein" und "Aus" ist das richtig gedacht von mir..?
Der Taster der jetzt an meinem Antrieb ist kann ja parallel dazu weiter betrieben werden, aber wenn der "HM-LC-Sw1-Pl-CT" die Spannung wegschaltet geht das ja nicht mehr...!
Habe ich da einen Denkfehler..? :-\
Zitat von: moonsorrox am 11 Mai 2017, 13:04:07
ich habe mir jetzt diesen Aktor "HM-LC-Sw1-Pl-CT" bestellt.
Meine Frage dazu wäre jetzt, wenn der Aktor in die Steckdose meines Garagentorantriebes gesteckt wird, schalte ich doch damit die Spannung des gesamten Antriebs "Ein" und "Aus" ist das richtig gedacht von mir..?
Der Taster der jetzt an meinem Antrieb ist kann ja parallel dazu weiter betrieben werden, aber wenn der "HM-LC-Sw1-Pl-CT" die Spannung wegschaltet geht das ja nicht mehr...!
Habe ich da einen Denkfehler..? :-\
Also ich steuere über einen Aktor den Tastereingang vom Garagentor an. Das macht sicher mehr Sinn als den ganzen Antrieb aus und ein zu schalten.
-Till
Zitat von: Skywalker007 am 11 Mai 2017, 13:43:36
Das macht sicher mehr Sinn als den ganzen Antrieb aus und ein zu schalten.
ich glaube wir meinen beide etwas anderes..! ;)
Ich hatte irrtümlich angenommen der Aktor verhält sich wie jeder andere Aktor und schaltet die Spannung weg, dass tut er aber nicht sonst würde ja das Tor gar nicht mehr fahren.
Also der Antrieb fährt ja auch schon ohne das Modul..! Ich habe parallel auch noch den Innentaster mit angeschlossen.
Ich habe nur jetzt noch keinen Sensor der mir signalisiert ob "Auf" oder "Zu".
Mit einem DOIF kann man das sicher auch steuern, da gibt es einen "echten" Taster im DOIF Labor, ob man den nun einsetzen könnte weiß ich noch nicht
Hi Frieder,
Danke für das Modul.
Wirst du es noch erweitern?
ZitatIch werde wohl auf Dauer noch einen zweiten HM-SEC-SC-2 einbauen um den Offen-Zustand eindeutig zu haben.
Ich möchte ein HM-LC-Sw1-Pl-CT zum schalten und HM-SCI-3-FM für die Positionen verbauen.
LG Benjamin
Hallo farion,
zunächst einmal vielen Dank für das Tolle Modul, in FHEM funktioniert es bei mir bisher auch super. Ich nutze einen optischen HM Fensterkontaktsensor und einen HM Aufsteckschaltaktor für Antriebssteuerung und habe den Taster per Dummy und on-for-timer implementiert. Das Modul arbeitet damit wie gesagt in FHEM super.
Mein nächster Schritt wäre eine Integration in Homekit.
Was wäre denn hier der genericDeviceType und das homebridgemapping? Da steig ich irgendwie noch nicht ganz durch. Müsste evtl ähnlich einem Rolladen funktionieren können oder?
Hi,
das Modul wäre genau das Rchtige für mich, jedoch bekomme ich es nicht zum Laufen!
Aus dem Log:
2017.07.30 14:46:58 3: [GarageDoorSingleButton] Change state: DrivingDown
Undefined subroutine &main::BlockingCall called at ./FHEM/98_GarageDoorSingleButton.pm line 426.
Habe schon alle Variationen getestet, vor dem ersten fahren auf "forceClose" bzw. "forceOpen". Der Parameter "inconsistent" steht vor dem ersten close od. open immer auf "no".
Beim setzen von "close" oder "open" hängt sich FHEM auf und ich muss mit "sudo service fhem restart" wieder neu starten.
defmod Garage_Tor GarageDoorSingleButton AB.GA.To.Sc AB.GA.To.Se
attr Garage_Tor group Garage
attr Garage_Tor room 40_Aussen
attr Garage_Tor totalTimeDown 15
attr Garage_Tor totalTimeUp 17
Sensor ist ein HM-SEC-SCo und Schalter ein HM-LC-SW1-SM.
Wer kann helfen?
Gruß
Waldo
Hallo zusammen,
ich möchte auch gern mein Eintasten Garagentorantrieb über Fhem ansteuern,
das Modul hört sich sehr gut dafür an.
Es es möglich für den Auf/Zu Zustand anstatt den Tür/Fensterkontakt HM-Sec-SC-2
auch diesen HM-SCI-3-FM Kontakt-Interface in Verbindung mit Mirco-Schalter einzusetzten ?
Hallo,
wo findet man denn die aktuellste Version ? und wie definiert man das Device ?
Grüsse Christian
Zitat von: cs-online am 04 Oktober 2017, 21:51:25
wo findet man denn die aktuellste Version ?
:-\ :'(
vllt. mal 1.Post schauen...!
soso, da wäre ich ja echt nicht drauf gekommen.... und welche der dort angegebenen Versionen ist nun die aktuelle ?
* 98_GarageDoorSingleButton.pm (18.09 kB - runtergeladen 121 Mal.)
oder
* 98_GarageDoorSingleButton_v0.0.3.pm (19.24 kB - runtergeladen 82 Mal.)
???
und ein "define <Device> GarageDoorSingleButton" liefert nur
Unknown module GarageDoorSingleButton
daher die Frage nach der Definition. Und bevor es wieder rollende Augen gibt: ich habe die v0.0.3. bereits in das pm-Verzeichnis kopiert und Neustart durchgeführt.
hast du sie auch umbenannt in "98_GarageDoorSingleButton.pm"
>:( .... OK, da hätte ich drauf kommen können ;) Danke für den Tip :D
;) geht doch... :D
...manchmal sieht man den Wald vor lauter Bäume nicht....
Hallo liebe Gemeinde,
ich habe jetzt alle Komponenten zusammen, habe mich für den Schließerkontakt entschieden bei der ich jetzt ein eindeutiges AUF bzw. ZU Signal vom Tor habe.
Wie wird das jetzt alles in Betrieb genommen?
Kann ich die Originale Fernbedienung im Auto noch benutzen?
Kann ich den Taster der das Tor bisher geöffnet an den Taster vom HM-LC-SW1-BA-PCB anschließen (Löten) und dadurch weiter benutzen?
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...
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 .*
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 !!!
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.
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
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?)
@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
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.
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.
@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.
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
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
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
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
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
Ich habe das nun doch anders gemacht, ich weiß gar nicht, ob das hier hin darf.
Ich habe im Keller einen arduino micro und einen ESP8266 verkabelt; beide kommunizieren seriell (ich brauchte eine Weile um herauszufinden, dass die Schnittstelle beim Micro dann Serial1 heißt). Am arduino hängt ein DHT22 und misst die Temperatur, sowie ein Reed-Kontakt. Damit mein wackliges Garagentor auch gemessen werden kann, musste ich etwas tiefer in die Tasche greifen und eines bei pollin kaufen (https://www.pollin.de/p/alu-magnetkontakt-mit-neodymmagnet-mk-106a-420716, da sind auch mal 5cm Entfernung drin). Zugleich habe ich einen RXB6-Empfänger installiert, der dann misst, ob ein bestimmtes Funksignal eingetroffen ist und öffnet dann mit einem Relais das Tor.
Hier beide Sketche und ein Foto meiner Installation. Auf dem ESP8266:
/*
Dieser Webserver kommuniziert seriell mit dem arduino.
*/
#include <ESP8266WiFi.h>
#include <ESP8266WebServer.h>
const char *ssid = "WLAN-120954";
const char *password = "XXXXXXXXXXXXXXX";
String webString = "timeout"; // String to display
ESP8266WebServer server ( 80 );
void setup ( void ) {
Serial.begin(9600);
WiFi.begin ( ssid, password );
// Wait for connection
while ( WiFi.status() != WL_CONNECTED ) {
delay ( 500 );
}
server.on ( "/", handleRoot);
server.onNotFound ( handleNotFound );
server.begin();
}
void handleNotFound() { //in case we opened the wrong page
server.send ( 404, "text/plain", "Not found, reacts only on root / showing temperature and the like");
}
void handleRoot() {
server.send(200, "text/plain", webString);
}
void loop ( void ) {
if (Serial.available() > 0) {
webString= Serial.readString();
}
server.handleClient();
} und auf dem arduino
/*
Dieser arduino hört regelmässig 433 MHz und wartet auf das Drücken einer Taste an der Fernbedienung. Bei "On" löst
er das Tor mit dem Relais aus. Bei "Off" wird zuerst beim ESP seriell angefragt, ob das Tor bereits geschlossen ist - wenn nein, wird
das Relais ausgelöst.
*/
#include <RCSwitch.h>
#include <DHT.h>
RCSwitch mySwitch = RCSwitch();
#define RECEIVER 1 //Receiver on pin #2 which is interrupt 1
#define RELAIS 3 //relais to pin #3
#define REED 4 //Reed at pin #4
#define DHTPIN 5//DHT pin #5
#define DHTTYPE DHT22
// Initialize DHT sensor
// NOTE: For working with a faster than ATmega328p 16 MHz Arduino chip, like an ESP8266,
// you need to increase the threshold for cycle counts considered a 1 or 0.
// You can do this by passing a 3rd parameter for this threshold. It's a bit
// of fiddling to find the right value, but in general the faster the CPU the
// higher the value. The default for a 16MHz AVR is a value of 6. For an
// Arduino Due that runs at 84mhz a value of 30 works.
// This is for the ESP8266 processor on ESP-01, 11 works fine for ESP8266
DHT dht(DHTPIN, DHTTYPE);
float humidity, temp; // Values read from sensor
String webString = ""; // String to display
unsigned long previousMillis = 0; // will store when last temp was read
unsigned long previousData = 0; // will store when last data were sent
const long interval = 500; // interval at which to read sensor
const char* b;
byte Tor;
static const char* bin2tristate(const char* bin) {
static char returnValue[50];
int pos = 0;
int pos2 = 0;
while (bin[pos] != '\0' && bin[pos + 1] != '\0') {
if (bin[pos] == '0' && bin[pos + 1] == '0') {
returnValue[pos2] = '0';
} else if (bin[pos] == '1' && bin[pos + 1] == '1') {
returnValue[pos2] = '1';
} else if (bin[pos] == '0' && bin[pos + 1] == '1') {
returnValue[pos2] = 'F';
} else {
return "not applicable";
}
pos = pos + 2;
pos2++;
}
returnValue[pos2] = '\0';
return returnValue;
}
static char * dec2binWzerofill(unsigned long Dec, unsigned int bitLength) {
static char bin[64];
unsigned int i = 0;
while (Dec > 0) {
bin[32 + i++] = ((Dec & 1) > 0) ? '1' : '0';
Dec = Dec >> 1;
}
for (unsigned int j = 0; j < bitLength; j++) {
if (j >= bitLength - i) {
bin[j] = bin[ 31 + i - (j - (bitLength - i)) ];
} else {
bin[j] = '0';
}
}
bin[bitLength] = '\0';
return bin;
}
byte getTor() {
byte Tor = 1; // "offen" als default
if (digitalRead(REED) == LOW) {
Tor = 0; //zu, wenn LOW
}
return Tor;
}
void LeseSignal(unsigned long decimal, unsigned int length) {
if (decimal != 0) {
b = bin2tristate(dec2binWzerofill(decimal, length));
//Serial.println("b " + String(b)); //DEBUG
if ( strcmp( b, "0FF0F0F0FF0F") == 0 ) { //FB zu Hause auf C "On" gedrueckt
OeffneTor();
}
if ( strcmp( b, "0FF0F0F0FFF0") == 0 ) { //FB zu Hause auf C "Off" gedrueckt
//Serial.println("Tor " + String((byte)Tor)); //DEBUG
if ( getTor() != 0) {
OeffneTor();
}
}
}
}
void OeffneTor() {
digitalWrite(RELAIS, HIGH);
delay(400);
digitalWrite(RELAIS, LOW);
delay(600);//insgesamt eine Sekunde Pause
}
void HoleDaten() {
// Wait at least 500 milliseconds seconds between measurements.
// if the difference between the current time and last time you read
// the sensor is bigger than the interval you set, read the sensor
// Works better than delay for things happening elsewhere also
unsigned long currentMillis = millis();
if (currentMillis - previousMillis >= interval) {
// save the last time you read the sensor
previousMillis = currentMillis;
}
else {
delay(interval); //Sensor ist traege, also warten
}
// Reading temperature or humidity takes about 250 milliseconds!
// Sensor readings may also be up to 2 seconds 'old' (it's a very slow sensor)
humidity = dht.readHumidity(); // Read humidity (percent)
temp = dht.readTemperature(); // Read temperature as Celsius
if (isnan(humidity) || isnan(temp)) {
webString = "Failed to read from DHT sensor, Tor: ";
} else {
webString = "Temperature: " + String((int)temp) + "C Humidity: " + String((int)humidity) + "% Tor: "; // Arduino has a hard time with float to string
}
webString = webString + String((byte)getTor());
return ;
}
void setup() {
Serial1.begin(9600);
// while the serial stream is not open, do nothing:
while (!Serial1) ;
pinMode(RELAIS, OUTPUT);
digitalWrite(RELAIS, LOW);
mySwitch.enableReceive(RECEIVER);
pinMode(DHTPIN, INPUT_PULLUP);
dht.begin();
pinMode(REED, INPUT_PULLUP);
previousData = millis();
HoleDaten();
Serial1.print(webString+'\n');
}
void loop() {
unsigned long currentData = millis();
if (currentData - previousData > 6000 ) { //jede Minute (60.000 ms) Daten senden
HoleDaten();
Serial1.print(webString+'\n');
previousData = millis();
}
if (mySwitch.available()) { //433-Signal trifft ein
LeseSignal(mySwitch.getReceivedValue(), mySwitch.getReceivedBitlength());
mySwitch.resetAvailable();
}
}
Hi zusammen,
kann mir bitte einmal jemand erklären, wie ich meinen Sensor-Status hier eingeben muss:
closeSensorDeviceEvent
?? Irgendwie tut sich nichts, egal was ich probiere....
Danke, Grüße Christian
Hallo zusammen,
ich verwende das Modul (v0.6) sein einigen Wochen mit einem Sommer Garagentorantrieb und Homematic Aktor und Sensor.
Funktioniert soweit alles. Bekomme die richtigen Anzeigen und kann das Tor öffnen und schliessen.
Leider habe ich das Reading: inconsistent = yes
Meine Vermutung
Das CLOSE_SENSOR_DEVICE geht auf einen Kontakt des Antriebs der geöffnet ist wenn das Tor geschlossen ist. (Bei offenem Tor wäre eine Lampe an)
Das CLOSE_SENSOR_DEVICE ist also "open" wenn das Tor zu ist. Dies könnte zu dem inconsistent = yes führen?
Sehe ich das richtig? und was könnte ich tun um das geradezubiegen?
Danke und Gruß
hf
Ich bedanke mich schon mal für das Modul.
Mein Hörmann aus den Anfängen der 80er läuft nämlich auch noch einwandfrei. Wenn auch nicht mehr mit der originalen Funkplatine welche irgendwann in Rauch aufgegangen ist ;-)
Als Sensoren für den Zustand würde ich die Fensterkontakte von Smartwares (SH5-TSM-A) versuchen. Die gibt es recht günstig (10,99€) und müssten mit dem IT v3 Protokoll laufen.
Hat da bereits jemand Erfahrungen mit?
Welchen Potifreien Kontakt ich als Taster nehme weiß ich noch nicht so genau.
Ich hätte da aber noch einen Verbesserungsvorschlag. Kann man nicht evtl noch einen dritten Sensor einbauen der prüft ob das Tor auch frei ist?
Denn die Verlockung ist ja groß das Tor, falls mal vergessen, abends von der Couch mit Alexa zu schliessen.
Steht da aber nun ein Auto halb drin oder eben irgendetwas anderes dann könnt es schließlich ein paar Kratzer geben.
Ich überlege noch wie ich das absichere. Per Lichtschranke oder Entfernungsmesser...
Grüße, Alex.
Hallo,
vielen Dank für das coole Modul, endlich kann ich mein in die Jahre gekommenes Hörmann Tor damit bedienen.
Zum auslesen der Sensoren ob das Tor geschlossen bzw. geöffnet ist verwendet ich ein HM-SCI-3-FM Sensor.
Da ich leider nicht so fit bin was Perl angeht, finde ich den Vorschlag von axs77 echt super.
Aktuell habe ich an dem Sensor noch ein freien Anschluss, mit dem ich gerne Überprüfen würde ob die Dachbodentreppe geöffnet ist und das öffnen des Tores ggf. blockieren.
Viele Grüße
T-M
Hallo,
ich komme leider nicht ganz mit dem Modul klar. Aber es funktioniert fast einwandfrei, das ist schon mal super.
Woran es jedoch scheitert ist diese inconsistent, welches wohl mit dem XsensoreDevice(Event) zu tun hat.
Läuft es bei euch und was mache ich falsch?
Hätte schon gerne damit abgefangen, wenn von Hand der Schalter betätigt wird. aber er reagiert leider nicht.
Anbei habe ich mal 2 Screenshots von den Devices angehängt. Vielleicht seht ihr ja den Fehler. inconsistent bleibt nämlich immer auf Yes
Danke für eure Hilfe.
Gruß
Steffen
Hallo,
ich habe das Modul (v0.6)auch erfolgreich eingebunden, vielen Dank schon einmal dafür! Was mir aber auffällt: Ich habe einen Homematic HM-Sec-SCo Sensor, der meldet, wenn das Garagentor geschlossen ist. Der meldet auch ganz artig "closed", sobald das Tor geschlossen ist, aber das Modul hier meldet kurz danach doch wieder "open" und ich bekomme es nicht mehr systemisch zu, auch nicht mit forceClose.
Vielleicht hab ich auch komplett was falsch eingebunden, aber er verhält sich aus meiner Sicht nicht korrekt. Hier mal mein Versuchsaufbau:
Ich öffne das Tor und schließe es wieder. Dabei tracke ich im Event-Monitor alles, was mit Garagentor zu tun hat
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor timeToClose: 0.00
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor timeToOpen: 18.00
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor level: 0
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor DrivingUp
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor timeToClose: 0.00
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor timeToOpen: 18.00
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor level: 0
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor pressQueueSize: 0
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor pressesTriggered: 14
2018-06-21 22:44:52 GarageDoorSingleButton Garagentor pressesDone: 14
2018-06-21 22:44:53 GarageDoorSingleButton Garagentor opening
2018-06-21 22:44:53 GarageDoorSingleButton Garagentor timeToClose: 1.35
2018-06-21 22:44:53 GarageDoorSingleButton Garagentor timeToOpen: 16.65
2018-06-21 22:44:53 GarageDoorSingleButton Garagentor level: 8
2018-06-21 22:44:53 GarageDoorSingleButton Garagentor closed
2018-06-21 22:44:54 readingsGroup BatterieStatus Garagentorsensor.zu.battery: ok
2018-06-21 22:44:54 CUL_HM Garagentorsensor.zu battery: ok
2018-06-21 22:44:54 CUL_HM Garagentorsensor.zu contact: open (to broadcast)
2018-06-21 22:44:54 CUL_HM Garagentorsensor.zu open
2018-06-21 22:44:54 CUL_HM Garagentorsensor.zu trigDst_broadcast: noConfig
2018-06-21 22:44:54 CUL_HM Garagentorsensor.zu trigger_cnt: 65
2018-06-21 22:44:54 CUL_HM Garagentorsensor.zu last: 2018-06-21 22:44:54
2018-06-21 22:44:54 GarageDoorSingleButton Garagentor opening
2018-06-21 22:44:54 GarageDoorSingleButton Garagentor pressQueueSize: 0
2018-06-21 22:44:54 GarageDoorSingleButton Garagentor pressesTriggered: 14
2018-06-21 22:44:54 GarageDoorSingleButton Garagentor pressesDone: 14
2018-06-21 22:44:54 GarageDoorSingleButton Garagentor timeToClose: 2.40
2018-06-21 22:44:54 GarageDoorSingleButton Garagentor timeToOpen: 15.60
2018-06-21 22:44:54 GarageDoorSingleButton Garagentor level: 13
2018-06-21 22:44:55 GarageDoorSingleButton Garagentor timeToClose: 3.45
2018-06-21 22:44:55 GarageDoorSingleButton Garagentor timeToOpen: 14.55
2018-06-21 22:44:55 GarageDoorSingleButton Garagentor level: 19
2018-06-21 22:44:56 GarageDoorSingleButton Garagentor timeToClose: 4.50
2018-06-21 22:44:56 GarageDoorSingleButton Garagentor timeToOpen: 13.50
2018-06-21 22:44:56 GarageDoorSingleButton Garagentor level: 25
2018-06-21 22:44:58 GarageDoorSingleButton Garagentor timeToClose: 5.55
2018-06-21 22:44:58 GarageDoorSingleButton Garagentor timeToOpen: 12.45
2018-06-21 22:44:58 GarageDoorSingleButton Garagentor level: 31
2018-06-21 22:44:58 GarageDoorSingleButton Garagentor closed
2018-06-21 22:44:59 GarageDoorSingleButton Garagentor timeToClose: 6.60
2018-06-21 22:44:59 GarageDoorSingleButton Garagentor timeToOpen: 11.40
2018-06-21 22:44:59 GarageDoorSingleButton Garagentor level: 37
2018-06-21 22:45:00 GarageDoorSingleButton Garagentor timeToClose: 7.65
2018-06-21 22:45:00 GarageDoorSingleButton Garagentor timeToOpen: 10.35
2018-06-21 22:45:00 GarageDoorSingleButton Garagentor level: 42
2018-06-21 22:45:01 GarageDoorSingleButton Garagentor timeToClose: 8.70
2018-06-21 22:45:01 GarageDoorSingleButton Garagentor timeToOpen: 9.30
2018-06-21 22:45:01 GarageDoorSingleButton Garagentor level: 48
2018-06-21 22:45:02 GarageDoorSingleButton Garagentor timeToClose: 9.75
2018-06-21 22:45:02 GarageDoorSingleButton Garagentor timeToOpen: 8.25
2018-06-21 22:45:02 GarageDoorSingleButton Garagentor level: 54
2018-06-21 22:45:03 GarageDoorSingleButton Garagentor timeToClose: 10.80
2018-06-21 22:45:03 GarageDoorSingleButton Garagentor timeToOpen: 7.20
2018-06-21 22:45:03 GarageDoorSingleButton Garagentor level: 60
2018-06-21 22:45:04 GarageDoorSingleButton Garagentor timeToClose: 11.85
2018-06-21 22:45:04 GarageDoorSingleButton Garagentor timeToOpen: 6.15
2018-06-21 22:45:04 GarageDoorSingleButton Garagentor level: 66
2018-06-21 22:45:05 GarageDoorSingleButton Garagentor timeToClose: 12.90
2018-06-21 22:45:05 GarageDoorSingleButton Garagentor timeToOpen: 5.10
2018-06-21 22:45:05 GarageDoorSingleButton Garagentor level: 72
2018-06-21 22:45:07 GarageDoorSingleButton Garagentor timeToClose: 14.88
2018-06-21 22:45:07 GarageDoorSingleButton Garagentor timeToOpen: 3.12
2018-06-21 22:45:07 GarageDoorSingleButton Garagentor level: 83
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor timeToClose: 19.15
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor timeToOpen: -1.15
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor level: 106
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor timeToClose: 19.20
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor timeToOpen: -1.20
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor level: 107
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor Open
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor inconsistent: Yes
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor timeToClose: 18.00
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor timeToOpen: 0.00
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor level: 100
2018-06-21 22:45:11 GarageDoorSingleButton Garagentor open
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor timeToClose: 18.00
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor timeToOpen: 0.00
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor level: 100
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor DrivingDown
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor timeToClose: 18.00
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor timeToOpen: 0.00
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor level: 100
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor pressQueueSize: 0
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor pressesTriggered: 15
2018-06-21 22:45:17 GarageDoorSingleButton Garagentor pressesDone: 15
2018-06-21 22:45:18 GarageDoorSingleButton Garagentor timeToClose: 16.67
2018-06-21 22:45:18 GarageDoorSingleButton Garagentor timeToOpen: 1.33
2018-06-21 22:45:18 GarageDoorSingleButton Garagentor level: 93
2018-06-21 22:45:19 GarageDoorSingleButton Garagentor pressQueueSize: 0
2018-06-21 22:45:19 GarageDoorSingleButton Garagentor pressesTriggered: 15
2018-06-21 22:45:19 GarageDoorSingleButton Garagentor pressesDone: 15
2018-06-21 22:45:19 GarageDoorSingleButton Garagentor timeToClose: 15.62
2018-06-21 22:45:19 GarageDoorSingleButton Garagentor timeToOpen: 2.38
2018-06-21 22:45:19 GarageDoorSingleButton Garagentor level: 87
2018-06-21 22:45:20 GarageDoorSingleButton Garagentor timeToClose: 14.57
2018-06-21 22:45:20 GarageDoorSingleButton Garagentor timeToOpen: 3.43
2018-06-21 22:45:20 GarageDoorSingleButton Garagentor level: 81
2018-06-21 22:45:21 GarageDoorSingleButton Garagentor timeToClose: 13.52
2018-06-21 22:45:21 GarageDoorSingleButton Garagentor timeToOpen: 4.48
2018-06-21 22:45:21 GarageDoorSingleButton Garagentor level: 75
2018-06-21 22:45:22 GarageDoorSingleButton Garagentor timeToClose: 12.47
2018-06-21 22:45:22 GarageDoorSingleButton Garagentor timeToOpen: 5.53
2018-06-21 22:45:22 GarageDoorSingleButton Garagentor level: 69
2018-06-21 22:45:23 GarageDoorSingleButton Garagentor timeToClose: 11.42
2018-06-21 22:45:23 GarageDoorSingleButton Garagentor timeToOpen: 6.58
2018-06-21 22:45:23 GarageDoorSingleButton Garagentor level: 63
2018-06-21 22:45:24 GarageDoorSingleButton Garagentor timeToClose: 10.37
2018-06-21 22:45:24 GarageDoorSingleButton Garagentor timeToOpen: 7.63
2018-06-21 22:45:24 GarageDoorSingleButton Garagentor level: 58
2018-06-21 22:45:25 GarageDoorSingleButton Garagentor timeToClose: 9.31
2018-06-21 22:45:25 GarageDoorSingleButton Garagentor timeToOpen: 8.69
2018-06-21 22:45:25 GarageDoorSingleButton Garagentor level: 52
2018-06-21 22:45:26 GarageDoorSingleButton Garagentor timeToClose: 8.26
2018-06-21 22:45:26 GarageDoorSingleButton Garagentor timeToOpen: 9.74
2018-06-21 22:45:26 GarageDoorSingleButton Garagentor level: 46
2018-06-21 22:45:28 GarageDoorSingleButton Garagentor timeToClose: 7.21
2018-06-21 22:45:28 GarageDoorSingleButton Garagentor timeToOpen: 10.79
2018-06-21 22:45:28 GarageDoorSingleButton Garagentor level: 40
2018-06-21 22:45:29 GarageDoorSingleButton Garagentor timeToClose: 6.16
2018-06-21 22:45:29 GarageDoorSingleButton Garagentor timeToOpen: 11.84
2018-06-21 22:45:29 GarageDoorSingleButton Garagentor level: 34
2018-06-21 22:45:29 GarageDoorSingleButton Garagentor closed
2018-06-21 22:45:30 readingsGroup BatterieStatus Garagentorsensor.zu.battery: ok
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor timeToClose: 5.03
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor timeToOpen: 12.97
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor level: 28
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor Closed
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor inconsistent: No
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor timeToClose: 0.00
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor timeToOpen: 18.00
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor level: 0
2018-06-21 22:45:30 CUL_HM Garagentorsensor.zu battery: ok
2018-06-21 22:45:30 CUL_HM Garagentorsensor.zu contact: closed (to broadcast)
2018-06-21 22:45:30 CUL_HM Garagentorsensor.zu closed
2018-06-21 22:45:30 CUL_HM Garagentorsensor.zu trigDst_broadcast: noConfig
2018-06-21 22:45:30 CUL_HM Garagentorsensor.zu trigger_cnt: 66
2018-06-21 22:45:30 CUL_HM Garagentorsensor.zu last: 2018-06-21 22:44:54
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor opening
2018-06-21 22:45:30 GarageDoorSingleButton Garagentor closed
2018-06-21 22:45:31 GarageDoorSingleButton Garagentor closed
2018-06-21 22:45:34 GarageDoorSingleButton Garagentor closed
2018-06-21 22:45:45 GarageDoorSingleButton Garagentor open
Für mich sieht das alles normal aus, allerdings sind die letzten 5 Zeilen echt seltsam. Das Tor ist zu, ich bediene nichts und dennoch switcht er zwischen opening, closed und dann wieder open.
Tiefer bin ich nicht gekommen mit einer Analyse, aber hat jemand eine Idee, woran das liegt?
Hier nochmal meine Raw Definition von meinem angelegten Modul:
defmod Garagentor GarageDoorSingleButton Toröffner Garagentorsensor.zu
attr Garagentor buttonDevice HM_392187
attr Garagentor buttonTriggerCommand on
attr Garagentor closeSensorDevice Garagentorsensor.zu
attr Garagentor closeSensorDeviceEvent closed
attr Garagentor room Garage
attr Garagentor totalTimeDown 18
attr Garagentor totalTimeUp 18
setstate Garagentor open
setstate Garagentor 2018-06-21 22:45:30 inconsistent No
setstate Garagentor 2018-06-21 22:45:30 level 0
setstate Garagentor 2018-06-21 22:45:19 pressQueueSize 0
setstate Garagentor 2018-06-21 22:45:19 pressesDone 15
setstate Garagentor 2018-06-21 22:45:19 pressesTriggered 15
setstate Garagentor 2018-06-21 22:45:45 state open
setstate Garagentor 2018-06-21 22:45:30 timeToClose 0.00
setstate Garagentor 2018-06-21 22:45:30 timeToOpen 18.00
Vielleicht ist mein closeSensorDeviceEvent ja auch falsch, so richtig bin ich da noch nicht durchgestiegen, was das zu bedeuten hat.
Über jeden Tipp freue ich mich :-)
Oh, bei mir waren noch Relikte des alten Garagentores vorhanden, die haben da quergeschossen. Nun funktioniert alles super!
Hat jemand schon Homebridge integriert? Mit:
attr Garagentor genericDeviceType GarageDoorOpener
attr Garagentor homebridgeMapping CurrentDoorState=state,values=Closed:CLOSED;;;;Open:OPEN;;;;DrivingUp:OPENING;;;;DrivingDown:CLOSING\\
TargetDoorState=state,cmds=OPEN:open;;;;CLOSED:close,values=Closed:CLOSED;;;;Open:OPEN
Zeigt er immerhin das Garagentor an, allerdings haut das TargetDoorState noch nicht hin, raufdrücken bewirkt nichts...
Ich kämpfe auch noch mit inconsistent. Eine genauere Beschreibung des Moduls wäre super. Oder läuft die letzte Version nicht richtig?
Edit: Habe jetzt auch nochmal die version 3 probiert. Hatte zum start tatsächlich das inconsistent auf no. Aber nun steht es wieder dauerhaft auf yes. Zudem würde ich gerne wissen warum mein Tor durch die Sensoren nicht auf "open" oder "closed" gesetzt wird wenn man es durch Funk oder den normalen Taster bedient.
Hey farion. Hilf uns doch bitte nochmal über die Straße ;-)
Moin.
Habe heute zufällig dieses Modul entdeckt. Genau sowas kann ich brauchen!!!
Habe den Rademacher RolloPort SX5 DuoFern den ich auch über ein/en Relais/Taster ansteuern kann. RasPi in der Garage, DuoFernStick zu teuer bzw. für ein Device?
Habe das Modul mit meinem Testaufbau für die Garage gestestet und werde das Gefühl nicht los, dass es die Sensoren überhaupt nicht behandelt. Und wenn doch, dann ignoriert das Modul die openSensorDeviceEvent/closeSensorDeviceEvent Attribute. Oder wie werden diese richtig gesetzt? Es gibt ja keine Doku.
Dadurch wahrscheinlich auch "incosistent"! Ich habe bei mir konventionelle Magnetkontakte am GPIO hängen. Hier ist der state "on" oder "off". Unnötig zu sagen, dass es keinen Sinn macht den state zu verbiegen, wenn ich doch dem Modul sagen kann auf was es lauschen soll.
Was ich mich noch frage (weiß nicht ob es schon angesprochen wurde) warum man die Hochlauf/Runterlauf Zeiten festlegen muss.
Kann man nicht eine Initialisierungsfahr machen? Dazu hat man doch die Auf/Zu Sensoren?!?
Ansonsten kann ich nur sagen respekt. Ich hab null Plan von Perl......
Grüße^^
...die rauf-/runter-Zeiten sind wichtig, wenn du a) keine Endsensoren hast um ca. sehen zu können, wann es zu ist, und b) um berechnen zu können, wie weit auf / zu das Tor ist, wenn es nicht ganz auf / zu ist.
Das Problem mit der Einbindung der Endschalter habe ich auch, aber mittels notify kann man forceopen oder forceclose setzen, das klappt wohl.
Ich habe bei mir einfach einen esp8266 in der Garage, der steuert neben Aussensteckdosen auch alles vom Tor...
Zitat von: roman1528 am 22 Juli 2018, 13:06:41
und werde das Gefühl nicht los, dass es die Sensoren überhaupt nicht behandelt.
Dein Gefühl täuscht dich nicht :) Leider ist die Abfrage der Endlagen im Modul hardcoded und wird so für die meisten Endlagen Sensoren nicht passen.
Ich plane auch das Modul für mein Garagentor einzuetzen und wenn Farion Interesse hat kann ich gern Verbesserungsvorschläge machen.
hmmm....von dem hab ich hier leider lange nichts gelesen, weiß gar nicht, ob der noch supportet....
Hallo,
ich plane bereits seit langem meine Markise zu steuern.
Der Antrieb mit einem Motor und Endschaltern oder Sensoren ist etwas schwieriger zu realisieren.
Meine Idee:
für den Antrieb einen Schrittmotor einsetzen. Hierdurch könnte ich die Endschalter weglassen. Der Schrittmotor würde dann ja nach z.B. 1000 Schritten (Endpunkt) aufhören und abschalten.
Hat jemand mit Schrittmotoren / Steppmotoren bereits Erfahrungen gesammelt oder eine ähnliches Projekt verwirklicht?
Gruß
Hubi3922
Hallo,
ob ein Schrittmotor genug Power hätte, weiß ich nicht. Steuerbar sind die Dinger z.B. mit einem CNC-Shield mit Arduino. Würde denn ein 40er Rolladenmotor da nicht besser passen ? Die Dinger haben schon recht viel Kraft und die Endlagen sind einstellbar, geben nur gewöhnlicherweise keine Rückmeldung, ob sie in Endlage stehen.
Grüße
Christian
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ß
...bin gespannt, wie es wird ! Lass uns mal dran teilhaben, wenn es soweit ist...
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
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
...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
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 :(
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.
Moin,
hier gibt es schon ein sehr gutes DOIF Beispiel: https://forum.fhem.de/index.php/topic,84969.msg822560.html#msg822560
VG
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 ;)
Ich hab das jetzt mit doif und forceclose/forceopen gelöst.
Funktioniert einwandfrei!
Dank für die Hilfe.
Habe auch das Problem mit dem inconsistent.
Hast Du es komplett auf eine DoIf Lösung umgestellt?
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
#
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
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
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
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
Zitat von: Niko1987 am 22 Juni 2019, 12:37:29
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
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
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.
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
attr Garage stateFormat TorStatus
und mit
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
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):
update all https://raw.githubusercontent.com/farion/fhem-garagedoorsinglebutton/master/controls_garagedoorsinglebutton.txt
Gruss 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.
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ß
@kabanett
Kannst du mal den Log mit den Logs deiner Sensor-Events anhängen?
Hi,
ist so aus dem "Event monitor" kopiert!
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ß
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:
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".
attr closeSensorDevice Hoermann_Tor_Zu
attr closeSensorDeviceEvent POWER2:on
attr openSensorDevice Hoermann_Tor_Auf
attr openSensorDeviceEvent POWER3:on
und so:
attr closeSensorDevice Hoermann_Tor_Zu
attr closeSensorDeviceEvent on
attr openSensorDevice Hoermann_Tor_Auf
attr openSensorDeviceEvent on
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 :-)
Zitat von: Beetle2003 am 21 Januar 2020, 22:43:34
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ß
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:
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:
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.
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..
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
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.
Hallo zusammen,
ich habe mir mal das Modul eingerichtet und finde es super, allerdings bekomme ich das ganze nicht in homebridge als Garage zum laufen. Das Garagensymbol wird angezeigt aber der Zustand steht immer auf auf und wenn ich es schalten möchte am Handy kommt nur die wait Anzeige und es verändert sich nichts, das Tor fährt auch nicht zu oder auf. In FHEM läuft alles prima, Zeiten zum verfahren werden angezeigt und auch die Symbole passen. Echt ein tolles Modul, allerdings hätte ich das ganze noch gerne lauffähig in meiner Home App. Ich hatte meine Garagentorsteuerung über Dummy und notify gelöst das funktioniert auch alles super in der Home App über homebridge nur wird bei meiner Lösung nicht das verfahren angezeigt. Sobald ich das Tor öffne wechselt der Zustand auf offen, ich benutze zwei Fensterkontakte von max für auf und zu Zustand, funktioniert auch gut allerdings wird der Zustand erst bei Endlage gesetzt sodas ich mir nie 100% Sicher sein kann ob das Tor noch am fahren ist oder auf bzw. zu. Deshalb fand ich das Modul als Lösung super da hier auch der Verfahrweg gemessen wird bis die Kontakte als Endlage schalten. Lange Rede kurzer Sinn, hier mal meine List vom Modul, vielleicht ist es nur eine Kleinigkeit beim state oder so, welches verhindert das das Garagentor als Device richtig in der Home App arbeitet.
Garagentorsteuerung:
Internals:
.eventMapCmd auf:noArg zu:noArg
BUTTON_DEVICE Shelly1_Garagentaster
CFGFN
CHANGED
CLOSE_SENSOR_DEVICE shutterContact05
DEF Shelly1_Garagentaster shutterContact05 shutterContact06
FUUID 5f6c8c50-f33f-7f1e-7811-31fb5e52b1a72742
NAME Garagentorsteuerung
NR 832
NTFY_ORDER 50-Garagentorsteuerung
OPEN_SENSOR_DEVICE shutterContact06
STATE Closed
TYPE GarageDoorSingleButton
.attraggr:
.attreocr:
state
.attrminint:
READINGS:
2020-09-25 16:08:20 inconsistent Yes
2020-09-25 16:08:20 level 0
2020-09-25 16:08:19 pressQueueSize 0
2020-09-25 16:08:19 pressesDone 15
2020-09-25 16:08:19 pressesTriggered 15
2020-09-25 16:08:20 state Closed
2020-09-25 16:08:20 timeToClose 0.00
2020-09-25 16:08:20 timeToOpen 20.00
helper:
DOORSTATE 6
LASTTIME 1601042900.05842
PRESSES_DONE 15
PRESS_QUEUE 0
PRESS_TOTAL 15
RUNNING_TRIGGER_COUNT 0
TC 0
TO 20
Attributes:
buttonTriggerCommand on
devStateIcon Open:fts_garage_door_10@red Closed:fts_garage_door_100@green
event-on-change-reading state
eventMap open:auf close:zu
genericDeviceType garage
icon fts_garage
room Garage,Homekit
verbose 4
webCmd auf:zu
Danke schon mal an alle die mir hier Hilfreich zur Seite stehen ;D
Hallo zusammen,
ist ja ziemlich still geworden hier. Ich habe das Modul gerade für mich entdeckt, und 3 Fragen.
1.
Entweder ich bin blind, oder es steht nirgends wie genau das Modul definiert wird .
Ich habe jetzt folgendes rausgelesen.
defmod Garagentorsteuerung GarageDoorSingleButton <Device zum Öffnen> <Sensor Tor geschlossen> <Sensor Tor offen>
Passt das so?
2.
Wie genau ist die definition von "inconsistent Yes" oder "inconsistent No?
Meinem Verständnis nach müsste ich ein "No" haben.
Internals:
BUTTON_DEVICE MQTT2_DVES_98B2FB
CFGFN
CLOSE_SENSOR_DEVICE HUESensor7
DEF MQTT2_DVES_98B2FB HUESensor7 HUESensor8
FUUID 608582a3-f33f-1e28-d170-af6ce4456ec6a3ad
NAME Garagentorsteuerung
NR 383
NTFY_ORDER 50-Garagentorsteuerung
OPEN_SENSOR_DEVICE HUESensor8
STATE Closed
TYPE GarageDoorSingleButton
Helper:
DBLOG:
inconsistent:
DBLogging:
TIME 1619362467.38679
VALUE Yes
logdb:
TIME 1619362467.40924
VALUE Yes
level:
DBLogging:
TIME 1619362467.42448
VALUE 0
logdb:
TIME 1619362467.4476
VALUE 0
pressQueueSize:
DBLogging:
TIME 1619362467.35095
VALUE 0
logdb:
TIME 1619362467.37311
VALUE 0
pressesDone:
DBLogging:
TIME 1619362467.35095
VALUE 0
logdb:
TIME 1619362467.37311
VALUE 0
pressesTriggered:
DBLogging:
TIME 1619362467.35095
VALUE 0
logdb:
TIME 1619362467.37311
VALUE 0
state:
DBLogging:
TIME 1619362467.38679
VALUE Closed
logdb:
TIME 1619362467.40924
VALUE Closed
timeToClose:
DBLogging:
TIME 1619362467.42448
VALUE 0.00
logdb:
TIME 1619362467.4476
VALUE 0.00
timeToOpen:
DBLogging:
TIME 1619362467.42448
VALUE 20.00
logdb:
TIME 1619362467.4476
VALUE 20.00
READINGS:
2021-04-26 16:03:27 inconsistent Yes
2021-04-26 16:03:27 level 0
2021-04-26 16:03:27 pressQueueSize 0
2021-04-26 16:03:27 pressesDone 0
2021-04-26 16:03:27 pressesTriggered 0
2021-04-26 16:03:27 state Closed
2021-04-26 16:03:27 timeToClose 0.00
2021-04-26 16:03:27 timeToOpen 26.00
helper:
DOORSTATE 6
LASTTIME 1619445807.08954
PRESSES_DONE 0
PRESS_QUEUE 0
PRESS_TOTAL 0
RUNNING_TRIGGER_COUNT 0
TC 0
TO 26
Attributes:
DbLogExclude .*
buttonDevice MQTT2_DVES_98B2FB
buttonTriggerCommand on
closeSensorDevice HUESensor7
closeSensorDeviceEvent closed
devStateIcon Open:fts_garage_door_10@red Closed:fts_garage_door_100@green
eventMap open:auf close:zu
icon fts_garage
openSensorDevice HUESensor8
openSensorDeviceEvent closed
room Garage
totalTimeDown 25
totalTimeUp 26
warnFct set TelegramBot msg @#Home Garage steht noch offen
webCmd auf:zu:stop
3.
Wenn ich das Tor per Hand Sensor steuere bekommt das Modul das überhaupt nicht mit.
Ist das so richtig? Es müsste doch zumindest eine Auswertung über die beiden Kontaktsensoren stattfinden oder nicht?
Grüße
zu 3.
ja genau das ist das Problem. Ich verstehe auch nicht so ganz, wofür der Sensor ins Modul eingebunden wird, wenn dann auf dessen Status nicht reagiert wird. Man kann das Problem über ein notify bei Sensor-Änderung und ein set forceopen bzw. forceclose am Modul lösen.
Hallo,
zu 1. DieDefinition sieht für mich richtig aus.
zu 2. es gibt einen Eintrag der dieses Verhalten beschreibt und korrigiert
zu 3. Es ist unschön, dass sich das Modul nicht weiter entwickelt. Ich nutze es sowie es ist und habe es wie mein Vorredner beschrieben, durch ein notify gelöst. Das ginge sicherlich schöner ( siehe ASC Modul ), doch habe ich nicht die Kenntnisse, dieses zu ändern.
Gruss
Danke euch beiden.
Vll findet sich ja nochmal irgendjemand der das Modul korrigiert.
Grüße