[gelöst] EEP A5-13-01: Probleme mit "isSunny*"

Begonnen von KiK, 13 Juni 2019, 09:51:59

Vorheriges Thema - Nächstes Thema

KiK

Hallo,

ich betreibe seit einer Woche eine ELTAKO Wetterstation "Multisensor MS" an einem "FWG14MS".
Die Wetterstation wurde per Teach erkannt und ich konnte sie parametrieren.

Helligkeits-Schwelleneinstellungen: Helligkeit 40.000:60.000, Delay 300:300 (All / East / South / West)

Folgende Probleme:
1.
"isSunny" schaltete nicht auf "yes" - auch wenn die Attribute "brightnessSunny" & "brightnessSunnyDelay" gesetzt wurden. Die Readings "isSunnyEast/South/West" schalteten korrekt.
Workaround: Userreadings:
isSunnyAll:isSunny.*
  {
  if ((ReadingsVal($name,"isSunnyEast",0) eq "yes") || (ReadingsVal($name,"isSunnySouth",0) eq "yes") || (ReadingsVal($name,"isSunnyWest",0) eq "yes")) { sprintf("yes")} else { sprintf("no")}
  }


Damit funktionierte es .... bis heute:

2.
Heute früh Sonnenaufgang: Trotz >70.000 Lux (Schwelle 40000 / 60000 Lux) bleibt "isSunnyEast = no".
Neustart Raspi keine Verbesserung.
...dann gegen 9:30 plötzlich alle 3 isSunny Werte (East/South/West) auf "yes", obwohl Helligkeit "South" & "West" weit unter 40000 Lux.

3.
Der max. Helligkeitswert bleibt bei konstant max. 98823. Dieser sollte bis 150kLux gehen, scheint aber "gedeckelt". Vielleicht haben die anderen Problem was damit zu tun (Overflow)?
...ok, wer lesen kann: Die "Deckelung" auf 99kLux macht laut Datenblatt das ELTAKO Gerät

Hat jemand von euch einen Tipp?

Danke
Frank

klaus.schauer

zu 1.: isSunny wurde nicht mit dem korrekten Helligkeitswert versorgt. Morgen nach einem Update sollte es gehen.
zu 2.: Bitte die Schwellwertfunktion zuerst mit den Standardwerten testen. Dazu einfach alle zugehörigen Attribute entfernen. Während der Verzögerungszeit muss der Schwellwert unterbrechungsfrei über- bzw. unterschritten sein, sonst beginnt die Verzögerungszeit erneut. Im Devicelog sollte man das gut nachvollziehen können. Bei meiner Installation sind mir bisher keine Probleme aufgefallen. Ich nutze dafür zwar das Modul ElsnerWS, das mit einem RS485-Transceiver arbeitet aber funktional identisch ist.

KiK

#2
Hallo,

zu 1.: isSunny schaltet nun - Danke
zu 2.: isSunnyEast/West/South verhalten sich bei mir weiterhin sonderbar (evt. Einfluss aus einem anderen Teil der Config?)
z.B. hier: Alle isSunny* waren auf "no":
2019-06-14 11:15:35 EnOcean EnO_00001800 brightness: 33529
2019-06-14 11:15:35 EnOcean EnO_00001800 sunWest: 17647
2019-06-14 11:15:35 EnOcean EnO_00001800 sunSouth: 33529
2019-06-14 11:15:35 EnOcean EnO_00001800 sunEast: 18823
2019-06-14 11:15:55 readingsGroup rWetter EnO_00001800.windSpeedKMH:   Created by potrace 1.8, written by Peter Selinger 2001-2007      0.0 km/h
2019-06-14 11:15:55 EnOcean EnO_00001800 windSpeed: 0.0
2019-06-14 11:15:55 EnOcean EnO_00001800 windStrength: 0
2019-06-14 11:15:55 EnOcean EnO_00001800 T: 16.9 B: 33529 W: 0.0 IR: yes
2019-06-14 11:15:55 EnOcean EnO_00001800 windSpeedKMH: 0.0
2019-06-14 11:17:15 readingsGroup rWetter EnO_00001800.brightness:   Created by potrace 1.8, written by Peter Selinger 2001-2007                 35882 Lux
2019-06-14 11:17:15 EnOcean EnO_00001800 brightness: 35882
2019-06-14 11:17:15 EnOcean EnO_00001800 sunWest: 20000
2019-06-14 11:17:15 EnOcean EnO_00001800 sunSouth: 35882
2019-06-14 11:17:15 EnOcean EnO_00001800 sunEast: 20000
2019-06-14 11:18:19 readingsGroup rWetter EnO_00001800.brightness:   Created by potrace 1.8, written by Peter Selinger 2001-2007                 37647 Lux
2019-06-14 11:18:19 EnOcean EnO_00001800 brightness: 37647
2019-06-14 11:18:19 EnOcean EnO_00001800 sunWest: 20588
2019-06-14 11:18:19 EnOcean EnO_00001800 sunSouth: 37647
2019-06-14 11:18:19 EnOcean EnO_00001800 sunEast: 20588
2019-06-14 11:18:19 EnOcean EnO_00001800 T: 16.9 B: 37647 W: 0.0 IR: yes
2019-06-14 11:19:14 readingsGroup rWetter EnO_00001800.brightness:   Created by potrace 1.8, written by Peter Selinger 2001-2007                 40000 Lux
2019-06-14 11:19:14 EnOcean EnO_00001800 brightness: 40000
2019-06-14 11:19:14 EnOcean EnO_00001800 sunWest: 22941
2019-06-14 11:19:14 EnOcean EnO_00001800 sunSouth: 40000
2019-06-14 11:19:14 EnOcean EnO_00001800 sunEast: 21764
2019-06-14 11:19:44 EnOcean EnO_00001800 isSunnySouth: yes
2019-06-14 11:19:44 EnOcean EnO_00001800 isSunnyWest: yes
2019-06-14 11:19:44 EnOcean EnO_00001800 isSunnyEast: yes


...da ich die Schwellenwerte/Delays East/South/West belassen habe, sehe ich keinen Grund, warum "isSunnyWest & East" auf "yes" schalten.

Nachtrag: Ist es das hier? Im File 10_EnOcean:
push @event, "3:isSunnySouth:" . EnOcean_swayCtrl($hash, "isSunnySouth", $sunSouth, "brightnessSunnySouth", "brightnessSunnySouthDelay", 20000, 40000, 120, 30, 'no', 'yes');
push @event, "3:isSunnyWest:" . EnOcean_swayCtrl($hash, "isSunnyWest", $sunSouth, "brightnessSunnyWest", "brightnessSunnyWestDelay", 20000, 40000, 120, 30, 'no', 'yes');
push @event, "3:isSunnyEast:" . EnOcean_swayCtrl($hash, "isSunnyEast", $sunSouth, "brightnessSunnyEast", "brightnessSunnyEastDelay", 20000, 40000, 120, 30, 'no', 'yes');


...sollte das so sein?
push @event, "3:isSunnySouth:" . EnOcean_swayCtrl($hash, "isSunnySouth", $sunSouth, "brightnessSunnySouth", "brightnessSunnySouthDelay", 20000, 40000, 120, 30, 'no', 'yes');
push @event, "3:isSunnyWest:" . EnOcean_swayCtrl($hash, "isSunnyWest", $sunWest, "brightnessSunnyWest", "brightnessSunnyWestDelay", 20000, 40000, 120, 30, 'no', 'yes');
push @event, "3:isSunnyEast:" . EnOcean_swayCtrl($hash, "isSunnyEast", $sunEast, "brightnessSunnyEast", "brightnessSunnyEastDelay", 20000, 40000, 120, 30, 'no', 'yes');


Zusätzliche Anmerkung: dayNight
brightnessDayNightCtrl custom
Nach einem System-Neustart, wird das Reading "dayNight" zunächst auf "night" gesetzt. Vorausgesetzt es ist draußen hell, wird es nach Ablauf der Verzögerung (Standard = 10min) wieder korrekt auf "day" gesetzt. Ist dem so? Praktisch würde das bei mir bedeuten, dass nach einem Stromausfall erst einmal für 10min die Rolladen herunterfahren  ;)
- ok, ich könnte auch das entsprechende Notify nach dem Systemstart um >10min verzögern oder noch mit der aktuellen Helligkeit verknüpfen.

klaus.schauer

Gut dass die Funktionen gründlich getestet werden, danke. Den Kopierfehler hatte ich übersehen. Wird umgehend berichtigt.

Die Basiswerte zur Berechnung von dayNight und isSunny* werden aus mehreren Gründen flüchtig im Hash gespeichert. Als Startwert wird bei einem Neustart ein festgelegter Wert - der "Minimalwert" - gesetzt. In dem Modulen ElsnerWS und ModbusElsnerWS ist dies unproblematisch, da die Messwerte im Sekundentakt empfangen werden. Deshalb habe ich dem keine weitere Beachtung geschenkt. Bei den größeren Sendeintervallen der EnOcean-Geräte ist das natürlich unschön. Ich sehe mir das in aller Ruhe nochmals an. Vielleicht finde eine brauchbare Lösung.

KiK

Super - es funktioniert jetzt!
Danke für den Support  :)

Jump2016

@KiK kannst du mir die "RAW definition" deines FWG14MS-Devices schicken?

Hab mir auch eins gekauft und würde dieses nun gerne in FHEM integrieren, weiß leider nur nicht genau wie  ;)

Danke

Gruß

Jonas

KiK

das hier?

defmod EnO_00001800 EnOcean 00001800
attr EnO_00001800 IODev TCM120
attr EnO_00001800 brightnessDayNight 100:150
attr EnO_00001800 brightnessDayNightCtrl custom
attr EnO_00001800 brightnessDayNightDelay 200:300
attr EnO_00001800 brightnessSunny 60000:80000
attr EnO_00001800 brightnessSunnyDelay 900:300
attr EnO_00001800 eep A5-13-01
attr EnO_00001800 event-min-interval .*:3600
attr EnO_00001800 event-on-change-reading .*
attr EnO_00001800 manufID 00D
attr EnO_00001800 room EnOcean
attr EnO_00001800 subType environmentApp
attr EnO_00001800 userReadings windSpeedKMH:windSpeed:.*\
  { \
  sprintf("%.1f",ReadingsNum($NAME,"windSpeed",0)*3.6) \
  }

Jump2016

@KiK, vielen Dank genau das hab ich gemeint.

Komme leider erst jetzt dazu es zu testen, gab leider andere Dinge mit größerer Priorität...

Ich habe meinen Raspberry per Eltako USB angebunden.
Wenn ich nun deine RAW-Definition nehme, dann wird zwar ein neues Device angelegt, aber ich bekomme keine Readings.

Mein Device sieht nun so aus:
defmod EnO_00001800_Wetter EnOcean 00001800
attr EnO_00001800_Wetter IODev TCM_ESP2_0
attr EnO_00001800_Wetter brightnessDayNight 100:150
attr EnO_00001800_Wetter brightnessDayNightCtrl custom
attr EnO_00001800_Wetter brightnessDayNightDelay 200:300
attr EnO_00001800_Wetter brightnessSunny 60000:80000
attr EnO_00001800_Wetter brightnessSunnyDelay 900:300
attr EnO_00001800_Wetter eep A5-13-01
attr EnO_00001800_Wetter event-min-interval .*:3600
attr EnO_00001800_Wetter event-on-change-reading .*
attr EnO_00001800_Wetter manufID 00D
attr EnO_00001800_Wetter room EnOcean
attr EnO_00001800_Wetter subType environmentApp
attr EnO_00001800_Wetter userReadings windSpeedKMH:windSpeed:.*\
  { \
  sprintf("%.1f",ReadingsNum($NAME,"windSpeed",0)*3.6) \
  }


hab also "nur" das IODev auf mein Device umgestellt.

Was hab ich vergessen?

Vielen Dank für eine kurze Rückmeldung.

Gruß

Jonas

KiK

Hi Jonas,

Die Messages hätten schon vor dem Define der Wetterstation empfangen werden sollen - per Autoteach wäre ein Device angelegt worden.

Das könnte vieles sein. Sorry wenn ich jetzt etwas blöd frage:

- Ist das TCM120 Modul im FHEM korrekt definiert und läuft ohne Fehlermeldung?
- Bekommst du Messages der anderen Eltako FAM14 Devices?
   - Wenn nein: FWG14MS + FWG14-USB korrekt am FAM14 angemeldet (Adresse vergeben)?
   - FWG14MS/-USB Wahlschalter korrekt ?
   - Wenn Ja: elektrische Verdrahtung der Wetterstation ok?

Gruß