fakeWT: Ein Thermostat lässt sich nicht verbinden

[nuxgawk]

Hallo zusammen,

ich benutze die MAX-Thermostate nun schon seit geraumer Zeit mit einem CUL an einem Raspberry Pi. Kürzlich habe ich mir LaCrosse-Thermometer inkl. JeeLink gegönnt, die ich nun als FakeWT benutzen möchte.

Ich habe insgesamt 4 Thermostate: Eins in der Küche, Zwei im Schlafzimmer und eins im Wohnzimmer. Thermometer stehen jeweils eines in jedem der genannten Räume.

Ich habe mir die BETA der Module 10_MAX und 14_CUL_MAX heute heruntergeladen und an entsprechender Stelle abgelegt. Die fakeWT funktionieren sowohl in der Küche, als auch im Schlafzimmer. Nur im Wohnzimmer will es nicht funktionieren.

Sobald ich das Attribut externalSensor für das HT MAX_Wohnzimmer von Wohnzimmer_Temp:temperature:0 auf Wohnzimmer_Temp:temperature:1 stelle, erscheint im Log alle 10 Sekunden folgende Meldung:

Code Auswählen Erweitern

cm, could not handle message WakeUp from device MAX_Wohnzimmer to MAX_111111 - ignoring !

Nach kurzer Zeit stellt sich das HT im Wohnzimmer dann auf 12 °C ein (windowOpenTemperature).

Bei den anderen HTs funktioniert es problemlos. Natürlich wurden alle HTs mit dem fakeWT assoziiert. Die Intervalle der LaCrosse-Thermometer-Events habe ich auf 720 Sekunden gesetzt, damit der Verbrauch an Credits im Rahmen bleibt.

Irgend 'ne Idee, was da schief läuft, oder wie der Fehler zu beheben ist?

[Wzut]

also allgemein : ich bin mit dem fakeWT nie so richtig glücklich geworden, da bei mir nie mehr als eins zu gleichen Zeit funktioniert hat.
So gesehen kannst du schon mal glücklich sein wenn bei dir zwei laufen und erst das dritte mit den Mucken anfängt. Die neue Alternative sollte eigentlich das virtuelle WT werden, da hier jedes virtuelle Device seine eigene Adresse hat ( wie beim fakeShutterContact ), bisher war da aber von User Seite recht wenig Bedarf, aber die Funktionen sind im Modul vorhanden.

Aber nun zu deinem Fall : die Meldung im Log ist keine Fehlermeldung, aber schon erstaunlich !
Ich habe bisher noch nie gesehen das HTs ihrem Chef (in deinem Fall das fakeWT) WakUp Telegramme schicken. Da FHEM (das fakeWT) ja immer empfangsbereit ist wird diese Nachricht ignoriert ( steht ja auch so im Log )
Das HT ist aber dann beleidigt und reagiert mit dem rferror - kann ich noch nachvollziehen, aber das es dann auch noch auf die windowOpen Temp springt...  sehr komisch
Ok ich kann mal versuchen die WakeUp Nachricht nicht unter den Tisch fallen zu lassen und einfach mit einem ACK beantworten, doof ist dabei nur das ich im Moment noch keine Anung habe wie ich das sinnvoll testen soll, d.h. ich müsste das quasi blind ins Modul einbauen und du müsstest testen.

[Wzut]

Ich habe 14_CUL_MAX erweitert -> https://forum.fhem.de/index.php/topic,115018.0.html
a. bitte lade die neue Beta Version und starte FHEM neu ( kein einfaches reload 14_CUL_MAX )
b. stelle am cm Device den verbose Level auf 5
c. mache an deinem Wohnzimmer HT die externalSensor Änderung
d. gehe in den Event Montor mit Filter auf MAX und setze den FHEM log Haken

eigentlich solltest du hier jetzt sehen wenn versucht wird dem Wohnzimmer HT die aktuelle Ist Temperatur zu senden und wie dessen Reaktionen sind.
stelle nun das cm wieder auf verbose 3 oder 2 zurück und poste den Log Abschnitt.   

[nuxgawk]

Danke schon mal für die Antwort. Generell wäre ich bereit zu testen, wobei ich mittlerweile glaube, dass es wohl irgendwie am HT liegt. Ich werde die Tage mal einen factoryReset am Wohnzimmer-Thermostat durchführen und gucken ob es das Problem behebt.

Das virtuelle WT scheint ja aber die bessere Lösung zu sein. Die Funktion ist noch nicht im commandref zu finden, oder? Gerade mal den Code von 10_MAX.pm durchforstet. Ich würde also drei davon beispielsweise so anlegen (Adresse natürlich für jedes virtualThermostat anders):

Code Auswählen Erweitern

define Kueche_vWT MAX virtualThermostat 123123
und dann testen, wie die HTs damit zurechtkommen.

Edit: Danke für die Anpassung. Das werde ich gerne nochmal testen.

[Wzut]

ja ich wäre dir sehr dankbar zuerst die neue Version zu testen bevor du das HT dumm machst.

Mit deiner Vermutung zum define liegst du richtig, ich würde aber wenn erst einmal mit nur einem beginnen.

[nuxgawk]

Hm, also, ich habe heute Nachmittag schon mal den Log-Level auf 5 gestellt, da sah das ganze so aus:

Code Auswählen Erweitern

2020.12.06 14:33:31 5: cm, IODev CUL_0, msgcnt 01, msgType WakeUp, src 1bcff7 HeatingThermostat, dst 111111 UNKNOWN, group 0, payload 03, rssi -46
2020.12.06 14:33:31 3: cm, could not handle message WakeUp from device MAX_Wohnzimmer to MAX_111111 - ignoring !
2020.12.06 14:33:41 5: cm, IODev CUL_0, msgcnt 02, msgType WakeUp, src 1bcff7 HeatingThermostat, dst 111111 UNKNOWN, group 0, payload 03, rssi -46
2020.12.06 14:33:41 3: cm, could not handle message WakeUp from device MAX_Wohnzimmer to MAX_111111 - ignoring !
2020.12.06 14:33:52 5: cm, IODev CUL_0, msgcnt 03, msgType WakeUp, src 1bcff7 HeatingThermostat, dst 111111 UNKNOWN, group 0, payload 03, rssi -46
2020.12.06 14:33:52 3: cm, could not handle message WakeUp from device MAX_Wohnzimmer to MAX_111111 - ignoring !
2020.12.06 14:34:31 5: cm, IODev CUL_0, msgcnt 04, msgType WakeUp, src 1bcff7 HeatingThermostat, dst 111111 UNKNOWN, group 0, payload 03, rssi -46
2020.12.06 14:34:31 3: cm, could not handle message WakeUp from device MAX_Wohnzimmer to MAX_111111 - ignoring !
2020.12.06 14:34:41 5: cm, IODev CUL_0, msgcnt 05, msgType WakeUp, src 1bcff7 HeatingThermostat, dst 111111 UNKNOWN, group 0, payload 03, rssi -46
2020.12.06 14:34:41 3: cm, could not handle message WakeUp from device MAX_Wohnzimmer to MAX_111111 - ignoring !

Für den jetzigen Test habe ich die anderen Thermostate auf dummy gestellt und den dritten Parameter deren Attribut "externalSensor" auf 0 geändert, damit sie nicht im wahrsten Sinne des Wortes dazwischenfunken.

Hier ist das jetzige Ergebnis:

Code Auswählen Erweitern

2020.12.06 19:33:09 4: cm, send -> cmd:WallThermostatControl, msgcnt:d6, flags:00, Cmd2id:42, src:MAX_111111 , dst:MAX_Wohnzimmer , gid:00 , payload:28d2 , cul:none
2020.12.06 19:33:09 5: cm, send packet: 0cd600421111111bcff70028d2
2020.12.06 19:33:09 5: cm, Send Queue : 1 packet are in the queue
2020.12.06 19:33:09 5: cm, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 111, credit10ms: CUL_0 = 900, CMD_LAST_H: 10
2020.12.06 19:33:09 4: cm, Send Queue packet send : Zs0cd600421111111bcff70028d2 to MAX_Wohnzimmer with CUL_0
2020.12.06 19:33:09 5: cm, Send Queue : 1 packet are in the queue
2020.12.06 19:33:10 5: cm, Send Queue : 1 packet are in the queue
2020.12.06 19:33:10 5: cm, IODev CUL_0, msgcnt D6, msgType Ack, src 1bcff7 HeatingThermostat, dst 111111 UNKNOWN, group 0, payload 01180028, rssi -41.5
2020.12.06 19:33:10 5: cm, ACK from HeatingThermostat MAX_Wohnzimmer for cmd WallThermostatControl , packet will be removed soon
2020.12.06 19:33:10 5: cm: dispatch MAX,0,Ack,1bcff7,01180028
2020.12.06 19:33:10 5: MAX_Parse, MAX,0,Ack,1bcff7,01180028
2020.12.06 19:33:10 5: cm, Send Queue : 1 packet are in the queue
2020.12.06 19:33:10 4: cm, Send Queue ACK from MAX_Wohnzimmer for WallThermostatControl, removing from queue
2020.12.06 19:33:10 5: cm, Send Queue is now empty
2020.12.06 19:33:11 5: cm, IODev CUL_0, msgcnt 00, msgType ThermostatState, src 1bcff7 HeatingThermostat, dst 000000 UNKNOWN, group 0, payload 18002800D2, rssi -41.5
2020.12.06 19:33:11 5: cm: dispatch MAX,0,ThermostatState,1bcff7,18002800D2
2020.12.06 19:33:11 5: MAX_Parse, MAX,0,ThermostatState,1bcff7,18002800D2

