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.