Die MAX Module heute und die Aussichten für 2020

Begonnen von Wzut, 22 Dezember 2019, 13:46:18

Vorheriges Thema - Nächstes Thema

Wzut

Zitat von: SibbeH am 15 Mai 2020, 19:12:34
  NAME       MAX_CV_Woonkamer_VR
     2020-05-14 21:41:20   error           Invalid command/argument  81190028
     2020-05-14 21:57:01   lastcmd         set_associate MAX_WT_Woonkamer
Hier sieht man das es nicht um einen Batteriewechsel geht sondern ein "set MAX_CV_Woonkamer_VR associate MAX_WT_Woonkamer"
Dieser Versuch schlug fehl , IMHO hat MAX_WT_Woonkamer eine Adresse die irgendwie zu 190028 passt.
Noch besser sieht man solche Dinge wenn man das CULMAX Device auf verbose 5 stellt. Aber egal der Error sollte sich auch im Logfile finden lassen.
Meine Vermutung : es wurde ein associate versucht das bereits bestand, die werden dann immer mit Fehler abgewiesen.

Zur rg , das + wählt Internals aus, der RSSI Wert ist aber ein Reading !
Wäre es meine rg würde sie so aussehen :

defmod rssi2 readingsGroup TYPE=MAX:RSSI
attr rssi2 mapping %DEVICE
attr rssi2 valueStyle style="text-align:right"
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

SibbeH

#181
Ich habe in der Tat versehentlich einen associate an MAX_CV_Woonkamer_RV gesendet. Damit habe ich die Readings nicht richtig nachgesehen. Sorry.
Das mit die RSSI habe ich ausprobiert und hat geklapt.
Ich soll nachdenken über wie ich die Readings und die Internals in einem Tabelle bekomme.
Vielen Dank !

Gruß,
Sibbe
Raspberry Pi, CULV3, 3xCUNO, MAX Thermostat, MAX Wandthermostat, HM, HmIP. UWZ, WeekProfile

Wzut

Na einfach die Regex anpassen , erweitern :
TYPE=(MAX|CUL_MAX|CUL|FS20):RSSI,+.*RSSI,+.*TIME
wobei ich es nicht machen würde, die Tabelle hat dann keine schöne Formatierung mehr.
Und beim CUL und CULMAX Device sagen doch diese nackten RSSI Werte gar nichts.
Wenn FS20 die nur als Internals hat würde ich zwei Gruppen machen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

SibbeH

Ich mache zwei Gruppen.
Vielen Dank !

Gruß,
Sibbe
Raspberry Pi, CULV3, 3xCUNO, MAX Thermostat, MAX Wandthermostat, HM, HmIP. UWZ, WeekProfile

jhohmann

Hallo, ich habe heute mal nach sehr langer Zeit wieder ein update für fhem einspielen lassen und damit auch die neuen MAX Module bekommen.
Ich betreibe MAX mit MAX_LAN und lasse zusätzlich eine CUL mitlaufen, um schneller auf Nachrichten reagieren zu können.
Ich habe z.B. bei allen Fenstern ein Notify, um auf geöffnete und geschlossene Fenster reagieren zu können.
Nun sieht das Log für ein Fenster nach dem Update so aus:

2020-05-27_09:51:40 Arbeit_Fenster waiting for data
2020-05-27_09:51:40 Arbeit_Fenster closed
2020-05-27_09:51:53 Arbeit_Fenster waiting for data
2020-05-27_09:51:54 Arbeit_Fenster closed
2020-05-27_09:52:03 Arbeit_Fenster waiting for data
2020-05-27_09:52:04 Arbeit_Fenster closed
2020-05-27_09:52:16 Arbeit_Fenster waiting for data
2020-05-27_09:52:17 Arbeit_Fenster closed
2020-05-27_09:55:24 Arbeit_Fenster waiting for data
2020-05-27_09:55:25 Arbeit_Fenster closed
2020-05-27_09:55:37 Arbeit_Fenster waiting for data
2020-05-27_09:55:38 Arbeit_Fenster closed
2020-05-27_09:55:48 Arbeit_Fenster waiting for data
2020-05-27_09:55:49 Arbeit_Fenster closed
2020-05-27_09:56:00 Arbeit_Fenster waiting for data
2020-05-27_09:56:01 Arbeit_Fenster closed
2020-05-27_09:59:09 Arbeit_Fenster waiting for data
2020-05-27_09:59:11 Arbeit_Fenster closed
2020-05-27_09:59:23 Arbeit_Fenster waiting for data
2020-05-27_09:59:24 Arbeit_Fenster closed
2020-05-27_09:59:34 Arbeit_Fenster waiting for data
2020-05-27_09:59:35 Arbeit_Fenster closed
2020-05-27_09:59:47 Arbeit_Fenster waiting for data
2020-05-27_09:59:49 Arbeit_Fenster closed

Und darauf springen meine Notifys dann immer wieder neu an, auch wenn die Fenster geschlossen sind.
defmod ntArbeitFenster notify Arbeit_Fenster:.* {}.
Ist das Verhalten bekannt? Was kann man da machen?
Und dann noch eine weitere Meldung aus dem globalen fhem-Log:
After sleep: MAXLAN_Write: MAXLAN_SimpleWrite: Not connected
Was soll mir das sagen?

Das Update habe ich erstmal wieder zurück genommen und fahre weiter mit meiner alten Installation.

Danke für jede Unterstützung
Jürgen
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Wzut

das sieht aus als ob Cube und CUL sich gegenseitig state überschreiben.
Ich würde die notifys nicht mit der dicken Kelle .* anlegen sondern eher nach dem Muster Arbeit_Fenster:onoff:(0|1) {blablub}
und natürlich am Device event-on-change-reading .* bzw. mindestens onoff

Zu der MAXLAN Meldung kann ich nichts sagen da ich das Modul bisher weder angefasst habe noch wisse was da intern abläuft.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jhohmann

Danke für die schnelle Antwort. Ich stelle meine notifys um.
Aber vor dem nächsten Updateversuch werde ich vermutlich erstmal auf buster upgraden und dann später einen neuen Versuch mit fhem starten.
Immer nur eins nach dem anderen  :).
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Wzut

Kannst ja erst einmal ein notify anpassen und testen, da es das onoff Reading schon immer gab sollte das auch bei uralt Versionen gehen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jhohmann

Hallo, inzwischen habe ich die Upgrade durch (sowohl Raspi auf buster als auch fhem auf die neuste Version).
So alt war mein bisheriges FHEM nun doch nicht. Der alte Stand war von November 2019.
Und zur Sicherheit habe ich vor dem Upgrade von FHEM auch mal alle Geräte inklusive des Cube resetet und neu verbunden, da ich zwischendurch den Eindruck hatte, das da noch alte oder unbekannte Geräte schlummern.

Die Einschränkung des notify hat so natürlich funktioniert.
Aber die Meldungen mit "waiting for data" habe ich immer noch.
Bei den Fensterkontakten kann ich mich überhaupt nicht auf "Value("fenstername")" verlassen, da hier immer wieder obige Meldung dazwischen funkt, und damit auch die Watchdogs nicht mehr liefen.
Ich habe jetzt alle Zugriffe auf das Reading onoff umgestellt und das funktioniert auch.

Aber einen Grund für diese Nachrichten zu haben wäre schon schön (und die Meldungen weg zu bekommen).

Zur Situation: Ich betreibe schon länger einen MAXLAN und einige Geräte daran.
Da mir aber das Melden von offenen Fenstern damit zu lange dauert, kam später noch ein CUL868 dazu. Alles lief ohne Probleme bis zum Upgrade von FHEM. Der Cube wird nur noch alle 10 Minuten gefragt, wahrscheinlich könnte ich das Intervall auch verlängern.
Hier ein Listing meines MAXLAN
Internals:
   CULMAX0_MSGCNT 7
   CULMAX0_TIME 2020-06-10 11:27:44
   DEF        192.168.168.29 600 ondemand
   DeviceName 192.168.168.29:62910
   FUUID      5ed90403-f33f-98e0-79f0-b8d3b5fff43200fe
   INTERVAL   600
   LASTInputDev CULMAX0
   MSGCNT     7
   NAME       ml
   NR         286
   STATE      1
   TYPE       MAXLAN
   addr       03b7d0
   clockset   3
   cubeTimeDifference 0
   dutycycle    1 %
   fwversion  0113
   pairmode   0
   persistent 0
   serial     JEQ0131613
   READINGS:
     2020-06-10 11:27:44   RSSI            -22
     2020-06-10 07:01:44   desiredTemperature 0.0
     2020-06-10 11:27:13   dutycycle       1
     2020-06-10 11:27:13   firmware        0.1
     2020-06-10 07:01:44   mode            auto
     2020-06-10 11:27:44   peerIDs         002141,00532b,006864,006c1e,01591f,02066e,020d72,020e10,021902,024e74,026283,0270ac,029fa7,02a1ad,02a4a4,03c7cb,0a031f,0f6aef,133012
     2020-06-10 11:27:44   peerList        Arbeit_Fenster,Arbeit_Thermo,Arbeit_WandThermo,Bad_Fenster,Bad_Thermo,Bad_WandThermo,Kueche_Fenster,Kueche_Thermo,Kueche_WandThermo,Schlaf_Fenster,Schlaf_Thermo,Schlaf_WandThermo,Souterrain_Fenster_links,Souterrain_Fenster_rechts,Wohn_Fenster,Wohn_Thermo_Couch,Wohn_Thermo_Ess,Wohn_Thermo_Front,Wohn_WandThermo
     2020-06-10 11:27:44   state           waiting for data
     2020-06-10 11:27:13   testresult      0
   devices:
     HASH(0x5bae310)
     HASH(0x5bb26b8)
     HASH(0x5bb54b0)
     HASH(0x5bba6b8)
     HASH(0x5bbf7c8)
     HASH(0x26919c8)
     HASH(0x5bb6400)
     HASH(0x5bb2718)
     HASH(0x5ba0500)
     HASH(0x5ba0ea8)
     HASH(0x53f98a8)
     HASH(0x2761608)
     HASH(0x5b56dc0)
     HASH(0x5b57138)
     HASH(0x14d4940)
     HASH(0x2691680)
     HASH(0x55523f0)
     HASH(0x5bb63a0)
     HASH(0x54b4480)
     HASH(0x5bac590)
     HASH(0x251dfe8)
   groups:
     HASH(0x5040f40)
     HASH(0x5bb0260)
     HASH(0x43fb798)
     HASH(0x5bb9070)
     HASH(0x5b56e08)
     HASH(0x5bb97e0)
   helper:
     io:
       CUL_868:
         raw        Z0B10000203B7D01330120000
         rssi       -22
         time       1591781264.4284
Attributes:
   event-on-change-reading .*
   icon       wuerfel
   room       System
   stateFormat dutycycle

Auch dieser ist oft im Status "waiting for data". Komisch finde ich auch, dass ich hier zwei Internals mit CULMAX0 sehen kann.

Und hier der Log-Auszug eines Fensterkontakts:
2020-06-10_10:12:55 Arbeit_Fenster waiting for data
2020-06-10_10:12:56 Arbeit_Fenster closed
2020-06-10_10:22:58 Arbeit_Fenster waiting for data
2020-06-10_10:23:00 Arbeit_Fenster closed
2020-06-10_10:26:00 Arbeit_Fenster RSSI: -70
2020-06-10_10:33:02 Arbeit_Fenster waiting for data
2020-06-10_10:33:04 Arbeit_Fenster closed
2020-06-10_10:43:06 Arbeit_Fenster waiting for data
2020-06-10_10:43:07 Arbeit_Fenster closed
2020-06-10_10:53:09 Arbeit_Fenster waiting for data
2020-06-10_10:53:11 Arbeit_Fenster closed
2020-06-10_11:03:13 Arbeit_Fenster waiting for data
2020-06-10_11:03:16 Arbeit_Fenster closed
2020-06-10_11:07:11 Arbeit_Fenster waiting for data
2020-06-10_11:07:11 Arbeit_Fenster closed
2020-06-10_11:17:12 Arbeit_Fenster waiting for data
2020-06-10_11:17:12 Arbeit_Fenster closed
2020-06-10_11:27:13 Arbeit_Fenster waiting for data
2020-06-10_11:27:14 Arbeit_Fenster closed

Das Zeitintervall passt oft mit den 10 Minuten zu meinem Update-Intervall des MAXLAN. Aber früher kam das nicht.
Aber nicht immer
2020-06-09_21:08:43 Souterrain_Fenster_links waiting for data
2020-06-09_21:08:44 Souterrain_Fenster_links closed
2020-06-09_21:18:46 Souterrain_Fenster_links waiting for data
2020-06-09_21:18:47 Souterrain_Fenster_links closed
2020-06-09_21:28:49 Souterrain_Fenster_links waiting for data
2020-06-09_21:28:50 Souterrain_Fenster_links closed
2020-06-09_21:33:11 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:13 Souterrain_Fenster_links closed
2020-06-09_21:33:18 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:19 Souterrain_Fenster_links closed
2020-06-09_21:33:23 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:24 Souterrain_Fenster_links closed
2020-06-09_21:33:29 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:30 Souterrain_Fenster_links closed


Werden mehr Angaben gebraucht? Hat jemand eine Idee?
Vielen Dank
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Wzut

Zitat von: Wzut am 27 Mai 2020, 11:48:22
das sieht aus als ob Cube und CUL sich gegenseitig state überschreiben.
Poste doch bitte mal ein List von deinem CUL , dem CUL_MAX Device und einem beliebigen FK.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jhohmann

CUL
Internals:
   CMDS       ABCEeFfGiKlMNRTtUVWXxYZ
   CUL_868_MSGCNT 2023
   CUL_868_TIME 2020-06-10 17:42:41
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400
   FD         41
   FHTID      0000
   FUUID      5c822521-f33f-98e0-51bb-c6112116609df5ed
   NAME       CUL_868
   NR         132
   NR_CMD_LAST_H 2
   PARTIAL   
   RAWMSG     Z0E5D0202020E100A031F00011800271D
   RSSI       -59.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.04 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
   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:
     2020-06-10 11:06:59   cmds             A B C E e F f G i K l M N R T t U V W X x Y Z
     2020-06-08 11:25:06   credit10ms      3011
     2020-05-12 10:19:33   raw             No answer
     2020-06-10 17:42:41   state           Initialized
     2020-05-12 14:10:07   version         V 1.26.04 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
   XMIT_TIME:
     1591780031.386
     1591780033.89654
Attributes:
   icon       cul_868
   rfmode     MAX
   room       System

CUL_MAX
Internals:
   CUL_868_MSGCNT 2029
   CUL_868_RAWMSG Z0EB2020202066E02A4A40001180022
   CUL_868_RSSI -62
   CUL_868_TIME 2020-06-10 17:43:50
   DEF        123456
   FUUID      5c822527-f33f-98e0-5073-77706678a1d47e8e
   IODev      CUL_868
   LASTInputDev CUL_868
   MSGCNT     2029
   NAME       CULMAX0
   NR         167
   STATE      CUL_868:ok
   SVN        21994
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2020-06-04 16:22:12   packetsLost     31
     2020-06-10 17:43:50   state           CUL_868:ok
   sendQueue:
Attributes:
   IODev      CUL_868
   event-on-change-reading .*
   fakeSCaddr 222222
   fakeWTaddr 111111
   icon       cul_max
   room       System

Arbeitszimmerfenster
Internals:
   CULMAX0_MSGCNT 13
   CULMAX0_TIME 2020-06-10 17:26:00
   DEF        ShutterContact 00532b
   FUUID      5c82251d-f33f-98e0-7089-3fa019224cf5a900
   IODev      ml
   LASTInputDev ml
   MSGCNT     238
   NAME       Arbeit_Fenster
   NR         30
   NTFY_ORDER 50-Arbeit_Fenster
   STATE      closed
   SVN        22023
   TYPE       MAX
   addr       00532b
   devtype    4
   ml_MSGCNT  225
   ml_TIME    2020-06-10 17:41:22
   type       ShutterContact
   READINGS:
     2020-06-10 17:41:22   MAXLAN_error    0
     2020-06-10 17:41:22   MAXLAN_errorInCommand
     2020-06-10 17:41:22   MAXLAN_initialized 1
     2020-06-10 17:41:22   MAXLAN_isAnswer 0
     2020-06-10 17:41:22   MAXLAN_valid    1
     2020-06-10 17:26:00   RSSI            -72.5
     2020-06-10 17:41:22   SerialNr        IEQ0154690
     2020-06-10 17:41:22   battery         ok
     2020-06-10 17:41:22   batteryState    ok
     2020-06-10 17:41:22   firmware        1.3
     2020-06-08 10:59:05   groupid         2
     2020-06-10 17:41:22   onoff           0
     2020-06-10 17:41:22   peerIDs         026283,029fa7,03b7d0
     2020-06-10 17:41:22   peerList        Arbeit_Thermo,Arbeit_WandThermo,ml
     2020-06-10 17:41:22   rferror         0
     2020-06-10 17:41:22   state           closed
     2020-06-10 17:41:22   testresult      15
     2020-06-10 17:41:22   windowOpen      0
   helper:
     io:
       CUL_868:
         raw        Z0B1C063000532B03B7D00010
         rssi       -72.5
         time       1591802760.42519
Attributes:
   IODev      ml
   event-on-change-reading .*
   genericDeviceType ContactSensor
   icon       fts_window_1w
   model      ShutterContact
   room       Arbeitszimmer,Homekit
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Wzut

also das list des CULMAX sieht schon mal komisch aus , da stehen Readings die da einfach nichts zu suchen haben.
Du betreibst MAXLAN und CUL_MAX parallel aber unter verschiedenen Ids :
MAXLAN : 03b7d0
CUL_MAX : 123456
CUL : maxid nicht gesetzt
In der Theorie hat nun CUL_MAX bei Paketen von/nach 03b7d0 keine Ahnung das diese von/für seinem "Bruder" MAXLAN sind und behandelt sie wie von einem unbekannten MAX Gerät. ( das müsste man auch schön in einem verbose 5 Log des CUL_MAX sehen )
Ich würde an deiner Stelle drei Dinge versuchen (bitte einzeln nicht gleich alle zusammen !) :
a. trage die 03b7d0 beim CUL_MAX im Attribut blacklist ein.
b. gib dem CUL_MAX Device beim define die  03b7d0 mit statt der 123456 und setze am CUL Device das Attribut maxid auch auf 03b7d0
c. leg ein neues MAX Device vom Typ Cube mit der Adresse 03b7d0 an.
define myCube MAX Cube 03b7d0

Bei Variante a. wird alles was direkt an 03b7d0 geht oder von 03b7d0 kommt von CULMAX als "fremd" verworfen, sollte kein Problem sein wenn deine FKs mit einem HT oder WT assoziert sind, da dann der FK seinen Status direkt um HT/WT schickt und die ID 03b7d0 nicht im Telegramm auftaucht. 
Ich kann frühestens Mitte Juli bei mir das Ganze mal so nachstellen und testen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

@jhohmann, hast du dich mal gefragt wie es kommt das dein CUL weniger als 3600 Credits zur Verfügung hat ?
Wenn ich dich bis jetzt richtig verstanden habe soll dein CUL nur mithören aber nicht aktiv senden, aber das tut er sonst hätte er immer seine max Credits.
U.a könnte ich wetten versucht er alle paar Stunden deinen HT & WTs die aktuelle Uhrzeit zu senden.

Und dazu natürlich noch die Ketzerfrage : Wieso benutzt du überhaupt noch den Cube mit MAXLAN wenn du doch schon einen CUL hast ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jhohmann

Erstmal vielen Dank für die schnellen Rückmeldungen zu meinem Problem.
A) habe ich ausprobiert und es hat bei den Fensterkontakten zu keiner Änderung geführt.
B) konnte ich über die WEB GUI nicht einpflegen. Hier kam die Meldung, dass die Adresse schon vergeben ist.
Ich werde B) Anfang nächster Woche noch auf andere Wege versuchen, reinzubekommen und dann auch mal C) ausprobieren.

Zu der ketzerischen Frage: Ich habe im Forum schon gelesen, dass man einfach umsteigen können soll, indem man den MAXLAN rauswirft und auch vom Netz nimmt.
Das habe ich ausprobiert und prompt hat FHEM nicht sofort auf "Fenster ist auf" oder "zu" reagiert, ich musste warten. In Kombination MAXLAN und CUL_MAX kommt die Reaktion sofort (das kann aber an der falschen Adresse am CUL_MAX liegen. Aber ich meine, dass hätte ich auch schon mal probiert und durch ein rückgespieltes Backup wieder verloren).
Der zweite Grund, warum ich nicht umsteige, ist mein Heizungseinstellungsprogramm:
https://forum.fhem.de/index.php/topic,92704.0.html Damit kann ich für mich sehr einfach das Profil ändern. Wie ich das mit dem Weekprofile und unter Einhaltung der Credits sauber hinbekomme, muss ich mir anschauen, wenn das Problem der schlechteren Reaktion auf "Fenster auf" behoben ist.

Und als Randbemerkung: Ich scheine nicht mehr alleine zu sein  ;) https://forum.fhem.de/index.php/topic,112021.0.html
Ich melde mich dann Anfang kommender Woche wieder.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Wzut

#194
Zum Thema Blacklist :
das wundert mich nun schon. Klarheit kann da wohl nur ein verbose 5 Log des CUL_MAX und des FKs bringen.
zu B : ja das geht z.Z. nur mittels löschen des CUL_MAX Device und gleich wieder neu anlegen, aber heb dir das noch etwas auf.
Variante c hast du nicht probiert ?

Das mit dem weekprofil sollte gehen, da es inzwischen so schlau ist nur den Tag zu übertragen der sich geändert hat statt stur wie früher wegen einer Temperatur das komplette Wochenprogramm zu schreiben. Und ja Änderungen am Wochenprofil sind nicht billig, auch die ELV Software zeigt einem irgendwann nur noch die drehenden Zahnräder wenn zuviel auf einmal machen will. 

Edit :
Traust du dir zu eine Zeile in 10_MAX.pm zu ändern ?
In Zeile 1921 steht :
# Build state READING
  my $state = "waiting for data";


dies ändern in :

# Build state READING
my $state = ReadingsVal($name, 'state', 'waiting for data');


danach noch ein reload 10_MAX oder FHEM Neustart.
Ich glaube jetzt es ist nicht der CUL_MAX der für den Wechsel sorgt sondern MAXLAN.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher