Probleme mit HM-LC-Sw1-Pl-DN, stochastische längere Kommunikationsausfälle

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von Matsch » 17.03.2023, 15:32

stan23 hat geschrieben:
17.03.2023, 14:54
Du kannst einfach diese Zeile auskommentieren:
https://github.com/pa-pa/AskSinPP/blob/ ... age.h#L164
Hmm, die ist ja schon auskommentiert!
Ist das gerade erst im letzten Update vorgenommen worden? Ich habe es gerade aktualisiert, aber wohl noch die Version von gestern geflasht.
Jetzt taucht die Meldung nicht mehr auf. :D

In der Tat hat mich CCU-Historian in eine falsche Richtung geschickt. Dort werden immer mal wieder Ausfalllücken im Status angezeigt, die aber wohl gar nicht stattfinden. Meine zusätzliche Überprüfung per Programm ergab in solchen Fällen keinen Statusfehler und bislang auch noch keine Kommunikationsaussetzer mehr.

TomMajor
Beiträge: 1790
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von TomMajor » 17.03.2023, 16:23

Matsch hat geschrieben:
17.03.2023, 15:32
Hmm, die ist ja schon auskommentiert!
Ist das gerade erst im letzten Update vorgenommen worden? Ich habe es gerade aktualisiert, aber wohl noch die Version von gestern geflasht.
Jetzt taucht die Meldung nicht mehr auf. :D
hat trilu2000 vor 8h geändert:
https://github.com/pa-pa/AskSinPP/commi ... 9920379259
(im trilu branch den Marco verlinkt hatte)
Viele Grüße,
Tom

HMSteve
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von HMSteve » 17.03.2023, 22:11

Schade, 10h lief das minuetliche An- und Ausschalten fehlerfrei, dann tauchte ein Kommunikationsfehler bei einem Einschaltbefehl auf. Im Log ist ziemlich genau zu der Zeit, zu der er empfangen worden sein sollte, ein Rx1B zu sehen, sonst keine Spur eines empfangenen Telegramms fuer das Testgeraet. Das Ausschalttelegramm 10s spaeter wurde wieder empfangen. Zum Zeitpunkt des nicht empfangenen Telegramms herrschte allerdings reger Funkverkehr zwischen einem raeumlich nahen E-Paper und einer anderen CCU, zu erkennen an vielen ignorierten Messages im log, so dass ich nicht sicher bin, ob das E-Paper schlicht meine Test-CCU uebertoent hat. Andererseits kam diese Gleichzeitigkeit von Test-Schaltbefehl und E-Paper-Update auf dem anderen System im Testzeitraum ca 40x vor, und nur einmal kam ein Fehler. Zudem sind auch keine Wiederholungen der nicht empfangenen Sendung zu sehen. Nach dem Fehler lief der Testaufbau bis jetzt weitere 2h fehlerfrei. Hmmm...

Nachtrag: Auch mein Analyser hat den vermissten Einschaltbefehl nicht gehoert, also habe ich mit hoher Wahrscheinlichkeit kein Indiz gefunden, dass der gesuchte Fehler weiter auftritt.

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von Matsch » 18.03.2023, 10:52

Hat nicht mal jemand ein entsprechendes HM-Originalgerät, mit dem man den Test parallel machen könnte (Schaltsteckdose)?
Ich würde schon gerne wissen wollen, ob diese Effekte beim Original nicht ebenso vorhanden sind, auch wegen dem fehlenden listen-before-talk.

Bei einem meiner 3 Geräten ist nach nunmehr 14 h auch wieder der bekannte Fehler kurzzeitig aufgetreten. Das Gerät hing aber nicht am Monitor. Pauschal sieht es momentan so aus, dass der Fehler nur noch selten auftritt, aber so eine subjektive Aussage kann auch Fehleinschätzung oder dem Zufall geschuldet sein.

Ich werde jetzt einige Tage nichts mehr testen können - weil das Arbeitszimmer vorgerichtet werden und deshalb der PC abgebaut wird :cry:

Nachtrag:
Inzwischen sind wieder alle 3 Geräte wie bekannt nicht erreichbar gewesen :cry:

HMSteve
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von HMSteve » 18.03.2023, 17:51

Matsch hat geschrieben:
18.03.2023, 10:52
Hat nicht mal jemand ein entsprechendes HM-Originalgerät, mit dem man den Test parallel machen könnte (Schaltsteckdose)?
Ich würde schon gerne wissen wollen, ob diese Effekte beim Original nicht ebenso vorhanden sind, auch wegen dem fehlenden listen-before-talk.
Ich habe drei Originalsteckdosen verschiedener Versionen im Dauerbetrieb. Zwei davon werden mehrmals taeglich geschaltet. An solche Taubheitsphasen wie bei den S26-Umbauten kann ich mich nicht erinnern. Habe jetzt einen ca. minuetlichen Test mit einer HM-ES-PMSw1-PI-DN-R1 gestartet.

HMSteve
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von HMSteve » 18.03.2023, 22:23

Zwischenstand nach ca 4h Dreiervergleich:
1. Testhardware mit geaenderter lib: ohne Kommunikationsfehler
2. HM-Originalsteckdose: ohne Kommunikationsfehler
3. S26-Umbau mit alter lib: diverse kurze und laengere taube Phasen, wiederholte Sendeversuche der CCU im Analyser sichtbar. Die letzte habe ich eben per Tastendruck beendet.

Vielleicht noch nicht repraesentativ, aber erstmal vielversprechend. Werde morgen die S26 mit geaenderter lib flashen.

HMSteve
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von HMSteve » 19.03.2023, 20:40

Testsetup heute:
1. Testhardware mit alter lib: keine Kommunikationsstoerungen
2. S26-Umbau mit alter lib: diverse Kommunikationsstoerungen
3. S26-Umbau mit geaenderter lib: diverse Kommunikationsstoerungen

3. verhielt sich eher zickiger als 2., waehrend die alte lib ebenso wie die geaenderte gestern auf der Testhardware keine (definitiven) Kommunikationsstoerungen lieferte.

Damit ist m.E. meine These mit dem HF-Problem in der S26 noch nicht vom Tisch, oder welchen Ideen habt Ihr noch?

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von Matsch » 24.03.2023, 10:48

So, nachdem ich wieder einen funktionieren PC zur Verfügung habe und die 3 Steckdosen mehrere Tage unbeobachtet durchgelaufen sind:

Bei mir hat sich nichts geändert, nach wie vor stellen sich alle Steckdosen irgendwann (mind. einmal am Tag, auch häufiger) für kürzere Zeit oder auch stundenlang taub - um danach wieder längere Zeit korrekt zu funktionieren.

Der Test mit der geänderten Firmware, aber mit einem Labornetzteil als Stromversorgung steht noch aus, werde ich die nächsten Tage anstoßen.

Horbi
Beiträge: 199
Registriert: 29.05.2019, 12:51
Hat sich bedankt: 19 Mal
Danksagung erhalten: 65 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von Horbi » 08.05.2023, 15:18

Aktueller Stand meiner Untersuchung über den Dimmer Sketch. Ich hatte ja immer wieder Probleme das meine Selbstbau Dualwhite Dimmer unerklärlich hängengeblieben sind. Manchmal konnte ich sie durch Drücken der Config-Taste wiederbeleben, manchmal half nur ein Reset.

Ich denke es waren 3 Problem die dazu geführt hatten

1. Ein Problem mit dem Blink Timer in der Ausschaltrampe des Dimmers. Es gab Situationen da wurde der Timer mehrfach gestartet.
2. Bei short Broadcast Nachrichten wird vom Switch eine direkt adressierte Nachricht mit selben Inhalt an das Gerät geschickt. Im besten Fall schaltet die Rampe unerwünscht weiter und bricht die eigentliche Aktion ab.
3. Fehler beim Empfang führen zu langen Nachrichten im Buffer des Empfangsmoduls, bleiben bestehen und verhindern eine vernünftige Signalisierung das eine Nachricht zur Abholung steht.

1. habe ich im Dimmer Sketch bereinigt
2. ist in der Asksinpp bereinigt
3. es gibt einen Watchdog der über ein #define eingeschaltet wird und alle 5000ms prüft, ob was im Buffer ist. Falls er was findet und die Übermittlung nach 50ms nicht fertig ist, wird das READ flag gesetzt und Asksin liest den Buffer und kümmert sich um den Input.

Die Änderungen sind im dev-trilu Zweig. Zum Einschalten vom Watchdog folgende Zeile im Sketch einfügen:

Code: Alles auswählen

#define RADIOWATCHDOG
Bisher laufen meine Geräte ohne Probleme. Vielleicht hilft es ja dem Einen oder Anderen. Feedback welcome.

papa
Beiträge: 705
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 24 Mal
Danksagung erhalten: 120 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von papa » 08.05.2023, 20:37

Das klinkt ja gut. Das sollten wir unbedingt in den Master übernehmen.
Anfragen zur AskSin++ werden nur im Forum beantwortet

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“