Max!-Thermostat WT und HT nicht ansteuerbar

[thburkhart]

Bis vor wenigen Wochen betrieb ich einen MAX-Cube mit 5 Wandthermostaten und 8 Heizkörperthermotaten. Die Readings habe ich in in FHEM per CUL zu Statistikzwecken mitgelesen.
Der Cube begann zu Zicken und steuerte die angelernten Max-Devices nicht mehr sauber an auch bei Verkleinerung des Abstandes af ca. 3 m.
Ich warf daraufhin den MAX-Cube raus.
Ich habe alle Max-Devises komplett geresetted (Batterie raus und  3-fach Kunstgriff), in der FHEM.cfg MAX-defines gelöscht und in FHEM einzeln neu angelernt.

Ich kann die Devices wunderbar lesen aber nach mehreren Versuchen eben nicht steuern.

define CUL_0 CUL /dev/ttyACM0@9600 1234
setuuid CUL_0 5db11c8f-f33f-9b0e-6d74-d64e19930a86bb79
attr CUL_0 rfmode MAX
attr CUL_0 room STICKS

define MaxSystem CUL_MAX 123456
setuuid MaxSystem 5db11c90-f33f-9b0e-6d3e-2b6365467f30f6eb
attr MaxSystem IODev CUL_0
attr MaxSystem alias MaxSystem via CUL
attr MaxSystem room MAX
attr MaxSystem verbose 5

define Bad_WT_07dcf6 MAX WallMountedThermostat 07dcf6
setuuid Bad_WT_07dcf6 5db11c92-f33f-9b0e-5e3f-0d391fdc5d327395
attr Bad_WT_07dcf6 IODev MaxSystem
attr Bad_WT_07dcf6 alias Bad Wand
attr Bad_WT_07dcf6 comment 07dcf6 KEQ0244397
attr Bad_WT_07dcf6 room MAX,Bad

define Weblink_Bad_WT_07dcf6 SVG dblog_THB:THB_MAX_WMT:HISTORY
attr Weblink_Bad_WT_07dcf6 fixedrange week
attr Weblink_Bad_WT_07dcf6 group Max
attr Weblink_Bad_WT_07dcf6 label "Bad Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr Weblink_Bad_WT_07dcf6 plotfunction Bad_WT_07dcf6
attr Weblink_Bad_WT_07dcf6 room MAX,Bad

define Bad_HT_08a378 MAX HeatingThermostat 08a378
setuuid Bad_HT_08a378 5db11c92-f33f-9b0e-05f5-023d14e9206dfa7e
attr Bad_HT_08a378 IODev MaxSystem
attr Bad_HT_08a378 alias Bad HT
attr Bad_HT_08a378 comment 08a378 KEQ0337007
attr Bad_HT_08a378 room MAX,Bad


Woran kann das liegen.

Ich bitte um Hilfe.

Beste Grüße und vielen Dank

Thomas

[Jackson]

Hi,

was heißt du kannst die HT's und WT's nicht steuern? Manuell am Gerät oder über FHEM?

Hast du die HT's und WT's untereinander bekannt gemacht?

https://wiki.fhem.de/wiki/MAX#CUL_MAX

[thburkhart]

ich meine damit, dass ich Solltemperatur, Wochenprogramm über FHEm und entsprechende Frontends nicht einstellen kann.

Die WT/HTs funktionieren zwar per Tastendruck am Gerät und sind auch untereinander bekannt.

Ich kann z.B. eine Solltemperatur am Wandthermostat einstellen, nicht aber über FHEM. Das Ergebnis sehe ich dann in FHEM.

[Jackson]

OK...

* was zeigt dann das log?
* sind genug credits für den CUL verfügbar?
* und! hast du den WT mit den HT's untereinander angelernt gemäß Wiki?

[thburkhart]

- laut log habe 900 credits

- das Anlernen der WTs und HTs konnte ich nicht per FHEM machen, da die Geräte auch diesbezüglich nicht ansteuerbar waren


Muss ich denn Geräte herausnehmen, um mehr Credits zu erhalten ?

[don.redhorse]

Moin,

ich hänge mich hier mal rein, gleiches Problem..

Verbaut sind 8 HTs und drei SCs. Die HTs und SCs sind sich untereinander bekannt. Öffne ich ein Fenster wird der HT runtergedreht. Die Änderung open/close kann ich in FHEM sehen, ebenso die Änderung der Solltemperatur. Stelle ich einen Sollwert am HT direkt ein, wird die Änderung akzeptiert und auch in FHEM angezeigt. Ich kann aber keinen Sollwert via FHEM an die HTs schicken, ebensowenig z.B. von Man auf Auto schalten. Wochenprogramme werden ebenfalls nicht angenommen, es sieht fast so aus, als wären die HTs readonly.

Verbaut ist ein MaxCube, mit dem lief auch alles, im ganzen Haus. Nur schlug der CubeAlzheimer zu, deswegen ist der Cube zum CUBe umgeflasht:

Code Auswählen Erweitern


DeviceOverview CUBe

Initialized  CUBe
CUBe
Internals
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
CUBe_MSGCNT 4736
CUBe_TIME 2019-11-19 08:39:44
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.1.40:2323 0000
DeviceName 192.168.1.40:2323
FD 8
FHTID 0000
FUUID 5d527ba1-f33f-9edc-0132-31c8d5e480d9bb22
NAME CUBe
NR 34
NR_CMD_LAST_H 9
PARTIAL

RAWMSG  Z0F00046018BC2C0000000019091C008FF6
RSSI -79
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
initString X21
               Zr
               Za123456
               Zw111111

Readings cconf

freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB 2019-11-02 18:05:22
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 2019-11-13 21:40:51
credit10ms 2852 2019-11-19 08:42:12
fhtbuf AE 2019-11-02 17:57:23
raw No answer 2019-11-02 17:57:30
state Initialized 2019-11-19 08:39:44
uptime 0 00:07:05 2019-11-02 17:57:30
version V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz) 2019-11-02 17:57:34

Ein HT (WoZi)

Code Auswählen Erweitern

DeviceOverview
HT WZ Straße
14.2°C
MAX_18bc2c
Internals
DEF
HeatingThermostat 18bc2c
FUUID 5d528bcb-f33f-9edc-56db-d2f888398f4ea520
IODev cm
LASTInputDev cm
MSGCNT 758
NAME MAX_18bc2c
NR 40
RSSI -79
STATE 14.0 °C
TYPE MAX
addr 18bc2c
cm_MSGCNT 758
cm_TIME 2019-11-19 08:48:28
dstsetting 1
mode 1
rferror 0
type HeatingThermostat
ReadingsR SSI -79 2019-11-19 08:48:28
TimeInformationHour 1 2019-08-13 12:59:23
battery ok 2019-11-19 08:48:28
batteryState ok 2019-11-19 08:48:28
desiredTemperature 14.0 2019-11-19 08:48:28
groupid 0 2019-08-13 14:47:15
mode manual 2019-11-19 08:48:28
msgcnt 172 2019-11-19 08:41:32
panel unlocked 2019-11-19 08:48:28
rferror 0 2019-11-19 08:48:28
state 14.0 °C 2019-11-19 08:48:28
temperature 14.2 2019-11-19 08:48:28
valveposition 12 2019-11-19 08:48:28

Credits sind 3600 vorhanden, alle X Minuten werden es weniger und bauen sich wieder auf. Alles sieht so aus als würde es laufen, tuts aber nicht.
Dieses Haus ist derzeit nur zum WE bewohnt, deswegen auch die Temperatur bei 14°C, aber dieses Wochenende gehts wieder dorthin, wäre schön wenn ich vorher heizen könnte
In meiner Wohnung habe ich 6 HTs verbaut, an einem nanoCUL, dort läuft alles seit Jahren problemfrei, ich sehe auch keinen Unterschied zwischen beiden (Haus und Wohnung), nur das es im Haus nicht funktioniert. An der Reichweite liegt es ja nicht, sonst würden ja keine Readings stattfinden (?), ein HT ist im gleichen Raum mit dem CUBe, zumindest er sollte reagieren.

Das ist das Log von heute:

Code Auswählen Erweitern

2019.11.19 00:16:12 3: WARNING master device MAX_1a70a2 has no week profile - create default
2019.11.19 00:24:17 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 00:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 1a747e for 0fe104031234561a747e00131300a9f4
2019.11.19 00:48:49 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 00:48:49 3: WARNING master device MAX_1a70a2 has no week profile - create default
2019.11.19 01:25:47 3: WARNING master device MAX_1a107d has no week profile - create default
2019.11.19 01:34:30 3: WARNING master device MAX_1a70a2 has no week profile - create default
2019.11.19 01:34:57 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 01:35:35 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 01:36:09 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 01:41:01 3: WARNING master device MAX_1a70a2 has no week profile - create default
2019.11.19 01:41:31 3: WARNING master device MAX_18bcd6 has no week profile - create default
2019.11.19 01:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 1a70a2 for 0f9204031234561a70a200131301a9f3
2019.11.19 01:42:18 2: CUL_MAX_SendQueueHandler: Missing ack from 1781a3 for 0fdd04031234561781a300131301aace
2019.11.19 01:43:39 3: WARNING master device MAX_18bcd6 has no week profile - create default
2019.11.19 01:43:43 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 01:43:47 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 01:44:53 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 01:45:47 3: WARNING master device MAX_18bcd6 has no week profile - create default
2019.11.19 01:47:56 3: WARNING master device MAX_18bcd6 has no week profile - create default
2019.11.19 01:49:43 3: WARNING master device MAX_1a70a2 has no week profile - create default
2019.11.19 01:50:04 3: WARNING master device MAX_18bcd6 has no week profile - create default
2019.11.19 01:50:25 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 01:51:26 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 01:53:37 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 01:53:53 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 01:55:48 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 01:57:59 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 01:58:25 3: WARNING master device MAX_1a70a2 has no week profile - create default
2019.11.19 01:59:15 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 01:59:59 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 02:00:10 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 02:02:01 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 02:02:21 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 02:05:52 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 02:06:43 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 02:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 18bc2c for 0fab040312345618bc2c00131302a9f4
2019.11.19 02:42:18 2: CUL_MAX_SendQueueHandler: Missing ack from 1781aa for 0fe704031234561781aa00131302aace
2019.11.19 02:48:12 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 02:50:23 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 02:54:27 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 02:56:56 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 03:00:59 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 03:01:18 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 03:03:29 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 03:15:13 3: WARNING master device MAX_1a7144 has no week profile - create default
2019.11.19 03:18:45 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 03:29:41 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 03:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 18c102 for 0fb1040312345618c10200131303a9f3
2019.11.19 03:42:18 2: CUL_MAX_SendQueueHandler: Missing ack from 1a107d for 0f9904031234561a107d00131303aace
2019.11.19 03:58:04 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:02:26 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:04:37 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:06:48 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:08:59 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:09:32 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 04:13:21 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:17:43 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:39:33 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 1a7144 for 0ffb04031234561a714400131304a9f4
2019.11.19 04:42:18 2: CUL_MAX_SendQueueHandler: Missing ack from 17810f for 0f15040312345617810f00131304aacf
2019.11.19 04:46:06 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:48:17 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:54:50 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 04:57:01 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 05:04:45 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 05:27:35 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 05:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 18bcd6 for 0ff8040312345618bcd600131305a9f4
2019.11.19 05:58:09 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:00:20 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:02:31 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:04:42 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:06:53 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:08:47 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 06:09:04 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:10:44 3: WARNING master device MAX_1a70a2 has no week profile - create default
2019.11.19 06:17:48 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:39:38 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:41:49 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 1a747e for 0fe204031234561a747e00131306a9f4
2019.11.19 06:46:11 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:48:22 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:52:44 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:52:57 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 06:54:56 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 06:57:06 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 07:10:37 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 07:25:30 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 07:41:55 2: CUL_MAX_SendQueueHandler: Missing ack from 1a70a2 for 0f9304031234561a70a200131307a9f3
2019.11.19 07:42:18 2: CUL_MAX_SendQueueHandler: Missing ack from 1781a3 for 0fde04031234561781a300131307aace
2019.11.19 07:53:52 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 07:56:04 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 07:58:15 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:00:25 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:01:25 3: WARNING master device MAX_1781aa has no week profile - create default
2019.11.19 08:02:36 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:06:59 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:09:10 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:37:33 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:39:44 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:41:54 2: CUL_MAX_SendQueueHandler: Missing ack from 18bc2c for 0fac040312345618bc2c00131308a9f3
2019.11.19 08:42:15 2: CUL_MAX_SendQueueHandler: Missing ack from 1781aa for 0fe804031234561781aa00131308aacc
2019.11.19 08:44:05 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:48:28 3: WARNING master device MAX_18bc2c has no week profile - create default
2019.11.19 08:52:49 3: WARNING master device MAX_18bc2c has no week profile - create default

"WARNING master device MAX_1a7144 has no week profile - create default"

stimmt nicht, in FHEM ist eines hinterlegt.

"CUL_MAX_SendQueueHandler: Missing ack from 1781aa for 0fe804031234561781aa00131308aacc"

und was soll das? Das heisst doch, dass sich das HT nicht zurückmeldet?

Nach dem Umflashen sind alle HTs und SCs zurückgesetzt worden, Batterien raus, Affengriff und nacheinander angelernt worden, wobei ich mir nicht sicher bin ob die via Autocreate gefunden wurden, oder via Pairing von FHEM aus.

Was übersehe ich, was mache ich falsch?

[thburkhart]

"Nach dem Umflashen sind alle HTs und SCs zurückgesetzt worden, Batterien raus, Affengriff und nacheinander angelernt worden, wobei ich mir nicht sicher bin ob die via Autocreate gefunden wurden, oder via Pairing von FHEM aus."

Das könnte eine Erklärung sein, dass sich autoCreate die Devices im read-only mode greift.
Man könnte ja testen, autocreate mal temporär auszuschalten und neu zu pairen.
Ich selbst bin allerdings erst wieder in 3 Wochen at home.

Was sagen die Experten dazu? Oder ist es eher ein Credit-Problem?

[don.redhorse]

Das könnte eine Erklärung sein, dass sich autoCreate die Devices im read-only mode greift.

Auf diese Idee bin ich gar nicht gekommen, hmm, kann ich auch erst am Wochenende ausprobieren.

Oder ist es eher ein Credit-Problem?

Eher unwahrscheinlich. Die Credits würden druchlaufen und mit ihnen würde etwas passieren, es würden auf jeden Fall teile eines Wochenprogrammes übertragen, oder zumindest eine Temperatur richtig eingestellt, oder sonst irgendetwas.
Wenn ich in der Wohnung alle Wochenprogramme überschreibe und nebenher den MAX Scanner laufen haben, kann es mal nen ganzen Abend dauern bis alles übertragen ist. Im Haus ist es aber so das die Credits auf 3600 stehen, ab und an weniger werden, sich aber eben wieder aufbauen. Will ich aber einen Wert von via FHEM einstellen laufen die Credits runter, oder das etwas passiert.

Ich teste jetzt mal. Credits sind 3600 vorhanden. Jetzt setze ich einen HT um 1 K hoch. Wert ist nicht angenommen worden, aber Credits gehen runter. Habe es wiederholt und dabei ein Tab mit dem Eventmonitor offen:

Code Auswählen Erweitern

2019-11-19 10:38:50 MQTT myBroker connection: active
2019-11-19 10:39:02 CUL CUBe credit10ms: 3215
2019-11-19 10:39:05 CUL CUBe credit10ms: 3218
2019-11-19 10:39:08 CUL CUBe credit10ms: 3220
2019-11-19 10:39:10 CUL CUBe credit10ms: 3223
2019-11-19 10:39:27 CUL CUBe credit10ms: 3240
2019-11-19 10:39:27 weekprofile WP_Buero profile_count: 1
2019-11-19 10:39:27 MAX MAX_1a7144 desiredTemperature 15.0
2019-11-19 10:39:33 CUL CUBe credit10ms: 3136
2019-11-19 10:39:39 CUL CUBe credit10ms: 3034
2019-11-19 10:39:46 CUL CUBe credit10ms: 2931
2019-11-19 10:39:49 CUL_MAX cm packetsLost: 3123
2019-11-19 10:39:50 MQTT myBroker connection: active
2019-11-19 10:40:06 CUL CUBe credit10ms: 2841
2019-11-19 10:40:18 CUL CUBe credit10ms: 2854
2019-11-19 10:40:18 weekprofile WP_Buero profile_count: 1
2019-11-19 10:40:18 MAX MAX_1a7144 desiredTemperature auto
2019-11-19 10:40:25 CUL CUBe credit10ms: 2751
2019-11-19 10:40:31 CUL CUBe credit10ms: 2648
2019-11-19 10:40:38 CUL CUBe credit10ms: 2545
2019-11-19 10:40:41 CUL_MAX cm packetsLost: 3124
2019-11-19 10:40:50 MQTT myBroker connection: active
2019-11-19 10:41:14 MAX MAX_177d03 battery: ok
2019-11-19 10:41:14 MAX MAX_177d03 batteryState: ok
2019-11-19 10:41:14 MAX MAX_177d03 rferror: 0
2019-11-19 10:41:14 MAX MAX_177d03 onoff: 0
2019-11-19 10:41:14 MAX MAX_177d03 closed
2019-11-19 10:41:14 MAX MAX_177d03 RSSI: -54
2019-11-19 10:41:32 CUL CUBe credit10ms: 2490
2019-11-19 10:41:39 CUL CUBe credit10ms: 2384
2019-11-19 10:41:45 CUL CUBe credit10ms: 2278
2019-11-19 10:41:50 MQTT myBroker connection: active
2019-11-19 10:41:52 CUL CUBe credit10ms: 2172
2019-11-19 10:41:55 CUL_MAX cm packetsLost: 3125
2019-11-19 10:41:55 CUL CUBe credit10ms: 2063
2019-11-19 10:42:00 weekprofile Wohnzimmer profile_count: 1
2019-11-19 10:42:00 MAX MAX_18bc2c mode: manual
2019-11-19 10:42:00 MAX MAX_18bc2c battery: ok
2019-11-19 10:42:00 MAX MAX_18bc2c batteryState: ok
2019-11-19 10:42:00 MAX MAX_18bc2c panel: unlocked
2019-11-19 10:42:00 MAX MAX_18bc2c rferror: 0
2019-11-19 10:42:00 MAX MAX_18bc2c desiredTemperature: 14.0
2019-11-19 10:42:00 MAX MAX_18bc2c temperature: 14.4
2019-11-19 10:42:00 MAX MAX_18bc2c valveposition: 8
2019-11-19 10:42:00 MAX MAX_18bc2c 14.0 °C
2019-11-19 10:42:00 MAX MAX_18bc2c RSSI: -79.5
2019-11-19 10:42:02 CUL CUBe credit10ms: 1957
2019-11-19 10:42:08 CUL CUBe credit10ms: 1851
2019-11-19 10:42:15 CUL CUBe credit10ms: 1745
2019-11-19 10:42:18 CUL_MAX cm packetsLost: 3126
2019-11-19 10:42:50 MQTT myBroker connection: active
2019-11-19 10:43:21 CUL CUBe credit10ms: 1699
2019-11-19 10:43:25 CUL CUBe credit10ms: 1703
2019-11-19 10:43:28 CUL CUBe credit10ms: 1706
2019-11-19 10:43:36 CUL CUBe credit10ms: 1714
2019-11-19 10:43:50 MQTT myBroker connection: active
2019-11-19 10:43:56 CUL CUBe credit10ms: 1734
2019-11-19 10:44:11 weekprofile Wohnzimmer profile_count: 1
2019-11-19 10:44:11 MAX MAX_18bc2c mode: manual
2019-11-19 10:44:11 MAX MAX_18bc2c battery: ok
2019-11-19 10:44:11 MAX MAX_18bc2c batteryState: ok
2019-11-19 10:44:11 MAX MAX_18bc2c panel: unlocked
2019-11-19 10:44:11 MAX MAX_18bc2c rferror: 0
2019-11-19 10:44:11 MAX MAX_18bc2c desiredTemperature: 14.0
2019-11-19 10:44:11 MAX MAX_18bc2c temperature: 14.4
2019-11-19 10:44:11 MAX MAX_18bc2c valveposition: 9
2019-11-19 10:44:11 MAX MAX_18bc2c 14.0 °C
2019-11-19 10:44:11 MAX MAX_18bc2c RSSI: -79


Habe jetzt eine neue Suche im Forum gestartet, mit Autocreate im Text und siehe da, es gibt da mehre Fälle, u.a. diesen:
https://forum.fhem.de/index.php/topic,96215.0.html

[Jackson]

@don.redhorse:
Ich habe meinen Cube auch umgeflasht. Und nutze die gleiche Version wie du

Code Auswählen Erweitern

VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)

Allerdings betreibe ich ihn nicht über LAN sondern komplett über USB.

@don.redhorse @thburkhart

Da ich mein FHEM neu aufgesetzt habe, sind auch die Geräte neu angelegt worden. Daher musste ich auch das WeekProfile im FHEM neu anlegen. Ich bin mir nicht sicher, ob die HT's nach dem Rücksetzen ein Standardheizprofil bekommen..?? Vielleicht auf dem Gerät, FHEM weiß davon sicher nichts. Selbst wenn ihr ein altes Gerät (also voher über MAXCUBE) über das IODev auf "cm" stellt anstelle "ml" muss nach dem Rücksetzten des HT's das Weekprofile für FHEM neugesetzt werden.

Die Credits von 900 sind Standard und reichen aus. Problematisch wird das nur wenn der CUBE ungünstig steht. Dann sind die Credits schnell weg.

[don.redhorse]

das umflashen habe ich diesen frühen Sommer gemacht, vor einigen Wochen nocheinmal auf die aktuelle Version aktualisiert. FHEM habe ich im Zuge dessen komplett von MAX! befreit und alles neu angelegt, die HTs eben vorher resettet. Es müsste alles neu sein, ich bin mir jetzt aber sicher das es an Autocreate liegt, die sind nicht richtig gepaired worden, daran wird es liegen. Das gib Donnerstag Abend, wenn wir wieder im Haus sind, richtige Haue von Frauchen weil die Bude kalt ist...

Offenbar ist das ganze bei mir ein mischmasch aus rest Cube Steuerung, Haussteuerung und neu CUBe via FHEM, d.h. die ganze resetterei und anlernerrei hat nicht funktioniert. Wenn SC und HT gepaired ist kann FHEM offenar nur lauschen würde auch den RF Error erklären:

Code Auswählen Erweitern

Internals:
   DEF        HeatingThermostat 1a7144
   FUUID      5d87e2cf-f33f-9edc-f27e-75a847bd1a7bb190
   IODev      cm
   NAME       MAX_1a7144
   NR         48
   RSSI       -50.5
   STATE      14.0 °C (rf error)
   TYPE       MAX
   addr       1a7144
   type       HeatingThermostat
   READINGS:
     2019-11-19 03:15:13   RSSI            -50
     2019-09-23 00:04:42   TimeInformationHour 3
     2019-11-19 03:15:13   battery         ok
     2019-11-19 03:15:13   batteryState    ok
     2019-11-19 03:15:13   desiredTemperature 14.0
     2019-10-06 13:07:22   groupid         0
     2019-11-19 03:15:13   mode            manual
     2019-11-19 10:41:32   msgcnt          255
     2019-11-19 03:15:13   panel           unlocked
     2019-11-19 03:15:13   rferror         1
     2019-11-19 03:15:13   state           14.0 °C (rf error)
     2019-11-19 03:15:13   temperature     14.3
     2019-11-19 03:15:13   valveposition   19
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      cm
   alias      HT Büro
   room       Büro

[thburkhart]

"Problematisch wird das nur wenn der CUBE ungünstig steht. Dann sind die Credits schnell weg."

Der CUL ist bei mir in der Mitte des Hauses platziert. Dennoch werden die oberen Tele des Hauses nicht so gut erreich, wie die unteren.
Kann es sein, dass die Credits bei den Verbindungsversuchen zu den weniger gut erreichbaren Devices verbraucht werden und deshalb auch die nahegelegenen Devices nicht geschrieben werden können.?

Kann man irgendwo sehen, wie die Devices verbunden sind readonly oder write?

[don.redhorse]

wenn ich nachher wieder in der Wohnung bin vergleiche ich zwei HTs mal mit einem list <device> miteinander, vielleicht sieht man da etwas.

Mit den Credits geht der CUL eigentlich reihum, wenn also das erste Gerät in der Liste fertig ist, gehts zum nächsten etc. So werden auch die Wochenprofile nacheinander übertragen, ändert man alle kann es echt lange dauern. Aber über nen Tag gesehen sollten alle erreicht werden, wenn sie denn erreichbar sind. Ausserdem machen die doch eh so eine Art Mesh Netz auf, oder nicht?
Lasse mal den Event Monitor neben her laufen, da kann man eigentlich wunderbar sehen wo es harkt, wenn er mal einen nicht richtig bekommt.

[thburkhart]

ich füge mal screenshots bei:

Treppenhaus ist 1 m vom CUL entfernt
Bad ca. 8 m

die RSSI-Werden liegen mit -60 und -67 ja eng beieinander

im Eventmonitor sehe ich viel Trafffc auch meinen 12 Lacrosse-Thermometern.
Zählen hier die Credits mit?

wäre ein 2ter CUL dedizidiert für MAX besser?

[rudolfkoenig]

Die Credits sind dafuer da, um das Gesetz (Max. 1% Sendezeit pro Teilnehmer falls kein LBT implementiert ist) einzuhalten.
Es geht darum, dass andere Teilnehmer (z.Bsp. die Thermostaten des Nachbars) eine realistische Chance haben, zu kommunizieren.
Wie das Gesetz genau zu interpretieren ist (ist FHEM ein Teilnehmer, oder ein CUL?), muesste ein Gericht entscheiden.
Das Problem koennte mAn legal geloest werden, falls jemand LBT (Listen Before Talk) im Firmware implementiert.

RSSI ist mit Lautstaerke vergleichbar.
Ist aber je nach Umgebung (Party vs. Bibliothek) unterschiedlich zu bewerten.

[thburkhart]

interpretiere ich die beiden RSSI-Werte -6x insofern richtig, dass nicht ein Reichweitenproblem vorliegt ?

natürlich möchte ich mich an die Gesetze halten..
Die Credits werden als an den FHEM server insgesamt vergeben?
Ist es richtig, dass ich ingesamt ein Credit-Problem habe und diese möglicherweise durch den Lacrosse-Traffic verstärkt werden (die Lacrosse liegen übrigens auf einem separaten JEELINK) ?
Der CUL ist also bereits exclusiv für MAX da.

[rudolfkoenig]

interpretiere ich die beiden RSSI-Werte -6x insofern richtig, dass nicht ein Reichweitenproblem vorliegt ?

Haengt davon ab, ob bei Dir "Party" ist
Ein RSSI von -60 bedeutet ein starkes Signal, ich habe welche aber auch mit -97 schon gesehen ("Bibliothek").

Die Credits werden als an den FHEM server insgesamt vergeben?

Nein, die Zaehlung erfolgt mW im culfw.

Ist es richtig, dass ich ingesamt ein Credit-Problem habe und diese möglicherweise durch den Lacrosse-Traffic verstärkt werden (die Lacrosse liegen übrigens auf einem separaten JEELINK)

Ob du ein "Credit-Problem" hast, muesstest du an "LOVF" (Limit OverFlow) Ausgaben im FHEM-Log sehen.
Generell: wenn viel ueber die gleiche(!) Frequenz kommuniziert wird (== Party), dann kann es zu Stoerungen kommen, unabhaengig vom Credit.

[thburkhart]

Haengt davon ab, ob bei Dir "Party" ist
Ein RSSI von -60 bedeutet ein starkes Signal, ich habe welche aber auch mit -97 schon gesehen ("Bibliothek").
Nein, die Zaehlung erfolgt mW im culfw.
Ob du ein "Credit-Problem" hast, muesstest du an "LOVF" (Limit OverFlow) Ausgaben im FHEM-Log sehen.
Generell: wenn viel ueber die gleiche(!) Frequenz kommuniziert wird (== Party), dann kann es zu Stoerungen kommen, unabhaengig vom Credit.

ich habe dann wohl definitiv viel "Party"

als summary für die Problemstellung kommen also als Ursachen in Betracht:

1) zuviel "Party" und Lösungsansatz JEELINK mit heftigem LaCrosse-Traffic mal herausnehmen.
2) über autodetect angelernt und Lösungsansatz: autodetect deaktivieren und devices resetten und neu pairen

oder gibt es weitere mögliche Ursachen ?

[don.redhorse]

@thburkhart

die Lacross sind doch nur Temperatur - Feuchte Sensoren? In welchen Abständen funken die denn? Wenn du die nur pollst, dann setze den Intervall mal hoch, man benötigt nicht jede Minute die Temperatur, alle 10 reicht auch für einen sinnvolle Aufzeichnung. Damit nimmst du schon einmal viel Traffic raus.
Das Übertragen von kompletten Wochenprogrammen an 8 Thermostaten dauert sicherlich ein paar Stunden, aber auch das läuft innerhalb eines Abends durch, auch wenn andere Geräte (deine Lacross) da stören. Ein Problem mit den Credits sehe ich da nicht. Das wird am falschen anlernen liegen, bzw. ein Fehler mit Autocreate, oder aber, sind noch HTs und WTs miteinander assoziiert? Wenn z.B. das HT resettet wurde, der WT aber nicht, kann es gut sein das FHEM dann nicht als Master läuft und deswegen keine Sollwerte vorgeben kann. Zumindest ist es das was ich mir bis jetzt aus vielen anderen Beiträgen zusammen gereimt habe, Stichwort aber Autocreate gewesen, davor habe ich der Suche wohl immer die falschen Fragen gestellt...

[thburkhart]

@don.redhorse

bingo; als dein Plan mit disable autocreate scheint der Zielführenste

ich kann das leider bei mir erst in 3 Wochen ausprobieren; und du wirst sicher berichten

Herzliche Grüße

Thomas

[Jackson]

@don.redhorse:
Ich habe meinen Cube auch umgeflasht. Und nutze die gleiche Version wie du

Code Auswählen Erweitern

VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)

Allerdings betreibe ich ihn nicht über LAN sondern komplett über USB.

@don.redhorse @thburkhart

Da ich mein FHEM neu aufgesetzt habe, sind auch die Geräte neu angelegt worden. Daher musste ich auch das WeekProfile im FHEM neu anlegen. Ich bin mir nicht sicher, ob die HT's nach dem Rücksetzen ein Standardheizprofil bekommen..?? Vielleicht auf dem Gerät, FHEM weiß davon sicher nichts. Selbst wenn ihr ein altes Gerät (also voher über MAXCUBE) über das IODev auf "cm" stellt anstelle "ml" muss nach dem Rücksetzten des HT's das Weekprofile für FHEM neugesetzt werden.

Die Credits von 900 sind Standard und reichen aus. Problematisch wird das nur wenn der CUBE ungünstig steht. Dann sind die Credits schnell weg.

Meine verwendete Version für den MAX_CUL ist doch eine andere..

Code Auswählen Erweitern

V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 868MHz)

Einen Jeelink Stick hatte ich auch im System.... In wie fern diese aber für Störungen verantwortlich sein kann, kann ich nicht sagen. Wurde durch Zigbee2MQTT abgelöst

[don.redhorse]

das ist das List <Device> in der Wohnung mit dem nanoCul

Code Auswählen Erweitern

Internals:
   CULMAX_MSGCNT 219
   CULMAX_TIME 2019-11-19 23:03:03
   DEF        HeatingThermostatPlus 13b0f2
   FUUID      5c48c25e-f33f-3581-ecca-fde2378e50552a1a
   IODev      CULMAX
   LASTInputDev CULMAX
   MSGCNT     219
   NAME       MAX_13b0f2
   NR         89
   RSSI       -44.5
   STATE      16.0 °C
   TYPE       MAX
   addr       13b0f2
   backend    CULMAX
   dstsetting 1
   mode       1
   rferror    0
   type       HeatingThermostatPlus
   READINGS:
     2019-11-19 23:03:03   RSSI            -44.5
     2017-02-21 16:57:27   TimeInformationHour 0
     2019-11-19 23:03:03   battery         ok
     2019-11-19 23:03:03   batteryState    ok
     2019-11-19 23:03:03   desiredTemperature 16.0
     2017-03-03 17:58:55   ecoTemperature  17
     2019-04-14 15:13:03   firmware        1.0
     2019-04-14 15:13:03   groupid         0
     2019-11-19 23:03:03   mode            manual
     2019-11-19 23:01:00   msgcnt          149
     2019-11-19 23:03:03   panel           unlocked
     2019-11-19 23:03:03   rferror         0
     2019-11-19 23:03:03   state           16.0 °C
     2019-11-19 23:03:03   temperature     18.4
     2019-04-14 15:13:03   testresult      0
     2019-11-19 23:03:03   valveposition   0
     2019-10-03 20:50:39   weekprofile-0-Sat-temp 16.0 °C  /  18.0 °C  /  16.0 °C
     2019-10-03 20:50:39   weekprofile-0-Sat-time 00:00-16:00  /  16:00-23:00  /  23:00-00:00
     2019-10-03 20:50:39   weekprofile-1-Sun-temp 16.0 °C  /  18.0 °C  /  16.0 °C
     2019-10-03 20:50:39   weekprofile-1-Sun-time 00:00-16:00  /  16:00-23:00  /  23:00-00:00
     2019-10-03 20:50:39   weekprofile-2-Mon-temp 16.0 °C  /  18.0 °C  /  16.0 °C
     2019-10-03 20:50:39   weekprofile-2-Mon-time 00:00-16:00  /  16:00-23:00  /  23:00-00:00
     2019-10-03 20:50:39   weekprofile-3-Tue-temp 16.0 °C  /  18.0 °C  /  16.0 °C
     2019-10-03 20:50:39   weekprofile-3-Tue-time 00:00-16:00  /  16:00-23:00  /  23:00-00:00
     2019-10-03 20:50:39   weekprofile-4-Wed-temp 16.0 °C  /  18.0 °C  /  16.0 °C
     2019-10-03 20:50:39   weekprofile-4-Wed-time 00:00-16:00  /  16:00-23:00  /  23:00-00:00
     2019-10-03 20:50:39   weekprofile-5-Thu-temp 16.0 °C  /  18.0 °C  /  16.0 °C
     2019-10-03 20:50:39   weekprofile-5-Thu-time 00:00-16:00  /  16:00-23:00  /  23:00-00:00
     2019-10-03 20:50:39   weekprofile-6-Fri-temp 16.0 °C  /  18.0 °C  /  16.0 °C
     2019-10-03 20:50:39   weekprofile-6-Fri-time 00:00-16:00  /  16:00-23:00  /  23:00-00:00
   helper:
     DesiTime   1574092803
     LastCmdDate 1574200860.14206
     NextScan   1574201866
     NextScanTimestamp 2019-11-19 23:17:46
     TempBeforeWindOpen 16.0
     TemperatureTime 1574200983
     WinWasOpen 0
     desiredOffset 0
     gotTempTS  1
     leadDesiTemp 16.0
     switchDate 1574204400
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      CULMAX
   alias      Büro
   group      Klima
   homebridgeMapping TargetTemperature=desiredTemperature::desiredTemperature,minValue=5,maxValue=35,minStep=0.5,nocache=1 CurrentTemperature=temperature
   keepAuto   0
   room       Büro,Heizkörper,homekit
   scanTemp   1
   scnModeHandling AUTO
   scnProcessByDesiChange 0
   sortby     13
   userattr   scnProcessByDesiChange:0,1 scnShutterList scnModeHandling:NOCHANGE,AUTO,MANUAL

Und dieses wieder das im Haus mit dem CUBe

Code Auswählen Erweitern

Internals:
   DEF        HeatingThermostat 1a7144
   FUUID      5d87e2cf-f33f-9edc-f27e-75a847bd1a7bb190
   IODev      cm
   LASTInputDev cm
   MSGCNT     14
   NAME       MAX_1a7144
   NR         48
   RSSI       -50.5
   STATE      14.0 °C (rf error)
   TYPE       MAX
   addr       1a7144
   cm_MSGCNT  14
   cm_TIME    2019-11-19 22:41:05
   dstsetting 1
   mode       1
   rferror    1
   type       HeatingThermostat
   READINGS:
     2019-11-19 22:41:05   RSSI            -50.5
     2019-09-23 00:04:42   TimeInformationHour 3
     2019-11-19 22:41:05   battery         ok
     2019-11-19 22:41:05   batteryState    ok
     2019-11-19 22:41:05   desiredTemperature 14.0
     2019-10-06 13:07:22   groupid         0
     2019-11-19 22:41:05   mode            manual
     2019-11-19 22:06:51   msgcnt          1
     2019-11-19 22:41:05   panel           unlocked
     2019-11-19 22:41:05   rferror         1
     2019-11-19 22:41:05   state           14.0 °C (rf error)
     2019-11-19 22:41:05   temperature     13.9
     2019-11-19 22:41:05   valveposition   19
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      cm
   alias      HT Büro
   room       Büro

Das Wochenprogramm oben ist via FHEM übertragen worden, mit dem CUBe klappte das nicht. Wird wahrscheinlich am nicht richtig durchgeführten Reset liegen, Freitag Nachmittag sollte ich nen Stündchen dafür frei bekommen, hoffe ich mal..

[don.redhorse]

Habe nun frei bekommen, nunja, gleich wird's Ärger geben. Küche sieht aus wie Bombe, Frau bringt Tochter ins Bett. Gestern habe ich nur deswegen überlebt weil ich alles übernommen habe im Haus, war aber auch sau kalt in der Bude, wie schön das so nen Holzofen schnell Wärme bringt. Tochter hatte trotzdem einen Schneeanzug an (9 Monate).

Aber btT:

Es ist wie es geschrieben wurde, eigentlich ganz einfach. Autocreate habe ich erstmal auf disable 1 gesetzt, dann den HT im Büro gelöscht und FHEM neu gestartet. Danach dem HT eine Batterie geklaut, kurz gewartet, den Affengriff durchgeführt (habe noch nen Krampf im Finger) und die Batterie wieder eingesetzt. Im Display erscheint RES, danach halt INS und ADP. Danach am cm (so heisst mein zum CUNO gemachter Cube) das Pairing angeworfen, am HT gestartet und zack, 5 sec. später stand da AC das Funkzeichen blinkte und blieb dann fix stehen. Zum Rechner hin, Temperatur eingestellt und, jau, sie wurde übernommen. Also ganz klar ein 60 cm Bug, der Fehler saß vor dem Monitor. Ich habe entweder FHEM nicht neu gestartet, oder, den Reset durchgeführt und erst dann gelöscht und neu gestartet. Ich weiss genau das ich bei allen HTs das RES und das Neueinrichten durchgeführt habe. Ich bin mir aber nicht sicher ob ich die HTs vorher gelöscht hatte, ich glaube ich hatte erst alles resettet, dann alles was mit MAX! zu tun hatte in FHEM gelöscht und eben neu gebootet. Die HTs werden sich dann aber schon gepairt haben. Sie tauchten auf jeden Fall nacheinander wieder automatisch auf. Da es im Sommer war habe ich nur gedacht: "super, läuft ja klasse", nix lief, alles falsch gemacht..

Auf zu nächsten HT..

[Wzut]

Sie tauchten auf jeden Fall nacheinander wieder automatisch auf.

