Max Cube state kein Event

Begonnen von neyzen, 01 August 2020, 01:34:30

Vorheriges Thema - Nächstes Thema

neyzen

Hallo,

ich möchte mit einem DOIF überprüfen ob mein Cube seine Verbindung verliert.
im state steht ja dann "disconnected"

Mein DOIF sieht so aus.

([ml:state] eq "disconnected") (set SystemOk on)
DOELSEIF ([ml:state] eq "opened") (set SystemOk off)


Wenn ich jetzt den Strom abschalte dann verliert mein Cube die Verbindung und im state steht auch disconnected. Aber mein DOIF reagiert nicht. Nur wenn ich es manuel anstoße. Also...
set  DOIF_SystemStatus checkall

der state scheint kein Event zu erzeugen.
Im Eventmonitor steht aber das ml(cube) DISCONNECTED
Hat einer eine Idee?

amenomade


Dein Problem kann mehrere Ursachen haben, aber ich tippe auf "do always" vergessen
https://fhem.de/commandref_DE.html#DOIF_do_always

Wenn das nicht das Problem ist, brauchen wir für weitere Analyse ein paar Informationen: ein "list" von betroffenen Devices, ein Auszug aus dem Eventmonitor, wo man die Events sehen kann, usw
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

neyzen

Do always könnte ich mal probieren, aber glaube nicht das das problem ist, da der doif von cmd1 auf cmd2 springen müsste,aber er bekommt kein event. wie gesagt wenn ich das doif manuell anstoße dan reagiert er auch richtig.

das device heist ml

Internals:
   CULMAX0_MSGCNT 12
   CULMAX0_TIME 2020-08-01 00:17:00
   DEF        192.168.178.24:62910 180
   DeviceName 192.168.178.24:62910
   FD         51
   FUUID      5c48d15a-f33f-2b39-9a84-f57a5ddb372d557b
   INTERVAL   180
   LASTInputDev CULMAX0
   MSGCNT     12
   NAME       ml
   NR         24
   PARTIAL   
   STATE      auto
   TYPE       MAXLAN
   addr       00d3ca
   clockset   3
   cubeTimeDifference 0
   dutycycle    0 %
   freememoryslot 48
   fwversion  0113
   pairmode   0
   persistent 1
   serial     IHA0005577
   READINGS:
     2020-08-01 00:17:00   RSSI            -58.5
     2020-08-01 00:17:00   desiredTemperature 0.0
     2020-08-01 01:09:46   dutycycle       0
     2020-08-01 01:09:46   firmware        0.1
     2020-08-01 00:17:00   mode            auto
     2020-08-01 00:17:00   peerIDs         00e3f1,030f8a,050258,0696d1,19c9ee
     2020-08-01 00:17:00   peerList        MAX_00e3f1,MAX_030f8a,MAX_050258,MAX_0696d1,MAX_19c9ee
     2020-08-01 01:09:46   state           opened
     2020-08-01 01:09:46   testresult      0
   devices:
     HASH(0x46236d0)
     HASH(0x4274a50)
     HASH(0x49da068)
     HASH(0x4b06c20)
     HASH(0x456f0d0)
     HASH(0x4a33268)
     HASH(0x4cd6958)
   groups:
     HASH(0x44942b8)
     HASH(0x44287a8)
     HASH(0x42750c8)
     HASH(0x4ad66e0)
     HASH(0x4b221d0)
   helper:
     io:
       CULStick:
         raw        Z0F49050300D3CA00E3F100141F974ECE
         rssi       -58.5
         time       1596237257.04552
Attributes:
   event-on-change-reading .*
   icon       hue_filled_bridge_v2
   room       Heizung
   stateFormat mode


Ich hab nochmal den strom abgeschaltet und im eventmonitor taucht diese zeile auf

2020-08-01 02:31:56 MAXLAN ml DISCONNECTED
aber das reading state wird nicht aktualisiert wird also nicht rot,nur wenn ich die seite refreshe




Wzut

Zitat von: neyzen am 01 August 2020, 02:33:48
das reading state wird nicht aktualisiert wird also nicht rot,nur wenn ich die seite refreshe
works as designed :)
DISCONNECT wird nicht von 00_MAXLAN gesetzt (mit Event) sondern direkt duch DevIo.pm
Da ich mit DevIo noch nie etwas zu tun hatte und auch nicht so richtig durchblicke was es wie macht hatte ich u.a. hier -> https://forum.fhem.de/index.php/topic,112669.0.html schon um Hilfe angefragt aber leider bis heute ohne direkte Antwort. D.h. nach heutigem Stand müsste man in 00_MAXLAN diesen untergeschobenen Status abfragen und dann damit einen zusätzlichen Event generieren (den könntest du dann abfragen)l Ich habe bisher auf solche Aktionen verzichtet da dies nur greifen würde wenn man MAXLAN ohne ondemand betreibt (wie du) was aber eigentlich nach den bisherigen Erfahrungen nicht ratsam ist.


Bei deinem list fällt mir aber noch etwas anderes auf : Du hast zusätzlich noch einen CUL im rfmode MAX am Start und am dazugehörigen CUL_MAX Device hast du den
CUBE mit seiner ID 00d3ca nicht auf die blacklist gesetzt. Das führt u.a. dazu das CULMAX Device den Cube als MAX Gerät sieht und auch so behandelt :
2020-08-01 00:17:00   mode            auto
2020-08-01 00:17:00   peerIDs         00e3f1,030f8a,050258,0696d1,19c9ee
2020-08-01 00:17:00   peerList        MAX_00e3f1,MAX_030f8a,MAX_050258,MAX_0696d1,MAX_19c9ee

da macht dann dein stateFormat mode auch wenig Sinn. Hat nun alles nicht mit deinem aktuellen Problem zu tun, zeigt aber eine aktuell nicht "saubere" Config :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

neyzen

Ja ich hab noch ein Cul Stick mit dem ich max Taster steuere. Hat aber nichts mit der Heizung zu tuen.
Was könnte ich den hier noch optimieren? Hab ich nicht so ganz verstanden. Wo müsste ich was auf eine Blackliste stellen?

Wie könnte ich den den Status vom Cube abfragen und das kontrollieren?

Wzut

Das du da zwei Welten hast spielt keine Rolle, der CUL "sieht" den Cube und behandelt ihn falsch.
Damit er ihn ignoriert setze einfach wie geschrieben an deinem CUL_MAX Device das Attribut blacklist auf 00d3ca.
Bsp bei mir um die Testinsel vom aktiven System zu trennen :
attr CULMAX0 blacklist 14491a

Den Cube kann man ganz gut mit dem PRESENCE Modul überwachen
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

#6
zum Thema keine Events :
Du kannst gern mal meine Beta Version testen, die erzeugt den Event DISCONNECTED  in state (gross geschrieben im Gegensatz zu DevIO)
Zum Überwachen würde ich aber das neue Reading connected benutzen ( 0 bzw 1 ) das hat den Vorteil das es mit event-on-change-reading klar kommt,
im Gegensatz zu state.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

neyzen

Super,

vielen Dank. Probiere ich aus

Wzut

na so drigend scheint es ja nicht gewesen zu sein, nach 6 Tagen 0 Downloads ....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

amenomade

Zitat von: Wzut am 08 August 2020, 18:19:21
na so drigend scheint es ja nicht gewesen zu sein, nach 6 Tagen 0 Downloads ....
Urlaubsperiode ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus