4 fach Aktor Homematic channel_03 Einschalten ok, Ausschalten Nein

Begonnen von UweUwe, 09 März 2019, 15:20:37

Vorheriges Thema - Nächstes Thema

UweUwe


UweUwe

Hab mit meinem Wemos ein Thema. Der angeschlossene 4 fach Aktor schält nicht mehr und zeigt unbestimmte Zustände. Ich glaube , dass er keine Rückmeldung bekommt.

[Internals:
   AssignedPeerCnt 1
   CNT        125
   Clients    :CUL_HM:
   DEF        uart://192.168.10.74:23
   DEVCNT     125
   DevState   99
   DevType    UART
   DeviceName 192.168.10.74:23
   FD         39
   FUUID      5c892cba-f33f-64ff-f9ff-c5c529ae97f3014b
   LastOpen   1553191539.53255
   NAME       Wemos_HM_GW
   NR         285
   PARTIAL   
   RAWMSG     040200
   RSSI       -62
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory 0/0/0/0/0/-1/0/0/0/0/0/0
   msgLoadHistoryAbs 0/0/0/0/0/0/1/1/1/1/1/1/1
   owner      070657
   owner_CCU  VCCU
   Helper:
     CreditTimer 364
     FW         66561
     Initialized 1
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     PeerQueue:
     RoundTrip:
       Delay      0.0886640548706055
     loadLvl:
       lastHistory 1553196942.17653
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     68DB70     +68DB70,00,00,00
   READINGS:
     2019-03-21 19:05:42   D-HMIdAssigned  070657
     2019-03-21 19:05:42   D-HMIdOriginal  59DB4E
     2019-03-21 19:05:42   D-firmware      1.4.1
     2019-03-21 19:05:42   D-serialNr      OEQ0607792
     2019-03-13 17:33:43   D-type          HM-MOD-UART
     2019-03-21 19:05:42   cond            ok
     2019-03-21 20:10:29   load            0
     2019-03-21 19:05:42   loadLvl         low
     2019-03-21 19:05:39   state           opened
   helper:
Attributes:
   DbLogExclude .*
   hmId       070657
   room       HomeMatic


Der betroffene 4 fach Aktor sieht so aus , eine Wand und 4 Meter vom WEMOS entfernt . Hier ist nur ein Kanal dargestellt, alle Kanäle sind undefiniert
Internals:
   DEF        43D9AB
   FUUID      5c481922-f33f-64ff-3c5c-6781476d57d6b599
   IODev      myHmUART
   LASTInputDev Wemos_HM_GW
   MSGCNT     43
   NAME       AKTOR01_GARTEN
   NOTIFYDEV  global
   NR         88
   NTFY_ORDER 50-AKTOR01_GARTEN
   STATE      MISSING ACK
   TYPE       CUL_HM
   Wemos_HM_GW_MSGCNT 22
   Wemos_HM_GW_RAWMSG 05000045AA800243D9AB0706570102C84059
   Wemos_HM_GW_RSSI -69
   Wemos_HM_GW_TIME 2019-03-20 20:19:06
   channel_01 G.Pan.Li
   channel_02 G.Weg.Li
   channel_03 Rudi.Li
   channel_04 AKTOR01_GARTEN_Sw_04
   lastMsg    No:AA - t:02 s:43D9AB d:070657 0102C84059
   myHmUART_MSGCNT 21
   myHmUART_RAWMSG 0403004FAA800243D9AB0706570102C84059
   myHmUART_RSSI -79
   myHmUART_TIME 2019-03-20 20:19:06
   protCmdDel 23
   protLastRcv 2019-03-20 20:19:06
   protRcv    22 last_at:2019-03-20 20:19:06
   protResnd  38 last_at:2019-03-21 19:43:53
   protResndFail 12 last_at:2019-03-21 19:43:58
   protSnd    39 last_at:2019-03-21 19:43:40
   protState  CMDs_done_Errors:1
   rssi_at_Wemos_HM_GW cnt:22 min:-77 max:-67 avg:-73.45 lst:-69
   rssi_at_myHmUART cnt:21 min:-87 max:-79 avg:-83.09 lst:-79
   rssi_myHmUART cnt:21 min:-98 max:-89 avg:-94.28 lst:-89
   READINGS:
     2019-02-07 21:41:12   CommandAccepted yes
     2019-01-06 10:41:33   D-firmware      2.8
     2019-01-06 10:41:33   D-serialNr      MEQ1810146
     2019-03-09 14:54:28   PairedTo        0x070657
     2019-01-06 10:41:38   R-pairCentral   0x070657
     2019-03-09 14:54:28   RegL_00.        00:00 02:01 0A:07 0B:06 0C:57 15:FF 18:00
     2019-02-02 17:49:45   powerOn         2019-02-02 17:49:45
     2019-03-21 19:43:58   state           MISSING ACK
   helper:
     HM_CMDNR   182
     cSnd       1107065743D9AB0203000000,1107065743D9AB0202000000
     mId        0061
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +43D9AB,00,00,00
       nextSend   1553109546.41898
       rxt        0
       vccu       VCCU
       p:
         43D9AB
         00
         00
         00
       prefIO:
         myHmUART
     mRssi:
       mNo        AA
       io:
         Wemos_HM_GW:
           -69
           -69
         myHmUART:
           -77
           -77
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_Wemos_HM_GW:
         avg        -73.4545454545455
         cnt        22
         lst        -69
         max        -67
         min        -77
       at_myHmUART:
         avg        -83.0952380952381
         cnt        21
         lst        -79
         max        -79
         min        -87
       myHmUART:
         avg        -94.2857142857143
         cnt        21
         lst        -89
         max        -89
         min        -98
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   genericDeviceType switch
   icon       light_fairy_lights
   model      HM-LC-SW4-DR
   room       GARTENHAUS,CUL_HM
   serialNr   MEQ1810146
   subType    switch
   webCmd     getConfig:clear msgEvents


Wo liegt mein Fehler

Otto123

Hi,

naja der hat    IOgrp      VCCU:myHmUART
eingetragen. Und Der ist nicht der Beste:
rssi_myHmUART cnt:21 min:-98 max:-89 avg:-94.28 lst:-89

Mach doch daraus einfach VCCU dann regelt die das?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

UweUwe

Hallo Otto, schön von dir zu hören. Da ich physikalisch darauf die nächsten Wochen keinen Zugriff habe  , nochmals eine Nachfrage. Hab hier schlechte Erfahrung gemacht. Dazu melde ich mich noch.
Aktuell steht
IOgrp VCCU:myUART
und ich soll es verändern auf
IOgrp VCCU
korrekt ?



Otto123

ja. damit steht kein preffered IO mehr, der offenbar nicht der Beste ist.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

UweUwe

Hi, hab ich gemacht, WEMOS ist weiterhin an dem Aktor aktiv. Ich hab ihn auch installiert genau für diesen Zweck, den WEMOS und er hat auch seine Dienste getan, wenige Tage. Eigentlich war nur nur der Kanal 1 schwach, die übrigen Kanäle des Aktors taten ihren Dienst, jetzt ist das Phänomen auf allen Kanälen.

Frank_Huber

Wie gut ist das wlan?
Hat evtl der Aktor ein Antennen Problem?

Ich hab hier 3 IO Module über VCCU.
Lief über WLAN 2 Jahre stabil, jetzt seit der Umstellung über LAN.

Gesendet von meinem Doogee S60 mit Tapatalk


UweUwe

Hi, kann ich den wemos einfach mal inaktiv setzten ?
Dann sollte ja der ursprüngliche I/o wieder dran gehen.
Wlan ist an der Stelle top

Frank_Huber

dann einfach ein set Wemos_HM_GW close absetzen.
Hast die IOgrp umgestellt wie Otto es vorgeschlagen hat?
und falls es das Attribut IOdev gibt, das kannst löschen.

Hier ein Beispielaktor der über die VCCU läuft:
defmod HM_Bewegung_Garten CUL_HM 69F568
attr HM_Bewegung_Garten IOgrp VCCU
attr HM_Bewegung_Garten actCycle 000:30
attr HM_Bewegung_Garten actStatus alive
attr HM_Bewegung_Garten autoReadReg 4_reqStatus
attr HM_Bewegung_Garten expert 2_raw
attr HM_Bewegung_Garten firmware 1.7
attr HM_Bewegung_Garten model HM-Sen-MDIR-O-3
attr HM_Bewegung_Garten peerIDs 00000000,
attr HM_Bewegung_Garten serialNr PEQ00000000
attr HM_Bewegung_Garten subType motionDetector


wie sieht deine VCCU aus? sind die Gateways da sauber drin?

UweUwe

Hallo, ich habe die IOgrp Umstellung gemäss Otto gemacht. Es hat sich nichts geändert, da da sich WEMOS wieder eingebracht ist. Er sitzt ja auch am nächsten zu dem 4 fach Aktor. Und ich habe den Wemos dort örtlich installiert, da der direkte Draht vom RPI zu dem 4 fach Aktor nicht gut war, ab er komischerweise besser als jetzt. Eigentlich ging bisher nur ein Kanal des 4 fach Aktors nicht zuverlässig, jetzt geht kein Kanal mehr.
Mit dem Wemos gingen jedoch die Kanäle alle schon mal. Zuverlässig, das weiss ich nicht, zu wenig Testzeit stand leider zur Verfügung.
Ich kann mir auch vorstellen, dass der Aktor ein Thema hat, gibt es da eine Möglichkeit, diesen 4 fach Aktor neu zu starten, falls ich da drauf komme?

Ich hatte jetzt den Wemos die Nacht über aus und heute Vormittag geöffnet. Das ist das list der VCCU
Internals:
   DEF        070657
   FUUID      5c481922-f33f-64ff-6e3c-da736185b158c4c7
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     7048
   NAME       VCCU
   NOTIFYDEV  global
   NR         57
   NTFY_ORDER 50-VCCU
   STATE      myHmUART:ok,Wemos_HM_GW:ok
   TYPE       CUL_HM
   Wemos_HM_GW_MSGCNT 5828
   Wemos_HM_GW_RAWMSG 0500004223800207065769791200
   Wemos_HM_GW_RSSI -66
   Wemos_HM_GW_TIME 2019-03-22 09:44:47
   assignedIOs Wemos_HM_GW,myHmUART
   channel_01 RAUCHMELDER_Team
   channel_02 VCCU_Btn2
   channel_03 VCCU_Btn3
   channel_04 VCCU_Btn4
   channel_05 VCCU_Btn5
   channel_06 VCCU_Btn6
   channel_07 VCCU_Btn7
   channel_08 VCCU_Btn8
   channel_09 VCCU_Btn9
   channel_0A VCCU_Btn10
   channel_0B VCCU_Btn11
   channel_0C VCCU_Btn12
   channel_0D VCCU_Btn13
   channel_0E VCCU_Btn14
   channel_0F VCCU_Btn15
   channel_10 VCCU_Btn16
   channel_11 VCCU_Btn17
   channel_12 VCCU_Btn18
   channel_13 VCCU_Btn19
   channel_14 VCCU_Btn20
   channel_15 VCCU_Btn21
   channel_16 VCCU_Btn22
   channel_17 VCCU_Btn23
   channel_18 VCCU_Btn24
   channel_19 VCCU_Btn25
   channel_1A VCCU_Btn26
   channel_1B VCCU_Btn27
   channel_1C VCCU_Btn28
   channel_1D VCCU_Btn29
   channel_1E VCCU_Btn30
   lastMsg    No:C2 - t:11 s:070657 d:43D9AB 0201000000
   myHmUART_MSGCNT 1220
   myHmUART_RAWMSG 0500003CC2A01107065743D9AB0201000000
   myHmUART_RSSI -60
   myHmUART_TIME 2019-03-22 09:54:54
   protLastRcv 2019-03-22 09:54:39
   protRcv    3440 last_at:2019-03-22 09:54:39
   protRcvB   115 last_at:2019-03-22 08:07:23
   rssi_at_Wemos_HM_GW cnt:4596 min:-81 max:-65 avg:-69.76 lst:-66
   rssi_at_myHmUART cnt:255 min:-68 max:-59 avg:-62.15 lst:-60
   READINGS:
     2019-03-22 09:44:47   CommandAccepted yes
     2019-03-22 08:02:26   IOopen          2
     2019-03-22 08:02:26   state           myHmUART:ok,Wemos_HM_GW:ok
     2019-03-17 07:45:29   unknown_121059  received
     2019-03-02 17:55:35   unknown_325B86  received
     2019-01-06 09:12:24   unknown_36569B  received
   helper:
     HM_CMDNR   194
     PONtest    1
     mId        FFF0
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       nextSend   1553244894.44479
       prefIO     
       vccu       VCCU
       ioList:
         myHmUART
         Wemos_HM_GW
     mRssi:
       mNo        C2
       io:
         Wemos_HM_GW:
           -66
         myHmUART:
           -56
           -56
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_Wemos_HM_GW:
         avg        -69.7615317667539
         cnt        4596
         lst        -66
         max        -65
         min        -81
       at_myHmUART:
         avg        -62.1529411764705
         cnt        255
         lst        -60
         max        -59
         min        -68
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      myHmUART
   IOList     myHmUART,Wemos_HM_GW
   IOgrp      VCCU
   expert     2_raw
   model      CCU-FHEM
   room       HomeMatic
   subType    virtual
   webCmd     virtual:update


Die unknowns rühren von einer 2. Raspberry Installation her.
Ich tippe auch auf den 4 fach Aktor. Aber komisch ist es schon.

Otto123

Aktor neu starten bedeutet Strom weg und wieder dran ...
Die vier Kanäle des Aktors können eigentlich nicht unterschiedlich sein. Es wird ja alles über ein Devices empfangen und gesendet.
Es könnte sein, dass das was die Kanäle schalten separat zu Störungen führt und damit zu einem unterschiedlichem Verhalten.

Du kannst den Wemos ja als preferred IO eintragen.
IOgrp VCCU:Wemos_HM_GW
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

1. der aktor hat eventuell auch einen leichten "hörschaden". im letzten list gab es rssi unterschiede von etwa 10 punkten.

2.  ist der aktor in einen metallschrank eingebaut?

3. der wemos uart zeigt im list ein roundtrip delay von ca 90ms. ich würde mal kontrollieren, ob dieser wert konstant bleibt. dazu würde ich vorübergehend (eventuell 30 min) das attribut logIDs=sys beim uart setzen, und anschliessend die roundtrip delay in fhem log begutachten.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Frank_Huber

Eine weitere Möglichkeit:
Die Last am channel 3 stört den Funk. daher hier kein Ausschakten.

Den Aktor ohne Lasten an den Kanälen testen wäre gut.

Wuppi68

man kann auch mit on-for-timer ausschalten - so als workaround wenn es funktioniert
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

UweUwe

Hi Wuooi68, danke für den gutgemeinten Tip, aktuell geht aber an dem Aktor weder Ein- noch Ausschalten.