Absterben von HM-LC-SW1-BA-PCB

[Prof. Dr. Peter Henning]

Nein, Funkinterface scheidet aus.
Ich denke inzwischen, dass es irgendein Problem mit der Spannungsversorgung ist - ein 1.7er an einem anderen Netzteil macht keine Probleme.

Mal sehen, ob sich das durch ein paar Kondensatoren lösen lässt.

Edit: Weder das, noch durch eine andere Spannungsversorgung. Ich bleibe dran und versuche weiter, den Grund zu finden.

LG

pah

[frank]

ich habe noch ein paar ideen:

1. attr burstAccess löschen.
das ist eigentlich nur für devices, die man wahlweise über burst wecken kann. dieser actor braucht aber immer burst. das attribut sollte zwar dann keinen einfluss haben, aber wer weiss...

2. attr actCycle löschen
hier hast du 600 std / 25 tage eingestellt. soll das so sein? nutzt du auch zusätzlich im actiondetector das attr actAutoTry?
zum testen eventuell auch mal löschen.

3. attr autoReadReg ausschalten / auf null setzen.
es gibt wohl 1,2 oder 3 devices, bei denen probleme auftreten, wenn das attribut gesetzt ist.

4. raw messages sniffen, wie im wiki beschrieben.
enweder erkennt man eine sonderbare kommunikation beim "ausstieg" des actors, oder ein vergleich der beiden fw zeigt besondere unterschiede.

5. ein at mit regelmässigem statusrequest könnte eventuell die tests forcieren/verkürzen.

6. hat der actor vielleicht ein burst problem?
gibt es bei dir viele burst messages? mit "get hminfo msgStat" kann man die anzahl der burst messages sehen, die von den io empfangen werden. hier werden auch eventuelle burst messages vom nachbarn gezählt.
zum monitoren, was der actor empfängt, sollte sich dieser in der nähe des messenden io befinden.

[frank]

und noch etwas:
hin und wieder hat eq3 probleme mit aes.
also auch mal aes ausschalten.

[Prof. Dr. Peter Henning]

Dank für die vielen Tipps. burstAccess und ActCycle sind schon länger weg, daran lag es auch nicht. Am AES auch nicht.

Weiter mit der Detektivarbeit.

LG

pah

[noansi]

Hallo Peter,

noch was zum Prüfen ins Blaue.

Schau mal, ob das Device mit get assignIDs beim IO gelisted wird. Bevor und wenn es abgestorben ist.

Gruß, Ansgar.

[Prof. Dr. Peter Henning]

@noansi: Device wird vor und nach dem Absterben bei den assigned IDs korrekt gelistet.

Die Spannungsversorgung habe ich ja inzwischen auf mehrfache Weise ausgeschlossen.

Nächster Verdacht war, dass der Raspberry Pi mit dem HMCFG Netzwerkprobleme hat (möglich, weil über PowerLAN angeschlossen)

      ==> Nein, das war es auch nicht. Absterben trotz direktem Ethernetkabelanschluss

Nächster Verdacht war: Freezes auf der FHEM-Installation auf diesem speziellen Raspberry Pi (diese FHEM-Installation greift aber NICHT auf den HMCFG zu, der hmland mit HMCFG läuft einfach nebenher). Diese Freezes kommen von dem BOSE Soundtouch-Modul ( grrr.... ). Außerdem hat diese FHEM-Installation ziemlich viele HTTPMOD, die das Netzwerk blockieren könnten. Also noch einen Raspberry Pi daneben gestellt, auf dem keinerlei FHEM läuft, sondern nur ein hmland mit HMCFG.

      ==> Nein, das war es auch nicht. Absterben trotz dezidiertem Raspberry Pi für den HMCFG

Derzeit unternehme ich einen Versuch mit einem weiteren HM-Interface, HM-MOD-RPI-PCB mit noch einem weiteren separaten Raspberry Pi, der nur dieses Funkmodul bedient. Und der als assigned ID's nur die vier HM-LC-SW1-BA-PCB hat.

Mir stellt sich die Frage, warum eigentlich die 1.7er HM-LC-SW1-BA-PCB im "Missing Ack" Zustand verbleiben. Sie müssten doch eigentlich irgendwie wieder aufgeweckt werden?

