Leistungsprognose für Wechselrichter

[DS_Starter]

Sieht alles soweit gut aus.
Ich habe bei mir deine Attribute soweit möglich nachgestellt. Funktioniert damit bei mir auch einwandfrei.
Hinweis: Das Attr ctrlAutoRefreshFW hat nur eine Funktion wenn auch das Attr ctrlAutoRefresh eingeschaltet ist.

Longpoll = Websocket habe ich auch eingestellt.

Wichtig für die Funktion ist, dass state ein Event bringt. Das kannst du im Eventmonitor überprüfen.
Ansonsten fällt mir grad nicht viel ein. Testweise kannst du das Device mal in einen separaten Raum zuordnen und die Funktion in diesem separaten Raum prüfen um evtl. störende Nebeneffekte anderer Devices auszuschließen. Ist bisschen weit hergeholt, aber machmal ...

Edit: Browsercache mal geleert ?

[300P]

Das Problem mit der Aktualisierung hatte ich am Anfang auch mal

Bei mir war dann am Ende die Lösung mit "nur"

Code Auswählen Erweitern

...
attr Forecast ctrlInterval 10
attr Forecast disable 0
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicAnimate 1
.....

und auf jeden Fall (bei mir) immer ohne "dies"

Code Auswählen Erweitern

attr Forecast ctrlAutoRefreshFW WEB

....und FHEM kompletter Neustart hier nach der durchführten Veränderung wirkt evtl. auch besser.

Bei meinen Fritzbox-gedöns hab ich z.B. beim Springbrunnen im Device auch (wie du) "event-min-interval .*:300" stehen.
Das dauert dann dort bei mir immer bis zu 6 Minuten ehe das "richtig und geändert" angezeigt wird.

Gruß
300P

 

[Dracolein]

Kurz nachgefragt auf der Suche, wo ich einen Fehler gemacht habe: Ich möchte zwei existente Readings modifizieren und deren Dimension (Wh) vom numerischen Wert trennen und habe dazu folgendes userReading erstellt

Code Auswählen Erweitern

RestOfDayPVforecast_num:RestOfDayPVforecast:.* { ReadingsNum($name,'RestOfDayPVforecast',0) },
Tomorrow_PVforecast_num:Tomorrow_PVforecast:.* { ReadingsNum($name,'Tomorrow_PVforecast',0) }

RestOfDayPVforecast_num wurde wie gewünscht angelegt und funktioniert. Tomorrow_PVforecast_num hingegen wird nicht angelegt, obwohl Tomorrow_PVforecast bereits mehrfach aktualisiert wurde. Wo liegt mein Fehler?

[DS_Starter]

Schreibe es beides besser so:

Code Auswählen Erweitern

RestOfDayPVforecast_num:RestOfDayPVforecast.* { ReadingsNum($name,'RestOfDayPVforecast',0) },
Tomorrow_PVforecast_num:Tomorrow_PVforecast.* { ReadingsNum($name,'Tomorrow_PVforecast',0) }

D.h. nimm ":" hinter den beiden _PVforecast weg.

[stefanru]

Ok danke fürs schauen.
Das heißt für mich es sollte gehen.

Im Event Monitor sehe ich beim Schalten vom Tuya Device nur:
2023-05-06 17:19:23 fhempy tuya_local_bf0572e0fb6ccbe356ykuh on
2023-05-06 17:19:24 fhempy tuya_local_bf0572e0fb6ccbe356ykuh on

Und vom Forecast Device sehe ich:
2023-05-06 17:19:24 SolarForecast Forecast updated


Sind das die state events oder müsste da auch state stehen?
Habe auch mal
event-min-interval .*:300
event-on-change-reading .*
entfernt.

Hat aber leider auch nichts gebracht.

Dann habe ich einen Testdummy angelegt.
Der Testdummy schaltet und es updated in der Raum Übersicht.
Im EventMonitor sehe ich für den Testdummy:
2023-05-06 17:41:36 dummy testdummy on
2023-05-06 17:41:36 SolarForecast Forecast updated

Sieht gleich aus wie beim Tuya device.
Komisch warum updated es beim Tuya device nicht?

Also mit einem Dummy geht es mit dem Tuya Device nicht.
Das Tuya Device feuert im Event Monitor immer 2 mal im Gegensatz zum Dummy Device.
Events scheinen ok.

Was ich noch bemerkt habe, wenn ich mit dem Tuya device im Forecast in der Raum Übersicht schalte, schaltet das Tuya Device aber der Status ändert sich nicht in der Anzeige vom Forecast Device.
Drücke ich dann nochmal auf den Schalter der noch im alten Status hängt im Forecast Device ändert sich der Status auf den richtigen Wert. Also updated.
Habt ihr noch eine Idee?

Danke und Gruß,
Stefan

[stefanru]

Ok jetzt habe ich eine Vermutung:

