SIGNALDuino Empfänger Firmware V 3.3.2r-dev

Begonnen von Ralf9, 07 Januar 2018, 21:37:44

Vorheriges Thema - Nächstes Thema

Ralf9

Danke für das Testen.
An den Nachrichten vom UV- und Helligkeitssensor der WH3080 und an den FS20 Nachrichten lässt sich erkennen, daß die Trennung der MU-Nachrichten recht gut funktioniert.

Jetzt fehlt nur noch ein Test von Siro mit mit aktiviertem MC-Dedoder.

Ich habe in dieser Übersicht noch die allgemeinen Befehle ergänzt:
https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921

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

andies

#76
Eine Frage zur 3.3.2. Ich habe bei 3.3.1 ein raw-signal gesendet, um mein Gartentor zu öffnen:
set sduino raw SR;;R=7;;P0=335;;P1=-665;;P2=-335;;P3=665;;P4=-15018;;D=01010232310101023101010234;;
Das  bewegt sich mit 3.3.2 aber nicht mehr. Gab es da eine Änderung der Befehle?
Fehler von mir. Alles ok.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Bei mir hat sich heute morgen (zumindest ohne mein bewusstes Zutun) die Frequenz von 433.92 verstellt, siehe Screenshot vom iPhone. Hat das schon mal jemand gehabt?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

KölnSolar

Das hatten wir doch schon oft, zumindest, wenn meine Annahme richtig ist, dass es sich um einen SelbstbauCUL handelt, also Arduino mit CC1101. Ursachen waren dann kalte Lötstellen, fehlende Verbindungen, Spannungsprobleme.....
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

andies

Zitat von: KölnSolar am 02 Mai 2018, 11:03:36
wenn meine Annahme richtig ist, dass es sich um einen SelbstbauCUL handelt, also Arduino mit CC1101. Ursachen waren dann kalte Lötstellen, fehlende Verbindungen, Spannungsprobleme.....
Ist ein Selbstbau, korrekt. Allerdings lief der ein Jahr fehlerfrei und erst seit der neuen dev hatte ich das Problem. Wenn es nochmal auftritt, schaue ich mal in diese Richtung.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Ich habe erneut eine Frequenzänderung beobachtet. Bevor ich die Lötstellen prüfe (ich muss dazu das Ding ausbauen), würde ich gern schauen, ob es ein Muster bei der Umwandlung gibt; bei 3.3.1 hatte ich diese Probleme nämlich nicht. Dazu würde ich gern die Frequenz selbst beobachten und einen Logeintrag generieren, wenn die Frequenz wechselt.

Gibt es einen einfachen Weg, die Frequenz abzufragen? Ich hole sie sonst mit

get sduino freq

allerdings weiß ich nicht, wie ich daraus einen Perlcode machen kann. Geht denn so etwas wie

$freq=fhem("get sduino freq")

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Ralf9

Ist die Frequenzänderung nur ein Anzeigeproblem oder funktioniert dann der Empfang nicht mehr?


Die Frequenz kannst Du mit "get sduino ccconf" abfragen.
Wenn Du
attr sduino noMsgVerbose 3
setzt, dann steht auch bei verbose 3 im log folgendes:
2018.05.06 19:51:00.705 3 : sduino/noMsg Parse: C0Dn11=10B07117C43023B900070018146C070090

10B071 ist 433.920MHz

Du kannst mit
get sduino raw C0Dn1
auch die Frequenz Register direkt auslesen.
2018.05.06 19:10:44.184 3 : sduino/noMsg Parse: C0Dn03=10B071

Wenn sich die Frequenz geändert hat, dann ist auch der Inhalt vom EEPROM und die uptime interessant:
get sduino raw r0Fn
2018.05.06 19:11:49.662 3 : sduino/noMsg Parse: EEPROM 0F : 10 B0 71 17 C4 30 23 B9 00 07 00 18 14 6C 07 00


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

andies

Danke, damit komme ich (hoffentlich) weiter. Ich kann dann nicht mehr senden, weil ich mehrere 433MHz-Geräte habe. (Bzw ich müsste es so umprogrammieren, dass vor jedem Senden oder gar regelmäßig die Frequenz geändert wird.) Ich beobachte mal und melde mich dann wieder.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

So, jetzt habe ich zum ersten Mal eine Situation, in der die Frequenz geändert wird. Ich habe folgender Logeinträge
2018.05.07 15:03:12 3: sduino/noMsg Parse: SR;R=7;P0=335;P1=-665;P2=-335;P3=665;P4=-15018;D=01010102310101023101023104;
2018.05.07 15:03:12 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
... keine weiteren sduino-Eintrage ...
2018.05.07 16:47:36 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 16:50:00 3: sduino: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2018.05.07 16:50:00 3: sduino/noMsg Parse: W0F10
2018.05.07 16:50:01 3: sduino/noMsg Parse: W10B0
2018.05.07 16:50:01 3: sduino/noMsg Parse: W1171
2018.05.07 16:50:01 3: sduino/noMsg Parse: cmdStrobeReg 36 chipStatus 1 delay1 0
2018.05.07 16:50:02 3: sduino/noMsg Parse: cmdStrobeReg 34 chipStatus 0 delay1 1

und dazwischen ist es ja passiert. Ich würde mir gern mehr Einträge anzeigen lassen, kriege das aber nicht richtig hin: https://forum.fhem.de/index.php?topic=87579.msg800235#msg800235
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Ist es möglich, dass ich das Problem selbst auslöse? Ich habe folgende Einträge im Logfile, die mE einen Wechsel der Frequenz anzeigen:
2018.05.07 21:07:01 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:07:25 3: motion_switch_off return value:

2018.05.07 21:07:50 3: sduino/noMsg Parse: SR;R=7;P0=335;P1=-665;P2=-335;P3=665;P4=-15018;D=01010102310101023101023104;
2018.05.07 21:07:50 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:08:59 3: sduino IT_set: Garagentor on
2018.05.07 21:08:59 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:08:59 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:09:00 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:09:10 3: sduino IT_set: Garagentor off
2018.05.07 21:09:11 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:09:11 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:09:11 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304230404;
2018.05.07 21:09:25 3: sduino IT_set: Garagentor on
2018.05.07 21:09:25 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:09:25 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:09:26 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:00 3: sduino IT_set: Garagentor on
2018.05.07 21:10:01 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:01 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:10:01 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:07 3: sduino IT_set: Garagentor on
2018.05.07 21:10:07 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:07 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:10:08 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:24 3: sduino IT_set: Garagentor on
2018.05.07 21:10:25 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:25 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:10:25 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:37 3: sduino IT_set: Garagentor on
2018.05.07 21:10:38 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:38 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:10:38 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:11:00 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:22 3: sduino IT_set: Garagentor off
2018.05.07 21:11:22 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:22 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:22 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304230404;
2018.05.07 21:11:28 3: sduino IT_set: Garagentor on
2018.05.07 21:11:29 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:29 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:11:29 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:11:48 3: sduino IT_set: Garagentor on
2018.05.07 21:11:49 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:49 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:49 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:11:53 3: sduino IT_set: Garagentor off
2018.05.07 21:11:54 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:54 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:54 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304230404;

Besagtes Garagentor ist wie folgt definiert, das sind jetzt mehrere Schritte, leider:
Internals:
   00         f0
   DEF        0FF00FF0FF 0F F0
   IODev      sduino
   NAME       Garagentor
   NR         102
   STATE      &nbsp
   TYPE       IT
   XMIT       0ff00ff0ff
   XMITdimdown 00
   XMITdimup  00
   XMITon     0f
   CODE:
     1          0ff00ff0ff
   READINGS:
     2017-10-31 20:30:17   protocol        V1
     2018-05-07 21:11:53   state           off
Attributes:
   IODev      sduino
   ITclock    290
   devStateIcon .*:noIcon:noFhemwebLink
   eventMap   off:Zu on:Auf
   group      Tore
   room       Schalter

und zugleich
defmod Garagentor_Lampe notify Garagentor:.* set LampeGarage on-for-timer 180

wobei
defmod LampeGarage dummy
attr LampeGarage setList on off
attr LampeGarage useSetExtensions 1
attr LampeGarage webCmd on:off

und
defmod Lampe_Garage_Ein notify LampeGarage:on {fhem("set sduino raw SR;;;;R=3;;;;P0=1100;;;;P1=-743;;;;P2=425;;;;P3=-1401;;;;P4=630;;;;P5=-7010;;;;D=012301010123230123230123232323232323230123230123232301232323232345;;;;")}

und analog ein Befehl fuer Lampe aus.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Ralf9

Evtl kommt es ab und zu vor, daß das Register am Anfang falsch ausgelesen wird.
Anstatt 10 wird FF ausgelesen. 

C0Dn11=10B071550A3023B900070018146C070090
C0Dn11=FFB071550A3023B900070018146C070090


Wenn die Frequenz falsch angezeigt wird und Du dann noch ein paarmal ein "get sduino ccconf" machst, ist dann auch die richtige Frequenz dabei?

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

andies

Habe es gerade mal getestet. Es war die falsche Frequenz drin und nach zweimaligem lesen der ccconf (get sduino ccconf) erschien wieder 433.92.

Das verstehe ich aber nicht. Wieso ändert sich die eingestellte Frequenz, wenn ich sie lese? Ist das ein Hardware-Problem?


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Ralf9

so wies aussieht, ändert sich die eingestellte Frequenz nicht, sie wird nur ab und zu fehlerhaft ausgelesen.
Was für ein CC1101 Modul verwendest Du?

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

andies

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Ralf9

Du kannst mal testen ob die fehlerhaft ausgelesene Frequenz auch bei der 3.3.1 dev und  3.3.1 RC5/RC6 auftritt.

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