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

Begonnen von 87insane, 24 Juli 2018, 12:35:08

Vorheriges Thema - Nächstes Thema

Beta-User

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

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

87insane

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

Beta-User

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")
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

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

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

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

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

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

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

Prof. Dr. Peter Henning

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

87insane

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


Beta-User

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!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

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


Beta-User

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)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors