Signalduino Entwicklung

[Ralf9]

Code Auswählen Erweitern

V 3.2.0-b14 SIGNALduino - compiled at Mar 4 2016 22:13:07


Die letzte stabile Version ist z.Zt. die "V 3.2.0-b12 SIGNALduino .." siehe:
https://forum.fhem.de/index.php/topic,38831.msg418861.html#msg418861
oder
https://forum.fhem.de/index.php/topic,38831.msg418832.html#msg418832

Code Auswählen Erweitern

2016.03.17 17:23:57 1: reload: Error:Modul 00_SIGNALduino deactivated:
Too many arguments for main::RemoveInternalTimer at ./FHEM/00_SIGNALduino.pm line 1516, near ""SIGNALduino_HandleWriteQueue")"
BEGIN not safe after errors--compilation aborted at ./FHEM/00_SIGNALduino.pm line 2093, <$fh> line 313.
2016.03.17 17:23:57 0: Too many arguments for main::RemoveInternalTimer at ./FHEM/00_SIGNALduino.pm line 1516, near ""SIGNALduino_HandleWriteQueue")"

Benutzt Du auch die Sendefunktion? sieht nach einem Problem bei der Sendewarteschlange aus die Sidey vor kurzem eingebaut hat.

Gruß Ralf

[Dr.E.Witz]

Hallo,

Ich nutze die Version
V 3.2.0-b12 SIGNALduino - compiled at Feb 13 2016 21:34:09 zum reinen Empfang.
Keine Abstürze.

Der WLAN Stick schläft allerdings ein, LAN nicht.
Das ist aber ein bekanntes Problem beim Raspi...

Gruß

Michael

[Ralf9]

In der 00_SIGNALduino.pm war in der Zeile 1516 ein Syntaxfehler, ist habe ihn gefixt. Müsste jetzt funktionieren.

@Sidey
Das senden von IT V1 funktioniert noch nicht. Mit dieser Änderung in Zeile 1145 müsste es funktionieren:

Code Auswählen Erweitern

if ($arg =~ /^is.*/ && (length($arg) == 34) || length($arg) == 14)

Code Auswählen Erweitern

2016.03.18 20:42:44 5 : sduino: command for gets: isF00000000FFF
2016.03.18 20:42:44 5 : sduino: calling set :sendmsg P17;R6#F00000000FFF
2016.03.18 20:42:44 5 : sduino: sendmsg Preparing rawsend command for protocol=17, repeats=6, bits= F00000000FFF
2016.03.18 20:42:44 1 : PERL WARNING: Use of uninitialized value $clock in multiplication (*) at ./FHEM/00_SIGNALduino.pm line 1064.
2016.03.18 20:42:44 4 : sduino/set: sending via SendMsg: SR;R=6;P0=0;P1=0;P2=0;P3=0;D=0103020302030203020302030203020302;
Es ist aber noch ein "PERL WARNING" dabei.

Das set enable/disableMessagetype funktioniert nicht mehr:

Code Auswählen Erweitern

2016.03.18 20:45:26 4 : set sduino enableMessagetype manchesterMC CEC
2016-03-18 20:45:26 SIGNALduino sduino enableMessagetype manchesterMC
2016.03.18 20:45:26 5 : sduino SW: manchesterMC
2016.03.18 20:45:26 4 : sduino/msg READ: Unsupported command
2016.03.18 20:45:27 5 : sduino/HandleWriteQueue: nothing to send, stopping timer

Gruß Ralf

[michiatlnx]

Alles Klar, damit geht es wieder und mein TFA Temp Sensor geht jetzt auch wieder.

V 3.2.0-b12 SIGNALduino - compiled at Feb 13 2016 21:34:09
CUL_TX Unknown device 60, please define it

Senden wollte ich eigentlich die bereits zurückgegebenen mumbi Steckdosen war aber noch nicht implementiert, habe jetzt die IT-1500 bestellt.

Vielen Dank für den Hinweis.

[Sidey]

Da kommt man vom Hundertsten ins Tausende... Echt schade, dass die Fehlerbehebungen und Anpassungen immer wieder Funktionen beeinträchtigen.

Hat das mal jemand eine Idee, wie man so was automatisiert testen könnte?

Grüße Sidey

[Sidey]

@Sidey
Das senden von IT V1 funktioniert noch nicht. Mit dieser Änderung in Zeile 1145 müsste es funktionieren:

Code Auswählen Erweitern

if ($arg =~ /^is.*/ && (length($arg) == 34) || length($arg) == 14)

Danke für das Beheben des Fehlers.
Das ITv1 nicht funktioniert finde ich seltsam.  || length($arg) == 14 ist prinzipiell eine Möglichkeit um die sendraw Funktion zu verwenden.
Bislang ist das itv1 Senden aber direkt als Funktion im SIGNALduino implementiert.

Das Problem mit enable/disable ms,mc,mu habe ich behoben. Es war ein einfacher copy/past Fehler

Den master Branch habe ich jetzt auf die Firmware 3.2.0b12 zurück gesetzt.
Der Modul Code entspricht jedoch dem aktuellen.

Grüße Sidey

[sash.sc]

Da kommt man vom Hundertsten ins Tausende... Echt schade, dass die Fehlerbehebungen und Anpassungen immer wieder Funktionen beeinträchtigen.

Schade das es so ist.

Möchte hier aber mal ein dickes Dankeschön loswerden, für die Unterstützung und die Arbeit die hier geleistet wird.

Hätte es einen Vorteil den Signalduino als auch Sender  einzusetzen, gegenüber den nano cul mir der afw?

[Ralf9]

Das ITv1 nicht funktioniert finde ich seltsam.  || length($arg) == 14 ist prinzipiell eine Möglichkeit um die sendraw Funktion zu verwenden.
Bislang ist das itv1 Senden aber direkt als Funktion im SIGNALduino implementiert.

Ich habe es mir nochmals etwas genauer angeschaut. Das senden von ITv1 scheint zu funktionieren.
Das Problem ist, daß das IT-Modul nicht die erwartete Antwort ( "raw => $msg" ) bekommt.

Das Problem dürfte hier in der SIGNALduino_Get sein. Hier wird immer ein undef zurückgegeben:

Code Auswählen Erweitern

  return undef; # We will exit here, and give an output only, if asny output is supported. If this is not supported, only the readings are updated
 
  return undef if ($hash->{CL} && $hash->{CL}->{canAsyncOutput});    # Exit for async output here
 
  ($err, $msg) = SIGNALduino_ReadAnswer($hash, $a[1], 0, $gets{$a[1]}[1]);

Nachtrag:
Eine Möglichkeit wäre evtl:

Code Auswählen Erweitern

return "$a[0] $a[1] => $arg" if ($arg =~ /^is.*/ && length($arg) == 14);

Gruß Ralf

[Sidey]

Ja, aber der Arduino müsste das Signal ja trotzdem senden. Ich habe es heute ausprobiert.

Die Steckdosen werden nicht geschaltet, aber der Arduino gibt den Befehl sogar korrekt per Echo zurück...

[michiatlnx]

Hallo,
heute habe ich die intertechno IT-1500 erhalten.
Device wird per autocreate als IT protocol V3 angelegt und das Schalten per Fernbedienung wird erkannt.
Beim Senden aus FHEM entsteht eine einminütige pause, wo es laut Log auch keine anderen Daten am sduino empfangen werden.
Die Steckdose wird aber nicht geschaltet.

Ein Protokoll Log habe ich auf github gestellt unter:
Protokoll für intertechno IT-1500 #73 - https://github.com/RFD-FHEM/RFFHEM/issues/73

gruss Michael

[RappaSan]

Da es in meinem in https://forum.fhem.de/index.php/topic,38831.msg423606.html#msg423606 geschilderten Problem auch um IT-devices mit sowohl V1 als auch V3 Protokoll geht- besteht da eventuell ein Zusammenhang?
Die Meldung "IT IODev device didn't answer is command correctly:   raw => No answer" macht mich etwas stutzig...

[Sidey]

Ich habe den Fehler noch nicht näher analysieren können.
Ich denke er tritt mit allen Sendebefehl auf.

Für das Senden der IT Dosen werden drei Befehle vom IT Modul gesendet.
1. Clock oder Wiederholungen anpassen
2. Signal senden
3. Clock anpassen

Es kann sein, dass Befehl 3. an den Arduino gesendet wird, bevor Befehl 2 bearbeitet wurde.
Das liegt daran, dass ich die Get Funktion auf non blocking umgestellt habe.

Mal sehen ob das der Grund ist, bislang ist es nur eine Vermutung.

