Signalduino Entwicklung

[Sidey]

Zu erkennen an einigen FF am Anfang gefolgt von einer 5.

Auf das FF 5 am Anfang würde ich nicht zu sehr setzen. Da muss der Empfang nur um ein Bit verschoben sein und schon kommen andere Werte in Hex raus.

Grüße Sidey

[Sidey]

Hi Burny,

Ist es eigentlich normal das der SIGNALduino sich ca. jede Minute mit einer Initialisierung meldet.

Das mit dem initalized im Minutentakt ist ein Fehler.
Das passiert, wenn die USB Verbindung abbricht oder der Arduino abstürzt.

Das Problem hatten bereits einige Anwender. Die Ursachen sind vielfältig. Es kann am Arduino liegen oder am USB Kabel oder sonst was.
Leider hilft dir das jetzt nicht weiter.

Grüße
Sidey

[Burny4600]

Ich vermute das liegt am Umgang der USB Schnittstellen.

Aus mangel an USB Schnittstellen habe ich den SIGNALduino an einem USB HUB angeschlossen.

Die nanoCUL's brechen an einem USB Hub die Verbindung ab und melden sich nicht mehr an bis ein Hardware Reset erfolgt (Spannungslos machen des RASPBERRY und USB HUB).
Der SIGNALduino führt zumindest eine Initialisierung aus.

FHEM oder der RASPBERRY haben mit USB-HUB's anscheinend ein Problem.

[Pythonf]

Ich habe einen Interessanten Eintrag mit Namens: "CUL_TCM97001_Unknown" welcher wie folgt aussieht:

Code Auswählen Erweitern

Internals:
   CODE       Unknown
   DEF        Unknown
   LASTInputDev sduino
   MSGCNT     11
   NAME       CUL_TCM97001_Unknown
   NR         210
   STATE      Code: 592806A150
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1448912565.79988
   sduino_DMSG s592806A15000
   sduino_MSGCNT 11
   sduino_RAWMSG MS;P0=-1929;P1=512;P2=-3879;P3=-9150;D=13101210121210101210101210121010101010101010121210121012101010101210121012;CP=1;SP=3;O;
   sduino_TIME 2015-11-30 20:42:45
   Readings:
     2015-11-30 20:42:45   state           Code: 592806A150
Attributes:
   model      Unknown
   room       CUL_TCM97001
Vielleicht kann mir jemand erklären, um was es sich handeln könnte?

[Ralf9]

Auf das FF 5 am Anfang würde ich nicht zu sehr setzen. Da muss der Empfang nur um ein Bit verschoben sein und schon kommen andere Werte in Hex raus.

Ja, das ist klar, daß es mit dem FF 5 nicht immer passt, aber es müssten bei brauchbarem Empfang am Anfang normalerweise ein paar FF sein.

In den log habe ich von 2 Sensoren Nachrichten gefunden bei denen es passt:

Code Auswählen Erweitern


MC;LL=-1043;LH=908;SL=-560;SH=414;D=FFFFFF5F1426100A040E41C27700;C=440;
MC;LL=-1269;LH=692;SL=-762;SH=283;D=FFFFFF5F1424C3020002C1824900;C=324


F142 ist die SensorID gefolgt von dem Kanal 6 + 4

Beim Kanal steht:

Code Auswählen Erweitern

Some Sensors use the coding 1 << (ch – 1), where ch is 1, 2 or 3.
ist dann 4 und 6 Kanal 3 und 4?

Was bei der  SensorID steht kapiere ich nicht:

Code Auswählen Erweitern

Nibble values in these codes assume LSB first order. That is, if the bits of a nibble in order of transmission are '0101',
the hex value is taken to be 'A' (not '5').
The nibbles are presented in order of transmission. However, since all other multi-nibble data in the sensor data message is sent least-significant nibble
first these values might be considered "backwards". In other words, the ID code "1D20" shown above might be more properly called "02D1".
That said, this description describes the code nibbles in order of transmission.


Das F142 könnte der THGR810  mit der ID F824 sein.

Hier sind die Sensoren mit ihren IDs:

PCR800   2914
THGR810  F824
THWR800  C844
UVN800   D874
WGR800   1984 oder 1994


@Burny4600

was für ein Empfänger verwendest Du beim Signalduino. Evtl werden ein paar Sensoren nicht so gut empfangen.

Gruß Ralf

[RappaSan]

Was bei der  SensorID steht kapiere ich nicht:

Code Auswählen Erweitern

Nibble values in these codes assume LSB first order. That is, if the bits of a nibble in order of transmission are '0101',
the hex value is taken to be 'A' (not '5').
The nibbles are presented in order of transmission. However, since all other multi-nibble data in the sensor data message is sent least-significant nibble
first these values might be considered "backwards". In other words, the ID code "1D20" shown above might be more properly called "02D1".
That said, this description describes the code nibbles in order of transmission.


Heißt doch nur, daß alle Bits in LSB order und Halbbyte gesendet werden. Also 1101 (Hex D) heißt in Wirklichkeit rückwärts 1011 (Hex B) .
Und 1D20 wird genauso rückwärts gelesen, also 02D1.

[Ralf9]

Ich habe mal mit der OSV3 (Oregon v3) Protokoll erkennung angefangen.
Wenn ein OSV3 Protokoll erkannt wird erscheint bei verbose 5 im log:

Code Auswählen Erweitern

2015.11.30 22:00:06 4: Found manchester Protocol id 10 clock 324 -> OSV2o3
2015.11.30 22:00:06 5: sduino: OSV3 protocol detected: preamble_pos = 24, message_length = 88

Es fehlt noch die Umwandlung von Bit nach Hex und die Übergabe ans Oregon Modul.

Ich habe es in den dev-r32 Branch eingebaut

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

Gruß Ralf

[Burny4600]

@Ralf9

Ich verwende diesen Empfänger der eigentlich als bester Empfänger empfohlen wurde.
http://www.ebay.at/itm/281782855830?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Kann aber gerne einmal einen Versuch mit diesem Empfänger machen.
http://www.ebay.at/itm/321504040911?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT


Ein Problem habe ich beim flashen unter FHEM was immer zu Fehlern führt:

Code Auswählen Erweitern

flashing Arduino sduino
hex file: ./FHEM/firmware/SIGNALduino_nano328.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D7H7-if00-port0
log file: ./log/SIGNALduino-Flash.log
sduino closed
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D7H7-if00-port0 -p atmega328p -vv -U flash:w:./FHEM/firmware/SIGNALduino_nano328.hex 2>./log/SIGNALduino-Flash.log

--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 6.1, compiled on Jul  7 2015 at 10:29:47
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D7H7-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x02
         Hardware Version: 2
         Firmware Version: 1.16

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x4d

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x55

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x3b

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x50

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x30
         Vtarget         : 519654.4 V
         Varef           : 199312628.4 V
         Oscillator      : 0.002 Hz
         SCK period      : 581284.8 us


avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x3d

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x2d
avrdude: stk500_initialize(): (a) protocol error, expect=0x14, resp=0x32
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x32

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

sduino opened

Auf der Console funktioniert es aber.

Code Auswählen Erweitern

pi@ccs-ht-rasp ~ $ sudo avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D7H7-if00-port0 -p atmega328p -vv -U flash:w:/opt/fhem/FHEM/firmware/SIGNALduino_nano328.hex

avrdude: Version 6.1, compiled on Jul  7 2015 at 10:29:47
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D7H7-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/opt/fhem/FHEM/firmware/SIGNALduino_nano328.hex"
avrdude: input file /opt/fhem/FHEM/firmware/SIGNALduino_nano328.hex auto detected as Intel Hex
avrdude: writing flash (18784 bytes):

Writing | ################################################## | 100% 5.20s

avrdude: 18784 bytes of flash written
avrdude: verifying flash memory against /opt/fhem/FHEM/firmware/SIGNALduino_nano328.hex:
avrdude: load data flash data from input file /opt/fhem/FHEM/firmware/SIGNALduino_nano328.hex:
avrdude: input file /opt/fhem/FHEM/firmware/SIGNALduino_nano328.hex auto detected as Intel Hex
avrdude: input file /opt/fhem/FHEM/firmware/SIGNALduino_nano328.hex contains 18784 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.86s

avrdude: verifying ...
avrdude: 18784 bytes of flash verified

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

pi@ccs-ht-rasp ~ $



Hat sich da wirklich etwas geändert?
http://forum.fhem.de/index.php/topic,38831.msg367615.html#msg367615

Mein SIGNALduino gibt immer noch diese Version aus.
V 3.2.0-b3 SIGNALduino - compiled at Nov 13 2015 21:39:55

[Ralf9]

@Ralf9

Ich verwende diesen Empfänger der eigentlich als bester Empfänger empfohlen wurde.
http://www.ebay.at/itm/281782855830?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Kann aber gerne einmal einen Versuch mit diesem Empfänger machen.
http://www.ebay.at/itm/321504040911?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Der Empfänger ist perfekt.
Evtl sind einige Sensoren zu weit vom Empfänger weg.
Mit einer einfachen Drahtantenne geht bei mir maximal eine Wand/Decke.
Du kannst Dir mal dies anschauen:
http://forum.fhem.de/index.php/topic,38831.msg347043.html#msg347043

Gruß Ralf

[Sidey]

@Burny,

Du verwendest den richtigen Empfänger. Den anderen kannst Du vergessen.

Was das flashen angeht, ist das ja sehr seltsam.
Kann es sein, dass der system user, unter dem fhem läuft nicht ausreichend Rechte auf den seriellen Port hat?


@Ralf:
Das mit dem Umwandeln schaue ich mir gerne an.
Ich habe die letzten Tage an einem Manchester Encoder gearbeitet. Das Senden klappt mittlerweile auch ganz gut.

Dabei  bin ich auf ein Design Fehler im decoder gestoßen.

Es sieht für mich aktuell so aus, dass es passieren kann, dass der decoder das 1. Bit falsch erkennt und danach alles invertiert ist.
Bei osv2 fällt das nicht so auf. Wieso das beim Hideki klappt weiss ich auch noch nicht.
Das OSV3 könnte von der Problematik betroffen sein.

Grüße Sidey

[Ralf9]

Es sieht für mich aktuell so aus, dass es passieren kann, dass der decoder das 1. Bit falsch erkennt und danach alles invertiert ist.
Bei osv2 fällt das nicht so auf. Wieso das beim Hideki klappt weiss ich auch noch nicht.
Das OSV3 könnte von der Problematik betroffen sein.

Kann dies die Auswirkung haben, daß das Hideki und das OSV3 momentan nur bei sehr guten Empfangsverhältnissen funktioniert?

Gruß Ralf

[Burny4600]

@Sidey

Kann es sein, dass der system user, unter dem fhem läuft nicht ausreichend Rechte auf den seriellen Port hat?

Wie kann ich das überprüfen?

@Ralf9

Evtl sind einige Sensoren zu weit vom Empfänger weg.

Habe bei beiden Empfängern diese Antenne in Verwendung:
DeLock ISM 433 MHz Antenna - Antenne - 2.5 dBi
Der nanoCUL empfängt alles ausser halt die Oregon Sensoren.
Die Entfernung zu dem SIGNALduino ist auch bei weitem kürzer als es bei anderen Empfänger wie der WMR200 oder der XS1 ist. Damit sollte eigentlich der SIGNALduino ohne Probleme zurecht kommen.
Zudem empfängt der SIGNALduino die IT Kompontenten.

Anhand der LED's des RFXtrx433 und des nanoCUL im Vergleich zum SIGNALduino spielt sich am SIGNALduino bei weitem mehr ab was da rein kommen sollte.

[Ralf9]

@Ralf9
Habe bei beiden Empfängern diese Antenne in Verwendung:
DeLock ISM 433 MHz Antenna - Antenne - 2.5 dBi
Die Entfernung zu dem SIGNALduino ist auch bei weitem kürzer als es bei anderen Empfänger

Die Empfangsprobleme liegen evtl  auch daran:

Dabei  bin ich auf ein Design Fehler im decoder gestoßen.

Es sieht für mich aktuell so aus, dass es passieren kann, dass der decoder das 1. Bit falsch erkennt und danach alles invertiert ist.
Bei osv2 fällt das nicht so auf. Wieso das beim Hideki klappt weiss ich auch noch nicht.
Das OSV3 könnte von der Problematik betroffen sein.

Hat sich da wirklich etwas geändert?

Mein SIGNALduino gibt immer noch diese Version aus.
V 3.2.0-b3 SIGNALduino - compiled at Nov 13 2015 21:39:55

Dies ist die SIGNALduino Version auf dem Arduino.
Die Änderungen sind in der 00_SIGNALduino.pm in fhem.

Wenn Du im log nach 'OSV3 protocol detected' suchst, kannst Du sehen welche Nachrichten als OSV3 erkannt wurden.

Gruß Ralf

[Burny4600]

OSV3 protocol detected Einträge sind zumindest vorhanden.

[Ralf9]

OSV3 protocol detected Einträge sind zumindest vorhanden.

Hallo Burny,

so wies aussieht, werden einige Oregon v3 empfangen.

Hier sind einige raw Sensor ID:
F142
3122
8912

Interessant wäre, ob nach der Umwandlung

Code Auswählen Erweitern

Nibble values in these codes assume LSB first order. That is, if the bits of a nibble in order of transmission are '0101',
the hex value is taken to be 'A' (not '5').
The nibbles are presented in order of transmission. However, since all other multi-nibble data in the sensor data message is sent least-significant nibble
first these values might be considered "backwards". In other words, the ID code "1D20" shown above might be more properly called "02D1".
That said, this description describes the code nibbles in order of transmission.
Sensor ID rauskommen die hier enthalten sind:

PCR800   2914
THGR810  F824
THWR800  C844
UVN800   D874
WGR800   1984 oder 1994

Das debug Attribut kannst Du wieder löschen, dann wird der log übersichtlicher.

Nachtrag:
hier sind die Werte vom Oregon Modul:

Code Auswählen Erweitern

ID   OREGON_type_length_key
PCR800 (0x2a19, 92)
THGR810 (0xfa28, 80)
UVN800 (0xda78, 72)
WGR800 (0x1a89, 88)

Irgendwas passt mit den Sensor ID nicht. Die raw Sensor ID in den Nachrichten scheinen nicht zu den Sensor ID der Sensoren zu passen.

@Sidey
Kann dies mit dem Design Fehler im decoder zusammenhängen?

Gruß Ralf