Ccu träge ohne erkennbaren Grund

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Linnet998
Beiträge: 110
Registriert: 04.07.2018, 21:46
Danksagung erhalten: 2 Mal

Re: Ccu träge ohne erkennbaren Grund

Beitrag von Linnet998 » 04.08.2021, 22:18

Linnet998 hat geschrieben:
04.08.2021, 14:17
achja eine weitere Pi mit iobroker ist im haushalt diese habe ich auch ausgeschaltet um fremdzugriffe auszuschließen.
Hatte ich im Anfangspost erwähnt... es hat leider nicht geholfen.

cloudman88
Beiträge: 151
Registriert: 26.10.2020, 11:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 12 Mal
Danksagung erhalten: 22 Mal

Re: Ccu träge ohne erkennbaren Grund

Beitrag von cloudman88 » 05.08.2021, 15:27

Sorry ist ziemlich schwierig die ganzen Infos zu sortieren
Ich versuche es einmal für dich zusammen zu fassen

Mit HM-RPI-RP-PCB => träge
Neues HM-MOD RP-PCB => nicht erkannt (dazu fällt nichts ein :)I

Nach dem du auf HM-RPI-RF-MOD gewechselt hast kannst du den DRAP ansprechen. Den Co-Prozesser Fehler kannst du ignorieren. Das der Fehler angezeigt wird ist ein "kosmetischer" bug in der aktuelle Raspberrymatic Version
==> schon versucht den DRAP neu anzulernen ?

Firmware für RPI-RF-MOD fehlt. Wie hast du das festgestellt?

DC ca. 20% da aber auch Wired betroffen => unwahrscheinlich, dass Funkprobleme die Ursache sind

Es laufen noch einige Add-ons aber die hast du für dich als Ursache ausgeschlossen.

Die Raspberrymatic logs hier posten - könnte auch helfen

Ansonsten würde ich nach dem Ausschlußprinzip vorgehen


Hypothese 1: Funkprobleme
==> dann dürfte HM-IPW nicht betroffen sein

Hypothese 2: Browser verursacht das Problem
==> Mit curl testen

Im Browser http://<ccu ip>/config/xmlapi/statelist.cgi die Geräte auflisten
Im Ergebnis einen Schalterkanal suchen

Code: Alles auswählen

 <channel name="KuecheFensterSchalter:4" ise_id="4126" index="4" visible="true" operate="true">
<...
<datapoint name="HmIP-RF.xyz:4.STATE" type="STATE" ise_id="4132" value="true" valuetype="2" valueunit="" timestamp="1628165037" operations="7"/>
</channel>
 
Jetzt curl aufrufen und den gefunden ise_id Wert verwenden - ist die Verzögerung damit auch noch da?

Licht an:

Code: Alles auswählen

 curl "http://<ccu ip>/addons/xmlapi/statechange.cgi?ise_id=4132&new_value=1"
Licht aus

Code: Alles auswählen

 curl "http://<ccu ip>/addons/xmlapi/statechange.cgi?ise_id=4132&new_value=0"
Wenn die Verzögerung auch mit curl auftritt können wir Browser Probleme auch ad acta legen
Was bleibt dann noch übrig?
- Zugriffe von außen (iobroker) => hast du getestet - keine Änderung
- Problem mit der aktuellen Raspberrymatic Version. Ältere Version installieren und Backup einspielen
- add-ons
- Konfig irgendwie zerschossen

Jetzt kannst du dir aussuchen was du zuerst testen möchtest - alle add-ons deaktivieren oder mit Konfig Troubleshooting beginnen

Wenn es die Konfig ist, könntest du versuchen ob es ein älteres Backup gibt mit dem das Problem nicht reproduzierbar ist
oder
Nachdem du jetzt ein RPI-RF-MOD übrig hast und einen PI wohl auch damit eine frische Installation machen.
- Die Wired Geräte ablernen dann den DRAP ablernen und am neuen System anlernen
- Sobald das geht Schritt für Schritt Komponenten vom alten zum neuen System umziehen und testen

Ich bin jetzt sicher nicht der Homematic Spezialist aber ein großer Fan von systematischer Fehlersuche.
Es ist immer leichter seine eigene Vermutung zu widerlegen als sie zu beweisen - dann kann man zum nächsten Punkt gehen. Warum z.b. noch weiter am Funk basteln wenn doch auch Wired Geräte betroffen sind. (Falls es da doch einen Zusammenhang geben sollte werden sie Spezialisten mich sicher korrigieren )

Antworten

Zurück zu „RaspberryMatic“