Brauche Hilfe bei der Automatisierung von Rolläden (SOMFY)

Begonnen von Joker2002, 13 April 2015, 21:07:26

Vorheriges Thema - Nächstes Thema

Joker2002

Hallo liebe FHEM Comunity,

ich beschäftige mich erst seit einer kurzen Zeit mit FHEM daher bitte ich um Nachsicht :)

Ich habe es endlich geschafft FHEM auf einem Raspberry Pi2 in Verbindung mit einem CUL Stick V3.4 zum Laufen zu bringen. Nachdem ich die erste Hürde, die Rollläden von Somfy in FHEM einzubinden genommen habe, würde ich nun gerne eine Zeitschaltung zu realisieren. Ich hätte gerne, dass meine Rollläden mit dem Sonnenstand (dieser wird über das Weather/Wetter Modul realisiert) hoch bzw. runterfahren.
Ich habe mir dazu entsprechend das entsprechende ,,Heimautomatisierung-mit-fhem" PDF durchgelesen und meine Rollläden zu einer Gruppe namens ,,Somfy" zusammengeführt.
Anschließend wollte ich das Hochfahren der Rollläden definieren:
define somfy DOIF ([{sr()}]) (set somfy off, attr somfy wait {(600)} if ($we) {fhem("set rollo_OG_Z1, rollo_OG_Z2_tuer off at 09:00"})

bzw. das runterfahren der Rollos nach Sonnenuntergang mit Verzögerung von 10 Minuten realisieren:

define Somfy DOIF ([{ss()}]) (set Somfy on, attr Somfy wait {(600))})

Ich erhalte jedoch imer einer Fehlermeldung mit der ich so gar nichts anfangen kann.

Fehlermeldung:

Somfy DOIF: the at function "ss()" must return a timespec and not Undefined subroutine &main::ss called at (eval 566) line 1.
.: {ss()}

Könnt Ihr mir vielleicht weiterhelfen ?



Pfriemler

Von sr() und ss() höre ich das erste Mal ... liefert unpassendes Format für die DOIF-Zeitbestimmung.
Zum DOIF gibt's haufenweise Beispiele auch im ZUsammenhang mit Sonnenuntergang etc. in der deutschen commandref ...
set a,b off at xx:xx? Was ist das denn?
"somfy" ist eine structure oder was? eine andere Möglichkeit, mehrere Geräte mit einem Befehl zu steuern, kenne ich (bisher noch) nicht.
Ein attr xy group z dient nur zu Anzeigesortierzwecken ...
Wieso setzt Du die Verzögerung nach dem Schaltbefehl?
Abgesehen davon solltest Du Dein Anliegen konsequent DOIF-gemäß formulieren und umsetzen ... also alles in ein DOIF und alle möglichen Kombinationen in separaten DOELSEIFs ausformulieren, also
DOIF (Sonnenaufgang und kein Wochenende) (tue das)
DOELSEIF (Sonnenaufgang und Wochenende (tue das)
DOELSEIF (Sonnenuntergang)(tue das)
mit attr wait für die jeweiligen Zustände ...

Jm2c.

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Hallo Pfriemler,

vielen Dank für Deine schnelle Antwort. Wie gesagt, ich betrete mit FHEM Neuland und kenn mich mit der Materie noch nicht gut aus. Ich habe zwar schon viel gelesen, manches kann ich jedoch nicht nachvollziehen.
Ich werde mal schauen ob ich mit Deinem Rat eine brauchbare Automatisierung basteln kann :)

Danke

Pfriemler

#3
Dein Ansatz ist ja prinzipiell verständlich, halt nur von hinten durch die Brust ins Auge. Ich meinte ja nur: Wenn schon DOIF, dann doch richtig.
Ganz prinzipiell: Bevor Du Automatisierungen bastelst, versuche die Aktionen zuerst auf der Kommandozeile auszuführen. Führt denn "set somfy on" bzw. "set somfy off" bei Dir zu einer Aktion?
Falls Du nicht zuviele Rolläden hast, ist das Setzen mehrerer Rolläden mit einer "Gruppe" (also einer Structure) vielleicht overkill - schreibe sie einfach direkt in den Ausführungsteil hinein.
Für alle Fragen zum DOIF selbst bist Du im Unterforum "Automatisierung" besser aufgehoben.
Im Detail:
define somfy DOIF ([{sr()}]) (set somfy off, attr somfy wait {(600)} if ($we) {fhem("set rollo_OG_Z1, rollo_OG_Z2_tuer off at 09:00"})
a) Du verwendest als Namen für das DOIF einen Begriff, der offenbar ein Device oder eine Structure benennt (siehe "set somfy ...") Das ist der erste Fehler
b) das Attribut "wait" zum DOIF gibst Du einmalig auf der Kommandozeile bei der Definition ein, es hat in der Definition des DOIF nichts verloren.
    Ich würde aber vielmehr nicht den Zustandswechsel des DOIF verzögern, sondern den Trigger selbst
