jens-maus / RaspberryMatic

:house: A feature-rich but lightweight, buildroot-based Linux operating system alternative for your CloudFree CCU3/ELV-Charly 'homematicIP CCU' IoT smarthome central. Running as a pure virtual appliance (ProxmoxVE, Home Assistant, LXC, Docker/OCI, Kubernetes/K8s, etc.) or on a dedicated embedded device (RaspberryPi, Tinkerboard, IntelNUC, etc.)
https://raspberrymatic.de
Apache License 2.0
1.5k stars 184 forks source link

Access to all 6 heating / cooling week profiles via room #2795

Closed x4N70pHyLL closed 1 week ago

x4N70pHyLL commented 1 week ago

Describe the issue you are experiencing

If I use the room feature to combine thermostats (WTH-1 and BWTH) with FALMOT, there are still 6 week profiles I can set and adjust (3 for heating, 3 for cooling). If I want to change these externally via Home Assistant (homematic custom integration), I can only see 1-3 when in heating mode, none when in cooling mode.

Described in detail in this post: https://github.com/danielperna84/hahomematic/discussions/793#discussioncomment-4602543

Describe the behavior you expected

I want to also see week program 4-6 when in cooling mode and be able to change them via Home Assistant. The Homematic custom integration just displays whats coming from Homematic/Raspberrymatic.

Steps to reproduce the issue

  1. Create heating groups in Raspberrymatic
  2. Create rooms in Raspberrymatic and add the devices
  3. Use the room as thermostat in Home Assistant using custom homematic integration
  4. when in heating, you see WP1-3, but when in cooling, you can see no WP

What is the version this bug report is based on?

3.75.7.20240601

Which base platform are you running?

ha-addon (HomeAssistant Add-on)

Which HomeMatic/homematicIP radio module are you using?

HmIP-RFUSB

Anything in the logs that might be useful for us?

-

Additional information

No response

jens-maus commented 1 week ago

As @Baxxy13 pointed out (cf. https://github.com/danielperna84/hahomematic/discussions/793#discussioncomment-4602543) this is no limitation of RaspberryMatic but a design/vendor-decided decision of eQ3. Thus, there is nothing that this project (RaspberryMatic) can do about that.

github-actions[bot] commented 1 week ago

@x4N70pHyLL, the issue you reported cannot be solved within this project or should be better directly solved in the upstream OCCU project RaspberryMatic is just using. However, for being able to reference and track this upstream issue we will keep this ticket open for the time being so that you can also reference it accordingly.

github-actions[bot] commented 1 week ago

@x4N70pHyLL, the maintainer of this project has decided that the issue/idea you reported does not seem to be relevant for the projects' mission or that it is out of the scope or simply not explained in enough detail. This ticket will therefore be closed and you are advised to better discuss this issue in more detail in the discussion area of this project and then perhaps come back here and open a new issue in case consensus has been achieved within this discussion.

x4N70pHyLL commented 1 week ago

As @Baxxy13 pointed out (cf. danielperna84/hahomematic#793 (reply in thread)) this is no limitation of RaspberryMatic but a design/vendor-decided decision of eQ3. Thus, there is nothing that this project (RaspberryMatic) can do about that.

I did get that, however I was wondering if it makes sense to take it as an improvement in comparison to the "standard" Homematic software within this project here. As it seems to be not solved upstream.

jens-maus commented 1 week ago

I did get that, however I was wondering if it makes sense to take it as an improvement in comparison to the "standard" Homematic software within this project here. As it seems to be not solved upstream.

Not really possible because upstream defines that closed source and we are just using their device descriptions, etc. Thus, make a request for improvements upstream (@eQ3).

Baxxy13 commented 1 week ago

Ich hatte das "Problem" irgendwann/irgendwo schon mal detaillierter beschrieben. Es gibt, vereinfacht, 3 verschiedene "Heizungsarten" die immer mit dem selben virtuellen Gruppengerät abgebildet werden.

Bei B+C ist das WTH (mit seinen 6 Profilen) der alleinige Herrscher, denn es muss für B einfach nur den Aktor schalten und für C einfach nur SOLL/IST an den FALxxx übergeben.

A funktioniert grundsätzlich wie C nur das zusätzlich auch die Profile synchron sein müssen. Und genau hier ist der Haken. eTRV's haben nur 3 Profile. Das "dumme" virtuelle Heizgruppengerät weiß aber nicht welche "Heizungsart" es bedient (es können ja auch alle 3 sein) und daher wird der kleinste gemeinsame Nenner genutzt, nämlich nur 3 Profile.

Ich glaube nicht das eQ-3 hier irgendwas "optimiert". Aber das brauchen sie eigentlich auch gar nicht. Denn wenn B oder C genutzt wird kann man die Heizungssteuerung problemlos über das WTH machen und das virtuelle Heizgruppengerät "links liegen" lassen.

x4N70pHyLL commented 1 week ago

Ich glaube nicht das eQ-3 hier irgendwas "optimiert". Aber das brauchen sie eigentlich auch gar nicht. Denn wenn B oder C genutzt wird kann man die Heizungssteuerung problemlos über das WTH machen und das virtuelle Heizgruppengerät "links liegen" lassen.

Das hatte ich mir so auch überlegt, bin aber davor zurückgeschreckt, weil ich in mindestens einem Raum noch einen Heizkörper habe (Handtuchtrockner) und damit über kurz oder lang mir hier die Möglichkeit verbauen würde, den mitzusteuern. Sonst konnte ich bisher auch keine Nachteile finden, aber vielleicht hab ich was übersehen?

Baxxy13 commented 1 week ago

Ich würde das eTRV vom Handtuchheizer "autark" betreiben, also nicht gruppiert mit WTH und FALxxx. Letztlich klappt das in der Gruppe eh nicht denn wenn du im WTH z.B. "Profil 4" vorgibst dann bleibt das eTRV auf seinem aktuellen Profil (oder geht auf 3, weiß ich nicht genau). Außerdem kann ein eTRV nicht "kühlen", es wäre also sinnlos ihm ein Kühlprofil unterzujubeln.

x4N70pHyLL commented 1 week ago

Das wäre jetzt in meinem Setup kein Problem. Ist ja sowieso das selbe (kühle) Wasser, dass von der Wärmepumpe kommt, ob es jetzt durch Heizkörper oder Fußboden geht ist egal. Alternativ unterscheide ich heute schon zwischen Heizkörpern und Fußboden, so dass ich beim umschalten auf Kühlbetrieb das auch unterscheiden kann.

Ein anderer Grund warum ich die Räume ursprünglich genutzt habe ist, dass die eine Ventilstellung haben und der Thermostat nicht. Dort wird aber eben NICHT die Ventilstellung der zugeordneten FALMOT-Kanäle angezeigt, sondern gar nichts, was ich auch für einen Bug halte

Baxxy13 commented 1 week ago

So langsam wird's OT: eTRV's kennen nur eine "Regelrichtung" und zwar öffnen wenn SOLL > IST. Fließt jetzt Kühlwasser durch dein System müsstest du dem eTRV einen hohen Sollwert vorgeben damit es öffnet. Da es diesen Sollwert nie erreichen kann wird es wohl darauf hinauslaufen das es irgendwann einfach 100% geöffnet ist.

Die Sache mit den Ventilstellungen ist m.E. was für den inneren Monk oder Kontrollfreak. Eingreifen in die Regelung kann man eh nicht, es sei denn man spielt an seiner Heizungsanlage mit den Durchflüssen rum. Was man bei einer gut eingestellten Anlage allerdings möglichst vermeiden sollte.