Max!-Thermostat WT und HT nicht ansteuerbar

[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.