openWB Forum

Zu dem CMI und dem Werte übergeben kann ich aus eigener Erfahrung beisteuern, dass das CMI max. alle 10s den modbus pollt. (Siehe meinen Projekt-Thread) per Json gibt das CMI nur Daten alle 15s raus, nimmt aber keine entgegen. Die 10s reichen aus, um schöne Sägezähne in den Verbrauchskurven hinzuzaubern. Meiner Erkenntnis nach gehen nur Sensorwerte verzögerungsfrei in die TA-Welt. Digital ist halt ein potentialfreier Shelly, knifflig wird‘s mit analogen Werten. Vielleicht experimentiere ich irgendwann mal mit den 0-10V herum, die waren damals, als ich an dem Projekt saß, gerade in der Mache. (Es gibt da für 45 Euros einen 5-fach PWM/0-10V Eingang für den DL-Bus, der ist bei mir noch unbelegt)

Thema Pufferspeicher und wasserführender Kamin: ja, habe ich auch. Ich hoffe, du hast an eine Rücklaufanhebung auf 60° gedacht. Falls nicht, schnell nachbauen, damit das mit dem Glanzruß nicht überhand nimmt. Bei mir sind es 1200l, wobei das obere Drittel für WW-Bereitung reserviert ist. Beheizt wird der speicher von Kamin, Solar, öl und eben dem Heizstab. Wobei Öl nur in den wirklich kalten Zeiten notwendig ist, sonst reicht der Kamin. Es ist aber auch keine 23° in der Bude, eher 19°.

Nachtrag: was ist denn das CoE, über das ssmcon in die TA-Welt kommt? Das kenne ich nicht

Nachtrag: was ist denn das CoE, über das ssmcon in die TA-Welt kommt? Das kenne ich nicht

Das hier ist der Link: https://github.com/jotata/SymconJoTTACoE#symconjottacoe

Und in der Tat, die Rücklaufanhebung ist eingebaut - mit Glanzruß hab ich eigentlich keine Probleme.

Na, das ist aber auch ein ganz ordentlicher Hack. CAN over Ethernet ist von TA dafür erfunden worden, aus zwei CAN-Bussen über Ethernet gekoppelt, einen zu machen. Also implementiert das da oben einen CMI mit einem dahinter liegenden TA-Regler, der entweder die Werte real existierender Regler importiert oder die des implementierten exportiert. Sollte aber Real-Time funktionieren.

https://wiki.ta.co.at/CAN_over_Ethernet_(CoE)

Ich hatte mal den kurzen Ideenblitz, ein eigenes CAN-Device in den TA-Bus zu hängen und mal zu kucken, was da so passiert schnell wieder drangegeben. Hat aber wohl einer durchgezogen.

Na, schau da einer kuck: TA macht mit einer Heidelberg-Wallbox Überschussladen.

https://www.youtube.com/watch?v=Crxr6QfTt38

Damit die Ansteuerung per modbus auch aus der TA-Welt funktioniert, braucht es wohl ein weiteres TA-Kästchen für 200+ Euros.

Spannend - geht also doch. Bei mir wird's nur andersrum laufen: das Energiemanagementsystem (das zufällig auf der Wallbox läuft...) gibt der TA den Überschußstrom frei.

Ich hab das ein bisschen mit einem Dummygerät in Smarthome 2.0 getestet. Über MQTT werden die korrekten Werte übermittelt, als Integer. Passt auch mit dem Vorrang von Haus, Hausspeicher und Auto.

Das macht Sinn, wenn man bedenkt, was die openWB für die EV's und das Energiesystem (EVU-Zähler, PVA, Speicher) schon alles kann. Smarthome wird weiter ausgebaut.
Als Standalone-Variante hat man den Energiemanager-Teil auch schön separiert verfügbar.

DirkA hat geschrieben: ↑Mo Jul 08, 2024 12:35 pm ch hab das ein bisschen mit einem Dummygerät in Smarthome 2.0 getestet. Über MQTT werden die korrekten Werte übermittelt, als Integer. Passt auch mit dem Vorrang von Haus, Hausspeicher und Auto.

Das, was im aktuellen smarthome noch nicht geht, ist Prio Heizen, das Auto kommt immer zuerst. Das wird aber im Zuge mit der Umstellung des smarthome auf die 2er-Architektur kommen. (Aktuell läuft noch das selbe smarthome-coding auf der 2er wie auf der1.9er)

Das, was im aktuellen smarthome noch nicht geht, ist Prio Heizen, das Auto kommt immer zuerst.

Ich sehe das im Augenblick nicht so kritisch. Wenn ich unbedingt das Heizen vorziehen will, häng ich eben das Auto ab. Auch eine Art "Schalter"...

Ladepunkt auf Stop oder Standby tuts ja auch.

Geht halt nur noch nicht automatisch.

Das sollte ich doch auch über MQTT schalten können, oder? Dann kann ich das über ein bisschen Logik über Symcon anstoßen.