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. :o
Edit: Ich bin jetzt bis zum November zurück gegangen, funktioniert auch nicht. Komisch, ich habe das doch schon verwendet?
Gruß Otto
was willst du denn genau erreichen?
was bedeutet genau inaktiv/ruhe?
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 :(
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?
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 ;D - aber der Sinn war das ja nicht.
Ich forsche mal noch in meinen anderen Instanzen.
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
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
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
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:
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
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.
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
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:
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
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
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
defmod ser2netUart_notify_1 notify myHmUARTLGW|ser2netUart:DISCONNECTED {fhem("set $NAME close") if (AttrNum($NAME,"dummy",0) == 1)}
Gruß Otto
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
Hallo Michael,
sieht auf die Schnelle getestet gut aus :)
Danke.
So sieht ein list aus:
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