Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

Begonnen von Sidey, 02 Oktober 2016, 23:39:11

Vorheriges Thema - Nächstes Thema

Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Wenn z.B. dies empfangen wird, mit welchem ITclock Bereich funktioniert dann das Senden noch? Funktioniert ITclock 350 noch?
MS;P0=-1246;P1=426;P4=1262;P5=-459;P6=-9979;D=16101010101010101010451010101010101010104510451045;CP=1;SP=6;
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Also das Senden funktioniert, aber ob der Empfänger reagiert ist ja eher die Frage.
Dessen Empfindlich kenne ich nicht.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

RaspII

Zitat von: fstefan1960 am 04 März 2017, 21:27:11
AAAaaargh,

beim Versuch, einen neuen Anlauf mit neuer Hardware zu machen, klappt das flashen schon mal nicht. Obwohl ich die aktuellste firmware habe, bricht der flash-Vorgang aus FHEM heraus mit sync-Fehlern ab.
Auf einem anderen PC habe ich dann mit dem direkten avrdude-Aufruf erfolgreich geflasht, so die Rückmeldung des Programms.
Dann wieder an FHEM angesteckt. Hardware-Attribut ist CC1101. Beim Versuch, ccconf abzurufen, kommt die Meldung, "This command is only available with a cc1101 receiver".
Und obwohl ich definitiv diese Datei geflasht habe:
"56423 SIGNALduino_nanoCC1101.hex"
kommt als Version in FHEM:
V 3.3.1-dev SIGNALduino - compiled at Jan 12 2017 23:04:38

Ich meine, da hätte doch sonst in der Versionsbezeichnung auch "CC1101" gestanden ... 
Hat noch einmal jemand einen Link zur aktuellsten Dev.-Firmware mit CC1101-Unterstützung?

:'(




Das Problem ist hier beschrieben:
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino#Bekannte_Probleme_bei_der_Inbetriebnahme_des_SIGNALduino_mit_CC1101

Witziger Weise hatte ich eben mit einem neuen Arduino Nano wieder das selbe Problem, ich musste zur Korrektur heute D10/CSn unterbrechen bevor die Initialisierung geklappt hat (gib mir mal ein Feed Back welche Aktionen Du durchgeführt hast, mit denen es dann bei Deinem System zum Erfolg geführt hat).

RaspII

fstefan1960

#274
Ich bekomme beim Aufruf von "raw e" nur immer "raw: Unsupported command", egal, ob ich alle PINs belegt lasse, D10 oder auch D11 abziehe...

Welche firmware wäre denn eigentlich die richtige für den SIGNALduino mit CC1101?

Ich habe hier die, die ich via update bekomme, nachdem ich

update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt


eingegeben hatte.
Dann update, shutdown restart, Attribut auf "hardware nanoCC1101" und dann geflasht. Als Version zeigt er mir nun
V 3.3.1-dev SIGNALduino - compiled at Jan 12 2017 23:04:38

Ich meine aber, ich hätte früher bereits einmal eine firmware-Version gehabt, in der "nanoCC" im Namen auftauchte.
Mit der gingen auch die "get ccconf" und "get ccreg" Befehle, die jetzt immer nur Fehlermeldungen produzieren.

Auf einen anderen SIGNALduino (der leider auch nicht funktioniert), habe ich noch einmal geschaut. Dort heißt die Firmware
V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38

Die finde ich aber nicht mehr ...
FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.

Ralf9

Zitat von: RaspII am 05 März 2017, 10:15:06
Witziger Weise hatte ich eben mit einem neuen Arduino Nano wieder das selbe Problem, ich musste zur Korrektur heute D10/CSn unterbrechen bevor die Initialisierung geklappt hat
Warst Du wieder zu ungeduldig und hast den Nano geflasht bevor Du den cc1101 vollständig verkabelt hattest?
In den zukünftigen hex Files müsste der Fehler weg sein. Der Fehler ist im Github behoben.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

fstefan1960

Es flasht sich einfach besser, wenn der Arduino noch nicht zwischen all den fliegenden Drähten auf dem breadboard steckt ...

Aber auch, wenn ich das da mache, ist der Erfolg nicht da. Habe gerade eben vor 5 Minuten die firmware noch einmal via update heruntergeladen. Das Protokoll bestätigt, dass die dabei auch tatsächlich neu geladen wurde.
Dann aus FHEM heraus mit vollständigem Aufbau geflasht.

Dabei kam das:
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
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 "./FHEM/firmware/SIGNALduino_nanoCC1101.hex"
avrdude: input file ./FHEM/firmware/SIGNALduino_nanoCC1101.hex auto detected as Intel Hex
avrdude: writing flash (20054 bytes):

Writing | ################################################## | 100% 7.98s

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

Reading | ################################################## | 100% 8.53s

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


Und trotzdem kommt als Version:
V 3.3.1-dev SIGNALduino - compiled at Jan 12 2017 23:04:38
also ohne "nanoCC1101"!

:'( :'( :'( :'(
FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.

Ralf9

V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38
Das cc1101 ist in der Version nur enthalten, wenn während der Initialsierung der cc1101 erkannt wurde.
Der cc1101 Signalduino funktioniert nur mit der Verkabelung vom Selbstbau CUL.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Zitat von: Sidey am 05 März 2017, 08:52:12
Also das Senden funktioniert, aber ob der Empfänger reagiert ist ja eher die Frage.
Dessen Empfindlich kenne ich nicht.

Ok, dann muß ich anders fragen.
Weißt Du zufällig innerhalb welcher ITclock Toleranz die Intertechno Empfänger normalerweise noch reagieren.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

fstefan1960

#279
Ja, ich habe soeben den Aufbau noch einmal kontrolliert. Das passt alles. Dann geflasht ... Nix gelingt ...

Ich krame jetzt noch mal einen anderen CC1101 raus, Bei dem Arduino hab ich schon durchgetauscht ...

Mein Aufbau ist der hier beschriebene mit den Widerständen und in der Version mit 470 / 1000 Ohm.
https://forum.fhem.de/index.php/topic,52865.msg558825.html#msg558825


Der fertig gekaufte hat keine Widerstände drin. Da sich mit dem aber kaum etwas schalten lässt, wollte ich es nun einmal "richtig" machen. Aber wie gesagt, ich bekomme nicht einmal die Firmware ans Laufen ...
FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.

Sidey

Zitat von: Ralf9 am 05 März 2017, 11:37:41
Ok, dann muß ich anders fragen.
Weißt Du zufällig innerhalb welcher ITclock Toleranz die Intertechno Empfänger normalerweise noch reagieren.

Nein, leider nicht. 20% würde ich aber mal annehmen sind kein Problem.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

sash.sc

Hallo zusammen.

ich habe mir nen Signalduino mit dem cc1101 zusammen gebaut. das flashen über den pi hat auch ohne Probleme geklappt.
Nach kurzer Zeit ging er auf closed. 
Habe die Verkabelung des cc1101 nochmal geprüft, soweit alles ok.
habe den sduino dann an den Lappi mit windows10 gehangen. COM Port wurde auch soweit alles erkannt. Habe die ArduinoIDE gestartet, das entsprechende Board eingestellt und den Seriel Minitor gestartet.
Habe dan ein "V" abgesetzt, jedoch keine reaktion.

Habt Ihr noch eine Idee, warum der sduino nicht reagiert?
Gibt es eine Möglichkeit die .hex Datei auch über die Arduino IDE zu flashen (Windows)?
Oder brauche ich dafür den ganzen SourceCode?

Gruß und Danke
Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

fstefan1960

@ sash.sc

Prinzipiell sollte man das flashen auch über WINDOWS machen können. Ich habe es oft erfolgreich über Linux gemacht. Da muss man dann eben die entsprechende *.hex flashen.

Allerdings habe ich das Problem, dass, obwohl der Flashvorgang sauber durchläuft, auch das Verify und damit Erfolg gemeldet wird, am Ende kein funktionierender Stick dabei herauskommt.

Wenn ich den (auch während des Flashens fertig zusammengebauten) SIGNALduino dann in FHEM anhänge, bekomme ich derzeit nicht einmal das GET-Feld zu sehen. Ein dann frisch abgesetztes "SET sduino flash" läuft wieder erfolgreich durch. Es wird auch die ...nanoCC1101.hex geflasht. Dann "SET sduino reset" lässt auch die LED auf dem Arduino aufblinken, aber nach wie vor kommt nicht mal das GET-Feld ...

FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.

Sidey

Zitat von: fstefan1960 am 05 März 2017, 11:25:27
Und trotzdem kommt als Version:
V 3.3.1-dev SIGNALduino - compiled at Jan 12 2017 23:04:38
also ohne "nanoCC1101"!

Sehr seltsam. Der Flash Vorgang sieht eigentlich gut aus. Ich habe die Firmware gerade aktualisiert. Damit hätten wir schon mal das Problem der Erstinitalisierung dann gelöst.


So sieht eine Initalisierung eines Nano mit verbundenem cc1101 Modul aus.
Folgendes habe ich gemacht:
1. Verbose auf 5
2. set flash



2017.03.05 13:01:27.846 3: sduino/init: enable receiver (XE)
2017.03.05 13:01:27.835 5: sduino SW: XE
2017.03.05 13:01:27.834 2: sduino: initialized. v3.3.1-dev
2017.03.05 13:01:27.814 5: sduino/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar  5 2017 12:39:25
2017.03.05 13:01:27.812 4: sduino/msg READ: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar  5 2017 12:39:25
2017.03.05 13:01:27.789 5: sduino SW: V
2017.03.05 13:01:27.784 3: sduino/init: get version, retry = 0
2017.03.05 13:01:27.286 5: sduino SW: XQ
2017.03.05 13:01:27.284 3: sduino/init: disable receiver (XQ)
2017.03.05 13:01:27.257 4: sduino/msg READ: receiver enabled
2017.03.05 13:01:27.213 4: sduino/msg READ: Starting timerjob
2017.03.05 13:01:27.212 4: sduino/msg READ: CCPartnum=0
2017.03.05 13:01:27.210 4: sduino/msg READ: CCVersion=20
2017.03.05 13:01:27.201 4: sduino/msg READ: CCInit
2017.03.05 13:01:27.200 4: sduino/msg READ: Reading values fom eeprom
2017.03.05 13:01:27.190 4: sduino/msg READ: Using sFIFO
2017.03.05 13:01:25.777 3: sduino device opened
2017.03.05 13:01:25.774 1: sduino/init: /dev/ttyUSB0
2017.03.05 13:01:25.772 1: sduino/define: /dev/ttyUSB0
2017.03.05 13:01:25.737 3: Setting sduino serial parameters to 57600,8,N,1
2017.03.05 13:01:25.720 3: Opening sduino device /dev/ttyUSB0
2017.03.05 13:01:08.822 3: sduino: setting Verbose to: 5


An folgenden Zeilen ist zu erkennen, dass ein cc1101 gefunden wurde,

2017.03.05 13:01:27.212 4: sduino/msg READ: CCPartnum=0
2017.03.05 13:01:27.210 4: sduino/msg READ: CCVersion=20
2017.03.05 13:01:27.201 4: sduino/msg READ: CCInit



Wiederhole ich das gleiche und habe den cc1101 nicht angeschlossen ( vcc unterbrochen ) kommt folgendes heraus:


2017.03.05 13:04:09.705 3: sduino/init: enable receiver (XE)
2017.03.05 13:04:09.694 5: sduino SW: XE
2017.03.05 13:04:09.693 2: sduino: initialized. v3.3.1-dev
2017.03.05 13:04:09.673 5: sduino/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-dev SIGNALduino - compiled at Mar  5 2017 12:39:25
2017.03.05 13:04:09.671 4: sduino/msg READ: V 3.3.1-dev SIGNALduino - compiled at Mar  5 2017 12:39:25
2017.03.05 13:04:09.650 5: sduino SW: V
2017.03.05 13:04:09.648 3: sduino/init: get version, retry = 0
2017.03.05 13:04:09.379 4: sduino/msg READ: receiver enabled
2017.03.05 13:04:09.339 4: sduino/msg READ: Starting timerjob
2017.03.05 13:04:09.338 4: sduino/msg READ:
2017.03.05 13:04:09.337 4: sduino/msg READ: no CC11xx found!
2017.03.05 13:04:09.328 4: sduino/msg READ: CCPartnum=0
2017.03.05 13:04:09.327 4: sduino/msg READ: CCVersion=0
2017.03.05 13:04:09.149 5: sduino SW: XQ
2017.03.05 13:04:09.148 3: sduino/init: disable receiver (XQ)
2017.03.05 13:04:09.065 4: sduino/msg READ: CCInit
2017.03.05 13:04:09.064 4: sduino/msg READ: Reading values fom eeprom
2017.03.05 13:04:09.056 4: sduino/msg READ: Using sFIFO


Get version liefert dann wie bei dir einen SIGNALduino ohne cc1101


version: V 3.3.1-dev SIGNALduino - compiled at Mar 5 2017 12:39:25


Nachdem ich den cc1101 wieder verbunden hatte habe ich ein set reset ausgeführt:

2017.03.05 13:05:48.671 3: sduino/init: enable receiver (XE)
2017.03.05 13:05:48.660 5: sduino SW: XE
2017.03.05 13:05:48.659 2: sduino: initialized. v3.3.1-dev
2017.03.05 13:05:48.635 5: sduino/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar  5 2017 12:39:25
2017.03.05 13:05:48.633 4: sduino/msg READ: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar  5 2017 12:39:25
2017.03.05 13:05:48.609 5: sduino SW: V
2017.03.05 13:05:48.608 3: sduino/init: get version, retry = 0
2017.03.05 13:05:48.109 5: sduino SW: XQ
2017.03.05 13:05:48.108 3: sduino/init: disable receiver (XQ)
2017.03.05 13:05:48.086 4: sduino/msg READ: receiver enabled
2017.03.05 13:05:48.041 4: sduino/msg READ: Starting timerjob
2017.03.05 13:05:48.040 4: sduino/msg READ: CCPartnum=0
2017.03.05 13:05:48.039 4: sduino/msg READ: CCVersion=20
2017.03.05 13:05:48.030 4: sduino/msg READ: CCInit
2017.03.05 13:05:48.028 4: sduino/msg READ: Reading values fom eeprom
2017.03.05 13:05:48.019 4: sduino/msg READ: Using sFIFO
2017.03.05 13:05:46.601 3: sduino device opened
2017.03.05 13:05:46.599 1: sduino/init: /dev/ttyUSB0
2017.03.05 13:05:46.598 1: sduino/define: /dev/ttyUSB0
2017.03.05 13:05:46.563 3: Setting sduino serial parameters to 57600,8,N,1
2017.03.05 13:05:46.550 3: Opening sduino device /dev/ttyUSB0
2017.03.05 13:05:46.545 3: sduino reset


Der cc1101 wurde erkannt und alles funktioniert wie erwartet.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

pejonp

Fstefan1960,
Hast du nur einen Nano am raspberry oder mehrere ? Stimmt der Port ? Ich denke das wirst du schon kontrolliert haben. In deinem flash-log sieht man nicht den Port bzw. Der log ist nicht vollständig.

Pejonp
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect