Signalduino Entwicklung

Sidey · 10 Mai 2016, 21:17:14

Ich hab ein Problem. Ich finde derzeit einfach keine Lösung...

Ich schätze, ich sehe den Wald vor lauter Bäumen nicht.

Jetzt, versuche ich erst mal mein Problem zu schildern..

Es gibt eine List, die enthält mögliche Werte. Nehmen wir an, 43, 50 und 100. Gesucht wird ein Wert von ca. 45 (+-15).
Also sind 40 und 50 valide. Sortiert wird auch. Also haben wir 43 und 50, was in der Toleranz wäre.

Jetzt wird ein 2. Wert gesucht. z.B. 90 (+-15).
100 ist im Toleranzbereich, also ein Wert.

Es gibt also mehrere Listen (zwei im Beispiel) mit einer variablen Anzahl von Einträgen:
43,50 und 100 in diesem Beispiel.

Ich brauche alle Kombinationen dieser Listen.

In diesem Beispiel:
43,100
50,100

Ergänzend muss ich sagen. Es steht nicht fest, wie viel Einträge in einer der Listen entsteht und an welcher Stelle die Liste mit mehr oder weniger Einträgen entsteht.

Edit: Das formulieren der Problemstellung hat mich nun doch weiter gebracht. Sieht schon ganz gut aus, was ich da jetzt habe:

Code Auswählen


my @array = (
    [ "2", "3"],
    [ "4", "6", ],
    [ "1",  ],
 
    ); 
my @results = ('');

foreach my $subarray (@array)
{
    @results = map {my $res = $_; map $res.$_, @$subarray } @results;
}
print join "\n", @results,'';

Code Auswählen

Grüße Sidey

habeIchVergessen · 11 Mai 2016, 08:33:04

Konnte das Senden von Somfy RTS mittels SIGNALduino und der entsprechende Empfang mittels SIGNALduino erfolgreich getestet werden?

hjgode · 11 Mai 2016, 18:57:01

Hi

könnt Ihr euch mal entscheiden?

Habe gerade ein update gemacht und nun ist STATE statt 'Initialized' wieder 'opened'.

NanoCUL etc. verwenden 'Initialized', oder?!

Ist ja nicht so, dass man den State vielleicht in irgendeinem Code abfragt und dann jedesmal anpassen muss, weil Ihr euch nicht entscheiden könnt

)

Nur so als Anregung.

ein freundliches Danke

~Josef

Ellert · 11 Mai 2016, 19:12:53

Zitat von: habeIchVergessen am 11 Mai 2016, 08:33:04
Konnte das Senden von Somfy RTS mittels SIGNALduino und der entsprechende Empfang mittels SIGNALduino erfolgreich getestet werden?

Ich habe versucht mit dem SD zu senden und ein SOMFY-Gerät 12389A anzulernen, das hat nicht geklappt, mit
V 3.2.0-b23 SIGNALduino - compiled at May 8 2016 01:24:34
00_SIGNALduino.pm 104841 2016-05-08 17:00:00Z v3.2.1-dev $

Logeintrag:
2016.05.11 19:04:21 4: SOMFY_set: somfy -> entering with mode :send: cmd :prog: arg1 :: pos :open:
2016.05.11 19:04:21 1: PERL WARNING: Argument "open" isn't numeric in addition (+) at ./FHEM/10_SOMFY.pm line 956.
2016.05.11 19:04:21 4: SOMFY_set: handled command prog --> move :prog: newState :open:
2016.05.11 19:04:21 5: SOMFY_set: handled for drive/udpate: updateState :: drivet :0: updatet :0:
2016.05.11 19:04:21 4: SOMFY_sendCommand: somfy -> cmd :prog:
2016.05.11 19:04:21 5: SOMFY_sendCommand: somfy -> message :sA080000012389A:
2016.05.11 19:04:21 5: SDuino_433/write: adding to queue Y sA080000012389A

Der Rolladen hat beim Anlernen nicht reagiert.
Ich meine, die Adresse wird falsch übermittelt 12389A statt 9A2812.

habeIchVergessen · 11 Mai 2016, 21:10:02

es gibt noch eine Version vom 10.05.2016, 106.817 Bytes, md5: a1271eef5ae6907e8a324f8b5beaa216
Sie enthält den Bugfix für das Decode von Nachrichten. Aber keinen Code für das Senden (nur in meinem Fork, 108.309 Bytes, md5: 24278b82a7c3d88b9ca85959b7336004).

Ist schon verwirrend, das beim Senden (nicht vertauscht) und Empfangen (vertauscht) die Adressbytes unterschiedlich dargestellt werden. Ist bis dato durch SOMFY so vorgegeben.

Selbst wenn beim Anlernen die Adresse nicht stimmt, dann sollte doch wenigstens das Anlernen funktionieren (Funksignal kommt an).

