[GELÖST] Slider für Schaltung von GPIO basierend auf Zeit

[87insane]

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.

Code Auswählen Erweitern

# 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?

[Beta-User]

Nutze das zwar nicht, aber m.E. dürfte das ROLLO-Modul deine Anforderungen abdecken:

https://wiki.fhem.de/wiki/ROLLO

[87insane]

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

[Beta-User]

Habe an der Stelle HM-Aktoren im Einsatz. Da brauche ich die Zwischenschicht nicht...

[87insane]

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!

[Beta-User]

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 .

[87insane]

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

[Beta-User]

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

[87insane]

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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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?

[Beta-User]

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:

Code Auswählen Erweitern

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.

[87insane]

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?

[Beta-User]

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

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.

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 .

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?

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

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[87insane]

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

Code Auswählen Erweitern

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.

[Beta-User]

Das nenne ich doch mal eine super Lehrstunde hier! TOP! DANKE!

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.

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 .

[87insane]

Das mit dem Hoch und Runter habe ich in der Programmierung des ESPeasy Schalters gelöst.

Code Auswählen Erweitern

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

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.