Die MAX Module heute und die Aussichten für 2020

Wzut · 27 März 2020, 08:44:11

ja du hast recht. 30.5 wird normal zur reinen Anzeige in on gewandelt und 4.5 in off. Beides wird aktuell beim setzen des Readings desiredTemperatur verworfen :

Code Auswählen

  if (exists($shash->{'.desiredTemperature'}) && ($shash->{'.desiredTemperature'} ne 'on') && ($shash->{'.desiredTemperature'} ne 'off'))
  {
   readingsBulkUpdate($shash, 'desiredTemperature', $shash->{'.desiredTemperature'});
   readingsBulkUpdate($shash, 'windowOpen', '0') if (($shash->{'.desiredTemperature'} != ReadingsNum($sname,'windowOpenTemperature',0)) && (ReadingsVal($sname,'windowOpen','0') ne '0') && AttrNum($sname,'windowOpenCheck',0));
  }

ich überlege schon die ganze Zeit warum ich das ausklammern wollte ... anaway wenn du den Block oben kürzt auf

Code Auswählen

readingsBulkUpdate($shash, 'desiredTemperature', $shash->{'.desiredTemperature'}) if (exists($shash->{'.desiredTemperature'});

dann solltest du dein on und off wieder haben. Ich möchte an der Stelle erst einmal keine neue Datei hochladen, da ich bei mir noch einen anderen Fehler habe den ich schon seit über einem Tag krampfhaft suche.

Maui · 27 März 2020, 09:04:05

Danke dir. Ich bin geduldig. Wollte nur fleißig "Fehler" melden. Der HT macht ja was er soll.

Wzut · 29 März 2020, 18:36:41

Was haben wir heute ? Richtig , den ersten Tag der Sommerzeit aber auch mal wieder Sonntag und somit höchste Zeit für eine neue Beta Runde.
Die letzte Woche hat sich im Modul Entwicklerbereich einiges getan, so gibt es jetzt da ein Unterforum wo u.A. über Qualität des Perl Modulcodes diskutiert wird.
Juckt den normalen Anwender eigentlich herzlich wenig, der will i.d.R. "nur" das ein Modul das tut was es soll, ob der Code nun mit rosa Schleifen geschmückt oder total häßlich ist.
Einige Modulautoren sehen das etwas anderes, ein Stichwort ist z.B. Lesbarkeit. Trifft zu wenn z.B. ein Modul den Maintainer wechselt.
Lange Rede kurzer Sinn : ich habe jetzt einige der dort gemacht Empfehlungen in der aktuellen Beta umgesetzt.
Mir wäre es sehr recht wenn möglichst viele da mitesten würden, denn die jetzt gemachten internen Änderungen sind teilweise recht umstritten.
Wichtig ist wie so oft : Nicht einfach nur das Modul tauschen und ein simples reload 10_MAX machen, sondern FHEM komplett neu starten !

eine kleine Erweiterung habe ich aber doch noch : -> https://forum.fhem.de/index.php/topic,107152.msg1036354.html

Maui · 29 März 2020, 22:34:26

Wird getestet.
Direkt aufgefallen:
-desTemp on geht wieder
-Version beim max modul ist weg?! (Bei max und cul_max gab es bei deinen Beta Versionen immer unter fixversion ein timestamp (DL Datum und unstable unter fixversion). Das ist nu weg. Vielleicht ja auch absicht.

Wzut · 30 März 2020, 08:16:32

ist Absicht da ich die Unterstützung für den FHEM Installer auf Eis gelegt habe bis da was geklärt ist, sollte aber keinen Einfluß auf die Arbeitsweise des Moduls haben.

Maui · 02 April 2020, 08:39:12

Moin. Hast du eine Idee oder einen Ansatz, wie man das leerlaufen der Credits besser visualisieren kann?
Es gibt ja schon im CUL_MAX das Reading .*_cmd_last_h, aber damit sehe ich ja nur die abgesetzen Kommandos eines CUNs.
Und dort werden vermutlich auch nicht die retrys abgebildet, oder?
Interessant wäre als debug bei einzelnen MAX-Geräten die Anzahl der wirklich stattgefundenen Sendevorgänge an das Gerät (wenn das technisch geht).
Oder alternativ eine Art History der SendQueue, sodass man im Falle der Fälle besser debuggen kann, wenn die Credits leergezogen werden.

Wzut · 02 April 2020, 08:51:35

hm hm , ja mir ist dein Problem klar, wenn man erst später sieht das da wieder mal so ein riesen Einbruch in den Credits war.
Da stellt sich dann natürtlich jedesmal die Frage : wer und warum ?
Ich hatte bisher überlegt ob man vllt im cm Device einen Schwellwert setzen kann der bei Unterschreitung eines Credit Werts X automatisch das verbose auf 5 hoch setzt und später wieder runter, dann würde zumindest die Log Datei sich nicht so aufpumpen.
a. History der SQ sollte relativ einfach machbar sein , logging in eine extra Datei ?
b. History für jedes Device : vllt ein möglicher Ansatz mit entsprechendne Readings und Hilfe des Statistic Moduls ?

Ich überleg mir was, vllt habe ich den Tag über einen Geistsblitz

Maui · 02 April 2020, 08:54:47

History der SendQueue wäre schonmal ein super Anfang. Mit FileLog in extra Datei klingt gut. Das geht aber aktuell noch nicht, oder? Ich kann ja nur per get ShowSendQueue mir die aktuelle Queue abfragen, aber nicht neue Einträge in ein Log schreiben, oder?
Aus der Datei kann man dann ja mit wc oä relativ schnell Statistik betreiben. Mich interessiert ja wirklich nur der Fall, wenn es knallt.

Wzut · 02 April 2020, 12:46:25

Nein müsste ich einbauen.
Was du aber heute schon machen kannst : setze bei jedem MAX Device das Attribut CULdev und beim CULMAX debug auf 1
dann logst du alle Readings des CULMAX mit dem Filter (.*_lost|.*_nack|.*_retry) in ein neues Filelog
Bei Problemen musst du da durchschauen oder du erstellt dir gleich noch ne handvoll SVGs in einem eigenen Raum.
Wenn die dann alle untereinader stehen siehst du auf einen Blick wer & wann da Probleme gemacht hat, es fehlt dann nur das warum

Maui · 02 April 2020, 13:26:37

Bei dem Thema fällt mir wieder ein: Kann es sein, dass du bei CUL_MAX das readingsUpdate anders machst als bei MAX?
Hintergrund: Habe mehrere FHEM-Instanzen, die ich per MQTT-GB zusammenführe in einen Master. Dieser Master loggt per DB-Log die mir wichtigen Daten.
War jetzt ein kleiner Rundumschlag zum Abholen. Bei den MAX Geräten (und anderen devices) klappt das Senden über die Bridge, aber bei CUL_MAX kommen nicht wirklich readings rüber.
Kann es sein, dass das updaten bei CUL_MAX kein event erzeugt?

Edit: Ich habe grad mal gesucht, und es wird wohl an

Code Auswählen

setReadingsVal liegen, da dort kein Event erzeugt wird. Hast du eine Idee, wie ich da trotzdem was triggern kann in fhem?!

Gruß

Wzut · 02 April 2020, 20:13:18

richtig setReadingsVal erzeugt keine Events .... k.A. warum ich mich da gegen readingsSingleUpdate entschieden habe.
Hab die 14_CUL_MAX.pm im Beta Thread getauscht, teste mal.

Maui · 02 April 2020, 21:52:15

Achtung. Du hast beim ersetzen singele geschrieben.

Wzut · 03 April 2020, 07:33:35

oh verdammt und ausser dir hat jetzt noch einer die kaputte Version erwischt .. THX !!

Maui · 03 April 2020, 07:38:37

Ne das war 2x ich. Ich hab das gestern erst nebenbei gemacht und nicht in FHEM sondern in fhem kopiert.
Später dann nochmal neu gemacht und deswegen 2x geladen.
Hab dann gestern abend bei mir erstmal die Singele gegen Single ersetz. Damit die Heizung brav weiter läuft.

jonien · 14 April 2020, 19:45:49

Hallo,
bin jetzt einige Zeit am testen der neuen Module und muss feststellen, das diese für mich einen echten Mehrwert haben

Ich habe einen externen Temperatursensor eingebunden und habe diesbezüglich eine Frage.
HeatingThermostatPlus Readings:
externalTemp 14.2
desiredTemperature 16.0
temperature 16.5
measurementOffset 0.0
Wirkt die "externalTemp" irgendwie intern auf die Ereichung der desiredTemperature ein? Oder müsste ich über ein "notify" das measurementOffset dynamisch anpassen?

Eine weitere Verständisfrage habe ich zu den max.template. Ich habe dieses nach meinen Bedürfnissen angepasst. Wie kann ich ggf. ein eigentständiges (zusätzliches) max.template anlegen? Aktuell habe ich diese aus den Updates herausgenommen, da ich befürchte, das es jeweils überschrieben werden könnte.

Vielen Dank für die vielen Verbesserungen!