Hallo,
habe es nicht hinbekommen, dass ich drei Heizkörperthermostate HM-CC-RT-DN (WOH_HEIZUNG_1, WOH_HEIZUNG_2, WOH_HEIZUNG_3) mit einem externen Thermometer verbinde um diese Temperatur zur Steuerung zu verwenden.
Versucht habe ich es u.a. mit folgender Anleitung:
https://raspberry.tips/hausautomatisierung/fhem/heizungssteuerung-mit-homematic-hm-cc-rt-dn-und-fhem-auf-dem-raspberry-pi
Leider funktioiniert es immer noch nicht; als Hilfe habe ich folgenden Thread:
https://forum.fhem.de/index.php/topic,95699.msg906413.html#msg906413
Anscheinend ist o.g. Anleitung nicht richtig und ich müsste pro Heizkörperthermostat ein virtuelles device plus jeweils einen virtuellenen Kanal erstellen.
Komischerweise funktioniert es mit einen Thermostat (WOH_HEIZUNG_3) mit den anderen zwei nicht. Dies hätte ich auch schon im o.g. Thread näher beschrieben.
Da ich ja die Heizkörperthermostate bereits (falsch) gepeert habe wollte ich diese wieder "entpeeren" um wieder von Vorne zu beginnen.
Mit folgenden Befehl:
set WOH_virt_Temperatur_Sensor1 peerChan 0 WOH_HEIZUNG_1_Weather single unset
Leider habe ich hier anscheinend schon wieder einen (anderen) Fehler gemacht.
Wie bekomme ich es hin, dass ich alle Spuren von meinen Versuchen entferne ohne FHEM komplett neu zu installieren?
Der Befehl
get hm configCheck
gibt folgendes Ergebniss:
configCheck done:
missing register list
WOH_HEIZUNG_1_Weather: RegL_01.
peer not defined
WOH_HEIZUNG_1_Weather id:96517501
WOH_HEIZUNG_2_Weather id:96655501
trigger sent to undefined device
triggerUndefined: WOH_SCHALTER_1_Btn_01:FA3B12
triggerUndefined: WOH_SCHALTER_1_Btn_02:FA3B12
Was kann ich jetzt machen?
Bin schon kurz vorm Verzweifeln... ???
Welche List kann ich zur Verfügung stellen um den Fehler zu finden?
Vielen Dank
Viele Grüße
Ruggy
Hier wäre eigentlich kein neuer Thread erforderlich gewesen...
Vorab: Die Frage ist nicht, wie du "falsche" Werte "aus FHEM" bekommst, sondern, wie du nur noch die richtigen _in deinen Thermostaten_ haben kannst. Die Peers werden nämlich auf dem jeweiligen Gerät gespeichert, du kannst FHEM noch 5x jungfräulich installieren, ohne dass sich da was tut; FHEM holt die nur dort ab ;) .
An sich hast du das schon richtig gemacht (mal abgesehen davon, dich auf einen CUL als IO einzulassen; das wird doch in diesem unseligen Video so gemacht, oder?). Aber auch damit sollte es gehen.
Wichtig ist zunächst, dass vor solchen Aktionen keine Funkoperationen zu dem Gerät mehr anstehen. Wenn da also was von "CMDs pending" steht, muß erst mal da Ordnung gemacht werden. Manchmal reicht Abarbeiten lassen (config-Knopf ggf. mehrfach drücken), manchmal einfach ein clear msgEvents (am jeweiligen Zielgerät der Funkaktion, hier also nur am RT).
Dann einmalig den Befehl absetzen und Knopf drücken oder - bei lazy-irgendwas-Geräten wie dem RT - WARTEN und Geduld haben.
Wenn dann alles soweit durch ist, nochmal mit getConfig checken, dann sollte (nach geduldigem WARTEN) alles wieder sein, wie es sollte.
Ansonsten gibt's noch regBulk. Dazu bitte commandref und ggf. mal den hinteren Teil des Einsteiger-pdf's konsultieren. Das ist zu den HM-Geschichten immer noch DIE Infoquelle, die man kennen sollte.
Good luck!
Hallo,
bzgl. dem CUL hat sich schon im anderen Tread geklärt. Habe das HM-MOD-RPI-PCB HomeMatic Funkmodul und anfangs dies auch falsch gemacht.
Wenn die Peers auf den Gerät gespeichert werden; kann es sein, dass auf dem Gerät mehrere HMID's gespeichert werden?
Hatte nämlich anfangs, durch meine Probiererei, für ein Device bzw. Thermostat verschiedene HMID's verwendet (weil ich verschiedene Anleitungen mir angeschaut habe). Ist dabei evlt. das Thermostat durcheinander gekommen?
Müsste ich das Thermostat komplett resetten und neu einrichten?
Bei allen drei Geräten steht als status "CMDs_done". Also wäre ja alles ok.
Aber trotzdem schaffe ich es bei zwei Thermostaten nicht, dass in beide Richtungen gepeert wird. Beim dritten klappte es aber. Also mache ich es doch grundsätzlich richtig, wenn es bei einem funktioniert?
Sorry, dass ich einen weiteren Tread aufgemacht habe. Dachte mir aber, dass das entpeeren und die Frage nach dem "Bereinigen" des HM-CC-RT-DN nicht unbedingt zu meinem Ursprünglichen Problem passt. Was aber leider immer noch eines ist.
Kann es an den verschiedenen HMID's liegen?
Sorry, aber da gehen die Begrifflichkeiten m.E. zu sehr durcheinander.
Kläre erst mal für dich, was eine HmID ist und was ein Kanal. Schau die Definitionen in FHEM an (ganz genau).
Grundsätzlich kann ein RT-Weather-Kanal nach meiner Kenntnis mit bis zu 6 Kanälen von anderen Devices gepeert werden.
Aber Zentrale (siehe Pairing im Wiki) kann nur eine sein, und die sollte auch bei allen 3 gleich sein.
Ich kann (und will) aber nicht raten, was du jetzt im Einzelnen mit den mehreren HmID's meinst, die du genutzt haben willst.
Vielleicht folgendes zum mitdenken:
Ich habe EINE VCCU und noch zwei weitere virtuelle CUL_HM-Device mit einer eigenen, anderen HmID. Beide haben je einen virtuellen Kanal (eigentlich sollte man die VCCU dafür nicht nutzen, sondern ein separates 4. virtuelles Device), die wie folgt gepeert sind (an den Geräten je mit dem passenden Kanal, versteht sich):
Kanal1 von virtuellem CUL_HM-Device 1 mit 2 RT'sKanal1 von virtuellem CUL_HM-Device 2 mit einem anderen RTKanal2 von der VCCU (die ist eigentlich auch nur ein virtuelles CUL_HM-Device) mit noch 2 RT's und einem Wandthermostaten.
Die beiden RT's vom "normalen virtuellen" Device befinden sich in einem Raum (mit 2 Außentüren und werden miteinander runtergeregelt, wenn mind. eine der beiden Türen länger offen ist, bei den nachfolgenden ist es je ein Türkontakt, der länger offen sein muß),die 3 RT/WT in einem anderen mit einer Außentürder einzelne RT im Gang neben der Haustür
Wird es jetzt klarer, wie die Dinge zusammengehören?
Und bitte: lies das pdf. (ich habe den hinteren Teil auch bestimmt 5 Mal gelesen und dabei rumprobiert, bis ich halbwegs verstanden zu haben glaubte, wie das funktioniert).
Bzgl. den "HMID's" meinte ich die 6-Stellige Homematic-Id
Ich habe anfangs einmal den Befehl
define WOH_virt_Temperatur CUL_HM 968863und bei einem weiteren Versuch den Befehl gegeben
define WOH_virt_Temperatur CUL_HM 965175Also zwei verschiedene Homematic_ID's. Hier frage ich mich, ob dies ein Problem darstellen könnte und dadurch etwas durcheinander gekommen ist?
Auch durch mein darauf folgendes Herumprobieren.
Im Kinderzimmer mit zwei Thermostaten hat das peeren ohne Probleme funktioniert.
Im Wohnzimmer will es aber nicht klappen. Es funktioniert bei einem Thermostat und bei zwei nicht.
Obwohl ich meiner Meinung nach gleich vorgegangen bin.
Dafür muss es doch einen Grund geben?
Im Device "WOH_HEIZUNG_3_Weather" (welches funktioniert) steht bei "peerIDs" die 96886303, also die richtige.
Im Device "WOH_HEIZUNG_1_Weather" und "WOH_HEIZUNG_2_Weather" bei "peerIDs" die 96655501 bzw. die 96517501. Also die falschen.
Hier sollte doch die 96886301 bzw. 96886302 stehen...
Das PDF lese ich mir noch ein paarmal durch obwohl ich es schon öfters gelesen habe.
Zitat von: Beta-User am 23 Februar 2019, 21:48:04
Vielleicht folgendes zum mitdenken:
Alleine das musste ich mehrmals durchlesen, bevor ich es einigermaßen verstanden habe. Sorry, liegt aber nicht an dir ;-)
Es gibt sicher einen Grund...
Aber nur, weil du hier postest, gelten immer noch die Regeln wie im Anfängerbereich bekanntgegeben: Ohne list(s) muß man raten.
V.a.: Paßt das Pairing?
Aber nochmal zurück auf los: Du schreibst erst (sinngemäß, so habe ich das verstanden), 968863 gäbe es nicht mehr (das Device mit demselben Namen hat jetzt eine andere HmID), aber dann später, dass 96886303 korrekt wäre. Fällt dir was auf?
Und mit dem pdf ist in diesem Zusammenhang eigentlich der ANHANG gemeint.
Anfangs die 968863 verwendet, dann eine andere und jetzt wieder die 968863 um nicht noch eine dritte zu verwenden.
Hier die Lists.
List hm
Internals:
FUUID 5c65c66e-f33f-194f-60bb-b48677201217c8a5
NAME hm
NR 73
NTFY_ORDER 50-hm
STATE updated:2019-01-07 23:53:24
TYPE HMinfo
Version 01
READINGS:
2019-01-07 23:53:24 CRI__protocol -
2019-01-07 23:53:24 C_sumDefined entities:39,device:6,channel:31,virtual:2
2019-01-07 23:53:24 ERR__protocol -
2019-01-07 23:53:24 ERR__unreachable 0
2019-01-07 23:53:24 I_actTotal alive:5,dead:0,unkn:0,off:0
2019-01-07 23:53:24 I_autoReadPend 0
2019-01-07 23:53:24 I_rssiMinLevel 59<:1 60>:2 80>:2 99>:0
2019-01-07 23:53:24 I_sum_battery ok:5,
2019-01-07 23:53:24 W__protocol CmdPend:1,Resnd:2
helper:
cfgChkResult configCheck done:
missing register list
WOH_HEIZUNG_1_Weather: RegL_01.
peer not defined
WOH_HEIZUNG_1_Weather id:96517501
WOH_HEIZUNG_2_Weather id:96655501
trigger sent to undefined device
triggerUndefined: WOH_SCHALTER_1_Btn_01:FA3B12
triggerUndefined: WOH_SCHALTER_1_Btn_02:FA3B12
weekplanListDef ./FHEM/tempList.cfg
weekplanListDir ./FHEM/
bm:
HMinfo_GetFn:
cnt 4
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 16:16:33
max 0.0140740871429443
tot 0.0269870758056641
mAr:
HASH(0x2929968)
hm
configCheck
HMinfo_Notify:
cnt 6143
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 16:53:54
max 0.00103902816772461
tot 0.174458980560303
mAr:
HASH(0x2929968)
HASH(0x1c57168)
HMinfo_SetFn:
cnt 5
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 22:46:34
max 0.0205450057983398
tot 0.0210332870483398
mAr:
HASH(0x2929968)
hm
peerXref
weekplanList:
KIND_HEIZUNG_1_Clima
KIND_HEIZUNG_2_Clima
WOH_HEIZUNG_1_Clima
WOH_HEIZUNG_2_Clima
WOH_HEIZUNG_3_Clima
nb:
cnt 6
Attributes:
configDir FHEM
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update:protoEvents short:rssi:peerXref:configCheck:models
list WOH_HEIZUNG_1_Weather
Internals:
DEF 62FAC401
FUUID 5c65c66f-f33f-194f-ebd2-f62164a2a76c7f32
NAME WOH_HEIZUNG_1_Weather
NOTIFYDEV global
NR 107
NTFY_ORDER 50-WOH_HEIZUNG_1_Weather
STATE 24.4
TYPE CUL_HM
chanNo 01
device WOH_HEIZUNG_1
peerList 96517501,
Helper:
DBLOG:
state:
DbLog:
TIME 1550960346.40933
VALUE 24.4
READINGS:
2019-01-13 13:25:17 R-sign off
2019-02-23 23:19:06 measured-temp 24.4
2019-02-22 17:57:02 peerList 96517501,
2019-02-23 23:19:06 state 24.4
helper:
getCfgListNo
peerIDsRaw ,96517501,00000000
regLst ,1
bm:
CUL_HM_Get:
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 16:28:15
max 0.00108504295349121
tot 0.00284600257873535
mAr:
HASH(0x2e39d78)
WOH_HEIZUNG_1_Weather
?
CUL_HM_Set:
cnt 178
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 23:16:03
max 0.0161049365997314
tot 1.53236985206604
mAr:
HASH(0x2e39d78)
WOH_HEIZUNG_1_Weather
?
expert:
def 1
det 0
raw 1
tpl 0
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,96517501,
list WOH_HEIZUNG_2_Weather
Internals:
DEF 62FB0B01
FUUID 5c65c66e-f33f-194f-0bec-4ada40121057493e
NAME WOH_HEIZUNG_2_Weather
NOTIFYDEV global
NR 34
NTFY_ORDER 50-WOH_HEIZUNG_2_Weather
STATE 23.9
TYPE CUL_HM
chanNo 01
device WOH_HEIZUNG_2
peerList 96655501,
Helper:
DBLOG:
state:
DbLog:
TIME 1550960408.46844
VALUE 23.9
READINGS:
2018-11-23 19:22:09 R-sign off
2019-02-22 17:55:06 RegL_01. 00:00 08:00
2019-02-23 23:20:08 measured-temp 23.9
2019-02-22 17:55:06 peerList 96655501,
2019-02-23 23:20:08 state 23.9
helper:
peerIDsRaw ,96655501,00000000
regLst ,1
bm:
CUL_HM_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 22:30:45
max 0.000507116317749023
tot 0.000507116317749023
mAr:
HASH(0x228c698)
WOH_HEIZUNG_2_Weather
?
CUL_HM_Set:
cnt 22
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 23:10:14
max 0.0155689716339111
tot 0.196925401687622
mAr:
HASH(0x228c698)
WOH_HEIZUNG_2_Weather
?
expert:
def 1
det 0
raw 1
tpl 0
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,96655501,
List WOH_HEIZUNG_3_Weather
Internals:
DEF 62FACF01
FUUID 5c65c66e-f33f-194f-0ac0-08f1997657c8a51d
NAME WOH_HEIZUNG_3_Weather
NOTIFYDEV global
NR 25
NTFY_ORDER 50-WOH_HEIZUNG_3_Weather
STATE 22.1
TYPE CUL_HM
chanNo 01
device WOH_HEIZUNG_3
peerList WOH_virt_Temperatur_Sensor3,
Helper:
DBLOG:
state:
DbLog:
TIME 1550960512.95635
VALUE 22.1
READINGS:
2018-11-23 19:21:42 R-sign off
2019-02-13 21:18:32 RegL_01. 08:00 00:00
2019-02-23 23:21:52 measured-temp 22.1
2019-02-14 20:50:07 peerList WOH_virt_Temperatur_Sensor3,
2019-02-23 23:21:52 state 22.1
helper:
regLst ,1
bm:
CUL_HM_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 22:30:43
max 0.000873088836669922
tot 0.000873088836669922
mAr:
HASH(0x21af398)
WOH_HEIZUNG_3_Weather
?
CUL_HM_Set:
cnt 22
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 23:14:18
max 0.0123419761657715
tot 0.192125797271729
mAr:
HASH(0x21af398)
WOH_HEIZUNG_3_Weather
?
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,96886303,
List WOH_HEIZUNG_1
Internals:
DEF 62FAC4
FUUID 5c65c66f-f33f-194f-3792-0c0466630a9bfee7
HmUART_MSGCNT 5255
HmUART_RAWMSG 05000028A4861062FAC40000000AB0F40C0C00
HmUART_RSSI -40
HmUART_TIME 2019-02-23 23:21:54
IODev HmUART
LASTInputDev HmUART
MSGCNT 5255
NAME WOH_HEIZUNG_1
NOTIFYDEV global
NR 105
NTFY_ORDER 50-WOH_HEIZUNG_1
STATE CMDs_done
TYPE CUL_HM
channel_01 WOH_HEIZUNG_1_Weather
channel_02 WOH_HEIZUNG_1_Climate
channel_03 WOH_HEIZUNG_1_WindowRec
channel_04 WOH_HEIZUNG_1_Clima
channel_05 WOH_HEIZUNG_1_ClimaTeam
channel_06 WOH_HEIZUNG_1_remote
lastMsg No:A4 - t:10 s:62FAC4 d:000000 0AB0F40C0C00
protCmdDel 6
protLastRcv 2019-02-23 23:21:54
protNack 2 last_at:2019-02-22 18:12:26
protRcv 5255 last_at:2019-02-23 23:21:54
protResnd 1 last_at:2019-02-22 17:57:08
protSnd 96 last_at:2019-02-23 13:24:35
protState CMDs_done
rssi_HmUART cnt:4 min:-36 max:-36 avg:-36 lst:-36
rssi_at_HmUART cnt:5255 min:-51 max:-32 avg:-38.22 lst:-40
Helper:
DBLOG:
state:
DbLog:
TIME 1550924675.70768
VALUE CMDs_done
READINGS:
2019-02-14 20:50:07 Activity alive
2019-02-22 18:12:26 CommandAccepted no
2019-02-10 08:37:47 D-firmware 1.4
2019-02-10 08:37:47 D-serialNr OEQ1704670
2019-02-22 17:57:01 PairedTo 0xFA3B12
2019-02-14 20:51:24 R-backOnTime 10 s
2019-02-14 20:51:24 R-burstRx on
2019-02-14 20:51:24 R-cyclicInfoMsg on
2019-02-14 20:51:24 R-cyclicInfoMsgDis 0
2019-02-14 20:51:24 R-pairCentral 0xFA3B12
2019-02-22 17:57:01 RegL_00. 00:00 01:01 02:01 09:01 0A:FA 0B:3B 0C:12 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00
2019-02-23 23:21:54 actuator 12
2019-02-23 23:21:54 battery ok
2019-02-23 23:21:54 batteryLevel 2.7
2019-02-23 23:21:54 desired-temp 22.0
2019-02-23 23:21:54 measured-temp 24.4
2019-02-23 23:21:54 motorErr ok
2019-02-09 08:04:32 powerOn 2019-02-09 08:04:32
2019-02-09 08:04:32 recentStateType info
2019-02-23 13:24:35 state CMDs_done
2019-02-23 13:24:35 time-request -
RegL_07.:
VAL
helper:
HM_CMDNR 164
cSnd 01FA3B1262FAC406040000000001,01FA3B1262FAC401019651750101
mId 0095
regLst ,0
rxType 140
supp_Pair_Rep 0
bm:
CUL_HM_Get:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 16:44:06
max 0.000986099243164062
tot 0.00152230262756348
mAr:
HASH(0x2e631b8)
WOH_HEIZUNG_1
?
CUL_HM_Set:
cnt 159
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 22:33:23
max 0.017632007598877
tot 1.60076189041138
mAr:
HASH(0x2e631b8)
WOH_HEIZUNG_1
?
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +62FAC4,00,00,00
nextSend 1550960514.69221
prefIO
rxt 2
vccu
p:
62FAC4
00
00
00
mRssi:
mNo A4
io:
HmUART:
-32
-32
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rssi:
HmUART:
avg -36
cnt 4
lst -36
max -36
min -36
at_HmUART:
avg -38.2253092293055
cnt 5255
lst -40
max -32
min -51
shRegW:
07 04
shadowReg:
tmpl:
Attributes:
IODev HmUART
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
group Heizung
model HM-CC-RT-DN
room Wohnzimmer
serialNr OEQ1704670
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
List WOH_HEIZUNG_2
Internals:
DEF 62FB0B
FUUID 5c65c66e-f33f-194f-66eb-3ccb772b3149532c
HmUART_MSGCNT 5205
HmUART_RAWMSG 050000229F861062FB0B0000000AB0ED0E0800
HmUART_RSSI -34
HmUART_TIME 2019-02-23 23:22:48
IODev HmUART
LASTInputDev HmUART
MSGCNT 5205
NAME WOH_HEIZUNG_2
NOTIFYDEV global
NR 32
NTFY_ORDER 50-WOH_HEIZUNG_2
STATE CMDs_done
TYPE CUL_HM
channel_01 WOH_HEIZUNG_2_Weather
channel_02 WOH_HEIZUNG_2_Climate
channel_03 WOH_HEIZUNG_2_WindowRec
channel_04 WOH_HEIZUNG_2_Clima
channel_05 WOH_HEIZUNG_2_ClimaTeam
channel_06 WOH_HEIZUNG_2_remote
lastMsg No:9F - t:10 s:62FB0B d:000000 0AB0ED0E0800
protCmdDel 3
protLastRcv 2019-02-23 23:22:48
protNack 1 last_at:2019-02-22 17:50:40
protRcv 5205 last_at:2019-02-23 23:22:48
protSnd 48 last_at:2019-02-23 13:22:38
protState CMDs_done
rssi_HmUART cnt:4 min:-31 max:-31 avg:-31 lst:-31
rssi_at_HmUART cnt:5205 min:-57 max:-29 avg:-34.49 lst:-34
Helper:
DBLOG:
state:
DbLog:
TIME 1550924558.27388
VALUE CMDs_done
READINGS:
2019-02-14 20:50:07 Activity alive
2019-02-22 17:55:05 CommandAccepted yes
2019-02-13 21:01:40 D-firmware 1.4
2019-02-13 21:01:40 D-serialNr OEQ1704649
2019-02-22 17:55:05 PairedTo 0xFA3B12
2018-11-23 19:22:09 R-backOnTime 10 s
2019-02-13 22:29:35 R-burstRx on
2018-11-23 19:22:09 R-cyclicInfoMsg on
2018-11-23 19:22:09 R-cyclicInfoMsgDis 0
2018-11-23 19:22:09 R-pairCentral 0xFA3B12
2019-02-22 17:55:05 RegL_00. 00:00 01:01 02:01 09:01 0A:FA 0B:3B 0C:12 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00
2019-02-23 23:22:48 actuator 8
2019-02-23 23:22:48 battery ok
2019-02-23 23:22:48 batteryLevel 2.9
2019-02-23 23:22:48 desired-temp 22.0
2019-02-23 23:22:48 measured-temp 23.7
2019-02-23 23:22:48 motorErr ok
2019-02-09 08:02:18 powerOn 2019-02-09 08:02:18
2019-02-09 08:02:18 recentStateType info
2019-02-23 13:22:38 state CMDs_done
2019-02-23 13:22:38 time-request -
RegL_07.:
VAL
helper:
HM_CMDNR 159
cSnd 01FA3B1262FB0B0603,01FA3B1262FB0B06040000000001
mId 0095
regLst ,0
rxType 140
supp_Pair_Rep 0
bm:
CUL_HM_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 22:30:32
max 0.000817060470581055
tot 0.000817060470581055
mAr:
HASH(0x2204d48)
WOH_HEIZUNG_2
?
CUL_HM_Set:
cnt 155
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 18:32:04
max 0.0167081356048584
tot 1.53052425384521
mAr:
HASH(0x2204d48)
WOH_HEIZUNG_2
?
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +62FB0B,00,00,00
nextSend 1550960569.00251
prefIO
rxt 2
vccu
p:
62FB0B
00
00
00
mRssi:
mNo 9F
io:
HmUART:
-26
-26
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rssi:
HmUART:
avg -31
cnt 4
lst -31
max -31
min -31
at_HmUART:
avg -34.4941402497598
cnt 5205
lst -34
max -29
min -57
shRegW:
07 04
shadowReg:
tmpl:
Attributes:
IODev HmUART
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
group Heizung
model HM-CC-RT-DN
room Wohnzimmer
serialNr OEQ1704649
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
List WOH_HEIZUNG_3
Internals:
DEF 62FACF
FUUID 5c65c66e-f33f-194f-db67-869f4db009b57c92
HmUART_MSGCNT 5149
HmUART_RAWMSG 050000269A861062FACF0000000AB0DD0E0100
HmUART_RSSI -38
HmUART_TIME 2019-02-23 23:24:17
IODev HmUART
LASTInputDev HmUART
MSGCNT 5149
NAME WOH_HEIZUNG_3
NOTIFYDEV global
NR 23
NTFY_ORDER 50-WOH_HEIZUNG_3
STATE CMDs_done
TYPE CUL_HM
channel_01 WOH_HEIZUNG_3_Weather
channel_02 WOH_HEIZUNG_3_Climate
channel_03 WOH_HEIZUNG_3_WindowRec
channel_04 WOH_HEIZUNG_3_Clima
channel_05 WOH_HEIZUNG_3_ClimaTeam
channel_06 WOH_HEIZUNG_3_remote
lastMsg No:9A - t:10 s:62FACF d:000000 0AB0DD0E0100
protLastRcv 2019-02-23 23:24:17
protRcv 5149 last_at:2019-02-23 23:24:17
protSnd 16 last_at:2019-02-23 13:19:21
protState CMDs_done
rssi_HmUART cnt:4 min:-47 max:-46 avg:-46.5 lst:-47
rssi_at_HmUART cnt:5149 min:-79 max:-35 avg:-46.36 lst:-38
Helper:
DBLOG:
state:
DbLog:
TIME 1550924361.93144
VALUE CMDs_done
READINGS:
2019-02-14 20:50:07 Activity alive
2019-02-16 10:48:19 CommandAccepted yes
2019-02-13 21:01:29 D-firmware 1.4
2019-02-13 21:01:29 D-serialNr OEQ1704682
2019-02-13 21:18:31 PairedTo 0xFA3B12
2018-11-23 19:21:41 R-backOnTime 10 s
2018-11-23 19:21:41 R-burstRx on
2018-11-23 19:21:41 R-cyclicInfoMsg on
2018-11-23 19:21:41 R-cyclicInfoMsgDis 0
2018-11-23 19:21:41 R-pairCentral 0xFA3B12
2019-02-13 21:18:31 RegL_00. 01:01 02:01 09:01 0A:FA 0B:3B 0C:12 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00 00:00
2019-02-13 21:51:39 RegL_07.
2019-02-23 23:24:17 actuator 1
2019-02-23 23:24:17 battery ok
2019-02-23 23:24:17 batteryLevel 2.9
2019-02-23 23:24:17 desired-temp 22.0
2019-02-23 23:24:17 measured-temp 22.1
2019-02-23 23:24:17 motorErr ok
2019-02-09 07:59:07 powerOn 2019-02-09 07:59:07
2019-02-09 07:59:07 recentStateType info
2019-02-23 13:19:21 state CMDs_done
2019-02-23 13:19:21 time-request -
helper:
HM_CMDNR 154
cSnd 11FA3B1262FACF860427,11FA3B1262FACF860427
mId 0095
regLst ,0
rxType 140
supp_Pair_Rep 0
bm:
CUL_HM_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 22:30:31
max 0.000988006591796875
tot 0.000988006591796875
mAr:
HASH(0x1f83278)
WOH_HEIZUNG_3
?
CUL_HM_Set:
cnt 154
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 21:35:05
max 0.017819881439209
tot 1.55424571037292
mAr:
HASH(0x1f83278)
WOH_HEIZUNG_3
?
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +62FACF,00,00,00
nextSend 1550960657.2675
prefIO
rxt 2
vccu
p:
62FACF
00
00
00
mRssi:
mNo 9A
io:
HmUART:
-30
-30
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
HmUART:
avg -46.5
cnt 4
lst -47
max -46
min -47
at_HmUART:
avg -46.3606525538938
cnt 5149
lst -38
max -35
min -79
shRegW:
07 04
tmpl:
Attributes:
IODev HmUART
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
group Heizung
model HM-CC-RT-DN
room Wohnzimmer
serialNr OEQ1704682
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
list WOH_virt_Temperatur_Sensor1
Internals:
DEF 96886301
FUUID 5c65c66f-f33f-194f-92c4-cb38dacb13b7f063
NAME WOH_virt_Temperatur_Sensor1
NOTIFYDEV global
NR 134
NTFY_ORDER 50-WOH_virt_Temperatur_Sensor1
STATE stopped
TYPE CUL_HM
chanNo 01
device WOH_virt_Temperatur
READINGS:
2019-02-14 20:50:08 state stopped
helper:
fkt virtThSens
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
vd:
idh 0
idl 0
msgCnt 1
msgRed 0
next 1550173977.7254
nextM 1550173978.68267
Attributes:
model virtual_3
peerIDs
webCmd press short:press long
list WOH_virt_Temperatur_Sensor2
Internals:
DEF 96886302
FUUID 5c65c66f-f33f-194f-6420-2ca380541b1b772e
NAME WOH_virt_Temperatur_Sensor2
NOTIFYDEV global
NR 135
NTFY_ORDER 50-WOH_virt_Temperatur_Sensor2
STATE stopped
TYPE CUL_HM
chanNo 02
device WOH_virt_Temperatur
READINGS:
2019-02-14 20:50:08 state stopped
helper:
fkt virtThSens
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
vd:
idh 0
idl 0
msgCnt 1
msgRed 0
next 1550173977.74342
nextM 1550173978.68415
Attributes:
model virtual_3
peerIDs
webCmd press short:press long
list WOH_virt_Temperatur_Sensor3
Internals:
DEF 96886303
FUUID 5c65c66f-f33f-194f-8c93-c7f616199e2856bb
NAME WOH_virt_Temperatur_Sensor3
NOTIFYDEV global
NR 136
NTFY_ORDER 50-WOH_virt_Temperatur_Sensor3
STATE set_virtTemp 22.11
TYPE CUL_HM
chanNo 03
device WOH_virt_Temperatur
peerList WOH_HEIZUNG_3_Weather,
Helper:
DBLOG:
state:
DbLog:
TIME 1550960707.35093
VALUE set_virtTemp 22.11
temperature:
DbLog:
TIME 1550960707.32122
VALUE 22.11
READINGS:
2019-02-14 20:50:08 peerList WOH_HEIZUNG_3_Weather,
2019-02-23 23:25:07 state set_virtTemp 22.11
2019-02-23 23:25:07 temperature 22.11
helper:
fkt virtThSens
virtTC 00
bm:
CUL_HM_Set:
cnt 86
dmx -1000
dtot 0
dtotcnt 0
mTS 23.02. 19:35:07
max 0.509747982025146
tot 13.2008366584778
mAr:
HASH(0x2f14c80)
WOH_virt_Temperatur_Sensor3
virtTemp
21.95
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
vd:
cmd 8470968863000000
idh 2730472
idl 25344
msgCnt 52
msgRed 0
next 1550960928.02709
nextM 1550960928.02709
typ 2
val 00DD
vin 22.11
Attributes:
model virtual_3
peerIDs 62FACF01,
webCmd press short:press long
list WOH_virt_Temperatur
Internals:
DEF 968863
FUUID 5c65c66f-f33f-194f-16ce-89c70e3801f70a8d
IODev HmUART
NAME WOH_virt_Temperatur
NOTIFYDEV global
NR 133
NTFY_ORDER 50-WOH_virt_Temperatur
STATE CMDs_done
TYPE CUL_HM
channel_01 WOH_virt_Temperatur_Sensor1
channel_02 WOH_virt_Temperatur_Sensor2
channel_03 WOH_virt_Temperatur_Sensor3
protSnd 5173 last_at:2019-02-23 23:28:48
protState CMDs_done
Helper:
DBLOG:
state:
DbLog:
TIME 1550960928.19061
VALUE CMDs_done
READINGS:
2019-02-23 23:28:48 state CMDs_done
helper:
HM_CMDNR 236
mId
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:
IODev HmUART
expert 2_raw
model virtual_3
msgRepeat 0
subType virtual
webCmd virtual
So, gedanklich nochmal von vorne:
Wenn du drei unterschiedliche Temperatur-Sensoren mit unterschiedlichen Werten nehmen willst, benötigst du nicht ein virtuelles Device mit drei Kanälen, sondern drei mit je einem Kanal...
Für Wohnung1-Wetter wäre das 965175 bzw. 96517501 (das steht schon im Aktor),für Wohnung2-Wetter entsprechend 966555 und 96655501 (dt.)
Wohnung3-Wetter ist schließlich mit Kanal 3 von 968863 gepeert (das kann so bleiben)
Ergo: lege zwei virtuelle Devices an mit den fehlenden 6-stelligen Nummern und ändere die Definitionen von den ersten beiden WOH_virt_Temperatur_Sensor(1|2) ab auf 96517501 bzw. 96655501.
Dann mußt du jeweils noch das peerIDs-Attribut anpassen (müßte eigentlich reichen) oder eben doch nochmal ein Peering durchführen...
Jedenfalls auf den Aktoren wäre es so ok, nur FHEM ist verbogen, weil du genau das Gegenteil von dem gemacht hast, was du eigentlich als Auftrag aus dem anderen Thread mitbekommen hast: Eine Temperatur => ein Kanal von einem _separaten_ Device.
Grad das letzte List sagt doch deutlich, was du hast: EIN Device mit 3 Kanälen... Und genau das geht nicht, jedenfalls nicht mit den RT's.
Meinst du die internen Temperatur-Sensoren in den drei Heizkörperthermostate HM-CC-RT-DN selber?
Weil ich habe doch nur einen externen Temperatur-Sensor (Xiaomi) und drei Heizkörper (mit je einen Heizkörperthermostat HM-CC-RT-DN) in einem Raum.
Deshalb hatte ich es auch nach dieser Anleitung versucht (https://raspberry.tips/hausautomatisierung/fhem/heizungssteuerung-mit-homematic-hm-cc-rt-dn-und-fhem-auf-dem-raspberry-pi), da ich dachte, dass es vergleichbar mit meinem Vorhaben ist. In dieser Anleitung wurden es statt mit drei mit zwei Thermostaten konfiguriert.
Nach dieser Anleitung wurde für einen Raum ein virtuelles Device (bei mir WOH_virt_Temperatur) und pro HM-CC-RT-DN im Raum ein virtueller Aktor (bei mir set WOH_virt_Temperatur virtual 3). So dass ich dann 3 virtuelle Sensoren (Buttons) habe.
Wie bereits geschrieben hat es nach dieser Anleitung im Kinderzimmer (wo die HM-CC-RT-DN noch "jungfreulich" waren) funktioniert. Im Wohnzimmer habe ich durch meine vorherige Probiererei etwas durcheinander gebracht.
Wie kann ich das jetzt wieder geradebiegen?
Ich hoffe Du hast noch etwas Geduld mit mir; ich glaube nämlich, dass ich sonst hier nicht mehr weiterkommen. ::)
Nein, es ging immer um den/die externen Temp-Sensoren, der/die via virtuellem Kanal gepeert werden soll/en.
Wenn also einer für drei maßgeblich sein soll, muss auf dem Wetter-Kanal im Aktor auch derselbe virtuelle Peer stehen - bei dir sind das aber drei verschiedene virtuelle Kanäle, und im Wetter-Kanal steht jeweils ein ganz anderes Stamm-Gerät drin.
Also doch: peerBulk verwenden, und erst mal die falschen Peers jeweils aus dem Wetter-Kanal werfen.
Dann alle (also auch die zwei, die nicht funktionieren) mit demselben virtuellen Kanal peeren (dem aus dem funktionierenden).
Das Prinzip muß aber so sein, wie ich das mit den Türkontakten schon dargestellt hatte: Alles, was zusammengehört (alle RTs und ggf. ein WT, nennen wir das Gruppe), bekommt ein virtuelles Stammdevice. Daran darf es max. zwei Kanäle geben, nämlich einen virtuellen Fenster/Türkontakt und ein Temp.-Kanal. Damit (mit dem Temp-Kanal und/oder dem FK-Kanal) wird die Gruppe dann jeweils in den entsprechenden Kanälen des RT/WT gepeert.
Sorry, wenn ich das nicht besser erklären kann, da fehlt mir im Moment auch etwas die Geduld.
Liegt vermutlich auch daran, dass ich mich über diese zumeist halbgaren Tutorials ärgere (leider ist das im Wiki auch noch verbesserungsfähig, sonst wäre ich schon lange raus).
Beim Nachlesen bzgl. peerBulk bin ich auch über die (deutsche) Commandref zu CUL_HM gestolpert. Lies da mal die Einleitung und dann den Teil zu peerBulk. Vielleicht verstehst du das dann besser, was ich meine und worauf ich raus wollte.
Eines möchte ich vorweg sagen.
Ich bin Dir dankbar, dass du Dir die Zeit nimmst (und auch andere User im anderen Treads); es ist nicht selbstverständlich, vor allem wenn sich jemand so anstellt wie ich ;)
Du erklärst es auch sehr gut; ich muss es halt erst verstehen.
In der Wiki habe ich bzgl. dem peeren zuerste nachgesehen. Leider bin ich damit nicht klar gekommen. Ich denke, dass es daran liegen könnte, dass die Wiki Leute schreiben, welche Ahnung davon haben. Leute die von der Sache Ahnung haben, verstehen das auch wahrscheinlich. Ein Leihe wie ich, hat damit aber dann evlt. Probleme. Deshalb hat ich nach weiteren Anleitungen gesucht. Diese eine hat es mir leichter gemacht.
Werde mir peerBulk nochmal genauer anschauen. Auf die Schnelle war es in der Wiki für leider auch (noch) nicht verständlich.
Ich muss es irgendwie schaffen, dass ich mein verursachtes Chaos wieder beseitigen kann...
Würde mich aber trotzdem freuen, wenn ich später nochmal evtl. Fragen beantortet bekomme.
Schöne Sonntag
Danke für die Rückmeldung, aber in dem Fall hatte ich mit Absicht auf die _deutsche commandref_ verwiesen und dort nur auf Abschnitte.
Am besten du "vergißt" erst mal alles, was du bisher gelesen hast und "lernst das aus der commandref auswendig" (nur die Auszüge...). Da steht sehr straff genau das, was du brauchst. Kein Gemüse drumrum, aber das Notwendige.
Erst mal vorne weg. Es funktioniert (hoffentlich nicht nur kurzzeitig) ;D
Ganz genau weiß ich immer noch nicht was ich gemacht habe aber es funktioniert und es werden keine Fehlermeldungen angezeigt.
Folgendes habe ich eingegeben
set WOH_HEIZUNG_1_Weather peerBulk 96517501
Habe aber nicht bemerkt, dass sich etwas ändert oder funktioniert
---
Dann habe ich manuell unter WOH_HEIZUNG_1_Weather bei Attributes -> peerIDs die HMID "96517501" geändert auf "96886301"
Es wurde dann zumindest unter "peerList" "WOH_virt_Temperatur_Sensor1" angezeigt und nicht mehr "96517501"
Der Befehl set hm peerXref zeigte jedoch an, dass das peeren wieder nicht funktioniert hat.
Habe dann nochmal
set WOH_virt_Temperatur_Sensor1 peerChan 0 WOH_HEIZUNG_1_Weather single set
Es funktionierte wieder nicht unter es wurde unter WOH_HEIZUNG_1_Weather bei Attributes -> peerIDs wieder die HMID "96517501" angezeigt.
Diese habe ich dann nochmal manuell die peerIDs auf "96886301"geändert.
Nun zeigte mir der Befehl set hm peerXref an, dass das peeren in beide Richtungen funktioniert.
Das selbe habe ich dann mit WOH_HEIZUNG_2_Weather gemacht und es funktioniert auch.
Zwischen den einzelnen Schritten habe ich immer mal wieder unter "WOH_HEIZUNG_1" getConfig geklickt (und am Thermostat die Anlerntaste gedrückt bis der Anlernmodus gestartet ist) bis "CMDs_done" dort stand.
Ich hoffe, dass es jetzt auf Dauer funktioniert.
Zuletzt habe ich dann noch mit den Befehl
define at_WOH_virt_Temperatur_Sensor1 at +*00:05 { my $T=(ReadingsVal("WOH_LUFTFEUCHTE","temperature",20.0));; fhem "set WOH_virt_Temperatur_Sensor1 virtTemp $T" }
eingestelt, dass die wirkliche Temperatur an den virtuellen Sensor übertragen wird (das selbe mit Sensor2 und Sensor3)
Nicht optimal ist jedoch, dass die Temperaturwerte vom externen Thermometer zu verschiedenen Zeiten (1-3 Minuten) an die virtuellen Sensoren übertragen werden und dadurch unterschiedlich sind.
Kann man dies optimieren, dass die Sensoren immer gleichzeitig die Temperatur übermittelt bekommen (und somit alle immer dieselbe)?
Vorab mal: Schön, dass es jetzt soweit zu funktionieren scheint.
Was ich nicht verstehen: Warum das at, um die Temperaturwerte zu übertragen?
Wenn ein aktualisierter Wert reinkommt (vom Sensor), sollte dieser direkt auch im virtuellen Kanal landen (mit notify oder einem anderen EventHandler). Dort holt ihn der RT bzw. die RT'S dann jeweils ab, wenn er aufwacht. Allerdings sollte dazu der Sensor tatsächlich regelmäßig einen aktualisierten Wert senden, sonst verwenden die RT's irgendwann den internen Thermometer (was jedenfalls dann richtig ist, wenn der externe Sensor ausgefallen sein sollte).
Darüber solltest du dir nochmal Gedanken machen.
Weitere Anregung: Man braucht nicht unbedingt für jeden externen Sensor ein eigenes notify, sondern kann das generalisieren. Dazu muss dann aber der notify-Code "wissen", wohin er jetzt den Wert schicken muß. Das kann man hart vercoden, man kann aber auch z.B. einen FILTER verwenden, der dann den Wert "automatisch" an das richtige Device weitergibt. Hier würde ich empfehlen, je ein Reading am virtuellen Temp-Sensor (am Kanal) anzulegen, das als Inhalt den Namen des tatsächlichen Sensors hat. Der Readingname sollte "associatedWith" lauten. Damit kann nämlich FHEM ermitteln, dass die Geräte "probably associated with" (unten in der Detailansicht des Geräts) sind.
Beispielcode (Fritzbox-MAC-Check nach der Wiki-Anleitung, event-on-change-reading bei der Fritzbox gesetzt, so dass nur eine Änderung das notify triggert):
defmod rr_xn_MAC_Check notify Fritzbox:mac_.*:.* {if ($EVTPART1 eq "inactive") {\
fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone absent");;\
}\
else {\
fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone present");;\
}\
}
(das Reading "smartphone" ist in der setList der dummy-Geräte enthalten, weiter gibt es da ein Reading smartphone_MAC, das jeweils den zugehörigen Wert enthält)
Mußt du aber nicht so machen, ist wirklich nur als Anregung gedacht.
Gruß, Beta-User
Da ich leider die Zusammenhänge noch nicht so ganz verstanden habe, muss ich mich an Anleitungen entlang hangeln. Das at wurde in der genannten Anleitung verwendet und funktioniert bei diesen anscheinend. Das Wiki ist leider für einen Leihen bzw. für mich nicht immer verständlich. Eine Anleitung, Buch, Blog,... zum lernen von FHEM habe ich noch nicht gefunden.
Ein Bekannter versucht mich schon länger von Openhab 2 zu überzeugen, da es seiner Meinung nach einfacher zu handhaben ist. Bisher möchte ich aber trotzdem bei FHEM bleiben, da ich jetzt schon einiges an Zeit investiert habe. Ich komme jedoch immer mehr ins Grübeln. Ich weiß nicht wieviel Zeit ich noch investieren möchte. Sorry, aber derzeit (jetzt) bin ich ziemlich genervt von FHEM. Ich hoffe, nach einer Runde schlaf legt sich das wieder
Ein Grund ist, dass die Ganze Sache jetzt wieder nicht funktioniert.
Ich habe an den Heizungen bzw. Thermostaten nichts mehr gemacht, seit es funktionierte. Ich habe lediglich etws mit einem Wandschalter von Homematic probiert.
Der Befehl set hm peerXref zeigt wieder die falschen peerings. Es sind wieder die HMID's 96517501 und 96655501 von denen ich nicht weiß woher sie kommen bzw. wie ich sie los werde.
peerXref done:
x-ref list
KIND_HEIZUNG_1_Weather => KIND_virt_Temperatur_Sensor1
KIND_HEIZUNG_2_Weather => KIND_virt_Temperatur_Sensor2
KIND_virt_Temperatur_Sensor1 => KIND_HEIZUNG_1_Weather
KIND_virt_Temperatur_Sensor2 => KIND_HEIZUNG_2_Weather
WOH_HEIZUNG_1_Weather => 96517501
WOH_HEIZUNG_2_Weather => 96655501
WOH_HEIZUNG_3_Weather => WOH_virt_Temperatur_Sensor3
WOH_virt_Temperatur_Sensor1 => WOH_HEIZUNG_1_Weather
WOH_virt_Temperatur_Sensor2 => WOH_HEIZUNG_2_Weather
WOH_virt_Temperatur_Sensor3 => WOH_HEIZUNG_3_Weather
Sorry, aber dein Verständnisproblem ist nicht FHEM-spezifisch.
Wie bereits erläutert, holt sich FHEM (via getConfig in Folge der Konsistenzprüfung der Installation durch hminfo) schlicht ab, was in den Aktoren steht. Das ist ergo IMMER NOCH FALSCH.
Das peerXref sollte (nach meinem Verständnis deines Ziels) so aussehen:
x-ref list
KIND_HEIZUNG_1_Weather => KIND_virt_Temperatur_Sensor1
KIND_HEIZUNG_2_Weather => KIND_virt_Temperatur_Sensor1
KIND_virt_Temperatur_Sensor1 => KIND_HEIZUNG_1_Weather
KIND_virt_Temperatur_Sensor1 => KIND_HEIZUNG_2_Weather
WOH_HEIZUNG_1_Weather => WOH_virt_Temperatur_Sensor1
WOH_HEIZUNG_2_Weather => WOH_virt_Temperatur_Sensor1
WOH_HEIZUNG_3_Weather => WOH_virt_Temperatur_Sensor1
WOH_virt_Temperatur_Sensor1 => WOH_HEIZUNG_1_Weather
WOH_virt_Temperatur_Sensor1 => WOH_HEIZUNG_2_Weather
WOH_virt_Temperatur_Sensor1 => WOH_HEIZUNG_3_Weather
Wenn dir das aber immer noch nicht klar sein sollte, dann - das ist ernst, aber nicht böse gemeint! - solltest du ggf. einfach darüber nachdenken, die Finger von jeder Art der Hausautomatisierung zu lassen.
Just my2ct.
Beta-User
Zitat von: Ruggy am 24 Februar 2019, 23:17:05
Dann habe ich manuell unter WOH_HEIZUNG_1_Weather bei Attributes -> peerIDs die HMID "96517501" geändert auf "96886301"
Weil wie Beta-User schon geschrieben hat: die Peers stehen in Registern IN den GERÄTEN, da ist es egal was du in den Attributen in fhem rumschreibst.
Nach den nächsten Abfragen von den Geräten ist es wieder so wie es IN den GERÄTEN ist...
Ich hab jetzt nicht alle Peering-Befehle die du gepostet hast angesehen aber da machen so einige keinen Sinn...
Es sollte aber im Forum einige Threads genau mit diesem Thema (Peeren mit virtuellen Temp-Sensoren) geben...
EDIT: evtl. das: https://forum.fhem.de/index.php/topic,19686.msg726413.html#msg726413 oder das: https://forum.fhem.de/index.php/topic,85166.msg775172.html#msg775172
Gruß, Joachim
Möchte nur kurz Berichten, dass es bisher funktioniert.
Ich hätte gleich "folgen" sollen und für jedes Thermostat, jeweils ein virtuelles device mit einen virtuellen Kanal erstellen.
Habe mich zu sehr an eine Anleitung geklammert (siehe Link) nach welcher es aber bei den Erstelle funktioniert hat. Und im Kinderzimmer hat es bei mir ja auch nach dieser Anleitung funktioniert.
Aber letztlich habe ich es so gemacht, dass ich die drei Thermostate entpeert habe (mit unset) und die Devices und die dazugehörigen Kanäle/Sensoren gelöscht habe. Dann habe ich jedes Thermostat einzeln behandelt und habe dabei die HMID (für jedes der drei Thermostate eine andere) verwendet, welches das Thermostat "unbedingt immer wollte".
Falls es jemanden interessiert oder auch bei einen ähnlichen Problem weiterhilft; hier kurz die Befehlte welche ich nacheinander in FHEM ausgeführt habe
define WOH_virt_Temperatur_1 CUL_HM 965175
set WOH_virt_Temperatur_1 virtual 1
rename WOH_virt_Temperatur_1_Btn1 WOH_virt_Temperatur_1_Sensor1
attr WOH_virt_Temperatur_1 IODev HmUART
Dann unter dem Gerät WOH_virt_Temperatur_1 das Attribut "expert" löschen (ich weiß nicht aus welchem Grund das machen soll/muss; dies habe ich aber aus der o.g. Anleitung)
zwischendruch immer wieder mit "save config" gespeichert
Dann zum peeren folgenden Befehl:
set WOH_virt_Temperatur_1_Sensor1 peerChan 0 WOH_HEIZUNG_1_Weather single set
Folgendes habe ich dann gemacht um den peervorgang zu starten bzw. etwas zu beschleunigen:
-> am Thermostat den mittleren Taster länger drücken bis von 30 sec heruntergezählt wird
-> beim Gerät WOH_HEIZUNG_1 nachsehen ob CMDs_done steht
-> falls nicht; "getConfig" oben im Gerät WOH_HEIZUNG_2 anklicken und erneut am Thermostat die mittlere Taste drücken
Dann folgender Befehlt, dass die Temperatur vom externen Sensor alle 5 Minuten auf den virtuellen Sensor übertragen wird (wenn keine Übertragung, warum auch immer, erfolgt soll ein Temperaturwert von 20 Grad übertragen werden
define at_WOH_virt_Temperatur_1 at +*00:05 { my $T=(ReadingsVal("WOH_LUFTFEUCHTE","temperature",20.0));; fhem "set WOH_virt_Temperatur_1_Sensor1 virtTemp $T";;}
Für die anderen zwei Thermostate habe ich es genauso gemacht nur hat mit Heizung_2 und Heizung_3, Temperatur_2 und Temperatur_3, Temperatur_2_Sensor1, Temperatur_3_Sensor1 und für jedes Thermostat eine andere HMID.
Ich hoffe ich habe hier jetzt nichts falsches geschrieben; bei mir funktioniert es bisher. Falls nicht bitte melden.
Das einzige, was mich noch stört ist, dass manchmal die Ventile immer so extrem ihre Position ändern. Liegt dies am Heizsystem oder geht das nicht anders.
Dies ist vor allem auch (aber nicht nur in dieser Situation), wenn das Zimmer durch Stoßlüften abkühlt. Danach werden die Ventile bis zu 100% geöffnet, bis die Temperatur erreicht ist.
Aber auch ohne das Lüften sind manchmal so Ventilöffnungen vorhanden.
Kann man es nicht einstellen, dass z.B. nach so einen "Temperatursturz" z.B. durch Fensteröffnen (ohne einen Fensterkontakt zu verwenden) erst nach z.B. 10 minuten wieder versucht wird die eingestellte Themperatur zu erreichen? In den 10 Minuten würde sich die Lufttemperatur wieder von selber größtenteils anpassen (durch warme Wände, Möbel, Fußboden, usw). Nach den 10 min. kann ja dann wieder geheizt werden um die Temperatur zu erreichen.
Habe mal den Ventil- und Temperaturverlauf aufgezeichnet, damit man evtl. sieht, was ich meine.
Na ja, ein virtueller Peer pro Raum hätte wohl gereicht, aber schön, dass es jetzt im wesentlichen so paßt...
Was die Fensterkontakte angeht:
Hängt sehr von allem möglichen ab, was Sinn macht.
Ich habe direkte Peerings in vielen Räumen, aber da, wo oft geöffnet wird (Haustür, diverse Terrassentüren usw.), habe ich noch eine Verzögerung eingebaut: Da gibt es je einen virtuellen Fensterkontakt, der erst nach "längerer" Öffnung überhaupt geöffnet an die zugehörigen RT's schickt, so dass zum einen die Zahl der bursts geringer wird (alle wachen auf!) und auch wirklich nur runtergeregelt, wenn "zum Fenster raus" geheizt wird; bei kurzem Öffnen ist das System sowieso so träge, dass kurzzeitiges Runterregeln eh' nichts bringt.
das zugehörige notify sieht z.B. so aus:
defmod Tuerkontakt_EZ_notify notify Terrassentuer_EZ:(open|closed).* {\
if($EVENT eq "open" )\
{fhem 'defmod at_Check_EZ at +00:01:30 {if (Value("Terrassentuer_EZ") eq "open" && ReadingsVal("Heizperiode","state","off") eq "on") {fhem "set Virtueller_Tuerkontakt_EZ offen"}}';;\
} else {\
fhem "set Virtueller_Tuerkontakt_EZ geschlossen" if( Value("Virtueller_Tuerkontakt_EZ") ne "geschlossen" && Value("Terrassentuer_EZ") eq "closed")\
}\
}
attr Tuerkontakt_EZ_notify room Steuerung->Logik
(die Abfrage im 2. Zweig bei else könnte man vereinfachen, aber das ist ein abgestripptes notify von einem anderen, das 2 Türkontakte berücksichtigt...)
Wie meinst Du ein virtueller Peer pro Raum?
Hätte ich brauch für jedes Thermostat ein peer?
Wegen den Fensterkontakten:
Danke für das notify mit dem Türkontakt, aber das muss ich mir wieder ein paarmal durchlesen, bis ich einigermaßen weiß was hier gemeint ist. ::)
Zitat von: Ruggy am 04 März 2019, 23:09:43
Wie meinst Du ein virtueller Peer pro Raum?
Hätte ich brauch für jedes Thermostat ein peer?
Das schon, aber für alle HK-Thermostate, die in einem Raum sind, genügt jeweils einer... Du simulierst doch im Prinzip einen WandThermostaten, und der kann auch mehrere Peers haben ;) . Das war mit dem hier gemeint:
Zitat von: Beta-User am 26 Februar 2019, 07:51:41
Das peerXref sollte (nach meinem Verständnis deines Ziels) so aussehen:
x-ref list
KIND_HEIZUNG_1_Weather => KIND_virt_Temperatur_Sensor1
KIND_HEIZUNG_2_Weather => KIND_virt_Temperatur_Sensor1
KIND_virt_Temperatur_Sensor1 => KIND_HEIZUNG_1_Weather
KIND_virt_Temperatur_Sensor1 => KIND_HEIZUNG_2_Weather
WOH_HEIZUNG_1_Weather => WOH_virt_Temperatur_Sensor1
WOH_HEIZUNG_2_Weather => WOH_virt_Temperatur_Sensor1
WOH_HEIZUNG_3_Weather => WOH_virt_Temperatur_Sensor1
WOH_virt_Temperatur_Sensor1 => WOH_HEIZUNG_1_Weather
WOH_virt_Temperatur_Sensor1 => WOH_HEIZUNG_2_Weather
WOH_virt_Temperatur_Sensor1 => WOH_HEIZUNG_3_Weather
Zitat von: Ruggy am 04 März 2019, 22:23:29
(wenn keine Übertragung, warum auch immer, erfolgt soll ein Temperaturwert von 20 Grad übertragen werden
Das ist übrigens m.E. nicht gut: Wenn der externe Sensor ausfällt, sollte gar nichts mehr übertragen werden, damit die RT's den internen Sensor verwenden! Vermutlich müßte man dazu den (virtuellen) Temperaturwert löschen (da mußt du ggf. recherchieren!).
Kann es sein, dass die virtuellen Temperatursensoren das ganze FHEM ausbremsen?
Wenn ich auf "Everything" klicke, dauert es ewig, bis sich die Seite öffnet.
"Unsorted" geht schnell.
meiner Meinung nach ist es seit der Probiererei mit dem Peeren der Heizkörperthermostate und den virt. Temperatursensoren.
Habe gelesen, dass man mit myFreezemon die "Bremser" herausfinden kann. Hier ein List davon. Anscheinend liegt es wirklich an den virt Sensoren? aber was kann ich dagegen machen?
Internals:
CFGFN
FUUID 5c98e176-f33f-194f-9589-034735209486fdeb
NAME myFreezemon
NR 84245
NTFY_ORDER 99-myFreezemon
STATE s:13:43:45 e:13:43:46 f:1.685 d:tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
TYPE freezemon
VERSION 0.0.28
Helper:
DBLOG:
state:
DbLog:
TIME 1553604226.68877
VALUE s:13:43:45 e:13:43:46 f:1.685 d:tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
READINGS:
2019-03-26 13:43:46 fcDay 132
2019-03-26 00:00:11 fcDayLast 90
2019-03-26 13:43:46 freezeDevice tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019-03-26 13:43:46 freezeTime 1.685
2019-03-26 13:43:46 ftDay 311.933
2019-03-26 00:00:11 ftDayLast 237.9
2019-03-26 13:43:46 state s:13:43:45 e:13:43:46 f:1.685 d:tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
helper:
DISABLED 0
TIMER 1553604262
apptime
fn
freeze 1.68575811386108
intCount 15
msg [Freezemon] myFreezemon: possible freeze starting at 13:43:45, delay is 1.685 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
now 1553604226.68576
bm:
freezemon_Define:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 25.03. 15:11:02
max 0.00141811370849609
tot 0.00141811370849609
mAr:
HASH(0xc5ed5a0)
myFreezemon freezemon
freezemon_Get:
cnt 9
dmx -1000
dtot 0
dtotcnt 0
mTS 25.03. 21:45:32
max 0.000162839889526367
tot 0.00115418434143066
mAr:
HASH(0xc5ed5a0)
myFreezemon
?
freezemon_Notify:
cnt 39128
dmx -1000
dtot 0
dtotcnt 0
mTS 25.03. 22:45:10
max 0.00352883338928223
tot 5.59141540527344
mAr:
HASH(0xc5ed5a0)
HASH(0x3d66208)
freezemon_Set:
cnt 79
dmx -1000
dtot 0
dtotcnt 0
mTS 25.03. 20:08:47
max 0.000176906585693359
tot 0.00461697578430176
mAr:
HASH(0xc5ed5a0)
myFreezemon
?
inAt:
HASH(0x15f5d110)
HASH(0x15f3f228)
HASH(0x15f97ba8)
HASH(0x15f38a70)
HASH(0x15f8e150)
HASH(0x15f68df0)
HASH(0x15f7a378)
HASH(0x15eea838)
HASH(0x158cbd98)
HASH(0x158f6e10)
HASH(0x15f8adc0)
HASH(0x1593df08)
HASH(0x15f5a7f8)
HASH(0x15f73c38)
HASH(0x15f86278)
HASH(0x158e3cc0)
HASH(0x15f7c6d0)
HASH(0x15f6a820)
HASH(0x15fc7f68)
HASH(0x15d0f020)
HASH(0x140235e0)
HASH(0x15d4ece0)
logfilequeue:
logqueue
Attributes:
Nope, es sind nicht die virtuellen Devices, die bremsen, sondern das at:
at_KIND_virt_Temperatur_Sensor1
Ich weise nochmals darauf hin, dass die "at-Lösung" m.E. KEINE Lösung ist. Entweder es gibt neue Meßwerte, dann ist es besser, die mit notify zu übertragen, oder es gibt sie nicht, dann ist es besser, den RT-DN selber messen zu lassen...
Ok, dann weiß ich dazu schon mal Bescheid.
Und wenn du sagst, dass das "at" hier nicht ideal ist, glaube ich es dir (habe dir damals auch schon geglaubt).
Leider weiß ich nicht wie ich es mit notify lösen soll, weil ich (noch) nicht so weit bin (hoffe das kommt noch). :-[
deshalb habe ich es anhand der Anleitung (blog) gemacht.
Ist das Problem, dass mit at immer abgefragt wird, auch wenn keine Temperaturänderung war?
Zitat von: Ruggy am 26 März 2019, 14:39:44
Leider weiß ich nicht wie ich es mit notify lösen soll, weil ich (noch) nicht so weit bin (hoffe das kommt noch). :-[
https://wiki.fhem.de/wiki/Notify sollte da Abhilfe schaffen.
Dabei mußt du vom realen Temperatursensor als dem Gerät ausgehen, das Events generiert.
Zitatdeshalb habe ich es anhand der Anleitung (blog) gemacht.
Und weil es viele unsinnigen Blogs gibt, habe ich das hier mal angefangen: https://wiki.fhem.de/wiki/Dokumentationsstruktur
ZitatIst das Problem, dass mit at immer abgefragt wird, auch wenn keine Temperaturänderung war?
Ist die Frage, ob das die Ursache für das Blockieren ist? Kann ich nicht sagen, aber wenn es noch "alle 5 Sekunden" ist, ist das einfach unsinnig. Weiter ist es Unsinn, den Homematic-Aktor mit scheinbar aktuellen Werten zu füttern, wenn du nicht sicher bist, dass die aktuell sind. Das sind aber 2 Probleme, nicht "das [eine] Problem"...
Danke für den wiki-link
Das mit den Blogs glaube ich dir, aber wenn man nicht vom Fach ist und nicht weiß wie es geht, ist man für solche Lösungen dankbar. hatte auch noch einen zweiten blog gefunden wo es auch mit at gemacht wurde.
Das notify hätte ich mir schon angeschaut. kann aber zu meinem Vorhaben damit nichts anfangen? :-\
Zitat von: Beta-User am 26 März 2019, 14:49:38
Dabei mußt du vom realen Temperatursensor als dem Gerät ausgehen, das Events generiert.
Aber ich dachte, dass ich geraden den internen Sensor "umgehen" will?
werde es dann wahrscheinlich "vorerst" so lassen müssen und mit dem langsamen FHEM auskommen mussen.
Du hast doch 3 Temperatursensoren, oder?
1. Den im RT-DN. Den willst du im Regelfall nicht nutzen, weil der externe "besser" ist (ich kann das nicht in der Form bestätigen...).
2. Den virtuellen. Der wird gefüllt von dem
3. Das ist der eigentliche Sensor, der maßgeblich sein soll.
Welchen meine ich denn wohl, solltest du mit dem notify "abhören"?
Das mit dem at hat auch einen Vorteil (nicht bei 5 sek!, aber grundsätzlich): Der RT-DN schaltet nämlich nach einer bestimmten Zeit wieder auf interne Messung, wenn nichts vom Peer kommt. Aber zum einen kommt eventuell immer der letzte Wert vom Peer (und sollte als ggf. sogar aktiv gelöscht werden...), und zum anderen ist und bleibt es unsinnig, den virtuellen Sensor mit nur scheinbar aktualisierten Daten zu füttern. Das ist ok, solange du sicher bist, dass der Sensor sich wieder melden wird (manche melden sich nur alle Stunde, wenn der Wert sich nicht wesentlich geändert hat), aber wenn du das nicht weißt, ändern auch 3 blogs, die voneinander dasselbe Halbwissen abschreiben, nichts an den Tatsachen....
abhören möchte ich dann wahrscheinlich den externen nr. 3.
Der externe ist meiner Meinung nach insofern "besser", da er die Temperatur direkt im Raum misst bzw. dort wo er installiert ist und ich auch die Wunschtemperatur haben möchte. Der interne ist sehr nahe an der Heizung und ist deshalb eher Temperaturschwankungen ausgesetzt. Dies wurde bei der Entwicklung bestimmt berücksichtigt.
Ob es tatsächlich so ist, kann ich aber auch nicht sicher beurteilen.
Ich sollte also sensor 3 abhören, welcher erst nach einer Änderungen den virtuellen füttert, welcher dann wiederum die Temperatur an das Thermostat bzw. weather weiter gibt?
Wenn das so stimmt; was ist dann, wenn z. b. der externe keinen anderen wert liefert, wird dann wieder der interne Wert vom Thermostat sensor genommen?
Liege ich hiermit richtig?
Zitat von: Ruggy am 26 März 2019, 16:04:39
Wenn das so stimmt; was ist dann, wenn z. b. der externe keinen anderen wert liefert, wird dann wieder der interne Wert vom Thermostat sensor genommen?
Alles bis auf den letzten Punkt richtig :) .
Da bin ich mir nicht sicher, wie das Modul CUL_HM das macht, wenn der Wert nicht aktualisiert wird. Müßtest du im Wiki nachsehen bzw. die Threads dazu lesen und ggf. mal nachfragen (aber bitte vorher LESEN und dann qualifiziert nachfragen (unter Verlinkung der Dinge, die du dazu gelesen hast!)).
Aber selbst wenn dann der vorhandene veraltete Wert weitergegeben wird, ist das keine Verschlechterung zu jetzt (denn der mit at da reingeschriebene Wert IST ja tatsächlich NICHT aktuell!)...
dann muss ich mit das Modul CUL_HM anschauen...
Weil, wenn es ungünstig läuft kommt die Regelung evtl. durcheinander? Angenommen der externe hat z. b. 20° und liefert keinen Wert mehr; der interne schaltet sich ein und liefert z. b. einen Wert von 24°, dann liefert der externe wieder den Wert von 20°.
Die Ventile würden dann hin und her regeln?
Beim at ist es so, dass er den Wert 20° bekommen würde, wenn der sensor ausfällt und keinen wert liefert.
Zitat von: Ruggy am 26 März 2019, 16:49:23
dann muss ich mit das Modul CUL_HM anschauen...
Jein. Eher nochmal die Doku zum Thema virtueller Temperatursensor für Homematic.
ZitatWeil, wenn es ungünstig läuft kommt die Regelung evtl. durcheinander? Angenommen der externe hat z. b. 20° und liefert keinen Wert mehr; der interne schaltet sich ein und liefert z. b. einen Wert von 24°, dann liefert der externe wieder den Wert von 20°.
Die Ventile würden dann hin und her regeln?
Im ungünstigsten Fall kommt es ggf. tatsächlich zu unnötigen Adaptionsfahrten des Reglers in der Konstellation, dass der (3.) Sensor zu selten was liefert.
Das müßte man dann aber m.E. ANDERS lösen., denn:
ZitatBeim at ist es so, dass er den Wert 20° bekommen würde, wenn der sensor ausfällt und keinen wert liefert.
Wenn du dieses at meinst, ist dein Verständnis m.E. ein anderes als die tatsächliche Funktionsweise ;) :
define at_WOH_virt_Temperatur_1 at +*00:05 { my $T=(ReadingsVal("WOH_LUFTFEUCHTE","temperature",20.0));; fhem "set WOH_virt_Temperatur_1_Sensor1 virtTemp $T";;}Dafür müßte m.E. ein watchdog definiert werden (es sei denn, der oder eine vergleichbare Funktion schriebe schon was in WOH_LUFTFEUCHTE, was aber das Pferd von hinten aufgezäumt wäre...
Mein Verständnis hierzu ist annähernd gleich null :-\ ;)
In einem von dem Blogs (ich habe verstanden bzgl. den Blogs 8) ) wurde es aber so erklärt, dass wenn WOH_LUFTFEUCHTE keinen Wert liefert automatisch die 20.0 gesetzt werden.
Evtl. kann man dies ja auch mit notify irgendwie bewerkstelligen?
Habe jetzt ne zeitlang den Event Monitor mitlaufen lassen und nach dem Wohnzimmersensor filtern lassen. Die Aktualisierung ist anscheinend recht unregelmäßig. die letzten 30 min wurde nicht mehr aktualisiert.
Auch nicht so ideal. Ob das normal ist? Muss ich getrennt davon mal recherchieren
Ich lasse es noch ne weile mal mitlaufen.
Füge hier ausnahmsweise davon mal einen Screenshot ein, da ich nicht weiß wie/ob ich dies jetzt noch rückwirkend zeigen kann.
Kann schon sein, dass das in dem Blog so steht. Aber wenn, müßte irgendwo auch erläutert sein, dass das nur klappt, wenn der Readingwert aktiv gelöscht wird ;) . Denn nur dann ist kein Readingwert da und ReadingsVal() liefert den gesetzten Defaultwert zurück. Ansonsten ist ReadingsVal() egal, wie alt der vorhandene Wert ist...
Das Stichwort watchdog hatte ich genannt, oder? Versuch mal nachzudenken, was der hier wohl helfen könnte.