Die MAX Module heute und die Aussichten für 2020

[Thomas_Homepilot]

Guten Morgen und vielen Dank für Deine Arbeit.

Beim Testen ist mir aufgefallen, das die windowOpenTemperature in der setlist fehlt. Ansonsten läuft bei mir alles stabil.
GrußThomas

[Wzut]

oh THX , war mir noch gar nicht aufgefallen
Ich habe auf meinem aktiven System noch eine ältere Version da fehlt es auch.

[VolkerGBenner]

Hallo Wzut,
erstmal Danke, dass du die MAX!-Module weiterentwickelst.

Ich habe gerade mal testweise 10_MAX.pm und 14_CUL_MAX.pm gegen deine Betas ausgetauscht. Beim nach dem Neustart wurde mir einer meiner beiden CUL_MAX nicht mehr angezeigt und auf dem Startbildschirm standen zwei widersprüchliche Hinweise. 1.dass dieser CM nicht existiert und erst defined werden soll und er 2. nicht defined werden kann, weil er schon defined ist. Hab dann einfach mal ein neues define von der Fhem-Eingabezeile losgeschickt und wieder Aussage 2 bekommen. Er wird aber dennoch nicht angezeigt.
Wieder zurück in die regulären . pm und alles ist wieder gut.  Hab ich was überlesen in Bezug auf MultiIO?

Ich hab das ganze FHEM mit configdb laufen und gerade frisch aufgesetzt.

Für MAX! werkeln bei mir zwei umgeflashte CUBEs; einer pro Stockwerk. Einer heißt 123456 und der andere 654321. Interessant finde ich, dass die sich gegenseitig als WT erkennen. Einer ist sogar (wie auch immer das passiert) mit einem FK "probably associated".

Und mit einem HT habe ich seit ein paar Tagen das Problem, dass er scheinbar mit einer fremden Installation gepaired ist. Dass es gepaired sein muss erkenne ich ja daran, dass der MODE sich am HT ändern lässt. Ich hab es heute schon dreimal versucht den HT aus dem Werkszustand an mein System zu pairen. Er paired sich immer mit irgendwas nur nicht wie er soll. Irgendein Nachbar hat auch MAX! , aber ein CUL oder CUBE ist doch nicht dauerhaft in pairing-Bereitschaft.

[Wzut]

ich fang mal hinten an :

aber ein CUL oder CUBE ist doch nicht dauerhaft in pairing-Bereitschaft.

doch CUL_MAX liegt da ständig auf der Lauer da sonst beim Batterie Wechsel kein repairing stattfinden würde. D.h. der extra Pairmode ist nur notwendig wenn das Device in FHEM noch nicht existiert.

Er paired sich immer mit irgendwas nur nicht wie er soll

Auch hier könnte die Beta helfen mit einem verbose 5 Log Auszug des CUL_MAX Device

Interessant finde ich, dass die sich gegenseitig als WT erkennen..

Das liegt daran das MAX kein Device für andere MAX Installationen hat und versucht aus den Nachrichten ein Gerät für sich zu erkennen. Das Problem lässt sich bei der Beta mit dummy  oder DeviceType Cube lösen.

Für MAX! werkeln bei mir zwei umgeflashte CUBEs; einer pro Stockwerk. Einer heißt 123456 und der andere 654321.

ah wir kommen der nächsten Sache näher :

1.dass dieser CM nicht existiert und erst defined werden soll und er 2. nicht defined werden kann, weil er schon defined ist.

Du hast heute zwei CUL_MAX Geräte in deiner fhem.cfg, das ist nun nicht mehr erlaubt da CUL_MAX nun wie früher ein Highlander geworden ist -> "Es kann nur Einen geben" D.h. für dich beim Einsatz der Beta ein CUL_MAX löschen und wie in der Beta beschrieben IOgrp setzen und am jeweiligen CUL die maxid.
Auf Dauer wirst aber glücklicher werden wenn die beiden CULs sich die Arbeit teilen und nur noch eine maxid verwendet wird. Bedeutet für dich dann leider eine der beiden Insel komplett auf Werkzustand zurück zu setzen. Aber ACHTUNG : nicht die Geräte aus FHEM löschen !! 

[Wzut]

wieder mal Sonntag und Zeit für neue Infos :
1. die bisherigen Versionen von 10_MAX hatten einen Fehler wenn autocreate ein neues Device anlegen sollte und bei CUL_MAX der pairmode aktiv war.
Sollte jetzt wieder passen, wer mutig ist kann ja mal ein Device auf Werkseinstellung zurück setzen und aus FHEM löschen

2. die letzten Tage war ein Thema aktuell das ich eigentlich noch etwas aufschieben wollte : virtuelle Fensterkontakte statt des fakeSC.
Ich habe da etwas Doku zu geschrieben, zu finden im Moment noch hier -> https://forum.fhem.de/index.php/topic,106355.msg1028418.html#msg1028418
Die dortigen Dateien habe ich wieder gelöscht, da der Stand jetzt in der Beta ist. Wichtig : um den virtuellen Fensterkontakt nutzen zu können muss via Update ( ab morgen) die MaxCommon.pm aktualisiert werden -> update MaxCommon  , FHEM Neustart

3. Das 10_MAX Modul unterstützt jetzt auch attrTemplate -> https://forum.fhem.de/index.php/topic,109034.0.html
Das erste Template habe ich vorhin hochgeladen, steht also auch ab morgen früh als Update zur Verfügung.

[Tedious]

Kurze Zwischenfrage - sind die beiden Module eigentlich inzwischen im offiziellen Repo? Da bei mir (danke nochmals!) alles super-stabil läuft stecken die im Moment noch im exclude des Updates.

[Wzut]

Nein nach wie vor noch Beta.
Zum einen tauchen jetzt nach längerer Zeit doch noch Fehler auf, zum anderen hänge ich stark mit der commandref hinter her.

[Maui]

Moin.
Ich kämpfe grad ein wenig mit den Credits. Habe 2 CUNs und der eine betreut 7, der andere 6 HTs. Also ähnlich viele.
Der eine ist Von den Credits her häufig bei null und der andere verlässt die Obergrenze (3600) nicht wirklich.
Per culdev sind beide sauber zugewiesen. Ich suche noch nach Gründen oder Fehlern die das erklären.

Was mir aber in dem Zuge aufgefallen ist: die queue ist aktuell noch nicht wirklich multi CUL fähig, also soll heißen: gehen einem CUL die Credits aus, laufen viele Messages in die Queue und bremsen unnötigerweise den zweigen CUL da sich dessen Telegramme brav hinten anstellen.
Wäre es da nicht möglich die Abarbeitung pro CUL per FIFO zu machen und nicht über alle CULs hinweg?

[Wzut]

1. Credits :
Da gibt es IMHO nur einen Weg : loggen mit verbose 3 global und verbose 5 am CUL_MAX Device.
Um die Menge der Daten zu reduzieren kannst du noch mit der whitelist/blacklist arbeiten. D.h. entweder die Gruppe der Guten auf die blacklist oder die Bösen auf die whitelist. Klingt komisch, aber du möchtest ja sehen was mit den Problemkindern los ist. Nimm dabei in Kauf das die andern dann halt mal ein paar Minuten nicht mit FHEM reden. Ich habe seit November gefühlt Eimerweise Logs gelesen, d.h. wenn es dir zuviel ist poste die Datei hier. Was auch hilfreich sein kann ist ein Plot der freien Credits.
Als Schnellschuss : a. kein MaxScanner verwenden. b. broadcastTimeDiff auf 300 setzen um Sync Geier auszuschliessen.

2.  Sicher das Thema MutliIO ist bei weitem noch nicht perfekt, um dein Thema anzugehen : Ich habe gleich am Anfang jedem Paket in der Queue schon mal die Info verpasst über welchen CUL es laufen soll. Damit Paket B Paket A "überholen" kann muß eigentlich der ganze SendQueueHandler neu geschrieben werden. Einfacher wäre natürlich eine Queue pro CUL , so hatte ich es am Anfang. Da hat man aber das Problem bei den eintreffenden ACKs die verschieden Queues durchsuchen zu müssen, was auch wieder viel Umschreiben bedeutet. So oder so, ist halt jetzt alles noch Beta und je mehr Feedback ich von Usern erhalte um so leichter wird es eine endgültige Marschrichtung festzulegen. So hatte ich jetzt zum Beispiel dein Thema Überholen noch gar nicht auf dem Radar, weil es in meiner Umgebung bisher nicht relavant war. 

[Maui]

Überholen wird ja auch nur interessant, wenn ein anderer hängt.

Ich habe mal angefangen zu suchen.
Kann ich retry und lost genauer analysieren?
Habe auf dem einen CUL mehr retrys als auf dem anderen.
Mit verbose 5 (cul_max) sehe ich nur dass es retry Versuche gibt, aber nicht warum.

Habe zb mal ein device mit "vielen" retrys. (Was ist da eigentlich viel? Mehr als 1 pro Tag und device?)
Kann man eigentlich die weekprofiles irgendwie löschen?
Ich nutze sie nicht und sie machen nur die readings Liste lang.

Code Auswählen Erweitern



Internals:
   CULMAX0_MSGCNT 29
   CULMAX0_TIME 2020-03-12 12:19:19
   DEF        HeatingThermostat 18f97e
   FUUID      5da733c7-f33f-a5e8-92bb-9c972b02346d99cc
   FVERSION   10_MAX.pm:?/2020-03-11 UNSTABLE
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     29
   NAME       hkGastUnten
   NR         85
   NTFY_ORDER 50-hkGastUnten
   STATE      waiting for data
   TYPE       MAX
   TimeSlot   6
   addr       18f97e
   devtype    1
   type       HeatingThermostat
   READINGS:
     2020-01-30 18:19:23   PairedTo        123456
     2020-03-12 12:19:19   RSSI            -75
     2020-01-30 18:19:23   SerialNr        OEQ0444847
     2019-10-16 18:10:52   TimeInformationHour 1
     2020-03-12 12:19:19   battery         ok
     2020-03-12 12:19:19   batteryState    ok
     2019-10-16 17:14:15   boostDuration   25
     2019-10-16 17:14:15   boostValveposition 80
     2019-10-16 17:14:15   comfortTemperature 21.0
     2019-10-16 17:14:15   decalcification Sat 12:00
     2020-03-12 12:19:19   desiredTemperature on
     2020-03-12 12:00:44   deviation       -12.8
     2019-10-16 17:14:15   ecoTemperature  17.0
     2020-01-30 18:19:23   firmware        1.0
     2020-03-12 12:19:19   gateway         1
     2019-10-16 17:14:31   groupid         0
     2020-03-12 12:19:19   lastConfigSave  ./log/hkGastUnten.max
     2020-03-12 07:48:14   lastTimeSync    2020-03-12 07:48:14
     2020-03-12 12:19:19   lastcmd         maxValveSetting 0
     2020-03-12 09:49:26   mapleCUN1_lost  17
     2020-03-12 11:49:18   mapleCUN1_retry 62
     2020-03-12 12:19:19   maxValveSetting 0
     2019-10-16 17:14:15   maximumTemperature on
     2019-10-16 17:14:15   measurementOffset 0.0
     2019-10-16 17:14:15   minimumTemperature off
     2020-03-12 12:19:19   mode            manual
     2020-03-12 12:19:18   msgcnt          76
     2020-03-12 12:19:19   panel           locked
     2020-03-12 12:00:44   peerIDs         000000
     2020-03-12 12:00:44   peerList        Broadcast
     2020-03-12 12:19:19   rferror         0
     2020-03-12 12:19:19   state           waiting for data
     2020-03-12 12:00:44   temperature     17.7
     2020-01-30 18:19:23   testresult      160
     2019-10-16 17:14:15   valveOffset     0
     2020-03-12 12:19:19   valveposition   0
     2019-10-16 17:14:15   weekprofile-0-Sat-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2019-10-16 17:14:15   weekprofile-0-Sat-time 00:00-06:00  /  06:00-22:00  /  22:00-00:00
     2019-10-16 17:14:15   weekprofile-1-Sun-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2019-10-16 17:14:15   weekprofile-1-Sun-time 00:00-06:00  /  06:00-22:00  /  22:00-00:00
     2019-10-16 17:14:15   weekprofile-2-Mon-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2019-10-16 17:14:15   weekprofile-2-Mon-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2019-10-16 17:14:15   weekprofile-3-Tue-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2019-10-16 17:14:15   weekprofile-3-Tue-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2019-10-16 17:14:15   weekprofile-4-Wed-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2019-10-16 17:14:15   weekprofile-4-Wed-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2019-10-16 17:14:15   weekprofile-5-Thu-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2019-10-16 17:14:15   weekprofile-5-Thu-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2019-10-16 17:14:15   weekprofile-6-Fri-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2019-10-16 17:14:15   weekprofile-6-Fri-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2019-10-16 17:14:15   windowOpenDuration 15
     2019-10-16 17:14:15   windowOpenTemperature 12.0
   helper:
     io:
       mapleCUN1:
         raw        Z0E4C020218F97E123456000139003D
         rssi       -84
         time       1584011959.51813
       mapleCUN2_1:
         raw        Z0E4C020218F97E123456000139003D
         rssi       -75
         time       1584011959.41694
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   CULdev     mapleCUN1
   IODev      CULMAX0
   model      HeatingThermostat
   mqttPublish *:topic={"$base/$device/$name"}
   room       1_Gast



[Wzut]

Nein man kann den Geräten leider nicht ins Hirn schauen warum sie keine Antwort geben. Fakt ist aber wohl bei dir das keine Antwort kommt, zumindest nicht beim ersten Versuch. Was die Häufigkeit angeht : Fast alle Geräte haben bei mir Null Wiederholungen über den Tag, was aber auch nicht verwunderlich ist, denn im Normalfall  schickt FHEM ja nichts an die Geräte sondern empfängt nur.
Daher auch die Frage : warum muß bei dir FHEM so oft mit einem Gerät reden ?

Wochenprofil kannst du nicht ganz ausschalten aber ein kurzes primitiv Profil setzen ala 00:00 - 24:00 20°C  und das für alle 7 Tage

Warum hat dein Device  mapleCUN1 als CULdev und nicht  mapleCUN2_1 mit seinem besseren RSSI ?

[Maui]

Naja ich beobachte es die nächsten Tage mal weiter.
Im Moment passen die credits ganz gut.
Hab den CUL mal gewechselt bei dem HT. Der 1er ist eigentlich näher dran als der andere.

Ich sende so viel an die HTs, weil ich mit PID20 regele. Und somit höchstens alle 10 Minuten 13 HTs einen neuen maxValve Wert gebe.
Könnte ich auch noch zur not auf 15 Minuten hoch drehen.

[Wzut]

OK mit dem PID20 ist das bei dir natürliche eine ganze andere Welt.
Was ich an deiner Stelle machen würde ist bei jedem HT das Attribut debug setzen damit du ständig die RSSI beider CULs in den Readings hast und damit loggen und plotten kannst. Dann siehst du schön wer i.d.R. über den Tag verteilt über der bessere Partner ist (Nähe ist eben nicht alles) und danach die Entscheidung treffen welches CULdev endgültig verwendet werden soll.

[Maui]

Hatte ich gestern schon gemacht. Und alle (bis auf Gast unten) waren schon mit dem richtigen connected.
Aber danke für den Tipp.

[Wzut]

Heute ist war erst Samstag, ich habe euch trotzdem schon heute eine neue Version von 10_MAX in den Beta Thread gelegt.
Wie in einem anderen Therad angesprochen ein neues Attribut zur Überwachung  der Soll Temperatur zum Wochenprofil (HT & WT) und als "Abfallprodukt" daraus ein Reading das die Fenster offen Zeit in Stunden:Minuten anzeigt. (FK,HT & WT )