Neue Beta Test Runde für alle MAX Module

Begonnen von Wzut, 14 Oktober 2020, 17:41:04

Vorheriges Thema - Nächstes Thema

dirk.k

Hallo zusammen.
Erst mal ein dickes Dankeschön. Die neuen Funktionen sind toll.
Was verwendet ihr für Module/Firmware zum Senden/Empfangen?
Ich habe einen "V 1.67 nanoCUL433" (auf 3600 credits aufgebohrt) drunter und der hängt sich jetzt recht häufig auf.
Besonders, wenn ich zum Testen das "getStatus" alle 1-2 Minuten ausführe. Credits sind zum Schluss noch ausreichen da.
Vom CUL bekomme ich dann auf alle Befehle "no Answer" zurück.
Helfen tut dann nur ein Trennen vom USB + "reopen".
Habe ihn direkt am FHEM Server und via ser2net getestet ... immer das Gleiche.
Danke, Dirk
 

Parador

Hallo Zusammen,
ich habe gestern und heute versucht mittels "deassociate" zwei VSC's von einem HT abzulernen - erhalte von diesem HT ab immer "keine Reaktion" bei deassiciate ... d.h. er behält ihn - Sonstige Aufträge übernimmt er sofort...

error Send Queue NACK from Thermostat_EG_ArbZi for RemoveLinkPartner

Was kann ich noch versuchen um hier einen VSC hinauszuwerfen?

Parador

#62
Guten Morgen,

heute hatte ich einen Schwung Meldungen im Log, die ich mir nicht, oder nur schwer erklären kann.
Wenn ich es richtig sehe, wurden viele "fremde" MAX-Geräte "gehört" und deren Nachrichten konnten nicht interpretiert werden..
Die Geräte sind m.W. bei mir nicht angelegt (zumindest finde ich die Adressen in den eckigen Klammern nicht), bis auf die Nachricht um 2021.05.17 00:27:56 wo zumindest mein CUL_MAX vorkommt.
Was dann ab 06:32 Uhr los ist - keine Ahnung

2021.05.17 00:17:56 2: cm, unknown message type 66 from MAX_440018 [440018] to MAX_002600 [440018] - ignoring !
2021.05.17 00:27:56 2: cm, unknown message type CC from cm [entfernt] to MAX_001800 [entfernt] - ignoring !
2021.05.17 01:07:56 2: cm, unknown message type 1F from MAX_840fa0 [840fa0] to MAX_00600a [840fa0] - ignoring !
2021.05.17 03:47:56 2: cm, unknown message type 66 from MAX_44000f [44000f] to MAX_000060 [44000f] - ignoring !
2021.05.17 05:10:27 2: cm, unknown message type 18 from MAX_002600 [002600] to MAX_d02486 [002600] - ignoring !
2021.05.17 05:37:56 2: cm, unknown message type 18 from MAX_1f2a00 [1f2a00] to MAX_d02486 [1f2a00] - ignoring !
2021.05.17 05:46:14 2: cm, unknown message type 25 from MAX_860f00 [860f00] to MAX_046004 [860f00] - ignoring !
2021.05.17 05:46:26 2: cm, unknown message type CF from MAX_1b850f [1b850f] to MAX_a00460 [1b850f] - ignoring !
2021.05.17 05:50:34 2: cm, unknown message type 37 from MAX_850fa0 [850fa0] to MAX_04600a [850fa0] - ignoring !
2021.05.17 05:57:56 2: cm, unknown message type 1F from MAX_2a00d9 [2a00d9] to MAX_258585 [2a00d9] - ignoring !
2021.05.17 06:24:29 2: cm, unknown message type DF from MAX_1d890f [1d890f] to MAX_000460 [1d890f] - ignoring !
2021.05.17 06:28:23 2: cm, unknown message type 1F from MAX_2a00e2 [2a00e2] to MAX_26890f [2a00e2] - ignoring !
2021.05.17 06:32:14 1: PERL WARNING: Use of uninitialized value in abs at ./FHEM/14_CUL_MAX.pm line 745.
2021.05.17 06:32:14 1: ERROR: empty name in readingsBeginUpdate
2021.05.17 06:32:14 1: stacktrace:
2021.05.17 06:32:14 1:     main::readingsBeginUpdate           called by fhem.pl (5070)
2021.05.17 06:32:14 1:     main::readingsSingleUpdate          called by ./FHEM/14_CUL_MAX.pm (911)
2021.05.17 06:32:14 1:     FHEM::CUL_MAX::Parse                called by fhem.pl (4083)
2021.05.17 06:32:14 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (954)
2021.05.17 06:32:14 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (832)
2021.05.17 06:32:14 1:     main::CUL_Read                      called by fhem.pl (3887)
2021.05.17 06:32:14 1:     main::CallFn                        called by fhem.pl (773)
2021.05.17 06:32:14 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4924.
2021.05.17 06:32:14 1: readingsUpdate(,PairedTo,180b2a) missed to call readingsBeginUpdate first.
2021.05.17 06:32:14 1: stacktrace:
2021.05.17 06:32:14 1:     main::readingsBulkUpdate            called by fhem.pl (5071)
2021.05.17 06:32:14 1:     main::readingsSingleUpdate          called by ./FHEM/14_CUL_MAX.pm (911)
2021.05.17 06:32:14 1:     FHEM::CUL_MAX::Parse                called by fhem.pl (4083)
2021.05.17 06:32:14 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (954)
2021.05.17 06:32:14 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (832)
2021.05.17 06:32:14 1:     main::CUL_Read                      called by fhem.pl (3887)
2021.05.17 06:32:14 1:     main::CallFn                        called by fhem.pl (773)
2021.05.17 06:32:14 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4670.
2021.05.17 06:44:16 2: cm, unknown message type 52 from MAX_e0850b [e0850b] to MAX_520630 [e0850b] - ignoring !
2021.05.17 06:44:23 2: cm, unknown message type D6 from MAX_128900 [128900] to MAX_520583 [128900] - ignoring !
2021.05.17 06:47:56 2: cm, unknown message type 2A from MAX_00e525 [00e525] to MAX_820b52 [00e525] - ignoring !

Taipan

Ich wüßte immernoch gern ob die Pakete mittlerweile im offiziellen Update sind weil ich sie noch vom Update ausgeschlossen habe!
Kann das jemand klarstellen?

List of new / modified files since last update:
UPD FHEM/00_MAXLAN.pm (excluded from update)
UPD FHEM/10_MAX.pm (excluded from update)
UPD FHEM/14_CUL_MAX.pm (excluded from update)

Wzut

@Parador, ich tippe da auf zerstörte Telegramme - kommt manchmal vor, auch bei mir

@Taipan, sind nicht im svn daher ja auch dieser Thread
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

west2107

@ Parador

Das Problem mir dem Empfang hatte ich auch. Bei mir wurden über mehrere Tage 41 MAX-Geräte per Autocreate erzeugt.
Die habe ich alle auf ignore gesetzt. Seit einigen Wochen ist aber Ruhe.
Es macht auch Sinn die PeerList der eigenen Geräte zu überwachen. Ich hatte einen Kandidaten der sehr gerne mit solchen
neuen Geräten "schwatzte". Die erscheinen dann in seiner PeerList.
Den habe ich zurückgesetzt und neu angelernt. Jetzt ist der auch ruhig geworden.

Ansonstenlaufen die Module gut und die neuen Funktionen sind ein echter Mehrwert.

Parador

@west2107 & @Wzut
Danke für die Hinweise, ich habe tatsächlich auch einen "Schätzer" gefunden, bei dem einige der unbekannten Geräte in der peerList auftauchen.
Die meisten habe ich auf ignore gesetzt.
Jetzt habe ich aber noch einige Fragen:
Wie unterscheiden sich "peerIDs", "peerList" und "peers" ?
"peers" sind m.M. nach die die mit "associate" verknüpft wurden, und die anderen?
Hier mal ein List des "Schätzers", die "peers" sind ok - muss ich wegen der anderen bei peerIDs und peerList noch was tun?

2021-05-23 13:09:03   peerIDs         000000,0f0000,440f00,4427c4,44660f
2021-05-23 13:09:03   peerList        Broadcast,MAX_0f0000,MAX_440f00,MAX_4427c4,MAX_44660f
2020-05-01 08:49:12   peers           010501,010502


Und dann habe ich noch das Problem, dass ein anderer nicht auf ein "deassiciate" reagiert

2020-11-30 11:30:14   peerIDs         000000,222222
2020-11-30 11:30:14   peerList        Broadcast,MAX_222222
2021-05-14 22:55:59   peers           [u]010001,010201[/u],010301,010302


Hier erhalte ich im CUL_MAX immer die identische Fehlermeldung:
Internals:
   DEF        --entfernt--
   FUUID      5d9598f6-f33f-71bb-9d12-fbd0e5ae82f8ad07
   IODev      MAX_CUL_0
   LASTInputDev
   NAME       cm
   NOTIFYDEV  global
   NR         267
   NTFY_ORDER 50-cm
   STATE      MAX_CUL_0:ok
   SVN        28032021
   TYPE       CUL_MAX
   addr       --entfernt--
   cnt        0
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2021-05-23 13:21:58   IODev           MAX_CUL_0
     2021-05-25 15:06:16   error           Send Queue NACK from Thermostat_EG_AZi for RemoveLinkPartner
     2021-05-25 13:22:08   msgcnt          5
     2020-03-26 10:53:27   packetsLost     697
     2021-05-25 15:12:24   state           MAX_CUL_0:ok
   helper:
     asso:
       Fenster_EG_SZi_re Dispatch
       MAX_CUL_0  IO
       Thermostat_EG_AZi Send
       Thermostat_EG_EZi Dispatch
       Thermostat_EG_K Dispatch
       Thermostat_EG_SZi Send
       Thermostat_EG_WZi Dispatch
       Thermostat_OG_GZiA Dispatch
       Thermostat_OG_GZiB Dispatch
       Thermostat_OG_KZi_2 Dispatch
       Thermostat_OG_XZi Send
   sendQueue:
Attributes:
   IODev      MAX_CUL_0
   fakeSCaddr 222222
   fakeWTaddr 111111
   icon       cul_max
   room       MAX

Habt Ihr da Ideen?

Wzut

peerIDs und peerList gehören zusammen , IDs listet die sechstelligen HEX Adressen, List versucht die dazu passenden Namen dazustellen.
Ist bei vielen Usern leider relativ sinnlos, da sie an den blöden MAX_Hex autocreate Namen festhängen .... anyway
Beide Listen bauen sich dynamisch auf je nachdem welche Telegramme das CUL_MAX Device jemals gesehen hat, entweder als Ziel oder als Quelle.
Ist ne reine Info für den User und wenn da Müll drin steht oder es jamand nicht haben will -> delereading

peers baut sich auch selbst auf, aber nur nach einem peering (associate) von Hand.
Ebenfalls eine reine Info, mit Ausnahme bei den virtuellen Geräten.

wenn ein Gerät auf deassociate (unpeering) ein NACK ausgibt dann ist das betreffende Gerät nicht mehr gepeered oder war es noch nie.
Auch hier muß das Reading nicht unbedingt stimmen, da es halt bis jetzt keine Möglichkeit gibt diese direkt auszulesen.     

und BTW :
Zitat--entfernt--
sowas ist Unfug, die MAX Adressen sind keine Staatsgeheimnisse sondern einfach nur Nummern .....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

scooty

Hallo Wzut,

habe die drei Beta-Module ansonsten problemlos im Einsatz, bekomme aber für meinen Eindruck viele solcher Meldungen
XXXX_CULMAX00, Send Queue could not change IODev !
im FHEM-Log (z.B. aktuell seit Mo, 00:00h: 46 Meldungen, letzte Woche: 222 Meldungen).

XXXX_CULMAX00 ist das CUL_MAX Device.

