Viele werden es nicht mitbekommen haben, ich habe Ende November den Support für alle MAX Module übernommen.
Dank Hardware Spenden einiger netter User im Marktplatz konnte ich neben meinem aktiven MAX System noch eine Testinsel aufbauen mit einem Cube ( original ELV Firmware). Die ersten beiden Wochen habe ich extrem viel Funktelegramme zwischen dem Cube und den Geräten bzw. der Geräte untereinander gelogt und analysiert.
Ziel war es ein besseres Verständnis der Arbeitsweise der MAX Module zu bekommen. Einige kleine Fehler konnte ich schon fixen und das Logging ist auch stark erweitert.
Das erweiterte Logging bringt Euch im Normalbetrieb nichts, für mich war es aber sehr hilfreich um bestimmte Zusammenhänge besser zu verstehen und Ihr werdet daraus Nutzen ziehen können wenn vllt. mal etwas nicht so ganz rund läuft und es darum geht die Ursache zu finden.
Ich habe schon öfters geschrieben das in meinen Augen das größte Manko von 14_CUL_MAX die Tatsache ist das es nicht mit mehr als einem CUL klar kommt.
In der Beziehung kann man nur neidisch zu HM rüber schielen wo das mit der VCCU in meinen Augen einfach perfekt umgesetzt ist :(
Aber am Freitag Abend gab es einen kleinen Durchbruch : Ich habe bis jetzt recht erfolgreich zwei CULs und zwei CUL_MAX Devices auf meinem Testsystem gleichzeitig laufen. So wird es vermutlich ab Januar 2020 möglich sein ein ganzes Haus mit einer FHEM Zentrale und mehreren IOs (USB/Lan) abzudecken !
Das können dann entweder mehrere kleine MAX Inseln mit jeweils einer eignen ID sein oder alles unter dem Dach einer Einzigen. Der Unterschied zur HM VCCU ist allerdings das es bis jetzt noch nicht so schön automatisch läuft was das Senden betrifft, aber beim reinen Empfang arbeiten alle CULs gut zusammen. FHEM hat die Eigenschaft doppelte Telegramme zu erkennen ( Stichwort attr global dupTimeout ) so das man sich als Entwickler darum schon mal nicht selbst kümmern muß, allerdings "gewinnt" das erste Telegramm das ankommt. Dieses muss aber nicht unbedingt auch den besten RSSI Wert haben.
Beim senden bestimmt z.Z. noch der User via dem IODev bzw. CULdev Attribut über welchen CUL sein Endgerät angesprochen wird, aber vllt. kann man ja bei der VCCU noch die eine oder andere Idee klauen.
Hallo Wzut,
ich möchte mein erstes öffentliches Posting im FHEM-Forum dazu nutzen, um dir ein herzliches Dankschön für die Weiterentwicklung im MAX-Bereich zu übermitteln.
Wegen Reichweitenproblemen habe ich seit einiger Zeit zwei zu CUL's umgeflashte MAX-Cubes im Einsatz, was ja bekanntermaßen einige Probleme bereitet. Nun habe ich deine Beta-Module einige Tage getestet und bin richtig begeistert. Endlich kann ich bestimmen, welche MAX-Komponenten mit welchem CUL kommunizieren und habe kaum noch Paketverluste und dadurch auch ein viel besseres Credit-Management.
Also noch einmal ein großes Danke, damit deine Motivation hoffentlich noch längere Zeit erhalten bleibt. :)
Ich danke dir ebenfalls für das erste Feedback eines Multi IO Users :)
Bitte bedenke aber : Auch wenn das jetzt schon recht gut für dich persönlich läuft ist es noch nicht wirklich fertig.
Z.Z. bastele ich :
a. an der Unterstützung für mehr als eine MAX Wolke auf einem FHEM
b. und daran das IO Handling zu verbessern, in dem der User entweder eine Vorauswahl treffen kann (HT Wohnzimmer über CUL1 ) oder automatisch an Hand der besseren RSSI Werte.
So richtig knifflig wird es wenn man a und b zusammen betrachtet ....
Das hört sich spannend und vielversprechend an.
Ich bleibe am Ball und werde die weitere Entwicklung auf jeden Fall verfolgen und eifrig mittesten...
Wow, das ist Mal ein Weihnachtsgeschenk. :)
Ich warte noch die aktuelle Heizperiode ab und dann werde ich intensiv testen und Rückmeldung geben.
So kann ich mindestens eine (virtuelle) fhem instanz loswerden.
Es ist vollbracht ! Mann kann nun mehr als eine MAX Wolke unter FHEM betreiben und jede Wolke darf auch wieder mehere IOs (CUL) haben.
Ich habe eben die Beta Versionen ausgetauscht.
Seit ein paar Tagen hat 00_CUL ein neues Attribut maxid, bitte einmal update 00_CUL ausführen um diese Version zu erhalten.
Kurzanleitung für zwei MAX Wolken/Inseln : ACHTUNG erfordert mindestens auch zwei CULs (einen pro ID !!!)
1. bei jedem CUL Device das Attribut maxid auf die ID der MAX Wolke setzen die dieser CUL versorgen soll (beim senden)
2. im CULMAX Device das attribut IOgrp setzen , z.b. CUL1,CUL2 darauf achten das die Namen wirklich zu Punkt 1 passen.
3. bei jedem MAX Device das Attribut CULdev auf den Namen des zuständigen CULs setzen, auf keinen Fall leer lassen !
Dieser Punkt ist extrem wichtig, wenn ihr hier den falschen CUL eintragt wird das Senden an das Gerät in jedem Fall scheitern und sehr schnell hat der CUL dann alle seine Credits verbraten !!!
4. FHEM neu starten
Schön. Ich hätte ein paar Fragen.
-Hast du einen groben Zeitplan, wann du aus der Beta raus willst? Vielleicht spring ich doch noch auf den Beta-Zug und teste mit. Du scheinst ja einiges geändert zu haben, und das Modul wird mit Sicherheit besser geworden sein. Wurde ja ewig kaum gepflegt.
-maxid finde ich gleich doppelt nicht so schön vom Naming, da a) alles klein, und b) man bei maxid erstmal andere Erwartungen hat. Nur als Info :)
-Wolken ist für dich ein Satz an MAX-Geräten, welche alle mit einer ID per CULMAX zusammenarbeiten, richtig? Ich sehe keinen Mehrwert, wenn ich eh mehrere CULs pro CULMAX definieren und nutzen kann. Höchstens den historischen, ich muss meine bereits bestehenden Wolken nicht neu pairen und könnte sie so fortführen.
Gruß und Danke, du motivierst mich, dass ich meine MAX-HW doch noch nicht bald entsorgen muss ;)
Noch einmal danke für deinen Einsatz für die immer kleiner werdende MAX-Gemeinde. :)
Genau wie Maui habe ich allerdings den praktischen Mehrwert von mehreren Wolken/Inseln noch nicht verstanden. Kannst du uns den Unterschied zwischen 2 CUL's in einer Wolke und jeweils einem CUL in zwei Wolken erklären? Hat die eine Lösung Vorteile gegenüber der anderen?
Irgendwie stehe ich gerade auf der Leitung...
Zitat von: Maui am 08 Januar 2020, 13:30:43
-maxid finde ich gleich doppelt nicht so schön vom Naming, da a) alles klein, und b) man bei maxid erstmal andere Erwartungen hat.
Ich habe mich da 00_CUL angepasst , da gab es für Homematic schon das Attribut hmid und für mich war es logisch da weiter zu machen mit maxid :)
Aber anyway , diese maxid ist nur wirklich wichtig wenn wer unbedingt diese zwei/drei Wolken/Inseln unter einer FHEM Instanz haben will.
Ich geb dir und Plextor völlig Recht, ich würde es bei mir auch nicht machen sondern immer den Weg gehen viele IOs aber nur eine ID.
Zeitplan : Das 10_MAX könnte ich eigentlich sofort einchecken, möchte aber damit nochmal zurück auf den Original Cube zusammen mit MAXLAN
um ganz sicher zu sein da keine negativen Auswirkungen zu haben.
Das 14_CUL_MAX könnte ich auch raushauen, wäre aber schön doch noch etwas mehr Feedback über Multi IO zu haben.
Fertig sind beide Module noch nicht , zumindest ich kenne da noch Schwachstellen die mir nicht gefallen :
a. Das Pairing und Peering von Fensterkontakten ist höflich gesagt suboptimal.
b. ich träume auch noch davon das Multi IO Handling etwas dynamischer wie bei HM zu machen statt wie jetzt starr
Das pairing von FK empfinde ich jetzt auch schon als lästig. Die HTs zicken da nicht so. Von den FKs bekommt man häufig einen rf error zurück und nicht immer ist mir ersichtlich warum. Bzw. Nach dem Wechsel eines CUL mit gleicher culmax id laufen die HTs super und die FKs muss ich resetten und neu pairen wenn ich keine rf errors will.
Gruss
Ja da man WTs und HTs jederzeit direkt ansprechen kann ist das alles kein Problem. Die FKs schlafen halt die meiste Zeit und wachen nur auf wenn der Reedkontakt betätigt wurde oder der Config Button gedrückt wurde oder eben auch x mal am Tag um ihren Status los zu werden wenn sie mit einer Zentrale gepaired sind.
Die Orginal ELV Software mit dem Cube macht das viel eleganter als heute CUL_MAX und da würde ich gerne hin.
rf errors lassen sich aber inzwischen recht gut finden, die neuen debug Attribute sowie ein verbose 5 Log helfen (mir) sehr gut weiter :)
Ich verlange gar nicht das jeder fit im Log lesen ist, aber erstellen und posten kann jeder, ich helfe dann als Klugscheisser schon weiter .....
kleines Update :
ich habe die Version im Beta Thread ausgetauscht , neues Get Kommando showSendQueue , Beispiel im Thread
und das nächste Update :
10_MAX
neue Set Funktion deviceRename
Vllt. wird so der eine oder andere User doch noch ermutigt seinen MAX Geräten einen anderen Namen als den von autocreate erzeugtem MAX_112233 Namen zu geben. Im Unterschied zum FHEM rename Konsole Kommando werden hier eventuell betroffene FileLogs gleich mit geändert.
neues Attribut externalSensor (device:reading)
Wenn in einem Raum kein Wandthermostat vorhanden ist aber die Raumtemperatur zusätlich mit einem externen Sensor in FHEM erfasst wird (z.B. LaCrosse)
kann dessen aktueller Temperatur Wert zur Berechnung des Readings deviation benutzt werden statt des eigenen Readings temperature
neue Readings peerList und peerIDs (Name analog zur HomeMatic Welt)
Schon oft im Forum angefragt : Wie lese ich aus einem MAX Device die anderen Geräte aus die mit diesem assoziiert sind (peers) ?
Einfache Antwort : gar nicht , bzw. bis heute ist kein Befehl bekannt der irgend etwas von einem MAX Gerät auslesen kann.
Die jetzt eingebaute einfache Lösung überwacht den Datenaustausch zwischen zwei Geräten und sammelt diese Daten in den beiden Readings.
So kann man z.B. recht leicht herausfinden ob ein Fensterkontakt wirklich mit seinem HT / WT assoziiert ist oder ob er seinen Status lediglich als Broadcast Nachricht verschickt.
Für diese neuen Funktionen wird unbedingt auch die neue Version von CUL_MAX benötigt und auch ein FHEM Neustart ist dringend empfohlen.
Die 10_MAX arbeitet auch mit MAXLAN oder älternen CUL_MAX Versionen zusammen, allerdings stehen dann die hier beschriebenen Neuerungen teilweise oder gar nicht nicht zur Verfügung.
Moin. Ich bin jetzt gestern auch auf den Beta-zug aufgesprungen. Bisher sieht alles gut aus aber multi-CUL kann ich erst testen meine Teile aus china alle da sind.
Bzgl deviation? Wird damit auch aktiv was getan am HT, also mit der Temperatur gearbeitet?
Im Moment nutze ich die max Thermos als Aktor und mit PID20 und ext Sensor wird geregelt. Über maxValve dann eingestellt
Z.Z. wird deviation (Abweichung) bei jeder aktualisierung berechnet ( IST - SOLL ) durch den externen Sensor wird lediglich für IST statt des Readings temperatur der aktuelle Wert des externen Sensors genommen. Ziel ist es aber das später noch weiter auszubauen (Stichwort fakeWT).
Hallo,
Zitat von: Wzut am 17 Januar 2020, 07:04:48
neue Set Funktion deviceRename
das FHEM-rename ändert aber doch auch das FileLog-Device? Ändert die neue deviceRename-Funktion dann jetzt auch die Devicenamen innerhalb der Logs, auch rückwirkend - bislang nur über händisches suchen und ersetzen zu schaffen? Greift dein deviceRename auch Modulübergreifend durch (ändert in den verknüpften Devices, wie PID20 o.ä.)?
Ich habe zwar die MAX-123456 Namen geändert, aber so richtig einheitlich und trotzdem sprechend ist das alles nicht. Ich schrecke aber davor zurück, auch in den aufgelaufenen Monatslogs rückwirkend rumzuändern (und ja, ich bin kein Freund vom "digitalen Vergessen". Vielleicht sind die Daten für eine eigene KI später mal interessant - so viel Speicherplatz habe ich).
Zitat von: Wzut am 17 Januar 2020, 07:04:48
Ziel ist es aber das später noch weiter auszubauen (Stichwort fakeWT).
Soll das dann später mal fakeWT ablösen können?
In jedem Fall ganz vielen lieben Dank für die Weiterentwicklung und die vielen neuen Funktionen!
Grüße,
Jan
Zitat von: JHo am 17 Januar 2020, 09:17:54
das FHEM-rename ändert aber doch auch das FileLog-Device?
im ersten Moment wollte ich da eigentlich widersprechen da es mein FHEM nicht macht. Allerdings habe ich jetzt nochmal die command.ref zum autocreate Modul gelesen und dort steht das Gegenteil :( D.h. ich werde mich wohl oder übel noch mehr mit autocreate beschäftigen müssen.
Änderungen an anderen Modulen bzw. dem Inhalt von Log Dateien :
Mir ist z.Z. kein Modul bekannt das so weit geht, aber ich schreibe gern bei anderen ab wenn das doch jemand erfolgreich umgesetzt hat.
fakeWT : ich ich würde hier gern in Zukunft etwas weiter gehen als heute mit dem für viele etwas verwirrendem und umständlichen Set Kommando via CUL_MAX. Ideen habe ich, trotzdem sind auch hier wie bei allen anderen Themen Vorschläge willkommen.
Zitat von: Wzut am 17 Januar 2020, 10:03:47
im ersten Moment wollte ich da eigentlich widersprechen da es mein FHEM nicht macht. Allerdings habe ich jetzt nochmal die command.ref zum autocreate Modul gelesen und dort steht das Gegenteil :( D.h. ich werde mich wohl oder übel noch mehr mit autocreate beschäftigen müssen.
Änderungen an anderen Modulen bzw. dem Inhalt von Log Dateien :
Mir ist z.Z. kein Modul bekannt das so weit geht, aber ich schreibe gern bei anderen ab wenn das doch jemand erfolgreich umgesetzt hat.
Gefährliches Halb-Erinnern meinerseits, ich werde das am Wochenende nochmal ausprobieren und hier posten:
- ich glaube, bei meinen letzten Umbenennungen (ZWave war das) wurden das jeweilige FileLog-Device (ja, das scheint von autocreate zu kommen) und auch der Devicename im aktuellen Filelog geändert (klassisches Text-Log, nicht dblog). Die älteren Logs, die im FileLog-Device ja mit angezeigt werden, wurden nicht angefasst.
- ich dachte, dass die unter "probably associated with" geführten Devices ebenso angefasst werden. Kann mich nicht erinnern, da was geändert zu haben, aber alle "at" oder "doif" tun noch, was sie sollen.
Also das FileLogs mit angepasst werden kenne ich auch so. Sogar svg plots werden beim rename mit angefasst.
Andere Devices aber nicht. Kann mir auch nicht vorstellen, dass das irgendwo in fhem passiert
Zitat von: JHo am 17 Januar 2020, 10:17:56
- ich glaube, bei meinen letzten Umbenennungen (ZWave war das) wurden das jeweilige FileLog-Device (ja, das scheint von autocreate zu kommen) und auch der Devicename im aktuellen Filelog geändert (klassisches Text-Log, nicht dblog). Die älteren Logs, die im FileLog-Device ja mit angezeigt werden, wurden nicht angefasst.
--> geprüft: ja. Das scheint von Autocreate zu kommen: Sowohl der Name vom FileLog-Device inkl. Notifydef und Regexp werden geändert (das FileLog-Device loggt also das umbenannte Device "weiter" mit, als auch die Devicenamen im aktuellen Logfile des FileLog werden geändert. "AlterName" wird tatsächlich auch im Textfile-Filelog zu "NeuerName" geändert. Allerdings nur beim aktuellen Logfile - wer monatlich ein neues Logfile schreiben lässt, muss die Files der Vormonate händisch anpassen, wenn nötig.
Zitat
- ich dachte, dass die unter "probably associated with" geführten Devices ebenso angefasst werden. Kann mich nicht erinnern, da was geändert zu haben, aber alle "at" oder "doif" tun noch, was sie sollen.
--> geprüft (mit at, notify und doif): da spielt mir meine Erinnerung einen Streich, hier wird nix mit umbenannt. Wäre vielleicht eine schöne Option, aber sicherlich keine Baustelle hier.
Bisher rennt die neue Version echt gut. :)
Spannend wird es, wenn in den nächsten 2 Wochen meine neuen mapleCUN's in einem fhem zusammenlaufen.
Ein wenig OT: Wenn ich nicht will, dass die Beta Versionen vom update überschrieben werden, wäre wohl ein exclude_from_update die einzige saubere Möglichkeit oder?
Müsste es nicht auch gehen, den owner auf root zu ändern? Nicht dass es seine schöne Lösung ist, aber ich sehe mich schon in paar Wochen per update die Versionen überschreiben. ::)
root bewirkt zwar auch das die Module nicht überschrieben werden, allerdings bricht das Update dann ganz ab und kein Modul wurde überschrieben :)
Naja zumindest hält es mich dann von dummen Taten ab ;D
Danke.
Ich will dir wirklich nicht in die Suppe spucken, deswegen frage ich nur so als lose Idee.
Eine Möglichkeit wäre ja auch zb. die Dateien auf github zu legen und dann in das update mit einbringen. Aber da weiß ich dann auch nicht wer gewinnt beim Update, ob fhem oder github.
Gruß
von github halte ich gar nichts :
a. habe ich dort keinen Account und wenn ich ihn hätte wüsste ich nicht damit umzugehen.
b. wir haben doch hier genug Möglichkeiten innerhalb der FHEM Welt da brauch es keine Externen.
Erstmal ein Danke an Wzut das du MAX! Übernommen hast. Einen zweiten IO kann ich bei mir super gebrauchen, bin aber erst im Februar wieder im Haus um da einen zweiten einzubauen. Das tolle ist, ich habe noch einen Cube rumliegen, perfekt, super, danke!
Update :
Ich habe gestern Abend wieder neue Version bereit gestellt.
14_CUL_MAX -> fix der Abstürze durch nicht vorhandene sub bei fakeWT und fakeSC -> https://forum.fhem.de/index.php/topic,107522.0.html
10_MAX -> neue Set Kommandos saveConfig , restoreReadings & restoreDevice
ich komme mir langsam vor wie Cindy & Bert ( immer wieder Sonntags ... )
10_ MAX :
Fix msgcnt , damit sollte der MAXScanner wieder funktionieren.
Fix lastcmd , wird nun auch bei desiredTemperature richtig gesetzt
Erweiterung des externalSensor Attributs um die fakeWT Funktion
neues Sets : restore/Device / exportWeekprofile
(ausführliche Beschreibung im Beta Thread )
Neue Woche, neues Glück :)
lastcmd passt jetzt.
Allerdings habe ich immer noch peerIDs 000000 und peerList Broadcast.
(Für mich persönlich nicht schlimm, da trotzdem alles läuft.)
Internals:
CULMAX0_MSGCNT 28
CULMAX0_TIME 2020-02-03 15:06:17
DEF HeatingThermostat 18acec
FUUID 5e328478-f33f-a5e8-8a55-7954e49c8ec1faad
FVERSION 10_MAX.pm:?/2020-02-03 UNSTABLE
IODev CULMAX0
LASTInputDev CULMAX0
MSGCNT 28
NAME hkAnkleide
NR 213
NTFY_ORDER 50-hkAnkleide
STATE 18.0°C
TYPE MAX
TimeSlot 5
addr 18acec
devtype 1
type HeatingThermostat
READINGS:
2020-02-03 14:33:25 PairedTo 123456
2020-02-03 15:06:17 RSSI -52
2020-02-03 14:33:25 SerialNr OEQ1133534
2020-02-03 15:06:17 battery ok
2020-02-03 15:06:17 batteryState ok
2020-01-30 08:23:37 boostDuration 25
2020-01-30 08:23:37 boostValveposition 80
2020-01-30 08:23:37 comfortTemperature 21.0
2020-01-30 08:23:37 decalcification Sat 12:00
2020-02-03 15:06:17 desiredTemperature 18.0
2020-02-03 15:06:17 deviation 0.4
2020-01-30 08:23:37 ecoTemperature 17.0
2020-01-30 08:23:37 error invalid or missing value for READING groupid
2020-02-03 14:33:25 firmware 1.0
2020-02-03 15:06:17 gateway 1
2020-01-30 08:23:37 groupid 0
2020-01-30 08:23:37 lastConfigSave 2020-01-30 08:23:37
2020-02-03 01:23:39 lastTimeSync 2020-02-03 01:23:39
2020-02-03 10:29:34 lastcmd desiredTemperature 18.0
2020-02-03 15:06:17 mapleCUN2_1_RSSI -52
2020-02-03 15:06:17 mapleCUN4_RSSI -82
2020-01-30 08:23:37 maxValveSetting 100
2020-01-30 08:23:37 maximumTemperature on
2020-01-30 08:23:37 measurementOffset 0.0
2020-01-30 08:23:37 minimumTemperature off
2020-02-03 15:06:17 mode manual
2020-02-03 14:33:25 msgcnt 2
2020-02-03 15:06:17 panel locked
2020-02-03 15:06:17 peerIDs 000000
2020-02-03 15:06:17 peerList Broadcast
2020-02-03 15:06:17 rferror 0
2020-02-03 15:06:17 sendTo_Broadcast 382
2020-02-03 15:06:17 state 18.0°C
2020-02-03 15:06:17 temperature 18.4
2020-02-03 14:33:25 testresult 160
2020-01-30 08:23:37 valveOffset 0
2020-02-03 15:06:17 valveposition 4
2020-01-30 08:23:37 weekprofile-0-Sat-temp 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-0-Sat-time 00:00-06:00 / 06:00-22:00 / 22:00-24:00
2020-01-30 08:23:37 weekprofile-1-Sun-temp 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-1-Sun-time 00:00-06:00 / 06:00-22:00 / 22:00-24:00
2020-01-30 08:23:37 weekprofile-2-Mon-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 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:23:37 weekprofile-3-Tue-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 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:23:37 weekprofile-4-Wed-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 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:23:37 weekprofile-5-Thu-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 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:23:37 weekprofile-6-Fri-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 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:23:37 windowOpenDuration 15
2020-01-30 08:23:37 windowOpenTemperature 12.0
helper:
io:
mapleCUN2_1:
raw Z0F00046018ACEC0000000039042400B8
rssi -52
time 1580738777.86329
mapleCUN4:
raw Z0F00046018ACEC0000000039042400B8
rssi -81.5
time 1580738778.04032
internals:
interfaces thermostat;battery;temperature
Attributes:
CULdev mapleCUN2_1
IODev CULMAX0
debug 1
model HeatingThermostat
mqttPublish *:topic={"$base/$device/$name"}
room 2_Ankleide
Wenn dein HT keinen Partner (HT,WT oder FK) hat wohin soll er dann auch direkt senden ?
Ahhh wieder was gelernt.
Bei anderen klappt es auch, grad gesehn.
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"
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.
Zitat von: Wzut am 03 Februar 2020, 15:55:59
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... :)
@ Maui nein , Zitat Wiki
Zitatset 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 !
Zitat von: Plextor am 03 Februar 2020, 16:19:01
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.
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:
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?
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 :
Zitat# 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.
Zum Thema groupid:
In der Commandref steht u.a. folgendes:
Zitatgroupid <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...
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.
Wo bald wieder Sonntag ist... ;D
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.
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
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 )
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?!
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 )
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.
Zitat von: Maui am 09 Februar 2020, 15:15:11
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.
Dann kann ich ja direkt wieder auf PID20 zurück mit meinem Testballon. Danke.
Hmm aber dann unterstelle ich, dass bei direkt untereinander gepairten WT und HT ohne Cube mit mindestens 2-3 von den WTs, diese in Summe (pro Haus/Wohnung) sich nicht an die 1% Regel halten?!
Zitat von: Maui am 09 Februar 2020, 17:57:32
Hmm aber dann unterstelle ich, dass bei direkt untereinander gepairten WT und HT ohne Cube mit mindestens 2-3 von den WTs, diese in Summe (pro Haus/Wohnung) sich nicht an die 1% Regel halten?!
Wenn man einen MAX-Cube zum CUL/CUN umflasht, kann man mit ein paar kleinen Modifikationen der a-culfw-Firmware dieses Ärgernis ebenfalls umgehen. Ob das jetzt legal ist, lasse ich mal dahingestellt... ::)
Ich weiß wie man die Credits im Header anpasst, aber manche Regularien haben ja auch ihren Grund.
Und irgendwann blockiert man evtl. Seine eigenen Signale.
Dann lieber die Regler-Logik in fhem und den HT als reinen (Stellglied) Knecht.
Zitat von: Maui am 09 Februar 2020, 18:52:38
Dann lieber die Regler-Logik in fhem und den HT als reinen (Stellglied) Knecht.
Und genau hier wird es verrückt : 1 x FHEM & 1 x CUL versorgen 20 Thermostate -> könnte knapp werden mit 3600 Credits
1 x FHEM & 2 x CUL = 7200 Credits -> laut Rudi rechtliche Grauzone , denn wer genau wird gezählt ? FHEM oder der CUL ?
20 x FHEM & 20 x CUL -> alles im grünen Bereich .....
Ob nun 10 WTs ständig ihr Limit ausnutzen oder 1 CUL mit "leicher" Kontoüberziehung den gleichen Job macht :)
Anyway , die Art von Diskussion gab es hier über die Jahre zuhauf, ich halte es da ähnlich wie Plextor : Ich mache was ich will und kann, rede aber nicht darüber :)
Ich hab zum Glück nur 10 HTs, welche ich (bald) selber regle. Aufgeteilt auf 2 CULs "passt" das mit den Credits.
Hast du denn zufällig mal Tests gefahren bzgl. Des Heizverhaltens mit fakeWT und mit PID20, welches schöner ist? Der PID "lernt" dazu aber der HT weiß mehr über sich selbst. Hmmm.
PID20 wollte ich schon immer mal testen, bin aber leider bisher nie dazu gekommen :(
Mal schauen ich habe in zwei Räumen HM Thermostate verbaut und weil mir die Homematic WTs zu teuer waren benutze ich die "alten" MAX WTs als Istwert.
Also quasi fakeWT nur geht es da mit den einzelen Channels viel eleganter als bei MAX
Hallo Wzut,
erstmal vielen Dank, dass du meine Investition (MAX 7x komplett) weiterhin sicherst ;)
Die Multi-Sender Variante brauche ich in unserer Wohnung zwar noch nicht, aber wer weiß...
Was mich bisher am meisten geärgert hat, ist die fehlende Intelligenz im MAX Modul für "set desiredTemperature" bei geöffnetem Fenster.
(siehe auch hier: https://forum.fhem.de/index.php/topic,95107.msg903947.html#msg903947)
Ist das etwas, was ich mir wünschen dürfte? :)
Alex
Wünchen darf man immer ... aber ich wäre vorsichtiger damit anderen ihre Inteligenz abzusprechen , siehe https://forum.fhem.de/index.php/topic,95107.msg1023065.html#msg1023065
Heyho, danke für Deine Arbeit.
Bin heute drüber gestolpert - eingerichtet, neu gepaired - und endlich keine Probleme mehr mit zwei IOs in verschiedenen Stockwerken und gebastel mit multiplen cm. Hat eine Stunde gedauert, jetzt harmonisiert das hervorragend und auch der PID20 regelt sauber. Wenns nach mir ginge könnte das ins offizielle Repo gestellt werden ;)
Dank,
Tedious
Zitat von: Wzut am 11 Februar 2020, 07:18:56
Wünschen darf man immer ...
Die "Associate" Liste zeigt mir auch alle fremden MAX Geräte, die ich auf "ignore=1" gesetzt habe.
Außerdem könnte man die Liste evtl. auch auf sinnvolle Gerätekombinationen reduzieren, z.B. Am HT nur FKs und WT zeigen, am WT nur FKs und HT zeigen.
Aber es gibt bestimmt Wichtigeres :)
nein, das ist wichtig ! Du darfst in deiner jeweiligen Liste nur Geräte stehen haben mit denen das Device wirklich redet.
Ignored Devices haben da schon gar nichts verloren, d.h. bei dir läuft etwas richtig schief.
D.h. wenn wir hier von den neuen Readings reden oder meinst du du Drop Down Auswahlliste ?
Sorry, meinte das Dropdown (die Auswahlliste) :)
ahh OK, ist schon aufgeräumt , neue Version liegt im Beta Thread.
Ebenfalls gefixt , das doppelte t und doppelte Einträge bei peers.
Funktioniert perfekt, danke für die schnelle Umsetzung!
leider nicht perfekt, bei den HTs habe ich vergessen den eigenen Namen aus der Liste zu nehmen :(
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
oh THX , war mir noch gar nicht aufgefallen :(
Ich habe auf meinem aktiven System noch eine ältere Version da fehlt es auch.
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.
ich fang mal hinten an :
Zitat von: VolkerGBenner am 29 Februar 2020, 13:34:53
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.
ZitatEr 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
ZitatInteressant 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.
ZitatFü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 :
Zitat1.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 !!
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.
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.
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.
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?
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.
Ü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.
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
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 ?
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.
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.
Hatte ich gestern schon gemacht. Und alle (bis auf Gast unten) waren schon mit dem richtigen connected.
Aber danke für den Tipp.
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 )
Hallo,
ich finde es toll, das es neue Entwicklungen für die MAX Module gibt. Viele nützliche Neuerungen.
Ich habe vor ca. 2 Wochen auf einem Zweitsystem (mit MAXLAN) die damals akt. Beta Versionen von 10_MAX.pm und 14_CUL_MAX.pm integriert. Alle MAX Geräte (Thermostate Fensterkontakte Taster) wurden erkannt, die geänderte Ansicht in Fhem und neue Attr. waren sichtbar. Und es gab das MAXtemplate in der Auswahlliste. So weit richtig gut...
Mein Ziel war, einen virtuellen Fensterkontakt (ähnl.wie bei HM) anzulegen (habe ich bisher nur mit einer "Krücke" gelöst). Das hat dann nicht funktioniert: nach Eingabe der GrID kam die Fehlermeldung IO Gerät nicht verfügbar (oä), (im Beta-Status noch nicht möglich?).
Deshalb habe ich per Update die Original Module wieder hergestellt, so weit so gut.
Nun wollte ich mit den Beta Modulen (akt. Stand) einen neuen Versuch starten... Alles wie zuvor, aber ich kann die MAXtemplates nirgendwo finden in der Geräteansicht, bzw. aktivieren.... (Im Ordner \FHEM\lib\AttrTemplate liegt ein MAX.template vom 16.3 195kb). Irgendwie stehe ich auf dem Schlauch, hat jemand einen Tipp...?
Liebe Grüße Jörg
Die Original Module unterstützen nicht den Download von Templates, d.h. was im Template steht musst du dann jeweils einzeln für jedes Device ausführen.
Versuch es nochmal mit der letzten Beta, wichtig ist das du zuvor ein update MaxCommon machst.
Deine Fehlermeldung sagt mir in der Form nichts, bitte wenn Probleme auftauchen sollten die "echten" Meldungen posten, ich kann mir nicht vorstellen das wir das nicht hin bekommen.
Edit : sorry mein Fehler. Im max.template ist der falsche Filter daher wird keine Auswahl angezeigt. Ich checke die neue Version ein (FHEM neu starten)
bzw. hänge die aktuelle Version hier an.
Danke :D
...werde ich gleich mal testen...
... die MAXtemplates können jetzt ausgewählt werden. :D Hat sich ja einiges getan...
Beim set attrtemplate kommt diese Fehlermeldung:
"Unknown template_entry_name speech_recognition_type_thermostate"
Die Fehlermeldung hatte ich auch und musste mich dann belehren lassen das mein FHEm nicht aktuell sei ....
(als Schnellhilfe kannst aber auch den set Befehl in jedem Template auskommentieren wobei IMHO trotz der Meldung alles andere umgesetzt wird)
ok :)
Gibt es für den ShutterContact auch ein template? Wird aktuell noch nicht angezeigt.
Zu meinen Versuchen mit dem virtuellemFensterkontakt, sollte das schon möglich sein?
Für FKs gibt es kein Template , a. weil mir bisher für die nicht Sinnvolles eingefallen ist und b. hatte ich mir hier https://forum.fhem.de/index.php/topic,109034.0.html mehr versprochen.
Was sollte möglich sein ? IMHO ist der virtuelleShutterContact fertig und macht was er soll.
...mit dem virtuellemFK werde ich nochmal testen.
Für die FK habe ich in der alten Conf. es wie folgt dargestellt. Ist aber immer viel Handarbeit...:
etwas weniger wird die Handarbeit wenn du statt die ganzen Attribute von Device zu Device kopierst , die am Stück in ein eigenes Template packst.
OK, das brachte bisher nichts da 10_MAX keine Templates unterstütze, aber jetzt ist das ein möglicher Weg.
...das ist ein guter Weg!
Beim virtFK mache ich wahrscheinlich einen Denkfehler, an dem ich immer wieder scheitere. So habe ich es versucht:
virtFK:
define Fenster_Bad_v MAX virtualShutterContact 345678
set virtFK open > Unknown argument open, choose one of deviceRename groupid open close
...device gelöscht, dann...
virtFK:
define Fenster_Bad_v MAX virtualShutterContact 345678
set groupid 2
Dazugehöriges Thermostat: (groupid=2)
set HzgTh_Bad associate Fenster_Bad_v
virtFK:
set virtFK open > Fenster_Bad_v, invalid IODev
a. lists im Code Tags sind immer besser als Screenshots
b. schreibst du weiter oben das du 10_MAX und 14_CUL_MAX im Einsatz hast, dein IO trägt den Namen maxlan.
Ist der nur unglücklich gewählt oder steckt hinter maxlan wirklich 00_MAXLAN und nicht 14_CUL_MAX ?
Dem Cube mit der Original Firmware kann man keine virtuellen Geräte beibringen !
Das würde die auch die Fehlermeldungen mit dem invalid IO erklären.
Hallo würde mich noch als lernfähigen Anfänger beschreiben und bin froh das es im MAX Bereich jetzt eine Menge mehr an Möglichkeiten gibt. Ich nutze fhem auf einem raspi 2b mit einem max-cul. Betreibe parallel bei meinem Bruder, der eine Etage unter mir wohnt, auch fhem auf einem raspi 3 und einem max-cul. Ist nicht gerade immer einfach Des Weiteren scheint es in der Nachbarschaft noch weitere MAX Nutzer zu geben. Da immer mal wieder neue unbekannte Geräte auftauchen.
Ich habe jetzt bei mir und meinem Bruder die Beta Module installiert und bekomme beim starten folgende Fehlermeldung:
2020.03.18 20:26:08 1: PERL WARNING: Use of uninitialized value $_ in concatenation (.) or string at ./FHEM/14_CUL_MAX.pm line 156.
Ist das ein Fehler im Code?
Naja Fehler nicht direkt , es ist wie der Name schon sagt eine Warnung.
In der besagten Zeile 156 geht es um das Attribut IOGrp daher die Frage : Was hast du da eingetagen und hast du überhaupt eine Gruppe ?
Zitat von: LostInSpace am 18 März 2020, 20:39:47
Da immer mal wieder neue unbekannte Geräte auftauchen.
Das lässt sich trotz check leider nicht vermeiden es gibt immer wieder mal zerstörte Telegramme die dann doch irgendwie passen.
Daher mein Tipp : autocreate auf disable und nur einschalten wenn wirkliche neue Geräte ins System sollen.
Ich konnte auch die Zeile 156 nachvollziehen , war ein copy&paste Fehler wenn IOgrp nicht verwendet wird.
Danke bzgl. Hinweis autocreate. Sind erst einmal disabled.
Also ich habe mit set groupid und attr. group ein wenig herum experimentiert. War aber noch nicht so wirklich zielführend. Und jetzt bekomme ich die Einstellung allerdings auch nicht mehr gelöscht.
Versuche allerdings gerade bei meinem Bruder 2 neue WTs einzubinden. Werden per autocreate auch erkannt. Versuche gerade weekproofile zu übermitteln. Die Befehle werden leider nach und nach aus der Sendeliste gelöscht. Wegen fehlendem ACC vom WT.
Irgendwo ist da aktuell der Wurm drin.. Mal schauen.
Ä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)
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..
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.
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.
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.
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.
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 !
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
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 !!
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
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.
Sieht gut aus. Danke
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ß
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.
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
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 :
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
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.
Danke dir. Ich bin geduldig. Wollte nur fleißig "Fehler" melden. Der HT macht ja was er soll.
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
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.
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.
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.
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 :)
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.
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 :)
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 setReadingsVal liegen, da dort kein Event erzeugt wird. Hast du eine Idee, wie ich da trotzdem was triggern kann in fhem?!
Gruß
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.
Achtung. Du hast beim ersetzen singele geschrieben. ::)
oh verdammt und ausser dir hat jetzt noch einer die kaputte Version erwischt .. THX !!
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.
Hallo,
bin jetzt einige Zeit am testen der neuen Module und muss feststellen, das diese für mich einen echten Mehrwert haben ;D
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!
was habe ich in https://forum.fhem.de/index.php/topic,106258.0.html externalSensor vergessen zu schreiben bzw was ist da unklar ?
ZitatWirkt die "externalTemp" irgendwie intern auf die Ereichung der desiredTemperature ein?
nein
poste doch mal dein Template hier : https://forum.fhem.de/index.php/topic,109034.0.html
::)
...ich hatte x-mal gelesen und immer den 3. Parameter nicht wirklich realisiert (fakeWT). Jetzt sollte es funktionieren...
Zitat von: jonien am 14 April 2020, 20:40:21
::)
...ich hatte x-mal gelesen und immer den 3. Parameter nicht wirklich realisiert (fakeWT). Jetzt sollte es funktionieren...
Wobei ich fakeWT nicht bei mehreren Thermostaten empfehlen würde. Das frisst dir die Credits schneller auf als das Krümelmonster.
...die LaCrosse Sensoren habe ich auf 600 sek "gedrosselt". Ich habe es jetzt für einen Raum vorgesehen. Werde es mal etwas genauer beobachten...
Ich würde dir eher PID20 empfehlen in Kombination mit maxValvePosition.
Richtig cool, dass ihr euch um bessere Anbindung der Max Thermostate bemüht. Ich habe davon ja eine Menge im Betrieb :-)
Ich habe den Thread so grob durchgelesen. Eine Anmerkung: wenn ich mich richtig erinner, und das ist schon ein paar Jahre her, ist ein Problem bei mehreren CULs, dass die sich zu jedem Funktelegram gegenseitige Auto-ACKs schicken. Das Problem liegt aber in der culfw. Falls ihr das schon auf dem Schirm hattet ignoriert bitte diese kleine Klugscheisserei :-)
Zitat von: zweiundzwanzig am 16 April 2020, 11:07:15
ist ein Problem bei mehreren CULs, dass die sich zu jedem Funktelegram gegenseitige Auto-ACKs schicken. Das Problem liegt aber in der culfw.
wenn die CULs das glücklich macht sollen sie es tun. Ich kann bis jetzt keine negativen Auswirkungen erkennen und eine Änderung der culfw liegt jenseits meines Wissens.
Klar wenn da jemand mit Plan käme und mal eben schnell eine bessere FW bauen würde .....
Das Problem ist glaube ich, dass das die credits auffrisst. Weil jedes Auto-ACK credits verbraucht. Außerdem vermute ich, dass der sendende CUL "denkt", dass das Thermostat ein ACK gesendet hat obwohl es möglicherweise ein anderer cul war.
Meines Erachtens nach müsste man in die aculf ein array mit ignorierten MAX Geräten einbauen, das man dem Cul bei der Initialisierung mitteilt. Dann können sich die culs gegenseitig ignorieren.
Kurze Frage: in der aktuellen Beta gibts ja neu virtualShutterContact.
Funktioniert das alte fakeSC immernoch, oder muss ich meinen Code direkt auf die neue Variante anpassen?
du kannst sogar fakeSC und virtualSC zusammen in einer Wolke betreiben
Hi, wollte in Corona Zeiten mal die neuen Module austesten.
Ich habe fhem angehalten und die Module überschrieben mit den neuen. Dann den pi neugestartet.
Jetzt sind alle max Geräte weg! Müssen die alle neu angelehnt werden?
Nach Rückspielen der alten Module sind wieder alle Geräte da.
Gruß Dirk
PS: Habe gerade diese Fehler in der Log gesehen
2020.04.18 08:13:10.100 0: Server shutdown
2020.04.18 08:13:10.165 1: Shutdown executed
2020.04.18 08:18:27.010 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.010 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.010 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.022 1: Including /opt/fhem/FHEM/CULMAX.cfg
2020.04.18 08:18:27.028 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 1.
2020.04.18 08:18:27.028 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 1.
2020.04.18 08:18:27.028 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 1.
2020.04.18 08:18:27.029 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 1.
2020.04.18 08:18:27.029 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 1.
2020.04.18 08:18:27.029 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 1.
2020.04.18 08:18:27.030 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 1.
2020.04.18 08:18:27.030 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 1.
2020.04.18 08:18:27.030 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 1.
2020.04.18 08:18:27.031 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 1.
2020.04.18 08:18:27.032 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 1.
2020.04.18 08:18:27.034 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 1.
2020.04.18 08:18:27.035 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 1.
2020.04.18 08:18:27.036 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 1.
2020.04.18 08:18:27.036 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 1.
2020.04.18 08:18:27.036 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 1.
2020.04.18 08:18:27.037 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 1.
2020.04.18 08:18:27.037 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 1.
2020.04.18 08:18:27.038 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 1.
2020.04.18 08:18:27.040 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 1.
2020.04.18 08:18:27.040 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 1.
2020.04.18 08:18:27.041 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 1.
2020.04.18 08:18:27.074 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.074 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.087 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 20.
2020.04.18 08:18:27.087 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 20.
2020.04.18 08:18:27.088 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 20.
2020.04.18 08:18:27.088 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 20.
2020.04.18 08:18:27.088 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 20.
2020.04.18 08:18:27.089 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 20.
2020.04.18 08:18:27.089 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 20.
2020.04.18 08:18:27.089 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 20.
2020.04.18 08:18:27.090 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 20.
2020.04.18 08:18:27.090 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 20.
2020.04.18 08:18:27.092 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 20.
2020.04.18 08:18:27.094 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 20.
2020.04.18 08:18:27.095 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 20.
2020.04.18 08:18:27.096 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 20.
2020.04.18 08:18:27.096 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 20.
2020.04.18 08:18:27.096 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 20.
2020.04.18 08:18:27.097 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 20.
2020.04.18 08:18:27.097 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 20.
2020.04.18 08:18:27.098 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 20.
2020.04.18 08:18:27.099 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 20.
2020.04.18 08:18:27.100 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 20.
2020.04.18 08:18:27.101 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 20.
2020.04.18 08:18:27.134 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.134 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.151 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 40.
2020.04.18 08:18:27.151 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 40.
2020.04.18 08:18:27.152 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 40.
2020.04.18 08:18:27.152 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 40.
2020.04.18 08:18:27.152 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 40.
2020.04.18 08:18:27.153 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 40.
2020.04.18 08:18:27.153 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 40.
2020.04.18 08:18:27.153 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 40.
2020.04.18 08:18:27.154 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 40.
2020.04.18 08:18:27.154 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 40.
2020.04.18 08:18:27.156 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 40.
2020.04.18 08:18:27.157 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 40.
2020.04.18 08:18:27.159 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 40.
2020.04.18 08:18:27.159 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 40.
2020.04.18 08:18:27.160 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 40.
2020.04.18 08:18:27.160 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 40.
2020.04.18 08:18:27.160 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 40.
2020.04.18 08:18:27.161 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 40.
2020.04.18 08:18:27.161 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 40.
2020.04.18 08:18:27.163 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 40.
2020.04.18 08:18:27.164 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 40.
2020.04.18 08:18:27.165 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 40.
2020.04.18 08:18:27.198 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.198 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.211 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 59.
2020.04.18 08:18:27.212 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 59.
2020.04.18 08:18:27.212 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 59.
2020.04.18 08:18:27.212 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 59.
2020.04.18 08:18:27.213 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 59.
2020.04.18 08:18:27.213 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 59.
2020.04.18 08:18:27.213 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 59.
2020.04.18 08:18:27.213 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 59.
2020.04.18 08:18:27.214 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 59.
2020.04.18 08:18:27.214 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 59.
2020.04.18 08:18:27.216 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 59.
2020.04.18 08:18:27.217 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 59.
2020.04.18 08:18:27.219 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 59.
2020.04.18 08:18:27.219 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 59.
2020.04.18 08:18:27.220 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 59.
2020.04.18 08:18:27.220 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 59.
2020.04.18 08:18:27.221 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 59.
2020.04.18 08:18:27.221 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 59.
2020.04.18 08:18:27.222 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 59.
2020.04.18 08:18:27.224 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 59.
2020.04.18 08:18:27.224 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 59.
2020.04.18 08:18:27.225 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 59.
2020.04.18 08:18:27.258 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.258 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.296 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 93.
2020.04.18 08:18:27.296 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 93.
2020.04.18 08:18:27.297 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 93.
2020.04.18 08:18:27.297 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 93.
2020.04.18 08:18:27.297 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 93.
2020.04.18 08:18:27.298 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 93.
2020.04.18 08:18:27.298 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 93.
2020.04.18 08:18:27.298 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 93.
2020.04.18 08:18:27.299 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 93.
2020.04.18 08:18:27.299 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 93.
2020.04.18 08:18:27.301 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 93.
2020.04.18 08:18:27.302 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 93.
2020.04.18 08:18:27.304 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 93.
2020.04.18 08:18:27.304 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 93.
2020.04.18 08:18:27.305 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 93.
2020.04.18 08:18:27.305 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 93.
2020.04.18 08:18:27.305 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 93.
2020.04.18 08:18:27.306 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 93.
2020.04.18 08:18:27.307 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 93.
2020.04.18 08:18:27.308 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 93.
2020.04.18 08:18:27.309 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 93.
2020.04.18 08:18:27.310 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 93.
2020.04.18 08:18:27.343 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.343 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.370 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 128.
2020.04.18 08:18:27.371 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 128.
2020.04.18 08:18:27.371 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 128.
2020.04.18 08:18:27.372 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 128.
2020.04.18 08:18:27.372 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 128.
2020.04.18 08:18:27.372 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 128.
2020.04.18 08:18:27.373 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 128.
2020.04.18 08:18:27.373 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 128.
2020.04.18 08:18:27.373 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 128.
2020.04.18 08:18:27.374 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 128.
2020.04.18 08:18:27.375 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 128.
2020.04.18 08:18:27.377 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 128.
2020.04.18 08:18:27.378 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 128.
2020.04.18 08:18:27.379 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 128.
2020.04.18 08:18:27.379 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 128.
2020.04.18 08:18:27.379 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 128.
2020.04.18 08:18:27.380 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 128.
2020.04.18 08:18:27.380 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 128.
2020.04.18 08:18:27.381 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 128.
2020.04.18 08:18:27.383 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 128.
2020.04.18 08:18:27.384 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 128.
2020.04.18 08:18:27.384 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 128.
2020.04.18 08:18:27.417 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.418 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.443 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 161.
2020.04.18 08:18:27.443 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 161.
2020.04.18 08:18:27.444 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 161.
2020.04.18 08:18:27.444 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 161.
2020.04.18 08:18:27.444 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 161.
2020.04.18 08:18:27.445 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 161.
2020.04.18 08:18:27.445 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 161.
2020.04.18 08:18:27.445 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 161.
2020.04.18 08:18:27.446 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 161.
2020.04.18 08:18:27.446 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 161.
2020.04.18 08:18:27.448 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 161.
2020.04.18 08:18:27.449 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 161.
2020.04.18 08:18:27.451 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 161.
2020.04.18 08:18:27.451 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 161.
2020.04.18 08:18:27.452 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 161.
2020.04.18 08:18:27.452 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 161.
2020.04.18 08:18:27.453 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 161.
2020.04.18 08:18:27.453 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 161.
2020.04.18 08:18:27.454 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 161.
2020.04.18 08:18:27.455 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 161.
2020.04.18 08:18:27.456 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 161.
2020.04.18 08:18:27.457 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 161.
2020.04.18 08:18:27.490 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.490 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.515 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 195.
2020.04.18 08:18:27.515 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 195.
2020.04.18 08:18:27.516 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 195.
2020.04.18 08:18:27.516 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 195.
2020.04.18 08:18:27.516 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 195.
2020.04.18 08:18:27.517 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 195.
2020.04.18 08:18:27.517 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 195.
2020.04.18 08:18:27.517 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 195.
2020.04.18 08:18:27.517 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 195.
2020.04.18 08:18:27.518 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 195.
2020.04.18 08:18:27.519 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 195.
2020.04.18 08:18:27.521 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 195.
2020.04.18 08:18:27.523 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 195.
2020.04.18 08:18:27.523 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 195.
2020.04.18 08:18:27.524 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 195.
2020.04.18 08:18:27.524 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 195.
2020.04.18 08:18:27.524 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 195.
2020.04.18 08:18:27.525 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 195.
2020.04.18 08:18:27.525 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 195.
2020.04.18 08:18:27.527 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 195.
2020.04.18 08:18:27.528 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 195.
2020.04.18 08:18:27.529 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 195.
2020.04.18 08:18:27.562 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.563 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.578 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 215.
2020.04.18 08:18:27.578 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 215.
2020.04.18 08:18:27.579 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 215.
2020.04.18 08:18:27.579 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 215.
2020.04.18 08:18:27.580 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 215.
2020.04.18 08:18:27.580 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 215.
2020.04.18 08:18:27.580 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 215.
2020.04.18 08:18:27.580 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 215.
2020.04.18 08:18:27.581 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 215.
2020.04.18 08:18:27.581 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 215.
2020.04.18 08:18:27.583 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 215.
2020.04.18 08:18:27.585 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 215.
2020.04.18 08:18:27.586 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 215.
2020.04.18 08:18:27.587 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 215.
2020.04.18 08:18:27.587 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 215.
2020.04.18 08:18:27.587 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 215.
2020.04.18 08:18:27.588 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 215.
2020.04.18 08:18:27.588 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 215.
2020.04.18 08:18:27.589 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 215.
2020.04.18 08:18:27.591 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 215.
2020.04.18 08:18:27.591 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 215.
2020.04.18 08:18:27.592 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 215.
2020.04.18 08:18:27.626 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.626 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.651 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 249.
2020.04.18 08:18:27.651 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 249.
2020.04.18 08:18:27.651 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 249.
2020.04.18 08:18:27.652 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 249.
2020.04.18 08:18:27.652 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 249.
2020.04.18 08:18:27.652 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 249.
2020.04.18 08:18:27.653 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 249.
2020.04.18 08:18:27.653 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 249.
2020.04.18 08:18:27.653 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 249.
2020.04.18 08:18:27.654 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 249.
2020.04.18 08:18:27.655 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 249.
2020.04.18 08:18:27.657 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 249.
2020.04.18 08:18:27.658 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 249.
2020.04.18 08:18:27.659 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 249.
2020.04.18 08:18:27.659 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 249.
2020.04.18 08:18:27.660 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 249.
2020.04.18 08:18:27.660 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 249.
2020.04.18 08:18:27.661 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 249.
2020.04.18 08:18:27.661 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 249.
2020.04.18 08:18:27.663 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 249.
2020.04.18 08:18:27.664 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 249.
2020.04.18 08:18:27.665 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 249.
2020.04.18 08:18:27.698 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.698 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.713 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 263.
2020.04.18 08:18:27.714 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 263.
2020.04.18 08:18:27.714 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 263.
2020.04.18 08:18:27.714 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 263.
2020.04.18 08:18:27.715 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 263.
2020.04.18 08:18:27.715 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 263.
2020.04.18 08:18:27.715 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 263.
2020.04.18 08:18:27.715 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 263.
2020.04.18 08:18:27.716 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 263.
2020.04.18 08:18:27.716 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 263.
2020.04.18 08:18:27.718 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 263.
2020.04.18 08:18:27.720 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 263.
2020.04.18 08:18:27.721 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 263.
2020.04.18 08:18:27.722 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 263.
2020.04.18 08:18:27.722 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 263.
2020.04.18 08:18:27.722 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 263.
2020.04.18 08:18:27.723 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 263.
2020.04.18 08:18:27.723 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 263.
2020.04.18 08:18:27.724 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 263.
2020.04.18 08:18:27.726 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 263.
2020.04.18 08:18:27.726 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 263.
2020.04.18 08:18:27.727 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 263.
2020.04.18 08:18:27.761 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.761 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.774 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 274.
2020.04.18 08:18:27.775 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 274.
2020.04.18 08:18:27.775 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 274.
2020.04.18 08:18:27.776 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 274.
2020.04.18 08:18:27.776 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 274.
2020.04.18 08:18:27.776 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 274.
2020.04.18 08:18:27.776 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 274.
2020.04.18 08:18:27.777 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 274.
2020.04.18 08:18:27.777 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 274.
2020.04.18 08:18:27.778 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 274.
2020.04.18 08:18:27.779 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 274.
2020.04.18 08:18:27.781 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 274.
2020.04.18 08:18:27.782 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 274.
2020.04.18 08:18:27.783 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 274.
2020.04.18 08:18:27.783 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 274.
2020.04.18 08:18:27.784 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 274.
2020.04.18 08:18:27.784 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 274.
2020.04.18 08:18:27.784 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 274.
2020.04.18 08:18:27.785 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 274.
2020.04.18 08:18:27.787 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 274.
2020.04.18 08:18:27.788 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 274.
2020.04.18 08:18:27.789 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 274.
2020.04.18 08:18:27.822 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.822 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.842 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 298.
2020.04.18 08:18:27.842 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 298.
2020.04.18 08:18:27.843 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 298.
2020.04.18 08:18:27.843 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 298.
2020.04.18 08:18:27.844 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 298.
2020.04.18 08:18:27.844 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 298.
2020.04.18 08:18:27.844 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 298.
2020.04.18 08:18:27.845 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 298.
2020.04.18 08:18:27.845 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 298.
2020.04.18 08:18:27.845 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 298.
2020.04.18 08:18:27.847 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 298.
2020.04.18 08:18:27.849 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 298.
2020.04.18 08:18:27.850 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 298.
2020.04.18 08:18:27.851 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 298.
2020.04.18 08:18:27.851 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 298.
2020.04.18 08:18:27.852 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 298.
2020.04.18 08:18:27.852 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 298.
2020.04.18 08:18:27.852 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 298.
2020.04.18 08:18:27.853 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 298.
2020.04.18 08:18:27.855 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 298.
2020.04.18 08:18:27.856 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 298.
2020.04.18 08:18:27.856 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 298.
2020.04.18 08:18:27.890 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.890 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.911 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 320.
2020.04.18 08:18:27.912 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 320.
2020.04.18 08:18:27.912 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 320.
2020.04.18 08:18:27.912 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 320.
2020.04.18 08:18:27.913 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 320.
2020.04.18 08:18:27.913 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 320.
2020.04.18 08:18:27.913 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 320.
2020.04.18 08:18:27.913 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 320.
2020.04.18 08:18:27.914 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 320.
2020.04.18 08:18:27.914 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 320.
2020.04.18 08:18:27.916 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 320.
2020.04.18 08:18:27.918 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 320.
2020.04.18 08:18:27.919 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 320.
2020.04.18 08:18:27.920 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 320.
2020.04.18 08:18:27.920 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 320.
2020.04.18 08:18:27.920 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 320.
2020.04.18 08:18:27.921 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 320.
2020.04.18 08:18:27.921 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 320.
2020.04.18 08:18:27.922 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 320.
2020.04.18 08:18:27.924 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 320.
2020.04.18 08:18:27.924 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 320.
2020.04.18 08:18:27.925 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 320.
2020.04.18 08:18:27.959 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.959 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:27.978 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 356.
2020.04.18 08:18:27.978 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 356.
2020.04.18 08:18:27.978 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 356.
2020.04.18 08:18:27.979 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 356.
2020.04.18 08:18:27.979 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 356.
2020.04.18 08:18:27.979 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 356.
2020.04.18 08:18:27.980 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 356.
2020.04.18 08:18:27.980 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 356.
2020.04.18 08:18:27.980 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 356.
2020.04.18 08:18:27.981 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 356.
2020.04.18 08:18:27.982 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 356.
2020.04.18 08:18:27.984 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 356.
2020.04.18 08:18:27.986 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 356.
2020.04.18 08:18:27.986 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 356.
2020.04.18 08:18:27.987 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 356.
2020.04.18 08:18:27.987 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 356.
2020.04.18 08:18:27.987 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 356.
2020.04.18 08:18:27.988 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 356.
2020.04.18 08:18:27.988 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 356.
2020.04.18 08:18:27.990 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 356.
2020.04.18 08:18:27.991 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 356.
2020.04.18 08:18:27.992 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 356.
2020.04.18 08:18:28.025 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.025 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.049 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 388.
2020.04.18 08:18:28.050 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 388.
2020.04.18 08:18:28.050 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 388.
2020.04.18 08:18:28.050 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 388.
2020.04.18 08:18:28.051 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 388.
2020.04.18 08:18:28.051 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 388.
2020.04.18 08:18:28.051 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 388.
2020.04.18 08:18:28.052 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 388.
2020.04.18 08:18:28.052 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 388.
2020.04.18 08:18:28.052 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 388.
2020.04.18 08:18:28.054 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 388.
2020.04.18 08:18:28.056 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 388.
2020.04.18 08:18:28.057 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 388.
2020.04.18 08:18:28.058 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 388.
2020.04.18 08:18:28.058 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 388.
2020.04.18 08:18:28.058 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 388.
2020.04.18 08:18:28.059 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 388.
2020.04.18 08:18:28.059 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 388.
2020.04.18 08:18:28.060 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 388.
2020.04.18 08:18:28.062 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 388.
2020.04.18 08:18:28.063 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 388.
2020.04.18 08:18:28.063 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 388.
2020.04.18 08:18:28.097 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.098 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.128 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 425.
2020.04.18 08:18:28.129 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 425.
2020.04.18 08:18:28.129 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 425.
2020.04.18 08:18:28.129 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 425.
2020.04.18 08:18:28.130 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 425.
2020.04.18 08:18:28.130 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 425.
2020.04.18 08:18:28.130 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 425.
2020.04.18 08:18:28.131 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 425.
2020.04.18 08:18:28.131 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 425.
2020.04.18 08:18:28.132 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 425.
2020.04.18 08:18:28.133 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 425.
2020.04.18 08:18:28.135 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 425.
2020.04.18 08:18:28.136 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 425.
2020.04.18 08:18:28.137 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 425.
2020.04.18 08:18:28.137 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 425.
2020.04.18 08:18:28.138 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 425.
2020.04.18 08:18:28.138 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 425.
2020.04.18 08:18:28.138 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 425.
2020.04.18 08:18:28.139 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 425.
2020.04.18 08:18:28.141 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 425.
2020.04.18 08:18:28.142 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 425.
2020.04.18 08:18:28.143 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 425.
2020.04.18 08:18:28.176 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.176 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.193 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 445.
2020.04.18 08:18:28.194 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 445.
2020.04.18 08:18:28.194 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 445.
2020.04.18 08:18:28.194 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 445.
2020.04.18 08:18:28.195 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 445.
2020.04.18 08:18:28.195 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 445.
2020.04.18 08:18:28.195 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 445.
2020.04.18 08:18:28.196 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 445.
2020.04.18 08:18:28.196 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 445.
2020.04.18 08:18:28.196 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 445.
2020.04.18 08:18:28.198 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 445.
2020.04.18 08:18:28.200 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 445.
2020.04.18 08:18:28.201 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 445.
2020.04.18 08:18:28.202 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 445.
2020.04.18 08:18:28.202 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 445.
2020.04.18 08:18:28.202 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 445.
2020.04.18 08:18:28.203 1: PERL WARNING: Subroutine MAX_SerializeTemperature redefined at ./FHEM/10_MAX.pm line 378, <$fh> line 445.
2020.04.18 08:18:28.203 1: PERL WARNING: Subroutine MAX_Validate redefined at ./FHEM/10_MAX.pm line 387, <$fh> line 445.
2020.04.18 08:18:28.204 1: PERL WARNING: Subroutine MAX_ReadingsVal redefined at ./FHEM/10_MAX.pm line 398, <$fh> line 445.
2020.04.18 08:18:28.206 1: PERL WARNING: Subroutine MAX_ParseWeekProfile redefined at ./FHEM/10_MAX.pm line 445, <$fh> line 445.
2020.04.18 08:18:28.207 1: PERL WARNING: Subroutine MAX_WakeUp redefined at ./FHEM/10_MAX.pm line 545, <$fh> line 445.
2020.04.18 08:18:28.207 1: PERL WARNING: Subroutine MAX_Get redefined at ./FHEM/10_MAX.pm line 552, <$fh> line 445.
2020.04.18 08:18:28.241 1: reload: Error:Modul 10_MAX deactivated:
Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.241 0: Too many arguments for main::MAX_Restore at ./FHEM/10_MAX.pm line 617, near "$f)"
2020.04.18 08:18:28.258 1: PERL WARNING: Subroutine MAX_validTemperature redefined at ./FHEM/10_MAX.pm line 127, <$fh> line 465.
2020.04.18 08:18:28.259 1: PERL WARNING: Subroutine MAX_ParseTemperature redefined at ./FHEM/10_MAX.pm line 130, <$fh> line 465.
2020.04.18 08:18:28.259 1: PERL WARNING: Subroutine MAX_validWindowOpenDuration redefined at ./FHEM/10_MAX.pm line 131, <$fh> line 465.
2020.04.18 08:18:28.259 1: PERL WARNING: Subroutine MAX_validMeasurementOffset redefined at ./FHEM/10_MAX.pm line 132, <$fh> line 465.
2020.04.18 08:18:28.260 1: PERL WARNING: Subroutine MAX_validBoostDuration redefined at ./FHEM/10_MAX.pm line 133, <$fh> line 465.
2020.04.18 08:18:28.260 1: PERL WARNING: Subroutine MAX_validValveposition redefined at ./FHEM/10_MAX.pm line 134, <$fh> line 465.
2020.04.18 08:18:28.260 1: PERL WARNING: Subroutine MAX_validWeekProfile redefined at ./FHEM/10_MAX.pm line 135, <$fh> line 465.
2020.04.18 08:18:28.261 1: PERL WARNING: Subroutine MAX_validGroupid redefined at ./FHEM/10_MAX.pm line 136, <$fh> line 465.
2020.04.18 08:18:28.261 1: PERL WARNING: Subroutine MAX_validDecalcification redefined at ./FHEM/10_MAX.pm line 139, <$fh> line 465.
2020.04.18 08:18:28.261 1: PERL WARNING: Subroutine MAX_Initialize redefined at ./FHEM/10_MAX.pm line 145, <$fh> line 465.
2020.04.18 08:18:28.263 1: PERL WARNING: Subroutine MAX_Define redefined at ./FHEM/10_MAX.pm line 167, <$fh> line 465.
2020.04.18 08:18:28.265 1: PERL WARNING: Subroutine MAX_Timer redefined at ./FHEM/10_MAX.pm line 227, <$fh> line 465.
2020.04.18 08:18:28.266 1: PERL WARNING: Subroutine MAX_Attr redefined at ./FHEM/10_MAX.pm line 288, <$fh> line 465.
2020.04.18 08:18:28.267 1: PERL WARNING: Subroutine MAX_Undef redefined at ./FHEM/10_MAX.pm line 343, <$fh> line 465.
2020.04.18 08:18:28.267 1: PERL WARNING: Subroutine MAX_TypeToTypeId redefined at ./FHEM/10_MAX.pm line 350, <$fh> line 465.
2020.04.18 08:18:28.267 1: PERL WARNING: Subroutine MAX_CheckIODev redefined at ./FHEM/10_MAX.pm line 361, <$fh> line 465.
2020.04.18 08:18:28.268 1: PERL WARNING: Subroutine MAX_S
Hast du vllt in deiner 99_myUtils eine Funktion MAX_Backup bzw. MAX_Restore ?
Wenn ja musst du diese löschen, da mit der Beta alle Backup & Restore Funktionen vom MAX Modul übernommen werden.
Hi,
ja habe ich, und auch noch andere "Helfer" in der myUtil.
Was muss alles raus?
nur Backup&Restore?
nutze z.B. auch die
99_UtilsMaxProf.pm
hour Counter
Maxcreate Alias
get_valve_data( ) }
get daily profiles
Hi Wzut,
auch ich bin gerade durch Zufall über Umwege auf diesen Thread gestoßen und happy, dass die Modulentwicklung für die MAX! Geräte weitergeht. Vielen Dank dafür!
Aktuell plagte mich die Sonos Anbindung mit ständigen disconnects und ich habe deshalb mein System (Raspberry Pi 3) mal voll umfänglich mit perfmon gecheckt.
Dabei ist mir als allererstes natürlich mein MAX! System aufgefallen, welches sogar noch schlimmer als das Sonos Modul funkt.
Alle 3 Minuten (da ich das DEF natürlich auf IP 180 ondemand gesetzt habe) nimmt es das System ordentlich in Anspruch.
Das sieht im Logfile dann entsprechend so aus:
2020.04.18 13:04:27 1: Perfmon: possible freeze starting at 13:04:26, delay is 1.458
2020.04.18 13:01:25 1: Perfmon: possible freeze starting at 13:01:23, delay is 2.172
2020.04.18 12:58:22 1: Perfmon: possible freeze starting at 12:58:21, delay is 1.768
2020.04.18 12:55:20 1: Perfmon: possible freeze starting at 12:55:19, delay is 1.606
2020.04.18 12:52:18 1: Perfmon: possible freeze starting at 12:52:17, delay is 1.279
2020.04.18 12:49:16 1: Perfmon: possible freeze starting at 12:49:14, delay is 2.083
2020.04.18 12:46:13 1: Perfmon: possible freeze starting at 12:46:12, delay is 1.81
2020.04.18 12:43:11 1: Perfmon: possible freeze starting at 12:43:10, delay is 1.501
2020.04.18 12:40:09 1: Perfmon: possible freeze starting at 12:40:07, delay is 2.046
2020.04.18 12:37:06 1: Perfmon: possible freeze starting at 12:37:04, delay is 2.155
2020.04.18 12:34:03 1: Perfmon: possible freeze starting at 12:34:01, delay is 2.515
2020.04.18 12:31:00 1: Perfmon: possible freeze starting at 12:30:59, delay is 1.718
2020.04.18 12:27:58 1: Perfmon: possible freeze starting at 12:27:57, delay is 1.347
2020.04.18 12:24:56 1: Perfmon: possible freeze starting at 12:24:54, delay is 2.103
2020.04.18 12:21:53 1: Perfmon: possible freeze starting at 12:21:52, delay is 1.906
2020.04.18 12:18:51 1: Perfmon: possible freeze starting at 12:18:50, delay is 1.618
2020.04.18 12:15:49 1: Perfmon: possible freeze starting at 12:15:48, delay is 1.319
2020.04.18 12:12:47 1: Perfmon: possible freeze starting at 12:12:45, delay is 2.059
2020.04.18 12:09:44 1: Perfmon: possible freeze starting at 12:09:42, delay is 2.417
2020.04.18 12:06:42 1: Perfmon: possible freeze starting at 12:06:40, delay is 2.005
2020.04.18 12:03:39 1: Perfmon: possible freeze starting at 12:03:36, delay is 3.174
2020.04.18 12:00:35 1: Perfmon: possible freeze starting at 12:00:34, delay is 1.957
2020.04.18 11:57:33 1: Perfmon: possible freeze starting at 11:57:32, delay is 1.577
2020.04.18 11:54:31 1: Perfmon: possible freeze starting at 11:54:30, delay is 1.45
2020.04.18 11:51:29 1: Perfmon: possible freeze starting at 11:51:27, delay is 2.085
2020.04.18 11:48:26 1: Perfmon: possible freeze starting at 11:48:25, delay is 1.898
2020.04.18 11:45:24 1: Perfmon: possible freeze starting at 11:45:23, delay is 1.564
2020.04.18 11:42:22 1: Perfmon: possible freeze starting at 11:42:21, delay is 1.35
2020.04.18 11:39:20 1: Perfmon: possible freeze starting at 11:39:18, delay is 2.076
2020.04.18 11:36:17 1: Perfmon: possible freeze starting at 11:36:16, delay is 1.724
2020.04.18 11:33:15 1: Perfmon: possible freeze starting at 11:33:14, delay is 1.463
2020.04.18 11:30:13 1: Perfmon: possible freeze starting at 11:30:11, delay is 2.191
2020.04.18 11:27:10 1: Perfmon: possible freeze starting at 11:27:09, delay is 1.992
2020.04.18 11:26:09 1: Perfmon: possible freeze starting at 11:26:02, delay is 7.802
2020.04.18 11:24:08 1: Perfmon: possible freeze starting at 11:24:07, delay is 1.755
2020.04.18 11:21:06 1: Perfmon: possible freeze starting at 11:21:05, delay is 1.589
2020.04.18 11:18:04 1: Perfmon: possible freeze starting at 11:18:03, delay is 1.365
2020.04.18 11:15:02 1: Perfmon: possible freeze starting at 11:15:00, delay is 2.175
2020.04.18 11:11:59 1: Perfmon: possible freeze starting at 11:11:58, delay is 1.994
2020.04.18 11:08:57 1: Perfmon: possible freeze starting at 11:08:56, delay is 1.776
2020.04.18 11:05:55 1: Perfmon: possible freeze starting at 11:05:54, delay is 1.639
2020.04.18 11:02:53 1: Perfmon: possible freeze starting at 11:02:52, delay is 1.486
2020.04.18 10:59:51 1: Perfmon: possible freeze starting at 10:59:50, delay is 1.29
2020.04.18 10:56:49 1: Perfmon: possible freeze starting at 10:56:47, delay is 2.088
2020.04.18 10:53:46 1: Perfmon: possible freeze starting at 10:53:45, delay is 1.82
2020.04.18 10:50:44 1: Perfmon: possible freeze starting at 10:50:43, delay is 1.593
2020.04.18 10:47:42 1: Perfmon: possible freeze starting at 10:47:41, delay is 1.301
2020.04.18 10:44:40 1: Perfmon: possible freeze starting at 10:44:38, delay is 2.163
2020.04.18 10:41:37 1: Perfmon: possible freeze starting at 10:41:36, delay is 1.904
2020.04.18 10:38:35 1: Perfmon: possible freeze starting at 10:38:34, delay is 1.593
2020.04.18 10:35:33 1: Perfmon: possible freeze starting at 10:35:32, delay is 1.445
2020.04.18 10:32:31 1: Perfmon: possible freeze starting at 10:32:30, delay is 1.314
2020.04.18 10:29:29 1: Perfmon: possible freeze starting at 10:29:27, delay is 2.105
2020.04.18 10:26:26 1: Perfmon: possible freeze starting at 10:26:25, delay is 1.93
2020.04.18 10:23:24 1: Perfmon: possible freeze starting at 10:23:23, delay is 1.829
2020.04.18 10:20:22 1: Perfmon: possible freeze starting at 10:20:21, delay is 1.653
2020.04.18 10:19:57 1: Perfmon: possible freeze starting at 10:19:56, delay is 1.089
2020.04.18 10:17:20 1: Perfmon: possible freeze starting at 10:17:19, delay is 1.493
2020.04.18 10:14:18 1: Perfmon: possible freeze starting at 10:14:17, delay is 1.376
2020.04.18 10:11:16 1: Perfmon: possible freeze starting at 10:11:14, delay is 2.222
2020.04.18 10:08:13 1: Perfmon: possible freeze starting at 10:08:12, delay is 1.855
2020.04.18 10:05:11 1: Perfmon: possible freeze starting at 10:05:10, delay is 1.72
2020.04.18 10:02:09 1: Perfmon: possible freeze starting at 10:02:08, delay is 1.477
2020.04.18 09:59:07 1: Perfmon: possible freeze starting at 09:59:06, delay is 1.259
2020.04.18 09:56:05 1: Perfmon: possible freeze starting at 09:56:03, delay is 2.018
2020.04.18 09:53:02 1: Perfmon: possible freeze starting at 09:53:01, delay is 1.883
2020.04.18 09:50:00 1: Perfmon: possible freeze starting at 09:49:59, delay is 1.725
2020.04.18 09:46:58 1: Perfmon: possible freeze starting at 09:46:57, delay is 1.518
2020.04.18 09:43:56 1: Perfmon: possible freeze starting at 09:43:55, delay is 1.476
2020.04.18 09:40:54 1: Perfmon: possible freeze starting at 09:40:53, delay is 1.351
2020.04.18 09:37:52 1: Perfmon: possible freeze starting at 09:37:50, delay is 2.147
2020.04.18 09:34:50 1: Perfmon: possible freeze starting at 09:34:48, delay is 2.001
2020.04.18 09:31:47 1: Perfmon: possible freeze starting at 09:31:46, delay is 1.868
2020.04.18 09:28:45 1: Perfmon: possible freeze starting at 09:28:44, delay is 1.69
2020.04.18 09:25:43 1: Perfmon: possible freeze starting at 09:25:42, delay is 1.638
2020.04.18 09:22:41 1: Perfmon: possible freeze starting at 09:22:40, delay is 1.453
2020.04.18 09:19:39 1: Perfmon: possible freeze starting at 09:19:37, delay is 2.029
2020.04.18 09:16:36 1: Perfmon: possible freeze starting at 09:16:35, delay is 1.927
2020.04.18 09:13:34 1: Perfmon: possible freeze starting at 09:13:33, delay is 1.846
2020.04.18 09:10:32 1: Perfmon: possible freeze starting at 09:10:31, delay is 1.719
2020.04.18 09:07:30 1: Perfmon: possible freeze starting at 09:07:29, delay is 1.603
2020.04.18 09:04:28 1: Perfmon: possible freeze starting at 09:04:26, delay is 2.294
2020.04.18 09:01:26 1: Perfmon: possible freeze starting at 09:01:24, delay is 2.004
2020.04.18 08:58:23 1: Perfmon: possible freeze starting at 08:58:22, delay is 1.753
2020.04.18 08:55:21 1: Perfmon: possible freeze starting at 08:55:20, delay is 1.591
2020.04.18 08:52:19 1: Perfmon: possible freeze starting at 08:52:18, delay is 1.43
2020.04.18 08:49:17 1: Perfmon: possible freeze starting at 08:49:16, delay is 1.294
2020.04.18 08:46:15 1: Perfmon: possible freeze starting at 08:46:14, delay is 1.127
2020.04.18 08:43:13 1: Perfmon: possible freeze starting at 08:43:11, delay is 2.069
2020.04.18 08:40:10 1: Perfmon: possible freeze starting at 08:40:09, delay is 1.921
2020.04.18 08:37:08 1: Perfmon: possible freeze starting at 08:37:07, delay is 1.713
2020.04.18 08:34:06 1: Perfmon: possible freeze starting at 08:34:05, delay is 1.564
2020.04.18 08:31:04 1: Perfmon: possible freeze starting at 08:31:03, delay is 1.472
2020.04.18 08:28:02 1: Perfmon: possible freeze starting at 08:28:01, delay is 1.388
2020.04.18 08:25:00 1: Perfmon: possible freeze starting at 08:24:58, delay is 2.101
2020.04.18 08:21:57 1: Perfmon: possible freeze starting at 08:21:56, delay is 1.947
Wird es auch in dieser Richtung eine Verbesserung geben? Siehst du hier potential oder gibt es vielleicht jetzt schon hilfreiche Attribute oder Settings, um die Last zu reduzieren? Ich verwende aktuell noch keine Plots, sondern lediglich 6 HT, 6 FK und 5 WT's über den MAX! Cube. Das device sieht wie folgt aus:
Internals:
DEF 192.168.XXX.XXX 180 ondemand
DeviceName 192.168.XXX.XXX:62910
FUUID XXXXXX-XXXX-XXXX-XXXX-XXXXXXX
INTERVAL 180
NAME MAXCube
NR 669
STATE opened
TYPE MAXLAN
addr XXXXXX
clockset 3
cubeTimeDifference 0
dutycycle 4 %
freememoryslot 49
fwversion 0113
pairmode 0
persistent 0
serial XXXXXXXXX
READINGS:
2020-04-18 13:28:44 dutycycle 4
2020-04-18 13:28:44 firmware 0.1
2020-04-18 13:28:43 state opened
2020-04-18 13:28:44 testresult 0
devices:
HASH(0x9323d40)
HASH(0x6b4f9c0)
HASH(0x50fdf60)
HASH(0x680a4a8)
HASH(0x52458e0)
HASH(0x6580e30)
HASH(0xa0f21b8)
HASH(0x484b048)
HASH(0x589bfe0)
HASH(0x6184ba0)
HASH(0x4a91578)
HASH(0x66bc620)
HASH(0x51dcdd0)
HASH(0x50af6e0)
HASH(0x667dab8)
HASH(0x7e65be8)
HASH(0xa615670)
HASH(0x776b518)
HASH(0x6a332d8)
groups:
HASH(0x1a44ff0)
HASH(0x43fa270)
HASH(0x43fcfa8)
HASH(0x43fa228)
HASH(0x43ee518)
Attributes:
group Systeme
icon text_max
room MAX,Wohnzimmer
Eigentlich wollte ich mich mal um das Plotten kümmern aber da habe ich aktuell bzgl. Performance zu viel Sorgen, dass es mein System noch weiter in die Knie zieht.
Gruß
sTaN
@hyper2910, es darf keine sub MAX_Backup und keine sub MAX_Restore ausserhalb von 10_MAX.pm geben. Wenn du dir da welche in die 99_myUtils.pm oder sonstwo hingebastelt hast ( was auch immer 99_UtilsMaxProf.pm ist) : entweder die subs ganz löschen oder umbennen in Moritz_Backup , usw.
@sTaN, du benutzt MAXLAN ! Für MAXLAN werde ich nichts Neues machen. Diese ständigen Komplettabfragen des Cubes bringt IMHO mit der fehlerhaften Alzheimer ELV Firmware nichts.
Zitat von: Wzut am 18 April 2020, 13:45:46
@sTaN, du benutzt MAXLAN ! Für MAXLAN werde ich nichts Neues machen. Diese ständigen Komplettabfragen des Cubes bringt IMHO mit der fehlerhaften Alzheimer ELV Firmware nichts.
Dann ist das doch schon mal ein Ansatz und sicher auch die Erklärung warum bei mir so viel los ist?! Offen gesprochen habe ich das Thema die letzten Jahre etwas vernachlässigt und relativ stümperhaft über den Cube eingebunden.
Wo kann ich hier am besten wieder anfangen zu recherchieren und neu zu starten, die Komponenten über zeitgemäße Sender/Empfänger an meinen RPi anzuschließen?
Ist hier zwangsläufig dann ein zweiter CUL oder CUNO zu empfehlen oder ist es empfehlenswert den Max Cube umzuflashen? Mein bestehender ist ca. 8-10 Jahre alt und hat die Firmware V 1.53 CUL868.
Im Wiki steht zwar:
ZitatNachteil vom Cube ist, dass man ein Polling machen muss, um zu sehen ob sich der Status eines Gerätes geändert hat. Z.B. checkt man das alle 30 Sekunden. Dann sieht man aber auch Änderungen möglicherweise erst nach 30 Sekunden. Beim CUL sieht man die Funknachrichten direkt.
Aber die unterschiedlichen Möglichkeiten im Detail mit Vor- und Nachteile und Hardware Empfehlung fehlt mir aktuell. Was wäre jetzt eigentlich das non plus ultra, wenn ich einen RPi 3 mit bestehendem CUL (weiß gar nicht mehr ob V1, V2 oder schon V3) von Busware und Max Cube im Einsatz habe? Neuen CUL als Haupt Sender/Empfenger und alten für die MAX! Kommunikation?
Danke schon mal und sorry wenn es vielleicht zu grundlegende Fragen sind!
Viele Grüße
sTaN
Für nur MAX reicht ein nanoCUL. Ich würde dir aber gleich einen mapleCUN empfehlen, entweder selbst löten oder im Marktplatz gucken.
@sTaN, für MAX kannst du sogar einen uralt CUL benutzen, der FW Teil für MAX wurde schon Jahre nicht mehr geändert. ( meiner hat noch die FW 1.6 )
Natürlich kann man auch einen der vielen NanoCULs nehmen (Marktplatz / Ebay) wenn man denn mit dem USB vom Standort hinkommt.
Ein Maple oder CUBE umflashen geht natürlich auch : Vorteil entweder LAN oder USB Kommt halt drauf an wie groß das Umfeld ist das du abdecken musst , Haus mit drei Etagen vs. Einzimmer Wohnung. Bei mir läuft ein USB CUL und ein umgeflashter CUBE mit LAN im Tandem, das reicht für vier Etagen (Keller, EG, 1.Stock & Dach) wobei ich im EG eine sauschlechte Ecke habe, da wird wohl demnächst noch ein CUBE oder Maple in den Keller kommen zur Unterstützung.
Ich nutze seit dem Wochenende die neuen Module.
Bei mir läuft immer ein Freezemon mit, seit dem nutzen der neuen Module, habe ich immer ein paar Einträge wegen Max
1 - 2020-04-22: s:08:10:38 e:08:10:42 f:4.452 d:tmr-echodevice_GetSettings(Echos) tmr-echodevice_LoginStart(Echos) tmr-MAX_Timer(Garage) tmr-CUL_HM_procQs(N/A) tmr-MAX_Timer(Schlafzimmer) tmr-echodevice_GetSettings(ECHO_7094180751260KV3) tmr-ec...
1 - 2020-04-22: s:08:14:43 e:08:14:47 f:4.565 d:tmr-CUL_HM_procQs(N/A) tmr-echodevice_GetSettings(Echos) tmr-echodevice_LoginStart(Echos) tmr-MAX_Timer(Garage) tmr-MAX_Timer(Schlafzimmer) tmr-echodevice_GetSettings(ECHO_7094180751260KV3) tmr-ec...
Die Echo Einträge habe ich schon im Echo forum angefragt
bitte mal ein List von so einem MAX Device das im Freezmon auftaucht
Zitat von: Wzut am 22 April 2020, 08:42:27
bitte mal ein List von so einem MAX Device das im Freezmon auftaucht
Hier mal vom Schlafzimmer
Internals:
CFGFN /opt/fhem/FHEM/CULMAX.cfg
DEF HeatingThermostat 072072
FUUID 5c44db7c-f33f-3ae4-a398-d18b045e1749df92
IODev CULMAX0
NAME Schlafzimmer
NR 365
NTFY_ORDER 50-Schlafzimmer
STATE manual
ok
0
Activity
TYPE MAX
TimeSlot 0
addr 072072
devtype 1
type HeatingThermostat
READINGS:
2020-04-22 01:37:13 RSSI -54.5
2020-04-18 08:23:24 TimeInformationHour 1
2020-04-22 01:37:13 battery ok
2020-04-22 01:37:13 batteryState ok
2020-04-18 16:02:47 boostDuration 5
2020-04-18 16:02:47 boostValveposition 80
2020-04-18 16:02:47 comfortTemperature 21
2020-04-18 16:02:47 decalcification Sat 12:00
2020-04-22 01:37:13 desiredTemperature 12.0
2020-04-21 12:00:55 deviation 6.0
2020-04-18 16:02:47 ecoTemperature 17
2020-04-18 16:02:47 error invalid or missing value for READING windowOpenDuration
2020-04-22 01:37:13 gateway 1
2020-04-18 08:23:26 groupid 0
2020-04-18 17:10:26 lastConfigSave ./log/Schlafzimmer.max
2020-04-22 01:37:12 lastTimeSync 2020-04-22 01:37:12
2020-04-18 17:10:26 lastcmd ConfigWeekProfile
2020-04-18 16:02:47 maxValveSetting 100
2020-04-18 16:02:47 maximumTemperature on
2020-04-18 16:02:47 measurementOffset 0
2020-04-18 16:02:47 minimumTemperature off
2020-04-22 01:37:13 mode manual
2020-04-22 01:37:11 msgcnt 18
2020-04-22 01:37:13 panel unlocked
2020-04-21 12:00:55 peerIDs 000000
2020-04-21 12:00:55 peerList Broadcast
2020-04-22 01:37:13 rferror 0
2020-04-22 01:37:13 state 12.0°C
2020-04-21 12:00:55 temperature 18.0
2020-04-18 16:02:47 valveOffset 0
2020-04-22 01:37:13 valveposition 0
2020-04-18 17:10:26 weekprofile-0-Sat-temp 18.5 °C / 17.0 °C / 17.0 °C / 17.0 °C
2020-04-18 17:10:26 weekprofile-0-Sat-time 00:00-07:00 / 07:00-09:00 / 09:00-22:00 / 22:00-24:00
2020-04-18 17:10:26 weekprofile-1-Sun-temp 17.0 °C / 18.0 °C / 17.0 °C / 17.0 °C
2020-04-18 17:10:26 weekprofile-1-Sun-time 00:00-08:00 / 08:00-09:00 / 09:00-22:00 / 22:00-24:00
2020-04-18 17:10:26 weekprofile-2-Mon-temp 18.0 °C / 17.5 °C / 19.0 °C / 21.0 °C / 22.5 °C / 19.5 °C
2020-04-18 17:10:26 weekprofile-2-Mon-time 00:00-06:00 / 06:00-09:00 / 09:00-14:00 / 14:00-17:00 / 17:00-22:00 / 22:00-24:00
2020-04-18 17:10:26 weekprofile-3-Tue-temp 18.0 °C / 17.5 °C / 19.5 °C / 20.5 °C / 23.0 °C / 18.0 °C
2020-04-18 17:10:26 weekprofile-3-Tue-time 00:00-06:00 / 06:00-09:00 / 09:00-14:00 / 14:00-17:00 / 17:00-22:00 / 22:00-24:00
2020-04-18 17:10:26 weekprofile-4-Wed-temp 18.0 °C / 17.0 °C / 17.0 °C / 17.0 °C / 17.5 °C / 19.0 °C
2020-04-18 17:10:26 weekprofile-4-Wed-time 00:00-06:00 / 06:00-09:00 / 09:00-14:00 / 14:00-17:00 / 17:00-22:00 / 22:00-24:00
2020-04-18 17:10:26 weekprofile-5-Thu-temp 18.0 °C / 17.0 °C / 19.0 °C / 18.0 °C / 17.0 °C / 19.0 °C
2020-04-18 17:10:26 weekprofile-5-Thu-time 00:00-06:00 / 06:00-09:00 / 09:00-14:00 / 14:00-17:00 / 17:00-22:00 / 22:00-24:00
2020-04-18 17:10:26 weekprofile-6-Fri-temp 18.0 °C / 17.5 °C / 17.0 °C / 17.0 °C
2020-04-18 17:10:26 weekprofile-6-Fri-time 00:00-06:00 / 06:00-09:00 / 09:00-22:00 / 22:00-24:00
2020-04-18 16:02:47 windowOpenDuration 15
2020-04-18 16:02:47 windowOpenTemperature 12
Attributes:
IODev CULMAX0
autosaveConfig 1
comment Configured using template MAX_HeatingThermostat_1
devStateIcon auto:sani_heating_automatic@lightgray manual:sani_heating_manual@yellow ok:measure_battery_100@green low:measure_battery_0@red (0|alive):10px-kreis-gruen (1|dead):10px-kreis-rot timeout:10px-kreis-gelb
event-on-change-reading .*
group Heizung
icon hc_wht_regler
model HeatingThermostat
room 3.00 Schlafzimmer->3.10 Schlafzimmer,GoogleAssistant
stateFormat mode
battery
rferror
Activity
webCmd temperature:desiredTemperature:valveposition
webCmdLabel Ist
:Soll
:Ventil
widgetOverride valveposition:slider,0,1,100 temperature:selectnumbers,15,0.1,29,1,lin
hmm echt komsich, ich hatte erwartet das du da das Attribut windowOpenCheck gesetzt hast, da aber nicht gesetzt fällt der Zweig schon mal raus.
dTempCheck ist auch nicht gesetzt damit ist der zweite Block auch raus.
Ich muß mal schauen und die Prüfungen vorziehen, dann wird für solche Geräte der Timer erst gar nicht mehr aufgerufen.
Was mir aber auffällt ( hat nichts mit deinem aktuellen Problem zu tun ) :
Du hast das max Template gezogen aber das Attribut actCyle nicht gesetzt, damit fehlt dir das Reading Activity und du hast dadurch den Text Activity statisch im state :)
Tipp : entweder actCyle noch setzen (1:0) oder das Wort Activity aus dem stateFormat werfen
Hallo Wzut,
ich versuche gerade die beiden Beta-Dateien zu installieren, scheitere aber an der Übertragung / Rechten.
Ich habe versucht die beiden Dateien in das Verzeichnis /opt/fhem/FHEM zu schreiben, scheine aber kein Zugriffsrecht zu haben.
Für die Übertragung wollte ich meinen User pi nehmen, den ich auch für Putty nutze.... Allerdings erhalte ich ein "Permission denied"
Was muss ich machen?
Sudo davor, wenn du sie per console kopierst.
Rechte von pi reichen nicht aus zum schreiben in /FHEM
Eine weitere Möglichkeit gebe es mit "Filezilla". In Filezilla mit User=fhem auf dem Raspi anmelden. Dann kann man mit "drag and drop" die Dateien direkt in das entsprechende Verzeichnis kopieren. Die Rechte stimmen dann auch schon.
Ich habe es bisher mit WinSCP und Filezilla probiert, Anmeldung mit Pi und meinem Kennwort klappt, nur reichen die Rechte nicht.
Den User fhem habe ich meines Wissens nach nie selbst angelegt und auch nie ein Kennwort geändert.
Gibt es ein Standard-Kennwort? Leer-Lassen klappt nicht...
Vergiss den ganzen Zilla und FTP Kram , ich habe unter contrib/Wzut ein Beta Verzeichniss erstellt. In der FHEM Eingabezeile nach einander eingeben :
"wget -qO ./FHEM/10_MAX.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/Wzut/10_MAX.pm"
"wget -qO ./FHEM/14_CUL_MAX.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/Wzut/14_CUL_MAX.pm"
statt abtippen geht natürlich auch copy & paste , aber ACHTUNG : die Anführungzeichen müssen mit !
Es gibt noch mehr als MAX Module! Wenn man häufiger ohne den "Aufwand" über die Konsole etwas testen oder ändern möchte (icons, Dateien, cfg, Module etc.), ist Filezilla ein tolles Hilfsmittel (ggf. mit Hilfe von Notepad++"), welches man nicht mehr missen möchte. Kurz mal "google" bemühen und einmal "fhem" user anlegen... Dann lassen sich auch einfach Dateirechte /Attribute anpassen. Ich bin damit bisher gute Erfahrungen gemacht... Aber, wie man es gewohnt ist...
..."fhem" User anlegen meint Passwort etc vergeben.
Also bei mir laufen die neuen Module ohne Probleme, die freeze sind auch weg.
Kannst du schon sagen, wann die Module ins normale update kommen???
Danke nochmal für die Hilfestellungen, habe die beiden Dateien erfolgreich eingebunden!
Habe auch gesehen, dass die Hilfestellung schon im Beta-Thread ist - spitze!
Nun bin ich dabei mich mit dem VirtualShutterContact (VSC) auseinanderzusetzen. Dazu habe ich noch Fragen ;-)
- ich habe ja schon Fensterkontakte, diese liefern in der Regel ein "auf/zu", bisher habe dann diesen Zustand kontrollieren lassen und ein Signal an den jeweiligen HT FakeShutter gesendet. Neu lege ich einen zusätzlichen VSC an an den ich dann das Signal senden lasse, anstelle direkt an den HT - richtig?
- Ich habe gelesen, dass es wichtig (notwendig?) ist bei HT und VSC eine GroupID zu setzen, die zusammenpassen muß. Damit der VSC die zu steuernden HT kennt. Zusätzlich dem HT noch den VSC zuordnen, damit alles klappt.
Wenn ich das richtig verstanden habe, nun meine ergänzende Frage: Damit kann ich z.B. einen Raum mit einem HT und einem Fenster wunderbar steuern, auch wenn in einem Raum mehrere Fenster sind, senden die jeweils ein "auf" an den einen VSC des Raumes, oder? Ich habe nun aber zusätzlcih geplant, dass wenn z.B. die Haustür länger offensteht, das komplette EG auf "Fenster offen" geht, dazu sendet nun die Tür nach einer Wartezeit "auf" an wen? An alle relevanten VSC? Bin ich da auch richtig unterwegs?
Wenn nun aber ein anderes Fenster im EG aufgemacht und kurz darauf geschlossen wird, sendet es ein "zu" an den VSC, obwohl die Tür z.B. noch offen steht... Wie löse ich das richtig, oder habe ich da etwas falsch verstanden?
Zitat von: Parador am 29 April 2020, 17:24:16
Neu lege ich einen zusätzlichen VSC an an den ich dann das Signal senden lasse, anstelle direkt an den HT - richtig?
den Satz verstehe ich nicht so richtig. Ja du kannst einen vSC anlegen, nein dem sendest du nichts !
Du belegst im vSC das Attribut externalSensor und der vSC macht den Rest - kein DOIF, kein notify
ZitatIch habe gelesen, dass es wichtig (notwendig?) ist bei HT und VSC eine GroupID zu setzen,
Notwendig, die groupID ist der Raum in der Original ELV Cube Firmware. IMHO schenkt die Mehrheit der User der groupID zu wenig Beachtung.
ZitatZusätzlich dem HT noch den VSC zuordnen, damit alles klappt.
Das HT/WT associate vSC ist zwingend notwendig damit ein HT/WT überhaupt auf Nachrichten dieses vSC regagiert.
Zitatsenden die jeweils ein "auf" an den einen VSC des Raumes, oder?
nein die senden nicht an den vSC , siehe oben. Das vSC Device sieht den open/close Event des FKs und sendet in Abhängikeit des Attributs sendMode
ZitatWie löse ich das richtig
gute Frage , ich hatte bisher nie die Test Stellung mehr als ein FK an ein HT/WT. Eigentlich müssten die Dinger sich intern dafür eine Tabelle anlegen und dann wenn min noch einer offen den WindowOpen Mode behalten.
ok, der Reihe nach..
Ich bin nach der der Beschreibung bei "neue Beta Versionen von 10_MAX und 14_CUL_MAX" gegangen...
und bin leider nicht bis zum Punkt: braucht kein Doif/Notify gekommen ;-(
In Deiner Anleitung liest es sich als seidie GroupID nun zwingend zu setzen, aktuell habe ich Sie auch nicht gesetzt.
Ich habe jetzt einen HT mit einem FK über einen vSC verbunden und die Erkennung Fenster auf/zu klappt! Danke
Wenn Du jetzt noch eine Idee zu meinem "komplettes EG runterfahren, wenn ein Fenster/Tür im EG länger als x Minuten offen ist" hinbekommst, wäre das spitze.
Aktuell löse ich das über Doif's mit wait, wenn ich aber im Moment alles richtig verstanden habe, fällt diese Option weg.... da keine Doif wie beim FSC mehr zum Einsatz kommen
a. wie ich schrieb : groupId ist leider ein Stiefkind für die User , tue dir den Gefallen und mach es gleich sauber , d.h. setze sie.
b. welchen sendMode benutzt du z.Z. ?
c. nein dein verzögertes DOIF ist nicht raus , naürlich kannst du es weiter nutzen, nur für simple 1:1 Verbindungen werden sie halt im Gegensatz zum fakeSC halt nicht unbedingt gebraucht, da externalSensor dem User die Arbeit abnimmt - wenn er denn möchte.
a. Ok, werde die GroupID mal pro Raum vergeben, ist ja auch schnell gemacht!
b. da primär ein FK zu einem HT habe ich es aktuell bei Broadcast belassen
c. Von der Reihenfolge was ist denn über/untergeordnet.... vSC oder FSC? und was ist wenn hier unterschiedliche Dinge ankommen?
noch eine andere Frage zu den Peers:
Bei mir finden sich in bei dem einen umgestellten HT folgende Einträge:
peerIDs: 000000,222222
peerList: Broadcast,MAX_222222
peers: 010201
010201 ist der vSC den ich angelegt habe,
000000 ist Broadcast, verstehe ich auch
222222 bzw. MAX_222222 ist der FSC... konnte ich nur der fhem.cfg entnehmen
könnte man dies vielleicht noch mit sprechenden Namen hinterlegen? Also z.B. den Device Namen dazuschreiben? Oder ist das dann zuviel Information und überflüssig?
peerIDs & peerList sind die gleiche Liste : mit wem hat das Gerät gesprochen -> einmal die Hex Adresse und einmal der FHEM Device Name
Das 222222 die fakeSC Adresse ist war schon immer so, nur halt unsichtbar für den User. Jetzt sieht man sie -> Attribut fakeSCaddr am CULMAX Device und man darf sie sogar ändern :)
peers ist eine Liste die sich auf und abbaut durch absetzen des associate/deassoicate Kommandos -> Ausnahme die virtuellen Geräte SC und Thermostat,
da hier kein set associate ausgeführt wird muss der User die Liste als Attribut selber pflegen. Wie ich in der Doku bereits schrieb kann man die nicht vom Gerät zurücklesen, also gut merken, aufschreiben oder mittels saveConfig von Hand sichern oder Attribut autoSaveConfig setzen und automatisch bei jeder Änderung sichern.
Und die Liste willst du nun nochmal als sprechende Namen haben ?
wenn ja : werd ich so schnell nicht tun, Namen sind Schall & Rauch und können sich mittels rename ändern, die HEX Adressen dagegen sind in Stein gemeißelt.
Alles klar, Danke für die Ausführungen und die viele Mühe!! Toll das Du dieses Modul so gut überarbeitest!
Werde jetzt erstmal die Umstellung bei mir Stück für Stück vornehmen.
Zitat von: hyper2910 am 29 April 2020, 13:27:04
Kannst du schon sagen, wann die Module ins normale update kommen???
ja stimmt , das negativ Echo war bisher bescheiden und die Heizperiode geht auch langsam zu Ende.
Ganz zu schweigen von der Tatsache das ich nun schon seit Tagen an der Beta von der Beta schraube .....
machen wir es wie im Kinderlied "Alles neu macht der Mai"
Zitatalles freut sich der Zeit, die verschönt erneut.
Widerschein der Schöpfung blüht uns erneuend im Gemüt.
Alles neu, frisch und frei macht der holde Mai
Bei der Umstellung hat sich noch eine Frage ergeben:
Was mache ich bei mehreren Fenstern? Im vSC hinterlege ich ja als external Sensor einen FK, kann ich auch mehrere hinterlegen? Oder wie mache ich das richtig?
Der Sinn des virtuellenShutterContacts ist u.A. das man soviele davon anlegen kann wie einem Adressen einfallen. Der fakeSC ist auf einen pro Installation beschränkt.
D.h. du legest dir für jeden echten FK einen virtuellen Bruder an :)
Ah, ok! Das würde ich als Ergänzung noch in die Anleitung packen.
Aber den FSC gabs nur einmal? Hm, ich hatte den Eindruck dass ich da mehr hatte, einen pro HT... aber das hätte ich mir wohl mal in der fhem.cfg ansehen müssen. Hat einigermaßen gut geklappt.
wenn mehr als ein fakeSC möglich wäre :
a. gäbe es die Probleme der User nicht
b. hätte ich mir die Arbeit sparen können ein virtuelles Device zu erfinden.
;-) ok verstehe, komisch hat bei mir geklappt.
Jetzt ist ein Problem aufgetaucht: Ich habe einen vSC angelegt und habe die falsche MAX-ID (laut meiner Logik) erwischt.
Bin daraufhin nochmal in die Device-Def und habe Sie geändert.
Dann wollte ich am HT den vSC assoziieren... Aber jetzt taucht er zwei Mal auf.
Wenn ich das Device lösche, verschwindet einer, der andere ist immer noch da...
FHEM Grundlagen : Readings von Geräten kann der User selbst nach Lust & Laune selbst verbiegen, das Zauberwort nennt sich setreading
Ich kann im Modul nicht alles vorsehen was der User so macht, daher auch keine Änderung von Readings am Gerät A wenn B von Hand angepasst wird.
Hallo Wzut,
danke für den Hinweis, allerdings wüsste ich nicht wo ich ein Reading ändern sollte.
Vermutlich habe ich mich falsch ausgedrückt. Ich habe einen vSC (Name AAA) mit falscher ID (020201) angelegt. Dieser spukt nun noch als Geist herum.
Wenn ich in den vSC (AAA) gehe, steht inzwischen die richtige 6-Stellige MaxID (020401) darin, das geht ja über die DEF. Auch im zugehörigen HT steht die richtige.
Wenn ich nun aber versuche einen weiteren vSC (Name BBB) anzulegen diesmal ist die MaxID (020201) laut meiner Logic die richtige, sagt mit FHEM diese sei bereits vergeben und verweist auf den vSC (AAA)...
Auch wenn ich bei einem HT in das DropDown zum Associate gehe taucht der eigentlich gelöschte vSC (AAA) zusätzlich oder wenn wieder korrekt angelegt doppelt auf.
Mir ist im Moment also unklar, was ich korrigieren muss, damit der "Geist" verschwindet.
Ergänzung: Ich habe gerade mal einen Neustart gemacht und jetzt scheint der Geist verschwunden zu sein!
Zitat von: Parador am 01 Mai 2020, 13:31:04
Ich habe gerade mal einen Neustart gemacht und jetzt scheint der Geist verschwunden zu sein!
Das wäre jetzt auch mein erster Rat gewesen. Es gibt Fälle (die ich selbst schon hatte, aber nicht reproduzieren konnte) wo sich so ein Geist hartnäckig hält.
I.d.R. spuckt FHEM den auch nicht via list TYPE=MAX aus.
Nachdem Du ja immer ganz tolle Dinge mit einbaust, dürfte ich was auf eine Wunschliste setzen?
- Wäre evtl. eine Zeitverzögerung über ein wait Attribut noch denkbar? Szenario: (Terrassen)tür die nur kurz geöffnet wird um rein/raus zu gehen, da muß nicht sofort auf window-open-temp heruntergefahren werden...
- Ich bin mir noch nicht sicher, ob es von der Programmierung sinnvoll ist.. da man ja mehrere Vsc anlegen kann.
Aber vielleicht ist es machbar, dass bei einen vSC mehrere FK aufehmenbar sind ? d.h. das es z.B. "ExternalSensor1 bis 5" gibt, und solange einer offen ist, bleibt es auf offen? Mehrere Fenster,(-Flügel) oder Fenster und Tür pro Zimmer könnte es schon öfter geben :-)
Zitat von: Parador am 01 Mai 2020, 13:31:04
allerdings wüsste ich nicht wo ich ein Reading ändern sollte.
*seufz* , ich hatte dir das Zauberwort bereits genannt : setreading -> https://fhem.de/commandref_DE.html#setreading
Zitatsteht inzwischen die richtige 6-Stellige MaxID (020401) darin, das geht ja über die DEF.
genau hier liegt der Hund begraben, sobald man mittels DEF edit die Adresse ändert bleibt die alte Definition mit der alten Adresse als Leiche zurück.
Habe das nun nachstellen können und wird in einem späteren Update gefixt. Bis dahin ist man auf der sichern Seite wenn man das Device komplett löscht und mit der richtigen Adresse neu anlegt.
Zitat von: Parador am 01 Mai 2020, 18:59:17
Wäre evtl. eine Zeitverzögerung über ein wait Attribut noch denkbar?
nein, ich werde nicht versuchen DOIF Teile (wait) oder notify ( disabledAfterTrigger ) in den MAX Modulen nachzubauen. Wer das haben möchte muß die Module benutzen deren Job soetwas ist und den auch wesentlich besser machen als Teilclone.
Zitatdass bei einen vSC mehrere FK aufehmenbar sind
auch das macht IMHO keinen Sinn , ein vSC ist ein Ersatz für einen echten MAX FK. Wie ich schon schrieb können MAX HTs & WTs mehr als einen FK als Sensor verwalten. Warum also nicht zwei vSC ? Für Gruppenabfragen oder Schaltungen würde ich mir mal eines der darauf spezialisierten FHEM Module anschauen, bzw ganz neu : 98_combine -> https://forum.fhem.de/index.php/topic,110165.0.html
Zitat von: Parador am 01 Mai 2020, 18:59:17
Wäre evtl. eine Zeitverzögerung über ein wait Attribut noch denkbar? Szenario: (Terrassen)tür die nur kurz geöffnet wird um rein/raus zu gehen, da muß nicht sofort auf window-open-temp heruntergefahren werden...[/li][/list]
Dafür gibt es schon einige Lösungen:
https://forum.fhem.de/index.php/topic,49635.msg413616.html#msg413616 (https://forum.fhem.de/index.php/topic,49635.msg413616.html#msg413616)
https://forum.fhem.de/index.php/topic,49852.msg416026.html#msg416026 (https://forum.fhem.de/index.php/topic,49852.msg416026.html#msg416026)
Gruss
Willyk
ZitatDafür gibt es schon einige Lösungen:
https://forum.fhem.de/index.php/topic,49635.msg413616.html#msg413616
https://forum.fhem.de/index.php/topic,49852.msg416026.html#msg416026
so ähnlich habe ich es aktuell mit den alten FSC und Doifs gelöst (vielleicht noch nicht so perfekt wie in den Beispielen, danke willyk), hatte nur Potential gesehen sich zusätzliche Doifs sparen zukönnen... muss aber ja nicht sein... ;-)
Zitat*seufz* , ich hatte dir das Zauberwort bereits genannt : setreading -> https://fhem.de/commandref_DE.html#setreading
Ja, ich kenne "setreading" nur waren wir uns ja schon einig, dass nirgends ein Reading mit dem Wert auftauchte... also nicht
wie, sondern
wo war das Problem ;-))
Ist ja aber erledigt...
Danke nochmal für die Hilfestellungen!
Ich habe mich versucht meine alten fake WTs mit der neuen Methode zu ersetzen. Ich benutze Xiaomi Zigbee Temperatur Sensoren.
Ich habe bei meine HT nun external Sensor "BZ_TEMP:temperature:1" definiert, damit mit jeden update die Temperatur zum Thermostat gesendet wird.
Leider stürzt fhem komplett ab sobald der Temperatursensor Daten schickt. Ohne "BZ_TEMP:temperature:1" funktioniert alles.
Ein Stück Logfile vom Absturz wäre schön, so kann ich nur raten.
Um 18:22:58 hab ich den knopf am Thermometer für manuelles senden gedrückt, dann steigt fhem direkt aus.
2020.05.14 18:22:58 5: deCONZ: websocket data: $VAR1 = {
'uniqueid' => '00:15:8d:00:03:5c:06:d8-01-0402',
't' => 'event',
'r' => 'sensors',
'e' => 'changed',
'config' => {
'offset' => 0,
'battery' => 95,
'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'reachable' => $VAR1->{'config'}{'on'}
},
'id' => '9'
};
2020.05.14 18:22:58 4: parse status message for WZ_Temp
2020.05.14 18:22:58 4: WZ_Temp: lastupdated: , hash->{lastupdated}: 2020-05-14 16:14:27, lastupdated_local: , offsetUTC: 0
2020.05.14 18:22:58 5: deCONZ: websocket data: $VAR1 = {
'id' => '9',
'e' => 'changed',
'state' => {
'temperature' => 2406,
'lastupdated' => '2020-05-14T16:22:58'
},
'r' => 'sensors',
't' => 'event',
'uniqueid' => '00:15:8d:00:03:5c:06:d8-01-0402'
};
2020.05.14 18:22:58 4: parse status message for WZ_Temp
2020.05.14 18:22:58 4: WZ_Temp: use offsetUTC 7200 from bridge
2020.05.14 18:22:58 4: WZ_Temp: lastupdated: 2020-05-14 16:22:58, hash->{lastupdated}: 2020-05-14 16:14:27, lastupdated_local: 2020-05-14 18:22:58, offsetUTC: 7200
2020.05.14 18:22:58 5: Starting notify loop for WZ_Temp, 1 event(s), first is temperature: 24.06
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> ### start of new Logcycle ###
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> number of events received: 1 for device: WZ_Temp
2020.05.14 18:22:58 4: DbLog DBLogging -> check Device: WZ_Temp , Event: temperature: 24.06
2020.05.14 18:22:58 5: DbLog DBLogging -> parsed Event: WZ_Temp , Event: temperature: 24.06
2020.05.14 18:22:58 5: DbLog DBLogging -> DbLogInclude of "WZ_Temp": temperature
2020.05.14 18:22:58 4: DbLog DBLogging -> added event - Timestamp: 2020-05-14 18:22:58, Device: WZ_Temp, Type: HUEDEVICE, Event: temperature: 24.06, Reading: temperature, Value: 24.06, Unit: °C
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> ### New database processing cycle - synchronous ###
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> DbLogType is: Current/History
2020.05.14 18:22:58 4: DbLog DBLogging -> AutoCommit mode: ON, Transaction mode: ON
2020.05.14 18:22:58 4: DbLog DBLogging -> Insert mode: Array
2020.05.14 18:22:58 4: DbLog DBLogging -> Primary Key used in history: none
2020.05.14 18:22:58 4: DbLog DBLogging -> Primary Key used in current: none
2020.05.14 18:22:58 4: DbLog DBLogging -> processing event Timestamp: 2020-05-14 18:22:58, Device: WZ_Temp, Type: HUEDEVICE, Event: temperature: 24.06, Reading: temperature, Value: 24.06, Unit: °C
2020.05.14 18:22:58 4: DbLog DBLogging -> 1 of 1 events inserted into table history
2020.05.14 18:22:59 4: DbLog DBLogging -> insert table history committed by autocommit
2020.05.14 18:22:59 4: DbLog DBLogging -> 1 of 1 events updated in table current
2020.05.14 18:22:59 4: DbLog DBLogging -> insert / update table current committed by autocommit
2020.05.14 18:22:59 5: MAX_1262e3, NOTIFY EVENT -> Dev : WZ_Temp | Event : temperature: 24.06
2020.05.14 18:22:59 5: MAX_1262e3, updating externalTemp with 24.06
Undefined subroutine &main::validTemperature called at ./FHEM/14_CUL_MAX.pm line 490.
2020.05.14 18:23:07 5: Initializing Type Library:
2020.05.14 18:23:10 5: Cmd: >attr global userattr DbLogExclude DbLogInclude DbLogValueFn:textField-long assistantName:textField cmdIcon devStateIcon devStateIcon:textField-long devStateStyle gassistantName:textField genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock,aircondition,airpurifier,camera,coffeemaker,dishwasher,dryer,fan,kettle,oven,refrigerator,scene,sprinkler,vacuum,washer,airfreshener,fireplace,heater,blinds,awning,boiler,curtain,door,gate,hood,microwave,pregola,securitysystem,shutter,shower,valve,waterheater,ac_unit,bathtub,bed,blender,closet,coffee_maker,cooktop,dehumidifier,dehydrator,drawer,faucet,fryer,grill,humidifier,mop,mower,multicooker,pergola,petfeeder,pressurecooker,radiator,sousvide,standmixer,yogurtmaker,charger,sensor,carbon_monoxide_detector,remotecontrol,settop,smoke_detector,tv,waterpurifier,watersoftener,network,router homebridgeMapping:textField-long icon realRoom:textField sortby webCmd webCmdLabel:textField-long widgetOverride<
2020.05.14 18:23:10 5: Cmd: >attr global DbLogExclude .*<
2020.05.14 18:23:10 5: Cmd: >attr global autoload_undefined_devices 1<
2020.05.14 18:23:10 5: Cmd: >attr global latitude 48.705587<
2020.05.14 18:23:10 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2020.05.14 18:23:10 5: Cmd: >attr global longitude 10.161534<
2020.05.14 18:23:10 5: Cmd: >attr global modpath .<
2020.05.14 18:23:10 5: Loading ./FHEM/99_MyUtils.pm
2020.05.14 18:23:10 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_MyUtils.pm line 15.
2020.05.14 18:23:10 1: PERL WARNING: Subroutine checkFritzMACpresent redefined at ./FHEM/99_MyUtils.pm line 21.
2020.05.14 18:23:10 5: Cmd: >attr global motd none<
2020.05.14 18:23:10 5: Cmd: >attr global room 99_System<
2020.05.14 18:23:10 5: Cmd: >attr global stacktrace 1<
2020.05.14 18:23:10 5: Cmd: >attr global statefile ./log/fhem.save<
2020.05.14 18:23:10 5: Cmd: >attr global verbose 5<
2020.05.14 18:23:10 5: Cmd: >define WEB FHEMWEB 8083 global<
2020.05.14 18:23:10 5: Loading ./FHEM/01_FHEMWEB.pm
2020.05.14 18:23:11 4: configDB reading file: ./FHEM/FhemUtils/uniqueID
2020.05.14 18:23:11 3: WEB: port 8083 opened
2020.05.14 18:23:11 5: Cmd: >setuuid WEB 5c713551-f33f-ccaa-7af7-e82ebd99127cb37d<
2020.05.14 18:23:11 5: Cmd: >attr WEB defaultRoom dash<
2020.05.14 18:23:11 5: Cmd: >attr WEB endPlotNow 1<
2020.05.14 18:23:11 5: Cmd: >attr WEB hiddenroom Everything<
2020.05.14 18:23:11 5: Cmd: >attr WEB room 99_System<
2020.05.14 18:23:11 5: Cmd: >attr WEB roomIcons 06_Hausgang:light_stairs 05_Schlafzimmer:hue_room_bedroom 04_Flur:scene_hall 60_Plots:time_graph 01_Wohnzimmer:scene_livingroom 00_Draußen:scene_summerhouse 02_Küche:scene_baking_oven 03_Bad:scene_bathroom 04_Schlafzimmer:scene_sleeping 80_Automation:rc_SHUFFLE 96_PLOTS:time_graph 99_System:edit_settings 97_LOG:time_note 98_Geräte:mqtt_device 85_Bewohner:user_unknown GoogleAssistant:alexa2 97_Battery:measure_battery_100<
2020.05.14 18:23:11 5: Cmd: >attr WEB styleData {
"f18": {
"Pinned.menu": true,
"hidePin": false,
"cols.bg": "F8F8F8",
"cols.fg": "465666",
"cols.link": "4C9ED9",
"cols.evenrow": "E8E8E8",
"cols.oddrow": "F0F0F0",
"cols.header": "DDDDDD",
"cols.menu": "EEEEEE",
"cols.sel": "CAC8CF",
"cols.inpBack": "FFFFFF",
"savePinChanges": true,
"rightMenu": false,
"wrapcolumns": false,
"fixedInput": false,
"Pinned.Room.80%5fAutomation.grp.MAX!": true,
"Pinned.Room.GoogleAssistant.grp.Multimedia": true,
"Pinned.Room.02%5fK%c3%bcche.grp.Fenster": true
}
}<
2020.05.14 18:23:11 5: Cmd: >attr WEB stylesheetPrefix f18<
2020.05.14 18:23:11 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m.log fakelog<
2020.05.14 18:23:11 5: Loading ./FHEM/92_FileLog.pm
Vielleicht das hier?
Undefined subroutine &main::validTemperature called at ./FHEM/14_CUL_MAX.pm line 490.
na also geht doch :) Fix habe ich eben hochgeladen ( siehe anderer Thread )
Und BTW : wir müssen ein Thema nicht in zwei verschiednen Threads behandeln, da blicke ich am Ende selbst nicht mehr durch wo ich was geschrieben habe.
Hallo
Eine vielleicht ganz dumme Frage aber eine Frage welche ich nicht beantworten kann da ich hierzu keine Antwort gefunden habe. Ich verwende für meine MAX Geräte den MAX Cube im Original, eingebunden als MAXLAN. Auf Grund der Wohnungsgröße ist das ein oder andere Gerät eher schlecht in der Verbindung (RSSI bei 65 bis 75). Ein versetzen des MAX Cube ist eher problematisch da ich in einer Mietwohnung wohne. Nun zu meiner Frage : Besteht die Möglichkeit einen zweiten MAX Cube in FHEM einzubinden mit MAXLAN und zu betreiben. Den zweiten MAX Cube könnte ich per DLAN an FHEM anbinden und in der Wohnung an einer anderen Stelle platzieren.
Wie ich gelesen habe funktioniert das mit zwei CUL jetzt ohne Probleme. Für eine Antwort wäre ich dankbar.
Gruß an alle.
Zitat von: Wzut am 14 Mai 2020, 19:24:44
na also geht doch :) Fix habe ich eben hochgeladen ( siehe anderer Thread )
Und BTW : wir müssen ein Thema nicht in zwei verschiednen Threads behandeln, da blicke ich am Ende selbst nicht mehr durch wo ich was geschrieben habe.
Fix hat funktioniert.
Eine kurze Frage noch zu dem neuen fakeWT: Muss ich trotzdem ein associate mit fakeWT durchführen? Und wie ist das verhalten wenn 30 min kein neues Event vom Thermometer kommt? Seither sind die Thermostate dann auf rferror gesprungen.
was bitte ist das "neue" fakeWT ? Ich habe intern eine Baustelle die nennt sich virtualThermostat (ähnlich dem neuen virtualSC),
allerdings würde ich heute keinem User empfehlen damit an den Start zu gehen. D.h. wer die Funktion fakeWT brauch muß auch fakeWT benutzen.
Das ein HT "meckert" wenn es eine Zeit X keine Telegramme vom Chef WT bekommt (egal ob echt oder fake) liegt in der Firmware der HTs und darauf habe ich keinen Einfluß.
Mit der neuen Methode meine ich den Sensor über Externalsensor zu koppeln
Mit ist nicht klar ob ich dann trotzdem noch ein associate mit fakeWT machen muss?
Das heißt der mit dem Attribut "externalsensor" wird nicht automatisch ein neue Befehl bevor der HT auf Störung geht?
Natürlich brauchst du das associate des HT mit dem fakeWT, da hat sich nichts geändert !
Habe ich das in der Doku so unverständlich geschrieben ?
Zitatund ausserdem über das CULMAX Device der Befehl fakeWT abgesetzt werden soll. D.h. man spart sich das im Wiki beschriebene notify und den Code Teil in der 99_myUtils
spart : notify und 99_myUtils , spart
nicht : associate
Hallo Wzut
Ich bin sehr froh mit Ihrer Wartung der MAX!-Module ! !
Habe gesternabend ein algemeine Update von FHEM gemacht. Dann habe ich die Batterien eines HT gewechselt. Ich kann nicht mehr überprüfen, ob die Fehlermeldung, die in MAX_CV_Voorkamer_VR nach dem Update oder nach dem Batteriewechsel aufgetreten ist. Soweit ich weiß, ist alles in Ordnung, aber ich gehe davon aus, dass Sie an der Fehlermeldung interessiert sind (siehe Reading: error)
Internals:
DEF HeatingThermostat 0f893b
FUUID 5c51ecea-f33f-5a50-d8a7-1a250eb83ded379b
IODev cm
LASTInputDev cm
MSGCNT 17
NAME MAX_CV_Woonkamer_VR
NR 232
NTFY_ORDER 50-MAX_CV_Woonkamer_VR
STATE 20.5°C
SVN 21928
TYPE MAX
TimeSlot 4
addr 0f893b
cm_MSGCNT 17
cm_TIME 2020-05-15 18:25:02
devtype 1
type HeatingThermostat
READINGS:
2020-05-14 21:41:18 PairedTo 123456
2020-05-15 18:25:02 RSSI -62.5
2020-05-14 21:41:18 SerialNr LEQ1004593
2015-11-06 21:11:18 TimeInformationHour 4
2020-05-15 18:25:02 battery ok
2020-05-15 18:25:02 batteryState ok
2015-11-06 21:57:33 boostDuration 5
2015-11-06 21:57:33 boostValveposition 80
2015-11-06 21:57:33 decalcification Sat 12:00
2020-05-15 18:25:02 desiredTemperature 20.5
2020-05-15 15:32:33 deviation 0.1
2020-05-14 21:41:20 error Invalid command/argument 81190028
2020-05-14 21:41:18 firmware 1.0
2020-05-15 18:25:02 gateway 1
2020-05-14 21:51:52 groupid 1
2020-05-15 18:24:54 lastTimeSync 2020-05-15 18:24:54
2020-05-14 21:57:01 lastcmd set_associate MAX_WT_Woonkamer
2015-11-06 21:57:33 maxValveSetting 100
2020-05-15 18:25:02 mode auto
2020-05-15 18:24:54 msgcnt 31
2020-05-15 18:25:02 panel unlocked
2020-05-15 15:32:33 peerIDs 000000
2020-05-15 15:32:33 peerList Broadcast
2020-05-15 18:25:02 rferror 0
2020-05-15 18:25:02 state 20.5°C
2020-05-15 15:32:33 temperature 20.6
2020-05-14 21:41:18 testresult 161
2015-11-06 21:57:33 valveOffset 0
2020-05-15 18:25:02 valveposition 0
helper:
io:
CUL1:
raw Z0E1F02020F893B1234560001180029
rssi -62.5
time 1589559902.42552
Attributes:
IODev cm
model HeatingThermostat
room Woonkamer
Um die RSSIs der verschiedenen Geräte zu überprüfen, habe ich in Fhem eine Tabelle namens RSSI. Nach der Aktualisierung wird das Datum und die Uhrzeit des Empfangs angezeigt, aber die RSSI-Werte gehen jedoch verloren. Ich mache das mit
define rssi readingsGroup .*:+.*RSSI,+.*_TIME
CUL1, cm und MAX..... gehören zu MAX!
Die anderen Geräte gehören zu FS20.
Wie sehe ich die RSSI-Werte wieder?
Mit freundlichen Grüßen
Sibbe
Zitat von: SibbeH am 15 Mai 2020, 19:12:34
NAME MAX_CV_Woonkamer_VR
2020-05-14 21:41:20 error Invalid command/argument 81190028
2020-05-14 21:57:01 lastcmd set_associate MAX_WT_Woonkamer
Hier sieht man das es nicht um einen Batteriewechsel geht sondern ein "set MAX_CV_Woonkamer_VR associate MAX_WT_Woonkamer"
Dieser Versuch schlug fehl , IMHO hat MAX_WT_Woonkamer eine Adresse die irgendwie zu 190028 passt.
Noch besser sieht man solche Dinge wenn man das CULMAX Device auf verbose 5 stellt. Aber egal der Error sollte sich auch im Logfile finden lassen.
Meine Vermutung : es wurde ein associate versucht das bereits bestand, die werden dann immer mit Fehler abgewiesen.
Zur rg , das + wählt Internals aus, der RSSI Wert ist aber ein Reading !
Wäre es meine rg würde sie so aussehen :
defmod rssi2 readingsGroup TYPE=MAX:RSSI
attr rssi2 mapping %DEVICE
attr rssi2 valueStyle style="text-align:right"
Ich habe in der Tat versehentlich einen associate an MAX_CV_Woonkamer_RV gesendet. Damit habe ich die Readings nicht richtig nachgesehen. Sorry.
Das mit die RSSI habe ich ausprobiert und hat geklapt.
Ich soll nachdenken über wie ich die Readings und die Internals in einem Tabelle bekomme.
Vielen Dank !
Gruß,
Sibbe
Na einfach die Regex anpassen , erweitern :
TYPE=(MAX|CUL_MAX|CUL|FS20):RSSI,+.*RSSI,+.*TIME
wobei ich es nicht machen würde, die Tabelle hat dann keine schöne Formatierung mehr.
Und beim CUL und CULMAX Device sagen doch diese nackten RSSI Werte gar nichts.
Wenn FS20 die nur als Internals hat würde ich zwei Gruppen machen.
Ich mache zwei Gruppen.
Vielen Dank !
Gruß,
Sibbe
Hallo, ich habe heute mal nach sehr langer Zeit wieder ein update für fhem einspielen lassen und damit auch die neuen MAX Module bekommen.
Ich betreibe MAX mit MAX_LAN und lasse zusätzlich eine CUL mitlaufen, um schneller auf Nachrichten reagieren zu können.
Ich habe z.B. bei allen Fenstern ein Notify, um auf geöffnete und geschlossene Fenster reagieren zu können.
Nun sieht das Log für ein Fenster nach dem Update so aus:
2020-05-27_09:51:40 Arbeit_Fenster waiting for data
2020-05-27_09:51:40 Arbeit_Fenster closed
2020-05-27_09:51:53 Arbeit_Fenster waiting for data
2020-05-27_09:51:54 Arbeit_Fenster closed
2020-05-27_09:52:03 Arbeit_Fenster waiting for data
2020-05-27_09:52:04 Arbeit_Fenster closed
2020-05-27_09:52:16 Arbeit_Fenster waiting for data
2020-05-27_09:52:17 Arbeit_Fenster closed
2020-05-27_09:55:24 Arbeit_Fenster waiting for data
2020-05-27_09:55:25 Arbeit_Fenster closed
2020-05-27_09:55:37 Arbeit_Fenster waiting for data
2020-05-27_09:55:38 Arbeit_Fenster closed
2020-05-27_09:55:48 Arbeit_Fenster waiting for data
2020-05-27_09:55:49 Arbeit_Fenster closed
2020-05-27_09:56:00 Arbeit_Fenster waiting for data
2020-05-27_09:56:01 Arbeit_Fenster closed
2020-05-27_09:59:09 Arbeit_Fenster waiting for data
2020-05-27_09:59:11 Arbeit_Fenster closed
2020-05-27_09:59:23 Arbeit_Fenster waiting for data
2020-05-27_09:59:24 Arbeit_Fenster closed
2020-05-27_09:59:34 Arbeit_Fenster waiting for data
2020-05-27_09:59:35 Arbeit_Fenster closed
2020-05-27_09:59:47 Arbeit_Fenster waiting for data
2020-05-27_09:59:49 Arbeit_Fenster closed
Und darauf springen meine Notifys dann immer wieder neu an, auch wenn die Fenster geschlossen sind.
defmod ntArbeitFenster notify Arbeit_Fenster:.* {}.
Ist das Verhalten bekannt? Was kann man da machen?
Und dann noch eine weitere Meldung aus dem globalen fhem-Log:
After sleep: MAXLAN_Write: MAXLAN_SimpleWrite: Not connected
Was soll mir das sagen?
Das Update habe ich erstmal wieder zurück genommen und fahre weiter mit meiner alten Installation.
Danke für jede Unterstützung
Jürgen
das sieht aus als ob Cube und CUL sich gegenseitig state überschreiben.
Ich würde die notifys nicht mit der dicken Kelle .* anlegen sondern eher nach dem Muster Arbeit_Fenster:onoff:(0|1) {blablub}
und natürlich am Device event-on-change-reading .* bzw. mindestens onoff
Zu der MAXLAN Meldung kann ich nichts sagen da ich das Modul bisher weder angefasst habe noch wisse was da intern abläuft.
Danke für die schnelle Antwort. Ich stelle meine notifys um.
Aber vor dem nächsten Updateversuch werde ich vermutlich erstmal auf buster upgraden und dann später einen neuen Versuch mit fhem starten.
Immer nur eins nach dem anderen :).
Kannst ja erst einmal ein notify anpassen und testen, da es das onoff Reading schon immer gab sollte das auch bei uralt Versionen gehen.
Hallo, inzwischen habe ich die Upgrade durch (sowohl Raspi auf buster als auch fhem auf die neuste Version).
So alt war mein bisheriges FHEM nun doch nicht. Der alte Stand war von November 2019.
Und zur Sicherheit habe ich vor dem Upgrade von FHEM auch mal alle Geräte inklusive des Cube resetet und neu verbunden, da ich zwischendurch den Eindruck hatte, das da noch alte oder unbekannte Geräte schlummern.
Die Einschränkung des notify hat so natürlich funktioniert.
Aber die Meldungen mit "waiting for data" habe ich immer noch.
Bei den Fensterkontakten kann ich mich überhaupt nicht auf "Value("fenstername")" verlassen, da hier immer wieder obige Meldung dazwischen funkt, und damit auch die Watchdogs nicht mehr liefen.
Ich habe jetzt alle Zugriffe auf das Reading onoff umgestellt und das funktioniert auch.
Aber einen Grund für diese Nachrichten zu haben wäre schon schön (und die Meldungen weg zu bekommen).
Zur Situation: Ich betreibe schon länger einen MAXLAN und einige Geräte daran.
Da mir aber das Melden von offenen Fenstern damit zu lange dauert, kam später noch ein CUL868 dazu. Alles lief ohne Probleme bis zum Upgrade von FHEM. Der Cube wird nur noch alle 10 Minuten gefragt, wahrscheinlich könnte ich das Intervall auch verlängern.
Hier ein Listing meines MAXLAN
Internals:
CULMAX0_MSGCNT 7
CULMAX0_TIME 2020-06-10 11:27:44
DEF 192.168.168.29 600 ondemand
DeviceName 192.168.168.29:62910
FUUID 5ed90403-f33f-98e0-79f0-b8d3b5fff43200fe
INTERVAL 600
LASTInputDev CULMAX0
MSGCNT 7
NAME ml
NR 286
STATE 1
TYPE MAXLAN
addr 03b7d0
clockset 3
cubeTimeDifference 0
dutycycle 1 %
fwversion 0113
pairmode 0
persistent 0
serial JEQ0131613
READINGS:
2020-06-10 11:27:44 RSSI -22
2020-06-10 07:01:44 desiredTemperature 0.0
2020-06-10 11:27:13 dutycycle 1
2020-06-10 11:27:13 firmware 0.1
2020-06-10 07:01:44 mode auto
2020-06-10 11:27:44 peerIDs 002141,00532b,006864,006c1e,01591f,02066e,020d72,020e10,021902,024e74,026283,0270ac,029fa7,02a1ad,02a4a4,03c7cb,0a031f,0f6aef,133012
2020-06-10 11:27:44 peerList Arbeit_Fenster,Arbeit_Thermo,Arbeit_WandThermo,Bad_Fenster,Bad_Thermo,Bad_WandThermo,Kueche_Fenster,Kueche_Thermo,Kueche_WandThermo,Schlaf_Fenster,Schlaf_Thermo,Schlaf_WandThermo,Souterrain_Fenster_links,Souterrain_Fenster_rechts,Wohn_Fenster,Wohn_Thermo_Couch,Wohn_Thermo_Ess,Wohn_Thermo_Front,Wohn_WandThermo
2020-06-10 11:27:44 state waiting for data
2020-06-10 11:27:13 testresult 0
devices:
HASH(0x5bae310)
HASH(0x5bb26b8)
HASH(0x5bb54b0)
HASH(0x5bba6b8)
HASH(0x5bbf7c8)
HASH(0x26919c8)
HASH(0x5bb6400)
HASH(0x5bb2718)
HASH(0x5ba0500)
HASH(0x5ba0ea8)
HASH(0x53f98a8)
HASH(0x2761608)
HASH(0x5b56dc0)
HASH(0x5b57138)
HASH(0x14d4940)
HASH(0x2691680)
HASH(0x55523f0)
HASH(0x5bb63a0)
HASH(0x54b4480)
HASH(0x5bac590)
HASH(0x251dfe8)
groups:
HASH(0x5040f40)
HASH(0x5bb0260)
HASH(0x43fb798)
HASH(0x5bb9070)
HASH(0x5b56e08)
HASH(0x5bb97e0)
helper:
io:
CUL_868:
raw Z0B10000203B7D01330120000
rssi -22
time 1591781264.4284
Attributes:
event-on-change-reading .*
icon wuerfel
room System
stateFormat dutycycle
Auch dieser ist oft im Status "waiting for data". Komisch finde ich auch, dass ich hier zwei Internals mit CULMAX0 sehen kann.
Und hier der Log-Auszug eines Fensterkontakts:
2020-06-10_10:12:55 Arbeit_Fenster waiting for data
2020-06-10_10:12:56 Arbeit_Fenster closed
2020-06-10_10:22:58 Arbeit_Fenster waiting for data
2020-06-10_10:23:00 Arbeit_Fenster closed
2020-06-10_10:26:00 Arbeit_Fenster RSSI: -70
2020-06-10_10:33:02 Arbeit_Fenster waiting for data
2020-06-10_10:33:04 Arbeit_Fenster closed
2020-06-10_10:43:06 Arbeit_Fenster waiting for data
2020-06-10_10:43:07 Arbeit_Fenster closed
2020-06-10_10:53:09 Arbeit_Fenster waiting for data
2020-06-10_10:53:11 Arbeit_Fenster closed
2020-06-10_11:03:13 Arbeit_Fenster waiting for data
2020-06-10_11:03:16 Arbeit_Fenster closed
2020-06-10_11:07:11 Arbeit_Fenster waiting for data
2020-06-10_11:07:11 Arbeit_Fenster closed
2020-06-10_11:17:12 Arbeit_Fenster waiting for data
2020-06-10_11:17:12 Arbeit_Fenster closed
2020-06-10_11:27:13 Arbeit_Fenster waiting for data
2020-06-10_11:27:14 Arbeit_Fenster closed
Das Zeitintervall passt oft mit den 10 Minuten zu meinem Update-Intervall des MAXLAN. Aber früher kam das nicht.
Aber nicht immer
2020-06-09_21:08:43 Souterrain_Fenster_links waiting for data
2020-06-09_21:08:44 Souterrain_Fenster_links closed
2020-06-09_21:18:46 Souterrain_Fenster_links waiting for data
2020-06-09_21:18:47 Souterrain_Fenster_links closed
2020-06-09_21:28:49 Souterrain_Fenster_links waiting for data
2020-06-09_21:28:50 Souterrain_Fenster_links closed
2020-06-09_21:33:11 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:13 Souterrain_Fenster_links closed
2020-06-09_21:33:18 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:19 Souterrain_Fenster_links closed
2020-06-09_21:33:23 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:24 Souterrain_Fenster_links closed
2020-06-09_21:33:29 Souterrain_Fenster_links waiting for data
2020-06-09_21:33:30 Souterrain_Fenster_links closed
Werden mehr Angaben gebraucht? Hat jemand eine Idee?
Vielen Dank
Zitat von: Wzut am 27 Mai 2020, 11:48:22
das sieht aus als ob Cube und CUL sich gegenseitig state überschreiben.
Poste doch bitte mal ein List von deinem CUL , dem CUL_MAX Device und einem beliebigen FK.
CUL
Internals:
CMDS ABCEeFfGiKlMNRTtUVWXxYZ
CUL_868_MSGCNT 2023
CUL_868_TIME 2020-06-10 17:42:41
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400
FD 41
FHTID 0000
FUUID 5c822521-f33f-98e0-51bb-c6112116609df5ed
NAME CUL_868
NR 132
NR_CMD_LAST_H 2
PARTIAL
RAWMSG Z0E5D0202020E100A031F00011800271D
RSSI -59.5
STATE Initialized
TYPE CUL
VERSION V 1.26.04 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-06-10 11:06:59 cmds A B C E e F f G i K l M N R T t U V W X x Y Z
2020-06-08 11:25:06 credit10ms 3011
2020-05-12 10:19:33 raw No answer
2020-06-10 17:42:41 state Initialized
2020-05-12 14:10:07 version V 1.26.04 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
XMIT_TIME:
1591780031.386
1591780033.89654
Attributes:
icon cul_868
rfmode MAX
room System
CUL_MAX
Internals:
CUL_868_MSGCNT 2029
CUL_868_RAWMSG Z0EB2020202066E02A4A40001180022
CUL_868_RSSI -62
CUL_868_TIME 2020-06-10 17:43:50
DEF 123456
FUUID 5c822527-f33f-98e0-5073-77706678a1d47e8e
IODev CUL_868
LASTInputDev CUL_868
MSGCNT 2029
NAME CULMAX0
NR 167
STATE CUL_868:ok
SVN 21994
TYPE CUL_MAX
addr 123456
cnt 0
pairmode 0
retryCount 0
sq 0
READINGS:
2020-06-04 16:22:12 packetsLost 31
2020-06-10 17:43:50 state CUL_868:ok
sendQueue:
Attributes:
IODev CUL_868
event-on-change-reading .*
fakeSCaddr 222222
fakeWTaddr 111111
icon cul_max
room System
Arbeitszimmerfenster
Internals:
CULMAX0_MSGCNT 13
CULMAX0_TIME 2020-06-10 17:26:00
DEF ShutterContact 00532b
FUUID 5c82251d-f33f-98e0-7089-3fa019224cf5a900
IODev ml
LASTInputDev ml
MSGCNT 238
NAME Arbeit_Fenster
NR 30
NTFY_ORDER 50-Arbeit_Fenster
STATE closed
SVN 22023
TYPE MAX
addr 00532b
devtype 4
ml_MSGCNT 225
ml_TIME 2020-06-10 17:41:22
type ShutterContact
READINGS:
2020-06-10 17:41:22 MAXLAN_error 0
2020-06-10 17:41:22 MAXLAN_errorInCommand
2020-06-10 17:41:22 MAXLAN_initialized 1
2020-06-10 17:41:22 MAXLAN_isAnswer 0
2020-06-10 17:41:22 MAXLAN_valid 1
2020-06-10 17:26:00 RSSI -72.5
2020-06-10 17:41:22 SerialNr IEQ0154690
2020-06-10 17:41:22 battery ok
2020-06-10 17:41:22 batteryState ok
2020-06-10 17:41:22 firmware 1.3
2020-06-08 10:59:05 groupid 2
2020-06-10 17:41:22 onoff 0
2020-06-10 17:41:22 peerIDs 026283,029fa7,03b7d0
2020-06-10 17:41:22 peerList Arbeit_Thermo,Arbeit_WandThermo,ml
2020-06-10 17:41:22 rferror 0
2020-06-10 17:41:22 state closed
2020-06-10 17:41:22 testresult 15
2020-06-10 17:41:22 windowOpen 0
helper:
io:
CUL_868:
raw Z0B1C063000532B03B7D00010
rssi -72.5
time 1591802760.42519
Attributes:
IODev ml
event-on-change-reading .*
genericDeviceType ContactSensor
icon fts_window_1w
model ShutterContact
room Arbeitszimmer,Homekit
also das list des CULMAX sieht schon mal komisch aus , da stehen Readings die da einfach nichts zu suchen haben.
Du betreibst MAXLAN und CUL_MAX parallel aber unter verschiedenen Ids :
MAXLAN : 03b7d0
CUL_MAX : 123456
CUL : maxid nicht gesetzt
In der Theorie hat nun CUL_MAX bei Paketen von/nach 03b7d0 keine Ahnung das diese von/für seinem "Bruder" MAXLAN sind und behandelt sie wie von einem unbekannten MAX Gerät. ( das müsste man auch schön in einem verbose 5 Log des CUL_MAX sehen )
Ich würde an deiner Stelle drei Dinge versuchen (bitte einzeln nicht gleich alle zusammen !) :
a. trage die 03b7d0 beim CUL_MAX im Attribut blacklist ein.
b. gib dem CUL_MAX Device beim define die 03b7d0 mit statt der 123456 und setze am CUL Device das Attribut maxid auch auf 03b7d0
c. leg ein neues MAX Device vom Typ Cube mit der Adresse 03b7d0 an.
define myCube MAX Cube 03b7d0
Bei Variante a. wird alles was direkt an 03b7d0 geht oder von 03b7d0 kommt von CULMAX als "fremd" verworfen, sollte kein Problem sein wenn deine FKs mit einem HT oder WT assoziert sind, da dann der FK seinen Status direkt um HT/WT schickt und die ID 03b7d0 nicht im Telegramm auftaucht.
Ich kann frühestens Mitte Juli bei mir das Ganze mal so nachstellen und testen.
@jhohmann, hast du dich mal gefragt wie es kommt das dein CUL weniger als 3600 Credits zur Verfügung hat ?
Wenn ich dich bis jetzt richtig verstanden habe soll dein CUL nur mithören aber nicht aktiv senden, aber das tut er sonst hätte er immer seine max Credits.
U.a könnte ich wetten versucht er alle paar Stunden deinen HT & WTs die aktuelle Uhrzeit zu senden.
Und dazu natürlich noch die Ketzerfrage : Wieso benutzt du überhaupt noch den Cube mit MAXLAN wenn du doch schon einen CUL hast ?
Erstmal vielen Dank für die schnellen Rückmeldungen zu meinem Problem.
A) habe ich ausprobiert und es hat bei den Fensterkontakten zu keiner Änderung geführt.
B) konnte ich über die WEB GUI nicht einpflegen. Hier kam die Meldung, dass die Adresse schon vergeben ist.
Ich werde B) Anfang nächster Woche noch auf andere Wege versuchen, reinzubekommen und dann auch mal C) ausprobieren.
Zu der ketzerischen Frage: Ich habe im Forum schon gelesen, dass man einfach umsteigen können soll, indem man den MAXLAN rauswirft und auch vom Netz nimmt.
Das habe ich ausprobiert und prompt hat FHEM nicht sofort auf "Fenster ist auf" oder "zu" reagiert, ich musste warten. In Kombination MAXLAN und CUL_MAX kommt die Reaktion sofort (das kann aber an der falschen Adresse am CUL_MAX liegen. Aber ich meine, dass hätte ich auch schon mal probiert und durch ein rückgespieltes Backup wieder verloren).
Der zweite Grund, warum ich nicht umsteige, ist mein Heizungseinstellungsprogramm:
https://forum.fhem.de/index.php/topic,92704.0.html (https://forum.fhem.de/index.php/topic,92704.0.html) Damit kann ich für mich sehr einfach das Profil ändern. Wie ich das mit dem Weekprofile und unter Einhaltung der Credits sauber hinbekomme, muss ich mir anschauen, wenn das Problem der schlechteren Reaktion auf "Fenster auf" behoben ist.
Und als Randbemerkung: Ich scheine nicht mehr alleine zu sein ;) https://forum.fhem.de/index.php/topic,112021.0.html (https://forum.fhem.de/index.php/topic,112021.0.html)
Ich melde mich dann Anfang kommender Woche wieder.
Zum Thema Blacklist :
das wundert mich nun schon. Klarheit kann da wohl nur ein verbose 5 Log des CUL_MAX und des FKs bringen.
zu B : ja das geht z.Z. nur mittels löschen des CUL_MAX Device und gleich wieder neu anlegen, aber heb dir das noch etwas auf.
Variante c hast du nicht probiert ?
Das mit dem weekprofil sollte gehen, da es inzwischen so schlau ist nur den Tag zu übertragen der sich geändert hat statt stur wie früher wegen einer Temperatur das komplette Wochenprogramm zu schreiben. Und ja Änderungen am Wochenprofil sind nicht billig, auch die ELV Software zeigt einem irgendwann nur noch die drehenden Zahnräder wenn zuviel auf einmal machen will.
Edit :
Traust du dir zu eine Zeile in 10_MAX.pm zu ändern ?
In Zeile 1921 steht :
# Build state READING
my $state = "waiting for data";
dies ändern in :
# Build state READING
my $state = ReadingsVal($name, 'state', 'waiting for data');
danach noch ein reload 10_MAX oder FHEM Neustart.
Ich glaube jetzt es ist nicht der CUL_MAX der für den Wechsel sorgt sondern MAXLAN.
Hallo Wzut
Habe gerade die vermutliche Lösung ausprobiert und 10_MAX.pm angepasst.
# Build state READING
my $state = ReadingsVal($name, 'state', 'waiting for data');
Das Verhalten hat sich wie folgt geändert.
Jetzt generiert jeder Poll ..
- Für jeden Fensterkontakt ein ein opened und ein closed Event
- Für jedes andere MAX Device (Radiator, Thermometer) einen opened Event
Meine Notfys werden pausenlos aufgerufen. Ich habe den Change wieder Rückgängig gemacht.
sorry , da war ich geistig bei meiner aktuellen Test Version !
richtig wäre bei euch :
my $state = ReadingsVal($shash->{NAME}, 'state', 'waiting for data');
ich check das heute ein, es ist dann morgen ab 8:00 Uhr via update verfügbar.
Bitte auch die 14_CUL_MAX updaten, da habe ich auch noch einen Tippfehler gefunden.
Ok, werde updaten sobald verfügbar.
Update funktioniert ausgezeichnet :)
Bei mir sieht es nach dem Update auch gut aus.
Wobei ich jetzt meine Notifys und Prüfungen auf onoff stehen lasse.
Wenn das state ein Mischzustand ist (teilweise kommt da manchmal auch ein rf error mit dran), scheint mir das der bessere Weg zu sein.
Auch das mit den ReadingsNum("Wohn_Fenster", "onoff", undef) habe ich auf einen sinnvollen Default Wert korrigiert.
Mein CULMAX Device habe ich gelöscht und mit meiner MAXLAN Adresse neu definiert. Nur das ohne das Update der Module hatte aber nicht gereicht.
Jetzt werde ich mein System weiter beobachten und prüfen, ob ich irgendwann mal auf mein MAXLAN ganz verzichten kann/will.
Vielen Dank für die Unterstützung :D
beim testen gestern mit MAXLAN und CUL_MAX Tandem ist mir noch eine Besonderheit aufgefallen :
Wenn die CUL_MAX Adresse (bsp 123456) ungleich der MAXLAN Adresse ist erkennt CUL_MAX die Telegramme des CUBE als normales MAX Device.
Das ist u.A. der Grund warum komische Readings im MAXLAN Device auftauchen können und man kein Dummy MAX Device mit der Adresse anlegen kann.
Hier werde ich nochmal nacharbeiten müssen, damit CUL_MAX den Cube als Bruder des CUL erkennt.
Hallo jhohmann
Basieren Deine Notify's auf den onoff Events. Wie hast Du diese definiert?
Ich habe es gestern versucht, aber nicht hinbekommen :(
Gruss, birdy
dann zeig doch mal was du gemacht hast und event-on-change-reading hast auch angepasst ?
Auf die schnelle, bin gerade nicht am Rechner.
defmod ntArbeitFenster notify Arbeit_Fenster:onoff:..* {
my $state=ReadingsNum("Arbeit_Fenster", "onoff", 0);
}
Geht bestimmt auch eleganter, aber für mich hat es gereicht :)
Zitat von: Wzut am 14 Juni 2020, 17:51:44
dann zeig doch mal was du gemacht hast und event-on-change-reading hast auch angepasst ?
event-on-change-reading habe ich beim ShutterContact mit .* definiert
Die notify's hatte ich wie vorgeschlagen defniert :
DEFMOD <name> notify .*:onoff:1 {winOpenStart($NAME)}
DEFMOD <name> notify .*:onoff:0 {winOpenStop($NAME)}
onoff:.1 bzw. onoff:.0 , der Punkt vor der Zahl macht den Unterschied
Zitat von: Wzut am 15 Juni 2020, 12:46:00
onoff:.1 bzw. onoff:.0 , der Punkt vor der Zahl macht den Unterschied
Ja so funktioniert es. Ein kleiner aber feiner Unterschied. :D
Wzut was ist nun Deine Empfehlung. Auf was soll der Notify idealerweise reagieren onoff oder opened / cosed?
Vielen Dafür Deine Unterstützung.
Gruss, birdy
ich dachte eigentlich das sei klar : onoff kann nur 1 oder 0 sein, state dagegen kann noch Zusätze haben wie den rferror.
D.h. um state sauber zu verarbeiten musst du wesentlich mehr Aufwand treiben wie das simple 0/1 beim onoff.
Zitat von: Wzut am 16 Juni 2020, 09:20:00
ich dachte eigentlich das sei klar : onoff kann nur 1 oder 0 sein, state dagegen kann noch Zusätze haben wie den rferror.
D.h. um state sauber zu verarbeiten musst du wesentlich mehr Aufwand treiben wie das simple 0/1 beim onoff.
Falls der State einen rferror enthält, kann man dann trotzdem davon ausgehen, dass bei onoff ein zuverlässiger Wert geliefert wird?
Hallo Wzut,
vielen Dank für die viele Arbeit an den MAX-Modulen. Du hattest vor einiger Zeit mal ein "virtualThermostat" erwähnt, das wohl noch nicht ganz reif war.
Gibt's da schon etwas neues? Ich würde liebend gerne meine FKs mit einem virtuellem Thermostat koppeln (associate), damit sie ihre Meldung nicht nur einmalig als Broadcast schicken. Bisher habe ich dafür noch keine Lösung gefunden. Die Meldung der FKs geht bei mir nicht 1:1 an die Thermostate, so dass ich die nicht direkt koppeln kann.
Auch wenn es um die MAX Module scheinbar ruhig geworden ist : Ich habe die Corona Kurzarbeitszeit nicht verschlafen sondern wirklich viel programmiert.
Das betrifft alle Module die von mir betreut werden, da wir im Frühjahr hier einigen Wirbel hatten zum Thema Perl Programmierung und unsere Module im FHEM Umfeld.
Anyway, der User merkt davon nichts, aber intern hat sich der Code doch stark verändert. Dabei besteht natürlich immer die Gefahr das Funktionen die vorher einwandfrei liefen nun plötzlich neue Macken zeigen wo bisher keine waren. Ich denke es wird wieder Zeit für eine neue Beta Runde bevor ich das alles wieder via Update auf euch loslasse ( bei mir laufen sie schon seit Juni auf dem Live System )
Das Thema virtuelles Wandthermostat habe ich dabei nicht so intensiv weiter verfolgt, u.a. war ich mir halt auch unsicher ob es wirklich Bedraf dafür gibt.
Aber mal Hand aufs Herz : Was versprichst du dir vom Einsatz eines vWT ? Nur damit die FKs Unicast Telegramme verschicken ? Ich sehe da keinen wirklichen Vorteil, denn autark sind sie damit ja immer noch nicht sondern nach wie vor von einem laufendem FHEM abhängig. Die eigentliche Idee für ein vWT war aber etwas komplexer, aber deine einfache Anforderung solle das was ich bis jetzt habe erfüllen.
Hallo Wzut,
das sind ja super Neuigkeiten :)
Ich habe immer wieder aber nicht extrem häufig das Problem, dass die Broadcast-Telegramme "nicht ankommen". Die RSSI bei korrekt empfangenen Nachrichten ist okay, vermutlich handelt es sich also um kurzzeitige Störungen auf dem Funkkanal. Mit einem SDR-Empfänger habe ich gelegentlich mal ein breitbandiges Signal gesehen, vielleicht hat also ein Nachbar einen alten Funkkopfhörer...
Mein Ziel für das associate sind also retries bei ausbleibendem Ack von FHEM und/oder zumindest die stündliche Wiederholung des Status. Letzteres könnte ich auch mit einem "im Schrank liegenden" WT schaffen, aber ersteres geht nur, wenn ich den FK mit FHEM verbinden kann. Die ganzen zusätzlichen Funktionen eines echten, virtuellen Thermostats würde ich also nicht nutzen wollen.
Mahlzeit,
schön zu hören, daß Du hier die Weiterentwicklung vorantreibst 8) Gerne bin ich mit dabei beim Testen.
Viele Grüße Rainer
Beim Beta-Testen bin ich auch dabei.
Meine Heizperiode fängt langsam aber bereits an.
Bin gerade dabei den virtualShutterContact für meine Secusignal Fenstergriffe einzurichten. Eins klappt schon, beim zweiten habe ich noch ein Problem mit dem Attribut für den externen Sensor. Ich kann doch mehrere externe Sensoren verwenden? Da muss ich noch mal Testen...
Meine Frage bezieht sich aber auf die Möglichkeit einer Reaktionsverzögerung bei Fenster offen. Es macht einfach keinen Sinn, dass das Thermostat sofort losrennt, wenn man den Griff betätigt, insbesondere bei Terrassen- oder Balkontüren. Da lässt sich doch sicher eine Verzögerung bei der Statusübernahme einbauen...
Ich glaube nicht, dass nur mich das stört... und ein Dummy dazwischenschalten ist vielleicht ein Workaround, aber nicht sehr elegant.
Danke
Zitat von: Dr. Ulfi am 18 Oktober 2020, 17:38:12
Ich kann doch mehrere externe Sensoren verwenden?
IMHO nein, das müsste ich intern etwas ändern damit das mit den durchgreichten Events funktioniert, habe das aber jetzt nicht probiert.
Das Thema mit der Zeitverzögerung kommt auch immer wieder mal hoch, jetzt nicht explizit bei MAX sondern generell bei der Kombi FK und HT.
Bei direkt gepeerten Geräten (MAX, HM) hat man da aus Modul Sicht gar keine Chance bremsend einzugreifen.
Sicher bei dem viruellen könnte man Vor und Nachlaufzeiten einbauen.
Allerdings muss man das auch irgendwie anzeigen, z.B. beim state -> open / open wait / close / close wait oder gleich als Countdown ala close 0:10
D.h. für den User muss ersichtlich sein ob die offen Meldung da ist und ob sie bereits weitergegeben wurde.
Meinugen / Vorschläge zur Umsetzung ?
Theoretisch kann man auch die MAX-FKs ja auch als virtuelle FKs definieren. Dann sollte man eine wait_time_open und eine wait_time_close definieren können. Ein Countdown ist m.M. nicht notwendig, aber ein Status 'open / close wait xx sek.' wäre sicher von Vorteil.
Zitat von: Dr. Ulfi am 18 Oktober 2020, 17:38:12
Ich kann doch mehrere externe Sensoren verwenden? Da muss ich noch mal Testen...
---snipp ---
Da lässt sich doch sicher eine Verzögerung bei der Statusübernahme einbauen...
a. ich habe da eine Zeitlang hin und her überlegt und werde keine Unterstützung für mehrere externe Sensoren gleichzeitig einbauen.
Grund : wenn mehr als ein externer Sensor vorhanden ist muß auch eine und/oder Logik eingebaut werden wie diese auszuwerten sind.
Das möchte ich mir ersparen und empfehle in so einem Fall die externen Kontakte in eine Structure zu packen und dort die Logik zu definieren.
Die Structure kann dann der der externe Sensor für den vSC sein.
b. Das habe ich jetzt mit zwei neuen Attributen delay_open und delay_close umgesetzt die nur der vSC hat.
Verzögerungszeit ist in Sekunden anzugeben (default 0)
Die neue Version des 10_MAX Moduls werde ich heute Abend im Thread
Neue Beta Test Runde für alle MAX Module -> https://forum.fhem.de/index.php/topic,115018.0.html zur Verfügung stellen.
Top !
a) macht Sinn, eine 1 zu 1 Beziehung ist immer das unkomplizierteste.
b) dann werde ich das ab morgen mal testen.
Danke
Listing:
Internals:
DEF virtualShutterContact abc111
FUUID 5f8c4aec-f33f-8ee8-462d-b5cefbe88505d711
IODev CULMAX
NAME vTuerkontakt_MAX_abc111
NOTIFYDEV Terasse_Tuergriff
NR 358
NTFY_ORDER 50-vTuerkontakt_MAX_abc111
STATE closed
SVN BETA
TYPE MAX
addr abc111
devtype 6
type virtualShutterContact
READINGS:
2020-10-24 19:56:09 error invalid or missing value for READING groupid
2020-10-24 19:56:09 groupid 0
2020-10-24 20:31:56 msgcnt 102
2020-10-24 20:31:56 onoff 0
2020-10-24 20:31:56 state closed
2020-10-24 20:33:33 windowOpen 0
Attributes:
IODev CULMAX
comment Configured using template MAX_ShutterContact_dark
debug 1
delay_close 40
delay_open 20
devStateIcon closed:fts_door_right opened:fts_door_right_open
event-on-change-reading .*
externalSensor Terasse_Tuergriff:state:(open.*|til.*|offen):(close.*|zu)
icon hm-sec-win
model virtualShutterContact
room MAX
userattr delay_close delay_open
und log:
2020-10-24 20:29:53 at at_open_vTuerkontakt_MAX_abc111 Next: 20:30:33
2020-10-24 20:29:53 Global global DEFINED at_open_vTuerkontakt_MAX_abc111
2020-10-24 20:30:33 MAX vTuerkontakt_MAX_abc111 onoff: 1
2020-10-24 20:30:33 MAX vTuerkontakt_MAX_abc111 opened
2020-10-24 20:30:33 MAX vTuerkontakt_MAX_abc111 windowOpen: 00:00
2020-10-24 20:31:16 at at_close_vTuerkontakt_MAX_abc111 Next: 20:31:56
2020-10-24 20:31:16 Global global DEFINED at_close_vTuerkontakt_MAX_abc111
2020-10-24 20:31:33 MAX vTuerkontakt_MAX_abc111 windowOpen: 00:01
2020-10-24 20:31:56 MAX vTuerkontakt_MAX_abc111 onoff: 0
2020-10-24 20:31:56 MAX vTuerkontakt_MAX_abc111 closed
2020-10-24 20:31:56 MAX vTuerkontakt_MAX_abc111 windowOpen: 0
Eigentlich hatte ich unterschiedliche delay-Zeiten eingestellt und erwartet, es hat aber bei open und close immer eine Verzögerung von 40 sek. gegeben.
ja saublöder copy & paste Fehler. Ich tausche heute Abend die Datei aus.
Bei der Gelegenheit habe ich auch die ats gegeneinander verriegelt, d.h. falls ein at_close angelegt wird und es noch ein at_open gibt wird dieses gelöscht und vice versa.
Bei deiner Def ist mir noch aufgefallen : (open.*|til.*|offen):(close.*|zu)
Welche Events erzeugt denn Terasse_Tuergriff nun wirklich ?
Ggf. mal den vSC auf verbose 5 stellen.
Dann werde ich morgen die Dateien herunterladen und testen
Meine MAX Fensterkontakte liefern "closed" und "opened" und die Türgriffe selbst
"closed", "open", "tilted" und "open_from_tilted"
dan wäre doch (open.*|til.*):close.* völlig ausreichend wenn die deutschen Bezeichnungen nicht im Event vorkommen.
Ich werde diese Optimierung einbauen, Danke
(sind historisch gewachsene Altlasten über die man sich keine Gedanken macht, so lange es funktioniert)
Jetzt klappt es mit den Verzögerungszeiten :) prima