Scheint so, als hätte das HT sich erholt?! Ich werde mal die anderen Thermostate dazuschalten und gucken was passiert.

Vielen Dank für die Hilfe.

[Wzut]

Danke, echt komisch
Dein zweites Log sieht aus wie erwartet, kein WakeUp Telegramm.
Und nun ?
Ich würde es aber ein paar Tage unter Beobachtung halten mit Level 3 und immer ins Log schauen wenn das Wohnzimmer HT Auffälligkeiten zeigt.

[nuxgawk]

Ja, das war eigentlich auch mein Plan. Nun macht aber die Küche Probleme. Ich habe nach dem Kochen dort etwas gelüftet, was das HT wohl richtigerweise dazu veranlasst hat, die windowOpenTemperature zu setzen. (Ich habe keine Fensterkontakte im Einsatz.)

Code Auswählen Erweitern

2020.12.07 18:26:54 3: cm, got WakeUp from device [1bcdb3] MAX_Kueche to [111111] MAX_111111
2020.12.07 18:26:54 3: cm, 111111 is a fakeWT, we will send ACK back now
2020.12.07 18:26:54 1: cm, could not find valid hash for src MAX_090708 -> dst MAX_111111, nothing will be send !

Die drei Meldungen wiederholen sich einige Male bis 18:41:05, dann ist der eingestellte Countdown der windowOpenTemperature ja abgelaufen und das HT stellt sich wieder auf die eingestellte desiredTemperature. Bei Verbosity-Level 3 herrscht im Log dann erstmal einige Minuten Funkstille, bis ohne weitere Vorwarnung folgendes erscheint:

Code Auswählen Erweitern

2020.12.07 18:50:30 2: cm, Send Queue missing ack from MAX_Kueche for WallThermostatControl, removing from queue

Kurze Zeit später hat sich das HT erneut auf die windowOpenTemperature gestellt, die obigen Logs blieben jedoch aus.

Alles sehr seltsam. Mein jetziger Plan ist, mich am Donnerstag intensiver mit den Thema »virtualThermostat« zu beschäftigen, da ich dann frei habe.

Danke trotzdem vielmals für die Hilfe.

[Wzut]

Nunja zumindest wurde nun der neue Teil mal durchlaufen :

Code Auswählen Erweitern

2020.12.07 18:26:54 3: cm, 111111 is a fakeWT, we will send ACK back now
2020.12.07 18:26:54 1: cm, could not find valid hash for src MAX_090708 -> dst MAX_111111, nothing will be send !
die zweite Zeile ist so kompletter Unsinn, hast du ein Device mit der Adresse 090708 ?
Das ist halt das Problem wenn es selbst nicht nachstellen kann, aber ich geh mal suchen das reizt mich einfach

Mit dem virtuellen Thermo kannst du heute noch nicht beginnen, da fehlt noch zuviel Code im Modul.
Ich kann dir auch nicht versprechen was ich davon die nächsten beide Tage noch schaffe.


edit : der Sendeaufruf für das Ack war Blödsinn , traust du dir zu den Teil zu tauschen ?

Code Auswählen Erweitern

if ($msgType eq 'WakeUp') {
Log3($sname,  3, "$sname, got WakeUp from device [$src] $src_name to [$dst] $dst_name");
if ($dst eq AttrVal($sname, 'fakeWTaddr', '')) {
    Log3($sname,  3, "$sname, $dst is a fakeWT, we will send ACK back now");
    my $groupid = ReadingsNum($src_name, 'groupid', 0);

    Send($shash, 'Ack', $src, '00',
groupId => sprintf('%02x', $groupid),
flags   => ( $groupid ? '04' : '00' ),
src     => AttrVal($sname, 'fakeWTaddr', '111111')
);
    return $name;
}
    }


[nuxgawk]

Das Device mit der Adresse 090708 ist mein CUL, der müsste eigentlich kein Telegramm an das FakeWT senden, ist er ja selber, wenn auch unter anderer Adresse.

Hab den Code ab Zeile 971 getauscht und bin gespannt, was passiert. Echt guter Support. Vielen Dank.

Edit: Nachdem fhem wieder gestartet wurde, läuft mir die sendQueue voll und frisst meine Credits, diesmal wieder mit dem Wohnzimmer-HT.

Code Auswählen Erweitern

        Time        | Destination    | Command
--------------------+----------------+--------
2020-12-07 20:18:38 | MAX_Wohnzimmer | Ack   
2020-12-07 20:18:49 | MAX_Wohnzimmer | Ack   
2020-12-07 20:19:28 | MAX_Wohnzimmer | Ack   
2020-12-07 20:19:38 | MAX_Wohnzimmer | Ack   
2020-12-07 20:19:49 | MAX_Wohnzimmer | Ack   
2020-12-07 20:20:28 | MAX_Wohnzimmer | Ack   
2020-12-07 20:20:38 | MAX_Wohnzimmer | Ack   
2020-12-07 20:20:49 | MAX_Wohnzimmer | Ack   
2020-12-07 20:21:28 | MAX_Wohnzimmer | Ack   
2020-12-07 20:21:38 | MAX_Wohnzimmer | Ack   
2020-12-07 20:21:49 | MAX_Wohnzimmer | Ack   
--------------------+----------------+--------

[Wzut]

ja vermutlich werden sie in der SendQueue nicht gelöscht weil einfach unbekannt ist wann sie denn gelöscht werden dürfen.
Ich denke inzwischen das ist ganz der falsche Ansatz, du schriebst das du relativ lange Intervalle hast für die aktuelle Ist Temperatur ( 720 ? )
Das ist erheblich länger als bei einem echten WT. U.U. ist das WakeUp auch eine Art Hilferuf an den Chef sich doch endlich mal wieder zu melden.

Da fällt mir noch etwas ein : Haben deine HTs verschiedene groupIds in den jeweiligen Räumen ?
Bzw. da du im Schlafzimmer zwei Stück hast müssen die die gleiche groupId haben.

[Wzut]

Eigentlich bringt man einem alten Hund keine Kunststückchen mehr bei, aber ich habe es jetzt doch geschafft das nachzustellen und kann es auch zu einem gewissen Teil erklären.

Auslöser ist wie bereits vermutet der lange Intervall des externen Sensors. Das HT geht nach einer Zeit X (die muss ich noch genau bestimmen) auf rferror. In FHEM sieht man es nicht sofort da kein Telegram verschickt wird, aber am HT blinkt der Funkturm. Mit dem rferror schaltet das HT wieder um auf seinen internen Temp Sensor.
Wenn nun irgendwann vom Chef ein Telegramm über die neue Ist Temperatur kommt und diese einen bestimmten Betrag niedriger ist als die interne des HTs, dann meint es einen Temperatursturz zu erkennen und geht auf Window Open Temp. Mit diesem Ereigniss beginnt das HT nun auch die WakUp Telegramme zu verschicken.
Ich vermute es will sicherstellen das der letzte Wert so in Ordung war und ihn einfach nochmal. Ist aber eine reine Vermutung, ich muss schauen ob ich das mit einem echten WT irgendwie nachstellen kann um zu sehen wie das WT auf ein WakeUp antwortet.
Dummerweise kann man sich dabei auch nicht auf windowOpenDuration verlassen, so hat es bei mir heute morgen fast ne Stunde gedauert bis das HT wieder aus dem Fenster offen Mode raus ist.

Edit : jetzt ist mir auch klar warum der HT ewig bei der WindowOpenTemp hängen bleibt :
das ist die aktuelle desired Temperatur die für den fakeWT als Referenz verwendet wird. Ein echtes WT würde die nach seinem aktuellen Weeekprofile wählen.
Jetzt fällt mir auch wieder ein was ich schon immer mal ins Modul packen wollte : Feststellen der aktuellen Soll Temp nach Datum/Uhrzeit im Weekprofile.
Das brauche ich später für das virtuelle Thermo und beim fakeWT würde sich die Katze nicht mehr in den Schwanz beissen.

[nuxgawk]

ja vermutlich werden sie in der SendQueue nicht gelöscht weil einfach unbekannt ist wann sie denn gelöscht werden dürfen.

Ich habe es jetzt nicht genau nachgehalten, aber ich meine nach drei fehlendes Acks seitens der HTs werden die Befehle aus der Queue gelöscht. Die sendQueue wächst aber trotzdem kontinuierlich, da die Credits auf diese Weise recht schnell zur Neige gehen.

( 720 ? )
Das ist erheblich länger als bei einem echten WT. U.U. ist das WakeUp auch eine Art Hilferuf an den Chef sich doch endlich mal wieder zu melden.

Ich werde mal versuchen das Ganze zu halbieren und gucken, was dann mit meinen Credits passiert. Vielen Dank auch für die umfangreiche Analyse im darauffolgenden Post.

Da fällt mir noch etwas ein : Haben deine HTs verschiedene groupIds in den jeweiligen Räumen ?
Bzw. da du im Schlafzimmer zwei Stück hast müssen die die gleiche groupId haben.

Die beiden HTs im Schlafzimmer haben die gleiche groupId bekommen und sind untereinander assoziiert. Könnte man dann nicht eigentlich auch eines der beiden in fhem auf "dummy" stellen? Es sollte die Werte ja vom anderen HT bekommen. Auf diese Weise würde ich auch Credits sparen.
Die groupIds der anderen beiden HTs habe ich auf 0 gelassen. Sollten die auch ungleich 0 sein?

[Wzut]

Die Idee bei deinem Tandem einen zum dummy zu machen und dem anderen die Arbeit zu überlassen hört sich erst einmal gut an,
ich kann auch kein aber anbringen da ich das so noch nie im Einsatz hatte.
Aber (also doch) du darfst das gerne testen, wir alle freuen uns über neue Erkentnisse

Deine beiden Nuller sollten unbedingt jeweils groupIds grösser 0 haben, denn wie ich schon oft schrieb ist für MAX die groupId der Raum und alles was die gleiche groupId hat gehört dann zusammen und das ist bei dir ja nicht der Fall.

Zum Thema Intervall läuft bei mir gerade ein Test : 420 ohne Murren, vor 5 Minuten bin ich auf Stufe 480 gegangen.

[nuxgawk]

Kurzes Update zum Tandem: Hat nicht so gut funktioniert. Das linke Schlafzimmerthermostat hat während der dummy-Phase auf rferror geschaltet. Das war ja im Grunde zu erwarten. Dann hat es aber innerhalb einer Viertelstunde 17 WakeUp-Anfragen an das rechte Schlafzimmerthermostat gesendet. Da es so viele innerhalb so kurzer Zeit waren, vermute ich, dass es die erwünschte Antwort nicht bekommen hat.

Und Update zu verkürztem Intervall: Die Credits waren doch recht schnell in niedrigen Bereichen angekommen, so dass die SendQueue zwar langsam, aber doch stetig wuchs.

Ich habe deshalb jetzt erstmal alles wieder so eingestellt, dass das Wochenprogramm halbwegs vernünftig läuft. Die 12 °C werden nur vereinzelt geschaltet, was mich nicht weiter stört.

Vielen Dank für alles. Ich lasse das jetzt erstmal so.

[Wzut]

OK, dann auch ein kurzes Update von meiner Seite :
Aus dem 12°C Loch komme ich jetzt ganz gut raus indem ich den echten Soll Wert des HTs aus dem Wochenprogramm als Soll nehme.
Mit den WakeUps bin ich nicht weiter gekommen, nur wenn das HT zuviele rausgehauen hat blinkt der Funkturm schnell !!
Schnell bedeutet das seine Credis alle sind und da die sich nicht im Minutentakt erholen wie beim CUL ist das Ding eine Stunde lang von FHEM aus nicht mehr ansprechbar und sndet selbst natürlich auch nichts mehr.
Kontrolle : am HT Auto/Manu drücken wenn die Credits alle sind erscheint kurz dEC im Display.

[Wzut]

also MAX bringt mich noch an den Rand der Verzweiflung
Ich habe heute ein HT mit einem WT gepeered und dann das WT in einer Keksdose eingeschlossen weil ich warten wollte bis das HT mit seinen WakeUps anfängt.
Aber was macht das blöde Ding ? Statt WakeUps schickt es regelmäßig seinen Status als Broadcast raus.
Das heisst nun für mich ein Peering HT-WT ist etwas anderes als ein Peering HT-fakeWT.
Ich werde nun nicht mehr dem Wakeups hinterher jagen sondern checken wo der Unterschied bei der Hochzeit liegt.

[nuxgawk]

Nochmal ein kurzes Update zum jetzigen Stand. Die fakeWT scheinen im Großen und Ganzen zu funktionieren. Ab und zu schalten die HTs noch auf 12 °C, aber meist nur für kurze Zeit. Heute Morgen allerdings waren die Credits vom Wohnzimmer-HT verbraucht, nachdem es wakeUps geschickt hat, weshalb es anschließend eine Stunde bei 12 °C verharrte. (Der Funkturm hat schnell geblinkt.) Das ist aber eher die Ausnahme.

Ich hänge mal ein Bild an auf dem man sieht, dass sich die Ventile öffnen, sobald die Soll-Temperatur unterschritten ist. Die rotbraune Linie ist dabei die Temperaturverlauf aus dem state-Reading des entsprechenden LaCrosse-Sensors. Die grüne Linie ist das Temperatur Reading vom HT.

Bei den anderen HTs zeigen die Graphen das gleiche Verhalten. Die Regelung funktioniert also ganz gut, bis auf die 12-°C-Phasen.

[Wzut]

wenn du magst teste mal die angehängte 10_MAX Version, da beisst sich das Soll nicht an den 12° fest (desiredTemperature)
sondern zieht sich die passende Soll Temperatur aus dem Weekprofil (aber nur bei mode auto)

[Wzut]

kurzes Update :
ich kenne nun die richtige Antwort auf ein WakeUp von einem HT und werde das in die nächste Version von 14_CUL_MAX einbauen.

[nuxgawk]

Sehr schön, das freut mich. Danke für den Einsatz.

Vorgestern Abend habe ich übrigens schon die 10_MAX.pm getauscht. Es gab keine Auffälligkeiten und auch keinen Temperatursturz auf 12 °C mehr. 

[Wzut]

Das ist schön. Ein großes Problem des fakeWT ist das man bei dem Namen denkt es würde ein echtes WT ersetzen.
In Wahrheit ist es aber nur ein Beschaffer der Ist Temperatur und alle anderen Funktionen die ein echtes WT hat fallen einfach hinten runter.
Das wird nun bei den WakeUps richtig deutlich, hier müssen Code Abschnitte ins 14_CUL_MAX gebastelt werden die eigentlich von der Logik ins 10_MAX gehören.
Je mehr ich probiere umso mehr komme ich zu dem Entschluss das fakeWT nicht weiter aufzubohren und all diese Dinge im 10_MAX unterzubringen beim virtualThermostat.

[neyzen]

Ich lese mal mit

[neyzen]

Hallo Wzut,

wie schon im anderen Thread besprochen hab ich jetzt mein 10_Max aktualisiert.
Und hab folgende Einstellungen mit meinem Externen Sensor eingebunden.

Code Auswählen Erweitern

Internals:
   CFGFN     
   CULMAX0_MSGCNT 23
   CULMAX0_TIME 2020-12-20 20:42:48
   DEF        HeatingThermostat 0696d1
   FUUID      5fdfa4e4-f33f-2b39-5391-2040d400ba770fa1
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     23
   NAME       MAX_0696d1
   NR         1185
   NTFY_ORDER 50-MAX_0696d1
   STATE      18.5 (rf error)
   SVN        23290
   TYPE       MAX
   TimeSlot   -1
   addr       0696d1
   devtype    1
   type       HeatingThermostat
   webCmd     desiredTemperature
   READINGS:
     2020-12-20 20:24:20   PairedTo        123456
     2020-12-20 20:42:48   RSSI            -62.5
     2020-12-20 20:24:20   SerialNr        JHA0008724
     2020-12-20 20:42:48   battery         ok
     2020-12-20 20:42:48   batteryState    ok
     2020-12-20 20:42:48   desiredTemperature 18.5
     2020-12-20 20:42:48   deviation       3.3
     2020-12-20 20:24:20   error           invalid or missing value  for READING .weekProfile
     2020-12-20 20:44:30   externalTemp    21.81
     2020-12-20 20:24:20   firmware        1.6
     2020-12-20 20:42:48   gateway         1
     2020-12-20 20:24:20   groupid         0
     2020-12-20 20:42:48   lastcmd         ConfigWeekProfile
     2020-12-20 20:42:48   mode            auto
     2020-12-20 20:42:37   msgcnt          11
     2020-12-20 20:42:48   panel           unlocked
     2020-12-20 20:34:34   peerIDs         000000
     2020-12-20 20:34:34   peerList        Broadcast
     2020-12-20 20:27:29   peers           111111
     2020-12-20 20:42:48   rferror         1
     2020-12-20 20:42:48   state           18.5 (rf error)
     2020-12-20 20:34:34   temperature     21.1
     2020-12-20 20:24:20   testresult      255
     2020-12-20 20:42:48   valveposition   0
     2020-12-20 20:42:48   weekprofile-0-Sat-temp 17.0 °C  /  18.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-0-Sat-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-1-Sun-temp 17.0 °C  /  18.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-1-Sun-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-2-Mon-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-2-Mon-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-3-Tue-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-3-Tue-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-4-Wed-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-4-Wed-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-5-Thu-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-5-Thu-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-6-Fri-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-6-Fri-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
   helper:
     dt         18.5
     myday      1
     io:
       CULStick:
         raw        Z0E0B02020696D11234560001580025
         rssi       -62.5
         time       1608493368.22064
Attributes:
   IODev      CULMAX0
   alexaName  Büro Heizung
   alias      Altkat_Kalorifer
   event-on-change-reading .*
   externalSensor Temperatursensor_Altkat:temperature
   genericDeviceType thermostat
   icon       hc_wht_regler
   keepAuto   1
   model      HeatingThermostat
   room       Heizung
   sortby     06

Ebenfalls hab ich die routine wie im Wiki noch beschreiben, gelöscht und auch das notify.
Schein zu laufen und regaiert auch auf den externen Sensor. Allerdings steht im state (rf error). Kann ich das jetzt ignorieren, oder fehlt mir noch was?

[Wzut]

da stimmt einiges nicht :

Code Auswählen Erweitern

SVN        23290
TimeSlot   -1
externalSensor Temperatursensor_Altkat:temperature
a. 23290 : das ist nicht die Version hier aus dem Thread vom 11. Dezember
b. -1 , da wird FHEM nicht dessen interne Uhr stellen
c. da fehlt die :1 , so wird nie automatisch das fakeWT gesendet

[neyzen]

Ups Sorry, hatte ein allgemeines Update gemacht. Hab es jetzt aus diesem Tread eingefügt und hab die Version BETA_11122020.
Jetzt steht im timeslot eine 0, hab aber auser dem 10_MAX update nichts gemacht.

c. da fehlt die :1 , so wird nie automatisch das fakeWT gesendet

Wo muss ich die reinschreiben?

Code Auswählen Erweitern

Internals:
   DEF        HeatingThermostat 0696d1
   FUUID      5fdfa4e4-f33f-2b39-5391-2040d400ba770fa1
   IODev      CULMAX0
   NAME       MAX_0696d1
   NOTIFYDEV  Temperatursensor_Altkat
   NR         220
   NTFY_ORDER 50-MAX_0696d1
   STATE      18.5 (rf error)
   SVN        BETA_11122020
   TYPE       MAX
   TimeSlot   0
   addr       0696d1
   devtype    1
   type       HeatingThermostat
   READINGS:
     2020-12-20 20:24:20   PairedTo        123456
     2020-12-21 14:30:30   RSSI            -61.5
     2020-12-20 20:24:20   SerialNr        JHA0008724
     2020-12-21 14:30:30   battery         ok
     2020-12-21 14:30:30   batteryState    ok
     2020-12-21 14:30:30   desiredTemperature 18.5
     2020-12-21 14:30:30   deviation       3.8
     2020-12-20 20:24:20   error           invalid or missing value  for READING .weekProfile
     2020-12-21 19:04:42   externalTemp    21.83
     2020-12-20 20:24:20   firmware        1.6
     2020-12-21 14:30:30   gateway         1
     2020-12-20 20:24:20   groupid         0
     2020-12-21 13:05:15   lastTimeSync    2020-12-21 13:05:15
     2020-12-20 20:42:48   lastcmd         ConfigWeekProfile
     2020-12-21 14:30:30   mode            auto
     2020-12-21 13:05:15   msgcnt          13
     2020-12-21 14:30:30   panel           unlocked
     2020-12-21 14:30:30   peerIDs         000000
     2020-12-21 14:30:30   peerList        Broadcast
     2020-12-20 20:27:29   peers           111111
     2020-12-21 14:30:30   rferror         1
     2020-12-21 14:30:30   state           18.5 (rf error)
     2020-12-21 14:30:30   temperature     22.1
     2020-12-20 20:24:20   testresult      255
     2020-12-21 14:30:30   valveposition   0
     2020-12-20 20:42:48   weekprofile-0-Sat-temp 17.0 °C  /  18.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-0-Sat-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-1-Sun-temp 17.0 °C  /  18.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-1-Sun-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-2-Mon-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-2-Mon-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-3-Tue-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-3-Tue-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-4-Wed-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-4-Wed-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-5-Thu-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-5-Thu-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-6-Fri-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-6-Fri-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
Attributes:
   IODev      CULMAX0
   alexaName  Büro Heizung
   alias      Altkat_Kalorifer
   event-on-change-reading .*
   externalSensor Temperatursensor_Altkat:temperature
   genericDeviceType thermostat
   icon       hc_wht_regler
   keepAuto   1
   model      HeatingThermostat
   room       Heizung
   sortby     06

EDIT: Ach jetzt hab ich folgendes eingefügt:

Code Auswählen Erweitern

externalSensor Temperatursensor_Altkat:temperature:1

Jetzt ist der rf err im state weg

Code Auswählen Erweitern

Internals:
   CULMAX0_MSGCNT 1
   CULMAX0_TIME 2020-12-21 19:38:42
   DEF        HeatingThermostat 0696d1
   FUUID      5fdfa4e4-f33f-2b39-5391-2040d400ba770fa1
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     1
   NAME       MAX_0696d1
   NOTIFYDEV  Temperatursensor_Altkat
   NR         220
   NTFY_ORDER 50-MAX_0696d1
   STATE      18.5
   SVN        BETA_11122020
   TYPE       MAX
   TimeSlot   0
   addr       0696d1
   devtype    1
   type       HeatingThermostat
   READINGS:
     2020-12-20 20:24:20   PairedTo        123456
     2020-12-21 19:38:42   RSSI            -61
     2020-12-20 20:24:20   SerialNr        JHA0008724
     2020-12-21 19:38:42   battery         ok
     2020-12-21 19:38:42   batteryState    ok
     2020-12-21 19:38:42   desiredTemperature 18.5
     2020-12-21 19:38:42   deviation       3.3
     2020-12-20 20:24:20   error           invalid or missing value  for READING .weekProfile
     2020-12-21 19:38:41   externalTemp    21.83
     2020-12-20 20:24:20   firmware        1.6
     2020-12-21 19:38:42   gateway         1
     2020-12-20 20:24:20   groupid         0
     2020-12-21 13:05:15   lastTimeSync    2020-12-21 13:05:15
     2020-12-20 20:42:48   lastcmd         ConfigWeekProfile
     2020-12-21 19:38:42   mode            auto
     2020-12-21 19:38:41   msgcnt          14
     2020-12-21 19:38:42   panel           unlocked
     2020-12-21 19:38:42   peerIDs         000000,111111
     2020-12-21 19:38:42   peerList        Broadcast,MAX_111111
     2020-12-20 20:27:29   peers           111111
     2020-12-21 19:38:42   rferror         0
     2020-12-21 19:38:42   state           18.5
     2020-12-21 14:30:30   temperature     22.1
     2020-12-20 20:24:20   testresult      255
     2020-12-21 19:38:42   valveposition   0
     2020-12-20 20:42:48   weekprofile-0-Sat-temp 17.0 °C  /  18.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-0-Sat-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-1-Sun-temp 17.0 °C  /  18.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-1-Sun-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-2-Mon-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-2-Mon-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-3-Tue-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-3-Tue-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-4-Wed-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-4-Wed-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-5-Thu-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-5-Thu-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
     2020-12-20 20:42:48   weekprofile-6-Fri-temp 17.0 °C  /  21.5 °C  /  18.5 °C  /  17.0 °C
     2020-12-20 20:42:48   weekprofile-6-Fri-time 00:00-07:30  /  07:30-14:30  /  14:30-23:55  /  23:55-24:00
   helper:
     io:
       CULStick:
         raw        Z0E0E02020696D11111110001180025
         rssi       -61
         time       1608575922.78908
Attributes:
   IODev      CULMAX0
   alexaName  Büro Heizung
   alias      Altkat_Kalorifer
   event-on-change-reading .*
   externalSensor Temperatursensor_Altkat:temperature:1
   genericDeviceType thermostat
   icon       hc_wht_regler
   keepAuto   1
   model      HeatingThermostat
   room       Heizung
   sortby     06