und genau hier liegt IMHO eines der größten Probleme der MAX Module :
die Dinger werden mittels autocreate angelegt weil der CUL bzw. das CUL_MAX Device ein Telegramm davon gesehen hat ohne Rücksicht ob am CM Device überhaupt der pairmode aktiv ist. So bekommt man wunderbare readonly MAX Geräte in FHEM !
HM ist da ein bissel schlauer , es listet die unbekannten IDs nur als Reading in der VCCU ohne gleich aus jedem Schrotttelgramm ein komplettes Device zu erzeugen.
Aus dem Grund rate ich immer dringend autocreate auf disable zu setzen.[

Danach am cm (so heisst mein zum CUNO gemachter Cube) das Pairing angeworfen

kann nicht sein cm (14_CUL_MAX.pm) und CUNO/CUL/CUBE (00_CUL.pm) sind zwei verschiedene Geräte !

[thburkhart]

das heißt also:

des Rätsels Lösung ist :

autocreste disable

und ein Schneeanzug für die Tochter

ich versuche das nächste Woche auch

Gesendet von meinem SM-G950F mit Tapatalk

[don.redhorse]

warme Gedanken machen dabei nicht vergessen

Das Autocreate teste ich gleich aus. Zweiter HT läuft jetzt auch (Bad) und der SC (Fensterkontakt) funktioniert auch, seltsamerweise wird das HT nicht umgeschaltet bei Fenster offen, was ist das jetzt wieder?

Die Reihenfolge ist wohl wichtig:

Batterie raus
in FHEM das Device löschen
shutdown restart (ganz wichtig)
Affengriff mit Batterie rein
InS und ADP abwarten
CUBe in Pairmode bringen
HT in Pairmode
AC und Verbindungsaufbau abwarten
define MAX_xxx MAX HeatingThermostat xxx / HT anlegen

Test durchführen ob Temp eingestellt werden kann.

[don.redhorse]

und genau hier liegt IMHO eines der größten Probleme der MAX Module :
die Dinger werden mittels autocreate angelegt weil der CUL bzw. das CUL_MAX Device ein Telegramm davon gesehen hat ohne Rücksicht ob am CM Device überhaupt der pairmode aktiv ist. So bekommt man wunderbare readonly MAX Geräte in FHEM !

Unschön finde ich dabei nur das man es nicht direkt sieht. Als ich das ganze im Sommer umgestellt habe tauchten sie wieder auf, Temperaturen wurden angezeigt, sie haben auf ihre Fensterkontakte reagiert, die Änderungen habe ich in FHEM gesehen und ich dachte alles ist gut. Habs halt nicht getestet, ganz klar mein Fehler. Ist halt nicht wirklich DAU tauglich das ganze, aber ich kann vom Entwickler ja auch auch nicht verlangen das er mich bis ans Ende an die Hand nimmt, sollte vielleicht ein kleiner Vermerk ins Wiki, aber statt hier zu meckern heisst es selber machen ist jetzt wohl meine Aufgabe..

HM ist da ein bissel schlauer , es listet die unbekannten IDs nur als Reading in der VCCU ohne gleich aus jedem Schrotttelgramm ein komplettes Device zu erzeugen.
Aus dem Grund rate ich immer dringend autocreate auf disable zu setzen.

Mein Fehler, habs nicht gemacht.

 

kann nicht sein cm (14_CUL_MAX.pm) und CUNO/CUL/CUBE (00_CUL.pm) sind zwei verschiedene Geräte !

CUNO ist auch falsch, ist ein mit a-culfw geflashter Cube, habe ihn halt "cm" genannt

[Wzut]

CUNO ist auch falsch, ist ein mit a-culfw geflashter Cube, habe ihn halt "cm" genannt

ganz schlechte Idee ... denn so entsteht die Verwirrung und ggf. Fehler
cm = CUL_MAX Device , denn hier muss das paring angeworfen werden ( set pairmode 1 ) und nicht wie bei HM direkt am CUL ( set CUL hmPaiForSec  Zeit) 

[don.redhorse]

jetzt bin ich verwirrt:

Wiki:

Dazu muss der "pairmode" auf MAXLAN mit

set ml pairmode
bzw. bei CUL_MAX mit

set cm pairmode

Ein geflashter Cube ist doch ein CUBe ist doch wie ein CUNO und damit "cm"? MAXLAN war er doch nur mir der (vergesslichen) original Firmware "ml"

Also mein CUBe meldet sich als "CUL" und der cm als CUL_MAX, siehe auch die beiden Screenshots.

[Wzut]

ok, ich geb auf
du schreibst doch : CUBe in Pairmode bringen
und genau das stimmt nicht ! denn es ist das cm

Bei MAXLAN (ml) gibt es nur dieses eine IO Device für alle MAX Geräte.
D.h. IODev -> Device   ( genau wie bei HomeMatic und anderen )

Sobald aber ein CUL oder umgeflashter CUBE ins Spiel kommt wird das Ganze leider dreistufig
IODev -> CUL_MAX -> Device

und das Wiki geht nun mal davon aus das man sein CUL_MAX Device cm genannt hat

[don.redhorse]

Ah, sorry, dass meintest du. Ja sind zweie und natürlich pairmode im ,,cm" hatte die jetzt zusammen als Ganzes gesehen. Ist ja nur ein physikalische vorhandenes Gerät das in Fhem zweigeteilt dargestellt wird, habe dass immer nur als ein Gerät gesehen, halt mit zwei Seiten. Ist natürlich unsauber ja.

[don.redhorse]

habe gerade zwei Thermostate mit Autocreate disable 0 angelernt. Läuft auch ohne Probleme. Dieses Mal habe ich nur alle einen nach dem anderen resettet und neu angelernt. Vom Aufwand ist es IMHO aber egal, ob man ein define MAX_1a107d MAX HeatingThermostat 1a107d schreibt und dann Alias und Raum zuweist, oder in den Raum MAX geht, das HT öffnet und zuweist.. Nun denn, am Autocreate liegt es nicht es wird die Reihenfolge sein in der man das macht. Schätze im Sommer bin ich auch gegen Credit Ende gelaufen, da ich alles auf einen Schlag resettet und neu angelernt habe. Wie auch immer:
kaum macht man es Richtig, schon funktioniert.

Einen Dank an alle die hier Tipps gegeben haben!

Autocreate kann doch dazwischenfunken.
Letztes HT resettet, Ins abgewartet ADP läuft, kurz weg, einige Minuten später am "cm" den Pairmode gestartet, zum HT hin und anlernen wollen. Zeit lief ab, nichts passierte. Zum Rechner zurück, Fragezeichen bei save config. Da hat Autocreate das Device angelegt, der Pairingprozess war aber nicht abgeschlossen. Sehe gerade das mir die Credits weglaufen, kann also die Kombination aus Credits Ende und Autocreate sein. War ja klar, beim letzten HT...
Lässt man die Devices mit Autocreate erzeugen werden auch gleich die Wochenprogramme übertragen, ist also gleich alles auf einen Schlag fertig. Kostet natürlich Credits und damit schafft man dann nur zwei drei HTs je Stunde.. und das Timing muss passen.

[thburkhart]

ist es nicht so, dass durch das pairing das gerät angelegt wird und ganz unten in der fhem.cfg neu erscheint; das ist dann also nich durch autocreate bedingt

ich habe es so verstanden:

a) pairing  definiert mit writable
b) autocreate definiert mit readonly

