Aktueller Status nur nach get Update

joachimm · 04 Oktober 2017, 11:52:05

Hallo,

ich habe mit HMCCUDEV ein ein neues Device angelegt. Änderungen im STATE werden nur nach get <device> update angezeigt (Entweder auf dem HMCCUDEV oder HMCCU). Ich finde das einfach nicht...

Vielen Dank
Joachim

Barit · 04 Oktober 2017, 15:24:53

Was für ein Device hast du neu denn neu angelegt hast und welches Protokoll verwendet es (BidCos-RF, HmIP-RF, etc.)?
Vielleicht hilft auch schon dieser Thread weiter:
https://forum.fhem.de/index.php/topic,40189.msg641541.html#msg641541

Die Suchfunktion des Forums hilft ggf. auch.

zap · 04 Oktober 2017, 16:39:48

Das passende Protokoll muss aktiviert und der RPC Server gestartet sein

joachimm · 05 Oktober 2017, 10:05:27

Vielen Dank,

das habe ich gemacht. Das geht ja auch eine Zeit lang... Dann nur noch mit "get update". Würde Ihr bitte mal einen Blick darauf werfen? Eigentlich habe ich alles nach "Best Practice" gemacht.... denke ich zumindest.
Das Device schaltet aber einwandfrei....
Stoppe und starte ich den RPC... geht das wieder für eine Zeit (10min) einwandfrei...

edit: habe auch den internen RPC probiert. Das gleiche Phänomen.

CCU

Code Auswählen

define d_ccu HMCCU 10.1.1.27
attr d_ccu ccuflags extrpc
attr d_ccu cmdIcon on:general_an off:general_aus
attr d_ccu eventMap /rpcserver on:on/rpcserver off:off/
attr d_ccu rpcinterfaces BidCos-RF
attr d_ccu rpcport 2001
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

#RPC
define d_ccu_rpc HMCCURPC 10.1.1.27
attr d_ccu_rpc stateFormat rpcstate/state
attr d_ccu_rpc verbose 2

Steckdosenschalter

Code Auswählen


define HM_TV HMCCUDEV TV
attr HM_TV IODev d_ccu
attr HM_TV ccureadingfilter (STATE|LOWBAT|ON_TIME)
attr HM_TV ccureadings 1
attr HM_TV devStateIcon on:10px-kreis-gruen off:10px-kreis-rot Initialized:10px-kreis-gelb
attr HM_TV event-on-change-reading .*
attr HM_TV statechannel 1
attr HM_TV statevals on:true,off:false
attr HM_TV substitute STATE!true:on,false:off,1:on,0:off

zap · 05 Oktober 2017, 12:42:08

Wenn die Aktualisierung nach 10 Minuten ausbleibt: was steht dann im FHEM Log? Irgendwelche Meldungen von HMCCU oder HMCCURPC?

Ich vermute, dass die Netzwerkverbindung zur CCU abbricht. Benutzt Du WLAN?

joachimm · 05 Oktober 2017, 19:30:12

Nein, die CCU ist am LAN und verliert auch nicht die Connectivität. Und die Funkttion ist ja gegeben. Er aktualisiert nur nicht. Bin echt ratlos...

zap · 05 Oktober 2017, 19:38:36

Ohne Fehlermeldung im FHEM Log?
FHEM ist auch im LAN und nicht im WLAN?

joachimm · 05 Oktober 2017, 19:43:38

Code Auswählen


17.10.05 19:16:03.997 2: HMCCU: Received no events from interface CB2001 for 600 seconds
2017.10.05 19:16:44.277 4: CUL_Parse: CUL_0 H007600595173F6 -79
2017.10.05 19:24:45.147 4: CUL_Parse: CUL_0 K01873083EA -85
2017.10.05 19:26:03.186 2: HMCCU: Received no events from interface CB2001 for 600 seconds
2017.10.05 19:28:30.010 4: CUL_Parse: CUL_0 K715581580C -68
2017.10.05 19:33:36.181 4: CUL_Parse: CUL_0 K01863083F6 -79
2017.10.05 19:36:33.193 4: CUL_Parse: CUL_0 K01863083E0 -90
2017.10.05 19:37:36.330 4: CUL_Parse: CUL_0 H007600595173F8 -78

Nein, keine Fehler zu sehen. CCU ist im LAN. Schalten tut es ja...

zap · 06 Oktober 2017, 08:16:12

Entweder du hast nur wenige Geräte angemeldet und deshalb gibt es für 10 Minuten kein Event. Oder die CCU vergisst aus welchen Gründen auch immer FHEM als Abnehmer der Events.

Du kannst mal prüfen, ob in /var/log/messages auf der CCU irgendwelche Fehlermeldungen stehen.

Wenn der Fall eintritt: startest du dann nur den RPC Server neu oder auch die CCU?

joachimm · 06 Oktober 2017, 10:16:08

Ich danke schon mal für die Hilfe. In /var/log/messages sind keine Einträge. Um wieder in Funktion zu gehen starte ich einfach den RPC neu. Dann gehts wieder für 5min...

Ich setze mal auf einem anderen Raspi das System neu auf. Mal sehen was dann ist...

Danke
Joachim

joachimm · 09 Oktober 2017, 14:31:07

Hallo,

muss ich noch mal aufgreifen. Ich habe ein neues System aufgesetzt. Funktioniert auch nicht. Nach genau 10min. keine Aktualisierung. Meine CCU ist auf einem anderen Raspberry installiert (Raspimatic). Kann es daran liegen? Würde mich aber wundern, denn der läuft besser als org. CCU2

Danke
Joachim

zap · 09 Oktober 2017, 16:31:31

Welche (Typ) und wie viele Homematic Geräte hast Du in FHEM definiert?

joachimm · 09 Oktober 2017, 16:59:33

Hallo,

3x HM-CC-RT-DN
1x HM-LC-Sw1-Pl-2

das mit den genau 10min stimmt doch nicht so. Jetzt gings mal für 15min. Wenn ich den RPC neu starte ist wieder alles gut. Da muss doch bei mir irgendwas anders sein....*verzweifel*

joachimm · 09 Oktober 2017, 17:38:06

Habe noch mal die Kommunikation mit tshark getraced..

Ab Zeile 593 funktioniert es nicht mehr. Hier stellt der RPC seinen Dienst ein...

