Hallo,
habe nun ein Thermokon SR06 im Einsatz, eep D2-11-01, subType roomCtrlPanel.01. Dabei habe ich festgestellt, dass die Werte, die vom SR06 gesendet werden, nicht immer in die entsprechenden Readings des FHEM Devices übernommen werden. Es hängt anscheined vom "trigger" ab, was übernommen wird. Wenn trigger = sensor, werden die setpointxxx Readings NICHT übernommen (außer setpointType). Das kann problematisch sein, wenn am SR06 mit den Tastern die Solltemperatur verstellt wurde, das Signal aber wegen schwachem Akku oder schlechter Verbindung nicht beim Transceiver ankam. Beim nächsten Senden wegen geänderter Ist-Temperatur wird die neue Solltemperatur zwar mitgeschickt, aber nicht in die Readings übernommen!
Gibt es einen Grund, warum das so ist?
Mein Wunsch: das SR06 hat immer Recht, d.h. unabhängig vom "trigger" immer alle Werte in die FHEM Readings übernehmen.
Zweiter Wunsch: ein Set Befehl für setpointShift. Damit könnte man auch 0.5° Schritte in der Solltemperatur vorgeben.
Oh, ein Smart-Ack Nutzer.
Das muss wegen der Besonderheiten der bidirektionalen Kommunikation so sein. Einige Sollwerte können sowohl am Gerät als auch in Fhem gesetzt werden. Damit immer der zuletzt gesetzte Wert gilt, egal ob am Gerät oder in Fhem eingestellt, werden die "Trigger"-Werte in Fhem nur dann übernommen, falls ein Trigger-Telegram ankommt.
Bei der bidirektionalen Kommunikation mit batteriegespeisten Geräten (z. B. mit Smart-Ack Profil) werden die Fhem set-Befehle erst einmal zwischengespeichert, bis das Gerät ein Telegramm sendet und eine kurze Zeit auf eine Antwort des Gateways (Fhem) wartet. Das Gerät kennt zu diesem Zeitpunkt den neuen Wert aus dem set-Befehl noch nicht. Um sicherzustellen, dass ein älterer Wert in Fhem nicht wieder den set-Wert überschreibt, werden nur set-Werte aus dem Gerät übernommen, die in einem Trigger-Telegramm kommen.
Da Fhem seinen set-Befehl bei Smart-Ack im Transceiver "parkt", wird der Befehl in jedem Fall gesendet und man kann beim Empfang eines Telegramms im Fhem-Modul auch nicht mehr per Fallunterscheidung eingreifen.
Dies ist z. B. bei beim subType hvac.01 für Heizkörper-Aktoren anders. Dort wird das Gerätetelegramm ausgewertet, ggf. bei eingeschaltetem PID-Regler ein neuer setpoint-Wert berechnet und sofort an den Aktor gesandt.
Den Wunsch nach Sollwerten in 0,5er Schritten kann ich auch nicht erfüllen. Das Übertragungsprotokoll (EEP) sieht 1er-Schritte vor.
Hallo,
danke für die ausführliche Antwort.
ZitatDen Wunsch nach Sollwerten in 0,5er Schritten kann ich auch nicht erfüllen. Das Übertragungsprotokoll (EEP) sieht 1er-Schritte vor.
Das sehe ich anders.
setpointTemp ist zwar ganzzahlig, aber
setpointShift kann in 0.5 Grad Schritten vorgegeben werden. Im Sendetelegramm (message type B /ID 1) ist ein 8 bit Wert ab Offset 8 dafür vorgesehen. Berechnung gemäß:
int(128 + 127.5 * setpointShift/setpointShiftMax)Es würde reichen, für den neu anzulegenden Set-Befehl für
setpointShift die Werte 0 und 0.5 anzubieten.
(bei Änderung von
setpointShiftMax muss der Wert natürlich neu berechnet werden)
Einen zusätzlichen Befehl dieser Art halte ich nicht für sinnvoll. Ich habe mich bei diesem Profil unabhängig von der Betriebsart des Sensors (setpointTemp oder setpointShift) dafür entschieden, als Stellwert immer setpointTemp zu verwenden. Da passt setpointShift konzeptionell nicht.
Zudem scheint es mir unabhängig von der Bittiefe von OSO / SP in der Logik des EEP zu liegen, durchgängig 1er-Schtitte zu verwenden. Auch kann ich den praktischen Nutzen und die Notwendigkeit für einen Temperaturstellwert in Dezimalschritten nicht erkennen. Beides kann man vielleicht auch anders sehen.
Sobald ich Zeit finde, werde ich mir dennoch das Profil nochmals ansehen. Ich habe aber noch andere Arbeiten am Modul in der Warteschleife, die auch schon viele Wochen warten mussten.
Zitat von: klaus.schauer am 07 August 2024, 07:17:31Sobald ich Zeit finde, werde ich mir dennoch das Profil nochmals ansehen. Ich habe aber noch andere Arbeiten am Modul in der Warteschleife, die auch schon viele Wochen warten mussten.
Habe auch zwei von diesen SR06 LCD aber mit eep D2-11-02 (Meine haben noch ein humidity Reading).
Hoffe das eep D2-11-02 passt du dann auch gleich mit an.
Ist halt schon nicht so Toll wenn FHEM einen anderen Einstellbereich hat als das Gerät an sich.
Hoffe Du findest mal Zeit für die Anpassung.
Vielen Dank für die Arbeit und das Modul.
Hallo,
ja, der separate Set-Befehl ist nicht die beste Lösung. Einfacher wäre es, setpointTemp in 0.5° Schritten vorgeben zu können. Habe mal einen Patch dafür gemacht. Funktioniert einwandfrei.
(Schicke die Diff-Datei als PM).
phys1 hat einen Patch erstellt. Danke dafür. Ich gehe davon aus, dass der Patch tut, was er soll. Ich kann das nicht testen, da ich kein Mustergerät dieses Typs habe.
Bitte testen und eine kurze Rückmeldung geben. Wenn alles ok ist, stelle ich die Version ein.
Hallo Klaus,
ich habe noch 3 wesentliche Unterschiede zu meinem Patch festgestellt; es muss wie folgt lauten:
Zeile 6310:
$a[1] = sprintf "%.1f", (int(0.5 + 2 * $a[1]) / 2);Zeile 6315:
$setpointShiftMax = int(0.501 + $setpointBase - $a[1]) if ($setpointShiftMax < -$setpointShift);Zeile 6320:
$setpointShiftMax = int(0.501 + $a[1] - $setpointBase) if ($setpointShiftMax < $setpointShift);Damit wird erzwungen, dass nur 0.5° Schritte angenommen werden (Z. 6310) und dass setpointShiftMax ganzzahlig bleibt, auch wenn der übergebene Wert einen 0.5° Teil hat. Bitte noch so einbauen.
Diese Änderungen habe ich jetzt auch noch übernommen. Bitte testen.
Hallo,
von meiner Seite aus ist es nun ok. Sowohl in FHEM als auch am lokalen Gerät können 0.5° Schritte eingestellt werden; der jeweils andere übernimmt den Wert korrekt.
Das geänderte Modul steht morgen mit dem nächsten Update zur Verfügung.
Hallo,
habe nach umfangreichen Tests doch noch eine Unstimmigkeit gefunden:
Die von FHEM gesetzte Temperatur wird in manchen Fällen am Gerät um 0.5° falsch angezeigt. Anscheinend rundet das Gerät den empfangenen Offset nicht, sondern arbeitet mit Stufen. Wenn FHEM nur 1 bit neben der Stufe liegt, zeigt das Gerät falsch an. Nach einigem Probieren habe ich nun folgende Formel gefunden (statt der in Z. 6494):
my $offset = int(($setpointShiftMax - abs($setpointShift)) * 127.5 / $setpointShiftMax);
$setpointShift = ($setpointShift < 0) ? $offset : (255 - $offset);Damit hat es in allen Tests nun gepasst.
Steht morgen als Update zur Verfügung.