HM-CC-RT-DN Entpeeren funktioniert nicht-Wie FHEM von falschen Werten bereinigen

[Ruggy]

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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


[Beta-User]

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

[MadMax-FHEM]

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

[Ruggy]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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.

[Beta-User]

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:

Code Auswählen Erweitern

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...)

[Ruggy]

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. 

[Beta-User]

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:

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 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!).

[Ruggy]

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?

Code Auswählen Erweitern

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:

[Beta-User]

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...

[Ruggy]

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?

[Beta-User]

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.

deshalb 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

Ist 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"...

[Ruggy]

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? 

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.

[Beta-User]

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....

[Ruggy]

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?

[Beta-User]

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!)...