Neue Beta Test Runde für alle MAX Module

Wzut · 02 Dezember 2021, 10:08:56

IMHO passen die beiden Zeilen nicht direkt zusammen, das D5 Telegramm wurde laut Log ja schon verworfen.
Zu dem Montatsfehler kann es nur bei gültigem Typ TimeSync aber fehlerhaften/zerstörtem Payload kommen - werde ich in einer der nächsten Versionen noch mit eval kapseln

dirk.k · 05 Dezember 2021, 21:17:01

zum Theme MAX-Scanner ...
ich hatte auch probiert das mit "at" nachzubauen. Funktionierte irgendwie nicht. Ich hatte auch freezes beim Erneuern des AT. Evtl. gibt es da einen Zusammenhang.
Funktionieren tut jetzt sehr gut eine Lösung mit doif

Code Auswählen

defmod di_MaxScanner DOIF ([+00:05] and [?MAX_TH_16e522:temperature:sec]>3800)    \
	(set MAX_TH_16e522 wakeUp)\
	(set MAX_TH_16e522 getStatus)\
DOELSEIF ([+00:06] and [?MAX_TH_1a9aeb:temperature:sec]>3800)    \
	(set MAX_TH_1a9aeb wakeUp)\
	(set MAX_TH_1a9aeb getStatus)\
DOELSEIF ([+00:07] and [?MAX_TH_190d84:temperature:sec]>3800)    \
	(set MAX_TH_190d84 wakeUp)\
	(set MAX_TH_190d84 getStatus)\
DOELSEIF ([+00:08] and [?MAX_TH_16e560:temperature:sec]>3800)\
	(set MAX_TH_16e560 wakeUp)\
	(set MAX_TH_16e560 getStatus)\

attr di_MaxScanner do always
attr di_MaxScanner icon helper_doif
attr di_MaxScanner wait 1,5:1,5:1,5

ob ich das wakeUp wirklich brauche, kann ich (noch) nicht sagen. ist ein Überbleibsel von den AT-versuchen.

michael.winkler · 06 Dezember 2021, 16:16:52

Mal ein kurzes Fazit zu meinen BETA Tests.

Sobald ich den AT gesetzt hatte, der alle 5 Minuten, an 9 Thermostate ein getStatus gesendet hatte. Hat es nicht lange gedauert bis einige Thermostate komische Werte bei der Temperatur angezeigt hatten. Hier wurden dann z.B. 58 Grad angezeigt. Das Aktualisieren an sich hat auch nicht wirklich funktioniert. Zum Schluss hatte an jedes Thermostat 2x einen getStatus abgesendet. Dazwischen ein sleep von 2 Sekunden. Das hat aber leider auch nicht den gewünschten Erfolg gebracht.

Aktuell bin ich wieder auf der letzten offiziellen SVN Version. Meinem MAXScanner habe ich nicht mehr aktiviert. Stattdessen läuft bei mir folgender AT

Code Auswählen


+*00:00:30 { 
	my @Maxs       = devspec2array("TYPE=MAX");
	my $DeviceAge ;
	my $DeviceTemp;
	my $DeviceModeAge;
	#fhem "set culmax.remote deleteSendQueue";
	foreach my $MaxDevice (@Maxs) {
		$DeviceAge      = ReadingsAge($MaxDevice,"temperature",0);
		$DeviceModeAge  = ReadingsAge($MaxDevice,"mode","0");
		$DeviceTemp     = ReadingsVal($MaxDevice, "desiredTemperature", "19.0");
		#fhem "setreading $MaxDevice 00_ReadingsAge $DeviceAge";
		#Log3 "watchdog",3,"CHECK MAX $MaxDevice $DeviceAge"; 
		if ($DeviceAge >= 1000) {
			if (ReadingsVal($MaxDevice, "sendmessage", "0") ne "1") {
				fhem "set teleBot message $GroupChar$MichaelID MAX Device $MaxDevice defekt";
				fhem "setreading $MaxDevice sendmessage 1";
				if ($DeviceModeAge >= 180) {
					if (ReadingsVal($MaxDevice, "mode", "unbekannt") eq "auto") {
						fhem "set $MaxDevice desiredTemperature $DeviceTemp";
					}
					else {
						fhem "set $MaxDevice desiredTemperature auto";
					}
				}
			}	
		}
		elsif ($DeviceAge >= 300) {
			if ($DeviceModeAge >= 180) {
				if (ReadingsVal($MaxDevice, "mode", "unbekannt") eq "auto") {
					fhem "set $MaxDevice desiredTemperature $DeviceTemp";
				}
				else {
					fhem "set $MaxDevice desiredTemperature auto";
				}
			}
		}
		else {
			fhem "setreading $MaxDevice sendmessage 0";
		}
		$DeviceAge  = ReadingsAge($MaxDevice,"temperature",0);
		fhem "setreading $MaxDevice 00_ReadingsAge $DeviceAge";
	}
	
	

}

Sollte sich an der BETA wieder was tun, bin ich gerne bereit wieder zu testen.

Gruß
Michael

HeikoGr · 07 Dezember 2021, 06:41:55

Die komischen Werte hatte die Tage auch 2x beobachtet. Allerdings nach unten (3 °C).

Was mir auch aufgefallen ist:
Ich musste ein neues Thermostat anlernen und wollte das weekprofile abfragen. Das hat leider nicht funktioniert.
Nachdem ich die SVN Versionen der MAX Komponenten genommen habe konnte ich das weekprofile auslesen.

schreiben muss funktioniert haben, da das Thermostat sich auf "Auto" stellen ließ und die richtige Temperatur hatte.

Ich werde versuchen dass ganze nocheinmal nachzustellen und detailiertere Informationen liefern.

west2107 · 16 Dezember 2021, 21:10:07

Das Problem mit komischen Temperaturen habe ich an einem HT. Er hat die Firmwareversion 1.8 laut Readings.
Ein zweiter HT - identische Konfiguration hat das Problem nicht.
Bei ihm wird in den Readings die Firmwareverson nicht angezeigt, wahrscheinlich eine andere.

Wird die Stausabfrage per AT am ersten HT nicht gemacht, sind die Temperatur-Werte normal. Ich denke da weht der Wind her.

Wzut · 17 Dezember 2021, 08:51:36

"komische Werte" würde ich ja gerne abfangen, aber :
a. habe ich sie selber nicht
b. scheint mal wieder niemand in der Lage zu sein ein simples verbose 5 Log zu liefern damit ich es mal nachvollziehen kann.

Manley · 09 Februar 2022, 05:28:29

Hi.
Ich habe zwei umgebaute CUBEs im Einsatz.
Immer wenn ich einen Befehl absetze und dabei das IODev geswitcht werden muss, kommt er nicht durch. Setze ich ihn ein zweites Mal geht es sofort.

Code Auswählen

2022.02.09 04:54:16 4: cm, send -> cmd:SetTemperature, msgcnt:1f, flags:00, Cmd2id:40, src:MAX_123456 , dst:MAX_1c0792 , gid:00 , payload:52 , cul:CULSZ
2022.02.09 04:54:16 5: cm, send packet: 0b1f00401234561c07920052
2022.02.09 04:54:16 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:16 4: cm, Send Queue packet to MAX_1c0792 needs CULSZ but current IODev is CUL0
2022.02.09 04:54:16 4: cm, Send Queue IODev switched to CULSZ with version 154
2022.02.09 04:54:17 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 3000, CULSZ CMD_LAST_H: 12
2022.02.09 04:54:17 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:17 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:18 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:18 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:19 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:19 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:20 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:20 4: cm, Send Queue retry MAX_1c0792 for SetTemperature count: 3
2022.02.09 04:54:23 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:23 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 2897, CULSZ CMD_LAST_H: 13
2022.02.09 04:54:23 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:24 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:24 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:25 5: cm, IODev CUL0, len 15, msgcnt BA, msgflag 04, msgType WallThermostatState, src 1a54cd, dst 000000, group 0, payload 19042400C7, rssi -75.5
2022.02.09 04:54:25 5: cm: dispatch MAX,0,WallThermostatState,1a54cd,19042400C7
2022.02.09 04:54:25 5: MAX_Parse, MAX,0,WallThermostatState,1a54cd,19042400C7
2022.02.09 04:54:25 5: MAX_1a54cd, bat 0, rferror 0, panel 0, langateway 1, dst 1, mode 1, displayActualTemperature 4
2022.02.09 04:54:25 5: MAX_1a54cd, desiredTemperature 18
2022.02.09 04:54:25 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:25 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:26 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:26 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:26 4: cm, Send Queue retry MAX_1c0792 for SetTemperature count: 2
2022.02.09 04:54:30 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:30 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 2794, CULSZ CMD_LAST_H: 14
2022.02.09 04:54:30 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:31 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:31 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:32 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:32 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:33 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:33 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:33 4: cm, Send Queue retry MAX_1c0792 for SetTemperature count: 1
2022.02.09 04:54:36 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:36 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 2691, CULSZ CMD_LAST_H: 15
2022.02.09 04:54:36 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:37 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:38 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:38 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:39 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:39 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:40 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:40 3: cm, Send Queue missing ack from MAX_1c0792 for SetTemperature, removing from queue
2022.02.09 04:54:40 5: cm, Send Queue is now empty

Dabei ist es egal, ob von CUL0 oder von CULSZ geswitcht werden muss.
Ich muss noch erwähnen, das der CULSZ über VPN angebunden ist. Also sind da die Latenzen etwas höher.
Vielleicht habt ihr ja nen Tipp, oder nen Schubs in die richtige Richtung.

Code Auswählen

Internals:
   CUL0_MAXID 123456
   CUL0_MSGCNT 3647
   CUL0_RAWMSG Z0B8306301A09A61234560010
   CUL0_RSSI  -65.5
   CUL0_TIME  2022-02-09 05:13:13
   CUL0_VERSION 154
   CULSZ_MAXID 234567
   CULSZ_MSGCNT 615
   CULSZ_RAWMSG Z0E3402021A8BDF1C07920001190010
   CULSZ_RSSI -55
   CULSZ_TIME 2022-02-09 05:12:09
   CULSZ_VERSION 154
   DEF        123456
   FUUID      5c44b228-f33f-9a7c-4b3b-a38737fcfd94412c
   FVERSION   14_CUL_MAX.pm:0.221750/2020-06-13
   IODev      CULSZ
   IOgrp      CUL0,CULSZ
   LASTInputDev CUL0
   MSGCNT     4262
   NAME       cm
   NR         78
   STATE      CULSZ:ok,CUL0:ok Last:CUL0
   SVN        22175
   TYPE       CUL_MAX
   addr       234567
   cnt        0
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2022-02-09 05:03:51   CUL0_cmd_last_h 31
     2022-02-09 05:03:51   CUL0_credit10ms 1138
     2022-02-09 05:03:14   CUL0_lost       5
     2022-02-09 05:03:08   CUL0_retry      16
     2022-02-09 05:04:53   CULSZ_cmd_last_h 22
     2022-02-09 05:04:53   CULSZ_credit10ms 2103
     2022-02-09 05:04:22   CULSZ_lost      5
     2022-02-09 05:04:15   CULSZ_retry     15
     2022-02-09 05:03:59   IODev           CULSZ
     2022-02-09 05:02:52   lastTimeSync    MAX_0e7611
     2022-02-09 05:13:13   state           CULSZ:ok,CUL0:ok Last:CUL0
   sendQueue:
Attributes:
   IOgrp      CUL0, CULSZ
   alias      cm
   debug      1
   fakeSCaddr 222222
   fakeWTaddr 111111
   group      Netzwerk
   room       2.4_Netzwerk
   showtime   0
   verbose    3

Code Auswählen

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz*
   CUL0_MSGCNT 5913
   CUL0_TIME  2022-02-09 05:25:54
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.1.29:2323 1234
   DeviceName 192.168.1.29:2323
   FD         15
   FHTID      1234
   FUUID      5c44b228-f33f-9a7c-f087-2ee0161588f64815
   FVERSION   00_CUL.pm:0.248150/2021-08-01
   NAME       CUL0
   NR         77
   NR_CMD_LAST_H 32
   PARTIAL    
   RAWMSG     *s4408A0FF10E6;  464: 8944
   RSSI       -63
   STACKED    CUL1
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBEx4_83 (F-Band: 868MHz)
   devioNoSTATE 1
   initString X21
Zr
Za123456
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2022-02-08 15:02:08   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
     2022-02-09 05:03:51   credit10ms      1138
     2022-02-09 05:25:54   state           Initialized
   XMIT_TIME:
     1644378481.17689
     1644378487.23443
     1644378493.76236
     1644378500.27874
     1644378516.0607
     1644378523.20662
     1644378718.05272
     1644378724.5835
     1644378731.14404
     1644378737.66231
     1644378760.98414
     1644378769.18974
     1644378775.70119
     1644378788.58223
     1644378828.84168
     1644378835.35139
     1644378841.86569
     1644378848.40157
     1644378892.93436
     1644378899.44367
     1644378905.96179
     1644378912.47768
     1644378924.85317
     1644378932.81879
     1644379143.77931
     1644379151.70103
     1644379372.68941
     1644379379.23086
     1644379385.74298
     1644379391.80209
     1644379399.92632
     1644379432.00834
Attributes:
   alias      CUL0
   group      Netzwerk
   maxid      123456
   rfmode     MAX
   room       2.4_Netzwerk

Code Auswählen

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   CULSZ_MSGCNT 625
   CULSZ_TIME 2022-02-09 05:26:31
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.2.115:2323 1034
   DeviceName 192.168.2.115:2323
   FD         28
   FHTID      1034
   FUUID      6162d424-f33f-9a7c-72d3-2b3596175256a614
   FVERSION   00_CUL.pm:0.248150/2021-08-01
   NAME       CULSZ
   NR         168
   NR_CMD_LAST_H 23
   PARTIAL    
   RAWMSG     Z0E3902021A8BDF1C0792000119001025
   RSSI       -55.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
   devioNoSTATE 1
   initString X21
Zr
Za234567
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2022-02-08 15:02:13   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2022-02-09 05:04:53   credit10ms      2103
     2022-02-09 05:26:31   state           Initialized
   XMIT_TIME:
     1644378581.35121
     1644378587.87557
     1644378594.36497
     1644378600.89858
     1644378796.21791
     1644378802.74057
     1644378809.27375
     1644378815.8118
     1644378857.04816
     1644378863.55996
     1644378870.07037
     1644378876.59416
     1644379288.64864
     1644379295.17716
     1644379301.68916
     1644379308.1929
     1644379370.57035
     1644379439.23922
     1644379445.76903
     1644379452.25892
     1644379458.77183
     1644379489.48913
     1644379493.42967
Attributes:
   group      Netzwerk
   maxid      234567
   rfmode     MAX
   room       2.4_Netzwerk

MfG Manley

Nachtrag:
Mir ist gerade aufgefallen, dass das Paket als Absender den 123456 ( CUL0 ) enthält. Danach erst festgestellt wird, dass das andere IODev (2345467) benutzt werden muss, das Paket aber weiterhin die ID vom CUL0 behält. Klar dass das Ziel dann nicht auf den Befehl reagiert.
Es wird als Absendere immer die ID des zuletzt verwendeten CULs benutzt. Die Überprüfung auf das nötige IODev müsste also erfolgen, bevor das Paket erstellt wird.
Wäre es ein Problem, wenn die Beiden CULs die selbe ID haben? Kann ich frühestens am Freitag testen, da sie räumlich knapp 100km auseinander sind

Hier nochmal ein Auszug wo CULSZ vorher benutzt wurde und er auf CUL0 switcht. (Paket enhält den Absender 234567 und müsste 123456)

Code Auswählen

2022.02.09 09:24:38 4: cm, send -> cmd:SetTemperature, msgcnt:3b, flags:00, Cmd2id:40, src:MAX_234567 , dst:MAX_19cd91 , gid:00 , payload:6c , cul:CUL0
2022.02.09 09:24:38 5: cm, send packet: 0b3b004023456719cd91006c
2022.02.09 09:24:38 5: cm, Send Queue 1 packet in queue
2022.02.09 09:24:38 4: cm, Send Queue packet to MAX_19cd91 needs CUL0 but current IODev is CULSZ
2022.02.09 09:24:38 4: cm, Send Queue IODev switched to CUL0 with version 154
2022.02.09 09:24:38 5: cm, Send Queue CUL0 -> needPreamble: 1, necessaryCredit: 110, credit10ms: 3600, CUL0 CMD_LAST_H: 3
2022.02.09 09:24:38 4: cm, Send Queue packet send : Zs0b3b004023456719cd91006c to MAX_19cd91 with CUL0

MfG Manley

Wzut · 09 Februar 2022, 10:14:57

Zitat von: Manley am 09 Februar 2022, 05:28:29
Wäre es ein Problem, wenn die Beiden CULs die selbe ID haben? Kann ich frühestens am Freitag testen, da sie räumlich knapp 100km auseinander sind

Gleiche ID ist eigentlich der Normalfall ! Zwei verschiedene MAX Wolken unter einer FHEM Instanz schafft nur unötige Probleme und daher habe ich recht schnell jede Unterstützung dafür nicht weiterverfolgt.
Allerdings verstehe ich dein Umfeld mit den 100km gerade überhaupt nicht, wie sollen da die zwei CULs eine sinnvolle Gruppe bilden ?

Manley · 09 Februar 2022, 11:23:35

Der zweite CUL(SZ) steht in meinem Zweitwohnsitz. Ich dachte, dass eine unterschiedliche ID besser wäre für eine deutliche Unterscheidung der Systeme.
Die CULs sollen also gar keine Gruppe bilden

Wzut · 09 Februar 2022, 12:20:02

ah ok verstehe. Allerdings hast du dann genau das Umfeld das nicht unterstützt wird.
Mögliche Lösungen :
a. gleiche ID verwenden - Nachteil : aufwändig da in einer der beiden Wolken bei allen Geräten ein Werkreset fällig ist.
b. eine zweite FHEM Instanz auf einem anderen Port anlegen und die Zweitwohnung komplett damit verwalten - Vorteil : ist schnell gemacht.

Manley · 09 Februar 2022, 14:01:22

Verstehe.
Da ich am Freitag eh in der anderen Wohnung bin und die Anzahl an Geräten überschaubar ist, werde ich alles auf eine ID setzen.
Eine Zweite Instanz nur für die Paar Maxgeräte ist mir tatsächlich den Aufwand nicht wert. Vor allem hab ich dann nicht alles zusammen.
Danke für die schnelle Hilfe.

MfG Manley

P.s.: vielleicht im HowTo kurz erwähnen, dass beide CULs die gleiche ID haben müssen

dirk.k · 19 Februar 2022, 21:09:26

Hallo,
habe mit den neuen Modulen ein kleines Problem.
Nachdem wieder mal ein einzelnes MAX-Gerät ausgestiegen ist, habe ich es auf "dummy=1" und "disabled=1" gestellt.
Trotzdem landeten weiterhin Daten für dieses Gerät in der sendQueue.
Verursacht wird das vom selbstgebastelten Scanner:
doif...
(set MAX_TH_16e522 wakeUp)
(set MAX_TH_16e522 getStatus)
Ich dachte, bei gesetzten "dummy"-Attribut werden die Sendeanforderungen einfach verworfen.!?
Wo liegt mein Fehler?

scooty · 27 Februar 2022, 16:55:24

Hallo Wzut,

zwei Dinge, die mir bisher nicht aufgefallen waren:
1) In meiner Installation funktioniert die "Boost"-Funktion an Thermostaten des type=HeatingThermostat (auch unabhängig von der Firmware Version) nicht:
Ein

Code Auswählen

set MaxThermostat desiredTemperature boost
führt nicht zur Einschaltung des Boost-Modus am Ventil.
Normalerweise daran erkennbar, dass das Reading "mode" auf "boost" geht, das Ventil voll geöffnet wird (wegen boostValveposition=100) und im Display des Thermostats die verbleibende Zeit (von boostDuration) in Minuten und später in Sekunden angezeigt wird.
Ein Ventil im mode=auto verbleibt im "auto"-Modus, Ventile im mode=eco verbleiben im "eco"-Modus, an allen Thermostaten trotz des angezeigten Readings "lastcmd=desiredTemperature boost" leider keinerlei Reaktion.
Mit Thermostaten des type=HeatingThermostatPlus funktioniert die Boost-Funktion vollumfänglich.
Auch scheint es unabhängig vom aktuell CULdev zu sein, habe zwei MaxCube und einen CUL als IOs für MAX im Einsatz.

2) Das Reading "firmware" ist leider nicht bei allen Thermostaten (unabhängig davon ob HeatingThermostat oder HeatingThermostatPlus) vorhanden. Gibt es einen Trick, dieses für alle zu bekommen?

Bitte ach kurze Info, wenn ich weitere Details/Logs liefern sollte.

Vielen Dank und Grüße,
Andreas

Wzut · 28 Februar 2022, 16:35:28

1.) klappt bei mir ohne Probleme mit einem normalen HT (ich besitze keine Plus)
hier ein verbose 5 Log :

Code Auswählen

2022.02.28 16:17:29 4: 2_HT_Esszimmer, _handle_SetTemperature: boost
2022.02.28 16:17:29 5: 2_HT_Esszimmer, SetTemperature: val : boost, gid : 00, pl : c0, flags : 00
2022.02.28 16:17:30 5: 2_HT_Esszimmer, msgtype Ack : 011B502A
2022.02.28 16:17:30 5: 2_HT_Esszimmer, msgtype ThermostatState : 1B502A
2022.02.28 16:17:30 5: 2_HT_Esszimmer, desiredTemperature:21, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:80
2022.02.28 16:17:30 4: 2_HT_Esszimmer, desiredTemperature:21.0, rssi:-59.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:17:30 5: 2_HT_Esszimmer, msgtype AckSetTemperature : boost

sicher das du auch die letzte Version hast ?
Bzw was sagt denn bei dir ein verbose 5 Log ?

2.) firmware ist ein Wert den ich nicht direkt auslesen kann, der Wert wird aber bei jedem Pair-Ping übertragen.
D.h. wenn er verloren gegangen ist (Thema Backup !!) einfach die boost Taste am HT etwas länger drücken (Pairing) dann sollte der fehlende Wert im Reading stehen.

scooty · 28 Februar 2022, 17:13:10

Hallo Wzut,

danke erst einmal für die prompte Rückmeldung.

Nach weiteren Forschungen:
Das unterschiedliche Verhalten scheint nicht am Unterschied HeatingThermostat/HeatingThermostatPlus sondern am gesetzten Attribut "keepAuto=1".
Mit Attribut "keepAuto=1" funktioniert (auch bei HeatingThermostatPlus) kein

