Darstellung Sonnenbatterie

Begonnen von dennis_n, 11 März 2021, 10:33:34

Vorheriges Thema - Nächstes Thema

yersinia

#90
Zitat von: octek0815 am 10 Juli 2022, 20:48:15hast du mal die neue pvvis.component.js parat, zwecks testen (in der eigene Oberfläche) ;-)
Jup. Aber sowohl die js als auch css müssen ersetzt werden.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

yersinia

#91
Kleines Update:
- kleine Korrektur: einige classes wurden falsch zugeordnet
- Erweiterung: neuer experimenteller parameter do-not-show-zero: wenn gesetzt (Verwendung analog zu has-no-battery), werden alle gerundeten 0-Werte nicht angezeigt.

Nutzung weiterhin wie in #57 (und bezgl battstep das Update in #64 sowie von unit-soc und unit-value das Update in #82) beschrieben.

viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

mr_petz

Ich habe mal auf gefällt  ;) mir geklickt für dein Arrangement hier, wenn es sonst keiner macht...

LG mr_petz

octek0815

Zitat von: mr_petz am 11 Juli 2022, 17:39:18
Ich habe mal auf gefällt  ;) mir geklickt für dein Arrangement hier, wenn es sonst keiner macht...

LG mr_petz

Recht hast du!

h002

#94
Ich bin bei ftui3 gerade auf Entdeckerreise und von dieser Komponente begeistert. Ganz tolle Arbeit! Beim Probieren ist mir bei meiner Anlage was aufgefallen (siehe Bild), was sehr wahrscheinlich auch andere Gründe haben könnte.

Wenn das Reading der Anlage sich verändert, reagiert die Anzeige von ftui-pvvis sehr verzögert und rechnet das Laden der Batterie dem Hausverbrauch zu.

Kurz mein Bild erklärt:
- PV liefert 923
- Haus benötigt 507
- Batterie läd mit 417 (wird aber nicht in SVG angezeigt)
- Einspeisung in das Netz 3 (Einspeisung wird bei mir neagtiv angezeigt)

Die Werte werden bei meinem S10 Device aller 10 Sekunden geladen (event-on-change-reading und event-on-update-reading haben den Wert ".*". Trotzdem zeigt er in regelmäßigen Abständen keine Batterieleistung an, sondern rechnet diese dem Hausverbrauch zu. Nach erneuter Änderung der Readings klappt es manchmal mit der Anzeige. Ich kann es nicht so richtig reproduzieren.

Was könnte die Ursache sein?


<ftui-pvvis
                            [pvmax]="8000"
                            [soc]="S10E:Batterieladezustand"
                            [feed-receive]="S10E:Netzleistung | multiply (-1)"
                            [charge-discharge]="S10E:Batterieleistung"
                            [produce]="S10E:Solarleistung"
                            grid-icon="pylon"
                            width="400px"
                        >
                        </ftui-pvvis>


Ich weiß, die Werte passen mit dem Bild nicht genau, aber das Grundproblem sollte verständlich sein.

Eine Frage fehlt mir noch ein. Kann man die aktuellen Werte auch ohne Berechnung anzeigen lassen?

mr_petz

Hi, ok als erstes die [] wegnehmen bei pvmax.
pvmax ist hier ein fester Wert und kein Reading.

@yersinia
Hier scheint was falsch zu sein im Code (denke ich zumindest):

    case 'charge-discharge':
            // one reading - negative when discharge; positive when charge
            if(this.chargeDischarge < 0) {
               this.discharge = Math.abs(this.chargeDischarge);
               this.charge = 0;
            } else if(this.feedReceive > 0) {
               this.charge = this.chargeDischarge;
               this.discharge = 0;
            } else {
               this.charge = 0;
               this.discharge = 0;
            }
    break;

müsste:

    case 'charge-discharge':
            // one reading - negative when discharge; positive when charge
            if(this.chargeDischarge < 0) {
               this.discharge = Math.abs(this.chargeDischarge);
               this.charge = 0;
            } else if(this.chargeDischarge > 0) {
               this.charge = this.chargeDischarge;
               this.discharge = 0;
            } else {
               this.charge = 0;
               this.discharge = 0;
            }
    break;

copy/paste?? ;D
LG

yersinia

#96
Zitat von: mr_petz am 15 Juli 2022, 13:33:27Hi, ok als erstes die [] wegnehmen bei pvmax.
pvmax ist hier ein fester Wert und kein Reading.
+1

Zitat von: mr_petz am 15 Juli 2022, 13:33:27            } else if(this.feedReceive > 0) {
müsste:
            } else if(this.chargeDischarge > 0) {
copy/paste?? ;D
:o ::) *hust* Neeeeeiiiiin. Tausend mal geprüft und nicht gesehen.  ::) Danke @h002 fürs melden! :) Korrigierte Version anhängend.