Sidey

[Ralf9]

Ich sehe für das IT senden nur eine saubere Möglichkeit. Das umstellen auf IOWrite, dazu sind jedoch anpassungen um IT-Modul notwendig.

Code Auswählen Erweitern

  if ($io->{TYPE} ne "SIGNALduino") {
# das IODev ist kein SIGNALduino
..
  } else {  # SIGNALduino
if ($hash->{READINGS}{protocol}{VAL} eq "V3") {
my $SignalRepeats = AttrVal($name,'ITrepetition', '6');
my $ITClock = AttrVal($name,'ITclock', undef);
if (defined($ITClock)) {
$ITClock = '#C' . $ITClock;
} else {
$ITClock = '';
}
IOWrite($hash, 'sendMsg', 'P17#' . substr($message,2) . '#R' . $SignalRepeats . $ITClock);
} else {

Code Auswählen Erweitern

2016.03.20 15:55:09 2 : IT_0011101101010011010010111000000: IT set IT_0011101101010011010010111000000 on
2016.03.20 15:55:09 5 : sduino/write: adding to queue sendMsg P17#00111011010100110100101110010000#R4#C240
2016.03.20 15:55:09 5 : sduino: sendmsg Preparing rawsend command for protocol=17, repeats=4, clock=240 bits=00111011010100110100101110010000
2016.03.20 15:55:09 4 : sduino/set: sending via SendMsg: SR;R=4;P0=240;P1=-2400;P2=-1200;P3=-240;D=0103020302020302030203030202030203030202030302020303020302020302030302020303020302020303020203020302030302030202030302030203020302;
2016-03-20 15:55:09 IT IT_0011101101010011010010111000000 on
2016.03.20 15:55:09 5 : sduino SW: SR;R=4;P0=240;P1=-2400;P2=-1200;P3=-240;D=0103020302020302030203030202030203030202030302020303020302020302030302020303020302020303020203020302030302030202030302030203020302;
2016.03.20 15:55:09 5 : sduino/HandleWriteQueue: nothing to send, stopping timer
2016.03.20 15:55:09 4 : sduino/msg READ: SR;R=4;P0=240;P1=-2400;P2=-1200;P3=-240;D=0103020302020302030203030202030203030202030302020303020302020302030302020303020302020303020203020302030302030202030302030203020302;


Spricht etwas dagegen für das IT V1 auch das sendmsg zu verwenden? Hat dies beim Timing des Sendesignals irgendwelche Nachteile?
Kann dafür dann die Protokoll ID 3 verwendet werden?

Gruß Ralf

[Ralf9]

Spricht etwas dagegen für das IT V1 auch das sendmsg zu verwenden? Hat dies beim Timing des Sendesignals irgendwelche Nachteile?
Kann dafür dann die Protokoll ID 3 verwendet werden?

Bei mir funktioniert jetzt auch das senden vom IT V1 wie gewünscht über sendmsg.
Ist es ok, wenn ich die notwendigen Anpassungen an der sendMsg im dev-r32 commite?

Code Auswählen Erweitern

2016.03.20 20:46:37 2 : IT_F00000000F_test: IT set IT_F00000000F_test on
2016.03.20 20:46:37 5 : sduino/write: adding to queue sendMsg P3#F00000000FFF#R5#C300
2016.03.20 20:46:37 5 : sduino: sendmsg Preparing rawsend command for protocol=3, repeats=5, clock=300 bits=F00000000FFF
2016.03.20 20:46:37 4 : sduino/set: sending via SendMsg: SR;R=5;P0=300;P1=-9300;P2=900;P3=-300;P4=-900;D=01042304040404040404040404040404040404042304230423;
2016-03-20 20:46:37 IT IT_F00000000F_test on
2016.03.20 20:46:37 5 : sduino SW: SR;R=5;P0=300;P1=-9300;P2=900;P3=-300;P4=-900;D=01042304040404040404040404040404040404042304230423;
2016.03.20 20:46:37 4 : sduino/msg READ: SR;R=5;P0=300;P1=-9300;P2=900;P3=-300;P4=-900;D=01042304040404040404040404040404040404042304230423;
2016.03.20 20:46:38 5 : sduino/HandleWriteQueue: nothing to send, stopping timer

Gruß Ralf

[Sidey]

Mach das, nur was ist jetzt anders?