Code Auswählen

set MaxThermostat desiredTemperature boost
Mit Attribut "keepAuto=0" funktioniert es wie oben beschrieben.

Zumindest ich hätte jetzt nicht erwartet, dass dieses Attribut (auch) eine Auswirkung darauf hat ob "boost" funktioniert oder nicht.
"keepAuto=1" finde ich eigentlich ziemlich sinnvoll, um das Wochenprogramm als "führend" zu behalten.
Oder gibt es eine andere Art das Wochenprogramm als "führend" zu behalten und "boosten" zu ermöglichen?
Ein "manuelles"

Code Auswählen

attr MaxThermostat keepAuto 0
set MaxThermostat desiredTemperature boost
<Warte bis boostDuration vorbei>
attr MaxThermostat keepAuto 1

würde ich gerne vermeiden.

Hier verbose 5 Log mit "keepAuto=1" (es wird keine Boost-Funktion am HT ausgelöst):

Code Auswählen

2022.02.28 16:51:11.256 4: WZOG_MT, _handle_SetTemperature: boost
2022.02.28 16:51:11.256 5: WZOG_MT, SetTemperature: keepAuto and mode auto = staying in auto mode
2022.02.28 16:51:11.326 5: WZOG_MT, SetTemperature: val : boost, gid : 17, pl : 00, flags : 04
2022.02.28 16:51:12.435 5: WZOG_MT, msgtype Ack : 01181228
2022.02.28 16:51:12.435 5: WZOG_MT, msgtype ThermostatState : 181228
2022.02.28 16:51:12.436 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:18
2022.02.28 16:51:12.437 4: WZOG_MT, desiredTemperature:20.0, rssi:-59.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2022.02.28 16:51:12.616 5: WZOG_MT, msgtype Ack : 01181228
2022.02.28 16:51:12.616 5: WZOG_MT, msgtype ThermostatState : 181228
2022.02.28 16:51:12.616 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:18
2022.02.28 16:51:12.617 4: WZOG_MT, desiredTemperature:20.0, rssi:-46.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2022.02.28 16:51:12.838 5: WZOG_MT, msgtype AckSetTemperature : boost

Hier verbose 5 Log mit "keepAuto=0" (es wird Boost-Funktion am HT ausgelöst):

Code Auswählen

022.02.28 16:52:57.702 4: WZOG_MT, _handle_SetTemperature: boost
2022.02.28 16:52:57.773 5: WZOG_MT, SetTemperature: val : boost, gid : 17, pl : c0, flags : 04
2022.02.28 16:52:58.888 5: WZOG_MT, msgtype Ack : 011B6428
2022.02.28 16:52:58.888 5: WZOG_MT, msgtype ThermostatState : 1B6428
2022.02.28 16:52:58.888 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:100
2022.02.28 16:52:58.889 4: WZOG_MT, desiredTemperature:20.0, rssi:-60.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:52:59.061 5: WZOG_MT, msgtype Ack : 011B6428
2022.02.28 16:52:59.061 5: WZOG_MT, msgtype ThermostatState : 1B6428
2022.02.28 16:52:59.061 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:100
2022.02.28 16:52:59.062 4: WZOG_MT, desiredTemperature:20.0, rssi:-46.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:52:59.237 5: WZOG_MT, msgtype Ack : 011B6428
2022.02.28 16:52:59.238 5: WZOG_MT, msgtype ThermostatState : 1B6428
2022.02.28 16:52:59.238 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:100
2022.02.28 16:52:59.239 4: WZOG_MT, desiredTemperature:20.0, rssi:-96.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:52:59.404 5: WZOG_MT, msgtype AckSetTemperature : boost

2) Alles klar, danke für den Tipp zur Auslösung des Pair-Pings als eine Möglichkeit Readings wieder zu bekommen.

Viele Grüße,
Andreas