CCU3 -> hoher DC auf einem Lan Gateway.....why ?

[onkeltommy]

Kein Prob, ohne diesem Fred wäre ich sicher nicht "so schnell" draufgekommen, dass die Anzeige von den 3 DCs aufn Tablet falsch, bzw, "verreiht" war und damit nicht der LGW den hohen DC hat sondern die CCU

Jetzt ist nur die Frage, den Grund rausfinden. Wie. Kommt der vom IP Bereich oder vom Classic HM Bereich....wer ist der Schuldige.....

lG

Thomas

[alchy]

Oh Schei******

habe mir den Fred von Alchy nochmal durchgekaut....es stimmte die Reihenfolge der Variablen nicht (mehr ?)

Das Script liest der Reihe nach alles aus.
Es verschiebt sich dann etwas, soweit ich mich erinnere, beim z.B. Hinzufügen eines weiteren LanGW automatisch.
Der Grund war *IMHO* das ein neues Gerät an den Anfang gesetzt wird und nicht an das Ende. Daher habe ich die Seriennummern mit ausgegeben.

Kommt der vom IP Bereich oder vom Classic HM Bereich....wer ist der Schuldige....

Man kann auch den IP Duty Cycle auslesen.

Alchy

[Familienvater]

Hi,

Man kann auch den IP Duty Cycle auslesen.

dann erkläre doch bitte mal, was das hilft? Ich behaupte einfach mal, das sich der HmIP-DC max. um Nuancen vom rfd-DC unterscheidet, und das weil der DC vom Funkmodul bei der einen Variante evtl. direkt vom Funkmodul kommt, und bei der anderen Variante der "letzte" zyklisch abgefragte Wert benutzt wird.
In der Zentrale ist es das gleiche Sendemodul, also die gleiche Antenne, also wird/muss die verbrauchte Sendezeit unabhängig vom versendeten "Protokoll" sein.

Bei mir ist gerade auf dem Produktiv-System der HmIP-DC 1 % höher als rfd-DC gewesen, nach 2 min ist es genau umgekehrt, auf dem Testsystem sind beide Werte gleich niedrig, wobei es da, wenn es einen Unterschied machen würde, der HmIP-DC deutlich anders sein müsste, und wenn ich einen HmIP-TFK ein paar mal betätige, dann steigt dort sowohl der rfd-DC als auch der HmIP-DC.
Auch dagegen spricht, das ein HmIP-Firmware-Update ohne Zweifel im rfd-DC zu sehen ist.

Der Familienvater

[onkeltommy]

Ja das müsste stimmen, da auch die Werte, welcher der Script ausgibt schön ansteigen, wenn ich IP Geräte update. Zuletzt eben ein Wandthermo. Konnte man so schön sehen, wann das Teil ready 4 update war.

Nur jetzt komm ich nich dahinter, warum der DC von der CCU so hoch ist, alle Geräte funktionieren, einige IP Steckdosen kann ich nicht ausstecken /Kaltstarten, ausser im Notfall, da darüber Server usw versorgt werden. Aber auch diese senden (PSM), brav ihre Werte, sind aber von den Parametern her auf "Ruhe" angepasst, damit die nicht jede mA Änderung senden. Was sich in der Vergangenheit bewährt hat. Dank Hilfe vom Forum
Andere Classic Stecker habe ich schon gezogen und damit neu gestartet....Batteriesender detto....
Ich habe keine Ahnung, was seit FW Update der CCU3 nun "anders" ist. Jetzt bin ich wieder auf ~70 herum, keiner zu Hause, das System ist im "Schlafmodus", außer der Basiskommunikation wird nichts geschaltet etc. Letzter Neustart war ja gestern so um 17 Uhr herum, also wären genug Stunden vergangen, dass sich der DC nach Reboot wieder beruhigt.

lG an Alle

Thomas

[Daimler]

Hi,

um das herauszufinden - du kannst ja im Log nichts finden - wirst du wohl oder übel die harte Methode gehen müssen:
Alle über die Ccu angesteuerten Geräte Strom- / Batterielos machen und dann nach und nach wieder anklemmen und den Dc beobachten.

Hast du zuf. Rollo- oder Licht Markenschalter im Einsatz - C26?

[onkeltommy]

Das mit stromlos machen, da bin ich eh dabei, eben soweit wie es geht.

Rollo: nein, IP-BSM, ja, einer, ein paar Wochen alt, aber der läuft auch einwandfrei. Ist aber Direktverknüpft mit sich selber und mit einem IP Unterputzaktor. Tut alles brav seinen Dienst. Bis jetzt war "ich" "gewohnt", dass ein Gerät im Dauerfeuer keine Befehle annimmt / oder extrem schlecht reagiert und die LED des betroffenen Gerätes auf Discolight schaltet. Aber ich habe nur einen Classic TFK, welcher aller paar Wochen meint, jetzt blinke ich mal in allen Farben bis die LED hin ist...nein...bis auf den einen hatte ich bisher noch keinen Dauersender. Und eben den habe ich als Erstes reseted.
Wäre ja schonmal hilfreich, rauszufinden, ob sich Classic oder IP zubrüllt......bei mir ist die Aufteilung Classic / IP ca. 50:50 und nicht wenige....
Wo es möglich ist, Empfangsseitig, habe ich die meisten Classic den LGWs zugewiesen und Roaming abgedreht, aber .... ändert sich nix. Ausser, dass mal der eine oder andere gemeckert hat.....Komm Fehler (logisch) ....was aber dem DC der LGWs relativ wurscht war

