Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)
Moderatoren: jmaus, Co-Administratoren
-
Xel66
- Beiträge: 14086
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 581 Mal
- Danksagung erhalten: 1492 Mal
Beitrag
von Xel66 » 27.11.2021, 09:37
juwo1811 hat geschrieben: ↑27.11.2021, 09:21
..., eine hochwertige SD Karte ist auch ein guter Tipp!
Eine Max-Endurance ist eine gute Empfehlung.
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
Stefan0815
- Beiträge: 169
- Registriert: 16.04.2019, 15:15
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 10 Mal
Beitrag
von Stefan0815 » 27.11.2021, 19:46
Ich habe tatsächlich ein Problem mit dem neuen Feature:
- added new service message for `HmIP-WRCD` informing about a too high wake-on-radio usage.
Dieses löst Service Meldungen aus (gelbes Blinksignal), die aber nicht im WebUI zu sehen sind, sondern nur unter DevConfig. Hat eine Weile gedauert, bis ich darauf gekommen bin.
Ab wann reden wir denn von einer "too high wake-on-radio usage"? Ich aktualisiere das Display bisher maximal alle 12 Minuten. Bisher immer ohne Probleme. Jetzt gibt es dieses unschöne gelbe Blinken ohne Meldung in der WebUI.
Viele Grüße, Stefan
Viele Grüße
Stefan
-
Bernd-Joras
- Beiträge: 730
- Registriert: 26.03.2016, 09:33
- Hat sich bedankt: 34 Mal
- Danksagung erhalten: 40 Mal
Beitrag
von Bernd-Joras » 27.11.2021, 21:09
Hallo und nur zur Information … bei mir auch !
Ist jetzt bei mir schon zwei mal passiert seit dem ich mit der 3.61.5.20211113 unterwegs bin ….
Nach ca. 3-4 Tagen wollen meine HM-Sec-SCo nicht mehr mit der CCU reden …
Wenn zu einem GW zugeordnet ist alles OK … wieder zur CCU habe ich keine Kommunikation mehr.
Betrifft jetzt beide meiner HM-Sec-SCo Kontakte.
Wenn ich die CCU neu starte ist erstmal wieder alles OK …
Habe jetzt mal Testweise einen dritten neuen HM-Sec-SCo neben die CCU (5m) gelegt.
Mal abwarten was in zwei Tagen zu sehen … oder auch nicht ist …. Melde mich dann wieder …
BG, Bernd
Nachtrag ... ja der DC steigt dann natürlich auch bei mir ... von ca. 5-8 auf 13-18 ... nicht dramatisch ...
2 Standorte mit je RPi3B+ RaspberryMatic 3.73.9.20240130 / RPI-RF-MOD | Externe USB-Platinen Antenne | 2x LAN_RF_GW | 1x LAN_RS485_GW | ca. 170 Geräte davon 35x IP | ca. 250 Programme |>600 Kanäle | Addons: CUX-Daemon, XML-API, hm_pdetect, E-Mail, CCU-Historian
-
Thomas.Weinreich
- Beiträge: 67
- Registriert: 06.10.2014, 07:18
- System: CCU
- Wohnort: Seevetal
- Hat sich bedankt: 10 Mal
- Danksagung erhalten: 4 Mal
Beitrag
von Thomas.Weinreich » 28.11.2021, 16:53
Bernd-Joras hat geschrieben: ↑27.11.2021, 21:09
Hallo und nur zur Information … bei mir auch !
...
Nach ca. 3-4 Tagen wollen meine HM-Sec-SCo nicht mehr mit der CCU reden …
...
Betrifft jetzt beide meiner HM-Sec-SCo Kontakte.
...
Habe jetzt mal Testweise einen dritten neuen HM-Sec-SCo neben die CCU (5m) gelegt.
Mal abwarten was in zwei Tagen zu sehen … oder auch nicht ist …. Melde mich dann wieder …
BG, Bernd
Hallo Bernd,
ich habe zwar inzwischen einen Downgrade gemacht kann aber zur 3.61.5. vor dem Downgrad noch folgendes sagen. Bei mir haben sich die SCo schneller, so innerhalb eines Tages abgemeldet.
Zu Deiner aktuellen Testphase: Ich habe 2 SCo's mit 1,5 m und 2,5 m Entfernung quasi direkt neben der CCU sitzen, aber die sind leider auch (ohne LAN-GW Anbindung) mit der 3.61.5 ausgestiegen...
Grüße
Thomas
-
roe1974
- Beiträge: 746
- Registriert: 17.10.2017, 16:15
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Wien
- Hat sich bedankt: 52 Mal
- Danksagung erhalten: 13 Mal
Beitrag
von roe1974 » 29.11.2021, 08:07
Hallo zusammen
Ich hatte auch kurz nach dem Update auf die 3.61.5 das Problem, dass alle HM-Sec-SCo (13 Stk. insgesamt) nicht mehr mit der CCU kommunizieren wollten (Bei Zustandsveränderung leuchtete die LED immer rot statt grün). Habe dann die CCU einmal durchgestartet, seit dem (14 Tage her) funktionieren die Sensoren allerdings ohne Probleme. Was ich jedoch auch festelle, dass bei vielen Zustandsveränderungen der HM-Sec-SCo in kurzer Zeit der DC relativ schnell ansteigt....
lg Richard
-
jp112sdl
- Beiträge: 12085
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 2139 Mal
-
Kontaktdaten:
Beitrag
von jp112sdl » 29.11.2021, 08:38
Nur mal eine kurze Zwischenmeldung von mir:
12 HM-Sec-SCo laufen auch nach dem Update auf 3.61.5.20211113 vor 2 Wochen problemlos weiter.
Bernd-Joras hat geschrieben: ↑27.11.2021, 21:09
Wenn zu einem GW zugeordnet ist alles OK … wieder zur CCU habe ich keine Kommunikation mehr.
Welche Firmware hattest du vor dem Update auf 3.61 zu laufen?
-
jmaus
- Beiträge: 9820
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 459 Mal
- Danksagung erhalten: 1857 Mal
-
Kontaktdaten:
Beitrag
von jmaus » 29.11.2021, 09:20
jp112sdl hat geschrieben: ↑29.11.2021, 08:38
Nur mal eine kurze Zwischenmeldung von mir:
12 HM-Sec-SCo laufen auch nach dem Update auf 3.61.5.20211113 vor 2 Wochen problemlos weiter.
Auch hier laufen ein Haufen HM-Sec-SCo ohne jegliche Probleme auf einer 3.61.5.20211113. Insofern wüsste ich nicht inwieweit hier wirklich ein allgemeines Problem existiert.
-
virgin
- Beiträge: 636
- Registriert: 09.01.2013, 18:36
- Wohnort: Leichlingen
- Hat sich bedankt: 124 Mal
- Danksagung erhalten: 5 Mal
-
Kontaktdaten:
Beitrag
von virgin » 29.11.2021, 09:32
Das hatte ich jetzt erstmals nach diesem Update: alle drei FLGW fallen auf einmal aus und verbinden sich dann automatisch neu. Der watchdog meldet das. Hier mal das zugehörige Syslog
Code: Alles auswählen
Nov 28 23:24:48 homematic-ccu2 user.err rfd: LGWPortWrapper::keepAliveThreadFunction(): Did not receive reply on keepalive.
Nov 28 23:24:48 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Nov 28 23:24:51 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Nov 28 23:25:00 homematic-ccu2 user.err rfd: (CCU2GWBUEG) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:00 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:00 homematic-ccu2 user.err rfd: (CCU2GWKell) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:00 homematic-ccu2 user.err watchdog: DutyCycle-CCU2GWBUEG, NAME: 'FLGW_Buegel', TYPE: HMLGW2, CONNECTED: 0, DC: -1 %, CS: -1 %
Nov 28 23:25:00 homematic-ccu2 user.err watchdog: DutyCycle-CCU2GWGARA, NAME: 'FLGW_GarageNEU', TYPE: HMLGW2, CONNECTED: 0, DC: -1 %, CS: -1 %
Nov 28 23:25:00 homematic-ccu2 user.err watchdog: DutyCycle-CCU2GWKell, NAME: 'FLGW_Keller', TYPE: HMLGW2, CONNECTED: 0, DC: -1 %, CS: -1 %
Nov 28 23:25:13 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"hm-rpc.0","JEQ0057851:1","VALVE_STATE",0}]}) on http://192.168.0.67:2001/RPC2:
Nov 28 23:25:13 homematic-ccu2 user.err rfd: XmlRpc transport error
Nov 28 23:25:14 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:15 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:16 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:16 homematic-ccu2 user.err rfd: (CCU2GWKell) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:17 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:18 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:18 homematic-ccu2 user.err rfd: (CCU2GWKell) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:18 homematic-ccu2 user.err rfd: (CCU2GWBUEG) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:18 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:19 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:20 homematic-ccu2 user.err rfd: (CCU2GWBUEG) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:20 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:20 homematic-ccu2 user.err rfd: (CCU2GWBUEG) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:20 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:21 homematic-ccu2 user.err rfd: (CCU2GWBUEG) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:21 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:21 homematic-ccu2 user.err rfd: (CCU2GWKell) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:21 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:25:22 homematic-ccu2 user.err rfd: UnifiedLanCommController::connect(): Could not connect.
Nov 28 23:25:25 homematic-ccu2 user.err rfd: (CCU2GWBUEG) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Nov 28 23:26:01 homematic-ccu2 user.err rfd: (CCU2GWGARA) CCU2CommController::getDutyCycle(): Could not get DutyCycle from coprocessor.
Bernd
-
Bernd-Joras
- Beiträge: 730
- Registriert: 26.03.2016, 09:33
- Hat sich bedankt: 34 Mal
- Danksagung erhalten: 40 Mal
Beitrag
von Bernd-Joras » 29.11.2021, 10:09
jp112sdl hat geschrieben: ↑29.11.2021, 08:38
Nur mal eine kurze Zwischenmeldung von mir:
12 HM-Sec-SCo laufen auch nach dem Update auf 3.61.5.20211113 vor 2 Wochen problemlos weiter.
Bernd-Joras hat geschrieben: ↑27.11.2021, 21:09
Wenn zu einem GW zugeordnet ist alles OK … wieder zur CCU habe ich keine Kommunikation mehr.
Welche Firmware hattest du vor dem Update auf 3.61 zu laufen?
Ich gehe da immer mit ... lasse eher keine Version aus ... somit die Vorgängerversion ... 3.59.6.20211009
An der Stelle auch nochmal kurz erwähnt … Das meine HM-Sec-SCo nun nicht mehr mit der CCU reden wollten kann auch schon vorher (FW Vorversion) so gewesen sein …. Ich bastel ziemlich viel rum und somit restarte ich die CCU auch schon mal alle 1-5 Tage …. Da muss das dann nicht unbedingt auffallen das der HM-Sec-SCo ggf. gerade nicht funktioniert. Ich warte nun mal ab und teste täglich 2 Kontakte im Programm integriert und einer nur an der CCU angemeldet rumliegend … BG.Bernd
2 Standorte mit je RPi3B+ RaspberryMatic 3.73.9.20240130 / RPI-RF-MOD | Externe USB-Platinen Antenne | 2x LAN_RF_GW | 1x LAN_RS485_GW | ca. 170 Geräte davon 35x IP | ca. 250 Programme |>600 Kanäle | Addons: CUX-Daemon, XML-API, hm_pdetect, E-Mail, CCU-Historian
-
Xel66
- Beiträge: 14086
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 581 Mal
- Danksagung erhalten: 1492 Mal
Beitrag
von Xel66 » 29.11.2021, 12:25
Ich habe auch so einige HM-Sec-SCo bei mir im System (alle Fenster damit ausgestattet) und fahre darüber sowohl eine direktverknüpfte Einbruchsmeldefunktion mit einer klassischen Innensirene sowie direktverknüpfte (Thermostate) sowie programmierte Heizungssteuerung (und andere Programme). Eine nicht funktionierende Statusübermittlung wäre mir definitiv aufgefallen. Euer "Problem" muss also eine recht individuelle Ursache haben. Wäre es ein Grundproblem in der Firmware, müssten viel mehr Anwender darüber klagen. Nun bekommt aber nicht jeder das mit (insbesondere nicht Anwender, die wenig automatisiert haben und ein Smartphonehome betreiben). Aber bei mir passen alle Zeitstempel, so dass ich davon ausgehe, dass die TFK ihren Status ordnungsgemäß an die CCU senden können.
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch