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

stefanru

#255
Hi,

ich hoffe ich bin hier richtig.

Ich habe eine sduino mit cc1101 und einen ohne.
Außerdem einen CUL.

Ich schalte ein Somfy lichtrelais bei dem der enc teil fix ist.
Dafür gab es eine Anpassung im Somfy modul.

Es tut wunderbar mit dem sduino ohne cc1101. Wenn ich sende steht dieses im Log:
2017.02.02 22:58:47 4: sduino/set: sending via SendMsg: SC;R=9;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A08D8936AA9344;
2017.02.02 22:58:47 4: sduino SendFromQueue: msg=SC;R=9;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A08D8936AA9344;

Nun habe ich ab und zu ein reichweiten Problem und wollte es mit dem sduino mit cc1101 probieren. Leider ohne Erfolg. Auch der CUL geht nicht.
Nun habe ich gelesen dass der CUL mit cc1101 auf 433,42 umschaltet beim senden. Der Sduino wohl auch mit F= am ende.
Die Umschaltung passiert da Somfy normal auf 433,42 hört. Ich bilde mir ein das Lichtrelais nicht. Ich schaue das am WE mal genau nach.

Ich wollte nun aber schon mal probieren ob etwas passiert wenn ich den Sduino mit cc1101 ohne frequenzanpassung den Somfy befehl senden lasse.
Also habe ich obige sendmsg einfach als sendmsg beim sduino mit cc1101 senden wollen.
Dabei ist aber nichts passiert. Ist es richtig einfach den string SC;R=9;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A08D8936AA9344; in das Feld hinter set sendmsg einzugeben?

Wie könnte ich noch verhindern dass der sduino mit cc1101 die frequenz bei somfy ändert?

Gruß und Danke,
Stefan


P.S.:
Sorry, ist wohl hier auch nicht ganz richtig hänge die Frage nochmal hier an:
"Signalduino + Somfy"
https://forum.fhem.de/index.php/topic,64141.msg575860.html#msg575860

hanshome

Hi,

ich habe jetzt noch mal ausprobiert meinen nanoCUL mit CC1101 auf signalduino umzuflashen. Hierzu habe ich die Version aus https://forum.fhem.de/index.php/topic,58397.msg571078.html#msg571078 genommen. Aber ich den gleichen Effekt wie stefanru, das Senden funktioniert nicht. Und der Empfang auch nur ganz sporadisch, zumindest mit IT-Komponenten. V1 ging so 50%, ein V3-Schalter nur so bei 10% der Betätigungen. Das Log ist ganz seltsam, auf Level 5 gestellt, wird manchmal ganz normal geloggt, manchmal minutenlang gar nichts, was eigentlich nicht sein kann *). Interessanterweise wird ein X10-Bewegungsmelder anscheinend regelmäßig erkannt. Allerdings gibt es hierzu auch keine Einträge im Logfile, in der Oberfläche ändert sich aber der Status gemäß Bewegungsmelder.

*) Ich habe jetzt wieder zurückgeflasht auf nanoCUL und auch den Signalduino mit RXB6 wieder verbunden. Die IT-Schalter werden jedes mal korrekt erkannt und ich habe hier 30sec-Rhythmus Einträge im Logfile auf Level 5 vom Signalduino.

Für mich sieht das so aus, als ob die Dev-Version irgendwie "faul" ist. Ich kann aber keine richtige Fehlermeldung erkennen und kein richtig nachvollziehbares Verhalten.


RaspII

Hi,
bei mir funktioniert der Signalduino mit CC1101 einwandfrei.
Ich habe die NanoCUL Hardware allerdings mit 470/1000 Ohm Spannungteiler (anstelle von 4,7/10k) für die 3V3 Pegelanpassung aufgebaut
(mit dem Hochohmigen Spannungsteiler gab es wohl Probleme)

Getestet habe ich das mit Brennerstuhl IT Steckdosen und mit SOMFY RTS Rolläden.

Hattest Du die aktuellen SDUINO Updates in FHEM installierunt und FHEM neu gestartet?

Weiter Infos hierzu findest Du hier :
http://forum.fhem.de/index.php/topic,24158.msg574267.html#msg574267
https://forum.fhem.de/index.php/topic,64141.msg553811.html#msg553811
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino#HW-Variante_mit_CC1101_Transceiver

RaspII

hanshome

#258
Mmmhhhh, ich habe gar keinen Spannungsteile verbaut  :-\, stand auch irgendwo im Wiki. Funktioniert bei mir mit dem nanoCUL problemlos. Vielleicht sollte ich das mal umbauen, nicht dass das die Probleme macht.

Und ja ich denke ich habe die aktuellste Version. Ich habe das Update von hier:update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txtund anschließend ein shutdown restart gemacht.

Wie kann ich denn rausfinden welche Version des Signalduinomoduls ich gerade verwende? Sidey hatte irgendwas mit X10 hinzugefügt, siehe irgendwo hier weiter vorne. Danach hatte ich aktualisiert, da ich X10 auch benötige.

EDIT: In der 00_SIGNALduino.pm steht
# $Id: 00_SIGNALduino.pm 13215 2017-01-23 20:09:44Z Sidey $

RaspII

#259
Ohne Spannungsteiler  sollte man den NanoCUL (wenn der Arduino Nano 16Mhz, 5V) wie im Wiki beschrieben verbaut ist nicht aufbauen.
Die Version siehst Du in FHEM unter dem SDUINO Device sehen. Am besten mal posten was dort angezeigt wird

Gesendet von meinem SM-G900F mit Tapatalk
RaspII

hanshome

Du meinst das hier?
Internals:
   Clients    :IT:CUL_TCM97001:OREGON:CUL_TX:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_WS_Maverick:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04VCKX-if00-port0@57600
   DMSG       W37#9515564B4B
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04VCKX-if00-port0@57600
   FD         25
   MSGCNT     6320
   NAME       sduino
   NR         59
   PARTIAL
   RAWMSG     MU;P0=-518;P1=457;P2=-276;P3=214;P4=-1027;P5=700;P6=-764;D=01230301230121230123030123012123456565656123030123012301230303012301230123012301230121230301230301230121230123030123012123456565656123030123012301230303012301230123012301230121230301230301230121230123030123012123456565656123030123012301230303012301230123;CP=3;O;
   STATE      opened
   TIME       1486212044
   TYPE       SIGNALduino
   unknownmessages
   version    V 3.3.1-dev SIGNALduino - compiled at Jan  3 2017 23:59:32


Die Version der Firmware habe ich aber nie geändert, die verwende ich schon seit zwei/drei Wochen. Irgendwo hatte Sidey auch geschrieben, dass sich die Firmware nicht geändert hätte. Nur wenn ich die Module aus dem Dev-Zweig nehme, bekomme ich so seltsame Probleme. Oder passt die Firmware doch nicht zu den neuen Modulen?

hanshome

Habe gerade noch mal ein wenig getestet:
Die Version des SIGNALduino ist immer gleich, sie oben.

Mit der folgenden Version der 00_SIGNALduino.pm funktioniert alles einwandfrei, ausser eben X10-Empfang
00_SIGNALduino.pm 13215 2017-01-23 20:09:44Z

Mit dieser Version aus dem Dev-Pfad funktioniert zwar der X10-Empfang, aber ich bekomme seltsame Fehlermeldungen, s.u.
00_SIGNALduino.pm 10484 2017-01-22 15:00:00Z v3.3.1-dev

Fehlermeldunge z.B.
2017.02.04 15:02:41 3: sduino: Unknown code u6#0700140CA, help me!
2017.02.04 15:02:43 2: After sleep: Unknown argument Unknown:, choose one of off:noArg on:noArg  on-for-timer intervals on-till on-till-overnight blink off-for-timer off-till off-till-overnight toggle
2017.02.04 15:02:43 3: nanoCUL IT_set: Steckdose2 off
2017.02.04 15:02:43 3: sduino IT: Steckdose2 off->off


Die Steckdose wird auch nicht geschaltet.

killah78

Hi,
ich möchte mir in Kürze einen Signalduino auf CC1101 868 MHz zusammenbauen. Diesen würde ich gerne einsetzen mit einer Wetterstation a la WH1080, welche ja grundsätzlich funktioniert. Hat denn jemand auch schon die WH4000 damit genutzt? Ich verstehe die WH4000 Pass18c als die 868MHz Version zur WH3080 welche ja auf 433MHz sendet.
Würde gerne die 4000 nehmen, da diese UV und Lichtsensor hat, die 1080 aber nicht.

Wäre um eine kurze Antwort dankbar, da ich die Aussenstation noch nicht gekauft habe.

Gruss
killah78

pejonp

