Hallo zusammen,
nachdem ich in den letzten Tagen gefühlt nur noch hm- und info- und Cul und was weiss ich alles gelesen habe, komme ich langsam aber sicher nicht mehr klar. Ich habe mehrere HM-CC-RT-DN Thermostate, die ich nach und nach eingebunden habe. Beim ersten war es kein Problem (hier war nur ein ext. Temperatur Sensor) in Betrieb, dieser funktionierte auch auf Anhieb. Erklärung was ich alles gemacht habe, folgt weiter unten, für die die es interessiert. Hier oben erstmal die wichtigen Infos......
Ich bekomme mit den (korrekten) virtuellen Geräten einfach keine Verbindung zwischen den virtuellen und den normalen Geräten hin :'( Sprich, die Temperatur vom Sensor wird ignoriert und er nimmt nur die Interne her...... :
Virtuelles Gerät angelegt:
Internals:
CFGFN
DEF 007001
FUUID 5dfa7111-f33f-8d79-72d9-d3a0127e872a2edf
IODev CUL_IO1
NAME virtual_BUE
NOTIFYDEV global
NR 22766
STATE CMDs_done
TYPE CUL_HM
channel_01 virtual_HEAT_BUE_HZ_TempSensor
protCmdDel 4
protIOerr 4 last_at:2019-12-18 19:50:31
protSnd 461 last_at:2019-12-19 15:18:56
protState CMDs_done
READINGS:
2019-12-19 15:18:56 state CMDs_done
helper:
HM_CMDNR 186
mId 0000
peerFriend
peerOpt -:-
regLst
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
DbLogExclude .*
IODev CUL_IO1
expert 2_defReg+raw
model VIRTUAL
msgRepeat 0
room System->CUL
subType virtual
webCmd virtual:update
darin einen kanal angelegt, umbenannt und zugeordnet:
Internals:
CFGFN
DEF 00700101
FUUID 5dfa719d-f33f-8d79-7a23-0ca82ade0ee7e873
IODev
NAME virtual_HEAT_BUE_HZ_TempSensor
NOTIFYDEV global
NR 22789
STATE set_virtTemp 21.52
TYPE CUL_HM
chanNo 01
device virtual_BUE
peerList HEAT_BUE_HZ_Weather,
protState Info_Cleared
READINGS:
2019-12-19 15:03:56 peerList HEAT_BUE_HZ_Weather,
2019-12-19 15:17:26 state set_virtTemp 21.52
2019-12-19 15:17:26 temperature 21.52
helper:
cfgChkResult No regs found for:
fkt virtThSens
virtTC 00
expert:
def 1
det 0
raw 1
tpl 0
prt:
bErr 0
sProc 0
role:
chn 1
vrt 1
tmpl:
vd:
ackT
cmd 8470007001000000
idh 2248624
idl 256
miss 0
msgCnt 209
msgRed 0
next 1576765313.62725
nextM 1576765313.62725
typ 2
val 00D72E
vin 21.52
vinH 46.29
nb:
cnt 1
Attributes:
DbLogExclude .*
event-on-change-reading .*
group Büro
model VIRTUAL
peerIDs 6B242901,
room System->CUL
webCmd :
diesen dann mit dem _weather Kanal vom Thermostat gepeert:
Internals:
DEF 6B242901
FUUID 5ddd9b38-f33f-8d79-82a6-77c1c601ded3174e
IODev
NAME HEAT_BUE_HZ_Weather
NOTIFYDEV global
NR 228
NTFY_ORDER 50-HEAT_BUE_HZ_Weather
STATE 21.9
TYPE CUL_HM
chanNo 01
device HEAT_BUE_HZ
protState Info_Cleared
READINGS:
2019-12-19 15:20:46 measured-temp 21.9
2019-12-19 15:20:46 state 21.9
helper:
getCfgListNo
peerFriend peerSensT
peerOpt p:thermostat
regLst 1
expert:
def 1
det 1
raw 0
tpl 0
prt:
bErr 0
sProc 0
role:
chn 1
tmpl:
Attributes:
DbLogExclude .*
group Büro
model HM-CC-RT-DN
room System->CUL
Das Ganze wird dann alle 15 Min vom at gefüttert
bei set hminfo peerXref kommt
virtual_HEAT_BUE_HZ_TempSensor => HEAT_BUE_HZ_Weather
heraus
ich hatte auch die config, dass das auch
HEAT_BUE_HZ_Weather => virtual_HEAT_BUE_HZ_TempSensor
stand, aber das kam mir falsch vor, weil dann der _Weather kanal meinen Virtuellen überschreiben würde oder ?
Wie gesagt, egal was ich mache, wird einfach die Temperatur vom virtuellen Gerät ignoriert.
Nun die Erklärung was ich vorher gemacht habe:
Zur ersten Einrichtung habe ich dummerweise die VCCU als virtuelles Device genommen, was natürlich falsch ist, wenn man mehrere Dinge benutzen will. Das habe ich dann leider erst zu spät gelesen. Im zweiten Raum war es dann erstmal ein Fensterkontakt, der dann auch erstmal funktionierte, aber dann ging der Spaß los .... Deshalb habe ich dann die ganzen Geräte / Peerings usw gelöscht und neu angelegt. Nun scheitere ich bereits mit dem ersten Gerät und dessen Temp. Sensor :(
Würde mich sehr freuen, wenn mir da jemand ein wenig auf die Sprünge helfen könnte....
Vielen Dank im Voraus
Grüße
Andreas
peerings sind immer "2-seitig". jeder der beiden muss den anderen kennen.
get hminfo configCheck sollte den fehler zeigen.
Hallo Frank,
danke für Deine Antwort. Ich habe es jetzt soweit umgesetzt, dass eine peerXref ausgabe so aussieht:
peerXref done:
x-ref list
HEAT_BUE_HZ_Weather => virtual_HEAT_BUE_HZ_TempSensor
virtual_HEAT_BUE_HZ_TempSensor => HEAT_BUE_HZ_Weather
im configCheck taucht das jetzt auch nicht mehr auf, dass es nicht gefunden werden kann *grübel*
Scheint also soweit richtig zu sein ?
Kann ich es irgendwie noch testen, außer abzuwarten, ob die Temperatur übernommen wird ?
Vielen Dank
Grüße
Andreas
Hallöchen
so langsam aber sicher verzweifel ich total ??? :'(
Ich hatte einiges durcheinander get hminfo configCheck hat hier einiges gebracht und geholfen. Ich habe dann so alle peerings wieder gelöscht und neu angelegt (ich habe sogar in der VCCU - die ich fälschlicherweise für die virtuellen Kontakte genommen habe - sogar die Kanäle neu angelegt und dann die Peerings einzeln gelöscht, weil diese sonst teilweise nicht sichtbar waren). Nachdem ich alles neu angelegt hatte , haben die Peerings (bis zum ALLER letzten Gerät) geklappt und ich habe das Gefühl gehabt, dass es funktioniert - Fensterkontakte wurden sofort akzeptiert und umgesetzt und bei der Temperatur sah es so aus, als wäre das nach einige Zeit wieder drin..... Nun ist es aber so dass ich total verzweifele:
Gibt es einen Zeitraum, an dem man festmachen kann "nach x Sekunden , Minuten oder was auch immer" sollten die Werte übernommen worden sein ?
Es war nämlich so, dass ich in dem betroffenen Raum auf dem Thermostat 22,3 °C hatte, in dem Raum aber 21 °C waren. Dann habe ich die lists vorbereitet und den oberen Roman angefangen. Dann (ca. 15 min später) nochmal kontrolliert und es war auf 21 °C. Vorher wurde ca. 1 Std lang keine spürbare Anpassung an den aktuellen Wert vorgenommen :(
Mir fehlt da einfach ein generelles Verständnis wie ich das nachvollziehen kann .....
Die Temperaturwerte werden alle 10min übermittelt (ein at das alle 10 min die Temperaturen übergibt) - Kann das ein Grund sein ?
Würde mich sehr sehr freuen, wenn mir da jemand weiterhelfen könnte.
Grüße
Andreas
Ich habe einige Zeit damit verbracht, einen Eigenbausensor (papa's Firmware) mit dem Thermostat zu synchronisieren. Das Timing zwischen Sender und Empfänger ist ziemlich intolerant. Kann es sein, daß Dein CUL hier das Problem ist? Kannst Du mal ein originales HM-IOdevice verwenden?
Hallöchen,
Zitat von: Gernott am 20 Dezember 2019, 21:43:20
Das Timing zwischen Sender und Empfänger ist ziemlich intolerant
....
Kannst Du mal ein originales HM-IOdevice verwenden?
Weiss nicht warum es intollerant sein sollte, aber möglich ist es ja: Wahrscheinlich will das Thermostat zu einer bestimmten Zeit eine "Antwort" vom Gerät haben um somit dann auch zuverlässig die Heizukurve anzupassen. Da bin ich mir aber ziemlich sicher, dass ich nicht der erste bin, dem das aufgefallen wäre ;)
Genau das war der Hintergrund von dem ganzen: Wenn Homematic / CUL oder was auch immer mal ausfällt, soll nicht alles ausfallen und natürlich gerade bei Temperatur und Fenstersensoren ist es auch eine Preisfrage. Bisher bin ich mit den Geräten insg. sehr zufrieden. Die Anbindung an FHEM Geräte ist ja grundsätzlich zuverlässig möglich, sonst würden das nicht so viele Leute nutzen.
Wenn ich eine Alternative für den CUL hätte, würde ich diese natürlich nutzen, oder zumindest mal testen ob es besser ist ;)
Aber wie dem auch sei. Ich werde es jetzt mal so testen, dass ich alle 5 Minuten die Werte übergebe. Läuft seit 2 Std und bisher macht es einen sehr guten Eindruck.
Grüße
Andreas
p.s. Als Gelöst markiert, weil das eigentliche Grundproblem ja gelöst ist.
alle 5 min eine temp "füttern" ist völlig nutzlos. nimm lieber ein notify, so dass nur bei änderung gefüttert wird.
einmal eine temp gesetzt, wird diese vom vt automatisch bei jedem rt zyklus gesendet, bis eine neue gefüttert wird.
wichtig: ein separater vt (nur 1 channel) pro rt.
du musst dein system "timingfähig" machen:
1. cul mit passender fw flashen: nur tsculfw kann das.
2. latenzen beseitigen, vor allem unregelmässige (zb durch wlan strecken zwischen fhem und io).
3. fhem auf freezes untersuchen und ggf beseitigen (modul freezemon, apptime).
4. je weniger der timingserver zu tun hat, desto besser das ergebnis.
5. perfekte funkverbindung zum rt, ggf rssi verbessern.
6. ...
testen kannst du nur die temps; es gibt null reaktionen beim rt.
mach dir einen plot mit beiden temps, dann siehst du am besten wann und wie oft der "fallback" passiert.
erneutes synchronisieren kann dauern.
eigentlich tolerieren die rt gelegentliche aussetzer. wenn du es trotzdem nicht auf dauer hinbekommst, ist dein system untauglich.
nachdem du dein system best möglich auf timing vorbereitet hast, kannst du noch eine "feinabstimmung" mit dem beschriebenen attribut (offset) am vt probieren.
Hallo Frank,
Vielen Dank für Deine Antwort und die beinhaltenden Tipps ;)
Hab da aber mal ein zwei Fragen dazu, wenn es OK ist....
0. Ein virtuelles Gerät mit eigenem Kanal PRO externen Sensor. Genau das war der Hauptknackpunkt. Erst als ich das hatte, konnte ich wegen dem Rest schauen... Hab jetzt 3 Räume in ein AT gesetzt und diese dann alle 5 Min "gefüttert" wie du so schön sagtst - Das ist dann natürlich schon ein wenig an Datenflut auf einmal .... Für jede Temperatur eigenes notify, das dann erst bei 0,2 Grad Unterschied die Temperatur sendet ist wohl sinniger...*grübel*
1. Was bedeutet in diesem Zusammenhang "timingfähig"? Warum kann tsculfw das und andere Firmenware nicht ? - bzw wo kann ich was darüber nachlesen ?
2. Ich behaupte mal JEDER der hier bastelt, hat neben seinem CUL auch WLAN im Haus eingerichtet, wie kann ich denn ggf kontrollieren, ob sich da was stört?
3,4,5 Ist etwas worauf ich eh bei vielen Dingen achte. Darum auch der Versuch mit ein paar Geräten weniger auszukommen und nicht für jeden Kleinmist ein eigenes Gerät anzulegen. Manchmal wohl auch falsch ;(
Das Mitschreiben / Plotten der Temperaturen ist für heute oder morgen eh geplant, je nachdem wie ich dazu komme. Nur hier kann man am besten sehen wie sich die Sachen verhalten.
Wäre schön, wenn Du Dir da noch mal die Zeit dafür nehmen könntest :)
Grüße
Andrea
Zitat von: flummy1978 am 21 Dezember 2019, 11:53:31
1. Was bedeutet in diesem Zusammenhang "timingfähig"? Warum kann tsculfw das und andere Firmenware nicht ? - bzw wo kann ich was darüber nachlesen ?
Bin zwar nicht Frank, aber ab hier:
https://forum.fhem.de/index.php/topic,20620.msg963911.html#msg963911
finden sich einige aufschlussreiche Informationen, warum der Thermostat nur dann die Temperatur vom externen Sensor übernimmt, wenn der zu einem bestimmten Zeitpunkt sendet.