was die Zeit betrifft ist also Geduld angesagt.. als sicherheitshalber nur alle Stunde ein Gerät neu hereinnehmen

richtig ?

[don.redhorse]

Autocreate legt auch korrekt writable an. Wenn die Credits ausgehen wird es aber nur angelegt, dass HT weiß davon aber nix, dann ist es nur readable. So hat sich das bei mir gezeigt. Testweise habe ich später, als wieder Credits da waren eines neu angelegt, wieder mit Autocreate, läuft alles richtig. Die Credits sind weggelaufen, da ich noch Wochenprogramme hatte die übertragen wurden und das dauert.

Auch zwei auf einmal anlernen ist kein Problem. Nur im CUBe einmal die Credits überprüfen und im cm dann das pairen starten.

[Wzut]

Gerade zu Thema pairing gibt es viele Mythen und Unwahrheiten !
Ich habe gestern Abend bei mir einiges getestet unter harten Bedinungen -> Test MAX Wolke mit andere ID neben meiner aktiven MAX Umgebung.
( ich kann davon nur dringend jedem abraten, das Chaos will erst einmal verstanden und beherscht werden )
Zur gleichen Zeit habe ich mir auch die MAX Module intensiv angeschaut und geändert.
Also Thema Pairing ( wer mir nicht glaubt schaue in die Module und die Kommentare dort von Mathias Gehre )
Wenn autocreate an ist :
sobald CUL_MAX ein Telegramm vom CUL/CUBE bekommt was halbwegs nach einem MAX Gerät ausschaut legt autocreate das komplette Device an,
egal ob am cm Device der pairmode aktiv ist oder nicht !!! es spielt auch keine Rolle ob man am Gerät den pairing Modus aktiviert hat, d.h. Batterie neu einlegen oder ein Status von einem anderen Gerät an eine andere Zentrale reicht schon dafür aus.
Das System versucht jetzt natürlich mit dem neuen Device weiter zu reden, d.h. bei HTs / WTs das Wochenprogramm zu ziehen.
Entspricht also fast genau den Erfahrungen von don.redhorse.

wie ich schon schrieb kann dieses Verhalten für den User zwar recht einfach sein, kann aber auch zu Frust führen wenn autocreate irgend einen Mist anlegt und dann die Creadits sinnlos verbraten werden weill das Device nicht die Antworten gibt die FHEm gerne hätte. Beispiel :
Wie ich oben schrieb hatte ich eine zweite MAX Wolke am Start. Sobald jetzt System A die cm ID des anderen System B sieht legt er ein Device an (und umgekehrt),
danach rappelt es nur noch so in beiden Logs. Die Credits können sich nicht mehr erholen und die Send Queues werden nie mehr leer


 

[thburkhart]

A) kann man als Zusammenfassung nun aller Mythen sagen,

dass man mit

a) disable autocreate
b) alle Geräte rausnehmen (damit sie hinzukommende Neulinge nicht  noch vor deren eigentlichem pairen read-only anlegen lassen)
c) device auf Werkseinstellung, Befehle pair und save
d) restart FHEM ( (wie kann man erkennen, dass echtes pairen erfolgt ist und  Übertragen der Profile möglich und erfolgreich abgeschlossen ist?)
e)  danach 1h warten und

auf der sicheren Seite ist?

B)
andere Überlegung; um das langwierige Verfahren A) etwas zu verkürzen..

wenn man Wandthermostate verwendet, ist da nötig, dass die HTs von FHEM geschrieben werden können.?
Sie tauschen sich ja direkt mit dem jeweiligen WT aus, von dem sie auch die aktuelle Soll-Temperator oder Boost bekommen.

Insofern müsste es doch genügen, wenn die WTs writable sind also Sinne von wzut wirklich gepairt sind

richtig?

[Wzut]

Mir gefallen diese neuen Begriffe read-only und writeable gar nicht ....
das sind völlig neue Worte in Verbindung mit MAX und sorgen vermutlich nur für noch mehr Verwirrung.

Es gibt in FHEM nur zwei Sorten MAX Geräte : gepaired und eben ungepaired     

[thburkhart]

hmm .. ich habe devices mit befehl "pair" gesucht ; entsprechendes define wurde gesetzt; ich kann die devices zwar auslesen, aber nichts schreiben.

Nach deiner Definition sind sie damit nicht gepairt;

anyway ..

was meint der Entwickler zu meinen Vorgehensoptionen A) und B)?

[amenomade]

Obwohl ich Wzut (der Entwickler) nicht bin, eine Anmerkung: zwischen b und c würde ich noch ein "save" machen

[don.redhorse]

Der Übersicht wegen und um die MAX IDs zu haben würde ich die noch alle rausschreiben. Ich habe jetzt also eine Liste mit Namen (Position) und ID angelegt. Danach eben alles gelöscht, gespeichert shutdown restart und dann neu gepairt. Du kannst alle direkt nacheinander pairen. Sind, glaube ich, 120 sec Max pairzeit. Da bekommt man schon einige fertig. Danach mit define xyz die Devices anlegen und eben umbenennen etc. Dann testen (und das war mein Fehler diesen Sommer, sah gut aus und habe weiter gemacht). Wenn man bis dahin keine Wochenprofile übertragen hat (will), wird's auch keinen Ärger mit den Credits geben, die bauen sich ja fix wieder auf. Geschätzt würde ich sagen das rund 100 Credits je HT benötigt werden. Wenn also alles gepairt ist und läuft, dann die WPs anlegen und übertragen, dass wird bei genügenden HTs lange dauern.

@Wzut

Japp, da hast du recht und Autocreate kann da echt Mist machen. Eine Zeitlang hatte ich auch einfach auftauchende Max Geräte, deswegen habe ich in der Wohnung Autocreate auch abgeschaltet. Es ist auch definitiv so, dass Autocreate alles mögliche anlegt, von dem es etwas ließt. Ich hatte mal spaßeshalber einen Signalduino gebaut (bzw. SignalESP) und den so mitlaufen lassen, nach einem Monat hatte ich ein halbes Dutzend Funk Temperaturfühler im System, die der Nachbarn. Gepairt worden ist davon genau gar nichts, aber lesbar waren sie.