SIGNALduino geht nach einiger Zeit auf "closed"

Begonnen von tante ju, 24 August 2021, 20:20:54

Vorheriges Thema - Nächstes Thema

tante ju

Habe einen SIGNALduino, FW 3.4.0, am FHEM, aktuelle Version. Nach nicht voraussagbarer Zeit geht der auf "closed". Läßt sich dann auch von FHEM nicht resetten. Muß erst ausziehen oder per usbreset neu starten. Dann geht es wieder.

Er hängt an einem extra Hub mit eigener Versorgung, weil hier https://forum.fhem.de/index.php?topic=91648 ja erwähnt wurde, daß der Pi, auf dem FHEM läuft, u.U. Probleme habe könnte, die Leistung zu liefern.

Ein Downgrade des SD auf 3.3.1 hat auch keine Besserung gebracht.

Irgendwelche Ideen, wie das zu lösen ist (außer einem notify, welches den Neustart automatisieren würde)?

andies

Klingt nach Hardwareproblem. War jedenfalls bei mir so.
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

connormcl

Selbstbau oder wo gekauft?

China-Nano als Basis oder was hochwertigeres?

-> könnte das Masseproblem der Testleitungen am FTDI sein...

andies

Selbstbau (ich habe noch entsprechende Platinen, verkaufe die auch im Forum unter ,,verkaufe") und habe eine Weile mit China-Nanos experimentiert, das dann aber tunlichst gelassen. Inzwischen läuft bei mir alles.

Ach so, un dann war mal eine Lötstelle unsauber, das war auch ein Highlight, bis ich das gemerkt hatte.
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

tante ju

Zitat von: connormcl am 25 August 2021, 01:04:43
Selbstbau oder wo gekauft?

China-Nano als Basis oder was hochwertigeres?

-> könnte das Masseproblem der Testleitungen am FTDI sein...

Gekauft, hier: https://www.ebay.de/usr/smart-home-komponente

Scheint aber ein normaler Nano zu sein mit Zusatzplatine, also vermute ich kein generelles Problem am FTDI. Wobei man sowas natürlich nie ausschließen kann.

andies

FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: tante ju am 25 August 2021, 13:00:26
Gekauft, hier: https://www.ebay.de/usr/smart-home-komponente

Scheint aber ein normaler Nano zu sein mit Zusatzplatine, also vermute ich kein generelles Problem am FTDI. Wobei man sowas natürlich nie ausschließen kann.
"smartie" kennt das Test-PIN-Thema eigentlich und weiß, dass man bei "normalen" (China-"FTDI"-) Nanos nachlöten _muss_ und checken, dass es wirklich ein FTDI ist (daher auch eine "spezielle" "by-id"-Kennung). Vermutlich ist beim Nachlöten was schiefgegangen...

Zitat von: andies am 25 August 2021, 13:02:22
https://forum.fhem.de/index.php/topic,122159.45.html
Selbe Quelle, aber m.E. ein Lötproblem an einer anderen Stelle. Deutet aber darauf hin, dass er (mal wieder) etwas nachlässig ist mit der Qualitätskontrolle...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

connormcl

Die CULs von Ebay haben bei mir nie stabil funktioniert...hatte nach und nach 3 Stück gekauft, weil mir unklar war, wo der Fehler liegt...Software auf dem CUL, CUL Hardware oder Einbindung und FHEM.

Auf allen drei waren die China-Nano zu sehen wie auf den Ebay Links. Sie haben sich ebenso disconnected oder nicht mehr reagiert.

Seitdem ich die Nanos auf den Platinen gegen teure (7 EUR) aus Europäischer Quelle mit garantiert echtem FTDI getauscht hatte funktioniert alles wie es soll.

Sehr ärgerliche Erfahrung, die man hier im Forum auch immer wieder liest.
Am Ende hat man ein Heidengeld verschwendet um es "einfach" zu haben, wegen dem Funkmodul, von dem es ja auch jede Menge nicht funktionierende/gefälschte gibt, wenn man die selbst besorgen möchte und der praktischen Platine.

tante ju

Zitat von: connormcl am 25 August 2021, 23:41:16
Seitdem ich die Nanos auf den Platinen gegen teure (7 EUR) aus Europäischer Quelle mit garantiert echtem FTDI getauscht hatte funktioniert alles wie es soll.

Wie hast Du die identifiziert? Wo her?
Für 7 EUR finde ich eigentlich nur Chinaware.

connormcl

Zitat von: tante ju am 25 August 2021, 23:53:20
Wie hast Du die identifiziert? Wo her?
Für 7 EUR finde ich eigentlich nur Chinaware.

Das war bei mir vor 3 Jahren. Da war der Markt noch ein anderer und es gab die neuen China-Gesetze und Gebühren noch nicht. Da hatte ein Nano Board 1-2 EUR gekostet.

Das damals "teure" 7 EUR Board hatte ich glaube ich bei Eckstein Komponente gekauft. Müsste das Himalaya Board mit dem FCC Aufdruck sein. Damals wurde das auf Ebay auch mit "original FTDI" beworben.

Zugegebenermassen habe ich nichts selbst identifiziert. Kann auch sein, dass das der gleiche nur sorgfältiger zusammengebaute China-Kram ist. Ich kann nur berichten, dass seit dem Wechsel zumindest bei mir die Probleme aufgehört haben und zwar auf allen meinen 3 von ebay gekauften Nano CULs. Deine Erfahrung kann eine andere sein. Auch kann sich die Qualität oder Typ der Boards seit damals wieder verändert haben.

andies

Ich habe mit Demos die gleiche Erfahrung gemacht...
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: andies am 26 August 2021, 06:43:58
Ich habe mit Demos die gleiche Erfahrung gemacht...
Wemos, nehme ich an?

Grundsätzlich kann man die Liste endlos fortsetzen. Aus meiner eigenen Erfahrung: 3.3V an der Mini-Platine der FTDI-Konkurrenz...? nRF24L+-fakes anyone? Verlässliche Mini-Step-Downs?

Es wird halt gespart, wo es geht, und wo das nicht mehr klappt, wird eben "getrickst", "geklont" oder betrogen.

Was das hier geschilderte Ausgangsproblem angeht, klingt es aber nach wie vor nach einem "simplen" Lötfehler beim Nachlöten der Test-PIN-GND-Verbindung. Das Nachlöten ist btw. nur erforderlich, weil bei der ersten Version der originalen Arduino-Boards ein Design-Fehler drin war...

(Ich hatte das Problem auch mal mit einem ziemlich billigen China-Arduino-Signalduino (Eigenbau), aber nach dem Nachlöten war das Ding grundsätzlich tauglich. Grade hängt aber ein Prologic-based Arduino als Signalduino am Server, daher habe ich keine Lang-Langzeiterfahrung.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

andies

FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

tante ju

Zitat von: Beta-User am 26 August 2021, 07:36:23
Was das hier geschilderte Ausgangsproblem angeht, klingt es aber nach wie vor nach einem "simplen" Lötfehler beim Nachlöten der Test-PIN-GND-Verbindung. Das Nachlöten ist btw. nur erforderlich, weil bei der ersten Version der originalen Arduino-Boards ein Design-Fehler drin war...

Bevor ich jetzt in den Datenblättern suche: weiß jemand as hoc, welcher PIN das ist? Dann löte ich den mal an.

Aber erstmal warte ich darauf, ob der Verkäufer sich meldet. Gibt ja sowas wie Gewährleistung:)

Beta-User

Steht im Wiki bei Arduino - https://wiki.fhem.de/wiki/Arduino#FTDI-Resets:
ZitatBei Arduinos Nanos mit FTDI-USB-seriell-Wandlern kann es vorkommen, dass diese immer wieder scheinbar grundlos rebooten und keine stabile Kommunikation entsteht. In diesesem Fall sollte geprüft werden, ob der TEST-Pin (26) auf Ground liegt. Ist dies nicht der Fall, kann der Fehler dadurch behoben werden, dass der TEST-Pin mit AGND (25) zusammengelötet wird.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors