Die MAX Module heute und die Aussichten für 2020

[Wzut]

Recht intressant ist das wenn ein WT oder FK ins Spiel kommt, besonders bei den FKs sieht man dann schön ob sie wirklich mit den HT/WT gepeerd sind oder einfach nur Broadcasts senden. Ich wette 90% der FKs sind eben nicht direkt verbunden ( u.a. meine eigenen auch )  wegen dieser Falschaussage im Wiki oder den super Forum Tipps "starte FHEM neu wenn die Meldung nervt"

[Maui]

Ich dachte immer, dass weiss nur der HT, ob er mit einem FK gepairt ist?!
Oder liest du genau das vom HT aus?
Aber ja es ist spannend das zu sehen, vor allem zur Fehler Eingrenzung.

[Plextor]

Recht intressant ist das wenn ein WT oder FK ins Spiel kommt, besonders bei den FKs sieht man dann schön ob sie wirklich mit den HT/WT gepeerd sind oder einfach nur Broadcasts senden. Ich wette 90% der FKs sind eben nicht direkt verbunden ( u.a. meine eigenen auch )  wegen dieser Falschaussage im Wiki oder den super Forum Tipps "starte FHEM neu wenn die Meldung nervt"

Genau. Bei den FK's ist diese Funktion wirklich nützlich. Damit kann man hervorragend feststellen, dass die FK-Assoziierung erst funktioniert, wenn man nach dem Associate-Befehl ein Ack des FK's durch Drücken des Knopfes unter der Abdeckung erzwingt.

Ich habe dadurch auch festgestellt, dass ein WT die alleinige Kontrolle über die FK's übernimmt. Bei mir im Wohnzimmer gibt es 1 WT, 2 HT's und 3 FK's, die alle miteinander assoziiert sind. Aber in der Peer-Liste der FK's erscheint nur der WT, der dann das Öffnen/Schließen der Fenster an die HT's weitergibt.

Wirklich sehr nützlich diese Listen...

[Wzut]

@ Maui nein , Zitat Wiki

set Heizthermostat1 associate Fensterkontakt1
set Fensterkontakt1 associate Heizthermostat1

das erste set Heizthermostat1 associate Fensterkontakt1 ist unbedingt nötig damit das HT1 überhaupt auf Nachrichten vom FK1 reagiert.
Macht man nun hier Schluß hat FK1 keine Ahnung das es Geräte gibt die direkt von ihm informiert werden wollen, ergo wird er seine Status Nachrichten weiter mittels Ziel 000000 Broadcast versenden. Unser HT wird auch brav darauf reagieren wenn es sie empfängt.

Das zweite set Fensterkontakt1 associate Heizthermostat1 ist nun dafür da dem FK1 klar zu machen das er ausser Broadcasts auch Nachrichten direkt an einen oder mehrere Partner schicken soll. Und hier fängt das Elend an weil die FKs  normalerweise schlafen und erst geweckt werden müssen um eine Nachricht zu empfangen und genau dieser Abschnitt steht falsch im Wiki.
Ist aber nicht tragisch, denn wenn associate erfolgreich war und das HT nicht antwortet blinkt der FK dreimal, was hier auch schon den einen oder anderen User verwirrt hat. Ergo : FK nicht peeren und sich freuen das sie immer nur 1x blinken

@Plextor : genau !

[Wzut]

Ich habe dadurch auch festgestellt, dass ein WT die alleinige Kontrolle über die FK's übernimmt. Bei mir im Wohnzimmer gibt es 1 WT, 2 HT's und 3 FK's, die alle miteinander assoziiert sind. Aber in der Peer-Liste der FK's erscheint nur der WT, der dann das Öffnen/Schließen der Fenster an die HT's weitergibt.

Das wird man vermutlich aber nicht verallgemeinern können. Meine Testinsel besteht aus 1 x WT , 2 x HT & 1  x FK und wurde mit der Original ELV MAX Software als Raum in Betrieb genommen. Hier zeigt sich beim Telegramm Mitschnitt das der FK zuerst sein open/close an ein HT schickt, dann das nächste HT und als leztes an das WT.
D.h. als drei verbunde Geräte , dreimal opn/close , dreimal open/close Events in FHEM da der CUL natürlich alle drei Telegramme gesehen hat.
Das besondere an den Telgrammen : Im Kopf gibt es einen Zähler (msgcount) und der bleibt bei allen drei gleich, vermutlich da der FK meint es sei ja das gleiche Ereignis.
Daraufhin habe ich 10_MAX das Attribut skipDouble spendiert. Ist es gesetzt wird nur das erste open/close in FHEM verarbeitet, die nachfolgeden Telegramme aber verworfen.

[JHo]

Jetzt bin ich ziemlich verwirrt und habe drei Fragen:

1) Ich habe bislang immer "nur" die Fenster nach Absenden des associate einmal geöffnet, und das noch nichtmal unmittelbar danach (mal 10 Sekunden, aber auch mal 5 erst Minuten danach). Meistens hat danach das Peering funktioniert - aber nicht immer. 3x blinken habe ich nicht festgestellt. --> Muss (!) das FK-Peering mit Tastendruck "abgeschlossen" werden und in welchem Zeitraum nach Absetzen des Befehls, oder reicht ein onoff-Event auch aus?

2) Die neuen Funktionen in Bezug auf die Peers sind absolut großartig, aber... in meiner zweiten Installation funktionieren sie nicht wie erwartet. Denkfehler, Problem in meiner Installation oder im Modul?
Haus 2 hat keine Fensterkontakte. Das Problem besteht nur bei HTs, die untereinander gepeert sein sollen. Ziel: ändere ich die Soll-Temperatur HT1, soll sie auch an HT2 übernommen werden, und umgekehrt. Die Einrichtung war damals über die ELV-Software, das System ist dann zu FHEM via Cube umgezogen. Mittlerweile ist der Cube zum CUL geflasht.
Der Eventmonitor sagt:

Code Auswählen Erweitern

2020-02-04 13:12:58 MAX Heizung.Sanitaerwand peers: 133e0b
2020-02-04 13:12:58 MAX Heizung.Sanitaerwand lastcmd: associate 133e0b
2020-02-04 13:12:58 MAX Heizung.Sanitaerwand lastConfigSave: 2020-02-04 13:12:58
2020-02-04 13:12:58 MAX Heizung.Sanitaerwand waiting for data
2020-02-04 13:13:02 CUL CUNoMAX credit10ms: 3493
2020-02-04 13:13:03 MAX Heizung.Kuechenwand peers: 133e0c
2020-02-04 13:13:03 MAX Heizung.Kuechenwand lastcmd: associate 133e0c
2020-02-04 13:13:03 MAX Heizung.Kuechenwand lastConfigSave: 2020-02-04 13:13:03
2020-02-04 13:13:03 MAX Heizung.Kuechenwand waiting for data
[...]
händische Änderung der desiredTemperature
[...]
2020-02-04 13:16:25 MAX Heizung.Kuechenwand peerList: Broadcast,Clubraum,Heizung.Leinwand,Heizung.Skatecke
2020-02-04 13:16:25 MAX Heizung.Kuechenwand peerIDs: 000000,133e0d,133f6b,156d02
2020-02-04 13:22:14 MAX Heizung.Sanitaerwand peerList: Broadcast,Clubraum,Heizung.Leinwand,Heizung.Skatecke
2020-02-04 13:22:14 MAX Heizung.Sanitaerwand peerIDs: 000000,133e0d,133f6b,156d02

Das kreuzweise Assoziieren von Sanitaer- und Kuechenwand wird ums verrecken nicht angenommen. Die anderen beiden HTs und das WT haben jeweils die anderen 4 Geräte gepeert. Auf welche Data warten diese beiden HTs? Gleiches Problem habe ich noch an anderer Stelle in diesem Haus (da sind nur HTs involviert).

3) Hat nichts mit der Beta zu tun, aber hilft vielleicht beim Verständnis meiner Frage aus 2): In welcher funktionalen Verbindung stehen eine händisch, Raum-einheitliche GroupID und Assoziation/Peering bei MAX?

[Wzut]

Ich fang mal hinten an :
3. Die groipid ist wichtig/erforderlich wenn mehr als ein HT in einem Raum ( damit meine ich nicht FHEM room ! ) ist und dieses direkt mit den anderen HT in gleichen Raum kommunizieren soll. D.h. ändert man von Hand am Drehrad die Soll Temp an HT1 schickt dieses den Befehl an HT2,3,4 usw.
Die FHEM groupid ist der Ersatz für Raum in der ELV Software. Das hässliche ist nun das diese groupid in FHEM "verloren" gehen kann , z.B. wenn man in das HT neue Batterien einlegt und kurz das Re-Paiering anwirft. Auf dem HT müsste sie eigentlich erhalten bleiben aber CUL_MAX sorgt dafür das das Reading mit 0  gesetzt wird. - Das ist eine der nächsten Baustellen, versuchen die groupid über den Batteriewechsel zu erhalten, bis dahin sollte bei jedem HT das unbedingt die groupid benötigt diese wieder nach dem Batteriewechsel von Hand gesetzt werden.

zu 2 :
eigentlich schaut das von deinen Readings her sehr gut aus ,
jeder hat den anderen als peer gelistet und bei beiden ist lastcmd ohne set_
Unter der Bedingung das Heizung.Sanitaerwand und Heizung.Kuechenwand als ID die 133e0b bzw. 133e0c haben. ( Krass direkt aufsteigende IDs hatte ich noch nie )
Nun die Frage : hatten auch beide die gleiche groupid ? bzw. passt diese auch zu den anderen beiden HTs Heizung.Leinwand und Heizung.Skatecke ?
Um es ganz zu verstehen müsstest du deine Gerätenamen mal mit Device Typ posten und hast du wirklich einen so großen Raum das dort vier HTs verbaut sind ?

zu 1 :
warten kannst du solange du möchtest, der Befehl "hängt" in der SendQueue fest und geht nicht eher raus bis ein Pair Pong (Re-Pairing) zum FK gesendet wird. Wer es nicht glaubt dem sei ein Blick in die 14_CUL_MAX empfohlen, da hat M. Gehre den entsprechenden Kommentar hinterlassen :

# Handle outgoing messages to that ShutterContact. It is only awake shortly
# after sending an Ack to a PairPong

Das wird dann meine übernächste Baustelle. Der CUBE mit ELV Firmware kann tatsächlich den Zeitpunkt besser erkennen wann der FK wach ist und ihm sofort die Peering Nachricht unterschieben.


   

[Plextor]

Zum Thema groupid:

In der Commandref steht u.a. folgendes:

groupid <id>
For devices of type HeatingThermostat only

Bei den Shuttercontacts existiert allerdings in der Dropdown-Liste ebenfalls der set-Befehl "groupid", auf den die FK's aber keine Antwort geben. Vielleicht sollte man den für die Fensterkontakte aus der Liste entfernen...

[Wzut]

ja und für WTs kann man sie auch setzen ....
Ich muss das Thema nochmal für beide Typen mit der ELV Software angehen und sicherstellen das wirklich keine groupid gesetzt wird obwohl beide in einen Raum können.

[Maui]

Wo bald wieder Sonntag ist... 
in dem list von associate hast du ein Typo beim fakeWT am Ende. Gibt kein thermostatt.
Und wenn ich den fakeWT associated habe, dann kriege ich beim Umstellen der Temp immer ein rf Error.

Code Auswählen Erweitern



Internals:
   CULMAX0_MSGCNT 901
   CULMAX0_TIME 2020-02-08 15:49:59
   DEF        HeatingThermostat 18af57
   FUUID      5e3283b8-f33f-a5e8-493d-42321291271d1687
   FVERSION   10_MAX.pm:?/2020-02-03 UNSTABLE
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     901
   NAME       hkSz
   NOTIFYDEV  tsSz
   NR         211
   NTFY_ORDER 50-hkSz
   STATE      17.0°C (rf error)
   TYPE       MAX
   TimeSlot   10
   addr       18af57
   devtype    1
   type       HeatingThermostat
   READINGS:
     2020-01-30 11:28:59   PairedTo        123456
     2020-02-08 15:49:59   RSSI            -72
     2020-01-30 11:28:59   SerialNr        OEQ1132912
     2020-02-08 15:49:59   battery         ok
     2020-02-08 15:49:59   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-02-08 15:49:59   desiredTemperature 17.0
     2020-02-08 15:49:59   deviation       0.0
     2020-01-30 08:20:24   ecoTemperature  17.0
     2020-01-30 08:20:24   error           invalid or missing value  for READING groupid
     2020-02-08 15:05:43   externalTemp    17.1
     2020-01-30 11:28:59   firmware        1.0
     2020-02-08 15:49:59   gateway         1
     2020-01-30 08:20:24   groupid         0
     2020-02-08 15:48:38   lastConfigSave  ./log/hkSz.max
     2020-02-08 11:12:48   lastTimeSync    2020-02-08 11:12:48
     2020-02-08 15:48:38   lastcmd         associate 111111
     2020-02-08 15:49:59   mapleCUN2_1_RSSI -51.5
     2020-02-08 15:49:59   mapleCUN4_RSSI  -72
     2020-02-08 10:28:20   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-02-08 15:49:59   mode            manual
     2020-02-08 15:48:36   msgcnt          107
     2020-02-08 15:49:59   panel           locked
     2020-02-08 15:49:59   peerIDs         000000,111111
     2020-02-08 15:49:59   peerList        Broadcast,MAX_111111
     2020-02-08 15:48:38   peers           111111,111111
     2020-02-08 15:49:59   rferror         1
     2020-02-08 15:49:59   sendTo_Broadcast 5
     2020-02-08 15:49:59   state           17.0°C (rf error)
     2020-02-08 15:49:59   temperature     17.7
     2020-01-30 11:28:59   testresult      160
     2020-01-30 08:20:24   valveOffset     0
     2020-02-08 15:49:59   valveposition   0
     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:
     io:
       mapleCUN2_1:
         raw        Z0F00046018AF570000000079002200B1
         rssi       -51
         time       1581173399.31067
       mapleCUN4:
         raw        Z0F00046018AF570000000079002200B1
         rssi       -72
         time       1581173399.12679
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   CULdev     mapleCUN2_1
   IODev      CULMAX0
   debug      1
   externalSensor tsSz:temperature:1
   model      HeatingThermostat
   mqttPublish *:topic={"$base/$device/$name"}
   room       2_Schlafzimmer
   verbose    5


Gruß
Maui

[Wzut]

es ist zwar wieder Sonntag , aber ich bin die Woche über nicht zu sehr viel gekommen.
Das tt und deine peers  111111,111111 setze ich auf die ToDo Liste
Um hinter deinen rferror zu kommen bedarf es eines CUL_MAX Log Abschnitts mit verbose 5.
Da du den external Sensor mit ,1 Parameter verwendest :
Kommt denn die Soll Vorgabe des Sensors regelmäßig beim HT an ?
Denn wenn da die Pausen zu groß sind meint er sein Chef wäre tot und setzt den rferror ( siehe Wiki )

[Maui]

Alles klar.
Definiere regelmäßig. 
Bei 0.2 Grad Änderung oder spätestens nach 3000s.
Mal was ähnliches dazu. Hab grad ein neues laCrosse thermostat angelernt, welches behauptet hat, genau mein "Test" thermostat vom schlafzimmer zu sein.
Dadurch haben sich beide reading technisch abgewechselt und es wurde alle 4s was per fakeWT an das HT geschickt. Credits waren natürlich ruck zuck leer.
Gibt es in fhem etwas wie event max intervall? Oder event pause?
Also sodass in so einem Fall (oder Fenster offen) nicht häufiger als alle 5 Minuten ein Event ausgelöst wird?!

[Wzut]

also bei den 3000 Sekunden würde ich ne Null streichen, das MAX Wandthermo schickt seinen Wert so knapp alle 3 Minuten.
event pause gibt es nicht, einige Module unterstützen do_not_notify ( aber nicht LaCrosse )

[Maui]

Aber dann muss ich nochmal ganz blöd fragen.
Eine Nachricht vom CUL an das HT kostet grob 100 Credits.
Selbst mit 3600 bin ich bei allen 3 Minuten bei 2000 Credits pro fakeWT pro Std.
Also bei 2 fakeWT laufe ich schon leer. Oder wo ist mein Denkfehler?
Bzgl. Event pause könnte ich ein DOIF zwischenschalten mit cmdpause.

[Wzut]

Oder wo ist mein Denkfehler?

Kein Denkfehler, du liegst richtig. Ich bin auch kein Freund von fakeWT zumindest nicht als Komplettlösung für Haus.