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

Ähh set groupid und attr group haben Null Komma Nix mit einander zu tun ! Das Attr group gibt es an jedem Device und regelt die Darstellung in FHEMWEB.
Das Reading groupid ist bei MAX extrem wichtig das muß immer da sein, da ist nichts mit löschen.

Da du aber schreibst dein Bruder und du hat jeder eine MAX Wolke und das noch in Sichtweite :
Verwendet ihr beide unterschiedliche MAXIDs oder hat jeder die 123456 ? (gar nicht gut)
Habt ihr unterschiedliche kann es sein das die WTs deines Bruders mit deiner Wolke gepaired sind, dann kann er nie die Profile übertragen.
Wenn ihr beide die Beta benutzt sieht man bei der Beta 10_MAX mit welcher Wolke das Device wirklich gepaired ist.

Ansonsten glit das Gleiche wie immer : list vom Device , verbose 5 am CUL_MAX und Log posten (alles in Code Tags)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

LostInSpace

Ok.

Die MAXIDs sind unterschiedlich. Darüber bin ich schon beim einrichten der MAX Wolke bei meinem Bruder gestolpert. Die Systeme liefen jetzt auch schon über ein Jahr mehr oder weniger rund.

Ich bekomme bei meinem Bruder die beiden neuen WTs einfach nicht gepaired. Die Schlange baut sich auf arbeitet sich ab bekommt aber kein Accept vom jeweiligen WT.

Es scheint sich aber wohl eher um ein grundsätliches Problem zu handeln. Entweder habe ich beim einpflegen der Beta-pm.s die Systeme durcheinander gebracht (wovon ich jetzt mal ausgehe) oder die Betas laufen noch nicht rund.

Es stellt sich für mich nämlich wie folgt dar: Gebe zum pairen in fhem " set cm pairmode" ein und bekomme im event monitor die Meldung
" Please define cm first". Im logfile taucht (mit verbose 5)

2020.03.20 18:28:15 5: Cmd: >set cm pairmode<

und nichts weiter auf!

führe ich dann noch einmal den Befehl "define cm CUL_MAX 123456" aus bekomme ich folgendes ins logfile:

2020.03.20 18:30:20 5: Cmd: >define cm CUL_MAX 123456<
2020.03.20 18:30:20 1: a CUL_MAX device with address 123456 is already defined !
2020.03.20 18:30:20 1: define cm CUL_MAX 123456: a CUL_MAX device with address 123456 is already defined !

Bin gerade etwas ratlos..

Wzut

Zitat von: LostInSpace am 20 März 2020, 18:33:01
Die MAXIDs sind unterschiedlich.
sehr gut

Zitat
Ich bekomme bei meinem Bruder die beiden neuen WTs einfach nicht gepaired.
Sind sie denn als Device bei ihm schon vorhanden ?

Zitat
Die Schlange baut sich auf arbeitet sich ab bekommt aber kein Accept vom jeweiligen WT.
vermutlich sind sie schon gepaired aber mit deiner Installation ! Um den Fall auszuschließen :
a. Stoppe dein FHEM
b. setze die WTs auf den Werkszustand zurück.
c. wenn die WTs schon in FHEM vorhanden sind : NICHT löschen ! Wenn nein, lass sie mit autocreate etwas laufen, FHEM sollte die raltiv schnell sehen und anlegen.
d. wenn sie da sind : die Taste am WT drücken zum pairen.
Zitat
Es scheint sich aber wohl eher um ein grundsätliches Problem zu handeln. Entweder habe ich beim einpflegen der Beta-pm.s die Systeme durcheinander gebracht (wovon ich jetzt mal ausgehe) oder die Betas laufen noch nicht rund.
2 x nein

Zitat
Es stellt sich für mich nämlich wie folgt dar: Gebe zum pairen in fhem " set cm pairmode" ein und bekomme im event monitor die Meldung
" Please define cm first". Im logfile taucht (mit verbose 5)
Du mssst doch wissen welches CULMAX device du angelegt hast ? Ein Device cm gibt es wohl nicht, aber irgendetwas doch weil deine MAXID 123456 ja schon vergeben ist. Hier sollte ein list TYPE=CUL_MAX schnell Klarheit schaffen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

LostInSpace

#93
Sorry vorab ich tue mich hier mit dem zitieren und Code anzeigen noch etwas schwer deshalb erst einmal nur copy & paste.

1. Ja alle Device von meinem Bruder sind schon vorhanden und liefern soweit ich das überblicken kann auch readings. Es geht exemplarisch erst einmal um ein WT. Dieses ist der richtigen Installation gepaired. Gerade noch einmal nachgeschaut.

2. Werde ich am WE noch einmal in Ruhe angehen, durchspielen und berichten.

Und bzgl. der CULMAX device bin ich mir recht sicher das ich die richtig angelegt habe. Haben ja beide auch schon eine Weile anstandslos funktioniert.

Die Fehlermeldung bzgl. set cm pairmode habe ich auf beiden Systemen (das von meinem Bruder und mir). Ich kann sie mit den jeweiligen CULMAX Def reproduzieren.

Hier mal die Ausgabe von list TYPE=CUL_MAX aus meinem System

   CULMAX0_MSGCNT 15
   CULMAX0_TIME 2020-03-19 19:37:41
   DEF        123456
   FUUID      5c42e095-f33f-1d7c-fdde-1e741446b03786e9
   FVERSION   14_CUL_MAX.pm:?/2020-03-18 UNSTABLE
   IODev      nanoCUL868
   LASTInputDev nanoCUL868
   MSGCNT     10293
   NAME       CULMAX0
   NR         39
   STATE      Defined
   TYPE       CUL_MAX
   _VERSION   167
   addr       123456
   cnt        0
   nanoCUL868_MSGCNT 10278
   nanoCUL868_RAWMSG Z0E1102021B9C741C0ADC0001080022
   nanoCUL868_RSSI -61.5
   nanoCUL868_TIME 2020-03-20 20:26:29
   pairmode   0
   retryCount 0
   sq         0
   123456:
   READINGS:
     2020-03-05 21:35:44   packetsLost     2022
   sendQueue:
Attributes:
   IODev      nanoCUL868
   fakeSCaddr 222222
   fakeWTaddr 111111
   room       CUL_MAX,Zentrale

P.S. Ich möchte Dir jetzt nicht unbedingt diesen Thread mit meinem Fall vollspammen. Soll ich dazu mal einen eigenen Thread eröffnen oder kannst du den abkoppeln.

Auf jeden Fall schon mal vielen Dank für deine Hilfe.

Wzut

Zitat von: LostInSpace am 20 März 2020, 20:52:31
Hier mal die Ausgabe von list TYPE=CUL_MAX aus meinem System
   NAME       CULMAX0
da haben wir es doch : set cm pairmode kann doch gar nicht gehen wenn dein Device den Namen CULMAX0 hat !
und btw : Wenn du deinen CULMAX0 im FHEMWEB aufrufst hast du den pairmode inklusive Zeit sogar als DropDown zum einfachen anklicken.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

LostInSpace

Danke. Dieser Umstand war mir gestern auch schon aufgefallen. Ich bin mir aber sicher das ich beide culs mit cm definiert hatte. Steht ja überall in den entsprechenden Definitionsvorgaben. Hat in der Vergangenheit beim pairen ja auch immer so funktioniert!?

Ok... Es ist wie es ist. Kann / soll ich die CUls sinnvoller Weise umbenennen? Ansonsten nutze ich jetzt die FHEMWEB Variante mit Dropdown und schaue mal ob ich damit ans Ziel komme.

Erstmal ein sonniges entspanntes Wochenende.

Wzut

Zitat von: LostInSpace am 21 März 2020, 09:24:50
Kann / soll ich die CUls sinnvoller Weise umbenennen?
Verstehe ich nicht, warum willst du jetzt an die CULs ran ? Natürlich kann man alles anders nennen, aber mach dir lieber klar wie 10_MAX -> 14_CUL_MAX -> 00_CUL zusammenhängen (IODev) , d.h. wenn du jetzt mit umbennen anfängst musst du auch immer das jeweilige Attribut IODev mit anfassen !   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Maui

 Nabend. Ich hoffe es stört dich nicht wenn ich Themen, die Beta Versionen betreffend, hier einstelle. Finde als eigener Thread muss auch nicht sein, dass verwirrt evtl. Andere Leser.
