Hallo zusammen,
im Zuge meines Projektes Sonoff T1 EU schalter für die Rollo-Steuerung zu nutzen, stehe ich nun vor folgender Aufgabe.
Ich möchte in Fhem im Raum anstatt on, off einen Slider haben. Dieser soll basierend auf der Zeit die das Rollo zum hoch und runter fahren benötigt, in z.B. 10% Schritten regelbar sein.
Wie ich einen Slider anlege, habe ich verstanden aber wie ich diesen nun zeitabhängig und dazu noch den korrekten GPIO schalten lasse, leider nicht.
Das wäre z.B. ein Device bzw (da ich combine aus habe) sind es drei.
Am Ende wäre es schön mit combinedevice zu arbeiten und pro Rollo einfach einen Regler zu haben.
# Schlafzimmer Rollo
define ESPEasy_sz_rollo_RSSI ESPEasy 192.168.20.31 80 espBridge sz_rollo_RSSI
attr ESPEasy_sz_rollo_RSSI IODev espBridge
attr ESPEasy_sz_rollo_RSSI Interval 300
attr ESPEasy_sz_rollo_RSSI group ESPEasy Device
attr ESPEasy_sz_rollo_RSSI presenceCheck 1
attr ESPEasy_sz_rollo_RSSI readingSwitchText 1
attr ESPEasy_sz_rollo_RSSI room ESPEasy
attr ESPEasy_sz_rollo_RSSI setState 3
define ESPEasy_sz_rollo_rollo_hoch ESPEasy 192.168.20.31 80 espBridge sz_rollo_rollo_hoch
attr ESPEasy_sz_rollo_rollo_hoch IODev espBridge
attr ESPEasy_sz_rollo_rollo_hoch Interval 300
attr ESPEasy_sz_rollo_rollo_hoch eventMap /gpio 12 on:on/gpio 12 off:off/
attr ESPEasy_sz_rollo_rollo_hoch group ESPEasy Device
attr ESPEasy_sz_rollo_rollo_hoch presenceCheck 1
attr ESPEasy_sz_rollo_rollo_hoch readingSwitchText 1
attr ESPEasy_sz_rollo_rollo_hoch room ESPEasy
attr ESPEasy_sz_rollo_rollo_hoch setState 3
define ESPEasy_sz_rollo_rollo_runter ESPEasy 192.168.20.31 80 espBridge sz_rollo_rollo_runter
attr ESPEasy_sz_rollo_rollo_runter IODev espBridge
attr ESPEasy_sz_rollo_rollo_runter Interval 300
attr ESPEasy_sz_rollo_rollo_runter eventMap /gpio 5 on:on/gpio 5 off:off/
attr ESPEasy_sz_rollo_rollo_runter group ESPEasy Device
attr ESPEasy_sz_rollo_rollo_runter presenceCheck 1
attr ESPEasy_sz_rollo_rollo_runter readingSwitchText 1
attr ESPEasy_sz_rollo_rollo_runter room ESPEasy
attr ESPEasy_sz_rollo_rollo_runter setState 3
Dazu kommt, das ich im eventmap nicht mal hin bekomme den namen von z.B. attr ESPEasy_sz_rollo_rollo_hoch eventMap /gpio 12 on:on/gpio 12 off:off/ zu hoch zu ändern. Wenn ich attr ESPEasy_sz_rollo_rollo_hoch eventMap /gpio 12 on:hoch/gpio 12 off:stop/ schreibe, sieht man im Raum einfach garkeinen Button mehr.
Welche Ideen habt Ihr? Was macht man hier sinnvollerweise in Fhem?
Nutze das zwar nicht, aber m.E. dürfte das ROLLO-Modul deine Anforderungen abdecken:
https://wiki.fhem.de/wiki/ROLLO
Hi Beta-User,
sehe meine Rollos gerade nicht aber sieht SW Seitig gut aus.
Du selber nutzt es nicht...warum? (wenn man fragen darf).
An sich kann man mit dem Modul ja auf wirklich sehr einfach Art und Weise alles einstellen, was ich so brauche....
Habe an der Stelle HM-Aktoren im Einsatz. Da brauche ich die Zwischenschicht nicht...
Guten Morgen,
ah -okay. Leider muss ich noch ein wenig auf meine Euronen achten. Aber HM werde ich nächstes Jahr auch verbauen wo es nur geht.
Ich weiß, es ist ggf. nicht üblich aber da es in dem Thread nicht weiter geht, stelle ich die Frage mal hier. Ich bin mir sicher, dass du eine Lösung dafür kennst.
(https://forum.fhem.de/index.php/topic,47202.630.html ---- Antwort #641).
Problem ist in meinen Augen hier das die DOIFs nicht korrekt laufen können. Wenn ich Schalter A betätige wird automatisch Schalter B off gesetzt und A auf on (dies gillt für die Relays und auch die Schalter). In dem Moment versagt bei mir das DOIF für hoch fahren und der Status wird nicht an das Modul übermittelt. Also an sich eine reine Programmier-Sache ohne das man dieses Modul kennen muss. Vielleicht liest das hier ja auch noch @KölnSolar oder ein weiterer guter Programmierer.
Danke aber schon mal für die Idee mit diesem Modul!
Kleine Anmerkung: Ich nutze HM, weil das bei meinem Einstieg in 2014 eben "state of the art" war. Heute würde ich vermutlich ZWave nehmen, jedenfalls, wenn es um eine Lösung ohne Heizkörper geht (es gibt aber zwischenzitlich wohl auch ZWave-FLIRS-Thermostate, die was können).
Was das ROLLO-update angeht: Da gab es jüngst erhebliche Änderungen (schau mal die letzten Post zu Cluni's Rollandesteuerung an); vermutlich ist es das einfachste, die aktuelle Version manuell runterzuladen oder eine Vorversion zu nehmen; aber was da genau geändert wurde usw.: Ich nutze dieses Modul nicht und habe daher auch keine Ahnung...
Was deine nicht funktionierenden DOIF angeht: Auch dieses Modul nutze ich seit geraumer Zeit nicht mehr - ich blicke bei den vielen Attributen einfach nicht durch und kann mir mittlerweile mit Perl soweit behelfen, dass ich notify+Perlcode als deutlich einfacher empfinde. Da kann und mag ich also nicht helfen ;) .
Zu der Anmerkung:
Auch wenn es nicht hier her gehört... ZWave, las ich einiges drüber. Was ist dein Pro oder deine Pros hier? HM ist ja schon sehr lange etabliert.
Das mit dem Update meine ich nicht. Da habe ich keine Probleme, dass manuell zu machen. Den Change habe ich eingesehen.
Okay...Hmmm.... Nicht wollen ist die Aussage, die mir hier sorgen macht :-P
Mir ist es ja vollkommen egal wie es funktionieren würde. KölnSolar empfiehlt auch immer Perl. Ich bin leider noch nicht ganz so weit. Immer neben der Arbeit ein wenig und langsam ran tasten. Kennst du ja vermutlich selber. Vielleicht ließt das ja noch jemand der hier Anstoß liefern kann und möchte :)
Zu ZWave vs. HM:
Vorab: Ich mag es, wenn Dinge "direkt" angebunden sind, also ohne weitere Netzwerkinfrastruktur usw. Daher ist bei mir z.B. HM-IP wegen der Abhängigkeit von einer CCU raus (mir ist bekannt, dass man die auch virtuell auf demselben Rechner betreiben kann, das lindert zwar den Schmerz, beseitigt ihn aber nicht).
Ansonsten sind es zwei Punkte, die für mich relevant sind:
- HMClassic braucht ggf. für eine vernünftige Funkabdeckung mehrere IO's, da hat ZWave mit dem Mesh-Konzept deutlich die Nase vorn.
- ZWave legt einen nicht auf einen bestimmten Hersteller fest. HM BidCos scheint zum einen bei eQ-3 unter "lassen wir irgendwann auslaufen" einsortiert zu sein, zum anderen gibt es keinen Wettbewerb, und so langen die Jungens bei "Nebengeräten" ziemlich zu. Das ist mit der Grund, warum ich Sensorik mittlerweile vorrangig mit MySensors selber aufbaue (das macht nebenbei auch noch Spaß, hätte ich so nicht vermutet, bin fachfremd...)
Zu Perl vs. DOIF: Auch DOIF ist Perl und vollbringt keine Wunder, sondern versteckt nur - je nach Anwendungsfall - einiges an Komplexität vor dem User. Aber auch DOIF entbindet einen nicht von der Last, sich erst mal im klaren zu werden, was man unter welchen Rahmenbedingungen eigentlich erreichen will. Hat man aber sein Problem mal einigermaßen klar in Worte gefaßt, kann man es erfahrungsgemäß auch einfach nach Perl "übersetzen", wenn man mal ein wenig Übung hat. Und Üben muß man auch bei DOIF, wenn man nicht grade in der überbordenden Doku das passende Beispiel findet...
Ich hatte auch erst einige schnelle DOIF definiert und mir irgendwann dann aber zum Ziel gesetzt, diese wieder loszuwerden, nachdem mir aufgefallen war, dass auch die Experten in dem Bereich sich oft nicht einig waren, wie selbst einfache Probleme eigentlich sinnvollerweise zu lösen wären. Das Rauswerfen der DOIF war bei mehr als 3/4 der Fälle recht einfach, in anderen Fällen wollte ich dann aber gleich mehr, weswegen es am Ende fas 1,5 Jahre gedauert hat, bis ich am Ziel war.
Seitdem habe ich zwar eine größere Vielfalt in den eingesetzten Modulen, aber wenn ein "kleines" Modul einen ganz eingeschränkten Zweck hat, ist mir das allemal lieber als eine eierlegende Wollmilchsau, die ich dann für "das bißchen" zurechtbiegen muß. Bin wohl zwischenzeitlich einfach zu sehr Linuxer :) .
Aber wie gesagt: Rom wurde nicht an einem Tag erbaut, und so vorzugehen ist mein Weg. Muß jeder selber wissen...
Danke für deine ausführliche Erklärung!
Habe mal versucht das auf PERL um zu bauen. Ich hoffe das es so klappt. Konnte noch nicht testen, da ich noch nicht zuhause bin.
define az_rollo_manuell_ab notify ESPEasy_az_rollo:strom_output_runter:.* {
if (ReadingsVal("ESPEasy_az_rollo", "strom_output_runter", "") eq "on") && (ReadingsVal("az_rollo", "drive-down", "") ne "drive-down") {
fhem("setreading az_rollo extern closed");;
}
if (ReadingsVal("ESPEasy_az_rollo", "strom_output_runter", "") eq "off") && (ReadingsVal("az_rollo", "drive-down", "") eq "drive-down") {
fhem("setreading az_rollo extern stop");;
}
Gibt es für dieses Konstrukt eine Chance? In meinen Augen sollte es eigentlich genau das gleiche machen wie das hier:
define az_rollo_manuell_ab DOIF ([ESPEasy_az_rollo:strom_output_runter] eq "on" and [az_rollo] ne "drive-down") (set az_rollo extern closed) DOELSEIF ([ESPEasy_az_rollo:strom_output_runter] eq "off" and [az_rollo] eq "drive-down") (set az_rollo extern stop)
Da mir nun immer wieder von verschiedenen Usern hier gesagt wurde, dass PERL einfacher und besser ist und die DOIF Variante leider nicht zu 100% läuft, dachte ich, so sollte es ja gehen.. Wäre die Syntax an sich korrekt?
Zitat von: 87insane am 30 Juli 2018, 14:39:08
Gibt es für dieses Konstrukt eine Chance? In meinen Augen sollte es eigentlich genau das gleiche machen wie das hier:
Das ist doch schon mal kein schlechter Anfang!
M.E. besteht zwar Optimierungspotential, in etwa so:
define az_rollo_manuell_ab notify ESPEasy_az_rollo:strom_output_runter:(on|off) {if ($EVENT eq "on" && ReadingsVal("az_rollo", "drive-down", "") ne "drive-down") {
fhem("set az_rollo extern closed");;
}
elsif ($EVENT eq "off" && ReadingsVal("az_rollo", "drive-down", "") eq "drive-down") {
fhem("set az_rollo extern stop");;
}Kann sein, dass
- vor das (on|off) noch ein Punkt muß und/oder
- die Abfrage nach $EVTPART1 gehen muß, ich kenne den gesamten Event nicht; (da sollte der Event-Monitor-helfen können)
- die ";;" und so weiter noch nicht passen (am besten über die DEF in FHEMWEB gehen, da bekommst du idR. Rückmeldung)
Alles eine Übungsfrage, ich bin im Moment mehr in PerlModul direkt drin, weniger an der Oberfläche...
Aber wenn das DOIF nicht läuft, liegt irgendwo auch noch ein Logikfehler drin, den bekommt man durch die simple Übersetzung dann auch nicht raus. Hier wäre es wichtig zu wissen, unter welchen Rahmenbedingungen etwas nicht funktioniert.
Hi Beta-User,
ich versuche mal eben zu verstehen....
Du hast den Code verkürzt und meine primitive Art und Weise etwas schicker gemacht.
1. ESPEasy_az_rollo:strom_output_runter:(on|off) = Hier willst du ausschließen das andere Events als an und aus mit rein rutschen?
2. ...{if ($EVENT eq ... = Hier steht dann im $Event: ESPEasy_az_rollo:strom_output_runter: on (zum Beispiel)? So das man sich das doppelte schreiben spart.
3. ...elsif ($EVENT... = Hier stelle ich mir die Frage, warum elsif und nicht wie bei mir die weitere if Bedingung. Geht $Event sonst verloren oder hat es einen weiteren / anderen Grund?
Zu deinen "Kann sein, dass´s" - Das bekomme ich hin. Mit dem EventMonitor bin ich schon fleißig unterwegs. Die ;; machen mir auch keine Sorgen.
Das DOIF läuft nur in eine Richtung. Immer wenn ich ein DOIF für runter und eins für hoch schreibe (Rollo Steuerung), dann läuft nur das für runter. Da ich in FHEM selber auch bei der Trocknerprogrammierung schon bemerkt habe, dass immer mal wieder etwas nicht so läuft wie man das gerne hätte oder verstehen würde, sobald man es rein in FHEM programmiert, schien mir die Übersetzung nach PERL schon sehr logisch. Meine Benachrichtigungen usw. sind auch alle von FHEM nach PERL und zurück. Will selber auch ein wenig lernen dabei um dieses Forum irgendwann mal nicht mit jedem Kleinkram nerven zu müssen.
Entschuldige bitte, wenn ich mich hier oder da noch etwas komisch ausdrücke. Auch die Begrifflichkeiten muss ich noch lernen :-\
PS: Bei mir aber auch bei dir fehlt noch eine } nach dem fhem("set az_rollo extern stop");; oder?
Zitat von: 87insane am 30 Juli 2018, 15:20:21
1. ESPEasy_az_rollo:strom_output_runter:(on|off) = Hier willst du ausschließen das andere Events als an und aus mit rein rutschen?
Korrekt, nur "on" oder "off" triggert das notify; wie es aussieht, sollte da tatsächlich ein Punkt dazwischen (statt des Leerzeichens im Event).
Zitat2. ...{if ($EVENT eq ... = Hier steht dann im $Event: ESPEasy_az_rollo:strom_output_runter: on (zum Beispiel)? So das man sich das doppelte schreiben spart.
Nicht ganz, man nutzt die interne Variable, und die sollte eigentlich "on" oder "off" sein, manchmal (vermutlich auch hier) besteht $EVENT aus mehreren Worten, dann nutzt man eben besser die einzelnen Teile (hier: $EVTPART1). Ist nicht nur das doppelte Schreiben, ist auch übersichtlicher, wenn man sich mal dran gewöhnt hat ;) .
Zitat3. ...elsif ($EVENT... = Hier stelle ich mir die Frage, warum elsif und nicht wie bei mir die weitere if Bedingung. Geht $Event sonst verloren oder hat es einen weiteren / anderen Grund?
Das "else" (das in elsif steckt) hat nur den Grund, dass diese Abfrage dann gar nicht mehr gemacht wird, wenn der erste Zweig gewählt wurde. Da sich das sowieso logisch ausschließt, spart es etwas Rechenzeit. außerdem wolltest du ja was lernen ;) ...
Zitat
Das DOIF läuft nur in eine Richtung. Immer wenn ich ein DOIF für runter und eins für hoch schreibe (Rollo Steuerung), dann läuft nur das für runter.
Grundsätzlich finde ich es besser, zusammengehörende Logik auch miteinander zu betrachten. Warum also nicht ein DOIF bzw. ein Notify für beides? Also die Event-Definition so:
ESPEasy_az_rollo:strom_output_(runter|hoch):.(on|off)Dann kannst du nach $EVTPART0 (mit sowas wie =~/runter/) unterscheiden bzw. ggf. Infos auch in eigene Readings von $NAME schreiben, ohne vorher zu wissen, welches von deinen 5 ESPEasy-Geräten denn das Notify aufruft. Du müßtest dann allerdings abfragen, aus welchem Device dann die ReadingsVal gelesen werden sollen. Das geht einfacher, wenn man dann irgendwann auf eigene myUtils ausweicht und z.B. solche Angaben dann in userattr speichert (oder Readings).
Tendenziell würde ich die Fahrtrichtung des Rollos eher bei dem ESP-Device speichern (statt in einem eigenen Dummy dafür?), dann ist einfacher festzustellen, auf welches Device (nämlich $NAME) sich ReadingsVal beziehen soll ;) .
(Und sorry, wenn das jetzt sehr abstrakt klingt. Einfach mal in der commandref nachlesen, was sich hinter den Variablen verbirgt. Helfen kann auch, erst mal einen Log3-Befehl abzusetzen, der die Teile enthält ;) ).
Entschuldige bitte, wenn ich mich hier oder da noch etwas komisch ausdrücke. Auch die Begrifflichkeiten muss ich noch lernen Kein Thema, und ich finde das auch kein bißchen komisch, wie du das schreibst. Wenn man sowas nicht regelmäßig macht, ist die Einarbeitung eher sehr mühsam, und wirklich einfache+gute Beispiele sind nicht so leicht zu finden. Jedenfalls solche an denen man was lernen kann.
Mir hat z.B. Benni's Code für die globale Tür- und Fensterüberwachung sehr weitergeholfen (hier (https://forum.fhem.de/index.php/topic,36504.0.html)).
Das nenne ich doch mal eine super Lehrstunde hier! TOP! DANKE!
EVENTPART usw. hatte ich mir angesehen. Habe es bisher noch nicht so oft verbaut, da ich bisher immer hin ging die Materie als solche zu verstehen.
Solange ich nicht so fit bin was das hier angeht, wollte ich erst mal so runter coden und danach weiter ausbauen. Das macht es mir z.B. einfacher,
Fehleranalyse zu betreiben. Deine letzten Zeilen, alles zu vereinheitlichen und über ein notify laufen zu lassen, wäre meine nächste Instanz. Das
würde ich aber erst machen wollen, wenn ich es in "primitiv" hinbekommen habe. Also erst alles in einfach und dann immer weiter verschönern.
Zu 1) Verstanden. (. für ein Zeichen, .* für Mehrere bzw alles davor/hinter usw.)
2018-07-30 16:49:14 ROLLO az_rollo command: closed
2018-07-30 16:49:14 ROLLO az_rollo desired_pct: 100
2018-07-30 16:49:14 ROLLO az_rollo last_drive: drive-down
2018-07-30 16:49:14 ROLLO az_rollo drive-down
2018-07-30 16:49:14 ROLLO az_rollo drive-type: modul
2018-07-30 16:49:14 ESPEasy ESPEasy_az_rollo gpio 5 1
2018-07-30 16:49:14 ESPEasy ESPEasy_az_rollo strom_output_runter: on
2018-07-30 16:49:14 ESPEasy ESPEasy_az_rollo RSS: -38.00 str: on
Zu 2) Ahhhhh - Da geht mir gerade ein Licht auf bzw. bekomme ich den Aha-Effekt. Logisch... $EVENT = z.B. on und es wird abgefragt ob on = oder != on ist. Weil er muss ja gar nicht " ESPEasy_az_rollo:strom_output_runter: on" wissen wenn er es direkt vergleichen kann. Ich selber gebe ja nur "(ReadingsVal("ESPEasy_az_rollo", "strom_output_runter", "")" ein, da ich sonst nicht direkt an die Variable kommen würde bzw. an das Event. (Die Erkenntnis ist schon mal Gold wert!!).
Zu 3) Logisch, verstanden. (Macht immer Sinn effizienter zu sein)
Zu 4) Ich weiß nicht ob das Rollo Modul da einen weg hat. Diverse Personen melden Fehler mit dieser Funktion. Es geht ja darum, dem Modul mitzuteilen, dass ein physikalischer Schalter benutzt wird, um die Position des Rollos weiter korrekt im Modul nach zu halten. Warum z.B. auch bei getrennten DOIFs nur runter geht, obwohl hoch das gleiche in grün ist, weiß ich leider noch nicht. Will zum einen hier was lernen und zum anderen der Sache auf den Grund gehen.
Zu 5) commandref ... Oh ja und wie ich das commandref am lesen bin. Ab und zu muss ich allerdings kleine "Übungsaufgaben" machen, da es sonst nicht immer verständlich ist. Habe mir extra meinen zweiten Raspi als "Test-Umgebung" aufgebaut.
Zu "Benni's Code für die globale Tür- und Fensterüberwachung" - Werde ich gleich mal lesen und gucken was ich da mitnehmen kann.
Zitat von: 87insane am 30 Juli 2018, 16:27:51
Das nenne ich doch mal eine super Lehrstunde hier! TOP! DANKE!
:)
ZitatZu 4) Ich weiß nicht ob das Rollo Modul da einen weg hat. Diverse Personen melden Fehler mit dieser Funktion. Es geht ja darum, dem Modul mitzuteilen, dass ein physikalischer Schalter benutzt wird, um die Position des Rollos weiter korrekt im Modul nach zu halten. Warum z.B. auch bei getrennten DOIFs nur runter geht, obwohl hoch das gleiche in grün ist, weiß ich leider noch nicht. Will zum einen hier was lernen und zum anderen der Sache auf den Grund gehen.
Das kann ich letztlich nicht beurteilen. Entweder das Modul hat einen Fehler, oder eben die bisherige Logik, um dem Modul zu sagen, was Sache ist. Interessieren würde mich z.B. was passiert, wenn man beim hochfahrenden Rollo die runter-Taste drückt ;) .
zu Commandref:
Na ja, hier ging es est mal um die zu Notify. Die ist ziemlich übersichtlich, aber insbesondere $EVTPART0 etc. ist dort zu finden.
Ansonsten finde ich den Ansatz gut, erst mal klein anzufangen. Dabei ist nur wichtig, die Skalierbarkeit im Auge zu behalten, daher auch an der Stelle bereits die weitergehenden Hinweise ::) .
Das mit dem Hoch und Runter habe ich in der Programmierung des ESPeasy Schalters gelöst.
on rollo_runter#taste_runter do
if [rollo_runter#strom_output_runter]=1
gpio,5,0
else
if [rollo_hoch#strom_output_hoch]=1
gpio,12,0
delay 2000
if [rollo_hoch#strom_output_hoch]=0
gpio,5,1
endif
endOn
Siehe: https://forum.fhem.de/index.php/topic,89136.0.html (https://forum.fhem.de/index.php/topic,89136.0.html)
Das reagiert auf HW aber auch SW Nutzung. Egal von wo ich nun den ersten Befehl gebe, das Rollo bleibt zwei Sekunden lang unbedienbar und zusätzlich bleibt es stehen. Wie man es zB von Gira Schaltern kennt.
Schon. (und der Ansatz, das direkt auf dem Aktor zu machen ist auch gut!)
Aber wie bekommt FHEM die Änderung mit? Also: aktualisiert das ESPEasy-Modul das entsprechende Reading und kommt es dann auch ins Rollo-Modul?
So die Idee....
ESPeasy sagt direkt - Hallo die Taste läuft... Und meldet auch wenn diese wieder ausgeschaltet wurde. Im Wiki vom Rollo Modul steht auch dieser DOIF-Kram aber der klappt leider nicht richtig.
Jeder Tastendruck löst immer direkt genug events aus....
2018-07-30 18:10:32 ESPEasy ESPEasy_az_rollo taste_runter: on
2018-07-30 18:10:32 ESPEasy ESPEasy_az_rollo tas: on
2018-07-30 18:10:32 ESPEasy ESPEasy_az_rollo strom_output_runter: on
2018-07-30 18:10:32 ESPEasy ESPEasy_az_rollo str: on tas: on
2018-07-30 18:10:33 ESPEasy ESPEasy_az_rollo taste_runter: off
2018-07-30 18:10:33 ESPEasy ESPEasy_az_rollo str: on tas: off
2018-07-30 18:10:33 ESPEasy ESPEasy_az_rollo strom_output_runter: off
2018-07-30 18:10:33 ESPEasy ESPEasy_az_rollo str: off tas: off
Nur reagiert mein notify noch nicht. Oder ich nenne es mal lieber unser ;)
Für heute muss ich aufgeben....
1. Rollo fährt runter/hoch und dies wird auch angezeigt.
2. Beim stoppen wird leider nur der Stop Befehl nicht an das Modul gesendet. Es wirkt als würde elsif einfach nie funktionieren. Ich weiß nur leider noch nicht warum.
Anbei mal das Event Log vom runter und hoch fahren:
2018-07-30 18:58:17 ESPEasy ESPEasy_az_rollo taste_runter: on
2018-07-30 18:58:17 ESPEasy ESPEasy_az_rollo RSS: -42.00 tas: on
2018-07-30 18:58:17 ROLLO az_rollo drive-type: extern
2018-07-30 18:58:17 ROLLO az_rollo command: closed
2018-07-30 18:58:17 ROLLO az_rollo desired_pct: 100
2018-07-30 18:58:17 ROLLO az_rollo last_drive: drive-down
2018-07-30 18:58:17 ROLLO az_rollo drive-down
2018-07-30 18:58:17 ESPEasy ESPEasy_az_rollo strom_output_runter: on
2018-07-30 18:58:17 ESPEasy ESPEasy_az_rollo RSS: -42.00 str: on tas: on
2018-07-30 18:58:19 ESPEasy ESPEasy_az_rollo taste_runter: off
2018-07-30 18:58:19 ESPEasy ESPEasy_az_rollo RSS: -42.00 str: on tas: off
2018-07-30 18:58:19 ESPEasy ESPEasy_az_rollo strom_output_runter: off
2018-07-30 18:58:19 ESPEasy ESPEasy_az_rollo RSS: -42.00 str: off tas: off
2018-07-30 18:58:26 ESPEasy ESPEasy_az_rollo taste_hoch: off
2018-07-30 18:58:26 ESPEasy ESPEasy_az_rollo RSS: -42.00 str: off tas: off tas: off
2018-07-30 18:58:26 ROLLO az_rollo drive-type: extern
2018-07-30 18:58:26 ROLLO az_rollo pct: 35.2941176470588
2018-07-30 18:58:26 ROLLO az_rollo command: open
2018-07-30 18:58:26 ROLLO az_rollo desired_pct: none
2018-07-30 18:58:26 ROLLO az_rollo drive-type: na
2018-07-30 18:58:26 ROLLO az_rollo pct-40
2018-07-30 18:58:26 ESPEasy ESPEasy_az_rollo strom_output_hoch: on
2018-07-30 18:58:26 ESPEasy ESPEasy_az_rollo RSS: -42.00 str: on str: off tas: off tas: off
2018-07-30 18:58:27 ROLLO az_rollo last_drive: drive-up
2018-07-30 18:58:27 ROLLO az_rollo drive-up
2018-07-30 18:58:27 ROLLO az_rollo drive-type: modul
2018-07-30 18:58:27 ESPEasy ESPEasy_az_rollo gpio 12 1
2018-07-30 18:58:28 ESPEasy ESPEasy_az_rollo taste_hoch: on
2018-07-30 18:58:28 ESPEasy ESPEasy_az_rollo RSS: -42.00 str: on str: off tas: on tas: off
2018-07-30 18:58:28 ESPEasy ESPEasy_az_rollo strom_output_hoch: off
2018-07-30 18:58:28 ESPEasy ESPEasy_az_rollo RSS: -42.00 str: off str: off tas: on tas: off
Anbei die aktuelle Definition:
define az_rollo_manuell_ab notify ESPEasy_az_rollo:strom_output_runter:.* {\
if ($EVTPART1 eq "on" && ReadingsVal("az_rollo", "drive-down", "") ne "drive-down") {\
fhem("set az_rollo extern closed");;;;\
}\
elsif ($EVTPART1 eq "off" && ReadingsVal("az_rollo", "drive-down", "") eq "drive-down") {\
fhem("set az_rollo extern stop");;;;\
}\
}
define az_rollo_manuell_auf notify ESPEasy_az_rollo:strom_output_hoch:.* {\
if ($EVTPART1 eq "on" && ReadingsVal("az_rollo", "drive-up", "") ne "drive-up") {\
fhem("set az_rollo extern open");;;;\
}\
elsif ($EVTPART1 eq "off" && ReadingsVal("az_rollo", "drive-up", "") eq "drive-up") {\
fhem("set az_rollo extern stop");;;;\
}\
}
Diese ist beabsichtigt nach den ganzen Tests mit .* - Damit mir das nicht auf einmal den Fehler macht.
Leider ist es recht schwer zu durchschauen, wo da was herkommt an Auswirkungen etc..
Ggf. könntest du die Zweige jeweils noch mit einem aussagefähigen Log-Befehl versehen, dann siehst du hinterher im Log, welcher Zweig durchlaufen wird. Dazu würde ich den elsif-Befehl auftrennen und mit "else {" beginnen, dann den Log-befehl, dann das "if"...
Manchmal sind auch schlicht die Zeitstempel hilfreich, wann ein Reading aktualisiert wurde; manchmal hilft es, das Reading nicht mit einem Wert zu füllen, der auch woanders herkommen kann (z.B. so: "set az_rollo extern notify_Zweig1")
Hi und guten Mittag,
genau da hab ich gestern auch abgebrochen. Hab ein wenig probiert und in beiden Fällen (hoch und runter), leider keine STOP Funktion. Das Rollo an sich stoppt natürlich aber das Modul bekommt es nicht mit. Somit ist der pct natürlich falsch im Modul.
Eine sehr gute Idee mal wieder. Hab ich gestern auch schon dran gedacht mal ein wenig zu loggen. Mich ärgert es nur, es nicht so zu verstehen.
Ich glaube (Vermutungs-Modus aktiviert),
elsif ($EVTPART1 eq "off" && ReadingsVal("az_rollo", "drive-down", "") eq "drive-down") {\
fhem("set az_rollo extern stop");;;;\
$EVTPART ist in diesem Moment falsch. Das werde ich aber auch erst heute Abend oder nächste Woche testen können. (Leider) bin ich ab morgen Abend im Urlaub. Ich hab solche Dinge immer gern abgeschlossen vorher.
Im Event Log sehe ich ja wann die aktualisiert wurden. Das deckt sich mit den Readings.
Das Reading in az_rollo, denke ich so lassen zu müssen. Dies ist ja im Modul vorgegeben und ich habe die .pm nicht auseinander genommen bisher.
Der Ersteller des Modules hat sicher die beiden Werte drive-down/up an mehreren Stellen verankert und soweit bin ich noch nicht....
Das Event Log zeigt ja z.B.
2018-07-30 18:58:17 ROLLO az_rollo last_drive: drive-down
2018-07-30 18:58:17 ROLLO az_rollo drive-down
ROLLO az_rollo last_drive: drive-down / Hier ist Modul, Gerätename, Reading, Reading-Inhalt
ROLLO az_rollo drive-down / Hier ist Modul, Gerätename, und auf einmal einfach drive down. Das verstehe ich ehrlich gesagt nicht ganz. So als ob drive-down nirgendwo wirklich hingeschrieben wird.
Was sagst du dazu?
In dem Moment wo else geprüft wird, müssen beide Werte stimmen. Und genau da wird der Hase im Pfeffer liegen (denke ich).
Mahlzeit!
Vermutungs-Modus ein: Du solltest nicht auf das Reading "drive-down" zugreifen, sondern auf "last_drive"?!? (Oder auf STATE vom Rollo, also Value()).
Ich würde die Events so interpretieren, dass das Reading "last_drive" gefüllt wird und das dann in "state" kommt, von wo es nach STATE geht...
Schau dir mal das list von az_rollo an, da sollte zu sehen sein, was ggf. Sinn macht.
Das ist es ja... Das ergibt für mich noch weniger Sinn..
List wenn es steht:
Internals:
CFGFN ./FHEM/ESPeasy.cfg
NAME az_rollo
NR 69
STATE open
TYPE ROLLO
stoptime 1533018863
OLDREADINGS:
READINGS:
2018-07-31 08:34:19 command open
2018-07-31 08:34:57 desired_pct 0
2018-07-31 08:34:23 drive-type na
2018-07-31 08:34:19 last_drive drive-up
2018-07-31 08:34:57 pct 0
2018-07-31 08:34:57 state open
Attributes:
autoStop 0
commandDown set ESPEasy_az_rollo gpio 5 1
commandStopDown set ESPEasy_az_rollo gpio 5 0
commandStopUp set ESPEasy_az_rollo gpio 12 0
commandUp set ESPEasy_az_rollo gpio 12 1
devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop pct-100:fts_shutter_100:open pct-90:fts_shutter_80:closed pct-80:fts_shutter_80:closed pct-70:fts_shutter_70:closed pct-60:fts_shutter_60:closed pct-50:fts_shutter_50:closed pct-40:fts_shutter_40:open pct-30:fts_shutter_30:open pct-20:fts_shutter_20:open pct-10:fts_shutter_10:open pct-0:fts_shutter_10:closed
excessBottom 2
excessTop 4
resetTime 0
room ESPEasy
secondsDown 17
secondsUp 18
switchTime 1
type normal
webCmd open:closed:half:stop:pct
List wenn es fährt: (allerdings hier nur per FHEM da ich nicht zuhause bin):
Internals:
CFGFN ./FHEM/ESPeasy.cfg
NAME az_rollo
NR 69
STATE drive-down
TYPE ROLLO
stoptime 1533036977
OLDREADINGS:
READINGS:
2018-07-31 13:35:54 command closed
2018-07-31 13:35:54 desired_pct 100
2018-07-31 13:35:54 drive-type extern
2018-07-31 13:35:54 last_drive drive-down
2018-07-31 13:35:54 pct 0
2018-07-31 13:35:54 state drive-down
Attributes:
autoStop 0
commandDown set ESPEasy_az_rollo gpio 5 1
commandStopDown set ESPEasy_az_rollo gpio 5 0
commandStopUp set ESPEasy_az_rollo gpio 12 0
commandUp set ESPEasy_az_rollo gpio 12 1
devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop pct-100:fts_shutter_100:open pct-90:fts_shutter_80:closed pct-80:fts_shutter_80:closed pct-70:fts_shutter_70:closed pct-60:fts_shutter_60:closed pct-50:fts_shutter_50:closed pct-40:fts_shutter_40:open pct-30:fts_shutter_30:open pct-20:fts_shutter_20:open pct-10:fts_shutter_10:open pct-0:fts_shutter_10:closed
excessBottom 2
excessTop 4
resetTime 0
room ESPEasy
secondsDown 17
secondsUp 18
switchTime 1
type normal
webCmd open:closed:half:stop:pct
Last Drive ist immer das was als letztes passiert ist.
Auf der Wiki Seite https://wiki.fhem.de/wiki/ROLLO (https://wiki.fhem.de/wiki/ROLLO)
steht ja das Verfahren mit DOIF:
define rollo_manuell_auf DOIF ([meinRollo_Kanal1] eq "on" and [meinRolloModul] ne "drive-up") (set meinRolloModul extern open) DOELSEIF ([meinRollo_Kanal1] eq "off" and [meinRolloModul] eq "drive-up") (set meinRolloModul extern stop)
define rollo_manuell_ab DOIF ([meinRollo_Kanal2] eq "on" and [meinRolloModul] ne "drive-down") (set meinRolloModul extern closed) DOELSEIF ([meinRollo_Kanal2] eq "off" and [meinRolloModul] eq "drive-down") (set meinRolloModul extern stop)
Da habe ich mich doch nichts vertauscht??? oO
Hatte mich daran gehalten....Nur das hier kein DOIF läuft sondern eben notify.
So langsam sehe ich den Wald vor lauter Bäumen nicht mehr. Runter und hoch an sich klappt ja wunderbar mit der notify Lösung. Bin gespannt ob ich nachher stop zum laufen bekomme. Sonst wird der UL eher doof :-P
Zitat von: Beta-User am 31 Juli 2018, 13:25:36
auf STATE vom Rollo, also Value()
Nimm mal Value("az_rollo") statt des ReadingsVal(...), dann sehen wir weiter.
Ahhh - Da oben bist du. macht beim lesen jetzt schon Sinn.
Allerdings kann ich das erst am späten Nachmittag testen. Wird also erst mal still hier....
Dann ist meine Übersetzung ja schon falsch. Bei genauem betrachten wird das so sein.
ReadingsVal geht nur beim runter fahren da ja da auch noch nichts ist bzw. das Ergebnis immer ungleich ist. Somit ist es auch nur Glück das runter fahren läuft.
Wo ist der Smilie der sich selber gegen den Kopf haut!? Danke schon mal. Werde berichten...
Zitat$EVENT = z.B. on und es wird abgefragt ob on = oder != on ist
Vorsicht, Vergleichsoperatoren für Strings sind "eq" und "ne"
LG
pah
Guten Morgen zusammen....
die vergleichsoperatoren sind mir bekannt. Siehe Quelltext oben.
Habe nun mit Value getestet. Hoch und runter läuft nun. Allerdings habe ich das gefühl, das das Rollo Modul nicht korrekt rechnet was die Position des Rollos angeht. Bedeutet das wenn ich mit den Schaltern arbeite und dann mit fhem, ist zb hoch fahren auf die höchste Position nicht wirklich die höchste Position.
Vermutlich liegt das an dem minimalem Delay zwischen dem aktiven schalten und dem senden an fhem des schalters. Muss ich nach meinem Urlaub genauer untersuchen.
Gesendet von meinem LG-H850 mit Tapatalk
Danke für die Rückmeldung zu Value().
Leider scheint das Rollo-Modul keine Einstellung für eine typiche Verzögerung zwischen physischem Tastendruck und der "Ankunft" in FHEM zu kennen und auch eventuelle interne Verzögerungen scheinen keine Rolle zu spielen. Da wäre evtl. room for improvement ;) .
Aber allgemein: die meisten Rolladenaktoren arbeiten intern zeitgesteuert, und das paßt dann nach einigen Schaltvorgängen praktisch nie (auch nicht bei den HM-Aktoren), insbesondere, wenn der Rolladen aufgerollt wird (kann man auch für Jalousien verwenden, da besteht das Problem der zunehmenden Dicke der "Welle" nicht). In solchen Fällen empfielt es sich, hin und wieder eine "Kalibrierungsfahrt" einzuplanen, also den Rolladen einmal ganz (ganz!) hochzufahren (oder runter).
Kommt halt auch drauf an, wie oft der Rolladen manuell gefahren wird (vielleicht magst du dir Clunis Code mal zu Gemüte führen). Kommt das oft vor, könnte es einen Test wert sein, die Fahrzeiten im Rollo-Modul etwas zu verlängern (oder den C-Code auf dem ESP anzufassen und dort einen Prozentwert zu errechnen; theoretisch könntest du da dann sogar Wicklungseffekte optional berücksichtigen ;D . Aber vermutlich ist das dann ein Projekt für das Jahr 2021, wenn sich bis dahin niemand erbarmt hat, eine Vorlage dafür zu machen ::) .)
Schönen Urlaub!
Hey,
Ich meine in dem Modul kann man so eine Art Delay eingeben. Muss ich aber noch mal mach sehen. Es ist aber schon ein großer bzw sehr schöner Erfolg das es so funktioniert. Und ich danke dir !!! Also auf ein bier bist du immer willkommen ;)
Gesendet von meinem LG-H850 mit Tapatalk
Zum delay habe ich nur kurz ins Wiki gesehen (ist ja nicht im svn, das Modul), kann also sein, dass da mehr geht, als im Wiki steht.
Zitat von: 87insane am 01 August 2018, 16:20:40Also auf ein bier bist du immer willkommen ;)
Gerne, allerdings bin ich eher selten in deiner Gegend. Aber wenn das klappen sollte, will ich in jedem Fall den generalisierten Code für Hoch- und Runter-Tasten in Aktion sehen ;) . Natürlich nur, wenn er bis dahin nicht schon im Wiki steht (oder sich im Code des Moduls findet, so dass man nur noch die beiden (oder mehrere?) Tasten (Gerät:Reading) und das Eventpaar (on|off) als Attribute angeben muß?)
Welcome to Perl! 8) 8) 8)