HM-MOD-Re-8: Sleepmodus?

[jbadlat]

Hallo Gemeinde,

ich schalte zuverlässig damit meine Relais. Nur steigt das Gerät nach einer gewissen Zeit wieder aus. Dann bekomme ich keinen Kontakt mehr und kann nicht schalten.
Dann kommt immer wieder: MISSING ACK
Nehme ich das Ganze vom Netz und wieder dran, so klappt es wieder für eine gewisse Zeit. Sehr komisch.

Code Auswählen Erweitern

Internals:
   CUL868_2_MSGCNT 60
   CUL868_2_RAWMSG A0E20800256E9210A123F0102000000::-89.5:CUL868_2
   CUL868_2_RSSI -89.5
   CUL868_2_TIME 2018-06-18 12:37:38
   DEF        56E921
   IODev      CUL868_2
   LASTInputDev CUL868_2
   MSGCNT     60
   NAME       Gartensteckdose
   NOTIFYDEV  global
   NR         262
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 Gartensteckdose_Sw_01
   channel_02 Gartensteckdose_Sw_02
   channel_03 Gartensteckdose_Sw_03
   channel_04 Gartensteckdose_Sw_04
   channel_05 Gartensteckdose_Sw_05
   channel_06 Gartensteckdose_Sw_06
   channel_07 Gartensteckdose_Sw_07
   channel_08 Gartensteckdose_Sw_08
   lastMsg    No:20 - t:02 s:56E921 d:0A123F 0102000000
   protCmdDel 196
   protLastRcv 2018-06-18 12:37:38
   protResnd  41 last_at:2018-06-18 14:31:26
   protResndFail 41 last_at:2018-06-18 14:31:31
   protSnd    92 last_at:2018-06-18 14:31:19
   protState  CMDs_done_Errors:1
   rssi_CUL868_2 cnt:1 min:-186 max:-186 avg:-186 lst:-186
   rssi_at_CUL868_2 cnt:60 min:-91 max:-44 avg:-66.79 lst:-89.5
   READINGS:
     2018-06-18 10:48:02   CUL868_2_RSSI_old -91
     2018-06-05 15:34:23   CommandAccepted yes
     2018-06-05 15:34:22   D-firmware      1.2
     2018-06-05 15:34:22   D-serialNr      OEQ0205865
     2018-06-18 11:42:05   PairedTo        0x0A123F
     2018-06-05 15:34:27   R-pairCentral   0x0A123F
     2018-06-18 11:41:59   level           0
     2018-06-18 11:41:59   pct             0
     2018-06-18 11:41:59   powerOn         2018-06-18 11:41:59
     2018-06-18 11:41:59   recentStateType info
     2018-06-18 14:31:31   state           MISSING ACK
     2018-06-18 11:41:59   timedOn         off
     RegL_00.:
       VAL       
   helper:
     HM_CMDNR   40
     PONtest    0
     cSnd       010A123F56E92100040000000000,110A123F56E9210202C80000
     mId        00BE
     regLst     ,0
     rxType     2
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +56E921,00,00,00
       nextSend   1529318258.8984
       prefIO     
       rxt        0
       vccu       
       p:
         56E921
         00
         00
         00
     mRssi:
       mNo        20
       io:
         CUL868_2:
           -87.5
           -87.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       CUL868_2:
         avg        -186
         cnt        1
         lst        -186
         max        -186
         min        -186
       at_CUL868_2:
         avg        -66.8
         cnt        60
         lst        -89.5
         max        -44
         min        -91
     shadowReg:
     tmpl:
Attributes:
   IODev      CUL868_2
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   model      HM-MOD-Re-8
   msgRepeat  1
   room       Garten
   serialNr   OEQ0205865
   subType    switch
   webCmd     getConfig:clear msgEvents


Das meine Verbindung nicht die Beste ist, weiß ich. Aber direkt nach dem Neueinstecken, klappt es ja zuverlässig. Das ist reproduzierbar!
Brauche vielleicht einen Denkschubser. Danke, Jörg

[frank]

ich behaupte mal, das du mit rssi -186 den negativen highscore hast. glückwunsch!!!

[hexenmeister]

ich behaupte mal, das du mit rssi -186 den negativen highscore hast. glückwunsch!!!

ich hätte nicht gedacht, dass so ein Wert überhaupt noch gemessen werden kann

[LuckyDay]

Man musste jetzt mal fragen , welche Software er auf dem Cul hat , Noansi?

[jbadlat]

Der Wert ist 89.5dB.
Der CUL hat V 1.55.

Jetzt hatte ich über Nacht alles beim alten belassen und heute Morgen gar keinen Kontakt mehr.
Stecker raus,Stecker rein. Alles wieder ok mit 84,5 dB RSSI.

Code Auswählen Erweitern

HM Gartensteckdose CMDs_pending
HM Gartensteckdose_Sw_05 set_off
HM Gartensteckdose CMDs_done
HM Gartensteckdose RAWMSG: BLAHC8002512345A122A0105000000::-84.5:CUL868_2
HM Gartensteckdose RSSI: -84.5
HM Gartensteckdose_Sw_05 deviceMsg: off (to CUL868_2)
HM Gartensteckdose_Sw_05 level: 0
HM Gartensteckdose_Sw_05 pct: 0
HM Gartensteckdose_Sw_05 off
HM Gartensteckdose_Sw_05 timedOn: off
HM Gartensteckdose CMDs_pending
HM Gartensteckdose_Sw_05 set_on
HM Gartensteckdose CMDs_done
HM Gartensteckdose RSSI: -84.5
HM Gartensteckdose RAWMSG: BLUBD8002512345A122A0105C80000::-84.5:CUL868_2
HM Gartensteckdose_Sw_05 deviceMsg: on (to CUL868_2)
HM Gartensteckdose_Sw_05 level: 100
HM Gartensteckdose_Sw_05 pct: 100
HM Gartensteckdose_Sw_05 on
HM Gartensteckdose_Sw_05 timedOn: off

Das sagt der Eventmonitor. Wie komme ich nun dem Fehler auf die Spur? Ideen?
Danke, Jörg

[LuckyDay]

Der CUL hat V 1.55

weis gar nicht mehr ob die 1.55 sauber den burst kann?
und der wäre zwingend bei deinem HM-MOD-Re-8

und wie gesagt ab -80 kann gehen muß aber nicht!

verbessere deinen Funk, update vom Cul

[Otto123]

verbessere deinen Funk, update vom Cul

am Besten auch die TimeStamp Firmware -> https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Und/oder einen zweiten IO von Homematic und VCCU

Gruß Otto

[Bison]

Hallo Jbladat,

konntest du dein Problem lösen?

ich hänge gerade an der gleichen Stelle.

Gruß

Bison

[noansi]

Hallo Zusammen,

Man musste jetzt mal fragen , welche Software er auf dem Cul hat , Noansi?

Nee, das kann auch die tsculfw nicht. 

Die -186 kommen allerdings auch aus der Interpretation einer Ack Info message vom device in CUL_HM. Sprich, das device würde behaupten mit einem RSSI von -186 vom CUL zu empfangen.

Gruß, Ansgar.

[Bison]

Hallo zusammen,

ich bin mit meinen RSSI Werten unter -80 (-76,5). Wenn ich nach 24 Stunden ein set on-for-timer an das Device sende wird es nich aufgeweckt. Sende ich vom WebFrontEnd ein Set on funktioniert das aufwecken. Da ich inzwischen sehr viel in diese Lösung investiert habe möchte ich noch nicht aufgeben und verfolge gerade diese Ansätze:

1. kurz vor Set on-for-timer einen "Wake on Radio" Befehl senden (set on - geht nicht da dann bereits die Beregnung beginnt)
2. innerhalb der Wake-Phase mit einer gepoolten Abfrage das Device Wach zu halten.

Vielleicht kann mir jemand mit seinem Wissen oder Erfahrung helfen.

P.S. CULFW 1.66

Mit freundlichen Grüßen

Bison

[frank]

zu 1. seltsam dass ein "on" funktioniert und ein "on-for-timer" nicht. versuche es mit einem statusrequest.
zu 2. damit wird das device sicher in overload gehen und gar nichts mehr senden.

warum investierst du nicht einfach 20eur und besorgst dir ein echtes homematic io (HM-MOD-UART)?
den cul kannst du dann mit einer vccu als fallback betreiben.

und noansi's tsculfw ist für homematic sowieso "pflicht" beim cul.

[Bison]

Hallo Frank,

ich werde den StatusRequest gleich mal einbauen. Da der MOD-RE-8 8 Kanäle hat muss ich das wohl für alle 8 machen (ich probiere es erst mal mit einem damit meine Funklast nicht so hoch geht). Da der Sleepmodus gefühlt erst nach ein paar Stunden zuschlägt dachte ich den WAKE ON RADIO im 6 Stunden Takt zu machen. Leider ist die Funktion WAKE ON RADIO des MOD-RE-8 nirgends dokumentiert. Die empirische Ermittlung ist halt nervig.

Ich habe mit dem MOD-RE-8 eine 8 kanalige Beregnungssteuerung gebaut. Diese ist im Gartenhaus und wird von FHEM gesteuert. Der MOD-RE-8 sitzt im Gehäuse mit 8 Tastern und LED (für die Frau). Ich habe vor in Abhängigkeit von Sonnenstunden, Regenmenge und Ort (Gewächshaus, Terrasse usw) die Bewässerung zu steuern. Nun stolpere ich aber schon am ersten kleinen Schritt (habe als Backup Idee 2 mal den HM-LC-Sw4-PCB im Sinn) Aber er reizt mich das mit etwas günstigeren MOD-RE-8 hinzubekommen -> kann doch nicht so schwer sein.

Gruß

Werner

[Pfriemler]

ich werde den StatusRequest gleich mal einbauen. Da der MOD-RE-8 8 Kanäle hat muss ich das wohl für alle 8 machen ...

Nö. Die verwenden alle das gleiche Funkmodul und den gleichen Chip. Einmal wecken reicht sicher.

Einen "Sleepmodus" gibt es in dem Sinne nicht beim Re-8. Allerdings werden meine beiden schon regelmäßig am Tag bespielt und ich kann da nicht mitreden.
Wie frank fände ich es auch seltsam, dass on-for-timer nicht gehen soll. Hast Du das auch schon mal aus dem WebIF probiert? Funktioniert die steuernde Routine nachweislich (sprich: gibt es "set ... on-for-timer.."-Einträge im Log)?

es reizt mich das mit etwas günstigeren MOD-RE-8 hinzubekommen -> kann doch nicht so schwer sein.

Du solltest nicht völlig vergessen, dass die Bursts zum Aufwecken des Gerätes doch ziemlich Funklast erzeugen. 1x pro Tag schalten und einmal Status abfragen mag angehen. Wird aber hier wohl eher so sein.

[Bison]

Hallo zusammen,

ich hatte gestern vergessen denn statusRequest einzubauen. Werde deshalb erst morgen früh was sagen können ob es funktioniert. Allerdings ist mir bei den Attributen im Device wie in den Channel das Attribut BurstAccess aufgefallen. Da ich das Modul gebraucht gekauft habe könnte es evtl. damit was auf sich haben.
in den Internals des Device steht:
protCondBurst              forced_off

leider finde ich kein burstRx Register das ich auf on setzen kann. Aber es gibt eine Menge Register die auf (Dly -> Delay) usw hinweisen. Sollte also der Verkäufer meines Moduls dort eingetaucht sein wird es schwer. --> meine Zuversicht auf eine schwäbische Lösung sinkt.

Gruß

Bison

[Pfriemler]

protCondBurst kenne ich nicht. Meine beiden Re-8 haben das nicht.
burstRx regelt bei zyklisch aufwachenden Geräten wie dem Heizkörperthermostaten (die dann lazyConfig unterstützen), ob sie auch durch Burst geweckt werden können (etwa durch einen Fensterkontakt). Das ist hier nicht konfigurierbar, weil der Re-8 nicht zyklisch sendet und ein Warten auf eine Meldung also sinnlos ist.

In Bezug auf einen Peer gibt es bei jedem Schaltaktor Unmengen von Dly-Registern. Kann man getrost ignorieren.
Was in jedem Fall sichergestellt sein sollte: Ganz egal was ein Vorbesitzer dort herumgepfriemelt haben mag - mit einem erfolgreichen Reset sollten alle diese Spuren gelöscht sein und der Aktor wieder junfgräulich werkstdefault agieren. Und das beinhaltet einen sauberen Burstbetrieb. Schwaben ist nicht in Gefahr...