Kann leider nicht nachvollziehen, was sie genau bedeuten oder was ich tun kann, um die Meldungen zu eliminieren (außer verbose 2 am MAX-Device :'().
Muss ich mir Sorgen machen?

Als IO-Devices habe ich 1 CUL und 2 mit aculfw geflashte MAX-Cubes im Einsatz und entsprechend im CUL_MAX Device "XXXX_CULMAX00" im Attribut "IOgrp" aufgenommen:
Internals:
   DEF        123456
   FUUID      5c4429e7-f33f-cd7a-aa25-6899a3aa62ba5f6f
   IODev      XXOG_CUL_MAX
   IOgrp      XXOG_CUL_MAX,XXDG_MAXCUBE01,XXKG_MAXCUBE01
   LASTInputDev
   NAME       XXXX_CULMAX00
   NOTIFYDEV  global
   NR         26
   NTFY_ORDER 50-XXXX_CULMAX00
   STATE      XXOG_CUL_MAX:ok,XXDG_MAXCUBE01:ok,XXKG_MAXCUBE01:ok
   SVN        28032021
   TYPE       CUL_MAX
   XXDG_MAXCUBE01_VERSION 167
   XXKG_MAXCUBE01_VERSION 167
   XXOG_CUL_MAX_MAXID 123456
   XXOG_CUL_MAX_VERSION 167
   addr       123456
   cnt        0
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2021-06-05 14:03:25   IODev           XXOG_CUL_MAX
     2021-05-25 07:12:00   XXDG_MAXCUBE01_cmd_last_h 2
     2021-05-25 07:12:00   XXDG_MAXCUBE01_credit10ms 3600
     2020-10-01 07:31:23   XXDG_MAXCUBE01_lost 2
     2021-03-27 10:23:34   XXDG_MAXCUBE01_nack 4
     2021-06-07 07:08:41   XXDG_MAXCUBE01_retry 229
     2021-05-17 10:32:35   XXKG_MAXCUBE01_cmd_last_h 3
     2021-05-17 10:32:35   XXKG_MAXCUBE01_credit10ms 3600
     2021-01-10 11:57:41   XXKG_MAXCUBE01_lost 26
     2021-04-01 05:31:35   XXKG_MAXCUBE01_retry 116
     2021-06-09 07:17:51   XXOG_CUL_MAX_cmd_last_h 7
     2021-06-09 07:17:51   XXOG_CUL_MAX_credit10ms 900
     2021-03-15 08:56:04   XXOG_CUL_MAX_lost 64
     2020-12-22 18:08:02   XXOG_CUL_MAX_nack 6
     2021-06-05 15:23:45   XXOG_CUL_MAX_retry 924
     2021-06-09 07:17:51   error           could not change IODev
     2021-04-03 09:31:38   lastTimeSync    BAEG_MT
     2021-06-09 02:03:38   msgcnt          8
     2021-03-01 15:33:25   none_lost       109
     2021-03-01 15:33:18   none_retry      327
     2020-01-03 12:58:58   packetsLost     3188
     2020-01-03 10:10:42   packetsNACK     9
     2020-01-10 07:09:22   packetsRetry    145
     2021-05-09 23:57:48   short_message   Z00
     2021-06-09 07:28:41   state           XXOG_CUL_MAX:ok,XXDG_MAXCUBE01:ok,XXKG_MAXCUBE01:ok
     2021-03-30 18:25:09   unknown_message Z19F800101234560E847600015201511F53204520452045204520
   helper:
     asso:
       BADG_MFSC  Dispatch
       BADG_MT    Send
       BAEG_MF    Dispatch
       BAEG_MT    Dispatch
       BAOG_MF    Dispatch
       BAOG_MT    Dispatch
       EZEG_MT    Dispatch
       EZOG_MT    Dispatch
       FLDG_MB    Dispatch
       KUDG_MFSC  Dispatch
       KUDG_MT    Dispatch
       SZDG_MFSC  Dispatch
       SZDG_MT    Dispatch
       SZEG_MT    Dispatch
       SZOG_MFSC  Dispatch
       SZOG_MT    Send
       WGEG_MT    Dispatch
       WZDG_MFSC  Dispatch
       WZDG_MT    Dispatch
       WZEG_MFSC  Dispatch
       WZEG_MT    Send
       WZOG_MF    Dispatch
       WZOG_MT    Dispatch
       XXDG_MAXCUBE01 IO
       XXDG_MTW   Dispatch
       XXKG_MAXCUBE01 IO
       XXOG_CUL_MAX IO
   sendQueue:
Attributes:
   IODev      XXOG_CUL_MAX
   IOgrp      XXOG_CUL_MAX,XXDG_MAXCUBE01,XXKG_MAXCUBE01
   blacklist  02020a,0b2ce7,1325b9,13d598,0b2d0d,0b311b,1325e0,13d59a,02892b,600e84,da0985,180024
   debug      1
   fakeSCaddr 222222
   fakeWTaddr 111111


Danke für jeglichen Hinweis und falls weitere Infos benötigt werden, liefere ich sie gerne nach,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

Wzut

Ich befürchte das sind die ersten Auswirkungen von https://forum.fhem.de/index.php/topic,120603.0.html
Ist dein FHEM denn aktuell ?
Für den IOWechsel ist das CULdev Attribut des jeweiligen MAX Device zuständig, welcher Wechsel da genau schief geht verrät dir dein XXXX_CULMAX00 wenn es mit verbose 4 läuft.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

JHo

Zitat von: Wzut am 09 April 2021, 17:55:57
ach sorry, damit habe ich bisher unbekannte Tellegram Typen gesucht, das solltet ihr aber eigentlich nie vorgesetzt bekommen, habe ich doch glatt vergessen vorher zu löschen.
Nun werden eigentlich unsinnige Telegrammtypen plötzlich als gültig komplett durchgereicht.

Hallo Wzut,
hattest du das eigentlich wieder behoben? Bzw. was muss ich in der noch im ersten Post verlinkten Version von Ende März auskommentieren, damit sich bei mir nicht die Peerlists mit Müll füllen? Autocreate ist sowieso aus.

Danke!
Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

scooty

Zitat von: Wzut am 09 Juni 2021, 10:02:05
Ich befürchte das sind die ersten Auswirkungen von https://forum.fhem.de/index.php/topic,120603.0.html
Ist dein FHEM denn aktuell ?
Für den IOWechsel ist das CULdev Attribut des jeweiligen MAX Device zuständig, welcher Wechsel da genau schief geht verrät dir dein XXXX_CULMAX00 wenn es mit verbose 4 läuft.
Danke für die prompte Reaktion.
FHEM habe ich jetzt auf den neuesten Stand gebracht, die Meldungen kommen weiterhin.
Diesmal mit verbose 4:
2021.06.09 13:26:03.034 4: XXXX_CULMAX00, Send Queue packet to XXDG_MTW needs XXDG_MAXCUBE01 but current IODev is XXOG_CUL_MAX
2021.06.09 13:26:03.042 3: XXXX_CULMAX00, Send Queue could not change IODev !
2021.06.09 13:26:03.062 4: XXXX_CULMAX00, Send Queue packet send : Zs0beb043030281209a9611e10 to XXDG_MTW with XXOG_CUL_MAX
2021.06.09 13:26:04.133 4: XXXX_CULMAX00, C: EB, F: 02, T: 02, S: 09A961 D: 302812 G: 00 P: 0119043D
2021.06.09 13:26:04.134 4: XXXX_CULMAX00, IODev XXOG_CUL_MAX, flags 02, msgcnt EB, msgType Ack, src 09a961 WallMountedThermostat, dst 302812 virtualShutterContact, group 0, payload 0119043D, rssi -67.5
2021.06.09 13:26:04.235 4: XXXX_CULMAX00, C: EB, F: 04, T: 30, S: 302812 D: 09A961 G: 1E P: 10
2021.06.09 13:26:04.236 4: XXXX_CULMAX00, IODev XXKG_MAXCUBE01, flags 04, msgcnt EB, msgType ShutterContactState, src 302812 virtualShutterContact, dst 09a961 WallMountedThermostat, group 30, payload 10, rssi -84
2021.06.09 13:26:04.286 4: XXXX_CULMAX00, C: EB, F: 02, T: 02, S: 09A961 D: 302812 G: 00 P: 0119043D
2021.06.09 13:26:04.286 4: XXXX_CULMAX00, IODev XXKG_MAXCUBE01, flags 02, msgcnt EB, msgType Ack, src 09a961 WallMountedThermostat, dst 302812 virtualShutterContact, group 0, payload 0119043D, rssi -89.5
2021.06.09 13:26:04.381 4: XXXX_CULMAX00, C: EB, F: 04, T: 30, S: 302812 D: 09A961 G: 1E P: 10
2021.06.09 13:26:04.381 4: XXXX_CULMAX00, IODev XXDG_MAXCUBE01, flags 04, msgcnt EB, msgType ShutterContactState, src 302812 virtualShutterContact, dst 09a961 WallMountedThermostat, group 30, payload 10, rssi -67.5
2021.06.09 13:26:04.432 4: XXXX_CULMAX00, C: EB, F: 02, T: 02, S: 09A961 D: 302812 G: 00 P: 0119043D
2021.06.09 13:26:04.432 4: XXXX_CULMAX00, IODev XXDG_MAXCUBE01, flags 02, msgcnt EB, msgType Ack, src 09a961 WallMountedThermostat, dst 302812 virtualShutterContact, group 0, payload 0119043D, rssi -57.5
2021.06.09 13:26:04.542 4: XXXX_CULMAX00, Send Queue ACK from XXDG_MTW for ShutterContactState, removing from queue

Ich verstehe das so, dass
- zum Senden an das WT XXDG_MTW als IO-Device XXDG_MAXCUBE01 benutzt werden soll (woher stammt die Info, welches CULdev zu nutzen ist?)
- im Attribut "CULdev" des WT XXDG_MTW allerdings das IO-Device XXOG_CUL_MAX steht (automatisch durch die MAX-Module wegen mehrerer IO-Devices gesetzt, abhängig vom besten RSSI-Wert)
- das Attribut und somit der Wechsel nicht auf CULdev XXDG_MAXCUBE01 geändert werden kann (warum?)

Kann leider immer noch nicht einordnen (bin ehrlich gesagt daran gescheitert, den von Dir verlinkten Thread zu verstehen), ob die Meldung jetzt ein Problem darstellt oder es eher "normal" ist und ignoriert werden kann?

Viele Dank für Deine Unterstützung,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

Wzut

Zitat von: JHo am 09 Juni 2021, 10:11:29
was muss ich in der noch im ersten Post verlinkten Version von Ende März auskommentieren
die Zeilen mit TestXX :
my %msgId2Cmd = (
                 '00' => 'PairPing',
                 '01' => 'PairPong',
                 '02' => 'Ack',
                 '03' => 'TimeInformation',
                 '10' => 'ConfigWeekProfile',
                 '11' => 'ConfigTemperatures', #like eco/comfort etc
                 '12' => 'ConfigValve',
                 '20' => 'AddLinkPartner',
                 '21' => 'RemoveLinkPartner',
                 '22' => 'SetGroupId',
                 '23' => 'RemoveGroupId',
'24' => 'Test24',
                 '30' => 'ShutterContactState',
                 '40' => 'SetTemperature', # to thermostat
                 '42' => 'WallThermostatControl', # by WallMountedThermostat
                 # Sending this without payload to thermostat sets desiredTempeerature to the comfort/eco temperature
                 # We don't use it, we just do SetTemperature
                 '43' => 'SetComfortTemperature',
                 '44' => 'SetEcoTemperature',
                 '50' => 'PushButtonState',
                 '60' => 'ThermostatState', # by HeatingThermostat
'61' => 'Test61',
'62' => 'Test62',
'63' => 'Test63',
'71' => 'Test71',

                 '70' => 'WallThermostatState',
                 '82' => 'SetDisplayActualTemperature',
                 'F1' => 'WakeUp',
                 'F0' => 'Reset',
               );
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: scooty am 09 Juni 2021, 13:57:26
FHEM habe ich jetzt auf den neuesten Stand gebracht
so war das nicht gemeint, je neuer , je schlimmer :(
Zitatwoher stammt die Info, welches CULdev zu nutzen ist?
wie bereits geschrieben bestimmt du es selbst je MAX Device mit dem Attribut CULdev
Denn nur du kannst eigentlich wissen welcher deiner CULs der "Beste" für das jeweilige Device ist.
Zitatautomatisch durch die MAX-Module wegen mehrerer IO-Devices gesetzt
Das kann nur eine Empfehlung sein, die letzte Entscheidung trifft der User selbst , siehe Attribut autoselectCUL

Zitatbin ehrlich gesagt daran gescheitert, den von Dir verlinkten Thread zu verstehen
macht nichts, der ist auch schwere Kost und in weiten Teilen kann ich selbst die Argrumente der Profis nicht verstehen,
aber Fakt ist das diese Änderungen schuld am jetzigen Verhalten desCUL_MAX Device sind wenn das CUL_MAX Device kein simples IODev hat sondern
wie Homematic mehere unter IOGrp. Ich muß sehen wie dieser Schildbürgerstreich endet und dann schauen ob ich das Multi IO des CUL_MAX weiter am Leben halten kann.


Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

scooty

Zitat von: Wzut am 09 Juni 2021, 19:18:45
so war das nicht gemeint, je neuer , je schlimmer :(
Ups, aber egal, war ja sowieso schon auf einer der neueren Versionen, sonst wär die Meldung ja nicht da.

Zitat von: Wzut am 09 Juni 2021, 19:18:45
wie bereits geschrieben bestimmt du es selbst je MAX Device mit dem Attribut CULdev
Denn nur du kannst eigentlich wissen welcher deiner CULs der "Beste" für das jeweilige Device ist.Das kann nur eine Empfehlung sein, die letzte Entscheidung trifft der User selbst , siehe Attribut autoselectCUL
Alles klar, "autoselectCUL" hatte ich bisher nicht genutzt, der CUL-Auswahl-Automatismus funktioniert sehr gut.

Zitat von: Wzut am 09 Juni 2021, 19:18:45
Ich muß sehen wie dieser Schildbürgerstreich endet und dann schauen ob ich das Multi IO des CUL_MAX weiter am Leben halten kann.
Ich hoffe darauf, alles andere wäre mMn ein Rückschritt (natürlich nicht von Dir verschuldet).

Vielen Dank und Grüße,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol