Neueste Beiträge

#1
Anfängerfragen / Zeilenumbruch bei event-on-cha...
Letzter Beitrag von Gisbert - 14 Mai 2024, 08:55:55
Hallo zusammen,

bei vielen Readings liest sich die Definition einfacher, wenn man eine neue Zeile beim Attribut event-on-change-reading einfügt, also z.B. so:
attr JK_BMS event-on-change-reading Zeitstempel,average_cell_voltage,balancing,\
capacity_remaining,capacity_remaining_derived,charging_cycles,current:0.2,\
delta_cell_voltage,power:10,power_tube_temperature,temperature_sensor_1,\
temperature_sensor_2,total_charging_cycle_capacity,total_runtime,\
total_runtime_formatted,total_voltage:0.02
statt
attr JK_BMS event-on-change-reading Zeitstempel,average_cell_voltage,balancing,capacity_remaining,capacity_remaining_derived,charging_cycles,current:0.2,delta_cell_voltage,power:10,power_tube_temperature,temperature_sensor_1,temperature_sensor_2,total_charging_cycle_capacity,total_runtime,total_runtime_formatted,total_voltage:0.02Leider gibt es dann keine Events für das erste Reading in der neuen Zeile - und folglich wird auch nichts geloggt.

Beim Device handelt es sich um ein MQTT_DEVICE.

Hat jemand schon mal das gleiche beobachtet? Wie kann ich das weiter testen und ggf. eingrenzen?

Viele Grüße Gisbert
#2
FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version ...
Letzter Beitrag von RappaSan - 14 Mai 2024, 08:44:25
Habs gestern auch noch mal probiert, presence geht nach wie vor nicht.
72_FRITZBOX.pm 28642 2024-03-12 17:00:48Z jowiemann $ funktioniert...
#3
FHEM Code changes / Revision 28875: controls_fhem....
Letzter Beitrag von System - 14 Mai 2024, 08:40:25
Revision 28875: controls_fhem.txt: fhemupdate checkin

controls_fhem.txt: fhemupdate checkin

Source: Revision 28875: controls_fhem.txt: fhemupdate checkin
#4
Server - Linux / Aw: Offizielles FHEM Docker Ba...
Letzter Beitrag von rallye - 14 Mai 2024, 08:34:54
Zitat von: Sidey am 10 April 2024, 20:04:27
Zitat von: rallye am 10 April 2024, 15:40:23Danke an @Sidey für das Erzeugen des Images und @pasible für's aufmerksam machen.


Und funktioniert Fusionsolar nun wieder?
Alles bestens - es läuft wie ich mir es gewünscht habe.
Nochmals vielen Dank

(Sry für den Delay - war ziemlich lange in Urlaub)

Gruß Rallye
#5
Solaranlagen / Aw: SolarForecast currentInver...
Letzter Beitrag von DS_Starter - 14 Mai 2024, 08:28:07
Wie geschrieben ist das so falsch.
Das Reading heißt bei dir "eto". Da der Inhalt weder Wh noch kWh sind, brauchst du vorher ein umgerechnetes Reading. Das geht am enfachsten mit userReadings

Nehmen wir an, du erstellst ein userReading "etokwh" mit einem Inhalt in "kWh", wäre currentInverterDev so zu formulieren:

currentInverterDev   KacoHTTP pv=pac:W etotal=etokwh:kWh capacity=3600

Sollte an der Hilfe zu currentInverterDev noch etwas unkar sein, lass es mich bitte wissen. Wie die Schlüssel anzugeben sind ist meiner Meinung nach eindeutig beschrieben.
#6
MQTT / Aw: Bestway LayZSpar Wirlpool
Letzter Beitrag von Tueftler1983 - 14 Mai 2024, 07:50:29
So zusätzlich kann jetzt die Umgebungstemperatur "AMBC" gesetzt werden. Bei mir geschieht das via Doif mit einem Oregon Funk Temperatur sender. Dies dient zur internen Berechnung im Wirlpool Modul.
#7
TabletUI / Aw: Darstellung Sonnenbatterie
Letzter Beitrag von yersinia - 14 Mai 2024, 07:44:07
Zitat von: satprofi am 13 Mai 2024, 19:38:38Soc 86%
Power 800W
Errechnet werden 3,5h entladezeit.
Dann lass uns mal nachrechnen:
Zitat von: yersinia am 13 Mai 2024, 11:20:38Für die Berechnung definiert pvvis erst die basis:
socbasis = batmax ohne calc-bat-remain-soc-not-percent
socbasis = 100 mit calc-bat-remain-soc-not-percent
Die Berechnung erfolgt entsprechend dann
- fürs Entladen: (batmax * ([soc] / socbasis)) / Abs([charge-discharge])
- fürs Laden: (batmax * (1- ([soc] / socbasis))) / Abs([charge-discharge])
batmax = 28800
socbasis = 100 (da soc in % vorliegt)
charge-discharge = 800 (Wert ist positiv -> Akku wird geladen)

Der Ent-/Ladewert ergibt sich aus
chargeval = charge + gridCharge - dischargecharge = 800
gridCharge = 0 (gibt es bei dir ja nicht)
discharge = 0 (da Wert positiv und geladen wird, ist discharge = 0)
=> chargeval = 800
batremaintime = (batmax * (1- ([soc] / socbasis))) / chargeval
batremaintime = (28800 * (1 - (86 / 100)) / 800
batremaintime = (28800 * (1 - 0,86) / 800
batremaintime = (28800 * 0,14) / 800
batremaintime = 4032 / 800
batremaintime = 5,04
In diesem Fall werden 5,04h Ladezeit berechnet.

Sieht für mich, von der Berechnung her, nicht falsch aus. Dass der so errechnete Wert nur ein (sehr sehr) grober Schätzwert ist sollte klar sein. Wie schon erwähnt, hast du auch
[grid-charge]="PylonTech_Power:W"gesetzt, was die 800W noch zusätzlich hinzurechnen würde. Dies könnte den Schiefstand schon verursachen. Kannst du diesen Parameter weglassen, du hast das Reading sowieso schon via
[charge-discharge]="PylonTech_Power:W"eingebunden. Mit der doppelten Einbindung (2 * 800 = 1600) errechne ich dann entsprechend 2,52h Ladezeit.

Bereinige deinen Code und lass die sinnfreien Parameter weg (ich hab die Reihenfolge etwas umsortiert, der Übersichthalber würde ich gruppieren oder alphabetisch sortieren):
pvmax="7000"
[produce]="solarlog_totalpac:state"
[pv-prod-tdy]="SE7K:overview-energyDay"
batmax="28800"
[soc]="PylonTech_mSOC:mSOC"
[charge-discharge]="PylonTech_Power:W"
batstep="21,35,51,75,95"
calc-bat-remain-time
[feed]="SHRDZM_84F3EB1C394B:sensor_2.7.0_momentan_export"
[receive]="SHRDZM_84F3EB1C394B:sensor_1.7.0_momentan_import"
[grid-consume-tdy]="SHRDZM_84F3EB1C394B:statGesamt_Bezug_kWhDay"
[grid-feed-tdy]="SHRDZM_84F3EB1C394B:statGesamt_Einspeisung_kWhDay"
[wb-feed]="Wallbox:Watt"
no-wb-in-home
has-no-grid-feed
unit-soc="%"
unit-value="W"
unit-sum="Wh"
flow-threshold="0.5"
#8
Sprachsteuerung / Aw: Möglichkeit via Alexa z.b....
Letzter Beitrag von rabehd - 14 Mai 2024, 07:18:38
Zitat von: Dlay am 14 Mai 2024, 00:47:51Dazu müsste der Inhalt des Voice Readings ja "nur" an eine Telegram msg gehängt werden.
Das geht, aber erscheint mir sinnlos.
Soll FHEM alles was Du sagst versenden oder nur bestimmte Texte?
Deine Frage ist noch nicht ausgereift oder Du hast sie nicht vollständig formuliert.
Was wäre denn der Anwendungsfall?
#9
Wallboxen / Aw: Modul für Steuerung einer ...
Letzter Beitrag von Eckat - 14 Mai 2024, 07:16:53
Zitat von: Chris_XXX am 13 Mai 2024, 19:23:23Hi Carsten,

danke für deine Antwort. Tatsächlich schaut mein Setup ziemlich ähnlich aus. 2 Wallboxen, beide zusammen max. 11kw, Speicher (allerdings DIY). Ich triggere bei mir alles durch ein Smartmeter am Übergabepunkt.
Hast du unterschiedliche zweige für die Erhöhung bei 1phasig bzw. 3phasig gemacht? Bei 3phasig geht es bei 1A um mehr Leistung hoch als bei 1phasig.

VG
Christian

Hallo Christian,

habe das schon mehrfach umgebaut.
Aktuell rechne ich immer mit Leistung in Watt. Erst für die Ermittlung des PV-Überschuss und dann auch für die Ermittlung wie hoch die Ladeleistung sein darf.
Erst am Ende beim Einstellen der Stromstärke teile ich durch die Netzspannung um auf die Stromstärke zu kommen.
Das klappt ganz gut.

Das mit den größeren "Sprüngen" bei der Leistung im 3-phasigen Betrieb ist so.
Die Abgrenzung ob 1- oder 3-phasig geladen werden soll ist aber von der Normung abgenommen worden.
Typ2 kann Stromstärken ab 6 A in Schritten von 1 A, egal ob 1- oder 3-phasig.
Macht bei 1-phasigem Betrieb also 1 * 230 V * 16 A (für eine 11 kW Wallbox als Maximum) = 3.680 W.
Für 3-phasig sieht es so aus als Minimum: 3 * 230 V * 6 A = 4.140 W.
Das Minimum für 3-phasig liegt also über dem Maximum für 1-phasig.

Bei mir habe ich das Minimum von 4.140 W als Schwellwert für das Umschalten genommen. Liegt der Überschuss dazwischen, geht etwas in den Hausspeicher.

In der aktuellen Version bei mir habe ich auch zwei Schwellwerte definiert: Start-Ladeleistung-Prozent und Volle-Ladeleistung-Prozent.
Die Prozente beziehen sich auf den SoC der Tesla Powerwall 2.
Erst ab "Start-Ladeleistung-Prozent" fängt wenn überhaupt ein Ladevorgang an und erst bei dem Erreichen des SoC der Powerwall von "Volle-Ladeleistung-Prozent" wird der volle Überschuss ins Auto abgegeben.
Das führt dazu, dass morgens erst die Powerwall etwas aufgeladen wird, um z.B. Puffern zu können, wenn man morgens einen höheren Hausverbrauch hat, als die PV schon liefert.
Zwischen den beiden Werten "Start-Ladeleistung-Prozent" und "Volle-Ladeleistung-Prozent" errechne ich einen Faktor der linear den PV-Überschuss sozusagen "aufteilt" in einen Teil mit dem die Powerwall weiter geladen wird und einen anderen Teil mit dem schon das Auto geladen werden kann.
In der Praxis wird also die Powerwall auch noch weiter geladen, mit je steigendem SoC mit sinkender Leistung, bis der Wert "Volle-Ladeleistung-Prozent" erreicht ist. Dann geht der ganze PV-Überschuss ins Auto.

Mit dem Wert "Volle-Ladeleistung-Prozent" steuere ich übersetzt, wie viel SoC am Ende des Tages / am Ende der PV-Produktion in der Powerwall verbleibt um Nachts das Haus zu versorgen.

Planung für die Zukunft ist es noch, diesen Wert täglich zu ermitteln. Z.B. brauche ich mehr % on der Powerwall für die Nacht, je länger die Nächte sind (vielleicht Zeitraum zwischen Sonnenuntergang und Sonnenaufgang.

Gruß, Carsten
#10
Sprachsteuerung / Aw: Möglichkeit via Alexa z.b....
Letzter Beitrag von MadMax-FHEM - 14 Mai 2024, 06:43:29
Wenn dich nicht stört, dass Alexa (verm. jedesmal) antwortet: das verstehe ich nicht...

Bzw. auch bei "Fehleinfaben" der Text trotzdem im voice Reading steht (hab ich noch nicht getestet), dann einfach:

Eventmonitor auf, sprechen und auf das voice Reading Event warten, markieren und notify erzeugen lassen.

Erzeugtes notify anpassen.
In $EVENT sollte der Text zu finden sein.
Da verm. im Text Leerzeichen sind kannst du (verm.) nicht einfach $EVTPARTx nehmen, sondern musst den Text selber aus $EVENT holen...

Gruß, Joachim