MAX - fehlende ACK?

[scs90]

Hallo zusammen,

ich bin ganz neu hier im Forum und auch bei FHEM. Ich habe schon seit einiger Zeit mehrere MAX-Raumlösungen und konnte jetzt mit einem RasPi 3 mit Selbstbau-CUL, Jeelink und Pilight (zukunftssicher ) in FHEM starten. Um die ersten Schritte zu schaffen, habe ich mich erstmal nur auf das Büro beschränkt. Hier gibts einen HT+ und einen FK.

Status zu Anfang: FHEM hört fleißig den Funkverkehr in der Wohnung mit.

Nach dem einfachen Anlernen von FK, HT+ sah erstmal alles gut aus, der HT+ hat natürlich noch nicht auf den FK reagiert. Associate wurde dann in beide Richtungen durchgeführt, seitdem funktioniert alles wie gewohnt - EIGENTLICH. Blöderweise setzt der FK seinen Status immer mit "rferror" ab. Dazu passend blinkt die LED 3mal. Der HT+ allerdings zeigt dieses Problem nicht.

Klar könnte ich das einfach so lassen, aber das erzeugt ja auch nur unnötigen Funkverkehr, sorgt für einen höheren Akkuverbrauch und außerdem nervt mich die ständige Fehlermeldung.

Ich habe mich hierzu schon durch das Forum gelesen, derselbe Fall wurde ja schon mehrmals beschrieben. Meist - und das vermute ich hier auch - ist eine verspätete oder fehlende ACK von fhem schuld. Allerdings sind die Threads meist schon etwas älter und werden mit entsprechenden Updates für den CUL behoben. Ich bin aber der Meinung, für alles die neuesten Versionen zu haben - habe das Problem aber trotzdem. Zur Sicherheit hier einmal die Ausgabe der Versionen:

Code Auswählen Erweitern

Latest Revision: 15292

File               Rev   Last Change

fhem.pl            15289 2017-10-19 14:34:34Z rudolfkoenig
98_autocreate.pm   15038 2017-09-10 10:00:18Z rudolfkoenig
00_CUL.pm          15027 2017-09-08 09:11:43Z rudolfkoenig
14_CUL_MAX.pm      12440 2016-10-26 20:24:45Z mgehre
91_eventTypes.pm   14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm      15280 2017-10-18 11:07:18Z rudolfkoenig
92_FileLog.pm      14888 2017-08-13 12:07:12Z rudolfkoenig
36_JeeLink.pm      14707 2017-07-13 18:08:33Z justme1968
36_LaCrosse.pm     15263 2017-10-15 09:32:18Z HCS
10_MAX.pm          12107 2016-09-01 18:25:08Z mgehre
91_notify.pm       14888 2017-08-13 12:07:12Z rudolfkoenig
10_pilight_ctrl.pm 14997 2017-09-03 17:27:39Z Risiko
99_SUNRISE_EL.pm   14888 2017-08-13 12:07:12Z rudolfkoenig
98_telnet.pm       15006 2017-09-05 09:37:33Z rudolfkoenig
99_Utils.pm        13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm      15140 2017-09-26 09:20:09Z markusbloch

Blocking.pm        15200 2017-10-05 08:27:30Z rudolfkoenig
DevIo.pm           14933 2017-08-20 14:21:58Z rudolfkoenig
HttpUtils.pm       15284 2017-10-18 19:46:13Z rudolfkoenig
No Id found for MaxCommon.pm
RTypes.pm          10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm   12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm  14862 2017-08-07 15:16:03Z rudolfkoenig

fhemweb.js                 15228 2017-10-10 17:34:56Z rudolfkoenig

Was ich schon probiert habe, ist ein disassociate sowie Werksreset des FK, um zu testen, ob der Fehler auch ohne associate auftritt. Leider war nach dem neuen Anlernen das associate noch aktiv, was ich nicht ganz verstehe. Der Fehler war aber sofort nach dem Anlernen wieder vorhanden.

Auf eine Logfile verzichte ich erstmal, da ich nciht weiß, was davon hier benötigt wird. Aktuell ist die auch ziemlich voll von Meldungen über Nachrichten unbekannter Geräte (Heizungssteuerungen der anderen Räume). Ich reiche das log aber gerne nach

Bitte verzeiht mir, falls hier noch megawichtige Informationen fehlen - ich bin gerade mal seit 5 Tagen dabei.

Vielen Dank schonmal und viele Grüße
scs90

[scs90]

Hallo nochmal,

also ich habe den gesamten Tag alles hin- und herprobiert, letztendlich war es aber einfach. Nach einem Neustart von fhem bin ich über diese Zeile im log gestolpert:

Code Auswählen Erweitern

2017.11.05 17:09:19 1: CULMAX: did not find suitable IODev (CUL etc. in rfmode MAX)! You may want to execute 'attr CULMAX IODev SomeCUL'

Allerdings war das entsprechende IODev im Device overview gesetzt:

Code Auswählen Erweitern

CULMAX_MSGCNT 8
CULMAX_TIME 2017-11-05 17:55:03
CUL_USB_MSGCNT 16
CUL_USB_RAWMSG Z0EB002020C7FE00CCA7E000108642C
CUL_USB_RSSI -72
CUL_USB_TIME 2017-11-05 17:55:03
DEF123456
IODev CUL_USB
LASTInputDev CUL_USB
MSGCNT 24
NAME CULMAX
NR 21
STATE Defined
TYPE CUL_MAX
addr 123456
cnt 0
pairmode 0
retryCount 0

In einem alten Thread habe ich allerdings die Lösung gefunden. In der fhem.cfg ist die Reiehnfolge bei der Initialisierung der Komponenten (sorry für falsche Ausdrücke, ich bin kein Informatiker) vertauscht. Sprich erst wird CUL_MAX, und anschließend das dazugehörige CUL_USB als IODev geladen.

Code Auswählen Erweitern

define CULMAX CUL_MAX 123456
attr CULMAX IODev CUL_USB
attr CULMAX room MAX
define CUL_USB CUL /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
attr CUL_USB model nanoCUL
attr CUL_USB rfmode MAX

Daher findet CUL_MAX kein IODev, kann also auch nicht "antworten" (was zum rferror führt).  Einfache Lösung: Über Edit files die beiden Teile "richtigstellen" (vorher editConfig in WEB aktivieren).

Code Auswählen Erweitern

define CUL_USB CUL /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
attr CUL_USB model nanoCUL
attr CUL_USB rfmode MAX
define CULMAX CUL_MAX 123456
attr CULMAX IODev CUL_USB
attr CULMAX room MAX

Jetzt läufts.

Viele Grüße
scs90