[Familienvater]

Hi,

ich würde erstmal schauen, was so an Events los ist, z.B. in der ioBroker Ereignis-Anzeige, alternativ jedes andere extern angebundene System, was einem die Events irgendwie loggt/anzeigt nutzen.
Dann kommt die Universalwaffe syslog vom rfd hochzudrehen, und sich das anzuschauen, und z.B. nach ein bisschen "umformatieren" mit Excel zu pivotieren.
Alternativ kann man auch die log4j.xml-Konfigdatei vom hmserver "verfummeln", so das die andere Dinge loggt, und man ein etwas "größeres" Logfile zum Eventsammeln hat (wobei das hier jetzt rein um die Events geht), vorher auf jeden Fall die originale log4j.xml sichern, wer mutig ist kann ggf. auch ein bisschen an der MaxFileSize drehen, aber nicht übertreiben, das Log liegt im tempFs, kostet also in dieser Größe direkt Hauptspeicher!

Bei der CCU2 ist es die Datei /usr/local/etc/config/log4j.xml, nach einer Änderung muss auf jeden Fall der HM-Server neu gestartet werden, alternativ die ganze Zentrale sauber neu hochfahren. Mit dieser Log-Config werden alle Events, auch die des rfd und ggf. wired in /var/log/hmserver.log geloggt, und auch noch einmal wegrotiert, aber damit kann man vielleicht auch mal 30 Minuten oder mehr "sehen", wo das normale kleine messages-File mit seinen 200 kb schon x-mal wegrotiert wurde.

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
	<appender name="FILE" class="org.apache.log4j.RollingFileAppender">
		<param name="File" value="/var/log/hmserver.log"/>		
		<param name="MaxFileSize" value="2048KB" />
		<layout class="org.apache.log4j.PatternLayout">
			<param name="ConversionPattern" value="%d{MMM d HH:mm:ss} %c %-5p [%t] %m %n"/> 
		</layout>
	</appender>

	<appender name="SYSLOG" class="org.apache.log4j.net.SyslogAppender">
		<param name="SyslogHost" value="127.0.0.1"/>
		<param name="Facility" value="LOCAL0"/>
		<param name="FacilityPrinting" value="true"/>
		<layout class="org.apache.log4j.PatternLayout">
			<param name="ConversionPattern" value="%c %-5p [%t] %m %n"/> 
		</layout>
	</appender>
   
	<category name="de.eq3.ccu.groupdevice.service.BidCosDeviceEventHandler">
		<priority value="ERROR" />
	</category>
	<category name="de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher">
		<priority value="DEBUG" />
	</category>
	<category name="de.eq3.ccu.server.internal">
		<priority value="ERROR" />
	</category>
	<category name="de.eq3">
		<priority value="DEBUG" />
	</category>
	<category name="de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendNotificationHandler">
		<priority value="ERROR" />
	</category>
	<category name="org.apache.http.wire">
		<priority value="ERROR" />
	</category>
	<category name="org.apache.http">
		<priority value="ERROR" />
	</category>
	<category name="org.apache.http.impl.conn">
		<priority value="ERROR" />
	</category>
	<category name="org">
		<priority value="DEBUG" />
	</category>
	<category name="com">
		<priority value="DEBUG" />
	</category>

	<root>
		<priority value="DEBUG" />
		<appender-ref ref="FILE" />
		<appender-ref ref="SYSLOG" />
	</root>

</log4j:configuration>

Der Familienvater

[onkeltommy]

Uffffff

okay.....mit den Pivot im Excel hab ich nicht viel am Hut....aber, was wäre im Syslog auffällig ? Derzeit ist rfd auf alles loggen gestellt

Wird fleissig bepinselt, aber ich weiss nicht, nach was ich suchen soll.
iOBroker nicht im Einsatz

[Familienvater]

Hi,

man kann sich da z.B. aus dem Syslog diverse Dinge schnell "rausgreppen" (alternativ kann man statt /var/log/messages auch /var/log/messages.0 nehmen, das ist immer "randvoll", das ist halt die letzte wegrotierte Datei)

Code: Alles auswählen

Für "Alle" Antennen:
grep "rfd: RX" /var/log/messages|grep "BIDI=1"
 
Für eine Antenne mit der SN KEQ123456 (SN der Zentrale oder des Gateway)
grep "rfd: RX" /var/log/messages|grep "BIDI=1"|grep "KEQ123456"

