HMUARTLGW - inaktiv setzen durch dummy funktioniert nicht mehr

Otto123 · 24 Januar 2019, 09:49:24

Hallo,

gestern nach update bemerkt: Ich kann definitionen mit dem Modul HMUARTLGW (uart://) nicht mehr mit attr dummy 1 inaktiv setzen. Er versucht ständig Verbindungen aufzubauen. Erst ein set close bringt Ruhe.

Das hat "bis Letztens" funktioniert.

Edit: Ich bin jetzt bis zum November zurück gegangen, funktioniert auch nicht. Komisch, ich habe das doch schon verwendet?

Gruß Otto

frank · 24 Januar 2019, 11:08:10

was willst du denn genau erreichen?
was bedeutet genau inaktiv/ruhe?

Otto123 · 24 Januar 2019, 11:24:37

Na das Netzwerk Gerät ist mal eine Weile "nicht da". Ich habe es an einer anderen FHEM Instanz aktiv.
Mit close kann ich es schließen, das übersteht den restart nicht. Mit dummy kann ich das Gerät eigentlich restart fest aus dem Rennen nehmen. Es rennt aber weiter

frank · 24 Januar 2019, 11:58:08

das modul hmuartlgw wurde feb/2018 letztmalig geändert. dort ist auch ein handling von attr dummy eingebaut, habe ich gesehen.

funktioniert es vielleicht, wenn du erst set close und anschliessend attr dummy setzt?

Otto123 · 24 Januar 2019, 15:16:30

Ja die Änderung FEB habe ich gesehen. Ich dachte ich hätte es seit dem auch schon verwendet.
Es funktioniert im Zusammenhang mit close, aber nach dem Neustart versucht er wieder zu verbinden.
Ich bau mir jetzt ein notify

- aber der Sinn war das ja nicht.

Ich forsche mal noch in meinen anderen Instanzen.

mgernoth · 24 Januar 2019, 17:15:32

Hi,

Zitat von: Otto123 am 24 Januar 2019, 15:16:30
Es funktioniert im Zusammenhang mit close, aber nach dem Neustart versucht er wieder zu verbinden.

hmm, sollte es nicht tun. Ich schaue es mir am Wochenende an (wenn ich drandenke...).

Viele Grüße
Michael

Otto123 · 26 Januar 2019, 14:19:03

Hallo Michael,

ich habe eine zweite Instanz, da funktioniert das wie gewollt. Da werde ich mal noch in die Tiefen abtauchen müssen - was da jetzt genau die Unterschiede sind.
Eigentlich ist alles gleich, der Typ vorm Bildschirm

, die Definitionen, die beteiligten Geräte (bis auf die beiden Raspberrys).

Die Versionsstände von FHEM und der der Umfang der FHEM Installation sind unterschiedlich.

Die Version vom eigentlichen Modul ist aber auch gleich:
00_HMUARTLGW.pm 16166 2018-02-13 19:52:08Z mgernoth

Ich melde mich, sobald ich mehr weiß.

Gruß Otto

Otto123 · 10 Februar 2019, 02:56:35

Hallo Michael,

ich habe jetzt noch mal die Sache getestet und das Problem reproduzierbar gemacht:
Bei einem lokal an der UART installiertem HMUARTLGW funktioniert attr dummy wie gewünscht.
Bei einem remote angebundenem Modul ist es anders, man kann zwei Fälle unterschieden:

Das Modul ist erreichbar und frei verfügbar (nicht durch einen anderen Connect belegt): attr dummy funktioniert wie gewünscht
Ist das Modul nicht erreichbar (oder schon durch einen anderen Connect belegt): attr dummy nicht wie gewünscht.

Startet man das System neu, wirkt attr dummy gar nicht.

Ein HMLAN zeigt übrigens diese Verhalten nicht, ein Logfile bleibt leer

Code Auswählen

Internals:
   DEF        192.168.56.66:1000
   DeviceName 192.168.56.66:1000
   FUUID      5c5f294f-f33f-520c-addc-53ed25b54beb8c74
   NAME       HMLAN1
   NR         22
   NTFY_ORDER 50-HMLAN1
   STATE      disconnected
   TYPE       HMLAN
   XmitOpen   0
   assignedIDsCnt 0
   msgKeepAlive 
   msgLoadCurrent 0
   owner      
   owner_CCU  VCCU
   READINGS:
     2019-02-10 02:10:12   D-HMIdAssigned  200DB8
     2019-02-10 02:10:12   D-HMIdOriginal  26EACE
     2019-02-10 02:10:12   D-firmware      0.965
     2019-02-10 02:10:12   D-serialNr      LEQ0102164
     2019-02-10 02:26:49   Xmit-Events     dummy:1 disconnected:1 
     2019-02-10 02:26:49   cond            dummy
     2019-02-10 02:24:59   loadLvl         low
     2016-09-03 12:25:12   prot_ERROR-Overload last
     2016-09-03 12:30:10   prot_Warning-HighLoad last
     2019-02-10 02:26:49   prot_disconnected last
     2019-02-10 02:26:49   prot_dummy      last
     2019-02-10 02:19:09   prot_init       last
     2018-08-07 14:13:18   prot_keepAlive  last
     2019-02-10 02:19:09   prot_ok         last
     2017-02-22 06:59:02   prot_timeout    last
     2019-02-10 02:26:49   state           disconnected
   helper:
     assIdCnt   0
     assIdRep   0
     cnd:
       251        1
       253        1
     k:
       BufMin     30
       DlyMax     0
       Start      0
     loadLvl:
       bl         40
       a:
         99
         90
         40
         0
       h:
         0          low
         40         batchLevel
         90         high
         99         suspended
     log:
       all        0
       sys        0
       ids:
         ARRAY(0x1148cf8)
     q:
       HMcndN     251
       answerPend 0
       hmLanQlen  1
       loadLastMax 0
       loadNo     0
       scnt       0
       ald:
         0
         0
         0
         0
         0
         0
         0
         0
         0
         0
         0
         0
       apIDs:
Attributes:
   dummy      1
   hmId       200DB8
   hmLanQlen  1_min
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   room       Haus
   wdTimer    25

Der per LAN angebundene HMUARTLGW schreibt sein Log voll:

Code Auswählen

2019-02-10_02:28:29 ser2netUart cond: disconnected
2019-02-10_02:28:29 ser2netUart CONNECTED
2019-02-10_02:28:29 ser2netUart DISCONNECTED
2019-02-10_02:28:30 ser2netUart cond: init
2019-02-10_02:28:34 ser2netUart cond: disconnected
2019-02-10_02:28:34 ser2netUart CONNECTED
2019-02-10_02:28:34 ser2netUart DISCONNECTED
2019-02-10_02:28:35 ser2netUart cond: init
2019-02-10_02:28:41 ser2netUart cond: disconnected
2019-02-10_02:28:44 ser2netUart CONNECTED
2019-02-10_02:28:44 ser2netUart DISCONNECTED

Code Auswählen

Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://raspirpi:4000
   DevIoJustClosed 1
   DevState   1
   DevType    UART
   DeviceName raspirpi:4000
   FUUID      5c5f2959-f33f-520c-0120-5c0941b32ba49d05
   LastOpen   1549762419.85746
   NAME       ser2netUart
   NR         619
   STATE      disconnected
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     1
         time       1549762420.86255
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2019-02-09 20:26:41   D-HMIdAssigned  200DB8
     2019-02-09 20:26:41   D-HMIdOriginal  4706E9
     2019-02-09 20:26:41   D-firmware      1.4.1
     2019-02-09 20:26:41   D-serialNr      NEQ0230356
     2019-02-10 02:26:59   D-type          HM-MOD-UART
     2019-02-10 02:33:40   cond            init
     2019-02-09 23:24:35   load            1
     2019-02-10 02:26:59   loadLvl         suspended
     2019-02-10 02:33:39   state           disconnected
Attributes:
   dummy      1
   hmId       200DB8
   room       Haus,Test

Ich habe ca 02:35:27 das Modul im Netz wieder verfügbar gemacht und anschließend FHEM neu gestartet. Trotz attr dummy wird das Modul normal verbunden.

Code Auswählen

2019-02-10_02:35:15 ser2netUart DISCONNECTED
2019-02-10_02:35:16 ser2netUart cond: init
2019-02-10_02:35:22 ser2netUart cond: disconnected
2019-02-10_02:35:24 ser2netUart CONNECTED
2019-02-10_02:35:25 ser2netUart cond: init
2019-02-10_02:35:27 ser2netUart D-HMIdAssigned: 200DB8
2019-02-10_02:35:27 ser2netUart D-HMIdOriginal: 4706E9
2019-02-10_02:35:27 ser2netUart D-firmware: 1.4.1
2019-02-10_02:35:27 ser2netUart D-serialNr: NEQ0230356
2019-02-10_02:35:27 ser2netUart cond: ok
2019-02-10_02:35:27 ser2netUart loadLvl: low
2019-02-10_02:37:42 ser2netUart cond: init
2019-02-10_02:37:44 ser2netUart D-HMIdAssigned: 200DB8
2019-02-10_02:37:44 ser2netUart D-HMIdOriginal: 4706E9
2019-02-10_02:37:44 ser2netUart D-firmware: 1.4.1
2019-02-10_02:37:44 ser2netUart D-serialNr: NEQ0230356
2019-02-10_02:37:44 ser2netUart cond: ok
2019-02-10_02:37:44 ser2netUart loadLvl: low

Ich weiß nicht ob es mir gelungen ist alles klar zu beschreiben?

Gruß Otto

Otto123 · 10 Februar 2019, 20:04:25

Hallo Michael,

mir ist noch etwas aufgefallen, als ich heute ein notify als Würgaround für mich gebastelt habe.
Den folgenden Ablauf habe ich mehrfach reproduziert.

Der Ausgangszustand des Devices ist so:

Code Auswählen

Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://raspirpi:4000
   DevIoJustClosed 1
   DevState   0
   DevType    UART
   DeviceName raspirpi:4000
   FUUID      5c4c566f-f33f-27f7-ef3e-41b70040f788df11
   LastOpen   1549824830.10671
   NAME       ser2netUart
   NR         89
   RAWMSG     0500003C1F847032266700000000D836
   RSSI       -60
   STATE      closed
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         time       1549824831.11864
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
   READINGS:
     2019-02-10 02:20:56   D-HMIdAssigned  200DB8
     2019-02-10 02:20:56   D-HMIdOriginal  4706E9
     2019-02-10 02:20:56   D-firmware      1.4.1
     2019-02-10 02:20:56   D-serialNr      NEQ0230356
     2019-02-10 02:20:36   D-type          HM-MOD-UART
     2019-02-10 19:53:51   cond            disconnected
     2019-02-10 02:35:24   load            1
     2019-02-10 02:35:24   loadLvl         suspended
     2019-02-10 19:55:20   state           closed
   helper:
Attributes:
   dummy      1
   hmId       200DB8
   room       IO,Test
   verbose    5

Dann setze ich ein set open ab, dabei passiert irgendwie sichtbar nichts (im Log der Zeitpunkt 19:43:17)
Dann setze ich ein zweites set open ab, dann fängt das Device an zu öffnen (im Log der Zeitpunkt 19:44:10) und würde ständig versuchen zu verbinden. Mein notify schlägt aber sofort zu.
Das Log

Code Auswählen

2019.02.10 19:43:17 3: Opening ser2netUart device raspirpi:4000
2019.02.10 19:43:17 3: ser2netUart device opened
2019.02.10 19:43:17 1: raspirpi:4000 disconnected, waiting to reappear (ser2netUart)
2019.02.10 19:43:17 3: ser2netUart device closed
2019.02.10 19:44:10 3: Opening ser2netUart device raspirpi:4000
2019.02.10 19:44:10 5: HttpUtils url=http://raspirpi:4000/
2019.02.10 19:44:10 4: IP: raspirpi -> 192.168.56.219
2019.02.10 19:44:11 3: ser2netUart device opened
2019.02.10 19:44:11 5: HMUARTLGW ser2netUart read raw (21): 506f727420616c726561647920696e207573650a0d
2019.02.10 19:44:11 1: raspirpi:4000 disconnected, waiting to reappear (ser2netUart)
2019.02.10 19:44:11 3: ser2netUart device closed

Wenn das attr dummy nicht gesetzt ist, hat man diesen Effekt nicht. Das erste open wirkt sofort. Siehe Log

Code Auswählen

2019.02.10 19:53:36 5: HMUARTLGW ser2netUart Attr del dummy 
2019.02.10 19:53:44 3: Opening ser2netUart device raspirpi:4000
2019.02.10 19:53:44 5: HttpUtils url=http://raspirpi:4000/
2019.02.10 19:53:44 4: IP: raspirpi -> 192.168.56.219
2019.02.10 19:53:44 3: ser2netUart device opened
2019.02.10 19:53:44 5: HMUARTLGW ser2netUart read raw (21): 506f727420616c726561647920696e207573650a0d
2019.02.10 19:53:44 1: raspirpi:4000 disconnected, waiting to reappear (ser2netUart)
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:44 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:45 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:45 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:45 4: HMUARTLGW ser2netUart StartInit
2019.02.10 19:53:45 5: HMUARTLGW ser2netUart send: 00 00
2019.02.10 19:53:45 5: HMUARTLGW ser2netUart send: (8): fd00030001009e03
2019.02.10 19:53:45 5: SW: fd00030001009e03
2019.02.10 19:53:45 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:46 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:47 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:48 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:48 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:48 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:48 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:48 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:48 1: HMUARTLGW ser2netUart did not respond for the 1. time, resending
2019.02.10 19:53:48 5: HMUARTLGW ser2netUart send: (8): fd00030001009e03
2019.02.10 19:53:48 5: SW: fd00030001009e03
2019.02.10 19:53:49 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart Reopen
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart Reopen
2019.02.10 19:53:50 5: HttpUtils url=http://raspirpi:4000/
2019.02.10 19:53:50 4: IP: raspirpi -> 192.168.56.219
2019.02.10 19:53:50 1: raspirpi:4000 reappeared (ser2netUart)
2019.02.10 19:53:50 5: HMUARTLGW ser2netUart read raw (21): 506f727420616c726561647920696e207573650a0d
2019.02.10 19:53:50 1: raspirpi:4000 disconnected, waiting to reappear (ser2netUart)
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:50 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:51 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:51 4: HMUARTLGW ser2netUart ready: disconnected
2019.02.10 19:53:51 4: HMUARTLGW ser2netUart StartInit
2019.02.10 19:53:51 5: HMUARTLGW ser2netUart send: 00 00
2019.02.10 19:53:51 5: HMUARTLGW ser2netUart send: (8): fd00030001009e03
2019.02.10 19:53:51 5: SW: fd00030001009e03
2019.02.10 19:53:51 3: ser2netUart device closed

Nur zur Info, mein Notify

Code Auswählen

defmod ser2netUart_notify_1 notify myHmUARTLGW|ser2netUart:DISCONNECTED {fhem("set $NAME close") if (AttrNum($NAME,"dummy",0) == 1)}

Gruß Otto

mgernoth · 06 März 2019, 19:42:49

Hallo Otto,

habe da jetzt etwas mehr umgebaut und das Modul aus dem Anhang bei mir schon ein paar Tage ohne Probleme in Betrieb. Schau bitte mal, ob es bei Dir auch funktioniert und auch alle Dummy-Fälle abfängt (hat bei mir in Tests funktioniert).

Im Gegensatz zu HMLAN macht HMUARTLGW einen Nonblocking Connect, welcher zu dem Problem geführt hat.

Viele Grüße
Michael

Otto123 · 06 März 2019, 20:15:01

Hallo Michael,

sieht auf die Schnelle getestet gut aus

Danke.
So sieht ein list aus:

Code Auswählen

Internals:
   Clients    :CUL_HM:
   DEF        uart://raspirpi:4000
   DevState   0
   DevType    UART
   DeviceName raspirpi:4000
   FUUID      5c4c566f-f33f-27f7-ef3e-41b70040f788df11
   NAME       ser2netUart
   NOTIFYDEV  global
   NR         89
   NTFY_ORDER 50-ser2netUart
   STATE      dummy
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   Helper:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2019-03-05 21:05:36   D-HMIdAssigned  200DB8
     2019-03-05 21:05:36   D-HMIdOriginal  4706E9
     2019-03-05 21:05:36   D-firmware      1.4.1
     2019-03-05 21:05:36   D-serialNr      NEQ0230356
     2019-03-06 20:12:21   D-type          HM-MOD-UART
     2019-03-06 20:12:21   cond            disconnected
     2019-03-05 23:44:56   load            0
     2019-03-06 20:12:21   loadLvl         suspended
     2019-03-06 20:12:30   state           dummy
Attributes:
   dummy      1
   hmId       200DB8
   room       IO,Test

Was irgendwie lustig aussieht: beim HMLAN ist cond dummy und state disconnected, beim HMUARTLGW umgekehrt.

Gruß Otto