Autor Thema: Batteriewechsel bei HT  (Gelesen 868 mal)

Offline r-m-w

  • New Member
  • *
  • Beiträge: 16
Batteriewechsel bei HT
« am: 30 September 2018, 18:19:33 »
Hallo zusammen,

es steht mal wieder ein Batteriewechsel an einem meiner 5  MAX Heizthermostaten an.
Der letzte vor ca 2 Jahren war der blanke Horror ... >:(
... am Ende musste ich alle resetten (incl. des WT) und x-mal neu in FHEM ab- / anlernen...

Wie sollte die Prozedur am einfachsten durchgeführt werden ...
möglichst ohne rf-errors und credit-errors  ?
Muss ich das Teil erst in FHEM entfernen (und überall 'deassoziate' durchführen)  ?
oder hilft es FHEM herunterzufahren ... ?

Im Voraus mal Danke für eure Hilfe.
Gruß
Ralf

Offline kleineslichtHH

  • Full Member
  • ***
  • Beiträge: 109
Antw:Batteriewechsel bei HT
« Antwort #1 am: 30 September 2018, 19:57:29 »
Batterie raus, neue Batterien rein, Adaptionsfahrt durchführen lassen...fertig

bisher gab es bei mir an diversen Thermostaten keinerlei Probleme beim Wechsel der Batterien

Offline rubbertail

  • Full Member
  • ***
  • Beiträge: 466
Antw:Batteriewechsel bei HT
« Antwort #2 am: 30 September 2018, 22:01:18 »
Kann mich dem Vorredner anschließen. Hier hats immer so geklappt.
FHEM 5.7 auf Raspi mit Debian Jessie, CUL433, CUL868, RFXTRX433e, CULCuBE
MAX!: WT, HT, Fensterkontakte
netatmo: Wetterstation & Thermostat
FRITZ: Fritzbox7490, FritzDECT200, FritzPL543
Milights, IT, Withings

Offline DefanC

  • New Member
  • *
  • Beiträge: 22
  • Oooh mein FHEM !!
Antw:Batteriewechsel bei HT
« Antwort #3 am: 06 Oktober 2018, 18:29:43 »
Hallo r-m-w,
ich habe einige MAX! Geräte im Einsatz (Hk-Thermostate, Wandthermostate,...). Der Batteriewechsel verursachte bei mir noch keine Probleme. Nach dem Schema: Batterien raus, ca. >= 60s warten, neue Batterien rein, Adaptierfahrt auslösen ... usw., wie in der Bedienungsanleitung angegeben und alles wieder gut. Dann habe ich mir mit "setreading <device> Batteriewechsel 1" über die FHEM-Kommandozeile ein Reading über den durchgeführten Batteriewechsel angelegt. So habe ich einen Überblick, wann der letzte Batt.wechsel war und wie lange die Batterien schon halten. Ich hoffe ich konnte dir damit helfen.
mfG

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 4383
  • NIVEAu ist keine Creme...
Antw:Batteriewechsel bei HT
« Antwort #4 am: 06 Oktober 2018, 18:44:07 »
Dann habe ich mir mit "setreading <device> Batteriewechsel 1" über die FHEM-Kommandozeile ein Reading über den durchgeführten Batteriewechsel angelegt. So habe ich einen Überblick, wann der letzte Batt.wechsel war und wie lange die Batterien schon halten.

Das habe ich automatisiert (für HomeMatic, Zwave, EnOcean und Xiaomi)...
...und gibt's mitlerweile als fast-Modul: https://forum.fhem.de/index.php/topic,82637.msg747514.html#msg747514

Gruß, Joachim
FHEM 5.8 PI3: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf, ...
FHEM 5.8 PI2: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM 5.8 PI3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline r-m-w

  • New Member
  • *
  • Beiträge: 16
Antw:Batteriewechsel bei HT
« Antwort #5 am: 06 Oktober 2018, 19:25:52 »
Hallo zusammen,

vielen Dank für die Antworten.
Mittlerweile hab ich die Batterien gewechselt...
Seitdem (seit 3 Tagen..) meldet der HT einen 'rf error'  :(
wobei sonst alles wie erwartet funktioniert (programmiertes Wochenprogramm,
Verknüpfungen mit Wandthermostat und den anderen HT, etc.)
Nur eben der 'rf error' scheint nicht wegzugehen.

Gibt es da eine einfache Lösung?

Gruß
Ralf

Offline DefanC

  • New Member
  • *
  • Beiträge: 22
  • Oooh mein FHEM !!
Antw:Batteriewechsel bei HT
« Antwort #6 am: 07 Oktober 2018, 12:26:39 »
Hallo r-m-w,
<rf-error> waren bei mir bis jetzt nur dann, wenn das Funkprotokoll "unsauber/unvollständig" übertragen wurde. Das kam vor, wenn die Reichweite überschritten war oder die Batterien müde wurde oder der Cube keine korrekte Verbindung zum Gerät hatte. Dies kam häufiger bei Fensterkontakten vor.
Prüf mal deine Batterien.... vllt. sind die nicht mehr ganz taufrisch.
Und ein reboot FHEM ist allemal nicht falsch.

Offline r-m-w

  • New Member
  • *
  • Beiträge: 16
Antw:Batteriewechsel bei HT
« Antwort #7 am: 07 Oktober 2018, 20:16:28 »
@DefanC

hab mir den 'rf error' ja beim Batteriewechsel am HT gefangen...
Hab auch schon einen 'warm-start' von FHEM gemacht (re-read config)
... hat aber auch nicht geholfen.

Offline DefanC

  • New Member
  • *
  • Beiträge: 22
  • Oooh mein FHEM !!
Antw:Batteriewechsel bei HT
« Antwort #8 am: 08 Oktober 2018, 20:13:04 »
Hallo Ralf,
du sagst also das der bewußte HT mit allen anderen Komponenten zusammenspielt. Hab ich das richtig verstanden?
Wie steuerst du denn eigentlich die Heizung? Über Cube oder per FHEM? Hast du ein CUL oder einen Cube oder einen umgeflashten Cube?
Du könntest auch mal ein "list <device>" von dem bewußten HT in FHEM ausführen und das dann hier posten.
Ich häng dir mal ein list von einem meiner HT hier an. Ich steuere meine Heizung per Cube und lese in FHEM die Werte nur per Cube -> CULMAX0 mit und verarbeite die Daten dann weiter.
Hier mein "list <device>" :
Internals:
   .lastTimeMAXLAN_error 1539015964.59403
   .lastTimeMAXLAN_errorInCommand 1539015964.59403
   .lastTimeMAXLAN_initialized 1539015964.59403
   .lastTimeMAXLAN_isAnswer 1539015964.59403
   .lastTimeMAXLAN_valid 1539015964.59403
   .lastTimeRSSI 1539021136.32586
   .lastTimebattery 1539015964.58592
   .lastTimebatteryState 1539015964.58592
   .lastTimeboostDuration 1539015964.27645
   .lastTimeboostValveposition 1539015964.27645
   .lastTimecomfortTemperature 1539015964.27645
   .lastTimedecalcification 1539015964.27645
   .lastTimedesiredTemperature 1539021136.32586
   .lastTimeecoTemperature 1539015964.27645
   .lastTimefirmware 1539015964.27026
   .lastTimegroupid 1539015964.2644
   .lastTimemaxValveSetting 1539015964.27645
   .lastTimemaximumTemperature 1539015964.27645
   .lastTimemeasurementOffset 1539015964.27645
   .lastTimeminimumTemperature 1539015964.27645
   .lastTimemode 1539015964.58592
   .lastTimestate 1539013194.46301
   .lastTimetemperature 1539013264.13141
   .lastTimetestresult 1539015964.27026
   .lastTimevalveOffset 1539015964.27645
   .lastTimevalveposition 1539021136.32586
   .lastTimeweekprofile-0-Sat-temp 1539015964.27645
   .lastTimeweekprofile-0-Sat-time 1539015964.27645
   .lastTimeweekprofile-1-Sun-temp 1539015964.27645
   .lastTimeweekprofile-1-Sun-time 1539015964.27645
   .lastTimeweekprofile-2-Mon-temp 1539015964.27645
   .lastTimeweekprofile-2-Mon-time 1539015964.27645
   .lastTimeweekprofile-3-Tue-temp 1539015964.27645
   .lastTimeweekprofile-3-Tue-time 1539015964.27645
   .lastTimeweekprofile-4-Wed-temp 1539015964.27645
   .lastTimeweekprofile-4-Wed-time 1539015964.27645
   .lastTimeweekprofile-5-Thu-temp 1539015964.27645
   .lastTimeweekprofile-5-Thu-time 1539015964.27645
   .lastTimeweekprofile-6-Fri-temp 1539015964.27645
   .lastTimeweekprofile-6-Fri-time 1539015964.27645
   .lastTimewindowOpenDuration 1539015964.27645
   .lastTimewindowOpenTemperature 1539015964.27645
   CULMAX0_MSGCNT 544
   CULMAX0_TIME 2018-10-08 19:52:16
   Cube_MSGCNT 104
   Cube_TIME  2018-10-08 19:26:05
   DEF        HeatingThermostat ?xxxxxx?    #uninteressant
   IODev      Cube
   LASTInputDev CULMAX0
   MSGCNT     648
   NAME       Bad_HkThermostat
   NR         45
   RSSI       -77.5
   STATE      Soll: 19.0 °C &nbsp Ist: 20.0 °C &nbsp VentPos: 0 %
   TYPE       MAX
   addr       ?xxxxxx?   #uninteressant
   backend    Cube
   dstsetting 1
   mode       0
   rferror    0
   serial     ?xxxxxxxxxx?  #uninteressant
   type       HeatingThermostat
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     valveposition:300
     RSSI:300
     temperature:300
     desiredTemperature:300
     .*:43200
   READINGS:
     2018-10-08 19:26:05   .weekProfile    48604cfc4920492049204920492045204520452045204520452048604cfc4920492049204920492045204520452045204520452048304c3f48cc4cfc49204920492045204520452045204520452048304c3f48cc4cfc49204920492045204520452045204520452048304c3f48cc4cfc49204920492045204520452045204520452048304c3f48cc4cfc49204920492045204520452045204520452048304c3f48cc4cfc492049204920452045204520452045204520
     2018-04-01 16:44:41   Batteriewechsel 1
     2018-10-08 19:26:05   MAXLAN_error    0
     2018-10-08 19:26:05   MAXLAN_errorInCommand
     2018-10-08 19:26:05   MAXLAN_initialized 1
     2018-10-08 19:26:05   MAXLAN_isAnswer 0
     2018-10-08 19:26:05   MAXLAN_valid    1
     2018-10-08 19:52:16   RSSI            -77.5
     2018-10-08 19:52:16   battery         ok
     2018-10-08 19:52:16   batteryState    ok
     2018-10-08 19:26:05   boostDuration   5
     2018-10-08 19:26:05   boostValveposition 80
     2018-10-08 19:26:05   comfortTemperature 19.0
     2018-10-08 19:26:05   decalcification Sat 12:00
     2018-10-08 19:52:16   desiredTemperature 19.0
     2018-10-08 19:26:05   ecoTemperature  18.0
     2018-10-08 19:26:05   firmware        1.6
     2018-10-08 19:26:05   groupid         3
     2018-10-08 19:26:05   maxValveSetting 100
     2018-10-08 19:26:05   maximumTemperature on
     2018-10-08 19:26:05   measurementOffset 0.0
     2018-10-08 19:26:05   minimumTemperature off
     2018-10-08 19:52:16   mode            auto
     2018-10-08 19:52:16   state           19.0 °C
     2018-10-08 17:41:04   temperature     20.0
     2018-10-08 19:26:05   testresult      255
     2018-10-08 19:26:05   valveOffset     0
     2018-10-08 19:52:16   valveposition   0
     2018-10-08 19:26:05   weekprofile-0-Sat-temp 18.0 °C  /  19.0 °C  /  18.0 °C
     2018-10-08 19:26:05   weekprofile-0-Sat-time 00:00-08:00  /  08:00-21:00  /  21:00-00:00
     2018-10-08 19:26:05   weekprofile-1-Sun-temp 18.0 °C  /  19.0 °C  /  18.0 °C
     2018-10-08 19:26:05   weekprofile-1-Sun-time 00:00-08:00  /  08:00-21:00  /  21:00-00:00
     2018-10-08 19:26:05   weekprofile-2-Mon-temp 18.0 °C  /  19.0 °C  /  18.0 °C  /  19.0 °C  /  18.0 °C
     2018-10-08 19:26:05   weekprofile-2-Mon-time 00:00-04:00  /  04:00-05:15  /  05:15-17:00  /  17:00-21:00  /  21:00-00:00
     2018-10-08 19:26:05   weekprofile-3-Tue-temp 18.0 °C  /  19.0 °C  /  18.0 °C  /  19.0 °C  /  18.0 °C
     2018-10-08 19:26:05   weekprofile-3-Tue-time 00:00-04:00  /  04:00-05:15  /  05:15-17:00  /  17:00-21:00  /  21:00-00:00
     2018-10-08 19:26:05   weekprofile-4-Wed-temp 18.0 °C  /  19.0 °C  /  18.0 °C  /  19.0 °C  /  18.0 °C
     2018-10-08 19:26:05   weekprofile-4-Wed-time 00:00-04:00  /  04:00-05:15  /  05:15-17:00  /  17:00-21:00  /  21:00-00:00
     2018-10-08 19:26:05   weekprofile-5-Thu-temp 18.0 °C  /  19.0 °C  /  18.0 °C  /  19.0 °C  /  18.0 °C
     2018-10-08 19:26:05   weekprofile-5-Thu-time 00:00-04:00  /  04:00-05:15  /  05:15-17:00  /  17:00-21:00  /  21:00-00:00
     2018-10-08 19:26:05   weekprofile-6-Fri-temp 18.0 °C  /  19.0 °C  /  18.0 °C  /  19.0 °C  /  18.0 °C
     2018-10-08 19:26:05   weekprofile-6-Fri-time 00:00-04:00  /  04:00-05:15  /  05:15-17:00  /  17:00-21:00  /  21:00-00:00
     2018-10-08 19:26:05   windowOpenDuration 15
     2018-10-08 19:26:05   windowOpenTemperature 5.0
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      Cube
   devStateStyle style=text-align:right;;font-weight:normal;;color:#e04908;;
   event-min-interval valveposition:300,RSSI:300,temperature:300,desiredTemperature:300,.*:43200
   event-on-change-reading .*
   fp_Grundriss 570,886,0,Bad_HkThermostat,
   room       Bad,Heizung
   stateFormat Soll: desiredTemperature °C &nbsp Ist: temperature °C &nbsp VentPos: valveposition %

Wenn du so nett wärest und auch ein  "list <device>" von dem bewußten HT anhängst, könnte ich vll. mehr sehen.
Wie sieht es mit der Aktualität deines FHEM aus? Letztes update wann? Letzter fhem "shutdown+restart" ?
Ich meine nicht das es ausschließlich an einem reboot liegt, möchte aber der Reihe nach ausschließen.
<rf error> ist ein Problem mit der Funkübertragung, ich weiß.
Und wie sieht es mit den Batterien aus, die du erneuert hast? Sind die i.O.? (>=1,5 Volt?)
mfG Stefan

Offline r-m-w

  • New Member
  • *
  • Beiträge: 16
Antw:Batteriewechsel bei HT
« Antwort #9 am: 11 Oktober 2018, 21:21:46 »
Hallo Stefan,
also der HT ist mit drei weiteren im Wohnzimmer 'assoziiert', sowie mit einem Wandthermostat.
Über FHEM höre ich einfach nur mit (bzw. stelle machmal auch eine Temp. ein...).
An FHEM hängt ein CUL (CUL_MAX Protokoll).

list >device> sieht so aus
Internals:
   DEF        HeatingThermostatPlus 1356b9
   IODev      cm
   LASTInputDev cm
   MSGCNT     843
   NAME       HT_Wohnzimmer_Mitte
   NR         45
   RSSI       -78
   STATE      21.0 °C (rf error)
   TYPE       MAX
   addr       1356b9
   backend    cm
   cm_MSGCNT  843
   cm_TIME    2018-10-11 20:51:39
   dstsetting 1
   mode       0
   rferror    1
   type       HeatingThermostatPlus
   READINGS:
     2018-10-11 20:51:39   RSSI            -78
     2018-05-10 14:17:50   TimeInformationHour 1
     2018-10-11 20:51:39   battery         ok
     2018-10-11 20:51:39   desiredTemperature 21.0
     2018-10-04 11:15:05   firmware        1.0
     2018-10-04 11:15:05   groupid         0
     2018-10-11 20:51:39   mode            auto
     2018-10-11 20:15:15   msgcnt          141
     2018-10-11 20:51:39   state           21.0 °C (rf error)
     2018-10-11 17:00:05   temperature     22.1
     2018-10-04 11:15:05   testresult      0
     2018-10-11 20:51:39   valveposition   0
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      cm
   icon       hc_wht_regler
   keepAuto   1
   room       Wohnzimmer

Der <rf error> geht ja eigentlich vom HT aus ... der blinkt ja auch.
Wie krieg ich den wieder 'beruhigt' ?
Wie eingangs erwähnt hab ich in der Vergangenheit bei einem Batteriewechsel den betreffenden
HT immer erst komplett von allen anderen (inkl. WT) 'deassoziiert', von FHEM gelöscht, ...
Batterien gewechselt, anschließend wieder in FHEM angelernt und wieder mit allen 'assoziiert' ...
Manchmal hat sich bei dem Prozedere dann einer der anderen HTs oder der WT einen <rf error>
'eingefangen' ... :(
sodass mich das ganze fast in den Wahnsinn getrieben hat.... desshalb die Frage wie man diese
verdammten <rf errors> vermeiden kann, bzw. wieder los wird !
An der Funktion gibt es nix auszusetzen ... alles funktioniert wie erwartet/wie gewohnt,
nach dem Batteriewechsel.
Mich nervt das nur mit diesem Fehler ... 8)... der ist doch schon längst 'Geschichte'... wie
gesagt der Batteriewechsel war vor 11 Tagen  >:(

Ich hoffe ich nerve nicht mit meinem 'Problem' ... (..eigentlich ist es ja nur 'Kosmetik' ... ;)

Gruß
Ralf
Das FHEM ist rel. aktuell (letztes update war im Juni '18)

Offline DefanC

  • New Member
  • *
  • Beiträge: 22
  • Oooh mein FHEM !!
Antw:Batteriewechsel bei HT
« Antwort #10 am: 14 Oktober 2018, 12:37:50 »
Hallo Ralf,
also ich hab jetzt mal überlegt. Dauerte eine Weile, aber jetzt hab ich, glaube ich, eine Lösung für dich. 
* Du nervst mit deinem Problem nicht!
* Es ist eigentlich kein Problem, sondern ein Strukturfehler.
* NEIN! keine Kosmetik.

Aber der Reihe nach:

1. Habe ich dich richtig verstanden, deine Heizkörperthermostate sind alle in einem Raum.
2. In diesem Raum hast du einen Wandthermostaten installiert.
3. Du hast alle Geräte miteinander(?) verknüpft.
4. Du hast FHEM nur dafür, um die Daten der Heizungssteuerung mit zu lesen.
5. Du hast keinen CUBE sondern alle HT und der WT "reden" miteinander.

dann mußt du jetzt folgendes machen:

- du löschst alle MAX! Geräte aus deiner FHEM Installtion und setzt danach in der FHEM-Kommandozeile attr autocreate disable 1
  speicherst mit save config
  und zum Abschluss startest FHEM neu.
 
- du setzt alle MAX! Geräte auf die Werkseinstellungen zurück.

- danach gehst du nach dieser Anleitung vor:
  https://www.eq-3.de/Downloads/eq3/download%20bereich/handbuecher/MAX-Systemuebersicht.pdf
  Startpunkt: Kapitel 5 !

- du lernst also alle HT bitte nur(!) am WT an, nicht die HT untereinander(!) anlernen. (dazu mußt du warten, bis das Anlernen am jeweiligen Gerät abgeschlossen ist, siehst du am stabilen, nicht blinkenden WLAN-Symbol)

- wenn du alle MAX! HT an den WT angelernt hast, kannst du deine Steuerung (Tages-,Wochenprogramm, Comforttemperatur, Absenktemperatur, etc.) am WT einstellen. Anleitung dazu siehe hier:
  https://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/max/bda/BC-TC-C-WM-4_UM_DE.pdf

- die HT bekommen alle notwendigen Daten vom WT, du brauchst also nix weiter tun als ein HT nach dem anderen an das WT anzulernen. siehe:
  https://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/max/bda/BC-RT-TRX-CyG-4_UM_DE.pdf
  Startpunkt: Kapitel MAX! Raumlösung !!

voila:  Nun hast du eine funktionierende Raumlösung.

Jetzt kommt Kapitel drei, "Alle MAX! Geräte in FHEM":

- du setzt als erstes in der FHEM Kommandozeile ein attr autocreate disable 0
nach einer Weile warten, sollten sich alle deine MAX! Geräte in FHEM melden und du kannst nach Belieben weiter mit ihnen verfahren.

WICHTIG:

keines deiner MAX! Geräte muss händisch mit FHEM gepairt/angelernt/'assoziiert' werden!!

Du kannst NAME vergeben, <attr> setzen, die Geräte in einen Raum deiner Wahl schieben, mit den ausgelesenen Temperaturen Plots erstellen und so weiter und so weiter damit spielen.

Zum Schluss noch ein Wort zu deinem (von mir mit an Sicherheit grenzender Wahrscheinlichkeit vermuteten) Strukturfehler.
Es braucht bei der Steuerung immer einen Master. Unter diesen haben sich alle Slaves unter zu ordnen.
Wenn du den WT und die HT auf eine Stufe stellst, werden sie sich nie "einig", weil "jeder was zu sagen hat".
Deshalb der Kommunikationsfehler <rferror> .

Hoffe dir geholfen zu haben und wünsche dir viel Erfolg und einen schönen Restsonntag!  :)

mfG  Stefan
« Letzte Änderung: 14 Oktober 2018, 12:39:23 von DefanC »

Offline r-m-w

  • New Member
  • *
  • Beiträge: 16
Antw:Batteriewechsel bei HT
« Antwort #11 am: 14 Oktober 2018, 19:17:23 »
Hallo Stefan,

vielen Dank für deine Hinweise  ;)
Ich denke da hast du recht ... alle HT untereinander zu verknüpfen und mit dem Wandthermostat
ist vlt. kein so gute Idee.
Deine Erklärung mit der 'Master - Slave' Konfiguration leuchtet mir ein  8)

Bisher konnte ich durch die gegenseitige Verknüpfung aber immer alle HTs
auf die gleiche Soll-Temp. bringen, egal wo ich eine neue Temp. vorgegeben habe
(ob manuell an einem bel. HT oder am WT,  oder über FHEM per Kommando,
oder via ALEXA via 'HA bridge'  --> "ALEXA stelle Wandthermostat auf 24").

Ich dachte bisher auch, dass ich die HTs mit FHEM pairen muss, damit ich sie von dort
'steuern' kann ...

Also gut ... ich werde dann bei Gelegenheit meine MAX - FHEM Konfiguration noch einmal
neu aufsetzen.
Mein 'setup' in der fhem.cfg (device settings, etc.) bzgl. der HTs kann ich doch
danach auch so weiterverwenden, oder ?

Also nochmals Danke für deine Analyse und Hilfestellung.

Viel Grüße
Ralf

Offline DefanC

  • New Member
  • *
  • Beiträge: 22
  • Oooh mein FHEM !!
Antw:Batteriewechsel bei HT
« Antwort #12 am: 15 Oktober 2018, 18:25:34 »
'n Abend Ralf,

wenn du meinen Plan für deine Raumlösung so umsetzt, wie ich es beschrieben habe, kannst du vom WT aus alle angelernten HT steuern. Mit einer Einstellung am WT alle angelernten HT anweisen das zu tun, was du wünschst.  :)

Wenn du die Temperaturen aus FHEM heraus ändern willst, dann "übergehst" du wieder den "Master". Das funktioniert. Aber die Folge sind dann nach einigen Änderungen = <rferror> !!

Also, tu was du willst, deine Anlage wird es dir "danken".  ;)

Zitat
Mein 'setup' in der fhem.cfg (device settings, etc.) bzgl. der HTs kann ich doch
danach auch so weiterverwenden, oder ?
Wenn du meinen Plan genauso umsetzt wie oben beschrieben,
Zitat
- du löschst alle MAX! Geräte aus deiner FHEM Installation
gehen alle deine früher gemachten Einstellungen in FHEM verloren.
Das macht aber nix weil, dadurch das sich deine MAX! Geräte später wieder in FHEM melden, alle Daten der Geräte wieder mit übertragen werden.
Deine individuellen Einstellungen in FHEM deiner Gerätedarstellung (<attr> <device>:defStateIcon,defStateStyle,room,etc.) mußt du neu einrichten.
Einen Hinweis noch zu deinem gesendeten list <device> :
Zitat
Attributes:
   IODev      cm
   icon       hc_wht_regler
   keepAuto   1
   room       Wohnzimmer
das <attr> keepAuto würde ich nicht wieder setzen. Weil: Wer ist der Master ? Natürlich dein WT !!
Und du kannst ja an deinem WT in den  "manuellen Betrieb" schalten und so deine gewünschte "Komforttemperatur" setzen, die dann an alle gepairten Geräte gesendet wird.
Und die müssen dann machen was der Master = WT vorgibt.  ;)
sonst:  = <rferror>  !!!

Wenn du dann mit "Alexa" steuern willst, dann bring deiner "Alexa" bei sich mit dem Master = WT, zu unterhalten. Dann klappts auch mit der Steuerung... unangenehme Folgen bleiben dir so erspart.   ;)

Wenn du mit FHEM steuern willst, was aber nun ein völlig anderes Szenario als das beschriebene ist (!), dann lerne alle MAX! Geräte in FHEM an. Damit kann dann FHEM die Master-position einnehmen. Nimm den WT als "Führungsdevice", zum Erkennen der Temperatur.

Aber jetzt genug der unterschiedlichen Möglichkeiten, sonst verwirre ich dich und du leidest unter der Qual der Wahl.  ;D

Wenn Fragen oder Unklarheiten auftauchen, melde dich einfach nochmal. Sollte ich nicht gleich reagieren, schick mir ne Mail zur Erinnerung.
Das ist kein  nerven:) :)

Also nochmals  viel Erfolg !!

LG  Stefan

 

decade-submarginal