Sunny Tripower 6000TL-20

Begonnen von SpenZerX, 21 Oktober 2015, 20:39:47

Vorheriges Thema - Nächstes Thema

Waldmensch

Zumindest für das Einschalten des Nachtmodus könnte man schauen ob der $avgbuffer nur Nullen enthält. Das müssten dann die letzten 15 Minuten sein. Gefährlich wird das nur bei Unwetter oder anderen Gründen (Schnee) wenn die Leistung tagsüber mal für eine Weile auf Null geht. Zum Abschalten des Nachtmodus (morgens) geht das aber nicht, da ja im Nachtmodus keine Werte vorliegen.

Waldmensch

#61
Ich hatte gestern einen wunderbar sonnigen Tag und einen traumhaften Chart (außer das der EV Zähler - roter Graph - zwischen 14:00 und 16:30 ein Empfangsproblem hatte). Im Chart fällt auf, das da gegen 9:45 ein Nullwert vom Wechselrichter kam. Das ist nicht so toll.
Folgendes habe ich versucht mit dem Modul im Anhang zu fixen:
- Nullwerte (Ausreißer) werden nicht in die Readings geschrieben. Lieber einen Intervall verloren, als falsche Werte
- Readings werden nicht mehr geschrieben, wenn der Wechselrichter nur noch Nullwerte liefert, also wenn es dunkel ist. Das verhindert unnütze Einträge in DBLog oder FileLog. Damit sparen wir noch mehr Datenmüll als mit der Schlafphase ab 22:00. Also bei Dunkelheit werden erst die Readings nicht mehr geschrieben und ab 22:00 wird dann auch der Wechselrichter nicht mehr abgefragt.

Unter verbose 5 habe ich entsprechende Logeinträge zugefügt:

Schlafmodus:
2016.04.22 03:24:01 5 : Wechselrichter: 3 is out of working hours 5 - 22

Dunkelheit im Aktivmodus:
2016.04.22 05:16:05 5 : Wechselrichter: Recived: (534d4100000402a000000001003a001060650ed07800c8e803380001800059f3cc7d00010000000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)!
2016.04.22 05:16:05 5 : Wechselrichter: Recived: (534d4100000402a00000000100460010606511d07800c8e8033800a0800059f3cc7d000000000000f1b101020054000000000100000001012600161b195764470f01000000000122260072971957000000000000000000000000)!
2016.04.22 05:16:05 5 : Wechselrichter: Recived: (534d4100000402a00000000100420010606510d07800c8e8033800a0800059f3cc7d00000000000081f0010200510000000000000000013f26401b1b1957000000800000008000000080000000800100000000000000)!
2016.04.22 05:16:05 5 : Wechselrichter: Recived: (534d4100000402a000000001005e0010606517d07800c8e8033800a0800059f3cc7d00000000000081f0010280530000000001000000011e25401b1b19570000008000000080000000800000008001000000021e25401b1b1957000000800000008000000080000000800100000000000000)!
2016.04.22 05:16:05 4 : Wechselrichter: (Wechselrichter) from (192.168.178.86): (SP:0 W AvP1:0 W TTP:0 Wh ATP:17778532 Wh)
2016.04.22 05:16:05 5 : Wechselrichter: AvP05 = 0, SpotPower = 0, AvP15 = 0
2016.04.22 05:16:05 5 : Wechselrichter: Readings not updated


Wechselrichter liefert wieder - Normalbetrieb
2016.04.22 06:17:16 5 : Wechselrichter: Recived: (534d4100000402a000000001003a001060650ed07800c8e803380001800059f3cc7d00010000000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)!
2016.04.22 06:17:16 5 : Wechselrichter: Recived: (534d4100000402a00000000100460010606511d07800c8e8033800a0800059f3cc7d000000000000f1b101020054000000000100000001012600cca5195767470f010000000001222600c8a51957030000000000000000000000)!
2016.04.22 06:17:16 5 : Wechselrichter: Recived: (534d4100000402a00000000100420010606510d07800c8e8033800a0800059f3cc7d00000000000081f0010200510000000000000000013f2640cba51957440000004400000044000000440000000100000000000000)!
2016.04.22 06:17:16 5 : Wechselrichter: Recived: (534d4100000402a000000001005e0010606517d07800c8e8033800a0800059f3cc7d00000000000081f0010280530000000001000000011e2540cca519575400000054000000540000005400000001000000021e2540cca519571d0000001d0000001d0000001d0000000100000000000000)!
2016.04.22 06:17:16 4 : Wechselrichter: (Wechselrichter) from (192.168.178.86): (SP:68 W AvP1:60 W TTP:3 Wh ATP:17778535 Wh)
2016.04.22 06:17:16 5 : Wechselrichter: AvP05 = 36, SpotPower = 68, AvP15 = 12
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter SP:68 W AvP1:60 W TTP:3 Wh ATP:17778535 Wh
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter SpotP: 68
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter SpotPDC1: 84
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter SpotPDC2: 29
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter TodayTotalP: 3
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter AlltimeTotalP: 17778535
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter AvP01: 60
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter AvP05: 36
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter AvP15: 12
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter EV: 596
2016-04-22 06:17:16 InVERTER_CoNNECT_SW Wechselrichter FeedIN: -528
2016.04.22 06:17:16 5 : Wechselrichter: Readings updated

Waldmensch

Der Chart von heute, mit dem Script vom vorigen Post. Man sieht im oberen Chart sehr schön, das keine wilden Nullwerte auftreten und bei Dunkelheit keine Readings mit Nullwerten mehr geschrieben werden. Das funktioniert also wie gedacht. Ich probier mich mal als nächstes an ein paar Attributen, um dem User Konfigurationsmöglichkeiten anzubieten.


Waldmensch

Ich habe es tatsächlich geschafft, vier Attribute zuzufügen  :)

- suppress-night-mode: Unterdrückt den Schlafmodus, der Wechselrichter wird non-stop abgefragt
- suppress-inactivity-mode: Unterdrückt den Inaktivitätsmodus, Nullwerte werden fleißig in die Datenbank bzw ins Filelog geschrieben
- starttime-hour: überschreibt die default Startstunde (5) mit einem eigenen Wert, nur ganze Zahlen eintragen, da ist noch kein check drin, bei Sachen wie "5a" oder "5,5" werden unvorhergesehene Dinge passieren
- endtime-hour: Siehe starttime-hour

Waldmensch

Ich hatte noch ein bisschen Zeit und habe die "starttime-hour" und "endtime-hour" Attribute geändert zu "starttime" und "endtime". Eingabeformat nun hh:mm bei Beiden. Ein richtiger Syntax check ist da aber immer noch nicht drin. Auch wird nicht geprüft ob endtime < starttime, dass muss unbedingt noch rein, um Userfehler abzufangen.



Sollte das letzte update für dieses WE sein. Sorry fürs nerven  :-\

Michael

Moin Waldmensch

ZitatSollte das letzte update für dieses WE sein. Sorry fürs nerven  :-\
Nein, ein Nerven ist das bestimmt nicht.

Teste gern deine Neuerungen weiter.  :)
Gruß, Michael

FHEM 6.0 auf RPi 3
CUL V3 868 Mhz | JeeLink LaCrosse & PCA301 | CCU3
BMP085(180) | 14x TX29DTH-IT | 5x PCA 301 | SMA Peripheries | MobileAlerts MA-10(100,120PRO,200,251,410,650,660,800) | HM IP

Waldmensch

Okay, habe noch ein bisschen weitergemacht an einem "force-sleep" Attribut, was den Schlafmodus (keine WR Anfragen mehr) bei 15 Minuten Nullwerten erzwingt, unabhängig von der gesetzten Einschlafzeit. Aufwachen geht aber nur über die feste starttime. Da schwebt mir noch sowas wie sunrise +/- Korrekturwert vor. Aber ich weiß nicht ob man wegen 10-50 Anfragen an den WR wirklich solch Aufwand betreiben sollte. Im FilLog/LogDB wird ja eh nichts geschrieben, bis der WR anfängt zu arbeiten.

Die Validation der starttime/endtime Werte ist auch fertig. Muss es nur noch testen. Also gibt es heute Abend vielleicht doch noch ein Update

Waldmensch

#67
Okay, Test bestanden

Neues Attribut "force-sleepmode" mit den Werten 0 und 1. Setzt man das Attribut auf 1, wird der Schlafmodus erzwungen sobald der 15 Minuten Durchschnittswert auf 0 gefallen ist.

Einmalige Meldung im verbose 5 Log:
2016.04.23 20:05:34 5 : Wechselrichter: sleepmode forced after 15 minutes zero power
Dann wiederholend die Schlafmodus Meldungen mit dem Vermerk "FORCED"
2016.04.23 20:06:34 5 : Wechselrichter: 20:06 is out of working hours 05:30 - 21:00 FORCED!

Der Schlafmodus sollte zur "starttime" ganz normal verlassen werden

Waldmensch

#68
Ich habe den Sleepmode noch mal überarbeitet und über 3 DateTime Objekte realisiert. Das ist robuster und übersichtlicher. Auch verschwindet nun die "FORCED" Meldung im Log, wenn der Sleepmode reell erreicht wird. Läuft bei mir wie Uhrwerk.

Edit:

Wird eigentlich ein Reading benötigt, was den aktuellen Status anzeigt? Also "normal", "inactive", "sleeping"? Das würde dann bei

- Normalbetrieb immer
- Inaktivität (WR liefert 0 Watt) bei Eintritt in diesen Status
- Sleepmode (WR wird nicht abgefragt) bei Eintritt in diesen Status

geschrieben werden. Damit könnte man dann vielleicht Sachen schalten, die unabhängig von der WR Leistung gemacht werden sollen. Zum Beispiel könnte man die Wechsel "inactive" -> "normal" und "normal" -> "inactive" hernehmen als Helligkeitssensor.

Was auch noch ginge, wären ein paar Alarmschwellen. Beispielsweise über Attribut einstellbar Alarm 1-3 mit je der Angabe in Watt. Entsprechend dann 3 Readings, die zwischen 0 und 1 wechseln, wenn die Alarmgrenzen über oder unterschritten werden. Solche Werte kann man aber nicht fest vorgeben, da die Leistung ja von der Anlage abhängt. Deswegen über Attribute konfigurierbar.

Ich würde das nicht unbedingt brauchen, aber wenn ihr es für sinnvoll erachtet, gebt Bescheid. Ansonsten ist das Modul m.E. weitestgehend ausgereizt.

Michael

#69
Moin Waldmensch

ZitatWird eigentlich ein Reading benötigt, was den aktuellen Status anzeigt? Also "normal", "inactive", "sleeping"?
Benötigt eigentlich nicht, nur zu Info eine Option.

Was machen die beiden neuen Readings?
suppress-night-mode 0|1
suppress-inactivity-mode 0|1

Beim setzen des attr suppress-night-mode stürzt Fhem ab.
ZitatUse of uninitialized value $name in hash element at /opt/fhem//FHEM/23_InVERTER_CoNNECT_SW.pm line 63, <> line 7.
Use of uninitialized value $name in hash element at /opt/fhem//FHEM/23_InVERTER_CoNNECT_SW.pm line 74, <> line 7.
Use of uninitialized value $name in hash element at /opt/fhem//FHEM/23_InVERTER_CoNNECT_SW.pm line 85, <> line 7.
Use of uninitialized value $name in hash element at /opt/fhem//FHEM/23_InVERTER_CoNNECT_SW.pm line 86, <> line 7.
Use of uninitialized value $name in hash element at /opt/fhem//FHEM/23_InVERTER_CoNNECT_SW.pm line 87, <> line 7.
Use of uninitialized value $name in concatenation (.) or string at /opt/fhem//FHEM/23_InVERTER_CoNNECT_SW.pm line 89, <> line 7.
Use of uninitialized value in pattern match (m//) at /opt/fhem//FHEM/23_InVERTER_CoNNECT_SW.pm line 156, <> line 7.
Dürfen den die drei attr starttime, endtime und force-sleepmod gesetzt bleiben?

Edit:
Auch sonst hat diese Version einiges durcheinander gebraucht.
- Konnte keine Räume wechsel
- Beim Update Absturtz
Gruß, Michael

FHEM 6.0 auf RPi 3
CUL V3 868 Mhz | JeeLink LaCrosse & PCA301 | CCU3
BMP085(180) | 14x TX29DTH-IT | 5x PCA 301 | SMA Peripheries | MobileAlerts MA-10(100,120PRO,200,251,410,650,660,800) | HM IP

Waldmensch

Diese Fehlermeldungen bekomme ich immer beim reload des Moduls. Keine Ahnung was das ist, ich mach dann immer shutdown restart. An dem Attribut liegt das nicht, habs grad getestet. Da muß mal ein FHEM Modul Guru reinschauen.

suppress-night-mode 0|1            <- hängt über allem drüber und hebelt den sleepmode komplett aus, egal was in den anderen Attributen steht
suppress-inactivity-mode 0|1      <- schreibt weiter ins Log auch wenn es Nullwerte sind

Default sind beide auf 0. Die 1 ist nur dafür gedacht, wenn Du WR und Log maltretieren willst


Ich habe den "modulstate" schon eingebaut und auch 3 Alarme. Läuft grad zum testen. -1 steht für Wert unterschritten, 1 steht für Wert überschritten und 0 steht für kein wert im Attribut gesetzt.


Waldmensch

Hier nochmal eine neue Version mit modulstate und 3 Alarmen

neue Attribute:
alarm1-value - Wert in Watt
alarm2-value - Wert in Watt
alarm3-value - Wert in Watt

enable-modulstate 0/1

die Alarme liefern -1 bei WR Leistung unter diesem Wert und 1 bei WR Leistung über diesem Wert. Wenn das Attribut nicht gesetzt ist, ist das Reading 0. Ich denke mal, damit kann man innerhalb FHEM schon was anfangen. Im Bild habe ich die Werte auf 1000, 3000 und 7000 gesetzt und im Chart dargestellt

Der modulstate liefert "normal", "inactive" und "sleeping"


SpenZerX

Wozu sollen denn die Alarm-Werte sinnvoll sein?

Wenn du Geräte schalten willst würde ich es so machen:


# Notify Kuehltruhensteuerung
define Kuehltruhensteuerung notify SMA.Wechselrichter.AvP05:.* {\
  if ( ( ($hour >= 8 && $hour < 16) && ReadingsVal("SMA.Wechselrichter", "AvP05", "") >= "1200") && ( ReadingsVal("Kuehltruhe_COOL_DOWN", "state", "off") eq "off" ) ) {\
    fhem("set Kuehltruhe_COOL_DOWN on");;\
  }\
  else {\
    if ( ( ($hour >= 16 or $hour < 8) or ReadingsVal("SMA.Wechselrichter", "AvP05", "") < "900" ) && ( ReadingsVal("Kuehltruhe_COOL_DOWN", "state", "on") eq "on" ) ) {\
     fhem("set Kuehltruhe_COOL_DOWN off");;\
   }\
   }\
}



Waldmensch

#73
Das kann man ja trotzdem noch machen.
Ich denke bei den Alarmen an so Anwendungen wie eine LED Ampel oder Display (In Verbindung mit der TabletUI evtl) für die Hausfrau, damit sie weiß, dass es in dem Moment (k)eine gute Idee wäre, den Geschirrspüler, Waschmaschine, Bügeleisen, whatever einzuschalten oder just bei einer Wolke vor der Sonne mit staubsaugen anzufangen. Der Aufwand, die Alarme einzubauen war gering, ob man es nutzt kann ja jeder für sich selbst entscheiden.

Bei mir ist zum Beispiel 7000 Watt eine ganz wichtige Grenze, nämlich die 70% Regel Grenze (Anlage 10kWp). Bei über 7500 Watt (500Watt ist so die Grundlast vom Haus) müssen unbedingt Verbraucher zugeschaltet werden, sonst verschenke ich Energie und der Tripower drosselt sich runter. Im Sommer habe ich dafür die Pool Pumpe, aber aktuell ist der Pool noch nicht in Betrieb.

Ich werde noch eine Änderung an den Alarmen vornehmen, ich werde das Reading nur schreiben, wenn der Wert sich geändert hat also 1 zu -1 oder -1 zu 1. Das spart wieder Platz in Log und DBLog.

appi

Hallo
heute kommt meine PV in Bertrieb.  ca. 6 KW Leistung mit einem Sunny Tripower 6000TL-20.
In Fhem definier und er antwortet, jedoch nicht die letzte Version des Moduls. die neueste Version mit den 3 Alarmen für bei mir zum Abturz von Fhem.
Hatte aber noch keine Zeit den Log zu studieren bez. der Ursache. Werde es nachholen und berichten.

Frage: Ich bräuchte noch die Log definitionen, kann bitte jemand seine entsprechenden Fhem.cfg Zeilen hier einstellen.
Besten Dank und freundliche Güsse
Remo