Wie ich bereits in einem anderen Thread schrieb :
Ich habe die letzten Monate alle drei MAX Module intern stark umgebaut. Viel Neues ist dabei für euch User leider nicht enstanden, aber bevor ich diese Versionen auf die breite Masse via update loslasse würde ich mich wieder über leidensfähige Tester freuen :)
ich habe zwar bei mir viel getestet und nutze diese Versionen auch selbst auf meinem Live System, aber ..... :)
Wenn möglich möchte ich auch an den bisherigen SVN Versionen keine Änderungen / Erweiterungen mehr vornehmen sondern diese hier als zukünftige Basis nehmen.
Versionen:
00_MAXLAN.pm -> ??.??.????
10_MAX.pm -> 14.01.2024
14_CUL_MAX.pm -> 17.03.2024
Installiert.
Bisher keine Auffälligkeiten.
Danke
ebenfalls installiert
keine Probleme
Bei diese Gelegenheit noch eine Bitte : schaut mal nach dem set saveConfig Kommando, ich habe hier das Problem in einem anderen Thread das sich FHEM bendet mit der Fehlermeldung das main::Logdir nicht gefunden wurde. Erklären kann ich es mir noch nicht da Logdir() eine interne Funktion von fhem.pl ist.
Kann jemand Deassociate fakeWT probieren?
Im Log bekomme ich:
Zitat2020.10.18 19:08:44.386 1: UG_BU_Thermostat, invalid command/argument 81190018
2020.10.18 19:09:08.634 1: UG_KU_Thermostat, invalid command/argument 8119572C
2020.10.18 19:09:35.868 1: UG_SZ_Thermostat, invalid command/argument 81194B2C
2020.10.18 19:09:48.796 1: UG_WZ_Thermostat, invalid command/argument 81190018
Beim Associate von HT zu fakeWT kommt im Log:
Zitat2020.10.18 14:40:19.673 3: cm, target device 111111 has no name !
2020.10.18 14:40:19.673 3: CM_Parse, unhandled message WakeUp from UG_KU_Thermostat to MAX_111111, groupid : 0 , payload : 03 - ignoring !
THX4Info, werd ich mir im Laufe der Woche nochmal genau anschauen
Zitat von: Wzut am 18 Oktober 2020, 13:06:04
Bei diese Gelegenheit noch eine Bitte : schaut mal nach dem set saveConfig Kommando, ich habe hier das Problem in einem anderen Thread das sich FHEM bendet mit der Fehlermeldung das main::Logdir nicht gefunden wurde. Erklären kann ich es mir noch nicht da Logdir() eine interne Funktion von fhem.pl ist.
Save all:
2020.10.18 19:56:23.027 1: ERROR evaluating { MAX_Save('all') }: Undefined subroutine &main::MAX_Save called at (eval 39018) line 1.
set UG_WZ_Thermostat saveConfig:
2020.10.18 19:57:43.528 3: UG_WZ_Thermostat, configSaved to ./log/UG_WZ_Thermostat.max
set UG_WZ_Thermostat saveConfig test:
2020.10.18 19:55:41.743 3: UG_WZ_Thermostat, configSaved to ./log/test.max
main::Logdir kann ich daher nicht bestätigen
Zitat von: Jam2 am 18 Oktober 2020, 20:01:22
ERROR evaluating { MAX_Save('all') }
ja da hat sich inzwischen die Syntax geändert :
{ FHEM::MAX::MAX_Save() }und das Thema Logdir() ist inzwischen auch geklärt : Die Funktion kam erst im Frühjahr in fhem.pl.
überschreibt eigentlich ein update von FHEM die Beta?
na klar, wenn man es verhindern will -> attr global exlude_from_update
Wie im anderen Thread bereits angekündigt habe ich das 10_MAX Modul im ersten Beitrag ausgetauscht.
Neu : beim Typ virtualShutterContact gibt es zwei neue Attribute : delay_open & delay_close , Wert ist in Sekunden anzugeben, default 0
Sind die Attribute gesetzt wird nach Empfang des externen Sensors die Information nicht direkt zum HT weitergegeben sondern um den jeweiligen Wert verzögert.
Im state Reading steht dann zusätzlich zum aktuellen Status (waiting)
Die Wartezeit läuft nicht im Modul intern sondern über ein temporäres at das im gleichen Raum wie der vSC liegt.
14_CUL_MAX habe ich auch ausgetauscht, da durch die delays auch eine Änderung nötig war.
Zitat von: Jam2 am 18 Oktober 2020, 19:18:42
Kann jemand Deassociate fakeWT probieren?
Wurde bei mir in der aktuellen Beta mit FHEM Stop quittiert :(
Habe das jetzt gefixt und habe mehrfach das fakeWT assoziert und deassoziert , klappt jedesmal ohne Fehler.
Versuche ich allerdings ein deassociate obwohl der fakeWT gar nicht mehr als Peer im HT hinterlegt ist quttiert das HT das mit einem NACK.
Da allerdings intern das NACK wie ein ACK behandelt wird erzeugt das die Meldungen mit invalid command/argument 81xxxxx
Ich muss mal schauen da ich jetzt ja diese NACKs gewollt erzeugen kann an der Stelle das Logging noch etwas klarer zu gestalten,
betrifft aber jetzt wirklich nur den Text im Logfile nicht die eigentliche Funktion.
Ich teste es nächste Woche gleich mal.
Ich warte aktuell noch auf einen zusätzlichen CUL... Ich habe aktuell ein komisches Phänomen, welches meine Credits frisst.
CUL0 ist im EG - "weit entfernt" von UG-HTs
CUL1 ist im UG - direkt an UG-HTs
CUL1 bekommt aber von den UG-HTs keine(bzw. sehr wenige) ACK - diese werden mit Glück teilweise noch von CUL0 empfangen.
CUL1/CUL0 tauschen hat nicht geholfen. Ich prüfe mal direkt am CUL ob die ACK doch kommen und nicht an FHEM weitergeleitet werden.
Zitat von: Jam2 am 25 Oktober 2020, 21:52:25
Ich habe aktuell ein komisches Phänomen
Bei Multi IOs Lösungen muss man genauer hinschauen. maxid an beiden CULs gesetzt ?
Beide CULs als IOgrp am cm Device eingetragen ?
am UG-HTs das Attribut CULdev auf den CUL mit den besten RSSI Werten gesetzt ?
eine Bitte an alle die das Beta 14_CUL_MAX Modul nutzen :
Lasst euch mal in FHEMWEB ein list von eurem CUL_MAX Device ausgeben und schaut ob es bei den Internals einen Abschnit CHANGED gibt.
Bei mir steht da über 20 Mal der state des Gerätes. Bevor ich mir nun anderweitig Hilfe hole möchte ich sicherstellen das dies bei mir kein Einzelfall ist.
Kein Einzelfall
Ich hab dort 78x "cul868:ok" stehen. Wobei cul868 der Name meines IO Devices ist.
Mein Setup besteht aus einem Cul (Cube umgeflasht), 4x HT UND 1x SC
OK, danke für die Rückmeldung, dann muss ich hier unbedingt nachbessern und heute Abend eine geänderte Version bereitstellen !
Ich habe gestern Abend die 14_CUL_MAX im ersten Beitrag ausgetauscht,
bitte unbedingt nachziehen die CHANGED Einträge im cm Device wachsen sonst ewig ...
Ich habe mich die letzten Tage wieder mal mit dem Thema IO Gruppe und bester CUL für das Device beschäftigt.
Um die Entscheidung welcher CUL aus der IO Gruppe des cm der "bessere" ist leichter zu machen habe ich intern eine mini Statistik eingebaut die die letzten 10 RSSI Werte berücksichtigt. Anzeige mit zwei neuen Readings , Bsp :
2020-11-04 19:18:02 CUL1st CUL -43
2020-11-04 19:18:02 CUL2nd CUL2 -83
Bedeutet : Bei mir ist der CUL mit einem Durchschnitt von -43 besser als CUL2 mit -83 im Durchschnitt.
Also sollte ich CULdev an diesem Device auf CUL setzen, das nimmt mir jetzt das Modul ab und ändert selbst das Attribut.
Aber nur dann wenn der "Bessere" mindest 2db im Schnitt besser ist um ein ständiges hin und her zu vermeiden falls beide in etwa gleich gut/schlecht sind.
Wer diesen Automatismus nicht haben möchte kann ihn mit dem neuen Attribut autoselectCUL = 0 abschalten.
Die Berechnung der Readings CUL1st & CUL2nd ist davon nicht betroffen.
Bis die neuen Readings sichbar werden dauert es etwas, da zuerst mindestens 5 Werte vorliegen müssen.
edit:
Mir ist heute ein 1/3 CUL ausgefallen (Netzteil Raspberry defekt). Nicht nur der ausgefallene CUL hat nicht mehr funktioniert, kein CUL hat mehr etwas gesendet oder empfangen.
Ist das gewollt?
edit2:
Mit der neuen Beta hatte ich gerade bei allen Nachrichten und allen Thermostaten missingack (autoselectCUL = 0).
Ich teste morgen nochmals
Natürlich darf in einer Gruppe mal ein Teilnehmer ausfallen, die anderen können davon nichts wissen.
Wenn du überall missings ACKs hast dann ist IMHO dein erstes Problem noch aktuell -> kein CUL Empfang
Allerdings sehe ich da keinen Zusammenhang mit den MAX Modulen, egal ob alt oder Beta Version.
Sorry, meine Nachricht war anscheinend nicht verständlich.
Zum ersten Thema: Hier haben die anderen CUL keine weiteren Telegrame mehr versendet und die Queue ist gewachsen. Ich hatte bisher kein sendpool definiert - ggf. lag es an dem.
Zum zweiten Thema:
Komischerweise hatte ich sobald ich auf die neue Beta gewechselt habe eine massive Zunahme von missingack. Was natürlich wenig Sinn macht - das hat sich heute wieder bestätigt.
Trotzdem lag es natürlich an etwas anderem - ein Wandthermostat mit leeren Batterien (https://www.youtube.com/watch?v=ZR2VQ460duk)
Die neue Beta läuft soweit gut. Fakewt assoc funktioniert wie erwartet.
Zitat von: Jam2 am 07 November 2020, 17:24:04
Ich hatte bisher kein sendpool definiert
--snipp ---
ein Wandthermostat mit leeren Batterien (https://www.youtube.com/watch?v=ZR2VQ460duk)
a. einen sendpool brauchst du nicht, viel wichtiger wäre eine Antwort auf meine Fragen vom 26 Oktober 2020, 06:58:27 gewesen.
Multi IO ist nicht trivial , läuft aber bei mir sehr gut wenn man alles richtig macht.
b. ahhh ein Babbling Idiot -> https://de.wikipedia.org/wiki/Babbling_idiot
HomeMatic hat da auch so seine Probleme -> https://asksinpp.de/Grundlagen/FAQ/babbling_idiot.html
Ich selbst habe da mal zwei Tage mit meiner LaCrosse Welt gekämpft wo ein defekter Sensor alles lahm gelegt hat.
Also kann man MAX da mit einreihen und sollte das Problem im Hinterkopf behalten.
Wäre halt ein Traum wenn das tolle HM Teil auch MAX könnte -> https://github.com/jp112sdl/AskSinAnalyzer/wiki
Gibt es schon einen Plan, wann das Beta freigegeben werden soll?
wenn keine dicken Brocken mehr dazukommen : nach dem 10. Dezember 2020 , da habe ich wieder mehr Zeit.
ich installiere dann mal die Beta, Rückmeldung folgt
wollte einfach mal schnell Danke für die Integration von delay_open und delay_close sagen! Einfach SPITZE! Habe gerade die Beta installiert funktioniert 1A!
Hallo Zusammen,
kann nun doch noch ein komisches Verhalten feststellen. Habe eine Türe mit einem delay_open = 15 ausgestattet.
Wenn ich nun die Türe öffne und innerhalb der 15 Sekunden wieder schließe. Passiert der Reihe nach folgendes:
Türe auf: Sensor merkt Tür auf - vSC geht erst auf opened dann auf opened (waiting)
Türe zu: Sensor merkt Türe zu - vSC geht auf closed
dann 15 Sekunden nach Türe auf, geht der vSC auf opened und bleibt dort, der Sensor bleibt closed, der Thermostat schaltet auf Fenster offen und bleibt dort.
damit wird also das at ausgeführt und bleibt erhalten, obwohl die Türe ja schon wieder zu ist... sollte da das at nicht gelöscht werden? oder der vSC anhand des Sensors merken, dass schon wieder zu ist?
Ich hatte da am 25 Oktober nachgebessert :
Zitat von: Wzut am 25 Oktober 2020, 08:21:19
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.
leg doch mal ein close_delay von 1 Sekunde an und schaue ob das at dann gelöscht wird ( ich kann im Moment nicht testen )
Ja, wenn ich ein delay_close = 1 dazu aktiviere klappt's, das delay_open at wird gelöscht.
Wieder zurück bei delay_close = 0 gehts wieder nicht... das delay_open at wird ausgeführt.
Ok, dann hatte ich das noch richtig im Hinterkopf das ich das Gegenat mit Gewalt lösche, habe aber den Umstand nicht bedacht das es nicht zwingend beide delays geben muß.
Ich habe das löschen des gegen ats jetzt aus der Klammer genommen.
Aktulle Version im ersten Post.
Sind die Module inzwischen bereits ins normale Update integriert? ;-)
Nein, ich war vor zwei Wochen der Meinung fertig zu sein, dann kam das 12 °C ( Temperatursturz Erkennung ) des fakeWT dazwischen.
Ist zwar kein Fehler der Beta Version, aber ich hatte die Hoffnung das gleich mit erschlagen zu können ( habe ich vermutlich jetzt auch )
Offen ist nach wie vor das Thema der WakeUp Telgramme, das werde ich aber vermutich so schnell nicht lösen können.
Alles klar, danke für Deine tolle unermütlicheArbeit an den Modulen!
Ich lies mal mit
Eigentlich sah mein Plan vor die neuen Version Ende Januar einzuchecken, aber welcher Rentner hat schon Zeit ....
Ok, dachte ich warten wir bis die Heizperiode zu Ende ist dann tut es nicht zanz so weh wenn es noch an der einen oder anderen Ecke klemmt.
Tja und dann taucht ein neuer User im Anfängerforum auf und behauptet es wäre möglich die Ventilstellung und aktuelle Temperatur eines HT auszulesen !
Ohha, das wäre doch noch eine schöne Ergänzung der Beta Module, würde das direkte auslesen dieser Werte den von mir nicht gemochten MAX Scanner bei einem CUL doch völlig überfüssig machen.
Vor etwas über einer Woche gab es dann etwas mehr Infos zu diesem Thema -> https://forum.fhem.de/index.php/topic,119766.0.html
Heute kann ich nun sagen , 10_MAX hat ein paar neue Set Kommndos bekommen :
set <name> getStatus - bringt ein HT dazu seine aktuelle Temperatur und Ventilstellung an FHEM zu senden
set <name> getConfigValve - das HT sendet die interenen Parameter boostValveposition,maxValveSetting, valveOffset und decalcification
set <name> getConfigTemperatures - HT/WT senden ihre interenen Parameter maxTemp, min Temp usw.
und was mich besonders freut :
set <name> getConfigWeekProfile - damit ist es nund endlich möglich das aktuelle Wochenprofil von HTs& WTs auszulesen :)
Könnte sein das damit der eine oder andere ein bisher nicht gefundenes 17 Grad Problem auf die Spur kommt, so hatte ich bei einem HT einen nicht korrekten Temperatur Eintrag an einem Wochentag im Profil.
Wichtig : bitte unbedingt die 14_CUL_MAX auch austauschen damit die neuen Kommandos funktionieren !
Ich habe die Beta versuchsweise am laufen. Bisher keine Auffälligkeiten.
Mit den neue get Funktionen ist der Max-Scanner wirklich entbehrlich. Funktioniert
mit einem at alle 30min bestens!
teste jetzt seit 04.04. und bisher nichts negatives aufgefallen.. ! TOP
Bin auch mal auf die Beta umgestiegen und habe den Scanner durch at abgelöst.
läuft zwar noch nicht all zu lange aber bis jetzt ohne erkennbare Probleme ;)
Könntet ihr mir bitte mal das at-Kommando Schreiben/erklären?
Ab heute Nacht läuft das Log-File voll. Das sind nicht meine Geräte. Soviele neue Geräte kann ich mir hier
auch nicht vorstellen.
Ich habe CUL_MAX erstmal auf verbose 0 gesetzt.
2021.04.07 02:00:19 2: MAXCUL, unknown message type 0C from MAX_bc0442 [bc0442] to MAX_090aed [bc0442] - ignoring !
2021.04.07 02:00:19 2: MAXCUL, unknown message type 81 from MAX_099353 [099353] to MAX_079179 [099353] - ignoring !
2021.04.07 02:00:25 2: MAXCUL, unknown message type 18 from MAX_001800 [001800] to MAX_af2a89 [001800] - ignoring !
2021.04.07 02:00:25 3: MAXCUL, device [011800] UNKNOWN MAX_011800 want to be re-paired to [34810c] MAX_34810c, not to us [ 05cf48 ] - ignoring !
2021.04.07 02:01:22 2: MAXCUL, unknown message type 8C from MAX_0a625b [0a625b] to MAX_0018b4 [0a625b] - ignoring !
2021.04.07 02:01:22 2: MAXCUL, unknown message type 89 from MAX_08a16d [08a16d] to MAX_0018db [08a16d] - ignoring !
2021.04.07 02:01:41 2: MAXCUL, unknown message type 9A from MAX_0c83ad [0c83ad] to MAX_0018cb [0c83ad] - ignoring !
2021.04.07 02:01:41 2: MAXCUL, unknown message type 89 from MAX_08a16d [08a16d] to MAX_0018db [08a16d] - ignoring !
2021.04.07 02:02:17 2: MAXCUL, unknown message type 9A from MAX_0c83ad [0c83ad] to MAX_0018cb [0c83ad] - ignoring !
2021.04.07 02:02:17 2: MAXCUL, unknown message type 79 from MAX_099334 [099334] to MAX_0026cd [099334] - ignoring !
2021.04.07 02:29:54 2: MAXCUL, unknown message type 0C from MAX_840442 [840442] to MAX_079b89 [840442] - ignoring !
2021.04.07 02:29:54 2: MAXCUL, unknown message type 87 from MAX_044209 [044209] to MAX_078c08 [044209] - ignoring !
2021.04.07 02:30:12 2: MAXCUL, unknown message type 18 from MAX_001800 [001800] to MAX_ae2b89 [001800] - ignoring !
2021.04.07 02:30:42 2: MAXCUL, unknown message type 09 from MAX_119a0c [119a0c] to MAX_83ad00 [119a0c] - ignoring !
2021.04.07 02:30:42 2: MAXCUL, unknown message type 07 from MAX_917909 [917909] to MAX_933400 [917909] - ignoring !
2021.04.07 02:31:42 3: MAXCUL, device [18c419] UNKNOWN MAX_18c419 want to be re-paired to [890ec7] MAX_890ec7, not to us [ 05cf48 ] - ignoring !
2021.04.07 02:31:59 2: MAXCUL, unknown message type 0A from MAX_ed0001 [ed0001] to MAX_180018 [ed0001] - ignoring !
2021.04.07 02:31:59 2: MAXCUL, unknown message type 07 from MAX_8c0001 [8c0001] to MAX_180018 [8c0001] - ignoring !
2021.04.07 02:32:56 3: MAXCUL, could not handle message PairPong from device [180018] MAX_180018 to [0f8d0c] MAX_0f8d0c - ignoring !
2021.04.07 02:33:40 2: MAXCUL, unknown message type 07 from MAX_870c9c [870c9c] to MAX_044207 [870c9c] - ignoring !
2021.04.07 02:36:55 2: MAXCUL, unknown message type 04 from MAX_580305 [580305] to MAX_cf4800 [580305] - ignoring !
2021.04.07 02:37:23 2: MAXCUL, unknown message type 0A from MAX_626700 [626700] to MAX_18c419 [626700] - ignoring !
2021.04.07 02:37:23 2: MAXCUL, unknown message type 09 from MAX_0aed00 [0aed00] to MAX_011800 [0aed00] - ignoring !
2021.04.07 02:37:34 2: MAXCUL, unknown message type 08 from MAX_a16d00 [a16d00] to MAX_18b204 [a16d00] - ignoring !
2021.04.07 02:38:37 2: MAXCUL, unknown message type 89 from MAX_08a179 [08a179] to MAX_0018d9 [08a179] - ignoring !
2021.04.07 02:38:37 2: MAXCUL, unknown message type A1 from MAX_79079b [79079b] to MAX_890001 [79079b] - ignoring !
2021.04.07 02:38:45 2: MAXCUL, unknown message type 83 from MAX_7f0911 [7f0911] to MAX_9a0001 [7f0911] - ignoring !
2021.04.07 02:39:25 2: MAXCUL, unknown message type 0C from MAX_9e0442 [9e0442] to MAX_079179 [9e0442] - ignoring !
2021.04.07 02:55:08 2: MAXCUL, unknown message type 89 from MAX_0a6267 [0a6267] to MAX_090aed [0a6267] - ignoring !
2021.04.07 02:55:08 2: MAXCUL, unknown message type 8A from MAX_09078c [09078c] to MAX_08a16d [09078c] - ignoring !
2021.04.07 02:55:13 2: MAXCUL, unknown message type 77 from MAX_0b1a8b [0b1a8b] to MAX_05cf48 [0b1a8b] - ignoring !
2021.04.07 02:55:18 2: MAXCUL, unknown message type 77 from MAX_101a8a [101a8a] to MAX_0a6267 [101a8a] - ignoring !
2021.04.07 02:55:47 2: MAXCUL, unknown message type 8A from MAX_0a6267 [0a6267] to MAX_090aed [0a6267] - ignoring !
2021.04.07 02:55:47 2: MAXCUL, unknown message type 8C from MAX_090aed [090aed] to MAX_05cf48 [090aed] - ignoring !
2021.04.07 02:55:50 3: MAXCUBE: Unknown code Z0F6E0503090AED05CF48001507027710, help me!
2021.04.07 02:56:11 2: MAXCUL, unknown message type 89 from MAX_090aed [090aed] to MAX_05cf48 [090aed] - ignoring !
2021.04.07 02:56:13 2: MAXCUL, Send Queue missing ack from MAX_090aed for TimeInformation, removing from queue
2021.04.07 02:56:14 2: MAXCUL, unknown message type 89 from MAX_090aed [090aed] to MAX_05cf48 [090aed] - ignoring !
2021.04.07 02:56:21 2: MAXCUL, unknown message type 89 from MAX_090aed [090aed] to MAX_05cf48 [090aed] - ignoring !
2021.04.07 02:56:27 2: MAXCUL, unknown message type 89 from MAX_090aed [090aed] to MAX_05cf48 [090aed] - ignoring !
2021.04.07 02:56:36 2: MAXCUL, Send Queue missing ack from MAX_090aed for TimeInformation, removing from queue
2021.04.07 02:59:48 2: MAXCUL, unknown message type AE from MAX_2a88ad [2a88ad] to MAX_09119a [2a88ad] - ignoring !
2021.04.07 03:00:21 2: MAXCUL, unknown message type 89 from MAX_079179 [079179] to MAX_099334 [079179] - ignoring !
2021.04.07 03:00:21 2: MAXCUL, unknown message type 18 from MAX_358b34 [358b34] to MAX_079179 [358b34] - ignoring !
2021.04.07 03:30:16 2: MAXCUL, unknown message type 0C from MAX_990442 [990442] to MAX_079b89 [990442] - ignoring !
2021.04.07 03:30:16 2: MAXCUL, unknown message type 8B from MAX_044209 [044209] to MAX_078c08 [044209] - ignoring !
2021.04.07 03:30:26 2: MAXCUL, unknown message type 18 from MAX_001800 [001800] to MAX_ad2a88 [001800] - ignoring !
2021.04.07 03:31:01 2: MAXCUL, unknown message type 09 from MAX_119a0c [119a0c] to MAX_837f00 [119a0c] - ignoring !
2021.04.07 03:31:01 2: MAXCUL, unknown message type 07 from MAX_917909 [917909] to MAX_935300 [917909] - ignoring !
2021.04.07 03:31:59 2: MAXCUL, unknown message type 09 from MAX_0aed0a [0aed0a] to MAX_626700 [0aed0a] - ignoring !
2021.04.07 03:31:59 2: MAXCUL, unknown message type 07 from MAX_917909 [917909] to MAX_935300 [917909] - ignoring !
2021.04.07 03:32:15 2: MAXCUL, unknown message type 09 from MAX_0aed0a [0aed0a] to MAX_626700 [0aed0a] - ignoring !
2021.04.07 03:32:15 2: MAXCUL, unknown message type 09 from MAX_078c0a [078c0a] to MAX_620300 [078c0a] - ignoring !
2021.04.07 03:33:14 2: MAXCUL, unknown message type D7 from MAX_09890e [09890e] to MAX_9a0202 [09890e] - ignoring !
2021.04.07 03:33:15 2: MAXCUL, unknown message type C6 from MAX_23840e [23840e] to MAX_750202 [23840e] - ignoring !
2021.04.07 03:33:47 2: MAXCUL, unknown message type 0E from MAX_b10202 [b10202] to MAX_099334 [b10202] - ignoring !
2021.04.07 03:34:48 2: MAXCUL, unknown message type 88 from MAX_23840e [23840e] to MAX_750202 [23840e] - ignoring !
2021.04.07 03:34:48 2: MAXCUL, unknown message type 34 from MAX_26c6f0 [26c6f0] to MAX_8c0eb1 [26c6f0] - ignoring !
2021.04.07 03:35:09 3: MAXCUL, device [18c288] UNKNOWN MAX_18c288 want to be re-paired to [0edd02] MAX_0edd02, not to us [ 05cf48 ] - ignoring !
2021.04.07 03:35:09 2: MAXCUL, unknown message type ED from MAX_000118 [000118] to MAX_001834 [000118] - ignoring !
2021.04.07 03:35:55 2: MAXCUL, unknown message type 8C from MAX_000118 [000118] to MAX_0018ef [000118] - ignoring !
2021.04.07 03:35:55 2: MAXCUL, unknown message type 89 from MAX_000118 [000118] to MAX_001810 [000118] - ignoring !
2021.04.07 03:35:59 2: MAXCUL, unknown message type 8C from MAX_000118 [000118] to MAX_0018ef [000118] - ignoring !
2021.04.07 03:35:59 2: MAXCUL, unknown message type 89 from MAX_000118 [000118] to MAX_001810 [000118] - ignoring !
2021.04.07 03:36:39 2: MAXCUL, unknown message type 9A from MAX_000118 [000118] to MAX_001808 [000118] - ignoring !
2021.04.07 03:36:46 3: MAXCUL, device [26c6c6] UNKNOWN MAX_26c6c6 want to be re-paired to [f08a00] MAX_f08a00, not to us [ 05cf48 ] - ignoring !
2021.04.07 03:36:46 2: MAXCUL, unknown message type 09 from MAX_119a00 [119a00] to MAX_011800 [119a00] - ignoring !
2021.04.07 03:37:33 2: MAXCUL, unknown message type 0C from MAX_b20442 [b20442] to MAX_079179 [b20442] - ignoring !
2021.04.07 03:37:59 2: MAXCUL, unknown message type B0 from MAX_b00588 [b00588] to MAX_0626e9 [b00588] - ignoring !
2021.04.07 03:38:40 2: MAXCUL, unknown message type 18 from MAX_871a88 [871a88] to MAX_0ede02 [871a88] - ignoring !
2021.04.07 03:38:56 2: MAXCUL, unknown message type 09 from MAX_078c08 [078c08] to MAX_a16d00 [078c08] - ignoring !
2021.04.07 03:38:56 2: MAXCUL, unknown message type 08 from MAX_a16d07 [a16d07] to MAX_9b8900 [a16d07] - ignoring !
2021.04.07 03:39:41 2: MAXCUL, unknown message type 0C from MAX_83ad09 [83ad09] to MAX_119a00 [83ad09] - ignoring !
2021.04.07 03:39:41 2: MAXCUL, unknown message type 09 from MAX_933407 [933407] to MAX_917900 [933407] - ignoring !
2021.04.07 03:40:30 2: MAXCUL, unknown message type 09 from MAX_0aed0a [0aed0a] to MAX_626700 [0aed0a] - ignoring !
2021.04.07 03:40:30 2: MAXCUL, unknown message type 07 from MAX_917909 [917909] to MAX_933400 [917909] - ignoring !
2021.04.07 03:40:45 2: MAXCUL, unknown message type 09 from MAX_0aed0a [0aed0a] to MAX_626700 [0aed0a] - ignoring !
2021.04.07 03:40:46 2: MAXCUL, unknown message type 09 from MAX_078c0a [078c0a] to MAX_620300 [078c0a] - ignoring !
2021.04.07 03:41:37 2: MAXCUL, unknown message type 79 from MAX_0018d7 [0018d7] to MAX_088a0e [0018d7] - ignoring !
2021.04.07 03:41:50 3: MAXCUL, could not handle message PairPong from device [180018] MAX_180018 to [0f8b0c] MAX_0f8b0c - ignoring !
2021.04.07 03:42:32 2: MAXCUL, unknown message type 9A from MAX_000118 [000118] to MAX_001806 [000118] - ignoring !
2021.04.07 03:42:32 2: MAXCUL, unknown message type 91 from MAX_000119 [000119] to MAX_060626 [000119] - ignoring !
2021.04.07 03:43:23 2: MAXCUL, unknown message type 09 from MAX_119a00 [119a00] to MAX_011800 [119a00] - ignoring !
2021.04.07 03:43:45 2: MAXCUL, unknown message type 07 from MAX_000118 [000118] to MAX_000018 [000118] - ignoring !
2021.04.07 03:44:40 2: MAXCUL, unknown message type 9B from MAX_890001 [890001] to MAX_180018 [890001] - ignoring !
2021.04.07 03:45:20 2: MAXCUL, unknown message type 91 from MAX_099334 [099334] to MAX_002626 [099334] - ignoring !
2021.04.07 03:46:13 3: MAXCUL, device [00c21a] UNKNOWN MAX_00c21a want to be re-paired to [891586] MAX_891586, not to us [ 05cf48 ] - ignoring !
2021.04.07 03:46:13 3: MAX_Parse, got message WallThermostatControl for undefined device 079109 type WallMountedThermostat , autocreate is enabled
2021.04.07 03:46:13 2: autocreate: define MAX_079109 MAX WallMountedThermostat 079109
2021.04.07 03:46:13 3: MAX_079109, invalid or missing value for READING groupid , forcing to 0
2021.04.07 03:46:40 2: MAXCUL, unknown message type 09 from MAX_933407 [933407] to MAX_917900 [933407] - ignoring !
2021.04.07 03:47:19 3: MAXCUL, device [011800] UNKNOWN MAX_011800 want to be re-paired to [18358b] MAX_18358b, not to us [ 05cf48 ] - ignoring !
2021.04.07 03:48:04 2: MAXCUL, unknown message type 09 from MAX_530026 [530026] to MAX_26c5ef [530026] - ignoring !
2021.04.07 03:49:00 2: MAXCUL, unknown message type 89 from MAX_00180e [00180e] to MAX_8b0c7a [00180e] - ignoring !
2021.04.07 03:49:00 3: MAXCUL, could not handle message PairPong from device [000018] MAX_000018 to [348ac4] MAX_348ac4 - ignoring !
2021.04.07 03:50:05 2: MAXCUL, unknown message type 04 from MAX_079b89 [079b89] to MAX_08a16d [079b89] - ignoring !
2021.04.07 03:50:05 2: MAXCUL, unknown message type 9E from MAX_044209 [044209] to MAX_078c0a [044209] - ignoring !
2021.04.07 03:50:24 2: MAXCUL, unknown message type A0 from MAX_04079b [04079b] to MAX_8908a1 [04079b] - ignoring !
2021.04.07 03:51:00 2: MAXCUL, unknown message type 7B from MAX_02020c [02020c] to MAX_83ad09 [02020c] - ignoring !
2021.04.07 03:51:59 2: MAXCUL, unknown message type B7 from MAX_020209 [020209] to MAX_933407 [020209] - ignoring !
2021.04.07 03:51:59 2: MAXCUL, unknown message type E3 from MAX_02020a [02020a] to MAX_626709 [02020a] - ignoring !
2021.04.07 03:53:04 2: MAXCUL, unknown message type 09 from MAX_078c00 [078c00] to MAX_011800 [078c00] - ignoring !
2021.04.07 04:29:48 3: MAX_Parse, got message ThermostatState for undefined device 0f0000 type HeatingThermostat , autocreate is enabled
2021.04.07 04:29:48 2: autocreate: define MAX_0f0000 MAX HeatingThermostat 0f0000
2021.04.07 04:29:48 3: MAX_0f0000, invalid or missing value for READING groupid , forcing to 0
2021.04.07 05:00:39 2: MAXCUL, unknown message type CF from MAX_020209 [020209] to MAX_933407 [020209] - ignoring !
2021.04.07 05:00:39 2: MAXCUL, unknown message type FB from MAX_02020a [02020a] to MAX_626709 [02020a] - ignoring !
2021.04.07 05:00:59 2: MAXCUL, unknown message type 18 from MAX_af0487 [af0487] to MAX_87880e [af0487] - ignoring !
2021.04.07 05:00:59 2: MAXCUL, unknown message type 67 from MAX_0018c0 [0018c0] to MAX_18880e [0018c0] - ignoring !
2021.04.07 05:01:52 3: MAXCUL, device [18af04] UNKNOWN MAX_18af04 want to be re-paired to [870eb7] MAX_870eb7, not to us [ 05cf48 ] - ignoring !
2021.04.07 05:01:52 3: MAXCUL, device [011800] UNKNOWN MAX_011800 want to be re-paired to [18ed88] MAX_18ed88, not to us [ 05cf48 ] - ignoring !
2021.04.07 05:02:06 2: MAXCUL, unknown message type D6 from MAX_05890e [05890e] to MAX_b90202 [05890e] - ignoring !
2021.04.07 05:02:37 2: MAXCUL, unknown message type C1 from MAX_22830e [22830e] to MAX_940202 [22830e] - ignoring !
2021.04.07 05:02:38 2: MAXCUL, unknown message type C4 from MAX_f38b0e [f38b0e] to MAX_d00202 [f38b0e] - ignoring !
2021.04.07 05:02:40 2: MAXCUL, unknown message type 07 from MAX_054227 [054227] to MAX_068902 [054227] - ignoring !
2021.04.07 05:02:40 2: MAXCUL, unknown message type C4 from MAX_f38b0e [f38b0e] to MAX_d00202 [f38b0e] - ignoring !
2021.04.07 05:02:40 2: MAXCUL, unknown message type 07 from MAX_054227 [054227] to MAX_06890f [054227] - ignoring !
2021.04.07 05:02:41 2: MAXCUL, unknown message type 9B from MAX_890001 [890001] to MAX_180018 [890001] - ignoring !
2021.04.07 05:59:48 3: MAXCUL, device [006006] UNKNOWN MAX_006006 want to be re-paired to [836105] MAX_836105, not to us [ 05cf48 ] - ignoring !
2021.04.07 06:00:17 2: MAXCUL, unknown message type 35 from MAX_047007 [047007] to MAX_9b8900 [047007] - ignoring !
2021.04.07 06:00:57 3: MAX_Parse, message for undefined device 044209 and failed to guess devicetype from msg ConfigWeekProfile - ignoring !
2021.04.07 06:00:59 2: MAXCUL, unknown message type CC from MAX_044209 [044209] to MAX_078c0a [044209] - ignoring !
2021.04.07 06:00:59 2: MAXCUL, unknown message type 19 from MAX_890c10 [890c10] to MAX_044209 [890c10] - ignoring !
2021.04.07 06:02:00 2: MAXCUL, unknown message type 04 from MAX_420907 [420907] to MAX_8c0a62 [420907] - ignoring !
2021.04.07 06:02:06 3: MAX_Parse, message for undefined device 8b8bcc and failed to guess devicetype from msg ConfigWeekProfile - ignoring !
2021.04.07 06:02:08 2: MAXCUL, unknown message type 89 from MAX_0ece02 [0ece02] to MAX_0208a1 [0ece02] - ignoring !
2021.04.07 06:02:08 2: MAXCUL, unknown message type D6 from MAX_108b0c [108b0c] to MAX_a90442 [108b0c] - ignoring !
2021.04.07 06:02:40 2: MAXCUL, unknown message type 9A from MAX_000118 [000118] to MAX_00181c [000118] - ignoring !
2021.04.07 06:02:40 2: MAXCUL, unknown message type 89 from MAX_08a179 [08a179] to MAX_001507 [08a179] - ignoring !
2021.04.07 06:02:40 2: MAXCUL, unknown message type 9A from MAX_000118 [000118] to MAX_00181c [000118] - ignoring !
2021.04.07 06:02:41 2: MAXCUL, unknown message type 07 from MAX_064228 [064228] to MAX_06890e [064228] - ignoring !
2021.04.07 06:02:42 2: MAXCUL, unknown message type 6D from MAX_001507 [001507] to MAX_064228 [001507] - ignoring !
2021.04.07 06:30:43 2: MAXCUL, unknown message type B0 from MAX_03860c [03860c] to MAX_d80442 [03860c] - ignoring !
2021.04.07 06:30:43 3: MAXCUL, device [be3589] UNKNOWN MAX_be3589 want to be re-paired to [890000] MAX_890000, not to us [ 05cf48 ] - ignoring !
2021.04.07 06:30:49 2: MAXCUL, unknown message type 1C from MAX_878786 [878786] to MAX_0cd804 [878786] - ignoring !
2021.04.07 06:30:57 3: MAXCUL, device [00000d] UNKNOWN MAX_00000d want to be re-paired to [2700be] MAX_2700be, not to us [ 05cf48 ] - ignoring !
2021.04.07 06:32:11 2: MAXCUL, unknown message type 18 from MAX_0d2735 [0d2735] to MAX_888819 [0d2735] - ignoring !
2021.04.07 06:32:43 2: MAXCUL, unknown message type 79 from MAX_000119 [000119] to MAX_0b26fd [000119] - ignoring !
2021.04.07 06:32:45 3: MAXCUL, could not handle message PairPong from device [180d27] MAX_180d27 to [35880f] MAX_35880f - ignoring !
2021.04.07 06:32:45 2: MAXCUL, unknown message type 67 from MAX_000000 [000000] to MAX_00180d [000000] - ignoring !
2021.04.07 06:33:32 3: MAXCUL, device [011800] UNKNOWN MAX_011800 want to be re-paired to [18f188] MAX_18f188, not to us [ 05cf48 ] - ignoring !
2021.04.07 06:33:34 2: MAXCUL, unknown message type D7 from MAX_04890e [04890e] to MAX_d90202 [04890e] - ignoring !
2021.04.07 07:00:34 3: MAXCUL, device [a72a87] UNKNOWN MAX_a72a87 want to be re-paired to [0cf904] MAX_0cf904, not to us [ 05cf48 ] - ignoring !
2021.04.07 07:00:57 2: MAXCUL, unknown message type 91 from MAX_790001 [790001] to MAX_190b26 [790001] - ignoring !
2021.04.07 07:01:00 3: MAXCUL, could not handle message SetGroupId from device [840fcc] MAX_840fcc to [047009] MAX_047009 - ignoring !
2021.04.07 07:01:24 2: MAXCUL, unknown message type C4 from MAX_19870e [19870e] to MAX_250202 [19870e] - ignoring !
2021.04.07 07:01:24 2: MAXCUL, unknown message type B0 from MAX_04870e [04870e] to MAX_e10202 [04870e] - ignoring !
2021.04.07 07:02:02 2: MAXCUL, unknown message type 0F from MAX_0c0460 [0c0460] to MAX_0c83ad [0c0460] - ignoring !
2021.04.07 07:02:02 2: MAXCUL, unknown message type 8A from MAX_0ee302 [0ee302] to MAX_0208a1 [0ee302] - ignoring !
2021.04.07 07:02:08 3: MAXCUL, device [b2d69b] UNKNOWN MAX_b2d69b want to be re-paired to [9b600c] MAX_9b600c, not to us [ 05cf48 ] - ignoring !
2021.04.07 07:02:19 2: MAXCUL, unknown message type A1 from MAX_79002d [79002d] to MAX_dd078a [79002d] - ignoring !
2021.04.07 07:02:19 2: MAXCUL, unknown message type 06 from MAX_000000 [000000] to MAX_00000d [000000] - ignoring !
A. Bitte solche monster in code tags setzen. Ich war so frei den post zu edieren sonst waere er unlesbar fuer mich gewesen!
B. Das schaut aus als waere der cul voellig nben der spur oder etwas stoert massiv den emempfang
Das gesamte MAX-Systen funktioniert ohne Probleme. Senden und Empfang ist normal. Ich logge Temparaturen der Räume mit.
Von daher alles in Ordnung. Ich hatte bisher solche Log-Einträge noch nie.
Seit die Beta am Laufen ist, wurden auch 4 neue MAX-HT/WT per autocreate vollständig neu angelegt. Auch das gab es vorher
noch nicht. Die habe ich auf ignore gesetzt. Ist ja nicht weit schlimm. Ich schau mal mit verbose 2.
Zitat von: Taipan am 07 April 2021, 16:00:41
Könntet ihr mir bitte mal das at-Kommando Schreiben/erklären?
ich habe es damit gemacht
define at_ht_wz at +*00:10:00 set MAX_0dc446 getStatusdamit wird alle 10 minuten vom gerät MAX_0dc446 der Status abgefragt.
ggf. wäre es sinnvoller nur temperatur und valve abzufragen aber ich habe es erstmal so gelöst
@benkler
Danke!
Ich habe den CULMAX nochmal über Nacht auf verbose3 gesetzt.
14 neue MAX-Geräte angelegt. Da scheint in der Nachbarschaft ein neues Max-System in Betrieb zu sein.
Also alles gut mit den BETA.
Das glaube ich nicht. Um die antworten der neuen getConfig befehle zu empfangen musste ich den vorfilter etwas lockern. Ich vermute nun kommenbei dir teile durch diebisher geblockt wurden. Mein tipp : autocreate disable und den unuetzen mist loeschen ub culmax runter auf verbose 2
Ich bin total begeistert von den Fortschritten, die Wzut hier erzielt hat, und überaus dankbar für deine Pflege und Weiterentwicklung des MAX! Systems.
Trotzdem sei die Frage erlaubt, warum die neuen GET-Kommandos als FHEM-Set ausgeführt sind und nicht als FHEM-Get.
Alex
Die Frage hatte ich mir früher bei Homematic auch schon gestellt ( z.B. set getConfig)
Die Antwort ist relativ simpel :
FHEMWEB erwartet vom Modul bei Ausführung eines GET Kommandos eine Rückgabe die diekt zum User durchgereicht wird und i.d.R. als Popup angezeigt wird.
Bei Ausfühung eines Set Kommandos wird im Erfolgsfall nichts zurückgegeben, bzw. wenn es eine Rückgabe gibt wird sie als Fehler angesehen.
Bei den getConfig Kommandos ist es nun so das zuerst ein Kommando abgefeuert wird, es aber vom Device keine direkte postive/negative Rückmeldung gibt, sondern irgendwann kommt eine Antwort (oder auch nicht) auf die Anfrage.
Bei allen bisherigen set Kommandos reagiert das MAX Device da etwas anderes, zu jedem SET xy Telegramm gibt es ein passendes ACK xy.
Zitat von: Wzut am 29 Dezember 2020, 07:43:31
Nein, ich war vor zwei Wochen der Meinung fertig zu sein, dann kam das 12 °C ( Temperatursturz Erkennung ) des fakeWT dazwischen.
Ist zwar kein Fehler der Beta Version, aber ich hatte die Hoffnung das gleich mit erschlagen zu können ( habe ich vermutlich jetzt auch )
Offen ist nach wie vor das Thema der WakeUp Telgramme, das werde ich aber vermutich so schnell nicht lösen können.
So ein bisschen fühle ich mich ja verantwortlich, dass die Module später eingecheckt werden als ursprünglich geplant. ;)
Seit kurzem habe ich nun auch endlich die neueste Beta-Version im Einsatz und bisher funktioniert alles bestens. Die fakeWTs hatte ich nach dem letzten Posting erst mal deaktiviert, da die WakeUp-Telegramme meine Credits "fraßen" und die SendQueue voll gelaufen ist. Dies ist nun nicht mehr der Fall und ich habe stabil mehr als 3000 Credits bei vier per fakeWT gesteuerten Thermostaten. :)
Danke für die gute Arbeit.
nachdem ich heute nacht auch das MAX System eines Nachbarn bei mir im Fhem hatte tauchen die IDs der geräte nun in der peerlist eines HTs auf und das verhält sich etwas seltsam (siehe screenshot eigentlich durchgehend 5°C).
Ich habe mal Autocreate deaktiviert und die fremden Devices gelöscht.
Meine Fensterkontakte funken scheinbar auch nicht mehr richtig an den CUL aber an die WTs und HTs melden Sie sauber zurück
hier noch ein List des HT aus dem Screenshot
Internals:
.FhemMetaInternals 1
.count -109
.sendToAddr -1
.sendToName
.testbit 0
.timer 300
DEF HeatingThermostat 1ab4fb
FUUID 5c48893b-f33f-5212-2d05-9a9a34c36ee5cb81
IODev cul_MAX
LASTInputDev cul_MAX
MSGCNT 30
NAME MAX_1ab4fb
NOTIFYDEV global
NR 375
NTFY_ORDER 50-MAX_1ab4fb
STATE 5.0
SVN BETA_28032021
TYPE MAX
TimeSlot -1
addr 1ab4fb
cul_MAX_MSGCNT 30
cul_MAX_TIME 2021-04-09 07:15:29
devtype 1
type HeatingThermostat
.attraggr:
.attreour:
.*
.attrminint:
Helper:
DBLOG:
desiredTemperature:
DbLog:
TIME 1617945329.4133
VALUE 5.0
temperature:
DbLog:
TIME 1617943607.81932
VALUE 9.6
valveposition:
DbLog:
TIME 1617945329.4133
VALUE 0
READINGS:
2021-04-09 06:06:47 .associatedWith Broadcast,MAX_070fe9,MAX_07c30c,MAX_07c30f
2021-04-09 07:15:29 .lastact 1617945329
2021-04-07 08:25:13 .weekProfile 1448151015131520152015204520452045204520452045204520144815101513152015201520452045204520452045204520452014481510151315201520152045204520452045204520452045201448151015131520152015204520452045204520452045204520144815101513152015201520452045204520452045204520452014481510151315201520152045204520452045204520452045201448151015131520152015204520452045204520452045204520
2021-01-13 19:58:43 .wp_json {"Sat":{"time":["06:00","22:40","22:55","24:00"],"temp":["5","5","5","5"]},"Sun":{"time":["06:00","22:40","22:55","24:00"],"temp":["5","5","5","5"]},"Mon":{"time":["06:00","22:40","22:55","24:00"],"temp":["5","5","5","5"]},"Tue":{"time":["06:00","22:40","22:55","24:00"],"temp":["5","5","5","5"]},"Wed":{"time":["06:00","22:40","22:55","24:00"],"temp":["5","5","5","5"]},"Thu":{"time":["06:00","22:40","22:55","24:00"],"temp":["5","5","5","5"]},"Fri":{"time":["06:00","22:40","22:55","24:00"],"temp":["5","5","5","5"]}}
2021-03-17 17:56:15 MAXLAN_error 0
2021-03-17 17:56:15 MAXLAN_errorInCommand
2021-03-17 17:56:15 MAXLAN_initialized 1
2021-03-17 17:56:15 MAXLAN_isAnswer 0
2021-03-17 17:56:15 MAXLAN_valid 1
2021-04-09 07:15:29 RSSI -67.5
2021-03-16 21:51:54 SerialNr OEQ1952148
2021-04-09 07:15:29 battery ok
2021-04-09 07:15:29 batteryState ok
2021-03-16 21:51:54 boostDuration 5
2021-03-16 21:51:54 boostValveposition 80
2021-04-07 08:18:08 comfortTemperature 21.0
2021-03-16 21:51:54 decalcification Sat 12:00
2021-04-09 07:15:29 desired-temp 5.0
2021-04-09 07:15:29 desiredTemperature 5.0
2021-04-09 06:46:47 deviation -42.9
2021-04-07 08:18:08 ecoTemperature 17.0
2021-03-16 21:51:54 firmware 1.1
2021-04-09 07:15:29 gateway 1
2020-08-01 16:21:48 groupid 4
2021-01-13 19:58:43 lastConfigSave ./log/MAX_1ab4fb.max
2021-04-07 05:53:40 lastTimeSync 2021-04-07 05:53:40
2021-04-09 07:14:30 lastcmd desiredTemperature auto
2021-03-16 21:51:54 maxValveSetting 100
2021-04-07 08:18:08 maximumTemperature 30.5
2021-04-07 08:18:08 measurementOffset 0.0
2021-04-07 08:18:08 minimumTemperature 4.5
2021-04-09 07:15:29 mode auto
2021-04-09 07:26:45 msgcnt 113
2021-01-13 21:44:20 none_lost 4
2021-01-21 16:10:55 none_retry 13
2021-04-09 07:15:29 panel unlocked
2021-04-09 06:06:47 peerIDs 000000,070fe9,07c30c,07c30f
2021-04-09 06:06:47 peerList Broadcast,MAX_070fe9,MAX_07c30c,MAX_07c30f
2021-04-09 07:15:29 rferror 0
2021-04-09 07:15:29 state 5.0
2021-04-09 06:46:47 temperature 9.6
2021-03-16 21:51:54 testresult 161
2021-03-16 21:51:54 valveOffset 0
2021-04-09 07:15:29 valveposition 0
2021-04-07 08:25:13 weekprofile-0-Sat-temp 5.0 °C / 5.0 °C / 5.0 °C / 5.0 °C
2021-04-07 08:25:13 weekprofile-0-Sat-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-04-07 08:25:13 weekprofile-1-Sun-temp 5.0 °C / 5.0 °C / 5.0 °C / 5.0 °C
2021-04-07 08:25:13 weekprofile-1-Sun-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-04-07 08:25:13 weekprofile-2-Mon-temp 5.0 °C / 5.0 °C / 5.0 °C / 5.0 °C
2021-04-07 08:25:13 weekprofile-2-Mon-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-04-07 08:25:13 weekprofile-3-Tue-temp 5.0 °C / 5.0 °C / 5.0 °C / 5.0 °C
2021-04-07 08:25:13 weekprofile-3-Tue-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-04-07 08:25:13 weekprofile-4-Wed-temp 5.0 °C / 5.0 °C / 5.0 °C / 5.0 °C
2021-04-07 08:25:13 weekprofile-4-Wed-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-04-07 08:25:13 weekprofile-5-Thu-temp 5.0 °C / 5.0 °C / 5.0 °C / 5.0 °C
2021-04-07 08:25:13 weekprofile-5-Thu-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-04-07 08:25:13 weekprofile-6-Fri-temp 5.0 °C / 5.0 °C / 5.0 °C / 5.0 °C
2021-04-07 08:25:13 weekprofile-6-Fri-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-04-07 08:18:08 windowOpenDuration 15
2021-04-07 08:18:08 windowOpenTemperature 12.0
helper:
io:
nanoCul868:
raw Z0E6D02021AB4FB07C3E1000118000A
rssi -67.5
time 1617945329.41214
Attributes:
IODev cul_MAX
alexaName Heizung Büro
alias Heizung Büro
appOptions {
"template": "thermostat",
"dashboard": "true"
}
event-on-update-reading .*
group Heizung
icon hc_wht_regler
model HeatingThermostat
room Büro,MAX->Geräte,Homekit
scanTemp 0
scnModeHandling AUTO
siriName MAX_1ab4fb
userattr scnProcessByDesiChange:0,1 scnShutterList scnModeHandling:NOCHANGE,AUTO,MANUAL
Ich glaube nicht an diese MAX Nachbar Therorie. IMHO sind das zerstörte Telegramme die vorher verworfen wurden und nun durchgehen.
Ich muss einfach schauen wie ich strenge Prüfung und Config Teile lesen unter einen Hut bekomme.
war halt nur auffallend, dass diese geräte nun in der Peerlist sind.
aber ja die werte die hier geloggt wurden zeigen auch eher defekte Telegramme an (233% Ventil stellung, 48°C Gemessene Temperatur etc.)
ich habe aus dem HT mal die Batterie entfernt und damit neugestartet, nun schaut es erstmal besser aus.
Moin,
das Log von heute Nachcht sieht erheblich besser aus. Es kommen noch vereinzelt der gezeigten Meldungen.
Es ist dann immer ein zusammenhängender Block etwa dieser Form:
2021.04.09 03:18:31 2: MAXCUL, unknown message type 18 from MAX_c42488 [c42488] to MAX_0ec502 [c42488] - ignoring !
2021.04.09 03:19:56 2: MAXCUL, unknown message type 26 from MAX_c70489 [c70489] to MAX_898a0e [c70489] - ignoring !
2021.04.09 03:19:56 2: MAXCUL, unknown message type 07 from MAX_860cc5 [860cc5] to MAX_044209 [860cc5] - ignoring !
2021.04.09 03:20:21 2: MAXCUL, unknown message type 3C from MAX_890c9a [890c9a] to MAX_044207 [890c9a] - ignoring !
2021.04.09 03:20:21 3: MAXCUL, could not handle message PairPong from device [190026] MAX_190026 to [890c81] MAX_890c81 - ignoring !
Durch die bessere Überschaubarkeit, kam dann dies zum Vorschein:
2021.04.09 06:56:13 3: MAXCUL, could not handle message Test62 from device [670027] MAX_670027 to [c72486] MAX_c72486 - ignoring !
2021.04.09 06:57:29 3: MAXCUL, could not handle message PairPong from device [180727] MAX_180727 to [3c850f] MAX_3c850f - ignoring !
2021.04.09 06:57:29 1: PERL WARNING: Use of uninitialized value in abs at ./FHEM/14_CUL_MAX.pm line 745.
2021.04.09 06:57:29 1: ERROR: empty name in readingsBeginUpdate
2021.04.09 06:57:29 1: stacktrace:
2021.04.09 06:57:29 1: main::readingsBeginUpdate called by fhem.pl (5030)
2021.04.09 06:57:29 1: main::readingsSingleUpdate called by ./FHEM/14_CUL_MAX.pm (911)
2021.04.09 06:57:29 1: FHEM::CUL_MAX::Parse called by fhem.pl (4043)
2021.04.09 06:57:29 1: main::Dispatch called by ./FHEM/00_CUL.pm (954)
2021.04.09 06:57:29 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (832)
2021.04.09 06:57:29 1: main::CUL_Read called by fhem.pl (3847)
2021.04.09 06:57:29 1: main::CallFn called by fhem.pl (773)
2021.04.09 06:57:29 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4884.
2021.04.09 06:57:29 1: readingsUpdate(,PairedTo,180727) missed to call readingsBeginUpdate first.
2021.04.09 06:57:29 1: stacktrace:
2021.04.09 06:57:29 1: main::readingsBulkUpdate called by fhem.pl (5031)
2021.04.09 06:57:29 1: main::readingsSingleUpdate called by ./FHEM/14_CUL_MAX.pm (911)
2021.04.09 06:57:29 1: FHEM::CUL_MAX::Parse called by fhem.pl (4043)
2021.04.09 06:57:29 1: main::Dispatch called by ./FHEM/00_CUL.pm (954)
2021.04.09 06:57:29 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (832)
2021.04.09 06:57:29 1: main::CUL_Read called by fhem.pl (3847)
2021.04.09 06:57:29 1: main::CallFn called by fhem.pl (773)
2021.04.09 06:57:29 3: MAXCUL, device [000000] UNKNOWN MAX_000000 want to be re-paired to [180727] MAX_180727, not to us [ 05cf48 ] - ignoring !
Die Zuweisung der Gerätebefehle in der Beta enthält die Befehle "Test....". Das gibt es in der SVN-Version ja nicht. Nach Zuweisung von Test folgt ein " UNKNOWN"-Bock mit der MAXID [000000]
Das ist systematisch.
Zitat von: west2107 am 09 April 2021, 09:50:06
Die Zuweisung der Gerätebefehle in der Beta enthält die Befehle "Test....". Das gibt es in der SVN-Version ja nicht. Nach Zuweisung von Test folgt ein " UNKNOWN"-Bock mit der MAXID [000000]
Das ist systematisch.
Also den Abschnitt habe ich jetzt dreimal gelesen und muß sagen ich verstehe ihn nicht :(
Dieser Code-Abschnitt stammt aus der 14_CUL_MAX.prn beta:
my %msgId2Cmd = (
'00' => 'PairPing',
'01' => 'PairPong',
'02' => 'Ack',
'03' => 'TimeInformation',
'10' => 'ConfigWeekProfile',
'11' => 'ConfigTemperatures', #like eco/comfort etc
'12' => 'ConfigValve',
'20' => 'AddLinkPartner',
'21' => 'RemoveLinkPartner',
'22' => 'SetGroupId',
'23' => 'RemoveGroupId',
'24' => 'Test24',
'30' => 'ShutterContactState',
'40' => 'SetTemperature', # to thermostat
'42' => 'WallThermostatControl', # by WallMountedThermostat
# Sending this without payload to thermostat sets desiredTempeerature to the comfort/eco temperature
# We don't use it, we just do SetTemperature
'43' => 'SetComfortTemperature',
'44' => 'SetEcoTemperature',
'50' => 'PushButtonState',
'60' => 'ThermostatState', # by HeatingThermostat
'61' => 'Test61',
'62' => 'Test62',
'63' => 'Test63',
'71' => 'Test71',
'70' => 'WallThermostatState',
Die Zuweisungen Test gibt es in der 14_CUL-MAX.prn SVN Version nicht.
Die erste Zeile des Protokollauszug zeigt das Problem mit Test62 am Device MAX_670027 an.
Die letzte Zeile führt MAXCUL, device [000000] UNKNOWN MAX_000000 .....
Diesen Fehler habe ich 3 mal mit selben Protokolleinträgen. Wird einem Gerät der Befehl Test62 zugewiesen,
führt dies zur fehlerhaften Weiterbehandlung in 00_CUL.pm (954).
Das nächste MAX-Gerät wird mit ID 000000 geparst, was sicherlich nicht der Realität entspricht.
ach sorry, damit habe ich bisher unbekannte Tellegram Typen gesucht, das solltet ihr aber eigentlich nie vorgesetzt bekommen, habe ich doch glatt vergessen vorher zu löschen.
Nun werden eigentlich unsinnige Telegrammtypen plötzlich als gültig komplett durchgereicht.
ich kann berichten, dass auch bei mir alles wunderbar stabil läuft.
herzlichen Dank an WZUT!!
Bei mir auch alles bestens - Danke!
Wann gehen denn die Pakete in die offizielle Verteilung damit sie wieder ins Update aufgenommen werden können?
Hallo zusammen.
Erst mal ein dickes Dankeschön. Die neuen Funktionen sind toll.
Was verwendet ihr für Module/Firmware zum Senden/Empfangen?
Ich habe einen "V 1.67 nanoCUL433" (auf 3600 credits aufgebohrt) drunter und der hängt sich jetzt recht häufig auf.
Besonders, wenn ich zum Testen das "getStatus" alle 1-2 Minuten ausführe. Credits sind zum Schluss noch ausreichen da.
Vom CUL bekomme ich dann auf alle Befehle "no Answer" zurück.
Helfen tut dann nur ein Trennen vom USB + "reopen".
Habe ihn direkt am FHEM Server und via ser2net getestet ... immer das Gleiche.
Danke, Dirk
Hallo Zusammen,
ich habe gestern und heute versucht mittels "deassociate" zwei VSC's von einem HT abzulernen - erhalte von diesem HT ab immer "keine Reaktion" bei deassiciate ... d.h. er behält ihn - Sonstige Aufträge übernimmt er sofort...
error Send Queue NACK from Thermostat_EG_ArbZi for RemoveLinkPartner
Was kann ich noch versuchen um hier einen VSC hinauszuwerfen?
Guten Morgen,
heute hatte ich einen Schwung Meldungen im Log, die ich mir nicht, oder nur schwer erklären kann.
Wenn ich es richtig sehe, wurden viele "fremde" MAX-Geräte "gehört" und deren Nachrichten konnten nicht interpretiert werden..
Die Geräte sind m.W. bei mir nicht angelegt (zumindest finde ich die Adressen in den eckigen Klammern nicht), bis auf die Nachricht um 2021.05.17 00:27:56 wo zumindest mein CUL_MAX vorkommt.
Was dann ab 06:32 Uhr los ist - keine Ahnung
2021.05.17 00:17:56 2: cm, unknown message type 66 from MAX_440018 [440018] to MAX_002600 [440018] - ignoring !
2021.05.17 00:27:56 2: cm, unknown message type CC from cm [entfernt] to MAX_001800 [entfernt] - ignoring !
2021.05.17 01:07:56 2: cm, unknown message type 1F from MAX_840fa0 [840fa0] to MAX_00600a [840fa0] - ignoring !
2021.05.17 03:47:56 2: cm, unknown message type 66 from MAX_44000f [44000f] to MAX_000060 [44000f] - ignoring !
2021.05.17 05:10:27 2: cm, unknown message type 18 from MAX_002600 [002600] to MAX_d02486 [002600] - ignoring !
2021.05.17 05:37:56 2: cm, unknown message type 18 from MAX_1f2a00 [1f2a00] to MAX_d02486 [1f2a00] - ignoring !
2021.05.17 05:46:14 2: cm, unknown message type 25 from MAX_860f00 [860f00] to MAX_046004 [860f00] - ignoring !
2021.05.17 05:46:26 2: cm, unknown message type CF from MAX_1b850f [1b850f] to MAX_a00460 [1b850f] - ignoring !
2021.05.17 05:50:34 2: cm, unknown message type 37 from MAX_850fa0 [850fa0] to MAX_04600a [850fa0] - ignoring !
2021.05.17 05:57:56 2: cm, unknown message type 1F from MAX_2a00d9 [2a00d9] to MAX_258585 [2a00d9] - ignoring !
2021.05.17 06:24:29 2: cm, unknown message type DF from MAX_1d890f [1d890f] to MAX_000460 [1d890f] - ignoring !
2021.05.17 06:28:23 2: cm, unknown message type 1F from MAX_2a00e2 [2a00e2] to MAX_26890f [2a00e2] - ignoring !
2021.05.17 06:32:14 1: PERL WARNING: Use of uninitialized value in abs at ./FHEM/14_CUL_MAX.pm line 745.
2021.05.17 06:32:14 1: ERROR: empty name in readingsBeginUpdate
2021.05.17 06:32:14 1: stacktrace:
2021.05.17 06:32:14 1: main::readingsBeginUpdate called by fhem.pl (5070)
2021.05.17 06:32:14 1: main::readingsSingleUpdate called by ./FHEM/14_CUL_MAX.pm (911)
2021.05.17 06:32:14 1: FHEM::CUL_MAX::Parse called by fhem.pl (4083)
2021.05.17 06:32:14 1: main::Dispatch called by ./FHEM/00_CUL.pm (954)
2021.05.17 06:32:14 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (832)
2021.05.17 06:32:14 1: main::CUL_Read called by fhem.pl (3887)
2021.05.17 06:32:14 1: main::CallFn called by fhem.pl (773)
2021.05.17 06:32:14 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4924.
2021.05.17 06:32:14 1: readingsUpdate(,PairedTo,180b2a) missed to call readingsBeginUpdate first.
2021.05.17 06:32:14 1: stacktrace:
2021.05.17 06:32:14 1: main::readingsBulkUpdate called by fhem.pl (5071)
2021.05.17 06:32:14 1: main::readingsSingleUpdate called by ./FHEM/14_CUL_MAX.pm (911)
2021.05.17 06:32:14 1: FHEM::CUL_MAX::Parse called by fhem.pl (4083)
2021.05.17 06:32:14 1: main::Dispatch called by ./FHEM/00_CUL.pm (954)
2021.05.17 06:32:14 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (832)
2021.05.17 06:32:14 1: main::CUL_Read called by fhem.pl (3887)
2021.05.17 06:32:14 1: main::CallFn called by fhem.pl (773)
2021.05.17 06:32:14 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4670.
2021.05.17 06:44:16 2: cm, unknown message type 52 from MAX_e0850b [e0850b] to MAX_520630 [e0850b] - ignoring !
2021.05.17 06:44:23 2: cm, unknown message type D6 from MAX_128900 [128900] to MAX_520583 [128900] - ignoring !
2021.05.17 06:47:56 2: cm, unknown message type 2A from MAX_00e525 [00e525] to MAX_820b52 [00e525] - ignoring !
Ich wüßte immernoch gern ob die Pakete mittlerweile im offiziellen Update sind weil ich sie noch vom Update ausgeschlossen habe!
Kann das jemand klarstellen?
List of new / modified files since last update:
UPD FHEM/00_MAXLAN.pm (excluded from update)
UPD FHEM/10_MAX.pm (excluded from update)
UPD FHEM/14_CUL_MAX.pm (excluded from update)
@Parador, ich tippe da auf zerstörte Telegramme - kommt manchmal vor, auch bei mir
@Taipan, sind nicht im svn daher ja auch dieser Thread
@ Parador
Das Problem mir dem Empfang hatte ich auch. Bei mir wurden über mehrere Tage 41 MAX-Geräte per Autocreate erzeugt.
Die habe ich alle auf ignore gesetzt. Seit einigen Wochen ist aber Ruhe.
Es macht auch Sinn die PeerList der eigenen Geräte zu überwachen. Ich hatte einen Kandidaten der sehr gerne mit solchen
neuen Geräten "schwatzte". Die erscheinen dann in seiner PeerList.
Den habe ich zurückgesetzt und neu angelernt. Jetzt ist der auch ruhig geworden.
Ansonstenlaufen die Module gut und die neuen Funktionen sind ein echter Mehrwert.
@west2107 & @Wzut
Danke für die Hinweise, ich habe tatsächlich auch einen "Schätzer" gefunden, bei dem einige der unbekannten Geräte in der peerList auftauchen.
Die meisten habe ich auf ignore gesetzt.
Jetzt habe ich aber noch einige Fragen:
Wie unterscheiden sich "peerIDs", "peerList" und "peers" ?
"peers" sind m.M. nach die die mit "associate" verknüpft wurden, und die anderen?
Hier mal ein List des "Schätzers", die "peers" sind ok - muss ich wegen der anderen bei peerIDs und peerList noch was tun?
2021-05-23 13:09:03 peerIDs 000000,0f0000,440f00,4427c4,44660f
2021-05-23 13:09:03 peerList Broadcast,MAX_0f0000,MAX_440f00,MAX_4427c4,MAX_44660f
2020-05-01 08:49:12 peers 010501,010502
Und dann habe ich noch das Problem, dass ein anderer nicht auf ein "deassiciate" reagiert
2020-11-30 11:30:14 peerIDs 000000,222222
2020-11-30 11:30:14 peerList Broadcast,MAX_222222
2021-05-14 22:55:59 peers [u]010001,010201[/u],010301,010302
Hier erhalte ich im CUL_MAX immer die identische Fehlermeldung:
Internals:
DEF --entfernt--
FUUID 5d9598f6-f33f-71bb-9d12-fbd0e5ae82f8ad07
IODev MAX_CUL_0
LASTInputDev
NAME cm
NOTIFYDEV global
NR 267
NTFY_ORDER 50-cm
STATE MAX_CUL_0:ok
SVN 28032021
TYPE CUL_MAX
addr --entfernt--
cnt 0
pairmode 0
retryCount 0
sq 0
READINGS:
2021-05-23 13:21:58 IODev MAX_CUL_0
2021-05-25 15:06:16 error Send Queue NACK from Thermostat_EG_AZi for RemoveLinkPartner
2021-05-25 13:22:08 msgcnt 5
2020-03-26 10:53:27 packetsLost 697
2021-05-25 15:12:24 state MAX_CUL_0:ok
helper:
asso:
Fenster_EG_SZi_re Dispatch
MAX_CUL_0 IO
Thermostat_EG_AZi Send
Thermostat_EG_EZi Dispatch
Thermostat_EG_K Dispatch
Thermostat_EG_SZi Send
Thermostat_EG_WZi Dispatch
Thermostat_OG_GZiA Dispatch
Thermostat_OG_GZiB Dispatch
Thermostat_OG_KZi_2 Dispatch
Thermostat_OG_XZi Send
sendQueue:
Attributes:
IODev MAX_CUL_0
fakeSCaddr 222222
fakeWTaddr 111111
icon cul_max
room MAX
Habt Ihr da Ideen?
peerIDs und peerList gehören zusammen , IDs listet die sechstelligen HEX Adressen, List versucht die dazu passenden Namen dazustellen.
Ist bei vielen Usern leider relativ sinnlos, da sie an den blöden MAX_Hex autocreate Namen festhängen .... anyway
Beide Listen bauen sich dynamisch auf je nachdem welche Telegramme das CUL_MAX Device jemals gesehen hat, entweder als Ziel oder als Quelle.
Ist ne reine Info für den User und wenn da Müll drin steht oder es jamand nicht haben will -> delereading
peers baut sich auch selbst auf, aber nur nach einem peering (associate) von Hand.
Ebenfalls eine reine Info, mit Ausnahme bei den virtuellen Geräten.
wenn ein Gerät auf deassociate (unpeering) ein NACK ausgibt dann ist das betreffende Gerät nicht mehr gepeered oder war es noch nie.
Auch hier muß das Reading nicht unbedingt stimmen, da es halt bis jetzt keine Möglichkeit gibt diese direkt auszulesen.
und BTW :
Zitat--entfernt--
sowas ist Unfug, die MAX Adressen sind keine Staatsgeheimnisse sondern einfach nur Nummern .....
Hallo Wzut,
habe die drei Beta-Module ansonsten problemlos im Einsatz, bekomme aber für meinen Eindruck viele solcher Meldungen
XXXX_CULMAX00, Send Queue could not change IODev !
im FHEM-Log (z.B. aktuell seit Mo, 00:00h: 46 Meldungen, letzte Woche: 222 Meldungen).
XXXX_CULMAX00 ist das CUL_MAX Device.
Kann leider nicht nachvollziehen, was sie genau bedeuten oder was ich tun kann, um die Meldungen zu eliminieren (außer verbose 2 am MAX-Device :'().
Muss ich mir Sorgen machen?
Als IO-Devices habe ich 1 CUL und 2 mit aculfw geflashte MAX-Cubes im Einsatz und entsprechend im CUL_MAX Device "XXXX_CULMAX00" im Attribut "IOgrp" aufgenommen:
Internals:
DEF 123456
FUUID 5c4429e7-f33f-cd7a-aa25-6899a3aa62ba5f6f
IODev XXOG_CUL_MAX
IOgrp XXOG_CUL_MAX,XXDG_MAXCUBE01,XXKG_MAXCUBE01
LASTInputDev
NAME XXXX_CULMAX00
NOTIFYDEV global
NR 26
NTFY_ORDER 50-XXXX_CULMAX00
STATE XXOG_CUL_MAX:ok,XXDG_MAXCUBE01:ok,XXKG_MAXCUBE01:ok
SVN 28032021
TYPE CUL_MAX
XXDG_MAXCUBE01_VERSION 167
XXKG_MAXCUBE01_VERSION 167
XXOG_CUL_MAX_MAXID 123456
XXOG_CUL_MAX_VERSION 167
addr 123456
cnt 0
pairmode 0
retryCount 0
sq 0
READINGS:
2021-06-05 14:03:25 IODev XXOG_CUL_MAX
2021-05-25 07:12:00 XXDG_MAXCUBE01_cmd_last_h 2
2021-05-25 07:12:00 XXDG_MAXCUBE01_credit10ms 3600
2020-10-01 07:31:23 XXDG_MAXCUBE01_lost 2
2021-03-27 10:23:34 XXDG_MAXCUBE01_nack 4
2021-06-07 07:08:41 XXDG_MAXCUBE01_retry 229
2021-05-17 10:32:35 XXKG_MAXCUBE01_cmd_last_h 3
2021-05-17 10:32:35 XXKG_MAXCUBE01_credit10ms 3600
2021-01-10 11:57:41 XXKG_MAXCUBE01_lost 26
2021-04-01 05:31:35 XXKG_MAXCUBE01_retry 116
2021-06-09 07:17:51 XXOG_CUL_MAX_cmd_last_h 7
2021-06-09 07:17:51 XXOG_CUL_MAX_credit10ms 900
2021-03-15 08:56:04 XXOG_CUL_MAX_lost 64
2020-12-22 18:08:02 XXOG_CUL_MAX_nack 6
2021-06-05 15:23:45 XXOG_CUL_MAX_retry 924
2021-06-09 07:17:51 error could not change IODev
2021-04-03 09:31:38 lastTimeSync BAEG_MT
2021-06-09 02:03:38 msgcnt 8
2021-03-01 15:33:25 none_lost 109
2021-03-01 15:33:18 none_retry 327
2020-01-03 12:58:58 packetsLost 3188
2020-01-03 10:10:42 packetsNACK 9
2020-01-10 07:09:22 packetsRetry 145
2021-05-09 23:57:48 short_message Z00
2021-06-09 07:28:41 state XXOG_CUL_MAX:ok,XXDG_MAXCUBE01:ok,XXKG_MAXCUBE01:ok
2021-03-30 18:25:09 unknown_message Z19F800101234560E847600015201511F53204520452045204520
helper:
asso:
BADG_MFSC Dispatch
BADG_MT Send
BAEG_MF Dispatch
BAEG_MT Dispatch
BAOG_MF Dispatch
BAOG_MT Dispatch
EZEG_MT Dispatch
EZOG_MT Dispatch
FLDG_MB Dispatch
KUDG_MFSC Dispatch
KUDG_MT Dispatch
SZDG_MFSC Dispatch
SZDG_MT Dispatch
SZEG_MT Dispatch
SZOG_MFSC Dispatch
SZOG_MT Send
WGEG_MT Dispatch
WZDG_MFSC Dispatch
WZDG_MT Dispatch
WZEG_MFSC Dispatch
WZEG_MT Send
WZOG_MF Dispatch
WZOG_MT Dispatch
XXDG_MAXCUBE01 IO
XXDG_MTW Dispatch
XXKG_MAXCUBE01 IO
XXOG_CUL_MAX IO
sendQueue:
Attributes:
IODev XXOG_CUL_MAX
IOgrp XXOG_CUL_MAX,XXDG_MAXCUBE01,XXKG_MAXCUBE01
blacklist 02020a,0b2ce7,1325b9,13d598,0b2d0d,0b311b,1325e0,13d59a,02892b,600e84,da0985,180024
debug 1
fakeSCaddr 222222
fakeWTaddr 111111
Danke für jeglichen Hinweis und falls weitere Infos benötigt werden, liefere ich sie gerne nach,
Andreas
Ich befürchte das sind die ersten Auswirkungen von https://forum.fhem.de/index.php/topic,120603.0.html
Ist dein FHEM denn aktuell ?
Für den IOWechsel ist das CULdev Attribut des jeweiligen MAX Device zuständig, welcher Wechsel da genau schief geht verrät dir dein XXXX_CULMAX00 wenn es mit verbose 4 läuft.
Zitat von: Wzut am 09 April 2021, 17:55:57
ach sorry, damit habe ich bisher unbekannte Tellegram Typen gesucht, das solltet ihr aber eigentlich nie vorgesetzt bekommen, habe ich doch glatt vergessen vorher zu löschen.
Nun werden eigentlich unsinnige Telegrammtypen plötzlich als gültig komplett durchgereicht.
Hallo Wzut,
hattest du das eigentlich wieder behoben? Bzw. was muss ich in der noch im ersten Post verlinkten Version von Ende März auskommentieren, damit sich bei mir nicht die Peerlists mit Müll füllen? Autocreate ist sowieso aus.
Danke!
Jan
Zitat von: Wzut am 09 Juni 2021, 10:02:05
Ich befürchte das sind die ersten Auswirkungen von https://forum.fhem.de/index.php/topic,120603.0.html
Ist dein FHEM denn aktuell ?
Für den IOWechsel ist das CULdev Attribut des jeweiligen MAX Device zuständig, welcher Wechsel da genau schief geht verrät dir dein XXXX_CULMAX00 wenn es mit verbose 4 läuft.
Danke für die prompte Reaktion.
FHEM habe ich jetzt auf den neuesten Stand gebracht, die Meldungen kommen weiterhin.
Diesmal mit verbose 4:
2021.06.09 13:26:03.034 4: XXXX_CULMAX00, Send Queue packet to XXDG_MTW needs XXDG_MAXCUBE01 but current IODev is XXOG_CUL_MAX
2021.06.09 13:26:03.042 3: XXXX_CULMAX00, Send Queue could not change IODev !
2021.06.09 13:26:03.062 4: XXXX_CULMAX00, Send Queue packet send : Zs0beb043030281209a9611e10 to XXDG_MTW with XXOG_CUL_MAX
2021.06.09 13:26:04.133 4: XXXX_CULMAX00, C: EB, F: 02, T: 02, S: 09A961 D: 302812 G: 00 P: 0119043D
2021.06.09 13:26:04.134 4: XXXX_CULMAX00, IODev XXOG_CUL_MAX, flags 02, msgcnt EB, msgType Ack, src 09a961 WallMountedThermostat, dst 302812 virtualShutterContact, group 0, payload 0119043D, rssi -67.5
2021.06.09 13:26:04.235 4: XXXX_CULMAX00, C: EB, F: 04, T: 30, S: 302812 D: 09A961 G: 1E P: 10
2021.06.09 13:26:04.236 4: XXXX_CULMAX00, IODev XXKG_MAXCUBE01, flags 04, msgcnt EB, msgType ShutterContactState, src 302812 virtualShutterContact, dst 09a961 WallMountedThermostat, group 30, payload 10, rssi -84
2021.06.09 13:26:04.286 4: XXXX_CULMAX00, C: EB, F: 02, T: 02, S: 09A961 D: 302812 G: 00 P: 0119043D
2021.06.09 13:26:04.286 4: XXXX_CULMAX00, IODev XXKG_MAXCUBE01, flags 02, msgcnt EB, msgType Ack, src 09a961 WallMountedThermostat, dst 302812 virtualShutterContact, group 0, payload 0119043D, rssi -89.5
2021.06.09 13:26:04.381 4: XXXX_CULMAX00, C: EB, F: 04, T: 30, S: 302812 D: 09A961 G: 1E P: 10
2021.06.09 13:26:04.381 4: XXXX_CULMAX00, IODev XXDG_MAXCUBE01, flags 04, msgcnt EB, msgType ShutterContactState, src 302812 virtualShutterContact, dst 09a961 WallMountedThermostat, group 30, payload 10, rssi -67.5
2021.06.09 13:26:04.432 4: XXXX_CULMAX00, C: EB, F: 02, T: 02, S: 09A961 D: 302812 G: 00 P: 0119043D
2021.06.09 13:26:04.432 4: XXXX_CULMAX00, IODev XXDG_MAXCUBE01, flags 02, msgcnt EB, msgType Ack, src 09a961 WallMountedThermostat, dst 302812 virtualShutterContact, group 0, payload 0119043D, rssi -57.5
2021.06.09 13:26:04.542 4: XXXX_CULMAX00, Send Queue ACK from XXDG_MTW for ShutterContactState, removing from queueIch verstehe das so, dass
- zum Senden an das WT XXDG_MTW als IO-Device XXDG_MAXCUBE01 benutzt werden soll (woher stammt die Info, welches CULdev zu nutzen ist?)
- im Attribut "CULdev" des WT XXDG_MTW allerdings das IO-Device XXOG_CUL_MAX steht (automatisch durch die MAX-Module wegen mehrerer IO-Devices gesetzt, abhängig vom besten RSSI-Wert)
- das Attribut und somit der Wechsel nicht auf CULdev XXDG_MAXCUBE01 geändert werden kann (warum?)
Kann leider immer noch nicht einordnen (bin ehrlich gesagt daran gescheitert, den von Dir verlinkten Thread zu verstehen), ob die Meldung jetzt ein Problem darstellt oder es eher "normal" ist und ignoriert werden kann?
Viele Dank für Deine Unterstützung,
Andreas
Zitat von: JHo am 09 Juni 2021, 10:11:29
was muss ich in der noch im ersten Post verlinkten Version von Ende März auskommentieren
die Zeilen mit TestXX :
my %msgId2Cmd = (
'00' => 'PairPing',
'01' => 'PairPong',
'02' => 'Ack',
'03' => 'TimeInformation',
'10' => 'ConfigWeekProfile',
'11' => 'ConfigTemperatures', #like eco/comfort etc
'12' => 'ConfigValve',
'20' => 'AddLinkPartner',
'21' => 'RemoveLinkPartner',
'22' => 'SetGroupId',
'23' => 'RemoveGroupId',
'24' => 'Test24',
'30' => 'ShutterContactState',
'40' => 'SetTemperature', # to thermostat
'42' => 'WallThermostatControl', # by WallMountedThermostat
# Sending this without payload to thermostat sets desiredTempeerature to the comfort/eco temperature
# We don't use it, we just do SetTemperature
'43' => 'SetComfortTemperature',
'44' => 'SetEcoTemperature',
'50' => 'PushButtonState',
'60' => 'ThermostatState', # by HeatingThermostat
'61' => 'Test61',
'62' => 'Test62',
'63' => 'Test63',
'71' => 'Test71',
'70' => 'WallThermostatState',
'82' => 'SetDisplayActualTemperature',
'F1' => 'WakeUp',
'F0' => 'Reset',
);
Zitat von: scooty am 09 Juni 2021, 13:57:26
FHEM habe ich jetzt auf den neuesten Stand gebracht
so war das nicht gemeint, je neuer , je schlimmer :(
Zitatwoher stammt die Info, welches CULdev zu nutzen ist?
wie bereits geschrieben bestimmt du es selbst je MAX Device mit dem Attribut CULdev
Denn nur du kannst eigentlich wissen welcher deiner CULs der "Beste" für das jeweilige Device ist.
Zitatautomatisch durch die MAX-Module wegen mehrerer IO-Devices gesetzt
Das kann nur eine Empfehlung sein, die letzte Entscheidung trifft der User selbst , siehe Attribut autoselectCUL
Zitatbin ehrlich gesagt daran gescheitert, den von Dir verlinkten Thread zu verstehen
macht nichts, der ist auch schwere Kost und in weiten Teilen kann ich selbst die Argrumente der Profis nicht verstehen,
aber Fakt ist das diese Änderungen schuld am jetzigen Verhalten desCUL_MAX Device sind wenn das CUL_MAX Device kein simples IODev hat sondern
wie Homematic mehere unter IOGrp. Ich muß sehen wie dieser Schildbürgerstreich endet und dann schauen ob ich das Multi IO des CUL_MAX weiter am Leben halten kann.
Zitat von: Wzut am 09 Juni 2021, 19:18:45
so war das nicht gemeint, je neuer , je schlimmer :(
Ups, aber egal, war ja sowieso schon auf einer der neueren Versionen, sonst wär die Meldung ja nicht da.
Zitat von: Wzut am 09 Juni 2021, 19:18:45
wie bereits geschrieben bestimmt du es selbst je MAX Device mit dem Attribut CULdev
Denn nur du kannst eigentlich wissen welcher deiner CULs der "Beste" für das jeweilige Device ist.Das kann nur eine Empfehlung sein, die letzte Entscheidung trifft der User selbst , siehe Attribut autoselectCUL
Alles klar, "autoselectCUL" hatte ich bisher nicht genutzt, der CUL-Auswahl-Automatismus funktioniert sehr gut.
Zitat von: Wzut am 09 Juni 2021, 19:18:45
Ich muß sehen wie dieser Schildbürgerstreich endet und dann schauen ob ich das Multi IO des CUL_MAX weiter am Leben halten kann.
Ich hoffe darauf, alles andere wäre mMn ein Rückschritt (natürlich nicht von Dir verschuldet).
Vielen Dank und Grüße,
Andreas
@scooty und diejenigen die Multi IO am cm Device nutzen und jetzt auch diese Probleme haben :
löscht bitte am cm Device das Attribut IODev , save und FHEM restart.
Zumindest in meiner Testumgebung ist dann der Wechsel wieder ohne Fehler möglich.
Kann ich bestätigen, seit Löschung des Attributs und Restart keine Meldungen mehr.
8)
Andreas
OK, danke für die Rückmeldung.
Dann bekommt 14_CUL_MAX noch ein paar Zeilen die das IODev Attribut löschen sobald der User IOgrp mit mehr als einem gültigen CUL anlegt.
Eine kurze Rückfrage zu #36:
Verstehe ich es richtig, dass die neuen Möglichkeiten zur Temperaturabfrage in 10_MAX nicht mit dem MAXCube funktionieren, sondern einen CUL erfordern?
Hintergrund:
Mein FHEM soll ohnehin gerade auf einen anderen Server umziehen und das ist eine gute Gelegenheit zum Aufräumen/Ausmisten und (gerade außerhalb der Heizperiode) ggf. auch dafür, den Cube doch mal zu flashen. Bisher fehlte ein wenig der Anreiz, die Temperaturabfrage wäre ein solcher.
@Nuems, so ist es : 14_CUL_MAX only !
Wenn du aber jetzt ein Wechsel planst bitte denke daran und notiere dir deine aktuelle MAXID und ziehe Streßfrei vom CUBE auf CUL_MAX um ohne Werksreset !
Hi,
ich nutzt jetzt schon die Beta Version seit Anfang des Jahres mit einem externen Sensor.
Mir ist aufgefallen das ich in dieser Zeit schon zwei mal die Batterien wechseln musste. Bei den anderen Thermostaten die noch mit dem Cube laufen ist der Wechsel so alle 2 Jahre. Kennt das jemand?
Hallo,
ich habe auch die 3 angepassten Dateien aus dem dem ersten Post installiert, weil mich die aktuelle Temperatur der HTs interessiert und ich mit dem Scanner nicht warm wurde.
Aber seit dem habe ich massive Probleme mit den zwei vorhandenen CULs. Einer ist mit 433 MHz für Schaltsteckdosen und einer mit 868 MHz für MAX!
Aus dem verlinkten thread https://forum.fhem.de/index.php/topic,120603.0.html verstehe ich, dass die ursprünglichen Zuordnungen USB1 für 433 MHz und USB2 für 868 MHz wohl nicht mehr funktionieren.
Da mit die Schaltung der Steckdosen wichtiger ist als die Anzeige der Raumtemperatur werde ich die 3 Module wieder durch die Originaldateien ersetzen müssen.
@_fhemuser_ , du verwechselst Äpfel mit Birnen !
Das leidige IODev Thema kommt nicht von den MAX! Modulen, da kannst du installieren an Versionen was du möchtest.
Dein Problem scheint eher ein alt bekanntes zu sein, d.h absolute Namen (/dev/ttyUSB0) verwendet statt by-path oder by-id
Hallo Wzut,
bei mir wurde immer angezeigt beim CUL SOA statt ok und im Logfile: 2021.07.23 09:26:25 1: MAX_CUL_Stick, Send Queue error CUL CUL866 did not answer request for current credits. Waiting 5 seconds
Da das mit den Originalen Module nie war und in diesem thread auf Fehler mit dem USB verlinkt wurde, hatte ich den Verdacht, dass dort der Fehler liegt.
Benötigten die 3 Betamodule soviele Credits?
Ich habe jetzt noch einmal eine Woche lang die originalen Module ohne Fehlermedung installiert gehabt.
Nachdem ich heute vormittag wieder die 3 Betamodule installierte stieg die SendCue stark an und der Status des CUL steht auf UAS.
der CUL ist eingebunden mit: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0@38400 1234
Wo kann der Fehler liegen?
Ich sehe da noch immer nicht den Zusammenhang.
Der CUL wird direkt bedient von 00_CUL.pm -> nicht meine Baustelle.
00_MAXLAN.pm brauch einen Cube mit orignal Firmeware -> hast du doch gar nicht.
14_CUL_MAX.pm nutzt Funktionen von 00_CUL, egal ob altes Modul aus dem SVN oder die Beta Version.
Aber ohne gescheites verbose 5 Log ist das halt wie immer alles reine Kaffeesatz Leserei ......
Den Original Cube habe ich vor Monaten in Rente geschickt, da er die Konfiguration immer wieder vergessen hatte.
Wenn die 3 Betadateien unbedingt den Cube bennötigen, schließe ich ihn wieder an und richte ihn in fhem ein und entferne den CUL.
Bei den zukünftigen Fehlern erstelle ich Logdateien und füge sie hier ein.
Wenn du keinen Original Cube mehr im Einsatz hast macht der Austausch der 00_MAXLAN.pm doch gar keinen Sinn !
D.h. wie willst du die Funktion eines Modules testen wenn du die dazu notwendige Hardware gar nicht mehr in Betrieb hast.
Anyway, ich hoffe das nach dem Wechsel vom Cube zum CUL auch das entsprechende define aus der config gelöscht hast bzw. das komplette MAXLAN Device.
Als erstes wäre schon mal wichtig zu wissen wie du vom Cube auf den CUL umgezogen bist :
a. Soft und einfach mit Übernahme der MAXID vom MAXLAN Device zum CUL_MAX Device ?
oder
b. Hart und schwer mit neuer MAXID am CUL_MAX Device und Werksreset aller Geräte ?
In jedem Fall wäre ersteinmal ein list deines cm Device interessant.
ich bin nun leider wieder von der Beta auf die SVN version gegangen, da bei mir leider ein Paar Thermostate ziemlich defekte werte an Fhem übermittelt haben.
Siehe screenshot
So ein Screenshot alleine bringt leider niemand wirklich weiter. ( ich erkenne da gar nichts )
Ein entsprechendes Log hätte hilfreich sein können eventuel vorhandene Ausreisser zu erkennen.
wenn du mir sagst welches device ich auf welchem log level loggen soll dann kann ich das gerne mal machen.
Ein Anfamg wäre zuerst das entsprechende HT auf verbose 5 stellen und mal solange loggen lassen bis ein Ausreisser da ist.
Ist er im Log nicht zu sehen muß man eine Stufe höher am CUL_MAX Device mit verbose 5 ansetzen.
Bzw. Stimmt deine Sig noch und du nutzt MAXLAN ?
dann werde ich nochmal auf die Beta umstellen und mit Verbose 5 am HT mit loggen.
habe inzwischen auf cul migriert nur vergessen den MAX Lan aus der Signatur zu nehmen :D
So das Thermostat meldet seit 18:44 eine nicht plausible Temperatur
2021.08.05 18:44:53 5: MAX_1ab4fb, msgtype ThermostatState : 180026000F
2021.08.05 18:44:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:1.5
2021.08.05 18:44:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-74, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 19:14:53 5: MAX_1ab4fb, msgtype ThermostatState : 18002600D2
2021.08.05 19:14:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:21
2021.08.05 19:14:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-66.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
Und noch ein List des devices
Internals:
.FhemMetaInternals 1
.actCycle 3600
.count 0
.sendToAddr -1
.sendToName
.testbit 0
.timer 300
DEF HeatingThermostat 1ab4fb
FUUID 5c48893b-f33f-5212-2d05-9a9a34c36ee5cb81
IODev cul_MAX
LASTInputDev cul_MAX
MSGCNT 13
NAME MAX_1ab4fb
NOTIFYDEV global
NR 371
NTFY_ORDER 50-MAX_1ab4fb
STATE auto
ok
0
alive
21.0 °C
SVN BETA_28032021
TYPE MAX
TimeSlot -1
addr 1ab4fb
cul_MAX_MSGCNT 13
cul_MAX_TIME 2021-08-05 19:14:53
devtype 1
type HeatingThermostat
.attraggr:
.attreocr:
.*
.attreour:
.*
.attrminint:
Helper:
DBLOG:
desiredTemperature:
DbLog:
TIME 1628183693.46657
VALUE 19.0
temperature:
DbLog:
TIME 1628183693.46657
VALUE 21.0
valveposition:
DbLog:
TIME 1628183693.46657
VALUE 0
READINGS:
2021-08-05 16:54:53 .associatedWith Broadcast,MAX_070f00,MAX_070fe9,MAX_07c30c,MAX_07c30f,MAX_0f0000
2021-08-05 19:14:53 .isToMe 1
2021-08-05 19:14:53 .lastact 1628183693
2021-08-03 14:37:47 .weekProfile 4c484d104d134d204520452045204520452045204520452045204c484d104d134d204520452045204520452045204520452045204c484d104d134d204520452045204520452045204520452045204c484d104d134d204520452045204520452045204520452045204c484d104d134d204520452045204520452045204520452045204c484d104d134d204520452045204520452045204520452045204c484d104d134d20452045204520452045204520452045204520
2021-08-03 14:37:47 .wp_json {"Sat":{"time":["06:00","22:40","22:55","24:00"],"temp":["19","19","19","19"]},"Sun":{"time":["06:00","22:40","22:55","24:00"],"temp":["19","19","19","19"]},"Mon":{"time":["06:00","22:40","22:55","24:00"],"temp":["19","19","19","19"]},"Tue":{"time":["06:00","22:40","22:55","24:00"],"temp":["19","19","19","19"]},"Wed":{"time":["06:00","22:40","22:55","24:00"],"temp":["19","19","19","19"]},"Thu":{"time":["06:00","22:40","22:55","24:00"],"temp":["19","19","19","19"]},"Fri":{"time":["06:00","22:40","22:55","24:00"],"temp":["19","19","19","19"]}}
2021-08-05 19:14:53 Activity alive
2021-08-05 15:34:51 IODev cul_MAX
2021-08-03 14:42:50 MAXLAN_error 0
2021-08-03 14:42:50 MAXLAN_errorInCommand
2021-08-03 14:42:50 MAXLAN_initialized 1
2021-08-03 14:42:50 MAXLAN_isAnswer 0
2021-08-03 14:42:50 MAXLAN_valid 1
2021-08-03 14:37:47 PairedTo 07c3e1
2021-08-05 19:14:53 RSSI -66.5
2021-08-03 14:37:47 SerialNr OEQ1952148
2021-08-05 19:14:53 battery ok
2021-08-05 19:14:53 batteryState ok
2021-08-03 14:37:47 boostDuration 5
2021-08-03 14:37:47 boostValveposition 80
2021-08-03 14:37:47 comfortTemperature 21.0
2021-08-03 14:37:47 decalcification Sat 12:00
2021-08-05 19:14:53 desired-temp 19.0
2021-08-05 19:14:53 desiredTemperature 19.0
2021-08-05 19:14:53 deviation 2.0
2021-08-03 14:37:47 ecoTemperature 17.0
2021-08-03 14:37:47 firmware 1.1
2021-08-05 19:14:53 gateway 1
2021-08-03 14:37:47 groupid 4
2021-08-03 14:37:47 lastConfigSave ./log/MAX_1ab4fb.max
2021-08-05 09:43:34 lastTimeSync 2021-08-05 09:43:34
2021-08-05 15:27:54 lastcmd desiredTemperature 19.0 19.0
2021-08-03 14:37:47 maxValveSetting 100
2021-08-03 14:37:47 maximumTemperature on
2021-08-03 14:37:47 measurementOffset 0.0
2021-08-03 14:37:47 minimumTemperature off
2021-08-05 19:14:53 mode auto
2021-08-05 19:14:51 msgcnt 157
2021-08-05 15:28:19 nanoCul868_RSSI -70.5
2021-01-13 21:44:20 none_lost 4
2021-01-21 16:10:55 none_retry 13
2021-08-05 19:14:53 panel unlocked
2021-08-05 16:54:53 peerIDs 000000,070f00,070fe9,07c30c,07c30f,0f0000
2021-08-05 16:54:53 peerList Broadcast,MAX_070f00,MAX_070fe9,MAX_07c30c,MAX_07c30f,MAX_0f0000
2021-04-10 19:57:14 peers 0dc446
2021-08-05 19:14:53 rferror 0
2021-08-05 15:28:19 sendTo_Broadcast 551
2021-08-03 23:33:41 sendTo_MAX_070f00 3
2021-08-05 16:24:53 sendTo_MAX_07c30f 3
2021-08-05 16:54:53 sendTo_MAX_0f0000 8
2021-08-05 19:14:53 state 19.0
2021-08-05 19:14:53 temperature 21.0
2021-08-03 14:37:47 testresult 161
2021-08-03 14:37:47 valveOffset 0
2021-08-05 19:14:53 valveposition 0
2021-08-03 14:37:47 weekprofile-0-Sat-temp 19.0 °C / 19.0 °C / 19.0 °C / 19.0 °C
2021-08-03 14:37:47 weekprofile-0-Sat-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-08-03 14:37:47 weekprofile-1-Sun-temp 19.0 °C / 19.0 °C / 19.0 °C / 19.0 °C
2021-08-03 14:37:47 weekprofile-1-Sun-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-08-03 14:37:47 weekprofile-2-Mon-temp 19.0 °C / 19.0 °C / 19.0 °C / 19.0 °C
2021-08-03 14:37:47 weekprofile-2-Mon-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-08-03 14:37:47 weekprofile-3-Tue-temp 19.0 °C / 19.0 °C / 19.0 °C / 19.0 °C
2021-08-03 14:37:47 weekprofile-3-Tue-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-08-03 14:37:47 weekprofile-4-Wed-temp 19.0 °C / 19.0 °C / 19.0 °C / 19.0 °C
2021-08-03 14:37:47 weekprofile-4-Wed-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-08-03 14:37:47 weekprofile-5-Thu-temp 19.0 °C / 19.0 °C / 19.0 °C / 19.0 °C
2021-08-03 14:37:47 weekprofile-5-Thu-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-08-03 14:37:47 weekprofile-6-Fri-temp 19.0 °C / 19.0 °C / 19.0 °C / 19.0 °C
2021-08-03 14:37:47 weekprofile-6-Fri-time 00:00-06:00 / 06:00-22:40 / 22:40-22:55 / 22:55-24:00
2021-08-03 14:37:47 windowOpenDuration 15
2021-08-03 14:37:47 windowOpenTemperature 12.0
helper:
io:
nanoCul868:
raw Z0F0000601AB4FB07C3E10018002600D2
rssi -66.5
time 1628183693.46494
Attributes:
IODev cul_MAX
actCycle 1:0
alexaName Heizung Kinderzimmer
alias Heizung Kinderzimmer
appOptions {
"template": "thermostat",
"dashboard": "true"
}
autosaveConfig 1
comment Configured using template MAX_HeatingThermostat_dark
debug 1
devStateIcon auto:sani_heating_automatic@green manual:sani_heating_manual@yellow boost:sani_heating_boost@red temporary:sani_heating_timer@blue 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 .*
event-on-update-reading .*
genericDeviceType thermostat
group Heizung
icon hc_wht_regler
model HeatingThermostat
room Homekit,Kinderzimmer,MAX->Geräte
scanTemp 1
scnModeHandling AUTO
siriName Heizung Kinderzimmer
stateFormat mode
battery
rferror
Activity
temperature °C
userattr scnProcessByDesiChange:0,1 scnShutterList scnModeHandling:NOCHANGE,AUTO,MANUAL
verbose 5
webCmd desiredTemperature:valveposition
webCmdLabel LABEL
widgetOverride valveposition:slider,0,1,100 temperature:selectnumbers,15,0.1,29,1,lin
Hier mal Alles was das HT heute mittag produziert hat.
im 16:54 hatte ich auch valve auf 196%, gemsessene 45,1 °C und 35°C eingestellte Temperatur
2021.08.05 15:44:53 5: MAX_1ab4fb, msgtype ThermostatState : 18002600CC
2021.08.05 15:44:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.4
2021.08.05 15:44:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-71.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 15:54:53 5: MAX_1ab4fb, msgtype ThermostatState : 18002600CD
2021.08.05 15:54:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.5
2021.08.05 15:54:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-73, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 15:59:07 5: MAX_1ab4fb, msgtype Ack : 01180026
2021.08.05 15:59:07 5: MAX_1ab4fb, msgtype ThermostatState : 180026
2021.08.05 15:59:07 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0
2021.08.05 15:59:07 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-71.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 16:04:52 5: MAX_1ab4fb, msgtype ThermostatState : 18002600CD
2021.08.05 16:04:52 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.5
2021.08.05 16:04:52 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-71.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 16:24:53 5: MAX_1ab4fb, msgtype ThermostatState : 00600DC446
2021.08.05 16:24:53 5: MAX_1ab4fb, desiredTemperature:6.5, rferror:0, battery:0, mode:0, gateway:0, panel:0, dst:0, valveposition:96, curTemp:7
2021.08.05 16:24:53 4: MAX_1ab4fb, desiredTemperature:6.5, rssi:-70.5, rferror:0, battery:0, mode:0, gateway:0, panel:0, dstsetting:0
2021.08.05 16:44:52 5: MAX_1ab4fb, msgtype ThermostatState : 18002600CD
2021.08.05 16:44:52 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.5
2021.08.05 16:44:52 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-71, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 16:54:53 5: MAX_1ab4fb, msgtype ThermostatState : 0DC44607C3
2021.08.05 16:54:53 5: MAX_1ab4fb, desiredTemperature:35, rferror:0, battery:0, mode:1, gateway:0, panel:0, dst:1, valveposition:196, curTemp:45.1
2021.08.05 16:54:53 4: MAX_1ab4fb, desiredTemperature:35.0, rssi:-89.5, rferror:0, battery:0, mode:1, gateway:0, panel:0, dstsetting:1
2021.08.05 17:34:52 5: MAX_1ab4fb, msgtype ThermostatState : 18002600CE
2021.08.05 17:34:52 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.6
2021.08.05 17:34:52 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-73, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 17:54:53 5: MAX_1ab4fb, msgtype ThermostatState : 18002600CE
2021.08.05 17:54:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.6
2021.08.05 17:54:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-66.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 18:14:52 5: MAX_1ab4fb, msgtype ThermostatState : 18002600CF
2021.08.05 18:14:52 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.7
2021.08.05 18:14:52 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-73.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 18:24:52 5: MAX_1ab4fb, msgtype ThermostatState : 18002600D0
2021.08.05 18:24:52 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:20.8
2021.08.05 18:24:52 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-71.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 18:44:53 5: MAX_1ab4fb, msgtype ThermostatState : 180026000F
2021.08.05 18:44:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:1.5
2021.08.05 18:44:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-74, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 19:14:53 5: MAX_1ab4fb, msgtype ThermostatState : 18002600D2
2021.08.05 19:14:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:21
2021.08.05 19:14:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-66.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 19:24:52 5: MAX_1ab4fb, msgtype ThermostatState : 1800
2021.08.05 19:24:52 1: PERL WARNING: Use of uninitialized value $desiredTemperature in bitwise and (&) at ./FHEM/10_MAX.pm line 1304.
2021.08.05 19:24:52 5: MAX_1ab4fb, desiredTemperature:0, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0
2021.08.05 19:24:52 4: MAX_1ab4fb, desiredTemperature:0, rssi:-55, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 19:24:53 5: MAX_1ab4fb, msgtype ThermostatState : 18002600D2
2021.08.05 19:24:53 5: MAX_1ab4fb, desiredTemperature:19, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:0, curTemp:21
2021.08.05 19:24:53 4: MAX_1ab4fb, desiredTemperature:19.0, rssi:-71.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2021.08.05 20:21:23 1: PERL WARNING: Use of uninitialized value in abs at ./FHEM/14_CUL_MAX.pm line 745.
2021.08.05 20:21:23 1: ERROR: empty name in readingsBeginUpdate
2021.08.05 20:21:23 1: stacktrace:
2021.08.05 20:21:23 1: main::readingsBeginUpdate called by fhem.pl (5090)
2021.08.05 20:21:23 1: main::readingsSingleUpdate called by ./FHEM/14_CUL_MAX.pm (911)
2021.08.05 20:21:23 1: FHEM::CUL_MAX::Parse called by fhem.pl (4090)
2021.08.05 20:21:23 1: main::Dispatch called by ./FHEM/00_CUL.pm (975)
2021.08.05 20:21:23 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (840)
2021.08.05 20:21:23 1: main::CUL_Read called by fhem.pl (3894)
2021.08.05 20:21:23 1: main::CallFn called by fhem.pl (773)
2021.08.05 20:21:23 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4944.
2021.08.05 20:21:23 1: readingsUpdate(,PairedTo,180027) missed to call readingsBeginUpdate first.
2021.08.05 20:21:23 1: stacktrace:
2021.08.05 20:21:23 1: main::readingsBulkUpdate called by fhem.pl (5091)
2021.08.05 20:21:23 1: main::readingsSingleUpdate called by ./FHEM/14_CUL_MAX.pm (911)
2021.08.05 20:21:23 1: FHEM::CUL_MAX::Parse called by fhem.pl (4090)
2021.08.05 20:21:23 1: main::Dispatch called by ./FHEM/00_CUL.pm (975)
2021.08.05 20:21:23 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (840)
2021.08.05 20:21:23 1: main::CUL_Read called by fhem.pl (3894)
2021.08.05 20:21:23 1: main::CallFn called by fhem.pl (773)
2021.08.05 20:21:23 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4680.
interesant ist auch ich habe immer wieder fremde MAX Devices in Fhem wenn ich autocreate an lasse.
Zitat von: benkler am 05 August 2021, 20:31:33
interesant ist auch ich habe immer wieder fremde MAX Devices in Fhem wenn ich autocreate an lasse.
Das und auch deine absolut falschen Werte haben einen gemeinsammen Nenner in 14_CUL_MAX.pm.
Es handelt sich hier um quasi "zerstörte / verstümmelte" Telegramme die nicht als solche erkannt und einfach verworfen werden.
Leider bietet das MAX Protokoll hier recht wenig zur Erkennung. Ich schaue mal ob ich übers WE da noch etwas nachbessern kann.
Ich kann auch bestätigen, dass die aktuelle Beta sehr gut funktioniert.
Ich hab jedoch einige Geräte, welche bei einem getStatus nicht aufwachen. Das sind vor allem Geräte welche kein pairing mit einem fakewt haben.
Weißt du was passiert, wenn die Thermostate keinen ZeitSync bekommen? RFerror?
Hast du probiert den getStatus zu Broadcasten?
Auch ich bin mit der Beta sehr zufrieden.
Ich mache den getStatus mit wenigen Sekunden Abstand 2 mal. Damit bekomme ich alle Werte.
Bitte ins öffentliche Repository ...
DANKE für die viele/gute Arbeit !!
Ich hatte das schonmal hier geschrieben.
Ich habe bemerkt das der Batterieverbrauch sehr hoch ist. Ich musste von dem Heizkörperthermostat alle 3-4 Monate die Batterie austauschen. Kennt das jemand noch?
Hallo neyzen,
so einen hohen Batterieverbrauch habe ich nicht. Ich würde jetzt auf einen Wechsel 1x pro Jahr tippen. Ich verwende "Varta Industrial Pro" Batterien.
Hi,
ist die neue Version schon im SVN?
Habe lokal noch die: 14_CUL_MAX.pm 22175 2020-06-13 17:32:49Z Wzut
Nein, dann wäre hier schon längst dicht !
Da einige so ihre Probleme mit der Beta haben werd ich sie auch so schnell nicht einchecken, ich habe aktuell weder die Zeit noch die Nerven mich mit zig Usern rumzuschlagen bei denen dann irgend etwas nicht mehr so ist wie es nun jahrelang war.
Wer dagegen die Beta inzwischen lieb gewonnen hat (so wie ich) und i.d.R. auch weiss was er da tut, dem stehen nach wie vor die letzten Versionen im ersten Post zur Verfügung.
Hi,
ich setze Deine aktuelle BETA ein. Allerdings habe ich Probleme mit einem getStatus. Ich habe mit einen AT eingerichtet, der alle 5 Minuten einen getStatus an meinem MAX Thermostat sendet
defmod buero.heizung.at at +*00:05:00 set buero.heizung getStatus
Wenn der AT ausgeführt wird, erscheint bei einem Verbose 5 Log folgendes:
2021.12.01 10:42:35.267 5: exec at command buero.heizung.at
2021.12.01 10:42:35.267 4: culmax.remote, send -> cmd:ThermostatState, msgcnt:98, flags:08, Cmd2id:60, src:MAX_123456, dst:buero.heizung, gid:00, payload:00, cul:none
2021.12.01 10:42:35.267 5: culmax.remote, packet to SQH : 0b9808601234561b6c060000
2021.12.01 10:42:35.267 5: culmax.remote, Send Queue : 1 packet are in the queue
2021.12.01 10:42:36.289 5: culmax.remote, Send Queue cul868.remote -> needPreamble: 1, necessaryCredit: 110, credit10ms: cul868.remote = 900, CMD_LAST_H: 109
2021.12.01 10:42:36.289 4: culmax.remote, Send Queue packet send : Zs0b9808601234561b6c060000 to buero.heizung with cul868.remote
2021.12.01 10:42:36.290 5: culmax.remote, Send Queue is now empty
2021.12.01 10:42:36.291 5: redefine at command buero.heizung.at as +*00:05:00 set buero.heizung getStatus
Die Temperatur wird am Device nicht aktulaisiert.
Bei einem manuellen getStatus über die FHEM Oberfläche erscheint folgendes:
2021.12.01 10:47:52.418 4: culmax.remote, send -> cmd:ThermostatState, msgcnt:9b, flags:08, Cmd2id:60, src:MAX_123456, dst:buero.heizung, gid:00, payload:00, cul:none
2021.12.01 10:47:52.418 5: culmax.remote, packet to SQH : 0b9b08601234561b6c060000
2021.12.01 10:47:52.418 5: culmax.remote, Send Queue : 1 packet are in the queue
2021.12.01 10:47:54.255 5: culmax.remote, Send Queue cul868.remote -> needPreamble: 1, necessaryCredit: 110, credit10ms: cul868.remote = 900, CMD_LAST_H: 114
2021.12.01 10:47:54.257 4: culmax.remote, Send Queue packet send : Zs0b9b08601234561b6c060000 to buero.heizung with cul868.remote
2021.12.01 10:47:54.258 5: culmax.remote, Send Queue is now empty
2021.12.01 10:47:54.265 1: [Freezemon] myFreezemon: possible freeze starting at 10:47:53, delay is 1.265 possibly caused by: tmr-fronius_GetInverterRealtimeData(pvs.smartmeter) tmr-at_Exec(haus.strom.at)
2021.12.01 10:47:55.341 4: culmax.remote, C: 00, F: 00, T: 60, S: 1B6C06 D: 123456 G: 00 P: 194F300102
2021.12.01 10:47:55.341 4: culmax.remote, IODev cul868.remote, flags 00, msgcnt 00, msgType ThermostatState, src 1b6c06 HeatingThermostat, dst 123456 CUL_MAX, group 0, payload 194F300102, rssi -50.5
2021.12.01 10:47:55.346 5: culmax.remote: dispatch MAX,1,ThermostatState,1b6c06,194F300102
2021.12.01 10:47:55.346 5: MAX_Parse, MAX,1,ThermostatState,1b6c06,194F300102
2021.12.01 10:47:55.346 5: buero.heizung, msgtype ThermostatState : 194F300102
2021.12.01 10:47:55.346 5: buero.heizung, desiredTemperature:24, rferror:0, battery:0, mode:1, gateway:1, panel:0, dst:1, valveposition:79, curTemp:25.8
2021.12.01 10:47:55.347 4: buero.heizung, desiredTemperature:24.0, rssi:-50.5, rferror:0, battery:0, mode:1, gateway:1, panel:0, dstsetting:1
Kann hier jemand weiterhelfen?
GRuß
Michael
ist unlogisch bzw für mich so direkt nicht nachvollziehbar, da in beiden Fällen das Telegramm ja identisch ist -> Zs0b9808601234561b6c060000
kann ich aber leicht bei mir mal testen.
Warum machst du das überhaupt ? Um den Scanner zu simulieren ?
Zitat von: Wzut am 01 Dezember 2021, 17:00:52
ist unlogisch bzw für mich so direkt nicht nachvollziehbar, da in beiden Fällen das Telegramm ja identisch ist -> Zs0b9808601234561b6c060000
kann ich aber leicht bei mir mal testen.
Warum machst du das überhaupt ? Um den Scanner zu simulieren ?
Ja, wollte den MAXScanner entfernen.
Gerade hat sich mein FHEM verabschiedet:
2021.12.01 18:19:01.387 2: culmax.remote, unknown message type D5 from culmax.remote [123456] to MAX_001900 [123456] - ignoring !
Month '-1' out of range 0..11 at ./FHEM/14_CUL_MAX.pm line 831.
IMHO passen die beiden Zeilen nicht direkt zusammen, das D5 Telegramm wurde laut Log ja schon verworfen.
Zu dem Montatsfehler kann es nur bei gültigem Typ TimeSync aber fehlerhaften/zerstörtem Payload kommen - werde ich in einer der nächsten Versionen noch mit eval kapseln
zum Theme MAX-Scanner ...
ich hatte auch probiert das mit "at" nachzubauen. Funktionierte irgendwie nicht. Ich hatte auch freezes beim Erneuern des AT. Evtl. gibt es da einen Zusammenhang.
Funktionieren tut jetzt sehr gut eine Lösung mit doif
defmod di_MaxScanner DOIF ([+00:05] and [?MAX_TH_16e522:temperature:sec]>3800) \
(set MAX_TH_16e522 wakeUp)\
(set MAX_TH_16e522 getStatus)\
DOELSEIF ([+00:06] and [?MAX_TH_1a9aeb:temperature:sec]>3800) \
(set MAX_TH_1a9aeb wakeUp)\
(set MAX_TH_1a9aeb getStatus)\
DOELSEIF ([+00:07] and [?MAX_TH_190d84:temperature:sec]>3800) \
(set MAX_TH_190d84 wakeUp)\
(set MAX_TH_190d84 getStatus)\
DOELSEIF ([+00:08] and [?MAX_TH_16e560:temperature:sec]>3800)\
(set MAX_TH_16e560 wakeUp)\
(set MAX_TH_16e560 getStatus)\
attr di_MaxScanner do always
attr di_MaxScanner icon helper_doif
attr di_MaxScanner wait 1,5:1,5:1,5
ob ich das wakeUp wirklich brauche, kann ich (noch) nicht sagen. ist ein Überbleibsel von den AT-versuchen.
Mal ein kurzes Fazit zu meinen BETA Tests.
Sobald ich den AT gesetzt hatte, der alle 5 Minuten, an 9 Thermostate ein getStatus gesendet hatte. Hat es nicht lange gedauert bis einige Thermostate komische Werte bei der Temperatur angezeigt hatten. Hier wurden dann z.B. 58 Grad angezeigt. Das Aktualisieren an sich hat auch nicht wirklich funktioniert. Zum Schluss hatte an jedes Thermostat 2x einen getStatus abgesendet. Dazwischen ein sleep von 2 Sekunden. Das hat aber leider auch nicht den gewünschten Erfolg gebracht.
Aktuell bin ich wieder auf der letzten offiziellen SVN Version. Meinem MAXScanner habe ich nicht mehr aktiviert. Stattdessen läuft bei mir folgender AT
+*00:00:30 {
my @Maxs = devspec2array("TYPE=MAX");
my $DeviceAge ;
my $DeviceTemp;
my $DeviceModeAge;
#fhem "set culmax.remote deleteSendQueue";
foreach my $MaxDevice (@Maxs) {
$DeviceAge = ReadingsAge($MaxDevice,"temperature",0);
$DeviceModeAge = ReadingsAge($MaxDevice,"mode","0");
$DeviceTemp = ReadingsVal($MaxDevice, "desiredTemperature", "19.0");
#fhem "setreading $MaxDevice 00_ReadingsAge $DeviceAge";
#Log3 "watchdog",3,"CHECK MAX $MaxDevice $DeviceAge";
if ($DeviceAge >= 1000) {
if (ReadingsVal($MaxDevice, "sendmessage", "0") ne "1") {
fhem "set teleBot message $GroupChar$MichaelID MAX Device $MaxDevice defekt";
fhem "setreading $MaxDevice sendmessage 1";
if ($DeviceModeAge >= 180) {
if (ReadingsVal($MaxDevice, "mode", "unbekannt") eq "auto") {
fhem "set $MaxDevice desiredTemperature $DeviceTemp";
}
else {
fhem "set $MaxDevice desiredTemperature auto";
}
}
}
}
elsif ($DeviceAge >= 300) {
if ($DeviceModeAge >= 180) {
if (ReadingsVal($MaxDevice, "mode", "unbekannt") eq "auto") {
fhem "set $MaxDevice desiredTemperature $DeviceTemp";
}
else {
fhem "set $MaxDevice desiredTemperature auto";
}
}
}
else {
fhem "setreading $MaxDevice sendmessage 0";
}
$DeviceAge = ReadingsAge($MaxDevice,"temperature",0);
fhem "setreading $MaxDevice 00_ReadingsAge $DeviceAge";
}
}
Sollte sich an der BETA wieder was tun, bin ich gerne bereit wieder zu testen.
Gruß
Michael
Die komischen Werte hatte die Tage auch 2x beobachtet. Allerdings nach unten (3 °C).
Was mir auch aufgefallen ist:
Ich musste ein neues Thermostat anlernen und wollte das weekprofile abfragen. Das hat leider nicht funktioniert.
Nachdem ich die SVN Versionen der MAX Komponenten genommen habe konnte ich das weekprofile auslesen.
schreiben muss funktioniert haben, da das Thermostat sich auf "Auto" stellen ließ und die richtige Temperatur hatte.
Ich werde versuchen dass ganze nocheinmal nachzustellen und detailiertere Informationen liefern.
Das Problem mit komischen Temperaturen habe ich an einem HT. Er hat die Firmwareversion 1.8 laut Readings.
Ein zweiter HT - identische Konfiguration hat das Problem nicht.
Bei ihm wird in den Readings die Firmwareverson nicht angezeigt, wahrscheinlich eine andere.
Wird die Stausabfrage per AT am ersten HT nicht gemacht, sind die Temperatur-Werte normal. Ich denke da weht der Wind her.
"komische Werte" würde ich ja gerne abfangen, aber :
a. habe ich sie selber nicht
b. scheint mal wieder niemand in der Lage zu sein ein simples verbose 5 Log zu liefern damit ich es mal nachvollziehen kann.
Hi.
Ich habe zwei umgebaute CUBEs im Einsatz.
Immer wenn ich einen Befehl absetze und dabei das IODev geswitcht werden muss, kommt er nicht durch. Setze ich ihn ein zweites Mal geht es sofort.
2022.02.09 04:54:16 4: cm, send -> cmd:SetTemperature, msgcnt:1f, flags:00, Cmd2id:40, src:MAX_123456 , dst:MAX_1c0792 , gid:00 , payload:52 , cul:CULSZ
2022.02.09 04:54:16 5: cm, send packet: 0b1f00401234561c07920052
2022.02.09 04:54:16 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:16 4: cm, Send Queue packet to MAX_1c0792 needs CULSZ but current IODev is CUL0
2022.02.09 04:54:16 4: cm, Send Queue IODev switched to CULSZ with version 154
2022.02.09 04:54:17 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 3000, CULSZ CMD_LAST_H: 12
2022.02.09 04:54:17 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:17 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:18 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:18 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:19 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:19 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:20 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:20 4: cm, Send Queue retry MAX_1c0792 for SetTemperature count: 3
2022.02.09 04:54:23 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:23 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 2897, CULSZ CMD_LAST_H: 13
2022.02.09 04:54:23 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:24 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:24 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:25 5: cm, IODev CUL0, len 15, msgcnt BA, msgflag 04, msgType WallThermostatState, src 1a54cd, dst 000000, group 0, payload 19042400C7, rssi -75.5
2022.02.09 04:54:25 5: cm: dispatch MAX,0,WallThermostatState,1a54cd,19042400C7
2022.02.09 04:54:25 5: MAX_Parse, MAX,0,WallThermostatState,1a54cd,19042400C7
2022.02.09 04:54:25 5: MAX_1a54cd, bat 0, rferror 0, panel 0, langateway 1, dst 1, mode 1, displayActualTemperature 4
2022.02.09 04:54:25 5: MAX_1a54cd, desiredTemperature 18
2022.02.09 04:54:25 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:25 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:26 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:26 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:26 4: cm, Send Queue retry MAX_1c0792 for SetTemperature count: 2
2022.02.09 04:54:30 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:30 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 2794, CULSZ CMD_LAST_H: 14
2022.02.09 04:54:30 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:31 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:31 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:32 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:32 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:33 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:33 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:33 4: cm, Send Queue retry MAX_1c0792 for SetTemperature count: 1
2022.02.09 04:54:36 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:36 5: cm, Send Queue CULSZ -> needPreamble: 1, necessaryCredit: 110, credit10ms: 2691, CULSZ CMD_LAST_H: 15
2022.02.09 04:54:36 4: cm, Send Queue packet send : Zs0b1f00401234561c07920052 to MAX_1c0792 with CULSZ
2022.02.09 04:54:37 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:38 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:38 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:39 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:39 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:40 5: cm, Send Queue 1 packet in queue
2022.02.09 04:54:40 3: cm, Send Queue missing ack from MAX_1c0792 for SetTemperature, removing from queue
2022.02.09 04:54:40 5: cm, Send Queue is now empty
Dabei ist es egal, ob von CUL0 oder von CULSZ geswitcht werden muss.
Ich muss noch erwähnen, das der CULSZ über VPN angebunden ist. Also sind da die Latenzen etwas höher.
Vielleicht habt ihr ja nen Tipp, oder nen Schubs in die richtige Richtung.
Internals:
CUL0_MAXID 123456
CUL0_MSGCNT 3647
CUL0_RAWMSG Z0B8306301A09A61234560010
CUL0_RSSI -65.5
CUL0_TIME 2022-02-09 05:13:13
CUL0_VERSION 154
CULSZ_MAXID 234567
CULSZ_MSGCNT 615
CULSZ_RAWMSG Z0E3402021A8BDF1C07920001190010
CULSZ_RSSI -55
CULSZ_TIME 2022-02-09 05:12:09
CULSZ_VERSION 154
DEF 123456
FUUID 5c44b228-f33f-9a7c-4b3b-a38737fcfd94412c
FVERSION 14_CUL_MAX.pm:0.221750/2020-06-13
IODev CULSZ
IOgrp CUL0,CULSZ
LASTInputDev CUL0
MSGCNT 4262
NAME cm
NR 78
STATE CULSZ:ok,CUL0:ok Last:CUL0
SVN 22175
TYPE CUL_MAX
addr 234567
cnt 0
pairmode 0
retryCount 0
sq 0
READINGS:
2022-02-09 05:03:51 CUL0_cmd_last_h 31
2022-02-09 05:03:51 CUL0_credit10ms 1138
2022-02-09 05:03:14 CUL0_lost 5
2022-02-09 05:03:08 CUL0_retry 16
2022-02-09 05:04:53 CULSZ_cmd_last_h 22
2022-02-09 05:04:53 CULSZ_credit10ms 2103
2022-02-09 05:04:22 CULSZ_lost 5
2022-02-09 05:04:15 CULSZ_retry 15
2022-02-09 05:03:59 IODev CULSZ
2022-02-09 05:02:52 lastTimeSync MAX_0e7611
2022-02-09 05:13:13 state CULSZ:ok,CUL0:ok Last:CUL0
sendQueue:
Attributes:
IOgrp CUL0, CULSZ
alias cm
debug 1
fakeSCaddr 222222
fakeWTaddr 111111
group Netzwerk
room 2.4_Netzwerk
showtime 0
verbose 3
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz*
CUL0_MSGCNT 5913
CUL0_TIME 2022-02-09 05:25:54
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.1.29:2323 1234
DeviceName 192.168.1.29:2323
FD 15
FHTID 1234
FUUID 5c44b228-f33f-9a7c-f087-2ee0161588f64815
FVERSION 00_CUL.pm:0.248150/2021-08-01
NAME CUL0
NR 77
NR_CMD_LAST_H 32
PARTIAL
RAWMSG *s4408A0FF10E6; 464: 8944
RSSI -63
STACKED CUL1
STATE Initialized
TYPE CUL
VERSION V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBEx4_83 (F-Band: 868MHz)
devioNoSTATE 1
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:
2022-02-08 15:02:08 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
2022-02-09 05:03:51 credit10ms 1138
2022-02-09 05:25:54 state Initialized
XMIT_TIME:
1644378481.17689
1644378487.23443
1644378493.76236
1644378500.27874
1644378516.0607
1644378523.20662
1644378718.05272
1644378724.5835
1644378731.14404
1644378737.66231
1644378760.98414
1644378769.18974
1644378775.70119
1644378788.58223
1644378828.84168
1644378835.35139
1644378841.86569
1644378848.40157
1644378892.93436
1644378899.44367
1644378905.96179
1644378912.47768
1644378924.85317
1644378932.81879
1644379143.77931
1644379151.70103
1644379372.68941
1644379379.23086
1644379385.74298
1644379391.80209
1644379399.92632
1644379432.00834
Attributes:
alias CUL0
group Netzwerk
maxid 123456
rfmode MAX
room 2.4_Netzwerk
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
CULSZ_MSGCNT 625
CULSZ_TIME 2022-02-09 05:26:31
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.2.115:2323 1034
DeviceName 192.168.2.115:2323
FD 28
FHTID 1034
FUUID 6162d424-f33f-9a7c-72d3-2b3596175256a614
FVERSION 00_CUL.pm:0.248150/2021-08-01
NAME CULSZ
NR 168
NR_CMD_LAST_H 23
PARTIAL
RAWMSG Z0E3902021A8BDF1C0792000119001025
RSSI -55.5
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
devioNoSTATE 1
initString X21
Zr
Za234567
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:
2022-02-08 15:02:13 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2022-02-09 05:04:53 credit10ms 2103
2022-02-09 05:26:31 state Initialized
XMIT_TIME:
1644378581.35121
1644378587.87557
1644378594.36497
1644378600.89858
1644378796.21791
1644378802.74057
1644378809.27375
1644378815.8118
1644378857.04816
1644378863.55996
1644378870.07037
1644378876.59416
1644379288.64864
1644379295.17716
1644379301.68916
1644379308.1929
1644379370.57035
1644379439.23922
1644379445.76903
1644379452.25892
1644379458.77183
1644379489.48913
1644379493.42967
Attributes:
group Netzwerk
maxid 234567
rfmode MAX
room 2.4_Netzwerk
MfG Manley
Nachtrag:
Mir ist gerade aufgefallen, dass das Paket als Absender den 123456 ( CUL0 ) enthält. Danach erst festgestellt wird, dass das andere IODev (2345467) benutzt werden muss, das Paket aber weiterhin die ID vom CUL0 behält. Klar dass das Ziel dann nicht auf den Befehl reagiert.
Es wird als Absendere immer die ID des zuletzt verwendeten CULs benutzt. Die Überprüfung auf das nötige IODev müsste also erfolgen, bevor das Paket erstellt wird.
Wäre es ein Problem, wenn die Beiden CULs die selbe ID haben? Kann ich frühestens am Freitag testen, da sie räumlich knapp 100km auseinander sind ;)
Hier nochmal ein Auszug wo CULSZ vorher benutzt wurde und er auf CUL0 switcht. (Paket enhält den Absender 234567 und müsste 123456)
2022.02.09 09:24:38 4: cm, send -> cmd:SetTemperature, msgcnt:3b, flags:00, Cmd2id:40, src:MAX_234567 , dst:MAX_19cd91 , gid:00 , payload:6c , cul:CUL0
2022.02.09 09:24:38 5: cm, send packet: 0b3b004023456719cd91006c
2022.02.09 09:24:38 5: cm, Send Queue 1 packet in queue
2022.02.09 09:24:38 4: cm, Send Queue packet to MAX_19cd91 needs CUL0 but current IODev is CULSZ
2022.02.09 09:24:38 4: cm, Send Queue IODev switched to CUL0 with version 154
2022.02.09 09:24:38 5: cm, Send Queue CUL0 -> needPreamble: 1, necessaryCredit: 110, credit10ms: 3600, CUL0 CMD_LAST_H: 3
2022.02.09 09:24:38 4: cm, Send Queue packet send : Zs0b3b004023456719cd91006c to MAX_19cd91 with CUL0
MfG Manley
Zitat von: Manley am 09 Februar 2022, 05:28:29
Wäre es ein Problem, wenn die Beiden CULs die selbe ID haben? Kann ich frühestens am Freitag testen, da sie räumlich knapp 100km auseinander sind ;)
Gleiche ID ist eigentlich der Normalfall ! Zwei verschiedene MAX Wolken unter einer FHEM Instanz schafft nur unötige Probleme und daher habe ich recht schnell jede Unterstützung dafür nicht weiterverfolgt.
Allerdings verstehe ich dein Umfeld mit den 100km gerade überhaupt nicht, wie sollen da die zwei CULs eine sinnvolle Gruppe bilden ?
Der zweite CUL(SZ) steht in meinem Zweitwohnsitz. Ich dachte, dass eine unterschiedliche ID besser wäre für eine deutliche Unterscheidung der Systeme.
Die CULs sollen also gar keine Gruppe bilden :)
ah ok verstehe. Allerdings hast du dann genau das Umfeld das nicht unterstützt wird.
Mögliche Lösungen :
a. gleiche ID verwenden - Nachteil : aufwändig da in einer der beiden Wolken bei allen Geräten ein Werkreset fällig ist.
b. eine zweite FHEM Instanz auf einem anderen Port anlegen und die Zweitwohnung komplett damit verwalten - Vorteil : ist schnell gemacht.
Verstehe.
Da ich am Freitag eh in der anderen Wohnung bin und die Anzahl an Geräten überschaubar ist, werde ich alles auf eine ID setzen.
Eine Zweite Instanz nur für die Paar Maxgeräte ist mir tatsächlich den Aufwand nicht wert. Vor allem hab ich dann nicht alles zusammen.
Danke für die schnelle Hilfe.
MfG Manley
P.s.: vielleicht im HowTo kurz erwähnen, dass beide CULs die gleiche ID haben müssen ;)
Hallo,
habe mit den neuen Modulen ein kleines Problem.
Nachdem wieder mal ein einzelnes MAX-Gerät ausgestiegen ist, habe ich es auf "dummy=1" und "disabled=1" gestellt.
Trotzdem landeten weiterhin Daten für dieses Gerät in der sendQueue.
Verursacht wird das vom selbstgebastelten Scanner:
doif...
(set MAX_TH_16e522 wakeUp)
(set MAX_TH_16e522 getStatus)
Ich dachte, bei gesetzten "dummy"-Attribut werden die Sendeanforderungen einfach verworfen.!?
Wo liegt mein Fehler?
Hallo Wzut,
zwei Dinge, die mir bisher nicht aufgefallen waren:
1) In meiner Installation funktioniert die "Boost"-Funktion an Thermostaten des type=HeatingThermostat (auch unabhängig von der Firmware Version) nicht:
Ein
set MaxThermostat desiredTemperature boost
führt nicht zur Einschaltung des Boost-Modus am Ventil.
Normalerweise daran erkennbar, dass das Reading "mode" auf "boost" geht, das Ventil voll geöffnet wird (wegen boostValveposition=100) und im Display des Thermostats die verbleibende Zeit (von boostDuration) in Minuten und später in Sekunden angezeigt wird.
Ein Ventil im mode=auto verbleibt im "auto"-Modus, Ventile im mode=eco verbleiben im "eco"-Modus, an allen Thermostaten trotz des angezeigten Readings "lastcmd=desiredTemperature boost" leider keinerlei Reaktion.
Mit Thermostaten des type=HeatingThermostatPlus funktioniert die Boost-Funktion vollumfänglich.
Auch scheint es unabhängig vom aktuell CULdev zu sein, habe zwei MaxCube und einen CUL als IOs für MAX im Einsatz.
2) Das Reading "firmware" ist leider nicht bei allen Thermostaten (unabhängig davon ob HeatingThermostat oder HeatingThermostatPlus) vorhanden. Gibt es einen Trick, dieses für alle zu bekommen?
Bitte ach kurze Info, wenn ich weitere Details/Logs liefern sollte.
Vielen Dank und Grüße,
Andreas
1.) klappt bei mir ohne Probleme mit einem normalen HT (ich besitze keine Plus)
hier ein verbose 5 Log :
2022.02.28 16:17:29 4: 2_HT_Esszimmer, _handle_SetTemperature: boost
2022.02.28 16:17:29 5: 2_HT_Esszimmer, SetTemperature: val : boost, gid : 00, pl : c0, flags : 00
2022.02.28 16:17:30 5: 2_HT_Esszimmer, msgtype Ack : 011B502A
2022.02.28 16:17:30 5: 2_HT_Esszimmer, msgtype ThermostatState : 1B502A
2022.02.28 16:17:30 5: 2_HT_Esszimmer, desiredTemperature:21, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:80
2022.02.28 16:17:30 4: 2_HT_Esszimmer, desiredTemperature:21.0, rssi:-59.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:17:30 5: 2_HT_Esszimmer, msgtype AckSetTemperature : boost
sicher das du auch die letzte Version hast ?
Bzw was sagt denn bei dir ein verbose 5 Log ?
2.) firmware ist ein Wert den ich nicht direkt auslesen kann, der Wert wird aber bei jedem Pair-Ping übertragen.
D.h. wenn er verloren gegangen ist (Thema Backup !!) einfach die boost Taste am HT etwas länger drücken (Pairing) dann sollte der fehlende Wert im Reading stehen.
Hallo Wzut,
danke erst einmal für die prompte Rückmeldung.
Nach weiteren Forschungen:
Das unterschiedliche Verhalten scheint nicht am Unterschied HeatingThermostat/HeatingThermostatPlus sondern am gesetzten Attribut "keepAuto=1".
Mit Attribut "keepAuto=1" funktioniert (auch bei HeatingThermostatPlus) kein
set MaxThermostat desiredTemperature boost
Mit Attribut "keepAuto=0" funktioniert es wie oben beschrieben.
Zumindest ich hätte jetzt nicht erwartet, dass dieses Attribut (auch) eine Auswirkung darauf hat ob "boost" funktioniert oder nicht.
"keepAuto=1" finde ich eigentlich ziemlich sinnvoll, um das Wochenprogramm als "führend" zu behalten.
Oder gibt es eine andere Art das Wochenprogramm als "führend" zu behalten und "boosten" zu ermöglichen?
Ein "manuelles"
attr MaxThermostat keepAuto 0
set MaxThermostat desiredTemperature boost
<Warte bis boostDuration vorbei>
attr MaxThermostat keepAuto 1
würde ich gerne vermeiden.
Hier verbose 5 Log mit "keepAuto=1" (es wird keine Boost-Funktion am HT ausgelöst):
2022.02.28 16:51:11.256 4: WZOG_MT, _handle_SetTemperature: boost
2022.02.28 16:51:11.256 5: WZOG_MT, SetTemperature: keepAuto and mode auto = staying in auto mode
2022.02.28 16:51:11.326 5: WZOG_MT, SetTemperature: val : boost, gid : 17, pl : 00, flags : 04
2022.02.28 16:51:12.435 5: WZOG_MT, msgtype Ack : 01181228
2022.02.28 16:51:12.435 5: WZOG_MT, msgtype ThermostatState : 181228
2022.02.28 16:51:12.436 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:18
2022.02.28 16:51:12.437 4: WZOG_MT, desiredTemperature:20.0, rssi:-59.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2022.02.28 16:51:12.616 5: WZOG_MT, msgtype Ack : 01181228
2022.02.28 16:51:12.616 5: WZOG_MT, msgtype ThermostatState : 181228
2022.02.28 16:51:12.616 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:0, gateway:1, panel:0, dst:1, valveposition:18
2022.02.28 16:51:12.617 4: WZOG_MT, desiredTemperature:20.0, rssi:-46.5, rferror:0, battery:0, mode:0, gateway:1, panel:0, dstsetting:1
2022.02.28 16:51:12.838 5: WZOG_MT, msgtype AckSetTemperature : boost
Hier verbose 5 Log mit "keepAuto=0" (es wird Boost-Funktion am HT ausgelöst):
022.02.28 16:52:57.702 4: WZOG_MT, _handle_SetTemperature: boost
2022.02.28 16:52:57.773 5: WZOG_MT, SetTemperature: val : boost, gid : 17, pl : c0, flags : 04
2022.02.28 16:52:58.888 5: WZOG_MT, msgtype Ack : 011B6428
2022.02.28 16:52:58.888 5: WZOG_MT, msgtype ThermostatState : 1B6428
2022.02.28 16:52:58.888 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:100
2022.02.28 16:52:58.889 4: WZOG_MT, desiredTemperature:20.0, rssi:-60.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:52:59.061 5: WZOG_MT, msgtype Ack : 011B6428
2022.02.28 16:52:59.061 5: WZOG_MT, msgtype ThermostatState : 1B6428
2022.02.28 16:52:59.061 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:100
2022.02.28 16:52:59.062 4: WZOG_MT, desiredTemperature:20.0, rssi:-46.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:52:59.237 5: WZOG_MT, msgtype Ack : 011B6428
2022.02.28 16:52:59.238 5: WZOG_MT, msgtype ThermostatState : 1B6428
2022.02.28 16:52:59.238 5: WZOG_MT, desiredTemperature:20, rferror:0, battery:0, mode:3, gateway:1, panel:0, dst:1, valveposition:100
2022.02.28 16:52:59.239 4: WZOG_MT, desiredTemperature:20.0, rssi:-96.5, rferror:0, battery:0, mode:3, gateway:1, panel:0, dstsetting:1
2022.02.28 16:52:59.404 5: WZOG_MT, msgtype AckSetTemperature : boost
2) Alles klar, danke für den Tipp zur Auslösung des Pair-Pings als eine Möglichkeit Readings wieder zu bekommen.
Viele Grüße,
Andreas
Das mit dem keepAuto klingt zwar komisch, ist aber richtig !
Irgendwann ist beim Code aufräumen ein else mit entsprechenden Klammern untergegangen, dadurch wird der controlmode von 3 (boost) wieder auf 0 (auto) gesetzt wenn gleichzeitig keepAuto = 1 ist.
Zitat von: Wzut am 01 März 2022, 11:05:53
Das mit dem keepAuto klingt zwar komisch, ist aber richtig !
Hallo Wzut,
danke für die Info.
Habe es aber nicht so ganz verstanden.
Ist es "richtig", weil es aktuell im Code so hinterlegt ist und korrekt so ausgeführt wird?
Aber eigentlich ist durch das Code-Aufräumen nun dieses Verhalten so?
In diesem Fall, wirst Du es auf den Stand "boost funktioniert bei keepAuto=1" ändern?
Danke für eine kurze Rückmeldung.
Viele Grüße,
Andreas
Ich wollte mit einem DOIF den Status von mehreren Ventilen auslesen. Also:
define MaxSetStatusDummy DOIF ([+:05])(set MAX_TV_Eingang getStatus, set MAX_TV_Kueche getStatus, ...)
attr MaxSetStatusDummy do always
Das sendet an alle Ventile ein getStatus, gibt aber vermutlich ein Chaos im Äter, wenn alle Ventile gleichzeitig brüllen. Die Werte kommen nur von einzelnen Ventilen an.
DOIF kennt das "Wait" zwischen Kommandos. Dieses funktioniert aber nur bein eventgesteuerten DOIFs, nicht bei zeitgesteuerten.
Mein Umweg:
Ich habe einen Dummy definiert:
define MaxGetStatusEventTimer dummy
attr MaxGetStatusEventTimer event-on-change-reading state
attr MaxGetStatusEventTimer setList 0 1
Ein erstes DOIF setzt periodisch den Status des Dummy:
define MaxSetStatusDummy DOIF ([+:10])(set MaxGetStatusEventTimer 1)
attr MaxSetStatusDummy do always
Dies generiert ein Event, welche in einem zweiten Dummy verarbeitet wird. Zwischen den Kommandos wird hier 15s gewartet:
define MaxGetStatus DOIF ([MaxGetStatusEventTimer]) (set MAX_TV_Eingang getStatus) ... (set MAX_TV_Estrich getStatus)(set MaxGetStatusEventTimer 0)
attr MaxGetStatus do always
attr MaxGetStatus wait 0,15,15,15,...,15
Zuletzt wird der Dummy auf 0 zurückgesetzt.
Ein gebastel, aber es Funktioniert!
VIELEN DANK an wzut für das Modul!
Zitat von: thomasgloor am 04 März 2022, 13:38:56
Ein gebastel, aber es Funktioniert!
Ich verwende DOIF aus Prinzip nicht, hätte ich dieses "Problem" lösen müssen hätte ich eine LightScene definiert und den Abfrageabstand mit dem Attribut async_delay festgelegt.
Kurze Rückmeldung nach einer guten Woche Betrieb mit den Beta-Modulen: Es läuft soweit alles, d.h. meine Heizungsthermostate melden sinnvolle Werte, genau wie die Fenstersensoren. Auch das Senden eines neuen weekprofile an einen Thermostat hat funktioniert. In den Logs steht nichts Beunruhigendes. Ich gehe daher beruhigt in die kommende Heizperiode.
Die neue Abfragemöglichkeit für die Temperatur und Ventilstellung ist sehr willkommen. Ich habe vor, sie in meiner TabletUI-Installation zu nutzen - ein regelmäßiges Protokoll brauche ich nicht, aber wenn ich mir meine Übersicht ansehe, sind aktuelle Temperaturen natürlich eine sinnvolle Info.
Danke dafür!
Hi, auch ich habe die Beta-Module installiert und sie laufen gut. Keine beunruhigenden Effekte.
Eigentlich ist diese Beta ja schon recht alt - oder vielleicht besser reif :-) Wann soll es denn in die offizielle Distribution ausgenommen werden?
Und, bei dieser Gelegenheit : Vielen Dank für das Ausbauen und Weiterentwickeln der Software !
VG WIlly
Dem kann ich nur zustimmen.
Nutze die Beta jetzt seit mehr als 1/2 Jahr.
Keine Probleme.
Und ebenfalls ... DANKE!
Ich habe hier bisher nur mitgelesen, werde ab die Beta mal auf einem zweiten System testen. Ganz herzlichen Dank für die Arbeit!
Hallo zusammen,
Ist die Boost-Funktion absichtlich verändert?
Ein "set mymaxHT desiredTemperature boost" stellt die Temperatur auf 30Grad, aber der HT zählt nicht runter und die Boost-valve-einstellung wird auch nicht eingestellt.
Ob das HT nach der "boostDuration" zurückstellt, kann ich (noch) nicht sagen.
Danke Dirk
Zitat von: dirk.k am 29 Oktober 2022, 17:13:59
Ist die Boost-Funktion absichtlich verändert?
Zumindest nicht mit Absicht, muss ich bei Gelgenheit mal testen, da ich das selbst via FHEM nie nutze
@Wzut,
Ich benutze die Beta-Versionen jetzt seit vielen Monaten. Vielen Dank für die ganze Arbeit! Mithilfe der neuen Readings peerList /peerIDs konnte ich einige Fehler finden und korrigieren, die ich mit associate gemacht habe. Das hat Ruhe in die Meldungen im Logfile gebracht.
Eine Fehlermeldung bleibt:
Ich habe einen WT und ein oder mehrere HTs in meinen Räumen. Ein Wochenprofil wurde erstellt und an die WT und an die HTs übertragen. Jedes Mal, wenn ich nun die Temperatur an einem WT oder an einem HT manuell ändere, erhalte ich die Meldung:
2022.12.18 12:47:33 3: MAX_Parse, message for undefined device 123456 and failed to guess devicetype from msg SetTemperature - ignoring !
Die Logmeldungen kommen auch ab und zu spontan, auch wenn keine Temperaturänderung vorliegt.
Haben Sie eine Idee, woran das liegen könnte?
Hiermit die Liste der WT, HT (von der Küche: 1 x WT, 1 x HT) und der cm.
WT:
Internals:
DEF WallMountedThermostat 14aa93
FUUID 5c51ecea-f33f-5a50-ef0e-abad56571355c237
IODev cm
LASTInputDev cm
MSGCNT 22492
NAME MAX_WT_Keuken
NOTIFYDEV global
NR 211
NTFY_ORDER 50-MAX_WT_Keuken
STATE 19.0
SVN BETA_28032021
TYPE MAX
TimeSlot -1
addr 14aa93
cm_MSGCNT 22492
cm_TIME 2022-12-18 16:57:26
devtype 3
eventCount 22358
type WallMountedThermostat
OLDREADINGS:
READINGS:
2022-11-06 14:15:23 IODev cm
2022-04-01 12:33:22 PairedTo 123456
2022-12-18 16:57:26 RSSI -62
2022-04-01 12:33:22 SerialNr MEQ1790762
2016-05-20 21:36:11 TimeInformationHour 4
2022-12-18 12:30:27 battery ok
2022-12-18 12:30:27 batteryState ok
2022-12-18 16:57:26 desired-temp 19.0
2022-12-18 16:57:26 desiredTemperature 19.0
2022-12-18 16:57:26 deviation 0.4
2022-12-18 12:30:27 displayActualTemperature 1
2022-04-01 12:33:22 firmware 1.0
2022-12-18 12:30:27 gateway 1
2019-08-22 16:55:25 groupid 2
2022-10-30 02:32:49 lastTimeSync 2022-10-30 02:32:49
2022-12-15 12:11:27 lastcmd ConfigWeekProfile
2022-12-18 12:30:27 mode auto
2022-12-15 12:11:20 msgcnt 75
2022-12-18 12:30:27 panel unlocked
2022-12-18 16:57:26 peerIDs 000000,0be904,0f890e,0f8955
2022-12-18 16:57:26 peerList Broadcast,MAX_0be904,MAX_0f890e,MAX_CV_Keuken
2022-12-11 16:08:35 peers 0f8955
2022-12-18 12:30:27 rferror 0
2022-12-18 16:57:26 state 19.0
2022-12-18 16:57:26 temperature 19.4
2022-04-01 12:33:22 testresult 0
2022-12-15 12:11:27 weekprofile-0-Sat-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2022-12-15 12:11:27 weekprofile-0-Sat-time 00:00-07:30 / 07:30-11:00 / 11:00-17:30 / 17:30-18:30 / 18:30-23:55 / 23:55-24:00
2022-12-15 12:11:27 weekprofile-1-Sun-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2022-12-15 12:11:27 weekprofile-1-Sun-time 00:00-07:30 / 07:30-08:30 / 08:30-12:30 / 12:30-20:00 / 20:00-23:55 / 23:55-24:00
2022-12-15 12:11:27 weekprofile-2-Mon-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2022-12-15 12:11:27 weekprofile-2-Mon-time 00:00-07:30 / 07:30-08:30 / 08:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2022-12-15 12:11:27 weekprofile-3-Tue-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2022-12-15 12:11:27 weekprofile-3-Tue-time 00:00-07:30 / 07:30-08:30 / 08:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2022-12-15 12:11:27 weekprofile-4-Wed-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2022-12-15 12:11:27 weekprofile-4-Wed-time 00:00-07:30 / 07:30-08:30 / 08:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2022-12-15 12:11:27 weekprofile-5-Thu-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2022-12-15 12:11:27 weekprofile-5-Thu-time 00:00-07:30 / 07:30-09:30 / 09:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2022-12-15 12:11:27 weekprofile-6-Fri-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2022-12-15 12:11:27 weekprofile-6-Fri-time 00:00-07:30 / 07:30-09:30 / 09:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
helper:
dt 19.0
myday 6
io:
CUL1:
raw Z0CAA044214AA930F89550026C2
rssi -62
time 1671379046.66604
hmccu:
Attributes:
IODev cm
group Kamertempinstelling
keepAuto 1
model WallMountedThermostat
room Keuken
HT:
Internals:
DEF HeatingThermostat 0f8955
FUUID 5c51ecea-f33f-5a50-efc1-331293c12df70d3a
IODev cm
LASTInputDev cm
MSGCNT 22498
NAME MAX_CV_Keuken
NOTIFYDEV global
NR 230
NTFY_ORDER 50-MAX_CV_Keuken
STATE 19.0
SVN BETA_28032021
TYPE MAX
TimeSlot -1
addr 0f8955
cm_MSGCNT 22498
cm_TIME 2022-12-18 16:57:26
devtype 1
eventCount 21202
type HeatingThermostat
OLDREADINGS:
READINGS:
2022-11-06 14:15:23 IODev cm
2022-01-20 08:54:13 PairedTo 123456
2022-12-18 16:57:26 RSSI -69
2022-01-20 08:54:13 SerialNr LEQ1004619
2015-11-06 21:11:18 TimeInformationHour 2
2022-12-18 16:57:26 battery ok
2022-12-18 16:57:26 batteryState ok
2015-11-06 21:54:01 boostDuration 5
2015-11-06 21:54:01 boostValveposition 80
2020-05-14 21:27:02 comfortTemperature 21
2015-11-06 21:54:01 decalcification Sat 12:00
2022-12-18 16:57:26 desired-temp 19.0
2022-12-18 16:57:26 desiredTemperature 19.0
2022-12-18 16:53:36 deviation 0.2
2020-05-14 21:27:02 ecoTemperature 17
2020-05-14 21:27:02 error invalid or missing value for READING windowOpenDuration
2022-01-20 08:54:13 firmware 1.0
2022-12-18 16:57:26 gateway 1
2020-03-22 10:30:12 groupid 2
2020-05-14 21:27:02 lastConfigSave ./log/MAX_CV_Keuken.max
2022-05-13 02:37:31 lastTimeSync 2022-05-13 02:37:31
2022-12-08 18:58:27 lastcmd associate 14aa93
2015-11-06 22:57:47 maxValveSetting 100
2020-05-14 21:27:02 maximumTemperature on
2020-05-14 21:27:02 measurementOffset 0
2020-05-14 21:27:02 minimumTemperature off
2022-12-18 16:57:26 mode auto
2022-12-16 18:27:54 msgcnt 90
2016-05-20 21:21:30 onlyAutoMode 0
2022-12-18 16:57:26 panel unlocked
2022-12-18 16:57:26 peerIDs 000000,14aa93
2022-12-18 16:57:26 peerList Broadcast,MAX_WT_Keuken
2022-12-08 18:58:27 peers 14aa93
2022-12-18 16:57:26 rferror 0
2022-12-18 16:57:26 state 19.0
2022-12-18 16:53:36 temperature 19.2
2022-01-20 08:54:13 testresult 161
2015-11-06 21:54:01 valveOffset 0
2022-12-18 16:57:26 valveposition 0
2020-11-10 21:13:05 weekprofile-0-Sat-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2020-11-10 21:13:05 weekprofile-0-Sat-time 00:00-07:30 / 07:30-11:00 / 11:00-17:30 / 17:30-18:30 / 18:30-23:55 / 23:55-24:00
2020-11-10 21:13:05 weekprofile-1-Sun-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2020-11-10 21:13:05 weekprofile-1-Sun-time 00:00-07:30 / 07:30-08:30 / 08:30-12:30 / 12:30-20:00 / 20:00-23:55 / 23:55-24:00
2020-11-10 21:13:05 weekprofile-2-Mon-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2020-11-10 21:13:05 weekprofile-2-Mon-time 00:00-05:15 / 05:15-08:30 / 08:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2020-11-10 21:13:05 weekprofile-3-Tue-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2020-11-10 21:13:05 weekprofile-3-Tue-time 00:00-05:15 / 05:15-08:30 / 08:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2020-11-10 21:13:05 weekprofile-4-Wed-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2020-11-10 21:13:05 weekprofile-4-Wed-time 00:00-05:15 / 05:15-08:30 / 08:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2020-11-10 21:13:05 weekprofile-5-Thu-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2020-11-10 21:13:05 weekprofile-5-Thu-time 00:00-08:30 / 08:30-09:30 / 09:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2020-11-10 21:13:05 weekprofile-6-Fri-temp 15.0 °C / 19.0 °C / 17.0 °C / 19.0 °C / 15.0 °C / 15.0 °C
2020-11-10 21:13:05 weekprofile-6-Fri-time 00:00-08:30 / 08:30-09:30 / 09:30-16:30 / 16:30-19:00 / 19:00-23:55 / 23:55-24:00
2020-05-14 21:27:02 windowOpenDuration 15
2020-05-14 21:27:02 windowOpenTemperature 12
helper:
io:
CUL1:
raw Z0EAA02020F895514AA930001180026
rssi -69
time 1671379046.71354
hmccu:
Attributes:
IODev cm
event-on-change-reading .*
keepAuto 1
model HeatingThermostat
room Keuken
cm:
Internals:
DEF 123456
FUUID 5c51ece4-f33f-5a50-a54e-f2f8809a0face3c6
IODev CUL1
LASTInputDev cm
MSGCNT 166
NAME cm
NOTIFYDEV global
NR 54
NTFY_ORDER 50-cm
STATE CUL1:ok
SVN 28032021
TYPE CUL_MAX
addr 123456
cm_MSGCNT 166
cm_TIME 2022-12-18 12:47:33
cnt 0
eventCount 13009
pairmode 0
retryCount 0
sq 0
READINGS:
2022-11-06 14:15:24 IODev CUL1
2022-12-10 16:29:59 error Send Queue NACK from MAX_WT_Woonkamer for RemoveLinkPartner
2022-12-18 14:15:30 msgcnt 85
2020-04-26 22:23:34 packetsLost 546
2022-12-18 16:58:58 state CUL1:ok
helper:
asso:
CUL1 IO
MAX_0f474c Dispatch
MAX_149a00 Dispatch
MAX_345600 Dispatch
MAX_55af00 Dispatch
MAX_55af0f Dispatch
MAX_55af12 Dispatch
MAX_850b01 Dispatch
MAX_CV_Badkamer Dispatch
MAX_CV_Keuken Dispatch
MAX_CV_Vliering_A Dispatch
MAX_CV_Vliering_V Dispatch
MAX_CV_Woonkamer_L Dispatch
MAX_CV_Woonkamer_Rr Dispatch
MAX_CV_Woonkamer_VL Dispatch
MAX_CV_Woonkamer_VM Dispatch
MAX_CV_Woonkamer_VR Dispatch
MAX_Luchtdrogerschakelaar Dispatch
MAX_RC_Badkamer Dispatch
MAX_WT_Badkamer Dispatch
MAX_WT_Keuken Dispatch
MAX_WT_Vliering_A Dispatch
MAX_WT_Vliering_V Dispatch
MAX_WT_Woonkamer Dispatch
MAX_f34000 Dispatch
hmccu:
sendQueue:
Attributes:
IODev CUL1
verbose 3
Dann habe ich noch eine Frage. Die set-Menüs von HT und WT enthalten den Menüpunkt wakeUp.
Wofür wird das verwendet?
Gruß,
Sibbe
Irgend eines deiner Geräte "meint" die Änderung an ein anderes Gerät mit der MAX_ID 12346 schicken zu müssen, allerdings ist diese ID ja die Basisadresse deines cm !
Keine Ahnung was da irgendwann mal beim Peering schief gelaufen ist. Ich würde erst einmal verbose auf 5 beim cm Device setzen um zu sehen wer der Absender ist.
Danach hilft vermutlich nur ein Werksreset um dessen Peer Liste wieder sauber zu bekommen.
@Wzut
Vielen Dank für Ihre Antwort und ein Rückmeldung.
Ich habe zu Hause getestet und ich denke das beim Peering sehr vieles ist schief gelaufen!
Bei mir zu Hause (5 x WT, 9 x HT) erscheint bei jeder Änderung der Solltemperatur folgende Meldung:
2022.12.26 15:02:14 3: MAX_Parse, message for undefined device 123456 and failed to guess devicetype from msg SetTemperature - ignoring !
Die Meldung kommt, wenn ich bei einem WT die Solltemperatur ändere, aber auch wenn ich bei einem HT die Solltemperatur ändere.
Ändere ich die Solltemperatur in FHEM, kommt keine Meldung.
Im Haus meiner Tochter habe ich 5 WT's und 6 HT's montiert.
Auch dort habe ich getestet, die Solltemperatur an allen WT's und HT's zu ändern.
Auch dort erscheint diese Meldung bei jeder Änderung.
Ein kleines Teil des Logs mit Verbose auf 5:
2022.12.26 15:02:14 4: cm, C: C4, F: 00, T: 02, S: 123456 D: 14AA91 G: 00 P: 00
2022.12.26 15:02:14 4: cm, IODev CUL1, flags 00, msgcnt C4, msgType Ack, src 123456 CUL_MAX, dst 14aa91 WallMountedThermostat, group 0, payload 00, rssi -74
2022.12.26 15:02:14 4: cm, packet from ourselves -> 123456 - ignoring !
2022.12.26 15:02:14 4: cm, C: C4, F: 05, T: 40, S: 14AA91 D: 123456 G: 00 P: 1F
2022.12.26 15:02:14 4: cm, IODev CUL1, flags 05, msgcnt C4, msgType SetTemperature, src 14aa91 WallMountedThermostat, dst 123456 CUL_MAX, group 0, payload 1F, rssi -58
2022.12.26 15:02:14 5: cm: dispatch MAX,1,SetTemperature,14aa91,1F,14aa91-123456
2022.12.26 15:02:14 5: MAX_Parse, MAX,1,SetTemperature,14aa91,1F,14aa91-123456
2022.12.26 15:02:14 5: cm: dispatch MAX,1,SetTemperature,123456,1F,14aa91-123456
2022.12.26 15:02:14 5: MAX_Parse, MAX,1,SetTemperature,123456,1F,14aa91-123456
2022.12.26 15:02:14 3: MAX_Parse, message for undefined device 123456 and failed to guess devicetype from msg SetTemperature - ignoring !
2022.12.26 15:02:14 4: cm, C: C4, F: 00, T: 40, S: 14AA91 D: 149A31 G: 00 P: 1F
2022.12.26 15:02:14 4: cm, IODev CUL1, flags 00, msgcnt C4, msgType SetTemperature, src 14aa91 WallMountedThermostat, dst 149a31 HeatingThermostat, group 0, payload 1F, rssi -57.5
2022.12.26 15:02:14 5: cm: dispatch MAX,0,SetTemperature,14aa91,1F,14aa91-149a31
2022.12.26 15:02:14 5: MAX_Parse, MAX,0,SetTemperature,14aa91,1F,14aa91-149a31
2022.12.26 15:02:14 5: cm: dispatch MAX,0,SetTemperature,149a31,1F,14aa91-149a31
2022.12.26 15:02:14 5: MAX_Parse, MAX,0,SetTemperature,149a31,1F,14aa91-149a31
2022.12.26 15:02:14 4: cm, C: C4, F: 02, T: 02, S: 149A31 D: 14AA91 G: 00 P: 0118001F
2022.12.26 15:02:14 4: cm, IODev CUL1, flags 02, msgcnt C4, msgType Ack, src 149a31 HeatingThermostat, dst 14aa91 WallMountedThermostat, group 0, payload 0118001F, rssi -56.5
2022.12.26 15:02:14 4: cm, ACK from [149a31] HeatingThermostat MAX_CV_Vliering_V to [14aa91] WallMountedThermostat MAX_WT_Vliering_V
2022.12.26 15:02:14 5: cm: dispatch MAX,0,Ack,149a31,0118001F
2022.12.26 15:02:14 5: MAX_Parse, MAX,0,Ack,149a31,0118001F
und
2022.12.26 15:02:51 4: cm, C: C6, F: 02, T: 02, S: 14AA91 D: 149A31 G: 00 P: 010BC704
2022.12.26 15:02:51 4: cm, IODev CUL1, flags 02, msgcnt C6, msgType Ack, src 14aa91 WallMountedThermostat, dst 149a31 HeatingThermostat, group 0, payload 010BC704, rssi -81.5
2022.12.26 15:02:51 4: cm, ACK from [14aa91] WallMountedThermostat MAX_WT_Vliering_V to [149a31] HeatingThermostat MAX_CV_Vliering_V
2022.12.26 15:02:51 5: cm: dispatch MAX,0,Ack,14aa91,010BC704
2022.12.26 15:02:51 5: MAX_Parse, MAX,0,Ack,14aa91,010BC704
2022.12.26 15:02:51 5: MAX_WT_Vliering_V, desiredTemperature:4, rferror:0, battery:0, mode:3, gateway:0, panel:0, dst:1, dATemperature:199
2022.12.26 15:02:51 4: cm, C: 31, F: 14, T: AA, S: 910003 D: 1F880E G: C7 P: 020214AA91149A31000118041E
2022.12.26 15:02:51 2: cm, unknown message type AA from MAX_910003 [910003] to MAX_1f880e [910003] - ignoring !
2022.12.26 15:02:51 4: cm, C: 14, F: 9A, T: 31, S: 14AA91 D: 001E20 G: 87 P: 879A3114AA9100032587C60202
2022.12.26 15:02:51 2: cm, unknown message type 31 from MAX_WT_Vliering_V [14aa91] to MAX_001e20 [14aa91] - ignoring !
2022.12.26 15:02:52 4: cm, C: C7, F: 04, T: F1, S: 149A31 D: 14AA91 G: 00 P: 03
2022.12.26 15:02:52 4: cm, IODev CUL1, flags 04, msgcnt C7, msgType WakeUp, src 149a31 HeatingThermostat, dst 14aa91 WallMountedThermostat, group 0, payload 03, rssi -58.5
2022.12.26 15:02:52 5: cm, WakeUp send : MAX_WT_Vliering_V, 01180104, src 149a31, msgcnt C7
2022.12.26 15:02:52 4: cm, send -> cmd:Ack, msgcnt:C7, flags:02, Cmd2id:02, src:MAX_WT_Vliering_V, dst:MAX_CV_Vliering_V, gid:00, payload:01180104, cul:none
2022.12.26 15:02:52 5: cm, packet to SQH : 0eC7020214aa91149a310001180104
2022.12.26 15:02:52 5: cm, Send Queue : 1 packet are in the queue
2022.12.26 15:02:52 5: cm, Send Queue CUL1 -> needPreamble: 1, necessaryCredit: 112, credit10ms: CUL1 = 3501, CMD_LAST_H: 1
2022.12.26 15:02:52 4: cm, Send Queue packet send : Zs0eC7020214aa91149a310001180104 to MAX_CV_Vliering_V with CUL1
2022.12.26 15:02:52 5: cm, Send Queue is now empty
Ich habe in die vielen Informationen nach einem "fremden" Absender gesucht, aber im Log nur die relevanten WT, HT und FHEM gefunden. Und soweit ich das verstanden habe, handelt es sich um Benachrichtigungen, dass, wenn ich die Solltemperatur an einem WT ändere, eine Benachrichtigung vom WT an den associated HT gesendet wird und FHEM mithört. Bei einer Änderung an einem HT sehe ich eine Benachrichtigung an das associated WT und FHEM hört mit.
Die Temperaturänderungen werden in den HTs, WTs und in FHEM durchgeführt !
Ihr Rat, die WTs und HTs auf Werkseinstellungen zurückzusetzen, tue Ich nach der Heizsaison.
Ich habe verbose vorerst auf 2 gesetzt.
Gruß,
Sibbe
Hallo Wzut,
es ist wirklich toll zu lesen, dass du nach wie vor aktiv an den MAX! Komponenten bastelst!
Ich wollte mich endlich mal an die grafische Darstellung meiner Max WT/HT's machen und bin durch Zufall auf den Thread gestoßen.
Sind denn die neuen Beta Module bereits im aktuellen FHEM Release vorhanden und nutze ich Sie vielleicht schon oder ist noch eine manuelle Installation nötig?
Was empfiehlst du denn als aktuell beste Möglichkeit die Temperaturverläufe inkl. Ventilstellungen und alles was dazu gehört möglichst resourcenschonend zu plotten? Den MAX Temperatur Scanner? Gibt es hierzu eine aktuellste Anleitung dazu oder alles wie in den alten WIKI Einträgen beschrieben?
Vielen Dank noch Mal für die tolle Arbeit von dir! Wirklich bemerkenswert und froh, dass auch die alten ELV Komponenten noch ihren guten Dienst erfüllen können!
Gruß sTaN
auch ich möchte mich herzlich bei Wzut bedanken.
Das Plotten geht wunderbar mit GPLOT.
Auf Wunsch kann ich *.Confs zur Verfügung stellen.
Ich habe welche Für WT,HT,FK.
Gruß Thomas
Danke Thomas,
bin sehr interessiert an anderen Lösungen, wobei das vermutlich den Thread hier sprengt. Aus diesem Grund habe ich mal einen separaten Beitrag dazu aufgemacht:
https://forum.fhem.de/index.php/topic,131367.0.html
Würde mich freuen, wenn du und andere auch die Lösungen dort teilst!
Gruß
sTaN
Hallo Wzut,
meine ursprüngliche Frage hat sich ja zum Teil erledigt, da ich selbst festgestellt hatte, dass die Beta scheinbar noch kein offizieller Bestandteil in FHEM ist:
Zitat von: sTaN am 03 Januar 2023, 23:36:53
Sind denn die neuen Beta Module bereits im aktuellen FHEM Release vorhanden und nutze ich Sie vielleicht schon oder ist noch eine manuelle Installation nötig?
Ist denn hier deinerseits noch etwas geplant? Ich hatte zwar die Beta manuell installiert und die 3 MAX Module aus dem fhem update excluded, aber wäre natürlich toll, wenn dies offiziell weitergepflegt wird, falls überhaupt nötig.
Gibt es außer diesem Thread noch weitere Beiträge oder aktuelle Doku, die die Unterschiede und Vorteile der Beta etwas erläutern?
Vielleicht auch ein paar Tipps und Tricks, wie man seine MAX Konfiguration analysieren, aufräumen bzw. optimieren könnte?
Ich bin damals auf CUL_MAX umgestiegen und teilweise hab ich z.B.: das Reading peers und teilweise auch unbekannte Geräte (trotz autocreate disabled) und teilweise gar kein Reading peers. Hab zwar schon in diesem [urlhttps://forum.fhem.de/index.php/topic,129443.msg1238000.html#msg1238000]Thread[/url] die Unterschiede der Readings peerList, peerID und peers gelesen, aber dennoch ist es mir nicht ganz klar, wie es idealerweise aussehen sollte und ob eine Bereinigung sinnvoll ist, um ggf. Fehlermeldungen wie z.B.:
CM_Parse, unhandled message type 08 from MAX_02021a to MAX_6c4e19 - ignoring !zu verhindern. Wobei ich dazu sagen muss, dass dieser Fehler scheinbar nach dem Update auf die Beta nicht mehr auftaucht!
War bei meiner Suche dbzgl. leider nicht so erfolgreich und freue mich über alle Infos dazu.
Danke und Gruß
sTaN
Zitat von: sTaN am 09 Januar 2023, 02:09:35
aber wäre natürlich toll, wenn dies offiziell weitergepflegt wird
Gibt es außer diesem Thread noch weitere Beiträge oder aktuelle Doku, die die Unterschiede und Vorteile der Beta etwas erläutern?
a. habe ich schon mehrfach geschrieben das ich die Betas nicht einchecken werde, wer sie nutzen will (so wie ich) soll das tun.
b. zum Thema Doku habe ich hier -> https://forum.fhem.de/index.php/topic,106258.0.html recht viel zusammengeschrieben, was dort allerdings noch fehlt ist neuste Teil zum rücklesen einiger Werte von den HTs ( set getConfigxxxx )
Moin zusammen,
Ich hab grad mal wieder leerlaufende Credits und will mich dem Thema mal nachhaltig annehmen.
Ich suche nach einer Möglichkeit zu visualisieren, welche Geräte die Credits verbraten.
In Readings würde mir das schon reichen.
@Wzut: gibt es da zufällig in den einzelnen Geräten oder im CULMAX eine Möglichkeit zu sehen,
wie oft ein Gerät Credits verbraucht?
Gruss
Maui
Direkt leider nein. Da beibt nur verbose 4 oder 5 am culmax Device und im Log nach der Sendqueue schauen.
I.d.R sieht man da die Credit fressenden Fehlversuche
Hmmm ok schade. Aber müsste ich nicht ein updateReading auswerten können, zb auf RSSI?
Edit: wenn ich mit verbose in den Logs gucke, dann muss ich nach "Send Queue packet send" gucken und nur die verbraten credits?
Empfangen wird ja nix "Kosten" oder?
Hallo,
Bei mir laufen einige Max Thermostate mit dem Orginal Max Cube.
Zur Testzwecken habe ich auch die Beta Version BETA_11122020 am laufen. Hier hatte ich mit einem Thermostaten zur Testzwecke dies mit meinem CulMax betrieben und hatte dem Thermostaten auch einen externen Temperatursensor drangehängt.
Jetzt habe ich einen neuen Thermostaten in einem neuen Raum. Diesen habe ich auch mit dem Orginal Cube Max verbunden. Jetzt dachte ich mir da ich ja die Beta Version habe, das ich dem Thermostaten einen externen Temperatursensor als Sollwert vorgebe.
Das habe ich auch in den attributen von diesem Thermostat hinzugefügt.
externalSensor
Temperatursensor_Altkat:temperature:1
Das reading von diesem externen Sensor sehe ich auch in dem Thermostaten
Internals:
CULMAX0_MSGCNT 2
CULMAX0_TIME 2023-02-27 19:00:31
DEF HeatingThermostat 0696d1
FUUID 5fdfa4e4-f33f-2b39-5391-2040d400ba770fa1
IODev ml
LASTInputDev ml
MSGCNT 387
NAME MAX_0696d1
NOTIFYDEV Temperatursensor_Altkat
NR 198
NTFY_ORDER 50-MAX_0696d1
STATE 22.0
SVN BETA_11122020
TYPE MAX
TimeSlot -1
addr 0696d1
devtype 1
ml_MSGCNT 385
ml_TIME 2023-02-27 20:30:17
type HeatingThermostat
READINGS:
2023-02-27 20:30:17 MAXLAN_error 0
2023-02-27 20:30:17 MAXLAN_errorInCommand
2023-02-27 20:30:17 MAXLAN_initialized 1
2023-02-27 20:30:17 MAXLAN_isAnswer 0
2023-02-27 20:30:17 MAXLAN_valid 1
2023-02-20 21:43:01 PairedTo 000000
2023-02-27 19:00:31 RSSI -73
2023-02-27 06:00:57 SerialNr JHA0008724
2023-02-27 20:30:17 battery ok
2023-02-27 20:30:17 batteryState ok
2023-02-27 06:00:57 boostDuration 5
2023-02-27 06:00:57 boostValveposition 80
2023-02-27 06:00:57 comfortTemperature 21.5
2023-02-27 06:00:57 decalcification Sat 12:00
2023-02-27 20:30:17 desiredTemperature 22.0
2023-02-27 20:30:17 deviation 1.2
2023-02-27 06:00:57 ecoTemperature 16.5
2020-12-20 20:24:20 error invalid or missing value for READING .weekProfile
2023-02-27 20:15:52 externalTemp 23.16
2023-02-27 06:00:57 firmware 1.6
2023-02-27 20:30:17 gateway 1
2023-02-27 06:00:57 groupid 6
2023-02-20 13:01:46 lastTimeSync 2023-02-20 13:01:46
2023-02-27 06:00:57 lastcmd HeatingThermostatConfig
2023-02-27 06:00:57 maxValveSetting 100
2023-02-27 06:00:57 maximumTemperature on
2023-02-27 06:00:57 measurementOffset 0.0
2023-02-27 06:00:57 minimumTemperature off
2023-02-27 20:30:17 mode auto
2023-02-20 21:43:01 msgcnt 20
2023-02-27 20:30:17 panel unlocked
2023-02-20 19:46:35 peerIDs 000000,111111
2023-02-20 19:46:35 peerList Broadcast,MAX_111111
2020-12-20 20:27:29 peers 111111
2023-02-27 20:30:17 rferror 0
2023-02-27 20:30:17 state 22.0
2023-02-27 20:30:17 temperature 21.1
2023-02-27 06:00:57 testresult 255
2023-02-27 06:00:57 valveOffset 0
2023-02-27 20:30:17 valveposition 60
2023-02-27 06:00:57 weekprofile-0-Sat-temp 22.0 °C / 17.0 °C / 22.0 °C
2023-02-27 06:00:57 weekprofile-0-Sat-time 00:00-02:00 / 02:00-19:00 / 19:00-24:00
2023-02-27 06:00:57 weekprofile-1-Sun-temp 22.0 °C / 17.0 °C / 22.0 °C
2023-02-27 06:00:57 weekprofile-1-Sun-time 00:00-02:00 / 02:00-19:00 / 19:00-24:00
2023-02-27 06:00:57 weekprofile-2-Mon-temp 22.0 °C / 17.0 °C / 22.0 °C
2023-02-27 06:00:57 weekprofile-2-Mon-time 00:00-02:00 / 02:00-19:00 / 19:00-24:00
2023-02-27 06:00:57 weekprofile-3-Tue-temp 22.0 °C / 17.0 °C / 22.0 °C
2023-02-27 06:00:57 weekprofile-3-Tue-time 00:00-02:00 / 02:00-19:00 / 19:00-24:00
2023-02-27 06:00:57 weekprofile-4-Wed-temp 22.0 °C / 17.0 °C / 22.0 °C
2023-02-27 06:00:57 weekprofile-4-Wed-time 00:00-02:00 / 02:00-19:00 / 19:00-24:00
2023-02-27 06:00:57 weekprofile-5-Thu-temp 22.0 °C / 17.0 °C / 22.0 °C
2023-02-27 06:00:57 weekprofile-5-Thu-time 00:00-02:00 / 02:00-19:00 / 19:00-24:00
2023-02-27 06:00:57 weekprofile-6-Fri-temp 22.0 °C / 17.0 °C / 22.0 °C
2023-02-27 06:00:57 weekprofile-6-Fri-time 00:00-02:00 / 02:00-19:00 / 19:00-24:00
2023-02-27 06:00:57 windowOpenDuration 15
2023-02-27 06:00:57 windowOpenTemperature 12.0
helper:
dt 17.0
myday 2
io:
CULStick:
raw Z0F0004600696D100000000183C2C00D3
rssi -73
time 1677520831.71585
Attributes:
IODev ml
alexaName Büro Heizung
alias Altkat_Kalorifer
event-on-change-reading .*
externalSensor Temperatursensor_Altkat:temperature:1
genericDeviceType thermostat
icon hc_wht_regler
keepAuto 0
model HeatingThermostat
room Heizung
sortby 06
Die deviation wird auch von diesem externen S3nsor gebildet.
Allerdings habe ich das Problem das der Thermostat sich nicht auf die vorgegebene Solltemperatur einregeln will. Dieser liegt immer drüber. Was ich nicht verstehe. Ich dachte mir das die Thermostate einige Zeit brauchen bis sich einregeln aber so nach 1 Woche glaub ich das nicht mehr. Wenn ich mir allerdings die interne Temperaturs3nsor anschaue. Liegt dieser untrrhalb der Solltemperatur, und damit denkt er er müsste weiter heizen.
Frage? Funktioniert der externe Temperatursensor wenn man die Thermostate mit dem Orginal Cube Max betreibt?
Zitat von: neyzen am 27 Februar 2023, 20:38:55
Funktioniert der externe Temperatursensor wenn man die Thermostate mit dem Orginal Cube Max betreibt?
Kurze Antwort : nein
Lange Version :
Wenn man CULMAX und MAXLAN gleichzeitig nutzt gibt es ein paar Dinge zu beachten.
Version a : CULMAX und MAXLAN verwenden unterschiedliche MaxIDs. Hier hat man zwei sauber getrennte Welten die sich nicht gegenseitig beinflussen, trotzdem rate ich von dieser Lösung ab. :)
Version b : CULMAX und MAXLAN verwenden die gleiche ID. Bei dieser Variante sollte an allen MAX Geräten das IODev auf das MAXLAN Device gesetzt werden.
CULMAX ist dann nur beim Empfang aktiv, die Werte der MAX Geräte werden sofort in FHEM aktualisiert und nicht erst beim nächsten Cube Poll. Sendetelegramme laufen dabei dann immer über den Cube. Der grosse Vorteil dieser Version ist das man ganz schnell mal das MAXLAN Device und den Cube abschalten kann und komplett alles über CULMAX laufen zu lassen. Bei Problemen kann man sehr schnell wieder alles zurückdrehen, da an den MAX Geräten selbst
keine Änderung vorgenommen wird ! Lediglich das IODev ist in FHEM abzupassen.
Funktioniert der externe Temperatursensor wenn man die Thermostate mit dem Orginal Cube Max betreibt?
Kurze Antwort : nein
Das beantwortet meine Frage und verstehe jetzt warum der Thermostat nicht tut was er soll.
Dann muss ich mir mit einem Offset helfen.
Mist, jetzt lief die Heizung ne ganze Woche auf vollepulle. Da freut sich Putin. ;D
Heute morgen hat es mich auch erwischt:
ZitatMonth '13' out of range 0..11 at ./FHEM/14_CUL_MAX.pm line 831.
Danach war fhem abgestürzt. Nicht nett .....
Ich habe die aktuellen Beta-Module eingesetzt (und hatte monatelang keine Probleme). Gibts dafür schon eine Lösung?
Danke + Gruss
willyk
Zitat von: willyk am 05 März 2023, 08:17:55
Gibts dafür schon eine Lösung?
nein, denn sowas ist bisher noch nie vorgekommen. Offenbar wurde hier ein zerstörtes Telegramm decodiert.
Ich kann mir nicht vorstellen das sich dies in irgendeiner Form wiederholen lässt. bzw. hat auch nichts mit der Beta Version direkt zu tun da auch die normale Version einen Monat 13 nicht geschluckt hätte.
Zitat von: Wzut am 05 März 2023, 09:29:08
nein, denn sowas ist bisher noch nie vorgekommen.
NIE stimmt so nicht 8) .... siehe:
Zitat von: michael.winkler am 01 Dezember 2021, 18:21:13
Gerade hat sich mein FHEM verabschiedet:
2021.12.01 18:19:01.387 2: culmax.remote, unknown message type D5 from culmax.remote [123456] to MAX_001900 [123456] - ignoring !
Month '-1' out of range 0..11 at ./FHEM/14_CUL_MAX.pm line 831.
Die Antwort von dir war:
Zitat von: Wzut am 02 Dezember 2021, 10:08:56
IMHO passen die beiden Zeilen nicht direkt zusammen, das D5 Telegramm wurde laut Log ja schon verworfen.
Zu dem Montatsfehler kann es nur bei gültigem Typ TimeSync aber fehlerhaften/zerstörtem Payload kommen - werde ich in einer der nächsten Versionen noch mit eval kapseln
Deswegen hatte ich nachgefragt, ich dachte ich hab zwischen drin was verpasst.
Aber ja, man kann nicht alles abfangen. Ist trotzdem lästig, wenn FHEM so komplett stehen bleibt. Das vermindert den WAF erheblich, wie ich schmerzlich erfahren musste.
Danke dir + Gruss
willyk
Ok, hast recht : war mir nicht mehr in Erinnerung das es schon mal ein Problem mit einem ungültigen Monatswert gab.
Zum Glück wird timelocal nur an einer Stelle benutzt, da sollte es realtiv einfach sein diese mit eval zu kapseln und alle möglichen ungültigen Zeitwerte zu verwerfen.
Ich habe die 14_CUL_MAX im ersten Post ausgetauscht, jetzt wird eine Fehlermeldung ins Log geschrieben falls ein ungültiges Zeittelegramm empfangen wurde , Bsp :
023.03.05 11:01:08 1: CULMAX0, TimeInformation error from [0f30c1] : Month '12' out of range 0..11 at ./FHEM/14_CUL_MAX.pm line 860.
Prima, habs runtergeladen und eingebaut. Vielen Dank !
Gruss
willyk
Hi,
ich wollte letztens meine Solltemperatur manuel um 1 grad hochstellen.
Hat auch funktioniert. Allerdings wechselt er nach ein paar Minuten wieder in den Automatik Mode und nimmt wieder die alte Solltemperatur.
Mein keepAuto steht auf 0
Das HT schaltet auf sein Wochenprogramm zurück wenn es auf einen Schaltpunkt im Wochenprofil trifft und keepAuto = 1 ist.
Wenn das bei dir so schnell wieder auf Automatik gegangen ist muß etwas anderes dafür verantwortlich sein,
d.h. den Vorgang wiederholen, aber vorher das Device auf verbose 5 stellen und dann das Log posten.
Hast den den Scanner ( https://forum.fhem.de/index.php/topic,11624.0.html ) in Betrieb ?
Nein kein scanner.
Ich werde das mal beobachten und versuchen es mit zu loggen
Hallo Wzut, Hallo zusammen,
ich habe damals mit FHEM begonnen, bin dann zu Homegear und überlege nun zurück zu FHEM zu wechseln. Deine Fortschritte beim MAX Modul sind grandios! Ich habe vor einiger Zeit mal versucht, virtuelle WT bei Homegear zu implementieren und irgendwann aufgegeben.
Ich habe nun gesehen, dass in deinen Beta Modulen schon ein virtualThermostat vorhanden ist. Dazu konnte ich keine Doku finden. In FHEM lässt sich ein solches Gerät anlegen. Bevor ich nun umziehe, lassen sich diese virtualThermostate schon nutzen? Hier im Forum habe ich spezifisch zu den Thermostaten leider nichts aktuelles gefunden.
Viele Grüße
Kevin
a. warum umziehen ? Zieh das doch zeitgleich in FHEM hoch , spart mit Sicherheit jede Menge Arbeit und Frust.
b. wozu wird ein virtuelles Themostat benötigt ? I.d.R lässt sich das sehr gut mit dem fakeWT und dem Attribut externalSensor direkt aus dem Stand erledigen.
A) stimmt gute Idee! Ich muss mal versuchen die Adresse von meinem CUL zu finden. Zur Not schneide ich halt den Funkverkehr mit.
B) ich möchte externe Temperatursensoren (Zigbee Sonoff SNZB-02) einsetzen. Ich habe 4 Räume und in meiner Erinnerung war das mit nur einem fakeWT problematisch, weil es dann nur eine fakeWT Adresse gibt. Falls das kein Problem mehr ist, ginge das natürlich auch.
IMHO ist die eine fake Adresse nur ein Problem wenn mit Broadcasts gearbeitet wird, wenn die Telegramme aber ein einzelenes Device als Ziel haben ist das ersteinmal kein Problem.
Allerdings können bei vier Zielen die Credits zum Problem werden.
Die Gefahr mit den Credits besteht ja so oder so. Dann würde ich das einfach mal probieren.
Was würde das VirtualThermostat denn dann noch mehr tun? Im Code habe ich etwas entdeckt, dass sich glaube ich mit dem handling der WakeUp Pakete von den HTs befassen würde, wenn ich das richtig verstanden habe?
Hallo,
ist die aktuellste version im 1. beitrag herunterzuladen?
... oder wo ist diese zu finden?
Ist irgendwo eine Informartion zu finden, wann die letzte Änderung an den Dateien vorgenommen wurde?
a. ja
b. in der Kopfzeile des ersten Posts : Letzte Bearbeitung: 05 März 2023, 11:42:11 von Wzut
Nach langer Zeit habe ich mal wieder die 3 Betaversionen aus dem ersten Posting eingefügt und erhalte immer noch wie vor 3 Jahren beim CUL die Anzeige UAS.
Bei genauerer Betrachtung steht dort, dass die credits10ms nicht gelesen werden können.
Verwendet wird ein selbst gebauter CUL mit 868MHz und firmware V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) nanoCUL868 (F-Band: 868MHz)
Ich vermute, dass ein Firmwareupdate des CUL bei der dann auch 3600 statt 900 credits möglich sind, diese Fehler auch beseitgt. Aber da hakt es noch mit einer neueren Firmware.
Gruß
_fhemuser_
Ich habe jetzt den CUL mit neuer Firmware V 1.67 nanoCUL868 geflasht und von 900 credits auf 3600 credits geändert.
Mit den originalen MAX Modulen funktioniert auch wieder alles wie gewohnt, nur bei den 3 Betaversionen aus dem ersten Post habe ich immer noch Schwierigkeiten.
Es sieht so aus, dass die credits herunterzählen auf Null und dann ein Fehler im Modul entsteht und die Credits nicht wieder ansteigen. Auch nach mehreren Stunden nicht.
Wichtig wäre für mich die Funktion getStatus, da ich damit die Werte gleichmäßiger erhalte. In der Standardversion kann es passieren, dass ich an einem Tag gar keine Werte bekomme.
Gruß
_fhemuser_
Ich kann schlecht erraten was bei dir (und wohl nur bei dir) da so schief läuft, daher kann ich immer nur wieder das gleiche schreiben :
CM Device auf verbose 4 oder 5 stellen , eine Weile laufen lassen und das enstsprechende Log posten.
Alles andere ist Lotto.
Wenn die Credits runter sind und sich nicht wieder erholen würde ich mir mal sie Sendqueue anschauen !
@Wzut
Danke für die schnelle Rückmeldung
Bei den Betaversionen ist mir noch aufgefallen, dass der Status des CUL sich ändert zwischen initialized und connected.
Im Status initailized können die Werte credits und version ausgelesen werden. Im Status connected kommt immer keine Antword bzw missing FD
Hier das log direkt nach einem Neustart mit den Betaversionen:
2024.01.15 09:45:41 0: Featurelevel: 6.2
2024.01.15 09:45:41 0: Server started with 557 defined entities (fhem.pl:28227/2023-11-29 perl:5.032001 os:linux user:fhem pid:33983)
2024.01.15 09:45:46 5: DevIo_SimpleWrite CUL866: Zw111111
2024.01.15 09:45:46 5: DevIo_SimpleWrite CUL866: X
2024.01.15 09:45:46 5: CUL_ReadAnswer CUL866: 21 1821
2024.01.15 09:45:46 5: CUL866 sending Zs0f01040347111800000000180f092d6e
2024.01.15 09:45:46 5: DevIo_SimpleWrite CUL866: Zs0f01040347111800000000180f092d6e
2024.01.15 09:45:55 5: CUL_Read: CUL866 /Z0CAD0442088599000000002AC7
2024.01.15 09:45:55 5: CUL_Read: CUL866 Z0CAD0442088599000000002AC7/F5
2024.01.15 09:45:55 4: CUL_Parse: CUL866 Z0CAD0442088599000000002AC7F5 -79.5
2024.01.15 09:45:55 5: CUL866: dispatch Z0CAD0442088599000000002AC7
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C0D
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C0D = 21 / 33
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866:
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C0E
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C0E = 65 / 101
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C0F
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C0F = 6A / 106
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C10
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C10 = C8 / 200
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C1B
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C1B = 43 / 67
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C1D
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C1D = 91 / 145
2024.01.15 09:46:03 5: CUL_Read: CUL866 /Z0B460002471118073
2024.01.15 09:46:03 5: CUL_Read: CUL866 Z0B460002471118073/241000000
Z0B4606300732414711180010EC
2024.01.15 09:46:03 4: CUL_Parse: CUL866 Z0B460002471118073241000000 -74
2024.01.15 09:46:03 5: CUL866: dispatch Z0B4600024711180732410000
2024.01.15 09:46:03 4: CUL_Parse: CUL866 Z0B4606300732414711180010EC -84
2024.01.15 09:46:03 5: CUL866: dispatch Z0B4606300732414711180010
2024.01.15 09:46:09 5: DevIo_SimpleWrite CUL866: V
2024.01.15 09:46:09 5: CUL_ReadAnswer CUL866: V 1.67 nanoCUL868
2024.01.15 09:46:09 5: CUL_ReadAnswer CUL866:
2024.01.15 09:46:14 5: DevIo_SimpleWrite CUL866: X
2024.01.15 09:46:14 5: CUL_ReadAnswer CUL866: 21 1727
das device:define CUL866 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0@38400 0000
attr CUL866 model CUL
attr CUL866 rfmode MAX
attr CUL866 room Zentral
attr CUL866 verbose 5
# CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
# CUL866_MSGCNT 26
# CUL866_RAWMSG Z0FC0050308859947111800180F093B43
# CUL866_RSSI -80.5
# CUL866_TIME 2024-01-15 09:59:05
# Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
# DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0@38400 0000
# DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0@38400
# FD 41
# FHTID 0000
# FUUID 5f78455e-f33f-d33d-7870-276bbeb1f6b657dc
# LASTInputDev CUL866
# MSGCNT 13
# NAME CUL866
# NR 541
# NR_CMD_LAST_H 3
# PARTIAL
# RAWMSG Z0FC0050308859947111800180F093B43F3
# RSSI -80.5
# STATE Initialized
# TYPE CUL
# VERSION V 1.67 nanoCUL868
# devioNoSTATE 1
# eventCount 6
# initString X21
#Zr
#Za471118
#Zw111111
# Helper:
# DBLOG:
# ccconf:
# logdb:
# TIME 1705308361.85517
# VALUE freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
# credit10ms:
# logdb:
# TIME 1705309086.185
# VALUE 2438
# version:
# logdb:
# TIME 1705308369.16512
# VALUE V 1.67 nanoCUL868
# MatchList:
# 1:CUL_MAX ^Z........................
# 8:HMS ^810e04....(1|5|9).a001
# D:CUL_IR ^I............
# H:STACKABLE_CC ^\*
# M:TSSTACKED ^\*
# N:STACKABLE ^\*
# READINGS:
# 2024-01-15 09:46:01 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
# 2024-01-15 09:45:26 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
# 2024-01-15 09:58:06 credit10ms 2438
# 2024-01-14 07:26:11 fhtbuf AE
# 2024-01-14 07:23:57 raw No answer
# 2024-01-15 09:59:05 state Initialized
# 2024-01-14 13:46:34 uptime No answer
# 2024-01-15 09:46:09 version V 1.67 nanoCUL868
# XMIT_TIME:
# 1705308340.11602
# 1705308346.2794
# 1705308346.73725
#
setstate CUL866 2024-01-15 09:46:01 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
setstate CUL866 2024-01-15 09:45:26 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
setstate CUL866 2024-01-15 09:58:06 credit10ms 2438
setstate CUL866 2024-01-14 07:26:11 fhtbuf AE
setstate CUL866 2024-01-14 07:23:57 raw No answer
setstate CUL866 2024-01-15 09:59:05 state Initialized
setstate CUL866 2024-01-14 13:46:34 uptime No answer
setstate CUL866 2024-01-15 09:46:09 version V 1.67 nanoCUL868
[/code]
define MAX_CUL_Stick CUL_MAX 471118
attr MAX_CUL_Stick IODev CUL866
attr MAX_CUL_Stick debug 1
attr MAX_CUL_Stick fakeSCaddr 222222
attr MAX_CUL_Stick fakeWTaddr 111111
attr MAX_CUL_Stick icon cul_usb
attr MAX_CUL_Stick room Heizkoerper->-Heizkoerper
attr MAX_CUL_Stick verbose 0
# DEF 471118
# FUUID 5f78613b-f33f-d33d-fc63-8d877b2de163524a
# IODev CUL866
# LASTInputDev
# NAME MAX_CUL_Stick
# NOTIFYDEV global
# NR 543
# NTFY_ORDER 50-MAX_CUL_Stick
# STATE CUL866:ok
# SVN 28032021
# TYPE CUL_MAX
# addr 471118
# cnt 0
# eventCount 6
# pairmode 0
# retryCount 0
# sq 0
# Helper:
# DBLOG:
# CUL866_cmd_last_h:
# logdb:
# TIME 1705308346.48892
# VALUE 2
# CUL866_credit10ms:
# logdb:
# TIME 1705308346.55588
# VALUE 1821
# state:
# logdb:
# TIME 1705309240.44227
# VALUE CUL866:ok
# READINGS:
# 2024-01-15 09:45:46 CUL866_cmd_last_h 2
# 2024-01-15 09:45:46 CUL866_credit10ms 1821
# 2024-01-15 09:45:40 IODev CUL866
# 2024-01-14 12:30:05 error CUL866 did not answer request for current credits
# 2024-01-15 07:06:57 lastTimeSync Schlaf
# 2024-01-15 09:45:46 msgcnt 1
# 2024-01-15 10:00:40 state CUL866:ok
# helper:
# asso:
# Bad Dispatch
# CUL866 IO
# Kuechenfenster Dispatch
# Thermometer Dispatch
# Wohnfenster Dispatch
# sendQueue:
#
setstate MAX_CUL_Stick CUL866:ok
setstate MAX_CUL_Stick 2024-01-15 10:00:40 .associatedWith Bad,Thermometer,Kuechenfenster,Wohnfenster,CUL866
setstate MAX_CUL_Stick 2024-01-15 09:45:46 CUL866_cmd_last_h 2
setstate MAX_CUL_Stick 2024-01-15 09:45:46 CUL866_credit10ms 1821
setstate MAX_CUL_Stick 2024-01-15 09:45:40 IODev CUL866
setstate MAX_CUL_Stick 2024-01-14 12:30:05 error CUL866 did not answer request for current credits
setstate MAX_CUL_Stick 2024-01-15 07:06:57 lastTimeSync Schlaf
setstate MAX_CUL_Stick 2024-01-15 09:45:46 msgcnt 1
setstate MAX_CUL_Stick 2024-01-15 10:00:40 state CUL866:ok
So der Fehler tritt auf ca 1 Stunde nach Neustart.
Logdatei:
2024.01.15 09:45:41 0: Featurelevel: 6.2
2024.01.15 09:45:41 0: Server started with 557 defined entities (fhem.pl:28227/2023-11-29 perl:5.032001 os:linux user:fhem pid:33983)
2024.01.15 09:45:46 5: DevIo_SimpleWrite CUL866: Zw111111
2024.01.15 09:45:46 1: FHEM2FHEM 192.168.0.110:7072 reappeared (Raspi110fhem)
2024.01.15 09:45:46 5: DevIo_SimpleWrite CUL866: X
2024.01.15 09:45:46 5: CUL_ReadAnswer CUL866: 21 1821
2024.01.15 09:45:46 5: CUL866 sending Zs0f01040347111800000000180f092d6e
2024.01.15 09:45:46 5: DevIo_SimpleWrite CUL866: Zs0f01040347111800000000180f092d6e
2024.01.15 09:45:55 5: CUL_Read: CUL866 /Z0CAD0442088599000000002AC7
2024.01.15 09:45:55 5: CUL_Read: CUL866 Z0CAD0442088599000000002AC7/F5
2024.01.15 09:45:55 4: CUL_Parse: CUL866 Z0CAD0442088599000000002AC7F5 -79.5
2024.01.15 09:45:55 5: CUL866: dispatch Z0CAD0442088599000000002AC7
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C0D
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C0D = 21 / 33
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866:
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C0E
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C0E = 65 / 101
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C0F
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C0F = 6A / 106
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C10
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C10 = C8 / 200
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C1B
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C1B = 43 / 67
2024.01.15 09:46:01 5: DevIo_SimpleWrite CUL866: C1D
2024.01.15 09:46:01 5: CUL_ReadAnswer CUL866: C1D = 91 / 145
2024.01.15 09:46:03 5: CUL_Read: CUL866 /Z0B460002471118073
2024.01.15 09:46:03 5: CUL_Read: CUL866 Z0B460002471118073/241000000
Z0B4606300732414711180010EC
2024.01.15 09:46:03 4: CUL_Parse: CUL866 Z0B460002471118073241000000 -74
2024.01.15 09:46:03 5: CUL866: dispatch Z0B4600024711180732410000
2024.01.15 09:46:03 4: CUL_Parse: CUL866 Z0B4606300732414711180010EC -84
2024.01.15 09:46:03 5: CUL866: dispatch Z0B4606300732414711180010
2024.01.15 09:46:09 5: DevIo_SimpleWrite CUL866: V
2024.01.15 09:46:09 5: CUL_ReadAnswer CUL866: V 1.67 nanoCUL868
2024.01.15 09:46:09 5: CUL_ReadAnswer CUL866:
2024.01.15 09:46:14 5: DevIo_SimpleWrite CUL866: X
2024.01.15 09:46:14 5: CUL_ReadAnswer CUL866: 21 1727
2024.01.15 09:48:34 5: CUL_Read: CUL866 /Z0FBB0
2024.01.15 09:48:34 5: CUL_Read: CUL866 Z0FBB0/4700885990000000019042A00C6F3
2024.01.15 09:48:34 4: CUL_Parse: CUL866 Z0FBB04700885990000000019042A00C6F3 -80.5
2024.01.15 09:48:34 5: CUL866: dispatch Z0FBB04700885990000000019042A00C6
2024.01.15 09:48:47 5: CUL_Read: CUL866 /Z0CAE0442088599000000002AC6F4
2024.01.15 09:48:47 4: CUL_Parse: CUL866 Z0CAE0442088599000000002AC6F4 -80
2024.01.15 09:48:47 5: CUL866: dispatch Z0CAE0442088599000000002AC6
2024.01.15 09:51:35 5: CUL_Read: CUL866 /Z0CAF0442088599000000002AC6F
2024.01.15 09:51:35 5: CUL_Read: CUL866 Z0CAF0442088599000000002AC6F/4
2024.01.15 09:51:35 4: CUL_Parse: CUL866 Z0CAF0442088599000000002AC6F4 -80
2024.01.15 09:51:35 5: CUL866: dispatch Z0CAF0442088599000000002AC6
2024.01.15 09:52:54 5: CUL_Read: CUL866 /Z0F0004600830AD000000
2024.01.15 09:52:54 5: CUL_Read: CUL866 Z0F0004600830AD000000/00181F2300B8F6
2024.01.15 09:52:54 4: CUL_Parse: CUL866 Z0F0004600830AD00000000181F2300B8F6 -79
2024.01.15 09:52:54 5: CUL866: dispatch Z0F0004600830AD00000000181F2300B8
2024.01.15 09:54:20 5: CUL_Read: CUL866 /Z0CB00442088599000000002AC8F2
2024.01.15 09:54:20 4: CUL_Parse: CUL866 Z0CB00442088599000000002AC8F2 -81
2024.01.15 09:54:20 5: CUL866: dispatch Z0CB00442088599000000002AC8
2024.01.15 09:57:18 5: CUL_Read: CUL866 /Z0CB10442088599000000002AC8F2
2024.01.15 09:57:18 4: CUL_Parse: CUL866 Z0CB10442088599000000002AC8F2 -81
2024.01.15 09:57:18 5: CUL866: dispatch Z0CB10442088599000000002AC8
2024.01.15 09:58:06 5: DevIo_SimpleWrite CUL866: X
2024.01.15 09:58:06 5: CUL_ReadAnswer CUL866: 21 243
2024.01.15 09:58:06 5: CUL_ReadAnswer CUL866: 8
2024.01.15 09:58:35 5: CUL_Read: CUL866 /Z0B61000247111807320A000000
Z0B610
2024.01.15 09:58:35 4: CUL_Parse: CUL866 Z0B61000247111807320A000000 -74
2024.01.15 09:58:35 5: CUL866: dispatch Z0B61000247111807320A0000
2024.01.15 09:58:35 5: CUL_Read: CUL866 Z0B610/63007320A471118001010
2024.01.15 09:58:35 4: CUL_Parse: CUL866 Z0B61063007320A471118001010 -66
2024.01.15 09:58:35 5: CUL866: dispatch Z0B61063007320A4711180010
2024.01.15 09:59:01 5: CUL_Read: CUL866 /Z0FBF050308859947111800180F093A7AF3
2024.01.15 09:59:01 4: CUL_Parse: CUL866 Z0FBF050308859947111800180F093A7AF3 -80.5
2024.01.15 09:59:01 5: CUL866: dispatch Z0FBF050308859947111800180F093A7A
2024.01.15 09:59:05 5: CUL_Read: CUL866 /Z0FC0050308859947111800180F093B43F3
2024.01.15 09:59:05 4: CUL_Parse: CUL866 Z0FC0050308859947111800180F093B43F3 -80.5
2024.01.15 09:59:05 5: CUL866: dispatch Z0FC0050308859947111800180F093B43
2024.01.15 09:59:10 5: CUL_Read: CUL866 /Z0F
2024.01.15 09:59:10 5: CUL_Read: CUL866 Z0F/C1050308859947111800180F093B48F3
2024.01.15 09:59:10 4: CUL_Parse: CUL866 Z0FC1050308859947111800180F093B48F3 -80.5
2024.01.15 09:59:10 5: CUL866: dispatch Z0FC1050308859947111800180F093B48
2024.01.15 10:00:11 5: CUL_Read: CUL866 /Z0CB20442088599000000002AC8
2024.01.15 10:00:11 5: CUL_Read: CUL866 Z0CB20442088599000000002AC8/F4
2024.01.15 10:00:11 4: CUL_Parse: CUL866 Z0CB20442088599000000002AC8F4 -80
2024.01.15 10:00:11 5: CUL866: dispatch Z0CB20442088599000000002AC8
2024.01.15 10:00:34 5: CUL_Read: CUL866 /Z0FC204700885
2024.01.15 10:00:34 5: CUL_Read: CUL866 Z0FC204700885/990000000059042A00C8F4
2024.01.15 10:00:34 4: CUL_Parse: CUL866 Z0FC204700885990000000059042A00C8F4 -80
2024.01.15 10:00:34 5: CUL866: dispatch Z0FC204700885990000000059042A00C8
2024.01.15 10:01:10 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:01:10 5: CUL_ReadAnswer CUL866: 21 2614
2024.01.15 10:01:40 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:01:40 5: CUL_ReadAnswer CUL866: 21 2643
2024.01.15 10:03:01 5: CUL_Read: CUL866 /Z0CB30442088599000000002AC8F5
2024.01.15 10:03:01 4: CUL_Parse: CUL866 Z0CB30442088599000000002AC8F5 -79.5
2024.01.15 10:03:01 5: CUL866: dispatch Z0CB30442088599000000002AC8
2024.01.15 10:05:17 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:05:17 5: CUL_ReadAnswer CUL866: 21 2861
2024.01.15 10:05:17 5: CUL866 sending Zs0b0a08604711180af6880000
2024.01.15 10:05:17 5: DevIo_SimpleWrite CUL866: Zs0b0a08604711180af6880000
2024.01.15 10:05:18 5: CUL_Read: CUL866 /Z0F0A00600AF6884711180018642B00CFF5
2024.01.15 10:05:18 4: CUL_Parse: CUL866 Z0F0A00600AF6884711180018642B00CFF5 -79.5
2024.01.15 10:05:18 5: CUL866: dispatch Z0F0A00600AF6884711180018642B00CF
2024.01.15 10:05:44 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:05:44 5: CUL_ReadAnswer CUL866: 21 2778
2024.01.15 10:05:44 5: CUL866 sending Zs0b560860471118189f2d0000
2024.01.15 10:05:44 5: DevIo_SimpleWrite CUL866: Zs0b560860471118189f2d0000
2024.01.15 10:05:45 5: CUL_Read: CUL866 /Z0F000060189F2D4711180018000C0089
2024.01.15 10:05:45 5: CUL_Read: CUL866 Z0F000060189F2D4711180018000C0089/00
2024.01.15 10:05:45 4: CUL_Parse: CUL866 Z0F000060189F2D4711180018000C008900 -74
2024.01.15 10:05:45 5: CUL866: dispatch Z0F000060189F2D4711180018000C0089
2024.01.15 10:05:48 5: CUL_Read: CUL866 /Z0CB40442088599000000002AC8F4
2024.01.15 10:05:48 4: CUL_Parse: CUL866 Z0CB40442088599000000002AC8F4 -80
2024.01.15 10:05:48 5: CUL866: dispatch Z0CB40442088599000000002AC8
2024.01.15 10:06:15 5: CUL_Read: CUL866 /Z0B45000247111818D57E000000
Z0B450
2024.01.15 10:06:15 4: CUL_Parse: CUL866 Z0B45000247111818D57E000000 -74
2024.01.15 10:06:15 5: CUL866: dispatch Z0B45000247111818D57E0000
2024.01.15 10:06:15 5: CUL_Read: CUL866 Z0B450/63018D57E4711180012F0
2024.01.15 10:06:15 4: CUL_Parse: CUL866 Z0B45063018D57E4711180012F0 -82
2024.01.15 10:06:15 5: CUL866: dispatch Z0B45063018D57E4711180012
2024.01.15 10:06:35 5: CUL_Read: CUL866 /Z0B46000
2024.01.15 10:06:35 5: CUL_Read: CUL866 Z0B46000/247111818D57E000000
Z0B46063018D57E4711180010E9
2024.01.15 10:06:35 4: CUL_Parse: CUL866 Z0B46000247111818D57E000000 -74
2024.01.15 10:06:35 5: CUL866: dispatch Z0B46000247111818D57E0000
2024.01.15 10:06:35 4: CUL_Parse: CUL866 Z0B46063018D57E4711180010E9 -85.5
2024.01.15 10:06:35 5: CUL866: dispatch Z0B46063018D57E4711180010
2024.01.15 10:06:59 5: CUL_Read: CUL866 /Z0F000460189F2D00000000180020008900
2024.01.15 10:06:59 4: CUL_Parse: CUL866 Z0F000460189F2D00000000180020008900 -74
2024.01.15 10:06:59 5: CUL866: dispatch Z0F000460189F2D000000001800200089
2024.01.15 10:07:05 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:07:05 5: CUL_ReadAnswer CUL866: 21 2732
2024.01.15 10:07:05 5: CUL866 sending Zs0b570860471118189f2d0000
2024.01.15 10:07:05 5: DevIo_SimpleWrite CUL866: Zs0b570860471118189f2d0000
2024.01.15 10:07:06 5: CUL_Read: CUL866 /Z0F000060189F2D47111800180020008901
2024.01.15 10:07:06 4: CUL_Parse: CUL866 Z0F000060189F2D47111800180020008901 -73.5
2024.01.15 10:07:06 5: CUL866: dispatch Z0F000060189F2D471118001800200089
2024.01.15 10:09:04 5: CUL_Read: CUL866 /Z0CB50442088599000000002AC8F4
2024.01.15 10:09:04 4: CUL_Parse: CUL866 Z0CB50442088599000000002AC8F4 -80
2024.01.15 10:09:04 5: CUL866: dispatch Z0CB50442088599000000002AC8
2024.01.15 10:09:10 5: CUL_Read: CUL866 /Z0F0004601
2024.01.15 10:09:10 5: CUL_Read: CUL866 Z0F0004601/89F2D000000001864200089FF
2024.01.15 10:09:10 4: CUL_Parse: CUL866 Z0F000460189F2D000000001864200089FF -74.5
2024.01.15 10:09:10 5: CUL866: dispatch Z0F000460189F2D000000001864200089
2024.01.15 10:09:29 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:09:29 5: CUL_ReadAnswer CUL866: 21 2766
2024.01.15 10:09:29 5: CUL866 sending Zs0b480860471118086b820000
2024.01.15 10:09:29 5: DevIo_SimpleWrite CUL866: Zs0b480860471118086b820000
2024.01.15 10:09:30 5: CUL_Read: CUL866 /Z0F000060086B824711180018002600D812
2024.01.15 10:09:30 4: CUL_Parse: CUL866 Z0F000060086B824711180018002600D812 -65
2024.01.15 10:09:30 5: CUL866: dispatch Z0F000060086B824711180018002600D8
2024.01.15 10:11:42 5: CUL_Read: CUL866 /Z0CB60442088599000000002AC8F5
2024.01.15 10:11:42 4: CUL_Parse: CUL866 Z0CB60442088599000000002AC8F5 -79.5
2024.01.15 10:11:42 5: CUL866: dispatch Z0CB60442088599000000002AC8
2024.01.15 10:12:04 5: CUL_Read: CUL866 /Z0B090630072BC30981090010E7
2024.01.15 10:12:04 4: CUL_Parse: CUL866 Z0B090630072BC30981090010E7 -86.5
2024.01.15 10:12:04 5: CUL866: dispatch Z0B090630072BC30981090010
2024.01.15 10:14:33 5: CUL_Read: CUL866 /Z0CB7044208859900000000
2024.01.15 10:14:33 5: CUL_Read: CUL866 Z0CB7044208859900000000/2AC8F4
2024.01.15 10:14:33 4: CUL_Parse: CUL866 Z0CB70442088599000000002AC8F4 -80
2024.01.15 10:14:33 5: CUL866: dispatch Z0CB70442088599000000002AC8
2024.01.15 10:17:11 5: CUL_Read: CUL866 /Z0BFB0002471118073200000000
Z0BFB0
2024.01.15 10:17:11 4: CUL_Parse: CUL866 Z0BFB0002471118073200000000 -74
2024.01.15 10:17:11 5: CUL866: dispatch Z0BFB00024711180732000000
2024.01.15 10:17:11 5: CUL_Read: CUL866 Z0BFB0/6300732004711180010EB
2024.01.15 10:17:11 4: CUL_Parse: CUL866 Z0BFB06300732004711180010EB -84.5
2024.01.15 10:17:11 5: CUL866: dispatch Z0BFB06300732004711180010
2024.01.15 10:17:21 5: CUL_Read: CUL866 /Z0CB80442088599000000002AC8F3
2024.01.15 10:17:21 4: CUL_Parse: CUL866 Z0CB80442088599000000002AC8F3 -80.5
2024.01.15 10:17:21 5: CUL866: dispatch Z0CB80442088599000000002AC8
2024.01.15 10:17:25 5: CUL_Read: CUL866 /Z0B46000247111818D57E000000
Z0B46063
2024.01.15 10:17:25 4: CUL_Parse: CUL866 Z0B46000247111818D57E000000 -74
2024.01.15 10:17:25 5: CUL866: dispatch Z0B46000247111818D57E0000
2024.01.15 10:17:25 5: CUL_Read: CUL866 Z0B46063/018D57E4711180010E9
2024.01.15 10:17:25 4: CUL_Parse: CUL866 Z0B46063018D57E4711180010E9 -85.5
2024.01.15 10:17:25 5: CUL866: dispatch Z0B46063018D57E4711180010
2024.01.15 10:20:06 5: CUL_Read: CUL866 /Z0CB90442088599000000002AC8F5
2024.01.15 10:20:06 5: CUL_Read: CUL866 Z0CB90442088599000000002AC8F5
/
2024.01.15 10:20:06 4: CUL_Parse: CUL866 Z0CB90442088599000000002AC8F5 -79.5
2024.01.15 10:20:06 5: CUL866: dispatch Z0CB90442088599000000002AC8
2024.01.15 10:20:11 5: CUL_Read: CUL866 /Z0F000460086B820000000018062600D4
2024.01.15 10:20:11 5: CUL_Read: CUL866 Z0F000460086B820000000018062600D4/11
2024.01.15 10:20:11 4: CUL_Parse: CUL866 Z0F000460086B820000000018062600D411 -65.5
2024.01.15 10:20:11 5: CUL866: dispatch Z0F000460086B820000000018062600D4
2024.01.15 10:23:03 5: CUL_Read: CUL866 /Z0CBA0442088599000000002AC8F4
2024.01.15 10:23:03 4: CUL_Parse: CUL866 Z0CBA0442088599000000002AC8F4 -80
2024.01.15 10:23:03 5: CUL866: dispatch Z0CBA0442088599000000002AC8
2024.01.15 10:25:56 5: CUL_Read: CUL866 /Z0CBB0442088599000000002AC6F4
2024.01.15 10:25:56 4: CUL_Parse: CUL866 Z0CBB0442088599000000002AC6F4 -80
2024.01.15 10:25:56 5: CUL866: dispatch Z0CBB0442088599000000002AC6
2024.01.15 10:27:18 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:27:18 5: CUL_ReadAnswer CUL866: 21 3600
2024.01.15 10:27:18 5: CUL866 sending Zs0b0b08604711180af6880000
2024.01.15 10:27:18 5: DevIo_SimpleWrite CUL866: Zs0b0b08604711180af6880000
2024.01.15 10:27:18 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:27:19 5: CUL_ReadAnswer CUL866: 21 3491
2024.01.15 10:27:19 5: CUL866 sending Zs0b2a08604711180830ad0000
2024.01.15 10:27:19 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:27:19 5: CUL_ReadAnswer CUL866: Z0F0B00600AF6884711180018642B00CEF4
2024.01.15 10:27:19 4: CUL_Parse: CUL866 Z0F0B00600AF6884711180018642B00CEF4 -80
2024.01.15 10:27:19 5: CUL866: dispatch Z0F0B00600AF6884711180018642B00CE
2024.01.15 10:27:19 5: CUL_ReadAnswer CUL866: 21 3492
2024.01.15 10:27:19 5: CUL866 sending Zs0b490860471118086b820000
2024.01.15 10:27:19 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:27:19 5: CUL_ReadAnswer CUL866: 21 3492
2024.01.15 10:27:19 5: CUL866 sending Zs0b54086047111811bfba0000
2024.01.15 10:27:20 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:27:20 5: CUL_ReadAnswer CUL866: 21 3492
2024.01.15 10:27:20 5: CUL866 sending Zs0b010860471118189f290000
2024.01.15 10:27:20 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:27:20 5: CUL_ReadAnswer CUL866: 21 3
2024.01.15 10:27:20 5: CUL_ReadAnswer CUL866: 493
## manuell alle Thermostate abgefragt
2024.01.15 10:27:20 5: CUL866 sending Zs0b580860471118189f2d0000
2024.01.15 10:27:20 5: DevIo_SimpleWrite CUL866: Zs0b2a08604711180830ad0000
2024.01.15 10:27:20 5: DevIo_SimpleWrite CUL866: Zs0b490860471118086b820000
2024.01.15 10:27:21 5: DevIo_SimpleWrite CUL866: Zs0b54086047111811bfba0000
2024.01.15 10:27:21 5: DevIo_SimpleWrite CUL866: Zs0b010860471118189f290000
2024.01.15 10:27:21 5: DevIo_SimpleWrite CUL866: Zs0b580860471118189f2d0000
2024.01.15 10:49:35 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:49:38 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0 disconnected, waiting to reappear (CUL866)
2024.01.15 10:49:38 3: Setting CUL866 serial parameters to 38400,8,N,1
2024.01.15 10:49:38 5: DevIo_SimpleWrite CUL866: V
2024.01.15 10:49:41 5: DevIo_SimpleWrite CUL866: V
2024.01.15 10:49:44 5: DevIo_SimpleWrite CUL866: V
2024.01.15 10:49:47 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0, ignoring it (CUL866)
Der Status hat sich geändert von initialized auf opened.
Scheint am CUL bzw USB oder Netzteil zu liegen. Was evtl bei den Standversionen der MAX Module nicht auffällt.
Noch ein Nachtrag.
in der Logdatei ist noch der Fehler:
2024.01.14 09:43:39 1: PERL WARNING: Use of uninitialized value $value in string eq at ./FHEM/10_MAX.pm line 1751.
2024.01.14 09:43:39 1: PERL WARNING: Use of uninitialized value $value in string eq at ./FHEM/10_MAX.pm line 1752.
An der Position in der 10_MAX.pm steht: if (!AttrNum($name, 'DbLog_log_onoff', 0)) { # Todo ; fehlt in commandref
$value = '4.5' if ( $value eq 'off' );
$value = '30.5' if ( $value eq 'on' );
}
Ich nutze die Aufzeichnung in der Datenbank
Der Fehler ist allerdings identisch bei der originalen 10_MAX.pm.
PERL WARNING: Use of uninitialized value $value in string eq at ./FHEM/10_MAX.pm line 2057.
PERL WARNING: Use of uninitialized value $value in string eq at ./FHEM/10_MAX.pm line 2058.
Ich habe ohne etwas zu verändern fhem neu gestartet mit shutdown restart und kann den CUL868 nicht nutzen.
Restart über sudo service fhem restart ohne Änderung.
Die MAX Dateien wieder auf Standard gesetzt und fhem restart ohne Änderung
Systemdaten ausgelesen vor dem Reboot:
Model: Raspberry Pi 4 Model B Rev 1.5
Debian Bullseye aktuell
cul mit culfw-code-r571-trunk.zip geflasht
Was ist am USB Port:
1 SSD
1 CUL868
1 CUL443
1 ConbeeII Stick
Es fällt nur der CUL868 aus.
root@fhem:/home/pi/fhem/FHEM# sudo ls -l /dev/ttyA*
crw-rw----+ 1 root dialout 166, 0 15. Jan 11:34 /dev/ttyACM0
crw-rw---- 1 root dialout 204, 64 14. Jan 14:05 /dev/ttyAMA0
root@fhem:/home/pi/fhem/FHEM# sudo ls -l /dev/ttyU*
crw-rw----+ 1 root dialout 188, 0 15. Jan 11:21 /dev/ttyUSB0
crw-rw----+ 1 root dialout 188, 1 15. Jan 11:21 /dev/ttyUSB1
root@fhem:/home/pi/fhem/FHEM#
pi@fhem:~ $ vcgencmd get_throttled
throttled=0x0
pi@fhem:~ $ ls -la /dev/serial/by-id
insgesamt 0
drwxr-xr-x 2 root root 100 14. Jan 14:05 .
drwxr-xr-x 4 root root 80 14. Jan 14:05 ..
lrwxrwxrwx 1 root root 13 14. Jan 14:05 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2196162-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 14. Jan 14:05 usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 14. Jan 14:05 usb-FTDI_FT232R_USB_UART_A1062CV0-if00-port0 -> ../../ttyUSB0
pi@fhem:~ $ ls -la /dev/serial/by-path
insgesamt 0
drwxr-xr-x 2 root root 100 14. Jan 14:05 .
drwxr-xr-x 4 root root 80 14. Jan 14:05 ..
lrwxrwxrwx 1 root root 13 14. Jan 14:05 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 14. Jan 14:05 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 14. Jan 14:05 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0 -> ../../ttyUSB1
pi@fhem:~ $
i@fhem:~ $ sudo tail -f /var/log/kern.log
Jan 14 14:05:20 fhem kernel: [ 10.471510] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
Jan 14 14:05:20 fhem kernel: [ 10.476863] bcmgenet fd580000.ethernet eth0: Link is Down
Jan 14 14:05:20 fhem kernel: [ 10.685656] 8021q: 802.1Q VLAN Support v1.8
Jan 14 14:05:20 fhem kernel: [ 11.403781] Adding 102396k swap on /var/swap. Priority:-3 extents:1 across:102396k FS
Jan 14 14:05:20 fhem kernel: [ 11.829021] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Jan 14 14:05:23 fhem kernel: [ 14.560075] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Jan 14 14:05:23 fhem kernel: [ 14.560116] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jan 14 14:05:23 fhem kernel: [ 14.561059] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.200: link becomes ready
Jan 14 14:05:24 fhem kernel: [ 15.663256] node: epoll_ctl support in io_uring is deprecated and will be removed in a future Linux kernel version.
Jan 14 14:05:29 fhem kernel: [ 20.252015] tun: Universal TUN/TAP device driver, 1.6
11:48 sudo reboot mit originalen MAX Dateien.
2024.01.15 11:48:47 0: Server started with 557 defined entities (fhem.pl:28227/2023-11-29 perl:5.032001 os:linux user:fhem pid:864)
2024.01.15 11:48:54 5: CUL866 sending Za471118
2024.01.15 11:48:54 5: DevIo_SimpleWrite CUL866: Za471118
2024.01.15 11:48:54 5: CUL866 sending Zw111111
2024.01.15 11:48:56 1: FHEM2FHEM 192.168.0.110:7072 reappeared (Raspi110fhem)
2024.01.15 11:48:57 5: CUL_Read: CUL866 /Z0CD80442088599000000002AD2F7
2024.01.15 11:48:57 4: CUL_Parse: CUL866 Z0CD80442088599000000002AD2F7 -78.5
2024.01.15 11:48:57 5: CUL866: dispatch Z0CD80442088599000000002AD2
2024.01.15 11:48:57 5: DevIo_SimpleWrite CUL866: Zw111111
2024.01.15 11:51:38 5: DevIo_SimpleWrite CUL866: C0D
2024.01.15 11:51:38 5: CUL_ReadAnswer CUL866: C0D = 21 / 33
2024.01.15 11:51:38 5: DevIo_SimpleWrite CUL866: C0E
2024.01.15 11:51:38 5: CUL_ReadAnswer CUL866: C0E = 65 / 101
2024.01.15 11:51:38 5: DevIo_SimpleWrite CUL866: C0F
2024.01.15 11:51:38 5: CUL_ReadAnswer CUL866: C0F = 6A / 106
2024.01.15 11:51:38 5: DevIo_SimpleWrite CUL866: C10
2024.01.15 11:51:38 5: CUL_ReadAnswer CUL866: C10 = C8 / 200
2024.01.15 11:51:38 5: DevIo_SimpleWrite CUL866: C1B
2024.01.15 11:51:38 5: CUL_ReadAnswer CUL866: C1B = 43 / 67
2024.01.15 11:51:38 5: DevIo_SimpleWrite CUL866: C1D
2024.01.15 11:51:38 5: CUL_ReadAnswer CUL866: C1D = 91 / 145
2024.01.15 11:51:45 5: DevIo_SimpleWrite CUL866: V
2024.01.15 11:51:45 5: CUL_ReadAnswer CUL866: V 1.67 nanoCUL868
2024.01.15 11:51:47 5: CUL_Read: CUL866 /Z0CD90442088599000000002AD0F6
2024.01.15 11:51:47 4: CUL_Parse: CUL866 Z0CD90442088599000000002AD0F6 -79
2024.01.15 11:51:47 5: CUL866: dispatch Z0CD90442088599000000002AD0
2024.01.15 11:51:49 5: DevIo_SimpleWrite CUL866: t
2024.01.15 11:51:49 5: CUL_ReadAnswer CUL866: 0000622D
2024.01.15 11:51:53 5: DevIo_SimpleWrite CUL866: X
2024.01.15 11:51:53 5: CUL_ReadAnswer CUL866: 21 2005
2024.01.15 11:52:00 5: CUL_Read: CUL866 /Z0F000460189F2D00000000181E2000A001
2024.01.15 11:52:00 4: CUL_Parse: CUL866 Z0F000460189F2D00000000181E2000A001 -73.5
2024.01.15 11:52:00 5: CUL866: dispatch Z0F000460189F2D00000000181E2000A0
2024.01.15 11:54:41 5: CUL_Read: CUL866 /Z0C
2024.01.15 11:54:41 5: CUL_Read: CUL866 Z0C/DA0442088599000000002ACFF7
2024.01.15 11:54:41 4: CUL_Parse: CUL866 Z0CDA0442088599000000002ACFF7 -78.5
2024.01.15 11:54:41 5: CUL866: dispatch Z0CDA0442088599000000002ACF
2024.01.15 11:56:22 5: CUL_Read: CUL866 /Z0F000460189F2D00000000182
2024.01.15 11:56:22 5: CUL_Read: CUL866 Z0F000460189F2D00000000182/320009C01
2024.01.15 11:56:22 4: CUL_Parse: CUL866 Z0F000460189F2D00000000182320009C01 -73.5
2024.01.15 11:56:22 5: CUL866: dispatch Z0F000460189F2D00000000182320009C
2024.01.15 11:57:31 5: CUL_Read: CUL866 /Z0CDB0442088599000000002ACFF8
2024.01.15 11:57:31 4: CUL_Parse: CUL866 Z0CDB0442088599000000002ACFF8 -78
2024.01.15 11:57:31 5: CUL866: dispatch Z0CDB0442088599000000002ACF
2024.01.15 11:58:35 5: CUL_Read: CUL866 /Z0B61000247111807320A000000
Z0B61063007320A471118001
2024.01.15 11:58:35 4: CUL_Parse: CUL866 Z0B61000247111807320A000000 -74
2024.01.15 11:58:35 5: CUL866: dispatch Z0B61000247111807320A0000
2024.01.15 11:58:35 5: CUL_Read: CUL866 Z0B61063007320A471118001/00E
2024.01.15 11:58:35 4: CUL_Parse: CUL866 Z0B61063007320A47111800100E -67
2024.01.15 11:58:35 5: CUL866: dispatch Z0B61063007320A4711180010
2024.01.15 11:59:01 5: CUL_Read: CUL866 /Z0FED050308859947111800180F0B3A7AF8
2024.01.15 11:59:01 4: CUL_Parse: CUL866 Z0FED050308859947111800180F0B3A7AF8 -78
2024.01.15 11:59:01 5: CUL866: dispatch Z0FED050308859947111800180F0B3A7A
2024.01.15 11:59:05 5: CUL_Read: CUL866 /Z0FEE050308859947111800180F0B3B43F8
2024.01.15 11:59:05 4: CUL_Parse: CUL866 Z0FEE050308859947111800180F0B3B43F8 -78
2024.01.15 11:59:05 5: CUL866: dispatch Z0FEE050308859947111800180F0B3B43
2024.01.15 11:59:10 5: CUL_Read: CUL866 /Z0FEF050308859947111800180F0B3B48F8
2024.01.15 11:59:10 4: CUL_Parse: CUL866 Z0FEF050308859947111800180F0B3B48F8 -78
2024.01.15 11:59:10 5: CUL866: dispatch Z0FEF050308859947111800180F0B3B48
2024.01.15 12:00:11 5: CUL_Read: CUL866 /Z0F000460
2024.01.15 12:00:11 5: CUL_Read: CUL866 Z0F000460/086B820000000018062600D408
2024.01.15 12:00:11 4: CUL_Parse: CUL866 Z0F000460086B820000000018062600D408 -70
2024.01.15 12:00:11 5: CUL866: dispatch Z0F000460086B820000000018062600D4
2024.01.15 12:00:12 5: CUL_Read: CUL866 /Z0F000460189F2900000000180010007A1C
2024.01.15 12:00:12 4: CUL_Parse: CUL866 Z0F000460189F2900000000180010007A1C -60
2024.01.15 12:00:12 5: CUL866: dispatch Z0F000460189F2900000000180010007A
2024.01.15 12:00:31 5: CUL_Read: CUL866 /Z0F00046011BFBA00
2024.01.15 12:00:31 5: CUL_Read: CUL866 Z0F00046011BFBA00/00000019000E005AED
2024.01.15 12:00:31 4: CUL_Parse: CUL866 Z0F00046011BFBA0000000019000E005AED -83.5
2024.01.15 12:00:31 5: CUL866: dispatch Z0F00046011BFBA0000000019000E005A
2024.01.15 12:00:34 5: CUL_Read: CUL866 /Z0FF004700885990000000059042A0
2024.01.15 12:00:34 5: CUL_Read: CUL866 Z0FF004700885990000000059042A0/0CEF8
2024.01.15 12:00:34 4: CUL_Parse: CUL866 Z0FF004700885990000000059042A00CEF8 -78
2024.01.15 12:00:34 5: CUL866: dispatch Z0FF004700885990000000059042A00CE
2024.01.15 12:00:44 5: CUL_Read: CUL866 /Z0F000460189F2D0000000
2024.01.15 12:00:44 5: CUL_Read: CUL866 Z0F000460189F2D0000000/0182320009C01
2024.01.15 12:00:44 4: CUL_Parse: CUL866 Z0F000460189F2D00000000182320009C01 -73.5
2024.01.15 12:00:44 5: CUL866: dispatch Z0F000460189F2D00000000182320009C
2024.01.15 12:00:54 5: CUL_Read: CUL866 /Z0F0004600830AD0000000018142300C2F4
2024.01.15 12:00:54 4: CUL_Parse: CUL866 Z0F0004600830AD0000000018142300C2F4 -80
2024.01.15 12:00:54 5: CUL866: dispatch Z0F0004600830AD0000000018142300C2
2024.01.15 12:03:15 5: CUL_Read: CUL866 /Z0CDD04420
2024.01.15 12:03:15 5: CUL_Read: CUL866 Z0CDD04420/88599000000002ACEF8
2024.01.15 12:03:15 4: CUL_Parse: CUL866 Z0CDD0442088599000000002ACEF8 -78
2024.01.15 12:03:15 5: CUL866: dispatch Z0CDD0442088599000000002ACE
2024.01.15 12:06:10 5: CUL_Read: CUL866 /Z0CDE0442088599000000002ACEF8
2024.01.15 12:06:10 4: CUL_Parse: CUL866 Z0CDE0442088599000000002ACEF8 -78
2024.01.15 12:06:10 5: CUL866: dispatch Z0CDE0442088599000000002ACE
2024.01.15 12:07:25 5: CUL_Read: CUL866 /Z0B46
2024.01.15 12:07:25 5: CUL_Read: CUL866 Z0B46/000247111818D57E000000
Z0B46063018D57E4711180010E7
2024.01.15 12:07:25 4: CUL_Parse: CUL866 Z0B46000247111818D57E000000 -74
2024.01.15 12:07:25 5: CUL866: dispatch Z0B46000247111818D57E0000
2024.01.15 12:07:25 4: CUL_Parse: CUL866 Z0B46063018D57E4711180010E7 -86.5
2024.01.15 12:07:25 5: CUL866: dispatch Z0B46063018D57E4711180010
2024.01.15 12:09:02 5: CUL_Read: CUL866 /Z0CDF0
2024.01.15 12:09:02 5: CUL_Read: CUL866 Z0CDF0/442088599000000002ACDF6
2024.01.15 12:09:02 4: CUL_Parse: CUL866 Z0CDF0442088599000000002ACDF6 -79
2024.01.15 12:09:02 5: CUL866: dispatch Z0CDF0442088599000000002ACD
2024.01.15 12:11:29 5: DevIo_SimpleWrite CUL866: X
2024.01.15 12:11:29 5: CUL_ReadAnswer CUL866: 21 3161
Nach 20 Stunden mit den originalen Modulen ohne Fehler.
ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB 2024-01-16 08:12:16
cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z 2024-01-16 08:12:22
credit10ms 3600 2024-01-16 08:12:28
fhtbuf AE 2024-01-16 08:12:33
state Initialized 2024-01-16 08:11:42
uptime 0 20:23:26 2024-01-16 08:12:41
version V 1.67 nanoCUL868 2024-01-16 08:12:46
Ändere ich wieder auf die 3 MAX Dateien aus dem ersten posting und starte das System mit shutdown restart neu damit die Dateien aktiviert werden.
Verwendete MAX Geräte:
1 Heating Thermostat+
3 Heating Thermostat
2 Heating Thermostat basic
7 Fenster Sensoren
1 Wandthermostat
Sonst ist nichts im 868 MHz Bereich akitivert bzw verbunden.
An der fhem Konfiguration, am Raspberry und das Netzteil ist auch alles unverändert.
Ich wollte eigentlich ein verbose 4/5 Log des CUL_MAX Device sehen um vllt etwas Klarheit über die Sendqueue bzw deine Credits zu bekommen, du hast aber das CUL Device hochgeschraubt und dessen Logzeilen sagen halt darüber nichts aus. Aber OK egal, dein Hauptproblem liegt wohl im/am CUL selbst der sich nach einer Stunde verabschiedet :
2024.01.15 10:49:35 5: DevIo_SimpleWrite CUL866: X
2024.01.15 10:49:38 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0 disconnected, waiting to reappear (CUL866)
2024.01.15 10:49:38 3: Setting CUL866 serial parameters to 38400,8,N,1
2024.01.15 10:49:38 5: DevIo_SimpleWrite CUL866: V
2024.01.15 10:49:41 5: DevIo_SimpleWrite CUL866: V
2024.01.15 10:49:44 5: DevIo_SimpleWrite CUL866: V
2024.01.15 10:49:47 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0, ignoring it (CUL866)unklar ist mir dabei woher das gesendete X kommt und ob es einen direkten Zusammenhang gibt das der CUL anschliessend nicht mehr erreichbar ist - das wäre dann eh eine Frage an Leute die Ahnung von dem Ding haben. Warum dein Problem nur mit der Beta Version und nicht mit der aus dem SVN auftritt kann ich an der Stelle auch nicht beantworten. Hast du denn mit der Beta zusätzliche Dinge laufen die bei der SVN Version nicht aktiv sind , wie z.b das hier :
Zitat## manuell alle Thermostate abgefragt
Was ich auch nicht verstehe ist du schreibst immer von drei (3) Dateien, wieso das ?
Wenn du den CUL im Einsatz hast sind es 14_CUL_MAX und 10_MAX und beim Cube 00_MAXLAN und 10_MAX
Zitat von: Wzut am 16 Januar 2024, 10:42:01Was ich auch nicht verstehe ist du schreibst immer von drei (3) Dateien, wieso das ?
Wenn du den CUL im Einsatz hast sind es 14_CUL_MAX und 10_MAX und beim Cube 00_MAXLAN und 10_MAX
Ich habe immer alle Dateien die im ersten Post verlinkt sind übertragen, da ich davon ausgehe, dass unbenötigte Dateien nur Speicherplatz benötigen aber nicht verwendet werden.
Falls die Systemlogik aber beinhaltet, dass nur genutzte Dateien unter fhem/FHEM liegen dürfen, dann muss dort mal kräftig aufgeräumt werden.
Im Moment sind dort 653 Dateien. Abzüglich 6 für die kopierten und umbenannten Dateien aus dem ersten Post mit den Endungen pm.org bzw pm.beta.
Ich schalte mal verbose 5 bei dem genutzen Device an und starte fhem neu.
Es gibt noch eine Routine in der zu allen Heizungsreglern alle 20 Minuten der Befehl getStatus gesandt wird. der läuft in Fehler wenn das originale MAX Modul aktiv ist.
Die Zeitroutine deaktivier ich auch.
Zitat von: _fhemuser_ am 16 Januar 2024, 10:54:17da ich davon ausgehe, dass unbenötigte Dateien nur Speicherplatz benötigen aber nicht verwendet werden.
stimmt ja auch, ich wollte lediglich deine 3 verstehen und gleichzeitig sichergehen das da nicht auch noch ein Cube zusätzlich werkelt.
Ich habe wohl den Fehler gefunden.
2024.01.16 12:23:43 3: MAX_CUL_Stick, device [072bc3] ShutterContact Badfenster want to be re-paired to [098109] MAX_098109, not to us [ 471118 ] - ignoring !
Der Fensterkontakt hat versucht Datenpakete zu dem deaktivierten Cube MAX_098109 zu senden.
Fensterkontakt und zugehörigen Heizungsthermostat resettet und neu angelernt am CUL868.
Zu früh gefreut. Der Fehlerr tritt noch auf. Vermutlich liegt es an dem getStatus eines Devices.
Wenn ich nur 2 Devices abfrage läuft das System mehr als 10 Stunden problemlos. Nachdem ich bei 4 Devices getStatatus abfrage, hängt sich das System auf.
2024.01.17 07:23:41 4: CUL_Parse: CUL866 Z0C6904420885990000000026BFFA -77
2024.01.17 07:23:41 5: CUL866: dispatch Z0C6904420885990000000026BF
2024.01.17 07:23:41 4: MAX_CUL_Stick, C: 69, F: 04, T: 42, S: 088599 D: 000000 G: 00 P: 26BF
2024.01.17 07:23:41 4: MAX_CUL_Stick, IODev CUL866, flags 04, msgcnt 69, msgType WallThermostatControl, src 088599 WallMountedThermostat, dst 000000 Broadcast, group 0, payload 26BF, rssi -77
2024.01.17 07:23:41 5: MAX_CUL_Stick: dispatch MAX,0,WallThermostatControl,088599,26BF
2024.01.17 07:23:41 5: MAX_Parse, MAX,0,WallThermostatControl,088599,26BF
2024.01.17 07:24:00 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:17, flags:08, Cmd2id:60, src:MAX_471118, dst:Wohn, gid:00, payload:00, cul:none
2024.01.17 07:24:00 5: MAX_CUL_Stick, packet to SQH : 0b1708604711180af6880000
2024.01.17 07:24:00 5: MAX_CUL_Stick, Send Queue : 1 packet are in the queue
2024.01.17 07:24:00 5: DevIo_SimpleWrite CUL866: X
2024.01.17 07:24:00 5: CUL_ReadAnswer CUL866: 21 3600
2024.01.17 07:24:00 5: MAX_CUL_Stick, Send Queue CUL866 -> needPreamble: 1, necessaryCredit: 110, credit10ms: CUL866 = 3600, CMD_LAST_H: 10
2024.01.17 07:24:00 5: CUL866 sending Zs0b1708604711180af6880000
2024.01.17 07:24:00 5: DevIo_SimpleWrite CUL866: Zs0b1708604711180af6880000
2024.01.17 07:24:00 4: MAX_CUL_Stick, Send Queue packet send : Zs0b1708604711180af6880000 to Wohn with CUL866
2024.01.17 07:24:00 5: MAX_CUL_Stick, Send Queue is now empty
2024.01.17 07:24:00 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:16, flags:08, Cmd2id:60, src:MAX_471118, dst:Kueche, gid:00, payload:00, cul:none
2024.01.17 07:24:00 5: MAX_CUL_Stick, packet to SQH : 0b160860471118086b820000
2024.01.17 07:24:00 5: MAX_CUL_Stick, Send Queue : 1 packet are in the queue
2024.01.17 07:24:00 5: DevIo_SimpleWrite CUL866: X
2024.01.17 07:24:01 5: CUL_ReadAnswer CUL866: 21 34
2024.01.17 07:24:01 5: CUL_ReadAnswer CUL866: 91
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue CUL866 -> needPreamble: 1, necessaryCredit: 110, credit10ms: CUL866 = 3491, CMD_LAST_H: 11
2024.01.17 07:24:01 5: CUL866 sending Zs0b160860471118086b820000
2024.01.17 07:24:01 4: MAX_CUL_Stick, Send Queue packet send : Zs0b160860471118086b820000 to Kueche with CUL866
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue is now empty
2024.01.17 07:24:01 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:0e, flags:08, Cmd2id:60, src:MAX_471118, dst:Buro, gid:00, payload:00, cul:none
2024.01.17 07:24:01 5: MAX_CUL_Stick, packet to SQH : 0b0e086047111811bfba0000
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue : 1 packet are in the queue
2024.01.17 07:24:01 5: DevIo_SimpleWrite CUL866: X
2024.01.17 07:24:01 5: CUL_ReadAnswer CUL866: Z0F1700600AF6884711180018642B00C4F2
2024.01.17 07:24:01 4: CUL_Parse: CUL866 Z0F1700600AF6884711180018642B00C4F2 -81
2024.01.17 07:24:01 5: CUL866: dispatch Z0F1700600AF6884711180018642B00C4
2024.01.17 07:24:01 4: MAX_CUL_Stick, C: 17, F: 00, T: 60, S: 0AF688 D: 471118 G: 00 P: 18642B00C4
2024.01.17 07:24:01 4: MAX_CUL_Stick, IODev CUL866, flags 00, msgcnt 17, msgType ThermostatState, src 0af688 HeatingThermostat, dst 471118 CUL_MAX, group 0, payload 18642B00C4, rssi -81
2024.01.17 07:24:01 5: MAX_CUL_Stick: dispatch MAX,1,ThermostatState,0af688,18642B00C4
2024.01.17 07:24:01 5: MAX_Parse, MAX,1,ThermostatState,0af688,18642B00C4
2024.01.17 07:24:01 5: CUL_ReadAnswer CUL866: 21 3492
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue CUL866 -> needPreamble: 1, necessaryCredit: 110, credit10ms: CUL866 = 3492, CMD_LAST_H: 11
2024.01.17 07:24:01 5: CUL866 sending Zs0b0e086047111811bfba0000
2024.01.17 07:24:01 4: MAX_CUL_Stick, Send Queue packet send : Zs0b0e086047111811bfba0000 to Buro with CUL866
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue is now empty
2024.01.17 07:24:01 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:0b, flags:08, Cmd2id:60, src:MAX_471118, dst:Schlaf, gid:00, payload:00, cul:none
2024.01.17 07:24:01 5: MAX_CUL_Stick, packet to SQH : 0b0b0860471118189f2d0000
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue : 1 packet are in the queue
2024.01.17 07:24:01 5: DevIo_SimpleWrite CUL866: X
2024.01.17 07:24:01 5: CUL_ReadAnswer CUL866: 21 3492
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue CUL866 -> needPreamble: 1, necessaryCredit: 110, credit10ms: CUL866 = 3492, CMD_LAST_H: 11
2024.01.17 07:24:01 5: CUL866 sending Zs0b0b0860471118189f2d0000
2024.01.17 07:24:01 4: MAX_CUL_Stick, Send Queue packet send : Zs0b0b0860471118189f2d0000 to Schlaf with CUL866
2024.01.17 07:24:01 5: MAX_CUL_Stick, Send Queue is now empty
2024.01.17 07:24:02 5: DevIo_SimpleWrite CUL866: Zs0b160860471118086b820000
2024.01.17 07:24:02 5: DevIo_SimpleWrite CUL866: Zs0b0e086047111811bfba0000
2024.01.17 07:24:02 5: DevIo_SimpleWrite CUL866: Zs0b0b0860471118189f2d0000
2024.01.17 07:36:00 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:18, flags:08, Cmd2id:60, src:MAX_471118, dst:Wohn, gid:00, payload:00, cul:none
2024.01.17 07:36:00 5: MAX_CUL_Stick, packet to SQH : 0b1808604711180af6880000
2024.01.17 07:36:00 5: MAX_CUL_Stick, Send Queue : 1 packet are in the queue
2024.01.17 07:36:00 5: DevIo_SimpleWrite CUL866: X
2024.01.17 07:36:03 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0 disconnected, waiting to reappear (CUL866)
2024.01.17 07:36:03 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:17, flags:08, Cmd2id:60, src:MAX_471118, dst:Kueche, gid:00, payload:00, cul:none
2024.01.17 07:36:03 5: MAX_CUL_Stick, packet to SQH : 0b170860471118086b820000
2024.01.17 07:36:03 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:0f, flags:08, Cmd2id:60, src:MAX_471118, dst:Buro, gid:00, payload:00, cul:none
2024.01.17 07:36:03 5: MAX_CUL_Stick, packet to SQH : 0b0f086047111811bfba0000
2024.01.17 07:36:03 4: MAX_CUL_Stick, send -> cmd:ThermostatState, msgcnt:0c, flags:08, Cmd2id:60, src:MAX_471118, dst:Schlaf, gid:00, payload:00, cul:none
2024.01.17 07:36:03 5: MAX_CUL_Stick, packet to SQH : 0b0c0860471118189f2d0000
2024.01.17 07:36:06 5: MAX_CUL_Stick, Send Queue : 4 packets are in the queue
2024.01.17 07:36:06 5: DevIo_SimpleWrite CUL866: X
2024.01.17 07:36:06 3: Setting CUL866 serial parameters to 38400,8,N,1
2024.01.17 07:36:07 5: DevIo_SimpleWrite CUL866: V
2024.01.17 07:36:10 5: DevIo_SimpleWrite CUL866: V
2024.01.17 07:36:13 5: DevIo_SimpleWrite CUL866: V
2024.01.17 07:36:16 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0, ignoring it (CUL866)
2024.01.17 07:36:16 5: MAX_CUL_Stick, Send Queue : 4 packets are in the queue
2024.01.17 07:36:16 5: DevIo_SimpleWrite CUL866: X
2024.01.17 07:36:21 5: MAX_CUL_Stick, Send Queue : 4 packets are in the queue
2024.01.17 07:36:21 5: DevIo_SimpleWrite CUL866: X
Ich Teste mal verschiedene Kombinationen. Evtl liegt das an den unterschiedlichen MAX Geräten oder man darf nicht bei mehr als 2 Geräten gleichzeitig die Abfrage starten.
Ich habe gestern Abend nochmal alle 12 Seiten hier im Fred gelesen.
Dein Problem haben/hatten zwei andere User auch, beide haben kräftig getStatus genutzt.
Lösung könnte so aussehen :
getStatus nicht zu oft anwenden und dann mit entsprechenden Pausen immer nur auf ein Device.
Die Pausen sind wohl insoweit nötig damit das Device auch genügend Zeit hat zu antworten bevor schon das nächste Device angefragt wird. (bzw. der CUL ist der eigentliche Flaschenhals)
Wie schaut denn deine getStatus Abfrage aus ?, postet doch bitte mal ein List.
Das aktuelle sieht so aus:
define DF_getStatus DOIF ([+:12])\
(\
(set Wohn getStatus)\
###(set Bad getStatus)\
(set Kueche getStatus)\
(set Buro getStatus)\
###(set Hausflur getStatus)\
###(set Schlaf getStatus)\
)\
attr DF_getStatus disable 0
attr DF_getStatus do always
attr DF_getStatus icon time_clock
attr DF_getStatus initialize cmd1
attr DF_getStatus room Heizkoerper->-Heizkoerper
attr DF_getStatus startup $SELF cmd_1
attr DF_getStatus verbose 0
# DEF ([+:12])
#(
#(set Wohn getStatus)
####(set Bad getStatus)
#(set Kueche getStatus)
#(set Buro getStatus)
####(set Hausflur getStatus)
####(set Schlaf getStatus)
#)
#
# FUUID 65a6a06f-f33f-d33d-b2bc-30d80d64b78f7165
# MODEL FHEM
# NAME DF_getStatus
# NOTIFYDEV global
# NR 901
# NTFY_ORDER 50-DF_getStatus
# STATE initialized
# TYPE DOIF
# VERSION 27740 2023-07-10 09:31:11
# eventCount 10
# Helper:
# DBLOG:
# cmd:
# logdb:
# TIME 1705485524.08146
# VALUE 0
# cmd_event:
# logdb:
# TIME 1705484881.89881
# VALUE timer_3
# cmd_nr:
# logdb:
# TIME 1705484881.89881
# VALUE 2
# mode:
# logdb:
# TIME 1705485524.08146
# VALUE enabled
# state:
# logdb:
# TIME 1705485524.08146
# VALUE initialized
# READINGS:
# 2024-01-17 10:58:43 cmd 0
# 2024-01-17 10:58:43 mode enabled
# 2024-01-17 10:58:43 state initialized
# 2024-01-17 10:58:44 timer_01_c01 17.01.2024 11:00:00
# Regex:
# accu:
# bar:
# barAvg:
# collect:
# attr:
# cmdState:
# waitdel:
# condition:
# 0 ::DOIF_time_once($hash,0,$wday)
# days:
# do:
# 0:
# 0 (set Wohn getStatus) (set Kueche getStatus) (set Buro getStatus)
# 1:
# helper:
# NOTIFYDEV global
# globalinit 1
# last_timer 1
# sleeptimer -1
# intervalfunc:
# localtime:
# 0 1705485600
# realtime:
# 0 11:00:00
# time:
# 0 +:12
# timeCond:
# 0 0
# timer:
# 0 0
# timers:
# 0 0
# triggertime:
# 1705485600:
# localtime 1705485600
# hash:
# uiState:
# uiTable:
#
setstate DF_getStatus initialized
setstate DF_getStatus 2024-01-17 10:58:43 cmd 0
setstate DF_getStatus 2024-01-17 10:58:43 mode enabled
setstate DF_getStatus 2024-01-17 10:58:43 state initialized
setstate DF_getStatus 2024-01-17 10:58:44 timer_01_c01 17.01.2024 11:00:00
einfach alle 12 Minuten an alle Devices getStatus senden. 3 sind momentan aktiv und 3 ausge###
gehe mal zurück zu Antwort #106 da hat dirk.k seine DOIF Lösung gepostet - wenn ich das da recht verstehe hat er eine Entzerrung von 1,5 Sekunden drin. (wäre mir persönlich noch zu wenig)
Eine Antwort weiter stellt michael.winkler seine at Lösung vor und ein Stück weiter #122 scheitert wieder jemand mit DOIF und ich habe schon damals in #123 vorgeschlagen eine LightScene zu verwenden und mit async_delay zu arbeiten
ich habe das Zeitintervall mal auf 15 Minuten gestellt, eine Klammerebene entfernt damit wait funktioniert und die waittime auf 60,60,60,60,60,60 eingestellt
define DF_getStatus DOIF ([+:15])\
(set Wohn getStatus)\
(set Bad getStatus)\
(set Kueche getStatus)\
(set Buro getStatus)\
(set Hausflur getStatus)\
(set Schlaf getStatus)\
\
attr DF_getStatus disable 0
attr DF_getStatus do always
attr DF_getStatus icon time_clock
attr DF_getStatus initialize cmd1
attr DF_getStatus room Heizkoerper->-Heizkoerper
attr DF_getStatus startup $SELF cmd_1
attr DF_getStatus verbose 0
attr DF_getStatus wait 60,60,60,60,60,60
# DEF ([+:15])
#(set Wohn getStatus)
#(set Bad getStatus)
#(set Kueche getStatus)
#(set Buro getStatus)
#(set Hausflur getStatus)
#(set Schlaf getStatus)
#
#
# FUUID 65a6a06f-f33f-d33d-b2bc-30d80d64b78f7165
# MODEL FHEM
# NAME DF_getStatus
# NOTIFYDEV global
# NR 901
# NTFY_ORDER 50-DF_getStatus
# STATE initialized
# TYPE DOIF
# VERSION 27740 2023-07-10 09:31:11
# eventCount 23
# Helper:
# DBLOG:
# cmd:
# logdb:
# TIME 1705487130.54783
# VALUE 0
# cmd_event:
# logdb:
# TIME 1705487103.42349
# VALUE timer_1
# cmd_nr:
# logdb:
# TIME 1705487103.42349
# VALUE 1
# cmd_seqnr:
# logdb:
# TIME 1705487103.42349
# VALUE 2
# mode:
# logdb:
# TIME 1705487130.54783
# VALUE enabled
# state:
# logdb:
# TIME 1705487130.54783
# VALUE initialized
# wait_timer:
# logdb:
# TIME 1705487103.45744
# VALUE 17.01.2024 11:26:03 cmd_1_3 timer_1
# READINGS:
# 2024-01-17 11:25:30 cmd 0
# 2024-01-17 11:25:30 mode enabled
# 2024-01-17 11:25:30 state initialized
# 2024-01-17 11:25:30 timer_01_c01 17.01.2024 11:30:00
# Regex:
# accu:
# bar:
# barAvg:
# collect:
# attr:
# cmdState:
# wait:
# 0:
# 60
# 60
# 60
# 60
# 60
# 60
# waitdel:
# condition:
# 0 ::DOIF_time_once($hash,0,$wday)
# days:
# do:
# 0:
# 0 set Wohn getStatus
# 1 set Bad getStatus
# 2 set Kueche getStatus
# 3 set Buro getStatus
# 4 set Hausflur getStatus
# 5 set Schlaf getStatus
# 1:
# helper:
# NOTIFYDEV global
# globalinit 1
# last_timer 1
# sleeptimer -1
# intervalfunc:
# localtime:
# 0 1705487400
# realtime:
# 0 11:30:00
# time:
# 0 +:15
# timeCond:
# 0 0
# timer:
# 0 0
# timers:
# 0 0
# triggertime:
# 1705487400:
# localtime 1705487400
# hash:
# uiState:
# uiTable:
#
setstate DF_getStatus initialized
setstate DF_getStatus 2024-01-17 11:25:30 cmd 0
setstate DF_getStatus 2024-01-17 11:25:30 mode enabled
setstate DF_getStatus 2024-01-17 11:25:30 state initialized
setstate DF_getStatus 2024-01-17 11:25:30 timer_01_c01 17.01.2024 11:30:00
Zitat von: _fhemuser_ am 15 Januar 2024, 12:15:54in der Logdatei ist noch der Fehler:
2024.01.14 09:43:39 1: PERL WARNING: Use of uninitialized value $value in string eq at ./FHEM/10_MAX.pm line 1751.
2024.01.14 09:43:39 1: PERL WARNING: Use of uninitialized value $value in string eq at ./FHEM/10_MAX.pm line 1752.
ist gefixt, 10_MAX.pm im ersten Beitrag ausgetauscht
Erfolgsmeldung.
Wenn die automatisierten getStatus Abfragen in zeitlichen Abständen zwischen den Geräten und nicht häufiger als 4mal pro Stunde eingestellt sind funktioniert es sehr gut.
Aktuell lasse ich getStatus im Abstand von 9 Sekunden zwischen den Geräten auslesen und wiederhole das alle 15 Minuten. Damit werden alle Geräte innerhalb einer Minute aktualisiert und viermal pro Stunde.
Jede Abfrage benötigt 110 credits. Bei 6 Geräten ist damit sichergestellt, dass die credits sich auf 3600 erholen bevor wieder getStatus abgefragt wird. Verbraucht werden 660 credits in 15 Minuten und wir hätten 900 zur Verfügung. Die Wiederholrate von 15 Miunten kann bei weniger Geräten verkürzt und muss bei mehr Geräten entsprechend verlängert werden.
@Wzut vielen Dank für den Support
Zitatmichael.winkler 06 Dezember 2021, 16:16:52
Mal ein kurzes Fazit zu meinen BETA Tests.
Sobald ich den AT gesetzt hatte, der alle 5 Minuten, an 9 Thermostate ein getStatus gesendet hatte. Hat es nicht lange gedauert bis einige Thermostate komische Werte bei der Temperatur angezeigt hatten. Hier wurden dann z.B. 58 Grad angezeigt. Das Aktualisieren an sich hat auch nicht wirklich funktioniert. Zum Schluss hatte an jedes Thermostat 2x einen getStatus abgesendet. Dazwischen ein sleep von 2 Sekunden. Das hat aber leider auch nicht den gewünschten Erfolg gebracht.
Hallo,
ist zwar schon etwas länger her, ich habe bei mit eine Lösung gefunden.
Ich habe 2 HT eingesetzt. Einer mit FW 1.6, der andere mit FW 1.8.
Der mit FW 1.6 liefert korrekte Temperaturwerte mit: getStatus.
Der mit FW 1.8 benötigt für korrekte Temperturen: getStatus curTemp
Die Module laufen sehr gut.
Viele Grüße
Zitat von: west2107 am 28 Januar 2024, 13:34:59Hallo,
ist zwar schon etwas länger her, ich habe bei mit eine Lösung gefunden.
Ich habe 2 HT eingesetzt. Einer mit FW 1.6, der andere mit FW 1.8.
Der mit FW 1.6 liefert korrekte Temperaturwerte mit: getStatus.
Der mit FW 1.8 benötigt für korrekte Temperturen: getStatus curTemp
Die Module laufen sehr gut.
Viele Grüße
Ich habe Thermostaten mit allen möglichen Firmwares von 1.0 bis 1.8 alle funktionieren nur mit getStatus inzwischen sehr gut und stabil. Zu beachten ist jedoch, dass die letzten ausgeliferten MAX Thermostate eine geänderte Hardware beinhalten und nur mit Firmware 1.0 ausgeliefert wurden. Ich meine, dass die identisch zur 1.8 war. Im ELV Forum findet sich bestimmt noch ein Eintrag dazu.
Beachte bitte, dass die credits immer vorhanden sein müssen wie in meinem Betrag darüber bereits erläutert
Zitat von: Wzut am 05 März 2023, 11:45:06Ich habe die 14_CUL_MAX im ersten Post ausgetauscht, jetzt wird eine Fehlermeldung ins Log geschrieben falls ein ungültiges Zeittelegramm empfangen wurde , Bsp :
023.03.05 11:01:08 1: CULMAX0, TimeInformation error from [0f30c1] : Month '12' out of range 0..11 at ./FHEM/14_CUL_MAX.pm line 860.
Ich hatte heute auch das erste mal einen FHEM Absturz nach folgendem Fehler:
2024.03.15 17:52:29 2: cm, unknown message type 1A from MAX_6e7f00 [6e7f00] to MAX_21d84f [6e7f00] - ignoring !
2024.03.15 17:53:50 1: PERL WARNING: Use of uninitialized value $f3 in bitwise and (&) at ./FHEM/14_CUL_MAX.pm line 826.
2024.03.15 17:53:50 1: PERL WARNING: Use of uninitialized value $f4 in bitwise and (&) at ./FHEM/14_CUL_MAX.pm line 827.
2024.03.15 17:53:50 1: PERL WARNING: Use of uninitialized value $f5 in bitwise and (&) at ./FHEM/14_CUL_MAX.pm line 828.
2024.03.15 17:53:50 1: PERL WARNING: Use of uninitialized value $f4 in right bitshift (>>) at ./FHEM/14_CUL_MAX.pm line 829.
2024.03.15 17:53:50 1: PERL WARNING: Use of uninitialized value $f5 in right bitshift (>>) at ./FHEM/14_CUL_MAX.pm line 829.
Month '-1' out of range 0..11 at ./FHEM/14_CUL_MAX.pm line 831.Bin dann auf den Post gestoßen, wo zumindest augenscheinlich das Error Handling in der 14_CUL_MAX verbessert wurde.
Ich verwende seit dem 4. Januar 2023 angehängte 14_CUL_MAX und kann darin keine Versionierung erkennen. Gibt es hier eine aktuellere bzw. unterscheidet sich diese zu Post 1?
Danke und Gruß
sTaN
Zitat von: sTaN am 15 März 2024, 18:57:24Ich verwende seit dem 4. Januar 2023 angehängte 14_CUL_MAX und kann darin keine Versionierung erkennen.
Die Version steht im Internal SVN , habe die Version im ersten Post auf das heutige Datum gesetzt und die fängt wie schon die vorherige Version eventuell auftretende ungültigen Zeitstempel ab - im Gegensatz zu deiner angehängten alten Version.
Danke Wzut,
man kann aber nicht auf seiner lokalen z.B.: RaspberryPi Installation sehen, welche Datei Version verwendet wird und diese mit der aktuellsten vergleichen, oder?
Gruß
sTaN
Doch, das Internal SVN zeigt den Stand an.