Code Auswählen


 562 350.034355202    10.1.1.40 → 10.1.1.27    TCP 83 [TCP segment of a reassembled PDU]
  563 350.035212071    10.1.1.27 → 10.1.1.40    TCP 66 41418 → 7411 [ACK] Seq=539 Ack=18 Win=29312 Len=0 TSval=10853574 TSecr=641175
  564 350.035283164    10.1.1.40 → 10.1.1.27    HTTP/XML 776 HTTP/1.1 200 OK
  565 350.036085971    10.1.1.27 → 10.1.1.40    TCP 66 41418 → 7411 [ACK] Seq=539 Ack=728 Win=30720 Len=0 TSval=10853574 TSecr=641175
  566 350.036816071    10.1.1.27 → 10.1.1.40    HTTP/XML 604 POST /fh2001 HTTP/1.1
  567 350.044478780    10.1.1.40 → 10.1.1.27    TCP 83 [TCP segment of a reassembled PDU]
  568 350.091320866    10.1.1.27 → 10.1.1.40    TCP 66 41418 → 7411 [ACK] Seq=1077 Ack=745 Win=30720 Len=0 TSval=10853580 TSecr=641176
  569 350.091393313    10.1.1.40 → 10.1.1.27    HTTP/XML 776 HTTP/1.1 200 OK
  570 350.092127892    10.1.1.27 → 10.1.1.40    TCP 66 41418 → 7411 [ACK] Seq=1077 Ack=1455 Win=32128 Len=0 TSval=10853580 TSecr=641181
  571 360.055683579    10.1.1.40 → 10.1.1.27    TCP 66 7411 → 41418 [FIN, ACK] Seq=1455 Ack=1077 Win=31232 Len=0 TSval=642177 TSecr=10853580
  572 360.101341455    10.1.1.27 → 10.1.1.40    TCP 66 41418 → 7411 [ACK] Seq=1077 Ack=1456 Win=32128 Len=0 TSval=10854581 TSecr=642177
  573 365.025497154    10.1.1.27 → 10.1.1.40    HTTP/XML 604 POST /fh2001 HTTP/1.1
  574 365.025579914    10.1.1.40 → 10.1.1.27    TCP 54 7411 → 41418 [RST] Seq=1456 Win=0 Len=0
  575 365.025500904    10.1.1.27 → 10.1.1.40    TCP 66 41418 → 7411 [FIN, ACK] Seq=1615 Ack=1456 Win=32128 Len=0 TSval=10855073 TSecr=642177
  576 365.025658299    10.1.1.40 → 10.1.1.27    TCP 54 7411 → 41418 [RST] Seq=1456 Win=0 Len=0
  577 365.025502467    10.1.1.27 → 10.1.1.40    TCP 74 41420 → 7411 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=10855073 TSecr=0 WS=128
  578 365.025738298    10.1.1.40 → 10.1.1.27    TCP 74 7411 → 41420 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=642674 TSecr=10855073 WS=128
  579 365.026282982    10.1.1.27 → 10.1.1.40    TCP 66 41420 → 7411 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=10855073 TSecr=642674
  580 365.026490168    10.1.1.27 → 10.1.1.40    HTTP/XML 604 POST /fh2001 HTTP/1.1
  581 365.026530585    10.1.1.40 → 10.1.1.27    TCP 66 7411 → 41420 [ACK] Seq=1 Ack=539 Win=30080 Len=0 TSval=642674 TSecr=10855073
  582 365.035181309    10.1.1.40 → 10.1.1.27    TCP 83 [TCP segment of a reassembled PDU]
  583 365.036023908    10.1.1.27 → 10.1.1.40    TCP 66 41420 → 7411 [ACK] Seq=539 Ack=18 Win=29312 Len=0 TSval=10855074 TSecr=642675
  584 365.036095209    10.1.1.40 → 10.1.1.27    HTTP/XML 776 HTTP/1.1 200 OK
  585 365.036910464    10.1.1.27 → 10.1.1.40    TCP 66 41420 → 7411 [ACK] Seq=539 Ack=728 Win=30720 Len=0 TSval=10855074 TSecr=642675
  586 365.037654574    10.1.1.27 → 10.1.1.40    HTTP/XML 604 POST /fh2001 HTTP/1.1
  587 365.055278885    10.1.1.40 → 10.1.1.27    TCP 83 [TCP segment of a reassembled PDU]
  588 365.101314623    10.1.1.27 → 10.1.1.40    TCP 66 41420 → 7411 [ACK] Seq=1077 Ack=745 Win=30720 Len=0 TSval=10855081 TSecr=642677
  589 365.101405352    10.1.1.40 → 10.1.1.27    HTTP/XML 776 HTTP/1.1 200 OK
  590 365.102154253    10.1.1.27 → 10.1.1.40    TCP 66 41420 → 7411 [ACK] Seq=1077 Ack=1455 Win=32128 Len=0 TSval=10855081 TSecr=642682
  591 367.179217549    10.1.1.27 → 10.1.1.40    TCP 66 41420 → 7411 [FIN, ACK] Seq=1077 Ack=1455 Win=32128 Len=0 TSval=10855288 TSecr=642682
  592 367.179668223    10.1.1.40 → 10.1.1.27    TCP 66 7411 → 41420 [FIN, ACK] Seq=1455 Ack=1078 Win=31232 Len=0 TSval=642890 TSecr=10855288
  593 367.180432020    10.1.1.27 → 10.1.1.40    TCP 66 41420 → 7411 [ACK] Seq=1078 Ack=1456 Win=32128 Len=0 TSval=10855288 TSecr=642890
  594 370.465431647 Synology_3e:ae:dd → Broadcast    ARP 60 Who has 10.1.1.27? Tell 10.1.1.2
  595 400.468406075 Synology_3e:ae:dd → Broadcast    ARP 60 Who has 10.1.1.27? Tell 10.1.1.2
  596 430.478368023 Synology_3e:ae:dd → Broadcast    ARP 60 Who has 10.1.1.27? Tell 10.1.1.2
  597 449.811235979    10.1.1.27 → 224.0.0.22   IGMPv3 60 Membership Report / Join group 239.255.255.250 for any sources
  598 460.477341255 Synology_3e:ae:dd → Broadcast    ARP 60 Who has 10.1.1.27? Tell 10.1.1.2
  599 490.474322022 Synology_3e:ae:dd → Broadcast    ARP 60 Who has 10.1.1.27? Tell 10.1.1.2
  600 520.474311453 Synology_3e:ae:dd → Broadcast    ARP 60 Who has 10.1.1.27? Tell 10.1.1.2
  601 550.484296450 Synology_3e:ae:dd → Broadcast    ARP 60 Who has 10.1.1.27? Tell 10.1.1.2

zap · 09 Oktober 2017, 18:31:54

Ok, die Thermostate müssten auf jeden Fall regelmäßig Events liefern. HMCCU macht nach dem Start des RPC Servers ein globales get update. Ich vermute, das interpretierst Du als funktionierende Kommunikation.

Ich kenne mich mit tshark nicht aus, vermute aber, dass 45994 und 8181 TCP Ports sind. Port 8181 ist der tclrega Port auf der CCU. Darüber werden Homematic Scripts ausgeführt (eben z.B. get update).

RPC-Verkehr (das wären Updates, die von der CCU kommen) verwendet andere Ports.

Bitte poste mal die Logeinträge aus dem FHEM Log vom Start des RPC Servers bis zur ersten Meldung, dass keine Events kommen.