HM-CC-RT-DN mit externen Temp-Sensor verknüpfen

[quorle]

Hallo Gemeinde,

ich versuche gerade eine eigene Steuerung auf zu bauen, jedoch scheitere ich gerade etwas und stelle mir gerade ein paar fragen. Vielleicht könnt ihr die mir beantworten.

1. Ist es möglich den HM-CC-RT-DN Thermostat eine Temperatur zu senden ( nach dem er regeln soll ), die von einem externen Temp-Sensor kommt? Der Temp-Sensor wäre ein TFA und ich habe diesen mittel CUxD eingebunden ( zeigt auch Feuchte und Temp richtig an ) !? Denn ich kann den externen Sensor nicht mit dem Thermostat verknüpfen.
2. Ich benutze io.Broker, jedoch wird mir Kanal 1,2,3 nicht in den Objekten angezeigt, sonst hätte ich die gemessene Temperatur mittels io.Broker auf den _Weather Kanal gesendet. Kann man die Kanäle irgendwie anzeigen lassen, sodass alles in io.Broker angezeigt wird?

[manfredh]

Irgendwie verstehe ich nicht, was du meinst.

Du möchtest eine gemessene Temperatur ("...Sensor...") als Solltemperatur (???) an den Aktor übergeben? Der Sinn erschließt sich mir nicht ganz.

In ioBroker des Wert des Datenpunktes x in den Datenpunkt y (auch eines anderen Gerätes) zu übertragen ist problemlos möglich.

Versuche doch bitte mal dein Ziel allgemeinverständlich zu formulieren.

Gruß
Manfred

[66er]

Hallo.

Das dürfte, wenn überhaupt, ein Thema für die Skriptprofis sein.

@Manfred:
Wenn ich der TE richtig verstehe, soll der externe Sensor die Messung anstelle des HM-CC-RT-DN übernehmen, aber eben diesen bzw. den Heizkörper regeln.

LG
Stefan

[quorle]

Hey schon mal danke für die Antworten.

Ja der interne Temp-Sensor soll durch den externen ersetzt werden. Der externe Sensor soll die Messung übernehmen, die Temperatur soll vom externen Sonsor auf den Thermostat übertragen werden.
Der Kanal _WEATHER sollte dafür ja da sein, den kann man in der CCU aber nur mit einem Wandthermostat verknüpfen, den ich aber nicht nutze.

Ich hätte es ja in io.Broker erledigt, aber dort wird mir der Kanal nicht angezeigt und ich bekomme es auch nicht hin, dass er angezeit wird.

Sollte ich mein Problem vielleicht im Scriptbereich noch einmal stellen?

[paul53]

Sollte ich mein Problem vielleicht im Scriptbereich noch einmal stellen?

Das wird nichts nützen. Wenn es keinen Datenpunkt gibt, kann man auch mit einem Script nichts ausrichten. Der WEATHER-Kanal ist ein Link-Kanal für Direktverknüpfungen und liefert keine Datenpunkte (VALUE Parameter).

[quorle]

Jetzt wird es kompliziert.
Mittels FHEM könnte man einen externen Sensor mit dem _WEATHER Kanal verknüpfen. Was wahrscheinlich in io.Broker auch möglich wäre, aber da er mir nicht angezeigt wird, funktioniert es leider nicht, da ich nichts zum Verknüpfen habe.
Wobei FHEM ja alles ohne die CCU2 verbindet.

[paul53]

Mittels FHEM könnte man einen externen Sensor mit dem _WEATHER Kanal verknüpfen...Wobei FHEM ja alles ohne die CCU2 verbindet.

Das kann ioBroker auch mit dem Adapter iobroker.hmm, aber er verbindet nur kompatible HM-Kompenenten miteinander, so wie auch FHEM.

[quorle]

Den Adapter iobroker.hmm nutze ich ja bereits, um Daten auszulesen. Aber wie gesagt, zeigt er mir z.B. unter hm-rpc.1 nur Kanal 0 und 4 des Thermostates an und die restlichen Kanäle bleiben verschwunden. Somit kann ich auch den Temp-Sensor nicht auf den _WEATHER Kanal leiten.

Würde es vielleicht über Variablen geben, oder eine andere Möglichkeit?

[OiledAmoeba]

...verbindet nur kompatible HM-Kompenenten miteinander, so wie auch FHEM.

Da muss ich dir widersprechen.
Mit FHEM ist es tatsächlich möglich, z.B. den HM-CC-RT-DN mit einem virtuellen Sensor zu peeren und ihm dann auf Ch:1 (regelmäßig) eine Ist-Temperatur zu senden. Dem Heizungsregler ist egal, ob das Telegramm von einer Hardware oder Software kommt. Der will nur, dass der Sender in seiner Peering-Liste steht. In der CCU2 scheitert das schon daran, dass man keine virtuellen Geräte mit den Komponenten peeren kann. Selbst wenn man ein Script hätte (das sich aus der 10_CUL_HM.pm von FHEM ableiten ließe), würde der Heizungsregler die Temperatur nicht akzeptieren, da er nicht gepeert ist.
Leider ist die CCU(2) extrem beschnitten und benutzerunfreundlich, was das angeht. Mir geht nicht so ganz in den Kopp, warum FHEM das kann und die "Originalhardware" nicht...

BTW: Interessant finde ich da HmIP-RF, dort gibt es den DP 1.LEVEL und dieser ist beschreibbar. So bekommt man zwar keine Ist-Temp in das Ding, aber mit CUxD-Wrapper könnte man dort das Ventil abhängig einer externen Temperatur steuern. (Probiert hab ich's aber noch nicht)

Hier suche ich auch dringend eine Lösung, denn ich möchte ungern mit meinen Nicht-IP-Geräten zurück zu CUL. Nicht weil ich FHEM nicht mag, ganz im Gegenteil, die CCU ist bei mir nur das IO-Device. Sämtliche Steuerung läuft in FHEM. Aber ich will keine zwei IO-Devices für HM.

Edit: Rächtschraibung

[quorle]

Also ich hätte zwei Lösungsvorschläge für mein Problemchen und wollte mal euch fragen, was sinnvoller wäre.

1. Lösungsvorschlag:

- Ich lagere die CCU2 (pivccu) auf einen externen RPI aus, somit liefe io.broker autark auf dem zweiten RPI.
- Dann installiert man einfach auf dem RPI wo pivccu läuft FHEM --> somit könnte man die Sensoren miteinader peeren und mittels io.broker schalten und walten was man will.

2. Lösungsvorschlag:

- man lässt alles wie es ist und regelt den Heizkörperthermostat mittels Script ( PI-Regler ).
- in diesem PI-Regler wird dann in Prozent ausgegeben wie weit das Stellventil aufgefahren werden sollte. Diesen Prozentsatz rechnet man dann mit einem Dreisatz in eine "anzusteuerende" Temperatur um und schickt diese Temperatur an den Regler als Sollwertvorgabe, der dann mit dieser Temp regeln kann.
Dreisatz: 5°C --> Regelweg ( sollte reichen ) geteilt durch 100 % mal Prozentwert aus PI-Regler ist gleich neue_Sollwertvorgabe