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

[Matsch]

mit der Änderung in der Radio-cc1101.h sehen wir jetzt zumindest eine Debug Message

Vielleicht, denn bisher ist das Problem ja wohl noch nicht beobachtet worden beim Betrieb am FDTI-Adapter und Monitor.
Kann aber sein, dass die Zeit daran zu kurz war, damit es auftritt.

Eines meiner Geräte war heute 6 h taub und fing dann wieder an als sei nichts gewesen ...

[Matsch]

@Horbi, ich habe deine letzte Änderung mal in - zunächst - eines der schlimmsten Geräte geflasht. Negatives konnte ich bisher nicht beobachten. Ausfall war in den bisherigen 15 h noch keiner. Sehn wir mal weiter.

Später:
Wie gehabt, wieder der übliche Ausfall.

Manchmal zweifle ich daran, dass das bei Original-Geräten von eQ-3 nicht genauso passiert. Wenn da einfach drauflos gesendet wird, egal, ob der Partner das "hören" kann oder nicht, muß es doch irgendwann mal zum Kommunikationsausfall kommen (trotz Wiederholungen).
Leider habe ich kein solches für einen Dauertest zur Verfügung, überwiegend HmIP.

Ich habe jetzt auch mal einen batteriebetriebenen Eigenbauschalter HM-LC-Sw1-LK vom Typ HM-LC-SW1-Ba-PCB mit in den Test einbezogen, um zu probieren, ob das Thema wirklich Batteriegeräte nicht betrifft. Zudem habe ich mal die Konfiguration der Steckdose auf maximale Anzahl Sendeversuche gesetzt - wenn ich auch glaube, dass das nicht Schuld sein kann an stundenlanger Taubheit.


Was mich noch zudem irritiert: Ich kann bei den 5 Steckdosen feststellen, dass
- 2 Steckdosen fast nie oder nie ausfallen
- 2 Steckdosen besonders stark betroffen sind
- 1 Steckdose sich in der Mitte anordnet

und dies alles ziemlich standortunabhängig ist, also weder die Entfernung eine Rolle spielt noch die jeweiligen Standortgegebenheiten.

Hoffentlich erleben wir da nicht auch wieder ein Problem mit den CC1101-Modulen!? Doch ein Hardwareproblem?
Vielleicht sollte ich bei einem stark betroffenen Gerät mal das Modul wechseln?
Springt das Modul einfach nicht wieder an?

Letzteres ist Quatsch. Ich hatte ja zum Test mal in der loop() die Zeile zum Versetzen in den Idle-Modus auskommentiert (d.h. er bleibt im Normalbetrieb) und das Problem trat davon unabhängig genauso auf. Ist wohl der Eigenschaft geschuldet, dass ständig empfangen und nicht auf Boost gewartet wird.

[Horbi]

Ich habe die letzten Tage in meinem Testaufbau (jede Menge Debug Punkte in der Empfangs-, wie in der Sendefunktion) mit Nachrichten gequält.
Einen PB2 Schalter ganz nahe ans Gerät und dann hoch-, runtergedimmt, oder eben an und aus geschaltet. Und immer wieder den Abstand variiert, von Antenne berührt bis etwa einen halben Meter Entfernung.

Damit bringe ich das Gerät einigermassen zuverlässig aus dem Tritt, allerdings nicht in der Sende-, Empfangsfunktion. Ich tippe das passiert irgendwo in der Statemaschine. Allerdings lässt sich mein Gerät dann auch nicht mehr per Taster ins Leben zurück holen.

Beim Drücken kommt noch ein debounce mit einer kleinen Verzögerung und danach hängt das Gerät endgültig.

[jp112sdl]

mit der Änderung in der Radio-cc1101.h sehen wir jetzt zumindest eine Debug Message

Vielleicht, denn bisher ist das Problem ja wohl noch nicht beobachtet worden beim Betrieb am FDTI-Adapter und Monitor.

Ich hab noch mal intensiv darüber nachgedacht, wie es sich bei mir darstellt.

Es betrifft nur wenige Aktoren. Umgeflashte eQ-3 Unterputzaktoren für Markenschalter (mit ATmega 644PA) z.B. gar nicht!

Einer der betroffenen ist ein mit Pro Mini (328P) umgebauter Sonoff 4CH Aktor.
Und bei dem ist es so, dass dann tatsächlich nur 1 Kanal spinnt und keine Befehle mehr vom "Master" entgegen nimmt. Die anderen gehen weiter. Und auch der eine "kaputte" geht wieder, wenn ich ihn per Fernbedienungs-DV 1x schalte.

Dann hab ich noch einen zickigen umgeflashten RWE Zwischenstecker (328P) und einen 5V-USB versorgten LED-Lichterkettenaktor auch mit einem 328P.

[Matsch]

Ich habe jetzt auch mal einen batteriebetriebenen Eigenbauschalter HM-LC-Sw1-LK vom Typ HM-LC-SW1-Ba-PCB mit in den Test einbezogen, um zu probieren, ob das Thema wirklich Batteriegeräte nicht betrifft.

Nun, auch das Batteriegerät ist inzwischen einmal ausgefallen!
q.e.d.

[jp112sdl]

Ich habe heute mal kurz mit dem Logicanalyzer auf den SPI-Bus des CC1101 eines HM-LC-BL1-FM gelauscht.

Ich kann mit den Ausgaben jedoch im Moment noch nichts anfangen und hatte auch noch keine Zeit, mich damit intensiver zu beschäftigen.

Auf jeden Fall macht eQ-3 mit dem CC1101 alle 500ms irgendwas.

Nur was? Ich sehe 16 Clock Pulses und 2 Byte sowohl auf der MISO als auch MOSI Leitung (kann sein, dass ich sie vertauscht habe, wobei ich eigentlich die Strippen 2x kontrolliert hatte).

[stan23]

0x10 wäre ein Single Write ins Register MDMCFG4
0x0D würde die Bandbreite verdrehen.
Klingt unplausibel.

0xF5 wäre ein Burst Read aus dem Register MARCSTATE.
0x0D wäre MARCSTATE.MARC_STATE=RX
0x10 ist das Statusbyte:STATE=RX, FIFO_BYTES_AVAILALE=0

eQ3 pollt hier also den Status des Transceivers.

[Horbi]

Wäre interessant zu wissen ob sie das Funkmodul als Watchdog pollen, oder ob sie das als Empfangsroutine nutzen.

Als Empfangsroutine würde es das Empfangskonzept der Asksin über den Haufen schmeißen,
Asksin wartet auf das Signalisieren einer Message und ließt die dann aus.

Eine Erkennung durch 500ms Pollen müsste immer den ganzen String auslesen und ggf in mehrere Nachrichten aufteilen, da ja in 500ms ziemlich viele Nachrichten empfangen werden können.

Aber vielleicht gibts ja wirklich ein Problem mit der Interrupterkennung und EQ3 umgeht das per polling?
Also lesen auch per Interrupterkennung, aber wenn die versagt und was im Speicher stehen bleibt, dann wird das Lesen über den watchdog initiiert.
Macht das Sinn?

[jp112sdl]

Wenn ein Telegramm eintrifft, erfolgt eine Signalisierung am GDO0 gefolgt vom Lesen des Puffers.

Anders könnten die ACK-Timings auch nicht eingehalten werden.

Warum sie trotzdem alle 500ms pollen,… keine Ahnung

[stan23]

Vielleicht um unser Problem zum umgehen:
Dass das Funkmodul etwas im FIFO hat aber der Interrupt von GDO0 nicht durchschlägt?
Oder dass das Funkmodul aus irgendeinem Grund nicht in mehr in RX ist?
Oder der FIFO voll läuft aber kein IRQ beim vollständigen Paket erzeugt wird?

Wer baut einen CC1101-Emulator und hängt den an ein eQ-3-Gerät?