Das sähe also z.B. so aus (gefundene Tippfehler darf man behalten):
define di_SomfyZeitsteuerung DOIF ([{sunrise(600)}|7] or [09:00|7])(set rollo_OG_Z1 off, set rollo_OG_Z2_tuer off)
schaltet 600s nach dem Sonnenaufgang und am Wochenende oder Feiertagen oder (also evtl. spätestens) um 9 Uhr an Wochenenden und Feiertagen rollo_OG_Z1 und ~Z2 "off", vermutlich ist das der Hochfahren-Befehl. |7 entspricht quasi "$we", |8 wäre das Gegenteil, also "!$we" - siehe commandref zum DOIF
Befehle zum Öffnen an Nicht-Wochenenden und zum Schließen fügst Du wie erwähnt mit DOELSEIF im gleichen DOIF an. Im Def-Editor kannst Du wunderbar mit Leerzeichen und Leerzeilen strukturieren, also etwa
([{sunrise(600)}|7] or [09:00|7])
    (set rollo_OG_Z1 off,
     set rollo_OG_Z2_tuer off)
DOELSEIF ([{sunset(600)}])
    (set rollo_OG_Z1 on,
     set rollo_OG_Z2_tuer on)   

usw. Viel Spaß - je lesbarer, umso mehr freust Du Dich später bei Änderungen!
BTW: Negative Sekundenangaben bei sunrise und sunset verschieben die Ausführung nach vorn, also vor.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Vielen Dank für Deine Hilfe. Ich habe mich heute nochmal mit dem Thema "Automatisierung" auseinandergesetzt und das PDF und die Wiki gewählt. Herausgekommen ist hierbei folgende Struktur:

define di_Rollaeden_hoch DOIF ([[LichtWetter:sr_weather]|8])(set rollo_kue, rollo_OG_Z1, rollo_OG_Z2_tuer, rollo_OG_Z3, rollo_OG_Z4_tuer, rollo_OG_Z5, rollo_OG_Z6, rollo_wz_1, rollo_wz_2_tuer, rollo_wz_3 off) DOELSEIF ([09:00|60])(set rollo_OG_Z1, rollo_OG_Z2_tuer off)
attr di_Rollaeden_hoch wait 300



define di_Rollaeden_runter DOIF ([[LichtWetter:ss_weather]])(set rollo_kue, rollo_OG_Z1, rollo_OG_Z3, rollo_OG_Z5, rollo_OG_Z6, rollo_wz_1, rollo_wz_3 on)
attr di_Rollaeden_runter wait 600


define di_Rollaeden_Tuer_runter DOIF ([[LichtWetter:ss_weather]])(set rollo_OG_Z2_tuer, rollo_OG_Z2_tuer, rollo_OG_Z4_tuer, rollo_wz_2_tuer on)
attr di_Rollaeden_Tuer_runter wait 1200

FHEM hat die Angaben soweit auch ohne Fehler geschluckt nur fahren die Rollos irgendwie nicht runter. Was mache ich jetzt falsch ?? Das ist echt schwierig...

Pfriemler

Liefern deine Trigger Zeitpunkte? Oder Werte? In den Interna des Doifs werden die im voraus berechneten Triggerzeiten angezeigt.

geht nich Gips nich ...

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Pfriemler

Und wenn du mehrere Aktoren aufzählst, darf kein Leerzeichen stehen, zudem musst du Befehle mit Kommas zusätzlich klammern, weil DOIF sie an den Kommas sonst auseinander  reißt.  Und guck ins Log, da sind bestimmt Fehler gemeldet.

geht nich Gips nich ...

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

besten Dank für Deine Hilfe,

ich habe den Fehler gefunden (denke ich zumindest), denn heute Morgen gingen (fast) alle Rollläden hoch.
Der Fehler liegt wahrscheinlich im Code denn so funktionierte es nicht:

(set rollo_kue, rollo_OG_Z1, rollo_OG_Z2_tuer, rollo_OG_Z3, rollo_OG_Z4_tuer, rollo_OG_Z5, rollo_OG_Z6, rollo_wz_1, rollo_wz_2_tuer, rollo_wz_3 off)

erst als ich jeden Aktor mit set.... off bzw. set...on benannt habe lief es :)

Ich werde die nächsten Tage mal beobachten ob FHEM auch weiterhin brav die Rollläden hoch und runter fährt, ansonsten melde ich mich nochmal. Vielen lieben Dank für Deine Hilfe :O)

Pfriemler

Wie ich ja bereits sagte: DOIF kloppt die Zeilen auseinander, weil Kommas eine Trennung darstellen

Aus
(set rollo_kue, rollo_OG_Z1, rollo_OG_Z2_tuer, rollo_OG_Z3, rollo_OG_Z4_tuer, rollo_OG_Z5, rollo_OG_Z6, rollo_wz_1, rollo_wz_2_tuer, rollo_wz_3 off)


sendet das DOIF also nacheinander diese Befehle an FHEM:
set rollo_kue
rollo_OG_Z1
rollo_OG_Z2_tuer
rollo_OG_Z3
...
rollo_wz_3 off

Das sind alles keine gültigen Befehle.

Mein Vorschlag wäre
((set rollo_kue,rollo_OG_Z1,rollo_OG_Z2_tuer,rollo_OG_Z3,rollo_OG_Z4_tuer,rollo_OG_Z5,rollo_OG_Z6,rollo_wz_1,rollo_wz_2_tuer,rollo_wz_3 off))

also ohne Leerzeichen in der Aufzählung und mit doppelten Klammern, damit DOIF den Inhalt als zusammenhängenden Befehl versteht.

Zitaterst als ich jeden Aktor mit set.... off bzw. set...on benannt habe lief es :)
Natürlich.
Und danke für's Danke. Sehe ich nämlich nicht immer als Reaktion ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Ah, jetzt weiß ich was Du damit meinst. Ok. Das werde ich berücksichtigen. Ich hatte den Feher mit set..off bzw. set.. on bemerkt nachdem im Log File entsprechende Meldungen zu sehen waren. Habe das jetzt so schön strukturiert wie Du es in Deinem Beispiel angegeben hattest (wusste bis dato nicht dass man die DOIFS auch entsprechend editieren kann). Aber ich lerne mit jedem DOIF dazu :)

Danke ! :)

Joker2002

#10
So, jetzt muss ich noch was fragen :)
Ich habe heute an einer Automatisation für die Sommertage gearbeitet. Ich hätte gerne, dass die Rollläden und die Markise auf eine bestimmte Position fahren, bzw. ausfahren wenn mein TCM Außensensor gegen 10.00 Uhr eine Temperatur von 26 Grad meldet. Gegen 19.00 Uhr soll die Markise jedoch wieder einfahren; egal wie warm es zu dieser Zeit noch ist. Hierzu habe ich mich an das Beispiel in der Wiki von FHEM gehalten und folgende Zeilen verfasst:

define di_Rollo_Sonne_Hinten DOIF ([[TCM_Aussen]] > T:26 and [10:00-[[LichtWetter:ss_weather]]]) ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z2_tuer,rollo_OG_Z3,rollo_OG_Z4_tuer,rollo_OG_Z5,rollo_OG_Z6,rollo_wz_1,rollo_wz_2_tuer,rollo_wz_3 pos 50)) (set rollo_markise on) DOELSE ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z2_tuer,rollo_OG_Z3,rollo_OG_Z4_tuer,rollo_OG_Z5,rollo_OG_Z6,rollo_wz_1,rollo_wz_2_tuer,rollo_wz_3, rollo_markise off)) [19:00-[[LichtWetter:ss_weather]]]) (set rollo_markise off)

Hier erhalte ich im Logfile folgende Fehlermeldung:
di_Rollo_Sonne_Hinten DOIF: Wrong timespec T: 18.7 H: 20: either HH:MM:SS or {perlcode}: [TCM_Aussen]

Was mag er an den Temperaturangaben nicht ?

Joker2002

ich sehe gerade im Logfile bezüglich der Rollos immer folgende Fehlermeldung:

2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_kue off: sAA20000A000004
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_OG_Z1 off: sAC20000C000006
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_OG_Z2_tuer off: sAD20000D000007
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_OG_Z3 off: sAD20000D000008
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_OG_Z4_tuer off: sA0200010000009
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_OG_Z5 off: sA9200009000010
2015.04.15 06:39:08 2: di_Rollaeden_hoch: ser rollo_OG_Z6 off: Unknown command ser, try help.
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_wz_1 off: sAE20003E000001
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_wz_2_tuer off: sA3200013000002
2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_wz_3 off: sAC20000C000003

was hat das zu bedeuten ?

Pfriemler

Zitat von: Joker2002 am 15 April 2015, 21:29:30
Was mag er an den Temperaturangaben nicht ?
Weil DOIF sie als Zeitangaben betrachtet? Wegen des Doppelpunkts?
Poste mal ein List vom Sensor, also "list TCM_Aussen" auf der Kommandozeile. Du wertest den State aus, der offenbar "T: 18.7 H: 20" heißt.
Wir müssen ein anderes reading finden.

Zitat2015.04.15 06:39:08 1: SOMFY_set: Error - drivetime and updatetime = 0
2015.04.15 06:39:08 2: SOMFY set rollo_kue off: sAA20000A000004
Keine Ahnung, weil ich SOMFY nicht kenne.

Jemand anderes?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Puschel74

Zitat von: Pfriemler am 16 April 2015, 20:37:45
Keine Ahnung, weil ich SOMFY nicht kenne.

Jemand anderes?
z.B. der passende Beitrag zu SOMFY  ???
http://forum.fhem.de/index.php/topic,24158.0.html

@Joker: Deine Beiträge wären auch lesbarer wenn du die Tags benutzen könntest.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Pfriemler

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Puschel74

Zitat von: Pfriemler am 16 April 2015, 20:41:03
Damit dürften wir den TE erst in zwei Wochen wiedersehen  ::)
Soll ich jetzt die passenden Seiten auch noch raussuchen  ???
Wobei auch die Suchfunktion helfen würde (aber darauf darf man ja nicht verweisen).
Aber auch andere mussten sich einlesen und leben noch, es sollte dem TE also nicht schaden.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Pfriemler

Ach, und

Zitat von: Joker2002 am 15 April 2015, 21:49:04
2015.04.15 06:39:08 2: di_Rollaeden_hoch: ser rollo_OG_Z6 off: Unknown command ser, try help.

erklärt sich doch wohl von selbst?


P.S.: Tippfehler

@Puschel: Nein, sollst Du nicht. Ich meine nur, mit 34 Seiten ist man dann schon eine Weile absorbiert, aber die Lektüre schadet in keinem Fall.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

ZitatInternals:
   CODE       132
   CUL_0_MSGCNT 743
   CUL_0_RAWMSG s8441D004A00D
   CUL_0_TIME 2015-04-16 21:23:10
   DEF        132
   LASTInputDev CUL_0
   MSGCNT     743
   NAME       TCM_Aussen
   NR         50
   RSSI       -67.5
   STATE      T: 18.5 H: 20
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1429212190
   Readings:
     2015-04-15 21:54:14   battery         ok
     2015-04-16 21:23:10   humidity        20
     2015-04-16 21:23:10   state           T: 18.5 H: 20
     2015-04-16 21:23:10   temperature     18.4