Der Patch von Ralf9 (10_SOMFY.pm) scheint auch zu Fehlen (Nachricht lautet dann P43#A080000012389A#R6):

Zitat von: Ralf9 am 09 Mai 2016, 12:53:07
Eine Unterscheidung ist auch über den $io->{TYPE} möglich:
Code Auswählen Erweitern
if ($io->{TYPE} ne "SIGNALduino") { # das IODev ist kein SIGNALduino Log3($name,5,"SOMFY_sendCommand: $name -> message :$message: "); IOWrite( $hash, "Y", $message ); } else { # SIGNALduino my $SignalRepeats = AttrVal($name,'repetition', '6'); $message = 'P43#' . substr($message,1). '#R' . $SignalRepeats; Log3 $hash, 4, "$io->{NAME} SOMFY_sendCommand: $name -> message :$message: "; IOWrite($hash, 'sendMsg', $message); }

PS: habe einen 2. Satz Hardware bestellt

RappaSan · 12 Mai 2016, 07:17:29

Ich gebe Josef recht. Alles CUL-ähnliche steht auf "initialized" nach "opened".
Wenn ich's recht verstanden habe bedeutet "opened" nur, daß der Kommunikationsport ansprechbar ist, "initialized" dagegen, daß er auch brauchbare Reaktion zeigt.

Sidey · 12 Mai 2016, 07:28:12

Also der State ist schon seit einer Weile opened.

Die Bezeichnung kommt aus DevIO und ist aus meiner Sicht der FHEM Standard.

RappaSan · 12 Mai 2016, 09:00:32

Wenn bei mir ein CUL auf "opened" steht, funktioniert er nicht.
Jaja ich weiß - der Signalduino ist kein CUL, aber die Funktion ist nahezu gleich.
Aber es lohnt nicht, aus der Statusbezeichnung eine Grundsatzdiskussion anzufachen - hauptsache dat Ding läuft.
Und laufen tut's bei mir echt prima - alle verfügbaren Daumen hoch

Ralf9 · 12 Mai 2016, 10:03:25

Zitat von: RappaSan am 12 Mai 2016, 07:17:29
Ich gebe Josef recht. Alles CUL-ähnliche steht auf "initialized" nach "opened".
Wenn ich's recht verstanden habe bedeutet "opened" nur, daß der Kommunikationsport ansprechbar ist, "initialized" dagegen, daß er auch brauchbare Reaktion zeigt.

Ja, das ist mir auch schon aufgefallen. Ein nano ohne firmware hat auch schon den state opened.

Gruß Ralf

Ellert · 12 Mai 2016, 13:03:35

Zitat von: habeIchVergessen am 11 Mai 2016, 21:10:02
es gibt noch eine Version vom 10.05.2016, 106.817 Bytes, md5: a1271eef5ae6907e8a324f8b5beaa216
Sie enthält den Bugfix für das Decode von Nachrichten. Aber keinen Code für das Senden (nur in meinem Fork, 108.309 Bytes, md5: 24278b82a7c3d88b9ca85959b7336004).

Ist schon verwirrend, das beim Senden (nicht vertauscht) und Empfangen (vertauscht) die Adressbytes unterschiedlich dargestellt werden. Ist bis dato durch SOMFY so vorgegeben.

Selbst wenn beim Anlernen die Adresse nicht stimmt, dann sollte doch wenigstens das Anlernen funktionieren (Funksignal kommt an).

Der Patch von Ralf9 (10_SOMFY.pm) scheint auch zu Fehlen (Nachricht lautet dann P43#A080000012389A#R6):
PS: habe einen 2. Satz Hardware bestellt

Dein Link enthält in der zip- Datei eine md5: 8c143364a69f41b9a9e461aa52fdb4fd *00_SIGNALduino.pm die hat 108170 bytes.
Beim updaten mit update all https://raw.githubusercontent.com/habeIchVergessen/RFFHEM/dev-r32/controls_signalduino.txt
erhalte ich Got "108170 bytes for FHEM/00_SIGNALduino.pm, expected 106817".

Wo bekomme ich die

Zitat(nur in meinem Fork, 108.309 Bytes, md5: 24278b82a7c3d88b9ca85959b7336004)

her?

Ich versuch mal die 108170.

habeIchVergessen · 12 Mai 2016, 13:46:11

@Ellert: habe den Link auf 00_SIGNALduino.pm geändert. Die Datei hat sich zwischenzeitlich schon wieder geändert. Unter Linux kannst du

Code Auswählen


wget <URL>

im FHEM-Verzeichnis aufrufen.

hjgode · 12 Mai 2016, 17:34:22

Zitat von: Ralf9 am 12 Mai 2016, 10:03:25
Ja, das ist mir auch schon aufgefallen. Ein nano ohne firmware hat auch schon den state opened.

Gruß Ralf

Hi

Ist mir auch egal wie das heisst, Hauptsache ist, dass es nicht wieder geändert wird.

Ohne Update, nach langer Zeit, wäre mir das auch nicht aufgefallen.

Leider hat das Update (dev32 Zweig) auch nichts gebracht, der SIGNALduino Code hängt sich halbwegs auf. Vor dem Update alle 1.5 Tage, danach jetzt ca. alle 1-1.5 Stunden. Seltsamerweise liefert er noch Daten, er antwortet dann aber nicht mehr auf Version oder freeRam Abfragen. Zumindest bekomme ich keine Hideki-Daten mehr. Ich muss dann ein 'set sduino reset' machen, dann läuft er wieder und die Hideki Daten werden dekodiert. Hab schon eine watchdog gebaut, die alle 30 Minuten prüft ob die Hideki Daten aktualisiert wurden und ansonsten das reset ausführt.

~Josef

Ellert · 12 Mai 2016, 17:55:46

Zitat von: habeIchVergessen am 12 Mai 2016, 13:46:11
@Ellert: habe den Link auf 00_SIGNALduino.pm geändert. Die Datei hat sich zwischenzeitlich schon wieder geändert. Unter Linux kannst du

Code Auswählen Erweitern
wget <URL>
im FHEM-Verzeichnis aufrufen.

@habeIchVergessen:
Folgendes Setup:

1. Pi Wirksystem
nanoCUL433 Somfy senden für Tests
RFXTRX433E Somfy senden Wirkbetrieb

2. Pi Wirk- u. Testsystem
FHEMDuino Somfy empfangen für Somfy Handsender Wirkbetrieb, Somfy empfangen Testbetrieb.

3. Pi Testsystem
SIGNALduino Somfy senden/empfangen Testbetrieb
Firmware: V 3.2.0-b23 SIGNALduino - compiled at May 8 2016 01:24:34
10_SIGNALduino.pm um 14:07:27 gezogen 102915 Byte von hier https://forum.fhem.de/index.php/topic,38831.msg449722.html#msg449722
10_SOMFY.pm ergänzt mit dem Code aus Deinem Beitrag.

Versuch1:
1. Pi manuell das Gerät SOMFY_12389A angelegt und davon gesendet.
Ergebnis1:
2. Pi FHEMuino empfangt und legt FHEMduino_SomfyR_12389A an:

Zitat2016.05.12 17:08:39 4: SomfyR: Ys a5 10 0005 9a3812
2016.05.12 17:08:39 1: FHEMduino_SomfyR undefined sensor detected, address 12389A
2016.05.12 17:08:39 2: autocreate: define FHEMduino_SomfyR_12389A FHEMduino_SomfyR 12389A
2016.05.12 17:08:39 2: autocreate: define FileLog_FHEMduino_SomfyR_12389A FileLog ./log/FHEMduino_SomfyR_12389A-%Y.log FHEMduino_SomfyR_12389A
2016.05.12 17:08:39 4: SomfyR: Ys a5 10 0005 9a3812
2016.05.12 17:08:40 1: FHEMduino_SomfyR No rawDevice set in FHEMduino_SomfyR_12389A
2016.05.12 17:08:40 4: SomfyR: Ys a5 10 0005 9a3812
2016.05.12 17:08:40 4: SomfyR: Ys a5 10 0005 9a3812
2016.05.12 17:08:40 4: SomfyR: Ys a5 10 0005 9a3812

3. Pi SIGNALduino empfängt und legt kein Gerät an

Zitat2016.05.12 17:08:39 4: signal433/msg READ: MC;LL=-1295;LH=1285;SL=-682;SH=676;D=5A4A4A4FD5EDFF;C=653;L=56;

Versuch2:
3. Pi manulles Anlegen von SOMFY_12389A, Attribut IODev wird nicht automatisch angelegt (manuell nachgeholt).
Eegebnis2:
3. Pi SIGNALduino zeigt im Log:

Zitat
2016.05.12 17:29:09 5: signal433/write: adding to queue sendMsg P43#A211000212389A#R6

2. Pi FHEMduino empfängt nichts.

Soweit ich den Sendevorgang verstehe müsste
das SOMFY-Gerät Klartext and das SIGNALduino Gerät senden, das macht es auch.
Im SIGNALduino Gerät müsste die Nachricht so aufbereitet werden, wie in der somfy_rts.c
Das Ergebnis müsste dann, invertiert? oder nicht? an die Hardware gesendet werden.

Edit: Mir scheint Du hast auf die falsche Datei verlinkt, https://github.com/RFD-FHEM/RFFHEM/raw/master/FHEM/00_SIGNALduino.pm

habeIchVergessen · 12 Mai 2016, 19:32:40

@Ellert: du hast recht
https://github.com/habeIchVergessen/RFFHEM/raw/dev-r32/FHEM/00_SIGNALduino.pm

Sidey · 12 Mai 2016, 20:28:41

Zitat von: hjgode am 12 Mai 2016, 17:34:22
Hauptsache ist, dass es nicht wieder geändert wird.

Leider hat das Update (dev32 Zweig) auch nichts gebracht, der SIGNALduino Code hängt sich halbwegs auf.

Ich habe nicht vor, den State im Modul noch zu ändern. Das kommt jetzt so aus IODev.

Was das Aufhängen angeht.
Der Signalduino wird in regelmäßigen Intervallen abgefragt. Antwortet er nicht, dann wird er neu initialisiert.
Finden sich im Logfile denn Hinweise darauf?
Ist schon seltsam, dass es bei dir nicht funktioniert.
Schon dass er so regelmäßig abschmiert ist nicht richtig.

Grüße Sidey