[GELÖST] Externe Sensoren an Thermostaten werden ignoriert

Begonnen von flummy1978, 19 Dezember 2019, 15:30:58

Vorheriges Thema - Nächstes Thema

flummy1978

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



frank

peerings sind immer "2-seitig". jeder der beiden muss den anderen kennen.
get hminfo configCheck sollte den fehler zeigen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

flummy1978

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

flummy1978

#3
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

Gernott

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?

flummy1978

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.

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

flummy1978

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

Gernott

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.