Im Event Monitor sehe ich folgende Reihenfolge beim Schalten:
2023-05-06 18:01:16 SolarForecast Forecast updated
2023-05-06 18:01:16 fhempy Stefan_Tablet_bf0572e0fb6ccbe356ykuh off

Also zuerst das Update vom Forecast, dann der Statuswechsel vom Tuya.

Drücke ich dann nochmal im Forecast UI auf den Knopf kommt noch ein
2023-05-06 18:01:33 SolarForecast Forecast updated
und der Status wird upgedated.

Das Update vom Forecast scheint zu früh zu kommen.

Liegt das daran das Tuya vielleicht erst den status umsetzt wenn der Schaltbefehl von der Steckdose bestätigt ist?

Muss ich mich an den Tuya Autor wenden oder wie gehe ich hier am besten vor?

Gruß und Danke,
Stefan

[DS_Starter]

Deine Vermutung kann stimmen.
Es könnte sein, dass Tuya non-blocking (asynchron) arbeitet. Müsste ich mir mal anschauen.

Wenn das stimmt, dann wird der Status im Tuya mit Sicherheit erst upgedated wenn SF mit seiner Routine schon durch ist.
Wenn SF den nächsten Zyklus ausführt, sollte sich dann der Schaltzustand des Tuya richtig in der GUI zeigen.
Ist das so ?

[stefanru]

Hi Heiko,

ja stimmt genau.
Beim nächsten Update von SF zieht es sich gerade.
Tuya arbeitet wohl asynchron.

Gestern hatte ich noch den Fehler gemacht SF in der Datail Ansicht zu schalten.
Heute in der Raumansicht ist das verhalten völlig klar.

Update von SF kommt zu früh, also vor dem on/off vom Tuya.
Mit dem nächsten Update von SF zieht es sich gerade.

Gruß,
Stefan

[DS_Starter]

Das ist natürlich nicht so einfach zu lösen.
SF läuft ja über eine zyklische Abfrage aller definierten Devices, auch der Consumer Devices.

Um den Status asynchron arbeitender Consumerstatus "zeitnah" in SF darzustellen, müsste ich in einer Notify Funktion verarbeiten. Allerdings darf es nicht mit synchron arbeitender Consumer kollidieren, deren Status über die Schleife und quasi zeitgleich nochmal über eine Notify in SF verarbeitet werden.

Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt.
Hmm ... nicht ganz trivial.

[DS_Starter]

Wie wird denn ein Tuya Device definiert ? das List sieht etwas anders aus als gewöhnlich. Es gibt kein Internal TYPE.

[DS_Starter]

Jetzt habe ich mir diese Seite

https://github.com/fhempy/fhempy#installation

kurz angeschaut. Das ist offensichtlich asynchron und vor allem wieder ein eigenes "Universum". 

[DS_Starter]

Also ich habe eine Idee.
Eventuell kann ich dan Problem lösen indem ich einen Consumerschlüssel "asynchron" einführe.
In dem Fall wäre es für das Modul ein Schalter um asynchron über Notify auf Statusänderungen zu reagieren.
Könnte funktionieren.

Ich probiere das mal und melde mich wieder wenn ich etwas brauchbares habe.

[stefanru]

Ok, das klingt gut.
Wenn es geht nach dem Status wechsel des Consumers asynchron nochmal etwas verzögert den Consumer abfragen.

Gib bescheid wenn ich etwas testen kann.
Habe das Problem ja hier und teste gern wenn du etwas hast.

Gruß,
Stefan

[Skusi]

Hallo zusammen,
bei mir läuft das Modul nach Monaten der Einlernzeit wirklich sehr zufriedenstellend.
Vielen Dank dafür !!!
Es ist eine Große Hilfe meine Consumer "schlau" damit zu schalten. Und sogar der WAF Faktor stimmt

Nun ist mir eben aufgefallen das das Modul in der Web Ansicht seit Tagen " Abweichung heute: -, gestern: -100,6 %" anzeigt.

Hat jemand einen Tipp wo ich was verschlimmbessert haben könnte das der Wert auf -100,* % steht.
Das war früher nicht so. Die Balken im Graphen sehen eigentlich recht genau aus.
Also - 100 % kann nicht stimmen.

[dk3572]

Hallo Heiko,

in der Verbraucherplanung wird mir statt der Uhr dieser Text angezeigt:

"it_ups_charging@green"

Kannst du sagen woher das resultiert?

Meine Vermutung:
Planung liegt innerhalb der Zeit aber meine "externe" Bedingung swoncond war noch nicht erfüllt.
Nachdem die swoffcond Bedingung erfüllt wird, wird der Verbraucher auch nicht eingeschaltet.

Danke und VG
Dieter

Edit
Es hängt wohl eher mit dem affectBatteryPreferredCharge zusammen.
Als der Wert erreicht wurde, wurden die Verbraucher eingeschaltet und die Uhr wurde wieder angezeigt.