CUNO 1.61 Fehler im Log: unknown message LENERR

Begonnen von cfi, 11 September 2014, 21:54:01

Vorheriges Thema - Nächstes Thema

cfi

Hallo,

ich habe 2 CUNO's. Nach dem Update auf 1.61 bekomme ich auf einen CUNO die Fehlermeldung:
1. Fehler
unknown message LENERR

Die CUNO's laufen mit rfmode MAX.


Der CUNO, der den Fehler meldet hat diese Einstellungen. Der 1. CUNO die Gleichen. Ich habe zwei, um 7 Heizthermostate und 1 Fensterkontakt im Haus zu erreichen.

define cuno_2 CUL <IP>:2323 0000
attr cuno_2 icon cul_868
attr cuno_2 rfmode MAX



Update auf FHEM ist mit
update
und
shutdown restart
gemacht.

Server started with 135 defined entities (version $Id: fhem.pl 6498 2014-09-01 19:24:40Z rudolfkoenig $, os linux, user fhem, pid 14671)

2.Fehler
Desweiteren habe ich diese Meldungen, die möglicherweise auch damit zusammenhängen:

2014.09.11 21:12:52 2: CUL_MAX_SendQueueHandler: Missing ack from 066b81 for 0a4000401234066b810060
2014.09.11 21:12:52 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 109. Waiting 105 seconds.
2014.09.11 21:14:44 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 109. Waiting 103 seconds.
2014.09.11 21:16:33 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 109. Waiting 102 seconds.
2014.09.11 21:18:15 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 107, but we need 109. Waiting 2 seconds.
2014.09.11 21:18:24 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 109. Waiting 102 seconds.
2014.09.11 21:20:09 2: CUL_MAX_SendQueueHandler: Missing ack from 066bae for 0a3f00401234066bae0060
2014.09.11 21:20:09 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 109. Waiting 106 seconds.
2014.09.11 21:22:02 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 109. Waiting 102 seconds.
2014.09.11 21:23:51 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 109. Waiting 102 seconds.
2014.09.11 21:25:39 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 109. Waiting 103 seconds.
2014.09.11 21:27:26 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0a8900401234066b660060
2014.09.11 21:27:26 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 109. Waiting 105 seconds.
2014.09.11 21:29:17 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 109. Waiting 103 seconds.
2014.09.11 21:31:07 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 109. Waiting 103 seconds.
2014.09.11 21:32:57 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 109. Waiting 101 seconds.


Ich weiß, dass dies an der 1% Regelung liegt. Allerdings sollte doch die Anzahl meiner MAX! Geräte (8 Stück) problemlos laufen, oder?

Der 1. Fehler kam erst nach dem Update auf 1.61. Der 2. Fehler war vorher schon vorhanden, aber nicht so häufig.
Was könnte die Ursache für diese Fehler sein?

Danke und Gruß cfi


Puschel74

Moin,

du schreibst von MAX und postest im IT-Bereich?
Absicht oder Fehler?

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

cfi

Hi,

sorry war ein Fehler. Bitte nach MAX verschieben.

Gruß cfi

John

Hi cfi,

zum 2. Fehler:
CUL/Cuno realsieren den Sendebefehl bis zu 3x, wenn kein ACK durch das Device erfolgt.
Das "frisst" natürlich jede Menge Credits.
Wenn dies häufiger auftritt, hat man praktisch immer einen Mangel an Credits.

Ein sporadische Ausbleiben etwa 1x pro Tag sollte kein Problem sein.
Die Frage ist natürlich auch wie aktiv du FHEM einsetzt (Häufigkeit der Sendebefehle).

Bei folgender Kombination ist der Mangel an Credits sicher durch den fehlenden ACK verursacht
Zitat
2014.09.11 21:12:52 2: CUL_MAX_SendQueueHandler: Missing ack from 066b81 for 0a4000401234066b810060
2014.09.11 21:12:52 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 109. Waiting 105 seconds.

Bei den übrigen Einträgen, scheinen die Ursachen andere zu sein.

Wie betreibst du die Thermostate ?

Wird das Tagesprogramm HT-intern abgewickelt oder via FHEM-Modul ?

Welche Aktivitäten gehen von FHEM in Richtung HT aus ?

Bei meinem CUL würde ich hier das Attribut verbose von CUL_MAX-Modul auf 5 stellen, um hierzu weitere Informationen zu erhalten.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cfi

#4
Hi John,

ich nutze deinen MAX! Temperatur-Scanner. Das hat immer Super geklappt. Nun nach dem Sommer, habe ich diese Probleme.

#
#                     OG Bad
#
define MAX_0ba182 MAX HeatingThermostat 0ba182
attr MAX_0ba182 IODev cm1
attr MAX_0ba182 alias OG_HT_Bad
attr MAX_0ba182 room OG_Bad
attr MAX_0ba182 scanTemp 1
attr MAX_0ba182 userReadings onlyAutoMode { return "1";;}
attr MAX_0ba182 verbose 2

define FileLog_MAX_0ba182 FileLog ./log/MAX_0ba182-%Y.log MAX_0ba182
attr FileLog_MAX_0ba182 logtype text
attr FileLog_MAX_0ba182 room OG_Bad

# Bad Werte plotten
define MAX_0ba182_weblink SVG FileLog_MAX_0ba182:MB_MAX:CURRENT
attr MAX_0ba182_weblink label "Bad Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_0ba182_weblink room OG_Bad


Ein HT hat noch einen Fensterkontakt. Sonst keine anderen Aktivitäten von FHEM in Richtung HT.

Hier mal ein log mit verbose 5:

2014.09.12 11:22:40 0: Server shutdown
2014.09.12 11:22:43 2: [MaxScan] UtilsMaxScan_Initialize.68 MaxScan is starting
2014.09.12 11:22:43 1: Including /etc/fhem/fhem.cfg
2014.09.12 11:22:43 1: Including /opt/fhem/FHEM/main_1-wire.cfg
2014.09.12 11:22:43 1: OWX: Serial device /dev/ttyUSB0 defined
2014.09.12 11:22:43 1: Including /opt/fhem/FHEM/main_cuno.cfg
2014.09.12 11:22:43 2: Switched cuno_1 rfmode to MAX
2014.09.12 11:22:43 2: Switched cuno_2 rfmode to MAX
2014.09.12 11:22:43 5: cuno_2 sending Za1234
2014.09.12 11:22:43 5: SW: Za1234
2014.09.12 11:22:43 5: cuno_2 sending Zw111111
2014.09.12 11:22:43 5: SW: Zw111111
2014.09.12 11:22:44 1: Including /opt/fhem/FHEM/devices_max.cfg
2014.09.12 11:22:44 1: Including /opt/fhem/FHEM/zeitsteuerung.cfg
2014.09.12 11:22:48 1: Including ./log/fhem.save
2014.09.12 11:22:50 1: OWX: 1-Wire bus OWX_14_EC7B50050000: interface master DS2480 detected for the first time
2014.09.12 11:22:50 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.09.12 11:22:50 0: Server started with 135 defined entities (version $Id: fhem.pl 6498 2014-09-01 19:24:40Z rudolfkoenig $, os linux, user fhem, pid 26793)
2014.09.12 11:23:24 1: OWX: 1-Wire devices found on bus OWX_14_EC7B50050000 (DS18B20_5_28AAEB030000,DS18B20_1_A8C2EB030000,DS18B20_7_2CD0BA030000,DS18B20_6_2CD2BA030000,DS18B20_2_45C2EB030000,DS18B20_3_1DC1EB030000,DS18B20_4_5DA6EB030000,DS18B20_9_FF581B440400,DS18B20_15_FF5420440400,DS18B20_8_FF2F1E440400,OWX_M,OWX_M1,Gaszaehler)
2014.09.12 11:23:28 5: SW: X
2014.09.12 11:23:28 5: CUL/RAW (ReadAnswer): 21  208

2014.09.12 11:23:28 5: cuno_2 sending Zs0a9d00401234066b660028
2014.09.12 11:23:28 5: SW: Zs0a9d00401234066b660028
2014.09.12 11:23:34 5: SW: X
2014.09.12 11:23:34 5: CUL/RAW (ReadAnswer): 21  106

2014.09.12 11:23:34 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 106, but we need 109. Waiting 3 seconds.
2014.09.12 11:23:37 5: SW: X
2014.09.12 11:23:37 5: CUL/RAW (ReadAnswer): 21  109

2014.09.12 11:23:37 5: cuno_2 sending Zs0a9d00401234066b660028
2014.09.12 11:23:37 5: SW: Zs0a9d00401234066b660028
2014.09.12 11:23:44 5: SW: X
2014.09.12 11:23:44 5: CUL/RAW (ReadAnswer): 21    6

2014.09.12 11:23:44 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 109. Waiting 103 seconds.
2014.09.12 11:25:00 5: CUL/RAW: /Z0F0004600760A30000000018242800D413

2014.09.12 11:25:00 4: CUL_Parse: cuno_2 Z0F0004600760A30000000018242800D413 -64.5
2014.09.12 11:25:00 5: cuno_2 dispatch Z0F0004600760A30000000018242800D4


Und hier noch der Fehler mit LENERR:

2014.09.12 11:29:21 5: cuno_2 sending Zs0e97040312340ebd02000e0e0c0b9d55
2014.09.12 11:29:21 5: SW: Zs0e97040312340ebd02000e0e0c0b9d55
2014.09.12 11:29:21 5: CUL/RAW: /LENERR

2014.09.12 11:29:21 4: CUL_Parse: cuno_2 LENERR
2014.09.12 11:29:21 2: cuno_2: unknown message LENERR
2014.09.12 11:29:27 5: SW: X
2014.09.12 11:29:27 5: CUL/RAW (ReadAnswer): 21  131

2014.09.12 11:29:27 5: cuno_2 sending Zs0e97040312340ebd02000e0e0c0b9d5b
2014.09.12 11:29:27 5: SW: Zs0e97040312340ebd02000e0e0c0b9d5b
2014.09.12 11:29:27 5: CUL/RAW: /LENERR

John

Hi cfi
Zitat
2014.09.12 11:29:21 5: CUL/RAW: /LENERR
ich meine der Eintrag kommt von Zeile 762 des Moduls 00_CUL.pm

Log3 $name, 5, "CUL/RAW: $culdata/$buf";

"LENERR"  wäre dann der Inhalt von "$buf".
In $buf stehen die Rohdaten vom CUL/CUNO.

Somit wäre das ein Thema für die CUL-Entwickler.


John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cfi

#6
Hi John,

danke für die Hilfe und Info.

Bei den HT mit Missing ack habe ich einen Reset gemacht und nun kann ich diese nicht mehr pairen. Kann das auch am Credit liegen?

Kann man das statefile auch einsehen bzw. löschen?

Und wie kann ich elegant die HT's erst mal rausnehmen und dann wenn alles gut ist wieder anlernen?
Geht das auch über ignore 1?

Gruß cfi

John

#7
ZitatBei den HT mit Missing ack habe ich einen Reset gemacht und nun kann ich diese nicht mehr pairen. Kann das auch am Credit liegen?
Du siehst die Reaktion sofort in der Log-Datei.

ZitatBei den HT mit Missing ack habe ich einen Reset gemacht und nun kann ich diese nicht mehr pairen. Kann das auch am Credit liegen?
Wenn Credits fehlen landen die Kommandos in einer Queue und werden solange vorgehalten, bis wieder ausreichend Credits vorhanden sind.
D.h. die können stark verzögert kommen (viele Minuten).
Es macht dann auch keine Sinn weitere Kommandos abzusetzen, da der unmittelbare zeitliche Bezug fehlt.

ZitatKann man das statefile auch einsehen bzw. löschen?
In  fhem/log/fhem.save werden die Werte der Readings vorgehalten.
Du kannst diese ja sichern und die Werte ändern/manipulieren die nicht passen, nachdem FHEM runtergefahren ist.

ZitatUnd wie kann ich elegant die HT's erst mal rausnehmen und dann wenn alles gut ist wieder anlernen?
ich kommentiere die Devices und deren Attribute in fhem.cfg aus (fhem muss down sein).
Wenn man den Kommentar wieder entfernt ist ein erneutes Anlernen nicht nötig,
da die Verbindung in den Devices selbst hinterlegt ist.

Was du noch tun könntest:
Du legst den Fall den CUL-Entwicklern vor und downgradest deinen CUL auf die Version, die funktionierte.
Damit hast du zumindest ein lauffähiges System.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cfi

Hallo John,

nun habe ich die CUNO's auf die Version 1.54 zurück gesetzt und bis auf 2 HT alle anderen auskommentiert.

Die CUNO's habe ich nun so konfiguriert. Ich habe versucht, dass mit "sendpool" die CUNO's sich nicht in die Quere kommen:

define cuno_1 CUL 172.25.50.89:2323 1034
attr cuno_1 icon cul_868
attr cuno_1 rfmode MAX
attr cuno_1 sendpool cuno_1, cuno_2

define cuno_2 CUL 172.25.50.86:2323 1134
attr cuno_2 icon cul_868
attr cuno_2 rfmode MAX
attr cuno_2 sendpool cuno_1, cuno_2

define cm1 CUL_MAX 1234
attr cm1 IODev cuno_2
attr cm1 icon cul_usb


Leider bekomme ich es immer noch nicht in den Griff. Das ist das Logfile von der Konsole. Hier gibt es nun "Use of uninitialized value" Fehler:
2014.09.14 10:59:28 0: Server started with 116 defined entities (version $Id: fhem.pl 6498 2014-09-01 19:24:40Z rudolfkoenig $, os linux, user fhem, pid 10769)
2014.09.14 11:00:04 1: OWX: 1-Wire devices found on bus OWX_14_EC7B50050000 (DS18B20_5_28AAEB030000,DS18B20_1_A8C2EB030000,DS18B20_7_2CD0BA030000,DS18B20_6_2CD2BA030000,DS18B20_2_45C2EB030000,DS18B20_3_1DC1EB030000,DS18B20_4_5DA6EB030000,DS18B20_9_FF581B440400,DS18B20_15_FF5420440400,DS18B20_8_FF2F1E440400,OWX_M,OWX_M1,Gaszaehler)
2014.09.14 11:02:07 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 102, but we need 109. Waiting 7 seconds.
2014.09.14 11:02:20 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 109. Waiting 102 seconds.
2014.09.14 11:04:09 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 109. Waiting 103 seconds.
2014.09.14 11:05:55 2: CUL_MAX_SendQueueHandler: Missing ack from 066b75 for 0a4600401234066b750067
Use of uninitialized value $f1 in addition (+) at ./FHEM/14_CUL_MAX.pm line 300.
Use of uninitialized value $f3 in bitwise and (&) at ./FHEM/14_CUL_MAX.pm line 302.
Use of uninitialized value $f4 in bitwise and (&) at ./FHEM/14_CUL_MAX.pm line 303.
Use of uninitialized value $f5 in bitwise and (&) at ./FHEM/14_CUL_MAX.pm line 304.
Use of uninitialized value $f4 in right bitshift (>>) at ./FHEM/14_CUL_MAX.pm line 305.
Use of uninitialized value $f5 in right bitshift (>>) at ./FHEM/14_CUL_MAX.pm line 305.
Use of uninitialized value $f3 in right bitshift (>>) at ./FHEM/14_CUL_MAX.pm line 306.
Use of uninitialized value $f4 in right bitshift (>>) at ./FHEM/14_CUL_MAX.pm line 307.
Use of uninitialized value $f5 in right bitshift (>>) at ./FHEM/14_CUL_MAX.pm line 308.
Use of uninitialized value $day in concatenation (.) or string at ./FHEM/14_CUL_MAX.pm line 310.
2014.09.14 11:11:52 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 33, but we need 109. Waiting 76 seconds.


John

#9
Hi cfi

du verwendest also 2 Cuno's. Vermutlich um die Reichweite zu erhöhen.
Über dieses Szenario habe ich bisher noch nichts gelesen.

Das Device cml ist jedoch nur mit cuno_2 verknüpft.

Mir ist nicht klar, wie das Device cuno_1 die empfangenen Pakete weiterreichen soll.

Ich meine du brauchst für jeden cuno jeweils ein CUL_MAX Device.
Über das IODev Attribut kannst du exakt festlegen, wie die Informationen weitergereicht werden.
Das Attribut gibt es eben auch für die Max-Thermostate.


Vorschlag:
A. Du baust ein Minimal-System auf:
* 1x CUNO (cuno_2, da dieser mit CUL_MAX verbunden ist)
* 1x Max HT
* Max-Scanner rausnehmen

* Testen durch Ändern des Sollwerts am HT
* Log-file Check


B. System erweiteren
* weitere Max-HTs hinzufügen, die im Empfangsbereich des CUNOs liegen

* Testen durch Ändern des Sollwerts am HT
* Log-file Check


C. Cuno hinzufügen
* cuno_1 hinzufügen mit eigenem CUL_MAX
* Check wie B.

Sukzessive den Aufbau erweitern, bis die Probleme beginnen
-----------------------------------------
Bitte noch folgendes erledigen:
(verborgene Readings werden angezeigt)

attr global showInternalValues 1

danach ein
list cuno_1
list cuno_2
list cml


Ergebnisse ins Forum stellen.


John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cfi

Hallo John,

nun habe ich mal alle MAX HT herausgenommen und nur einen CUNO aktiv.

Dann ist das Log ruhig.

Nun habe ich einen MAX HT wieder aktiviert und nun hagelt es im Log Fehler:

2014.09.20 15:33:01 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:07 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:12 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:18 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:23 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:28 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:33 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:38 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:43 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:48 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:53 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:33:57 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 5, but we need 120. Waiting 115 seconds.
2014.09.20 15:33:58 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:34:03 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!
2014.09.20 15:34:08 1: [MAX_066b66] MaxScanRun.423 !! READING:temperature is not defined !!


Ich habe versucht auch das weekProfile zu setzen. Leider ohne Erfolg:

set MAX_066b66 weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17

Was kann das sein?

Danke und Gruß cfi



John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cfi

Hallo John,

hier nun meine Antwort:

1. Ohne Scanner:


Definition:
define MAX_066b66 MAX HeatingThermostat 066b66
attr MAX_066b66 IODev cm1
attr MAX_066b66 alias OG_HT_Test
attr MAX_066b66 room OG_Test
#attr MAX_066b66 scanTemp 1
#attr MAX_066b66 userReadings onlyAutoMode { return "1";;}
attr MAX_066b66 verbose 2


Log:
2014.09.24 14:55:14 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1604031034066b66000e0e180eb74a
2014.09.24 20:54:49 2: cuno_1: unknown message LENERR
2014.09.24 20:54:56 2: cuno_1: unknown message LENERR
2014.09.24 20:55:03 2: cuno_1: unknown message LENERR
2014.09.24 20:55:09 2: cuno_1: unknown message LENERR
2014.09.24 20:55:13 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1704031034066b66000e0e1814b749
2014.09.25 02:54:50 2: cuno_1: unknown message LENERR
2014.09.25 02:54:56 2: cuno_1: unknown message LENERR
2014.09.25 02:55:03 2: cuno_1: unknown message LENERR
2014.09.25 02:55:09 2: cuno_1: unknown message LENERR
2014.09.25 02:55:13 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1804031034066b66000e0e1902b749
2014.09.25 08:54:51 2: cuno_1: unknown message LENERR
2014.09.25 08:54:57 2: cuno_1: unknown message LENERR
2014.09.25 08:55:04 2: cuno_1: unknown message LENERR
2014.09.25 08:55:11 2: cuno_1: unknown message LENERR
2014.09.25 08:55:14 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1904031034066b66000e0e1908b74a
2014.09.25 14:54:51 2: cuno_1: unknown message LENERR
2014.09.25 14:54:58 2: cuno_1: unknown message LENERR
2014.09.25 14:55:04 2: cuno_1: unknown message LENERR
2014.09.25 14:55:13 2: cuno_1: unknown message LENERR
2014.09.25 14:55:17 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1a04031034066b66000e0e190eb74d
2014.09.25 20:54:53 2: cuno_1: unknown message LENERR
2014.09.25 20:55:00 2: cuno_1: unknown message LENERR
2014.09.25 20:55:06 2: cuno_1: unknown message LENERR
2014.09.25 20:55:13 2: cuno_1: unknown message LENERR
2014.09.25 20:55:16 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1b04031034066b66000e0e1914b74d
2014.09.26 02:54:53 2: cuno_1: unknown message LENERR
2014.09.26 02:55:00 2: cuno_1: unknown message LENERR
2014.09.26 02:55:06 2: cuno_1: unknown message LENERR
2014.09.26 02:55:13 2: cuno_1: unknown message LENERR
2014.09.26 02:55:16 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1c04031034066b66000e0e1a02b74d
2014.09.26 08:54:53 2: cuno_1: unknown message LENERR


2. Mit Scanner und verbose=5

Definition:

define MAX_066b66 MAX HeatingThermostat 066b66
attr MAX_066b66 IODev cm1
attr MAX_066b66 alias OG_HT_Test
attr MAX_066b66 room OG_Test
attr MAX_066b66 scanTemp 1
attr MAX_066b66 userReadings onlyAutoMode { return "1";;}
attr MAX_066b66 verbose 5


Log:
2014.09.27 12:14:14 5: [MAX_066b66] MaxScanRun.367 is HeatingThermostat
2014.09.27 12:14:14 4: [MAX_066b66] MaxScanRun.371 attribute scanTemp found
2014.09.27 12:14:14 3: [MAX_066b66] MaxScanRun.430 sdNextScan:2014-09-27 12:04:49 strDesiTime:2014-09-27 11:04:10
2014.09.27 12:14:14 3: [MAX_066b66] MaxScanRun.444 TYPE:CUL_MAX IOName:cm1
2014.09.27 12:14:14 4: [MAX_066b66] MaxScanRun.485 CulName:cuno_1 CulCredits:6 CreditTime:2014-09-27 12:12:28 dutyCycle:?
2014.09.27 12:14:14 5: [MAX_066b66] MaxWeekProfileInfo.104 ----- Start ---------
2014.09.27 12:14:14 5: [MAX_066b66] MaxWeekProfileInfo.121 weekprofile-0-Sat-temp: weekprofile-1-Sun-temp:
2014.09.27 12:14:14 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.27 12:14:19 5: [MAX_066b66] MaxScanRun.367 is HeatingThermostat
2014.09.27 12:14:19 4: [MAX_066b66] MaxScanRun.371 attribute scanTemp found
2014.09.27 12:14:19 3: [MAX_066b66] MaxScanRun.430 sdNextScan:2014-09-27 12:04:49 strDesiTime:2014-09-27 11:04:10
2014.09.27 12:14:19 3: [MAX_066b66] MaxScanRun.444 TYPE:CUL_MAX IOName:cm1
2014.09.27 12:14:19 4: [MAX_066b66] MaxScanRun.485 CulName:cuno_1 CulCredits:6 CreditTime:2014-09-27 12:12:28 dutyCycle:?
2014.09.27 12:14:19 5: [MAX_066b66] MaxWeekProfileInfo.104 ----- Start ---------
2014.09.27 12:14:19 5: [MAX_066b66] MaxWeekProfileInfo.121 weekprofile-0-Sat-temp: weekprofile-1-Sun-temp:
2014.09.27 12:14:19 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.27 12:14:24 5: [MAX_066b66] MaxScanRun.367 is HeatingThermostat
2014.09.27 12:14:24 4: [MAX_066b66] MaxScanRun.371 attribute scanTemp found
2014.09.27 12:14:24 3: [MAX_066b66] MaxScanRun.430 sdNextScan:2014-09-27 12:04:49 strDesiTime:2014-09-27 11:04:10
2014.09.27 12:14:24 3: [MAX_066b66] MaxScanRun.444 TYPE:CUL_MAX IOName:cm1
2014.09.27 12:14:24 4: [MAX_066b66] MaxScanRun.485 CulName:cuno_1 CulCredits:121 CreditTime:2014-09-27 12:14:23 dutyCycle:?
2014.09.27 12:14:24 5: [MAX_066b66] MaxWeekProfileInfo.104 ----- Start ---------
2014.09.27 12:14:24 5: [MAX_066b66] MaxWeekProfileInfo.121 weekprofile-0-Sat-temp: weekprofile-1-Sun-temp:
2014.09.27 12:14:24 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.27 12:14:29 5: [MAX_066b66] MaxScanRun.367 is HeatingThermostat
2014.09.27 12:14:29 4: [MAX_066b66] MaxScanRun.371 attribute scanTemp found
2014.09.27 12:14:29 3: [MAX_066b66] MaxScanRun.430 sdNextScan:2014-09-27 12:04:49 strDesiTime:2014-09-27 11:04:10
2014.09.27 12:14:29 3: [MAX_066b66] MaxScanRun.444 TYPE:CUL_MAX IOName:cm1
2014.09.27 12:14:29 4: [MAX_066b66] MaxScanRun.485 CulName:cuno_1 CulCredits:121 CreditTime:2014-09-27 12:14:23 dutyCycle:?
2014.09.27 12:14:29 5: [MAX_066b66] MaxWeekProfileInfo.104 ----- Start ---------
2014.09.27 12:14:29 5: [MAX_066b66] MaxWeekProfileInfo.121 weekprofile-0-Sat-temp: weekprofile-1-Sun-temp:
2014.09.27 12:14:29 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.27 12:14:30 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 120. Waiting 114 seconds.
2014.09.27 12:14:34 5: [MAX_066b66] MaxScanRun.367 is HeatingThermostat
2014.09.27 12:14:34 4: [MAX_066b66] MaxScanRun.371 attribute scanTemp found
2014.09.27 12:14:34 3: [MAX_066b66] MaxScanRun.430 sdNextScan:2014-09-27 12:04:49 strDesiTime:2014-09-27 11:04:10
2014.09.27 12:14:34 3: [MAX_066b66] MaxScanRun.444 TYPE:CUL_MAX IOName:cm1
2014.09.27 12:14:34 4: [MAX_066b66] MaxScanRun.485 CulName:cuno_1 CulCredits:6 CreditTime:2014-09-27 12:14:30 dutyCycle:?
2014.09.27 12:14:34 5: [MAX_066b66] MaxWeekProfileInfo.104 ----- Start ---------
2014.09.27 12:14:34 5: [MAX_066b66] MaxWeekProfileInfo.121 weekprofile-0-Sat-temp: weekprofile-1-Sun-temp:
2014.09.27 12:14:34 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.27 12:14:39 5: [MAX_066b66] MaxScanRun.367 is HeatingThermostat
2014.09.27 12:14:39 4: [MAX_066b66] MaxScanRun.371 attribute scanTemp found
2014.09.27 12:14:39 3: [MAX_066b66] MaxScanRun.430 sdNextScan:2014-09-27 12:04:49 strDesiTime:2014-09-27 11:04:10



list MAX_066b66

Save config
Heizung
LaCrosse
OG_Test
Plot
SHCdev
Server-Raum
Unsorted
Wetter
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Internals:
   CFGFN      /opt/fhem/FHEM/devices_max.cfg
   DEF        HeatingThermostat 066b66
   IODev      cm1
   NAME       MAX_066b66
   NR         189
   RSSI       -61
   STATE      21.0 °C
   TYPE       MAX
   addr       066b66
   type       HeatingThermostat
   Readings:
     2014-09-20 15:54:32   TimeInformationHour 0
     2014-09-27 11:04:10   battery         ok
     2014-09-27 11:04:10   desiredTemperature 21.0
     2014-09-20 15:54:58   groupid         0
     2014-09-20 16:28:23   measurementOffset 0
     2014-09-27 11:04:10   mode            manual
     2014-09-27 12:12:45   msgcnt          48
     2014-09-27 12:03:08   onlyAutoMode    1
     2014-09-27 11:04:10   state           21.0 °C
     2014-09-27 11:04:10   temperature     22.2
     2014-09-27 11:04:10   valveposition   27
   Helper:
     NextScan   1411812289
   Internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      cm1
   alias      OG_HT_Test
   room       OG_Test
   scanTemp   1
   userReadings onlyAutoMode { return "1";}
   verbose    5

John

#13
Hallo cfi,

ich sehe da mehrere Themen, die es zu klären gilt:

Thema 1: CUNO_1

Mit
attr cuno_1 rfmode MAX
ist er eindeutig den MAX-devices zugeordnet.

Aber du gibst ihm kein CULMAX Device.
Das gibt es nur für den cuno_2.
define cm1 CUL_MAX 1234
attr cm1 IODev cuno_2


Warum benötigst du cuno_1 überhaupt ?
Möglicherweise ist die fehlende Zuordnung zu einem eigenständigen CULMAX der Grund für diesen Fehler.
Zitat2014.09.25 02:54:50 2: cuno_1: unknown message LENERR

2. Thema: MAX-Device

Der Scanner beschwert sich:
Zitat2014.09.27 12:14:14 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
Dein Thermostat hat kein weekprofile und er hat recht wie wir sehen.

Überhaupt fehlt da eine Menge an Internals und Readings bei deinem MAX_066b66

Zum Vergleich eines meiner Thermostate

Internals:
   CULMAX0_MSGCNT 323
   CULMAX0_TIME 2014-09-27 17:38:27
   DEF        HeatingThermostat 063cce
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     323
   NAME       HT.JOHN
   NR         198
   RSSI       -53
   STATE      T:on [C] V:0 [%]
   TYPE       MAX
   addr       063cce
   backend    CULMAX0
   dstsetting 1
   mode       1
   rferror    0
   type       HeatingThermostat
   Readings:
     2013-11-15 21:22:18   TimeInformationHour 1
     2014-09-27 17:38:27   battery         ok
     2013-11-22 21:48:35   boostDuration   15
     2013-11-28 10:21:26   boostValveposition 100
     2013-11-15 21:45:27   comfortTemperature 19.0
     2013-11-15 21:24:27   decalcification Sat 12:00
     2014-09-27 17:38:27   desiredTemperature 16.0
     2013-11-15 21:25:22   ecoTemperature  17
     2014-09-10 23:22:53   firmware        1.6
     2014-09-10 23:22:53   groupid         0
     2014-01-30 15:15:05   maxValveSetting 100
     2014-06-22 14:05:36   maximumTemperature on
     2013-11-15 21:25:22   measurementOffset 0
     2013-11-15 21:25:22   minimumTemperature off
     2014-09-27 17:38:27   mode            manual
     2014-09-27 17:37:10   msgcnt          129
     2014-09-27 17:38:27   state           16.0 °C
     2014-09-27 17:38:27   temperature     19.1
     2014-09-10 23:22:53   testresult      255
     2013-11-15 21:24:27   valveOffset     0
     2014-09-27 17:38:27   valveposition   0
     2014-06-09 12:27:14   weekprofile-0-Sat-temp 16.0 °C  /  16.0 °C
     2014-06-09 12:27:14   weekprofile-0-Sat-time 00:00-23:55  /  23:55-00:00
     2014-06-09 12:27:14   weekprofile-1-Sun-temp 16.0 °C  /  16.0 °C
     2014-06-09 12:27:14   weekprofile-1-Sun-time 00:00-23:55  /  23:55-00:00
     2014-06-09 12:27:14   weekprofile-2-Mon-temp 16.0 °C  /  16.0 °C
     2014-06-09 12:27:14   weekprofile-2-Mon-time 00:00-23:55  /  23:55-00:00
     2014-06-09 12:27:14   weekprofile-3-Tue-temp 16.0 °C  /  16.0 °C
     2014-06-09 12:27:14   weekprofile-3-Tue-time 00:00-23:55  /  23:55-00:00
     2014-06-09 12:27:14   weekprofile-4-Wed-temp 16.0 °C  /  16.0 °C
     2014-06-09 12:27:14   weekprofile-4-Wed-time 00:00-23:55  /  23:55-00:00
     2014-06-09 12:27:14   weekprofile-5-Thu-temp 16.0 °C  /  16.0 °C
     2014-06-09 12:27:14   weekprofile-5-Thu-time 00:00-23:55  /  23:55-00:00
     2014-06-09 12:27:14   weekprofile-6-Fri-temp 16.0 °C  /  16.0 °C
     2014-06-09 12:27:14   weekprofile-6-Fri-time 00:00-23:55  /  23:55-00:00
     2013-11-15 21:25:22   windowOpenDuration 15
     2013-11-15 21:25:22   windowOpenTemperature 12
   Helper:
     DesiTime   1411627631
     LastWasAutoReset
     NextScan   1411833550
     NextScanTimestamp 2014-09-27 17:59:10
     TempBeforeWindOpen 16.0
     TemperatureTime 1411832307
     WinWasOpen 0
     desiredOffset 0
     leadDesiTemp 16.0
     switchDate 1411854900
   Internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      CULMAX0
   group      10_Thermostat
   room       DG.JOHN,HT.ALL
   scanTemp   1
   stateFormat T:maximumTemperature [C] V:valveposition [%]
   verbose    2


Bei dir fehlen eine Menge von Readings.

Ich rate dir das Max-Device
* abzulernen
* aus FHEM zu löschen
* neu anzulernen

Thema 3: Zuordnung Max-Devices zu CUNO
Kannst du beschreiben, welche MAX-Devices welchem CUNO zugeordnet werden sollen.

Diese Meldung
Zitat2014.09.25 14:55:17 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 0e1a04031034066b66000e0e190eb74d
ist ein Hinweis auf ein unzureichende Sende/Empfangsqualität.

Nach meinem bisherigem Stand sind alle MAX-Devices ausnahmslos cuno_2 zugeordnet.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cfi

#14
Hallo John,

Thema 1: CUNO_1

Momentan habe ich nur einen CUNO und er hat eine Zuordnung:

define cuno_1 CUL 172.25.50.89:2323 1034
attr cuno_1 icon cul_868
attr cuno_1 rfmode MAX
#attr cuno_1 sendpool cuno_1, cuno_2
#attr cuno_1 verbose 5


#define cuno_2 CUL 172.25.50.86:2323 1134
#attr cuno_2 icon cul_868
#attr cuno_2 rfmode MAX
#attr cuno_2 sendpool cuno_1, cuno_2
##attr cuno_2 verbose 5

define cm1 CUL_MAX 1034
attr cm1 IODev cuno_1
attr cm1 icon cul_usb
#attr cm1 IODev cuno_1


Die Idee war, dass ich mit CUNO_1 und CUNO2 eine bessere Abdeckung erreichen kann, damit die "Missing ack" Fehler aufhören.

2. Thema: MAX-Device

Das habe ich versucht mit:

set MAX_066b66 weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17

Hierbei bekomme ich keine Meldung und im Log bekomme ich folgende Meldungen:

2014.09.28 21:02:53 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:02:58 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:03 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:09 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:14 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:14 2: CUL_MAX_SendQueueHandler: Missing ack from 066b66 for 183900101034066b66000244d2511444004520452045204520
2014.09.28 21:03:19 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:24 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:29 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:34 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available
2014.09.28 21:03:34 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 95, but we need 120. Waiting 25 seconds.
2014.09.28 21:03:39 1: [MAX_066b66] MaxScanRun.513 !! weekprofile is not available


Wie kann ich das Max-Device ab lernen? Meinst du den HT Reset?

Thema 3: Zuordnung Max-Devices zu CUNO

Wie bei Thema 1 schon beschrieben habe ich momentan nur einen CUNO (cuno_1) im Einsatz. Der Sendeabstand ist ca. 3-4 Meter durch eine Wand.
Das hat auch schon durch 2 Beton_Decken funktioniert.

Was mich eben wundert, das die Fehler im letzten Winter nicht vorhanden waren und ich plötzlich diese Probleme habe.

Gruß cfi