Nutzung weiterhin wie in #57 (und bezgl battstep das Update in #64 sowie von unit-soc und unit-value das Update in #82) beschrieben.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

h002

Genau das war es. Hatte es auch im Code gesehen, dachte aber das feedReceive muss so sein, da ich ungeeignet bin die Gesamtlogik zu verstehen und mich nicht blamieren wollte. :-)

Für mich funktioniert es wie erwartet. :-)

Nochmals Danke für die prima Umsetzung!  :D

yersinia

Zitat von: h002 am 15 Juli 2022, 13:49:39Genau das war es. Hatte es auch im Code gesehen, dachte aber das feedReceive muss so sein, da ich ungeeignet bin die Gesamtlogik zu verstehen und mich nicht blamieren wollte. :-)
Neee, das ergibt ja keinen Sinn. feed-receive und charge-discharge dienen nur als Vehikel um dann intern feed, receive, charge und discharge zu definieren. Da hat bei charge-discharge feedReceive nüschts zu suchen.
Ansonsten kann man sich hier auch gerne in der Gruppe blamieren - zumindest ich kann nur Trockentesten mangels PV Anlage. Daher ist Feedback von euch sehr willkommen - insbesondere mit readings list.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

mr_petz

Zitat von: yersinia am 15 Juli 2022, 13:46:20
...
:o ::) *hust* Neeeeeiiiiin. Tausend mal geprüft und nicht gesehen.  ::)...
...

Keine Sorge... passiert auch den Besten.  ;)
Aber hier sehen ja viele Augen hin. Nichts bleibt unaufgedeckt... ;D
LG

OdfFhem

@h002

Zitat
event-on-change-reading und event-on-update-reading haben den Wert ".*"

Ist nicht zu empfehlen bzw. macht die Attribute wirkungslos ...

mr_petz

#101
Zitat von: OdfFhem am 15 Juli 2022, 15:34:04
@h002

Ist nicht zu empfehlen bzw. macht die Attribute wirkungslos ...

Hi OdfFhem, lange nichts gehöhrt voneinander... :D
Ich denke event-on-change-reading macht schon sinn, wenn man es richtig anwendet.
im Bsp von @h002:

attr S10E event-on-change-reading Batt.*,Netzleistung,Solarleistung

so werden nur Event´s für FTUI,notify,log etc. erzeugt aus den 4 Readings wenn sie sich ändern.
Zur Not noch einen threshold einfügen wenn ein Wert minimal schwankt.
Die Systemlast wird dadurch auch reduziert.
Es sei denn er braucht mehr. Oder sehe ich das falsch??
https://wiki.fhem.de/wiki/Event-on-change-reading#Syntax

event-on-update-reading hingegen würde ich so auch nicht anwenden.
Höhere Systemlast.
Ist ja glaube automatisch in fhem, dass Events bei update erzeugt werden oder?

LG

OdfFhem

@mr_petz

Hi, der nächste Herbst/Winter kommt bestimmt ;)


Es ging tatsächlich um die von h002 genannte Kombination:
- event-on-change-reading auf ".*" ... nur Wertänderung beim Reading führt zum Event
- event-on-update-reading auf ".*" ... jede Aktualisierung (auch ohne Wertänderung) beim Reading führt zum Event
==> entspricht exakt dem Standardverhalten ... die beiden Attribute könnte man also so auch weglassen


event-on-change-reading findet mit ".*" breites Interesse, da man damit massiv unnötige Events vermeidet - im Zweifel kombiniert mit Schwellwerten
event-on-update-reading verwendet man eigentlich nur für (eher einzelne) Readings, die auch mit demselben Wert eine Bedeutung haben ... z.B. leiser/lauter oder rauf/runter

h002

Ich hatte event-on-update-reading für einen Test wegen dem o.g. Problem mit der Batterie eingetragen und später wieder entfernt. Bei event-on-change-reading habe ich produktiv spezifische Readings, damit u.a. das Statistik-Modul greift.

Vielen Dank trotzdem für den Hinweis.

Skusi

Tolle Arbeit !!! Sieht sehr ansprechend aus . Ich bin auf der Suche nach genau so etwas und habe nicht schon gefreut endlich was gefunden zu haben.
Nun hab ich genauer hingesehen und bemerkt das sich dieses Widget wohl nur unter FTUI3 installieren lässt. Leider habe ich mein ganzes Projekt auf FTUI2 laufen.

Gibt es eine dafür Lösung außer das ich meine seehr umfangreiches UI umstelle was definitiv nicht in Frage kommt !
RPI3B, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,ESPEasy an S0 Stromz., MAX Fensterkontakte, IButton, SonOff Tasmota, ESP LED Controler