"umgebauter" sensor HM-SEC-SC-2 zicked bei smartvisu, in fhem aber nicht

[the ratman]

hiho leute,

vielleicht kennt das problem wer? ich bin total ratlos und kann nicht mal sagen, ob ich wirklich hierher oder ins hm-abteil gehöre mit dem problem.

ich habe 3 der oben genannten magnet-kontakte am laufen.
in fehm machen alle 3, was sie sollen, in smartvisu nur 2

der einzige unterschied ist, das beim 3. kontakt der sabotage-kontakt ein ist und ich ihn als 2. magnetkontakt mißbrauche.
sinn: so kann ich "billig" bei 2 glashaus-fenster gleichzeitig feststellen, ob sie geöffnet sind.
der 3. kontakt war übrigens bis heute mittag ebenfalls noch richtig am werkeln. erst seit der sabotage-kontakt an ist, zeigt sich das komische verhalten:
er zeigt ab nun nur mehr den batteriestand von haus aus an, der magnetkontakt und der sabotage-kontakt zeigen jedoch erst ab einer änderung was an.
sobald ich die seite neu aufrufe sind auch die beiden werte wieder weg.
die beiden anderen sensoren zeigen IMMER korrekte stände in smartvisu an.

smartvisu aufruf

Code Auswählen Erweitern

{{ basic.symbol('MK_Treibhaus_Fenster', 'MK_Treibhaus_Fenster.ko','',icon1~'fts_window_roof_open_2.png','offen') }} {{ basic.symbol('MK_Treibhaus_Fenster1', 'MK_Treibhaus_Fenster.ko','',icon0~'fts_window_roof.png','geschlossen') }}
{{ basic.symbol('MK_Treibhaus_Fenster2', 'MK_Treibhaus_Fenster2.ko','',icon1~'fts_window_roof_open_2.png','offen') }} {{ basic.symbol('MK_Treibhaus_Fenster21', 'MK_Treibhaus_Fenster2.ko','',icon0~'fts_window_roof.png','geschlossen') }}

listing des sensors

Code Auswählen Erweitern

Internals:
   DEF        3FA638
   HMlan_MSGCNT 128
   HMlan_RAWMSG E3FA638,0000,00CE36B4,FF,FFCF,1EA6413FA63832243301AF00
   HMlan_RSSI -49
   HMlan_TIME 2016-04-11 16:08:50
   IODev      HMlan
   LASTInputDev HMlan
   MSGCNT     128
   NAME       MK_Treibhaus_Fenster
   NR         269
   NTFY_ORDER 50-MK_Treibhaus_Fenster
   STATE      <table> <tr align="left"><td>Fenster 1</td><td>geschlossen</td></tr> <tr align="left"><td>Fenster 2</td><td>geschlossen</td></tr> </table>
   TYPE       CUL_HM
   lastMsg    No:1E - t:41 s:3FA638 d:322433 01AF00
   protLastRcv 2016-04-11 16:08:50
   protSnd    120 last_at:2016-04-11 16:08:50
   protState  CMDs_done
   rssi_at_HMlan max:-38 cnt:128 lst:-49 avg:-43.88 min:-57
   Helper:
     Dblog:
       Activity:
         Logdb:
           TIME       1460380255.9409
           VALUE      alive
       R-cyclicinfomsg:
         Logdb:
           TIME       1460380519.43065
           VALUE      on
       R-eventdlytime:
         Logdb:
           TIME       1460380520.15005
           VALUE      0 s
       R-paircentral:
         Logdb:
           TIME       1460380519.43065
           VALUE      0x322433
       R-sabotagemsg:
         Logdb:
           TIME       1460380519.43065
           VALUE      on
       R-sign:
         Logdb:
           TIME       1460380520.15005
           VALUE      on
       Alive:
         Logdb:
           TIME       1460383573.94274
           VALUE      yes
       Battery:
         Logdb:
           TIME       1460383730.23436
           VALUE      ok
       Contact:
         Logdb:
           TIME       1460383730.23436
           VALUE      geschlossen (to HMlan)
       Sabotageerror:
         Logdb:
           TIME       1460383573.94274
           VALUE      geschlossen
       State:
         Logdb:
           TIME       1460383730.23436
           VALUE      geschlossen
       Trigdst_322433:
         Logdb:
           TIME       1460383730.23436
           VALUE      noConfig
       Trigger_cnt:
         Logdb:
           TIME       1460383730.23436
           VALUE      175
   Readings:
     2016-04-11 15:15:19   PairedTo        0x322433
     2016-04-11 15:15:19   R-cyclicInfoMsg on
     2016-04-11 15:15:20   R-eventDlyTime  0 s
     2016-04-11 15:15:19   R-pairCentral   0x322433
     2016-04-11 15:15:19   R-sabotageMsg   on
     2016-04-11 15:15:20   R-sign          on
     2016-04-11 16:06:13   alive           yes
     2016-04-11 16:08:50   battery         ok
     2016-04-11 16:08:50   contact         closed (to HMlan)
     2016-04-11 16:06:13   recentStateType info
     2016-04-11 16:06:13   sabotageError   off
     2016-04-11 16:08:50   state           closed
     2016-04-11 16:08:50   trigDst_322433  noConfig
     2016-04-11 16:08:50   trigger_cnt     175
   Helper:
     HM_CMDNR   30
     cSnd       013224333FA63801040000000001,013224333FA6380103
     mId        00B1
     peerIDsRaw ,00000000
     rxType     28
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       newCh      1
       newChn     +3FA638,00,00,00
       nextSend   1460383730.22154
       prefIO
       rxt        2
       vccu
       p:
         3FA638
         00
         00
         00
     Mrssi:
       mNo        1E
       Io:
         HMlan      -47
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMlan
       flg        A
       ts         1460383730.13454
       ack:
         HASH(0x3642ba0)
         1E80023224333FA6380101C800
     Rssi:
       At_hmlan:
         avg        -43.8828125
         cnt        128
         lst        -49
         max        -38
         min        -57
     Shadowreg:
     Tmpl:
Attributes:
   DbLogExclude 1
   IODev      HMlan
   actCycle   028:00
   actStatus  alive
   alias      Fenster
   autoReadReg 5_readMissing
   eventMap   off:geschlossen on:offen open:offen closed:geschlossen
   expert     0_defReg
   firmware   2.4
   group      Treibhaus Sensoren
   icon       scene_summerhouse
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       Treibhaus,HMlan
   serialNr   MEQ1140059
   sortby     5
   stateFormat <table> <tr align="left"><td>Fenster 1</td><td>state</td></tr> <tr align="left"><td>Fenster 2</td><td>sabotageError</td></tr> </table>
   subType    threeStateSensor
fehlermeldungen im log kommen auch keine - weder zum kontakt selber noch zu fronthem

[dev0]

Probiere es mal ohne eventmap attribut.

[the ratman]

interessante sache ...

eventmap raus und sicherheitshalber n neustart von fhem
jetzt kommt der sabotage-sensor sofort aber der magnetkontakt braucht immer noch nen anstoß.

und nun der größte gag des jahres:
ich hab mal schnell auch noch den stateFormat rausgeworfen - jetzt geht alles.

somit muß ich mir nur noch ne neue idee suchen, wie ich das auf anderen wege darstellen kann.
ich frag mich aber grade, ob dieses verhalten gewollt, normal oder fehlerhaft is und wie mans umgehen könnte. ich mag eig. eventmap und devstate, weils so herrlich simpel zu handeln ist und keine weiteren spielereien benötigt.

aber mal vielen thx für den denkanstoß in die richtige richtung!

[dev0]

Ich habe den Verdacht, dass eventMap unter gewissen Umständen nicht so arbeitet wie es soll. Ich kann und will es gar nicht beweisen, da ich es nicht verwende.
Vielleicht hat Jörg noch ne Idee, sonst musste debuggen und Dich ggf. mit dem Author kurzschließen.

[the ratman]

nomal thx für info

also readingsgroup nehmen
oder hast was besseres im angebot? *g*

[dev0]

Smartvisu und zum Administrieren telnet.

[herrmannj]

Müsste man debuggen. Vmtl irgendwelche Effekte converter vs stateFormat.

In der aktuelle Version möchte aber da kein debug investieren (schaue es mir aber für die next an).
Es gibt viele work-arounds: stateFormat raus, userReading, etc.

Wenn jemand das untersuchen möchte übernehme ich den patch gern - lohnt sich aber imho wegen der leichten Vermeidbarkeit nicht.

vg
joerg

[the ratman]

Smartvisu und zum Administrieren telnet.

naja, telnet is ned so meines - bin eher so der "drück drauf typ" *g* - smartvisu rennt lokal eh bei mir, aber leider ist das ding ja so extrem unkommunikativ nach "aussen" und nervt bei 8 endgeräten schon ein wenig sehr , wenn man mal wieder 1 (oder 150) neuen gads freigeben muß für alle *juhuuu* weil weiterkopieren der einzelnen configs mag nicht so wirklich funzen, hab ich gemerkt. aber wurscht - ich hab eigentlich alles, wie ichs will - somit bin ich recht zufrieden.

was das ursprüngliche problem angeht: ne readingsgroup hats ja super hingebracht fürs dashboard - jetzt kenn ich mich wenigstens auch gleich damit ein bissi aus ... so lernt man dazu!

aja - dashboard - nur zwecks vollständigkeit: dort kommen zwar die readings immer korrekt an, aber nur im "original". ne eventmap kommt auch wieder erst nach nem update.