[gelöst]: Verstehe diese Fehlermeldung nicht: cm, did not find suitable IODev

Begonnen von Dynalon, 18 Februar 2021, 12:42:09

Vorheriges Thema - Nächstes Thema

Dynalon

***Wer keine Lust auf die Details hat, kann für eine schnelle Übersicht auch nur das fett gedruckte lesen ***



Hallo zusammen,

habe mich entschieden wegen vieler kleiner Bugs die sich (teilweise durch Unwissenheit meinerseits) eingeschlichen haben mein FHEM komplett neu aufzusetzen und diesmal strikt ausschließlich nach FHEM Wiki vorzugehen. Bin leider auch nicht wirklich erfahren in der Materie (bitte berücksichtigt das auch bei Euren Antworten).

Es hat bisher alles super geklappt, doch mein Logfile zeigt eine Fehlermeldung zum meinem Max!:

2021.02.18 11:19:01 1: cm, did not find suitable IODev (CUL etc. in rfmode MAX)! You may want to execute 'attr cm IODev SomeCUL'

und einige Zeilen darunter:

2021.02.18 11:45:16 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/14_CUL_MAX.pm line 536.


Das Verwirrende: Alles funktioniert (habe bisher 4 Fenster-/Türsensoren darüber in Betrieb und bekomme deren Zustand wie gewünscht in Echtzeit. Ich habe schon nach einer Erklärung dieses Problems gesucht. Mein Bestes Google Ergebnis zu diesem Thema war hier im Forum: https://forum.fhem.de/index.php?topic=13099.0
Allerdings scheint dort zur Fehlermeldung auch der komplette CUL ausgefallen zu sein. Ähnliches in diesem Thread: https://forum.fhem.de/index.php?topic=13520.0

[Bei mir stimmt hingegen der rfmode MAX und der CUL arbeitet auch soweit ich sehen kann korrekt (sonst käme ja nichts an). Nur wäre es schön, zu wissen, was dieser Fehler bedeutet (können in Zukunft Probleme entstehen, zum Beispiel wenn ich Max!-Thermostate kaufe und anlernen will?) und wie man ihn weg bekommt (und nicht nur aus dem Logfile ausblendet).

hier sind die Readings meines cm:
Internals:
   DEF        123456
   FUUID      602aa7ab-f33f-dc36-9497-e451d3fd831f5b1a
   IODev     
   LASTInputDev SMH_2_868
   MSGCNT     4
   NAME       cm
   NR         55
   SMH_2_868_MSGCNT 3
   SMH_2_868_RAWMSG Z0B0700300456580000000000
   SMH_2_868_RSSI -40
   SMH_2_868_TIME 2021-02-18 11:45:25
   SMH_3_868_MSGCNT 4
   SMH_3_868_RAWMSG Z0B0700300456580000000000
   SMH_3_868_RSSI -49.5
   SMH_3_868_TIME 2021-02-18 11:45:25
   STATE      ???
   SVN        22175
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2021-02-18 11:45:25   state           ???
   sendQueue:
Attributes:
   IODev      SomeCUL
   fakeSCaddr 222222
   fakeWTaddr 111111


Und die Readings des CUL selbst:
Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfxz*
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        SMH_1_433
   FUUID      602a995d-f33f-dc36-53c5-ff4d958019c4da38
   IODev      SMH_1_433
   NAME       SMH_2_868
   NOTIFYDEV  SMH_1_433
   NR         42
   NTFY_ORDER 50-SMH_2_868
   PARTIAL   
   RAWMSG     *Z0B070030045658000000000031
   RSSI       -40
   SMH_2_868_MSGCNT 7
   SMH_2_868_TIME 2021-02-18 11:45:25
   STACKED    SMH_3_868
   STATE      Initialized
   StackLevel 2
   TYPE       STACKABLE_CC
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) MapleCUNx4_0F (F-Band: 868MHz)
   initString X21
Zr
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2021-02-18 11:18:30   cmds             b C F i A Z N E G M K L U Y R T V W X f x z *
     2021-02-18 11:45:25   state           Initialized
Attributes:
   alias      MaxBridge
   rfmode     MAX


Ich bin daraufhin auch im Logfile die letzten Tage durchgegangen, bis vorgestern kam noch folgende Fehlermeldung dutzende Male. Allerdings seit einem Neustart meines Raspis danach nicht ein einziges Mal mehr (daher weiß ich nicht, ob sie zur aktuellen Geschichte überhaupt noch relevant ist):


2021.02.16 11:00:07 1: cm, Send Queue error CUL  did not answer request for current credits. Waiting 5 seconds
2021.02.16 11:00:12 1: cm, Send Queue error CUL  did not answer request for current credits. Waiting 5 seconds
2021.02.16 11:00:17 1: cm, Send Queue error CUL  did not answer request for current credits. Waiting 5 seconds


Da mein Alter Raspi mit insgesamt 7 CULs, ConBees, ZWave Sticks, USB Hub usw. total überladen war, habe ich mich entschieden beim Neuaufsetzen nicht für jedes Protokoll einen eigenen CUL zu verwenden, sondern einen dieser Maple CULs, der gleich 4 Der bisherigen CULs ersetzt. (Bisher 3 eingerichtet: Homematic, Intertechno und Max! - Homematic Geräte wurden noch nicht angelernt, Intertechno funktioniert einwandfrei, Max! wie gesagt bis auf obige Fehlermeldung auch).

Hier ein Link zum Produkt:
https://www.ebay.de/itm/4-fach-CUL-868-433-USB-Stick-f%C3%BCr-FHEM-3x-868Mhz-CC1101-1x-433Mhz-cc1101-Maple/372740731131?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

FHEM als auch Raspi OS wurden erst vor ner Woche von neuen Quellen aufgesetzt und werden derzeit täglich upgedated. Hier aber sicherheitshalber noch meine FHEM Version, falls hilfreich:
Latest Revision: 23738

File                 Rev   Last Change

fhem.pl              23613 2021-01-25 09:34:42Z rudolfkoenig
96_allowed.pm        23727 2021-02-12 20:31:37Z rudolfkoenig
98_autocreate.pm     23727 2021-02-12 20:31:37Z rudolfkoenig
00_CUL.pm            23727 2021-02-12 20:31:37Z rudolfkoenig
14_CUL_MAX.pm        22175 2020-06-13 17:32:49Z Wzut
34_ESPEasy.pm        18608 2019-02-16 09:03:52Z dev0
91_eventTypes.pm     23471 2021-01-04 19:24:21Z rudolfkoenig
01_FHEMWEB.pm        23727 2021-02-12 20:31:37Z rudolfkoenig
92_FileLog.pm        23727 2021-02-12 20:31:37Z rudolfkoenig
30_HUEBridge.pm      23363 2020-12-16 09:35:18Z justme1968
31_HUEDevice.pm      23344 2020-12-13 17:05:33Z justme1968
10_IT.pm             20839 2019-12-28 09:41:47Z bjoernh
10_MAX.pm            23517 2021-01-13 15:38:49Z Wzut
10_MQTT2_DEVICE.pm   23596 2021-01-23 17:25:12Z rudolfkoenig
00_MQTT2_SERVER.pm   23609 2021-01-24 18:51:58Z rudolfkoenig
91_notify.pm         21427 2020-03-15 10:10:32Z rudolfkoenig
70_Pushbullet.pm      9730 2015-10-30 15:06:41Z fhainz
16_STACKABLE_CC.pm   18467 2019-01-31 08:02:51Z rudolfkoenig
99_SUNRISE_EL.pm     22789 2020-09-18 19:00:46Z rudolfkoenig
99_Utils.pm          22524 2020-08-02 14:34:02Z rudolfkoenig
98_version.pm        15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm        22982 2020-10-17 12:49:38Z CoolTux

AttrTemplate.pm      22985 2020-10-18 09:04:19Z rudolfkoenig
Blocking.pm          23268 2020-12-01 11:48:48Z rudolfkoenig
Color.pm             20813 2019-12-22 18:42:10Z justme1968
DevIo.pm             23241 2020-11-27 16:25:33Z rudolfkoenig
GPUtils.pm           19666 2019-06-20 11:17:29Z CoolTux
HttpUtils.pm         22917 2020-10-05 14:37:58Z rudolfkoenig
Meta.pm              21008 2020-01-18 10:22:10Z loredo
OpenWeatherMapAPI.pm 23645 2021-01-30 17:55:57Z CoolTux
RTypes.pm            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm     23300 2020-12-06 11:36:24Z rudolfkoenig
TcpServerUtils.pm    23472 2021-01-04 19:56:38Z rudolfkoenig

fhemweb.js                 23453 2021-01-01 18:10:12Z rudolfkoenig


Eine kleine Bitte: Ich weiß nicht, was Ihr von diesen Maple CULs haltet. Aber bisher sah mein Raspberry schon aus wie ein Igel und jedes Mal wenn man ihn anpackte, hatte man Angst, irgend eine Antenne abzubrechen. Daher hielt ich diese Entscheidung für notwendig und möchte ungern meine Hardwareentscheidung zum zentralen Thema dieses Threads machen.

Schonmal vielen Dank für Eure Hilfe!

Beta-User

Meine Güte. IODev ist leer, und du schreibst Romane...?!?

Wie wäre es mit:
attr cm IODev SMH_2_868
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Dynalon

Hallo Beta-User,

Du kennst mich ja mittlerweile - auf Dein Anraten hin habe ich mein FHEM ja komplett neu aufgesetzt und diesmal strikt keine externen Quellen zu Rate gezogen. Leider ist mein Blick/Gedächtnis für solche Dinge einfach miserabel.

Ich hatte es schon versucht, bin aber glaube ich vom falschen Anschluss des Maple ausgegangen und habe eine Fehlermeldung erhalten. Sorry!

Hat funktioniert, jetzt läuft es. Vielen Dank!



Beta-User

Nevermind... Besser zu viel als zu wenig geschrieben.

[gelöst]?

PS: MapleCUL ist für MAX m.E. eine gute Entscheidung!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Zitat von: Dynalon am 18 Februar 2021, 12:42:09
2021.02.18 11:19:01 1: cm, did not find suitable IODev (CUL etc. in rfmode MAX)! You may want to execute 'attr cm IODev SomeCUL'

Das Verwirrende: Alles funktioniert (habe bisher 4 Fenster-/Türsensoren darüber in Betrieb und bekomme deren Zustand wie gewünscht in Echtzeit
a. dann mach mal einen Vorschlag wie man das noch deutlicher als Fehlermeldung formuliern kann.

b. klar der "falsche" CUL empfängt und reicht bis zum bitteren Ende durch, aber beim senden ist dann halt Essig weil cm den "richtigen" CUL als IODev nicht erraten kann.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher