SIGNALduino - RaspberryPi3 <-> Debian Desktop PC untersch. FHEM Ping - Verhalten

[HomeAuto_User]

Hallo,
ich betreibe zum Test FHEM auf einem Raspberry Pi 3 Model B und parallel an einem Debian Desktop PC.
Da ich selbst in der DEV-Version mit teste, so ist mir folgendes aufgefallen und nicht erklärbar um einen Lösungsansatz zu finden.

Die beiden Geräte, NANO - SIGNALduino und radino - SIGNALduino verhalten sich im Programm unterschiedlich was die Initialisierung der Ports betrifft. Hinzu kommt,
das der Nano am Raspberry Pi das selbe Verhalten wie an dem Debian Desktop PC aufweist ABER der  radino - SIGNALduino sich anders verhält am PI als am Debian Desktop PC.

Gegebenheiten:
Der Nano macht bei einem Start der Schnittstelle

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.03.03
Using sFIFO
Reading values fom eeprom
CCInit
CCVersion=20
CCPartnum=0
Starting timerjob
receiver enabled

und der radino - SIGNALduino nix, bis ich einen Befehl sende.

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.03.03
V 3.3.1-dev Backup_170221 SIGNALduino cc1101 (433Mhz) - compiled at Mar  2 2017 20:17:59

Beide System sind auf der gleichen Version von SIGNALduino.

Der Nano besitz keinen echten USB, da USB-Seriall Wandler.
Der radino, da ist der USB mit im Prozessor.

Sobald ich FHEM neustarte via Shutdown restart oder über das Terminal, so öffnet sich der Nano zum Empfang umgehend und der radino öffnet zwar den Port aber Initialisiert sich nicht. Sobald ich das Gerät vom USB trenne und wieder dran stecke, funktioniert dies.

Wenn ich das FHEM PING Verhalten der Geräte an den Systemen vergleiche, so setzt der radino an einem Desktop PC einen regelmäßigen PING ab (bei keinem Empfang) aber am RaspberryPi erfolgt das nicht.

Da es immer lästig ist, den Stick an bzw. dranzustecken beim testen bzw. weiterentwickeln, so würde ich gern dies hinterleuchen und beheben wollen.
Über eine Mithilfe oder Tips wäre ich sehr erfreut, da es ggf. ins "eingemachte vom Betriebssystem" gehen kann.

MfG

[Sidey]

Soweit ich das jetzt verstehe, wird der atmega32u4 bei Fhem stop / Fhem Start nicht richtig initialisiert.

Was passiert, wenn Du den set Befehl "Reset" ausführst?

Hast Du das Problem auch, wenn Du den raspberry Pi bootest?

[HomeAuto_User]

Hallo,

Soweit ich das jetzt verstehe, wird der atmega32u4 bei Fhem stop / Fhem Start nicht richtig initialisiert.

Korrekt! Nur der State wir auf opened gesetzt und keine Meldungen werden erkannt.

Was passiert, wenn Du den set Befehl "Reset" ausführst?

Das klappt ohne Probleme. Soeben mehrfach getestet.
Nach dem Reset empfängt er normal.

Hast Du das Problem auch, wenn Du den raspberry Pi bootest?

Der Empfang ist normal und geht sofort problemlos.

[RaspiLED]

Hi,
So ein verhalten haben die China Arduinos auch, wenn am FTDI der Test Pin nicht auf Ground gezogen ist. Hat der Raduino auch einen USB to Serial mit Test Pin?
Gruß Arnd


Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...

[HomeAuto_User]

Hallo,

Hi,
So ein verhalten haben die China Arduinos auch, wenn am FTDI der Test Pin nicht auf Ground gezogen ist. Hat der Raduino auch einen USB to Serial mit Test Pin?
Gruß Arnd

Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...

Sowas habe ich schon gelesen aber für nichtig erklärt.
Ohne etwas zu verwechseln, da ich mitlerweile "Overlod" bin  ,
der Radino hat einen ATMEGA32U4 und da hat der Prozessor selbst das USB schon. Datenblatt - Prozessor | Beim Nano Bsp. ist ja ein USB to SERIAL Wandler drin.

Alles was vom "Stick" herausgeführt wurde, siehst du hier.
Demzufolge würde ich sagen, NEIN, sowas gibt es nicht.

[RaspiLED]

Hi, aber im Datenblatt steht doch drin "CPU Reset possible on USB Reset Detection" - Ist das also schon in der Firmware richtig implementiert?
Gruß Arnd


Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...

[HomeAuto_User]

Hi, aber im Datenblatt steht doch drin "CPU Reset possible on USB Reset Detection" - Ist das also schon in der Firmware richtig implementiert?
Gruß Arnd

Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...

Dazu können wir nur Sidey befragen. Er liest ja mit und weiß Bescheid über das Problem.

Ich kann nur für andere Firmware Varianten (CUL, aCul...) sprechen, welche ich getestet habe, da lief es.

[Sidey]

Probier bitte mal folgendes:

Code Auswählen Erweitern


1. fhem shutdown
2. tail -f /dev/serial/by-id/usb-....


und folgendes:

Code Auswählen Erweitern


1. fhem shutdown restart
2. set sduino reset


[HomeAuto_User]

Hallo

Probier bitte mal folgendes:

Code Auswählen Erweitern


1. fhem shutdown
2. tail -f /dev/serial/by-id/usb-....


Es kommt nichts außer ein Zeilenumbruch und dann bleibt dies so stehen. Abbruch nur mit STRG+C

root@raspberrypi:/home/pi# tail -f /dev/serial/by-id/usb-Unknown_radino_CC1101-if00

und folgendes:

Code Auswählen Erweitern


1. fhem shutdown restart
2. set sduino reset


Danach ist der Empfang wieder vorhanden.

2017.03.04 20:37:34 3: sduino_radino reset
2017.03.04 20:37:34 3: Opening sduino_radino device /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2017.03.04 20:37:34 3: Setting sduino_radino serial parameters to 38400,8,N,1
2017.03.04 20:37:34 1: sduino_radino/define: /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@38400
2017.03.04 20:37:34 1: sduino_radino/init: /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@38400
2017.03.04 20:37:34 3: sduino_radino device opened
2017.03.04 20:37:36 3: sduino_radino/init: disable receiver (XQ)
2017.03.04 20:37:36 3: sduino_radino/init: get version, retry = 0
2017.03.04 20:37:36 4: sduino_radino/msg READ: V 3.3.1-dev SIGNALduino cc1101 (433Mhz) - compiled at Mar  3 2017 10:18:18
2017.03.04 20:37:36 2: sduino_radino: initialized. v3.3.1-dev
2017.03.04 20:37:36 3: sduino_radino/init: enable receiver (XE)
2017.03.04 20:37:50 4: sduino_radino/msg READ: MC;LL=-1021;LH=937;SL=-535;SH=437;D=25A2D6443058CAAD5E1A;C=488;L=79;R=14;