Zitat von: killah78 am 15 Februar 2017, 14:58:00
...
ich möchte mir in Kürze einen Signalduino auf CC1101 868 MHz zusammenbauen..... Wetterstation a la WH1080, welche ja grundsätzlich funktioniert. Hat denn jemand auch schon die WH4000 damit genutzt? Ich verstehe die WH4000 Pass18c als die 868MHz Version zur WH3080 welche ja auf 433MHz sendet.
Würde gerne die 4000 nehmen, da diese UV und Lichtsensor hat, die 1080 aber nicht.
....
Hallo Killah78,

bei den WH1080 gib es 2 Versionen 868 MHz OOK/ASK und FSK (siehe hier https://forum.fhem.de/index.php/topic,39451.msg472672.html#msg472672).
Die WH1080 mit OOK/ASK kannst du mit einem CC1101 868MHz empfangen. Die FSK-Version mit einem JeeLink bzw. mit dem LaCrossGateway (https://forum.fhem.de/index.php/topic,43672.0.html). In wieweit die WH4000 dort empfangen wird, weis ich nicht.
Welche Modulation hat die WH4000 ?

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

killah78

Zitat von: pejonp am 15 Februar 2017, 16:10:38
Hallo Killah78,

bei den WH1080 gib es 2 Versionen 868 MHz OOK/ASK und FSK (siehe hier https://forum.fhem.de/index.php/topic,39451.msg472672.html#msg472672).
Die WH1080 mit OOK/ASK kannst du mit einem CC1101 868MHz empfangen. Die FSK-Version mit einem JeeLink bzw. mit dem LaCrossGateway (https://forum.fhem.de/index.php/topic,43672.0.html). In wieweit die WH4000 dort empfangen wird, weis ich nicht.
Welche Modulation hat die WH4000 ?

pejonp
Hallo pejonp,
Ich habe diesen wh4000 ja noch nicht gekauft, würde diesen aber dem wh1080 vorziehen, wegen des UV Sensors. Ich kann da auch nur raten, deshalb wollte ich fragen, ob es damit Erfahrung in Verbindung mit dem signalduino gibt.
Vielleicht einfach Mal das Risiko eingehen und dann vielleicht noch etwas Entwicklung betreiben.
Gruss
Killah78

Gesendet von meinem ONEPLUS A3003 mit Tapatalk


pejonp

Zitat von: killah78 am 15 Februar 2017, 17:23:55
Hallo pejonp,
Ich habe diesen wh4000 ja noch nicht gekauft, würde diesen aber dem wh1080 vorziehen, wegen des UV Sensors. Ich kann da auch nur raten, deshalb wollte ich fragen, ob es damit Erfahrung in Verbindung mit dem signalduino gibt.
Vielleicht einfach Mal das Risiko eingehen und dann vielleicht noch etwas Entwicklung betreiben....
Hallo Killah78,

wenn es mit dem signalduino nicht geht, könnte es vielleicht mit dem LaCrossGateway gehen. Vielleicht fragst du dort einmal nach ?
Denn ich glaube so einfach ist die Dekodierung des Funkprotokolls nicht, zumal da dann noch neue Daten wie UV.... enthalten sind.

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

hanshome

Soooo, mein in https://forum.fhem.de/index.php/topic,58397.msg576607.html#msg576607 und nachfolgend beschriebenes Problem habe ich wohl gelöst:


  • habe meinen nanoCUL komplett gemäß Wiki-Eintrag aufgebaut, also inkl. Spannungsteiler
  • habe gestern Abend die aktuellste Signalduino-Dev-Version installiert
  • eine Besonderheit des X10-Protokolls im Signalduinomodul hat mich dann auch noch auf 'ne falsche Fährte gelockt

Ich habe hier 'nen X10-Bewegungsmelder, bei Bewegungserkennung liefert der folgende Einträge im Event-Log
2017-02-15 21:08:05 RFXX10REC bw_Schlafzimmerschrank Unknown: on
2017-02-15 21:08:05 RFXX10REC bw_Schlafzimmerschrank on


Das Problem ist, dass hierfür aber keine Einträge im Logfile erscheinen, egal in welchem Level. Das hat mich dann mit der folgenden Fehlermeldung auf 'ne falsche Fährte gelockt:
2017.02.04 15:02:43 2: After sleep: Unknown argument Unknown:, choose one of off:noArg on:noArg  on-for-timer intervals on-till on-till-overnight blink off-for-timer off-till off-till-overnight toggle

Aber nu ist das klar, das ist die Fehlermeldung für die erste Meldung des Sensors. Ich habe jetzt erstmal zwei notifys definiert, die auf bw_Schlafzimmerschrank:on bzw. ...:off triggern. Damit funktioniert auch mein Bewegungsmelderlicht im begehbaren Schrank :)

Ralf9

Zitat von: elektron-bbs am 25 Februar 2017, 17:27:55
Hallo,
der RSSI wird ja jetzt als Internal vom SIGNALduino angezeigt. Ich habe aber noch keine Lösung gefunden, wie dieser Wert auch geloggt und weiterverarbeitet werden kann. Beim CUL muss man ja das Attribut "addvaltrigger" setzen. Das finde ich aber bei sduino nicht. Habe ich da etwas übersehen?

Ich habe das Attribut "addvaltrigger" in die dev Version eingebaut
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt



Ich habe auch das keepalive logging etwas verbessert:

So sieht es normalerweise aus, wenn mindestens alle 60 Sek was empfangen wird
2017.02.26 11:55:54.135 4 : sduino/keepalive ok, retry = 0
2017.02.26 11:56:54.135 4 : sduino/keepalive ok, retry = 0


Wenn innerhalb 60 Sek nichts empfangen wird, dann wird retry erhöht und ein ping gesendet
2017.02.26 12:01:54.151 4 : sduino/KeepAlive not ok, retry = 1 -> get ping
2017.02.26 12:01:54.359 4 : sduino/msg READ: OK
2017.02.26 12:02:54.156 4 : sduino/keepalive ok, retry = 0
2017.02.26 12:03:54.161 4 : sduino/KeepAlive not ok, retry = 1 -> get ping
2017.02.26 12:03:54.372 4 : sduino/msg READ: OK
2017.02.26 12:04:54.167 4 : sduino/keepalive ok, retry = 0
2017.02.26 12:05:54.170 4 : sduino/KeepAlive not ok, retry = 1 -> get ping
2017.02.26 12:05:54.283 4 : sduino/msg READ: OK


Wenn beim ping keine Antwort kommt, sieht es so aus (hier war ein per WLAN angebunderer Signalduino nicht erreichbar)
2017.02.26 12:09:54.191 4 : sduino/KeepAlive not ok, retry = 1 -> get ping
2017.02.26 12:10:54.194 3 : sduino/KeepAlive not ok, retry = 2 -> get ping
2017.02.26 12:11:54.198 3 : sduino/KeepAlive not ok, retry = 3 -> get ping
2017.02.26 12:12:54.201 3 : sduino/keepalive not ok, retry count reached. Reset
2017.02.26 12:12:54.201 3 : sduino reset
2017.02.26 12:12:54.202 3 : Opening sduino device 192.168.0.13:23
2017.02.26 12:12:54.202 4 : HttpUtils url=http://192.168.0.13:23/
2017.02.26 12:12:57.207 3 : Can't connect to 192.168.0.13:23: connect to http://192.168.0.13:23 timed out
2017.02.26 12:12:57.207 3 : SIGNALduino sduino: connect to http://192.168.0.13:23 timed out


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

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

#269
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?

:'(


Hier das List:

Internals:
   Clients    :IT:CUL_TCM97001:SIGNALduino_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:SIGNALduino_un:
   DEF        /dev/ttyUSB0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/ttyUSB0@57600
   FD         13
   NAME       sduino
   NR         118
   PARTIAL
   STATE      opened
   TIME       1488658909
   TYPE       SIGNALduino
   version    V 3.3.1-dev SIGNALduino - compiled at Jan 12 2017 23:04:38
   Matchlist:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^YsA[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SIGNALduino_RSL ^r[A-Fa-f0-9]+
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   Readings:
     2017-03-04 09:11:18   ccreg           C3E = 00 C8 00 00 00 00 00 00
     2017-03-04 21:22:03   config          MS=1;MU=1;MC=1
     2017-03-04 21:22:10   freeram         879
     2017-03-04 21:31:52   ping            OK
     2017-03-04 09:43:01   raw             EEPROM 00 : 33 1D 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10
     2017-03-04 21:21:52   state           opened
     2017-03-04 09:27:45   uptime          0 00:19:47
     2017-03-04 21:21:52   version         V 3.3.1-dev SIGNALduino - compiled at Jan 12 2017 23:04:38
   Getcmd:
   Keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     45
     51
     55
     6
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     42
     44
     44.1
     46
     48
     49
     5
     50
     56
     59
     60
     8
     9
Attributes:
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   room       IT
   verbose    5
FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.