Attributes:
   model      TCM21....
   room       TCM

ok, habe den Befehl eingegeben, das spuckt er aus :)

Joker2002

Zitat2015.04.15 06:39:08 2: di_Rollaeden_hoch: ser rollo_OG_Z6 off: Unknown command ser, try help.
jap, das habe ich schon korrigiert :)

Joker2002

Zitatz.B. der passende Beitrag zu SOMFY  ???
http://forum.fhem.de/index.php/topic,24158.0.html
Danke für den Hinweis. Den Threat kenne ich auch und habe ihn auch bevor ich mich an FHEM gemacht habe, gelesen, jedoch gibt es hierzu keine Erklärung (zumindest habe ich keine gefunden)  :-\

Puschel74

Und so wie das Einsteiger.pdf und die angepinnten Beiträge darf man sich auch andere Beiträge gerne öfter durchlesen.
Wo wenn nicht dort wird SOMFY behandelt?
Und es sind doch eindeutig Meldungen zu fehlerhaften Fahrzeiten.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Pfriemler

#21
Zitat von: Joker2002 am 16 April 2015, 21:26:16
ok, habe den Befehl eingegeben, das spuckt er aus :)
  Readings:
     2015-04-15 21:54:14   battery         ok
     2015-04-16 21:23:10   humidity        20
     2015-04-16 21:23:10   state           T: 18.5 H: 20
     2015-04-16 21:23:10   temperature     18.4
Siehste, ist doch alles da.
Und in der Commandref zum DOIF steht, wie man readings gezielt abfragt:
define di_shutters DOIF ([sensor:temperature] > 26 and [11:00-{sunset_abs()}] (set shutters down) DOELSE (set shutters up)


Wenn Du das verstanden hast, inkl. der Zahl der erforderlichen Klammerebenen, findest Du allein die Lösung. Und glaub uns, das schult mehr als copy&paste.

Und wenn Puschel74 meint,
ZitatUnd es sind doch eindeutig Meldungen zu fehlerhaften Fahrzeiten.
dann dürfte Deine Moduldefinition noch fehlerhaft sein, also bringe das in Ordnung inkl. Test einer manuellen Ansteuerung auf der Kommandozeile, bevor Du die Automatisierung dazu baust. Das ist immer die richtige Reihenfolge. Viel Erfolg!

edit:
Ich habe gerade mal im Forum gesucht und etliche Treffer zur Fehlermeldung gefunden (sogar in in einem Fred in dem DU geantwortet hast!), aber eine wirkliche Lösung offenbart sich mir über die Suche nicht.
Kosmetisch hilft offenbar http://forum.fhem.de/index.php/topic,34078.msg264511.html#msg264511 ...
editedit:
Hilft http://forum.fhem.de/index.php/topic,28107.msg272923.html#msg272923 weiter? Oder die Commandref? Zeiten alle richtig?

Hätte fast mal Dachrollos mit SOMFY bekommen und hätte mich dann genauso einarbeiten müssen, aber bisher bei mir alles graue Theorie.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Danke erstmal für die Hilfe,
ich weiß, ich muss noch viel lesen um zu verstehen nur ist es eben für mich als Laie sehr schwierig die "kryptischen" Fehler zu verstehen. Ich arbeite aber dran  ;)

Puschel74

Das
Zitat2014.11.28 16:57:24 1: SOMFY_set: Error - drivetime and updatetime = 0
habe ich hier
http://forum.fhem.de/index.php/topic,24158.msg224523.html#msg224523
in diesem Thread
http://forum.fhem.de/index.php/topic,24158.0.html
gefunden - ja, das ist der SOMFY-Thread.

Da ich dir einen der Beiträge schon rausgesucht habe wirst du es jetzt vermutlich leichter haben die Beiträge davor und danach zu
lesen.

Zitatdann dürfte Deine Moduldefinition noch fehlerhaft sein,
Das Modul selbst dürfte korrekt definiert sein.
Das Problem machen die Readings die korrekt gesetzt werden sollten/müssten.

Da ich aber noch mit einer der ersten Versionen der Somfy.pm arbeite habe ich diese Meldungen nicht.
Und ich habe auch nicht vor meinen Rollo-RasPi dahingehend auf den neuesten Stand zu bringen.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Pfriemler

Ein bisschen OT...
Da ich mal ein paar Minütchen Zeit hatte, habe ich interessehalber mal gestöbert in den Freds. Den ganzen Somfy-Fred durchzulesen halte ich demnach für einen Overkill. Klar hilft die Sufu (dass man darauf hier nicht verweisen darf, war mir neu, ich werde mich dran halten  ;D).
Spaß beiseite. Mein Eindruck (und das ist nicht das erste Mal mit FHEM): Es gibt etwa ein halbes Dutzend konkrete Nachfragen, aber nirgend wirklich ein eindeutiger Hinweis auf das Problem. Kennt man die Problemstellung selbst hinlänglich gut, liegt die Lösung oft klar auf der Hand und die Fragen weniger erfahrener Leute wundern einen dann nur. Ich kann zum Beispiel auch nicht verstehen, was man an einem DOIF nicht verstehen kann, und doch füllen die Fragen das Forum. Für einen Newbie sind die Lösungen aber eben oft leider ziemlich gut versteckt, teilweise wiederum zu offensichtlich und überraschend simpel. Eine HomeMatic-CCU2 zu programmieren ist dagegen wirklich Kindergarten.

Im konkreten Beispiel lassen die Fehlermeldungen SOMFY_set: Error - drivetime and updatetime = 0 doch darauf schließen, dass die per attr anzugebenden Fahrzeiten so sind, dass sich bei der Kalkulation intern unsinnige Werte ergeben (und das wäre für mich dann sehr wohl eine fehlerhafte Moduldefinition, um mal begriffshaarspalterig zu sein). Dankenswerterweise spricht die commandref (und das ist für mich genau der Ort, an dem man zuerst nachsehen sollte) hier ganz eindeutige Worte.
Bei der Lektüre der ganzen Beiträge findet man dann so seltsame Sachen wie das eigenständige Verstellen der Fahrzeiten (am Ende von http://forum.fhem.de/index.php/topic,24158.msg224523.html#msg224523, dessen Resultat sehr wohl solche Fehlermeldungen bewirken kann, obwohl die Def eigentlich korrekt ist), worüber dann aber im weiteren Verlauf des Freds kein Wort mehr verloren wird ...

Jeder FHEMler tut m.b.M.n. sehr gut daran, sich an diese Verhältnisse so schnell wie möglich zu gewöhnen. Denn eine vollständige Bemutterung kann umgekehrt nicht des Rätsels Lösung sein. Nur würde ich bei der Einteilung in ganz offensichtliche oder weniger offensichtlichen Problemlösungen um etwas mehr Gnade bitten wollen.
Jm2c.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

So, nach ein paar Tagen des Testes habe ich es halbwegs hinbekommen die Automatik der Rollläden fertig zu stellen. "Halbwegs" deshalb, da ich irgendwie noch Probleme mit den "DOIFS" habe.
Die einzelnen Rollläden sind soweit richtig eingestellt und lassen sich auch problemlos mit dem "set" Befehl ansteuern. Nur in Kombination mit der Automatik funktionieren sie mal, mal nicht.
Ich habe jetzt festgestellt dass die Automatik nur dann greift, wenn in den DOIF's der Befehlt "initialized" steht. Wie man sehen kann ist das aber nicht überall der Fall. Um diesen Zusand herbeizuführen muss ich manuell die DOIS's editieren (ich öffne also ein DOIF und schließe es gleich wieder, speichere ab und habe den Zustand "initialized" stehen.

Was muss ich noch einstellen, damit dieser Zustand von FHEM automatisch herbeigeführt wird? In den Logfiles bekomme ich keine Fehlermeldungen angezeigt.....

Pfriemler

Wenn DOIFs statt immer nur einmal nach der Initialisierung ausgeführt werden, riecht das stark nach einem fehlenden Attribut "do always", besonders wenn das DOIF nur einen Zweig hat (also kein DOELSEIF oder DOELSE).

Poste mal den Code eines betroffenen DOIFs, nur um sicher zu gehen. Nur die Def reicht eigentlich.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

([[LichtWetter: sr_weather]]) ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z2_tuer,rollo_OG_Z3,rollo_OG_Z4_tuer,rollo_OG_Z5,rollo_OG_Z6,rollo_wz_1,rollo_wz_2_tuer,rollo_wz_3 off)) DOELSEIF ([09:00|60]) ((set rollo_OG_Z1,rollo_OG_Z2_tuer off))

So sehen die DOIFs bei mir aus

Pfriemler

Hm .... hmmm ... *kopfkratz* Das DOIF berechnet den Timer jedes Mal wenn sich im Twilight-Modul sr_weather ändert. Wie oft tut es das? Ne Idee: Sollte der Timer auf 07:00 stehen und um 6:58 korrigiert Twilight die Zeit auf 6:57, fällt der Rollofahrvorgang für heute aus.

Das ist es aber nicht allein. Das DOIF verzweigt mo-fr immer nur in den Zweig 1. Damit findet kein Zustandswechsel im DOIF statt. Ohne das Attribut "do always" klappt das nur nach einmalig nach einer Neudefinition.
Dir ist aber schon klar, das die gesamte Rollobatterie auch wochenends bei Sonnenaufgang aufrollt?

P.S.: das Leerzeichen zwischen : und sr_weather ist bestimmt falsch ...?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Hm.. bezüglich der Timerberechnung steht in den Details der Automatik dass er die Werte um 21:39 Uhr neu lädt. Also hätte er ja noch genügen Zeit ....

Am Wochenende fahren nicht alle Rolläden mit dem Sonntenaufgang hoch. Hier habe ich ja den Code "DOELSEIF ([09:00|60]) ((set rollo_OG_Z1,rollo_OG_Z2_tuer off))" eingefügt damit mein Schlafzimmer bis 09.00 Uhr verdunkelt bleibt. Das klappt prinzipiell auch, wenn ich manuell eben immer den Vorgang in der DOIF speichere...


Pfriemler

Zitat von: Joker2002 am 30 April 2015, 21:39:33
Am Wochenende fahren nicht alle Rolläden mit dem Sonntenaufgang hoch. Hier habe ich ja den Code "DOELSEIF ([09:00|60]) ((set rollo_OG_Z1,rollo_OG_Z2_tuer off))" eingefügt damit mein Schlafzimmer bis 09.00 Uhr verdunkelt bleibt. Das klappt prinzipiell auch, wenn ich manuell eben immer den Vorgang in der DOIF speichere...
Nein, bei Sonnenaufgang fahren alle Rollos hoch, jeden Tag, da es keine Wochentagsbeschränkung gibt und diese Bedingung jeden Tag zutrifft. Nur Samstags und Sonntags fahren um 9 Uhr die spezifizierten Rollos, insbesondere wenn nicht zuvor die Sonne aufgegangen ist und sie ohnehin deswegen schon oben sind.

Tipp für den Umbau: Nimm 7 für Wochenende und Holiday, und 8 für alles was NICHT 7 ist.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Ok, werde ich einbauen, danke. Ich habe nochmal im commandref nachgeschaut und nach einer do always Option geschaut. Habe diese jetzt per Atribute eingefügt. Ein "initialized" bekomme ich dennoch nicht.... muss ich noch irgendetwas spezielles beachten ?

Pfriemler

Bei einer Neudefinition des DOIFs bekommst Du zumindest bei groben Fehlern immer eine Fehlermeldung, wenn die Spez nicht stimmt (DOIF versucht bspw. immer den ersten Timer sofort zu berechnen und gibt detallierte Fehlermeldungen wenn das nicht klappt). Du prüfst den richtig berechneten Timer im entsprechenden Reading "timer_...". War die Definition erfolgreich, erhältst du "initialzed" bis zur ersten Ausführung. Danach wechselt der Status (wenn man ihn nicht schöner definiert hat, was eine weitere Schönheit des Moduls ausmacht) auf "cmd_x", wobei die Zahl den Zustand benennt, der nach den Bedingungen zuletzt eintraf. Das ist völlig normal so.
Ob der Ausführungsteil eines DOIF-Zweiges ausgeführt wird, wenn die Bedingung erneut zutrifft, regelt "do always". Bei Deinem DOIF sollte also in der Regel "cmd_1" als Status stehen und das DOIF jeden Tag ausgeführt werden.
Was Du sonst noch beachten musst: Du brauchst eine auf Deine Bedürfnisse zugeschnittene Steuerung der Rolläden. Ich z.B. würde mich bedanken, wenn ich werktags durch ein sofortiges Öffnen eines Dutzend Rollos im Haus geweckt würde, weil zu erwarten ist, dass das Ereignis auch mal vor meinem Aufstehzeitpunkt eintritt. Aber das ist eine ganz persönliche Entscheidung, und Du wirst im Laufe der Wochen feststellen, dass noch viel mehr Automatisierung nicht so leicht wirklich komfortabel zu gestalten ist.

Jm2c.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Hallo,

ich bräuchte nochmal Eure Hilfe.

Ich habe noch Fehler in meiner Automatisierung, mit denen ich einfach nicht zurecht komme, bzw. den Fehler nicht finde...

Ich habe meine Rolladenprogrammierung für die Rolläden zum hochfahren durch folgenden Code realisieren wollen. Dabei sollen die Rolläden zum Sonnenaufgang, aber nicht vor 06:45 Uhr bzw. spätestens um 09:00 Uhr hochfahren.

So sieht also der Code aus:

define di_Rolladen_hoch at *{twilight("myTL","sr_weather","06:45","09:30")}} ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z3,rollo_OG_Z5,rollo_OG_Z6,rollo_wz_1,rollo_wz_3,rollo_OG_Z2_tuer,rollo_OG_Z4_tuer,rollo_wz_2_tuer off)) or ([09:00|7] ((set rollo_OG_Z1,rollo_OG_Z2_tuer off)))

Hier erhlate ich immer den Fehler:

di_Rolladen_hoch: Unknown command (set, try help.


Was mache ich falsch. Ich habe schon nach der Fehlermeldung gegoogelt aber irgendwie komme ich nicht weiter :(


Das Herunterfahren der Rollläden zum Sonnenuntergang nach dem Twilight Plugin klappt indess ganz gut, nur habe ich auch hier noch ein kleines Problem: Ich möchte gerne, dass die Rollläden der Türen 10 Minuten später herunterfahren als die Fensterrollläden. Ich habe es also als erstes mit "attr wait 600" probiert und danach mit dem Codeschnipsel ([+00:10]) gemäß der Commandref versucht.
Beides brachte leider nicht den gewünschten Erfolg. Habt ihr vielleicht noch einen Tipp für mich ?

Pfriemler

Dein zitierter Code ist eine nette Mischung aus at (was deine Definition, anders als es der Name di_ vermuten lässt, nun mal ist) und DOIF ...
Wieso zwei }?
Was macht das or und die Timespec "or ([09:00|7]" inmitten des Ausführungsteils?
Räum den Ausführungsteil also mal auf.
Sollen immer noch am Wochenende nur die zwei Rollos aufgehen? Dann kannst Du das mit einem IF oder if lösen. Eine abweichende Zeitangabe klappt so aber nicht.

Zitat... Rollläden der Türen 10 Minuten später herunterfahren als die Fensterrollläden...
"attr wait 600" ... Codeschnipsel ([+00:10]) ... Beides brachte leider nicht den gewünschten Erfolg.
Sehe ich beides nicht als zielführend an.
attr wait verzögert einen sonst sofort eingetretenen Zustandswechsel, wenn Du Fenster und Tür im gleichen DOIF quasi zur gleichen Zeit triggern lässt aber in getrennte Zweige packst. Das empfiehlt sich schon jetzt nicht. Besser ist, den Türrolladenzeitpunkt separat neu mit Zeitoffset in einen eigenen Zweig zu setzen, so dass es einen eigenen (abweichenden) Timer ggü. den Fensterrolläden gibt.
[+00:10] als Timespec in DOIF löst m.W. eine Aktion alle zehn Minuten aus und ist kein Offset.

ZitatHabt ihr vielleicht noch einen Tipp für mich ?
Ohne konkreten Code keinen generellen zum Problem.

twilight nutze ich nicht, stattdessen sunrise und sunset. So genau brauche ich es nicht. Aber dort kann man sehr bequem einen offset als Argument hinterlegen. Geht mit twilight mglw. ähnlich. Alternativ könntest Du sicher, auch wenn das nicht genau 10 Minuten ausmachen, einfach einen anderen twilight-Spec verwenden, bei dem es dann halt noch ein bisschen mehr dunkel ist.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

Hallo Pfriemler,

vielen Dank für Deine Engelsgeduld und verzeihe, dass ich noch so banale Fragen habe. Um FHEM jedoch zu verstehen lese ich in den Foren und in der Commandref viel und versuche danach dann das zu stricken was ich gerne hätte, mit bisher nur mäßigen Erfolg, aber ich lerne mit jeder Verbesserung :)

Was den Code zum Öffnen angeht hast Du recht, da muss ich aufräumen, das habe ich getan und werde diesen Code

define at_Rolladen_hoch at *{twilight("myTL","sr_weather","06:45","09:30")} ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z3,rollo_OG_Z5,rollo_OG_Z6,rollo_wz_1,rollo_wz_3,rollo_OG_Z2_tuer,rollo_OG_Z4_tuer,rollo_wz_2_tuer off)) if ([09:00|7] ((set rollo_OG_Z1,rollo_OG_Z2_tuer off)))

heute Abend mal in FHEM einfügen.

Den anderen Code zum Schließen habe ich bereits in zwei Automatismen aufgeteilt (einen für die Fenster und einen für die Tür). Ich habe es auch schon mit Sunrise und Sunset probiert, brachte mir nur leider nicht den Erfolg. Ich werde den Code heute Abend mal posten.


Pfriemler

Toll, Browser zickt, Antwort futsch.

Nochmal (ich habe der Übersicht mal die ganze Schalterschlange verkürzt)
define at_Rolladen_hoch at *{twilight("myTL","sr_weather","06:45","09:30")} ((set ...rollo_wz_2_tuer off)) if ([09:00|7] ((set rollo_OG_Z1,rollo_OG_Z2_tuer off)))

1. Wozu hier Doppelklammern?
2. Unterscheide IF (das Modul von Damian) und if (Perl)
3. KANN so nicht gehen, Timespec im IF?

Also wenn ich mal unterstelle, dass anscheinend werktags die Rolläden lichtgesteuert, frühestens 6:45, spätestens 9:30 fahren sollen und am Wochenende um 9 nur zwei von denen:

define at_Rolladen_hochMOFR at *{twilight("myTL","sr_weather","06:45","09:30")} IF ({!$we}] (set .......rollo_wz_2_tuer off))
define at_Rolladen_hochSASO at *09:00 IF ({$we}] set rollo_OG_Z1,rollo_OG_Z2_tuer off

Bin aber nicht sicher, ob die Abfrage mit $we so richtig ist

Aber hatten wir nicht schon mal ein DOIF dafür?

Wer Fehler findet, darf sie behalten  :D
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

So, habe jetzt mal Deinen verbesserten Code in FHEM eingebaut. Ich bin sehr gespannt ob die Rollläden morgen entsprechend hochfahren. Danke schon  mal für die Hilfe  ;D

Ich denke die doppelte Klammer ist einfach ein Tippfehler. Ich hatte den Code händisch erstellt und eingefügt.

Das mit dem "IF" und "if" wusste ich bis dato auch noch nicht, wieder was dazu gelernt :)

Wir hatten schon mal für die Rollladensteuerung eine DIOF gemacht, das ist richtig, ich habe es aber wieder verworfen weil ich nicht wollte dass im Sommer die Rollläden schon um 05:42 Uhr hochfahren. Daher habe ich mich umgesehen noch der Möglichkeit eine Zeit zu definieren in der die Rollos hochfahren sollten...

Was das Runterfahren der Rollläden betrifft:
Ich habe für die Fenster folgende Codes:

([[LichtWetter:ss_weather]]) ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z3,rollo_OG_Z6,rollo_wz_1,rollo_wz_3 on))

und für die Tür diesen hier angewandt:

([[LichtWetter:ss_weather]]) ([+00:10]) ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z3,rollo_OG_Z6,rollo_wz_1,rollo_wz_3 on))

die Türen fahren jedoch immer zeitgleich mit den Fenstern runter. Sie sollen jedoch 10 Minuten später runterfahren. Irgendwie bekomme ich es nicht hin. In der Commandref hierzu habe ich eben nur die Möglichkeit mit dem attr 600 bzw. dem ([+00:10]) gefunden..

Pfriemler

'n Ahmd,

Im DOIF müssen die doppelten Klammern natürlich sein - einmal um die Befehlskette zu umschließen, zweitens um die , in der Device-Aufzählung zu maskieren, damit DOIF die nicht auseinanderreißt (Komma ist dort Befehlstrennzeichen).

([[LichtWetter:ss_weather]]) ([+00:10]) ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z3,rollo_OG_Z6,rollo_wz_1,rollo_wz_3 on))

Mich wundert dass da überhaupt was passiert.  Probier als Bedingung doch mal ein Zeitoffset, sprich eine Sekundenanzahl als Operation also z.B. so: (die Klammern um die Rechenoperation ([LichtWetter:ss_weather]+600) nicht vergessen, (oder?))

([([LichtWetter:ss_weather]+600)]) ((set rollo_kue,rollo_OG_Z1,rollo_OG_Z3,rollo_OG_Z6,rollo_wz_1,rollo_wz_3 on))

Und ob das klappt mit meinem Code - wie gesagt, ich bin unsicher wegen des $we. Ich sehe gerade, wieder zu Hause, dass ich noch viele Perl-ifs einsetze:

define RolloOGWeHoch_Mo_Fr at *08:10 { if (!($we)) { fhem("set RolloOGWe Oeffnen"); } }

Das funktioniert. { eröffnet die Perl-Ebene nach der Zeitangabe des at. $we muss wohl vor der Negierung geklammert sein. Die zweite { öffnet den Ausführungsbereich des perl-if, aus Perl heraus werden FHEM-Befehle mit fhem(" ") aufrufen (verwirrend, aber ich setze von FHEM aus einen Perl-Befehl ab, von dem aus ich wieder einen FHEM-Befehl aufrufe, aber das ist richtig so), ";" als Abschluss des Befehls wie bei Perl Pflicht (bei Eingabe in der Kommandozeile von FHEM eine, in der fhem.cfg stehen dann automatisch und richtigerweise 2, und die zwei } schließen die Klammerebenen.
Und da ich kein Somfy nutze, sondern einen Dummy setze, bei dessen Änderung ein DOIF Impulse an den von mir umgepfriemelten (!) Antrieb schickt, heißt's bei mir nicht "set ... on" aber das nur am Rande.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

so, voller Spannung den heutigen Morgen abgewartet und.....

... es fuhr leider nicht hoch. Ich erhielt folgende Fehlermeldung:

IF: rightbracket without left bracket: ] (set rollo.....off)

so wie ich das sehe fehlt in der Formel noch eine entsprechende Klammer nach dem IF... muss ich diese nach der ( und vor dem { setzen ?


define at_Rolladen_hochMOFR at *{twilight("myTL","sr_weather","06:45","09:30")} IF ({!$we}] (set .......rollo_wz_2_tuer off))

Pfriemler

#40
ja Mist ... nein, die ] durch ) ersetzen. sh... ich probiers heute mal aus.
Die Punkte haste aber schön gemacht...,
Vom 7Zöller via Tapatalk
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker2002

So, heute Morgen neuer Versuch, leider (noch) ohne Erfolg :(

Code war folgender:
define at_Rolladen_hochMOFR at *{twilight("myTL","sr_weather","06:45","09:30")} IF ({!$we}) (set .......rollo_wz_2_tuer off))

Jetzt bekomme ich einen anderen Fehler:

IF: expected ELSE: )


Pfriemler

Also Klammerdurchzählen solltest Du schon selbst machen - für mich ist hinten eine runde ) zuviel an einer Stelle, an der IF sonst ein (optionales) ELSE erwarten würde. Das war auch in Deinem vorigen Zitat schon falsch, aber da ging's ja um das $we.
Probier doch mal den Ausführungsteil durch ein Notify mit einem Dummy aus - dann musst Du nicht immer einen Tag warten und wir kommen schneller zu Ergebnissen.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Puschel74

Fragen zu IF oder DOIF sollten besser unter Automatisierung gestellt werden.
Warum?
Weil Damian dort eher liest.
Klammerzählen wird aber auch dort niemandem abgenomen - zählen sollte jeder selbst können.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Joker2002

#44
So, neue Runde :)

Ich war das Wochenende nicht da, so dass ich nicht berichten konnte. Habe die Ausführungsteil überprüft und Klammern gezählt (wobei ich das von selbst getan hätte, wenn ich gewusst hätte was FHEM mir da erzählt  ;))

So, ich bekomme mit diesem Code eine neue Fehlermeldung, die mir leider ebenfalls nichts sagt :(

*{twilight("myTL","sr_weather","06:25","09:30")} IF ({!$we}) (set ...,rollo_wz_2_tuer off)

Das ist die dazugehörige Fehlermeldung...

Zitat2015.05.26 06:25:00 1: PERL WARNING: Odd number of elements in anonymous hash at (eval 2787) line 1.
2015.05.26 06:25:00 3: eval: {if({!$we}){fhem('set rollo_kue,rollo_OG_Z1,rollo_OG_Z3,rollo_OG_Z5,rollo_OG_Z6,rollo_wz_1,rollo_wz_3,rollo_OG_Z2_tuer,rollo_OG_Z4_tuer,rollo_wz_2_tuer off')}}

Pfriemler

*kopfkratz* ... Is ja interessant, der Log liefert das nach PERL übersetzte IF in Klarschrift - mit ' statt " und ohne ; hinten (siehe Post #38). Abgesehen davon, dass ich erst den Wert von $we negieren würde (also "IF ({!($we)})") ... bin ich jetzt am Ende...

Anyone else? (von denen die sich bis jetzt schon gekugelt haben im Hintergrund) ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."