Signalduino Entwicklung

[Ralf9]

Den sduino und den jeelink kann ich nur zum Leben erwecken, wenn ich die beiden sticks vom USB abziehe und wieder dran stecke.

Hast Du schon mal getestet ob ein reset mit dem Taster oder mit "set sduino reset" auch ausreicht?

Gruß Ralf

[sash.sc]

Mir den set sduino Reset klappt nicht!

Von mobil gesendet daher kurze Antwort

[habeIchVergessen]

mmh. hupcl ist immer gesetzt.

[Sidey]

Hallo,
Ich nutze Arduino 1.6.5 und Win10 64Bit.
Ich habe mir die Dateien von hier geholt: https://github.com/RFD-FHEM/SIGNALDuino
Aber wie beim Fhemduino einfach mal machen geht nicht.

Hallo Funsailor,

das Projekt ist für Visual Micro angelegt.
Leider sind die IDEs nicht sonderlich kompatibel untereinander. Mit der Arduino IDE wirst Du viel händisch anpassen müssen, damit es geht.

Du kannst das hex File mit avrdude direkt aufbrennen. Das geht auch unter Windows.

Grüße Sidey

[Sidey]

In dem log hat es einige fehlerhafte Nachrichten. @Sidey, kannst Du damit was anfangen?

Nicht so richtig.
Ich bin mir leider nicht so sicher, was fehlerhaft ist....
Einer der MU Nachrichten sehe ich mir gerade mal etwas genauer an.

Grüße Sidey

[Burny4600]

@sash.sc

Fhem wird ja automatisch gestartet.

Wie hast du diesen automatischen Start definiert?
Bei mir funktioniert das nicht mit dem aktuellen Jessie.

Gibt es schon eine neue SignalDuino Firmware die ich mit den Origone Sensoren testen kann?
Derzeit habe ich noch die b22.

[sash.sc]

Über ein Script im init.d verzeichnis. Es gibt verschiedene Anleitungen dazu. Schreibe was heute abend dazu. Bin unterwegs

Von mobil gesendet daher kurze Antwort

[Sidey]

Moin,

zum Thema Reboot und initialisieren:

Habe gestern mit einem Arduino mit ch340 Chip getestet.

Arduino steckt direkt am rpi 2.
Reboot des rpi durchgeführt.
Fhem wird über ein Startscript geladen. Der Signalduino ist nach dem Reboot opened und funktioniert.

Werde die Tage den Test mit einem Arduino mit FTDI Chip wiederholen.

Zum Thema Firmware / Oregon:
Ich habe im Moment keine Idee, wo der Fehler sitzen könnte.
Schwierig. Vielleicht muss ich mir mal so einen Sensor besorgen oder einen nachbauen.

Grüße Sidey

[hjgode]

Danke für die Info. Finde es nur komisch, dass es bei den anderen selbstbau sticks funktioniert.

Nanocul 443 läuft
Nanocul 868 läuft
Nanocul /jeelink läuft nicht
Nanocul /sduino läuft nicht

Alle haben einen ftdi Chip drauf und machen soweit keine Probleme. Alle nano v3 sind in Deutschland bestellt worden.

Die beiden nanocul sind mir der a-fw betankt.

Gruß Sascha

Gesendet von meinem SM-T560 mit Tapatalk

Hallo Sascha

hast Du alle Nanos gleichzeitig gekauft? Sind die alle von der Hardware und dem Aussehen gleich?

Es gibt leider auch in Deutschland-Versender die Nanos mit Fake-FTDI (China Zeugs) verkaufen. Die Dinger kann man besten erkennen, wenn man die unter Windows anschließt und die FTDI Treiber laden lässt. Bei den Fake Chips kommt dann serial immer nur wiederholt "Not a genuine product".

Meine Fake FTDI Nanos sind nacheinander mit den unschiedlichsten Symptomen aufgefallen oder 'gestorben': Initialisieren nicht, Serial geht gar nicht mehr, ...

gruss

Josef

[sash.sc]

Jeweils 2 sind beim gleichen Shop bestellt worden. 1x 2 Stück gleichzeitig und die anderen beiden sind im gleichen Shop zu verschiedenen Zeiten bestellt worden. Die die aus dem gleichen Shop kommen,  sehen identisch aus. Die anderen beiden nicht. Werde nach dem langen Wochenende mal unter windows testen, was da so passiert!

Danke für den Tipp!

Gruß Sascha

[Apateonas]

Guten Morgen,
steckt die Dinger mal auf einen aktiven USD-Hub und schaut unter /dev/serial/by-path/ . Die Fakes haben alle die selbe Serial-ID.
Beispiel:
ll /dev/serial/by-id/
lrwxrwxrwx 1 root root 13 Mai  2 20:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Mai  2 20:17 usb-busware.de_CUL433-if00 -> ../../ttyACM0

ll /dev/serial/by-path/
lrwxrwxrwx 1 root root  13 Mai  2 20:17 platform-20980000.usb-usb-0:1.3.1:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root  13 Mai  2 20:17 platform-20980000.usb-usb-0:1.3.4:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 Mai  2 20:17 platform-20980000.usb-usb-0:1.3.5:1.0-port0 -> ../../ttyUSB1
Wie man sieht, sind hier die USB-Ports nummeriert 0:1.3.1:1.0, :1.3.4:1.0, 0:1.3.5:1.0
Also, nicht mehr umstecken.

ll /dev/ttyU*
crw-rw---- 1 root dialout 188, 0 Mai  2 23:08 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Mai  2 22:56 /dev/ttyUSB1

In Fhem:
define sduino SIGNALduino /dev/serial/by-path/platform-20980000.usb-usb-0:1.3.4:1.0-port0
define nanoCUL CUL /dev/serial/by-path/platform-20980000.usb-usb-0:1.3.5:1.0-port0@38400 0000

Ich hoffe mein erster Beitrag hilft ein wenig.

[sash.sc]

Die werden alle von Linux mit einer eigenen id erkannt!

[Ellert]

Ich habe Somfy RTS (433 Mhz) Rolläden und steuere sie über FHEM mit RFXTRX433E (nanoCUL433 geht auch). Der Empfang der Handsender ist damit nicht möglich.
Der Empfang ist mit dem FHEMduino möglich, es gibt auch ein Modul dafür. Leider benötigt man einen zusätzlichen USB-Port.

Ich würde gern Somfy RTS mit dem SIGNALduino empfangen, da ich bereits einen SD in mein System eingebunden habe und kein Port am Pi2 mehr frei ist.

Somfy soll eine MC-Kodierung haben ein. Folgende Grundlagen habe dazu zusammengetragen.

Gemäss der SomfyRTS.cpp vom FHEMduino ist das so aufgebaut:

message format: Y <key-2-hex> <cmd-2-hex> <rollingcode-4-hex> <address-6-hex>

// set message ready when checksum is correct
if ( (checkSum & 0x0F) == 0 ) {
// # message looks like this
// # Ys_key_ctrl_cks_rollcode_a2a1a0
// # Ys ad 20 0ae3 a29842
// # address needs bytes 1 and 3 swapped
// # lenght is 2+1 2+1 2+1 4+1 6 = 20

In der SomfyRTS.h sind folgende Timings definiert:

// Timings and limits
#define LOW_FACTOR 0.7
#define HIGH_FACTOR 1.4

#define TIME_FULL_SYMBOL_LOW   (1280 * LOW_FACTOR)
#define TIME_FULL_SYMBOL_HIGH  (1280 * HIGH_FACTOR)

#define TIME_HALF_SYMBOL_LOW   (640 * LOW_FACTOR)
#define TIME_HALF_SYMBOL_HIGH  (640 * HIGH_FACTOR)

#define TIME_PRESYNC_LOW   (2416 * LOW_FACTOR)
#define TIME_PRESYNC_HIGH  (2416 * HIGH_FACTOR)

#define TIME_SYNC_LOW   (4550 * LOW_FACTOR)
#define TIME_SYNC_HIGH  (4550 * HIGH_FACTOR)

#define MIN_PRESYNC_COUNT 4

Für den CUL gibt es eine Senderoutine, in der somfy_rts.c mit folgenden Hinweisen:

// Somfy RTS bits are manchester encoded: 0 = high->low
// Somfy RTS bits are manchester encoded: 1 = low->high
// send hardware sync (pulses of ca. double length)
// send software sync (4 x symbol width high, half symbol width low)

// input is in format: Ys_key_ctrl_cks_rollcode_a0_a1_a2
// Ys ad 20 0ae3 a2 98 42

// create somfy frame from the given input
// 0   |    1     |   2     3    | 4   5   6
// key | ctrl+cks | rolling_code | address

Somfy symbol width: 1240

Der Empfang der Rohnachricht von Somfy gelingt fast nie mit Firmwareversion: V 3.2.0-b17, nur MC aktiviert
Ich simuliere einen Handsender mit dem SOMFY-Modul und sende über nanoCUL433 mit

define somfy SOMFY 12389A
Adresse: 12389A
Befehl stop:10 (11)
Schlüssel: Ax
RolingCodeNr.: 000x

FHEMduino empfängt RAWMSG: Ys ax 10 000x 9a3812, 9a ist mit 12 der Adresse getauscht.

Die mit dem Logikanalysator aufgenommenen Signale habe ich angehängt.

Was kann ich machen, damit Somfy RTS mit dem Signalduino empfangen werden kann?

Gruß
Ellert

[sash.sc]

Mit welcher baudrate soll der sduino definiert werden? Ist das egal?

Gruß Sascha

Gesendet von meinem SM-T560 mit Tapatalk

[habeIchVergessen]

@sash.sc: mit einem Nano benutze ich 57600 baud