Ich habe einen kruden Fehler.

Wenn ich manchen HTs das culdev zuweisen will dann verliert er es bei einem fhem neustart. Aber nicht alle HTs.
Im Log und auf dem Start Bildschirm kriege ich

configfile: hkGastOben, invalid CUL device mapleCUN2_1


List hkGastOben


Internals:
   DEF        HeatingThermostat 18baf5
   FUUID      5cdea262-f33f-a5e8-0150-59c1ee58b971c8bc
   FVERSION   10_MAX.pm:?/2020-03-24 UNSTABLE
   IODev      CULMAX0
   NAME       hkGastOben
   NR         32
   NTFY_ORDER 50-hkGastOben
   STATE      waiting for data
   TYPE       MAX
   TimeSlot   7
   addr       18baf5
   devtype    1
   type       HeatingThermostat
   READINGS:
     2020-01-30 11:29:38   PairedTo        123456
     2020-03-24 21:24:25   RSSI            -50
     2020-01-30 11:29:38   SerialNr        OEQ1136932
     2019-05-17 12:14:01   TimeInformationHour 0
     2020-03-24 21:24:25   battery         ok
     2020-03-24 21:24:25   batteryState    ok
     2020-01-30 08:17:54   boostDuration   25
     2020-01-30 08:17:54   boostValveposition 80
     2020-01-30 08:17:54   comfortTemperature 21.0
     2020-01-30 08:17:54   decalcification Sat 12:00
     2020-03-24 21:24:25   desiredTemperature 10.0
     2020-03-24 12:00:34   deviation       5.2
     2020-01-30 08:17:54   ecoTemperature  17.0
     2020-01-30 11:29:38   firmware        1.0
     2020-03-24 21:24:25   gateway         1
     2020-01-30 08:17:54   groupid         0
     2020-03-24 21:24:25   lastConfigSave  ./log/hkGastOben.max
     2020-03-24 12:48:21   lastTimeSync    2020-03-24 12:48:21
     2020-03-24 21:32:35   lastcmd         set_maxValveSetting 29
     2020-03-24 21:24:25   mapleCUN1_RSSI  -67
     2020-03-24 21:24:25   mapleCUN2_1_RSSI -50
     2020-03-24 15:53:20   mapleCUN2_1_retry 143
     2020-03-24 21:24:25   maxValveSetting 30
     2020-01-30 08:17:54   maximumTemperature on
     2020-01-30 08:17:54   measurementOffset 0.0
     2020-01-30 08:17:54   minimumTemperature off
     2020-03-24 21:24:25   mode            manual
     2020-03-24 21:32:35   msgcnt          150
     2020-03-24 21:19:05   none_retry      2
     2020-03-24 21:24:25   panel           unlocked
     2020-03-24 12:00:34   peerIDs         000000
     2020-03-24 12:00:34   peerList        Broadcast
     2020-03-24 21:24:25   rferror         0
     2020-03-24 12:00:34   sendTo_Broadcast 499
     2020-03-24 21:24:25   state           waiting for data
     2020-03-24 12:00:34   temperature     15.2
     2020-01-30 11:29:38   testresult      160
     2020-01-30 08:17:54   valveOffset     0
     2020-03-24 21:24:25   valveposition   0
     2020-01-30 08:17:54   weekprofile-0-Sat-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:17:54   weekprofile-0-Sat-time 00:00-06:00  /  06:00-22:00  /  22:00-24:00
     2020-01-30 08:17:54   weekprofile-1-Sun-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:17:54   weekprofile-1-Sun-time 00:00-06:00  /  06:00-22:00  /  22:00-24:00
     2020-01-30 08:17:54   weekprofile-2-Mon-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:17:54   weekprofile-2-Mon-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:17:54   weekprofile-3-Tue-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:17:54   weekprofile-3-Tue-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:17:54   weekprofile-4-Wed-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:17:54   weekprofile-4-Wed-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:17:54   weekprofile-5-Thu-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:17:54   weekprofile-5-Thu-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:17:54   weekprofile-6-Fri-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:17:54   weekprofile-6-Fri-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:17:54   windowOpenDuration 15
     2020-01-30 08:17:54   windowOpenTemperature 12.0
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   CULdev     mapleCUN2_1
   IODev      CULMAX0
   debug      1
   event-on-change-reading .*
   model      HeatingThermostat
   mqttPublish *:topic={"$base/$device/$name"}
   room       2_Gast
   verbose    5



Ein HT, der den Neustart überlebt



Internals:
   CULMAX0_MSGCNT 2
   CULMAX0_TIME 2020-03-24 21:37:54
   DEF        HeatingThermostat 18af57
   FUUID      5e3283b8-f33f-a5e8-493d-42321291271d1687
   FVERSION   10_MAX.pm:?/2020-03-24 UNSTABLE
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     2
   NAME       hkSz
   NR         172
   NTFY_ORDER 50-hkSz
   STATE      waiting for data
   TYPE       MAX
   TimeSlot   2
   addr       18af57
   devtype    1
   type       HeatingThermostat
   READINGS:
     2020-01-30 11:28:59   PairedTo        123456
     2020-03-24 21:37:54   RSSI            -52.5
     2020-01-30 11:28:59   SerialNr        OEQ1132912
     2020-03-24 21:37:54   battery         ok
     2020-03-24 21:37:54   batteryState    ok
     2020-01-30 08:20:24   boostDuration   25
     2020-01-30 08:20:24   boostValveposition 80
     2020-01-30 08:20:24   comfortTemperature 21.0
     2020-01-30 08:20:24   decalcification Sat 12:00
     2020-03-24 21:37:54   desiredTemperature on
     2020-03-24 21:37:54   deviation       -12.8
     2020-01-30 08:20:24   ecoTemperature  17.0
     2020-01-30 08:20:24   error           invalid or missing value  for READING groupid
     2020-03-24 21:37:54   externalTemp    17.7
     2020-01-30 11:28:59   firmware        1.0
     2020-03-24 21:37:54   gateway         1
     2020-01-30 08:20:24   groupid         0
     2020-03-24 21:37:54   lastConfigSave  ./log/hkSz.max
     2020-03-24 08:48:21   lastTimeSync    2020-03-24 08:48:21
     2020-03-24 21:37:54   lastcmd         maxValveSetting 100
     2020-03-24 21:37:54   mapleCUN1_RSSI  -78.5
     2020-03-24 21:37:54   mapleCUN2_1_RSSI -52.5
     2020-03-24 19:39:53   mapleCUN2_1_retry 236
     2020-03-05 19:33:59   mapleCUN4_RSSI  -78
     2020-03-24 21:37:54   maxValveSetting 100
     2020-01-30 08:20:24   maximumTemperature on
     2020-01-30 08:20:24   measurementOffset 0.0
     2020-01-30 08:20:24   minimumTemperature off
     2020-03-24 21:37:54   mode            manual
     2020-03-24 21:32:35   msgcnt          141
     2020-03-24 21:37:54   panel           locked
     2020-03-24 19:12:52   peerIDs         000000,111111
     2020-03-24 19:12:52   peerList        Broadcast,MAX_111111
     2020-02-09 19:30:22   peers           111111,111111
     2020-03-24 21:37:54   rferror         0
     2020-03-24 19:12:52   sendTo_Broadcast 1395
     2020-02-09 19:18:42   sendTo_MAX_111111 85
     2020-03-24 21:37:54   state           waiting for data
     2020-03-24 19:12:52   temperature     17.3
     2020-01-30 11:28:59   testresult      160
     2020-01-30 08:20:24   valveOffset     0
     2020-03-24 21:37:54   valveposition   100
     2020-01-30 08:20:24   weekprofile-0-Sat-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:20:24   weekprofile-0-Sat-time 00:00-06:00  /  06:00-22:00  /  22:00-24:00
     2020-01-30 08:20:24   weekprofile-1-Sun-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:20:24   weekprofile-1-Sun-time 00:00-06:00  /  06:00-22:00  /  22:00-24:00
     2020-01-30 08:20:24   weekprofile-2-Mon-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:20:24   weekprofile-2-Mon-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:20:24   weekprofile-3-Tue-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:20:24   weekprofile-3-Tue-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:20:24   weekprofile-4-Wed-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:20:24   weekprofile-4-Wed-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:20:24   weekprofile-5-Thu-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:20:24   weekprofile-5-Thu-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:20:24   weekprofile-6-Fri-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2020-01-30 08:20:24   weekprofile-6-Fri-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-24:00
     2020-01-30 08:20:24   windowOpenDuration 15
     2020-01-30 08:20:24   windowOpenTemperature 12.0
   helper:
     dt         21.0
     myday      3
     io:
       mapleCUN1:
         raw        Z0E8D020218AF57123456000139643D
         rssi       -78.5
         time       1585082274.18498
       mapleCUN2_1:
         raw        Z0E8D020218AF57123456000139643D
         rssi       -52.5
         time       1585082274.00163
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   CULdev     mapleCUN2_1
   IODev      CULMAX0
   debug      1
   externalSensor tsSz:temperature
   model      HeatingThermostat
   mqttPublish *:topic={"$base/$device/$name"}
   room       2_Schlafzimmer

Wzut

ist schon ok das alle Probleme der Beta hier landen. Deinen Device lists ieht man das Problem nicht an, denn es steckt in deiner fhem.cfg
D.h. alle die etwas zickig sind stehen in deiner fhem.cfg vor dem define des mapleCUN2_1 und da beim setzen des Attributs das CULdev auf vorhanden sein geprüft wird schlägt das dann fehl. Ich habe die Prüfung jetzt "ausgesetzt" bis FHEM komplett oben ist , neue Version im Beta Thread. THX4Info !!
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Maui

Moin danke. Wird gleich getestet.
Gibt es da eigentlich eine schöne Abhilfe?
Ich kenne das Problem von anderen Modulen zb PID20.
Ändere ich dort den temp sensor und der neue steht unter dem pid define dann zickt er rum.
Also nicht nur auf max bezogen sondern allgemein. Ich bilde mir ein, dass es Module gibt, die das im Griff haben. Oder warten die auch einfach nur bis fhem fertig ist?

Ich hoffe du verstehst das nicht als Kritik gegen deine Module   ;)

Feedback kriegst gleich.

Gruss

Wzut

zum Thema Reihenfolge in der fhem.cfg gab es vor einiger Zeit eine Diskussion.
Fakt ist einige Module haben damit ein Problem, verantwortlich ist aber der Modulautor das in den Griff zu bekommen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Maui


Maui

Neuer Tag, neues Problem  ;D
Kann es sein, dass bei einer neueren Version von Max (hab beide die aktuellsten) ein kleiner Fehler bei desiredTemperature on ist?
Stelle ich ein HT auf zb. 20 Grad und dann wieder hoch auf on, so macht der HT auch das was er soll.
Aber in fhem bleibt er bei desiredTemperature auf dem alten Wert (20 Grad) kleben.
Das passiert allerdings nur bei on, ich könnte also zb bei allen Thermostaten auch 30° einstellen, das würde fhem richtig anzeigen.
Hintergrund: ich nutze maxValveSetting und PID20.

Gruß

Wzut

Hm... muß ich testen. Generell : wenn du desiredTemperature in FHEMWEB oder via set Kommando direkt verstellst ändert sich die Anzeige (das Reading ) noch nicht.
Lediglich ein Eintrag unter lastCMD set_desiredTemperature xy . Erst mit der Antwort des HT/WT wird das Reading nachgezogen und bei lastMD das set_ gelöscht.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Maui

Moin, ja aber das meine ich ja nicht. Das kenne ich ja und kann es auch beim Setzen von zb. 30 Grad gut sehen, dass erst lastCMD gesetzt wird und mit Antwort des HT dann desiredTemp auf 30.
So wie ich es verstehe, kommt (mit verbose 5 am HT) auch eine Antwort vom HT, dass er auf 30,5 gesetzt hat. Aber in fhem scheint das nicht weiterverarbeitet werden.
2020.03.27 08:27:38 5:  hkGastUnten, bat 0, rferror 0, panel 1, langateway 1, dstsetting 1, mode 1, valveposition 40, desiredTemperature 30.5
2020.03.27 08:27:39 5:  hkGastUnten, msgtype AckSetTemperature : 30.5