Zeigt einem alle Empfangenen HM-Pakete, die quittungspflichtig waren (wo also die CCU eine Quittung senden musste), taucht da eine SN bei RX for xEQ?????? besonders häufig auf, drüber nachdenken, warum das so ist.

Dann kann man die gesendeten Pakete anschauen

Code: Alles auswählen

Für "Alle" Antennen:
grep "rfd: TX" /var/log/messages
 
Für eine Antenne mit der SN KEQ123456 (SN der Zentrale oder des Gateway)
grep "rfd: TX" /var/log/messages|grep "KEQ123456"

Da gibt es bei mir regelmäßig eine leere Ausgabe, weil bei mir nicht viel aktiv gesendet wird, hat man hier viele Zeilen mit TX, dann muss man leider forschen, wer der "Empfänger" ist, weil hier keine SN des angefunkten Geräts steht, sondern nur seine interne Funkkennung "0xHEXwert1 -> 0xHexWert2", wobei HexWert1 die Funkennung der Zentrale ist, und HexWert2 ist die Kennung des angefunkten Geräts, die können wir uns "auflösen" mit

Code: Alles auswählen

grep "address=\"0xHexWert2\"" /etc/config/rfd/*.dev

Dann kommt die Ausgabe, welches Gerät mit welcher SN dahinter steckt.

Wenn dann nicht klar ist, was der Treiber ist, dann muss man mit den MultiMac-Ausgaben (die erst nach einem Reboot der Zentrale mit bereits gesetztem rfd "Alles loggen" kommt), und da mit z.B. HMIP CMD= auf die Suche gehen. Das MultiMac-Syslog ist aber "kryptisch", und ich kann es auch nicht aus dem Kopf "debuggen", sondern muss es mir immer erst eine Zeitlang anschauen, und mit den Events vergleichen, dann kommt man auch dahinter (ich hatte aber noch nie die Not, da groß im HmIP-Bereich zu suchen), was die C> und <A usw. bedeuten, und man kann auch aus den Bytes die Adressen der HmIP-Geräte herausbekommen, wenn man sich nur genügend Beispiele am Stück rausgreppt, sieht man, was Fix ist, und wo sich Bytes ändern.

Der Familienvater

[onkeltommy]

Hi

okay, damit kann ich arbeiten 1000 Dank. Nachmittagsbeschäftigung gesichert....jetzt mal noch in der Firma n wenig daheim nachgeguckt

Was mir "aufgefallen" ist, mit dem ersten grep (über alle Antennen), egal wie oft ich den ausführe, es wird fast imme nur dieses Gerät angezeigt

Code: Alles auswählen

# grep "rfd: RX" /var/log/messages|grep "BIDI=1"
Jan  4 12:38:08 ccu3-webui user.debug rfd: RX for NEQ1552574: @413662257 RSSI=-66dB 0x513255 -> 0x3D6F15 Generic [NEQ0382000]:   CNT=21,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x5F   DATA = 91 50 14 00 1F 3E 01 6D 09 22 FE
Jan  4 12:38:21 ccu3-webui user.debug rfd: RX for NEQ1552574: @413675257 RSSI=-66dB 0x513255 -> 0x3D6F15 Generic [NEQ0382000]:   CNT=22,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x5F   DATA = 91 50 16 00 15 E2 00 F3 09 24 FE
# grep "rfd: RX" /var/log/messages|grep "BIDI=1"
Jan  4 12:38:08 ccu3-webui user.debug rfd: RX for NEQ1552574: @413662257 RSSI=-66dB 0x513255 -> 0x3D6F15 Generic [NEQ0382000]:   CNT=21,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x5F   DATA = 91 50 14 00 1F 3E 01 6D 09 22 FE
Jan  4 12:38:21 ccu3-webui user.debug rfd: RX for NEQ1552574: @413675257 RSSI=-66dB 0x513255 -> 0x3D6F15 Generic [NEQ0382000]:   CNT=22,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x5F   DATA = 91 50 16 00 15 E2 00 F3 09 24 FE
# grep "rfd: RX" /var/log/messages|grep "BIDI=1"
Jan  4 12:38:08 ccu3-webui user.debug rfd: RX for NEQ1552574: @413662257 RSSI=-66dB 0x513255 -> 0x3D6F15 Generic [NEQ0382000]:   CNT=21,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x5F   DATA = 91 50 14 00 1F 3E 01 6D 09 22 FE
Jan  4 12:38:21 ccu3-webui user.debug rfd: RX for NEQ1552574: @413675257 RSSI=-66dB 0x513255 -> 0x3D6F15 Generic [NEQ0382000]:   CNT=22,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x5F   DATA = 91 50 16 00 15 E2 00 F3 09 24 FE

Das ist der Not-Trennschalter der Heizung.......HM-ES-PMSw1-SM

scheinbar ein gesprächiger Teilnehmer... ?

aber der sollte so eingestellt ja "ruhiger" sein ?

lG