LG

pah

[Pfriemler]

Mir ist das alles auch zunehmend mystisch. MISSING_ACK heißt ja erst mal dass FHEM eine erwartete Antwort vom Gerät vermisst.
Im ersten Beitrag: 3 Sekunden zum Aufwecken? Was passiert eigentlich wenn man den Aktor einfach nur mit der Taste lokal schaltet? Schaltet er da? posaunt er seinen Status hinaus, liest das FHEM auch nicht?
Steuerbarkeit aus FHEM sollte unabhängig von MISSING_ACK sein, muss aber ein Burst sein. Denkbar, dass die Firmware nicht aufwacht bei den Bursts die FHEM senden kann.
Wo ist eigentlich Martin? 

[Prof. Dr. Peter Henning]

Mir ist das alles auch zunehmend mystisch

Amen, Bruder, Amen.

Hat auch nicht geholfen, dass ein nagelneues dezidiertes Interface nur 2m entfernt vom Device stand (letzter oben beschriebener Versuch...).

Eine Option hab ich noch. Morgen ...

LG

pah

[Prof. Dr. Peter Henning]

So, es scheint behoben (dem Himmel und allen Unterstützern sei Dank...)

Wenn es morgen noch läuft, werde ich hier eine Analyse posten - sonst sitze ich in der Ecke und lutsche am Daumen.

LG

pah

[frank]

du machst es aber spannend.
hoffentlich kann ich heute einschlafen.

[Prof. Dr. Peter Henning]

OK, scheint tatsächlich behoben zu sein.

Der BA-PCB sitzt zusammen mit einem Arduino und etwas Elektronik außen herum an meinem Hoftor und steuert das selbstverriegelnde Panikschloss. Der Arduino ist für den 1-Wire (genauer: iButton)-Kontakt zuständig, mit dem ich die Tür von außen entriegeln kann. Stromversorgung mit 5V.

Der 1.6er hatte sich im August nach einem Gewitter verabschiedet, gut, damit muss man im Außenbereich leben, also habe ich alle anderen Bauteile sorgfältig getestet und für gut befunden. Und den 1.7er eingebaut, womit die Probleme begannen.

Beim Test der Stromversorgung (irgendwo auf Seite 2 des Threads) habe ich den BA-PCB separat mit 5V versorgt. Sein Schaltausgang legt nur einen Pin des Arduino auf GND, das habe ich also so belassen.

Die "letzte Option", die ich oben genannt habe, war nun endlich die Richtige. Offenbar hatte das Schaltnetzteil (das sich im Innenbereich befindet) bei dem Gewitter etwas abbekommen, auf der Ausgangsseite war jedenfalls die Gleichspannung von 5V mit einer zusätzlichen hochfrequenten Wechselspannung von einigen Volt beaufschlagt. Dem Arduino hat das gar nichts ausgemacht, und bei einer Gleichspannungsmessung ist es natürlich auch nicht aufgefallen.

Auch bei separater Stromversorgung des BA-PCB wurde nun diese hochfrequente Wechselspannung über den Schaltausgang auf das Board des BA-PCB eingekoppelt (MOSFETs haben eine ziemlich hohe kapazitive Rückwirkung auf das Gate). Und zwar nicht so, dass der BA-PCB gestorben wäre oder gar nichts mehr gemacht hätte - aber doch so, dass er nach ein paar Stunden die Arbeit eingestellt hat. Man frage mich nicht, wieso erst nach ein paar Stunden...

Ich habe jetzt also das komplette Schaltnetzteil ersetzt, und die Kiste rennt.

Witzigerweise tut übrigens der 1.6er ebenfalls wieder, er war also "nur" scheintot.

Was lernen wir daraus:
1. Blitzschutz für Außenanlagen muss besser sein (ich habe seit Jahren die Funkenstrecken und Dioden dafür herumliegen, das aber nie wirklich implementiert).
2. In künftigen Anwendungen des BA-PCB werde ich den Schaltausgang sorgfältig absichern.

Danke an Alle, die sich gemeinsam mit mir Gedanken gemacht haben.

LG

pah

[Pfriemler]

Also ich weiß nicht ... du hattest doch einen zweiten 1.7 im Test, der auch ausgestiegen ist - doch wohl nicht am gleichen monierten Netzteil?
Also dass das gewittergeschädigte Netzteil ein Problem datstellt : ja. Aber die Rückwirkung sehe ich trotzdem nicht so kritisch. Immerhin darf die geschaltete Spannung ja sonst auch reichlich über der Versorgung liegen, und dass die über die Mosfet- Kapazitäten gestreuten Ströme den Prozessor des Ba-PCB lahmlegen, glaube ich auch nicht - zumal ja ein langer Tastendruck das Ding wieder zum Leben erweckte nach Deiner Schilderung.

Denkbar, dass das eine (Schaltnetzteil) mit dem anderen (Firmware) gar nix zu tun hat?

[Prof. Dr. Peter Henning]

Also ich weiß nicht ... du hattest doch einen zweiten 1.7 im Test, der auch ausgestiegen ist - doch wohl nicht am gleichen monierten Netzteil?

Nein, anderes Netzteil. Warum der (und passend dazu der 1.6er) ausgestiegen ist, kann ich nicht mehr nachvollziehen - und Du hast Recht, es passt nicht ins Bild.

Aber die Rückwirkung sehe ich trotzdem nicht so kritisch.

Vorsicht, es geht um hochfrequente Einkopplungen, das ist etwas anderes - die gehen problemlos 

Denkbar, dass das eine (Schaltnetzteil) mit dem anderen (Firmware) gar nix zu tun hat?

Die Firmware der Interfaces habe ich als Erstes aktualisiert - auch mit der aktuellen Firmware gab es noch dieses Absterben.

Und Tatsache ist, dass erst nach der "letzten Option" (=kompletter Austausch des betreffenden Netzteils) die Sache behoben war.

LG

pah

[Pfriemler]

... es geht um hochfrequente Einkopplungen, das ist etwas anderes - die gehen problemlos

Na, ich vermute doch mal, dass die überlagerte Wechselspannung vom kaputten Netzteil die Schaltwandler-Frequenz hat. Nach meinen Erfahrungen liegt die selten über 100 kHz.
Die "Reverse Transfer Capacitance" des Mosfets liegt laut Datenblatt bei ca. 66 pF (15V). Ist die gemeint? Das würde einen Serienwiderstand von 24 kOhm ergeben - bei 10 Volt Amplitude der überlagerten  Wechselspannung also weit weniger als 1mA eingekoppelter Strom. Das bringt den µP nicht durcheinander, denke ich doch stark. Da müsste schon der interne Takt durcheinandergewirbelt worden sein, so dass das timing nicht mehr stimmt. Aber das erklärt auch nicht, warum das Ding anfangs geht und erst nach Stunden aussteigt.

Genug der Kaffeestatzleserei  Ich drück die Daumen, dass es das nun wirklich endlich und dauerhaft war.

[Prof. Dr. Peter Henning]

Genau diese 66 pF meine ich. Und die Frequenz stimmt auch - allerdings ist mit ziemlich vielen Oberwellen zu rechnen.

Nun müsste man aber noch genauer wissen, welchen Mikrocontroller eQ-3 hier verwendet. Der Aktor wäre nicht für Batteriebetrieb geeignet, wenn es auf Ströme von einem mA ankäme - relevanter ist die eingekoppelte Spannung. Bei einem hochohmigen Eingang sind 24 k Vorwiderstand so gut wie nichts.

Da müsste schon der interne Takt durcheinandergewirbelt worden sein, so dass das timing nicht mehr stimmt

Das wäre eine Möglichkeit - aber da lesen wir wirklich im Kaffeesatz. Könnte allerdings erklären, warum die Software dann  Probleme machte.

Denkbar, dass das eine (Schaltnetzteil) mit dem anderen (Firmware) gar nix zu tun hat?

Habe jetzt beim erneuten Nachlesen erst verstanden, was eigentlich gemeint war. Der 1.6er ließ sich (an diesem Netzteil) gar nicht mehr durch einen langen Tastendruck wiederbeleben, der 1.7er schon.

LG

pah